does phy_create() fit into this picture?
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
the name string. Have the
consumer pass the data structure's address when it calls phy_create,
instead of passing the name. Then you don't have to worry about two
PHYs accidentally ending up with the same name or any other similar
problems.
Alan Stern
it in the DT core.
This particular approach doesn't seem very robust. What if
pdev-dev.dma_mask is already set to a different value for some good
reason?
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https
an
error-pointer?
looks like we get NULL when PHY layer is disabled. Sounds like an
oversight to me. Do you want to send a patch, or do I cook one and put
yourself as Reported-by ?
You're more familiar with that code. Reported-by is good enough for
me. :-)
Alan Stern
On Tue, 12 Mar 2013, Roger Quadros wrote:
Even when not in PHY mode, the USB device on the port (e.g. HUB)
might need resources like RESET which can be modelled as a PHY
device. So try to get the PHY device in any case.
Signed-off-by: Roger Quadros rog...@ti.com
CC: Alan Stern st
: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-omap.c | 38 +++---
1 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1ba1df8..dc2de47 100644
--- a/drivers/usb
On Mon, 4 Feb 2013, Roger Quadros wrote:
Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
On Mon, 4 Feb 2013, Roger Quadros wrote:
Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
On Mon, 4 Feb 2013, Roger Quadros wrote:
Allows the OHCI controller found in OMAP3 and later chips to
be specified via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
For the ohci-omap3 part:
Acked-by: Alan Stern st...@rowland.harvard.edu
On Mon, 4 Feb 2013, Roger Quadros wrote:
Allows the OMAP EHCI controller to be specified via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
For the ehci-omap part:
Acked-by: Alan Stern st...@rowland.harvard.edu
___
devicetree-discuss
diand...@chromium.org
Acked-by: Alan Stern st...@rowland.harvard.edu
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Fri, 11 Jan 2013, Vivek Gautam wrote:
Adding the phy driver to ehci-s5p. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Acked-by: Alan Stern st
On Fri, 11 Jan 2013, Vivek Gautam wrote:
Adding the phy-driver to ohci-exynos. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Acked-by: Alan Stern st
which still uses it
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Missing Alan's Acked-by here.
Any comments on this patch-series ?
Sorry, this patch and the ohci-exynos one slipped through my net.
Acked-by's have been sent.
Alan
On Mon, 17 Dec 2012, Greg KH wrote:
You can't pick anything up for 3.9 until after 3.8-rc1 is out, according
to the rules of linux-next
Well, you can accept a submission and store it in a private tree until
then. You just can't put it in any tree that feeds into linux-next.
Alan Stern
before picking them
up though.
Regarding the changes to drivers/usb/host/ehci-tegra.c:
Acked-by: Alan Stern st...@rowland.harvard.edu
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree
-EINVAL;
-
pm_runtime_get_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
pm_runtime_put_noidle(pdev-dev);
Acked-by: Alan Stern st...@rowland.harvard.edu
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https
outcome.
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Fri, 26 Oct 2012, Sebastian Andrzej Siewior wrote:
On Thu, Oct 25, 2012 at 10:36:14AM -0400, Alan Stern wrote:
What happens if the drivers get probed in the wrong order? That is, if
ehci-platform gets probed before ehci-spear (or whatever)?
The wrong driver may get loaded.
That's my
in the wrong order? That is, if
ehci-platform gets probed before ehci-spear (or whatever)?
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Tue, 23 Oct 2012, Rob Herring wrote:
On 10/23/2012 02:33 PM, Alan Stern wrote:
On Tue, 23 Oct 2012, Stephen Warren wrote:
Nothing intrinsically distinguishes this class of hardware. The only
thing these devices have in common is that they can be managed by
Linux's ehci-platform
On Wed, 24 Oct 2012, Stephen Warren wrote:
On 10/24/2012 09:26 AM, Sebastian Andrzej Siewior wrote:
On Wed, Oct 24, 2012 at 10:57:00AM -0400, Alan Stern wrote:
Under the circumstances, do we really need a new binding document for
the ehci-platform driver?
It seems reasonable to add
. A
better name might be something like reliable-IRQs. Again, it's not
such an easy thing to test for. Almost all the existing drivers leave
it unset.
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https
-ehci;
arch/powerpc/boot/dts/canyonlands.dts: compatible =
ibm,usb-ehci-460ex, usb-ehci;
Is there a real reason that I'm not aware of? Or can all these entries
safely be removed?
Alan Stern
___
devicetree-discuss mailing list
need to add to the
usb-ehci binding at the moment is has-tt.
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Wed, 24 Oct 2012, Rob Herring wrote:
On 10/24/2012 11:44 AM, Alan Stern wrote:
On Wed, 24 Oct 2012, Stephen Warren wrote:
We should absolutely avoid Linux-specific properties where possible.
That said, what Linux-specific properties are you talking about? The
properties discussed
is updated, it
seems reasonable to use the same approach right from the beginning.
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
that this
would not work with some of the devices that have usb-ehci listed in
their compatible values.
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
no generic standard
hardware for it to describe.
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
will be
rather generic, IMO it will be better to make has-tt,
has-synopsys-hc-bug, and no-io-watchdog separate properties, each
naturally defaulting to not present. That will avoid the need to
update the driver's table each time a new board comes along.
Alan Stern
to
accomplish the same thing?
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
models that the driver
currently supports?
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
-based drivers?
Eventually DMA capabilities will be supported properly in DT, right?
Then all these additions made to hundreds(?) of drivers will have to be
removed. Why not start the ball rolling now and prevent things from
getting even worse?
Alan Stern
where one HW block has an endianness that doesn't
match other HW blocks. Or to be more accurate, it doesn't match what
the other HW blocks expect. For example, on ARM readl and writel
expect to do byte-swapping but some particular EHCI blocks don't need
it.
Alan Stern
don't see how adding native-endian would help; the readl()
function always assumes the values it reads are little-endian, so in
that sense little-endian _is_ the native state.
Also, as far as I know there aren't any examples of big-endian EHCI
registers on systems with little-endian CPUs.
Alan
/ohci platform drivers, so you are right on time :)
At some point we'll need a way to handle the power_{on,off,suspend}
callbacks. I don't know how that should be done.
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
;
unsignedport_power_off:1;
+ unsignedno_io_watchdog:1;
This is also in Florian's patches.
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
...@samsung.com
Acked-by: Alan Stern st...@rowland.harvard.edu
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
...@samsung.com
Acked-by: Alan Stern st...@rowland.harvard.edu
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
...@samsung.com
Acked-by: Alan Stern st...@rowland.harvard.edu
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
if that error code is just
going to be ignored?
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
the compiler to know this hint to optimize things here?
Please don't use likely() or unlikely() except in places it really is
needed, _and_ you have measured the difference. Have you done so in
this place?
It's from a comment by Alan Stern.
http://www.spinics.net/lists/linux-usb/msg64987
is in usb_remove_hcd().
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
), because if
the device is connected on boot, there'll be no USB_PORT_STAT_C_CONNECTION.
Is it acceptable?
Yes. In fact the hub_port_debounce() routine turns off
USB_PORT_STAT_C_CONNECTION anyway.
Alan Stern
___
devicetree-discuss mailing list
On Wed, 13 Jun 2012, Richard Zhao wrote:
- to decrease redundant since both ehci_hcd and ohci_hcd have the same
variable
- it helps access phy in usb core code
- phy is more meaningful than transceiver
Signed-off-by: Richard Zhao richard.z...@freescale.com
Acked-by: Alan Stern st
USB_PORT_STAT_CONNECTION)
+ usb_phy_notify_connect(hcd-phy, port1);
+ else
+ usb_phy_notify_disconnect(hcd-phy, port1);
+ }
+
/* Return now if debouncing failed or nothing is connected or
* the device was removed.
*/
Alan Stern
struct
ehci_hcd to struct usb_hcd, then you _will_ be able to get at it from
within the debouncing routine.
Or if you prefer, leave the pointer where it is and add a method to
struct hc_driver for retrieving the pointer.
Alan Stern
___
devicetree
);
+ }
+
if (pstatus PORT_OWNER)
continue;
if (!(test_bit(i, ehci-suspended_ports)
Otherwise it's okay.
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org
of any x86 systems that would need to use this code.
On the other hand, port-status changes don't occur very frequently. A
little time penalty one way or the other won't make much difference.
Alan Stern
___
devicetree-discuss mailing list
devicetree
-status changes don't occur very frequently. A
little time penalty one way or the other won't make much difference.
I'm not opposed, just curious :)
No big deal either way. But the order of the tests should be switched,
because on most systems, ehci-transceiver will be NULL.
Alan Stern
a219b666e89bd2f7810b4eaaf4d7382ad0e6ecb1 (usb: host:
add dependence for USB_EHCI_MV).
Alan Stern
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Thu, 12 Jan 2012, Michal Simek wrote:
Drivers shouldn't use NO_IRQ. This driver is used
by Microblaze and PPC. PPC defines NO_IRQ as 0
and Microblaze has removed it.
Signed-off-by: Michal Simek mon...@monstr.eu
CC: Alan Stern st...@rowland.harvard.edu
CC: Greg Kroah-Hartman gre
52 matches
Mail list logo
