Re: [PATCH 4/4] staging: rtl8188eu: Replace function name with __func__
On Fri, Jun 26, 2020 at 11:36:42AM -0400, Brooke Basile wrote:
> Fix the following checkpatch warning:
> WARNING: Prefer using '"%s...", __func__' to using 'rtw_get_bcn_info',
> this function's name, in a string
>
> Signed-off-by: Brooke Basile
> ---
> drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
> b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
> index bf6b2fe9735f..0c43c0dcf95c 100644
> --- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
> +++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
> @@ -986,10 +986,10 @@ void rtw_get_bcn_info(struct wlan_network *pnetwork)
> if (bencrypt)
> pnetwork->BcnInfo.encryp_protocol = ENCRYP_PROTOCOL_WEP;
> }
> - RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("rtw_get_bcn_info:
> pnetwork->encryp_protocol is %x\n",
> - pnetwork->BcnInfo.encryp_protocol));
> - RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("rtw_get_bcn_info:
> pnetwork->encryp_protocol is %x\n",
> - pnetwork->BcnInfo.encryp_protocol));
> + RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("%s:
> pnetwork->encryp_protocol is %x\n",
> + __func__, pnetwork->BcnInfo.encryp_protocol));
> + RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("%s:
> pnetwork->encryp_protocol is %x\n",
> + __func__, pnetwork->BcnInfo.encryp_protocol));
> rtw_get_cipher_info(pnetwork);
>
> /* get bwmode and ch_offset */
This patch fails to apply to my latest branch, can you rebase it and
resend if it is still needed?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] fbtft-bus.c: Removing that prohibited space before ')'
On Sat, 2020-06-27 at 00:51 -0400, B K Karthik wrote: > fbtft-bus.c: > > fixing ERROR: space prohibited before that close parenthesis ')' by removing > that space and ',' in line 65 and 67. [] > diff --git a/drivers/staging/fbtft/fbtft-bus.c > b/drivers/staging/fbtft/fbtft-bus.c > index 63c65dd67b17..847cbfbbd766 100644 > --- a/drivers/staging/fbtft/fbtft-bus.c > +++ b/drivers/staging/fbtft/fbtft-bus.c > @@ -62,9 +62,9 @@ out: > \ > } > \ > EXPORT_SYMBOL(func); > > -define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, ) > +define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8) > define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16) > -define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, ) > +define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16) Q: Did you compile the files modified by this patch before you submitted it? A: No ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] fbtft-bus.c: Removing that prohibited space before ')'
On Sat, Jun 27, 2020 at 12:51:50AM -0400, B K Karthik wrote: > fbtft-bus.c: > > fixing ERROR: space prohibited before that close parenthesis ')' by removing > that space and ',' in line 65 and 67. > > Signed-off-by: B K Karthik > --- > drivers/staging/fbtft/fbtft-bus.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/fbtft/fbtft-bus.c > b/drivers/staging/fbtft/fbtft-bus.c > index 63c65dd67b17..847cbfbbd766 100644 > --- a/drivers/staging/fbtft/fbtft-bus.c > +++ b/drivers/staging/fbtft/fbtft-bus.c > @@ -62,9 +62,9 @@ out: > \ > } > \ > EXPORT_SYMBOL(func); > > -define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, ) > +define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8) > define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16) > -define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, ) > +define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16) Also, did you test-build this patch? I think this just broke the build... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] fbtft-bus.c:
On Sat, Jun 27, 2020 at 12:50:04AM -0400, B K Karthik wrote: > fbtft-bus.c: > > fixing ERROR: space prohibited before that close parenthesis ')' by removing > that space and ',' in line 65 and 67. > > Signed-off-by: B K Karthik > --- > drivers/staging/fbtft/fbtft-bus.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Your subject line is really odd :( Please read the following text from my patch-bot: - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. - You did not write a descriptive Subject: for the patch, allowing Greg, and everyone else, to know what this patch is all about. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what a proper Subject: line should look like. And fix up both the subject lines, and the changelog body text so that it looks correct. Look at the other patches for this code that have been accepted as examples of what to do. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: usbvision: removing prohibited space before ',' (ctx:WxW)
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Fri, Jun 26, 2020 at 11:42:49AM -0400, B K KARTHIK PES2201800185STUDENT ECE DeptPESU EC Campus wrote: > Oh, I'm sorry but wouldn't it be helpful if we had a file that lists > all drivers that are scheduled for removal? The TODO file in the directory for the driver should have this information in it. I don't know if all of the media drivers have this, if not, then there is no way you could have known this. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] fbtft-bus.c: Removing that prohibited space before ')'
fbtft-bus.c:
fixing ERROR: space prohibited before that close parenthesis ')' by removing
that space and ',' in line 65 and 67.
Signed-off-by: B K Karthik
---
drivers/staging/fbtft/fbtft-bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c
b/drivers/staging/fbtft/fbtft-bus.c
index 63c65dd67b17..847cbfbbd766 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -62,9 +62,9 @@ out:
\
} \
EXPORT_SYMBOL(func);
-define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
+define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
-define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
+define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
{
--
2.20.1
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] fbtft-bus.c:
fbtft-bus.c:
fixing ERROR: space prohibited before that close parenthesis ')' by removing
that space and ',' in line 65 and 67.
Signed-off-by: B K Karthik
---
drivers/staging/fbtft/fbtft-bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c
b/drivers/staging/fbtft/fbtft-bus.c
index 63c65dd67b17..847cbfbbd766 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -62,9 +62,9 @@ out:
\
} \
EXPORT_SYMBOL(func);
-define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
+define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
-define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
+define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
{
--
2.20.1
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: qlge: fix else after return or break
On Sat, 2020-06-27 at 07:57 +0800, Coiby Xu wrote: > On Thu, Jun 25, 2020 at 03:13:14PM -0700, Joe Perches wrote: > > On Fri, 2020-06-26 at 05:57 +0800, Coiby Xu wrote: > > > Remove unnecessary elses after return or break. > > > > unrelated trivia: [] > > looks like all of these could use netdev_err [] > should we also replace all pr_errs with netdev_err in > ql_dump_* functions? Ideally, anywhere a struct netdevice * is available, it should be used to output netdev_ in preference to pr_. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: qlge: fix else after return or break
On Thu, Jun 25, 2020 at 03:13:14PM -0700, Joe Perches wrote:
On Fri, 2020-06-26 at 05:57 +0800, Coiby Xu wrote:
Remove unnecessary elses after return or break.
unrelated trivia:
diff --git a/drivers/staging/qlge/qlge_dbg.c b/drivers/staging/qlge/qlge_dbg.c
[]
@@ -1391,12 +1391,11 @@ static void ql_dump_cam_entries(struct ql_adapter *qdev)
pr_err("%s: Failed read of mac index register\n",
__func__);
return;
- } else {
- if (value[0])
- pr_err("%s: CAM index %d CAM Lookup Lower =
0x%.08x:%.08x, Output = 0x%.08x\n",
- qdev->ndev->name, i, value[1], value[0],
- value[2]);
looks like all of these could use netdev_err
netdev_err(qdev, "etc...",
i, value[1], value[0], value[2]);
etc...
Should we also replace all pr_errs with netdev_err in
ql_dump_* functions? I'm not sure how we will use ql_dump_*. For example,
ql_dump_regs is not referred by any kernel source, so I guess it's for
the sole purpose of debugging the driver by the developer. But one
pr_err in ql_dump_routing_entries which is called by dl_dump_regs doesn't
prints out the device name whereas the other does,
void ql_dump_routing_entries(struct ql_adapter *qdev)
{
int i;
u32 value;
i = ql_sem_spinlock(qdev, SEM_RT_IDX_MASK);
if (i)
return;
for (i = 0; i < 16; i++) {
value = 0;
if (ql_get_routing_reg(qdev, i, )) {
pr_err("%s: Failed read of routing index register\n",
__func__);
break;
}
if (value)
pr_err("%s: Routing Mask %d = 0x%.08x\n",
qdev->ndev->name, i, value);
}
--
Best regards,
Coiby
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: usbvision: removing prohibited space before ',' (ctx:WxW)
Oh, I'm sorry but wouldn't it be helpful if we had a file that lists
all drivers that are scheduled for removal? I personally feel that it
would help out all kernel newbies.
I've been trying to complete task10 in the eudyptula challenge, and
the patches either get thrown out by greg's patch-bot, or the driver
is scheduled for removal.
Please do think about adding a file that lists all drivers scheduled
for removal.
I apologize if my message was hurtful or disrespectful in any way.
Thank you for reading this message,
Karthik
On Fri, Jun 26, 2020 at 10:32 AM B K Karthik wrote:
>
> fixing ERROR: space prohibited before that ',' (ctx:WxW)
>
> Signed-off-by: B K Karthik
> ---
> drivers/staging/media/usbvision/usbvision-i2c.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/usbvision/usbvision-i2c.c
> b/drivers/staging/media/usbvision/usbvision-i2c.c
> index 6e4df3335b1b..010ad03c6ec1 100644
> --- a/drivers/staging/media/usbvision/usbvision-i2c.c
> +++ b/drivers/staging/media/usbvision/usbvision-i2c.c
> @@ -32,7 +32,7 @@ MODULE_PARM_DESC(i2c_debug, "enable debug messages [i2c]");
> #define PDEBUG(level, fmt, args...) { \
> if (i2c_debug & (level)) \
> printk(KERN_INFO KBUILD_MODNAME ":[%s:%d] " fmt, \
> - __func__, __LINE__ , ## args); \
> + __func__, __LINE__, ## args); \
> }
>
> static int usbvision_i2c_write(struct usb_usbvision *usbvision, unsigned
> char addr, char *buf,
> --
> 2.20.1
>
--
B K Karthik
9535399755
karthik.oncreate.team
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] Some atomisp fixes and improvements
Em Fri, 26 Jun 2020 17:52:16 +0200 Mauro Carvalho Chehab escreveu: > Em Fri, 26 Jun 2020 18:00:21 +0300 > Andy Shevchenko escreveu: > > > On Fri, Jun 26, 2020 at 04:04:52PM +0200, Mauro Carvalho Chehab wrote: > > > Those patches are meant to improve device detection by the atomisp driver, > > > relying on ACPI bios when possible. > > > > > > It also adds a basis for using ACPI PM, but only if the DSDT tables have > > > a description about how to turn on the resources needed by the cameras. > > > > > > At least on the device I'm using for tests, this is not the case. > > > > Is this in your experimental tree? > > Yes. > > > I'll rebase mine on top and test. > > After I will send the rest from my series and give a tag to this. > > It would be helpful if you could test removing the DMI match table from > your board. If your device has a DSDT table close to the one I have, the > new code may be able to get everything from DSDT. Err... I spoke too soon... looking on the logs from your 00/15, it seems that your device's DSDT is indeed different: [ 116.401267] ACPI: \: failed to evaluate _DSM (0x1001) If possible, could you please send me (could be in priv) a copy of your DSDT? Thanks, Mauro ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] Some atomisp fixes and improvements
Em Fri, 26 Jun 2020 18:00:21 +0300 Andy Shevchenko escreveu: > On Fri, Jun 26, 2020 at 04:04:52PM +0200, Mauro Carvalho Chehab wrote: > > Those patches are meant to improve device detection by the atomisp driver, > > relying on ACPI bios when possible. > > > > It also adds a basis for using ACPI PM, but only if the DSDT tables have > > a description about how to turn on the resources needed by the cameras. > > > > At least on the device I'm using for tests, this is not the case. > > Is this in your experimental tree? Yes. > I'll rebase mine on top and test. > After I will send the rest from my series and give a tag to this. It would be helpful if you could test removing the DMI match table from your board. If your device has a DSDT table close to the one I have, the new code may be able to get everything from DSDT. > > > > > Mauro Carvalho Chehab (7): > > media: atomisp: reorganize the code under gmin_subdev_add() > > media: atomisp: Prepare sensor support for ACPI PM > > media: atomisp: properly parse CLK PMIC on newer devices > > media: atomisp: fix call to g_frame_interval > > media: atomisp: print info if gpio0 and gpio2 were detected > > media: atomisp: split add from find subdev > > media: atomisp: place all gpio parsing together > > > > .../staging/media/atomisp/pci/atomisp_cmd.c | 2 +- > > .../media/atomisp/pci/atomisp_gmin_platform.c | 393 -- > > 2 files changed, 267 insertions(+), 128 deletions(-) > > > > -- > > 2.26.2 > > > > > Thanks, Mauro ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] staging: rtl8188eu: Replace function name with __func__
Fix the following checkpatch warning:
WARNING: Prefer using '"%s...", __func__' to using 'rtw_get_bcn_info',
this function's name, in a string
Signed-off-by: Brooke Basile
---
drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index bf6b2fe9735f..0c43c0dcf95c 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -986,10 +986,10 @@ void rtw_get_bcn_info(struct wlan_network *pnetwork)
if (bencrypt)
pnetwork->BcnInfo.encryp_protocol = ENCRYP_PROTOCOL_WEP;
}
- RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("rtw_get_bcn_info:
pnetwork->encryp_protocol is %x\n",
-pnetwork->BcnInfo.encryp_protocol));
- RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("rtw_get_bcn_info:
pnetwork->encryp_protocol is %x\n",
-pnetwork->BcnInfo.encryp_protocol));
+ RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("%s:
pnetwork->encryp_protocol is %x\n",
+__func__, pnetwork->BcnInfo.encryp_protocol));
+ RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_, ("%s:
pnetwork->encryp_protocol is %x\n",
+__func__, pnetwork->BcnInfo.encryp_protocol));
rtw_get_cipher_info(pnetwork);
/* get bwmode and ch_offset */
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] staging: rtl8188eu: Fix indentation
Fix the following checkpatch warning:
WARNING: suspect code indent for conditional statements (16, 32)
Signed-off-by: Brooke Basile
---
.../staging/rtl8188eu/core/rtw_ieee80211.c| 30 +--
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 44a25d29f1d3..bf6b2fe9735f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -494,23 +494,23 @@ void rtw_get_sec_ie(u8 *in_ie, uint in_len, u8 *rsn_ie,
u16 *rsn_len, u8 *wpa_ie
authmode = in_ie[cnt];
if ((authmode == _WPA_IE_ID_) && (!memcmp(_ie[cnt + 2],
_oui[0], 4))) {
- RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_,
-("\n rtw_get_wpa_ie: sec_idx =%d
in_ie[cnt+1]+2 =%d\n",
-sec_idx, in_ie[cnt + 1] + 2));
-
- if (wpa_ie) {
- memcpy(wpa_ie, _ie[cnt], in_ie[cnt +
1] + 2);
-
- for (i = 0; i < (in_ie[cnt + 1] + 2); i
+= 8) {
-
RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_,
-("\n
%2x,%2x,%2x,%2x,%2x,%2x,%2x,%2x\n",
-wpa_ie[i], wpa_ie[i +
1], wpa_ie[i + 2], wpa_ie[i + 3], wpa_ie[i + 4],
-wpa_ie[i + 5],
wpa_ie[i + 6], wpa_ie[i + 7]));
- }
+ RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_,
+("\n rtw_get_wpa_ie: sec_idx =%d
in_ie[cnt+1]+2 =%d\n",
+sec_idx, in_ie[cnt + 1] + 2));
+
+ if (wpa_ie) {
+ memcpy(wpa_ie, _ie[cnt], in_ie[cnt + 1] + 2);
+
+ for (i = 0; i < (in_ie[cnt + 1] + 2); i += 8) {
+ RT_TRACE(_module_rtl871x_mlme_c_,
_drv_info_,
+("\n
%2x,%2x,%2x,%2x,%2x,%2x,%2x,%2x\n",
+wpa_ie[i], wpa_ie[i + 1],
wpa_ie[i + 2], wpa_ie[i + 3], wpa_ie[i + 4],
+wpa_ie[i + 5], wpa_ie[i + 6],
wpa_ie[i + 7]));
}
+ }
- *wpa_len = in_ie[cnt + 1] + 2;
- cnt += in_ie[cnt + 1] + 2; /* get next */
+ *wpa_len = in_ie[cnt + 1] + 2;
+ cnt += in_ie[cnt + 1] + 2; /* get next */
} else {
if (authmode == _WPA2_IE_ID_) {
RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_,
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] staging: rtl8188eu: Fix strings split across lines
Fix the following checkpatch warning:
WARNING: quoted string split across lines
Signed-off-by: Brooke Basile
---
drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index a27dce7f30b3..44a25d29f1d3 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -381,8 +381,8 @@ int rtw_parse_wpa_ie(u8 *wpa_ie, int wpa_ie_len, int
*group_cipher, int *pairwis
left -= 2;
if (count == 0 || left < count * WPA_SELECTOR_LEN) {
- RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("%s: ie
count botch (pairwise), "
- "count %u left %u", __func__,
count, left));
+ RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("%s: ie
count botch (pairwise), count %u left %u",
+ __func__, count, left));
return _FAIL;
}
@@ -448,8 +448,8 @@ int rtw_parse_wpa2_ie(u8 *rsn_ie, int rsn_ie_len, int
*group_cipher, int *pairwi
left -= 2;
if (count == 0 || left < count * RSN_SELECTOR_LEN) {
- RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("%s: ie
count botch (pairwise), "
-"count %u left %u", __func__,
count, left));
+ RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("%s: ie
count botch (pairwise), count %u left %u",
+ __func__, count, left));
return _FAIL;
}
@@ -943,8 +943,8 @@ static int rtw_get_cipher_info(struct wlan_network
*pnetwork)
pnetwork->BcnInfo.pairwise_cipher =
pairwise_cipher;
pnetwork->BcnInfo.group_cipher = group_cipher;
pnetwork->BcnInfo.is_8021x = is8021x;
- RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_,
("%s: pnetwork->pairwise_cipher: %d,"
- "pnetwork->group_cipher
is %d, is_8021x is %d", __func__, pnetwork->BcnInfo.pairwise_cipher,
+ RT_TRACE(_module_rtl871x_mlme_c_, _drv_info_,
("%s: pnetwork->pairwise_cipher: %d, pnetwork->group_cipher is %d, is_8021x is
%d",
+ __func__,
pnetwork->BcnInfo.pairwise_cipher,
pnetwork->BcnInfo.group_cipher, pnetwork->BcnInfo.is_8021x));
ret = _SUCCESS;
}
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] staging: rtl8188eu: Fix comment formatting
Fix the following checkpatch warnings:
WARNING: Block comments use * on subsequent lines
WARNING: Block comments use a trailing */ on a separate line
Signed-off-by: Brooke Basile
---
.../staging/rtl8188eu/core/rtw_ieee80211.c| 26 ---
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index caf600eba03b..a27dce7f30b3 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -139,9 +139,11 @@ u8 *rtw_set_ie
return pbuf + len + 2;
}
-/*
-index: the information element id index, limit is the limit for search
--*/
+/*
+ *
+ * index: the information element id index, limit is the limit for search
+ *
+ */
u8 *rtw_get_ie(u8 *pbuf, int index, uint *len, int limit)
{
int tmp, i;
@@ -680,9 +682,11 @@ static int rtw_ieee802_11_parse_vendor_specific(u8 *pos,
uint elen,
{
unsigned int oui;
- /* first 3 bytes in vendor specific information element are the IEEE
+ /*
+* first 3 bytes in vendor specific information element are the IEEE
* OUI of the vendor. The following byte is used a vendor specific
-* sub-type. */
+* sub-type.
+*/
if (elen < 4) {
if (show_errors) {
DBG_88E("short vendor specific information element
ignored (len=%lu)\n",
@@ -694,12 +698,16 @@ static int rtw_ieee802_11_parse_vendor_specific(u8 *pos,
uint elen,
oui = RTW_GET_BE24(pos);
switch (oui) {
case OUI_MICROSOFT:
- /* Microsoft/Wi-Fi information elements are further typed and
-* subtyped */
+ /*
+* Microsoft/Wi-Fi information elements are further typed and
+* subtyped
+*/
switch (pos[3]) {
case 1:
- /* Microsoft OUI (00:50:F2) with OUI Type 1:
-* real WPA information element */
+ /*
+* Microsoft OUI (00:50:F2) with OUI Type 1:
+* real WPA information element
+*/
elems->wpa_ie = pos;
elems->wpa_ie_len = elen;
break;
--
2.27.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] Some atomisp fixes and improvements
On Fri, Jun 26, 2020 at 04:04:52PM +0200, Mauro Carvalho Chehab wrote: > Those patches are meant to improve device detection by the atomisp driver, > relying on ACPI bios when possible. > > It also adds a basis for using ACPI PM, but only if the DSDT tables have > a description about how to turn on the resources needed by the cameras. > > At least on the device I'm using for tests, this is not the case. Is this in your experimental tree? I'll rebase mine on top and test. After I will send the rest from my series and give a tag to this. > > Mauro Carvalho Chehab (7): > media: atomisp: reorganize the code under gmin_subdev_add() > media: atomisp: Prepare sensor support for ACPI PM > media: atomisp: properly parse CLK PMIC on newer devices > media: atomisp: fix call to g_frame_interval > media: atomisp: print info if gpio0 and gpio2 were detected > media: atomisp: split add from find subdev > media: atomisp: place all gpio parsing together > > .../staging/media/atomisp/pci/atomisp_cmd.c | 2 +- > .../media/atomisp/pci/atomisp_gmin_platform.c | 393 -- > 2 files changed, 267 insertions(+), 128 deletions(-) > > -- > 2.26.2 > > -- With Best Regards, Andy Shevchenko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: usbvision: removing prohibited space before ',' (ctx:WxW)
On Fri, Jun 26, 2020 at 04:36:52PM +0200, Hans Verkuil wrote:
> On 26/06/2020 16:32, B K Karthik wrote:
> > fixing ERROR: space prohibited before that ',' (ctx:WxW)
> >
> > Signed-off-by: B K Karthik
>
> usbvision is another driver that is scheduled for removal by the end of the
> year,
> so I won't apply this patch.
>
> > ---
> > drivers/staging/media/usbvision/usbvision-i2c.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/media/usbvision/usbvision-i2c.c
> > b/drivers/staging/media/usbvision/usbvision-i2c.c
> > index 6e4df3335b1b..010ad03c6ec1 100644
> > --- a/drivers/staging/media/usbvision/usbvision-i2c.c
> > +++ b/drivers/staging/media/usbvision/usbvision-i2c.c
> > @@ -32,7 +32,7 @@ MODULE_PARM_DESC(i2c_debug, "enable debug messages
> > [i2c]");
> > #define PDEBUG(level, fmt, args...) { \
> > if (i2c_debug & (level)) \
> > printk(KERN_INFO KBUILD_MODNAME ":[%s:%d] " fmt, \
> > - __func__, __LINE__ , ## args); \
> > + __func__, __LINE__, ## args); \
>
> Actually, older (buggy) gcc compiler needed a space there, if memory serves.
Yes, that will break on old versions of gcc. crazy...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: usbvision: removing prohibited space before ',' (ctx:WxW)
On 26/06/2020 16:32, B K Karthik wrote:
> fixing ERROR: space prohibited before that ',' (ctx:WxW)
>
> Signed-off-by: B K Karthik
usbvision is another driver that is scheduled for removal by the end of the
year,
so I won't apply this patch.
> ---
> drivers/staging/media/usbvision/usbvision-i2c.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/usbvision/usbvision-i2c.c
> b/drivers/staging/media/usbvision/usbvision-i2c.c
> index 6e4df3335b1b..010ad03c6ec1 100644
> --- a/drivers/staging/media/usbvision/usbvision-i2c.c
> +++ b/drivers/staging/media/usbvision/usbvision-i2c.c
> @@ -32,7 +32,7 @@ MODULE_PARM_DESC(i2c_debug, "enable debug messages [i2c]");
> #define PDEBUG(level, fmt, args...) { \
> if (i2c_debug & (level)) \
> printk(KERN_INFO KBUILD_MODNAME ":[%s:%d] " fmt, \
> - __func__, __LINE__ , ## args); \
> + __func__, __LINE__, ## args); \
Actually, older (buggy) gcc compiler needed a space there, if memory serves.
Regards,
Hans
> }
>
> static int usbvision_i2c_write(struct usb_usbvision *usbvision, unsigned
> char addr, char *buf,
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: media: usbvision: removing prohibited space before ',' (ctx:WxW)
fixing ERROR: space prohibited before that ',' (ctx:WxW)
Signed-off-by: B K Karthik
---
drivers/staging/media/usbvision/usbvision-i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/usbvision/usbvision-i2c.c
b/drivers/staging/media/usbvision/usbvision-i2c.c
index 6e4df3335b1b..010ad03c6ec1 100644
--- a/drivers/staging/media/usbvision/usbvision-i2c.c
+++ b/drivers/staging/media/usbvision/usbvision-i2c.c
@@ -32,7 +32,7 @@ MODULE_PARM_DESC(i2c_debug, "enable debug messages [i2c]");
#define PDEBUG(level, fmt, args...) { \
if (i2c_debug & (level)) \
printk(KERN_INFO KBUILD_MODNAME ":[%s:%d] " fmt, \
- __func__, __LINE__ , ## args); \
+ __func__, __LINE__, ## args); \
}
static int usbvision_i2c_write(struct usb_usbvision *usbvision, unsigned char
addr, char *buf,
--
2.20.1
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/7] media: atomisp: Prepare sensor support for ACPI PM
Add support code for this driver to use ACPI power management.
Yet, at least with known devices, this won't work without
further changes.
The rationale is that the ACPI handling code checks for the _PR? tables
in order to know what is required to switch the device from power state
D0 (_PR0) up to D3COLD (_PR3).
The adev->flags.power_manageable is set to true if the device has a _PR0
table, which can be checked by calling acpi_device_power_manageable(adev).
However, this only says that the device can be set to power off mode.
At least on the DSDT tables we've seen so far, there's no _PR3 nor _PS3
(which would have a somewhat similar effect).
So, using ACPI for power management won't work, except if adding
an ACPI override logic somewhere.
Signed-off-by: Mauro Carvalho Chehab
---
.../media/atomisp/pci/atomisp_gmin_platform.c | 89 +--
1 file changed, 83 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 74331c4467bd..2903aa52115b 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -65,7 +65,6 @@ enum clock_rate {
struct gmin_subdev {
struct v4l2_subdev *subdev;
enum clock_rate clock_src;
- bool clock_on;
struct clk *pmc_clk;
struct gpio_desc *gpio0;
struct gpio_desc *gpio1;
@@ -77,6 +76,8 @@ struct gmin_subdev {
unsigned int csi_lanes;
enum atomisp_input_format csi_fmt;
enum atomisp_bayer_order csi_bayer;
+
+ bool clock_on;
bool v1p8_on;
bool v2p8_on;
bool v1p2_on;
@@ -107,7 +108,7 @@ static enum {
} pmic_id;
static const char *pmic_name[] = {
- [PMIC_UNSET]= "unset",
+ [PMIC_UNSET]= "ACPI device PM",
[PMIC_REGULATOR]= "regulator driver",
[PMIC_AXP] = "XPower AXP288 PMIC",
[PMIC_TI] = "Dollar Cove TI PMIC",
@@ -500,8 +501,39 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
gs->gpio1 = NULL;
/*
-* FIXME: the code below doesn't rely on ACPI device_pm.c code to
-* set clocks and do power management.
+* FIXME:
+*
+* The ACPI handling code checks for the _PR? tables in order to
+* know what is required to switch the device from power state
+* D0 (_PR0) up to D3COLD (_PR3).
+*
+* The adev->flags.power_manageable is set to true if the device
+* has a _PR0 table, which can be checked by calling
+* acpi_device_power_manageable(adev).
+*
+* However, this only says that the device can be set to power off
+* mode.
+*
+* At least on the DSDT tables we've seen so far, there's no _PR3,
+* nor _PS3 (which would have a somewhat similar effect).
+* So, using ACPI for power management won't work, except if adding
+* an ACPI override logic somewhere.
+*
+* So, at least for the existing devices we know, the check below
+* will always be false.
+*/
+ if (acpi_device_can_wakeup(adev) &&
+ acpi_device_can_poweroff(adev)) {
+ dev_info(dev,
+"gmin: power management provided via device PM\n");
+
+ return gs;
+ }
+
+ /*
+* The code below is here due to backward compatibility with devices
+* whose ACPI BIOS may not contain everything that would be needed
+* in order to set clocks and do power management.
*/
if (!pmic_id) {
@@ -856,6 +888,37 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int
on)
return -EINVAL;
}
+static int gmin_acpi_pm_ctrl(struct v4l2_subdev *subdev, int on)
+{
+ int ret = 0;
+ struct gmin_subdev *gs = find_gmin_subdev(subdev);
+ struct i2c_client *client = v4l2_get_subdevdata(subdev);
+ struct acpi_device *adev = ACPI_COMPANION(>dev);
+
+ /* Use the ACPI power management to control it */
+ on = !!on;
+ if (gs->clock_on == on)
+ return 0;
+
+ dev_dbg(subdev->dev, "Setting power state to %s\n",
+ on ? "on" : "off");
+
+ if (on)
+ ret = acpi_device_set_power(adev,
+ ACPI_STATE_D0);
+ else
+ ret = acpi_device_set_power(adev,
+ ACPI_STATE_D3_COLD);
+
+ if (!ret)
+ gs->clock_on = on;
+ else
+ dev_err(subdev->dev, "Couldn't set power state to %s\n",
+ on ? "on" : "off");
+
+ return ret;
+}
+
static int gmin_flisclk_ctrl(struct v4l2_subdev *subdev, int on)
{
int ret = 0;
@@ -921,7 +984,7 @@ static struct camera_vcm_control *gmin_get_vcm_ctrl(struct
[PATCH 3/7] media: atomisp: properly parse CLK PMIC on newer devices
Newer devices don't place the PMIC CLK line inside an EFI
var. Instead, those are found at the _PR0 table.
Add a parser for it, using info stored via the DSDT table.
Signed-off-by: Mauro Carvalho Chehab
---
.../media/atomisp/pci/atomisp_gmin_platform.c | 66 ++-
1 file changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 2903aa52115b..e476cf1f3294 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -444,6 +444,61 @@ static int gmin_i2c_write(struct device *dev, u16
i2c_addr, u8 reg,
return ret;
}
+static int atomisp_get_acpi_power(struct device *dev, acpi_handle handle)
+{
+ char name[5];
+ struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer b_name = { sizeof(name), name };
+ union acpi_object *package, *element;
+ acpi_handle rhandle;
+ acpi_status status;
+ int clock_num = -1;
+ int i;
+
+ status = acpi_evaluate_object(handle, "_PR0", NULL, );
+ if (!ACPI_SUCCESS(status))
+ return -1;
+
+ package = buffer.pointer;
+
+ if (!buffer.length || !package
+ || package->type != ACPI_TYPE_PACKAGE
+ || !package->package.count)
+ goto fail;
+
+ for (i = 0; i < package->package.count; i++) {
+ element = >package.elements[i];
+
+ if (element->type != ACPI_TYPE_LOCAL_REFERENCE)
+ continue;
+
+ rhandle = element->reference.handle;
+ if (!rhandle)
+ goto fail;
+
+ acpi_get_name(rhandle, ACPI_SINGLE_NAME, _name);
+
+ dev_dbg(dev, "Found PM resource '%s'\n", name);
+ if (strlen(name) == 4 && !strncmp(name, "CLK", 3)) {
+ if (name[3] >= '0' && name[3] <= '4')
+ clock_num = name[3] - '0';
+#if 0
+ /*
+* We could abort here, but let's parse all resources,
+* as this is helpful for debugging purposes
+*/
+ if (clock_num >= 0)
+ break;
+#endif
+ }
+ }
+
+fail:
+ ACPI_FREE(buffer.pointer);
+
+ return clock_num;
+}
+
static struct gmin_subdev *gmin_subdev_add(struct v4l2_subdev *subdev)
{
struct i2c_client *power = NULL, *client = v4l2_get_subdevdata(subdev);
@@ -451,7 +506,7 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
struct gmin_subdev *gs;
acpi_handle handle;
struct device *dev;
- int i, ret, clock_num;
+ int i, ret, clock_num = -1;
if (!client)
return NULL;
@@ -570,7 +625,14 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
* is a power resource already, falling back to the EFI vars detection
* otherwise.
*/
- clock_num = gmin_get_var_int(dev, false, "CamClk", -1);
+
+ /* Try first to use ACPI to get the clock resource */
+ if (acpi_device_power_manageable(adev))
+ clock_num = atomisp_get_acpi_power(dev, handle);
+
+ /* Fall-back use EFI and/or DMI match */
+ if (clock_num < 0)
+ clock_num = gmin_get_var_int(dev, false, "CamClk", 0);
if (clock_num < 0 || clock_num > MAX_CLK_COUNT) {
dev_err(dev, "Invalid clock number\n");
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/7] Some atomisp fixes and improvements
Those patches are meant to improve device detection by the atomisp driver, relying on ACPI bios when possible. It also adds a basis for using ACPI PM, but only if the DSDT tables have a description about how to turn on the resources needed by the cameras. At least on the device I'm using for tests, this is not the case. Mauro Carvalho Chehab (7): media: atomisp: reorganize the code under gmin_subdev_add() media: atomisp: Prepare sensor support for ACPI PM media: atomisp: properly parse CLK PMIC on newer devices media: atomisp: fix call to g_frame_interval media: atomisp: print info if gpio0 and gpio2 were detected media: atomisp: split add from find subdev media: atomisp: place all gpio parsing together .../staging/media/atomisp/pci/atomisp_cmd.c | 2 +- .../media/atomisp/pci/atomisp_gmin_platform.c | 393 -- 2 files changed, 267 insertions(+), 128 deletions(-) -- 2.26.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/7] media: atomisp: print info if gpio0 and gpio2 were detected
If the ACPI DSDT tables provide _CRS for the camera, the GPIO core code should be able to handle them automatically. Signed-off-by: Mauro Carvalho Chehab --- drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c index e476cf1f3294..31ec21a3ba84 100644 --- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c +++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c @@ -550,10 +550,14 @@ static struct gmin_subdev *gmin_subdev_add(struct v4l2_subdev *subdev) gs->gpio0 = gpiod_get_index(dev, NULL, 0, GPIOD_OUT_LOW); if (IS_ERR(gs->gpio0)) gs->gpio0 = NULL; + else + dev_info(dev, "will handle gpio0 via ACPI\n"); gs->gpio1 = gpiod_get_index(dev, NULL, 1, GPIOD_OUT_LOW); if (IS_ERR(gs->gpio1)) gs->gpio1 = NULL; + else + dev_info(dev, "will handle gpio1 via ACPI\n"); /* * FIXME: -- 2.26.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/7] media: atomisp: fix call to g_frame_interval
The media core has now a check if fi->pad is bigger than zero
or bigger than sd->entity.num_pads, if the media controller
is defined.
This causes a call to g_frame_interval to return -EINVAL.
Fix it by first cleaning up the struct.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/atomisp/pci/atomisp_cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
index 7b936e5a5f03..388b57455204 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
@@ -109,7 +109,7 @@ struct atomisp_acc_pipe *atomisp_to_acc_pipe(struct
video_device *dev)
static unsigned short atomisp_get_sensor_fps(struct atomisp_sub_device *asd)
{
- struct v4l2_subdev_frame_interval fi;
+ struct v4l2_subdev_frame_interval fi = { 0 };
struct atomisp_device *isp = asd->isp;
unsigned short fps = 0;
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/7] media: atomisp: split add from find subdev
There's only one place where a subdev can be added: when the
sensor driver registers it. Trying to do it elsewhere will
cause problems, as the detection code needs to access the
I2C bus in order to probe some things.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 31ec21a3ba84..3136759bf96f 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -202,6 +202,8 @@ int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
* gmin_subdev struct is already initialized for us.
*/
gs = find_gmin_subdev(subdev);
+ if (!gs)
+ return -ENODEV;
pdata.subdevs[i].type = type;
pdata.subdevs[i].port = gs->csi_port;
@@ -726,7 +728,7 @@ static struct gmin_subdev *find_gmin_subdev(struct
v4l2_subdev *subdev)
for (i = 0; i < MAX_SUBDEVS; i++)
if (gmin_subdevs[i].subdev == subdev)
return _subdevs[i];
- return gmin_subdev_add(subdev);
+ return NULL;
}
static int axp_regulator_set(struct device *dev, struct gmin_subdev *gs,
@@ -1077,7 +1079,7 @@ struct camera_sensor_platform_data
*gmin_camera_platform_data(
enum atomisp_input_format csi_format,
enum atomisp_bayer_order csi_bayer)
{
- struct gmin_subdev *gs = find_gmin_subdev(subdev);
+ struct gmin_subdev *gs = gmin_subdev_add(subdev);
gs->csi_fmt = csi_format;
gs->csi_bayer = csi_bayer;
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 7/7] media: atomisp: place all gpio parsing together
Instead of parsing GPIO for two exceptions inside the logic
which would be trying to use the GPIO, move the init code
to the routine which adds a new gmin device.
Move the notes to it too, as this helps to identify where
those two GPIO settings are used, explaining why they're
defaulting to -1 when not found.
Signed-off-by: Mauro Carvalho Chehab
---
.../media/atomisp/pci/atomisp_gmin_platform.c | 86 +--
1 file changed, 40 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 3136759bf96f..1a1a6a9ee8a3 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -83,6 +83,9 @@ struct gmin_subdev {
bool v1p2_on;
bool v2p8_vcm_on;
+ int v1p8_gpio;
+ int v2p8_gpio;
+
u8 pwm_i2c_addr;
/* For PMIC AXP */
@@ -122,24 +125,6 @@ static const struct atomisp_platform_data pdata = {
.subdevs = pdata_subdevs,
};
-/*
- * Something of a hack. The ECS E7 board drives camera 2.8v from an
- * external regulator instead of the PMIC. There's a gmin_CamV2P8
- * config variable that specifies the GPIO to handle this particular
- * case, but this needs a broader architecture for handling camera
- * power.
- */
-enum { V2P8_GPIO_UNSET = -2, V2P8_GPIO_NONE = -1 };
-static int v2p8_gpio = V2P8_GPIO_UNSET;
-
-/*
- * Something of a hack. The CHT RVP board drives camera 1.8v from an
- * external regulator instead of the PMIC just like ECS E7 board, see the
- * comments above.
- */
-enum { V1P8_GPIO_UNSET = -2, V1P8_GPIO_NONE = -1 };
-static int v1p8_gpio = V1P8_GPIO_UNSET;
-
static LIST_HEAD(vcm_devices);
static DEFINE_MUTEX(vcm_lock);
@@ -561,6 +546,23 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
else
dev_info(dev, "will handle gpio1 via ACPI\n");
+ /*
+* Those are used only when there is an external regulator apart
+* from the PMIC that would be providing power supply, like on the
+* two cases below:
+*
+* The ECS E7 board drives camera 2.8v from an external regulator
+* instead of the PMIC. There's a gmin_CamV2P8 config variable
+* that specifies the GPIO to handle this particular case,
+* but this needs a broader architecture for handling camera power.
+*
+* The CHT RVP board drives camera 1.8v from an* external regulator
+* instead of the PMIC just like ECS E7 board.
+*/
+
+ gs->v1p8_gpio = gmin_get_var_int(dev, true, "V1P8GPIO", -1);
+ gs->v2p8_gpio = gmin_get_var_int(dev, true, "V2P8GPIO", -1);
+
/*
* FIXME:
*
@@ -843,26 +845,22 @@ static int gmin_v1p8_ctrl(struct v4l2_subdev *subdev, int
on)
dev = >dev;
- if (v1p8_gpio == V1P8_GPIO_UNSET) {
- v1p8_gpio = gmin_get_var_int(dev, true,
-"V1P8GPIO", V1P8_GPIO_NONE);
- if (v1p8_gpio != V1P8_GPIO_NONE) {
- pr_info("atomisp_gmin_platform: 1.8v power on GPIO
%d\n",
- v1p8_gpio);
- ret = gpio_request(v1p8_gpio, "camera_v1p8_en");
- if (!ret)
- ret = gpio_direction_output(v1p8_gpio, 0);
- if (ret)
- pr_err("V1P8 GPIO initialization failed\n");
- }
+ if (gs->v1p8_gpio >= 0) {
+ pr_info("atomisp_gmin_platform: 1.8v power on GPIO %d\n",
+ gs->v1p8_gpio);
+ ret = gpio_request(gs->v1p8_gpio, "camera_v1p8_en");
+ if (!ret)
+ ret = gpio_direction_output(gs->v1p8_gpio, 0);
+ if (ret)
+ pr_err("V1P8 GPIO initialization failed\n");
}
if (!gs || gs->v1p8_on == on)
return 0;
gs->v1p8_on = on;
- if (v1p8_gpio >= 0)
- gpio_set_value(v1p8_gpio, on);
+ if (gs->v1p8_gpio >= 0)
+ gpio_set_value(gs->v1p8_gpio, on);
if (gs->v1p8_reg) {
regulator_set_voltage(gs->v1p8_reg, 180, 180);
@@ -905,26 +903,22 @@ static int gmin_v2p8_ctrl(struct v4l2_subdev *subdev, int
on)
dev = >dev;
- if (v2p8_gpio == V2P8_GPIO_UNSET) {
- v2p8_gpio = gmin_get_var_int(dev, true,
-"V2P8GPIO", V2P8_GPIO_NONE);
- if (v2p8_gpio != V2P8_GPIO_NONE) {
- pr_info("atomisp_gmin_platform: 2.8v power on GPIO
%d\n",
- v2p8_gpio);
- ret = gpio_request(v2p8_gpio, "camera_v2p8");
- if (!ret)
- ret = gpio_direction_output(v2p8_gpio, 0);
-
[PATCH 1/7] media: atomisp: reorganize the code under gmin_subdev_add()
The gmin_subdev_add() currently doesn't use ACPI device
power management. In order to prepare for adding support
for it, let's shift some things, placing the PM-related
stuff at the end of the probing logic.
Let's also store the current gs on a temporary var, in
order to simplify the source code.
Signed-off-by: Mauro Carvalho Chehab
---
.../media/atomisp/pci/atomisp_gmin_platform.c | 146 +-
1 file changed, 73 insertions(+), 73 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
index 4aebc7cd22d9..74331c4467bd 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c
@@ -447,6 +447,7 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
{
struct i2c_client *power = NULL, *client = v4l2_get_subdevdata(subdev);
struct acpi_device *adev;
+ struct gmin_subdev *gs;
acpi_handle handle;
struct device *dev;
int i, ret, clock_num;
@@ -457,16 +458,52 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
dev = >dev;
handle = ACPI_HANDLE(dev);
-
- // FIXME: may need to release resources allocated by
acpi_bus_get_device()
- if (!handle || acpi_bus_get_device(handle, )) {
- dev_err(dev, "Error could not get ACPI device\n");
- return NULL;
- }
+ adev = ACPI_COMPANION(>dev);
dev_info(>dev, "%s: ACPI detected it on bus ID=%s, HID=%s\n",
__func__, acpi_device_bid(adev), acpi_device_hid(adev));
+ for (i = 0; i < MAX_SUBDEVS && gmin_subdevs[i].subdev; i++)
+ ;
+ if (i >= MAX_SUBDEVS)
+ return NULL;
+
+ gs = _subdevs[i];
+ gs->subdev = subdev;
+
+ /*
+* FIXME:
+* WA:CHT requires XTAL clock as PLL is not stable.
+*
+* However, such data doesn't seem to be present at the _DSM
+* table under the GUID dc2f6c4f-045b-4f1d-97b9-882a6860a4be.
+* So, let's change the default according with the ISP version,
+* but allowing it to be overridden by BIOS or by DMI match tables.
+*/
+ if (IS_ISP2401)
+ gs->clock_src = VLV2_CLK_XTAL_25_0MHz;
+ else
+ gs->clock_src = VLV2_CLK_PLL_19P2MHZ;
+
+ gs->clock_src = gmin_get_var_int(dev, false, "ClkSrc",
+gs->clock_src);
+
+ gs->csi_port = gmin_get_var_int(dev, false, "CsiPort", 0);
+ gs->csi_lanes = gmin_get_var_int(dev, false, "CsiLanes", 1);
+
+ gs->gpio0 = gpiod_get_index(dev, NULL, 0, GPIOD_OUT_LOW);
+ if (IS_ERR(gs->gpio0))
+ gs->gpio0 = NULL;
+
+ gs->gpio1 = gpiod_get_index(dev, NULL, 1, GPIOD_OUT_LOW);
+ if (IS_ERR(gs->gpio1))
+ gs->gpio1 = NULL;
+
+ /*
+* FIXME: the code below doesn't rely on ACPI device_pm.c code to
+* set clocks and do power management.
+*/
+
if (!pmic_id) {
if (gmin_i2c_dev_exists(dev, PMIC_ACPI_TI, ))
pmic_id = PMIC_TI;
@@ -478,13 +515,8 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
pmic_id = PMIC_REGULATOR;
}
- for (i = 0; i < MAX_SUBDEVS && gmin_subdevs[i].subdev; i++)
- ;
- if (i >= MAX_SUBDEVS)
- return NULL;
-
if (power) {
- gmin_subdevs[i].pwm_i2c_addr = power->addr;
+ gs->pwm_i2c_addr = power->addr;
dev_info(dev,
"gmin: power management provided via %s (i2c addr
0x%02x)\n",
pmic_name[pmic_id], power->addr);
@@ -493,31 +525,7 @@ static struct gmin_subdev *gmin_subdev_add(struct
v4l2_subdev *subdev)
pmic_name[pmic_id]);
}
- gmin_subdevs[i].subdev = subdev;
-
/*
-* FIXME:
-* WA:CHT requires XTAL clock as PLL is not stable.
-*
-* However, such data doesn't seem to be present at the _DSM
-* table under the GUID dc2f6c4f-045b-4f1d-97b9-882a6860a4be.
-* So, let's change the default according with the ISP version,
-* but allowing it to be overridden by BIOS or by DMI match tables.
-*/
- if (IS_ISP2401)
- gmin_subdevs[i].clock_src = VLV2_CLK_XTAL_25_0MHz;
- else
- gmin_subdevs[i].clock_src = VLV2_CLK_PLL_19P2MHZ;
-
- gmin_subdevs[i].clock_src = gmin_get_var_int(dev, false, "ClkSrc",
-gmin_subdevs[i].clock_src);
-
- gmin_subdevs[i].csi_port = gmin_get_var_int(dev, false, "CsiPort", 0);
- gmin_subdevs[i].csi_lanes = gmin_get_var_int(dev, false, "CsiLanes", 1);
-
- /*
-* FIXME:
-*
* According with
Re: [PATCH v7 00/17] wilc1000: move out of staging
On Fri, Jun 26, 2020 at 08:34:48AM +0300, Kalle Valo wrote: > Greg KH writes: > > > On Wed, Jun 24, 2020 at 12:49:24PM +0300, Kalle Valo wrote: > >> Greg KH writes: > >> > >> > On Wed, Jun 24, 2020 at 11:50:07AM +0300, Kalle Valo wrote: > >> >> writes: > >> >> > >> >> > From: Ajay Singh > >> >> > > >> >> > This patch series is to review and move wilc1000 driver out of > >> >> > staging. > >> >> > Most of the review comments received in [1] & [2] are addressed in the > >> >> > latest code. > >> >> > Please review and provide your inputs. > >> >> > > >> >> > [1]. > >> >> > https://lore.kernel.org/linux-wireless/1537957525-11467-1-git-send-email-ajay.kat...@microchip.com/ > >> >> > [2]. > >> >> > https://lore.kernel.org/linux-wireless/1562896697-8002-1-git-send-email-ajay.kat...@microchip.com/ > >> >> > > >> >> > Changes since v6: > >> >> > - added Reviewed-by tag received for DT binding document patch > >> >> > earlier. > >> >> >* > >> >> > https://lore.kernel.org/linux-wireless/20200405013235.GA24105@bogus > >> >> > - merged latest driver and included --base commit as suggested. > >> >> > >> >> Greg, in preparation for moving the driver to drivers/net/wireless can I > >> >> ask you to not to take wilc1000 patches for the time being? I think that > >> >> way it would be easier to move the driver between trees if there are no > >> >> changes after v5.8-rc1. Or is there a better way handle the move? > >> > > >> > The best way is for there to be a series of patches that just adds the > >> > driver to the "real" part of the tree, and when that is merged, let me > >> > know and I will just delete the driver version in the staging tree. > >> > > >> > Does that work for you? > >> > >> It would be fine for me but won't that approach break the build (eg. > >> allyesconfig) due to two duplicate versions of the same driver in > >> wireless-drivers-next? > > > > For maybe one day, yes, but that's all. > > > >> What I was thinking that Ajay would create a patch moving the driver > >> from drivers/staging/wilc1000 to > >> drivers/net/wireless/microchip/wilc1000. Using 'git mv' and 'git > >> format-patch --find-renames' the patch should be really small, mostly > >> just renames and small changes to Kconfig, Makefile and MAINTAINERS > >> files. But this of course would require that there are no wilc1000 > >> patches in your tree until you get the driver move commit during the > >> next merge window, otherwise we would see conflicts between staging-next > >> and wireless-drivers-next. > >> > >> But I don't have any strong opinions, whatever is easiest for everyone :) > > > > It's kind of hard to review patches that do moves, but if you all want > > to do that, that's fine with me. > > Actually we have been reviewing the driver with full diffs, one file per > patch style[1], so I think everyone are happy. At least I have not heard > any complaints. > > And Ajay already submitted that the simple rename patch proposed, thanks > Ajay! > > https://patchwork.kernel.org/patch/11625025/ > > And indeed the patch is simple as it can get. So Greg, if it's ok for > you I would like to apply that simple patch to wireless-drivers-next. > > > Note, I can't guarantee that I'll not take any wilc1000 patches, I'll > > probably forget, but git mv will handle all of that just fine. > > Good point. To be on the safe side one option is that if I create a > topic branch for this simple patch and use v5.8-rc1 as the baseline. > Then I would pull the topic branch to wireless-drivers-next and you > could pull it to staging-next. That way you would not have wilc1000 in > your tree anymore and no accidental submission or commits either :) What > do you think? That sounds great, I will be happy to pull such a branch. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 4/4] media: staging: tegra-vde: Power-cycle hardware on probe
26.06.2020 10:48, Thierry Reding пишет: > On Wed, Jun 24, 2020 at 06:08:47PM +0300, Dmitry Osipenko wrote: >> VDE partition is left turned ON after bootloader on most devices, hence >> let's ensure that it's turned OFF in order to lower power leakage while >> hardware is idling by turning it ON and OFF during of the driver's probe. >> >> Signed-off-by: Dmitry Osipenko >> --- >> drivers/staging/media/tegra-vde/vde.c | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/drivers/staging/media/tegra-vde/vde.c >> b/drivers/staging/media/tegra-vde/vde.c >> index b64e35b86fb4..3be96c36bf43 100644 >> --- a/drivers/staging/media/tegra-vde/vde.c >> +++ b/drivers/staging/media/tegra-vde/vde.c >> @@ -1068,6 +1068,14 @@ static int tegra_vde_probe(struct platform_device >> *pdev) >> pm_runtime_use_autosuspend(dev); >> pm_runtime_set_autosuspend_delay(dev, 300); >> >> +/* >> + * VDE partition may be left ON after bootloader, hence let's >> + * power-cycle it in order to put hardware into a predictable lower >> + * power state. >> + */ >> +pm_runtime_get_sync(dev); >> +pm_runtime_put(dev); >> + >> return 0; >> >> err_deinit_iommu: > > Shouldn't this happen automatically? My understanding is that power > domains are turned on automatically before ->probe() and then unless a > runtime PM reference is taken during ->probe() it will get turned off > again after ->probe()? Older Tegra SoCs haven't been converted to use the generic power-domain API and today's VDE driver supports only T20 and T30 SoCs. > Is that not happening? Is auto-suspend perhaps getting in the way > somehow? We're manually toggling the PD using legacy Tegra-PD API in the driver's RPM callbacks, that's why the RPM needs to be toggled manually as well. Perhaps this hunk could be removed if older Tergas would get a genpd support. I guess it shouldn't be difficult to implement the genpd support, but then there will be a compatibility trouble with older DTs, so perhaps it's not really worth the effort. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/4] Tegra Video Decoder driver power management corrections
26.06.2020 09:58, Hans Verkuil пишет: > On 26/06/2020 02:17, Dmitry Osipenko wrote: >> 24.06.2020 18:23, Dmitry Osipenko пишет: >>> 24.06.2020 18:16, Hans Verkuil пишет: On 24/06/2020 17:08, Dmitry Osipenko wrote: > Hello, > > This small series addresses a Runtime PM issue that was discovered during > of Tegra VI driver reviewing by balancing RPM usage count on RPM resume > failure. Secondly it fixes reboot on some Tegra devices due to bootloader > expecting VDE power partition to be ON at the boot time, which wasn't > happening in case of a warm re-booting (i.e. by PMC resetting). Can you rebase this on top of the media_tree master branch? I think a variant of patch 1 has already been applied. I found a mail today where you mentioned that you preferred your version (it looks like I missed that) so you'll need to rework patch 1. >>> >>> Hello Hans, >>> >>> I'll take a look at what patches has been applied, my bad for sending >>> the v2 too late. Thank you for the heads up! >>> >> >> I tested the already-applied variant of the patch 1 and it has the same >> behaviour as my variant, so it's okay. >> >> Would you want me to send a v3 without the conflicting patch 1 or you >> could apply the patches 2-4 from this series? >> > > I'll mark 1/4 as superseded and will apply patches 2-4. No need for you > to do anything. Thank you! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: qlge: fix else after return or break
On Thu, Jun 25, 2020 at 03:13:14PM -0700, Joe Perches wrote:
On Fri, 2020-06-26 at 05:57 +0800, Coiby Xu wrote:
Remove unnecessary elses after return or break.
unrelated trivia:
diff --git a/drivers/staging/qlge/qlge_dbg.c b/drivers/staging/qlge/qlge_dbg.c
[]
@@ -1391,12 +1391,11 @@ static void ql_dump_cam_entries(struct ql_adapter *qdev)
pr_err("%s: Failed read of mac index register\n",
__func__);
return;
- } else {
- if (value[0])
- pr_err("%s: CAM index %d CAM Lookup Lower =
0x%.08x:%.08x, Output = 0x%.08x\n",
- qdev->ndev->name, i, value[1], value[0],
- value[2]);
looks like all of these could use netdev_err
netdev_err(qdev, "etc...",
i, value[1], value[0], value[2]);
etc...
Interestingly, scripts/checkpatch.pl couldn't detect this problem.
I once used printk(KERN_ALERT...) and the script would properly warn me
that,
WARNING: Prefer [subsystem eg: netdev]_alert([subsystem]dev, ... then
dev_alert(dev, ... then pr_alert(... to printk(KERN_ALERT .
I'll fix this issue when sending another version of the patches. Thank
you for the reminding!
--
Best regards,
Coiby
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: qlge: fix else after return or break
On Fri, Jun 26, 2020 at 11:34:36AM +0300, Dan Carpenter wrote:
On Fri, Jun 26, 2020 at 05:57:55AM +0800, Coiby Xu wrote:
@@ -1404,11 +1403,10 @@ static void ql_dump_cam_entries(struct ql_adapter *qdev)
pr_err("%s: Failed read of mac index register\n",
__func__);
return;
^^
- } else {
- if (value[0])
- pr_err("%s: MCAST index %d CAM Lookup Lower =
0x%.08x:%.08x\n",
- qdev->ndev->name, i, value[1], value[0]);
}
+ if (value[0])
+ pr_err("%s: MCAST index %d CAM Lookup Lower =
0x%.08x:%.08x\n",
+ qdev->ndev->name, i, value[1], value[0]);
}
ql_sem_unlock(qdev, SEM_MAC_ADDR_MASK);
^^^
}
@@ -1427,11 +1425,10 @@ void ql_dump_routing_entries(struct ql_adapter *qdev)
pr_err("%s: Failed read of routing index register\n",
__func__);
return;
^^
- } else {
- if (value)
- pr_err("%s: Routing Mask %d = 0x%.08x\n",
- qdev->ndev->name, i, value);
}
+ if (value)
+ pr_err("%s: Routing Mask %d = 0x%.08x\n",
+ qdev->ndev->name, i, value);
}
ql_sem_unlock(qdev, SEM_RT_IDX_MASK);
}
This is not caused by your patch, but in these two functions we return
without dropping the lock. There may be other places as well, but these
are the two I can see without leaving my email client.
Do you think you could fix that before we forget? Just change the
return to a break to fix the bug.
Sure, I'll address this issue in the next series
of patches. Thank you for bringing up this issue!
--
Best regards,
Coiby
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] wilc1000: move wilc driver out of staging
On 26/06/20 11:21 am, Kalle Valo wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > writes: > >> From: Ajay Singh >> >> WILC1000 is an IEEE 802.11 b/g/n IoT link controller module. The >> WILC1000 connects to Microchip AVR/SMART MCUs, SMART MPUs, and other >> processors with minimal resource requirements with a simple >> SPI/SDIO-to-Wi-Fi interface. >> >> WILC1000 driver has been part of staging for few years. With >> contributions from the community, it has improved significantly. Full >> driver review has helped in achieving the current state. >> The details for those reviews are captured in 1 & 2. >> >> [1]. >> https://lore.kernel.org/linux-wireless/1537957525-11467-1-git-send-email-ajay.kat...@microchip.com/ >> [2]. >> https://lore.kernel.org/linux-wireless/1562896697-8002-1-git-send-email-ajay.kat...@microchip.com/ >> >> Signed-off-by: Ajay Singh > > [...] > >> --- a/drivers/net/wireless/Kconfig >> +++ b/drivers/net/wireless/Kconfig >> @@ -47,6 +47,7 @@ source "drivers/net/wireless/st/Kconfig" >> source "drivers/net/wireless/ti/Kconfig" >> source "drivers/net/wireless/zydas/Kconfig" >> source "drivers/net/wireless/quantenna/Kconfig" >> +source "drivers/net/wireless/microchip/Kconfig" > > This should be in alphabetical order. > >> --- a/drivers/net/wireless/Makefile >> +++ b/drivers/net/wireless/Makefile >> @@ -19,6 +19,7 @@ obj-$(CONFIG_WLAN_VENDOR_ST) += st/ >> obj-$(CONFIG_WLAN_VENDOR_TI) += ti/ >> obj-$(CONFIG_WLAN_VENDOR_ZYDAS) += zydas/ >> obj-$(CONFIG_WLAN_VENDOR_QUANTENNA) += quantenna/ >> +obj-$(CONFIG_WLAN_VENDOR_MICROCHIP) += microchip/ > > And this as well. > > I fixed these in the topic branch, please double check: Thanks Kalle. I just checked the patch and it looks good. Regards, Ajay > > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?h=wilc1000-move-out-of-staging=5625f965d7644b4dc6a71d74021cfe093ad34eea > > I have not pulled that branch yet into master so we can make changes > still.> > -- > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Project Financing / Loan. 11
Hello, I am the investment officer of an investment company who are ready to fund projects in the form of debt finance. The company grant loan to both corporate and private entities at a low interest rate of 3% ROI per annual. The terms are very flexible and interesting. Kindly revert back if you have projects that needs funding for further discussion and negotiation with any of the companies that will be interested to fund your project. Regards, Mark Johnson ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: qlge: fix else after return or break
On Fri, Jun 26, 2020 at 05:57:55AM +0800, Coiby Xu wrote:
> @@ -1404,11 +1403,10 @@ static void ql_dump_cam_entries(struct ql_adapter
> *qdev)
> pr_err("%s: Failed read of mac index register\n",
> __func__);
> return;
^^
> - } else {
> - if (value[0])
> - pr_err("%s: MCAST index %d CAM Lookup Lower =
> 0x%.08x:%.08x\n",
> -qdev->ndev->name, i, value[1], value[0]);
> }
> + if (value[0])
> + pr_err("%s: MCAST index %d CAM Lookup Lower =
> 0x%.08x:%.08x\n",
> +qdev->ndev->name, i, value[1], value[0]);
> }
> ql_sem_unlock(qdev, SEM_MAC_ADDR_MASK);
^^^
> }
> @@ -1427,11 +1425,10 @@ void ql_dump_routing_entries(struct ql_adapter *qdev)
> pr_err("%s: Failed read of routing index register\n",
> __func__);
> return;
^^
> - } else {
> - if (value)
> - pr_err("%s: Routing Mask %d = 0x%.08x\n",
> -qdev->ndev->name, i, value);
> }
> + if (value)
> + pr_err("%s: Routing Mask %d = 0x%.08x\n",
> +qdev->ndev->name, i, value);
> }
> ql_sem_unlock(qdev, SEM_RT_IDX_MASK);
> }
This is not caused by your patch, but in these two functions we return
without dropping the lock. There may be other places as well, but these
are the two I can see without leaving my email client.
Do you think you could fix that before we forget? Just change the
return to a break to fix the bug.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 4/4] media: staging: tegra-vde: Power-cycle hardware on probe
On Wed, Jun 24, 2020 at 06:08:47PM +0300, Dmitry Osipenko wrote: > VDE partition is left turned ON after bootloader on most devices, hence > let's ensure that it's turned OFF in order to lower power leakage while > hardware is idling by turning it ON and OFF during of the driver's probe. > > Signed-off-by: Dmitry Osipenko > --- > drivers/staging/media/tegra-vde/vde.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/staging/media/tegra-vde/vde.c > b/drivers/staging/media/tegra-vde/vde.c > index b64e35b86fb4..3be96c36bf43 100644 > --- a/drivers/staging/media/tegra-vde/vde.c > +++ b/drivers/staging/media/tegra-vde/vde.c > @@ -1068,6 +1068,14 @@ static int tegra_vde_probe(struct platform_device > *pdev) > pm_runtime_use_autosuspend(dev); > pm_runtime_set_autosuspend_delay(dev, 300); > > + /* > + * VDE partition may be left ON after bootloader, hence let's > + * power-cycle it in order to put hardware into a predictable lower > + * power state. > + */ > + pm_runtime_get_sync(dev); > + pm_runtime_put(dev); > + > return 0; > > err_deinit_iommu: Shouldn't this happen automatically? My understanding is that power domains are turned on automatically before ->probe() and then unless a runtime PM reference is taken during ->probe() it will get turned off again after ->probe()? Is that not happening? Is auto-suspend perhaps getting in the way somehow? Thierry signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/4] media: staging: tegra-vde: Runtime PM is always available on Tegra
On Wed, Jun 24, 2020 at 06:08:45PM +0300, Dmitry Osipenko wrote:
> Runtime PM is always available on Tegra nowadays since commit 40b2bb1b132a
> ("ARM: tegra: enforce PM requirement"), hence the case of unavailable RPM
> doesn't need to be handled.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/staging/media/tegra-vde/vde.c | 16
> 1 file changed, 16 deletions(-)
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 3/4] media: staging: tegra-vde: Turn ON power domain on shutdown
On Wed, Jun 24, 2020 at 06:08:46PM +0300, Dmitry Osipenko wrote: > On some devices bootloader isn't ready to a clamped VDE power, and thus, > machine hangs on a warm reboot (CPU reset). The VDE power partition is > turned ON by default on a cold boot, hence VDE driver should keep power > partition enabled on system's reboot too. This fixes hang on a warm reboot > on a Tegra20 Acer A500 device, which is handy if Embedded Controller > driver is unavailable, i.e. cold reboot can't be performed. > > Signed-off-by: Dmitry Osipenko > --- > drivers/staging/media/tegra-vde/vde.c | 19 +++ > 1 file changed, 19 insertions(+) Unfortunate that we have to do this, but looks fine: Acked-by: Thierry Reding signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: media: soc_camera: Adding parentheses to macro defination at line 241, Clearing alignment issues at lines 410 and 1270, fixing return values at EPOLLERR
The soc_camera driver obsolete and depends on BROKEN. And in fact, I'm
working on removing it. So I'll drop this patch for those reasons.
Regards,
Hans
On 25/06/2020 17:35, B K Karthik wrote:
> staging: media: soc_camera: soc_camera.c: Clearing coding-style problem
> "Macros with complex values should be enclosed in parentheses" in line 241 by
> adding parentheses.
> staging: media: soc_camera: soc_camera.c: Clearing coding-style problem
> "Alignment should match open parenthesis" by adding tab spaces in line 410.
> staging: media: soc_camera: soc_camera.c: Clearing coding-style problem
> "return of an errno should typically be negative" by adding a "-" in front of
> EPOLLER in line 812.
> staging: media: soc_camera: soc_camera.c: Clearing coding-style problem
> "Alignment should match open parenthesis" by adding tab spaces in line 1270.
>
> Signed-off-by: B K Karthik
> ---
> drivers/staging/media/soc_camera/soc_camera.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/media/soc_camera/soc_camera.c
> b/drivers/staging/media/soc_camera/soc_camera.c
> index 39f513f69b89..66a14ebd8093 100644
> --- a/drivers/staging/media/soc_camera/soc_camera.c
> +++ b/drivers/staging/media/soc_camera/soc_camera.c
> @@ -238,8 +238,8 @@ unsigned long soc_camera_apply_board_flags(struct
> soc_camera_subdev_desc *ssdd,
> }
> EXPORT_SYMBOL(soc_camera_apply_board_flags);
>
> -#define pixfmtstr(x) (x) & 0xff, ((x) >> 8) & 0xff, ((x) >> 16) & 0xff, \
> - ((x) >> 24) & 0xff
> +#define pixfmtstr(x) ((x) & 0xff, ((x) >> 8) & 0xff, ((x) >> 16) & 0xff, \
> + ((x) >> 24) & 0xff)
>
> static int soc_camera_try_fmt(struct soc_camera_device *icd,
> struct v4l2_format *f)
> @@ -407,7 +407,7 @@ static int soc_camera_dqbuf(struct file *file, void *priv,
> }
>
> static int soc_camera_create_bufs(struct file *file, void *priv,
> - struct v4l2_create_buffers *create)
> + struct v4l2_create_buffers *create)
> {
> struct soc_camera_device *icd = file->private_data;
> int ret;
> @@ -806,10 +806,10 @@ static __poll_t soc_camera_poll(struct file *file,
> poll_table *pt)
> {
> struct soc_camera_device *icd = file->private_data;
> struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
> - __poll_t res = EPOLLERR;
> + __poll_t res = -EPOLLERR;
>
> if (icd->streamer != file)
> - return EPOLLERR;
> + return -EPOLLERR;
>
> mutex_lock(>host_lock);
> res = ici->ops->poll(file, pt);
> @@ -1267,7 +1267,7 @@ static int soc_camera_i2c_init(struct soc_camera_device
> *icd,
> }
>
> subdev = v4l2_i2c_new_subdev_board(>v4l2_dev, adap,
> - shd->board_info, NULL);
> + shd->board_info, NULL);
> if (!subdev) {
> ret = -ENODEV;
> goto ei2cnd;
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/4] Tegra Video Decoder driver power management corrections
On 26/06/2020 02:17, Dmitry Osipenko wrote: > 24.06.2020 18:23, Dmitry Osipenko пишет: >> 24.06.2020 18:16, Hans Verkuil пишет: >>> On 24/06/2020 17:08, Dmitry Osipenko wrote: Hello, This small series addresses a Runtime PM issue that was discovered during of Tegra VI driver reviewing by balancing RPM usage count on RPM resume failure. Secondly it fixes reboot on some Tegra devices due to bootloader expecting VDE power partition to be ON at the boot time, which wasn't happening in case of a warm re-booting (i.e. by PMC resetting). >>> >>> Can you rebase this on top of the media_tree master branch? I think a >>> variant >>> of patch 1 has already been applied. I found a mail today where you >>> mentioned >>> that you preferred your version (it looks like I missed that) so you'll >>> need to >>> rework patch 1. >> >> Hello Hans, >> >> I'll take a look at what patches has been applied, my bad for sending >> the v2 too late. Thank you for the heads up! >> > > I tested the already-applied variant of the patch 1 and it has the same > behaviour as my variant, so it's okay. > > Would you want me to send a v3 without the conflicting patch 1 or you > could apply the patches 2-4 from this series? > I'll mark 1/4 as superseded and will apply patches 2-4. No need for you to do anything. Regards, Hans ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
