Re: [PATCH v7 01/22] mfd: omap-usb-host: Consolidate OMAP USB-HS platform data
On Thu, Jan 17, 2013 at 8:59 AM, Tony Lindgren wrote: > * Alan Stern [130117 07:19]: >> On Thu, 17 Jan 2013, Roger Quadros wrote: >> >> > Let's have a single platform data structure for the OMAP's High-Speed >> > USB host subsystem instead of having 3 separate ones i.e. one for >> > board data, one for USB Host (UHH) module and one for USB-TLL module. >> > >> > This makes the code much simpler and avoids creating multiple copies of >> > platform data. >> > >> > CC: Alan Stern >> > >> > Signed-off-by: Roger Quadros >> >> For the ehci-omap.c part: >> >> Acked-by: Alan Stern > > If Samuel acks this patch, I can apply just this patch alone on v3.8-rc3 > into an immutable branch omap-for-v3.9/board-usb so we all merge it in > as needed. So, that didn't happen; Samuel applied it from the mailing list and sfr just hit merge conflicts due to it. Sigh. This patch (touching arch/arm/mach-omap2) didn't have acks from Tony either. Samuel, Tony, can you sort this out with a stable short topic branch as Tony suggested? It'd be nice to avoid the merge conflict by a little coordination here. :( -Olof -- 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
[PATCH] usb: gadget: at91_udc: Check gpio lookup results
This resolves the following valid build warning:
drivers/usb/gadget/at91_udc.c:1685:34: warning: 'flags' may be used
uninitialized in this function [-Wmaybe-uninitialized]
I switched from ? : to !! mostly to save from wrapping the lines while
I was at it.
Signed-off-by: Olof Johansson
---
Felipe, this would be nice to see fixed for 3.11 but I'd argue that it's
been here long enough to not really be needed for -stable.
drivers/usb/gadget/at91_udc.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
index 073b938..f3dbcd0 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -1682,12 +1682,20 @@ static void at91udc_of_init(struct at91_udc *udc,
board->vbus_pin = of_get_named_gpio_flags(np, "atmel,vbus-gpio", 0,
&flags);
- board->vbus_active_low = (flags & OF_GPIO_ACTIVE_LOW) ? 1 : 0;
+ if (board->vbus_pin < 0)
+ pr_err("%s: Failed to get atmel,vbus-gpio property\n",
+ np->full_name);
+ else
+ board->vbus_active_low = !!(flags & OF_GPIO_ACTIVE_LOW);
board->pullup_pin = of_get_named_gpio_flags(np, "atmel,pullup-gpio", 0,
&flags);
- board->pullup_active_low = (flags & OF_GPIO_ACTIVE_LOW) ? 1 : 0;
+ if (board->pullup_pin < 0)
+ pr_err("%s: Failed to get atmel,pullup-gpio property\n",
+ np->full_name);
+ else
+ board->pullup_active_low = !!(flags & OF_GPIO_ACTIVE_LOW);
}
static int at91udc_probe(struct platform_device *pdev)
--
1.7.10.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
[PATCH] usb: xhci: Mark two functions __maybe_unused
Resolves the following build warnings:
drivers/usb/host/xhci.c:332:13: warning: 'xhci_msix_sync_irqs' defined but not
used [-Wunused-function]
drivers/usb/host/xhci.c:3901:12: warning: 'xhci_change_max_exit_latency'
defined but not used [-Wunused-function]
These functions are not always used, and since they're marked static
they will produce build warnings:
- xhci_msix_sync_irqs is only used with CONFIG_PCI.
- xhci_change_max_exit_latency is a little more complicated with
dependencies on CONFIG_PM and CONFIG_PM_RUNTIME.
Instead of building a bigger maze of ifdefs in this code, I've just
marked both with __maybe_unused.
Signed-off-by: Olof Johansson
---
Sarah,
I guess taste might differ on ifdef vs __maybe_unused, let me know this
is not to your liking.
Thanks,
-Olof
drivers/usb/host/xhci.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2c49f00..87ae8cd 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -329,7 +329,7 @@ static void xhci_cleanup_msix(struct xhci_hcd *xhci)
return;
}
-static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
+static void __maybe_unused xhci_msix_sync_irqs(struct xhci_hcd *xhci)
{
int i;
@@ -3898,7 +3898,7 @@ int xhci_find_raw_port_number(struct usb_hcd *hcd, int
port1)
* Issue an Evaluate Context command to change the Maximum Exit Latency in the
* slot context. If that succeeds, store the new MEL in the xhci_virt_device.
*/
-static int xhci_change_max_exit_latency(struct xhci_hcd *xhci,
+static int __maybe_unused xhci_change_max_exit_latency(struct xhci_hcd *xhci,
struct usb_device *udev, u16 max_exit_latency)
{
struct xhci_virt_device *virt_dev;
--
1.7.10.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
Re: [PATCH] usb: gadget: at91_udc: Check gpio lookup results
On Thu, Jul 25, 2013 at 9:14 AM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 23, 2013 at 11:55:50AM -0700, Olof Johansson wrote:
>> This resolves the following valid build warning:
>>
>> drivers/usb/gadget/at91_udc.c:1685:34: warning: 'flags' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>>
>> I switched from ? : to !! mostly to save from wrapping the lines while
>> I was at it.
>>
>> Signed-off-by: Olof Johansson
>> ---
>>
>> Felipe, this would be nice to see fixed for 3.11 but I'd argue that it's
>> been here long enough to not really be needed for -stable.
>>
>> drivers/usb/gadget/at91_udc.c | 12 ++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
>> index 073b938..f3dbcd0 100644
>> --- a/drivers/usb/gadget/at91_udc.c
>> +++ b/drivers/usb/gadget/at91_udc.c
>> @@ -1682,12 +1682,20 @@ static void at91udc_of_init(struct at91_udc *udc,
>>
>> board->vbus_pin = of_get_named_gpio_flags(np, "atmel,vbus-gpio", 0,
>> &flags);
>> - board->vbus_active_low = (flags & OF_GPIO_ACTIVE_LOW) ? 1 : 0;
>> + if (board->vbus_pin < 0)
>> + pr_err("%s: Failed to get atmel,vbus-gpio property\n",
>> +np->full_name);
>> + else
>> + board->vbus_active_low = !!(flags & OF_GPIO_ACTIVE_LOW);
>
> should you even continue if you can't get the gpio ? If this gpio is
> optional, then it's not really and error, rather a debugging or
> informational message.
That's what the code does today, and I wasn't trying to second-guess
their decisions on that. Chances are firmware, in some instances, have
left power on so continuing might do no harm.
> BTW, this vbus-gpio looks, to me at least, like a fixed regulator
> controlled by a GPIO, no ?
Yes, it does. We have plenty of these kind of bindings from before
everything had to be a regulator.
-Olof
--
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] usb: gadget: at91_udc: Check gpio lookup results
On Thu, Jul 25, 2013 at 10:19 AM, Felipe Balbi wrote: > On Thu, Jul 25, 2013 at 09:18:39AM -0700, Olof Johansson wrote: >> That's what the code does today, and I wasn't trying to second-guess >> their decisions on that. Chances are firmware, in some instances, have >> left power on so continuing might do no harm. > > fair enough, then let's just decrease the error message level to debug > or info. Fair enough. info seems appropriate (or warn). Want me to respin, or can you edit when you apply? Thanks, -Olof -- 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] usb: gadget: at91_udc: Check gpio lookup results
On Fri, Jul 26, 2013 at 2:54 AM, Felipe Balbi wrote: > On Thu, Jul 25, 2013 at 01:59:51PM -0700, Olof Johansson wrote: >> On Thu, Jul 25, 2013 at 10:19 AM, Felipe Balbi wrote: >> > On Thu, Jul 25, 2013 at 09:18:39AM -0700, Olof Johansson wrote: >> >> That's what the code does today, and I wasn't trying to second-guess >> >> their decisions on that. Chances are firmware, in some instances, have >> >> left power on so continuing might do no harm. >> > >> > fair enough, then let's just decrease the error message level to debug >> > or info. >> >> Fair enough. info seems appropriate (or warn). Want me to respin, or >> can you edit when you apply? > > please respin An older patch from Arnd that accomplishes the same warning removal has mysteriously showed up in -next in the last couple of days (ae40d64b1f2db93d7b092e6425a2f716289fbd09), even though commit date was July 15. So, might as well, drop this one. -Olof -- 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] usb: gadget: at91_udc: Check gpio lookup results
On Fri, Jul 26, 2013 at 1:30 PM, Felipe Balbi wrote: > On Fri, Jul 26, 2013 at 09:23:35AM -0700, Olof Johansson wrote: >> On Fri, Jul 26, 2013 at 2:54 AM, Felipe Balbi wrote: >> > On Thu, Jul 25, 2013 at 01:59:51PM -0700, Olof Johansson wrote: >> >> On Thu, Jul 25, 2013 at 10:19 AM, Felipe Balbi wrote: >> >> > On Thu, Jul 25, 2013 at 09:18:39AM -0700, Olof Johansson wrote: >> >> >> That's what the code does today, and I wasn't trying to second-guess >> >> >> their decisions on that. Chances are firmware, in some instances, have >> >> >> left power on so continuing might do no harm. >> >> > >> >> > fair enough, then let's just decrease the error message level to debug >> >> > or info. >> >> >> >> Fair enough. info seems appropriate (or warn). Want me to respin, or >> >> can you edit when you apply? >> > >> > please respin >> >> An older patch from Arnd that accomplishes the same warning removal >> has mysteriously showed up in -next in the last couple of days >> (ae40d64b1f2db93d7b092e6425a2f716289fbd09), even though commit date >> was July 15. >> >> So, might as well, drop this one. > > doesn't look like the same thing: No, not the same patch, but fixes the same warning as a result. Please stick to the patch from Arnd that you've already applied. Thanks, -Olof -- 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] usb: misc: Fix swapped properties in usb3503 DT parsing
On Wed, Aug 07, 2013 at 08:28:24PM +0100, Mark Brown wrote: > From: Mark Brown > > The intn and connect GPIO properties are swapped in the code which will > cause failures at runtime if these are connected, fix the code. > > There are currently no in-tree users of this device to check or update. > > Signed-off-by: Mark Brown Acked-by: Olof Johansson -Olof -- 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 05/11] USB: OHCI: Properly handle ohci-ep93xx suspend
Hi, Greg,
[Adding ep93xx maintainers as well]
On Wed, Oct 2, 2013 at 3:15 AM, Majunath Goudar wrote:
> From: Manjunath Goudar
>
> Suspend scenario in case of ohci-ep93xx glue was not
> properly handled as it was not suspending generic part
> of ohci controller. Alan Stern suggested, properly handle
> ohci-ep93xx suspend scenario.
>
> Calling explicitly the ohci_suspend() routine in
> ohci_hcd_ep93xx_drv_suspend() will ensure proper handling of
> suspend scenario.
>
> Signed-off-by: Manjunath Goudar
> Signed-off-by: Manjunath Goudar
> Acked-by: Alan Stern
> Cc: Arnd Bergmann
> Cc: Greg KH
> Cc: linux-usb@vger.kernel.org
> ---
> drivers/usb/host/ohci-ep93xx.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
> index 492f681..08409bf 100644
> --- a/drivers/usb/host/ohci-ep93xx.c
> +++ b/drivers/usb/host/ohci-ep93xx.c
> @@ -112,13 +112,20 @@ static int ohci_hcd_ep93xx_drv_suspend(struct
> platform_device *pdev, pm_message_
> {
> struct usb_hcd *hcd = platform_get_drvdata(pdev);
> struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> + bool do_wakeup = device_may_wakeup(&pdev->dev);
> + int ret;
>
> if (time_before(jiffies, ohci->next_statechange))
> msleep(5);
> ohci->next_statechange = jiffies;
>
> - clk_disable(usb_host_clock);
> - return 0;
> + ret = ohci_suspend(hcd, do_wakeup);
> + if (ret)
> + return ret;
> +
> + ep93xx_stop_hc(&pdev->dev);
> +
> + return ret;
> }
This patch showed up in -next today (or maybe a while ago and I didn't
notice). It's causing a build failure on ep93xx:
>From
>http://arm-soc.lixom.net/buildlogs/next-thierry/v3.12-rc5-5366-gba2e8c2/buildall.arm.ep93xx_defconfig.log.failed:
drivers/usb/host/ohci-ep93xx.c: In function 'ohci_hcd_ep93xx_drv_suspend':
drivers/usb/host/ohci-ep93xx.c:126:2: error: implicit declaration of
function 'ep93xx_stop_hc'
It's really confusing though, because Majunath has posted this patch
three times. The first time it had the ep93xx_stop_hc() call in there,
the second patch (labelled V2) did not, and the third(?) version,
without version label, also lacked it. No revision log in the patch,
and no comments on it.
But it does seem like the wrong version was merged based on build results.
-Olof
--
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 05/11] USB: OHCI: Properly handle ohci-ep93xx suspend
On Mon, Oct 14, 2013 at 2:07 PM, Hartley Sweeten wrote: > On Monday, October 14, 2013 1:50 PM, Alan Stern wrote: >> On Mon, 14 Oct 2013, Hartley Sweeten wrote: >>> As an alternative to this patch, I have successfully used the ohci-platform >>> driver on the ep93xx. This does move a bit of glue code into the ep93xx >>> core (arch/arm/mach-ep93xx/core.c) but it removes the ohci-ep93xx glue >>> driver completely. >>> >>> I can post a patch for this shortly if you would like. >> >> That would be great! It would save me the trouble of fixing >> Manjanuth's patch and it would remove a source file too! > > The only thing I'm not sure about use where to enable the > USB_OHCI_HCD_PLATFORM driver for ARCH_EP93XX. > > Right now the ohci-ep93xx glue driver is enabled automatically > when USB_OHCI_HCD is enabled due to the ifdefery. I can add > a new config option similar to the other users of > USB_OHCI_HCD_PLATFORM but I was wondering if there is a > cleaner way. Given that we're trying to reduce code under arch/arm and move it out to driver directories instead, I'm not sure this is a step in the right direction. :-) I guess it depends on how much code we're talking about here, so let's take that discussion once patches are posted. -Olof -- 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] usb: ohci: remove ep93xx bus glue platform driver
Hi,
On Mon, Oct 14, 2013 at 2:35 PM, H Hartley Sweeten
wrote:
> Convert ep93xx to use the OHCI platform driver and remove the
> ohci-ep93xx bus glue driver.
>
> Signed-off-by: H Hartley Sweeten
> Cc: Alan Stern
> Cc: Greg Kroah-Hartman
> Cc: Ryan Mallon
> ---
> arch/arm/mach-ep93xx/clock.c | 2 +-
> arch/arm/mach-ep93xx/core.c| 45 +-
> drivers/usb/host/Kconfig | 2 +-
> drivers/usb/host/ohci-ep93xx.c | 184
> -
> drivers/usb/host/ohci-hcd.c| 18
> 5 files changed, 43 insertions(+), 208 deletions(-)
> delete mode 100644 drivers/usb/host/ohci-ep93xx.c
>
> diff --git a/arch/arm/mach-ep93xx/clock.c b/arch/arm/mach-ep93xx/clock.c
> index c95dbce..39ef3b6 100644
> --- a/arch/arm/mach-ep93xx/clock.c
> +++ b/arch/arm/mach-ep93xx/clock.c
> @@ -212,7 +212,7 @@ static struct clk_lookup clocks[] = {
> INIT_CK(NULL, "hclk", &clk_h),
> INIT_CK(NULL, "apb_pclk", &clk_p),
> INIT_CK(NULL, "pll2", &clk_pll2),
> - INIT_CK("ep93xx-ohci", NULL, &clk_usb_host),
> + INIT_CK("ohci-platform",NULL, &clk_usb_host),
> INIT_CK("ep93xx-keypad",NULL, &clk_keypad),
> INIT_CK("ep93xx-fb",NULL, &clk_video),
> INIT_CK("ep93xx-spi.0", NULL, &clk_spi),
> diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
> index 3f12b88..5489824 100644
> --- a/arch/arm/mach-ep93xx/core.c
> +++ b/arch/arm/mach-ep93xx/core.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -297,22 +298,58 @@ static struct platform_device ep93xx_rtc_device = {
> .resource = ep93xx_rtc_resource,
> };
>
> +/*
> + * EP93xx OHCI USB Host
> + */
> +
> +static struct clk *ep93xx_ohci_host_clock;
> +
> +static int ep93xx_ohci_power_on(struct platform_device *pdev)
> +{
> + if (!ep93xx_ohci_host_clock) {
> + ep93xx_ohci_host_clock = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(ep93xx_ohci_host_clock))
> + return PTR_ERR(ep93xx_ohci_host_clock);
> + }
> +
> + clk_enable(ep93xx_ohci_host_clock);
> +
> + return 0;
> +}
> +
> +static void ep93xx_ohci_power_off(struct platform_device *pdev)
> +{
> + clk_disable(ep93xx_ohci_host_clock);
> +}
> +
> +static void ep93xx_ohci_power_suspend(struct platform_device *pdev)
> +{
> + ep93xx_ohci_power_off(pdev);
> +}
> +
> +static struct usb_ohci_pdata ep93xx_ohci_pdata = {
> + .power_on = ep93xx_ohci_power_on,
> + .power_off = ep93xx_ohci_power_off,
> + .power_suspend = ep93xx_ohci_power_suspend,
> +};
This is definitely not a show-stopper in any way, but since this is
just standard clock management, could you even move these clock ops
into the driver? Are any other platforms already doing similar things
so you could remove code from their platform that way as well, per
chance?
-Olof
--
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: [alsa-devel] [PATCH v2 00/34] i.MX multi-platform support
On Fri, Sep 21, 2012 at 1:01 AM, Shawn Guo wrote: > On Thu, Sep 20, 2012 at 03:56:56PM +, Arnd Bergmann wrote: >> Ok, fair enough. I think we can put it in arm-soc/for-next as a staging >> branch anyway to give it some exposure to linux-next, and then we can >> decide whether a rebase is necessary before sending it to Linus. >> > I just saw the announcement from Olof - no more major merge for 3.7 > will be accepted from now on. Can this be an exception or should I > plan this for 3.8? I'll take a look at merging it tomorrow after I've dealt with smp_ops; if it looks reasonably conflict-free I'll pull it in. We need the sound dependency sorted out (or agreed upon) first though. -Olof -- 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 1/2] ARM: Kirkwood: ehci-orion: Add device tree binding
Hi,
Sorry for the late feedback but I didn't notice this until I looked at
the pull request from Jason.
Please go back and revisit these bindings. I'll merge in the current
version but they need to be fixed up.
Also, always cc devicetree-discuss and the DT maintainers on new bindings.
On Sat, Sep 1, 2012 at 2:26 AM, Andrew Lunn wrote:
> Based on previous work by Michael Walle and Jason Cooper.
>
> Made their work actually work, which required added interrupt from DT
> and auxdata, along with setting the dma_mask, which DT does not
> currently do.
>
> Signed-off-by: Andrew Lunn
> ---
> .../devicetree/bindings/usb/ehci-orion.txt | 19 +++
> drivers/usb/host/ehci-orion.c | 59
> +++-
> 2 files changed, 75 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/ehci-orion.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/ehci-orion.txt
> b/Documentation/devicetree/bindings/usb/ehci-orion.txt
> new file mode 100644
> index 000..1bd704e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ehci-orion.txt
> @@ -0,0 +1,19 @@
> +* EHCI controller, Orion Marvell variants
> +
> +Required properties:
> +- compatible: must be "marvell,orion-ehci"
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- interrupts: The EHCI interrupt
> +- phy-version: Can be one of:
> + "NA" - Don't touch the phy, something else has already configured it.
> + "orion5x" - PHY setup as specified by the Orion5x Errata
> +
> +Example:
> +
> + ehci@5 {
> + compatible = "marvell,orion-ehci";
> + reg = <0x5 0x1000>;
> + interrupts = <19>;
> + phy-version = "NA";
> + };
This isn't an appropriate binding for phy. I know, it maps straight
over from the platform data, but it doesn't focus on what the actual
hardware is.
A couple of options. What probably makes most sense depending on how
other phy bindings are moving ahead is to add a phy node under the
ehci controller for the "orion5x" case, and have an appropriate
compatible value there. No node means the same as "NA" in the above
binding. Alternatively, have a phy phandle that points to the phy
device if it sits on an i2c bus, etc.
-Olof
--
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: [alsa-devel] [PATCH v2 00/34] i.MX multi-platform support
Hi, On Fri, Sep 21, 2012 at 9:53 AM, Shawn Guo wrote: > On Sat, Sep 22, 2012 at 12:46:26AM +0800, Shawn Guo wrote: >> I just published the branch below with this series rebased on top of >> the necessary dependant branches. >> >> git://git.linaro.org/people/shawnguo/linux-2.6.git >> staging/imx-multiplatform >> >> The dependant branches include: >> > > Forgot the base: > > * arm-soc/next/multiplatform > > Shawn > >> * arm-soc/multiplatform/platform-data >> >> * arm-soc/multiplatform/smp_ops >> >> * git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-3.7 >> >> It contains dependant patch "ASoC: mx27vis: retrieve gpio numbers >> from platform_data" >> >> * git://git.infradead.org/mtd-2.6.git master >> >> The series is based on this tree to solve some non-trivial conflicts >> on mxc_nand driver. Because mtd tree completely missed 3.6 merge >> window, having the series base on 3.6-rc actually means 3.5 code base >> in term of mtd support. There are currently two cycles changes >> accumulated on mtd, and we need to base the series on it to sort out >> the conflicts. >> >> * git://linuxtv.org/mchehab/media-next.git master >> >> The media tree renames mx2/mx3 camera drivers twice. I'm not sure >> if git merge can detect them, so I just rebased the series on media >> tree to solve that. The bonus point is that a number of trivial >> conflicts with imx27-coda support on media tree gets solved as well. >> >> I'm not requesting you to pull the branch into arm-soc as a stable >> branch but staging one, because the external dependencies which might >> not be stable. I attempt to use it for exposing the series on >> linux-next, so that we can send it to Linus for 3.7 if there is chance >> for us to (e.g. all the dependant branches hit mainline early during >> 3.7 merge window). I've pulled this in now as staging/imx-multiplatform. As you mention, it might or might not make sense to send this up. It also accrued a few more merge conflicts with other branches in arm-soc, so we'll see how things play out. Either way, we'll for sure queue it for 3.8. -Olof -- 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: [alsa-devel] [PATCH v2 00/34] i.MX multi-platform support
On Sat, Sep 22, 2012 at 12:41 AM, Olof Johansson wrote: > Hi, > > On Fri, Sep 21, 2012 at 9:53 AM, Shawn Guo wrote: >> On Sat, Sep 22, 2012 at 12:46:26AM +0800, Shawn Guo wrote: >>> I just published the branch below with this series rebased on top of >>> the necessary dependant branches. >>> >>> git://git.linaro.org/people/shawnguo/linux-2.6.git >>> staging/imx-multiplatform >>> >>> The dependant branches include: >>> >> >> Forgot the base: >> >> * arm-soc/next/multiplatform >> >> Shawn >> >>> * arm-soc/multiplatform/platform-data >>> >>> * arm-soc/multiplatform/smp_ops >>> >>> * git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-3.7 >>> >>> It contains dependant patch "ASoC: mx27vis: retrieve gpio numbers >>> from platform_data" >>> >>> * git://git.infradead.org/mtd-2.6.git master >>> >>> The series is based on this tree to solve some non-trivial conflicts >>> on mxc_nand driver. Because mtd tree completely missed 3.6 merge >>> window, having the series base on 3.6-rc actually means 3.5 code base >>> in term of mtd support. There are currently two cycles changes >>> accumulated on mtd, and we need to base the series on it to sort out >>> the conflicts. >>> >>> * git://linuxtv.org/mchehab/media-next.git master >>> >>> The media tree renames mx2/mx3 camera drivers twice. I'm not sure >>> if git merge can detect them, so I just rebased the series on media >>> tree to solve that. The bonus point is that a number of trivial >>> conflicts with imx27-coda support on media tree gets solved as well. >>> >>> I'm not requesting you to pull the branch into arm-soc as a stable >>> branch but staging one, because the external dependencies which might >>> not be stable. I attempt to use it for exposing the series on >>> linux-next, so that we can send it to Linus for 3.7 if there is chance >>> for us to (e.g. all the dependant branches hit mainline early during >>> 3.7 merge window). > > I've pulled this in now as staging/imx-multiplatform. > > As you mention, it might or might not make sense to send this up. It > also accrued a few more merge conflicts with other branches in > arm-soc, so we'll see how things play out. > > Either way, we'll for sure queue it for 3.8. Hmm. Pulling it in gives me a few new build errors, in particular on the configs that Russell use to build test omap3, as well as one of his vexpress configs. So I dropped it again for now. Let's have the current contents sit in linux-next for at least one release before we bring in anything more, especially since it brings in dependencies on external trees, and it also has a handful of new merge conflicts. We're already exposing Stephen Rothwell to more merge conflicts than I'm entirely comfortable with. -Olof -- 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 1/2] ARM: Kirkwood: ehci-orion: Add device tree binding
On Mon, Sep 24, 2012 at 09:13:53AM +0200, Andrew Lunn wrote:
> > > +Required properties:
> > > +- compatible: must be "marvell,orion-ehci"
> > > +- reg: physical base address of the controller and length of memory
> > > mapped
> > > + region.
> > > +- interrupts: The EHCI interrupt
> > > +- phy-version: Can be one of:
> > > + "NA" - Don't touch the phy, something else has already configured it.
> > > + "orion5x" - PHY setup as specified by the Orion5x Errata
> > > +
> > > +Example:
> > > +
> > > + ehci@5 {
> > > + compatible = "marvell,orion-ehci";
> > > + reg = <0x5 0x1000>;
> > > + interrupts = <19>;
> > > + phy-version = "NA";
> > > + };
> >
> > This isn't an appropriate binding for phy. I know, it maps straight
> > over from the platform data, but it doesn't focus on what the actual
> > hardware is.
> >
> > A couple of options. What probably makes most sense depending on how
> > other phy bindings are moving ahead is to add a phy node under the
> > ehci controller for the "orion5x" case, and have an appropriate
> > compatible value there. No node means the same as "NA" in the above
> > binding. Alternatively, have a phy phandle that points to the phy
> > device if it sits on an i2c bus, etc.
>
> I Olaf
>
> Could i suggest a third option:
>
> I just drop USB phy configuration all together. Only mach-orion5x
> needs this and nobody has shown any interest in moving mach-orion5x to
> DT. So i would just hard code it to "NA".
>
> If anybody does show interest in DT for orion5x, we can add a phy node
> under ehci as a pure extension which does not affect backward
> compatibility.
Yeah, that works too.
-Olof
--
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: misc: usb3503: Fix up usb3503 driver
2013/5/31 Julius Werner : > This patch set contains a few minor changes to the recently added SMSC > USB3503 driver. It addresses issues that seem to be either left-over > stopgaps from an early development stage or board-specific hacks, > changing them to defaults that should be most sane and useable for all > platforms that contain this chip. > > Julius Werner (3): > usb: misc: usb3503: Fix up whitespace > usb: misc: usb3503: Remove hardcoded disabling of ports 2 and 3 > usb: misc: usb3503: Remove 100ms sleep on reset, conform to data > sheet > > drivers/usb/misc/usb3503.c | 16 +++- > 1 file changed, 3 insertions(+), 13 deletions(-) Series: Acked-by: Olof Johansson -Olof -- 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 v5 1/3] usb: ohci-at91: replace request_mem_region + ioremap by devm_ioremap_resource
Boris,
On Mon, Dec 9, 2013 at 12:51 AM, Boris BREZILLON
wrote:
> Replace the request_mem_region + ioremap calls by the
> devm_ioremap_resource call which does the same things but with device
> managed resources.
>
> Signed-off-by: Boris BREZILLON
> Acked-by: Nicolas Ferre
> Signed-off-by: Alan Stern
Did you build these patches? There's several breakages due to them in
last night's next. I'm a little puzzled how they passed testing before
you submitted?
This one fails with:
drivers/usb/host/ohci-at91.c: In function 'usb_hcd_at91_probe':
drivers/usb/host/ohci-at91.c:157:36: error: 'dev' undeclared (first
use in this function)
hcd->regs = devm_ioremap_resource(dev, res);
^
drivers/usb/host/ohci-at91.c:157:36: note: each undeclared identifier
is reported only once for each function it appears in
drivers/usb/host/ohci-at91.c:157:41: error: 'res' undeclared (first
use in this function)
hcd->regs = devm_ioremap_resource(dev, res);
There are more too, the original one I was bisecting for was the below
one, but the above hit first:
drivers/usb/host/ohci-at91.c: In function 'usb_hcd_at91_probe':
drivers/usb/host/ohci-at91.c:190:4: error: label 'err' used but not defined
drivers/usb/host/ohci-at91.c: At top level:
drivers/usb/host/ohci-at91.c:206:2: warning: data definition has no
type or storage class [enabled by default]
drivers/usb/host/ohci-at91.c:206:2: error: type defaults to 'int' in
declaration of 'at91_stop_hc' [-Werror=implicit-int]
drivers/usb/host/ohci-at91.c:206:2: warning: parameter names (without
types) in function declaration [enabled by default]
drivers/usb/host/ohci-at91.c:206:2: error: conflicting types for 'at91_stop_hc'
drivers/usb/host/ohci-at91.c:97:13: note: previous definition of
'at91_stop_hc' was here
drivers/usb/host/ohci-at91.c:208:5: error: expected '=', ',', ';',
'asm' or '__attribute__' before ':' token
drivers/usb/host/ohci-at91.c:210:2: error: expected identifier or '('
before 'return'
drivers/usb/host/ohci-at91.c:211:1: error: expected identifier or '('
before '}' token
drivers/usb/host/ohci-at91.c:97:13: warning: 'at91_stop_hc' defined
but not used [-Wunused-function]
static void at91_stop_hc(struct platform_device *pdev)
Somewhat spectacular. Greg, can you please drop these until he's
sorted out his submission? :(
-Olof
--
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 v6 3/8] dts: Add usb2phy to Exynos 4
On Wed, Jan 29, 2014 at 9:29 AM, Kamil Debski wrote: > Add support to PHY of USB2 of the Exynos 4 SoC. > > Signed-off-by: Kamil Debski > --- > .../devicetree/bindings/arm/samsung/pmu.txt|2 ++ > arch/arm/boot/dts/exynos4.dtsi | 31 > > arch/arm/boot/dts/exynos4210.dtsi | 17 +++ > arch/arm/boot/dts/exynos4x12.dtsi | 17 +++ > 4 files changed, 67 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt > b/Documentation/devicetree/bindings/arm/samsung/pmu.txt > index 307e727..a76f91d 100644 > --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt > +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt > @@ -3,6 +3,8 @@ SAMSUNG Exynos SoC series PMU Registers > Properties: > - name : should be 'syscon'; > - compatible : should contain two values. First value must be one from > following list: > + - "samsung,exynos4210-pmu" - for Exynos4210 SoC, > + - "samsung,exynos4x12-pmu" - for Exynos4212 SoC, >- "samsung,exynos5250-pmu" - for Exynos5250 SoC, >- "samsung,exynos5420-pmu" - for Exynos5420 SoC. > second value must be always "syscon". This and other PMU related bindings/dts changes should probably go in separate patch(es) instead of being snuck in with USB changes. -Olof -- 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 v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy framework
Hi,
On Wed, Jan 29, 2014 at 9:29 AM, Kamil Debski wrote:
> Change the phy provider used from the old one using the USB phy
> framework to a new one using the Generic phy framework.
>
> Signed-off-by: Kamil Debski
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 13 +++
> drivers/usb/host/ehci-exynos.c | 97
> +---
> 2 files changed, 76 insertions(+), 34 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> index d967ba1..25e199a 100644
> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -12,6 +12,10 @@ Required properties:
> - interrupts: interrupt number to the cpu.
> - clocks: from common clock binding: handle to usb clock.
> - clock-names: from common clock binding: Shall be "usbhost".
> + - port: if in the SoC there are EHCI phys, they should be listed here.
> +One phy per port. Each port should have its reg entry with a consecutive
> +number. Also it should contain phys and phy-names entries specifying the
> +phy used by the port.
>
> Optional properties:
> - samsung,vbus-gpio: if present, specifies the GPIO that
> @@ -27,6 +31,15 @@ Example:
>
> clocks = <&clock 285>;
> clock-names = "usbhost";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + phys = <&usb2phy 1>;
> + phy-names = "host";
> + status = "disabled";
> + };
> };
>
> OHCI
[...]
> @@ -102,14 +132,26 @@ static int exynos_ehci_probe(struct platform_device
> *pdev)
> "samsung,exynos5440-ehci"))
> goto skip_phy;
>
> - phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
> - if (IS_ERR(phy)) {
> - usb_put_hcd(hcd);
> - dev_warn(&pdev->dev, "no platform data or transceiver
> defined\n");
> - return -EPROBE_DEFER;
> - } else {
> - exynos_ehci->phy = phy;
> - exynos_ehci->otg = phy->otg;
> + for_each_available_child_of_node(pdev->dev.of_node, child) {
> + err = of_property_read_u32(child, "reg", &phy_number);
> + if (err) {
> + dev_err(&pdev->dev, "Failed to parse device tree\n");
> + of_node_put(child);
> + return err;
> + }
> + if (phy_number >= PHY_NUMBER) {
> + dev_err(&pdev->dev, "Failed to parse device tree -
> number out of range\n");
> + of_node_put(child);
> + return -EINVAL;
> + }
> + phy = devm_of_phy_get(&pdev->dev, child, 0);
> + of_node_put(child);
> + if (IS_ERR(phy)) {
> + dev_err(&pdev->dev, "Failed to get phy number %d",
> + phy_number);
> + return PTR_ERR(phy);
> + }
> + exynos_ehci->phy[phy_number] = phy;
this looks like it is now breaking older device trees, where ports
might not be described. Since device tree interfaces need to be
backwards compatible, you still need to handle the old case of not
having ports described.
There are two ways of doing this:
1. Fall back to the old behavior if there are no ports
2. Use a new compatible value for the new model with port subnodes,
and if the old compatible value is used, then fall back to the old
behavior.
I'm guessing (1) might be easiest since you can check for the presence
of #address-cells to tell if this is just an old style node, or if
it's a new-style node without any ports below it.
-Olof
--
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 v2 2/2] usb: host: xhci-plat: Fix build warning when !CONFIG_PM
On Thu, Jan 30, 2014 at 8:29 PM, Fabio Estevam wrote: > From: Fabio Estevam > > Building keystone_defconfig leads to the following build warnings: > > drivers/usb/host/xhci-plat.c:203:12: warning: 'xhci_plat_suspend' defined but > not used [-Wunused-function] > drivers/usb/host/xhci-plat.c:211:12: warning: 'xhci_plat_resume' defined but > not used [-Wunused-function] > > Cc: Olof Johansson > Reported-by: Olof Johansson > Signed-off-by: Fabio Estevam Acked-by: Olof Johansson -- 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 v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy framework
On Wed, Feb 5, 2014 at 7:57 AM, Kamil Debski wrote:
> Hi Olof,
>
> Thank you for your review.
>
>> From: Olof Johansson [mailto:o...@lixom.net]
>> Sent: Wednesday, January 29, 2014 9:55 PM
>>
>> Hi,
>>
>> On Wed, Jan 29, 2014 at 9:29 AM, Kamil Debski
>> wrote:
>> > Change the phy provider used from the old one using the USB phy
>> > framework to a new one using the Generic phy framework.
>> >
>> > Signed-off-by: Kamil Debski
>> > ---
>> > .../devicetree/bindings/usb/exynos-usb.txt | 13 +++
>> > drivers/usb/host/ehci-exynos.c | 97
>> +---
>> > 2 files changed, 76 insertions(+), 34 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> > b/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> > index d967ba1..25e199a 100644
>> > --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> > +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> > @@ -12,6 +12,10 @@ Required properties:
>> > - interrupts: interrupt number to the cpu.
>> > - clocks: from common clock binding: handle to usb clock.
>> > - clock-names: from common clock binding: Shall be "usbhost".
>> > + - port: if in the SoC there are EHCI phys, they should be listed
>> here.
>> > +One phy per port. Each port should have its reg entry with a
>> > +consecutive number. Also it should contain phys and phy-names
>> entries
>> > +specifying the phy used by the port.
>> >
>> > Optional properties:
>> > - samsung,vbus-gpio: if present, specifies the GPIO that @@ -27,6
>> > +31,15 @@ Example:
>> >
>> > clocks = <&clock 285>;
>> > clock-names = "usbhost";
>> > +
>> > + #address-cells = <1>;
>> > + #size-cells = <0>;
>> > + port@0 {
>> > + reg = <0>;
>> > + phys = <&usb2phy 1>;
>> > + phy-names = "host";
>> > + status = "disabled";
>> > + };
>> > };
>> >
>> > OHCI
>>
>> [...]
>>
>> > @@ -102,14 +132,26 @@ static int exynos_ehci_probe(struct
>> platform_device *pdev)
>> > "samsung,exynos5440-ehci"))
>> > goto skip_phy;
>> >
>> > - phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
>> > - if (IS_ERR(phy)) {
>> > - usb_put_hcd(hcd);
>> > - dev_warn(&pdev->dev, "no platform data or transceiver
>> defined\n");
>> > - return -EPROBE_DEFER;
>> > - } else {
>> > - exynos_ehci->phy = phy;
>> > - exynos_ehci->otg = phy->otg;
>> > + for_each_available_child_of_node(pdev->dev.of_node, child) {
>> > + err = of_property_read_u32(child, "reg",
>> &phy_number);
>> > + if (err) {
>> > + dev_err(&pdev->dev, "Failed to parse device
>> tree\n");
>> > + of_node_put(child);
>> > + return err;
>> > + }
>> > + if (phy_number >= PHY_NUMBER) {
>> > + dev_err(&pdev->dev, "Failed to parse device
>> tree - number out of range\n");
>> > + of_node_put(child);
>> > + return -EINVAL;
>> > + }
>> > + phy = devm_of_phy_get(&pdev->dev, child, 0);
>> > + of_node_put(child);
>> > + if (IS_ERR(phy)) {
>> > + dev_err(&pdev->dev, "Failed to get phy number
>> %d",
>> > +
>> phy_number);
>> > + return PTR_ERR(phy);
>> > + }
>> > + exynos_ehci->phy[phy_number] = phy;
>>
>> this looks like it is now breaking older device trees, where ports
>> might not be described. Since device tree interfaces need to be
>> backwards compatible, you still need to handle the old case of not
>> having ports described.
>>
>> There are two ways of doing this:
>>
Re: [PATCH] USB: mark USB drivers as being GPL only
On 10/02/2008, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > Yes, of course, and I'll never argue otherwise. However, what I was saying is > that it is the claim of the FSF that, in no uncertain terms, a C program that > uses the standard C library interface and is linked to glibc instead of, say, > the old Borland libc, is automatically GPL because it's been linked to GPL > code. > glibc is LGPL and will not force you to use GPL. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: phy: Fix deferred probing
Hi,
On Tue, Jan 6, 2015 at 7:45 AM, Maxime Ripard
wrote:
> Commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
> failure") actually broke the deferred probing mechanism, since it now returns
> EPROBE_DEFER only when the try_module_get call fails, but not when the phy
> lookup does.
>
> All the other similar functions seem to return ENODEV when try_module_get
> fails, and the error code of either __usb_find_phy or __of_usb_find_phy
> otherwise.
>
> In order to have a consistent behaviour, and a meaningful EPROBE_DEFER, always
> return EPROBE_DEFER when __(of_)usb_find_phy fails to look up the requested
> phy, that will be propagated by the caller, and ENODEV if try_module_get
> fails.
>
Fixes: 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error
on failure")
> Signed-off-by: Maxime Ripard
This also fixes USB on tegra/trimslice here.
Tested-by: Olof Johansson
Given that the regression went in during 3.19 merge window, this
should go in as a fix during -rc, please.
-Olof
--
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: [PATCHv4 15/20] ARM: configs: enable XHCI mvebu support in multi_v7_defconfig
On Wed, May 07, 2014 at 03:52:21PM +0200, Thomas Petazzoni wrote: > From: Gregory CLEMENT > > The Marvell Armada 38x platform needs the xhci_mvebu driver enabled > for the xHCI USB hosts, so this commit enables the corresponding > Kconfig option in multi_v7_defconfig. > > Signed-off-by: Gregory CLEMENT > Signed-off-by: Thomas Petazzoni > Cc: a...@kernel.org > Cc: Kevin Hilman > Cc: Olof Johansson > Cc: Arnd Bergmann Applied. -Olof -- 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: RCU bug with v3.17-rc3 ?
On Sun, Oct 19, 2014 at 8:28 AM, Felipe Balbi wrote: > Hi, > > On Sun, Oct 19, 2014 at 10:54:16AM +0100, Russell King - ARM Linux wrote: >> On Wed, Oct 15, 2014 at 10:25:13PM +0100, Russell King - ARM Linux wrote: >> > On Wed, Oct 15, 2014 at 10:23:10PM +0100, Russell King - ARM Linux wrote: >> > > As I said, I have a patch in progress, but it seems that there needed >> > > to be some discussion about exactly which compiler versions are affected. >> > > It seems that it's not as trivial as looking at the GCC bug entry. >> > >> > ... and in any case, it has been a known bug for well over a year now, >> > and it seems that it doesn't affect _that_ many people. So taking some >> > extra time to get it properly correct is the _right_ thing to do. >> >> Well, this is just great. Pushing out the change which blacklists these >> compilers takes out Olof's kernel build system... >> >> Things are not as trivial as they seem. > > Maybe Olof just needs to update his compiler. Olof ? Yep, doing a run with 4.9.1 to see how it looks. In the past, 4.9 has been really noisy with warnings, maybe most of them have been fixed by now. -Olof -- 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 1/2] usb: host: Kconfig: Select PHY drivers for Exynos EHCI/OHCI
On Fri, Jun 27, 2014 at 9:32 AM, Doug Anderson wrote: > Felipe, > > On Fri, Jun 27, 2014 at 8:59 AM, Felipe Balbi wrote: >>> I'll admit to not having been involved with the previous discussions, >>> but this seems strange to me. Are we throwing in the towel and >>> deciding that it's too hard to get the Kconfigs right and that we'll >>> just rely on individual users to figure out the right answer for >>> themselves? >> >> no. select prevents a driver from be built as a dynamically linked >> module and distro-kernels might want to enable everything as modules. > > Ah, that's what the problem was! I wasn't aware of this issue with > SELECT. Sorry for the noob-ness. Select is also fragile, for example if a main subsystem isn't enabled, the specific option will still be enabled (or there'll be a warning/error about it). Overall it tends to cause headaches so many maintainers are starting to push back against it. > Really we want the PHY to be "=y" if the USB driver is "=y" or "=m" if > the USB driver is "=m", I think. You could argue that one might want > to build the main USB driver into the kernel but have the phy drivers > as modules, so you could possibly also try to support that... > > If there's not a good way to specify that, I guess we'll just have to > use "default" and rely on the user not to purposely choose the wrong > thing. Like the following (untested): > > config PHY_SAMSUNG_USB2 > depends on USB_OHCI_EXYNOS || USB_EHCI_EXYNOS > default y if ARCH_EXYNOS=y && (USB_OHCI_EXYNOS=y || USB_EHCI_EXYNOS=y) > default m if ARCH_EXYNOS=m && (USB_OHCI_EXYNOS=m || USB_EHCI_EXYNOS=m) > ... > > I see some syntax like that elsewhere in Kconfig so I assume it's > reasonable... I think you can take out the test for ARCH_EXYNOS here (first of all, it can never be modular). I'm not sure it makes sense to work so hard to set the default right either, as long as the dependencies are correct. I.e. it'll still mess up randconfig if the combination doesn't build, and distros can still downgrade to 'm' if they want to. That'll just leave: config PHY_SAMSUNG_USB2 tristate "foo" depends on USB_OHCI_EXYNOS || USB_EHCI_EXYNOS default y (no need to add an if since it's taken care of by the depends) > With the above the user could purposely enable the OHCI or EHCI driver > and disable the PHY driver which is not really sensible. ...but it > wouldn't cause a compile failure or crash--USB just won't work. Just make the sub-drivers silent options with defaults. I.e: config PHY_EXYNOS5250_USB2 bool SOC_EXYNOS5250 depends on PHY_SAMSUNG_USB2 and so on. Note that it doesn't actually scale to make it depend on a specific SoC though, so it should probably just be cut down the line of EXYNOS4/5 and err on the side of including a bit too much code instead. -Olof -- 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: [GIT PULL] On-demand device probing
Hi, I've bisected boot failures in next-20151016 down to patches in this branch: On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso wrote: > Tomeu Vizoso (20): > driver core: handle -EPROBE_DEFER from bus_type.match() The machine it happened on was OMAP5UEVM: http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html But I've also seen it on tegra2, that one bisected down to: > regulator: core: Probe regulators on demand http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html -Olof -- 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: [GIT PULL] On-demand device probing
On Sat, Oct 17, 2015 at 8:19 AM, Rob Herring wrote: > On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson wrote: >> Hi, >> >> I've bisected boot failures in next-20151016 down to patches in this branch: >> >> On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso >> wrote: >>> Tomeu Vizoso (20): >>> driver core: handle -EPROBE_DEFER from bus_type.match() >> >> The machine it happened on was OMAP5UEVM: >> >> http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html > > So this one is because the MMC node numbering changed. I don't know > how to fix that other than with aliases, but that doesn't solve > backwards compatibility. Yep, aliases will take care of it in this case. This is where -next fills a great purpose, we can make sure we get those aliases added in before the patches go in. >> But I've also seen it on tegra2, that one bisected down to: >> >>> regulator: core: Probe regulators on demand >> >> http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html > > This one you need a rootwait I think. The MMC scanning is not > guaranteed to be done before the rootfs mounting AFAIK. There may be > other problems, but we can't see them since it panics. Embarrassing, I almost always do this and I'm surprised this machine has been this stable without it. -Olof -- 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
