[PATCH] HID: Add quirk for Primax PIXART OEM mice
The PixArt OEM mice are known for disconnecting every minute in
runlevel 1 or 3 if they are not always polled. So add quirk
ALWAYS_POLL for two Primax mice as well.
0x4e22 is the Dell MS111-P and 0x4d0f is the unbranded HP Portia
mouse HP 697738-001. Both were built until approx. 2014.
Those were the standard mice from those vendors and are still
around - even as new old stock.
Reference: https://github.com/sriemer/fix-linux-mouse/issues/11
Signed-off-by: Sebastian Parschauer
CC: sta...@vger.kernel.org
---
drivers/hid/hid-ids.h| 2 ++
drivers/hid/hid-quirks.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 2114ac647bef..ed35c9a9a110 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1210,6 +1210,8 @@
#define USB_DEVICE_ID_PRIMAX_MOUSE_4D220x4d22
#define USB_DEVICE_ID_PRIMAX_KEYBOARD 0x4e05
#define USB_DEVICE_ID_PRIMAX_REZEL 0x4e72
+#define USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4D0F 0x4d0f
+#define USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4E22 0x4e22
#define USB_VENDOR_ID_RISO_KAGAKU 0x1294 /* Riso Kagaku Corp. */
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index d82e5ab48837..c85a79986b6a 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -130,6 +130,8 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_PIXART,
USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_PIXART,
USB_DEVICE_ID_PIXART_USB_OPTICAL_MOUSE), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX,
USB_DEVICE_ID_PRIMAX_MOUSE_4D22), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX,
USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4D0F), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX,
USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4E22), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_PRODIGE,
USB_DEVICE_ID_PRODIGE_CORDLESS), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_QUANTA,
USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH_3001), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_QUANTA,
USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH_3003), HID_QUIRK_NOGET },
--
2.13.7
RE: [PATCH v2 0/4] usb: chipidea: imx: add HSIC support
> > > > On 23.10.18 08:33, Peter Chen wrote: > >>> As I already posted when I was testing v1 last week, there is a > >>> problem with auto suspend with my LAN9730 chip. I thought it was a > >>> problem with the smsc95xx/usbnet driver, but I'm not so sure > >>> anymore. > >>> > >>> So I'd like to figure out if it has something to do with the HSIC > >>> patches. I hope to find some time to do some more debugging soon. > >>> When this is sorted I will append my R-b, T-b tags. > >>> > >> Thanks, Frieder > > > > The problem is in the smsc95xx driver and I already sent a fix for it. > > So the HSIC patches are ok. > > > > I have some more small suggestions for the v2 patches, I will send > > separately. Could you send a v3, then I will add my R-b and T-b tags > > to the whole series? > > Did you have some time to prepare v3 so we can move on? > Also could you please have a quick look add the devicetree changes: > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork. > kernel.org%2Fpatch%2F10646853%2Fdata=02%7C01%7Cpeter.chen%40nx > p.com%7Cd99fc15773814491afef08d64dfa0d0e%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636782133691575095sdata=369DV9jAv17iBiZVjErI > XWRp63lJKueLBkgWPOilTTw%3Dreserved=0 > Hi Schrempf, I am afraid I am a little busy with some other USB tasks, I will send v3 at next week. Peter
Re: [PATCH v2] usb: hub: add retry routine after intr URB sumbit error
Hi Oliver,
thanks for the reviews :).
On Mon, 2018-11-19 at 15:04 +0100, Oliver Neukum wrote:
> On Mo, 2018-11-19 at 15:02 +0100, Nicolas Saenz Julienne wrote:
> > +static void hub_retry_irq_urb(struct timer_list *t)
> > +{
> > + struct usb_hub *hub = from_timer(hub, t, irq_urb_retry);
> > + int status;
> > +
> > + if (hub->disconnected || hub->quiescing)
> > + return;
> > +
> > + dev_err(hub->intfdev, "retrying int urb\n");
> > + status = usb_submit_urb(hub->urb, GFP_ATOMIC);
> > + if (status && status != -ENODEV && status != -EPERM &&
> > + status != -ESHUTDOWN)
> > + mod_timer(>irq_urb_retry,
> > + jiffies + msecs_to_jiffies(MSEC_PER_SEC));
> > +}
> > +
> > static void kick_hub_wq(struct usb_hub *hub)
> > {
> > struct usb_interface *intf;
> > @@ -713,8 +729,12 @@ static void hub_irq(struct urb *urb)
> > return;
> >
> > status = usb_submit_urb(hub->urb, GFP_ATOMIC);
> > - if (status != 0 && status != -ENODEV && status != -EPERM)
> > + if (status != 0 && status != -ENODEV && status != -EPERM &&
> > + status != -ESHUTDOWN) {
> > dev_err(hub->intfdev, "resubmit --> %d\n", status);
> > + mod_timer(>irq_urb_retry,
> > + jiffies + msecs_to_jiffies(MSEC_PER_SEC));
> > + }
> > }
> >
> > /* USB 2.0 spec Section 11.24.2.3 */
> > @@ -1268,6 +1288,7 @@ static void hub_quiesce(struct usb_hub *hub,
> > enum hub_quiescing_type type)
> > }
> >
> > /* Stop hub_wq and related activity */
> > + del_timer_sync(>irq_urb_retry);
>
> That is a race condition. You kill the timer here, but the URB may
> still be in flight. And if it fails, it will restart the error
> handler. You have to introduce a flag or poison the URB.
I see, wouldn't checking "hub->quiescing" in hub_irq()'s submit error
path do the work? Something the likes of this:
@@ -713,8 +729,12 @@ static void hub_irq(struct urb *urb)
return;
status = usb_submit_urb(hub->urb, GFP_ATOMIC);
- if (status != 0 && status != -ENODEV && status != -EPERM)
+ if (status != 0 && status != -ENODEV && status != -EPERM &&
+ status != -ESHUTDOWN && !hub->quiescing) {
dev_err(hub->intfdev, "resubmit --> %d\n", status);
+ mod_timer(>irq_urb_retry,
+ jiffies + msecs_to_jiffies(MSEC_PER_SEC));
+ }
>
> > usb_kill_urb(hub->urb);
> > if (hub->has_indicators)
> > cancel_delayed_work_sync(>leds);
> >
>
> Regards
> Oliver
>
Also, looking at this made me realize that there is no real need to
check "hub->disconnected" in the timer's function, since "hub-
>quiescing" is also set in that code path before any actual cleanup.
I'll update it in the next revision.
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
[PATCH] usb: gadget: u_ether: fix unsafe list iteration
list_for_each_entry_safe() is not safe for deleting entries from the
list if the spin lock, which protects it, is released and reacquired during
the list iteration. Fix this issue by replacing this construction with
a simple check if list is empty and removing the first entry in each
iteration. This is almost equivalent to a revert of the commit mentioned in
the Fixes: tag.
This patch fixes following issue:
--->8---
Unable to handle kernel NULL pointer dereference at virtual address 0104
pgd = (ptrval)
[0104] *pgd=
Internal error: Oops: 817 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 1 PID: 84 Comm: kworker/1:1 Not tainted
4.20.0-rc2-next-20181114-9-g8266b35ec404 #1061
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Workqueue: events eth_work
PC is at rx_fill+0x60/0xac
LR is at _raw_spin_lock_irqsave+0x50/0x5c
pc : []lr : []psr: 8093
sp : ee7fbee8 ip : 0100 fp :
r10: 006000c0 r9 : c10b0ab0 r8 : ee7eb5c0
r7 : ee7eb614 r6 : ee7eb5ec r5 : 00dc r4 : ee12ac00
r3 : ee12ac24 r2 : 0200 r1 : 6013 r0 : ee7eb5ec
Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 6d5dc04a DAC: 0051
Process kworker/1:1 (pid: 84, stack limit = 0x(ptrval))
Stack: (0xee7fbee8 to 0xee7fc000)
...
[] (rx_fill) from [] (process_one_work+0x200/0x738)
[] (process_one_work) from [] (worker_thread+0x2c/0x4c8)
[] (worker_thread) from [] (kthread+0x128/0x164)
[] (kthread) from [] (ret_from_fork+0x14/0x20)
Exception stack(0xee7fbfb0 to 0xee7fbff8)
...
---[ end trace 64480bc835eba7d6 ]---
Fixes: fea14e68ff5e ("usb: gadget: u_ether: use better list accessors")
Signed-off-by: Marek Szyprowski
---
drivers/usb/gadget/function/u_ether.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/function/u_ether.c
b/drivers/usb/gadget/function/u_ether.c
index 1000d864929c..0f026d445e31 100644
--- a/drivers/usb/gadget/function/u_ether.c
+++ b/drivers/usb/gadget/function/u_ether.c
@@ -401,12 +401,12 @@ static int alloc_requests(struct eth_dev *dev, struct
gether *link, unsigned n)
static void rx_fill(struct eth_dev *dev, gfp_t gfp_flags)
{
struct usb_request *req;
- struct usb_request *tmp;
unsigned long flags;
/* fill unused rxq slots with some skb */
spin_lock_irqsave(>req_lock, flags);
- list_for_each_entry_safe(req, tmp, >rx_reqs, list) {
+ while (!list_empty(>rx_reqs)) {
+ req = list_first_entry(>rx_reqs, struct usb_request, list);
list_del_init(>list);
spin_unlock_irqrestore(>req_lock, flags);
@@ -1125,7 +1125,6 @@ void gether_disconnect(struct gether *link)
{
struct eth_dev *dev = link->ioport;
struct usb_request *req;
- struct usb_request *tmp;
WARN_ON(!dev);
if (!dev)
@@ -1142,7 +1141,8 @@ void gether_disconnect(struct gether *link)
*/
usb_ep_disable(link->in_ep);
spin_lock(>req_lock);
- list_for_each_entry_safe(req, tmp, >tx_reqs, list) {
+ while (!list_empty(>tx_reqs)) {
+ req = list_first_entry(>tx_reqs, struct usb_request, list);
list_del(>list);
spin_unlock(>req_lock);
@@ -1154,7 +1154,8 @@ void gether_disconnect(struct gether *link)
usb_ep_disable(link->out_ep);
spin_lock(>req_lock);
- list_for_each_entry_safe(req, tmp, >rx_reqs, list) {
+ while (!list_empty(>rx_reqs)) {
+ req = list_first_entry(>rx_reqs, struct usb_request, list);
list_del(>list);
spin_unlock(>req_lock);
--
2.17.1
Re: [PATCH 1/2] phy: core: Add phy_pm_runtime_enabled
Hi Tony,
I love your patch! Yet something to improve:
[auto build test ERROR on phy/next]
[also build test ERROR on v4.20-rc3 next-20181119]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Tony-Lindgren/Improve-phy-mapphone-pm/20181119-222603
base: https://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git
next
config: riscv-tinyconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=riscv
All errors (new ones prefixed by >>):
In file included from include/linux/usb/otg.h:13,
from include/linux/usb/of.h:12,
from drivers/usb/phy/of.c:9:
include/linux/phy/phy.h: In function 'phy_pm_runtime_enabled':
>> include/linux/phy/phy.h:246:14: error: expected ';' before '}' token
return false
^
;
}
~
vim +246 include/linux/phy/phy.h
243
244 static inline bool phy_pm_runtime_enabled(struct phy *phy)
245 {
> 246 return false
247 }
248
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: EPROTO when USB 3 GbE adapters are under load
On 25/10/18 11:37 am, Hao Wei Tee wrote: Hi, There are multiple reports[1][2][3] (more elsewhere on the internet) of USB 3 GbE adapters throwing EPROTO errors on USB transfer especially when the devices are under load. Both of the two common chipsets (Realtek RTL8153 (r8152[4]) and Asix AX88179 (ax88179_178a[5])) seem to exhibit this behaviour. I got another RTL8153-powered adapter and, guess what, I can't seem to reproduce this anymore. Not sure if it is something that changed in 4.19 or something to do with the adapters themselves (I don't have the old adapter with me right now). -- Hao Wei
Re: [PATCH v2] usb: hub: add retry routine after intr URB sumbit error
On Mo, 2018-11-19 at 15:02 +0100, Nicolas Saenz Julienne wrote:
>
> +static void hub_retry_irq_urb(struct timer_list *t)
> +{
> + struct usb_hub *hub = from_timer(hub, t, irq_urb_retry);
> + int status;
> +
> + if (hub->disconnected || hub->quiescing)
> + return;
> +
> + dev_err(hub->intfdev, "retrying int urb\n");
> + status = usb_submit_urb(hub->urb, GFP_ATOMIC);
> + if (status && status != -ENODEV && status != -EPERM &&
> + status != -ESHUTDOWN)
> + mod_timer(>irq_urb_retry,
> + jiffies + msecs_to_jiffies(MSEC_PER_SEC));
> +}
> +
> static void kick_hub_wq(struct usb_hub *hub)
> {
> struct usb_interface *intf;
> @@ -713,8 +729,12 @@ static void hub_irq(struct urb *urb)
> return;
>
> status = usb_submit_urb(hub->urb, GFP_ATOMIC);
> - if (status != 0 && status != -ENODEV && status != -EPERM)
> + if (status != 0 && status != -ENODEV && status != -EPERM &&
> + status != -ESHUTDOWN) {
> dev_err(hub->intfdev, "resubmit --> %d\n", status);
> + mod_timer(>irq_urb_retry,
> + jiffies + msecs_to_jiffies(MSEC_PER_SEC));
> + }
> }
>
> /* USB 2.0 spec Section 11.24.2.3 */
> @@ -1268,6 +1288,7 @@ static void hub_quiesce(struct usb_hub *hub, enum
> hub_quiescing_type type)
> }
>
> /* Stop hub_wq and related activity */
> + del_timer_sync(>irq_urb_retry);
That is a race condition. You kill the timer here, but the URB may
still be in flight. And if it fails, it will restart the error
handler. You have to introduce a flag or poison the URB.
> usb_kill_urb(hub->urb);
> if (hub->has_indicators)
> cancel_delayed_work_sync(>leds);
>
Regards
Oliver
[PATCH v2] usb: hub: add retry routine after intr URB sumbit error
The hub sends hot-plug events to the host trough it's interrupt URB. The
driver takes care of completing the URB and re-submitting it. Completion
errors are handled in the hub_event() work, yet submission errors are
ignored, rendering the device unresponsive. All further events are lost.
It is fairly hard to find this issue in the wild, since you have to time
the USB hot-plug event with the URB submission failure. For instance it
could be the system running out of memory or some malfunction in the USB
controller driver. Nevertheless, it's pretty reasonable to think it'll
happen sometime. One can trigger this issue using eBPF's function
override feature (see BCC's inject.py script).
This patch adds a retry routine to the event of a submission error. The
HUB driver will try to re-submit the URB once every second until it's
successful or the HUB is disconnected.
As some USB subsystems already take care of this issue, the
implementation was inspired from usbhid/hid_core.c's.
Signed-off-by: Nicolas Saenz Julienne
---
v2: as per Alan's and Oliver's comments:
- Rename timer
- Delete the timer on disconnect
- Don't reset HUB nor exponential slowdown the timer, 1s fixed retry
period
- Check for -ESHUTDOWN prior kicking the timer
drivers/usb/core/hub.c | 24 +++-
drivers/usb/core/hub.h | 1 +
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index c6077d582d29..937ece45ea1f 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -607,6 +607,22 @@ static int hub_port_status(struct usb_hub *hub, int port1,
status, change, NULL);
}
+static void hub_retry_irq_urb(struct timer_list *t)
+{
+ struct usb_hub *hub = from_timer(hub, t, irq_urb_retry);
+ int status;
+
+ if (hub->disconnected || hub->quiescing)
+ return;
+
+ dev_err(hub->intfdev, "retrying int urb\n");
+ status = usb_submit_urb(hub->urb, GFP_ATOMIC);
+ if (status && status != -ENODEV && status != -EPERM &&
+ status != -ESHUTDOWN)
+ mod_timer(>irq_urb_retry,
+ jiffies + msecs_to_jiffies(MSEC_PER_SEC));
+}
+
static void kick_hub_wq(struct usb_hub *hub)
{
struct usb_interface *intf;
@@ -713,8 +729,12 @@ static void hub_irq(struct urb *urb)
return;
status = usb_submit_urb(hub->urb, GFP_ATOMIC);
- if (status != 0 && status != -ENODEV && status != -EPERM)
+ if (status != 0 && status != -ENODEV && status != -EPERM &&
+ status != -ESHUTDOWN) {
dev_err(hub->intfdev, "resubmit --> %d\n", status);
+ mod_timer(>irq_urb_retry,
+ jiffies + msecs_to_jiffies(MSEC_PER_SEC));
+ }
}
/* USB 2.0 spec Section 11.24.2.3 */
@@ -1268,6 +1288,7 @@ static void hub_quiesce(struct usb_hub *hub, enum
hub_quiescing_type type)
}
/* Stop hub_wq and related activity */
+ del_timer_sync(>irq_urb_retry);
usb_kill_urb(hub->urb);
if (hub->has_indicators)
cancel_delayed_work_sync(>leds);
@@ -1800,6 +1821,7 @@ static int hub_probe(struct usb_interface *intf, const
struct usb_device_id *id)
INIT_DELAYED_WORK(>leds, led_work);
INIT_DELAYED_WORK(>init_work, NULL);
INIT_WORK(>events, hub_event);
+ timer_setup(>irq_urb_retry, hub_retry_irq_urb, 0);
usb_get_intf(intf);
usb_get_dev(hdev);
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 4accfb63f7dc..b0740cf5ef19 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -69,6 +69,7 @@ struct usb_hub {
struct delayed_work leds;
struct delayed_work init_work;
struct work_struct events;
+ struct timer_list irq_urb_retry;
struct usb_port **ports;
};
--
2.19.1
Re: [PATCH] USB: host: ehci: allow tine of highspeed nak-count
On Fri, Nov 16, 2018 at 10:38:18AM -0500, Alan Stern wrote: > On Fri, 16 Nov 2018, Ben Dooks wrote: > > > On 14/11/18 18:47, Alan Stern wrote: > > > On Wed, 14 Nov 2018, Ben Dooks wrote: > > > > > >> From: Ben Dooks > > >> > > >> At least some systems benefit with less scheduling if the NAK count > > >> value is set higher than the default 4. For instance a Tegra3 with > > >> an SMSC9512 showed less interrupt load when this was changed to 14. > > > > > > Interesting. Why do you think this is? In theory, increasing the NAK > > > count RL value should cause a higher memory bus load and perhaps a > > > slight rise in the interrupt load (transfers will complete a little > > > more quickly because the controller tries harder to poll the endpoints > > > and see if they are ready). > > > > I thought the NAK counter was decremented until the transfer is given > > up on. > > That's right. So if the RL value is higher, there will be more polling > attempts in quick succession before the NAK counter drops to 0 and the > controller gives up. More polling attempts in quick succession means > heavier memory bus usage. > > > I'm going to have to go back and get some actual figures from > > a running system as this was originally done over a year ago with the > > SMSC9512 (IIRC) network driver. > > > > >> To allow the changing of this value, add a sysfs node to each of > > >> the controllers to allow run-time changing. > > >> > > >> Signed-off-by: Ben Dooks > > > > > > The patch looks okay to me. > > > > I'll look at getting some tracing from the SMSC driver to see what > > is going on. > > Okay. Should we consider the patch to be held in suspense until then? Yes, I'm not going to have access to any of the test hardware until the end of the week, and will re-verify my initial notes from last year. -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear.
Re: [PATCH] usbnet: use tasklet_init() for usbnet_bh handler
On Fr, 2018-11-16 at 15:50 +, Ben Dooks wrote: > The tasklet initialisation would be better done by tasklet_init() > instead of assuming all the fields are in an ok state by default. > > Note, this does not fix any known bug. > > Signed-off-by: Ben Dooks Acked-by: Oliver Neukum
Re: [PATCH] usb: hub: add I/O error retry & reset routine
On Do, 2018-11-15 at 18:14 +0100, Nicolas Saenz Julienne wrote:
Hi,
what Alan said, in addition you need to stop the error handling
when the device is suspended or reset.
> @@ -713,8 +751,10 @@ static void hub_irq(struct urb *urb)
> return;
>
> status = usb_submit_urb(hub->urb, GFP_ATOMIC);
> - if (status != 0 && status != -ENODEV && status != -EPERM)
> + if (status != 0 && status != -ENODEV && status != -EPERM) {
This also needs to check for -ESHUTDOWN
Regards
Oliver
Re: [PATCH v2 0/4] usb: chipidea: imx: add HSIC support
Hi Peter, On 05.11.18 09:52, Frieder Schrempf wrote: > Hi Peter, > > On 23.10.18 08:33, Peter Chen wrote: >>> As I already posted when I was testing v1 last week, there is a >>> problem with auto >>> suspend with my LAN9730 chip. I thought it was a problem with the >>> smsc95xx/usbnet driver, but I'm not so sure anymore. >>> >>> So I'd like to figure out if it has something to do with the HSIC >>> patches. I hope to >>> find some time to do some more debugging soon. >>> When this is sorted I will append my R-b, T-b tags. >>> >> Thanks, Frieder > > The problem is in the smsc95xx driver and I already sent a fix for it. > So the HSIC patches are ok. > > I have some more small suggestions for the v2 patches, I will send > separately. Could you send a v3, then I will add my R-b and T-b tags to > the whole series? Did you have some time to prepare v3 so we can move on? Also could you please have a quick look add the devicetree changes: https://patchwork.kernel.org/patch/10646853/ Thanks a lot, Frieder
