linux-kernel - Re: [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140915120654.GA31453@xps8300>
Date:	Mon, 15 Sep 2014 15:06:54 +0300
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	Kishon Vijay Abraham I <kishon@...com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Felipe Balbi <balbi@...com>,
	Vivek Gautam <gautam.vivek@...sung.com>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci

On Fri, Sep 12, 2014 at 07:41:56PM +0530, Kishon Vijay Abraham I wrote:
> >> I don't think create lookup should be in host init. If it's dt boot, the
> >> binding should be in dt data or for other boot modes the bindig should be done
> >> in the board file. This just seems hacky to me.
> > 
> > So are you now suggesting that instead of using platform independent
> > solution of sharing the PHYs here, you would have us add platform
> > specific quirks? That would be totally wrong!
> 
> No. The binding between the controller and the PHY is done in hardware design
> and it would be wrong to create such a binding in drivers/* IMO.

And kernel of course always knows the hardware design when it's being
booted, wrong!

Firstly, don't assume this kind of controllers are always part of some
SoC or chip set. They could easily be on a PCI card for example.
Secondly, don't assume we could tell all the details about the board
based on some identifiers. Fox example, at least with our SoCs we
won't be able to differentiate the boards. And it's not like every
board using the same SoC uses the same USB2 PHY for example. That kind
of things are up to the manufacturers.

By default we have to rely on hardware descriptions like DT and ACPI
tables or being able to runtime detect (ULPI). If those things don't
work, we live without PHY in this case. We add board specific quirks
_only_ in case of exceptions, where we simply have no other way. If
it's possible to avoid them, especially with something as simple as
this, we avoid them!

> > And please don't even consider use of board files especially if there
> > is an option. They are the one thing that we are meant to avoid if
> > possible! No?
> 
> For dt yes, I'm not sure about other modes.
> 
> So in the case of dt boot, I'd prefer giving the binding in dt file than
> anywhere else.

I don't know how dt works, but at least in case of ACPI we still need
to deliver the PHY to xHCI here, even when dwc3 is provided bindings
to a PHY(s).

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/