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: <20131211085320.GD28456@xps8300>
Date:	Wed, 11 Dec 2013 10:53:20 +0200
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	Kishon Vijay Abraham I <kishon@...com>, balbi@...com
Cc:	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 Mon, Dec 09, 2013 at 11:26:04AM +0200, Heikki Krogerus wrote:
> > >>>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
> > 
> > right. but that doesn't consider broken dt data. With quirks we'll
> > able to tell if a controller in a particular platform has PHY or not
> > without depending on the dt data.
> 
> Broken dt data? What kind of scenario are you thinking here? Do you
> mean case where the dt does not describe the phy on a platform that
> depends on it? Shouldn't that problem be fixed in the dt and not
> hacked in the drivers? Or are you thinking about something else?
> 
> Is there a case where something like that is actually happening?

I'm guessing I'm not getting an answer to this one.

Look, this patch will not work with ACPI enumerated devices. We will
have a platform providing a single ACPI id, but there is a whole bunch
of boards based on it and we have no way of telling which of them
need/have phys to deal with and which ones don't.


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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ