Hello.
Hello Dear, I am in need of your services to assist in transferring funds. ongenghuat...@gmail.com Yours faithfully. Mr. Ong Eng. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] USB Mux support for Chipidea
On 2017-07-14 23:27, Stephen Boyd wrote:
> Quoting Stephen Boyd (2017-07-13 15:35:02)
>> Quoting Peter Rosin (2017-07-11 22:04:46)
>>>
>>> Maybe no need for a compatible update either, if it works to do something
>>> like this in the DT?
>>>
>>> usb_switch: usb-switch {
>>> compatible = "gpio-mux";
>>> mux-gpios = <&pm8916_gpios 4 GPIO_ACTIVE_HIGH>,
>>> <&pm8916_gpios XXX GPIO_ACTIVE_XXX>;
>>> idle-state = <2>;
>>> #mux-control-cells = <0>;
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&usb_sw_sel_pm>;
>>> };
>>>
>>> But I obviously know little about how things are wired and really works,
>>> so that might be totally off...
>>>
>>> Otherwise, maybe a generic mux-pinctrl driver would do the trick?
>>> (compare with drivers/i2c/muxes/i2c-mux-pinctrl.c)
>>>
>>
>> Agreed.
>
> Testing looks good when I use the gpio-mux binding. The only thing I
Glad to hear it, I didn't really want a new driver so similar to the
mux-gpio driver...
> noticed is that gpio-mux driver is requesting the gpio with
> GPIOD_OUT_LOW. Is that intentional?
Not really intentional, it was just easy.
> I worry that may randomly mux the
> D+/D- lines during probe if the gpio is asserted at probe time. It isn't
> a problem for me right now, because the mux is power on defaulted to
> have the gpio deasserted, but it may be a problem if the default
> changes.
It will not change, the only change I will accept is if the code in
mux-gpio can be arranged to request the gpios with the idle-state from
the start. But even then, the default idle-state (0) will not change.
So, you should be safe.
I will look at the new patches later.
Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 usb-next 0/3] initialize (multiple) PHYs in xhci-plat
Hi Martin,
On Thu, 2017-07-13 at 12:59 +0200, Martin Blumenstingl wrote:
> This series is the outcome of a discussion with Felipe Balbi,
> see [0] and [1].
> The quick-summary of this is:
> - dwc3 already takes one USB2 and one USB3 PHY and initializes these
> correct
> - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and
> ohci-platform.c) do not have a limitation on the number of PHYs - they
> support one PHY per actual host port
> - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two
> or three USB2 ports enabled on the internal root-hub. The SoCs also
> provide separate USB2 PHYs, one per port. All USB2 PHYs (which are
> internally "connected" to the dwc3 roothub) need to be powered on,
> otherwise USB devices cannot be enumerated (even if just one PHY is
> disabled and if the device is plugged into another, enabled port)
>
> In my first attempt to get USB supported on the GXL and GXM SoCs I tried
> to work-around the problem that I could not pass multiple PHYs to the
> dwc3 controller.
> This was rejected by Rob Herring (which was definitely the thing to do in
> my opinion), see [2]
>
> This series adds a new "platform-roothub". This can be configured through
> devicetree by passing a child-node with "reg = <0>" to the USB
> controller. Additionally there has to be a child-node for each port on
> the root-hub. Each of the child-nodes takes a "phys" and "phy-names"
> property. This allows modeling the root-hub in devicetree similar to the
> USB device binding (documented in devicetree/bindings/usb/usb-device.txt)
> This avoids and backwards-compatibility problems (which was a concern
> regardless of the solution, see [3]) since the binding for the root-hub
> was previously not specified (and we're not using the "phys" property of
> the controller, which might have served different purposes before,
> depending on the drivers).
>
> Additionally this integrates the new platform-roothub into xhci-plat.c
> which automatically enables it for the dwc3 driver (in host-mode).
>
How to handle the phy0(one u2phy and one u3phy) when port1 support
dual-role mode? leave them to peripheral side as felipe suggested
before? If so, no port1 node for roothub, is there any problem when
change the port1 to host-only mode?
>
> Changes since RFCv1 at [4]:
> - split the usb-xhci dt-binding documentation into a separate patch
> - fixed a typo ("usb-phy" -> "phys" in the dt-binding example)
> - rebased to apply against latest usb-next
>
>
> [0]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001945.html
> [1]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001947.html
> [2]
> http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001818.html
> [3]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001948.html
> [4] http://marc.info/?l=linux-usb&m=148414866303604&w=2
>
>
> Martin Blumenstingl (3):
> dt-bindings: usb: add the documentation for USB root-hub
> usb: host: add a generic platform USB roothub driver
> usb: host: xhci: plat: integrate the platform-roothub
>
> .../devicetree/bindings/usb/usb-roothub.txt| 46 +++
> Documentation/devicetree/bindings/usb/usb-xhci.txt | 7 +
> drivers/usb/host/Kconfig | 4 +
> drivers/usb/host/Makefile | 2 +
> drivers/usb/host/platform-roothub.c| 146
> +
> drivers/usb/host/platform-roothub.h| 14 ++
> drivers/usb/host/xhci-plat.c | 27 +++-
> drivers/usb/host/xhci.h| 2 +
> 8 files changed, 247 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/usb/usb-roothub.txt
> create mode 100644 drivers/usb/host/platform-roothub.c
> create mode 100644 drivers/usb/host/platform-roothub.h
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 usb-next 0/3] initialize (multiple) PHYs in xhci-plat
Hi,
On Sat, Jul 15, 2017 at 11:33 AM, Chunfeng Yun
wrote:
> Hi Martin,
>
> On Thu, 2017-07-13 at 12:59 +0200, Martin Blumenstingl wrote:
>> This series is the outcome of a discussion with Felipe Balbi,
>> see [0] and [1].
>> The quick-summary of this is:
>> - dwc3 already takes one USB2 and one USB3 PHY and initializes these
>> correct
>> - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and
>> ohci-platform.c) do not have a limitation on the number of PHYs - they
>> support one PHY per actual host port
>> - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two
>> or three USB2 ports enabled on the internal root-hub. The SoCs also
>> provide separate USB2 PHYs, one per port. All USB2 PHYs (which are
>> internally "connected" to the dwc3 roothub) need to be powered on,
>> otherwise USB devices cannot be enumerated (even if just one PHY is
>> disabled and if the device is plugged into another, enabled port)
>>
>> In my first attempt to get USB supported on the GXL and GXM SoCs I tried
>> to work-around the problem that I could not pass multiple PHYs to the
>> dwc3 controller.
>> This was rejected by Rob Herring (which was definitely the thing to do in
>> my opinion), see [2]
>>
>> This series adds a new "platform-roothub". This can be configured through
>> devicetree by passing a child-node with "reg = <0>" to the USB
>> controller. Additionally there has to be a child-node for each port on
>> the root-hub. Each of the child-nodes takes a "phys" and "phy-names"
>> property. This allows modeling the root-hub in devicetree similar to the
>> USB device binding (documented in devicetree/bindings/usb/usb-device.txt)
>> This avoids and backwards-compatibility problems (which was a concern
>> regardless of the solution, see [3]) since the binding for the root-hub
>> was previously not specified (and we're not using the "phys" property of
>> the controller, which might have served different purposes before,
>> depending on the drivers).
>>
>> Additionally this integrates the new platform-roothub into xhci-plat.c
>> which automatically enables it for the dwc3 driver (in host-mode).
>>
> How to handle the phy0(one u2phy and one u3phy) when port1 support
> dual-role mode? leave them to peripheral side as felipe suggested
> before? If so, no port1 node for roothub, is there any problem when
> change the port1 to host-only mode?
on Amlogic Meson GXL we have the following IP blocks:
- 2x USB2 PHYs, some external component has to tell them which mode
(host/device) they should operate in
- there is an additional (1x) USB3 PHY with built-in OTG detection logic
on Amlogic Meson GXL it could work like this:
USB2 and USB3 phy0 can be passed to the root-hub. Additionally the
USB2 phy0 could be passed to the USB3 PHY. The USB3 PHY would then
tell the USB2 PHY in which mode it should operate.
please note that device mode and OTG support on Amlogic Meson GXL is
more complicated, as it uses dwc2 and dwc3 controllers in combination:
- dwc3 is reponsible for host-only mode
- dwc2 is responsible for device-only mode
- OTG detection is done by the USB3 PHY
would you mind sharing a short overview of host/device/OTG support
works on Mediatek SoCs? I assume that the Amlogic Meson GXL
implementation is quite special, so comparing this with another
implementation (for example the Mediatek one) may help spotting
potential issues.
>>
>> Changes since RFCv1 at [4]:
>> - split the usb-xhci dt-binding documentation into a separate patch
>> - fixed a typo ("usb-phy" -> "phys" in the dt-binding example)
>> - rebased to apply against latest usb-next
>>
>>
>> [0]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001945.html
>> [1]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001947.html
>> [2]
>> http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001818.html
>> [3]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001948.html
>> [4] http://marc.info/?l=linux-usb&m=148414866303604&w=2
>>
>>
>> Martin Blumenstingl (3):
>> dt-bindings: usb: add the documentation for USB root-hub
>> usb: host: add a generic platform USB roothub driver
>> usb: host: xhci: plat: integrate the platform-roothub
>>
>> .../devicetree/bindings/usb/usb-roothub.txt| 46 +++
>> Documentation/devicetree/bindings/usb/usb-xhci.txt | 7 +
>> drivers/usb/host/Kconfig | 4 +
>> drivers/usb/host/Makefile | 2 +
>> drivers/usb/host/platform-roothub.c| 146
>> +
>> drivers/usb/host/platform-roothub.h| 14 ++
>> drivers/usb/host/xhci-plat.c | 27 +++-
>> drivers/usb/host/xhci.h| 2 +
>> 8 files changed, 247 insertions(+), 1 deletion(-)
>> create mode 100644 Documentation/devicetree/bindings/usb/usb-roothub.txt
>> create mode 100644 drivers/usb/host/platform-roothub.c
>> create m
[PATCH] usb: gadget: udc: net2272: constify pci_device_id.
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
194532260 5 2171854d6 drivers/usb/gadget/udc/net2272.o
File size After adding 'const':
textdata bss dec hex filename
195492164 5 2171854d6 drivers/usb/gadget/udc/net2272.o
Signed-off-by: Arvind Yadav
---
drivers/usb/gadget/udc/net2272.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/net2272.c b/drivers/usb/gadget/udc/net2272.c
index 8f85a51..91ab2ad80 100644
--- a/drivers/usb/gadget/udc/net2272.c
+++ b/drivers/usb/gadget/udc/net2272.c
@@ -2556,7 +2556,7 @@ net2272_pci_remove(struct pci_dev *pdev)
}
/* Table of matching PCI IDs */
-static struct pci_device_id pci_ids[] = {
+static const struct pci_device_id pci_ids[] = {
{ /* RDK 1 card */
.class = ((PCI_CLASS_BRIDGE_OTHER << 8) | 0xfe),
.class_mask = 0,
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
