[PATCH] greybus: audio_manager: fix a missing check of ida_simple_get
ida_simple_get could fail. The fix inserts a check for its
return value.
Signed-off-by: Kangjie Lu
---
drivers/staging/greybus/audio_manager.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/greybus/audio_manager.c
b/drivers/staging/greybus/audio_manager.c
index d44b070d8862..c2a4af4c1d06 100644
--- a/drivers/staging/greybus/audio_manager.c
+++ b/drivers/staging/greybus/audio_manager.c
@@ -45,6 +45,9 @@ int gb_audio_manager_add(struct
gb_audio_manager_module_descriptor *desc)
int err;
id = ida_simple_get(&module_id, 0, 0, GFP_KERNEL);
+ if (id < 0)
+ return id;
+
err = gb_audio_manager_module_create(&module, manager_kset,
id, desc);
if (err) {
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
On Thu, Mar 14 2019, Chuanhong Guo wrote: > Hi! > On Thu, Mar 14, 2019 at 6:14 AM NeilBrown wrote: >> >> [...] >> My only small concern is that this driver was backported to openwrt >> (4.14 based) and then reverted >> >> https://github.com/openwrt/openwrt/commit/749a29f76ca780d8df70a5163d43bbdc6f13ba3f >> >> "This breaks some mt7621 devices." >> >> Possibly it was backported badly, or possibly there is a problem. > Last time I backported the version with broken SPI modes so it got > broken SPI CS1 support. There is one mt7621 router using SPI CS1 in > OpenWrt and the backported driver broke it. > It has been fixed by my two "drop broken spi modes" patches. Ahh, thanks for the clarification. Good to know all known problems are fixed. Thanks, NeilBrown >> >> John: do you have any more details of the problem other than what is in >> the commit message? >> >> Thanks, >> NeilBrown > > Regards, > Chuanhong Guo signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
Hi! On Thu, Mar 14, 2019 at 6:14 AM NeilBrown wrote: > > [...] > My only small concern is that this driver was backported to openwrt > (4.14 based) and then reverted > > https://github.com/openwrt/openwrt/commit/749a29f76ca780d8df70a5163d43bbdc6f13ba3f > > "This breaks some mt7621 devices." > > Possibly it was backported badly, or possibly there is a problem. Last time I backported the version with broken SPI modes so it got broken SPI CS1 support. There is one mt7621 router using SPI CS1 in OpenWrt and the backported driver broke it. It has been fixed by my two "drop broken spi modes" patches. > > John: do you have any more details of the problem other than what is in > the commit message? > > Thanks, > NeilBrown Regards, Chuanhong Guo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
On Wed, Mar 13 2019, Stefan Roese wrote: > On 13.03.19 17:46, Matthias Brugger wrote: >> >> >> On 13/03/2019 17:34, Chuanhong Guo wrote: >>> Hi! >>> On Wed, Mar 13, 2019 at 8:28 PM Matthias Brugger >>> wrote: On 13/03/2019 13:24, Armando Miraglia wrote: [...] Apart from fixing styling issues it would be usefull to see if we can add support for mt7621 to drivers/spi/spi-mt65xx.c >>> It's impossible. They are completely different IPs. >> >> Thanks for the info. Do you know the status of the rest of the drivers in >> staging? > > Just to inform you. We are using this SPI driver from staging > in one of our customer projects and I will try to move this > driver out of staging into drivers/spi very shortly. This is good news! I think the driver is ready to move out of staging and would be very happy to see you do it. My only small concern is that this driver was backported to openwrt (4.14 based) and then reverted https://github.com/openwrt/openwrt/commit/749a29f76ca780d8df70a5163d43bbdc6f13ba3f "This breaks some mt7621 devices." Possibly it was backported badly, or possibly there is a problem. John: do you have any more details of the problem other than what is in the commit message? Thanks, NeilBrown signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: media: imx7-mipi-csis: fix debugfs compilation
When CONFIG_DEBUGFS is enabled, we get a warning about an
incorrect section annotation that can lead to undefined
behavior:
WARNING: vmlinux.o(.text+0xd3c7c4): Section mismatch in reference from the
function mipi_csis_probe() to the function .init.text:mipi_csis_debugfs_init()
The function mipi_csis_probe() references
the function __init mipi_csis_debugfs_init().
This is often because mipi_csis_probe lacks a __init
annotation or the annotation of mipi_csis_debugfs_init is wrong.
The same function for an unknown reason has a different
version for !CONFIG_DEBUGFS, which does not have this problem,
but behaves the same way otherwise (it does nothing when debugfs
is disabled).
Consolidate the two versions, using the correct section from
one version, and the implementation from the other.
Signed-off-by: Arnd Bergmann
---
drivers/staging/media/imx/imx7-mipi-csis.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c
b/drivers/staging/media/imx/imx7-mipi-csis.c
index 2ddcc42ab8ff..001ce369ec45 100644
--- a/drivers/staging/media/imx/imx7-mipi-csis.c
+++ b/drivers/staging/media/imx/imx7-mipi-csis.c
@@ -9,6 +9,7 @@
*/
#include
+#include
#include
#include
#include
@@ -889,8 +890,6 @@ static int mipi_csis_subdev_init(struct v4l2_subdev
*mipi_sd,
return ret;
}
-#ifdef CONFIG_DEBUG_FS
-#include
static int mipi_csis_dump_regs_show(struct seq_file *m, void *private)
{
@@ -900,7 +899,7 @@ static int mipi_csis_dump_regs_show(struct seq_file *m,
void *private)
}
DEFINE_SHOW_ATTRIBUTE(mipi_csis_dump_regs);
-static int __init_or_module mipi_csis_debugfs_init(struct csi_state *state)
+static int mipi_csis_debugfs_init(struct csi_state *state)
{
struct dentry *d;
@@ -934,17 +933,6 @@ static void mipi_csis_debugfs_exit(struct csi_state *state)
debugfs_remove_recursive(state->debugfs_root);
}
-#else
-static int mipi_csis_debugfs_init(struct csi_state *state __maybe_unused)
-{
- return 0;
-}
-
-static void mipi_csis_debugfs_exit(struct csi_state *state __maybe_unused)
-{
-}
-#endif
-
static int mipi_csis_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
--
2.20.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: media: davinci_vpfe: fix large stack usage with clang
clang is unable to optimize the isif_ioctl() in the same way that
gcc does, as it fails to prove that the local copy of
the 'struct vpfe_isif_raw_config' argument is unnecessary:
drivers/staging/media/davinci_vpfe/dm365_isif.c:622:13: error: stack frame size
of 1344 bytes in function 'isif_ioctl' [-Werror,-Wframe-larger-than=]
Marking it as 'const' while passing the data down clearly shows us that
the copy is never modified, and we can skip copying it entirely, which
reduces the stack usage to just eight bytes.
Signed-off-by: Arnd Bergmann
---
.../staging/media/davinci_vpfe/dm365_isif.c | 20 +--
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/media/davinci_vpfe/dm365_isif.c
b/drivers/staging/media/davinci_vpfe/dm365_isif.c
index 0a6d038fcec9..46fd8184fc77 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_isif.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_isif.c
@@ -433,9 +433,9 @@ static int isif_get_params(struct v4l2_subdev *sd, void
*params)
return 0;
}
-static int isif_validate_df_csc_params(struct vpfe_isif_df_csc *df_csc)
+static int isif_validate_df_csc_params(const struct vpfe_isif_df_csc *df_csc)
{
- struct vpfe_isif_color_space_conv *csc;
+ const struct vpfe_isif_color_space_conv *csc;
int err = -EINVAL;
int i;
@@ -481,7 +481,7 @@ static int isif_validate_df_csc_params(struct
vpfe_isif_df_csc *df_csc)
#define DM365_ISIF_MAX_DFCMEM0 0x1fff
#define DM365_ISIF_MAX_DFCMEM1 0x1fff
-static int isif_validate_dfc_params(struct vpfe_isif_dfc *dfc)
+static int isif_validate_dfc_params(const struct vpfe_isif_dfc *dfc)
{
int err = -EINVAL;
int i;
@@ -532,7 +532,7 @@ static int isif_validate_dfc_params(struct vpfe_isif_dfc
*dfc)
#define DM365_ISIF_MAX_CLVSV 0x1fff
#define DM365_ISIF_MAX_HEIGHT_BLACK_REGION 0x1fff
-static int isif_validate_bclamp_params(struct vpfe_isif_black_clamp *bclamp)
+static int isif_validate_bclamp_params(const struct vpfe_isif_black_clamp
*bclamp)
{
int err = -EINVAL;
@@ -580,7 +580,7 @@ static int isif_validate_bclamp_params(struct
vpfe_isif_black_clamp *bclamp)
}
static int
-isif_validate_raw_params(struct vpfe_isif_raw_config *params)
+isif_validate_raw_params(const struct vpfe_isif_raw_config *params)
{
int ret;
@@ -593,20 +593,18 @@ isif_validate_raw_params(struct vpfe_isif_raw_config
*params)
return isif_validate_bclamp_params(¶ms->bclamp);
}
-static int isif_set_params(struct v4l2_subdev *sd, void *params)
+static int isif_set_params(struct v4l2_subdev *sd, const struct
vpfe_isif_raw_config *params)
{
struct vpfe_isif_device *isif = v4l2_get_subdevdata(sd);
- struct vpfe_isif_raw_config isif_raw_params;
int ret = -EINVAL;
/* only raw module parameters can be set through the IOCTL */
if (isif->formats[ISIF_PAD_SINK].code != MEDIA_BUS_FMT_SGRBG12_1X12)
return ret;
- memcpy(&isif_raw_params, params, sizeof(isif_raw_params));
- if (!isif_validate_raw_params(&isif_raw_params)) {
- memcpy(&isif->isif_cfg.bayer.config_params, &isif_raw_params,
- sizeof(isif_raw_params));
+ if (!isif_validate_raw_params(params)) {
+ memcpy(&isif->isif_cfg.bayer.config_params, params,
+ sizeof(*params));
ret = 0;
}
return ret;
--
2.20.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: ni_mio_common: Fix divide-by-zero for DIO cmdtest
On 04/03/2019 14:33, Ian Abbott wrote:
`ni_cdio_cmdtest()` validates Comedi asynchronous commands for the DIO
subdevice (subdevice 2) of supported National Instruments M-series
cards. It is called when handling the `COMEDI_CMD` and `COMEDI_CMDTEST`
ioctls for this subdevice. There are two causes for a possible
divide-by-zero error when validating that the `stop_arg` member of the
passed-in command is not too large.
The first cause for the divide-by-zero is that calls to
`comedi_bytes_per_scan()` are only valid once the command has been
copied to `s->async->cmd`, but that copy is only done for the
`COMEDI_CMD` ioctl. For the `COMEDI_CMDTEST` ioctl, it will use
whatever was left there by the previous `COMEDI_CMD` ioctl, if any.
(This is very likely, as it is usual for the application to use
`COMEDI_CMDTEST` before `COMEDI_CMD`.) If there has been no previous,
valid `COMEDI_CMD` for this subdevice, then `comedi_bytes_per_scan()`
will return 0, so the subsequent division in `ni_cdio_cmdtest()` of
`s->async->prealloc_bufsz / comedi_bytes_per_scan(s)` will be a
divide-by-zero error. To fix this error, call a new function
`comedi_bytes_per_scan_cmd(s, cmd)`, based on the existing
`comedi_bytes_per_scan(s)` but using a specified `struct comedi_cmd` for
its calculations. (Also refactor `comedi_bytes_per_scan()` to call the
new function.)
Once the first cause for the divide-by-zero has been fixed, the second
cause is that `comedi_bytes_per_scan_cmd()` can legitimately return 0 if
the `scan_end_arg` member of the `struct comedi_cmd` being tested is 0.
Fix it by only performing the division (and validating that `stop_arg`
is no more than the maximum value) if `comedi_bytes_per_scan_cmd()`
returns a non-zero value.
The problem was reported on the COMEDI mailing list here:
https://groups.google.com/forum/#!topic/comedi_list/4t9WlHzMhKM
Fixes: f164cbf98fa8 ("staging: comedi: ni_mio_common: add finite regeneration to dio
output")
Greg,
If it's not too late, it would be nice if the following "Reported-by:"
and "Tested-by:" lines could be added (or I can resend with these lines
included if necessary). It's no big deal if this is too late. I'll
live with it. Thanks.
Reported-by: Ivan Vasilyev
Tested-by: Ivan Vasilyev
Cc: # 4.6+
Cc: Spencer E. Olson
Signed-off-by: Ian Abbott
---
drivers/staging/comedi/comedidev.h| 2 ++
drivers/staging/comedi/drivers.c | 33 ---
.../staging/comedi/drivers/ni_mio_common.c| 10 --
3 files changed, 38 insertions(+), 7 deletions(-)
--
-=( Ian Abbott || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268. Registered address:)=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8188eu: Fix potential NULL pointer dereference
On Wed, Mar 13, 2019 at 12:11:30PM -0500, Aditya Pakki wrote:
> hwxmits is allocated via kcalloc and not checked for failure before its
> dereference. The patch fixes this problem similar to rtl8723bs.
>
> Signed-off-by: Aditya Pakki
> ---
> drivers/staging/rtl8188eu/core/rtw_xmit.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c
> b/drivers/staging/rtl8188eu/core/rtw_xmit.c
> index 1723a47a96b4..a557ed37923a 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
> @@ -1512,6 +1512,10 @@ void rtw_alloc_hwxmits(struct adapter *padapter)
>
> pxmitpriv->hwxmits = kcalloc(pxmitpriv->hwxmit_entry,
>sizeof(struct hw_xmit), GFP_KERNEL);
> + if (!pxmitpriv->hwxmits) {
> + DBG_88E("alloc hwxmits fail!...\n");
You never need to print a message for a memory allocation failure, that
happens by the function that tried to allocate the memory.
> + return;
Shouldn't you return an error?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: Fix potential NULL pointer dereference
hwxmits is allocated via kcalloc and not checked for failure before its
dereference. The patch fixes this problem similar to rtl8723bs.
Signed-off-by: Aditya Pakki
---
drivers/staging/rtl8188eu/core/rtw_xmit.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 1723a47a96b4..a557ed37923a 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -1512,6 +1512,10 @@ void rtw_alloc_hwxmits(struct adapter *padapter)
pxmitpriv->hwxmits = kcalloc(pxmitpriv->hwxmit_entry,
sizeof(struct hw_xmit), GFP_KERNEL);
+ if (!pxmitpriv->hwxmits) {
+ DBG_88E("alloc hwxmits fail!...\n");
+ return;
+ }
hwxmits = pxmitpriv->hwxmits;
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
On 13.03.19 17:46, Matthias Brugger wrote: On 13/03/2019 17:34, Chuanhong Guo wrote: Hi! On Wed, Mar 13, 2019 at 8:28 PM Matthias Brugger wrote: On 13/03/2019 13:24, Armando Miraglia wrote: [...] Apart from fixing styling issues it would be usefull to see if we can add support for mt7621 to drivers/spi/spi-mt65xx.c It's impossible. They are completely different IPs. Thanks for the info. Do you know the status of the rest of the drivers in staging? Just to inform you. We are using this SPI driver from staging in one of our customer projects and I will try to move this driver out of staging into drivers/spi very shortly. Thanks, Stefan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
On 13/03/2019 13:34, Dan Carpenter wrote:
> On Wed, Mar 13, 2019 at 01:24:04PM +0100, Armando Miraglia wrote:
>> Running Lindent on the mt7621-spi.c file in drivers/staging I noticed that
>> the
>> file contained style issues. This change attempts to address such style
>> problems.
>>
>
> Don't run lindent. I think checkpatch.pl has a --fix option that might
> be better, but once the code is merged then our standard become much
> higher for follow up patches.
>
>> Signed-off-by: Armando Miraglia
>> ---
>> NOTE: resend this patch to include all mainteners listed by
>> get_mantainers.pl.
>> drivers/staging/mt7621-spi/spi-mt7621.c | 27 +
>> 1 file changed, 14 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c
>> b/drivers/staging/mt7621-spi/spi-mt7621.c
>> index b509f9fe3346..03d53845f8c5 100644
>> --- a/drivers/staging/mt7621-spi/spi-mt7621.c
>> +++ b/drivers/staging/mt7621-spi/spi-mt7621.c
>> @@ -52,14 +52,14 @@
>> #define MT7621_LSB_FIRSTBIT(3)
>>
>> struct mt7621_spi {
>> -struct spi_master *master;
>> -void __iomem*base;
>> -unsigned intsys_freq;
>> -unsigned intspeed;
>> -struct clk *clk;
>> -int pending_write;
>> -
>> -struct mt7621_spi_ops *ops;
>> +struct spi_master *master;
>> +void __iomem *base;
>> +unsigned int sys_freq;
>> +unsigned int speed;
>> +struct clk *clk;
>> +int pending_write;
>> +
>> +struct mt7621_spi_ops *ops;
>
> The original is fine. I don't encourage people to do fancy indenting
> with their local variable declarations inside functions but for a struct
> the declarations aren't going to change a lot so people can get fancy
> if they want.
>
> The problem with a local is if you need to add a new variable then you
> have to re-indent a bunch of unrelated lines or have one out of
> alignment line. Most people know this intuitively so they don't get
> fancy.
>
>> };
>>
>> static inline struct mt7621_spi *spidev_to_mt7621_spi(struct spi_device
>> *spi)
>> @@ -303,7 +303,7 @@ static int mt7621_spi_setup(struct spi_device *spi)
>> struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
>>
>> if ((spi->max_speed_hz == 0) ||
>> -(spi->max_speed_hz > (rs->sys_freq / 2)))
>> +(spi->max_speed_hz > (rs->sys_freq / 2)))
>
> Yeah. Lindent is correct here.
>
>> spi->max_speed_hz = (rs->sys_freq / 2);
>>
>> if (spi->max_speed_hz < (rs->sys_freq / 4097)) {
>> @@ -316,9 +316,10 @@ static int mt7621_spi_setup(struct spi_device *spi)
>> }
>>
>> static const struct of_device_id mt7621_spi_match[] = {
>> -{ .compatible = "ralink,mt7621-spi" },
>> +{.compatible = "ralink,mt7621-spi"},
>
> The original was better.
>
>> {},
>> };
>> +
>> MODULE_DEVICE_TABLE(of, mt7621_spi_match);
>
> No need for a blank. These are closely related.
>
>>
>> static int mt7621_spi_probe(struct platform_device *pdev)
>> @@ -408,9 +409,9 @@ MODULE_ALIAS("platform:" DRIVER_NAME);
>>
>> static struct platform_driver mt7621_spi_driver = {
>> .driver = {
>> -.name = DRIVER_NAME,
>> -.of_match_table = mt7621_spi_match,
>> -},
>> + .name = DRIVER_NAME,
>> + .of_match_table = mt7621_spi_match,
>> + },
>
> The new indenting is very wrong.
>
Fair enough, I was too fast providing my Reviewed-by tag :-/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
On 13/03/2019 17:34, Chuanhong Guo wrote: > Hi! > On Wed, Mar 13, 2019 at 8:28 PM Matthias Brugger > wrote: >> >> >> >> On 13/03/2019 13:24, Armando Miraglia wrote: >> [...] >> Apart from fixing styling issues it would be usefull to see if we can add >> support for mt7621 to drivers/spi/spi-mt65xx.c > It's impossible. They are completely different IPs. Thanks for the info. Do you know the status of the rest of the drivers in staging? Best regards, Matthias ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
Hi! On Wed, Mar 13, 2019 at 8:28 PM Matthias Brugger wrote: > > > > On 13/03/2019 13:24, Armando Miraglia wrote: > [...] > Apart from fixing styling issues it would be usefull to see if we can add > support for mt7621 to drivers/spi/spi-mt65xx.c It's impossible. They are completely different IPs. > > Not sure if that is something you want to work on :) > > Regards, > Matthias ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtlwifi: Fix potential NULL pointer dereference
skb allocated via dev_alloc_skb can fail and return a NULL pointer. This patch avoids such a scenario and returns, consistent with other invocations. Signed-off-by: Aditya Pakki --- drivers/staging/rtlwifi/rtl8822be/fw.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/staging/rtlwifi/rtl8822be/fw.c b/drivers/staging/rtlwifi/rtl8822be/fw.c index f061dd1382aa..8fab9c8d1dd0 100644 --- a/drivers/staging/rtlwifi/rtl8822be/fw.c +++ b/drivers/staging/rtlwifi/rtl8822be/fw.c @@ -743,6 +743,9 @@ void rtl8822be_set_fw_rsvdpagepkt(struct ieee80211_hw *hw, bool b_dl_finished) u1_rsvd_page_loc, 3); skb = dev_alloc_skb(totalpacketlen); + if (!skb) + return; + memcpy((u8 *)skb_put(skb, totalpacketlen), &reserved_page_packet, totalpacketlen); -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtlwifi: Fix potential NULL pointer dereference
phydm.internal is allocated using kzalloc which is used multiple times without a check for NULL pointer. This patch avoids such a scenario. Signed-off-by: Aditya Pakki --- drivers/staging/rtlwifi/phydm/rtl_phydm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/staging/rtlwifi/phydm/rtl_phydm.c b/drivers/staging/rtlwifi/phydm/rtl_phydm.c index 9930ed954abb..37c7fcb72b65 100644 --- a/drivers/staging/rtlwifi/phydm/rtl_phydm.c +++ b/drivers/staging/rtlwifi/phydm/rtl_phydm.c @@ -181,6 +181,9 @@ static int rtl_phydm_init_priv(struct rtl_priv *rtlpriv, rtlpriv->phydm.internal = kzalloc(sizeof(struct phy_dm_struct), GFP_KERNEL); + if (!rtlpriv->phydm.internal) + return -ENOMEM; + _rtl_phydm_init_com_info(rtlpriv, ic, params); odm_init_all_timers(dm); -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
On Wed, Mar 13, 2019 at 01:24:04PM +0100, Armando Miraglia wrote:
> Running Lindent on the mt7621-spi.c file in drivers/staging I noticed that the
> file contained style issues. This change attempts to address such style
> problems.
>
Don't run lindent. I think checkpatch.pl has a --fix option that might
be better, but once the code is merged then our standard become much
higher for follow up patches.
> Signed-off-by: Armando Miraglia
> ---
> NOTE: resend this patch to include all mainteners listed by get_mantainers.pl.
> drivers/staging/mt7621-spi/spi-mt7621.c | 27 +
> 1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c
> b/drivers/staging/mt7621-spi/spi-mt7621.c
> index b509f9fe3346..03d53845f8c5 100644
> --- a/drivers/staging/mt7621-spi/spi-mt7621.c
> +++ b/drivers/staging/mt7621-spi/spi-mt7621.c
> @@ -52,14 +52,14 @@
> #define MT7621_LSB_FIRST BIT(3)
>
> struct mt7621_spi {
> - struct spi_master *master;
> - void __iomem*base;
> - unsigned intsys_freq;
> - unsigned intspeed;
> - struct clk *clk;
> - int pending_write;
> -
> - struct mt7621_spi_ops *ops;
> + struct spi_master *master;
> + void __iomem *base;
> + unsigned int sys_freq;
> + unsigned int speed;
> + struct clk *clk;
> + int pending_write;
> +
> + struct mt7621_spi_ops *ops;
The original is fine. I don't encourage people to do fancy indenting
with their local variable declarations inside functions but for a struct
the declarations aren't going to change a lot so people can get fancy
if they want.
The problem with a local is if you need to add a new variable then you
have to re-indent a bunch of unrelated lines or have one out of
alignment line. Most people know this intuitively so they don't get
fancy.
> };
>
> static inline struct mt7621_spi *spidev_to_mt7621_spi(struct spi_device *spi)
> @@ -303,7 +303,7 @@ static int mt7621_spi_setup(struct spi_device *spi)
> struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
>
> if ((spi->max_speed_hz == 0) ||
> - (spi->max_speed_hz > (rs->sys_freq / 2)))
> + (spi->max_speed_hz > (rs->sys_freq / 2)))
Yeah. Lindent is correct here.
> spi->max_speed_hz = (rs->sys_freq / 2);
>
> if (spi->max_speed_hz < (rs->sys_freq / 4097)) {
> @@ -316,9 +316,10 @@ static int mt7621_spi_setup(struct spi_device *spi)
> }
>
> static const struct of_device_id mt7621_spi_match[] = {
> - { .compatible = "ralink,mt7621-spi" },
> + {.compatible = "ralink,mt7621-spi"},
The original was better.
> {},
> };
> +
> MODULE_DEVICE_TABLE(of, mt7621_spi_match);
No need for a blank. These are closely related.
>
> static int mt7621_spi_probe(struct platform_device *pdev)
> @@ -408,9 +409,9 @@ MODULE_ALIAS("platform:" DRIVER_NAME);
>
> static struct platform_driver mt7621_spi_driver = {
> .driver = {
> - .name = DRIVER_NAME,
> - .of_match_table = mt7621_spi_match,
> - },
> +.name = DRIVER_NAME,
> +.of_match_table = mt7621_spi_match,
> +},
The new indenting is very wrong.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
That might be fun to try :) I should get an mt7621 dev board of sorts though.
On Wed, Mar 13, 2019 at 1:28 PM Matthias Brugger wrote:
>
>
>
> On 13/03/2019 13:24, Armando Miraglia wrote:
> > Running Lindent on the mt7621-spi.c file in drivers/staging I noticed that
> > the
> > file contained style issues. This change attempts to address such style
> > problems.
> >
> > Signed-off-by: Armando Miraglia
>
> Reviewed-by: Matthias Brugger
>
> Apart from fixing styling issues it would be usefull to see if we can add
> support for mt7621 to drivers/spi/spi-mt65xx.c
>
> Not sure if that is something you want to work on :)
>
> Regards,
> Matthias
>
> > ---
> > NOTE: resend this patch to include all mainteners listed by
> > get_mantainers.pl.
> > drivers/staging/mt7621-spi/spi-mt7621.c | 27 +
> > 1 file changed, 14 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c
> > b/drivers/staging/mt7621-spi/spi-mt7621.c
> > index b509f9fe3346..03d53845f8c5 100644
> > --- a/drivers/staging/mt7621-spi/spi-mt7621.c
> > +++ b/drivers/staging/mt7621-spi/spi-mt7621.c
> > @@ -52,14 +52,14 @@
> > #define MT7621_LSB_FIRST BIT(3)
> >
> > struct mt7621_spi {
> > - struct spi_master *master;
> > - void __iomem*base;
> > - unsigned intsys_freq;
> > - unsigned intspeed;
> > - struct clk *clk;
> > - int pending_write;
> > -
> > - struct mt7621_spi_ops *ops;
> > + struct spi_master *master;
> > + void __iomem *base;
> > + unsigned int sys_freq;
> > + unsigned int speed;
> > + struct clk *clk;
> > + int pending_write;
> > +
> > + struct mt7621_spi_ops *ops;
> > };
> >
> > static inline struct mt7621_spi *spidev_to_mt7621_spi(struct spi_device
> > *spi)
> > @@ -303,7 +303,7 @@ static int mt7621_spi_setup(struct spi_device *spi)
> > struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
> >
> > if ((spi->max_speed_hz == 0) ||
> > - (spi->max_speed_hz > (rs->sys_freq / 2)))
> > + (spi->max_speed_hz > (rs->sys_freq / 2)))
> > spi->max_speed_hz = (rs->sys_freq / 2);
> >
> > if (spi->max_speed_hz < (rs->sys_freq / 4097)) {
> > @@ -316,9 +316,10 @@ static int mt7621_spi_setup(struct spi_device *spi)
> > }
> >
> > static const struct of_device_id mt7621_spi_match[] = {
> > - { .compatible = "ralink,mt7621-spi" },
> > + {.compatible = "ralink,mt7621-spi"},
> > {},
> > };
> > +
> > MODULE_DEVICE_TABLE(of, mt7621_spi_match);
> >
> > static int mt7621_spi_probe(struct platform_device *pdev)
> > @@ -408,9 +409,9 @@ MODULE_ALIAS("platform:" DRIVER_NAME);
> >
> > static struct platform_driver mt7621_spi_driver = {
> > .driver = {
> > - .name = DRIVER_NAME,
> > - .of_match_table = mt7621_spi_match,
> > - },
> > +.name = DRIVER_NAME,
> > +.of_match_table = mt7621_spi_match,
> > +},
> > .probe = mt7621_spi_probe,
> > .remove = mt7621_spi_remove,
> > };
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
On 13/03/2019 13:24, Armando Miraglia wrote:
> Running Lindent on the mt7621-spi.c file in drivers/staging I noticed that the
> file contained style issues. This change attempts to address such style
> problems.
>
> Signed-off-by: Armando Miraglia
Reviewed-by: Matthias Brugger
Apart from fixing styling issues it would be usefull to see if we can add
support for mt7621 to drivers/spi/spi-mt65xx.c
Not sure if that is something you want to work on :)
Regards,
Matthias
> ---
> NOTE: resend this patch to include all mainteners listed by get_mantainers.pl.
> drivers/staging/mt7621-spi/spi-mt7621.c | 27 +
> 1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c
> b/drivers/staging/mt7621-spi/spi-mt7621.c
> index b509f9fe3346..03d53845f8c5 100644
> --- a/drivers/staging/mt7621-spi/spi-mt7621.c
> +++ b/drivers/staging/mt7621-spi/spi-mt7621.c
> @@ -52,14 +52,14 @@
> #define MT7621_LSB_FIRST BIT(3)
>
> struct mt7621_spi {
> - struct spi_master *master;
> - void __iomem*base;
> - unsigned intsys_freq;
> - unsigned intspeed;
> - struct clk *clk;
> - int pending_write;
> -
> - struct mt7621_spi_ops *ops;
> + struct spi_master *master;
> + void __iomem *base;
> + unsigned int sys_freq;
> + unsigned int speed;
> + struct clk *clk;
> + int pending_write;
> +
> + struct mt7621_spi_ops *ops;
> };
>
> static inline struct mt7621_spi *spidev_to_mt7621_spi(struct spi_device *spi)
> @@ -303,7 +303,7 @@ static int mt7621_spi_setup(struct spi_device *spi)
> struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
>
> if ((spi->max_speed_hz == 0) ||
> - (spi->max_speed_hz > (rs->sys_freq / 2)))
> + (spi->max_speed_hz > (rs->sys_freq / 2)))
> spi->max_speed_hz = (rs->sys_freq / 2);
>
> if (spi->max_speed_hz < (rs->sys_freq / 4097)) {
> @@ -316,9 +316,10 @@ static int mt7621_spi_setup(struct spi_device *spi)
> }
>
> static const struct of_device_id mt7621_spi_match[] = {
> - { .compatible = "ralink,mt7621-spi" },
> + {.compatible = "ralink,mt7621-spi"},
> {},
> };
> +
> MODULE_DEVICE_TABLE(of, mt7621_spi_match);
>
> static int mt7621_spi_probe(struct platform_device *pdev)
> @@ -408,9 +409,9 @@ MODULE_ALIAS("platform:" DRIVER_NAME);
>
> static struct platform_driver mt7621_spi_driver = {
> .driver = {
> - .name = DRIVER_NAME,
> - .of_match_table = mt7621_spi_match,
> - },
> +.name = DRIVER_NAME,
> +.of_match_table = mt7621_spi_match,
> +},
> .probe = mt7621_spi_probe,
> .remove = mt7621_spi_remove,
> };
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] spi: mediatek: Attempt to address style issues in spi-mt7621.c
Running Lindent on the mt7621-spi.c file in drivers/staging I noticed that the
file contained style issues. This change attempts to address such style
problems.
Signed-off-by: Armando Miraglia
---
NOTE: resend this patch to include all mainteners listed by get_mantainers.pl.
drivers/staging/mt7621-spi/spi-mt7621.c | 27 +
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c
b/drivers/staging/mt7621-spi/spi-mt7621.c
index b509f9fe3346..03d53845f8c5 100644
--- a/drivers/staging/mt7621-spi/spi-mt7621.c
+++ b/drivers/staging/mt7621-spi/spi-mt7621.c
@@ -52,14 +52,14 @@
#define MT7621_LSB_FIRST BIT(3)
struct mt7621_spi {
- struct spi_master *master;
- void __iomem*base;
- unsigned intsys_freq;
- unsigned intspeed;
- struct clk *clk;
- int pending_write;
-
- struct mt7621_spi_ops *ops;
+ struct spi_master *master;
+ void __iomem *base;
+ unsigned int sys_freq;
+ unsigned int speed;
+ struct clk *clk;
+ int pending_write;
+
+ struct mt7621_spi_ops *ops;
};
static inline struct mt7621_spi *spidev_to_mt7621_spi(struct spi_device *spi)
@@ -303,7 +303,7 @@ static int mt7621_spi_setup(struct spi_device *spi)
struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
if ((spi->max_speed_hz == 0) ||
- (spi->max_speed_hz > (rs->sys_freq / 2)))
+ (spi->max_speed_hz > (rs->sys_freq / 2)))
spi->max_speed_hz = (rs->sys_freq / 2);
if (spi->max_speed_hz < (rs->sys_freq / 4097)) {
@@ -316,9 +316,10 @@ static int mt7621_spi_setup(struct spi_device *spi)
}
static const struct of_device_id mt7621_spi_match[] = {
- { .compatible = "ralink,mt7621-spi" },
+ {.compatible = "ralink,mt7621-spi"},
{},
};
+
MODULE_DEVICE_TABLE(of, mt7621_spi_match);
static int mt7621_spi_probe(struct platform_device *pdev)
@@ -408,9 +409,9 @@ MODULE_ALIAS("platform:" DRIVER_NAME);
static struct platform_driver mt7621_spi_driver = {
.driver = {
- .name = DRIVER_NAME,
- .of_match_table = mt7621_spi_match,
- },
+ .name = DRIVER_NAME,
+ .of_match_table = mt7621_spi_match,
+ },
.probe = mt7621_spi_probe,
.remove = mt7621_spi_remove,
};
--
2.21.0.360.g471c308f928-goog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
