| Message ID | 1520819022-15238-1-git-send-email-me@tobin.cc (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 03/11/2018 08:43 PM, Tobin C. Harding wrote: > The kernel would like to have all stack VLA usage removed[1]. rsi uses > a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size > is defined using a magic number. We can use a pre-processor defined > constant and declare the array to maximum size. We add a check before > accessing the array in case of programmer error. > > [1]: https://lkml.org/lkml/2018/3/7/621 > > Signed-off-by: Tobin C. Harding <me@tobin.cc> > --- > > RESEND: add wireless mailing list to CC's (requested by Kalle) > > drivers/net/wireless/rsi/rsi_91x_hal.c | 13 +++++++------ > drivers/net/wireless/rsi/rsi_91x_sdio.c | 9 +++++++-- > 2 files changed, 14 insertions(+), 8 deletions(-) > > diff --git a/drivers/net/wireless/rsi/rsi_91x_hal.c b/drivers/net/wireless/rsi/rsi_91x_hal.c > index 1176de646942..839ebdd602df 100644 > --- a/drivers/net/wireless/rsi/rsi_91x_hal.c > +++ b/drivers/net/wireless/rsi/rsi_91x_hal.c > @@ -641,7 +641,7 @@ static int ping_pong_write(struct rsi_hw *adapter, u8 cmd, u8 *addr, u32 size) > u32 cmd_addr; > u16 cmd_resp, cmd_req; > u8 *str; > - int status; > + int status, ret; > > if (cmd == PING_WRITE) { > cmd_addr = PING_BUFFER_ADDRESS; > @@ -655,12 +655,13 @@ static int ping_pong_write(struct rsi_hw *adapter, u8 cmd, u8 *addr, u32 size) > str = "PONG_VALID"; > } > > - status = hif_ops->load_data_master_write(adapter, cmd_addr, size, > + ret = hif_ops->load_data_master_write(adapter, cmd_addr, size, > block_size, addr); > - if (status) { > - rsi_dbg(ERR_ZONE, "%s: Unable to write blk at addr %0x\n", > - __func__, *addr); > - return status; > + if (ret) { > + if (ret != -EINVAL) > + rsi_dbg(ERR_ZONE, "%s: Unable to write blk at addr %0x\n", > + __func__, *addr); > + return ret; > } > > status = bl_cmd(adapter, cmd_req, cmd_resp, str); > diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c > index b0cf41195051..b766578b591a 100644 > --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c > +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c > @@ -20,6 +20,8 @@ > #include "rsi_common.h" > #include "rsi_hal.h" > > +#define RSI_MAX_BLOCK_SIZE 256 > + > /** > * rsi_sdio_set_cmd52_arg() - This function prepares cmd 52 read/write arg. > * @rw: Read/write > @@ -362,7 +364,7 @@ static int rsi_setblocklength(struct rsi_hw *adapter, u32 length) > rsi_dbg(INIT_ZONE, "%s: Setting the block length\n", __func__); > > status = sdio_set_block_size(dev->pfunction, length); > - dev->pfunction->max_blksize = 256; > + dev->pfunction->max_blksize = RSI_MAX_BLOCK_SIZE; > adapter->block_size = dev->pfunction->max_blksize; > > rsi_dbg(INFO_ZONE, > @@ -567,9 +569,12 @@ static int rsi_sdio_load_data_master_write(struct rsi_hw *adapter, > { > u32 num_blocks, offset, i; > u16 msb_address, lsb_address; > - u8 temp_buf[block_size]; > + u8 temp_buf[RSI_MAX_BLOCK_SIZE]; > int status; > > + if (block_size > RSI_MAX_BLOCK_SIZE) > + return -EINVAL; > + > num_blocks = instructions_sz / block_size; > msb_address = base_address >> 16; I am not giving this patch a negative review, but my solution to the same problem has been to change the on-stack array into a u8 pointer, use kmalloc() to assign the space, and then free that space at the end. That way large stack allocations are avoided, with a minimum of changes. Larry > >
tcharding <me@tobin.cc> wrote: > The kernel would like to have all stack VLA usage removed[1]. rsi uses > a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size > is defined using a magic number. We can use a pre-processor defined > constant and declare the array to maximum size. We add a check before > accessing the array in case of programmer error. > > [1]: https://lkml.org/lkml/2018/3/7/621 > > Signed-off-by: Tobin C. Harding <me@tobin.cc> Tobin, your name in patchwork.kernel.org is just "tcharding" then it should be "Tobin C. Harding". Patchwork is braindead in a way as it takes the name from it's database instead of the From header of the patch in question. I can fix that manually but it would be helpful if you could register to patchwork and fix your name during registration. You have only one chance to fix your name (another braindead feature!) so be careful :)
"Tobin C. Harding" <me@tobin.cc> wrote: > The kernel would like to have all stack VLA usage removed[1]. rsi uses > a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size > is defined using a magic number. We can use a pre-processor defined > constant and declare the array to maximum size. We add a check before > accessing the array in case of programmer error. > > [1]: https://lkml.org/lkml/2018/3/7/621 > > Signed-off-by: Tobin C. Harding <me@tobin.cc> There were conflicts. Can you rebase on top of wireless-drivers-next and resend, please? Recorded preimage for 'drivers/net/wireless/rsi/rsi_91x_sdio.c' error: Failed to merge in the changes. Applying: rsi: Remove stack VLA usage Using index info to reconstruct a base tree... M drivers/net/wireless/rsi/rsi_91x_hal.c M drivers/net/wireless/rsi/rsi_91x_sdio.c Falling back to patching base and 3-way merge... Auto-merging drivers/net/wireless/rsi/rsi_91x_sdio.c CONFLICT (content): Merge conflict in drivers/net/wireless/rsi/rsi_91x_sdio.c Auto-merging drivers/net/wireless/rsi/rsi_91x_hal.c Patch failed at 0001 rsi: Remove stack VLA usage The copy of the patch that failed is found in: .git/rebase-apply/patch Patch set to Changes Requested.
On Sun, Mar 11, 2018 at 09:06:10PM -0500, Larry Finger wrote: > On 03/11/2018 08:43 PM, Tobin C. Harding wrote: > >The kernel would like to have all stack VLA usage removed[1]. rsi uses > >a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size > >is defined using a magic number. We can use a pre-processor defined > >constant and declare the array to maximum size. We add a check before > >accessing the array in case of programmer error. > > > >[1]: https://lkml.org/lkml/2018/3/7/621 > > > >Signed-off-by: Tobin C. Harding <me@tobin.cc> > >--- > > > >RESEND: add wireless mailing list to CC's (requested by Kalle) > > > > drivers/net/wireless/rsi/rsi_91x_hal.c | 13 +++++++------ > > drivers/net/wireless/rsi/rsi_91x_sdio.c | 9 +++++++-- > > 2 files changed, 14 insertions(+), 8 deletions(-) > > > >diff --git a/drivers/net/wireless/rsi/rsi_91x_hal.c b/drivers/net/wireless/rsi/rsi_91x_hal.c > >index 1176de646942..839ebdd602df 100644 > >--- a/drivers/net/wireless/rsi/rsi_91x_hal.c > >+++ b/drivers/net/wireless/rsi/rsi_91x_hal.c > >@@ -641,7 +641,7 @@ static int ping_pong_write(struct rsi_hw *adapter, u8 cmd, u8 *addr, u32 size) > > u32 cmd_addr; > > u16 cmd_resp, cmd_req; > > u8 *str; > >- int status; > >+ int status, ret; > > if (cmd == PING_WRITE) { > > cmd_addr = PING_BUFFER_ADDRESS; > >@@ -655,12 +655,13 @@ static int ping_pong_write(struct rsi_hw *adapter, u8 cmd, u8 *addr, u32 size) > > str = "PONG_VALID"; > > } > >- status = hif_ops->load_data_master_write(adapter, cmd_addr, size, > >+ ret = hif_ops->load_data_master_write(adapter, cmd_addr, size, > > block_size, addr); > >- if (status) { > >- rsi_dbg(ERR_ZONE, "%s: Unable to write blk at addr %0x\n", > >- __func__, *addr); > >- return status; > >+ if (ret) { > >+ if (ret != -EINVAL) > >+ rsi_dbg(ERR_ZONE, "%s: Unable to write blk at addr %0x\n", > >+ __func__, *addr); > >+ return ret; > > } > > status = bl_cmd(adapter, cmd_req, cmd_resp, str); > >diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c > >index b0cf41195051..b766578b591a 100644 > >--- a/drivers/net/wireless/rsi/rsi_91x_sdio.c > >+++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c > >@@ -20,6 +20,8 @@ > > #include "rsi_common.h" > > #include "rsi_hal.h" > >+#define RSI_MAX_BLOCK_SIZE 256 > >+ > > /** > > * rsi_sdio_set_cmd52_arg() - This function prepares cmd 52 read/write arg. > > * @rw: Read/write > >@@ -362,7 +364,7 @@ static int rsi_setblocklength(struct rsi_hw *adapter, u32 length) > > rsi_dbg(INIT_ZONE, "%s: Setting the block length\n", __func__); > > status = sdio_set_block_size(dev->pfunction, length); > >- dev->pfunction->max_blksize = 256; > >+ dev->pfunction->max_blksize = RSI_MAX_BLOCK_SIZE; > > adapter->block_size = dev->pfunction->max_blksize; > > rsi_dbg(INFO_ZONE, > >@@ -567,9 +569,12 @@ static int rsi_sdio_load_data_master_write(struct rsi_hw *adapter, > > { > > u32 num_blocks, offset, i; > > u16 msb_address, lsb_address; > >- u8 temp_buf[block_size]; > >+ u8 temp_buf[RSI_MAX_BLOCK_SIZE]; > > int status; > >+ if (block_size > RSI_MAX_BLOCK_SIZE) > >+ return -EINVAL; > >+ > > num_blocks = instructions_sz / block_size; > > msb_address = base_address >> 16; > > I am not giving this patch a negative review, but my solution to the same > problem has been to change the on-stack array into a u8 pointer, use > kmalloc() to assign the space, and then free that space at the end. That way > large stack allocations are avoided, with a minimum of changes. Your idea is better Larry, have you got a patch done already or do you want me to knock one up? thanks, Tobin.
On Mon, Mar 12, 2018 at 09:46:06AM +0000, Kalle Valo wrote: > tcharding <me@tobin.cc> wrote: > > > The kernel would like to have all stack VLA usage removed[1]. rsi uses > > a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size > > is defined using a magic number. We can use a pre-processor defined > > constant and declare the array to maximum size. We add a check before > > accessing the array in case of programmer error. > > > > [1]: https://lkml.org/lkml/2018/3/7/621 > > > > Signed-off-by: Tobin C. Harding <me@tobin.cc> > > Tobin, your name in patchwork.kernel.org is just "tcharding" then it should be > "Tobin C. Harding". Patchwork is braindead in a way as it takes the name from > it's database instead of the From header of the patch in question. > > I can fix that manually but it would be helpful if you could register to > patchwork and fix your name during registration. You have only one chance to > fix your name (another braindead feature!) so be careful :) Hi Kalle, I logged into my patchwork account but I don't see any way to set the name. Within 'profile' there is only 'change password' and 'link email'. I thought I could unregister then re-register but I can't see how to do that either. Is there a maintainer of patchwork.kernel.org who I can email to manually remove me from the system? thanks, Tobin.
On Tue, Mar 13, 2018 at 10:17 PM, tcharding <me@tobin.cc> wrote: > On Mon, Mar 12, 2018 at 09:46:06AM +0000, Kalle Valo wrote: >> tcharding <me@tobin.cc> wrote: I'm pretty much sure it depends on the original email headers, like above ^^^ — no name. Perhaps git config on your side should be done.
On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote: > On Tue, Mar 13, 2018 at 10:17 PM, tcharding <me@tobin.cc> wrote: > > On Mon, Mar 12, 2018 at 09:46:06AM +0000, Kalle Valo wrote: > >> tcharding <me@tobin.cc> wrote: > > I'm pretty much sure it depends on the original email headers, like > above ^^^ — no name. > Perhaps git config on your side should be done. Thanks for the suggestion Andy but the 'tcharding' as the name was munged by either Kalle or patchwork. I'm guessing patchwork. thanks, Tobin.
On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Harding <me@tobin.cc> wrote: > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote: >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding <me@tobin.cc> wrote: >> > On Mon, Mar 12, 2018 at 09:46:06AM +0000, Kalle Valo wrote: >> >> tcharding <me@tobin.cc> wrote: >> >> I'm pretty much sure it depends on the original email headers, like >> above ^^^ — no name. >> Perhaps git config on your side should be done. > > Thanks for the suggestion Andy but the 'tcharding' as the name was > munged by either Kalle or patchwork. I'm guessing patchwork. Something you're sending from is using "tcharding" (see the email Andy quotes). I see the headers as: Date: Wed, 14 Mar 2018 07:17:57 +1100 From: tcharding <me@tobin.cc> ... Message-ID: <20180313201757.GK8631@eros> X-Mailer: Mutt 1.5.24 (2015-08-30) User-Agent: Mutt/1.5.24 (2015-08-30) Your most recently email shows "Tobin C. Harding" though, and also sent with Mutt... Do you have multiple Mutt configurations? Is something lacking a "From" header insertion and your MTA is filling it in for you from your username? -Kees
Added Konstantin in case he is in charge of administering patchwork.kernel.org? On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote: > On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Harding <me@tobin.cc> wrote: > > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote: > >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding <me@tobin.cc> wrote: > >> > On Mon, Mar 12, 2018 at 09:46:06AM +0000, Kalle Valo wrote: > >> >> tcharding <me@tobin.cc> wrote: > >> > >> I'm pretty much sure it depends on the original email headers, like > >> above ^^^ — no name. > >> Perhaps git config on your side should be done. > > > > Thanks for the suggestion Andy but the 'tcharding' as the name was > > munged by either Kalle or patchwork. I'm guessing patchwork. > > Something you're sending from is using "tcharding" (see the email Andy > quotes). I see the headers as: > > Date: Wed, 14 Mar 2018 07:17:57 +1100 > From: tcharding <me@tobin.cc> > ... > Message-ID: <20180313201757.GK8631@eros> > X-Mailer: Mutt 1.5.24 (2015-08-30) > User-Agent: Mutt/1.5.24 (2015-08-30) > > Your most recently email shows "Tobin C. Harding" though, and also > sent with Mutt... > > Do you have multiple Mutt configurations? Is something lacking a > "From" header insertion and your MTA is filling it in for you from > your username? Thanks for taking the time to respond Kees (and Tycho). I have mutt configured to reply from whichever email address I receive from so if patchwork sent an email to 'tcharding <me@tobin.cc>' (which is the details it has) and I hit reply it would have come from 'tcharding', hence Andy's reply. I wouldn't bet my life on it but I'm kinda confident that I cannot initiate an email from 'tcharding' with my current set up. Super bad form to blame someone (or something else) but I think this is a problem with how my patchwork account is configured. Either way, that is still my fault I should have added my real name to patchwork when I signed up (not just username 'tcharding'). Is patchwork.kernel.org administered by Konstantin Ryabitsev? Added Konstantin to CC's. thanks, Tobin.
tcharding <me@tobin.cc> writes: > On Mon, Mar 12, 2018 at 09:46:06AM +0000, Kalle Valo wrote: >> tcharding <me@tobin.cc> wrote: >> >> > The kernel would like to have all stack VLA usage removed[1]. rsi uses >> > a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size >> > is defined using a magic number. We can use a pre-processor defined >> > constant and declare the array to maximum size. We add a check before >> > accessing the array in case of programmer error. >> > >> > [1]: https://lkml.org/lkml/2018/3/7/621 >> > >> > Signed-off-by: Tobin C. Harding <me@tobin.cc> >> >> Tobin, your name in patchwork.kernel.org is just "tcharding" then it should be >> "Tobin C. Harding". Patchwork is braindead in a way as it takes the name from >> it's database instead of the From header of the patch in question. >> >> I can fix that manually but it would be helpful if you could register to >> patchwork and fix your name during registration. You have only one chance to >> fix your name (another braindead feature!) so be careful :) > > Hi Kalle, > > I logged into my patchwork account but I don't see any way to set the > name. Within 'profile' there is only 'change password' and 'link > email'. I thought I could unregister then re-register but I can't see > how to do that either. Ok, maybe you have registered (=logged on for the first time) already earlier so it's not possible to change the name anymore. > Is there a maintainer of patchwork.kernel.org who I can email to > manually remove me from the system? helpdesk@kernel.org should be able to fix your name in patchwork, at least they have done it in the past. This is not the first time this has happened.
"Tobin C. Harding" <me@tobin.cc> writes: > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote: >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding <me@tobin.cc> wrote: >> > On Mon, Mar 12, 2018 at 09:46:06AM +0000, Kalle Valo wrote: >> >> tcharding <me@tobin.cc> wrote: >> >> I'm pretty much sure it depends on the original email headers, like >> above ^^^ — no name. >> Perhaps git config on your side should be done. > > Thanks for the suggestion Andy but the 'tcharding' as the name was > munged by either Kalle or patchwork. I'm guessing patchwork. You guessed corretly, patchwork is here to blame. I sent my "please rebase" mail earlier in this thread using my custom patchwork client script (pwcli) which takes the name and address from patchwork. Andy, this is definitely a bug in patchwork and I have seen this issue multiple times already. I have understood that it has been fixed in a recent version but patchwork.kernel.org is still running an old version. In the original mail Tobin did have the correct From header which can be checked from the headers in patch page[1]: From: "Tobin C. Harding" <me@tobin.cc> [1] https://patchwork.kernel.org/patch/10274983/
"Tobin C. Harding" <me@tobin.cc> writes: > Added Konstantin in case he is in charge of administering patchwork.kernel.org? > > On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote: >> On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Harding <me@tobin.cc> wrote: >> > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote: >> >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding <me@tobin.cc> wrote: >> >> > On Mon, Mar 12, 2018 at 09:46:06AM +0000, Kalle Valo wrote: >> >> >> tcharding <me@tobin.cc> wrote: >> >> >> >> I'm pretty much sure it depends on the original email headers, like >> >> above ^^^ — no name. >> >> Perhaps git config on your side should be done. >> > >> > Thanks for the suggestion Andy but the 'tcharding' as the name was >> > munged by either Kalle or patchwork. I'm guessing patchwork. >> >> Something you're sending from is using "tcharding" (see the email Andy >> quotes). I see the headers as: >> >> Date: Wed, 14 Mar 2018 07:17:57 +1100 >> From: tcharding <me@tobin.cc> >> ... >> Message-ID: <20180313201757.GK8631@eros> >> X-Mailer: Mutt 1.5.24 (2015-08-30) >> User-Agent: Mutt/1.5.24 (2015-08-30) >> >> Your most recently email shows "Tobin C. Harding" though, and also >> sent with Mutt... >> >> Do you have multiple Mutt configurations? Is something lacking a >> "From" header insertion and your MTA is filling it in for you from >> your username? > > Thanks for taking the time to respond Kees (and Tycho). I have mutt > configured to reply from whichever email address I receive from so if > patchwork sent an email to 'tcharding <me@tobin.cc>' (which is the > details it has) and I hit reply it would have come from 'tcharding', > hence Andy's reply. I wouldn't bet my life on it but I'm kinda > confident that I cannot initiate an email from 'tcharding' with my > current set up. > > Super bad form to blame someone (or something else) but I think this is > a problem with how my patchwork account is configured. Either way, that > is still my fault I should have added my real name to patchwork when I > signed up (not just username 'tcharding'). > > Is patchwork.kernel.org administered by Konstantin Ryabitsev? Added > Konstantin to CC's. Like I said earlier, just send a request to helpdesk@kernel.org and admins should fix your name.
On Wed, Mar 14, 2018 at 11:19:53AM +0200, Kalle Valo wrote: > "Tobin C. Harding" <me@tobin.cc> writes: > > > Added Konstantin in case he is in charge of administering patchwork.kernel.org? > > > > On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote: > >> On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Harding <me@tobin.cc> wrote: > >> > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote: > >> >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding <me@tobin.cc> wrote: > >> >> > On Mon, Mar 12, 2018 at 09:46:06AM +0000, Kalle Valo wrote: > >> >> >> tcharding <me@tobin.cc> wrote: > >> >> > >> >> I'm pretty much sure it depends on the original email headers, like > >> >> above ^^^ — no name. > >> >> Perhaps git config on your side should be done. > >> > > >> > Thanks for the suggestion Andy but the 'tcharding' as the name was > >> > munged by either Kalle or patchwork. I'm guessing patchwork. > >> > >> Something you're sending from is using "tcharding" (see the email Andy > >> quotes). I see the headers as: > >> > >> Date: Wed, 14 Mar 2018 07:17:57 +1100 > >> From: tcharding <me@tobin.cc> > >> ... > >> Message-ID: <20180313201757.GK8631@eros> > >> X-Mailer: Mutt 1.5.24 (2015-08-30) > >> User-Agent: Mutt/1.5.24 (2015-08-30) > >> > >> Your most recently email shows "Tobin C. Harding" though, and also > >> sent with Mutt... > >> > >> Do you have multiple Mutt configurations? Is something lacking a > >> "From" header insertion and your MTA is filling it in for you from > >> your username? > > > > Thanks for taking the time to respond Kees (and Tycho). I have mutt > > configured to reply from whichever email address I receive from so if > > patchwork sent an email to 'tcharding <me@tobin.cc>' (which is the > > details it has) and I hit reply it would have come from 'tcharding', > > hence Andy's reply. I wouldn't bet my life on it but I'm kinda > > confident that I cannot initiate an email from 'tcharding' with my > > current set up. > > > > Super bad form to blame someone (or something else) but I think this is > > a problem with how my patchwork account is configured. Either way, that > > is still my fault I should have added my real name to patchwork when I > > signed up (not just username 'tcharding'). > > > > Is patchwork.kernel.org administered by Konstantin Ryabitsev? Added > > Konstantin to CC's. > > Like I said earlier, just send a request to helpdesk@kernel.org and > admins should fix your name. thanks Kalle, I'm on it.
"Tobin C. Harding" <me@tobin.cc> writes: > On Wed, Mar 14, 2018 at 11:19:53AM +0200, Kalle Valo wrote: >> "Tobin C. Harding" <me@tobin.cc> writes: >> >> > Added Konstantin in case he is in charge of administering patchwork.kernel.org? >> > >> > On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote: >> >> On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Harding <me@tobin.cc> wrote: >> >> > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote: >> >> >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding <me@tobin.cc> wrote: >> >> >> > On Mon, Mar 12, 2018 at 09:46:06AM +0000, Kalle Valo wrote: >> >> >> >> tcharding <me@tobin.cc> wrote: >> >> >> >> >> >> I'm pretty much sure it depends on the original email headers, like >> >> >> above ^^^ — no name. >> >> >> Perhaps git config on your side should be done. >> >> > >> >> > Thanks for the suggestion Andy but the 'tcharding' as the name was >> >> > munged by either Kalle or patchwork. I'm guessing patchwork. >> >> >> >> Something you're sending from is using "tcharding" (see the email Andy >> >> quotes). I see the headers as: >> >> >> >> Date: Wed, 14 Mar 2018 07:17:57 +1100 >> >> From: tcharding <me@tobin.cc> >> >> ... >> >> Message-ID: <20180313201757.GK8631@eros> >> >> X-Mailer: Mutt 1.5.24 (2015-08-30) >> >> User-Agent: Mutt/1.5.24 (2015-08-30) >> >> >> >> Your most recently email shows "Tobin C. Harding" though, and also >> >> sent with Mutt... >> >> >> >> Do you have multiple Mutt configurations? Is something lacking a >> >> "From" header insertion and your MTA is filling it in for you from >> >> your username? >> > >> > Thanks for taking the time to respond Kees (and Tycho). I have mutt >> > configured to reply from whichever email address I receive from so if >> > patchwork sent an email to 'tcharding <me@tobin.cc>' (which is the >> > details it has) and I hit reply it would have come from 'tcharding', >> > hence Andy's reply. I wouldn't bet my life on it but I'm kinda >> > confident that I cannot initiate an email from 'tcharding' with my >> > current set up. >> > >> > Super bad form to blame someone (or something else) but I think this is >> > a problem with how my patchwork account is configured. Either way, that >> > is still my fault I should have added my real name to patchwork when I >> > signed up (not just username 'tcharding'). >> > >> > Is patchwork.kernel.org administered by Konstantin Ryabitsev? Added >> > Konstantin to CC's. >> >> Like I said earlier, just send a request to helpdesk@kernel.org and >> admins should fix your name. > > thanks Kalle, I'm on it. Thanks. Looks to be fixed, now patchwork gives me: From: Tobin C. Harding <me@tobin.cc>
diff --git a/drivers/net/wireless/rsi/rsi_91x_hal.c b/drivers/net/wireless/rsi/rsi_91x_hal.c index 1176de646942..839ebdd602df 100644 --- a/drivers/net/wireless/rsi/rsi_91x_hal.c +++ b/drivers/net/wireless/rsi/rsi_91x_hal.c @@ -641,7 +641,7 @@ static int ping_pong_write(struct rsi_hw *adapter, u8 cmd, u8 *addr, u32 size) u32 cmd_addr; u16 cmd_resp, cmd_req; u8 *str; - int status; + int status, ret; if (cmd == PING_WRITE) { cmd_addr = PING_BUFFER_ADDRESS; @@ -655,12 +655,13 @@ static int ping_pong_write(struct rsi_hw *adapter, u8 cmd, u8 *addr, u32 size) str = "PONG_VALID"; } - status = hif_ops->load_data_master_write(adapter, cmd_addr, size, + ret = hif_ops->load_data_master_write(adapter, cmd_addr, size, block_size, addr); - if (status) { - rsi_dbg(ERR_ZONE, "%s: Unable to write blk at addr %0x\n", - __func__, *addr); - return status; + if (ret) { + if (ret != -EINVAL) + rsi_dbg(ERR_ZONE, "%s: Unable to write blk at addr %0x\n", + __func__, *addr); + return ret; } status = bl_cmd(adapter, cmd_req, cmd_resp, str); diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c index b0cf41195051..b766578b591a 100644 --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c @@ -20,6 +20,8 @@ #include "rsi_common.h" #include "rsi_hal.h" +#define RSI_MAX_BLOCK_SIZE 256 + /** * rsi_sdio_set_cmd52_arg() - This function prepares cmd 52 read/write arg. * @rw: Read/write @@ -362,7 +364,7 @@ static int rsi_setblocklength(struct rsi_hw *adapter, u32 length) rsi_dbg(INIT_ZONE, "%s: Setting the block length\n", __func__); status = sdio_set_block_size(dev->pfunction, length); - dev->pfunction->max_blksize = 256; + dev->pfunction->max_blksize = RSI_MAX_BLOCK_SIZE; adapter->block_size = dev->pfunction->max_blksize; rsi_dbg(INFO_ZONE, @@ -567,9 +569,12 @@ static int rsi_sdio_load_data_master_write(struct rsi_hw *adapter, { u32 num_blocks, offset, i; u16 msb_address, lsb_address; - u8 temp_buf[block_size]; + u8 temp_buf[RSI_MAX_BLOCK_SIZE]; int status; + if (block_size > RSI_MAX_BLOCK_SIZE) + return -EINVAL; + num_blocks = instructions_sz / block_size; msb_address = base_address >> 16;
The kernel would like to have all stack VLA usage removed[1]. rsi uses a VLA based on 'blksize'. Elsewhere in the SDIO code maximum block size is defined using a magic number. We can use a pre-processor defined constant and declare the array to maximum size. We add a check before accessing the array in case of programmer error. [1]: https://lkml.org/lkml/2018/3/7/621 Signed-off-by: Tobin C. Harding <me@tobin.cc> --- RESEND: add wireless mailing list to CC's (requested by Kalle) drivers/net/wireless/rsi/rsi_91x_hal.c | 13 +++++++------ drivers/net/wireless/rsi/rsi_91x_sdio.c | 9 +++++++-- 2 files changed, 14 insertions(+), 8 deletions(-)