[PATCH 1/2] staging: rtl8712u: Remove dummy reset-resume callback
An USB wireless dongle uses rtl8712u stops working after system
suspend/resume.
When a USB device lost its power during suspend, the USB core knows the
power was lost and a reset-resume or a re-probe is required. But rtl8712u
provides a dummy reset-resume callback, which gets called and renders
the device dead after resume.
So remove the reset-resume call back, if power was lost during suspend,
let the USB core unbind and probe the device to solve the issue.
Signed-off-by: Kai-Heng Feng
---
drivers/staging/rtl8712/usb_intf.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/staging/rtl8712/usb_intf.c
b/drivers/staging/rtl8712/usb_intf.c
index 92d75d7c51ae..9cf2a798cfca 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -232,13 +232,6 @@ static int r871x_resume(struct usb_interface *pusb_intf)
rtl871x_intf_resume(padapter);
return 0;
}
-
-static int r871x_reset_resume(struct usb_interface *pusb_intf)
-{
- /* dummy routine */
- return 0;
-}
-
#endif
static struct drv_priv drvpriv = {
@@ -249,7 +242,6 @@ static struct drv_priv drvpriv = {
#ifdef CONFIG_PM
.r871xu_drv.suspend = r871x_suspend,
.r871xu_drv.resume = r871x_resume,
- .r871xu_drv.reset_resume = r871x_reset_resume,
#endif
};
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging: rtl8712u: Fix suspend and resume callbacks
When system resume and the rtl8712u dongle didn't lose its power, it
doesn't work quite right:
[ 146.844241] r8712u 2-3:1.0 wlp0s4f1u3: Unable to resume
...
[ 154.029573] r8712u 2-3:1.0 wlp0s4f1u3: In r8711_wx_set_scan: bDriverStopped=1
The !netif_running() check in PM callbacks aren't correct because
rtl8712u doesn't support runtime suspend, so the when the PM ops get
called, it's system suspend or system resume, hence we want to "stop
everthing" or "resume everything".
The NULL check on pnetdev is also redundant, the only place pnetdev can
become NULL is the disconnect callback, which is mutually exclusive to
PM callbacks.
This can make rtl8712u starts working after system resume.
Signed-off-by: Kai-Heng Feng
---
drivers/staging/rtl8712/usb_intf.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/staging/rtl8712/usb_intf.c
b/drivers/staging/rtl8712/usb_intf.c
index 9cf2a798cfca..005010de9997 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -196,10 +196,6 @@ static int r871x_suspend(struct usb_interface *pusb_intf,
pm_message_t state)
struct _adapter *padapter = netdev_priv(pnetdev);
netdev_info(pnetdev, "Suspending...\n");
- if (!pnetdev || !netif_running(pnetdev)) {
- netdev_info(pnetdev, "Unable to suspend\n");
- return 0;
- }
padapter->bSuspended = true;
rtl871x_intf_stop(padapter);
if (pnetdev->netdev_ops->ndo_stop)
@@ -221,10 +217,6 @@ static int r871x_resume(struct usb_interface *pusb_intf)
struct _adapter *padapter = netdev_priv(pnetdev);
netdev_info(pnetdev, "Resuming...\n");
- if (!pnetdev || !netif_running(pnetdev)) {
- netdev_info(pnetdev, "Unable to resume\n");
- return 0;
- }
netif_device_attach(pnetdev);
if (pnetdev->netdev_ops->ndo_open)
pnetdev->netdev_ops->ndo_open(pnetdev);
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
ipu3-imgu 0000:00:05.0: required queues are disabled
Hi, We have a bug report [1] that the ipu3 doesn’t work. Does ipu3 need special userspace to work? [1] https://bugs.launchpad.net/bugs/1812114 Kai-Heng ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: ipu3-imgu 0000:00:05.0: required queues are disabled
Hi Kieran, > On Jan 28, 2019, at 4:48 PM, Kieran Bingham > wrote: > > Hi Kai-Heng, > > On 27/01/2019 05:56, Kai-Heng Feng wrote: >> Hi, >> >> We have a bug report [1] that the ipu3 doesn’t work. >> Does ipu3 need special userspace to work? > > Yes, it will need further userspace support to configure the pipeline, > and to provide 3A algorithms for white balance, focus, and exposure > times to the sensor. > > We are developing a stack called libcamera [0] to support this, but it's > still in active development and not yet ready for use. Fortunately > however, IPU3 is one of our primary initial targets. Thanks for the info. > > [0] https://www.libcamera.org/ > >> [1] https://bugs.launchpad.net/bugs/1812114 > > I have reported similar information to the launchpad bug entry. > > It might help if we can get hold of a Dell 7275 sometime although I > think Mauro at least has one ? > > If this is a priority for Canonical, please contact us directly. Not really, just raise issues from Launchpad to appropriate mailing list. Kai-Heng > >> Kai-Heng > -- > Regards > > Kieran ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: Remove debugging information exposed via procfs
The procfs provides many useful information for debugging, but it may be
too much for normal usage, routines like proc_get_sec_info() reports
various security related information.
So let's remove it.
Signed-off-by: Kai-Heng Feng
---
drivers/staging/rtl8723bs/Makefile|1 -
drivers/staging/rtl8723bs/core/rtw_cmd.c |5 -
drivers/staging/rtl8723bs/core/rtw_debug.c| 1307 -
drivers/staging/rtl8723bs/include/autoconf.h |4 -
drivers/staging/rtl8723bs/include/drv_types.h |2 -
.../staging/rtl8723bs/include/osdep_intf.h|2 -
drivers/staging/rtl8723bs/include/rtw_debug.h | 77 -
drivers/staging/rtl8723bs/os_dep/os_intfs.c |8 -
drivers/staging/rtl8723bs/os_dep/rtw_proc.c | 779 --
drivers/staging/rtl8723bs/os_dep/rtw_proc.h | 37 -
drivers/staging/rtl8723bs/os_dep/sdio_intf.c |3 -
11 files changed, 2225 deletions(-)
delete mode 100644 drivers/staging/rtl8723bs/os_dep/rtw_proc.c
delete mode 100644 drivers/staging/rtl8723bs/os_dep/rtw_proc.h
diff --git a/drivers/staging/rtl8723bs/Makefile
b/drivers/staging/rtl8723bs/Makefile
index a12cf8dd8ed9..dfe410283ca0 100644
--- a/drivers/staging/rtl8723bs/Makefile
+++ b/drivers/staging/rtl8723bs/Makefile
@@ -60,7 +60,6 @@ r8723bs-y = \
os_dep/osdep_service.o \
os_dep/os_intfs.o \
os_dep/recv_linux.o \
- os_dep/rtw_proc.o \
os_dep/sdio_intf.o \
os_dep/sdio_ops_linux.o \
os_dep/wifi_regd.o \
diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c
b/drivers/staging/rtl8723bs/core/rtw_cmd.c
index c6565b0e502c..8d93c2f26890 100644
--- a/drivers/staging/rtl8723bs/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723bs/core/rtw_cmd.c
@@ -1817,11 +1817,6 @@ static void rtw_btinfo_hdl(struct adapter *adapter, u8
*buf, u16 buf_len)
len = info->len;
}
-/* define DBG_PROC_SET_BTINFO_EVT */
-#ifdef DBG_PROC_SET_BTINFO_EVT
- btinfo_evt_dump(RTW_DBGDUMP, info);
-#endif
-
/* transform BT-FW btinfo to WiFI-FW C2H format and notify */
if (cmd_idx == BTINFO_WIFI_FETCH)
buf[1] = 0;
diff --git a/drivers/staging/rtl8723bs/core/rtw_debug.c
b/drivers/staging/rtl8723bs/core/rtw_debug.c
index 695a85999270..c48a8b80af4c 100644
--- a/drivers/staging/rtl8723bs/core/rtw_debug.c
+++ b/drivers/staging/rtl8723bs/core/rtw_debug.c
@@ -132,1310 +132,3 @@ void rf_reg_dump(void *sel, struct adapter *adapter)
}
}
}
-
-#ifdef PROC_DEBUG
-ssize_t proc_set_write_reg(struct file *file, const char __user *buffer,
size_t count, loff_t *pos, void *data)
-{
- struct net_device *dev = data;
- struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
- char tmp[32];
- u32 addr, val, len;
-
- if (count < 3) {
- DBG_871X("argument size is less than 3\n");
- return -EFAULT;
- }
-
- if (buffer && !copy_from_user(tmp, buffer, sizeof(tmp))) {
-
- int num = sscanf(tmp, "%x %x %x", &addr, &val, &len);
-
- if (num != 3) {
- DBG_871X("invalid write_reg parameter!\n");
- return count;
- }
-
- switch (len) {
- case 1:
- rtw_write8(padapter, addr, (u8)val);
- break;
- case 2:
- rtw_write16(padapter, addr, (u16)val);
- break;
- case 4:
- rtw_write32(padapter, addr, val);
- break;
- default:
- DBG_871X("error write length =%d", len);
- break;
- }
-
- }
-
- return count;
-
-}
-
-static u32 proc_get_read_addr = 0x;
-static u32 proc_get_read_len = 0x4;
-
-int proc_get_read_reg(struct seq_file *m, void *v)
-{
- struct net_device *dev = m->private;
- struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
-
- if (proc_get_read_addr == 0x) {
- DBG_871X_SEL_NL(m, "address not initialized\n");
- return 0;
- }
-
- switch (proc_get_read_len) {
- case 1:
- DBG_871X_SEL_NL(m, "rtw_read8(0x%x) = 0x%x\n",
proc_get_read_addr, rtw_read8(padapter, proc_get_read_addr));
- break;
- case 2:
- DBG_871X_SEL_NL(m, "rtw_read16(0x%x) = 0x%x\n",
proc_get_read_addr, rtw_read16(padapter, proc_get_read_addr));
- break;
- case 4:
- DBG_871X_SEL_NL(m, "rtw_read32(0x%x) = 0x%x\n",
proc_get_read_addr, rtw_read32(padapter, proc_get_read_addr));
- break;
- default:
- DBG_871X_SEL_NL(m, "error read length =%d\n",
proc_get_read_len
Re: [PATCH] staging: Add rtl8821ce PCIe WiFi driver
at 19:40, Greg KH wrote: On Wed, May 15, 2019 at 07:24:01PM +0800, Kai-Heng Feng wrote: The rtl8821ce can be found on many HP and Lenovo laptops. Users have been using out-of-tree module for a while, The new Realtek WiFi driver, rtw88, will support rtl8821ce in 2020 or later. Where is that driver, and why is it going to take so long to get merged? rtw88 is in 5.2 now, but it doesn’t support 8821ce yet. They plan to add the support in 2020. 296 files changed, 206166 insertions(+) Ugh, why do we keep having to add the whole mess for every single one of these devices? Because Realtek devices are unfortunately ubiquitous so the support is better come from kernel. Why can't we just have a real driver now? It doesn’t support rtl8821ce yet. Kai-Heng thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Add rtl8821ce PCIe WiFi driver
at 20:33, Greg KH wrote: On Wed, May 15, 2019 at 07:54:58PM +0800, Kai-Heng Feng wrote: at 19:40, Greg KH wrote: On Wed, May 15, 2019 at 07:24:01PM +0800, Kai-Heng Feng wrote: The rtl8821ce can be found on many HP and Lenovo laptops. Users have been using out-of-tree module for a while, The new Realtek WiFi driver, rtw88, will support rtl8821ce in 2020 or later. Where is that driver, and why is it going to take so long to get merged? rtw88 is in 5.2 now, but it doesn’t support 8821ce yet. They plan to add the support in 2020. Who is "they" and what is needed to support this device and why wait a full year? “They” refers to Realtek. It’s their plan so I can’t really answer that on behalf of Realtek. 296 files changed, 206166 insertions(+) Ugh, why do we keep having to add the whole mess for every single one of these devices? Because Realtek devices are unfortunately ubiquitous so the support is better come from kernel. That's not the issue here. The issue is that we keep adding the same huge driver files to the kernel tree, over and over, with no real change at all. We have seen almost all of these files in other realtek drivers, right? Yes. They use one single driver to support different SoCs, different architectures and even different OSes. That’s why it’s a mess. Why not use the ones we already have? It’s virtually impossible because Realtek’s mega wifi driver uses tons of #ifdefs, only one chip can be selected to be supported at compile time. But better yet, why not add proper support for this hardware and not use a staging driver? Realtek plans to add the support in 2020, if everything goes well. Meanwhile, many users of HP and Lenovo laptops are using out-of-tree driver, some of them are stuck to older kernels because they don’t know how to fix the driver. So I strongly think having this in kernel is beneficial to many users, even it’s only for a year. Kai-Heng thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Add rtl8821ce PCIe WiFi driver
at 00:39, Greg KH wrote: On Wed, May 15, 2019 at 09:06:44PM +0800, Kai-Heng Feng wrote: at 20:33, Greg KH wrote: On Wed, May 15, 2019 at 07:54:58PM +0800, Kai-Heng Feng wrote: at 19:40, Greg KH wrote: On Wed, May 15, 2019 at 07:24:01PM +0800, Kai-Heng Feng wrote: The rtl8821ce can be found on many HP and Lenovo laptops. Users have been using out-of-tree module for a while, The new Realtek WiFi driver, rtw88, will support rtl8821ce in 2020 or later. Where is that driver, and why is it going to take so long to get merged? rtw88 is in 5.2 now, but it doesn’t support 8821ce yet. They plan to add the support in 2020. Who is "they" and what is needed to support this device and why wait a full year? “They” refers to Realtek. It’s their plan so I can’t really answer that on behalf of Realtek. Where did they say that? Any reason their developers are not on this patch? 296 files changed, 206166 insertions(+) Ugh, why do we keep having to add the whole mess for every single one of these devices? Because Realtek devices are unfortunately ubiquitous so the support is better come from kernel. That's not the issue here. The issue is that we keep adding the same huge driver files to the kernel tree, over and over, with no real change at all. We have seen almost all of these files in other realtek drivers, right? Yes. They use one single driver to support different SoCs, different architectures and even different OSes. Well, they try to, it doesn't always work :( That’s why it’s a mess. Oh we all know why this is a mess. But they have been saying for _years_ they would clean up this mess. So push back, I'm not going to take another 200k lines for a simple wifi driver, again. Along those lines, we should probably just delete the other old realtek drivers that don't seem to be going anywhere from staging as well, because those are just confusing people. Why not use the ones we already have? It’s virtually impossible because Realtek’s mega wifi driver uses tons of #ifdefs, only one chip can be selected to be supported at compile time. That's not what I asked. I want to know why they can't just add support for their new devices to one of the many existing realtek drivers we already have. That is the simpler way, and the correct way to do this. We don't do this by adding 200k lines, again. But better yet, why not add proper support for this hardware and not use a staging driver? Realtek plans to add the support in 2020, if everything goes well. Device "goes well" please. And when in 2020? And why 2020? Why not 2022? 2024? Meanwhile, many users of HP and Lenovo laptops are using out-of-tree driver, some of them are stuck to older kernels because they don’t know how to fix the driver. So I strongly think having this in kernel is beneficial to many users, even it’s only for a year. So who is going to be responsible for "fixing the driver" for all new kernel api updates? I'm tired of seeing new developers get lost in the maze of yet-another realtek wifi driver. We've been putting up with this crud for years, and it has not gotten any better if you want to add another 200k lines for some unknown amount of time with the hope that a driver might magically show up one day. I have no idea why they haven’t made everything upstream, and I do hope they did a better job, so I don’t need to cleanup their driver and send it upstream :( So basically I can’t answer any of your questions. As Larry suggested, their driver should be hosted separately and maybe by downstream distro. Kai-Heng thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: Disable procfs debugging by default
The procfs provides many useful information for debugging, but it may be too much for normal usage, routines like proc_get_sec_info() reports various security related information. So disable it by defaultl. Signed-off-by: Kai-Heng Feng --- drivers/staging/rtl8723bs/include/autoconf.h | 4 1 file changed, 4 deletions(-) diff --git a/drivers/staging/rtl8723bs/include/autoconf.h b/drivers/staging/rtl8723bs/include/autoconf.h index 196aca3aed7b..8f4c1e734473 100644 --- a/drivers/staging/rtl8723bs/include/autoconf.h +++ b/drivers/staging/rtl8723bs/include/autoconf.h @@ -57,9 +57,5 @@ #define DBG0 /* for ODM & BTCOEX debug */ #endif /* !DEBUG */ -#ifdef CONFIG_PROC_FS -#define PROC_DEBUG -#endif - /* define DBG_XMIT_BUF */ /* define DBG_XMIT_BUF_EXT */ -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: Disable procfs debugging by default
at 15:55, Greg KH wrote: On Thu, Jul 18, 2019 at 05:25:22PM +0800, Kai-Heng Feng wrote: The procfs provides many useful information for debugging, but it may be too much for normal usage, routines like proc_get_sec_info() reports various security related information. So disable it by defaultl. Signed-off-by: Kai-Heng Feng --- drivers/staging/rtl8723bs/include/autoconf.h | 4 1 file changed, 4 deletions(-) diff --git a/drivers/staging/rtl8723bs/include/autoconf.h b/drivers/staging/rtl8723bs/include/autoconf.h index 196aca3aed7b..8f4c1e734473 100644 --- a/drivers/staging/rtl8723bs/include/autoconf.h +++ b/drivers/staging/rtl8723bs/include/autoconf.h @@ -57,9 +57,5 @@ #define DBG0 /* for ODM & BTCOEX debug */ #endif /* !DEBUG */ -#ifdef CONFIG_PROC_FS -#define PROC_DEBUG -#endif What? Why? If you are going to do this, then rip out all of the code as well. Or make it a Kconfig option? Which one do you think is better? And are you _sure_ you want to do this? Yes. The procfs of rtl8723bs is useful to Realtek to decode but not to others. Kai-Heng thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
