Re: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency

Julienne wrote: > > Hi Alan, > > On Thu, 2021-04-01 at 11:23 -0400, Alan Cooper wrote: > > Nicolas, > > > > Sorry, I just noticed this thread. > > This is a known bug in some newer Arasan cores. > > The problem happens when the difference between the cor

Re: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency

Nicolas, Sorry, I just noticed this thread. This is a known bug in some newer Arasan cores. The problem happens when the difference between the core clock and the bus clock is too great. Limiting the clock to 200KHz minimum should be a good fix. In my experience, it's only eMMC that needs the

Re: [PATCH] mmc: brcmstb: Fix sdhci_pltfm_suspend link error

> I just posted a new patch for this, please have a look and test it. > > Kind regards > Uffe I tested your new patch and it works. Reviewed-and-tested-by: Al Cooper Thanks Al On Tue, Jan 26, 2021 at 4:55 AM Ulf Hansson wrote: > > On Mon, 25 Jan 2021 at 18:40, Florian Fainelli wrote: > > >

Re: [PATCH 1/3] dt-bindings: Add support for Broadcom USB pin map driver

On Tue, Aug 25, 2020 at 11:46 AM Rob Herring wrote: > > +Linus W > > On Tue, Aug 25, 2020 at 6:26 AM Alan Cooper wrote: > > > > On Mon, Aug 24, 2020 at 7:30 PM Rob Herring wrote: > > > > > > On Wed, Aug 12, 2020 at 04:20:16PM -0400, Al Cooper wrote: &g

Re: [PATCH 1/3] dt-bindings: Add support for Broadcom USB pin map driver

On Mon, Aug 24, 2020 at 7:30 PM Rob Herring wrote: > > On Wed, Aug 12, 2020 at 04:20:16PM -0400, Al Cooper wrote: > > Add DT bindings for the Broadcom USB pin map driver. This driver allows > > some USB input and output signals to be mapped to any GPIO instead > > of the normal dedicated pins

Re: [PATCH] mmc: Some Micron eMMC devices cause reboot to hang

On Wed, Aug 5, 2020 at 4:28 AM Ulf Hansson wrote: > > On Mon, 27 Jul 2020 at 15:07, Alan Cooper wrote: > > > > On Fri, Jul 24, 2020 at 7:03 AM Ulf Hansson wrote: > > > > > > On Tue, 21 Jul 2020 at 21:18, Al Cooper wrote: > > > > > > &g

Re: [PATCH 3/3] usb: Add Kconfig and Makefile changes to build brcmstb-usb-pinmap

On Thu, Aug 13, 2020 at 1:40 AM Greg Kroah-Hartman wrote: > > On Wed, Aug 12, 2020 at 04:20:18PM -0400, Al Cooper wrote: > > From: Al Cooper > > > > Add Kconfig and Makefile changes to build brcmstb-usb-pinmap and > > update MAINTAINERS for the new driver. > > This can be part of the previous

Re: [PATCH] mmc: Some Micron eMMC devices cause reboot to hang

On Fri, Jul 24, 2020 at 7:03 AM Ulf Hansson wrote: > > On Tue, 21 Jul 2020 at 21:18, Al Cooper wrote: > > > > When using eMMC as the boot device, some Micron eMMC devices will > > cause reboot to hang. This is a result of the eMMC device not going > > into boot mode after the hardware sends CMD0

Re: [PATCH 0/7] usb: bdc: Updates and fixes to the USB BDC driver

On Tue, Jul 21, 2020 at 5:33 AM Felipe Balbi wrote: > > > Hi, > > Al Cooper writes: > > Updates and fixes to the Broadcom USB BDC driver. > > > > Al Cooper (4): > > dt-bindings: usb: bdc: Update compatible strings > > usb: bdc: Add compatible string for new style USB DT nodes > > usb: bdc:

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

Al On Wed, May 13, 2020 at 3:42 PM Alan Cooper wrote: > > On Wed, May 13, 2020 at 1:46 PM Florian Fainelli wrote: > > > > > > > > On 5/13/2020 10:39 AM, Alan Stern wrote: > > > On Wed, May 13, 2020 at 07:05:05PM +0200, Greg Kroah-Hartman wrote: > &g

Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile

On Wed, May 13, 2020 at 1:46 PM Florian Fainelli wrote: > > > > On 5/13/2020 10:39 AM, Alan Stern wrote: > > On Wed, May 13, 2020 at 07:05:05PM +0200, Greg Kroah-Hartman wrote: > >> On Wed, May 13, 2020 at 09:31:11AM -0700, Florian Fainelli wrote: > >>> > >>> > >>> On 5/13/2020 9:27 AM, Greg

Re: [PATCH v9 4/5] usb: ehci: Add new EHCI driver for Broadcom STB SoC's

On Mon, May 11, 2020 at 3:51 PM Alan Stern wrote: > > On Mon, 11 May 2020, Al Cooper wrote: > > > Add a new EHCI driver for Broadcom STB SoC's. A new EHCI driver > > was created instead of adding support to the existing ehci platform > > driver because of the code required to work around bugs in

Re: [PATCH v7 4/5] usb: ehci: Add new EHCI driver for Broadcom STB SoC's

On Fri, May 8, 2020 at 2:46 PM Alan Stern wrote: > > On Thu, 7 May 2020, Al Cooper wrote: > > > Add a new EHCI driver for Broadcom STB SoC's. A new EHCI driver > > was created instead of adding support to the existing ehci platform > > driver because of the code required to workaround bugs in the

Re: [PATCH v6 3/4] usb: ehci: Add new EHCI driver for Broadcom STB SoC's

On Tue, May 5, 2020 at 7:00 AM Greg Kroah-Hartman wrote: > > On Thu, Apr 30, 2020 at 07:12:57AM -0400, Al Cooper wrote: > > Add a new EHCI driver for Broadcom STB SoC's. A new EHCI driver > > was created instead of adding support to the existing ehci platform > > driver because of the code

Re: [PATCH v6 4/4] usb: host: Add ability to build new Broadcom STB USB drivers

On Tue, May 5, 2020 at 6:54 AM Greg Kroah-Hartman wrote: > > On Thu, Apr 30, 2020 at 07:12:58AM -0400, Al Cooper wrote: > > Add the build system changes needed to get the Broadcom STB XHCI, > > EHCI and OHCI functionality working. The OHCI support does not > > require anything unique to Broadcom

Re: [PATCH] mmc: sdhci: Fix incorrect switch to HS mode

This does correct the sequence of switching to HS400 but it might be safest to just add this to the latest until it gets a little testing to make sure it doesn't expose some bug in existing controllers. Thanks Al On Tue, Sep 3, 2019 at 10:52 AM Ulf Hansson wrote: > > On Tue, 3 Sep 2019 at

Re: Issue with sequence to switch to HS400

No problem. Thanks Al On Tue, Jul 30, 2019 at 4:00 AM Adrian Hunter wrote: > > On 26/07/19 12:37 AM, Alan Cooper wrote: > > That's an even better solution and it gets my HS400 mode working. > > Will you add this change or should I? > > You, if you wouldn't mind.

Re: Issue with sequence to switch to HS400

That's an even better solution and it gets my HS400 mode working. Will you add this change or should I? Thanks Al On Thu, Jul 25, 2019 at 3:33 AM Adrian Hunter wrote: > > On 23/07/19 3:34 PM, Alan Cooper wrote: > > On Tue, Jul 23, 2019 at 1:21 AM Adrian Hunter > > wrote: >

Re: Issue with sequence to switch to HS400

On Tue, Jul 23, 2019 at 1:21 AM Adrian Hunter wrote: > > On 23/07/19 1:31 AM, Alan Cooper wrote: > > I'm having a problem with a new SD/MMC controller and PHY in our > > latest SoC's. The issue I'm seeing is that I can't switch into HS400 > > mode. This looks like somet

Issue with sequence to switch to HS400

I'm having a problem with a new SD/MMC controller and PHY in our latest SoC's. The issue I'm seeing is that I can't switch into HS400 mode. This looks like something the driver is doing that doesn't meet the JEDEC spec. In the "HS400 timing mode selection" section of the JEDEC spec , in step 7 it

Re: [PATCH 6/6] usb: bdc: Update compatible match strings

> > Remove "brcm,bdc-v0.16" because it was never used on any system. > > You're not really removing it, are you? Whoops, it was supposed to be removed. Thanks Al On Fri, Jun 21, 2019 at 4:28 AM Sergei Shtylyov wrote: > > Hello! > > On 21.06.2019 0:09, Al Cooper wrote: > > > Remove

Re: [PATCH 2/6] usb: bdc: Cleanup clock support

> > diff --git a/drivers/usb/gadget/udc/bdc/bdc_core.c > > b/drivers/usb/gadget/udc/bdc/bdc_core.c > > index ccbd1d34eb2a..11a43de6c1c6 100644 > > --- a/drivers/usb/gadget/udc/bdc/bdc_core.c > > +++ b/drivers/usb/gadget/udc/bdc/bdc_core.c > > @@ -490,8 +490,14 @@ static int bdc_probe(struct

Re: [PATCH 3/6] usb: bdc: driver may fail to get USB PHY

It's been very useful to have the DEFER debug message so I'd like to leave in the check for DEFER. I should not be skipping the clock disable, so I'll "goto clk_cleanup" for both cases. Thanks Al On Fri, Jun 21, 2019 at 1:39 AM Chunfeng Yun wrote: > > On Thu, 2019-06-20 at 17:09 -0400, Al

Re: Generic PHY "unload" crash

; Hi Alan, > > On 21/05/19 1:40 PM, Alan Cooper wrote: > > I'm seeing an issue on a system where I have a generic PHY that is > > used by a USB XHCI driver. The XHCI driver does the phy_init() in > > probe and the phy_exit() in remove. The problem happens when I use > > sysfs

Generic PHY "unload" crash

I'm seeing an issue on a system where I have a generic PHY that is used by a USB XHCI driver. The XHCI driver does the phy_init() in probe and the phy_exit() in remove. The problem happens when I use sysfs to "unload" the PHY driver before doing an unload of the XHCI driver. This is a result of

Re: [PATCH] PM / core: Clear the direct_complete flag on errors

> On 4 October 2018 at 11:08, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > If __device_suspend() returns early on an error or pending wakeup > > and the power.direct_complete flag has been set for the device > > already, the subsequent device_resume() will be confused by it > >

Re: [PATCH] PM / core: Clear the direct_complete flag on errors

> On 4 October 2018 at 11:08, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > If __device_suspend() returns early on an error or pending wakeup > > and the power.direct_complete flag has been set for the device > > already, the subsequent device_resume() will be confused by it > >

Re: [PATCH v4 3/4] mmc: sdhci: enable/disable the clock in sdhci_pltfm_suspend/resume

> On 23/08/17 07:15, Masahiro Yamada wrote: > > This commit provides similar cleanups as commit 83eacdfa2529 ("mmc: > > sdhci: disable the clock in sdhci_pltfm_unregister()") did for > > unregister hooks. > > > > sdhci-brcmstb.c and sdhci-sirf.c implement their own suspend/resume > > hooks to

Re: [PATCH v4 3/4] mmc: sdhci: enable/disable the clock in sdhci_pltfm_suspend/resume

> On 23/08/17 07:15, Masahiro Yamada wrote: > > This commit provides similar cleanups as commit 83eacdfa2529 ("mmc: > > sdhci: disable the clock in sdhci_pltfm_unregister()") did for > > unregister hooks. > > > > sdhci-brcmstb.c and sdhci-sirf.c implement their own suspend/resume > > hooks to

Re: [PATCH V3 2/2] usb: phy: phy-brcm-usb: Add Broadcom STB USB Phy driver

On Wed, Aug 31, 2016 at 5:57 AM, Kishon Vijay Abraham I wrote: > Hi, > > On Tuesday 30 August 2016 08:00 PM, Al Cooper wrote: >> Add a new USB Phy driver for Broadcom STB SoCs. This driver >> supports all Broadcom STB ARM SoCs. This driver in combination >> with the generic ohci,

Re: [PATCH V3 2/2] usb: phy: phy-brcm-usb: Add Broadcom STB USB Phy driver

On Wed, Aug 31, 2016 at 5:57 AM, Kishon Vijay Abraham I wrote: > Hi, > > On Tuesday 30 August 2016 08:00 PM, Al Cooper wrote: >> Add a new USB Phy driver for Broadcom STB SoCs. This driver >> supports all Broadcom STB ARM SoCs. This driver in combination >> with the generic ohci, ehci and xhci

[QUESTION] kexec: ARM: kexec reorders device suspend/resume order

I've found a problem on our ARM based systems where a kexec'd kernel fails coming out of S3. The problem is caused by the re-ordering of the device tree nodes done by kexec (which reconstructs the device tree from the proc file system). The re-ordered DT nodes cause the device registration to

[QUESTION] kexec: ARM: kexec reorders device suspend/resume order

I've found a problem on our ARM based systems where a kexec'd kernel fails coming out of S3. The problem is caused by the re-ordering of the device tree nodes done by kexec (which reconstructs the device tree from the proc file system). The re-ordered DT nodes cause the device registration to

Re: [PATCH 3/6] dt-bindings: mtu3: add devicetree bindings

On Thu, May 12, 2016 at 3:24 AM, chunfeng yun wrote: >> > + - mediatek,enable-manual-drd : supports manual dual-role switch by sysfs >> > + interface; only used when receptacle is TYPE-A and also wants to >> > support >> > + dual-role mode. >> >> sysfs is a Linux

Re: [PATCH 3/6] dt-bindings: mtu3: add devicetree bindings

On Thu, May 12, 2016 at 3:24 AM, chunfeng yun wrote: >> > + - mediatek,enable-manual-drd : supports manual dual-role switch by sysfs >> > + interface; only used when receptacle is TYPE-A and also wants to >> > support >> > + dual-role mode. >> >> sysfs is a Linux detail that doesn't apply to

Re: [RFC 0/6] mmc: Field Firmware Update

On Fri, Nov 13, 2015 at 9:56 AM, Holger Schurig wrote: > There have been some attempts to add FFU (field firmware update). The last > AFAIK in Nov 2014, http://www.spinics.net/lists/linux-mmc/msg29324.html > > But it seems that the committers weren't persistent enought. > > I took the liberty to

Re: [RFC 0/6] mmc: Field Firmware Update

On Fri, Nov 13, 2015 at 9:56 AM, Holger Schurig wrote: > There have been some attempts to add FFU (field firmware update). The last > AFAIK in Nov 2014, http://www.spinics.net/lists/linux-mmc/msg29324.html > > But it seems that the committers weren't persistent enought.

Re: [PATCH V2] mips: function tracer: Fix broken function tracing

When the kernel first boots we have to be able to handle the gcc generated jalr, addui sequence until ftrace_init gets a chance to run and change the sequence. At this point mcount just adjusts the stack and returns. When ftrace_init runs, we convert the jalr/addui to nops. Then whenever tracing

Re: [PATCH V2] mips: function tracer: Fix broken function tracing

When the kernel first boots we have to be able to handle the gcc generated jalr, addui sequence until ftrace_init gets a chance to run and change the sequence. At this point mcount just adjusts the stack and returns. When ftrace_init runs, we convert the jalr/addui to nops. Then whenever tracing

Re: [PATCH] mips: function tracer: Fix broken function tracing

On Tue, Jan 15, 2013 at 4:34 PM, David Daney wrote: > On 01/15/2013 01:07 PM, Steven Rostedt wrote: >> >> On Tue, 2013-01-15 at 09:55 -0800, David Daney wrote: >> There's nothing that states what the ftrace caller must be. We can have it do a proper stack update. That is, only at boot

Re: [PATCH] mips: function tracer: Fix broken function tracing

On Mon, Jan 14, 2013 at 10:40 PM, Steven Rostedt wrote: > On Fri, Jan 11, 2013 at 09:01:01AM -0800, David Daney wrote: >> >> I thought all CPUs were in stop_machine() when the modifications >> were done, so that there is no issue with multi-word instruction >> patching. >> >> Am I wrong about

Re: [PATCH] mips: function tracer: Fix broken function tracing

On Tue, Jan 15, 2013 at 4:34 PM, David Daney ddaney.c...@gmail.com wrote: On 01/15/2013 01:07 PM, Steven Rostedt wrote: On Tue, 2013-01-15 at 09:55 -0800, David Daney wrote: There's nothing that states what the ftrace caller must be. We can have it do a proper stack update. That is, only at

Re: [PATCH] mips: function tracer: Fix broken function tracing

On Mon, Jan 14, 2013 at 10:40 PM, Steven Rostedt rost...@goodmis.org wrote: On Fri, Jan 11, 2013 at 09:01:01AM -0800, David Daney wrote: I thought all CPUs were in stop_machine() when the modifications were done, so that there is no issue with multi-word instruction patching. Am I wrong

Re: [PATCH] mips: function tracer: Fix broken function tracing

On Mon, Jan 14, 2013 at 5:12 PM, David Daney wrote: > On 01/14/2013 01:10 PM, Alan Cooper wrote: >> >> I already tried using "adddiu sp, sp, 8" and it caused the kernel to >> randomly crash. After many hours of debugging the reason occurred to >> me wh

Re: [PATCH] mips: function tracer: Fix broken function tracing

I already tried using "adddiu sp, sp, 8" and it caused the kernel to randomly crash. After many hours of debugging the reason occurred to me while in bed in the middle of the night. The problem is that if we get an interrupt between the add 8 and the add -8 instructions, we trash the existing

Re: [PATCH] mips: function tracer: Fix broken function tracing

I already tried using adddiu sp, sp, 8 and it caused the kernel to randomly crash. After many hours of debugging the reason occurred to me while in bed in the middle of the night. The problem is that if we get an interrupt between the add 8 and the add -8 instructions, we trash the existing stack.

Re: [PATCH] mips: function tracer: Fix broken function tracing

On Mon, Jan 14, 2013 at 5:12 PM, David Daney ddaney.c...@gmail.com wrote: On 01/14/2013 01:10 PM, Alan Cooper wrote: I already tried using adddiu sp, sp, 8 and it caused the kernel to randomly crash. After many hours of debugging the reason occurred to me while in bed in the middle

MIPS Function Tracer question

I've been doing some testing of the MIPS Function Tracer functionality on the 3.3 kernel. I was surprised to find that the option to generate frame pointers was required for tracing. When I don't enable FRAME_POINTER along with FUNCTION_TRACER, the kernel hangs on boot. I also noticed that a

MIPS Function Tracer question

I've been doing some testing of the MIPS Function Tracer functionality on the 3.3 kernel. I was surprised to find that the option to generate frame pointers was required for tracing. When I don't enable FRAME_POINTER along with FUNCTION_TRACER, the kernel hangs on boot. I also noticed that a