From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Kishon Vijay Abraham I <kishon@ti.com>, balbi@ti.com
Cc: bcousson@baylibre.com, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-usb@vger.kernel.org, rob.herring@calxeda.com,
pawel.moll@arm.com, mark.rutland@arm.com, swarren@wwwdotorg.org,
ijc+devicetree@hellion.org.uk, rob@landley.net, tony@atomide.com,
linux@arm.linux.org.uk, gregkh@linuxfoundation.org,
grant.likely@linaro.org, s.nawrocki@samsung.com,
galak@codeaurora.org
Subject: Re: [PATCH v3 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY
Date: Wed, 11 Dec 2013 10:53:20 +0200 [thread overview]
Message-ID: <20131211085320.GD28456@xps8300> (raw)
In-Reply-To: <20131209092604.GC5231@xps8300>
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
next prev parent reply other threads:[~2013-12-11 8:53 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-25 10:01 [PATCH v3 00/10] Make dwc3 use Generic PHY Framework Kishon Vijay Abraham I
2013-11-25 10:01 ` [PATCH v3 01/10] usb: dwc3: invoke phy_resume after phy_init Kishon Vijay Abraham I
2013-11-25 10:01 ` [PATCH v3 02/10] usb: dwc3: power off usb phy in error path Kishon Vijay Abraham I
2013-11-25 10:01 ` [PATCH v3 03/10] usb: dwc3: preparation for adapting dwc3 to generic phy framework Kishon Vijay Abraham I
2013-11-25 10:01 ` [PATCH v3 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY Kishon Vijay Abraham I
2013-11-25 21:21 ` Felipe Balbi
2013-12-04 14:40 ` Heikki Krogerus
2013-12-05 6:34 ` Kishon Vijay Abraham I
2013-12-05 7:58 ` Heikki Krogerus
2013-12-09 7:13 ` Kishon Vijay Abraham I
2013-12-09 9:26 ` Heikki Krogerus
2013-12-11 8:53 ` Heikki Krogerus [this message]
2013-12-11 9:07 ` Kishon Vijay Abraham I
2013-11-25 10:01 ` [PATCH v3 05/10] usb: dwc3: adapt dwc3 core to use Generic PHY Framework Kishon Vijay Abraham I
2013-11-25 10:01 ` [PATCH v3 06/10] Documentation: dt bindings: move ..usb/usb-phy.txt to ..phy/ti-phy.txt Kishon Vijay Abraham I
2013-11-25 10:01 ` [PATCH v3 07/10] drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework Kishon Vijay Abraham I
2013-12-06 14:35 ` Roger Quadros
2013-12-10 14:40 ` Kishon Vijay Abraham I
2013-11-25 10:01 ` [PATCH v3 08/10] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2 Kishon Vijay Abraham I
2013-11-25 10:01 ` [PATCH v3 09/10] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/ Kishon Vijay Abraham I
2013-11-25 10:01 ` [PATCH v3 10/10] arm/dts: added dt properties to adapt to the new phy framwork Kishon Vijay Abraham I
[not found] ` <1385373690-12170-1-git-send-email-kishon-l0cyMroinI0@public.gmane.org>
2014-01-21 10:11 ` [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO Kishon Vijay Abraham I
[not found] ` <1390299099-14764-1-git-send-email-kishon-l0cyMroinI0@public.gmane.org>
2014-01-21 10:11 ` [PATCH v4 2/2] usb: dwc3: adapt dwc3 core to use Generic PHY Framework Kishon Vijay Abraham I
2014-01-21 14:00 ` Roger Quadros
2014-01-22 6:04 ` Vivek Gautam
2014-01-22 7:59 ` Roger Quadros
2014-01-22 10:14 ` Kishon Vijay Abraham I
2014-01-21 13:53 ` [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO Roger Quadros
2014-01-21 14:47 ` Felipe Balbi
2014-01-24 14:09 ` Kishon Vijay Abraham I
[not found] ` <20140121144725.GF30451-HgARHv6XitL9zxVx7UNMDg@public.gmane.org>
2014-01-27 15:08 ` Heikki Krogerus
2014-01-27 16:05 ` Felipe Balbi
2014-01-28 15:32 ` Heikki Krogerus
2014-01-28 16:30 ` Felipe Balbi
2014-01-29 14:47 ` Heikki Krogerus
2014-02-12 9:46 ` Kishon Vijay Abraham I
[not found] ` <52FB42DE.4090203-l0cyMroinI0@public.gmane.org>
2014-02-19 12:37 ` Roger Quadros
2014-02-21 12:25 ` Kishon Vijay Abraham I
2014-02-21 12:29 ` Roger Quadros
2014-02-24 9:51 ` Kishon Vijay Abraham I
2014-02-24 11:05 ` Roger Quadros
2014-02-24 14:24 ` Kishon Vijay Abraham I
2014-02-24 15:49 ` Felipe Balbi
2014-02-24 9:55 ` Kishon Vijay Abraham I
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131211085320.GD28456@xps8300 \
--to=heikki.krogerus@linux.intel.com \
--cc=balbi@ti.com \
--cc=bcousson@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=grant.likely@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=s.nawrocki@samsung.com \
--cc=swarren@wwwdotorg.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).