linux-kernel - Re: [PATCH v3 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY

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]

Date:	Thu, 5 Dec 2013 09:58:28 +0200
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	Kishon Vijay Abraham I <kishon@...com>
Cc:	balbi@...com, bcousson@...libre.com, devicetree@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-usb@...r.kernel.org, rob.herring@...xeda.com,
	pawel.moll@....com, mark.rutland@....com, swarren@...dotorg.org,
	ijc+devicetree@...lion.org.uk, rob@...dley.net, tony@...mide.com,
	linux@....linux.org.uk, gregkh@...uxfoundation.org,
	grant.likely@...aro.org, s.nawrocki@...sung.com,
	galak@...eaurora.org
Subject: Re: [PATCH v3 04/10] usb: dwc3: use quirks to know if a particualr
 platform doesn't have PHY

Hi,

On Thu, Dec 05, 2013 at 12:04:46PM +0530, Kishon Vijay Abraham I wrote:
> On Wednesday 04 December 2013 08:10 PM, Heikki Krogerus wrote:
> > On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote:
> >> There can be systems which does not have an external phy, so get
> >> phy only if no quirks are added that indicates the PHY is not present.
> >> Introduced two quirk flags to indicate the *absence* of usb2 phy and
> >> usb3 phy. Also remove checking if return value is -ENXIO since it's now
> >> changed to always enable usb_phy layer.
> > 
> > Can you guys explain why is something like this needed? Like with
> > clocks and gpios, the device drivers shouldn't need to care any more
> > if the platform has the phys or not. -ENODEV tells you your platform
> 
> Shouldn't we report if a particular platform needs a PHY and not able to get
> it. How will a user know if a particular controller is not working because it's
> not able to get and initialize the PHYs? Don't you think in such cases it's
> better to fail (and return from probe) because the controller will not work
> anyway without the PHY?

My point is that you do not need to separately tell this to the driver
like you do with the quirks (if you did, then you would need to fix
your framework and not hack the drivers).

Like I said, ENODEV tells you that there is no phy on this platform
for you, allowing you to safely continue. If your phy driver is not
loaded, the framework already returns EPROBE_DEFER, right. Any other
error when getting the phy you can consider critical. They are the
errors telling you that you do need a phy on this platform, but
something actually went wrong when getting it.

Those "quirks" should always be avoided, and I don't see any use for
them here.

> Thanks
> Kishon

Thanks,

-- 
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/