[PATCH] staging: olpc_dcon: fix wrong dependencies in Kconfig file
To allow simultaneous support for XO-1 and XO-1.5. This module require GPIO_CS5535 (for 1.0) and ACPI (for 1.5) now. Reported-by: kbuild test robot Signed-off-by: Jerry Lin --- drivers/staging/olpc_dcon/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/olpc_dcon/Kconfig b/drivers/staging/olpc_dcon/Kconfig index 4ae271f..c2429e4 100644 --- a/drivers/staging/olpc_dcon/Kconfig +++ b/drivers/staging/olpc_dcon/Kconfig @@ -3,7 +3,7 @@ config FB_OLPC_DCON tristate "One Laptop Per Child Display CONtroller support" depends on OLPC && FB depends on I2C - depends on (GPIO_CS5535 || ACPI) + depends on (GPIO_CS5535 && ACPI) select BACKLIGHT_CLASS_DEVICE help In order to support very low power operation, the XO laptop uses a -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: olpc_dcon: fix wrong dependencies in Kconfig file
On Wed, Sep 25, 2019 at 03:25:33PM +0800, Jerry Lin wrote: > To allow simultaneous support for XO-1 and XO-1.5. > This module require GPIO_CS5535 (for 1.0) and ACPI (for 1.5) now. > > Reported-by: kbuild test robot > Signed-off-by: Jerry Lin > --- > drivers/staging/olpc_dcon/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/olpc_dcon/Kconfig > b/drivers/staging/olpc_dcon/Kconfig > index 4ae271f..c2429e4 100644 > --- a/drivers/staging/olpc_dcon/Kconfig > +++ b/drivers/staging/olpc_dcon/Kconfig > @@ -3,7 +3,7 @@ config FB_OLPC_DCON > tristate "One Laptop Per Child Display CONtroller support" > depends on OLPC && FB > depends on I2C > - depends on (GPIO_CS5535 || ACPI) > + depends on (GPIO_CS5535 && ACPI) Please, remove the parentheses as well. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: olpc_dcon: fix wrong dependencies in Kconfig file
To allow simultaneous support for XO-1 and XO-1.5. This module require GPIO_CS5535 (for 1.0) and ACPI (for 1.5) now. Reported-by: kbuild test robot Signed-off-by: Jerry Lin --- Changes in v2: - Remove the parentheses --- drivers/staging/olpc_dcon/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/olpc_dcon/Kconfig b/drivers/staging/olpc_dcon/Kconfig index 4ae271f..d1a0dea 100644 --- a/drivers/staging/olpc_dcon/Kconfig +++ b/drivers/staging/olpc_dcon/Kconfig @@ -3,7 +3,7 @@ config FB_OLPC_DCON tristate "One Laptop Per Child Display CONtroller support" depends on OLPC && FB depends on I2C - depends on (GPIO_CS5535 || ACPI) + depends on GPIO_CS5535 && ACPI select BACKLIGHT_CLASS_DEVICE help In order to support very low power operation, the XO laptop uses a -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hardware prerequisites for driver development
Hi, This is probably a real rookie question. I have been interested in contributing to the driver subsystems such as iio. I have submitted some minor patches but nothing substantial. I feel that I need some hardware to be able to contribute more. What hardware would I need to get started? Where would I get this from? Thanks, Rohit ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: olpc_dcon: fix wrong dependencies in Kconfig file
Thanks! regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Hardware prerequisites for driver development
Hi Rohit, There are many companies for hobbyists which sell sensors included in IIO subsystem and for sure some electronic component store in your local area. Price of sensor can be from 0.10 USD to 10 USD. Then you plug this sensor to your Linux board (Beaglebone Black is Linux Foundation preferred, although there are others including Raspberry PI - can even be RPI Zero if you are on a budget, Odroid, Linaro, ...) and you will need to provide correct voltage/current for the sensor. Easiests is that you pick sensors which are 3.3V or 5V domains, because you have pins on most Linux boards with this voltages and these pins supply enough current for most iio sensors. Then you just connect (wire) power pin on sensor to power pin on your board, and then communication pins from sensor to board and ground from sensor to board. Some addition into dts will be needed for the Linux to know where your sensor is connected at, but then it should work as plug-and-play. I hope I did not miss too many steps in between :) Crt On Wed, 25 Sep 2019 at 10:18, Rohit Sarkar wrote: > > Hi, > This is probably a real rookie question. > I have been interested in contributing to the driver subsystems such as > iio. I have submitted some minor patches but nothing substantial. > I feel that I need some hardware to be able to contribute more. > What hardware would I need to get started? > Where would I get this from? > > Thanks, > Rohit ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: exfat: Use kvzalloc() instead of kzalloc() for exfat_sb_info
From: Jia-Ye Li Fix mount failed "Cannot allocate memory". When the memory gets fragmented, kzalloc() might fail to allocate physically contiguous pages for the struct exfat_sb_info (its size is about 34KiB) even the total free memory is enough. Use kvzalloc() to solve this problem. Reviewed-by: Ethan Wu Signed-off-by: Jia-Ye Li --- drivers/staging/exfat/exfat_super.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/exfat/exfat_super.c b/drivers/staging/exfat/exfat_super.c index 5f6caee819a6..bfad2a6bbcb3 100644 --- a/drivers/staging/exfat/exfat_super.c +++ b/drivers/staging/exfat/exfat_super.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include @@ -3450,7 +3451,7 @@ static void exfat_free_super(struct exfat_sb_info *sbi) kfree(sbi->options.iocharset); /* mutex_init is in exfat_fill_super function. only for 3.7+ */ mutex_destroy(&sbi->s_lock); - kfree(sbi); + kvfree(sbi); } static void exfat_put_super(struct super_block *sb) @@ -3845,7 +3846,7 @@ static int exfat_fill_super(struct super_block *sb, void *data, int silent) * the filesystem, since we're only just about to mount * it and have no inodes etc active! */ - sbi = kzalloc(sizeof(struct exfat_sb_info), GFP_KERNEL); + sbi = kvzalloc(sizeof(*sbi), GFP_KERNEL); if (!sbi) return -ENOMEM; mutex_init(&sbi->s_lock); -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Hardware prerequisites for driver development
On Wed, Sep 25, 2019 at 10:32:02AM +0200, Crt Mori wrote: > Hi Rohit, > There are many companies for hobbyists which sell sensors included in > IIO subsystem and for sure some electronic component store in your > local area. Price of sensor can be from 0.10 USD to 10 USD. Then you > plug this sensor to your Linux board (Beaglebone Black is Linux > Foundation preferred, although there are others including Raspberry PI > - can even be RPI Zero if you are on a budget, Odroid, Linaro, ...) > and you will need to provide correct voltage/current for the sensor. > Easiests is that you pick sensors which are 3.3V or 5V domains, > because you have pins on most Linux boards with this voltages and > these pins supply enough current for most iio sensors. Then you just > connect (wire) power pin on sensor to power pin on your board, and > then communication pins from sensor to board and ground from sensor to > board. Some addition into dts will be needed for the Linux to know > where your sensor is connected at, but then it should work as > plug-and-play. > > I hope I did not miss too many steps in between :) > > Crt Hi Crt, Thanks for replying, your answer was super detailed and helpful. Thanks, Rohit ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: fix possible null dereference
Inside a nested 'else' block at the beginning of this function is a
call that assigns 'psta' to the return value of 'rtw_get_stainfo()'.
If 'rtw_get_stainfo()' returns NULL and the flow of control reaches
the 'else if' where 'psta' is dereferenced, then we will dereference
a NULL pointer.
Fix this by checking if 'psta' is not NULL before reading its
'psta->qos_option' data member.
Addresses-Coverity: ("Dereference null return value")
Signed-off-by: Connor Kuehl
---
drivers/staging/rtl8188eu/core/rtw_xmit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 952f2ab51347..bf8877cbe9b6 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -784,7 +784,7 @@ s32 rtw_make_wlanhdr(struct adapter *padapter, u8 *hdr,
struct pkt_attrib *pattr
memcpy(pwlanhdr->addr2, pattrib->src, ETH_ALEN);
memcpy(pwlanhdr->addr3, get_bssid(pmlmepriv), ETH_ALEN);
- if (psta->qos_option)
+ if (psta && psta->qos_option)
qos_option = true;
} else {
RT_TRACE(_module_rtl871x_xmit_c_, _drv_err_,
("fw_state:%x is not allowed to xmit frame\n", get_fwstate(pmlmepriv)));
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v2] PCI: PM: Move to D0 before calling pci_legacy_resume_early()
> From: devel On Behalf Of > Dexuan Cui > Sent: Monday, September 2, 2019 5:35 PM > To: lorenzo.pieral...@arm.com; bhelg...@google.com; > linux-...@vger.kernel.org > [..snipped...] > > --- > > > > changes in v2: > > Updated the changelog with more details. > > > > drivers/pci/pci-driver.c | 7 --- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c > > index 36dbe960306b..27dfc68db9e7 100644 > > --- a/drivers/pci/pci-driver.c > > +++ b/drivers/pci/pci-driver.c > > @@ -1074,15 +1074,16 @@ static int pci_pm_thaw_noirq(struct device > *dev) > > return error; > > } > > > > - if (pci_has_legacy_pm_support(pci_dev)) > > - return pci_legacy_resume_early(dev); > > - > > /* > > * pci_restore_state() requires the device to be in D0 (because of MSI > > * restoration among other things), so force it into D0 in case the > > * driver's "freeze" callbacks put it into a low-power state directly. > > */ > > pci_set_power_state(pci_dev, PCI_D0); > > + > > + if (pci_has_legacy_pm_support(pci_dev)) > > + return pci_legacy_resume_early(dev); > > + > > pci_restore_state(pci_dev); > > > > if (drv && drv->pm && drv->pm->thaw_noirq) > > -- > > Hi, Lorenzo, Bjorn, > > Can you please take a look at the v2 ? > > -- Dexuan Hi Lorenzo, Bjorn, and all, It looks this patch has not been acked by anyone. Should I resend it? There is no change since v2. Thanks, -- Dexuan
Re: [PATCH] staging: rtl8188eu: fix possible null dereference
On 9/25/19 4:32 PM, Connor Kuehl wrote:
Inside a nested 'else' block at the beginning of this function is a
call that assigns 'psta' to the return value of 'rtw_get_stainfo()'.
If 'rtw_get_stainfo()' returns NULL and the flow of control reaches
the 'else if' where 'psta' is dereferenced, then we will dereference
a NULL pointer.
Fix this by checking if 'psta' is not NULL before reading its
'psta->qos_option' data member.
Addresses-Coverity: ("Dereference null return value")
Signed-off-by: Connor Kuehl
---
drivers/staging/rtl8188eu/core/rtw_xmit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 952f2ab51347..bf8877cbe9b6 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -784,7 +784,7 @@ s32 rtw_make_wlanhdr(struct adapter *padapter, u8 *hdr,
struct pkt_attrib *pattr
memcpy(pwlanhdr->addr2, pattrib->src, ETH_ALEN);
memcpy(pwlanhdr->addr3, get_bssid(pmlmepriv), ETH_ALEN);
- if (psta->qos_option)
+ if (psta && psta->qos_option)
qos_option = true;
} else {
RT_TRACE(_module_rtl871x_xmit_c_, _drv_err_, ("fw_state:%x
is not allowed to xmit frame\n", get_fwstate(pmlmepriv)));
This change is a good one, but why not get the same fix at line 779?
Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
