Re: [PATCH 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode
On Tue, May 10, 2016 at 10:23 AM, Chunfeng Yun wrote: > the default mode of GPIO16 pin is gpio, when set EINT16 to > IRQ_TYPE_LEVEL_HIGH, no interrupt is triggered, it can be > fixed when set its default mode as usb iddig. > > Signed-off-by: Chunfeng Yun This looks like it can be merged orthogonally to all the other patches, but I don't understand the patch or if it is correct. Hongzhou/Yingjoe, can either of you review this patch? Yours, Linus Walleij -- 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 6/6] pinctrl: mt8173: set GPIO16 to usb iddig mode
On Thu, May 12, 2016 at 4:55 AM, Hongzhou Yang wrote: > We find there are some other pins still have the same problem, so please > hold on it. Sorry for so much noise. It's OK. Get me a big patch fixing it all when you're combed through things and we can apply it for fixes/stable. Yours, Linus Walleij -- 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: fix switch off blocked in u_serial
On Wed, Nov 14, 2012 at 3:40 PM, Linus Walleij
wrote:
> From: Haipeng YU
>
> When a device is switched off by software, gserial_cleanup will
> be called, and switch off will be blocked in this function
> because wake_up_interruptible() in gs_close() can not wake_up
> the wait_event() in gserial_cleanup(), it should be changed to
> wake_up() to match the wait_event().
>
> Signed-off-by: Haipeng YU
> Signed-off-by: Linus Walleij
> ---
> drivers/usb/gadget/u_serial.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/u_serial.c b/drivers/usb/gadget/u_serial.c
> index f173952..2d074ba 100644
> --- a/drivers/usb/gadget/u_serial.c
> +++ b/drivers/usb/gadget/u_serial.c
> @@ -887,7 +887,7 @@ static void gs_close(struct tty_struct *tty, struct file
> *file)
> pr_debug("gs_close: ttyGS%d (%p,%p) done!\n",
> port->port_num, tty, file);
>
> - wake_up_interruptible(&port->port.close_wait);
> + wake_up(&port->port.close_wait);
> exit:
> spin_unlock_irq(&port->port_lock);
> }
Ping on this, we're trying to figure out if we're doing the right
thing here so help...
Yours,
Linus Walleij
--
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: autodetect USB MTP device characteristics without libusb_open()
ndows looks for those values) the string descriptor is not > requested. > > End result: A given device only ever crashes exactly once on a given > Windows system. Yep this is as far as I've understood as well. But now you're contradicting the first paragraph of your mail, so which one is it? >> But they have this concept of an .inf file, so the first time >> you insert an alien device, you are asked for an .inf file >> with some driver information. Then you can bind that >> VID+PID to a specific driver, and then they will not look >> further the next time the same device is plugged in again. >> They will just load the driver given from the .inf file. > > Note that everything in the .inf gets stored in the registry. > Noone looks at the .inf again, once the driver has been installed. OK got it. >> So I could mimic this by starting to cache away any >> successfully initiated MTP devices in some /var/libmtp >> file and just OK them the next time they are plugged in. > > You'll have to cache *every* device, so that you do not make a given > device crash more than once, like Windows. Hm, need to figure out how to do this then... Thanks, Linus Walleij -- 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: fix switch off blocked in u_serial
On Wed, Nov 21, 2012 at 3:33 PM, Linus Walleij wrote:
> On Wed, Nov 14, 2012 at 3:40 PM, Linus Walleij
> wrote:
>
>> From: Haipeng YU
>>
>> When a device is switched off by software, gserial_cleanup will
>> be called, and switch off will be blocked in this function
>> because wake_up_interruptible() in gs_close() can not wake_up
>> the wait_event() in gserial_cleanup(), it should be changed to
>> wake_up() to match the wait_event().
>>
>> Signed-off-by: Haipeng YU
>> Signed-off-by: Linus Walleij
>> ---
>> drivers/usb/gadget/u_serial.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/u_serial.c b/drivers/usb/gadget/u_serial.c
>> index f173952..2d074ba 100644
>> --- a/drivers/usb/gadget/u_serial.c
>> +++ b/drivers/usb/gadget/u_serial.c
>> @@ -887,7 +887,7 @@ static void gs_close(struct tty_struct *tty, struct file
>> *file)
>> pr_debug("gs_close: ttyGS%d (%p,%p) done!\n",
>> port->port_num, tty, file);
>>
>> - wake_up_interruptible(&port->port.close_wait);
>> + wake_up(&port->port.close_wait);
>> exit:
>> spin_unlock_irq(&port->port_lock);
>> }
>
> Ping on this, we're trying to figure out if we're doing the right
> thing here so help...
Ping again. This is stopping our systems from shutting down
so would really appreciate some advice if this is the way
to go.
Yours,
Linus Walleij
--
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: fix switch off blocked in u_serial
On Tue, Nov 27, 2012 at 3:11 PM, Linus Walleij wrote:
> On Wed, Nov 21, 2012 at 3:33 PM, Linus Walleij
> wrote:
>> On Wed, Nov 14, 2012 at 3:40 PM, Linus Walleij
>> wrote:
>>
>>> From: Haipeng YU
>>>
>>> When a device is switched off by software, gserial_cleanup will
>>> be called, and switch off will be blocked in this function
>>> because wake_up_interruptible() in gs_close() can not wake_up
>>> the wait_event() in gserial_cleanup(), it should be changed to
>>> wake_up() to match the wait_event().
>>>
>>> Signed-off-by: Haipeng YU
>>> Signed-off-by: Linus Walleij
>>> ---
>>> drivers/usb/gadget/u_serial.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/gadget/u_serial.c b/drivers/usb/gadget/u_serial.c
>>> index f173952..2d074ba 100644
>>> --- a/drivers/usb/gadget/u_serial.c
>>> +++ b/drivers/usb/gadget/u_serial.c
>>> @@ -887,7 +887,7 @@ static void gs_close(struct tty_struct *tty, struct
>>> file *file)
>>> pr_debug("gs_close: ttyGS%d (%p,%p) done!\n",
>>> port->port_num, tty, file);
>>>
>>> - wake_up_interruptible(&port->port.close_wait);
>>> + wake_up(&port->port.close_wait);
>>> exit:
>>> spin_unlock_irq(&port->port_lock);
>>> }
>>
>> Ping on this, we're trying to figure out if we're doing the right
>> thing here so help...
>
> Ping again. This is stopping our systems from shutting down
> so would really appreciate some advice if this is the way
> to go.
Ping on this again, Felipe do you want us to repost?
Soon one month in review...
Yours,
Linus Walleij
--
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: musb: ux500: use clk_prepare_enable and clk_disable_unprepare
On Mon, Jan 7, 2013 at 5:47 PM, Fabio Baltieri wrote: > This patch converts the module to use clk_prepare_enable and > clk_disable_unprepare variants as required by common clock framework. > > Without this the system crash during probe function. > > Signed-off-by: Fabio Baltieri Acked-by: Linus Walleij Yours, Linus Walleij -- 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: musb: ux500: use clk_prepare_enable and clk_disable_unprepare
On Thu, Jan 10, 2013 at 2:38 PM, Fabio Baltieri wrote: > On Thu, Jan 10, 2013 at 12:23:32PM +0100, Linus Walleij wrote: >> On Mon, Jan 7, 2013 at 5:47 PM, Fabio Baltieri >> wrote: >> >> > This patch converts the module to use clk_prepare_enable and >> > clk_disable_unprepare variants as required by common clock framework. >> > >> > Without this the system crash during probe function. >> > >> > Signed-off-by: Fabio Baltieri >> >> Acked-by: Linus Walleij > > Thanks for the ACK. This bug was here unnoticed since 3.6 merge window, Then it should have Cc: sta...@kernel.org.. > do you think it may make sense to add this driver to u8500_defconfig? I > can send a patch if you say so... Yes, can you make a patch updating the defconfig and also enabling a few other things like charging maybe? Sync with Lee. Yours, Linus Walleij -- 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 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Sat, Sep 24, 2016 at 12:50 AM, Martyn Welch
wrote:
> This patch adds support for the GPIO found on the CP2105.
> This device supports either push-pull or open-drain modes, it doesn't
> provide an explicit input mode, though the state of the GPIO can be read
> when used in open-drain mode. Like with pin use, the mode is configured in
> the one-time programable PROM and can't be changed at runtime.
I see.
So implement .direction_input() and .direction_output()
anyways.
Return failure on .direction_input() if it is in push-pull mode.
Return success on all .direction_output() calls.
Then implement .set_single_ended() and return success for open drain
if the is in open drain, success for push-pull if the line is in push-pull
mode, and failure in all other cases. Simple, but correct.
Add some comments to these functions so it is clear what is going on.
(...)
> +#ifdef CONFIG_GPIOLIB
> +static int cp210x_gpio_request(struct gpio_chip *gc, unsigned int offset)
> +{
> + struct cp210x_serial_private *priv =
> + container_of(gc, struct cp210x_serial_private, gc);
Just:
struct cp210x_serial_private *priv = gpiochip_get_data(gc);
> +static int cp210x_gpio_direction_get(struct gpio_chip *gc, unsigned int gpio)
> +{
> + return 0;
> +}
Aha no explicit input mode...
> +static int cp210x_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> +{
> + struct cp210x_serial_private *priv =
> + container_of(gc, struct cp210x_serial_private, gc);
gpiochip_get_data
> + struct usb_serial *serial = priv->serial;
> + int result;
> + u8 buf;
> +
> + result = cp210x_read_vendor_block(serial, REQTYPE_INTERFACE_TO_HOST,
> + CP210X_READ_LATCH, &buf,
> sizeof(buf));
> + if (result < 0)
> + return 0;
No just return the error code. We handle this nowadays.
> +
> + return (buf >> gpio) & 0x1;
Do it like this:
return !!(buf & BIT(gpio));
> +static void cp210x_gpio_set(struct gpio_chip *gc, unsigned int gpio, int
> value)
> +{
> + struct cp210x_serial_private *priv =
> + container_of(gc, struct cp210x_serial_private, gc);
gpiochip_get_data()
(...)
+ result = gpiochip_add(&priv->gc);
Use devm_gpiochip_add_data(&serial->interface->dev, &priv->gc, gc);
And you get the pointer you need.
+void cp210x_shared_gpio_remove(struct usb_serial *serial)
+{
+ struct cp210x_serial_private *priv = usb_get_serial_data(serial);
+
+ if (priv->gc.label)
+ gpiochip_remove(&priv->gc);
+}
Should not be needed with the devm_* call above doing garbage collection.
Yours,
Linus Walleij
--
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 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Fri, Oct 7, 2016 at 5:31 PM, Martyn Welch wrote: > WRT this driver, I think I need to keep set_single_ended, but change > .direction_input > to always return a failure and have .direction_output always return success to > avoid pins being driven in unexpected ways. Does that sould acceptable? I'm pretty sure it's OK, I just want you to consider and think these things over. Your conclusion is as good as mine. I suspect I will just ACK your patch when you have it working. Yours, Linus Walleij -- 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 v7 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Mon, Oct 10, 2016 at 3:39 PM, Martyn Welch wrote: > This patch adds support for the GPIO found on the CP2105. Unlike the GPIO > provided by some of the other devices supported by the cp210x driver, the > GPIO on the CP2015 is muxed on pins otherwise used for serial control > lines. The GPIO have been configured in 2 separate banks as the choice to > configure the pins for GPIO is made separately for pins shared with each > of the 2 serial ports this device provides, though the choice is made for > all pins associated with that port in one go. The choice of whether to use > the pins for GPIO or serial is made by adding configuration to a one-time > programable PROM in the chip and can not be changed at runtime. The device > defaults to GPIO. > > This device supports either push-pull or open-drain modes, it doesn't > provide an explicit input mode, though the state of the GPIO can be read > when used in open-drain mode. Like with pin use, the mode is configured in > the one-time programable PROM and can't be changed at runtime. > > Signed-off-by: Martyn Welch (...) > V7: - Using GPIO private data for GPIO bits. > - Adding limited .set_single_ended() and direction support. > - Simplifying attach() and removing release() as it's no longer required. >From a GPIO point of view: Reviewed-by: Linus Walleij Yours, Linus Walleij -- 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: [balbi-usb:testing/next 57/84] drivers/usb/dwc3/dwc3-st.c:328:2: error: implicit declaration of function 'pinctrl_pm_select_sleep_state'
On Mon, Oct 17, 2016 at 1:50 PM, Felipe Balbi wrote: > kbuild test robot writes: >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git >> testing/next >> head: 4281ef86fae986e0a9bb553fb311fe6d8e039118 >> commit: 040f47e7330045feaa8c06bf2900db2eb2038e80 [57/84] usb: dwc3: Kconfig: >> allow all glues to build if COMPILE_TEST >> config: blackfin-allmodconfig (attached as .config) >> compiler: bfin-uclinux-gcc (GCC) 6.2.0 >> reproduce: >> wget >> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross >> -O ~/bin/make.cross >> chmod +x ~/bin/make.cross >> git checkout 040f47e7330045feaa8c06bf2900db2eb2038e80 >> # save the attached .config to linux build tree >> make.cross ARCH=blackfin >> >> All errors (new ones prefixed by >>): >> >>drivers/usb/dwc3/dwc3-st.c: In function 'st_dwc3_suspend': >>>> drivers/usb/dwc3/dwc3-st.c:328:2: error: implicit declaration of function >>>> 'pinctrl_pm_select_sleep_state' [-Werror=implicit-function-declaration] >> pinctrl_pm_select_sleep_state(dev); >> ^ >>drivers/usb/dwc3/dwc3-st.c: In function 'st_dwc3_resume': >>>> drivers/usb/dwc3/dwc3-st.c:338:2: error: implicit declaration of function >>>> 'pinctrl_pm_select_default_state' [-Werror=implicit-function-declaration] >> pinctrl_pm_select_default_state(dev); >> ^~~ >>cc1: some warnings being treated as errors > > looks like a bug in . Something along the > lines of below should be enough: I don't think so, that include file looks pretty solid. I think the actual problem is that dwc3-st.c doesn't #include even if it is using the functions from it. Yours, Linus Walleij -- 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 v10 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
Good work on this patch, nice that it got merged. I was just thinking that as an add-on, you may want to name the gpio lines so they have meaningful names in userspace when you use this with the chardev (I have reasons to believe these GPIOs will be used from userspace, tell me if that is wrong). We currently support naming lines for devicetree and ACPI (in -next). I was thinking on either reusing the .names field of the struct gpiochip to name the lines for the userspace chardev. With the sideeffect of the names getting reflected also to sysfs if using that. We could otherwise add a special function to name the lines from drivers like this that hang off a pluggable bus. Johan/Martyn what is your idea? Yours, Linus Walleij -- 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 v10 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Wed, Oct 26, 2016 at 11:09 AM, Johan Hovold wrote: > On Tue, Oct 25, 2016 at 11:34:40AM +0200, Linus Walleij wrote: >> I was thinking on either reusing the .names field of the >> struct gpiochip to name the lines for the userspace >> chardev. With the sideeffect of the names getting reflected >> also to sysfs if using that. > > Simply reusing .names would cause problems since the old sysfs name > space is flat, so you would be unable to use more than one pluggable > expander (unless also encoding the topology in the name). Hm it seems we should actually #ifdef that field for sysfs then, it has no applicability outside the legacy sysfs. > Providing default names from the driver could perhaps be useful at > times. For this particular chip the names would still be GPIO_0, GPIO_1 > and GPIO_2 (possibly with a suffix depending on which of the two > controllers they hang off of) however, which may not be much better than > using chip->base + offset. I'd assume this to be the common case. The chardev names are pertaining to a certain device like "gpiochip1" already so the names only need to be unique per-instance. If we made them globally unique we could just use the .names in gpiochip anyways, but that seems ugly. What about suppling gpiochip_set_names(struct gpio_chip *gc, char **names); As the size of the array is implicit from ngpios and the function would be kernel-internal anyways. > Device-tree overlays is what I see a real use for where different > overlays can be applied based on topology data to describe what is > actually connected to a pin in a specific setup. And that seems like > something that could be useful for normal (static) DT systems as well > (e.g. describe what's actually connected to those Beaglebone pins). Yeah these overlays ... discussed that a lot recently. It fits the Beaglebone indeed. Yours, Linus Walleij -- 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: musb: ux500: Fix NULL pointer dereference at system PM
On Mon, Jan 25, 2016 at 1:01 PM, Ulf Hansson wrote:
> The commit 7d32cdef5356 ("usb: musb: fail with error when no DMA
> controller set"), caused the core platform driver to correctly return an
> error code when fail probing.
>
> Unfurtante it also caused bug for a NULL pointer dereference, during
> system suspend for the ux500 driver. The reason is a lacking validation
> of the corresponding ->driver_data pointer, which won't be set when the
> musb core driver fails to probe (or haven't yet been probed).
>
> Fixes: 7d32cdef5356 ("usb: musb: fail with error when no DMA...")
> Signed-off-by: Ulf Hansson
Acked-by: Linus Walleij
Yours,
Linus Walleij
--
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: [RESEND PATCH v5 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Fri, Jul 22, 2016 at 12:33 PM, Martyn Welch wrote: > This patch adds support for the GPIO found on the CP2105. Unlike the GPIO > provided by some of the other devices supported by the cp210x driver, the > GPIO on the CP2015 is muxed on pins otherwise used for serial control > lines. The GPIO have been configured in 2 separate banks as the choice to > configure the pins for GPIO is made separately for pins shared with each > of the 2 serial ports this device provides, though the choice is made for > all pins associated with that port in one go. The choice of whether to use > the pins for GPIO or serial is made by adding configuration to a one-time > programable PROM in the chip and can not be changed at runtime. The device > defaults to GPIO. > > This device supports either push-pull or open-drain modes, it doesn't > provide an explicit input mode, though the state of the GPIO can be read > when used in open-drain mode. Like with pin use, the mode is configured in > the one-time programable PROM and can't be changed at runtime. > > Signed-off-by: Martyn Welch > Acked-by: Linus Walleij Still stands. > V2: - Doesn't break build when gpiolib isn't selected. Nowadays I have changed the kernel so the driver can actually select GPIOLIB, any arch supports it now. Yours, Linus Walleij -- 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 v10 2/9] dt-bindings: pinctrl: Deprecate Tegra XUSB pad controller binding
On Fri, Mar 4, 2016 at 5:19 PM, Thierry Reding wrote: > From: Thierry Reding > > This is an old version of the binding that isn't flexible enough to > describe all aspects of the XUSB pad controller. Specifically with the > addition of XUSB support (for SuperSpeed USB) the existing binding is > no longer suitable. > > Signed-off-by: Thierry Reding That's unfortunate, not to say unelegant. I want to know Stephen's opinion on these patches (probably they are in another mail) before merging. Will the new binding also work with SuperDuperSpeed USB and SuperSuperMegaUltraOrtonSpeed USB I wonder... or will we change the bindings again? Yours, Linus Walleij -- 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 v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support
On Fri, Mar 4, 2016 at 5:19 PM, Thierry Reding wrote: > From: Thierry Reding > > Extend the binding to cover the set of feature found in Tegra210. > > Signed-off-by: Thierry Reding Again I'd like Stephen's ACK on this to keep things together, thanks. Please resend the pinctrl patches to me after v4.6-rc1 with the apropriate ACKs (hoping they will appear). Yours, Linus Walleij -- 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/3] pinctrl: Intel: add RX invertion config
On Wed, Mar 16, 2016 at 2:34 PM, Daniel Vetter wrote: > On Wed, Mar 16, 2016 at 01:27:49PM +0100, Linus Walleij wrote: >> - What is a HPD interrupt? > > hotplug interrupt, fires when you plug in a cable. > >> - What is a Type-C DP HPD? > > usb type C connector can multiplex both DisplayPort and USB, you need to > renegotiate the lane splitting every time the sink changes, i.e. on each > hotplug. OK I understand, thanks a lot! >> - Again why can't you just use a notifier or function call? > > Because windows sucks, hence all that coordination happens through hw > forwarded interrupts and magic registers. Same horror story on the sound > side, where the sound driver needs to know what kind of PCM stream the > monitor can take. It's hilarious. Except when they screw up the design and > then need to fake parts of it in software. So the story is something like that these IRQs have been put into hardware in order to compensate for flaws in Windows device driver model, I see. If there are such special registers in some hardware I guess I'm all for implementing some generic quirk in gpiolib for people who need to software-trigger GPIO IRQs. Could be good for testing too, as there are such registers in ARMs PL061 GPIO controller for test, just so as to simulate a GPIO IRQ. gpiod_trig_irq() would work with me, I'm happy to support whatever the GPIO hardware can do usually. > In sound we've switched over to a proper sw interface, and we tie the > different parts (drm graphics driver and alsa snd driver) using the > component.c framework. Hm is that solution or something similar proper for USB connector as well I wonder... I was thinking about just adding $random_notifier but maybe that is a bit ugly :/ >> What is VPG? Now it seems Intel's internal organization is being used as >> part of the argument to get this change in and that makes me a bit >> annoyed. (...) > There was chat of usb type C support for forever, but I was always > promised that we don't need any interactions on the sw side and it's all > magic in hw. There hasn't been any real design discussions in the open > source group. VPG is the hw/windows group and generally comes up with > "interesting" designs not suitable for upstream. > > Feel free to just nack this stuff, and please cc intel-gfx/dri-devel in > the future (since I tend to ignore everything that's not cc'ed to mailing > lists I don't care about, even when I'm on cc personally). I've added them > all to cc. Thanks a lot Daniel, I understand better now. I'm not really against adding this "interesting" workaround if that is how Windows works, we usually have to go by their standards. From the GPIO point of view it is OK, just something the GPIO can do. I would be more worried about what the USB PHY maintainer (Felipe) is going to say about this. Yours, Linus Walleij -- 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 v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding
On Fri, Mar 4, 2016 at 5:19 PM, Thierry Reding wrote: > From: Thierry Reding > > The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a > set of lanes that are used for PCIe, SATA and USB. > > Signed-off-by: Thierry Reding > --- > Changes in v10: > - clarify that the hardware documentation means something different when > referring to a "port" (intra-SoC connectivity) Thierry I'm a bit out of sync, so can you resend these patches with collected ACKs after -rc1? Please send me the patches I can just merge into the pinctrl tree separately if possible, I encourage any DTS changes to go in orthogonally through ARM SoC. The DTS business I regard as kind of its own tree. Yours, Linus Walleij -- 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/2] USB: serial: cp210x: Adding GPIO support for CP2105
On Tue, Mar 29, 2016 at 6:47 PM, Martyn Welch wrote: > This patch adds support for the GPIO found on the CP2105. Unlike the GPIO > provided by some of the other devices supported by the cp210x driver, the > GPIO on the CP2015 is muxed on pins otherwise used for serial control > lines. The GPIO have been configured in 2 separate banks as the choice to > configure the pins for GPIO is made separately for pins shared with each > of the 2 serial ports this device provides, though the choice is made for > all pins associated with that port in one go. The choice of whether to use > the pins for GPIO or serial is made by adding configuration to a one-time > programable PROM in the chip and can not be changed at runtime. The device > defaults to GPIO. > > This device supports either push-pull or open-drain modes, it doesn't > provide an explicit input mode, though the state of the GPIO can be read > when used in open-drain mode. Like with pin use, the mode is configured in > the one-time programable PROM and can't be changed at runtime. > > Signed-off-by: Martyn Welch Looking good from a GPIO point of view. Acked-by: Linus Walleij Yours, Linus Walleij -- 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 v10 2/9] dt-bindings: pinctrl: Deprecate Tegra XUSB pad controller binding
On Mon, Apr 18, 2016 at 1:12 PM, Thierry Reding wrote: > On Tue, Mar 15, 2016 at 10:01:25AM +0100, Linus Walleij wrote: >> On Fri, Mar 4, 2016 at 5:19 PM, Thierry Reding >> wrote: >> >> > From: Thierry Reding >> > >> > This is an old version of the binding that isn't flexible enough to >> > describe all aspects of the XUSB pad controller. Specifically with the >> > addition of XUSB support (for SuperSpeed USB) the existing binding is >> > no longer suitable. >> > >> > Signed-off-by: Thierry Reding >> >> That's unfortunate, not to say unelegant. I want to know Stephen's >> opinion on these patches (probably they are in another mail) >> before merging. >> >> Will the new binding also work with SuperDuperSpeed USB and >> SuperSuperMegaUltraOrtonSpeed USB I wonder... or will we >> change the bindings again? > > Linus, Stephen's gave his Acked-by on this patch (provided it gets > merged into patch 1/9, which I've done locally), would you be willing to > give your Acked-by so that this change can go in via the PHY tree where > the new bindings are introduced? Yes I trust Stephen to know what's right for Tegra. Acked-by: Linus Walleij Yours, Linus Walleij -- 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 v10 4/9] phy: Add Tegra XUSB pad controller support
On Mon, Apr 18, 2016 at 1:43 PM, Thierry Reding
wrote:
> On Fri, Mar 04, 2016 at 05:19:34PM +0100, Thierry Reding wrote:
>> -MODULE_LICENSE("GPL v2");
>> +EXPORT_SYMBOL_GPL(tegra_xusb_padctl_legacy_remove);
>
> Since this merely implements the binding change, does your Acked-by on
> the binding apply to this part as well?
Sure
Acked-by: Linus Walleij
Sorry for missing to reply to this, have been swamped.
Basically I trust anything that you and Stephen agree on.
Yours,
Linus Walleij
--
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/3 v2] usb: host: fotg2: add device tree probing
On Thu, Feb 9, 2017 at 3:20 PM, Hans Ulli Kroll wrote: > Add device tree probe for fotg2 driver > > v2: > fix in wrong MODULE_DEVICE_TABLE > > Signed-off-by: Hans Ulli Kroll Acked-by: Linus Walleij > + /* Right now device-tree probed devices don't get dma_mask set. > +* Since shared usb code relies on it, set it here for now. > +* Once we have dma capability bindings this can go away. > +*/ > + > + retval = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)); > + if (retval) > + goto fail_create_hcd; Were you able to test this part? I saw the gemini has some DMA engine but I never saw a driver for it. It looks like a reasonable thing to do to my untrained DMA eye. Yours, Linus Walleij -- 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 3/3] DT: add Faraday Tec. as vendor
On Wed, Feb 8, 2017 at 9:00 PM, Hans Ulli Kroll wrote: > add Faraday Technology Corporation as vendor faraday for DT > > Signed-off-by: Hans Ulli Kroll Reviewed-by: Linus Walleij I think I should use this for the PCI block as well, looking over some code and the root hub is using Faraday's PCI ID. Yours, Linus Walleij -- 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 2/3] usb: add DT bindings for farady fotg2 host controller
On Wed, Feb 8, 2017 at 9:00 PM, Hans Ulli Kroll wrote: > This adds DT bindings for the Faraday FOTG2 host controller. > > Signed-off-by: Hans Ulli Kroll Reviewed-by: Linus Walleij Yours, Linus Walleij -- 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: add device tree support for fotg2-hcd driver
On Wed, Feb 8, 2017 at 9:00 PM, Hans Ulli Kroll wrote: > Add device tree binding and DT driver support for fotg2-hcd controller > The device is used on Gemini SoC. All looks good to me. If you send a patch on top of my git branch adding it to the gemini.dtsi set as status = "disabled"; and gemini-nas4220b.dts mainly just setting status = "okay"; I can merge this on top of the rest of the stuff in my tree that should go upstream to ARM SoC. Yours. Linus Walleij -- 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 3/3] DT: add Faraday Tec. as vendor
On Wed, Feb 8, 2017 at 9:00 PM, Hans Ulli Kroll wrote: > add Faraday Technology Corporation as vendor faraday for DT > > Signed-off-by: Hans Ulli Kroll I realized a lot of Gemini IP blocks are actually from Faraday, so now I'm editing the drivers a bit... Rob could you pick this patch directly to the DT tree so we need not worry about the vendor thing? Yours, Linus Walleij -- 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 v1] usb: dwc3: pci: Switch to devm_acpi_dev_add_driver_gpios()
On Wed, Mar 22, 2017 at 3:08 PM, Andy Shevchenko wrote: > Switch to use managed variant of acpi_dev_add_driver_gpios() to simplify > error path and fix potentially wrong assignment if ->probe() fails. > > While here, add a debug message in case assignment fails to allow user > see the cause of a potential issue. > > Signed-off-by: Andy Shevchenko > --- > > Linus, according to preliminary agreement with Felipe it may go through > GPIO subsystem instead of pulling from it. Patch applied with Felipe's ACK. Yours, Linus Walleij -- 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 2/3] usb: add DT bindings for farady fotg2 host controller
On Tue, Feb 21, 2017 at 3:43 PM, Rob Herring wrote: > On Fri, Feb 17, 2017 at 4:07 AM, Hans Ulli Kroll > wrote: >> Hi Rob, >> >> On Wed, 15 Feb 2017, Rob Herring wrote: >> >>> On Wed, Feb 08, 2017 at 09:00:09PM +0100, Hans Ulli Kroll wrote: >>> > This adds DT bindings for the Faraday FOTG2 host controller. >>> > >>> > Signed-off-by: Hans Ulli Kroll >>> > --- >>> > Documentation/devicetree/bindings/usb/fotg2-host.txt | 15 +++ >>> > 1 file changed, 15 insertions(+) >>> > create mode 100644 Documentation/devicetree/bindings/usb/fotg2-host.txt >>> > >>> > diff --git a/Documentation/devicetree/bindings/usb/fotg2-host.txt >>> > b/Documentation/devicetree/bindings/usb/fotg2-host.txt >>> > new file mode 100644 >>> > index ..4c07566a4bf5 >>> > --- /dev/null >>> > +++ b/Documentation/devicetree/bindings/usb/fotg2-host.txt >>> > @@ -0,0 +1,15 @@ >>> > +Faraday FOTG Host controller >>> > + >>> > +Required properties: >>> > + >>> > +- compatible: should be "faraday,fotg210-hcd" >>> >>> hcd as in "host controller driver"? Bindings describe h/w not drivers. >>> >>> It's an OTG controller or host controller? >>> >> >> here only the host controller part used. >> >> faraday fotg2 is a dual role hcd/otg device and here is only the >> host part used. > > Because you don't care about device mode or restricted by the IP > configuration or SoC integration? The former is a user choice and > shouldn't be part of DT. The latter should be implied by an SoC > specific compatible string. Using only a compatible string for a > licensed IP is not specific enough as vendors use differing versions > and integrate them in different ways. Hans can you add: compatible = "cortina,gemini-fotg", "faraday,fotg210-hcd" or something as composite compatible for our controller? It's OK for the driver to only match on the latter for now, but for the future it's nice for the driver to know what silicon it is on. This is what I've done for most other Cortina/Gemini stuff. Yours, Linus Walleij -- 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: [rtc-linux] [PATCH 8/8] ARM: vt8500: gpio: Devicetree support for arch-vt8500
On Wed, Aug 8, 2012 at 3:39 AM, Tony Prisk wrote:
> Converted the existing arch-vt8500 gpio to a platform_device.
> Added support for WM8505 and WM8650 GPIO controllers.
(...)
> +++ b/drivers/gpio/gpio-vt8500.c
This driver looks very one-bit-per-gpio typed. Are you sure you cannot
just reuse drivers/gpio/gpio-generic.c? Make a compelling case please...
> +struct vt8500_gpio_bank_regs {
> + int en;
> + int dir;
> + int data_out;
> + int data_in;
Why are all these members int? They should be u8 from reading your code.
> + int ngpio;
> +};
> +static struct vt8500_gpio_data vt8500_data = {
> + .num_banks = 7,
> + .banks = {
> + VT8500_BANK(0x00, 0x20, 0x40, 0x60, 26),
> + VT8500_BANK(0x04, 0x24, 0x44, 0x64, 28),
> + VT8500_BANK(0x08, 0x28, 0x48, 0x68, 31),
> + VT8500_BANK(0x0C, 0x2C, 0x4C, 0x6C, 19),
> + VT8500_BANK(0x10, 0x30, 0x50, 0x70, 19),
> + VT8500_BANK(0x14, 0x34, 0x54, 0x74, 23),
> + VT8500_BANK(-1, 0x3C, 0x5C, 0x7C, 9),/* external gpio */
What on earth are all those magic numbers?
I *guess* they're enabling some default GPIO settings etc.
But it really needs better structure, #defines for each one or
atleast include and say:
= BIT(4) | /* Enable GPIO pin 5 on this bank */
BIT(5); /* Enable GPIO pin 6 on this bank */
However I suspect this is board specific and should
be taken from device tree. Please elaborate on this...
Ditto for the different instances.
(...)
> + unsigned val;
Looks like all of these should be u8.
> + val = readl(vt8500_chip->base + vt8500_chip->regs->en +
> + vt8500_chip->regoff);
val = (u8) readl(...);
usw
> + val |= (1 << offset);
Use
val |= BIT(offset);
Apart from these remarks it's looking good...
Yours,
Linus Walleij
--
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: [rtc-linux] [PATCH 8/8] ARM: vt8500: gpio: Devicetree support for arch-vt8500
On Wed, Aug 8, 2012 at 11:19 AM, Arnd Bergmann wrote:
>> What on earth are all those magic numbers?
>>
>> I *guess* they're enabling some default GPIO settings etc.
>
> No, they are the register offsets you quoted above, per bank.
Aha I was fooled by this:
+struct vt8500_gpio_bank_regs {
+ int en;
+ int dir;
+ int data_out;
+ int data_in;
+ int ngpio;
+};
This needs to be named something intuitive like "vt8500_gpio_bank_regoffsets"
Some kerneldoc intsead of the opaque comment above will also improve
readability a lot:
/**
* struct vt8500_gpio_bank_regoffsets
* @en: offset to enable register in the bank
* ...
Yours,
Linus Walleij
--
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: [rtc-linux] [PATCHv3 8/9] arm: vt8500: gpio: Devicetree support for arch-vt8500
On Tue, Aug 21, 2012 at 10:47 PM, Tony Prisk wrote: > Converted the existing arch-vt8500 gpio to a platform_device. > Added support for WM8505 and WM8650 GPIO controllers. (...) > + unsigned val; I asked about the datatype for this "val", it sure isn't "unsigned". I suspected the registers were only 8bit and so it should be u8. But atleast use u32 if you must use all these bits. (...) > + val = readl(vt8500_chip->base + vt8500_chip->regs->en); > + val |= BIT(offset); > + writel(val, vt8500_chip->base + vt8500_chip->regs->en); BTW: have you considered [readl|writel]_relaxed? Yours, Linus Walleij -- 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: [rtc-linux] [PATCHv4 8/9] arm: vt8500: gpio: Devicetree support for arch-vt8500
On Thu, Aug 23, 2012 at 9:35 AM, Tony Prisk wrote: > Converted the existing arch-vt8500 gpio to a platform_device. > Added support for WM8505 and WM8650 GPIO controllers. > Replaced existing readl/writel calls with _relaxed variants. > Replaced existing unsigned variables with u32 to match register size. > > Signed-off-by: Tony Prisk Sweet! Reviewed-by: Linus Walleij Yours, Linus Walleij -- 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: [rtc-linux] RE: [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree ***
On Thu, Aug 23, 2012 at 2:58 PM, Tony Prisk wrote: > Linus W has provided some feedback on the gpio driver - I missed the > issues he raised the first time around so just waiting for him to take a look > at v4 when he's got time. Reviewed and OK:ed, looking good now. Yours, Linus Walleij -- 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: Add Interface Association Descriptor to ECM
On Fri, Sep 7, 2012 at 8:51 PM, Sebastian Andrzej Siewior
wrote:
> On Wed, Jan 25, 2012 at 11:02:03AM +0100, Linus Walleij wrote:
>> static struct usb_descriptor_header *ecm_fs_function[] = {
>> /* CDC ECM control descriptors */
>> + (struct usb_descriptor_header *) &ecm_iad_descriptor,
>> (struct usb_descriptor_header *) &ecm_control_intf,
>> (struct usb_descriptor_header *) &ecm_header_desc,
>> (struct usb_descriptor_header *) &ecm_union_desc,
>> @@ -247,6 +262,7 @@ static struct usb_endpoint_descriptor hs_ecm_out_desc = {
>>
>> static struct usb_descriptor_header *ecm_hs_function[] = {
>> /* CDC ECM control descriptors */
>> + (struct usb_descriptor_header *) &ecm_iad_descriptor,
>> (struct usb_descriptor_header *) &ecm_control_intf,
>> (struct usb_descriptor_header *) &ecm_header_desc,
>> (struct usb_descriptor_header *) &ecm_union_desc,
>
> Why did you add this IAD thingy to FS and HS and not SS descriptors? I don't
> see a reason so I would guess you just forgot :)
Argh, Praveena, save me here ... I was being patch secretary
this time, but to my untrained USB-eyes it looks like you're right,
interested in patching it?
Yours,
Linus Walleij
--
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/39] ARM: ux500: Stop passing MMC's platform data for Device Tree boots
On Mon, Jun 10, 2013 at 11:15 AM, Lee Jones wrote: > On Wed, 15 May 2013, Linus Walleij wrote: > >> On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: >> >> > It was required to pass DMA channel configuration information to the >> > MMC driver before the new DMA API was in place. Now that it is, and >> > is fully compatible with Device Tree we can stop doing that. >> > >> > Reviewed-by: Linus Walleij >> > Signed-off-by: Lee Jones >> >> So since the use of dma_request_slave_channel() is not upstream, >> I guess this will break DMA use (i.e slow down transfers!) on all >> device tree boots? >> >> I'd be happy to apply it once the MMCI patch is in linux-next >> indicating there may just be a window in the merge period >> where it falls back to IRQ mode, but I don't want to disable >> DMA on DT boots for an entire kernel cycle just like that. >> >> Not applied as of yet. > > I believe it's now okay to apply this. Yep, I've rebased and applied it to the ux500-devicetree branch. I have some stuff on this branch which is queued up but may miss v3.11, because I need the 5 outstanding pull requests to land in ARM SoC so I get a merge base there before I can send any more stuff. It's mainly because this stuff isn't any orthogonal, everything just conflicts in the AUXDATA all the time. Yours, Linus Walleij -- 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 06/39] ARM: ux500: Move SDI (MMC) and UART devices under more descriptive heading
On Mon, Jun 10, 2013 at 11:17 AM, Lee Jones wrote: > On Wed, 15 May 2013, Linus Walleij wrote: > >> On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: >> >> > Now DMA DT bindings exist and are in use by he MMC and UART drivers, it >> > should be possible to remove them from the auxdata structure. However, >> > after doing so the drivers fail. Common clk is still reliant on the >> > dev_name() call to do device name matching, which will fail due to the >> > fact that Device Tree naming differs somewhat do the more traditional >> > conventions. >> > >> > Reviewed-by: Linus Walleij >> > Signed-off-by: Lee Jones >> >> Cannot be applied due to dependency on 5/39. > > I think this can be applied now (if it hasn't already). I really need a clean mergebase for this to merge ... This patch requires both the dma40 and devicetree branches to land in a common place before it can be applied. I want the DMA40 branch to be closed down now as I have sent all pull requests on it, so pls ping me again on this when we have something in the ARM SoC tree we can work on. Yours, Linus Walleij -- 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: [Ksummit-2013-discuss] Topic: where should the border between userspace and kernel be?
On Tue, Jul 16, 2013 at 12:39 PM, Miklos Szeredi wrote: > Is the border always where it should be? Are there any candidates for > moving things into, or out of the kernel? Are there some guidelines > for deciding which functionality belongs to the kernel? Now I need to flag ATTEND. On this subject I would add not just broadband modems but the media players and all type of Android devices that nowadays use the MTP protocol (and thus the PTP protocol). I am also the maintainer of libmtp. It has turned out that people think about this transactional object thing (which is more like FTP over USB than USB mass storage) as a file system and it is now being implemented with e.g. GVFS and KDE's counter-part in userspace as virtual filesystems. This would be all OK if it wasn't that I always have this worry that with all the device-specific quirks etc we had been better off in kernelspace for what is today libmtp. Certainly we had gotten to a point where it was usable for people quicker than has happened so far. The strangeness of how libusb abstracts things to userspace would not be there, and it would be more possible to share code between client and server (responder and initiator as they are called) than is currently possible. So I guess I could add some €0.01 here... Background: http://libmtp.git.sourceforge.net/git/gitweb.cgi?p=libmtp/libmtp;a=blob;f=README;hb=HEAD (The end of the file is especially interesting, may propose this as a talk for a conference this year.) Yours, Linus Walleij -- 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: musb: name ux500 platforms more broadly
The Kconfig help text is talking about the U5500 which is no longer supported by the kernel. Name the help text after the config symbol which is more correct. Signed-off-by: Linus Walleij --- drivers/usb/musb/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index c64ee09a7..a77ac0c 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -91,7 +91,7 @@ config USB_MUSB_BLACKFIN depends on (BF54x && !BF544) || (BF52x && ! BF522 && !BF523) config USB_MUSB_UX500 - tristate "U8500 and U5500" + tristate "Ux500 platforms" endchoice @@ -113,7 +113,7 @@ choice allow using DMA on multiplatform kernels. config USB_UX500_DMA - bool 'ST Ericsson U8500 and U5500' + bool 'ST Ericsson Ux500' depends on USB_MUSB_UX500 help Enable DMA transfers on UX500 platforms. -- 1.8.3.1 -- 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: fix pxa25x compilation problems
In commit 88f718e3fa4d67f3a8dbe79a2f97d722323e4051 "ARM: pxa: delete the custom GPIO header" we removed the implicit inclusion of from . The pxa25x_udc was not using that, but it was relying on to implictly include which in turn implicitly included , which was needed for the driver to compile. Fix this up by explicitly including the necessary header. Reported-by: Russell King Signed-off-by: Linus Walleij --- drivers/usb/gadget/pxa25x_udc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c index 0ac6064aa3b8..409a3c45a36a 100644 --- a/drivers/usb/gadget/pxa25x_udc.c +++ b/drivers/usb/gadget/pxa25x_udc.c @@ -54,6 +54,7 @@ */ #ifdef CONFIG_ARCH_PXA #include +#include #endif #ifdef CONFIG_ARCH_LUBBOCK -- 1.8.3.1 -- 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
autodetect USB MTP device characteristics without libusb_open()
1;
}
return 0;
}
static int check_sysfs(char *sysfspath)
{
char dirbuf[FILENAME_MAX];
int len = strlen(sysfspath);
DIR *dir;
struct dirent *dent;
regex_t r;
int ret;
int look_closer = 0;
dir = opendir(sysfspath);
if (!dir)
return -1;
strcpy(dirbuf, sysfspath);
dirbuf[len++] = '/';
/* Check for dirs that identify interfaces */
ret = regcomp(&r, "^[0-9]+-[0-9]+\\:[0-9]+\\.[0-9]+$", REG_EXTENDED
| REG_NOSUB);
if (ret)
return -1;
while ((dent = readdir(dir))) {
struct stat st;
int ret;
/* No need to check those beginning with a period */
if (dent->d_name[0] == '.')
continue;
strncpy(dirbuf + len, dent->d_name, FILENAME_MAX - len);
dirbuf[FILENAME_MAX - 1] = '\0'; /* Sentinel */
ret = lstat(dirbuf, &st);
if (ret)
continue;
/* Look closer at dirs that may be interfaces */
if (S_ISDIR(st.st_mode)) {
if (!regexec(&r, dent->d_name, 0, 0, 0))
if (check_interface(dirbuf) > 0)
/* potential MTP interface! */
look_closer = 1;
}
}
regfree(&r);
closedir(dir);
return look_closer;
}
Yours,
Linus Walleij
--
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: autodetect USB MTP device characteristics without libusb_open()
On Mon, Nov 5, 2012 at 11:31 PM, Bjørn Mork wrote:
> Linus Walleij writes:
> Excuse my lack of knowlegde here, but I have to ask why that is?
>
> I looked briefly at the MTP v1.1 spec from
So all MTP devices manufactured before that spec, and numerous produced
after that spec came out, and several still being produced don't use the
class code, i.e. they violate the spec. But we still have to detect them
somehow.
Here are some device logs I've been collecting:
http://libmtp.git.sourceforge.net/git/gitweb.cgi?p=libmtp/libmtp;a=tree;f=logs;hb=HEAD
Early devices look like this:
9Interface has a kernel driver attached.
10bcdUSB: 512
11bDeviceClass: 255
12bDeviceSubClass: 0
13bDeviceProtocol: 0
14idVendor: 041e
15idProduct: 4130
16IN endpoint maxpacket: 512 bytes
17OUT endpoint maxpacket: 512 bytes
18Raw device info:
19 Bus location: 2
20 Device number: 12
21 Device entry info:
22 Vendor: Creative
23 Vendor id: 0x041e
24 Product: ZEN Micro (MTP mode)
25 Vendor id: 0x4130
26 Device flags: 0x2001
This is the lsusb -v:
Bus 003 Device 004: ID 041e:4130 Creative Technology, Ltd Zen Micro (mtp)
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x041e Creative Technology, Ltd
idProduct 0x4130 Zen Micro (mtp)
bcdDevice1.00
iManufacturer 1 Creative Technology Ltd
iProduct2 Creative Zen Micro
iSerial 3 01052551C6038F82
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 16 Configuration 1
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 0 (Defined at Interface level)
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 33 MTP Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes3
Transfer TypeInterrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 4
Device Qualifier (for other device speed):
bLength10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
bNumConfigurations 1
Device Status: 0x128a
(Bus Powered)
Remote Wakeup Enabled
The story goes that Microsoft was not allowed to use the scheme
in the specification before publication, so they stuck a custom
scheme in there and fallback methods to figure out if a
device is MTP.
And since device manufacturers only test their devices against
Windows, and since the Windows MTP stack is *very* tolerant
all kinds of weird stuff exist out there. And we get to deal with
it...
So for not-so-bad behaved devices this question is relevant:
> I realize that you still have to probe to find out whether it supports
> MTP or just PTP, but won't it help if this probing could be limited to
> only 06/01/01 interfaces?
So in the current device rule we have to match:
ATTR{bDeviceClass}=="00|02|06|ef|ff"
00 = unspecified, check interfaces, which cannot currently be done by udev
rules, I think, so we need to perform libusb_open() which will
screw up some devices...
02 = comms device class, a lot of phones use this
06 = yay! PTP yes among others...
ef = no idea why this is used, but
Re: autodetect USB MTP device characteristics without libusb_open()
On Wed, Nov 7, 2012 at 12:28 AM, Bjørn Mork wrote: > Linus Walleij writes: >> So all MTP devices manufactured before that spec, and numerous produced >> after that spec came out, and several still being produced don't use the >> class code, i.e. they violate the spec. But we still have to detect them >> somehow. > > Yes, I feared so. But it still seemed likely that the non conforming > ones could be managed as a whitelist, if only most of the new ones were > using the standard class codes. I don't know if most of them do actually. Here is another device I bought just the other day, Philips GoGear Vibe: Bus 002 Device 008: ID 0471:20e5 Philips (or NXP) Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0471 Philips (or NXP) idProduct 0x20e5 bcdDevice0.01 iManufacturer 1 Philips iProduct2 GoGear ViBE iSerial 5 40049D0CDC190002DCE4AF289C19 bNumConfigurations 2 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 3 USB/MSC LCD Player bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 4 USB/MSC LCD Player Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 16 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 2 iConfiguration 3 USB/MSC LCD Player bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 4 USB/MSC LCD Player Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 16 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Define
Re: autodetect USB MTP device characteristics without libusb_open()
On Wed, Nov 7, 2012 at 2:54 AM, Peter Stuge wrote:
>> - some devices bug out on libusb_open()
>
> Please send me a debug log from when this happens. Exact steps are at
> http://libusb.org/wiki/debug
I'll see what I can dig up. Mostly this has come from upstream,
Alessio do you have something at hand for these color calibration
crashes you've been seeing?
>> I have added code like below to libmtp to instead inspect sysfs
>> *before* starting any libusb-based business.
> ..
>> - Is this a good idea?
>
> It's a horrible hack and I don't think it's a very good idea. I
> understand that you have some real broken devices to deal with,
> but let's just make libusb work for you instead.
Yeah I would prefer that ... currently I'm just adding to the
udev blacklist, looking like this:
# Some sensitive devices we surely don't wanna probe
# Color instruments
ATTR{idVendor}=="0670", GOTO="libmtp_rules_end"
ATTR{idVendor}=="0765", GOTO="libmtp_rules_end"
ATTR{idVendor}=="085c", GOTO="libmtp_rules_end"
ATTR{idVendor}=="0971", GOTO="libmtp_rules_end"
# Canon scanners that look like MTP devices (PID 0x22nn)
ATTR{idVendor}=="04a9", ATTR{idProduct}=="22*", GOTO="libmtp_rules_end"
# Canon digital camera (EOS 3D) that looks like MTP device (PID 0x3113)
ATTR{idVendor}=="04a9", ATTR{idProduct}=="3113", GOTO="libmtp_rules_end"
# Sensitive Atheros devices that look like MTP devices
ATTR{idVendor}=="0cf3", GOTO="libmtp_rules_end"
# Sensitive Atmel JTAG programmers
ATTR{idVendor}=="03eb", GOTO="libmtp_rules_end"
> Also, look into scanf() and friends, they are highly underrated! :)
Yes... hm.
>> - What is the scary business that libusb_open() does that makes
>> a lot of substandard USB devices totally freak out?
>
> I can only confirm that opening does not talk to the device.
> Enumeration can. But really, I need to see the debug log, and
> usbmon output from when this happens would certainly also be nice.
So we're not just doing this but also retieveing the descriptor,
looping over configs, interfaces, and checking the number of
endpoints. At this point if the endpoints != 3 we bail out.
> Linus Walleij wrote:
>> you cannot open a session to an MTP device in say a udev script,
>> then close it and open another session later
>
> Maybe don't do that. Open the session in the udev-driven program, and
> do not close it. Find a way to tell libmtp that a session is already
> open, and only OpenSession when one isn't. It isn't pretty, but..
Yeah :-/ so the *proper* solution (which we have though about)
is to do a pulseaudio-sized task by introducing an MTP hog daemon
that will proxy all MTP traffic, then patch *all* programs using
MTP to go through that daemon.
That would also solve the issue of concurrency we have
today.
However I don't have cycles enough to take on this and
I'm waiting for someone else to come along as it is today.
Yours,
Linus Walleij
--
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: fix switch off blocked in u_serial
From: Haipeng YU
When a device is switched off by software, gserial_cleanup will
be called, and switch off will be blocked in this function
because wake_up_interruptible() in gs_close() can not wake_up
the wait_event() in gserial_cleanup(), it should be changed to
wake_up() to match the wait_event().
Signed-off-by: Haipeng YU
Signed-off-by: Linus Walleij
---
drivers/usb/gadget/u_serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/u_serial.c b/drivers/usb/gadget/u_serial.c
index f173952..2d074ba 100644
--- a/drivers/usb/gadget/u_serial.c
+++ b/drivers/usb/gadget/u_serial.c
@@ -887,7 +887,7 @@ static void gs_close(struct tty_struct *tty, struct file
*file)
pr_debug("gs_close: ttyGS%d (%p,%p) done!\n",
port->port_num, tty, file);
- wake_up_interruptible(&port->port.close_wait);
+ wake_up(&port->port.close_wait);
exit:
spin_unlock_irq(&port->port_lock);
}
--
1.7.11.3
--
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: autodetect USB MTP device characteristics without libusb_open()
On Thu, Nov 8, 2012 at 3:38 PM, Bjørn Mork wrote:
> Linus Walleij writes:
>> One of them is an MTP interface, and will respond to MTP traffic.
>> I think the magic OS handshake make that come into play...
>> So Linux erroneously tries to use MSC on it, and we have to
>> use libusb_detach_kernel_driver() and then use the interface.
>>
>> And then it works.
>>
>> This type of misbehaviour is not uncommon, I just took some
>> device at random, there are literally millions of these.
>
> That may be. But I absolutely refuse thinking about the possibility of
> some udev rule probing all mass storage devices just because of
> completely broken devices like this one...
No, in this case I only use whitelisting, so we know of these
specific devices.
> OK, filtering on 3 endpoint mass storage devices will eliminate most of
> the false positives, but still. Ugly.
Is there a way to write a udev rule to only probe devices
with 3 endpoints? I have tried this but never found any :-(
>> (...)
>> # Autoprobe vendor-specific, communication and PTP devices
>> ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1",
>> ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{libsane_matched}!="yes",
>> ATTR{bDeviceClass}=="00|02|06|ef|ff", PROGRAM="mtp-probe
>> /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", RESULT=="1",
>> SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"
>
> I believe this rule is dangerously broad. It probes so many non MTP
> devices that I honestly do not understand why you need to except any
> device at all. Your config avoids probing a few whitelisted MTP devices
> but ends up probing evey other type of USB device instead. That does
> not make sense.
I'm only probing class 00, 02, 06, ef and ff.
>> So that rather horrible rule avoids probing:
>>
>> - Devices we just detected in the whitelist
>> - Color measurement or scanner devices (these have been
>> prone to errors...)
>> - Then check only the classes we mentioned
>
> Yes, but "only the classes we mentioned" includes *all* composite
> devices out there. To me that seems completely unacceptable, but others
> may disagree.
Well, the thing is that this is actually what Windows is doing.
If you insert any kind of device into a Windows machine, and Windows
does not find a .inf file for it, it will be probed for the OS descriptor.
I think it avoids anything with != 3 endpoints of the right type
though.
And basically that is how MTP devices "just work" on Windows,
as far as I can tell.
> IMHO, you should limit the probing to the devices which you have reason
> to believe may support MTP. That is
> - devices with one or more PTP interfaces
> - possibly devices with 3 endpoint Mass Storage interfaces, like the
>one you showed above
>
> The rest will have to be witelisted based on pid:vid.
So the current code means the probe program will actually
exit if it doesn't find the right number of endpoints and
the right type of endpoints.
> But this is my opinion, only..
Yeah, if it was only me I would prefer to only have a
whitelist. But then I also package this for Fedora, and
it turns out that users want MTP devices to "just work"
just like they "just work" on Windows. And for that this
program is crucial...
>>> Do you know if these early devices support the typical Microsoft
>>> descriptors? I.e. the 0xee string descriptor with "MSFT100"
>>> and its friends?
>>
>> Almost all devices support this. (There are exceptions even to this.)
>> So this is what we do as a last resort, if we can't figure it out
>> some other way.
>
> I do not understand why that has to be the last resort. I would expect
> this method to be very reliable since Microsoft has been heavily
> involved all the way here. It's an ugly non-standard method of course,
> but being pragmatic we do have to use whatever method the vendors have
> implemented and *tested*. Which most likely is what they have observed
> som random Windows version doing.
So there are devices that crash if you ask for descriptor 0xEE.
The way Windows gets around it is *probably* by using some
of the heuristics above, like making sure that there is an interface
with 3 endpoints and so on.
I don't know for sure :-(
I also think that a few devices actually crash on Windows.
But they have this concept of an .inf file, so the first time
you insert an alien device, you are asked for an .inf file
with some driver information. Then you can bind that
VID+PID to a specific driver, and then they will not look
further the next time the same device is plugged
Re: [PATCH 01/10] usb: musb: ux500: move channel number knowledge into the driver
Now that Fabio has written a few patches to this driver I'd like his help in reviewing this series, can you make sure he gets a copy? Also please include Praveena and Mian, thanks. On Tue, Apr 23, 2013 at 5:03 PM, Lee Jones wrote: > For all ux500 based platforms the maximum number of end-points are used. > Move this knowledge into the driver so we can relinquish the burden from > platform data. This also removes quite a bit of complexity from the driver > and will aid us when we come to enable the driver for Device Tree. > > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > Signed-off-by: Lee Jones Looks good to me. Acked-by: Linus Walleij Yours, Linus Walleij -- 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 02/10] usb: musb: ux500: move the MUSB HDRC configuration into the driver
On Tue, Apr 23, 2013 at 5:03 PM, Lee Jones wrote: > The MUSB HDRC configuration never changes between each of the ux500 > supported platforms, so there's little point passing it though platform > data. If we set it in the driver instead, we can make good use of it > when booting with either ATAGs or Device Tree. > > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > Signed-off-by: Lee Jones Acked-by: Linus Walleij Yours, Linus Walleij -- 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 03/10] usb: musb: ux500: take the dma_mask from coherent_dma_mask
On Tue, Apr 23, 2013 at 5:03 PM, Lee Jones wrote: > The dma_mask will always be the same as the coherent_dma_mask, so let's > cut down on the platform_data burden and set it as such in the driver. > This also saves us from supporting it separately when we come to enable > this driver for Device Tree. > > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > Signed-off-by: Lee Jones And makes it way more readable too! Acked-by: Linus Walleij Yours, Linus Walleij -- 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 04/10 v2] usb: musb: ux500: harden checks for platform data
On Wed, Apr 24, 2013 at 5:04 PM, Lee Jones wrote: > In its current state, the ux500-musb driver uses platform data pointers > blindly with no prior checking. If no platform data pointer is passed > this will Oops the kernel. In this patch we ensure platform data and > board data are present prior to using them. > > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > Signed-off-by: Lee Jones Acked-by: Linus Walleij Yours, Linus Walleij -- 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/10 v2] usb: musb: ux500: attempt to find channels by name before using pdata
On Wed, Apr 24, 2013 at 5:05 PM, Lee Jones wrote: > If we can ever get to a state where we can solely search for DMA channels > by name, this will almost completely alleviate the requirement to pass > copious amounts of information though platform data. Here we take the > first step towards this. The next step will be to enable Device Tree > complete with name<->event_line mapping. > > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > Signed-off-by: Lee Jones Looking good, would be nice if Arnd checked it tho. Acked-by: Linus Walleij Yours, Linus Walleij -- 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 06/10 v2] usb: musb: ux500: add device tree probing support
On Wed, Apr 24, 2013 at 9:43 AM, Lee Jones wrote: > usb: musb: ux500: add device tree probing support > > This patch will allow ux500-musb to be probed and configured solely from > configuration found in Device Tree. > > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > Signed-off-by: Lee Jones This patch needs to be CC: devicetree-discuss. But looks good to me! Acked-by: Linus Walleij Yours, Linus Walleij -- 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 01/39] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > During the initial setup of a logical channel, it is necessary to unmask > the GIM in order to receive generated terminal count and error interrupts. > We're separating out this required code so it will be possible to move > the remaining code in d40_phy_cfg(), which is mostly runtime configuration > into the runtime_config() routine. > > Cc: Vinod Koul > Cc: Dan Williams > Cc: Per Forlin > Cc: Rabin Vincent > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones Tentatively applied to my ux500-dma40 branch. This lacks an ACK from Vinod... I cannot get any of this stack of patches up to ARM SoC before I have Vinod's ACK on all hitting drivers/dma/* Yours, Linus Walleij -- 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 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > All configuration left in d40_phy_cfg() is runtime configurable and > there is already a call into it from d40_runtime_config(), so let's > rely on that. > > Acked-by: Vinod Koul > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones You forgot to update the commit message, but I saw that you fixed what I asked for so I just went in and edited the commit message and applied it. Yours, Linus Walleij -- 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 03/39] dmaengine: ste_dma40: Don't configure runtime configurable setup during allocate
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > Using the dmaengine API, allocating and configuring a channel are two > separate actions. Here we're removing logical channel configuration from > the channel allocating routines. This commit message is also incorrect, but I amended it. Besides, when I amend commit messages I make sure I really understand what is going on so no big deal... > Cc: Vinod Koul > Cc: Dan Williams > Cc: Per Forlin > Cc: Rabin Vincent > Signed-off-by: Lee Jones I still need Vinod's ACK on this before I send it anywhere. Patch applied! Yours, Linus Walleij -- 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 04/39] ARM: ux500: Stop passing UART's platform data for Device Tree boots
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> It was required to pass DMA channel configuration information to the
> UART driver before the new DMA API was in place. Now that it is, and
> is fully compatible with Device Tree we can stop doing that.
>
> Reviewed-by: Linus Walleij
> Signed-off-by: Lee Jones
> ---
> arch/arm/mach-ux500/cpu-db8500.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/cpu-db8500.c
> b/arch/arm/mach-ux500/cpu-db8500.c
> index 38ebf2b..9b26fe2 100644
> --- a/arch/arm/mach-ux500/cpu-db8500.c
> +++ b/arch/arm/mach-ux500/cpu-db8500.c
> @@ -230,9 +230,9 @@ static struct of_dev_auxdata u8500_auxdata_lookup[]
> __initdata = {
> /* Requires call-back bindings. */
> OF_DEV_AUXDATA("arm,cortex-a9-pmu", 0, "arm-pmu",
> &db8500_pmu_platdata),
> /* Requires DMA bindings. */
> - OF_DEV_AUXDATA("arm,pl011", 0x8012, "uart0", &uart0_plat),
> - OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", &uart1_plat),
> - OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", &uart2_plat),
> + OF_DEV_AUXDATA("arm,pl011", 0x8012, "uart0", NULL),
> + OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", NULL),
> + OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", NULL),
> OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0", &ssp0_plat),
> OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0", &mop500_sdi0_data),
> OF_DEV_AUXDATA("arm,pl18x", 0x80118000, "sdi1", &mop500_sdi1_data),
OK dma_request_slave_channel() is upstream in the PL011 driver,
so applied!
Yours,
Linus Walleij
--
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/39] ARM: ux500: Stop passing MMC's platform data for Device Tree boots
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > It was required to pass DMA channel configuration information to the > MMC driver before the new DMA API was in place. Now that it is, and > is fully compatible with Device Tree we can stop doing that. > > Reviewed-by: Linus Walleij > Signed-off-by: Lee Jones So since the use of dma_request_slave_channel() is not upstream, I guess this will break DMA use (i.e slow down transfers!) on all device tree boots? I'd be happy to apply it once the MMCI patch is in linux-next indicating there may just be a window in the merge period where it falls back to IRQ mode, but I don't want to disable DMA on DT boots for an entire kernel cycle just like that. Not applied as of yet. Yours, Linus Walleij -- 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 07/39] dmaengine: ste_dma40: Only use addresses passed as configuration information
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > Addresses are passed in from the client's driver via the invocation of > dmaengine_slave_config(), so there's no need to fetch them from platform > data too, hardwired or otherwise. This is a great step forward, as it > elevates a large burden from platform data in the way of a look-up > table. > > Signed-off-by: Lee Jones This should be the case even without patch 5 & 6 so patch tentatively applied. Waiting for Vinod's ACK on this though. Yours, Linus Walleij -- 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 08/39] dmaengine: ste_dma40: Remove redundant address fetching function
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > Addresses are now stored in local data structures and are easy to > obtain, thus a specialist function used to fetch them is now surplus > to requirement. > > Signed-off-by: Lee Jones Patch tentatively applied, waiting for Vinod's ACK. Yours, Linus Walleij -- 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 06/39] ARM: ux500: Move SDI (MMC) and UART devices under more descriptive heading
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > Now DMA DT bindings exist and are in use by he MMC and UART drivers, it > should be possible to remove them from the auxdata structure. However, > after doing so the drivers fail. Common clk is still reliant on the > dev_name() call to do device name matching, which will fail due to the > fact that Device Tree naming differs somewhat do the more traditional > conventions. > > Reviewed-by: Linus Walleij > Signed-off-by: Lee Jones Cannot be applied due to dependency on 5/39. Yours, Linus Walleij -- 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 09/39] ARM: ux500: Remove DMA address look-up table
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > DMA addresses are now passed as part of the dmaengine API by invoking > dmaengine_slave_config(). So there's no requirement for the DMA40 > driver to look them up in a table provided by platform data. This > method does not fit in well using Device Tree either. > > Signed-off-by: Lee Jones Good riddance. Patch tentatively applied. Awaiting Vinod's ACK for include/platform_data/*. Yours, Linus Walleij -- 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 10/39] dmaengine: ste_dma40: Correct copy/paste error
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > 'struct stedma40_half_channel_info's header comment says that it's > called 'struct stedma40_chan_cfg'. Let's straighten that out. > > Signed-off-by: Lee Jones Patch tentatively applied waiting for Vinod's ACK. Yours, Linus Walleij -- 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 12/39] crypto: ux500/hash - Prepare clock before enabling it
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > If we fail to prepare the ux500-hash clock before enabling it the > platform will fail to boot. Here we insure this happens. > > Cc: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-cry...@vger.kernel.org > Acked-by: Arnd Bergmann > Acked-by: Ulf Hansson > Signed-off-by: Lee Jones This patch seems to be totally independent of the other stuff in the patch series, and it even seems like an -rc fix to me (I don't think the crypto device works without this). This should go into the crypto tree? Else please convince Herbert to give his ACK on this before I apply it. Yours, Linus Walleij -- 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 13/39] crypto: ux500/hash - Set DMA configuration though dma_slave_config()
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > The DMA controller currently takes configuration information from > information passed though dma_channel_request(), but it shouldn't. > Using the API, the DMA channel should only be configured during > a dma_slave_config() call. > > Cc: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-cry...@vger.kernel.org > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones I think I need to stop applying here and wait for an ACK from Herbert on everything hitting drivers/crypto. If I get Vinod's ACK for the previous patches I can send an initial pull request on that and then follow up with the rest. Yours, Linus Walleij -- 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 15/39] crypto: ux500/cryp - Prepare clock before enabling it
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > If we fail to prepare the ux500-cryp clock before enabling it the > platform will fail to boot. Here we insure this happens. > > Cc: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-cry...@vger.kernel.org > Acked-by: Ulf Hansson > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones This patch also looks like -rc series stuff for the crypto tree. BTW: these two clk_prepare_enable() patches are Acked-by: Linus Walleij Yours, Linus Walleij -- 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 11/39] ARM: ux500: Remove unnecessary attributes from DMA channel request pdata
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > DMA data width and packet size information is only required at channel > configuration time. Any information passed from platform data is passed > directly to the DMA40 driver to use during channel allocation, but these > pieces of information are subsequently ignored by the driver, so we may > as well remove them. > > Signed-off-by: Lee Jones Patch applied. Yours, Linus Walleij -- 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 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > For all ux500 based platforms the maximum number of end-points are used. > Move this knowledge into the driver so we can relinquish the burden from > platform data. This also removes quite a bit of complexity from the driver > and will aid us when we come to enable the driver for Device Tree. > > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > Acked-by: Linus Walleij > Acked-by: Fabio Baltieri > Signed-off-by: Lee Jones I guess this stuff is dependent on the stuff Fabio has recently sent to Felipe for the ux500 musb DMA so these musb patches should primarily go through his tree. It seems like the later changes to the platform code (arch/arm/mach-ux500) may be sufficiently orthogonal so it can be done out-of-order? I can't merge any of this without Felipes ACKs in any case. Yours, Linus Walleij -- 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 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Wed, May 15, 2013 at 10:14 PM, Fabio Baltieri wrote: > On Wed, May 15, 2013 at 07:18:01PM +0200, Linus Walleij wrote: >> On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: >> >> > For all ux500 based platforms the maximum number of end-points are used. >> > Move this knowledge into the driver so we can relinquish the burden from >> > platform data. This also removes quite a bit of complexity from the driver >> > and will aid us when we come to enable the driver for Device Tree. >> > >> > Cc: Felipe Balbi >> > Cc: linux-usb@vger.kernel.org >> > Acked-by: Linus Walleij >> > Acked-by: Fabio Baltieri >> > Signed-off-by: Lee Jones >> >> I guess this stuff is dependent on the stuff Fabio has recently sent to >> Felipe for the ux500 musb DMA so these musb patches should >> primarily go through his tree. > > Not really, I only sent some coding style fix for the dma driver, as > almost all of my work was in the usb phy files. I also checked my > latest series against Lee's tree and the two seems to merge without any > conflict, so as far as I'm concerned it's really up to you and Felipe. OK so Felipe can merge these smallish patches to musb, fine... The other (DMA) stuff needs to be merged together with the rest of the DMA40 series, so here basically Felipe needs an indication if he can ACK it so I merge it through ARM SoC without colissions and it sounds like we can make the assumption that this will work. Yours, Linus Walleij -- 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 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
On Thu, May 16, 2013 at 12:59 PM, Lee Jones wrote: > On Thu, 16 May 2013, Vinod Koul wrote: > >> On Thu, May 16, 2013 at 08:25:57AM +0100, Lee Jones wrote: >> > On Thu, 16 May 2013, Vinod Koul wrote: >> > >> > > On Wed, May 15, 2013 at 10:51:25AM +0100, Lee Jones wrote: >> > > > All configuration left in d40_phy_cfg() is runtime configurable and >> > > > there is already a call into it from d40_runtime_config(), so let's >> > > > rely on that. >> > > > >> > > > Acked-by: Vinod Koul >> > > That needs up update! >> > >> > Ah, where did I get that from that? >> > >> > Was that my mistake, or was this in the MAINTAINERS file? >> Certainly not in MAINTAINERS file :) > > My bad then, sorry. > > Linus, > > Would you be kind enough to fix it please, as it's in your tree now. I've fixed it up! Yours, Linus Walleij -- 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 12/39] crypto: ux500/hash - Prepare clock before enabling it
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > If we fail to prepare the ux500-hash clock before enabling it the > platform will fail to boot. Here we insure this happens. > > Cc: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-cry...@vger.kernel.org > Acked-by: Arnd Bergmann > Acked-by: Ulf Hansson > Signed-off-by: Lee Jones Patch applied to my dma40 branch with Herbert's ACK. Yours, Linus Walleij -- 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 13/39] crypto: ux500/hash - Set DMA configuration though dma_slave_config()
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > The DMA controller currently takes configuration information from > information passed though dma_channel_request(), but it shouldn't. > Using the API, the DMA channel should only be configured during > a dma_slave_config() call. > > Cc: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-cry...@vger.kernel.org > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones Patch applied to my dma40 branch with Herbert's ACK. Yours, Linus Walleij -- 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 14/39] ARM: ux500: Stop passing Hash DMA channel config information though pdata
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > DMA channel configuration information should be setup in the driver. > The Ux500 Hash driver now does this, so there's no need to send it > though here too. > > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones Patch applied now that the deps are in! Yours, Linus Walleij -- 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 15/39] crypto: ux500/cryp - Prepare clock before enabling it
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > If we fail to prepare the ux500-cryp clock before enabling it the > platform will fail to boot. Here we insure this happens. > > Cc: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-cry...@vger.kernel.org > Acked-by: Ulf Hansson > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones Patch applied with Herbert's ACK. Yours, Linus Walleij -- 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 16/39] crypto: ux500/cryp - Set DMA configuration though dma_slave_config()
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > The DMA controller currently takes configuration information from > information passed though dma_channel_request(), but it shouldn't. > Using the API, the DMA channel should only be configured during > a dma_slave_config() call. > > Cc: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-cry...@vger.kernel.org > Acked-by: Arnd Bergmann > Acked-by: Linus Walleij > Signed-off-by: Lee Jones Patch applied with Herbert's ACK. Thanks, Linus Walleij -- 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 18/39] crypto: ux500/[cryp|hash] - Show successful start-up in the bootlog
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > The Cryp driver is currently silent and the Hash driver prints the > name of its probe function unnecessarily. Let's just put a nice > descriptive one-liner there instead. > > Cc: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-cry...@vger.kernel.org > Acked-by: Arnd Bergmann > Reviewed-by: Linus Walleij > Signed-off-by: Lee Jones Patch applied with Herbert's ACK. Thanks, Linus Walleij -- 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 19/39] ARM: ux500: Register Cyrp and Hash platform drivers on Snowball
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > These drivers are now operational and even use the latest common clk > and DMA APIs. There's no reason why we shouldn't start them up now. > > Reviewed-by: Linus Walleij > Signed-off-by: Lee Jones Patch applied now that the deps are in place. Yours, Linus Walleij -- 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 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > For all ux500 based platforms the maximum number of end-points are used. > Move this knowledge into the driver so we can relinquish the burden from > platform data. This also removes quite a bit of complexity from the driver > and will aid us when we come to enable the driver for Device Tree. > > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > Acked-by: Linus Walleij > Acked-by: Fabio Baltieri > Signed-off-by: Lee Jones I have now gone over and collected ACKs etc for the patches up until here. Now you need Felipe's consent to proceed with the MUSB changes through my tree. Yours, Linus Walleij -- 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 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Tue, May 28, 2013 at 6:27 PM, Felipe Balbi wrote: > On Wed, May 15, 2013 at 07:18:01PM +0200, Linus Walleij wrote: >> I can't merge any of this without Felipes ACKs in any >> case. > > Do you want to take this yourself ? I haven't fully read the series yet, > but seems like this depends on the rest of the series. If you want to > take it, let me know I can ack the patches as soon as I'm done > reviewing. Yes please. They are dependent on a stash of patches that that has recently landed in the ARM SoC tree, so currently they need to follow those through the same tree, which is where I funnel all the ux500 stuff. Yours, Linus Walleij -- 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 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > For all ux500 based platforms the maximum number of end-points are used. > Move this knowledge into the driver so we can relinquish the burden from > platform data. This also removes quite a bit of complexity from the driver > and will aid us when we come to enable the driver for Device Tree. > > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > Acked-by: Linus Walleij > Acked-by: Fabio Baltieri > Signed-off-by: Lee Jones Patch applied to my dma40 branch with Felipe's ACK. Thanks! Linus Walleij -- 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 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Wed, May 29, 2013 at 7:57 PM, Felipe Balbi wrote: > On Wed, May 15, 2013 at 10:51:43AM +0100, Lee Jones wrote: >> For all ux500 based platforms the maximum number of end-points are used. >> Move this knowledge into the driver so we can relinquish the burden from >> platform data. This also removes quite a bit of complexity from the driver >> and will aid us when we come to enable the driver for Device Tree. >> >> Cc: Felipe Balbi >> Cc: linux-usb@vger.kernel.org >> Acked-by: Linus Walleij >> Acked-by: Fabio Baltieri >> Signed-off-by: Lee Jones > > for drivers/usb/musb > > Acked-by: Felipe Balbi Is that only for this patch 20/39 or also 21, 22 & 23? Poke us if we should re-send them... Yours, Linus Walleij -- 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 21/39] usb: musb: ux500: move the MUSB HDRC configuration into the driver
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > The MUSB HDRC configuration never changes between each of the ux500 > supported platforms, so there's little point passing it though platform > data. If we set it in the driver instead, we can make good use of it > when booting with either ATAGs or Device Tree. > > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > Acked-by: Linus Walleij > Acked-by: Fabio Baltieri > Signed-off-by: Lee Jones Tentatively applied with Felipe's ACK. Yours, Linus Walleij -- 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 22/39] usb: musb: ux500: take the dma_mask from coherent_dma_mask
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > The dma_mask will always be the same as the coherent_dma_mask, so let's > cut down on the platform_data burden and set it as such in the driver. > This also saves us from supporting it separately when we come to enable > this driver for Device Tree. > > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > Acked-by: Linus Walleij > Acked-by: Fabio Baltieri > Signed-off-by: Lee Jones Tentatively applied with Felipe's ACK. Yours, Linus Walleij -- 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 23/39] usb: musb: ux500: harden checks for platform data
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > In its current state, the ux500-musb driver uses platform data pointers > blindly with no prior checking. If no platform data pointer is passed > this will Oops the kernel. In this patch we ensure platform data and > board data are present prior to using them. > > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > Acked-by: Fabio Baltieri > Signed-off-by: Lee Jones Tentatively applied with Felipe's ACK. Yours, Linus Walleij -- 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 24/39] usb: musb: ux500: attempt to find channels by name before using pdata
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > If we can ever get to a state where we can solely search for DMA channels > by name, this will almost completely alleviate the requirement to pass > copious amounts of information though platform data. Here we take the > first step towards this. The next step will be to enable Device Tree > complete with name<->event_line mapping. > > Cc: Felipe Balbi > Cc: linux-usb@vger.kernel.org > Acked-by: Linus Walleij > Acked-by: Fabio Baltieri > Signed-off-by: Lee Jones Tentatively applied with Felipe's ACK. Yours, Linus Walleij -- 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 25/39] usb: musb: ux500: add device tree probing support
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > This patch will allow ux500-musb to be probed and configured solely from > configuration found in Device Tree. > > Cc: Felipe Balbi > Cc: Rob Herring > Cc: linux-usb@vger.kernel.org > Cc: devicetree-disc...@lists.ozlabs.org > Acked-by: Linus Walleij > Acked-by: Fabio Baltieri > Signed-off-by: Lee Jones Tentatively applied with Felipe's ACK. Yours, Linus Walleij -- 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 26/39] ARM: ux500: Add an auxdata entry for MUSB for clock-name look-up
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > The recently DT:ed MUSB driver will require clock-name by device-name > look-up capability, until common clk has is properly supported by the > ux500 platform. > > Acked-by: Linus Walleij > Acked-by: Fabio Baltieri > Signed-off-by: Lee Jones Applied to my ux500-devicetree branch. Yours, Linus Walleij -- 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 27/39] ARM: ux500: Remove ux500-musb platform registation when booting with DT
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > Now the ux500-musb driver has been enabled for Device Tree, there is no > requirement to register it from platform code. > > Acked-by: Fabio Baltieri > Signed-off-by: Lee Jones Patch applied to my ux500-dma40 branch on top of the musb stuff. Yours, Linus Walleij -- 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 28/39] ARM: ux500: Remove empty function u8500_of_init_devices()
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > As promised, now all devices which resided in u8500_of_init_devices() > have been enabled for Device Tree, we can completely remove it. > > Acked-by: Fabio Baltieri > Signed-off-by: Lee Jones Applied on my ux500-dma40 branch. And this is looking real good now! Thanks! Linus Walleij -- 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 29/39] dmaengine: ste_dma40: Use the BIT macro to replace ugly '(1 << x)'s
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > The aim is to make the code that little more readable. > > Acked-by: Vinod Koul > Acked-by: Arnd Bergmann > Reviewed-by: Linus Walleij > Signed-off-by: Lee Jones Patch applied to my ux500-dma40 branch. Yours, Linus Walleij -- 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 30/39] ARM: ux500: Replace ST-E's home-brew DMA direction definition with the generic one
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > STEDMA40_*_TO_* direction definitions are identical in all but name to > the pre-defined generic DMA_*_TO_* ones. Let's make things easy by not > duplicating such things. > > Signed-off-by: Lee Jones Vinod, I'm lacking your ACK on this patch, but have tentatively queued it anyway. Maybe you missed it? Yours, Linus Walleij -- 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 31/39] dmaengine: ste_dma40: Replace ST-E's home-brew DMA direction defs with generic ones
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > STEDMA40_*_TO_* direction definitions are identical in all but name to > the pre-defined generic DMA_*_TO_* ones. Let's make things easy by not > duplicating such things. > > Cc: Vinod Koul > Cc: Dan Williams > Cc: Per Forlin > Cc: Rabin Vincent > Signed-off-by: Lee Jones Patch applied to my dma40 branch with Vinod's ACK. Yours, Linus Walleij -- 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 32/39] ARM: ux500: Remove recently unused stedma40_xfer_dir enums
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > We're now using the transfer direction definitions provided by the DMA > sub-system, so the home-brew ones have become obsolete. > > Signed-off-by: Lee Jones Tentatively applied, also missing Vinod's ACK on this, but it seems it was implicitly ACKed in the discussion on patch 31. Yours, Linus Walleij -- 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 33/39] dmaengine: ste_dma40_ll: Use the BIT macro to replace ugly '(1 << x)'s
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > The aim is to make the code that little more readable. > > Cc: Vinod Koul > Cc: Dan Williams > Cc: Per Forlin > Cc: Rabin Vincent > Signed-off-by: Lee Jones Patch applied with Vinod's ACK. Yours, Linus Walleij -- 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 34/39] dmaengine: ste_dma40: Convert data_width from register bit format to value
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> When a DMA client requests and configures a DMA channel, it requests
> data_width in Bytes. The DMA40 driver then swiftly converts it over to
> the necessary register bit value. Unfortunately, for any subsequent
> calculations we have to shift '1' by the bit pattern (1 << data_width)
> times to make any sense of it.
>
> This patch flips the semantics on its head and only converts the value
> to its respective register bit pattern when writing to registers. This
> way we can use the true data_width (in Bytes) value.
>
> Cc: Vinod Koul
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Rabin Vincent
> Signed-off-by: Lee Jones
Patch applied with what I interpret as Vinod's ACK
("okay..." statement on last reply.)
Yours,
Linus Walleij
--
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 35/39] dmaengine: ste_dma40_ll: Replace meaningless register set with comment
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > Unsure of the author's intentions, rather than just removing the nop, > we're replacing it with a comment containing the possible intention > of the statement OR:ing with 0. > > Cc: Vinod Koul > Cc: Dan Williams > Cc: Per Forlin > Cc: Rabin Vincent > Signed-off-by: Lee Jones Tentatively applied. Missing Vinod's ACK. Yours, Linus Walleij -- 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 36/39] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote: > At this moment in time the memcpy channels which can be used by the D40 > are fixed, as each supported platform in Mainline uses the same ones. > However, platforms do exist which don't follow this convention, so > these will need to be tailored. Fortunately, these platforms will be DT > only, so this change has very little impact on platform data. > > Cc: Vinod Koul > Cc: Dan Williams > Cc: Per Forlin > Cc: Rabin Vincent > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones Patch applied with Vinod's ACK. Yours, Linus Walleij -- 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 37/39] ARM: ux500: Stop passing DMA platform data though AUXDATA
On Wed, May 15, 2013 at 11:52 AM, Lee Jones wrote: > The DMA platform data is now empty due to some recent refactoring, > so there is no longer a requirement to pass it though. > > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones Applied to dma40 branch, hm now I may get a conflict with all the AUXDATA changes in the devicetree branch. Oh well, I'll figure it out... Yours, Linus Walleij -- 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 38/39] dmaengine: ste_dma40: Fetch the number of physical channels from DT
On Wed, May 15, 2013 at 11:52 AM, Lee Jones wrote: > Some platforms insist on obscure physical channel availability. This > information is currently passed though platform data in internal BSP > kernels. Once those platforms land, they'll need to configure them > appropriately, so we may as well add the infrastructure. > > Cc: Vinod Koul > Cc: Dan Williams > Cc: Per Forlin > Cc: Rabin Vincent > Signed-off-by: Lee Jones Patch applied with Vinod's ACK. Yours, Linus Walleij -- 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 39/39] dmaengine: ste_dma40: Fetch disabled channels from DT
On Wed, May 15, 2013 at 11:52 AM, Lee Jones wrote: > Some platforms have channels which are not available for normal use. > This information is currently passed though platform data in internal > BSP kernels. Once those platforms land, they'll need to configure them > appropriately, so we may as well add the infrastructure. > > Cc: Vinod Koul > Cc: Dan Williams > Cc: Per Forlin > Cc: Rabin Vincent > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones Patch applied with Vinod's ACK. Yours, Linus Walleij -- 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
