lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 22 Mar 2019 09:04:04 -0500 From: Bin Liu <b-liu@...com> To: Maxime Ripard <maxime.ripard@...tlin.com> CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Paul Kocialkowski <contact@...lk.fr>, Paul Kocialkowski <paul.kocialkowski@...tlin.com>, <linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>, Chen-Yu Tsai <wens@...e.org> Subject: Re: [PATCH] usb: musb: Support gadget mode when the port is set to dual role Hi all, On Fri, Mar 22, 2019 at 02:46:30PM +0100, Maxime Ripard wrote: > > > > Again, think about an embedded product, > > That's all I'm thinking about. > > > if dr_mode is 'otg' which indicates the peripheral mode will be used > > at some point > > No, it indicates that it *might* be used at some point, based on a > number of external factors, including: > - Whether or not the user has plugged something in the connected USB > connector > - If they did so, how the ID pin has been wired (and therefore, is > a device or a host on the other end) > - And how the system designer decided to configure their kernel and > userspace. > > > when and how to load the gadget driver if it is not loaded > > automatically when Linux boots up? the end user doesn't have access > > to the console. > > An application could load it. And really, we start seeing SoCs in more > and more pc-like devices, including with mUSB, so I don't think we > should be making assumptions here. > > How do you think Fedora, Ubuntu or Debian would behave here? > > > > Because no other controller requires it and therefore it's not > > > standard and violates the principle of least surprise? > > > > I know no other controller does this, but this doesn't mean it is not > > standard. > > I'm pretty sure that would be the definition of "standard", or of a > norm at least. > > > > And even without taking this into account, there's also the fact that > > > while the *hardware* can do dual role, the software might decide > > > otherwise. If I don't want to have support for any gadget (at all) in > > > the end system, then why should I be forced to compile and load > > > something I don't even want to use in the first place? > > > > then dr_mode should be set to 'host' instead, you don't have to load a > > gadget if peripheral mode will never be used. > > No. The hardware is perfectly capable of using OTG. The software has > been configured not to. I don't think the argument will lead to anywhere. Let's stop arguing here, so that you can spend time to fix the driver if you want to. Regards, -Bin.
Powered by blists - more mailing lists