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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <Yh5K0u3jp4jTXCPi@google.com> Date: Tue, 1 Mar 2022 08:33:22 -0800 From: "mka@...omium.org" <mka@...omium.org> To: "Linyu Yuan (QUIC)" <quic_linyyuan@...cinc.com> Cc: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>, "Tao Wang (Consultant) (QUIC)" <quic_wat@...cinc.com>, "balbi@...nel.org" <balbi@...nel.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "dianders@...omium.org" <dianders@...omium.org>, "frowand.list@...il.com" <frowand.list@...il.com>, "hadess@...ess.net" <hadess@...ess.net>, "krzk@...nel.org" <krzk@...nel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>, "mathias.nyman@...el.com" <mathias.nyman@...el.com>, "michal.simek@...inx.com" <michal.simek@...inx.com>, "peter.chen@...nel.org" <peter.chen@...nel.org>, "ravisadineni@...omium.org" <ravisadineni@...omium.org>, "robh+dt@...nel.org" <robh+dt@...nel.org>, "rogerq@...nel.org" <rogerq@...nel.org>, "stern@...land.harvard.edu" <stern@...land.harvard.edu>, "swboyd@...omium.org" <swboyd@...omium.org> Subject: Re: 回复: 回复: Re: [PATCH v20 3/5] usb: misc: Add onboard_usb_hub driver On Tue, Mar 01, 2022 at 02:30:00AM +0000, Linyu Yuan (QUIC) wrote: > > From: mka@...omium.org <mka@...omium.org> > > Sent: Tuesday, March 1, 2022 2:29 AM > > To: Linyu Yuan (QUIC) <quic_linyyuan@...cinc.com> > > Cc: gregkh@...uxfoundation.org; Tao Wang (Consultant) (QUIC) > > <quic_wat@...cinc.com>; balbi@...nel.org; devicetree@...r.kernel.org; > > dianders@...omium.org; frowand.list@...il.com; hadess@...ess.net; > > krzk@...nel.org; linux-kernel@...r.kernel.org; linux-usb@...r.kernel.org; > > mathias.nyman@...el.com; michal.simek@...inx.com; > > peter.chen@...nel.org; ravisadineni@...omium.org; robh+dt@...nel.org; > > rogerq@...nel.org; stern@...land.harvard.edu; swboyd@...omium.org > > Subject: Re: 回复: 回复: Re: [PATCH v20 3/5] usb: misc: Add > > onboard_usb_hub driver > > > > > > > > Hi Greg and mka, > > > > > > Let's make it clear that we are talking about once this driver is approved > > into usb tree, > > > If we use different USB HUB which have VID/PID not defined in this driver, > > > We need to update this driver. > > > > > > But if we defined VID/PID in device tree(for a specific board, manufacture > > should know VID/PID from HUB it used), > > > dynamic parsed by the driver, then we don't need to change this driver > > (increase VID/PID table). > > > > As per my earlier reply, the kernel/USB core uses the VID:PID reported > > by the USB device, the compatible string in the device tree is purely > > informational. That's not something that could be changed by this > > driver. > I can't fully understand this comment, could you please share step if we want to add a new HUB support, what should we do ? nothing ? Add the VID:PID and compatible strings to onboard_usb_hub.c, analogous to those for the RTS5411 and RTS5414. More work will be needed if the hub needs a special power up or power down sequence (multiple regulators, GPIOs, ...) > If do nothing, can we remove id_table from onboard_hub_usbdev_driver ? > > > > And even if the VID:PID from the device tree was used: how is the > > kernel supposed to know that the onboard_hub driver should be > > probed for a given VID:PID from the device tree, without listing > > the VID:PID (or compatible string) in the driver (which is what > > you seem to seek to avoid)? > In my opinion, if it need update VID/PID table in this driver to support a new HUB, > we can parse VID/PID from device tree and create dynamic VID/PID entry to id_table of onboard_hub_usbdev_driver. > > Hope you can understand what I said. Not really. I doubt that what you are suggesting would work. The easiest thing to convince people would probably be to send a patch (based on this one) with a working implementation of your idea.
Powered by blists - more mailing lists