On Fri, Jan 18, 2013 at 10:50:28AM +0800, Peter Chen wrote:
> +#ifdef CONFIG_PM
> +static int ci13xxx_imx_suspend(struct device *dev)
> +{
> + struct ci13xxx_imx_data *data =
> + platform_get_drvdata(to_platform_device(dev));
Is there a reason not to use dev_get_drvdata() here? Hi
On Fri, Jan 18, 2013 at 02:17:08PM +0200, Roger Quadros wrote:
> + tll->ch_clk = devm_kzalloc(dev, sizeof(struct clk * [tll->nch]),
> + GFP_KERNEL);
> + if (!tll->ch_clk) {
> + ret = -ENOMEM;
> + dev_err(dev, "Couldn't allo
On Fri, Jan 18, 2013 at 02:17:09PM +0200, Roger Quadros wrote:
> +/* only PHY and UNUSED modes don't need TLL */
> +#define omap_usb_mode_needs_tll(x) ((x != OMAP_USBHS_PORT_MODE_UNUSED) &&\
> + (x != OMAP_EHCI_PORT_MODE_PHY))
Growl.
These parens do not make
On Mon, Jan 21, 2013 at 05:07:36AM -0500, Chao Xie wrote:
> + mv_phy->extern_chip.head = devm_kzalloc(&pdev->dev,
> + sizeof(*mv_phy->extern_chip.head),
> + GFP_KERNEL);
> + if (mv_phy->extern_chip.head == NULL)
> +
epending on the
> number of clocks avaiable on the platform.
>
> Signed-off-by: Roger Quadros
> Reviewed-by: Felipe Balbi
Much better from the clk API usage, thanks.
Acked-by: Russell King
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a
This series cleans up phylib's MMD accessors, so that we have a common
way of accessing the Clause 45 register set.
The current situation is far from ideal - we have phy_(read|write)_mmd()
which accesses Clause 45 registers over Clause 45 accesses, and we have
phy_(read|write)_mmd_indirect(), whic
On Thu, Jan 19, 2017 at 11:42:47AM -0800, Florian Fainelli wrote:
> On 01/13/2017 07:20 AM, Russell King - ARM Linux wrote:
> > This series cleans up phylib's MMD accessors, so that we have a common
> > way of accessing the Clause 45 register set.
> >
> > The cur
On Wed, Sep 28, 2016 at 10:53:49AM +0300, Roger Quadros wrote:
> Hi,
>
> On 12/09/16 14:38, Roger Quadros wrote:
> > Hi Santosh & Russell,
> >
> > On 19/08/16 19:38, Santosh Shilimkar wrote:
> >>
> >> On 8/19/2016 12:30 AM, Roger Quadros wrote:
> >>> Hi Santosh,
> >>>
> >>
> > So I'm 99.9% co
On Wed, Jul 20, 2016 at 05:40:28PM +0800, Peter Chen wrote:
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 69426e6..0d05812 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -914,6 +914,16 @@ static int ci_hdrc_probe(struct platfor
On Thu, Jul 21, 2016 at 05:20:12PM +0800, Peter Chen wrote:
> On Thu, Jul 21, 2016 at 10:14:38AM +0100, Russell King - ARM Linux wrote:
> > On Wed, Jul 20, 2016 at 05:40:28PM +0800, Peter Chen wrote:
> > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
&
nal change.
The original commit doesn't mention which platform it was intended for
or what the problem was, which would've been helpful.
>
> Fixes: 6ce0d2001692 ("ARM: dma: Use dma_pfn_offset for dma address
> translation")
> Cc: sta...@vger.kernel.org
> Cc:
On Thu, Aug 18, 2016 at 09:55:55AM -0700, Santosh Shilimkar wrote:
> Hi Russell,
>
> On 8/18/2016 7:24 AM, Russell King - ARM Linux wrote:
> >On Wed, Aug 17, 2016 at 03:05:17PM +0300, Roger Quadros wrote:
> >>Since commit 6ce0d2001692 ("ARM: dma: Use d
On Mon, Aug 22, 2016 at 11:28:21AM -0400, Alan Stern wrote:
> On Fri, 19 Aug 2016, Russell King wrote:
>
> > ohci-omap doesn't need to include mach/irqs.h - nothing within this
> > driver needs anything from this header file. Remove this include.
> >
&g
On Fri, Aug 26, 2016 at 01:20:53PM -0400, Alan Stern wrote:
> On Fri, 26 Aug 2016, Russell King - ARM Linux wrote:
>
> > On Mon, Aug 22, 2016 at 11:28:21AM -0400, Alan Stern wrote:
> > > On Fri, 19 Aug 2016, Russell King wrote:
> > >
> > > > ohc
On Fri, Aug 26, 2016 at 01:18:25PM -0400, Alan Stern wrote:
> On Fri, 26 Aug 2016, Russell King wrote:
>
> > The neponset is a daughter board for the Assabet platform, which has a
> > SA chip on it. If we're initialising the SA OHCI, and we're
> > par
On Fri, Aug 26, 2016 at 02:20:50PM -0400, Alan Stern wrote:
> On Fri, 26 Aug 2016, Russell King - ARM Linux wrote:
>
> > On Fri, Aug 26, 2016 at 01:18:25PM -0400, Alan Stern wrote:
> > > On Fri, 26 Aug 2016, Russell King wrote:
> > >
> > > > The ne
On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> >
> > Hi Felipe and Arnd,
> >
> > It has been a while since the last response to this discussion, but we
> > haven't reached an agreement yet! Can we get to a conclusio
On Wed, Sep 07, 2016 at 05:29:01PM +0800, Peter Chen wrote:
> On Wed, Sep 07, 2016 at 10:52:46AM +0200, Arnd Bergmann wrote:
> > On Wednesday, September 7, 2016 3:44:28 PM CEST Peter Chen wrote:
> > >
> > > The pre-condition of DT function at USB HCD core works is the host
> > > controller device
On Fri, Mar 18, 2016 at 09:54:14AM +0800, Peter Chen wrote:
> Although I don't know what kinds of bugs it may have, it may be
> met before, otherwise, why most of platform drivers need to call
> dma_set_coherent_mask or dma_coerce_mask_and_coherent explicitly
See Documentation/DMA-API.txt, specifi
On Thu, Apr 28, 2016 at 09:37:08AM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Arnd Bergmann writes:
> >pointer and pass that in platform_data. This is really easy, it's
>
> Sorry but passing a struct device pointer in platform_data is
> ridiculous. Not to mention that, as I said before, we can'
Including phy.h and phy_fixed.h into net/dsa.h causes phy*.h to be an
unnecessary dependency for quite a large amount of the kernel. There's
very little which actually requires definitions from phy.h in net/dsa.h
- the include itself only wants the declaration of a couple of
structures and IFNAMSI
Hi,
This series cleans up the phylib MMD accessors. We have two accessors
at present, phy_(read|write)_mmd() and phy_(read|write)_mmd_indirect()
The _indirect methods access the MMD registers via a clause 22 phy,
whereas the non-_indirect methods acess via clause 45 accesses.
Current PHY-indepe
On Sun, Mar 19, 2017 at 03:30:38PM -0700, Florian Fainelli wrote:
> Le 03/19/17 à 03:59, Russell King - ARM Linux a écrit :
> > This series of patches does exactly that - we merge the functionality
> > of the indirect accesses into the clause 45 accessors, and use these
> >
This series cleans up phylib's MMD accessors, so that we have a common
way of accessing the Clause 45 register set.
The current situation is far from ideal - we have phy_(read|write)_mmd()
which accesses Clause 45 registers over Clause 45 accesses, and we have
phy_(read|write)_mmd_indirect(), whic
On Mon, Jan 28, 2013 at 10:17:33AM -0500, Alan Stern wrote:
> On Mon, 28 Jan 2013, Roger Quadros wrote:
>
> > Make use of devm_request_and_ioremap() and correct comment.
>
> Didn't a big patch come through recently converting all usages of
> devm_request_and_ioremap() to another function (I forg
On Tue, Jan 29, 2013 at 10:34:53AM -0500, Alan Stern wrote:
> On Mon, 28 Jan 2013, Russell King - ARM Linux wrote:
>
> > On Mon, Jan 28, 2013 at 10:17:33AM -0500, Alan Stern wrote:
> > > On Mon, 28 Jan 2013, Roger Quadros wrote:
> > >
> > > > Make use
On Wed, Feb 06, 2013 at 11:28:11AM +0530, Kishon Vijay Abraham I wrote:
> Added has_mailbox to the musb platform data to specify that omap uses
> an external mailbox (in control module) to communicate with the musb
> core during device connect and disconnect.
So, I've been through your five patche
On Wed, Feb 06, 2013 at 01:22:31PM +0200, Felipe Balbi wrote:
> there's a little more to it. When running allmodconfig,
> CONFIG_ARCH_MULTIPLATFORM is set but none of the other ARCHes
> (ARCH_OMAP, ARCH_AT91, ARCH_VERSATILE, etc) are set, so it turned out
> that the driver wasn't even included on m
On Tue, Mar 05, 2013 at 10:03:01AM +0800, Chao Xie wrote:
> On Mon, Mar 4, 2013 at 10:21 PM, Felipe Balbi wrote:
> > On Wed, Feb 20, 2013 at 11:07:11PM -0500, Chao Xie wrote:
> >> + for (i = 0; i < mv_phy->clks_num; i++) {
> >> + mv_phy->clks[i] = devm_clk_get(&pdev->dev,
> >> +
On Wed, Mar 06, 2013 at 04:24:58PM +0800, Chao Xie wrote:
> The clock numbers and names are depent of SOCes,
No they aren't. The clock names used to describe them in your documentation
may vary, but their _purpose_ for the sake of the device will be fixed -
and you should name them appropriately
On Wed, Mar 06, 2013 at 05:56:40PM +0800, Peter Chen wrote:
> root@freescale ~$ ci_hdrc ci_hdrc.0: Connected to host
> Unable to handle kernel paging request at virtual address 7f01171c
> pgd = 80004000
> [7f01171c] *pgd=4fa1e811, *pte=, *ppte=
> Internal error: Oops: 7 [#1] SMP ARM
On Tue, Jul 16, 2013 at 05:22:15PM +0200, Boris BREZILLON wrote:
> @@ -41,6 +41,10 @@ extern int usb_disabled(void);
>
> static void at91_start_clock(void)
> {
> + if (uclk) {
if (!IS_ERR(uclk)) {
> + clk_set_rate(uclk, 4800);
> + clk_prepare_enable(ucl
This started out as a request to look at the DMA mask situation, and how
to solve the issues which we have on ARM - notably how the DMA mask
should be setup.
However, I started off reviewing how the dma_mask and coherent_dma_mask
was being used, and what I found was rather messy, and in some cases
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > Use platform_device_register_full() for those drivers which can, to
> > avoid messing directly with DMA masks. This can only be done whe
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_c
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote:
> On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
> [...]
> > -dma_set_coherent_mask() will always be able to set the same or a
> > -smaller mask as dma_set_mask(). However for the rare case that a
> >
On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
> Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> > The DMA API requires drivers to call the appropriate dma_set_mask()
> > functions before doing any DMA mapping. Add this required call to
>
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
> On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> > register_platform_device_full() can setup the DMA mask provided the
> > appropriate member is set in struct platform_device_info. So lets
> >
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
> On Thu, 19 Sep 2013, Russell King wrote:
>
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask().
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote:
> 2013/9/19 Russell King - ARM Linux :
> > This email is only being sent to the mailing lists in question, not to
> > anyone personally. The list of individuals is far to great to do that.
> > I'm hoping n
On Mon, Oct 14, 2013 at 03:55:48PM +0800, Peter Chen wrote:
> On Mon, Oct 14, 2013 at 10:04:58AM +0200, Lothar Waßmann wrote:
> > Hi,
> >
> > Peter Chen wrote:
> > > This commit adds runtime and system power management support for
> > > chipidea core. The runtime pm support is controlled by glue
>
On Mon, Oct 14, 2013 at 05:04:21PM +0800, Peter Chen wrote:
> It is for ARM, but for other platforms, it may not.
Wrong. atomic_read() and atomic_set() are defined the same way and
have the same lack of atomicity across all architectures. There is
nothing special about these over a standard load
On Sat, Oct 12, 2013 at 05:35:03PM +0800, Peter Chen wrote:
> This commit adds runtime and system power management support for
> chipidea core. The runtime pm support is controlled by glue
> layer, it can be enabled by flag CI_HDRC_SUPPORTS_RUNTIME_PM.
Let's look at the locking.
1. Runtime PM. T
On Tue, Oct 15, 2013 at 10:18:15AM +0800, Peter Chen wrote:
> So, the lessons for this topic are:
>
> - If one atomic variable's operation only includes one instruction like
> atomic_read and atomic_set, it is not meaningful for using atomic
> operation, we can just use bool instead of it.
The le
from []
(driver_probe_device+0x9c/0x234)
[] (driver_probe_device+0x0/0x234) from []
(__device_attach+0x44/0x48)
...
---[ end trace c88ccaf3969e8423 ]---
Fix this so at least we can continue booting and get to a shell prompt.
Signed-off-by: Russell King
Tested-by: Russell King
---
drivers/usb/chipidea/h
On Thu, Oct 17, 2013 at 01:50:17PM +0800, Peter Chen wrote:
> Below is my proposal fix for this problem:
>
> diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> index 42a0bd4..c1d05c4 100644
> --- a/drivers/usb/chipidea/host.c
> +++ b/drivers/usb/chipidea/host.c
> @@ -270,16
On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
> Hi Russell,
>
> Em Mon, 30 Sep 2013 13:57:47 +0200
> Hans Verkuil escreveu:
>
> > On 09/19/2013 11:44 PM, Russell King wrote:
> > > Replace the following sequence:
> &g
On Thu, Nov 14, 2013 at 12:09:46AM -0200, Fabio Estevam wrote:
> @@ -107,10 +108,22 @@ static int ci_hdrc_imx_probe(struct platform_device
> *pdev)
> return ret;
> }
>
> + data->clk_phy = devm_clk_get(&pdev->dev, "phy");
> + if (IS_ERR(data->clk_phy)) {
> +
On Fri, Nov 15, 2013 at 09:45:16AM +0100, Daniel Mack wrote:
> Include linux/dma-mapping.h to make the new functions available that are
> used since 22d9d8e83 ("DMA-API: usb: use dma_set_coherent_mask()").
>
> Signed-off-by: Daniel Mack
> ---
> I got the following error while building for PXA pla
On Mon, Nov 25, 2013 at 12:22:47AM +0200, Aaro Koskinen wrote:
> Hi,
>
> With 3.13-rc1, the USB OHCI probe fails on Amstrad E3 (ARM/OMAP1)
> as follows:
>
> [ 33.814705] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [ 33.821482] ohci-omap: OHCI OMAP driver
> [ 33.925153] ohci ohc
On Mon, Nov 25, 2013 at 06:33:02PM +0200, Aaro Koskinen wrote:
> Hi,
>
> On Sun, Nov 24, 2013 at 10:43:59PM +, Russell King - ARM Linux wrote:
> > On Mon, Nov 25, 2013 at 12:22:47AM +0200, Aaro Koskinen wrote:
> > > [ 33.967324] ohci ohci: Coherent DMA mask 0x
This series moves some of the misplaced ARM header files, which
contain driver platform data, out of arch/arm/include/asm/mach
and into include/linux/platform_data.
arch/arm/include/asm/mach is supposed to be for include files
exporting generic ARM code structures and functions to ARM platforms,
n
On Fri, Sep 21, 2012 at 05:40:07PM +0800, Eric Miao wrote:
> On Fri, Sep 21, 2012 at 5:36 PM, Russell King
> wrote:
> > diff --git a/arch/arm/mach-ixp4xx/include/mach/udc.h
> > b/arch/arm/mach-ixp4xx/include/mach/udc.h
> > index 80d6da2..b47cc0d 100644
> > --- a/arc
On Thu, Sep 27, 2012 at 07:34:07PM +0530, Kishon Vijay Abraham I wrote:
> +static int omap5_usb_phy_power(struct omap_usb *phy, bool on)
> +{
> + u32 val;
> + unsigned long rate;
> + struct clk *sys_clk;
> +
> + sys_clk = clk_get(NULL, "sys_clkin");
> + if (IS_ERR(sys_clk)) {
>
On Wed, Oct 17, 2012 at 08:00:00PM +0900, Kukjin Kim wrote:
> > +static int samsung_usbphy_get_refclk_freq(struct samsung_usbphy *sphy)
> > +{
> > + struct clk *ref_clk;
> > + int refclk_freq = 0;
> > +
> > + ref_clk = clk_get(sphy->dev, "xusbxti");
> > + if (IS_ERR(ref_clk)) {
>
> IS_ERR_
On Tue, Oct 16, 2012 at 04:05:55PM +0200, Peter Stuge wrote:
> > Sometimes it is more easy just to copy paste and send by email part
> > of documentation instead of using hyperlinks.
>
> A group collaborating around a given hardware certainly needs a
> common repository of documentation. A file se
On Thu, Oct 18, 2012 at 12:25:20AM +0200, Peter Stuge wrote:
> Russell King - ARM Linux wrote:
> > You have to be careful of copyright infringement.
>
> Yeah, because a company might sue for datasheet copyright
> infringement when someone is (if only potentially) buying
>
Subject: usb: at91_udc: fix typo on vubs pullup valid check
typo.
On Mon, Nov 05, 2012 at 10:34:52AM +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> if the gpio is not valid complain
>
> since 3285e0ec088febc5a88f57ddd78385a7da71476c
> ARM: at91/udc: use
On Fri, Nov 16, 2012 at 11:12:46AM +0100, Nicolas Ferre wrote:
> On 11/16/2012 10:53 AM, Jean-Christophe PLAGNIOL-VILLARD :
> > On 10:36 Fri 21 Sep , Russell King wrote:
> >> The definitions provided by serial_at91.h are only used by the
> >> atmel_serial driver, an
On Fri, Nov 16, 2012 at 11:08:47PM +0100, Joachim Eastwood wrote:
> When the atmel_open_hook/atmel_open_close assignment is dropped, these
> global variables will be useless so we should remove them as well.
> There are also some other code that uses the variables that can be
> dropped. Should shav
On Sat, Apr 20, 2013 at 01:55:12AM +0400, Sergei Shtylyov wrote:
> Hello.
>
>Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo,
> 'renesas-next-20130419' tag. It was created to fix the shortcomings in the
> R8A7779/Marzen USB platform code and R8A7779 USB common PHY dr
On Mon, Apr 29, 2013 at 09:24:41PM +0300, Felipe Balbi wrote:
> On Wed, Apr 24, 2013 at 02:23:15AM -0400, Chao Xie wrote:
> > diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
> > index 6b5978f..98d7e60 100644
> > --- a/include/linux/usb/phy.h
> > +++ b/include/linux/usb/phy.h
> > @@ -
On Thu, May 02, 2013 at 11:24:33AM -0500, Nishanth Menon wrote:
> On 20:03-20130502, Alexander Shiyan wrote:
> >
> > Signed-off-by: Alexander Shiyan
> > ---
> > arch/arm/mach-omap2/usb-host.c | 21 +
> > 1 file changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/a
On Thu, May 02, 2013 at 07:40:58PM +0300, Felipe Balbi wrote:
> Hi,
>
> On Thu, May 02, 2013 at 08:28:44PM +0400, Alexander Shiyan wrote:
> > > On 20:03-20130502, Alexander Shiyan wrote:
> > > >
> > > > Signed-off-by: Alexander Shiyan
> > > > ---
> > > > arch/arm/mach-omap2/usb-host.c | 21
On Fri, May 03, 2013 at 09:21:51AM +0300, Felipe Balbi wrote:
> Hi,
>
> On Fri, May 03, 2013 at 12:13:53AM +0100, Russell King - ARM Linux wrote:
> > > > > > Signed-off-by: Alexander Shiyan
> > > > > > ---
> > > > > > arch/arm/mach-
On Fri, May 03, 2013 at 09:21:51AM +0300, Felipe Balbi wrote:
> How about we pass yours for not reading the patch before flaming ?
And another thing. If you want to be flamed, continue with that tone.
The problem here is that *you* have not been flamed in the previous
message. The previous messa
On Fri, May 03, 2013 at 11:30:09AM +0300, Felipe Balbi wrote:
> Hi,
>
> On Fri, May 03, 2013 at 09:15:10AM +0100, Russell King - ARM Linux wrote:
> > > > This is exactly why we have platform_device_alloc(),
> > > > platform_device_register_full() and fr
On Fri, May 03, 2013 at 11:39:00AM +0300, Felipe Balbi wrote:
> Hi,
>
> On Fri, May 03, 2013 at 09:32:06AM +0100, Russell King - ARM Linux wrote:
> > On Fri, May 03, 2013 at 09:21:51AM +0300, Felipe Balbi wrote:
> > > How about we pass yours for not reading the patch befor
On Wed, May 08, 2013 at 01:42:11AM +0200, Arnd Bergmann wrote:
> On Wednesday 08 May 2013, Greg Kroah-Hartman wrote:
> > On Tue, May 07, 2013 at 04:53:52PM -0600, Stephen Warren wrote:
> > > From: Stephen Warren
>
> > > Suggested-by: Arnd Bergmann
> > > Signed-off-by: Stephen Warren
> >
> > So
On Wed, May 08, 2013 at 10:54:48AM +0800, Peter Chen wrote:
> >
> > This probably could be initialized from some DT property. However,
> > there's no such property defined right now, and considering that DT is
> > supposed to be an ABI, we'd always need the code in this patch as a
> > fallback for
On Wed, May 08, 2013 at 09:24:44AM +0200, Arnd Bergmann wrote:
> It probably should. The main thing is that the dma_mask setting in
> of_platform (and elsewhere) is a mess and that nobody so far had the
> guts to try to get it right for good.
>
> Setting a 32 bit DMA mask is /probably/ the right d
On Thu, Dec 12, 2013 at 06:18:29AM -0500, Matt Porter wrote:
> /**
> + * struct phy_attrs - represents phy attributes
> + * @bus_width: Data path width implemented by PHY
> + */
> +struct phy_attrs {
> + u32 bus_width;
Why u32?
> int phy_power_off(struct phy *phy);
> +st
On Wed, Dec 12, 2007 at 09:47:54AM +0800, eric miao wrote:
> There are five patches all together:
>
> USB: update pxa27x ohci driver to use clk support
> USB: update to allow pxa27x ohci driver to support pxa3xx
>
> pxa: move pxa27x_device_ohci out of pxa27x.c for use with pxa3xx
> pxa: add clk o
On Sun, Jul 08, 2012 at 11:10:04PM +0800, Richard Zhao wrote:
> On Thu, Jun 28, 2012 at 10:06 PM, Richard Zhao wrote:
> > On Thu, Jun 28, 2012 at 03:53:46PM +0200, Marc Kleine-Budde wrote:
> >> Signed-off-by: Marc Kleine-Budde
> >> ---
> >> drivers/usb/chipidea/ci13xxx_pci.c |6 +++---
> >>
On Mon, Nov 17, 2014 at 06:07:40PM +0300, Dmitry Eremin-Solenikov wrote:
> Change clk_enable/disable() calls to clk_prepare_enable() and
> clk_disable_unprepare().
>
> Signed-off-by: Dmitry Eremin-Solenikov
> ---
> drivers/i2c/busses/i2c-pxa.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 delet
On Mon, Nov 17, 2014 at 06:07:39PM +0300, Dmitry Eremin-Solenikov wrote:
> Change clk_enable/disable() calls to clk_prepare_enable() and
> clk_disable_unprepare().
NAK. Console writes can be called from IRQs-off regions. clk_prepare()
can sleep. Sleeping is not permitted with IRQs off.
--
FTT
On Tue, Nov 18, 2014 at 12:05:45AM +0400, Dmitry Eremin-Solenikov wrote:
> Hello,
>
> 2014-11-17 21:44 GMT+03:00 Robert Jarzmik :
> > Dmitry Eremin-Solenikov writes:
> >
> >> Change clk_enable/disable() calls to clk_prepare_enable() and
> >> clk_disable_unprepare().
> >>
> >> Signed-off-by: Dmitr
While unplugging a Logitek Keyboard/mouse micro-receiver, I got the
lockdep splat below.
However, I don't fully understand this splat - I see nothing in
flush_work() nor process_one_work() making use of "intf->reset_ws" -
which seems to be a USB thing. I guess lockdep is being re-used to
validate
While testing an EM28xx based USB DVB stick which I've recently acquired,
I find that occasionally the driver stops responding after it returns
-EFBIG from one of its ioctls. I've no idea whether there's a previous
kernel version which works.
Finding the EFBIG return in ehci-sched.c, I decided to
On Wed, Dec 24, 2014 at 12:00:00PM +0100, Frank Schäfer wrote:
> See
> https://bugzilla.kernel.org/show_bug.cgi?id=72891
>
> Solved by
> http://www.spinics.net/lists/linux-usb/msg118366.html
Thanks, that seems to solve it.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
On Wed, Jan 07, 2015 at 10:42:14AM -0500, Alan Stern wrote:
> On Thu, 18 Dec 2014, Greg Kroah-Hartman wrote:
> > That seems reasonable to me, unbinding when a reset is happening is
> > going to be a rare condition, but if we get rid of it, and we try to
> > queue a reset for a device that is gone,
On Fri, Apr 25, 2014 at 04:07:00PM +0200, Gregory CLEMENT wrote:
> +#if defined(CONFIG_HAVE_CLK)
> +static int try_enable_clk(struct platform_device *pdev)
> +{
> + struct clk *clk = devm_clk_get(&pdev->dev, NULL);
> +
> + /* Not all platforms have a clk so it is not an error if the clock
>
On Fri, Aug 07, 2015 at 08:18:48PM -0700, Duc Dang wrote:
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 890ad9d..5d03f8b 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -93,14 +93,14 @@ static int xhci_plat_probe(struct plat
On Tue, Sep 01, 2015 at 02:54:17PM +0300, Mathias Nyman wrote:
> On 31.08.2015 21:58, Duc Dang wrote:
> >On Thu, Aug 20, 2015 at 12:38 PM, Duc Dang wrote:
> >>The xhci platform driver needs to work on systems that
> >>either only support 64-bit DMA or only support 32-bit DMA.
> >>Attempt to set a
On Fri, Oct 10, 2014 at 12:47:06AM +0300, Aaro Koskinen wrote:
> Hi,
>
> On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote:
> > What GCC version are you using?
> >
> > 4.8.1 and 4.8.2 are known to miscompile the ARM kernel and these
> > find_get_entry() crashes with 0x
On Fri, Oct 10, 2014 at 08:57:43AM -0500, Felipe Balbi wrote:
> On Thu, Oct 09, 2014 at 04:07:15PM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Oct 09, 2014 at 03:46:37PM -0500, Felipe Balbi wrote:
> > > On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote:
> > > > On Thu, Oct 09, 2
On Fri, Oct 10, 2014 at 08:44:33PM -0500, Nathan Lynch wrote:
> On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
> > We can blacklist these GCC versions quite easily. We already have GCC
> > 3.3 blacklisted, and it's trivial to add others. I would want to include
>
On Sat, Oct 11, 2014 at 11:54:32AM +0800, Peter Chen wrote:
> On Fri, Oct 10, 2014 at 08:44:33PM -0500, Nathan Lynch wrote:
> > On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
> > >
> > > Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
&
On Mon, Oct 13, 2014 at 09:11:34AM +, David Laight wrote:
> From: Nathan Lynch
> > On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
> > >
> > > Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
> > > it seems that thi
On Tue, Oct 14, 2014 at 04:06:40AM +0200, Greg KH wrote:
> On Mon, Oct 13, 2014 at 12:43:07PM +0100, Russell King - ARM Linux wrote:
> > I think the only viable solution here is that:
> >
> > 1. We blacklist the bad compiler versions outright in the kernel.
>
> Yes, p
On Wed, Oct 15, 2014 at 10:23:10PM +0100, Russell King - ARM Linux wrote:
> As I said, I have a patch in progress, but it seems that there needed
> to be some discussion about exactly which compiler versions are affected.
> It seems that it's not as trivial as looking at the
On Wed, Oct 15, 2014 at 10:25:13PM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 15, 2014 at 10:23:10PM +0100, Russell King - ARM Linux wrote:
> > As I said, I have a patch in progress, but it seems that there needed
> > to be some discussion about exactly which compil
On Thu, Jul 17, 2014 at 07:19:15PM +0800, Peter Chen wrote:
> Currently, we are designing a generic driver, we don't know what's the
> hardware architecture, we are trying to find a solution how to set
> dma mask for all possible devices which will use this driver, Antoine's
> this patch is trying
On Thu, Jun 18, 2015 at 05:47:46PM +0530, Sudip Mukherjee wrote:
> This is an attempt to fix the build failures when building mn10300 with
> allmodconfig. As I have never worked with arch files so I hope you will
> point me to right direction to correct my mistakes in this attempt.
Why has the lin
On Thu, Jun 18, 2015 at 10:31:07AM -0500, Jay C. Polmar wrote:
> I am on this list by mistake and 5/15/2011 we requested to be removed,
> can someone remove me from this list?
There are six mailing lists in the Cc line. For all of the lists
present there, I can't help you, but you should be able
This bug is soo obscure, I'm not even sure how to start debugging it.
This never used to be a problem, but I'm not sure when it started as
USB (in general) is not something I use regularly.
In this setup, the USB OTG port is wired in host mode via pinmix
configuration of the USB OTG ID pin:
On Thu, Oct 08, 2015 at 09:52:52AM +, Peter Chen wrote:
> I can't reproduce it for 5 hours, and will change pinmux (do the same
> thing with your platform), and do the overnight test.
There's definitely something weird going on. Over night last night,
I left the Logitech universal receiver in
On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> > On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> > > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > > > On Fri, Oct 16, 2015 at 11:57:50P
On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
> ... If a device is available and has
> a compatible driver, but it cannot be probed because a dependency
> isn't going to be available, that's an error and is going to cause
> real-world problems unless the device is redundant. Current
On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
> On 19 October 2015 at 15:18, Russell King - ARM Linux
> wrote:
> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
> >> ... If a device is available and has
> >> a compatible driver, but
101 - 200 of 216 matches
Mail list logo
