On Thu, Aug 08, 2019 at 09:10:15AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 08, 2019 at 10:46:36AM +0200, yvahkhfo.1df7f...@hashmail.org
> wrote:
> > --- a/drivers/usb/core/devio.c
> > +++ b/drivers/usb/core/devio.c
> > @@ -238,9 +238,14 @@ static int usbdev_mmap(struct file *file, struct
>
On Thu, Aug 08, 2019 at 10:58:11AM +0200, Greg KH wrote:
> But the main issue here is what exactly is this "fixing"? What is wrong
> with the existing code that non-x86 systems have such a problem with?
> Shouldn't all of these dma issues be handled by the platform with the
> remap_pfn_range() cal
On Wed, Jul 31, 2019 at 09:56:42PM +0200, Arnd Bergmann wrote:
> For dove, the patches are basically what I had proposed back in
> 2015 when all other ARMv6/ARMv7 machines became part of a single
> kernel build. I don't know what the state is mach-dove support is,
> compared to the DT based support
On Tue, Sep 26, 2017 at 11:35:32AM -0400, Alan Stern wrote:
> On Tue, 26 Sep 2017, Russell King - ARM Linux wrote:
>
> > On Tue, Sep 26, 2017 at 10:35:23AM -0400, Alan Stern wrote:
> > > On Tue, 26 Sep 2017, Russell King wrote:
> > > > Convert the shutdown method
On Tue, Sep 26, 2017 at 10:35:23AM -0400, Alan Stern wrote:
> On Tue, 26 Sep 2017, Russell King wrote:
> > Convert the shutdown method to use the device_driver shutdown function
> > pointer rather than a private bus-type shutdown. This is the only user
> > for SA bus types, so having the suppo
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 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
> >
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
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
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
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 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, 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, 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 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, 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
> > part of a neponset, the host platform mus
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 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.
> >
> > Signed-off-by: Russell King
> > ---
> >
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 Wed, Aug 17, 2016 at 03:05:17PM +0300, Roger Quadros wrote:
> Since commit 6ce0d2001692 ("ARM: dma: Use dma_pfn_offset for dma address
> translation"),
> dma_to_pfn() already returns the PFN with the physical memory start offset
> so we don't need to add it again.
>
> This fixes USB mass stora
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
&
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, 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'
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, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote:
>
>
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> > Given that downstreams are already carrying as many hacks as they
> > could think of to speed total boot up, I think this is effectively
> > telling them to
On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote:
> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
> > On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
> >> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>
> < snip >
On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
> But I worry a bit (and that my main point) about these few additional
> rounds of deferred device probing which I have right now and which allows
> some of drivers to finish, finally, their probes successfully.
> With proposed cha
On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote:
> On 10/21/2015 06:36 PM, Frank Rowand wrote:
> > The above is currently the last point for probe to succeed or defer
> > (until possibly, as you mentioned, module loading resolves the defer).
> > If a probe defers above, it will de
On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> > On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> >> Hi Russell,
> >>
> >> On Mon, Oct 19, 2015 at 5:35 PM,
On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
>
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - p
On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
> > It's a bit ironic that you've chosen GPIO as an example there. The
> > "new" GPIO API (the gpiod_
On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
>
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - p
On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> I don't know that there *is* a coherent plan here to address it all.
>
> Certainly, we *will* need subsystems to have firmware-specific
> knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> describe GPIO, and pr
On Mon, Oct 19, 2015 at 05:00:54PM +0200, Tomeu Vizoso wrote:
> On 19 October 2015 at 16:30, Russell King - ARM Linux
> wrote:
> > I typically see one or two, maybe five maximum on the platforms I have
> > here, but normally zero.
>
> Hmm, I have given a look at our l
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
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 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 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
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 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, 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 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
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 Wed, Jan 28, 2015 at 10:47:18PM +0100, Arnd Bergmann wrote:
> The renesas usbhs driver calls extcon_get_edev_by_phandle(), which
> is defined in drivers/extcon/extcon-class.c, and that can be a
> loadable module. If the extcon-class support is disabled, usbhs
> will work correctly for all device
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 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
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
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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 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 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:
> > >
> > > dma_set_mask(dev, mask);
> > > dma_set_coh
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
When CMA fails to initialize in v3.12-rc4, the chipidea driver oopses
the kernel while trying to remove and put the HCD which doesn't exist:
WARNING: CPU: 0 PID: 6 at /home/rmk/git/linux-rmk/arch/arm/mm/dma-mapping.c:511
__dma_alloc+0x200/0x240()
coherent pool not initialised!
Modules linked in:
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
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 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 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 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, 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(). Only arch and bus code s
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
> > make that be the case. This
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
> > the AMBA PL08x driver
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
> > +The coherent coherent mask
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_coherent_mask(). Only ar
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 when
> > the driver does n
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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 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 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
1 - 100 of 123 matches
Mail list logo
