From phil at raspberrypi.org  Thu May  4 02:58:20 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Thu, 4 May 2017 10:58:20 +0100
Subject: [PATCH] staging: vc04_services: Fix bulk cache maintenance
Message-ID: <d0edaf52-45e2-6fda-bb86-1a9b5e1a5425@raspberrypi.org>

vchiq_arm supports transfers less than one page and at arbitrary
alignment, using the dma-mapping API to perform its cache maintenance
(even though the VPU drives the DMA hardware). Read (DMA_FROM_DEVICE)
operations use cache invalidation for speed, falling back to
clean+invalidate on partial cache lines, with writes (DMA_TO_DEVICE)
using flushes.

If a read transfer has ends which aren't page-aligned, performing cache
maintenance as if they were whole pages can lead to memory corruption
since the partial cache lines at the ends (and any cache lines before or
after the transfer area) will be invalidated. This bug was masked until
the disabling of the cache flush in flush_dcache_page().

Honouring the requested transfer start- and end-points prevents the
corruption.

Fixes: cf9caf192988 ("staging: vc04_services: Replace dmac_map_area with dmac_map_sg")
Signed-off-by: Phil Elwell <phil at raspberrypi.org>
---
 .../interface/vchiq_arm/vchiq_2835_arm.c           | 31 +++++++++++++---------
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 3aeffcb..02e9736 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -501,8 +501,15 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
 	 */
 	sg_init_table(scatterlist, num_pages);
 	/* Now set the pages for each scatterlist */
-	for (i = 0; i < num_pages; i++)
-		sg_set_page(scatterlist + i, pages[i], PAGE_SIZE, 0);
+	for (i = 0; i < num_pages; i++)	{
+		unsigned int len = PAGE_SIZE - offset;
+
+		if (len > count)
+			len = count;
+		sg_set_page(scatterlist + i, pages[i], len, offset);
+		offset = 0;
+		count -= len;
+	}
 
 	dma_buffers = dma_map_sg(g_dev,
 				 scatterlist,
@@ -523,20 +530,20 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
 		u32 addr = sg_dma_address(sg);
 
 		/* Note: addrs is the address + page_count - 1
-		 * The firmware expects the block to be page
+		 * The firmware expects blocks after the first to be page-
 		 * aligned and a multiple of the page size
 		 */
 		WARN_ON(len == 0);
-		WARN_ON(len & ~PAGE_MASK);
-		WARN_ON(addr & ~PAGE_MASK);
+		WARN_ON(i && (i != (dma_buffers - 1)) && (len & ~PAGE_MASK));
+		WARN_ON(i && (addr & ~PAGE_MASK));
 		if (k > 0 &&
-		    ((addrs[k - 1] & PAGE_MASK) |
-			((addrs[k - 1] & ~PAGE_MASK) + 1) << PAGE_SHIFT)
-		    == addr) {
-			addrs[k - 1] += (len >> PAGE_SHIFT);
-		} else {
-			addrs[k++] = addr | ((len >> PAGE_SHIFT) - 1);
-		}
+		    ((addrs[k - 1] & PAGE_MASK) +
+		     (((addrs[k - 1] & ~PAGE_MASK) + 1) << PAGE_SHIFT))
+		    == (addr & PAGE_MASK))
+			addrs[k - 1] += ((len + PAGE_SIZE - 1) >> PAGE_SHIFT);
+		else
+			addrs[k++] = (addr & PAGE_MASK) |
+				(((len + PAGE_SIZE - 1) >> PAGE_SHIFT) - 1);
 	}
 
 	/* Partial cache lines (fragments) require special measures */
-- 
1.9.1



From stefan.wahren at i2se.com  Thu May  4 10:51:10 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Thu, 4 May 2017 19:51:10 +0200 (CEST)
Subject: [PATCH] staging: vc04_services: Fix bulk cache maintenance
In-Reply-To: <d0edaf52-45e2-6fda-bb86-1a9b5e1a5425@raspberrypi.org>
References: <d0edaf52-45e2-6fda-bb86-1a9b5e1a5425@raspberrypi.org>
Message-ID: <139394270.264573.1493920270267@email.1und1.de>


> Phil Elwell <phil at raspberrypi.org> hat am 4. Mai 2017 um 11:58 geschrieben:
> 
> 
> vchiq_arm supports transfers less than one page and at arbitrary
> alignment, using the dma-mapping API to perform its cache maintenance
> (even though the VPU drives the DMA hardware). Read (DMA_FROM_DEVICE)
> operations use cache invalidation for speed, falling back to
> clean+invalidate on partial cache lines, with writes (DMA_TO_DEVICE)
> using flushes.
> 
> If a read transfer has ends which aren't page-aligned, performing cache
> maintenance as if they were whole pages can lead to memory corruption
> since the partial cache lines at the ends (and any cache lines before or
> after the transfer area) will be invalidated. This bug was masked until
> the disabling of the cache flush in flush_dcache_page().
> 
> Honouring the requested transfer start- and end-points prevents the
> corruption.
> 
> Fixes: cf9caf192988 ("staging: vc04_services: Replace dmac_map_area with dmac_map_sg")
> Signed-off-by: Phil Elwell <phil at raspberrypi.org>

Reported-by: Stefan Wahren <stefan.wahren at i2se.com>
Tested-by: Stefan Wahren <stefan.wahren at i2se.com>

In order to clarify the context of this issue:

http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-April/006149.html


From phil at raspberrypi.org  Tue May  9 01:30:29 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Tue, 9 May 2017 09:30:29 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
Message-ID: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>

In order to reduce power consumption and bus traffic, it is sensible
for secondary cores to enter a low-power idle state when waiting to
be started. The wfe instruction causes a core to wait until an event
or interrupt arrives before continuing to the next instruction.
The sev instruction sends a wakeup event to the other cores, so call
it from bcm2836_smp_boot_secondary, the function that wakes up the
waiting cores during booting.

It is harmless to use this patch without the corresponding change
adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
and this patch is not applied then the other cores will sleep forever.

See: https://github.com/raspberrypi/linux/issues/1989

Signed-off-by: Phil Elwell <phil at raspberrypi.org>
---
 drivers/irqchip/irq-bcm2836.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index e10597c..6dccdf9 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
 	writel(secondary_startup_phys,
 	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
 
+	dsb(sy); /* Ensure write has completed before waking the other CPUs */
+	sev();
+
 	return 0;
 }
 
-- 
1.9.1



From phil at raspberrypi.org  Tue May  9 02:04:30 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Tue, 9 May 2017 10:04:30 +0100
Subject: [PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware
Message-ID: <b6aef857-1454-7931-2c60-6d7b55b7a0a8@raspberrypi.org>

The Raspberry Pi startup stub files for multi-core BCM27XX processors
make the secondary CPUs spin until the corresponding mailbox is
written. These stubs are loaded at physical address 0x00000xxx (as seen
by the ARMs), but this page will be reused by the kernel unless it is
explicitly reserved, causing the waiting cores to execute random code.

Use the /memreserve/ Device Tree directive to mark the first page as
off-limits to the kernel.

See: https://github.com/raspberrypi/linux/issues/1989

Signed-off-by: Phil Elwell <phil at raspberrypi.org>
---

Changes in V2:
- Rebase against linux-next
- Drop downstream-only patch

 arch/arm/boot/dts/bcm283x.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index a3106aa..6d12c3e8 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -3,6 +3,8 @@
 #include <dt-bindings/clock/bcm2835-aux.h>
 #include <dt-bindings/gpio/gpio.h>
 
+/memreserve/ 0x00000000 0x00001000;
+
 /* This include file covers the common peripherals and configuration between
  * bcm2835 and bcm2836 implementations, leaving the CPU configuration to
  * bcm2835.dtsi and bcm2836.dtsi.
-- 
1.9.1



From phil at raspberrypi.org  Wed May 10 01:42:43 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Wed, 10 May 2017 09:42:43 +0100
Subject: [PATCH] staging: vc04_services: Fix bulk cache maintenance
In-Reply-To: <139394270.264573.1493920270267@email.1und1.de>
References: <d0edaf52-45e2-6fda-bb86-1a9b5e1a5425@raspberrypi.org>
 <139394270.264573.1493920270267@email.1und1.de>
Message-ID: <bd72cc29-140e-dfd7-eac5-01ccc8b844b1@raspberrypi.org>

On 04/05/2017 18:51, Stefan Wahren wrote:
> 
>> Phil Elwell <phil at raspberrypi.org> hat am 4. Mai 2017 um 11:58 geschrieben:
>>
>>
>> vchiq_arm supports transfers less than one page and at arbitrary
>> alignment, using the dma-mapping API to perform its cache maintenance
>> (even though the VPU drives the DMA hardware). Read (DMA_FROM_DEVICE)
>> operations use cache invalidation for speed, falling back to
>> clean+invalidate on partial cache lines, with writes (DMA_TO_DEVICE)
>> using flushes.
>>
>> If a read transfer has ends which aren't page-aligned, performing cache
>> maintenance as if they were whole pages can lead to memory corruption
>> since the partial cache lines at the ends (and any cache lines before or
>> after the transfer area) will be invalidated. This bug was masked until
>> the disabling of the cache flush in flush_dcache_page().
>>
>> Honouring the requested transfer start- and end-points prevents the
>> corruption.
>>
>> Fixes: cf9caf192988 ("staging: vc04_services: Replace dmac_map_area with dmac_map_sg")
>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
> 
> Reported-by: Stefan Wahren <stefan.wahren at i2se.com>
> Tested-by: Stefan Wahren <stefan.wahren at i2se.com>
> 
> In order to clarify the context of this issue:
> 
> http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-April/006149.html

Thanks, Stefan.

Is there no feedback other on this patch? It's been in the rpi-4.11.y downstream
branch for a week now with favourable results - see issue
https://github.com/raspberrypi/linux/issues/1977 and pr
https://github.com/raspberrypi/linux/pull/1987.

Phil


From gregkh at linuxfoundation.org  Wed May 10 02:06:26 2017
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 10 May 2017 11:06:26 +0200
Subject: [PATCH] staging: vc04_services: Fix bulk cache maintenance
In-Reply-To: <bd72cc29-140e-dfd7-eac5-01ccc8b844b1@raspberrypi.org>
References: <d0edaf52-45e2-6fda-bb86-1a9b5e1a5425@raspberrypi.org>
 <139394270.264573.1493920270267@email.1und1.de>
 <bd72cc29-140e-dfd7-eac5-01ccc8b844b1@raspberrypi.org>
Message-ID: <20170510090626.GA21141@kroah.com>

On Wed, May 10, 2017 at 09:42:43AM +0100, Phil Elwell wrote:
> On 04/05/2017 18:51, Stefan Wahren wrote:
> > 
> >> Phil Elwell <phil at raspberrypi.org> hat am 4. Mai 2017 um 11:58 geschrieben:
> >>
> >>
> >> vchiq_arm supports transfers less than one page and at arbitrary
> >> alignment, using the dma-mapping API to perform its cache maintenance
> >> (even though the VPU drives the DMA hardware). Read (DMA_FROM_DEVICE)
> >> operations use cache invalidation for speed, falling back to
> >> clean+invalidate on partial cache lines, with writes (DMA_TO_DEVICE)
> >> using flushes.
> >>
> >> If a read transfer has ends which aren't page-aligned, performing cache
> >> maintenance as if they were whole pages can lead to memory corruption
> >> since the partial cache lines at the ends (and any cache lines before or
> >> after the transfer area) will be invalidated. This bug was masked until
> >> the disabling of the cache flush in flush_dcache_page().
> >>
> >> Honouring the requested transfer start- and end-points prevents the
> >> corruption.
> >>
> >> Fixes: cf9caf192988 ("staging: vc04_services: Replace dmac_map_area with dmac_map_sg")
> >> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
> > 
> > Reported-by: Stefan Wahren <stefan.wahren at i2se.com>
> > Tested-by: Stefan Wahren <stefan.wahren at i2se.com>
> > 
> > In order to clarify the context of this issue:
> > 
> > http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-April/006149.html
> 
> Thanks, Stefan.
> 
> Is there no feedback other on this patch? It's been in the rpi-4.11.y downstream
> branch for a week now with favourable results - see issue
> https://github.com/raspberrypi/linux/issues/1977 and pr
> https://github.com/raspberrypi/linux/pull/1987.

It's the middle of the merge window, I can't do anything with this
until after 4.12-rc1 comes out.  Please be patient...

thanks,

greg k-h


From phil at raspberrypi.org  Wed May 10 02:11:04 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Wed, 10 May 2017 10:11:04 +0100
Subject: [PATCH] staging: vc04_services: Fix bulk cache maintenance
In-Reply-To: <20170510090626.GA21141@kroah.com>
References: <d0edaf52-45e2-6fda-bb86-1a9b5e1a5425@raspberrypi.org>
 <139394270.264573.1493920270267@email.1und1.de>
 <bd72cc29-140e-dfd7-eac5-01ccc8b844b1@raspberrypi.org>
 <20170510090626.GA21141@kroah.com>
Message-ID: <93d0bbb7-f682-8f5f-9491-f3ad1941d397@raspberrypi.org>

On 10/05/2017 10:06, Greg Kroah-Hartman wrote:
> On Wed, May 10, 2017 at 09:42:43AM +0100, Phil Elwell wrote:
>> On 04/05/2017 18:51, Stefan Wahren wrote:
>>>
>>>> Phil Elwell <phil at raspberrypi.org> hat am 4. Mai 2017 um 11:58 geschrieben:
>>>>
>>>>
>>>> vchiq_arm supports transfers less than one page and at arbitrary
>>>> alignment, using the dma-mapping API to perform its cache maintenance
>>>> (even though the VPU drives the DMA hardware). Read (DMA_FROM_DEVICE)
>>>> operations use cache invalidation for speed, falling back to
>>>> clean+invalidate on partial cache lines, with writes (DMA_TO_DEVICE)
>>>> using flushes.
>>>>
>>>> If a read transfer has ends which aren't page-aligned, performing cache
>>>> maintenance as if they were whole pages can lead to memory corruption
>>>> since the partial cache lines at the ends (and any cache lines before or
>>>> after the transfer area) will be invalidated. This bug was masked until
>>>> the disabling of the cache flush in flush_dcache_page().
>>>>
>>>> Honouring the requested transfer start- and end-points prevents the
>>>> corruption.
>>>>
>>>> Fixes: cf9caf192988 ("staging: vc04_services: Replace dmac_map_area with dmac_map_sg")
>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>
>>> Reported-by: Stefan Wahren <stefan.wahren at i2se.com>
>>> Tested-by: Stefan Wahren <stefan.wahren at i2se.com>
>>>
>>> In order to clarify the context of this issue:
>>>
>>> http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-April/006149.html
>>
>> Thanks, Stefan.
>>
>> Is there no feedback other on this patch? It's been in the rpi-4.11.y downstream
>> branch for a week now with favourable results - see issue
>> https://github.com/raspberrypi/linux/issues/1977 and pr
>> https://github.com/raspberrypi/linux/pull/1987.
> 
> It's the middle of the merge window, I can't do anything with this
> until after 4.12-rc1 comes out.  Please be patient...

Yes, of course - that's the kind of feedback I was looking for.

Thanks,

Phil


From stefan.wahren at i2se.com  Sat May 13 02:07:28 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 13 May 2017 11:07:28 +0200 (CEST)
Subject: [Bug] VCHIQ functional test broken
In-Reply-To: <1381182989.263636.1493062504676@email.1und1.de>
References: <331235003.222371.1491934205807@email.1und1.de>
 <685482264.60263.1492105308873@email.1und1.de>
 <20170413222915.GF17774@n2100.armlinux.org.uk>
 <20170414074104.GA8704@laptop> <87pog7x7c5.fsf@eliezer.anholt.net>
 <20170420195822.GA22677@laptop>
 <696fb1c1-7751-caf0-e0d9-9c67b059b4cc@i2se.com>
 <20170424164015.GP17774@n2100.armlinux.org.uk>
 <1058502523.15283.1493055747531@email.1und1.de>
 <20170424185931.GQ17774@n2100.armlinux.org.uk>
 <1381182989.263636.1493062504676@email.1und1.de>
Message-ID: <952745481.440383.1494666448727@email.1und1.de>


> Stefan Wahren <stefan.wahren at i2se.com> hat am 24. April 2017 um 21:35 geschrieben:
> 
> 
> 
> > Russell King - ARM Linux <linux at armlinux.org.uk> hat am 24. April 2017 um 20:59 geschrieben:
> > 
> > 
> > On Mon, Apr 24, 2017 at 07:42:27PM +0200, Stefan Wahren wrote:
> > > > What I can't see is how changing flush_dcache_page() has possibly broken
> > > > this: it seems to imply that you're getting flush_dcache_page() somehow
> > > > called inbetween mapping it for DMA, using it for DMA and CPU accesses
> > > > occuring.  However, the driver doesn't call flush_dcache_page() other
> > > > than through get_user_pages() - and since dma_map_sg() is used in that
> > > > path, it should be fine.
> > > > 
> > > > So, I don't have much to offer.
> > > > 
> > > > However, flush_dcache_page() is probably still a tad heavy - it currently
> > > > flushes to the point of coherency, but it's really about making sure that
> > > > the user vs kernel mappings are coherent, not about device coherency.
> > > > That's the role of the DMA API.
> > > 
> > > Currently i don't care too much about performance. More important is to
> > > fix this regression, because i'm not able to verify the function of this
> > > driver efficiently.
> > 
> > This is a driver in staging, and the reason its in staging is because it
> > has problems.  This is just another example of another problem it has...
> > Yes, the regression is regrettable, but I don't think it's something to
> > get hung up on.
> > 
> > > I'm thinking about 2 options:
> > > 
> > > 1) add a force parameter to flush_dcache_page() which make it possible
> > >    to override the new logic
> > > 2) create a second version of flush_dcache_page() with the old behavior
> > 
> > Neither, really, because, as I've already explained, flush_dcache_page()
> > has nothing what so ever to do with DMA coherence - and if a driver
> > breaks because we change its semantic slightly (but still in a compliant
> > way) then it's uncovered a latent bug in _that_ driver.
> > 
> > Rather than trying to "fix" flush_dcache_page() to work how this driver
> > wants it to (which is a totally crazy thing to propose - we can't go
> > shoe-horning driver specific behaviour into these generic flushing
> > functions), it would be much better to work out why the driver has
> > broken.
> 
> I totally agree. I had the hope we could make a workaround within the driver until we found the real issue.
> 
> > 
> > I see the kernel driver has its own logging (using vchiq_log_info() etc?)
> > maybe a starting point would be to compare the output from a working
> > kernel with a non-working kernel to get more of an idea where the problem
> > actually is?
> 
> I will try ...
> 
> > 
> > What I'm willing to do is to temporarily drop the offending patch for
> > the next merge window to give more time for this driver to be debugged,
> > but I will want to re-apply it after that merge window closes.
> 
> Since this is already in 4.11, please keep it. At least this makes it easier to reproduce. No need for more confusion and effort.
> 

In the meantime this issue has been fixed by Phil [1].

Unfortunately i found another issue. If i enable CONFIG_HIGHMEM in the kernel config, the data during functional test gets corrupted. Phil said it's caused by the usage of get_user_pages() [2]. That makes me wonder, because there are a lot of gup users and it's hard to believe that they are also affected.

Would that be hard to fix?

In that case i tend to fix at least the dependency:

diff --git a/drivers/staging/vc04_services/Kconfig b/drivers/staging/vc04_servic
index 9e27636..6572903 100644
--- a/drivers/staging/vc04_services/Kconfig
+++ b/drivers/staging/vc04_services/Kconfig
@@ -2,7 +2,7 @@ menuconfig BCM_VIDEOCORE
        tristate "Broadcom VideoCore support"
        depends on HAS_DMA
        depends on OF
-       depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWAR
+       depends on (RASPBERRYPI_FIRMWARE && !HIGHMEM) || (COMPILE_TEST && !RASPB
        default y
        help
                Support for Broadcom VideoCore services including

Thanks
Stefan

[1] - http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2017-May/105443.html
[2] - https://github.com/raspberrypi/linux/issues/1996


From linux at armlinux.org.uk  Sat May 13 02:30:16 2017
From: linux at armlinux.org.uk (Russell King - ARM Linux)
Date: Sat, 13 May 2017 10:30:16 +0100
Subject: [Bug] VCHIQ functional test broken
In-Reply-To: <952745481.440383.1494666448727@email.1und1.de>
References: <20170413222915.GF17774@n2100.armlinux.org.uk>
 <20170414074104.GA8704@laptop> <87pog7x7c5.fsf@eliezer.anholt.net>
 <20170420195822.GA22677@laptop>
 <696fb1c1-7751-caf0-e0d9-9c67b059b4cc@i2se.com>
 <20170424164015.GP17774@n2100.armlinux.org.uk>
 <1058502523.15283.1493055747531@email.1und1.de>
 <20170424185931.GQ17774@n2100.armlinux.org.uk>
 <1381182989.263636.1493062504676@email.1und1.de>
 <952745481.440383.1494666448727@email.1und1.de>
Message-ID: <20170513093016.GQ22219@n2100.armlinux.org.uk>

On Sat, May 13, 2017 at 11:07:28AM +0200, Stefan Wahren wrote:
> In the meantime this issue has been fixed by Phil [1].

Right - definitely a driver bug.  Mapping more memory for DMA than is
actually going to be DMA'd to and expecting data to be preserved is
really horrid.

> Unfortunately i found another issue. If i enable CONFIG_HIGHMEM in
> the kernel config, the data during functional test gets corrupted.
> Phil said it's caused by the usage of get_user_pages() [2].

Without knowing who "Phil" is in that thread, but...

   HIGHMEM is a problem because you can't use get_user_pages on pages in
   HIGHMEM.

is an interesting statement, and without any reasoning or evidence.

I also believe it to be incorrect.  get_user_pages() returns an array
of struct page pointers for the user memory, calling flush_dcache_page()
and flush_anon_page() on them to ensure that any kernel mapping is
coherent with what is in userspace.

As far as returning the array of page pointers, get_user_pages() doesn't
care whether they're lowmem or highmem.

flush_dcache_page() doesn't care either - if it wants to flush the page
and the page is a highmem page, it will temporarily map it before
flushing it.

flush_anon_page() is a no-op for all non-aliasing caches.

get_user_pages() works fine for whatever memory on other platforms and
drivers such as etnaviv, so I think this comes down to the vchip driver
doing things in ways that the kernel interfaces its using don't expect -
exactly like the "lets pass full pages to the DMA API" broken-ness.

I would like to hear the justification for that statement, but without
any justification, I assert that the statement is false.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From stefan.wahren at i2se.com  Mon May  8 13:22:08 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Mon, 8 May 2017 22:22:08 +0200 (CEST)
Subject: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
In-Reply-To: <2127594073.298820.1493143869792@email.1und1.de>
References: <1795308650.27171.9a53158f-312d-40ce-80ce-8bf792d8db34.open-xchange@email.1und1.de>
 <172093673.40121.1492427140661@email.1und1.de>
 <CAD=FV=WJBTUcMPw8OgQT_jhz0H8AsH=YqWMR7LtudUKrF5-XOA@mail.gmail.com>
 <79b9b35b-0600-771f-4cd2-9e03c5ba3a25@i2se.com>
 <186569458.91967.1492547106553@email.1und1.de>
 <CAD=FV=VHkJFrsJDmMytbUw=WjKQaGZ-8Ewfy5bPCA82AWS4O2Q@mail.gmail.com>
 <212870399.174480.1492633502649@email.1und1.de>
 <87mvbaykn1.fsf@eliezer.anholt.net>
 <1998517910.54108.1492894253010@email.1und1.de>
 <2127594073.298820.1493143869792@email.1und1.de>
Message-ID: <316369012.317772.1494274928708@email.1und1.de>


> Stefan Wahren <stefan.wahren at i2se.com> hat am 25. April 2017 um 20:11 geschrieben:
> 
> 
> > Stefan Wahren <stefan.wahren at i2se.com> hat am 22. April 2017 um 22:50 geschrieben:
> > 
> > 
> > Hi,
> > 
> > > Eric Anholt <eric at anholt.net> hat am 20. April 2017 um 20:54 geschrieben:
> > > 
> > > 
> > > Stefan Wahren <stefan.wahren at i2se.com> writes:
> > > 
> > > > Hi,
> > > >
> > > >> Doug Anderson <dianders at chromium.org> hat am 18. April 2017 um 22:41 geschrieben:
> > > >> 
> > > >> 
> > > >> It's hard to know for sure that all of this time is really in
> > > >> urb_enqueue().  Possible we could have task switched out and been
> > > >> blocked elsewhere.  Using ftrace to get more fine-grained timings
> > > >> would be useful.  ktime_get(), ktime_sub(), and ktime_to_us() are your
> > > >> friends here if you want to use trace_printk.
> > > >
> > > > i'm a newbie to ftrace, so i hope this would be helpful.
> > > >
> > > > # connect PL2303 to the onboard hub
> > > > # echo 0 > options/sleep-time
> > > > # echo 0 > function_profile_enabled
> > > > # echo 1 > function_profile_enabled
> > > > # ./usb_test
> > > > # Waiting for at least 20 seconds and then disconnect PL2303
> > > > # echo 0 > function_profile_enabled
> > > > # cat trace_stat/function0
> > > >
> > > >   Function                               Hit    Time            Avg             s^2
> > > >   --------                               ---    ----            ---             ---
> > > >   bcm2835_handle_irq                  361347    219567633 us     607.636 us      1485199 us  
> > > >   __handle_domain_irq                1082482    212639551 us     196.437 us      3642030 us  
> > > >   generic_handle_irq                 1082482    100592051 us     92.927 us       50511334 us 
> > > >   irq_exit                           1082482    98197771 us     90.715 us       29649040 us 
> > > >   handle_level_irq                   1082482    95812379 us     88.511 us       51910093 us 
> > > 
> > > If I'm reading this output right, we're spending half of our interrupt
> > > processing time in irq_exit(), so even if dwc2's interrupt was free (the
> > > generic_handle_irq() chain), we'd be eating about half the CPU getting
> > > back out of the interrupt handler, right?
> > > 
> > > I don't really know anything about DWC2 or USB, but is there any way we
> > > could mitigate the interrupt frequency with this hardware?  If nothing
> > > else, could we loop reading gintsts until it reads back 0?
> > 
> > first of all i updated my kernel to 4.11rc7 and the issue still occures. Today i had some time to investigate this issue further and i made some interesting observations:
> > 
> > 1. The lockup doesn't occure always after starting usb_test. In rare cases i was able to run the program without lockup.
> > 2. In case the lockup occured we are always able to "rescue" the BCM2835 from this state by sending some serial data to the PL2303.
> 
> Based on this scenario i patched the interrupt routine to detect the interrupt storm and normal condition. So i can dump the global and host registers in both situations (bad and goodcase).
> 
> Here is the diff between both register dumps, maybe someone see something interesting:
> 
> --- badcase.txt	2017-04-25 18:02:59.000000000 +0000
> +++ goodcase.txt	2017-04-25 18:02:59.000000000 +0000
> @@ -4,12 +4,12 @@
>   dwc2_dump_global_registers: GAHBCFG	 @0xCC850008 : 0x00000031
>   dwc2_dump_global_registers: GUSBCFG	 @0xCC85000C : 0x20001700
>   dwc2_dump_global_registers: GRSTCTL	 @0xCC850010 : 0x80000000
> - dwc2_dump_global_registers: GINTSTS	 @0xCC850014 : 0x06000021
> + dwc2_dump_global_registers: GINTSTS	 @0xCC850014 : 0x06000029
>   dwc2_dump_global_registers: GINTMSK	 @0xCC850018 : 0xF300080E
> - dwc2_dump_global_registers: GRXSTSR	 @0xCC85001C : 0x00070044
> + dwc2_dump_global_registers: GRXSTSR	 @0xCC85001C : 0x000F0001
>   dwc2_dump_global_registers: GRXFSIZ	 @0xCC850024 : 0x00000306
>   dwc2_dump_global_registers: GNPTXFSIZ	 @0xCC850028 : 0x01000306
> - dwc2_dump_global_registers: GNPTXSTS	 @0xCC85002C : 0x1D080100
> + dwc2_dump_global_registers: GNPTXSTS	 @0xCC85002C : 0x18080100
> ...

@Doug, @John Y., @Johan: Any further ideas to narrow down the reason for this interrupt storm?

Regards
Stefan


From stefan.wahren at i2se.com  Tue May  9 02:03:36 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Tue, 9 May 2017 11:03:36 +0200
Subject: [PATCH] ARM: dts: bcm283x: Reserve first page for firmware
In-Reply-To: <c0c0ac24-b55d-046a-c765-0a2933424ac4@raspberrypi.org>
References: <c0c0ac24-b55d-046a-c765-0a2933424ac4@raspberrypi.org>
Message-ID: <09d845c6-42d2-d61d-226d-94ba0f391b63@i2se.com>

Hi Phil,

Am 09.05.2017 um 10:20 schrieb Phil Elwell:
> The Raspberry Pi startup stub files for multi-core BCM283X processors
> make the secondary CPUs spin until the corresponding mailbox is
> written. These stubs are loaded at physical address 0x00000xxx (as seen
> by the ARMs), but this page will be reused by the kernel unless it is
> explicitly reserved, causing the waiting cores to execute random code.
>
> Use the /memreserve/ Device Tree directive to mark the first page as
> off-limits to the kernel.
>
> See: https://github.com/raspberrypi/linux/issues/1989
>
> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
> ---
>  arch/arm/boot/dts/bcm2710-rpi-3-b.dts | 4 ----

could you please rebase your patch on a upstream tree (e.g. linux-next)?
There has never been such a file.

>  arch/arm/boot/dts/bcm283x.dtsi        | 2 ++
>  2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm2710-rpi-3-b.dts b/arch/arm/boot/dts/bcm2710-rpi-3-b.dts
> index b21d286..cbec919 100644
> --- a/arch/arm/boot/dts/bcm2710-rpi-3-b.dts
> +++ b/arch/arm/boot/dts/bcm2710-rpi-3-b.dts
> @@ -1,9 +1,5 @@
>  /dts-v1/;
>  
> -#ifdef RPI364
> -/memreserve/ 0x00000000 0x00001000;
> -#endif
> -
>  #include "bcm2710.dtsi"
>  #include "bcm283x-rpi-smsc9514.dtsi"
>  
> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
> index 7d58cd7..0bc1932 100644
> --- a/arch/arm/boot/dts/bcm283x.dtsi
> +++ b/arch/arm/boot/dts/bcm283x.dtsi
> @@ -3,6 +3,8 @@
>  #include <dt-bindings/clock/bcm2835-aux.h>
>  #include <dt-bindings/gpio/gpio.h>
>  
> +/memreserve/ 0x00000000 0x00001000;
> +

Would be nice to have a short comment within the dtsi file explaining
what this reserve contains.

Thanks
Stefan

>  /* This include file covers the common peripherals and configuration between
>   * bcm2835 and bcm2836 implementations, leaving the CPU configuration to
>   * bcm2835.dtsi and bcm2836.dtsi.




From f.fainelli at gmail.com  Tue May  9 09:25:54 2017
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 9 May 2017 09:25:54 -0700
Subject: [PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware
In-Reply-To: <b6aef857-1454-7931-2c60-6d7b55b7a0a8@raspberrypi.org>
References: <b6aef857-1454-7931-2c60-6d7b55b7a0a8@raspberrypi.org>
Message-ID: <e2718c25-fdf1-ead1-cbfa-d23bf729a079@gmail.com>

On 05/09/2017 02:04 AM, Phil Elwell wrote:
> The Raspberry Pi startup stub files for multi-core BCM27XX processors
> make the secondary CPUs spin until the corresponding mailbox is
> written. These stubs are loaded at physical address 0x00000xxx (as seen
> by the ARMs), but this page will be reused by the kernel unless it is
> explicitly reserved, causing the waiting cores to execute random code.
> 
> Use the /memreserve/ Device Tree directive to mark the first page as
> off-limits to the kernel.

This reserves a 4KB page here, is this good enough, or should we just go
directly to the maximum page granule size possible on an ARM64/Linux
system to be on the safe side?

> 
> See: https://github.com/raspberrypi/linux/issues/1989
> 
> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
> ---
> 
> Changes in V2:
> - Rebase against linux-next
> - Drop downstream-only patch
> 
>  arch/arm/boot/dts/bcm283x.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
> index a3106aa..6d12c3e8 100644
> --- a/arch/arm/boot/dts/bcm283x.dtsi
> +++ b/arch/arm/boot/dts/bcm283x.dtsi
> @@ -3,6 +3,8 @@
>  #include <dt-bindings/clock/bcm2835-aux.h>
>  #include <dt-bindings/gpio/gpio.h>
>  
> +/memreserve/ 0x00000000 0x00001000;

Can you put a comment above this /memreserve entry here to remind about
what this is useful for?

Thanks!

> +
>  /* This include file covers the common peripherals and configuration between
>   * bcm2835 and bcm2836 implementations, leaving the CPU configuration to
>   * bcm2835.dtsi and bcm2836.dtsi.
> 


-- 
Florian


From eric at anholt.net  Tue May  9 09:48:31 2017
From: eric at anholt.net (Eric Anholt)
Date: Tue, 09 May 2017 09:48:31 -0700
Subject: [PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware
In-Reply-To: <b6aef857-1454-7931-2c60-6d7b55b7a0a8@raspberrypi.org>
References: <b6aef857-1454-7931-2c60-6d7b55b7a0a8@raspberrypi.org>
Message-ID: <8737cenfhc.fsf@eliezer.anholt.net>

Phil Elwell <phil at raspberrypi.org> writes:

> The Raspberry Pi startup stub files for multi-core BCM27XX processors
> make the secondary CPUs spin until the corresponding mailbox is
> written. These stubs are loaded at physical address 0x00000xxx (as seen
> by the ARMs), but this page will be reused by the kernel unless it is
> explicitly reserved, causing the waiting cores to execute random code.
>
> Use the /memreserve/ Device Tree directive to mark the first page as
> off-limits to the kernel.
>
> See: https://github.com/raspberrypi/linux/issues/1989
>
> Signed-off-by: Phil Elwell <phil at raspberrypi.org>

This looks great.  We're currently in the merge window, so I can't
generate a new bcm2835-dt-next yet, but I'll pick this patch up when I
do.

Thanks for submitting upstream!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170509/8d2cfa63/attachment.sig>

From f.fainelli at gmail.com  Tue May  9 09:52:53 2017
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 9 May 2017 09:52:53 -0700
Subject: [PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware
In-Reply-To: <8737cenfhc.fsf@eliezer.anholt.net>
References: <b6aef857-1454-7931-2c60-6d7b55b7a0a8@raspberrypi.org>
 <8737cenfhc.fsf@eliezer.anholt.net>
Message-ID: <bdc05058-f65b-da08-0cf5-51aa1f97852e@gmail.com>

On 05/09/2017 09:48 AM, Eric Anholt wrote:
> Phil Elwell <phil at raspberrypi.org> writes:
> 
>> The Raspberry Pi startup stub files for multi-core BCM27XX processors
>> make the secondary CPUs spin until the corresponding mailbox is
>> written. These stubs are loaded at physical address 0x00000xxx (as seen
>> by the ARMs), but this page will be reused by the kernel unless it is
>> explicitly reserved, causing the waiting cores to execute random code.
>>
>> Use the /memreserve/ Device Tree directive to mark the first page as
>> off-limits to the kernel.
>>
>> See: https://github.com/raspberrypi/linux/issues/1989
>>
>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
> 
> This looks great.  We're currently in the merge window, so I can't
> generate a new bcm2835-dt-next yet, but I'll pick this patch up when I
> do.
> 
> Thanks for submitting upstream!

Considering that this is a fix, we could actually squeeze it in the
devicetree/fixes branch and we could submit those as soon as v4.12-rc1
is tagged, your call.
-- 
Florian


From eric at anholt.net  Tue May  9 09:59:04 2017
From: eric at anholt.net (Eric Anholt)
Date: Tue, 09 May 2017 09:59:04 -0700
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
Message-ID: <87ziemm0fb.fsf@eliezer.anholt.net>

Phil Elwell <phil at raspberrypi.org> writes:

> In order to reduce power consumption and bus traffic, it is sensible
> for secondary cores to enter a low-power idle state when waiting to
> be started. The wfe instruction causes a core to wait until an event
> or interrupt arrives before continuing to the next instruction.
> The sev instruction sends a wakeup event to the other cores, so call
> it from bcm2836_smp_boot_secondary, the function that wakes up the
> waiting cores during booting.
>
> It is harmless to use this patch without the corresponding change
> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
> and this patch is not applied then the other cores will sleep forever.
>
> See: https://github.com/raspberrypi/linux/issues/1989
>
> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
> ---
>  drivers/irqchip/irq-bcm2836.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
> index e10597c..6dccdf9 100644
> --- a/drivers/irqchip/irq-bcm2836.c
> +++ b/drivers/irqchip/irq-bcm2836.c
> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>  	writel(secondary_startup_phys,
>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>  
> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
> +	sev();
> +
>  	return 0;
>  }

This is also the behavior that the standard arm64 spin-table method has,
which we unfortunately can't quite use.

Acked-by: Eric Anholt <eric at anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170509/7a5a6846/attachment.sig>

From marc.zyngier at arm.com  Tue May  9 10:09:39 2017
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 9 May 2017 18:09:39 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <87ziemm0fb.fsf@eliezer.anholt.net>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
Message-ID: <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>

On 09/05/17 17:59, Eric Anholt wrote:
> Phil Elwell <phil at raspberrypi.org> writes:
> 
>> In order to reduce power consumption and bus traffic, it is sensible
>> for secondary cores to enter a low-power idle state when waiting to
>> be started. The wfe instruction causes a core to wait until an event
>> or interrupt arrives before continuing to the next instruction.
>> The sev instruction sends a wakeup event to the other cores, so call
>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>> waiting cores during booting.
>>
>> It is harmless to use this patch without the corresponding change
>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>> and this patch is not applied then the other cores will sleep forever.
>>
>> See: https://github.com/raspberrypi/linux/issues/1989
>>
>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>> ---
>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>> index e10597c..6dccdf9 100644
>> --- a/drivers/irqchip/irq-bcm2836.c
>> +++ b/drivers/irqchip/irq-bcm2836.c
>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>  	writel(secondary_startup_phys,
>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>  
>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>> +	sev();
>> +
>>  	return 0;
>>  }
> 
> This is also the behavior that the standard arm64 spin-table method has,
> which we unfortunately can't quite use.

And why is that so? Why do you have to reinvent the wheel (and hide the
cloned wheel in an interrupt controller driver)?

That doesn't seem right to me.

	M.
-- 
Jazz is not dead. It just smells funny...


From marc.zyngier at arm.com  Tue May  9 11:14:55 2017
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 9 May 2017 19:14:55 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <87o9v1c37r.fsf@eliezer.anholt.net>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
Message-ID: <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>

On 09/05/17 19:08, Eric Anholt wrote:
> Marc Zyngier <marc.zyngier at arm.com> writes:
> 
>> On 09/05/17 17:59, Eric Anholt wrote:
>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>
>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>> for secondary cores to enter a low-power idle state when waiting to
>>>> be started. The wfe instruction causes a core to wait until an event
>>>> or interrupt arrives before continuing to the next instruction.
>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>> waiting cores during booting.
>>>>
>>>> It is harmless to use this patch without the corresponding change
>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>> and this patch is not applied then the other cores will sleep forever.
>>>>
>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>
>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>> ---
>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>  1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>> index e10597c..6dccdf9 100644
>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>  	writel(secondary_startup_phys,
>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>  
>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>> +	sev();
>>>> +
>>>>  	return 0;
>>>>  }
>>>
>>> This is also the behavior that the standard arm64 spin-table method has,
>>> which we unfortunately can't quite use.
>>
>> And why is that so? Why do you have to reinvent the wheel (and hide the
>> cloned wheel in an interrupt controller driver)?
>>
>> That doesn't seem right to me.
> 
> The armv8 stubs (firmware-supplied code in the low page that do the
> spinning) do actually implement arm64's spin-table method.  It's the
> armv7 stubs that use these registers in the irqchip instead of plain
> addresses in system memory.

Let's put ARMv7 aside for the time being. If your firmware already
implements spin-tables, why don't you simply use that at least on arm64?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From phil at raspberrypi.org  Tue May  9 11:52:08 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Tue, 9 May 2017 19:52:08 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
Message-ID: <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>

On 09/05/2017 19:14, Marc Zyngier wrote:
> On 09/05/17 19:08, Eric Anholt wrote:
>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>
>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>
>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>> or interrupt arrives before continuing to the next instruction.
>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>> waiting cores during booting.
>>>>>
>>>>> It is harmless to use this patch without the corresponding change
>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>
>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>
>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>> ---
>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>  1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>> index e10597c..6dccdf9 100644
>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>  	writel(secondary_startup_phys,
>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>
>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>> +	sev();
>>>>> +
>>>>>  	return 0;
>>>>>  }
>>>>
>>>> This is also the behavior that the standard arm64 spin-table method has,
>>>> which we unfortunately can't quite use.
>>>
>>> And why is that so? Why do you have to reinvent the wheel (and hide the
>>> cloned wheel in an interrupt controller driver)?
>>>
>>> That doesn't seem right to me.
>>
>> The armv8 stubs (firmware-supplied code in the low page that do the
>> spinning) do actually implement arm64's spin-table method.  It's the
>> armv7 stubs that use these registers in the irqchip instead of plain
>> addresses in system memory.
>
> Let's put ARMv7 aside for the time being. If your firmware already
> implements spin-tables, why don't you simply use that at least on arm64?

We do.



From marc.zyngier at arm.com  Tue May  9 11:53:09 2017
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 9 May 2017 19:53:09 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
 <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
Message-ID: <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>

On 09/05/17 19:52, Phil Elwell wrote:
> On 09/05/2017 19:14, Marc Zyngier wrote:
>> On 09/05/17 19:08, Eric Anholt wrote:
>>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>>
>>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>>
>>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>>> or interrupt arrives before continuing to the next instruction.
>>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>>> waiting cores during booting.
>>>>>>
>>>>>> It is harmless to use this patch without the corresponding change
>>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>>
>>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>>
>>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>>> ---
>>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>>  1 file changed, 3 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>>> index e10597c..6dccdf9 100644
>>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>>  	writel(secondary_startup_phys,
>>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>>
>>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>>> +	sev();
>>>>>> +
>>>>>>  	return 0;
>>>>>>  }
>>>>>
>>>>> This is also the behavior that the standard arm64 spin-table method has,
>>>>> which we unfortunately can't quite use.
>>>>
>>>> And why is that so? Why do you have to reinvent the wheel (and hide the
>>>> cloned wheel in an interrupt controller driver)?
>>>>
>>>> That doesn't seem right to me.
>>>
>>> The armv8 stubs (firmware-supplied code in the low page that do the
>>> spinning) do actually implement arm64's spin-table method.  It's the
>>> armv7 stubs that use these registers in the irqchip instead of plain
>>> addresses in system memory.
>>
>> Let's put ARMv7 aside for the time being. If your firmware already
>> implements spin-tables, why don't you simply use that at least on arm64?
> 
> We do.

Obviously not the way it is intended if you have to duplicate the core
architectural code in the interrupt controller driver, which couldn't
care less.

	M.
-- 
Jazz is not dead. It just smells funny...


From phil at raspberrypi.org  Tue May  9 12:02:29 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Tue, 9 May 2017 20:02:29 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
 <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
 <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>
Message-ID: <187815f0-1316-ee87-883d-11304064f8f9@raspberrypi.org>

On 09/05/2017 19:53, Marc Zyngier wrote:
> On 09/05/17 19:52, Phil Elwell wrote:
>> On 09/05/2017 19:14, Marc Zyngier wrote:
>>> On 09/05/17 19:08, Eric Anholt wrote:
>>>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>>>
>>>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>>>
>>>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>>>> or interrupt arrives before continuing to the next instruction.
>>>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>>>> waiting cores during booting.
>>>>>>>
>>>>>>> It is harmless to use this patch without the corresponding change
>>>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>>>
>>>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>>>
>>>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>>>> ---
>>>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>>>  1 file changed, 3 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>>>> index e10597c..6dccdf9 100644
>>>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>>>  	writel(secondary_startup_phys,
>>>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>>>
>>>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>>>> +	sev();
>>>>>>> +
>>>>>>>  	return 0;
>>>>>>>  }
>>>>>>
>>>>>> This is also the behavior that the standard arm64 spin-table method has,
>>>>>> which we unfortunately can't quite use.
>>>>>
>>>>> And why is that so? Why do you have to reinvent the wheel (and hide the
>>>>> cloned wheel in an interrupt controller driver)?
>>>>>
>>>>> That doesn't seem right to me.
>>>>
>>>> The armv8 stubs (firmware-supplied code in the low page that do the
>>>> spinning) do actually implement arm64's spin-table method.  It's the
>>>> armv7 stubs that use these registers in the irqchip instead of plain
>>>> addresses in system memory.
>>>
>>> Let's put ARMv7 aside for the time being. If your firmware already
>>> implements spin-tables, why don't you simply use that at least on arm64?
>>
>> We do.
>
> Obviously not the way it is intended if you have to duplicate the core
> architectural code in the interrupt controller driver, which couldn't
> care less.

If we were using this method on arm64 then the other cores would not start up
because armstub8.S has always included a wfe. Nothing in the commit mentions
arm64 - this is an ARCH=arm fix.

Phil


From marc.zyngier at arm.com  Wed May 10 00:42:50 2017
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 May 2017 08:42:50 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <187815f0-1316-ee87-883d-11304064f8f9@raspberrypi.org>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
 <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
 <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>
 <187815f0-1316-ee87-883d-11304064f8f9@raspberrypi.org>
Message-ID: <06fad93c-a850-a99a-ae60-7306f9179032@arm.com>

On 09/05/17 20:02, Phil Elwell wrote:
> On 09/05/2017 19:53, Marc Zyngier wrote:
>> On 09/05/17 19:52, Phil Elwell wrote:
>>> On 09/05/2017 19:14, Marc Zyngier wrote:
>>>> On 09/05/17 19:08, Eric Anholt wrote:
>>>>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>>>>
>>>>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>>>>
>>>>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>>>>> or interrupt arrives before continuing to the next instruction.
>>>>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>>>>> waiting cores during booting.
>>>>>>>>
>>>>>>>> It is harmless to use this patch without the corresponding change
>>>>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>>>>
>>>>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>>>>
>>>>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>>>>> ---
>>>>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>>>>  1 file changed, 3 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>>>>> index e10597c..6dccdf9 100644
>>>>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>>>>  	writel(secondary_startup_phys,
>>>>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>>>>
>>>>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>>>>> +	sev();
>>>>>>>> +
>>>>>>>>  	return 0;
>>>>>>>>  }
>>>>>>>
>>>>>>> This is also the behavior that the standard arm64 spin-table method has,
>>>>>>> which we unfortunately can't quite use.
>>>>>>
>>>>>> And why is that so? Why do you have to reinvent the wheel (and hide the
>>>>>> cloned wheel in an interrupt controller driver)?
>>>>>>
>>>>>> That doesn't seem right to me.
>>>>>
>>>>> The armv8 stubs (firmware-supplied code in the low page that do the
>>>>> spinning) do actually implement arm64's spin-table method.  It's the
>>>>> armv7 stubs that use these registers in the irqchip instead of plain
>>>>> addresses in system memory.
>>>>
>>>> Let's put ARMv7 aside for the time being. If your firmware already
>>>> implements spin-tables, why don't you simply use that at least on arm64?
>>>
>>> We do.
>>
>> Obviously not the way it is intended if you have to duplicate the core
>> architectural code in the interrupt controller driver, which couldn't
>> care less.
> 
> If we were using this method on arm64 then the other cores would not start up
> because armstub8.S has always included a wfe. Nothing in the commit mentions
> arm64 - this is an ARCH=arm fix.

Thanks for the clarification, which you could have added to the commit
message.

The question still remains: why do we have CPU bring-up code in an
interrupt controller, instead of having it in the architecture code?

The RPi-2 is the *only* platform to have its SMP bringup code outside of
arch/arm, so the first course of action would be to move that code where
it belongs.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From phil at raspberrypi.org  Wed May 10 01:27:10 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Wed, 10 May 2017 09:27:10 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <06fad93c-a850-a99a-ae60-7306f9179032@arm.com>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
 <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
 <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>
 <187815f0-1316-ee87-883d-11304064f8f9@raspberrypi.org>
 <06fad93c-a850-a99a-ae60-7306f9179032@arm.com>
Message-ID: <f1394925-0651-0390-b646-1c489bfe6b4d@raspberrypi.org>

On 10/05/2017 08:42, Marc Zyngier wrote:
> On 09/05/17 20:02, Phil Elwell wrote:
>> On 09/05/2017 19:53, Marc Zyngier wrote:
>>> On 09/05/17 19:52, Phil Elwell wrote:
>>>> On 09/05/2017 19:14, Marc Zyngier wrote:
>>>>> On 09/05/17 19:08, Eric Anholt wrote:
>>>>>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>>>>>
>>>>>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>>>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>>>>>
>>>>>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>>>>>> or interrupt arrives before continuing to the next instruction.
>>>>>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>>>>>> waiting cores during booting.
>>>>>>>>>
>>>>>>>>> It is harmless to use this patch without the corresponding change
>>>>>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>>>>>
>>>>>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>>>>>
>>>>>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>>>>>> ---
>>>>>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>>>>>  1 file changed, 3 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>> index e10597c..6dccdf9 100644
>>>>>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>>>>>  	writel(secondary_startup_phys,
>>>>>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>>>>>
>>>>>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>>>>>> +	sev();
>>>>>>>>> +
>>>>>>>>>  	return 0;
>>>>>>>>>  }
>>>>>>>>
>>>>>>>> This is also the behavior that the standard arm64 spin-table method has,
>>>>>>>> which we unfortunately can't quite use.
>>>>>>>
>>>>>>> And why is that so? Why do you have to reinvent the wheel (and hide the
>>>>>>> cloned wheel in an interrupt controller driver)?
>>>>>>>
>>>>>>> That doesn't seem right to me.
>>>>>>
>>>>>> The armv8 stubs (firmware-supplied code in the low page that do the
>>>>>> spinning) do actually implement arm64's spin-table method.  It's the
>>>>>> armv7 stubs that use these registers in the irqchip instead of plain
>>>>>> addresses in system memory.
>>>>>
>>>>> Let's put ARMv7 aside for the time being. If your firmware already
>>>>> implements spin-tables, why don't you simply use that at least on arm64?
>>>>
>>>> We do.
>>>
>>> Obviously not the way it is intended if you have to duplicate the core
>>> architectural code in the interrupt controller driver, which couldn't
>>> care less.
>>
>> If we were using this method on arm64 then the other cores would not start up
>> because armstub8.S has always included a wfe. Nothing in the commit mentions
>> arm64 - this is an ARCH=arm fix.
> 
> Thanks for the clarification, which you could have added to the commit
> message.
> 
> The question still remains: why do we have CPU bring-up code in an
> interrupt controller, instead of having it in the architecture code?
> 
> The RPi-2 is the *only* platform to have its SMP bringup code outside of
> arch/arm, so the first course of action would be to move that code where
> it belongs.

You were CC'd on the commit (41f4988cc287e5f836d3f6620c9f900bc9b560e9) that
introduced bcm2836_smp_boot_secondary - it seems strange to start objecting
now. Yes, I think it is odd that it didn't go into arch/arm/mach-bcm, but in
the interests of making changes in small, independent steps, do you have a
problem with this commit?

Phil



From marc.zyngier at arm.com  Wed May 10 01:55:49 2017
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 May 2017 09:55:49 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <f1394925-0651-0390-b646-1c489bfe6b4d@raspberrypi.org> (Phil
 Elwell's message of "Wed, 10 May 2017 09:27:10 +0100")
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
 <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
 <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>
 <187815f0-1316-ee87-883d-11304064f8f9@raspberrypi.org>
 <06fad93c-a850-a99a-ae60-7306f9179032@arm.com>
 <f1394925-0651-0390-b646-1c489bfe6b4d@raspberrypi.org>
Message-ID: <87tw4thyzu.fsf@on-the-bus.cambridge.arm.com>

On Wed, May 10 2017 at  9:27:10 am BST, Phil Elwell <phil at raspberrypi.org> wrote:
> On 10/05/2017 08:42, Marc Zyngier wrote:
>> On 09/05/17 20:02, Phil Elwell wrote:
>>> On 09/05/2017 19:53, Marc Zyngier wrote:
>>>> On 09/05/17 19:52, Phil Elwell wrote:
>>>>> On 09/05/2017 19:14, Marc Zyngier wrote:
>>>>>> On 09/05/17 19:08, Eric Anholt wrote:
>>>>>>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>>>>>>
>>>>>>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>>>>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>>>>>>
>>>>>>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>>>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>>>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>>>>>>> or interrupt arrives before continuing to the next instruction.
>>>>>>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>>>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>>>>>>> waiting cores during booting.
>>>>>>>>>>
>>>>>>>>>> It is harmless to use this patch without the corresponding change
>>>>>>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>>>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>>>>>>
>>>>>>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>>>>>>> ---
>>>>>>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>>>>>>  1 file changed, 3 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>> index e10597c..6dccdf9 100644
>>>>>>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>>>>>>  	writel(secondary_startup_phys,
>>>>>>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>>>>>>
>>>>>>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>>>>>>> +	sev();
>>>>>>>>>> +
>>>>>>>>>>  	return 0;
>>>>>>>>>>  }
>>>>>>>>>
>>>>>>>>> This is also the behavior that the standard arm64 spin-table
>>>>>>>>> method has,
>>>>>>>>> which we unfortunately can't quite use.
>>>>>>>>
>>>>>>>> And why is that so? Why do you have to reinvent the wheel (and hide the
>>>>>>>> cloned wheel in an interrupt controller driver)?
>>>>>>>>
>>>>>>>> That doesn't seem right to me.
>>>>>>>
>>>>>>> The armv8 stubs (firmware-supplied code in the low page that do the
>>>>>>> spinning) do actually implement arm64's spin-table method.  It's the
>>>>>>> armv7 stubs that use these registers in the irqchip instead of plain
>>>>>>> addresses in system memory.
>>>>>>
>>>>>> Let's put ARMv7 aside for the time being. If your firmware already
>>>>>> implements spin-tables, why don't you simply use that at least on arm64?
>>>>>
>>>>> We do.
>>>>
>>>> Obviously not the way it is intended if you have to duplicate the core
>>>> architectural code in the interrupt controller driver, which couldn't
>>>> care less.
>>>
>>> If we were using this method on arm64 then the other cores would not start up
>>> because armstub8.S has always included a wfe. Nothing in the commit mentions
>>> arm64 - this is an ARCH=arm fix.
>> 
>> Thanks for the clarification, which you could have added to the commit
>> message.
>> 
>> The question still remains: why do we have CPU bring-up code in an
>> interrupt controller, instead of having it in the architecture code?
>> 
>> The RPi-2 is the *only* platform to have its SMP bringup code outside of
>> arch/arm, so the first course of action would be to move that code where
>> it belongs.
>
> You were CC'd on the commit (41f4988cc287e5f836d3f6620c9f900bc9b560e9) that
> introduced bcm2836_smp_boot_secondary - it seems strange to start objecting
> now.

Well, I'm far from being perfect. If I had noticed it, I'd have NACKed
it.

> Yes, I think it is odd that it didn't go into arch/arm/mach-bcm, but in
> the interests of making changes in small, independent steps, do you have a
> problem with this commit?

On its own, no. I'm just not keen on adding more unrelated stuff to this
file, so let's start with dealing with the original bug, and you can
then add this fix on top.

Thanks,

	M.
-- 
Jazz is not dead, it just smell funny.


From phil at raspberrypi.org  Wed May 10 02:05:23 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Wed, 10 May 2017 10:05:23 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <87tw4thyzu.fsf@on-the-bus.cambridge.arm.com>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
 <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
 <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>
 <187815f0-1316-ee87-883d-11304064f8f9@raspberrypi.org>
 <06fad93c-a850-a99a-ae60-7306f9179032@arm.com>
 <f1394925-0651-0390-b646-1c489bfe6b4d@raspberrypi.org>
 <87tw4thyzu.fsf@on-the-bus.cambridge.arm.com>
Message-ID: <a614119f-45a6-1fda-a261-e7e1a390b823@raspberrypi.org>

On 10/05/2017 09:55, Marc Zyngier wrote:
> On Wed, May 10 2017 at  9:27:10 am BST, Phil Elwell <phil at raspberrypi.org> wrote:
>> On 10/05/2017 08:42, Marc Zyngier wrote:
>>> On 09/05/17 20:02, Phil Elwell wrote:
>>>> On 09/05/2017 19:53, Marc Zyngier wrote:
>>>>> On 09/05/17 19:52, Phil Elwell wrote:
>>>>>> On 09/05/2017 19:14, Marc Zyngier wrote:
>>>>>>> On 09/05/17 19:08, Eric Anholt wrote:
>>>>>>>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>>>>>>>
>>>>>>>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>>>>>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>>>>>>>
>>>>>>>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>>>>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>>>>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>>>>>>>> or interrupt arrives before continuing to the next instruction.
>>>>>>>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>>>>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>>>>>>>> waiting cores during booting.
>>>>>>>>>>>
>>>>>>>>>>> It is harmless to use this patch without the corresponding change
>>>>>>>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>>>>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>>>>>>>
>>>>>>>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>>>>>>>> ---
>>>>>>>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>>>>>>>  1 file changed, 3 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>> index e10597c..6dccdf9 100644
>>>>>>>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>>>>>>>  	writel(secondary_startup_phys,
>>>>>>>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>>>>>>>
>>>>>>>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>>>>>>>> +	sev();
>>>>>>>>>>> +
>>>>>>>>>>>  	return 0;
>>>>>>>>>>>  }
>>>>>>>>>>
>>>>>>>>>> This is also the behavior that the standard arm64 spin-table
>>>>>>>>>> method has,
>>>>>>>>>> which we unfortunately can't quite use.
>>>>>>>>>
>>>>>>>>> And why is that so? Why do you have to reinvent the wheel (and hide the
>>>>>>>>> cloned wheel in an interrupt controller driver)?
>>>>>>>>>
>>>>>>>>> That doesn't seem right to me.
>>>>>>>>
>>>>>>>> The armv8 stubs (firmware-supplied code in the low page that do the
>>>>>>>> spinning) do actually implement arm64's spin-table method.  It's the
>>>>>>>> armv7 stubs that use these registers in the irqchip instead of plain
>>>>>>>> addresses in system memory.
>>>>>>>
>>>>>>> Let's put ARMv7 aside for the time being. If your firmware already
>>>>>>> implements spin-tables, why don't you simply use that at least on arm64?
>>>>>>
>>>>>> We do.
>>>>>
>>>>> Obviously not the way it is intended if you have to duplicate the core
>>>>> architectural code in the interrupt controller driver, which couldn't
>>>>> care less.
>>>>
>>>> If we were using this method on arm64 then the other cores would not start up
>>>> because armstub8.S has always included a wfe. Nothing in the commit mentions
>>>> arm64 - this is an ARCH=arm fix.
>>>
>>> Thanks for the clarification, which you could have added to the commit
>>> message.
>>>
>>> The question still remains: why do we have CPU bring-up code in an
>>> interrupt controller, instead of having it in the architecture code?
>>>
>>> The RPi-2 is the *only* platform to have its SMP bringup code outside of
>>> arch/arm, so the first course of action would be to move that code where
>>> it belongs.
>>
>> You were CC'd on the commit (41f4988cc287e5f836d3f6620c9f900bc9b560e9) that
>> introduced bcm2836_smp_boot_secondary - it seems strange to start objecting
>> now.
> 
> Well, I'm far from being perfect. If I had noticed it, I'd have NACKed
> it.
> 
>> Yes, I think it is odd that it didn't go into arch/arm/mach-bcm, but in
>> the interests of making changes in small, independent steps, do you have a
>> problem with this commit?
> 
> On its own, no. I'm just not keen on adding more unrelated stuff to this
> file, so let's start with dealing with the original bug, and you can
> then add this fix on top.

That's an interesting use of the word "bug". From Wikipedia:

"A software bug is an error, flaw, failure or fault in a computer program or
system that causes it to produce an incorrect or unexpected result, or to
behave in unintended ways."

Although your concerns are valid, the faults you are objecting to are not causing
a malfunction of any kind. If we were to update the RPi firmware before this
patch was merged then upstream users would be left with one wheel on their wagon.

Phil


From marc.zyngier at arm.com  Wed May 10 03:09:06 2017
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 May 2017 11:09:06 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <a614119f-45a6-1fda-a261-e7e1a390b823@raspberrypi.org>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
 <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
 <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>
 <187815f0-1316-ee87-883d-11304064f8f9@raspberrypi.org>
 <06fad93c-a850-a99a-ae60-7306f9179032@arm.com>
 <f1394925-0651-0390-b646-1c489bfe6b4d@raspberrypi.org>
 <87tw4thyzu.fsf@on-the-bus.cambridge.arm.com>
 <a614119f-45a6-1fda-a261-e7e1a390b823@raspberrypi.org>
Message-ID: <907820fc-c100-dad4-cf4f-95aa330667c5@arm.com>

On 10/05/17 10:05, Phil Elwell wrote:
> On 10/05/2017 09:55, Marc Zyngier wrote:
>> On Wed, May 10 2017 at  9:27:10 am BST, Phil Elwell <phil at raspberrypi.org> wrote:
>>> On 10/05/2017 08:42, Marc Zyngier wrote:
>>>> On 09/05/17 20:02, Phil Elwell wrote:
>>>>> On 09/05/2017 19:53, Marc Zyngier wrote:
>>>>>> On 09/05/17 19:52, Phil Elwell wrote:
>>>>>>> On 09/05/2017 19:14, Marc Zyngier wrote:
>>>>>>>> On 09/05/17 19:08, Eric Anholt wrote:
>>>>>>>>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>>>>>>>>
>>>>>>>>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>>>>>>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>>>>>>>>
>>>>>>>>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>>>>>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>>>>>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>>>>>>>>> or interrupt arrives before continuing to the next instruction.
>>>>>>>>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>>>>>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>>>>>>>>> waiting cores during booting.
>>>>>>>>>>>>
>>>>>>>>>>>> It is harmless to use this patch without the corresponding change
>>>>>>>>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>>>>>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>>>>>>>>
>>>>>>>>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>>>>>>>>> ---
>>>>>>>>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>>>>>>>>  1 file changed, 3 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>> index e10597c..6dccdf9 100644
>>>>>>>>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>>>>>>>>  	writel(secondary_startup_phys,
>>>>>>>>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>>>>>>>>
>>>>>>>>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>>>>>>>>> +	sev();
>>>>>>>>>>>> +
>>>>>>>>>>>>  	return 0;
>>>>>>>>>>>>  }
>>>>>>>>>>>
>>>>>>>>>>> This is also the behavior that the standard arm64 spin-table
>>>>>>>>>>> method has,
>>>>>>>>>>> which we unfortunately can't quite use.
>>>>>>>>>>
>>>>>>>>>> And why is that so? Why do you have to reinvent the wheel (and hide the
>>>>>>>>>> cloned wheel in an interrupt controller driver)?
>>>>>>>>>>
>>>>>>>>>> That doesn't seem right to me.
>>>>>>>>>
>>>>>>>>> The armv8 stubs (firmware-supplied code in the low page that do the
>>>>>>>>> spinning) do actually implement arm64's spin-table method.  It's the
>>>>>>>>> armv7 stubs that use these registers in the irqchip instead of plain
>>>>>>>>> addresses in system memory.
>>>>>>>>
>>>>>>>> Let's put ARMv7 aside for the time being. If your firmware already
>>>>>>>> implements spin-tables, why don't you simply use that at least on arm64?
>>>>>>>
>>>>>>> We do.
>>>>>>
>>>>>> Obviously not the way it is intended if you have to duplicate the core
>>>>>> architectural code in the interrupt controller driver, which couldn't
>>>>>> care less.
>>>>>
>>>>> If we were using this method on arm64 then the other cores would not start up
>>>>> because armstub8.S has always included a wfe. Nothing in the commit mentions
>>>>> arm64 - this is an ARCH=arm fix.
>>>>
>>>> Thanks for the clarification, which you could have added to the commit
>>>> message.
>>>>
>>>> The question still remains: why do we have CPU bring-up code in an
>>>> interrupt controller, instead of having it in the architecture code?
>>>>
>>>> The RPi-2 is the *only* platform to have its SMP bringup code outside of
>>>> arch/arm, so the first course of action would be to move that code where
>>>> it belongs.
>>>
>>> You were CC'd on the commit (41f4988cc287e5f836d3f6620c9f900bc9b560e9) that
>>> introduced bcm2836_smp_boot_secondary - it seems strange to start objecting
>>> now.
>>
>> Well, I'm far from being perfect. If I had noticed it, I'd have NACKed
>> it.
>>
>>> Yes, I think it is odd that it didn't go into arch/arm/mach-bcm, but in
>>> the interests of making changes in small, independent steps, do you have a
>>> problem with this commit?
>>
>> On its own, no. I'm just not keen on adding more unrelated stuff to this
>> file, so let's start with dealing with the original bug, and you can
>> then add this fix on top.
> 
> That's an interesting use of the word "bug". From Wikipedia:
> 
> "A software bug is an error, flaw, failure or fault in a computer program or
> system that causes it to produce an incorrect or unexpected result, or to
> behave in unintended ways."

Whatever. Should I call it "pile of crap dumped in unsuitable locations"
instead? What does Wikipedia says about it?

> Although your concerns are valid, the faults you are objecting to are not causing
> a malfunction of any kind. If we were to update the RPi firmware before this
> patch was merged then upstream users would be left with one wheel on their wagon.

And that'd be your problem, not mine. Look, you can argue around this
all day, or you can fix this mess. Your choice.

	M.
-- 
Jazz is not dead. It just smells funny...


From f.fainelli at gmail.com  Wed May 10 09:21:43 2017
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Wed, 10 May 2017 09:21:43 -0700
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <1bbd3527-3328-b9c0-e9e0-d37092850a91@raspberrypi.org>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
 <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
 <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>
 <187815f0-1316-ee87-883d-11304064f8f9@raspberrypi.org>
 <06fad93c-a850-a99a-ae60-7306f9179032@arm.com>
 <f1394925-0651-0390-b646-1c489bfe6b4d@raspberrypi.org>
 <87tw4thyzu.fsf@on-the-bus.cambridge.arm.com>
 <a614119f-45a6-1fda-a261-e7e1a390b823@raspberrypi.org>
 <907820fc-c100-dad4-cf4f-95aa330667c5@arm.com>
 <1bbd3527-3328-b9c0-e9e0-d37092850a91@raspberrypi.org>
Message-ID: <817a2689-15df-f2e4-3b3d-e5831fba7fa3@gmail.com>

On 05/10/2017 03:31 AM, Phil Elwell wrote:
> On 10/05/2017 11:09, Marc Zyngier wrote:
>> On 10/05/17 10:05, Phil Elwell wrote:
>>> On 10/05/2017 09:55, Marc Zyngier wrote:
>>>> On Wed, May 10 2017 at  9:27:10 am BST, Phil Elwell <phil at raspberrypi.org> wrote:
>>>>> On 10/05/2017 08:42, Marc Zyngier wrote:
>>>>>> On 09/05/17 20:02, Phil Elwell wrote:
>>>>>>> On 09/05/2017 19:53, Marc Zyngier wrote:
>>>>>>>> On 09/05/17 19:52, Phil Elwell wrote:
>>>>>>>>> On 09/05/2017 19:14, Marc Zyngier wrote:
>>>>>>>>>> On 09/05/17 19:08, Eric Anholt wrote:
>>>>>>>>>>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>>>>>>>>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>>>>>>>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>>>>>>>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>>>>>>>>>>> or interrupt arrives before continuing to the next instruction.
>>>>>>>>>>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>>>>>>>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>>>>>>>>>>> waiting cores during booting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is harmless to use this patch without the corresponding change
>>>>>>>>>>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>>>>>>>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>>>>>>>>>>  1 file changed, 3 insertions(+)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>> index e10597c..6dccdf9 100644
>>>>>>>>>>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>>>>>>>>>>  	writel(secondary_startup_phys,
>>>>>>>>>>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>>>>>>>>>>> +	sev();
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>  	return 0;
>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is also the behavior that the standard arm64 spin-table
>>>>>>>>>>>>> method has,
>>>>>>>>>>>>> which we unfortunately can't quite use.
>>>>>>>>>>>>
>>>>>>>>>>>> And why is that so? Why do you have to reinvent the wheel (and hide the
>>>>>>>>>>>> cloned wheel in an interrupt controller driver)?
>>>>>>>>>>>>
>>>>>>>>>>>> That doesn't seem right to me.
>>>>>>>>>>>
>>>>>>>>>>> The armv8 stubs (firmware-supplied code in the low page that do the
>>>>>>>>>>> spinning) do actually implement arm64's spin-table method.  It's the
>>>>>>>>>>> armv7 stubs that use these registers in the irqchip instead of plain
>>>>>>>>>>> addresses in system memory.
>>>>>>>>>>
>>>>>>>>>> Let's put ARMv7 aside for the time being. If your firmware already
>>>>>>>>>> implements spin-tables, why don't you simply use that at least on arm64?
>>>>>>>>>
>>>>>>>>> We do.
>>>>>>>>
>>>>>>>> Obviously not the way it is intended if you have to duplicate the core
>>>>>>>> architectural code in the interrupt controller driver, which couldn't
>>>>>>>> care less.
>>>>>>>
>>>>>>> If we were using this method on arm64 then the other cores would not start up
>>>>>>> because armstub8.S has always included a wfe. Nothing in the commit mentions
>>>>>>> arm64 - this is an ARCH=arm fix.
>>>>>>
>>>>>> Thanks for the clarification, which you could have added to the commit
>>>>>> message.
>>>>>>
>>>>>> The question still remains: why do we have CPU bring-up code in an
>>>>>> interrupt controller, instead of having it in the architecture code?
>>>>>>
>>>>>> The RPi-2 is the *only* platform to have its SMP bringup code outside of
>>>>>> arch/arm, so the first course of action would be to move that code where
>>>>>> it belongs.
>>>>>
>>>>> You were CC'd on the commit (41f4988cc287e5f836d3f6620c9f900bc9b560e9) that
>>>>> introduced bcm2836_smp_boot_secondary - it seems strange to start objecting
>>>>> now.
>>>>
>>>> Well, I'm far from being perfect. If I had noticed it, I'd have NACKed
>>>> it.
>>>>
>>>>> Yes, I think it is odd that it didn't go into arch/arm/mach-bcm, but in
>>>>> the interests of making changes in small, independent steps, do you have a
>>>>> problem with this commit?
>>>>
>>>> On its own, no. I'm just not keen on adding more unrelated stuff to this
>>>> file, so let's start with dealing with the original bug, and you can
>>>> then add this fix on top.
>>>
>>> That's an interesting use of the word "bug". From Wikipedia:
>>>
>>> "A software bug is an error, flaw, failure or fault in a computer program or
>>> system that causes it to produce an incorrect or unexpected result, or to
>>> behave in unintended ways."
>>
>> Whatever. Should I call it "pile of crap dumped in unsuitable locations"
>> instead? What does Wikipedia says about it?
>>
>>> Although your concerns are valid, the faults you are objecting to are not causing
>>> a malfunction of any kind. If we were to update the RPi firmware before this
>>> patch was merged then upstream users would be left with one wheel on their wagon.
>>
>> And that'd be your problem, not mine. Look, you can argue around this
>> all day, or you can fix this mess. Your choice.
> 
> Is that the opinion of all here?

The choice of word here got largely out of the original topic and I
surely did eat a ton of popcorn here. There are two things that need
fixing, and the time line and process for fixing these is clear:

- your bugfix (Phil) is something that should be applied now, and
backported to -stable trees once the fix hits the irqchip tree (or Linus')

- relocating the code that does the secondary boot out of
drivers/irqchip/ into arch/arm/mach-bcm/ needs to happen (Marc), and
this is 4.13 material, there is no urgency in doing this *right now*,
but it needs to happen

Does that work for everyone?
-- 
Florian


From marc.zyngier at arm.com  Wed May 10 10:15:07 2017
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 May 2017 18:15:07 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <817a2689-15df-f2e4-3b3d-e5831fba7fa3@gmail.com>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
 <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
 <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>
 <187815f0-1316-ee87-883d-11304064f8f9@raspberrypi.org>
 <06fad93c-a850-a99a-ae60-7306f9179032@arm.com>
 <f1394925-0651-0390-b646-1c489bfe6b4d@raspberrypi.org>
 <87tw4thyzu.fsf@on-the-bus.cambridge.arm.com>
 <a614119f-45a6-1fda-a261-e7e1a390b823@raspberrypi.org>
 <907820fc-c100-dad4-cf4f-95aa330667c5@arm.com>
 <1bbd3527-3328-b9c0-e9e0-d37092850a91@raspberrypi.org>
 <817a2689-15df-f2e4-3b3d-e5831fba7fa3@gmail.com>
Message-ID: <20b7df59-3f10-4e89-f87f-2e8c6af40d52@arm.com>

On 10/05/17 17:21, Florian Fainelli wrote:
> On 05/10/2017 03:31 AM, Phil Elwell wrote:
>> On 10/05/2017 11:09, Marc Zyngier wrote:
>>> On 10/05/17 10:05, Phil Elwell wrote:
>>>> On 10/05/2017 09:55, Marc Zyngier wrote:
>>>>> On Wed, May 10 2017 at  9:27:10 am BST, Phil Elwell <phil at raspberrypi.org> wrote:
>>>>>> On 10/05/2017 08:42, Marc Zyngier wrote:
>>>>>>> On 09/05/17 20:02, Phil Elwell wrote:
>>>>>>>> On 09/05/2017 19:53, Marc Zyngier wrote:
>>>>>>>>> On 09/05/17 19:52, Phil Elwell wrote:
>>>>>>>>>> On 09/05/2017 19:14, Marc Zyngier wrote:
>>>>>>>>>>> On 09/05/17 19:08, Eric Anholt wrote:
>>>>>>>>>>>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>>>>>>>>>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>>>>>>>>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>>>>>>>>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>>>>>>>>>>>> or interrupt arrives before continuing to the next instruction.
>>>>>>>>>>>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>>>>>>>>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>>>>>>>>>>>> waiting cores during booting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is harmless to use this patch without the corresponding change
>>>>>>>>>>>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>>>>>>>>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>>>>>>>>>>>  1 file changed, 3 insertions(+)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>>> index e10597c..6dccdf9 100644
>>>>>>>>>>>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>>>>>>>>>>>  	writel(secondary_startup_phys,
>>>>>>>>>>>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>>>>>>>>>>>> +	sev();
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>  	return 0;
>>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is also the behavior that the standard arm64 spin-table
>>>>>>>>>>>>>> method has,
>>>>>>>>>>>>>> which we unfortunately can't quite use.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And why is that so? Why do you have to reinvent the wheel (and hide the
>>>>>>>>>>>>> cloned wheel in an interrupt controller driver)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> That doesn't seem right to me.
>>>>>>>>>>>>
>>>>>>>>>>>> The armv8 stubs (firmware-supplied code in the low page that do the
>>>>>>>>>>>> spinning) do actually implement arm64's spin-table method.  It's the
>>>>>>>>>>>> armv7 stubs that use these registers in the irqchip instead of plain
>>>>>>>>>>>> addresses in system memory.
>>>>>>>>>>>
>>>>>>>>>>> Let's put ARMv7 aside for the time being. If your firmware already
>>>>>>>>>>> implements spin-tables, why don't you simply use that at least on arm64?
>>>>>>>>>>
>>>>>>>>>> We do.
>>>>>>>>>
>>>>>>>>> Obviously not the way it is intended if you have to duplicate the core
>>>>>>>>> architectural code in the interrupt controller driver, which couldn't
>>>>>>>>> care less.
>>>>>>>>
>>>>>>>> If we were using this method on arm64 then the other cores would not start up
>>>>>>>> because armstub8.S has always included a wfe. Nothing in the commit mentions
>>>>>>>> arm64 - this is an ARCH=arm fix.
>>>>>>>
>>>>>>> Thanks for the clarification, which you could have added to the commit
>>>>>>> message.
>>>>>>>
>>>>>>> The question still remains: why do we have CPU bring-up code in an
>>>>>>> interrupt controller, instead of having it in the architecture code?
>>>>>>>
>>>>>>> The RPi-2 is the *only* platform to have its SMP bringup code outside of
>>>>>>> arch/arm, so the first course of action would be to move that code where
>>>>>>> it belongs.
>>>>>>
>>>>>> You were CC'd on the commit (41f4988cc287e5f836d3f6620c9f900bc9b560e9) that
>>>>>> introduced bcm2836_smp_boot_secondary - it seems strange to start objecting
>>>>>> now.
>>>>>
>>>>> Well, I'm far from being perfect. If I had noticed it, I'd have NACKed
>>>>> it.
>>>>>
>>>>>> Yes, I think it is odd that it didn't go into arch/arm/mach-bcm, but in
>>>>>> the interests of making changes in small, independent steps, do you have a
>>>>>> problem with this commit?
>>>>>
>>>>> On its own, no. I'm just not keen on adding more unrelated stuff to this
>>>>> file, so let's start with dealing with the original bug, and you can
>>>>> then add this fix on top.
>>>>
>>>> That's an interesting use of the word "bug". From Wikipedia:
>>>>
>>>> "A software bug is an error, flaw, failure or fault in a computer program or
>>>> system that causes it to produce an incorrect or unexpected result, or to
>>>> behave in unintended ways."
>>>
>>> Whatever. Should I call it "pile of crap dumped in unsuitable locations"
>>> instead? What does Wikipedia says about it?
>>>
>>>> Although your concerns are valid, the faults you are objecting to are not causing
>>>> a malfunction of any kind. If we were to update the RPi firmware before this
>>>> patch was merged then upstream users would be left with one wheel on their wagon.
>>>
>>> And that'd be your problem, not mine. Look, you can argue around this
>>> all day, or you can fix this mess. Your choice.
>>
>> Is that the opinion of all here?
> 
> The choice of word here got largely out of the original topic and I
> surely did eat a ton of popcorn here. There are two things that need

Always happy to entertain.

> fixing, and the time line and process for fixing these is clear:
> 
> - your bugfix (Phil) is something that should be applied now, and
> backported to -stable trees once the fix hits the irqchip tree (or Linus')

Why? As far as I can tell, none of the current platforms are affected,
since the corresponding firmware hasn't been distributed. So by the
letter of this, this patch is 4.13 material too.

> - relocating the code that does the secondary boot out of
> drivers/irqchip/ into arch/arm/mach-bcm/ needs to happen (Marc), and
> this is 4.13 material, there is no urgency in doing this *right now*,
> but it needs to happen
> 
> Does that work for everyone?

I'm strongly opposed to it. Moving code over to arch/arm/ has zero risk,
and removes crap from the existing code. Hell, make the whole thing one
patch if that makes it easier for you to backport. But piling more crap
there? No, thank you.

	M.
-- 
Jazz is not dead. It just smells funny...


From f.fainelli at gmail.com  Wed May 10 10:59:27 2017
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Wed, 10 May 2017 10:59:27 -0700
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <20b7df59-3f10-4e89-f87f-2e8c6af40d52@arm.com>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
 <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
 <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>
 <187815f0-1316-ee87-883d-11304064f8f9@raspberrypi.org>
 <06fad93c-a850-a99a-ae60-7306f9179032@arm.com>
 <f1394925-0651-0390-b646-1c489bfe6b4d@raspberrypi.org>
 <87tw4thyzu.fsf@on-the-bus.cambridge.arm.com>
 <a614119f-45a6-1fda-a261-e7e1a390b823@raspberrypi.org>
 <907820fc-c100-dad4-cf4f-95aa330667c5@arm.com>
 <1bbd3527-3328-b9c0-e9e0-d37092850a91@raspberrypi.org>
 <817a2689-15df-f2e4-3b3d-e5831fba7fa3@gmail.com>
 <20b7df59-3f10-4e89-f87f-2e8c6af40d52@arm.com>
Message-ID: <aea9abf7-6206-8878-fa63-de5bbbcb3533@gmail.com>

On 05/10/2017 10:15 AM, Marc Zyngier wrote:
> On 10/05/17 17:21, Florian Fainelli wrote:
>> On 05/10/2017 03:31 AM, Phil Elwell wrote:
>>> On 10/05/2017 11:09, Marc Zyngier wrote:
>>>> On 10/05/17 10:05, Phil Elwell wrote:
>>>>> On 10/05/2017 09:55, Marc Zyngier wrote:
>>>>>> On Wed, May 10 2017 at  9:27:10 am BST, Phil Elwell <phil at raspberrypi.org> wrote:
>>>>>>> On 10/05/2017 08:42, Marc Zyngier wrote:
>>>>>>>> On 09/05/17 20:02, Phil Elwell wrote:
>>>>>>>>> On 09/05/2017 19:53, Marc Zyngier wrote:
>>>>>>>>>> On 09/05/17 19:52, Phil Elwell wrote:
>>>>>>>>>>> On 09/05/2017 19:14, Marc Zyngier wrote:
>>>>>>>>>>>> On 09/05/17 19:08, Eric Anholt wrote:
>>>>>>>>>>>>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>>>>>>>>>>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>>>>>>>>>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>>>>>>>>>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>>>>>>>>>>>>> or interrupt arrives before continuing to the next instruction.
>>>>>>>>>>>>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>>>>>>>>>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>>>>>>>>>>>>> waiting cores during booting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is harmless to use this patch without the corresponding change
>>>>>>>>>>>>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>>>>>>>>>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>>>>>>>>>>>>  1 file changed, 3 insertions(+)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>>>> index e10597c..6dccdf9 100644
>>>>>>>>>>>>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>>>>>>>>>>>>  	writel(secondary_startup_phys,
>>>>>>>>>>>>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>>>>>>>>>>>>> +	sev();
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>  	return 0;
>>>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is also the behavior that the standard arm64 spin-table
>>>>>>>>>>>>>>> method has,
>>>>>>>>>>>>>>> which we unfortunately can't quite use.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And why is that so? Why do you have to reinvent the wheel (and hide the
>>>>>>>>>>>>>> cloned wheel in an interrupt controller driver)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That doesn't seem right to me.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The armv8 stubs (firmware-supplied code in the low page that do the
>>>>>>>>>>>>> spinning) do actually implement arm64's spin-table method.  It's the
>>>>>>>>>>>>> armv7 stubs that use these registers in the irqchip instead of plain
>>>>>>>>>>>>> addresses in system memory.
>>>>>>>>>>>>
>>>>>>>>>>>> Let's put ARMv7 aside for the time being. If your firmware already
>>>>>>>>>>>> implements spin-tables, why don't you simply use that at least on arm64?
>>>>>>>>>>>
>>>>>>>>>>> We do.
>>>>>>>>>>
>>>>>>>>>> Obviously not the way it is intended if you have to duplicate the core
>>>>>>>>>> architectural code in the interrupt controller driver, which couldn't
>>>>>>>>>> care less.
>>>>>>>>>
>>>>>>>>> If we were using this method on arm64 then the other cores would not start up
>>>>>>>>> because armstub8.S has always included a wfe. Nothing in the commit mentions
>>>>>>>>> arm64 - this is an ARCH=arm fix.
>>>>>>>>
>>>>>>>> Thanks for the clarification, which you could have added to the commit
>>>>>>>> message.
>>>>>>>>
>>>>>>>> The question still remains: why do we have CPU bring-up code in an
>>>>>>>> interrupt controller, instead of having it in the architecture code?
>>>>>>>>
>>>>>>>> The RPi-2 is the *only* platform to have its SMP bringup code outside of
>>>>>>>> arch/arm, so the first course of action would be to move that code where
>>>>>>>> it belongs.
>>>>>>>
>>>>>>> You were CC'd on the commit (41f4988cc287e5f836d3f6620c9f900bc9b560e9) that
>>>>>>> introduced bcm2836_smp_boot_secondary - it seems strange to start objecting
>>>>>>> now.
>>>>>>
>>>>>> Well, I'm far from being perfect. If I had noticed it, I'd have NACKed
>>>>>> it.
>>>>>>
>>>>>>> Yes, I think it is odd that it didn't go into arch/arm/mach-bcm, but in
>>>>>>> the interests of making changes in small, independent steps, do you have a
>>>>>>> problem with this commit?
>>>>>>
>>>>>> On its own, no. I'm just not keen on adding more unrelated stuff to this
>>>>>> file, so let's start with dealing with the original bug, and you can
>>>>>> then add this fix on top.
>>>>>
>>>>> That's an interesting use of the word "bug". From Wikipedia:
>>>>>
>>>>> "A software bug is an error, flaw, failure or fault in a computer program or
>>>>> system that causes it to produce an incorrect or unexpected result, or to
>>>>> behave in unintended ways."
>>>>
>>>> Whatever. Should I call it "pile of crap dumped in unsuitable locations"
>>>> instead? What does Wikipedia says about it?
>>>>
>>>>> Although your concerns are valid, the faults you are objecting to are not causing
>>>>> a malfunction of any kind. If we were to update the RPi firmware before this
>>>>> patch was merged then upstream users would be left with one wheel on their wagon.
>>>>
>>>> And that'd be your problem, not mine. Look, you can argue around this
>>>> all day, or you can fix this mess. Your choice.
>>>
>>> Is that the opinion of all here?
>>
>> The choice of word here got largely out of the original topic and I
>> surely did eat a ton of popcorn here. There are two things that need
> 
> Always happy to entertain.
> 
>> fixing, and the time line and process for fixing these is clear:
>>
>> - your bugfix (Phil) is something that should be applied now, and
>> backported to -stable trees once the fix hits the irqchip tree (or Linus')
> 
> Why? As far as I can tell, none of the current platforms are affected,
> since the corresponding firmware hasn't been distributed. So by the
> letter of this, this patch is 4.13 material too.

I presume that people updating their RPI firmware and using an older
kernel can run into the scenario that Phil has described (secondary
cores spinning forever), that IMHO is worth fixing on its own.

> 
>> - relocating the code that does the secondary boot out of
>> drivers/irqchip/ into arch/arm/mach-bcm/ needs to happen (Marc), and
>> this is 4.13 material, there is no urgency in doing this *right now*,
>> but it needs to happen
>>
>> Does that work for everyone?
> 
> I'm strongly opposed to it. Moving code over to arch/arm/ has zero risk,
> and removes crap from the existing code. Hell, make the whole thing one
> patch if that makes it easier for you to backport. But piling more crap
> there? No, thank you.

It sounds unlikely that we can get the ARM SOC maintainers to accept a
change that late for 4.12 anyway, since it's not fixing anything but
your aversion for where the code currently is, which most people here
probably share as well (myself included), just with a different priority.

Anyway, I am just the guy taking Eric's pull requests on their way to
the ARM SOC maintainers, so I will let him decide what to do.
-- 
Florian


From marc.zyngier at arm.com  Wed May 10 11:23:01 2017
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 May 2017 19:23:01 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <87shkc1tff.fsf@eliezer.anholt.net> (Eric Anholt's message of
 "Wed, 10 May 2017 11:02:44 -0700")
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
 <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
 <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>
 <187815f0-1316-ee87-883d-11304064f8f9@raspberrypi.org>
 <06fad93c-a850-a99a-ae60-7306f9179032@arm.com>
 <f1394925-0651-0390-b646-1c489bfe6b4d@raspberrypi.org>
 <87tw4thyzu.fsf@on-the-bus.cambridge.arm.com>
 <a614119f-45a6-1fda-a261-e7e1a390b823@raspberrypi.org>
 <907820fc-c100-dad4-cf4f-95aa330667c5@arm.com>
 <1bbd3527-3328-b9c0-e9e0-d37092850a91@raspberrypi.org>
 <817a2689-15df-f2e4-3b3d-e5831fba7fa3@gmail.com>
 <87shkc1tff.fsf@eliezer.anholt.net>
Message-ID: <87o9v0inay.fsf@on-the-bus.cambridge.arm.com>

On Wed, May 10 2017 at  7:02:44 pm BST, Eric Anholt <eric at anholt.net> wrote:
> Florian Fainelli <f.fainelli at gmail.com> writes:
>
>> On 05/10/2017 03:31 AM, Phil Elwell wrote:
>>> On 10/05/2017 11:09, Marc Zyngier wrote:
>>>> On 10/05/17 10:05, Phil Elwell wrote:
>>>>> On 10/05/2017 09:55, Marc Zyngier wrote:
>>>>>> On Wed, May 10 2017 at 9:27:10 am BST, Phil Elwell
>>>>>> <phil at raspberrypi.org> wrote:
>>>>>>> On 10/05/2017 08:42, Marc Zyngier wrote:
>>>>>>>> On 09/05/17 20:02, Phil Elwell wrote:
>>>>>>>>> On 09/05/2017 19:53, Marc Zyngier wrote:
>>>>>>>>>> On 09/05/17 19:52, Phil Elwell wrote:
>>>>>>>>>>> On 09/05/2017 19:14, Marc Zyngier wrote:
>>>>>>>>>>>> On 09/05/17 19:08, Eric Anholt wrote:
>>>>>>>>>>>>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>>>>>>>>>>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>>>>>>>>>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>>>>>>>>>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>>>>>>>>>>>>> or interrupt arrives before continuing to the next instruction.
>>>>>>>>>>>>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>>>>>>>>>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>>>>>>>>>>>>> waiting cores during booting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is harmless to use this patch without the corresponding change
>>>>>>>>>>>>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>>>>>>>>>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>>>>>>>>>>>>  1 file changed, 3 insertions(+)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>>>> index e10597c..6dccdf9 100644
>>>>>>>>>>>>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>>>>>>>>>>>>  	writel(secondary_startup_phys,
>>>>>>>>>>>>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>>>>>>>>>>>>> +	sev();
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>  	return 0;
>>>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is also the behavior that the standard arm64 spin-table
>>>>>>>>>>>>>>> method has,
>>>>>>>>>>>>>>> which we unfortunately can't quite use.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And why is that so? Why do you have to reinvent the
>>>>>>>>>>>>>> wheel (and hide the
>>>>>>>>>>>>>> cloned wheel in an interrupt controller driver)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That doesn't seem right to me.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The armv8 stubs (firmware-supplied code in the low page that do the
>>>>>>>>>>>>> spinning) do actually implement arm64's spin-table
>>>>>>>>>>>>> method.  It's the
>>>>>>>>>>>>> armv7 stubs that use these registers in the irqchip
>>>>>>>>>>>>> instead of plain
>>>>>>>>>>>>> addresses in system memory.
>>>>>>>>>>>>
>>>>>>>>>>>> Let's put ARMv7 aside for the time being. If your firmware already
>>>>>>>>>>>> implements spin-tables, why don't you simply use that at
>>>>>>>>>>>> least on arm64?
>>>>>>>>>>>
>>>>>>>>>>> We do.
>>>>>>>>>>
>>>>>>>>>> Obviously not the way it is intended if you have to duplicate the core
>>>>>>>>>> architectural code in the interrupt controller driver, which couldn't
>>>>>>>>>> care less.
>>>>>>>>>
>>>>>>>>> If we were using this method on arm64 then the other cores
>>>>>>>>> would not start up
>>>>>>>>> because armstub8.S has always included a wfe. Nothing in the
>>>>>>>>> commit mentions
>>>>>>>>> arm64 - this is an ARCH=arm fix.
>>>>>>>>
>>>>>>>> Thanks for the clarification, which you could have added to the commit
>>>>>>>> message.
>>>>>>>>
>>>>>>>> The question still remains: why do we have CPU bring-up code in an
>>>>>>>> interrupt controller, instead of having it in the architecture code?
>>>>>>>>
>>>>>>>> The RPi-2 is the *only* platform to have its SMP bringup code outside of
>>>>>>>> arch/arm, so the first course of action would be to move that code where
>>>>>>>> it belongs.
>>>>>>>
>>>>>>> You were CC'd on the commit
>>>>>>> (41f4988cc287e5f836d3f6620c9f900bc9b560e9) that
>>>>>>> introduced bcm2836_smp_boot_secondary - it seems strange to
>>>>>>> start objecting
>>>>>>> now.
>>>>>>
>>>>>> Well, I'm far from being perfect. If I had noticed it, I'd have NACKed
>>>>>> it.
>>>>>>
>>>>>>> Yes, I think it is odd that it didn't go into arch/arm/mach-bcm, but in
>>>>>>> the interests of making changes in small, independent steps, do
>>>>>>> you have a
>>>>>>> problem with this commit?
>>>>>>
>>>>>> On its own, no. I'm just not keen on adding more unrelated stuff to this
>>>>>> file, so let's start with dealing with the original bug, and you can
>>>>>> then add this fix on top.
>>>>>
>>>>> That's an interesting use of the word "bug". From Wikipedia:
>>>>>
>>>>> "A software bug is an error, flaw, failure or fault in a computer
>>>>> program or
>>>>> system that causes it to produce an incorrect or unexpected result, or to
>>>>> behave in unintended ways."
>>>>
>>>> Whatever. Should I call it "pile of crap dumped in unsuitable locations"
>>>> instead? What does Wikipedia says about it?
>>>>
>>>>> Although your concerns are valid, the faults you are objecting to
>>>>> are not causing
>>>>> a malfunction of any kind. If we were to update the RPi firmware
>>>>> before this
>>>>> patch was merged then upstream users would be left with one wheel
>>>>> on their wagon.
>>>>
>>>> And that'd be your problem, not mine. Look, you can argue around this
>>>> all day, or you can fix this mess. Your choice.
>>> 
>>> Is that the opinion of all here?
>>
>> The choice of word here got largely out of the original topic and I
>> surely did eat a ton of popcorn here. There are two things that need
>> fixing, and the time line and process for fixing these is clear:
>>
>> - your bugfix (Phil) is something that should be applied now, and
>> backported to -stable trees once the fix hits the irqchip tree (or Linus')
>>
>> - relocating the code that does the secondary boot out of
>> drivers/irqchip/ into arch/arm/mach-bcm/ needs to happen (Marc), and
>> this is 4.13 material, there is no urgency in doing this *right now*,
>> but it needs to happen
>>
>> Does that work for everyone?
>
> Agreed.  This patch, which we'll want to go to -stable, should clearly
> go in first.  Marc's patch can go in after, since it's not a -stable
> candidate.
>
> Thomas, could you add the cc to stable when picking this patch?

So, for the record, I'm clearly NAKing this patch. Thomas or Jason can
pick it if they want to, I definitely won't.

	M.
-- 
Jazz is not dead, it just smell funny.


From stefan.wahren at i2se.com  Sat May 13 05:28:01 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 13 May 2017 14:28:01 +0200 (CEST)
Subject: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
In-Reply-To: <CAD=FV=VUaqtR2t04wodRJ33bqHo5DPke7zsvqBMYqZ5imX5+=A@mail.gmail.com>
References: <172093673.40121.1492427140661@email.1und1.de>
 <CAD=FV=WJBTUcMPw8OgQT_jhz0H8AsH=YqWMR7LtudUKrF5-XOA@mail.gmail.com>
 <79b9b35b-0600-771f-4cd2-9e03c5ba3a25@i2se.com>
 <186569458.91967.1492547106553@email.1und1.de>
 <CAD=FV=VHkJFrsJDmMytbUw=WjKQaGZ-8Ewfy5bPCA82AWS4O2Q@mail.gmail.com>
 <212870399.174480.1492633502649@email.1und1.de>
 <87mvbaykn1.fsf@eliezer.anholt.net>
 <1998517910.54108.1492894253010@email.1und1.de>
 <2127594073.298820.1493143869792@email.1und1.de>
 <316369012.317772.1494274928708@email.1und1.de>
 <20170510163150.GK30445@localhost>
 <CAD=FV=VUaqtR2t04wodRJ33bqHo5DPke7zsvqBMYqZ5imX5+=A@mail.gmail.com>
Message-ID: <446301756.220218.1494678481761@email.1und1.de>

> Doug Anderson <dianders at chromium.org> hat am 11. Mai 2017 um 01:50 geschrieben:
> 
> 
> Hi,
> 
> On Wed, May 10, 2017 at 9:31 AM, Johan Hovold <johan at kernel.org> wrote:
> > On Mon, May 08, 2017 at 10:22:08PM +0200, Stefan Wahren wrote:
> >> @Doug, @John Y., @Johan: Any further ideas to narrow down the reason
> >> for this interrupt storm?
> >
> > No, sorry.
> >
> > I suggested earlier that you could try commenting out the interrupt-URB
> > submission in a naive attempt to narrow it down since that is an obvious
> > difference from the ftdi driver, but then again so are the frequent ftdi
> > status bulk messages (and any other timing differences).
> >
> > Seems like you need to dig into dwc2.
> 
> I haven't had a chance to dig and not sure when I'll have that time.
> I'll keep this around in my inbox for now on the off chance that I
> clean it out enough to get back to this.  Sorry!
> 

But thanks for all your feedback guys.

Btw i think i took a step forward. During the whole time i a took a Raspberry Pi B to reproduce this issue, which has a builtin USB hub and a SMSC USB to ethernet chip.

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
        |__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M

I decide to switch to the Raspberry Pi Zero which neither have a builtin USB hub or a USB ethernet chip. If i connect the PL2303 directly to the RPi Zero the issue is not reproducible and usb_test behave as expected by opening the port and terminate after a few seconds (good case).

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
    |__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M

After that i placed a USB 4 port hub between RPi Zero and PL2303. Now the issue (interrupt storm) occurs on the RPi Zero (bad case). After nearly 20 seconds i disconnected the PL2303 in order to make the system usable and stop the trace.

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 3: Dev 4, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M

Additional i made usbmon traces of both cases. Maybe that's useful for somebody with more USB knowledge than me.

Stefan

good case:

d9adfd00 1324940464 S Co:1:005:0 s 40 01 0008 0000 0000 0
d9adfd00 1324941739 C Co:1:005:0 0 0
d9adfd00 1324941792 S Co:1:005:0 s 40 01 0009 0000 0000 0
d9adfd00 1324941879 C Co:1:005:0 0 0
d9adfd00 1324941920 S Ci:1:005:0 s a1 21 0000 0000 0007 7 <
d9adfd00 1324942046 C Ci:1:005:0 0 7 = 80250000 000000
d9adfd00 1324942093 S Co:1:005:0 s 21 20 0000 0000 0007 7 = 80250000 000008
d9adfd00 1324942211 C Co:1:005:0 0 7 >
d9adfd00 1324942248 S Co:1:005:0 s 40 01 0000 0000 0000 0
d9adfd00 1324942335 C Co:1:005:0 0 0
da6ef600 1324942367 S Ii:1:005:1 -115:1 10 <
da6efd00 1324942412 S Bi:1:005:3 -115 256 <
da6ef800 1324942431 S Bi:1:005:3 -115 256 <
d9adfd00 1324942447 S Co:1:005:0 s 21 22 0003 0000 0000 0
d9adfd00 1324943310 C Co:1:005:0 0 0
da6ef600 1324944174 C Ii:1:005:1 0:1 10 = a1200000 00000200 8b06
da6ef600 1324944192 S Ii:1:005:1 -115:1 10 <
da6ef600 1324946152 C Ii:1:005:1 0:1 10 = a1200000 00000200 8b00
da6ef600 1324946161 S Ii:1:005:1 -115:1 10 <
da6ef600 1325451149 C Ii:1:005:1 -5:1 0
da6ef600 1325451177 S Ii:1:005:1 -115:1 10 <
d9adf400 1330210089 S Co:1:005:0 s 21 22 0000 0000 0000 0
d9adf400 1330211717 C Co:1:005:0 0 0
da6efd00 1330211855 C Bi:1:005:3 -2 0
da6ef800 1330211921 C Bi:1:005:3 -2 0
da6ef600 1330211969 C Ii:1:005:1 -2:1 0
d9adf400 1330211997 S Co:1:005:0 s 21 23 0000 0000 0000 0
d9adf400 1330212158 C Co:1:005:0 0 0

bad case:

da6efb00 316377734 S Co:1:004:0 s 40 01 0008 0000 0000 0
da6efb00 316378587 C Co:1:004:0 0 0
da6efb00 316378837 S Co:1:004:0 s 40 01 0009 0000 0000 0
da6efb00 316379201 C Co:1:004:0 0 0
da6efb00 316379397 S Ci:1:004:0 s a1 21 0000 0000 0007 7 <
da6efb00 316379697 C Ci:1:004:0 0 7 = 80250000 000000
da6efb00 316379890 S Co:1:004:0 s 21 20 0000 0000 0007 7 = 80250000 000008
da6efb00 316380350 C Co:1:004:0 0 7 >
da6efb00 316380580 S Co:1:004:0 s 40 01 0000 0000 0000 0
da6efb00 316380932 C Co:1:004:0 0 0
d9a14b00 316381132 S Ii:1:004:1 -115:1 10 <
da780600 316381325 S Bi:1:004:3 -115 256 <
da780100 316381488 S Bi:1:004:3 -115 256 <
d9a14b00 316389933 C Ii:1:004:1 0:1 10 = a1200000 00000200 8b06
d9a14b00 316390820 S Ii:1:004:1 -115:1 10 <
d9a14b00 316398308 C Ii:1:004:1 0:1 10 = a1200000 00000200 8b00
d9a14b00 316399936 S Ii:1:004:1 -115:1 10 <
da6efb00 316419808 S Co:1:004:0 s 21 22 0003 0000 0000 0
da6efb00 316438433 C Co:1:004:0 0 0
da780600 339316684 C Bi:1:004:3 -32 0
da780100 339316772 C Bi:1:004:3 -32 0
d9a14b00 339317035 C Ii:1:004:1 -32:1 0
d9a14b00 339317049 S Ii:1:004:1 -115:1 10 <
d9a14b00 339318040 C Ii:1:004:1 -32:1 0
d9a14b00 339318057 S Ii:1:004:1 -115:1 10 <
d9a14b00 339319042 C Ii:1:004:1 -32:1 0
d9a14b00 339319056 S Ii:1:004:1 -115:1 10 <
d9a14b00 339329551 C Ii:1:004:1 -32:1 0
d9a14b00 339329571 S Ii:1:004:1 -115:1 10 <
d9a14b00 339330586 C Ii:1:004:1 -32:1 0
d9a14b00 339330601 S Ii:1:004:1 -115:1 10 <
d9a14b00 339331035 C Ii:1:004:1 -32:1 0
d9a14b00 339331046 S Ii:1:004:1 -115:1 10 <
d9a14b00 339332037 C Ii:1:004:1 -32:1 0
d9a14b00 339332049 S Ii:1:004:1 -115:1 10 <
d9a14b00 339333054 C Ii:1:004:1 -32:1 0
d9a14b00 339333068 S Ii:1:004:1 -115:1 10 <
d9a14b00 339334037 C Ii:1:004:1 -32:1 0
d9a14b00 339334050 S Ii:1:004:1 -115:1 10 <
d9a14b00 339335036 C Ii:1:004:1 -32:1 0
d9a14b00 339335050 S Ii:1:004:1 -115:1 10 <
d9a14b00 339336036 C Ii:1:004:1 -32:1 0
d9a14b00 339336049 S Ii:1:004:1 -115:1 10 <
d9a14b00 339337037 C Ii:1:004:1 -32:1 0
d9a14b00 339337050 S Ii:1:004:1 -115:1 10 <
d9a14b00 339338039 C Ii:1:004:1 -32:1 0
d9a14b00 339338074 S Ii:1:004:1 -115:1 10 <
d9a14b00 339339038 C Ii:1:004:1 -32:1 0
d9a14b00 339339052 S Ii:1:004:1 -115:1 10 <
d9a14b00 339340130 C Ii:1:004:1 -32:1 0
d9a14b00 339340143 S Ii:1:004:1 -115:1 10 <
d9a14b00 339341035 C Ii:1:004:1 -32:1 0
d9a14b00 339341048 S Ii:1:004:1 -115:1 10 <
d9a14b00 339342039 C Ii:1:004:1 -32:1 0
d9a14b00 339342051 S Ii:1:004:1 -115:1 10 <
d9a14b00 339343038 C Ii:1:004:1 -32:1 0
d9a14b00 339343051 S Ii:1:004:1 -115:1 10 <
d9a14b00 339344038 C Ii:1:004:1 -32:1 0
d9a14b00 339344050 S Ii:1:004:1 -115:1 10 <
d9a14b00 339345037 C Ii:1:004:1 -32:1 0
d9a14b00 339345050 S Ii:1:004:1 -115:1 10 <
d9a14b00 339346038 C Ii:1:004:1 -32:1 0
d9a14b00 339346049 S Ii:1:004:1 -115:1 10 <
d9a14b00 339347030 C Ii:1:004:1 -32:1 0
d9a14b00 339347041 S Ii:1:004:1 -115:1 10 <
d9a14b00 339348039 C Ii:1:004:1 -32:1 0
d9a14b00 339348052 S Ii:1:004:1 -115:1 10 <
d9a14b00 339349039 C Ii:1:004:1 -32:1 0
d9a14b00 339349053 S Ii:1:004:1 -115:1 10 <
d9a14b00 339350105 C Ii:1:004:1 -32:1 0
d9a14b00 339350119 S Ii:1:004:1 -115:1 10 <
d9a14b00 339351032 C Ii:1:004:1 -32:1 0
d9a14b00 339351044 S Ii:1:004:1 -115:1 10 <
d9a14b00 339352030 C Ii:1:004:1 -32:1 0
d9a14b00 339352042 S Ii:1:004:1 -115:1 10 <
d9a14b00 339353037 C Ii:1:004:1 -32:1 0
d9a14b00 339353051 S Ii:1:004:1 -115:1 10 <
d9a14b00 339354068 C Ii:1:004:1 -32:1 0
d9a14b00 339354083 S Ii:1:004:1 -115:1 10 <
d9a14b00 339355018 C Ii:1:004:1 -32:1 0
d9a14b00 339355026 S Ii:1:004:1 -115:1 10 <
d9a14b00 339356017 C Ii:1:004:1 -32:1 0
d9a14b00 339356025 S Ii:1:004:1 -115:1 10 <
d9a14b00 339357018 C Ii:1:004:1 -32:1 0
d9a14b00 339357026 S Ii:1:004:1 -115:1 10 <
d9a14b00 339358017 C Ii:1:004:1 -32:1 0
d9a14b00 339358025 S Ii:1:004:1 -115:1 10 <
d9a14b00 339359018 C Ii:1:004:1 -32:1 0
d9a14b00 339359026 S Ii:1:004:1 -115:1 10 <
d9a14b00 339360016 C Ii:1:004:1 -32:1 0
d9a14b00 339360024 S Ii:1:004:1 -115:1 10 <
d9a14b00 339361018 C Ii:1:004:1 -32:1 0
d9a14b00 339361026 S Ii:1:004:1 -115:1 10 <
d9a14b00 339362016 C Ii:1:004:1 -32:1 0
d9a14b00 339362024 S Ii:1:004:1 -115:1 10 <
d9a14b00 339363017 C Ii:1:004:1 -32:1 0
d9a14b00 339363049 S Ii:1:004:1 -115:1 10 <
d9a14b00 339364017 C Ii:1:004:1 -32:1 0
d9a14b00 339364025 S Ii:1:004:1 -115:1 10 <
d9a14b00 339365017 C Ii:1:004:1 -32:1 0
d9a14b00 339365025 S Ii:1:004:1 -115:1 10 <
d9a14b00 339366016 C Ii:1:004:1 -32:1 0
d9a14b00 339366024 S Ii:1:004:1 -115:1 10 <
d9a14b00 339367017 C Ii:1:004:1 -32:1 0
d9a14b00 339367025 S Ii:1:004:1 -115:1 10 <
d9a14b00 339368017 C Ii:1:004:1 -32:1 0
d9a14b00 339368024 S Ii:1:004:1 -115:1 10 <
d9a14b00 339369017 C Ii:1:004:1 -32:1 0
d9a14b00 339369025 S Ii:1:004:1 -115:1 10 <
d9a14b00 339370017 C Ii:1:004:1 -32:1 0
d9a14b00 339370024 S Ii:1:004:1 -115:1 10 <
d9a14b00 339371017 C Ii:1:004:1 -32:1 0
d9a14b00 339371026 S Ii:1:004:1 -115:1 10 <
d9a14b00 339372017 C Ii:1:004:1 -32:1 0
d9a14b00 339372024 S Ii:1:004:1 -115:1 10 <
d9a14b00 339373017 C Ii:1:004:1 -32:1 0
d9a14b00 339373025 S Ii:1:004:1 -115:1 10 <
d9a14b00 339374018 C Ii:1:004:1 -32:1 0
d9a14b00 339374025 S Ii:1:004:1 -115:1 10 <
d9a14b00 339375017 C Ii:1:004:1 -32:1 0
d9a14b00 339375025 S Ii:1:004:1 -115:1 10 <
d9a14b00 339376018 C Ii:1:004:1 -32:1 0
d9a14b00 339376026 S Ii:1:004:1 -115:1 10 <
d9a14b00 339377017 C Ii:1:004:1 -32:1 0
d9a14b00 339377024 S Ii:1:004:1 -115:1 10 <
d9930180 339605934 S Ci:1:002:0 s a3 00 0000 0003 0004 4 <
d9930180 339606101 C Ci:1:002:0 0 4 = 00010000
d9930380 339650171 S Ci:1:002:0 s a3 00 0000 0003 0004 4 <
d9930380 339650346 C Ci:1:002:0 0 4 = 00010000
d9842c80 339700165 S Ci:1:002:0 s a3 00 0000 0003 0004 4 <
d9842c80 339700346 C Ci:1:002:0 0 4 = 00010000
da780000 339751063 S Ci:1:002:0 s a3 00 0000 0003 0004 4 <
da780000 339751221 C Ci:1:002:0 0 4 = 00010000
d9a15380 339800833 S Ci:1:002:0 s a3 00 0000 0003 0004 4 <
d9a15380 339800974 C Ci:1:002:0 0 4 = 00010000
da737080 339801535 C Ii:1:002:1 -2:2048 0
d9a15380 339802157 S Co:1:002:0 s 00 03 0001 0000 0000 0
d9a15380 339802265 C Co:1:002:0 0 0
d9a15380 339802291 S Co:1:001:0 s 23 03 0002 0001 0000 0
d9a15380 339802352 C Co:1:001:0 0 0
da6ba280 339830247 C Ii:1:001:1 -2:2048 0


From eric at anholt.net  Tue May  9 11:08:56 2017
From: eric at anholt.net (Eric Anholt)
Date: Tue, 09 May 2017 11:08:56 -0700
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
Message-ID: <87o9v1c37r.fsf@eliezer.anholt.net>

Marc Zyngier <marc.zyngier at arm.com> writes:

> On 09/05/17 17:59, Eric Anholt wrote:
>> Phil Elwell <phil at raspberrypi.org> writes:
>> 
>>> In order to reduce power consumption and bus traffic, it is sensible
>>> for secondary cores to enter a low-power idle state when waiting to
>>> be started. The wfe instruction causes a core to wait until an event
>>> or interrupt arrives before continuing to the next instruction.
>>> The sev instruction sends a wakeup event to the other cores, so call
>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>> waiting cores during booting.
>>>
>>> It is harmless to use this patch without the corresponding change
>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>> and this patch is not applied then the other cores will sleep forever.
>>>
>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>
>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>> ---
>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>> index e10597c..6dccdf9 100644
>>> --- a/drivers/irqchip/irq-bcm2836.c
>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>  	writel(secondary_startup_phys,
>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>  
>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>> +	sev();
>>> +
>>>  	return 0;
>>>  }
>> 
>> This is also the behavior that the standard arm64 spin-table method has,
>> which we unfortunately can't quite use.
>
> And why is that so? Why do you have to reinvent the wheel (and hide the
> cloned wheel in an interrupt controller driver)?
>
> That doesn't seem right to me.

The armv8 stubs (firmware-supplied code in the low page that do the
spinning) do actually implement arm64's spin-table method.  It's the
armv7 stubs that use these registers in the irqchip instead of plain
addresses in system memory.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170509/91aac3a1/attachment.sig>

From eric at anholt.net  Tue May  9 11:10:57 2017
From: eric at anholt.net (Eric Anholt)
Date: Tue, 09 May 2017 11:10:57 -0700
Subject: [PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware
In-Reply-To: <bdc05058-f65b-da08-0cf5-51aa1f97852e@gmail.com>
References: <b6aef857-1454-7931-2c60-6d7b55b7a0a8@raspberrypi.org>
 <8737cenfhc.fsf@eliezer.anholt.net>
 <bdc05058-f65b-da08-0cf5-51aa1f97852e@gmail.com>
Message-ID: <87lgq5c34e.fsf@eliezer.anholt.net>

Florian Fainelli <f.fainelli at gmail.com> writes:

> On 05/09/2017 09:48 AM, Eric Anholt wrote:
>> Phil Elwell <phil at raspberrypi.org> writes:
>> 
>>> The Raspberry Pi startup stub files for multi-core BCM27XX processors
>>> make the secondary CPUs spin until the corresponding mailbox is
>>> written. These stubs are loaded at physical address 0x00000xxx (as seen
>>> by the ARMs), but this page will be reused by the kernel unless it is
>>> explicitly reserved, causing the waiting cores to execute random code.
>>>
>>> Use the /memreserve/ Device Tree directive to mark the first page as
>>> off-limits to the kernel.
>>>
>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>
>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>> 
>> This looks great.  We're currently in the merge window, so I can't
>> generate a new bcm2835-dt-next yet, but I'll pick this patch up when I
>> do.
>> 
>> Thanks for submitting upstream!
>
> Considering that this is a fix, we could actually squeeze it in the
> devicetree/fixes branch and we could submit those as soon as v4.12-rc1
> is tagged, your call.

While the issue is a bit obscure, I know I've hit it as well.  I agree
that it's a good stable candidate, so unless you'd like to pick it
yourself and cc stable, I'll just send you a PR doing so when rc1 rolls
around.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170509/b0b48682/attachment.sig>

From phil at raspberrypi.org  Wed May 10 03:31:46 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Wed, 10 May 2017 11:31:46 +0100
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <907820fc-c100-dad4-cf4f-95aa330667c5@arm.com>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
 <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
 <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>
 <187815f0-1316-ee87-883d-11304064f8f9@raspberrypi.org>
 <06fad93c-a850-a99a-ae60-7306f9179032@arm.com>
 <f1394925-0651-0390-b646-1c489bfe6b4d@raspberrypi.org>
 <87tw4thyzu.fsf@on-the-bus.cambridge.arm.com>
 <a614119f-45a6-1fda-a261-e7e1a390b823@raspberrypi.org>
 <907820fc-c100-dad4-cf4f-95aa330667c5@arm.com>
Message-ID: <1bbd3527-3328-b9c0-e9e0-d37092850a91@raspberrypi.org>

On 10/05/2017 11:09, Marc Zyngier wrote:
> On 10/05/17 10:05, Phil Elwell wrote:
>> On 10/05/2017 09:55, Marc Zyngier wrote:
>>> On Wed, May 10 2017 at  9:27:10 am BST, Phil Elwell <phil at raspberrypi.org> wrote:
>>>> On 10/05/2017 08:42, Marc Zyngier wrote:
>>>>> On 09/05/17 20:02, Phil Elwell wrote:
>>>>>> On 09/05/2017 19:53, Marc Zyngier wrote:
>>>>>>> On 09/05/17 19:52, Phil Elwell wrote:
>>>>>>>> On 09/05/2017 19:14, Marc Zyngier wrote:
>>>>>>>>> On 09/05/17 19:08, Eric Anholt wrote:
>>>>>>>>>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>>>>>>>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>>>>>>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>>>>>>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>>>>>>>>>> or interrupt arrives before continuing to the next instruction.
>>>>>>>>>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>>>>>>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>>>>>>>>>> waiting cores during booting.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is harmless to use this patch without the corresponding change
>>>>>>>>>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>>>>>>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>>>>>>>>>
>>>>>>>>>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>>>>>>>>>  1 file changed, 3 insertions(+)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>> index e10597c..6dccdf9 100644
>>>>>>>>>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>>>>>>>>>  	writel(secondary_startup_phys,
>>>>>>>>>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>>>>>>>>>
>>>>>>>>>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>>>>>>>>>> +	sev();
>>>>>>>>>>>>> +
>>>>>>>>>>>>>  	return 0;
>>>>>>>>>>>>>  }
>>>>>>>>>>>>
>>>>>>>>>>>> This is also the behavior that the standard arm64 spin-table
>>>>>>>>>>>> method has,
>>>>>>>>>>>> which we unfortunately can't quite use.
>>>>>>>>>>>
>>>>>>>>>>> And why is that so? Why do you have to reinvent the wheel (and hide the
>>>>>>>>>>> cloned wheel in an interrupt controller driver)?
>>>>>>>>>>>
>>>>>>>>>>> That doesn't seem right to me.
>>>>>>>>>>
>>>>>>>>>> The armv8 stubs (firmware-supplied code in the low page that do the
>>>>>>>>>> spinning) do actually implement arm64's spin-table method.  It's the
>>>>>>>>>> armv7 stubs that use these registers in the irqchip instead of plain
>>>>>>>>>> addresses in system memory.
>>>>>>>>>
>>>>>>>>> Let's put ARMv7 aside for the time being. If your firmware already
>>>>>>>>> implements spin-tables, why don't you simply use that at least on arm64?
>>>>>>>>
>>>>>>>> We do.
>>>>>>>
>>>>>>> Obviously not the way it is intended if you have to duplicate the core
>>>>>>> architectural code in the interrupt controller driver, which couldn't
>>>>>>> care less.
>>>>>>
>>>>>> If we were using this method on arm64 then the other cores would not start up
>>>>>> because armstub8.S has always included a wfe. Nothing in the commit mentions
>>>>>> arm64 - this is an ARCH=arm fix.
>>>>>
>>>>> Thanks for the clarification, which you could have added to the commit
>>>>> message.
>>>>>
>>>>> The question still remains: why do we have CPU bring-up code in an
>>>>> interrupt controller, instead of having it in the architecture code?
>>>>>
>>>>> The RPi-2 is the *only* platform to have its SMP bringup code outside of
>>>>> arch/arm, so the first course of action would be to move that code where
>>>>> it belongs.
>>>>
>>>> You were CC'd on the commit (41f4988cc287e5f836d3f6620c9f900bc9b560e9) that
>>>> introduced bcm2836_smp_boot_secondary - it seems strange to start objecting
>>>> now.
>>>
>>> Well, I'm far from being perfect. If I had noticed it, I'd have NACKed
>>> it.
>>>
>>>> Yes, I think it is odd that it didn't go into arch/arm/mach-bcm, but in
>>>> the interests of making changes in small, independent steps, do you have a
>>>> problem with this commit?
>>>
>>> On its own, no. I'm just not keen on adding more unrelated stuff to this
>>> file, so let's start with dealing with the original bug, and you can
>>> then add this fix on top.
>>
>> That's an interesting use of the word "bug". From Wikipedia:
>>
>> "A software bug is an error, flaw, failure or fault in a computer program or
>> system that causes it to produce an incorrect or unexpected result, or to
>> behave in unintended ways."
> 
> Whatever. Should I call it "pile of crap dumped in unsuitable locations"
> instead? What does Wikipedia says about it?
> 
>> Although your concerns are valid, the faults you are objecting to are not causing
>> a malfunction of any kind. If we were to update the RPi firmware before this
>> patch was merged then upstream users would be left with one wheel on their wagon.
> 
> And that'd be your problem, not mine. Look, you can argue around this
> all day, or you can fix this mess. Your choice.

Is that the opinion of all here?

Phil


From johan at kernel.org  Wed May 10 09:31:50 2017
From: johan at kernel.org (Johan Hovold)
Date: Wed, 10 May 2017 18:31:50 +0200
Subject: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
In-Reply-To: <316369012.317772.1494274928708@email.1und1.de>
References: <172093673.40121.1492427140661@email.1und1.de>
 <CAD=FV=WJBTUcMPw8OgQT_jhz0H8AsH=YqWMR7LtudUKrF5-XOA@mail.gmail.com>
 <79b9b35b-0600-771f-4cd2-9e03c5ba3a25@i2se.com>
 <186569458.91967.1492547106553@email.1und1.de>
 <CAD=FV=VHkJFrsJDmMytbUw=WjKQaGZ-8Ewfy5bPCA82AWS4O2Q@mail.gmail.com>
 <212870399.174480.1492633502649@email.1und1.de>
 <87mvbaykn1.fsf@eliezer.anholt.net>
 <1998517910.54108.1492894253010@email.1und1.de>
 <2127594073.298820.1493143869792@email.1und1.de>
 <316369012.317772.1494274928708@email.1und1.de>
Message-ID: <20170510163150.GK30445@localhost>

On Mon, May 08, 2017 at 10:22:08PM +0200, Stefan Wahren wrote:
> 
> > Stefan Wahren <stefan.wahren at i2se.com> hat am 25. April 2017 um 20:11 geschrieben:
> > 
> > 
> > > Stefan Wahren <stefan.wahren at i2se.com> hat am 22. April 2017 um 22:50 geschrieben:
> > > 
> > > 
> > > Hi,
> > > 
> > > > Eric Anholt <eric at anholt.net> hat am 20. April 2017 um 20:54 geschrieben:
> > > > 
> > > > 
> > > > Stefan Wahren <stefan.wahren at i2se.com> writes:
> > > > 
> > > > > Hi,
> > > > >
> > > > >> Doug Anderson <dianders at chromium.org> hat am 18. April 2017 um 22:41 geschrieben:
> > > > >> 
> > > > >> 
> > > > >> It's hard to know for sure that all of this time is really in
> > > > >> urb_enqueue().  Possible we could have task switched out and been
> > > > >> blocked elsewhere.  Using ftrace to get more fine-grained timings
> > > > >> would be useful.  ktime_get(), ktime_sub(), and ktime_to_us() are your
> > > > >> friends here if you want to use trace_printk.
> > > > >
> > > > > i'm a newbie to ftrace, so i hope this would be helpful.
> > > > >
> > > > > # connect PL2303 to the onboard hub
> > > > > # echo 0 > options/sleep-time
> > > > > # echo 0 > function_profile_enabled
> > > > > # echo 1 > function_profile_enabled
> > > > > # ./usb_test
> > > > > # Waiting for at least 20 seconds and then disconnect PL2303
> > > > > # echo 0 > function_profile_enabled
> > > > > # cat trace_stat/function0
> > > > >
> > > > >   Function                               Hit    Time            Avg             s^2
> > > > >   --------                               ---    ----            ---             ---
> > > > >   bcm2835_handle_irq                  361347    219567633 us     607.636 us      1485199 us  
> > > > >   __handle_domain_irq                1082482    212639551 us     196.437 us      3642030 us  
> > > > >   generic_handle_irq                 1082482    100592051 us     92.927 us       50511334 us 
> > > > >   irq_exit                           1082482    98197771 us     90.715 us       29649040 us 
> > > > >   handle_level_irq                   1082482    95812379 us     88.511 us       51910093 us 
> > > > 
> > > > If I'm reading this output right, we're spending half of our interrupt
> > > > processing time in irq_exit(), so even if dwc2's interrupt was free (the
> > > > generic_handle_irq() chain), we'd be eating about half the CPU getting
> > > > back out of the interrupt handler, right?
> > > > 
> > > > I don't really know anything about DWC2 or USB, but is there any way we
> > > > could mitigate the interrupt frequency with this hardware?  If nothing
> > > > else, could we loop reading gintsts until it reads back 0?
> > > 
> > > first of all i updated my kernel to 4.11rc7 and the issue still
> > > occures. Today i had some time to investigate this issue further
> > > and i made some interesting observations:
> > > 
> > > 1. The lockup doesn't occure always after starting usb_test. In
> > > rare cases i was able to run the program without lockup.
> > > 2. In case the lockup occured we are always able to "rescue" the
> > > BCM2835 from this state by sending some serial data to the PL2303.
> > 
> > Based on this scenario i patched the interrupt routine to detect the
> > interrupt storm and normal condition. So i can dump the global and
> > host registers in both situations (bad and goodcase).
> > 
> > Here is the diff between both register dumps, maybe someone see
> > something interesting:
> > 
> > --- badcase.txt	2017-04-25 18:02:59.000000000 +0000
> > +++ goodcase.txt	2017-04-25 18:02:59.000000000 +0000
> > @@ -4,12 +4,12 @@
> >   dwc2_dump_global_registers: GAHBCFG	 @0xCC850008 : 0x00000031
> >   dwc2_dump_global_registers: GUSBCFG	 @0xCC85000C : 0x20001700
> >   dwc2_dump_global_registers: GRSTCTL	 @0xCC850010 : 0x80000000
> > - dwc2_dump_global_registers: GINTSTS	 @0xCC850014 : 0x06000021
> > + dwc2_dump_global_registers: GINTSTS	 @0xCC850014 : 0x06000029
> >   dwc2_dump_global_registers: GINTMSK	 @0xCC850018 : 0xF300080E
> > - dwc2_dump_global_registers: GRXSTSR	 @0xCC85001C : 0x00070044
> > + dwc2_dump_global_registers: GRXSTSR	 @0xCC85001C : 0x000F0001
> >   dwc2_dump_global_registers: GRXFSIZ	 @0xCC850024 : 0x00000306
> >   dwc2_dump_global_registers: GNPTXFSIZ	 @0xCC850028 : 0x01000306
> > - dwc2_dump_global_registers: GNPTXSTS	 @0xCC85002C : 0x1D080100
> > + dwc2_dump_global_registers: GNPTXSTS	 @0xCC85002C : 0x18080100
> > ...
> 
> @Doug, @John Y., @Johan: Any further ideas to narrow down the reason
> for this interrupt storm?

No, sorry.

I suggested earlier that you could try commenting out the interrupt-URB
submission in a naive attempt to narrow it down since that is an obvious
difference from the ftdi driver, but then again so are the frequent ftdi
status bulk messages (and any other timing differences).

Seems like you need to dig into dwc2.

Johan


From eric at anholt.net  Wed May 10 11:02:44 2017
From: eric at anholt.net (Eric Anholt)
Date: Wed, 10 May 2017 11:02:44 -0700
Subject: [PATCH] irq_bcm2836: Send event when onlining sleeping cores
In-Reply-To: <817a2689-15df-f2e4-3b3d-e5831fba7fa3@gmail.com>
References: <ce824cd4-4ae4-d080-ed99-b8cef13f5482@raspberrypi.org>
 <87ziemm0fb.fsf@eliezer.anholt.net>
 <1e871525-3298-f16d-4f95-a44bc78068b5@arm.com>
 <87o9v1c37r.fsf@eliezer.anholt.net>
 <7f6f5e05-07b1-e64d-401c-a189623c22a0@arm.com>
 <3b9a0ec6-fc9e-5cd0-e40a-e91b5926f53e@raspberrypi.org>
 <93a69cf4-cbf6-e0a7-b7e3-d0e53040efe4@arm.com>
 <187815f0-1316-ee87-883d-11304064f8f9@raspberrypi.org>
 <06fad93c-a850-a99a-ae60-7306f9179032@arm.com>
 <f1394925-0651-0390-b646-1c489bfe6b4d@raspberrypi.org>
 <87tw4thyzu.fsf@on-the-bus.cambridge.arm.com>
 <a614119f-45a6-1fda-a261-e7e1a390b823@raspberrypi.org>
 <907820fc-c100-dad4-cf4f-95aa330667c5@arm.com>
 <1bbd3527-3328-b9c0-e9e0-d37092850a91@raspberrypi.org>
 <817a2689-15df-f2e4-3b3d-e5831fba7fa3@gmail.com>
Message-ID: <87shkc1tff.fsf@eliezer.anholt.net>

Florian Fainelli <f.fainelli at gmail.com> writes:

> On 05/10/2017 03:31 AM, Phil Elwell wrote:
>> On 10/05/2017 11:09, Marc Zyngier wrote:
>>> On 10/05/17 10:05, Phil Elwell wrote:
>>>> On 10/05/2017 09:55, Marc Zyngier wrote:
>>>>> On Wed, May 10 2017 at  9:27:10 am BST, Phil Elwell <phil at raspberrypi.org> wrote:
>>>>>> On 10/05/2017 08:42, Marc Zyngier wrote:
>>>>>>> On 09/05/17 20:02, Phil Elwell wrote:
>>>>>>>> On 09/05/2017 19:53, Marc Zyngier wrote:
>>>>>>>>> On 09/05/17 19:52, Phil Elwell wrote:
>>>>>>>>>> On 09/05/2017 19:14, Marc Zyngier wrote:
>>>>>>>>>>> On 09/05/17 19:08, Eric Anholt wrote:
>>>>>>>>>>>> Marc Zyngier <marc.zyngier at arm.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 09/05/17 17:59, Eric Anholt wrote:
>>>>>>>>>>>>>> Phil Elwell <phil at raspberrypi.org> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In order to reduce power consumption and bus traffic, it is sensible
>>>>>>>>>>>>>>> for secondary cores to enter a low-power idle state when waiting to
>>>>>>>>>>>>>>> be started. The wfe instruction causes a core to wait until an event
>>>>>>>>>>>>>>> or interrupt arrives before continuing to the next instruction.
>>>>>>>>>>>>>>> The sev instruction sends a wakeup event to the other cores, so call
>>>>>>>>>>>>>>> it from bcm2836_smp_boot_secondary, the function that wakes up the
>>>>>>>>>>>>>>> waiting cores during booting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is harmless to use this patch without the corresponding change
>>>>>>>>>>>>>>> adding wfe to the ARMv7/ARMv8-32 stubs, but if the stubs are updated
>>>>>>>>>>>>>>> and this patch is not applied then the other cores will sleep forever.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> See: https://github.com/raspberrypi/linux/issues/1989
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>  drivers/irqchip/irq-bcm2836.c | 3 +++
>>>>>>>>>>>>>>>  1 file changed, 3 insertions(+)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>>> index e10597c..6dccdf9 100644
>>>>>>>>>>>>>>> --- a/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>>> +++ b/drivers/irqchip/irq-bcm2836.c
>>>>>>>>>>>>>>> @@ -248,6 +248,9 @@ static int __init bcm2836_smp_boot_secondary(unsigned int cpu,
>>>>>>>>>>>>>>>  	writel(secondary_startup_phys,
>>>>>>>>>>>>>>>  	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> +	dsb(sy); /* Ensure write has completed before waking the other CPUs */
>>>>>>>>>>>>>>> +	sev();
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>  	return 0;
>>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is also the behavior that the standard arm64 spin-table
>>>>>>>>>>>>>> method has,
>>>>>>>>>>>>>> which we unfortunately can't quite use.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And why is that so? Why do you have to reinvent the wheel (and hide the
>>>>>>>>>>>>> cloned wheel in an interrupt controller driver)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> That doesn't seem right to me.
>>>>>>>>>>>>
>>>>>>>>>>>> The armv8 stubs (firmware-supplied code in the low page that do the
>>>>>>>>>>>> spinning) do actually implement arm64's spin-table method.  It's the
>>>>>>>>>>>> armv7 stubs that use these registers in the irqchip instead of plain
>>>>>>>>>>>> addresses in system memory.
>>>>>>>>>>>
>>>>>>>>>>> Let's put ARMv7 aside for the time being. If your firmware already
>>>>>>>>>>> implements spin-tables, why don't you simply use that at least on arm64?
>>>>>>>>>>
>>>>>>>>>> We do.
>>>>>>>>>
>>>>>>>>> Obviously not the way it is intended if you have to duplicate the core
>>>>>>>>> architectural code in the interrupt controller driver, which couldn't
>>>>>>>>> care less.
>>>>>>>>
>>>>>>>> If we were using this method on arm64 then the other cores would not start up
>>>>>>>> because armstub8.S has always included a wfe. Nothing in the commit mentions
>>>>>>>> arm64 - this is an ARCH=arm fix.
>>>>>>>
>>>>>>> Thanks for the clarification, which you could have added to the commit
>>>>>>> message.
>>>>>>>
>>>>>>> The question still remains: why do we have CPU bring-up code in an
>>>>>>> interrupt controller, instead of having it in the architecture code?
>>>>>>>
>>>>>>> The RPi-2 is the *only* platform to have its SMP bringup code outside of
>>>>>>> arch/arm, so the first course of action would be to move that code where
>>>>>>> it belongs.
>>>>>>
>>>>>> You were CC'd on the commit (41f4988cc287e5f836d3f6620c9f900bc9b560e9) that
>>>>>> introduced bcm2836_smp_boot_secondary - it seems strange to start objecting
>>>>>> now.
>>>>>
>>>>> Well, I'm far from being perfect. If I had noticed it, I'd have NACKed
>>>>> it.
>>>>>
>>>>>> Yes, I think it is odd that it didn't go into arch/arm/mach-bcm, but in
>>>>>> the interests of making changes in small, independent steps, do you have a
>>>>>> problem with this commit?
>>>>>
>>>>> On its own, no. I'm just not keen on adding more unrelated stuff to this
>>>>> file, so let's start with dealing with the original bug, and you can
>>>>> then add this fix on top.
>>>>
>>>> That's an interesting use of the word "bug". From Wikipedia:
>>>>
>>>> "A software bug is an error, flaw, failure or fault in a computer program or
>>>> system that causes it to produce an incorrect or unexpected result, or to
>>>> behave in unintended ways."
>>>
>>> Whatever. Should I call it "pile of crap dumped in unsuitable locations"
>>> instead? What does Wikipedia says about it?
>>>
>>>> Although your concerns are valid, the faults you are objecting to are not causing
>>>> a malfunction of any kind. If we were to update the RPi firmware before this
>>>> patch was merged then upstream users would be left with one wheel on their wagon.
>>>
>>> And that'd be your problem, not mine. Look, you can argue around this
>>> all day, or you can fix this mess. Your choice.
>> 
>> Is that the opinion of all here?
>
> The choice of word here got largely out of the original topic and I
> surely did eat a ton of popcorn here. There are two things that need
> fixing, and the time line and process for fixing these is clear:
>
> - your bugfix (Phil) is something that should be applied now, and
> backported to -stable trees once the fix hits the irqchip tree (or Linus')
>
> - relocating the code that does the secondary boot out of
> drivers/irqchip/ into arch/arm/mach-bcm/ needs to happen (Marc), and
> this is 4.13 material, there is no urgency in doing this *right now*,
> but it needs to happen
>
> Does that work for everyone?

Agreed.  This patch, which we'll want to go to -stable, should clearly
go in first.  Marc's patch can go in after, since it's not a -stable
candidate.

Thomas, could you add the cc to stable when picking this patch?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170510/5c2ce7cd/attachment.sig>

From dianders at chromium.org  Wed May 10 16:50:52 2017
From: dianders at chromium.org (Doug Anderson)
Date: Wed, 10 May 2017 16:50:52 -0700
Subject: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
In-Reply-To: <20170510163150.GK30445@localhost>
References: <172093673.40121.1492427140661@email.1und1.de>
 <CAD=FV=WJBTUcMPw8OgQT_jhz0H8AsH=YqWMR7LtudUKrF5-XOA@mail.gmail.com>
 <79b9b35b-0600-771f-4cd2-9e03c5ba3a25@i2se.com>
 <186569458.91967.1492547106553@email.1und1.de>
 <CAD=FV=VHkJFrsJDmMytbUw=WjKQaGZ-8Ewfy5bPCA82AWS4O2Q@mail.gmail.com>
 <212870399.174480.1492633502649@email.1und1.de>
 <87mvbaykn1.fsf@eliezer.anholt.net>
 <1998517910.54108.1492894253010@email.1und1.de>
 <2127594073.298820.1493143869792@email.1und1.de>
 <316369012.317772.1494274928708@email.1und1.de>
 <20170510163150.GK30445@localhost>
Message-ID: <CAD=FV=VUaqtR2t04wodRJ33bqHo5DPke7zsvqBMYqZ5imX5+=A@mail.gmail.com>

Hi,

On Wed, May 10, 2017 at 9:31 AM, Johan Hovold <johan at kernel.org> wrote:
> On Mon, May 08, 2017 at 10:22:08PM +0200, Stefan Wahren wrote:
>>
>> > Stefan Wahren <stefan.wahren at i2se.com> hat am 25. April 2017 um 20:11 geschrieben:
>> >
>> >
>> > > Stefan Wahren <stefan.wahren at i2se.com> hat am 22. April 2017 um 22:50 geschrieben:
>> > >
>> > >
>> > > Hi,
>> > >
>> > > > Eric Anholt <eric at anholt.net> hat am 20. April 2017 um 20:54 geschrieben:
>> > > >
>> > > >
>> > > > Stefan Wahren <stefan.wahren at i2se.com> writes:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > >> Doug Anderson <dianders at chromium.org> hat am 18. April 2017 um 22:41 geschrieben:
>> > > > >>
>> > > > >>
>> > > > >> It's hard to know for sure that all of this time is really in
>> > > > >> urb_enqueue().  Possible we could have task switched out and been
>> > > > >> blocked elsewhere.  Using ftrace to get more fine-grained timings
>> > > > >> would be useful.  ktime_get(), ktime_sub(), and ktime_to_us() are your
>> > > > >> friends here if you want to use trace_printk.
>> > > > >
>> > > > > i'm a newbie to ftrace, so i hope this would be helpful.
>> > > > >
>> > > > > # connect PL2303 to the onboard hub
>> > > > > # echo 0 > options/sleep-time
>> > > > > # echo 0 > function_profile_enabled
>> > > > > # echo 1 > function_profile_enabled
>> > > > > # ./usb_test
>> > > > > # Waiting for at least 20 seconds and then disconnect PL2303
>> > > > > # echo 0 > function_profile_enabled
>> > > > > # cat trace_stat/function0
>> > > > >
>> > > > >   Function                               Hit    Time            Avg             s^2
>> > > > >   --------                               ---    ----            ---             ---
>> > > > >   bcm2835_handle_irq                  361347    219567633 us     607.636 us      1485199 us
>> > > > >   __handle_domain_irq                1082482    212639551 us     196.437 us      3642030 us
>> > > > >   generic_handle_irq                 1082482    100592051 us     92.927 us       50511334 us
>> > > > >   irq_exit                           1082482    98197771 us     90.715 us       29649040 us
>> > > > >   handle_level_irq                   1082482    95812379 us     88.511 us       51910093 us
>> > > >
>> > > > If I'm reading this output right, we're spending half of our interrupt
>> > > > processing time in irq_exit(), so even if dwc2's interrupt was free (the
>> > > > generic_handle_irq() chain), we'd be eating about half the CPU getting
>> > > > back out of the interrupt handler, right?
>> > > >
>> > > > I don't really know anything about DWC2 or USB, but is there any way we
>> > > > could mitigate the interrupt frequency with this hardware?  If nothing
>> > > > else, could we loop reading gintsts until it reads back 0?
>> > >
>> > > first of all i updated my kernel to 4.11rc7 and the issue still
>> > > occures. Today i had some time to investigate this issue further
>> > > and i made some interesting observations:
>> > >
>> > > 1. The lockup doesn't occure always after starting usb_test. In
>> > > rare cases i was able to run the program without lockup.
>> > > 2. In case the lockup occured we are always able to "rescue" the
>> > > BCM2835 from this state by sending some serial data to the PL2303.
>> >
>> > Based on this scenario i patched the interrupt routine to detect the
>> > interrupt storm and normal condition. So i can dump the global and
>> > host registers in both situations (bad and goodcase).
>> >
>> > Here is the diff between both register dumps, maybe someone see
>> > something interesting:
>> >
>> > --- badcase.txt     2017-04-25 18:02:59.000000000 +0000
>> > +++ goodcase.txt    2017-04-25 18:02:59.000000000 +0000
>> > @@ -4,12 +4,12 @@
>> >   dwc2_dump_global_registers: GAHBCFG        @0xCC850008 : 0x00000031
>> >   dwc2_dump_global_registers: GUSBCFG        @0xCC85000C : 0x20001700
>> >   dwc2_dump_global_registers: GRSTCTL        @0xCC850010 : 0x80000000
>> > - dwc2_dump_global_registers: GINTSTS        @0xCC850014 : 0x06000021
>> > + dwc2_dump_global_registers: GINTSTS        @0xCC850014 : 0x06000029
>> >   dwc2_dump_global_registers: GINTMSK        @0xCC850018 : 0xF300080E
>> > - dwc2_dump_global_registers: GRXSTSR        @0xCC85001C : 0x00070044
>> > + dwc2_dump_global_registers: GRXSTSR        @0xCC85001C : 0x000F0001
>> >   dwc2_dump_global_registers: GRXFSIZ        @0xCC850024 : 0x00000306
>> >   dwc2_dump_global_registers: GNPTXFSIZ      @0xCC850028 : 0x01000306
>> > - dwc2_dump_global_registers: GNPTXSTS       @0xCC85002C : 0x1D080100
>> > + dwc2_dump_global_registers: GNPTXSTS       @0xCC85002C : 0x18080100
>> > ...
>>
>> @Doug, @John Y., @Johan: Any further ideas to narrow down the reason
>> for this interrupt storm?
>
> No, sorry.
>
> I suggested earlier that you could try commenting out the interrupt-URB
> submission in a naive attempt to narrow it down since that is an obvious
> difference from the ftdi driver, but then again so are the frequent ftdi
> status bulk messages (and any other timing differences).
>
> Seems like you need to dig into dwc2.

I haven't had a chance to dig and not sure when I'll have that time.
I'll keep this around in my inbox for now on the off chance that I
clean it out enough to get back to this.  Sorry!


From afaerber at suse.de  Sun May 14 05:50:07 2017
From: afaerber at suse.de (=?UTF-8?Q?Andreas_F=c3=a4rber?=)
Date: Sun, 14 May 2017 14:50:07 +0200
Subject: [PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware
In-Reply-To: <b6aef857-1454-7931-2c60-6d7b55b7a0a8@raspberrypi.org>
References: <b6aef857-1454-7931-2c60-6d7b55b7a0a8@raspberrypi.org>
Message-ID: <bb27bf8d-497e-6d1d-40da-828b04032eb4@suse.de>

Am 09.05.2017 um 11:04 schrieb Phil Elwell:
> The Raspberry Pi startup stub files for multi-core BCM27XX processors

Curiously, while this V2 was rebased to apply against the bcm283x rather
than bcm2710 file, it changed the text from BCM283X to BCM27XX.

> make the secondary CPUs spin until the corresponding mailbox is
> written. These stubs are loaded at physical address 0x00000xxx (as seen
> by the ARMs), but this page will be reused by the kernel unless it is
> explicitly reserved, causing the waiting cores to execute random code.
> 
> Use the /memreserve/ Device Tree directive to mark the first page as
> off-limits to the kernel.
> 
> See: https://github.com/raspberrypi/linux/issues/1989
> 
> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
> ---
> 
> Changes in V2:
> - Rebase against linux-next
> - Drop downstream-only patch
> 
>  arch/arm/boot/dts/bcm283x.dtsi | 2 ++
>  1 file changed, 2 insertions(+)

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)


From phil at raspberrypi.org  Mon May 15 07:29:29 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Mon, 15 May 2017 15:29:29 +0100
Subject: [Bug] VCHIQ functional test broken
In-Reply-To: <20170513093016.GQ22219@n2100.armlinux.org.uk>
References: <20170413222915.GF17774@n2100.armlinux.org.uk>
 <20170414074104.GA8704@laptop> <87pog7x7c5.fsf@eliezer.anholt.net>
 <20170420195822.GA22677@laptop>
 <696fb1c1-7751-caf0-e0d9-9c67b059b4cc@i2se.com>
 <20170424164015.GP17774@n2100.armlinux.org.uk>
 <1058502523.15283.1493055747531@email.1und1.de>
 <20170424185931.GQ17774@n2100.armlinux.org.uk>
 <1381182989.263636.1493062504676@email.1und1.de>
 <952745481.440383.1494666448727@email.1und1.de>
 <20170513093016.GQ22219@n2100.armlinux.org.uk>
Message-ID: <34277896-d59f-9026-8700-d592c14458f5@raspberrypi.org>

On 13/05/2017 10:30, Russell King - ARM Linux wrote:
> On Sat, May 13, 2017 at 11:07:28AM +0200, Stefan Wahren wrote:
>> In the meantime this issue has been fixed by Phil [1].
> 
> Right - definitely a driver bug.  Mapping more memory for DMA than is
> actually going to be DMA'd to and expecting data to be preserved is
> really horrid.

That feature was added during the upstreaming process, and as Stefan says
there is an outstanding patch for it.

>> Unfortunately i found another issue. If i enable CONFIG_HIGHMEM in
>> the kernel config, the data during functional test gets corrupted.
>> Phil said it's caused by the usage of get_user_pages() [2].
> 
> Without knowing who "Phil" is in that thread, but...
> 
>    HIGHMEM is a problem because you can't use get_user_pages on pages in
>    HIGHMEM.
> 
> is an interesting statement, and without any reasoning or evidence.
> 
> I also believe it to be incorrect.  get_user_pages() returns an array
> of struct page pointers for the user memory, calling flush_dcache_page()
> and flush_anon_page() on them to ensure that any kernel mapping is
> coherent with what is in userspace.
> 
> As far as returning the array of page pointers, get_user_pages() doesn't
> care whether they're lowmem or highmem.
> 
> flush_dcache_page() doesn't care either - if it wants to flush the page
> and the page is a highmem page, it will temporarily map it before
> flushing it.
> 
> flush_anon_page() is a no-op for all non-aliasing caches.
> 
> get_user_pages() works fine for whatever memory on other platforms and
> drivers such as etnaviv, so I think this comes down to the vchip driver
> doing things in ways that the kernel interfaces its using don't expect -
> exactly like the "lets pass full pages to the DMA API" broken-ness.

See previous comment.

> I would like to hear the justification for that statement, but without
> any justification, I assert that the statement is false.

I am the Phil in question, and the off-the-cuff comment was the result of
a hazy memory of issues encountered with VCHIQ bulk transfers as a Broadcom
employee (which would have been on a 2.6 kernel). I suspect there may have
been some use of kernel virtual addresses as an intermediate representation,
but I no longer have access to that code.

If get_user_pages is HIGHMEM-safe (and I can see why it would be), then the
cause of the corruption Stefan saw is probably the special handling of
unaligned reads, specifically:

			memcpy((char *)page_address(pages[0]) +
				pagelist->offset,
				fragments,
				head_bytes);

Phil


From stefan.wahren at i2se.com  Mon May 15 07:54:50 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Mon, 15 May 2017 16:54:50 +0200
Subject: [Bug] VCHIQ functional test broken
In-Reply-To: <34277896-d59f-9026-8700-d592c14458f5@raspberrypi.org>
References: <20170413222915.GF17774@n2100.armlinux.org.uk>
 <20170414074104.GA8704@laptop> <87pog7x7c5.fsf@eliezer.anholt.net>
 <20170420195822.GA22677@laptop>
 <696fb1c1-7751-caf0-e0d9-9c67b059b4cc@i2se.com>
 <20170424164015.GP17774@n2100.armlinux.org.uk>
 <1058502523.15283.1493055747531@email.1und1.de>
 <20170424185931.GQ17774@n2100.armlinux.org.uk>
 <1381182989.263636.1493062504676@email.1und1.de>
 <952745481.440383.1494666448727@email.1und1.de>
 <20170513093016.GQ22219@n2100.armlinux.org.uk>
 <34277896-d59f-9026-8700-d592c14458f5@raspberrypi.org>
Message-ID: <910b284d-52b4-d2ca-c0c6-0018718c1402@i2se.com>

Am 15.05.2017 um 16:29 schrieb Phil Elwell:
> On 13/05/2017 10:30, Russell King - ARM Linux wrote:
>> On Sat, May 13, 2017 at 11:07:28AM +0200, Stefan Wahren wrote:
>>> In the meantime this issue has been fixed by Phil [1].
>> Right - definitely a driver bug.  Mapping more memory for DMA than is
>> actually going to be DMA'd to and expecting data to be preserved is
>> really horrid.
> That feature was added during the upstreaming process, and as Stefan says
> there is an outstanding patch for it.
>
>>> Unfortunately i found another issue. If i enable CONFIG_HIGHMEM in
>>> the kernel config, the data during functional test gets corrupted.
>>> Phil said it's caused by the usage of get_user_pages() [2].
>> Without knowing who "Phil" is in that thread, but...
>>
>>    HIGHMEM is a problem because you can't use get_user_pages on pages in
>>    HIGHMEM.
>>
>> is an interesting statement, and without any reasoning or evidence.
>>
>> I also believe it to be incorrect.  get_user_pages() returns an array
>> of struct page pointers for the user memory, calling flush_dcache_page()
>> and flush_anon_page() on them to ensure that any kernel mapping is
>> coherent with what is in userspace.
>>
>> As far as returning the array of page pointers, get_user_pages() doesn't
>> care whether they're lowmem or highmem.
>>
>> flush_dcache_page() doesn't care either - if it wants to flush the page
>> and the page is a highmem page, it will temporarily map it before
>> flushing it.
>>
>> flush_anon_page() is a no-op for all non-aliasing caches.
>>
>> get_user_pages() works fine for whatever memory on other platforms and
>> drivers such as etnaviv, so I think this comes down to the vchip driver
>> doing things in ways that the kernel interfaces its using don't expect -
>> exactly like the "lets pass full pages to the DMA API" broken-ness.
> See previous comment.
>
>> I would like to hear the justification for that statement, but without
>> any justification, I assert that the statement is false.
> I am the Phil in question, and the off-the-cuff comment was the result of
> a hazy memory of issues encountered with VCHIQ bulk transfers as a Broadcom
> employee (which would have been on a 2.6 kernel). I suspect there may have
> been some use of kernel virtual addresses as an intermediate representation,
> but I no longer have access to that code.
>
> If get_user_pages is HIGHMEM-safe (and I can see why it would be), then the
> cause of the corruption Stefan saw is probably the special handling of
> unaligned reads, specifically:
>
> 			memcpy((char *)page_address(pages[0]) +
> 				pagelist->offset,
> 				fragments,
> 				head_bytes);


Btw shouldn't we use copy_from_user() at this place?


From phil at raspberrypi.org  Mon May 15 08:05:36 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Mon, 15 May 2017 16:05:36 +0100
Subject: [Bug] VCHIQ functional test broken
In-Reply-To: <910b284d-52b4-d2ca-c0c6-0018718c1402@i2se.com>
References: <20170413222915.GF17774@n2100.armlinux.org.uk>
 <20170414074104.GA8704@laptop> <87pog7x7c5.fsf@eliezer.anholt.net>
 <20170420195822.GA22677@laptop>
 <696fb1c1-7751-caf0-e0d9-9c67b059b4cc@i2se.com>
 <20170424164015.GP17774@n2100.armlinux.org.uk>
 <1058502523.15283.1493055747531@email.1und1.de>
 <20170424185931.GQ17774@n2100.armlinux.org.uk>
 <1381182989.263636.1493062504676@email.1und1.de>
 <952745481.440383.1494666448727@email.1und1.de>
 <20170513093016.GQ22219@n2100.armlinux.org.uk>
 <34277896-d59f-9026-8700-d592c14458f5@raspberrypi.org>
 <910b284d-52b4-d2ca-c0c6-0018718c1402@i2se.com>
Message-ID: <2578ec19-a41f-b16b-f713-4fae8e43006a@raspberrypi.org>

On 15/05/2017 15:54, Stefan Wahren wrote:
> Am 15.05.2017 um 16:29 schrieb Phil Elwell:
>> On 13/05/2017 10:30, Russell King - ARM Linux wrote:
>>> On Sat, May 13, 2017 at 11:07:28AM +0200, Stefan Wahren wrote:
>>>> In the meantime this issue has been fixed by Phil [1].
>>> Right - definitely a driver bug.  Mapping more memory for DMA than is
>>> actually going to be DMA'd to and expecting data to be preserved is
>>> really horrid.
>> That feature was added during the upstreaming process, and as Stefan says
>> there is an outstanding patch for it.
>>
>>>> Unfortunately i found another issue. If i enable CONFIG_HIGHMEM in
>>>> the kernel config, the data during functional test gets corrupted.
>>>> Phil said it's caused by the usage of get_user_pages() [2].
>>> Without knowing who "Phil" is in that thread, but...
>>>
>>>    HIGHMEM is a problem because you can't use get_user_pages on pages in
>>>    HIGHMEM.
>>>
>>> is an interesting statement, and without any reasoning or evidence.
>>>
>>> I also believe it to be incorrect.  get_user_pages() returns an array
>>> of struct page pointers for the user memory, calling flush_dcache_page()
>>> and flush_anon_page() on them to ensure that any kernel mapping is
>>> coherent with what is in userspace.
>>>
>>> As far as returning the array of page pointers, get_user_pages() doesn't
>>> care whether they're lowmem or highmem.
>>>
>>> flush_dcache_page() doesn't care either - if it wants to flush the page
>>> and the page is a highmem page, it will temporarily map it before
>>> flushing it.
>>>
>>> flush_anon_page() is a no-op for all non-aliasing caches.
>>>
>>> get_user_pages() works fine for whatever memory on other platforms and
>>> drivers such as etnaviv, so I think this comes down to the vchip driver
>>> doing things in ways that the kernel interfaces its using don't expect -
>>> exactly like the "lets pass full pages to the DMA API" broken-ness.
>> See previous comment.
>>
>>> I would like to hear the justification for that statement, but without
>>> any justification, I assert that the statement is false.
>> I am the Phil in question, and the off-the-cuff comment was the result of
>> a hazy memory of issues encountered with VCHIQ bulk transfers as a Broadcom
>> employee (which would have been on a 2.6 kernel). I suspect there may have
>> been some use of kernel virtual addresses as an intermediate representation,
>> but I no longer have access to that code.
>>
>> If get_user_pages is HIGHMEM-safe (and I can see why it would be), then the
>> cause of the corruption Stefan saw is probably the special handling of
>> unaligned reads, specifically:
>>
>> 			memcpy((char *)page_address(pages[0]) +
>> 				pagelist->offset,
>> 				fragments,
>> 				head_bytes);
> 
> 
> Btw shouldn't we use copy_from_user() at this place?

I'm sure you mean copy_to_user(), and the answer is "it's complicated". Depending
on the relative timing, this code can also be called from a kernel thread, so I
doubt that would work.

Phil


From eric at anholt.net  Tue May 16 15:04:54 2017
From: eric at anholt.net (Eric Anholt)
Date: Tue, 16 May 2017 15:04:54 -0700
Subject: arm64 vs arm tree for BCM2837 DT pull requests
Message-ID: <87tw4kbgqh.fsf@eliezer.anholt.net>

I'm looking for feedback on how the ARM folks would like to see pull
requests for Raspberry Pi 3 devicetree changes.  My problem is trying to
merge patches like:

https://patchwork.kernel.org/patch/9603689/

which depends on:

https://patchwork.kernel.org/patch/9619573/

bcm2837's DT is in arm64/, but includes the bcm283x.dtsi under arm/
(which also contains pi0-2), so we often end up with cross-tree
dependencies when trying to merge a patch series affecting peripherals
common to all of them.  How I've done this in the past is in
http://lists.infradead.org/pipermail/linux-rpi-kernel/2016-November/004804.html:
Send a PR for bcm2835-dt-next for the arm/ BCM283x changes, merge that
tag to bcm2835-dt-64-next, apply the arm64 change, and send a separate
PR for that branch.

This seems silly to me -- in trying to keep a small arm64/ change out of
the branch for arm/, we end up pulling in much larger arm/ changes to
the arm64/ branch.  Also, this process doesn't work if we need to make a
single-commit change across both (like if we decided to change a node
name that's referenced by '&' in the board-specific .dts files).

So, I'd like to ask that I be able to merge all the BCM283x DT changes
through my bcm2835-dt-next branch, if that's OK.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170516/2e9fc8df/attachment.sig>

From eric at anholt.net  Tue May 16 15:19:31 2017
From: eric at anholt.net (Eric Anholt)
Date: Tue, 16 May 2017 15:19:31 -0700
Subject: [GIT PULL] bcm2835 DT fixes for 4.12
Message-ID: <20170516221931.31292-1-eric@anholt.net>

Hi Florian,

The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:

  Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)

are available in the git repository at:

  git://github.com/anholt/linux tags/bcm2835-dt-fixes-2017-05-16

for you to fetch changes up to b0804ed0cadd7e38d94d2f15cdcc0d9695818856:

  ARM: dts: bcm283x: Reserve first page for firmware (2017-05-15 15:05:29 -0700)

----------------------------------------------------------------
This pull request brings in a fix for booting on SMP Raspberry Pis,
particularly with maxcpus=1

----------------------------------------------------------------
Phil Elwell (1):
      ARM: dts: bcm283x: Reserve first page for firmware

 arch/arm/boot/dts/bcm283x.dtsi | 5 +++++
 1 file changed, 5 insertions(+)


From stefan.wahren at i2se.com  Thu May 18 10:10:40 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Thu, 18 May 2017 19:10:40 +0200 (CEST)
Subject: dwc2: g-tx-fifo-size configuration on bcm2835
Message-ID: <2085832173.628784.1495127440328@email.1und1.de>

Hi,

since the dwc2 should be able to properly setup its fifos, i want to enable otg mode for Raspberry Pi Zero (BCM2835). According to the BCM2835 datasheet [1] it has 7 device EPs with a max FIFO depth for EP1..5 = 512 and EP6,7 = 768. This makes in sum 4096, which also seems to be okay regarding to datasheet.

So i defined the following DTS part:

&usb {
	dr_mode = "otg";
	g-rx-fifo-size = <256>;
	g-np-tx-fifo-size = <32>;
	g-tx-fifo-size = <512 512 512 512 512 768 768>;
};

Unfortunately i get the following errors from dwc2:

[    2.535879] dwc2 20980000.usb: dwc2_check_param_tx_fifo_sizes: Invalid parameter g-tx-fifo-size, setting to default average
[    2.561611] dwc2 20980000.usb: dwc2_check_param_tx_fifo_sizes: Invalid parameter g_tx_fifo_size[1]=539
[    2.586045] dwc2 20980000.usb: dwc2_check_param_tx_fifo_sizes: Invalid parameter g_tx_fifo_size[2]=539
[    2.611045] dwc2 20980000.usb: dwc2_check_param_tx_fifo_sizes: Invalid parameter g_tx_fifo_size[3]=539
[    2.636209] dwc2 20980000.usb: dwc2_check_param_tx_fifo_sizes: Invalid parameter g_tx_fifo_size[4]=539
[    2.661952] dwc2 20980000.usb: dwc2_check_param_tx_fifo_sizes: Invalid parameter g_tx_fifo_size[5]=539
[    2.688044] dwc2 20980000.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM
[    2.704753] g_serial gadget: Gadget Serial v2.4
[    2.717962] g_serial gadget: g_serial ready
[    2.730830] dwc2 20980000.usb: bound driver g_serial
[    2.745485] dwc2 20980000.usb: DWC OTG Controller
[    2.759763] dwc2 20980000.usb: new USB bus registered, assigned bus number 1
[    2.776556] dwc2 20980000.usb: irq 33, io mem 0x20980000

Since these messages aren't really helpful, i added a info messages about fifo_count, sum of all fifo sizes and allowed total from hardware:

[    2.512808] dwc2 20980000.usb: dwc2_check_param_tx_fifo_sizes: fifo_count = 7, sum = 4096, total = 3776

So i decided to use the following setting, which works without any issues:

g-tx-fifo-size = <512 512 512 512 512 512 512>;

Here are my questions:

Is the dwc2 still broken regarding to this error or is the datasheet wrong?

Is it save to use the working g-tx-fifo-size for peripheral and otg mode? Or do i need to reserve some space in fifo (for host mode)?

Is this the proper way to evaluate the right g-tx-fifo-size setting?

Regards
Stefan

[1] - https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf


From phil at raspberrypi.org  Fri May 19 08:07:23 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Fri, 19 May 2017 16:07:23 +0100
Subject: [PATCH] serial: 8250: Add CAP_MINI, set for bcm2835aux
Message-ID: <8d9c605a-bff7-607c-2c5b-4ec75e68ac2d@raspberrypi.org>

The AUX/mini-UART in the BCM2835 family of procesors is a cut-down
8250 clone. In particular it is lacking support for the following
features: CSTOPB PARENB PARODD CMSPAR CS5 CS6

Add a new capability (UART_CAP_MINI) that exposes the restrictions to
the user of the termios API by turning off the unsupported features in
the request.

N.B. It is almost possible to automatically discover the missing
features by reading back the LCR register, but the CSIZE bits don't
cooperate (contrary to the documentation, both bits are significant,
but CS5 and CS6 are mapped to CS7) and the code is much longer.

See: https://github.com/raspberrypi/linux/issues/1561

Signed-off-by: Phil Elwell <phil at raspberrypi.org>
---
 drivers/tty/serial/8250/8250.h            | 3 +++
 drivers/tty/serial/8250/8250_bcm2835aux.c | 2 +-
 drivers/tty/serial/8250/8250_port.c       | 6 ++++++
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index ce8d4ff..b2bdc35 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -81,6 +81,9 @@ struct serial8250_config {
 #define UART_CAP_HFIFO	(1 << 14)	/* UART has a "hidden" FIFO */
 #define UART_CAP_RPM	(1 << 15)	/* Runtime PM is active while idle */
 #define UART_CAP_IRDA	(1 << 16)	/* UART supports IrDA line discipline */
+#define UART_CAP_MINI	(1 << 17)	/* Mini UART on BCM283X family lacks:
+					 * STOP PARITY EPAR SPAR WLEN5 WLEN6
+					 */
 
 #define UART_BUG_QUOT	(1 << 0)	/* UART has buggy quot LSB */
 #define UART_BUG_TXEN	(1 << 1)	/* UART has buggy TX IIR status */
diff --git a/drivers/tty/serial/8250/8250_bcm2835aux.c b/drivers/tty/serial/8250/8250_bcm2835aux.c
index e10f124..a23c7da 100644
--- a/drivers/tty/serial/8250/8250_bcm2835aux.c
+++ b/drivers/tty/serial/8250/8250_bcm2835aux.c
@@ -39,7 +39,7 @@ static int bcm2835aux_serial_probe(struct platform_device *pdev)
 
 	/* initialize data */
 	spin_lock_init(&data->uart.port.lock);
-	data->uart.capabilities = UART_CAP_FIFO;
+	data->uart.capabilities = UART_CAP_FIFO | UART_CAP_MINI;
 	data->uart.port.dev = &pdev->dev;
 	data->uart.port.regshift = 2;
 	data->uart.port.type = PORT_16550;
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 09a65a3..dd218a1 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2584,6 +2584,12 @@ static unsigned int serial8250_get_baud_rate(struct uart_port *port,
 	unsigned long flags;
 	unsigned int baud, quot, frac = 0;
 
+	if (up->capabilities & UART_CAP_MINI) {
+		termios->c_cflag &= ~(CSTOPB | PARENB | PARODD | CMSPAR);
+		if ((termios->c_cflag & CSIZE) == CS5 ||
+		    (termios->c_cflag & CSIZE) == CS6)
+			termios->c_cflag = (termios->c_cflag & ~CSIZE) | CS7;
+	}
 	cval = serial8250_compute_lcr(up, termios->c_cflag);
 
 	baud = serial8250_get_baud_rate(port, termios, old);
-- 
1.9.1



From eric at anholt.net  Fri May 19 11:09:54 2017
From: eric at anholt.net (Eric Anholt)
Date: Fri, 19 May 2017 11:09:54 -0700
Subject: [PATCH] serial: 8250: Add CAP_MINI, set for bcm2835aux
In-Reply-To: <8d9c605a-bff7-607c-2c5b-4ec75e68ac2d@raspberrypi.org>
References: <8d9c605a-bff7-607c-2c5b-4ec75e68ac2d@raspberrypi.org>
Message-ID: <87vaowg1l9.fsf@eliezer.anholt.net>

Phil Elwell <phil at raspberrypi.org> writes:

> The AUX/mini-UART in the BCM2835 family of procesors is a cut-down
> 8250 clone. In particular it is lacking support for the following
> features: CSTOPB PARENB PARODD CMSPAR CS5 CS6
>
> Add a new capability (UART_CAP_MINI) that exposes the restrictions to
> the user of the termios API by turning off the unsupported features in
> the request.
>
> N.B. It is almost possible to automatically discover the missing
> features by reading back the LCR register, but the CSIZE bits don't
> cooperate (contrary to the documentation, both bits are significant,
> but CS5 and CS6 are mapped to CS7) and the code is much longer.
>
> See: https://github.com/raspberrypi/linux/issues/1561
>
> Signed-off-by: Phil Elwell <phil at raspberrypi.org>

Acked-by: Eric Anholt <eric at anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170519/cbe32ac4/attachment.sig>

From f.fainelli at gmail.com  Fri May 19 11:17:43 2017
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri, 19 May 2017 11:17:43 -0700
Subject: [GIT PULL] bcm2835 DT fixes for 4.12
In-Reply-To: <20170516221931.31292-1-eric@anholt.net>
References: <20170516221931.31292-1-eric@anholt.net>
Message-ID: <d16bf00b-d058-08d1-ed6a-2f369d1fd611@gmail.com>

On 05/16/2017 03:19 PM, Eric Anholt wrote:
> Hi Florian,
> 
> The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
> 
>   Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
> 
> are available in the git repository at:
> 
>   git://github.com/anholt/linux tags/bcm2835-dt-fixes-2017-05-16
> 
> for you to fetch changes up to b0804ed0cadd7e38d94d2f15cdcc0d9695818856:
> 
>   ARM: dts: bcm283x: Reserve first page for firmware (2017-05-15 15:05:29 -0700)
> 
> ----------------------------------------------------------------
> This pull request brings in a fix for booting on SMP Raspberry Pis,
> particularly with maxcpus=1
> 
> ----------------------------------------------------------------

Merged, thanks Eric
-- 
-- 
Florian


From eric at anholt.net  Mon May 15 10:35:04 2017
From: eric at anholt.net (Eric Anholt)
Date: Mon, 15 May 2017 10:35:04 -0700
Subject: [PATCH] clk: bcm2835: Correct the prediv logic
Message-ID: <20170515173504.11337-1-eric@anholt.net>

From: Phil Elwell <phil at raspberrypi.org>

If a clock has the prediv flag set, both the integer and fractional
parts must be scaled when calculating the resulting frequency.

Signed-off-by: Phil Elwell <phil at raspberrypi.org>
Signed-off-by: Eric Anholt <eric at anholt.net>
---

While this is a bugfix, I haven't put a "Fixes:" line in here to get
it automatically backported to stable.  We had trouble with the
out-of-tree DSI panel driver, at least: Our old set_rate() didn't
work, because the new PLL was just barely too fast to get the integer
PLL divider we needed.  We may run into similar troubles
elsewhere. --anholt

 drivers/clk/bcm/clk-bcm2835.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 025853870619..7a35df6b45bd 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -616,8 +616,10 @@ static unsigned long bcm2835_pll_get_rate(struct clk_hw *hw,
 	using_prediv = cprman_read(cprman, data->ana_reg_base + 4) &
 		data->ana->fb_prediv_mask;
 
-	if (using_prediv)
+	if (using_prediv) {
 		ndiv *= 2;
+		fdiv *= 2;
+	}
 
 	return bcm2835_pll_rate_from_divisors(parent_rate, ndiv, fdiv, pdiv);
 }
-- 
2.11.0



From stefan.wahren at i2se.com  Mon May 15 10:47:39 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Mon, 15 May 2017 19:47:39 +0200 (CEST)
Subject: [PATCH] clk: bcm2835: Correct the prediv logic
In-Reply-To: <20170515173504.11337-1-eric@anholt.net>
References: <20170515173504.11337-1-eric@anholt.net>
Message-ID: <1373231207.445862.1494870459462@email.1und1.de>

Hi Eric,

> Eric Anholt <eric at anholt.net> hat am 15. Mai 2017 um 19:35 geschrieben:
> 
> 
> From: Phil Elwell <phil at raspberrypi.org>
> 
> If a clock has the prediv flag set, both the integer and fractional
> parts must be scaled when calculating the resulting frequency.
> 
> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
> Signed-off-by: Eric Anholt <eric at anholt.net>
> ---
> 
> While this is a bugfix, I haven't put a "Fixes:" line in here to get
> it automatically backported to stable.  

sorry, i can't follow. How should this happen without "Fixes: "?

> We had trouble with the
> out-of-tree DSI panel driver, at least: Our old set_rate() didn't
> work, because the new PLL was just barely too fast to get the integer
> PLL divider we needed.  We may run into similar troubles
> elsewhere. --anholt
>


From eric at anholt.net  Mon May 15 12:03:29 2017
From: eric at anholt.net (Eric Anholt)
Date: Mon, 15 May 2017 12:03:29 -0700
Subject: [PATCH] clk: bcm2835: Correct the prediv logic
In-Reply-To: <1373231207.445862.1494870459462@email.1und1.de>
References: <20170515173504.11337-1-eric@anholt.net>
 <1373231207.445862.1494870459462@email.1und1.de>
Message-ID: <87bmqundry.fsf@eliezer.anholt.net>

Stefan Wahren <stefan.wahren at i2se.com> writes:

> Hi Eric,
>
>> Eric Anholt <eric at anholt.net> hat am 15. Mai 2017 um 19:35 geschrieben:
>> 
>> 
>> From: Phil Elwell <phil at raspberrypi.org>
>> 
>> If a clock has the prediv flag set, both the integer and fractional
>> parts must be scaled when calculating the resulting frequency.
>> 
>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>> Signed-off-by: Eric Anholt <eric at anholt.net>
>> ---
>> 
>> While this is a bugfix, I haven't put a "Fixes:" line in here to get
>> it automatically backported to stable.  
>
> sorry, i can't follow. How should this happen without "Fixes: "?

I didn't want it to be backported to stable, because of the risk.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170515/803ae7fe/attachment.sig>

From olof at lixom.net  Mon May 15 15:27:27 2017
From: olof at lixom.net (Olof Johansson)
Date: Mon, 15 May 2017 15:27:27 -0700
Subject: [PATCH] ARM: dts: Add devicetree for the Raspberry Pi 3, for
 arm32 (v6)
In-Reply-To: <20170425164508.32242-1-eric@anholt.net>
References: <20170425164508.32242-1-eric@anholt.net>
Message-ID: <CAOesGMjSR7AZ0o+bEHbjMDWwkyHgGSLLpVphCtTDVzKUyTzn5Q@mail.gmail.com>

Hi,

On Tue, Apr 25, 2017 at 9:45 AM, Eric Anholt <eric at anholt.net> wrote:
> Raspbian and Fedora have decided to support the Pi3 in 32-bit mode for
> now, so it's useful to be able to test that mode on an upstream
> kernel.  It's also been useful for me to use the same board for 32-bit
> and 64-bit development.
>
> Signed-off-by: Eric Anholt <eric at anholt.net>

Acked-by: Olof Johansson <olof at lixom.net>


-Olof


From eric at anholt.net  Tue May 16 15:19:51 2017
From: eric at anholt.net (Eric Anholt)
Date: Tue, 16 May 2017 15:19:51 -0700
Subject: [PATCH V2] ARM: dts: bcm283x: Reserve first page for firmware
In-Reply-To: <e2718c25-fdf1-ead1-cbfa-d23bf729a079@gmail.com>
References: <b6aef857-1454-7931-2c60-6d7b55b7a0a8@raspberrypi.org>
 <e2718c25-fdf1-ead1-cbfa-d23bf729a079@gmail.com>
Message-ID: <87pof8bg1k.fsf@eliezer.anholt.net>

Florian Fainelli <f.fainelli at gmail.com> writes:

> On 05/09/2017 02:04 AM, Phil Elwell wrote:
>> The Raspberry Pi startup stub files for multi-core BCM27XX processors
>> make the secondary CPUs spin until the corresponding mailbox is
>> written. These stubs are loaded at physical address 0x00000xxx (as seen
>> by the ARMs), but this page will be reused by the kernel unless it is
>> explicitly reserved, causing the waiting cores to execute random code.
>> 
>> Use the /memreserve/ Device Tree directive to mark the first page as
>> off-limits to the kernel.
>
> This reserves a 4KB page here, is this good enough, or should we just go
> directly to the maximum page granule size possible on an ARM64/Linux
> system to be on the safe side?
>
>> 
>> See: https://github.com/raspberrypi/linux/issues/1989
>> 
>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>> ---
>> 
>> Changes in V2:
>> - Rebase against linux-next
>> - Drop downstream-only patch
>> 
>>  arch/arm/boot/dts/bcm283x.dtsi | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
>> index a3106aa..6d12c3e8 100644
>> --- a/arch/arm/boot/dts/bcm283x.dtsi
>> +++ b/arch/arm/boot/dts/bcm283x.dtsi
>> @@ -3,6 +3,8 @@
>>  #include <dt-bindings/clock/bcm2835-aux.h>
>>  #include <dt-bindings/gpio/gpio.h>
>>  
>> +/memreserve/ 0x00000000 0x00001000;
>
> Can you put a comment above this /memreserve entry here to remind about
> what this is useful for?
>
> Thanks!

Phil, I chatted with Florian and added in:

+/* firmware-provided startup stubs live here, where the secondary CPUs are
+ * spinning.
+ */

and tagged and sent a PR for 4.12.  Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170516/13a30993/attachment.sig>

From srishtishar at gmail.com  Thu May 18 03:07:48 2017
From: srishtishar at gmail.com (srishti)
Date: Thu, 18 May 2017 15:37:48 +0530
Subject: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment coding
 style issue
Message-ID: <1495102068-3288-1-git-send-email-srishtishar@gmail.com>

Fixed a trailing */ issue.

Signed-off-by: srishti <srishtishar at gmail.com>
---
 drivers/staging/bcm2835-audio/bcm2835-ctl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/bcm2835-ctl.c b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
index a4ffa1b..38fabab 100644
--- a/drivers/staging/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
@@ -247,8 +247,8 @@ static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol *kcontrol,
 	struct snd_ctl_elem_value *ucontrol)
 {
 	/* bcm2835 supports only consumer mode and sets all other format flags
-	 * automatically. So the only thing left is signalling non-audio
-	 * content */
+	 * automatically. So the only thing left is signalling non-audio content
+	 */
 	ucontrol->value.iec958.status[0] = IEC958_AES0_NONAUDIO;
 	return 0;
 }
2.7.4



From dan.carpenter at oracle.com  Thu May 18 03:13:32 2017
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Thu, 18 May 2017 13:13:32 +0300
Subject: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment
 coding style issue
In-Reply-To: <1495102068-3288-1-git-send-email-srishtishar@gmail.com>
References: <1495102068-3288-1-git-send-email-srishtishar@gmail.com>
Message-ID: <20170518101332.nuy3bkw2bluzn6qh@mwanda>

On Thu, May 18, 2017 at 03:37:48PM +0530, srishti wrote:
> Fixed a trailing */ issue.
> 
> Signed-off-by: srishti <srishtishar at gmail.com>

Fix your From header and your signed-off-by line to use your legal name
as if you were signing a legal document.

regards,
dan carpenter



From srishtishar at gmail.com  Thu May 18 03:42:11 2017
From: srishtishar at gmail.com (srishti)
Date: Thu, 18 May 2017 16:12:11 +0530
Subject: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment coding
 style issue
Message-ID: <1495104131-4493-1-git-send-email-srishtishar@gmail.com>

From: srishti sharma <srishtishar at gmail.com>

Fixed a trailing */ issue.

Signed-off-by: srishti sharma <srishtishar at gmail.com>
---
 drivers/staging/bcm2835-audio/bcm2835-ctl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/bcm2835-ctl.c b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
index a4ffa1b..38fabab 100644
--- a/drivers/staging/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
@@ -247,8 +247,8 @@ static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol *kcontrol,
 	struct snd_ctl_elem_value *ucontrol)
 {
 	/* bcm2835 supports only consumer mode and sets all other format flags
-	 * automatically. So the only thing left is signalling non-audio
-	 * content */
+	 * automatically. So the only thing left is signalling non-audio content
+	 */
 	ucontrol->value.iec958.status[0] = IEC958_AES0_NONAUDIO;
 	return 0;
 }
2.7.4



From srishtishar at gmail.com  Thu May 18 03:50:15 2017
From: srishtishar at gmail.com (srishti)
Date: Thu, 18 May 2017 16:20:15 +0530
Subject: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment coding
 style issue
Message-ID: <1495104615-4752-1-git-send-email-srishtishar@gmail.com>

From: srishti sharma <srishtishar at gmail.com>

Fixed a trailing */ issue.

Signed-off-by: srishti sharma <srishtishar at gmail.com>
---
 drivers/staging/bcm2835-audio/bcm2835-ctl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/bcm2835-ctl.c b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
index a4ffa1b..38fabab 100644
--- a/drivers/staging/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
@@ -247,8 +247,8 @@ static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol *kcontrol,
 	struct snd_ctl_elem_value *ucontrol)
 {
 	/* bcm2835 supports only consumer mode and sets all other format flags
-	 * automatically. So the only thing left is signalling non-audio
-	 * content */
+	 * automatically. So the only thing left is signalling non-audio content
+	 */
 	ucontrol->value.iec958.status[0] = IEC958_AES0_NONAUDIO;
 	return 0;
 }
2.7.4



From gregkh at linuxfoundation.org  Thu May 18 06:58:50 2017
From: gregkh at linuxfoundation.org (Greg KH)
Date: Thu, 18 May 2017 15:58:50 +0200
Subject: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment
 coding style issue
In-Reply-To: <1495104615-4752-1-git-send-email-srishtishar@gmail.com>
References: <1495104615-4752-1-git-send-email-srishtishar@gmail.com>
Message-ID: <20170518135850.GA24513@kroah.com>

On Thu, May 18, 2017 at 04:20:15PM +0530, srishti wrote:
> From: srishti sharma <srishtishar at gmail.com>
> 
> Fixed a trailing */ issue.
> 
> Signed-off-by: srishti sharma <srishtishar at gmail.com>
> ---
>  drivers/staging/bcm2835-audio/bcm2835-ctl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

You sent two copies of this, which am I supposed to apply?  And what
changed from the last version?

I'm dropping this, please fix and only send _one_ copy of the patch.

thanks,

greg k-h


From srishtishar at gmail.com  Thu May 18 08:40:03 2017
From: srishtishar at gmail.com (srishti sharma)
Date: Thu, 18 May 2017 21:10:03 +0530
Subject: Fwd: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment
 coding style issue
In-Reply-To: <CAB3L5owb2go2Hik5iMRuzXzOdfyKH+gM27_ugfady79bXSnHuQ@mail.gmail.com>
References: <1495104615-4752-1-git-send-email-srishtishar@gmail.com>
 <20170518135850.GA24513@kroah.com>
 <CAB3L5owb2go2Hik5iMRuzXzOdfyKH+gM27_ugfady79bXSnHuQ@mail.gmail.com>
Message-ID: <CAB3L5owj6GJ7OaAbbE5rK-qGxLvop1LKyLsYK9L5up9gj4H+xg@mail.gmail.com>

---------- Forwarded message ----------
From: srishti sharma <srishtishar at gmail.com>
Date: Thu, May 18, 2017 at 9:06 PM
Subject: Re: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a
comment coding style issue
To: Greg KH <gregkh at linuxfoundation.org>


On Thu, May 18, 2017 at 7:28 PM, Greg KH <gregkh at linuxfoundation.org> wrote:
> On Thu, May 18, 2017 at 04:20:15PM +0530, srishti wrote:
>> From: srishti sharma <srishtishar at gmail.com>
>>
>> Fixed a trailing */ issue.
>>
>> Signed-off-by: srishti sharma <srishtishar at gmail.com>
>> ---
>>  drivers/staging/bcm2835-audio/bcm2835-ctl.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> You sent two copies of this, which am I supposed to apply?  And what
> changed from the last version?
>
> I'm dropping this, please fix and only send _one_ copy of the patch.
>
> thanks,
>
> greg k-h


both the patches are same , the from and signed-off-by didn't have my
legal name in the patch that I had sent before these . My "send mail
as " settings already have my legal name but it is only accepting the
first name . So I edited the from line in the patch itself , if this
format is correct do I still need to send another patch ?  Please let
me know if it is still incorrect . I have also tried sending it with
my legal name as an alias name in "send email as" settings , but it
only reflects in the from header when I send an email directly from
gmail and not when using git send-email and hence two copies got sent
, I am sorry about that.

Regards,
Srishti


From srishtishar at gmail.com  Fri May 19 12:30:17 2017
From: srishtishar at gmail.com (srishti sharma)
Date: Sat, 20 May 2017 01:00:17 +0530
Subject: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment
 coding style issue
In-Reply-To: <20170518135850.GA24513@kroah.com>
References: <1495104615-4752-1-git-send-email-srishtishar@gmail.com>
 <20170518135850.GA24513@kroah.com>
Message-ID: <CAB3L5ozKAq7rj71UdK0GpRTmk72eSpAwXEgUFq4uKrfB8Hrs9g@mail.gmail.com>

Was the format of this patch acceptable ,the "from" matches the
"signed-off-by" right , so this should be correct , were there any
errors in this ? Should I resend it ?

Regards,
Srishti

On Thu, May 18, 2017 at 7:28 PM, Greg KH <gregkh at linuxfoundation.org> wrote:
> On Thu, May 18, 2017 at 04:20:15PM +0530, srishti wrote:
>> From: srishti sharma <srishtishar at gmail.com>
>>
>> Fixed a trailing */ issue.
>>
>> Signed-off-by: srishti sharma <srishtishar at gmail.com>
>> ---
>>  drivers/staging/bcm2835-audio/bcm2835-ctl.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> You sent two copies of this, which am I supposed to apply?  And what
> changed from the last version?
>
> I'm dropping this, please fix and only send _one_ copy of the patch.
>
> thanks,
>
> greg k-h


From dan.carpenter at oracle.com  Fri May 19 12:33:33 2017
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Fri, 19 May 2017 22:33:33 +0300
Subject: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment
 coding style issue
In-Reply-To: <CAB3L5ozKAq7rj71UdK0GpRTmk72eSpAwXEgUFq4uKrfB8Hrs9g@mail.gmail.com>
References: <1495104615-4752-1-git-send-email-srishtishar@gmail.com>
 <20170518135850.GA24513@kroah.com>
 <CAB3L5ozKAq7rj71UdK0GpRTmk72eSpAwXEgUFq4uKrfB8Hrs9g@mail.gmail.com>
Message-ID: <20170519193333.5sfsripy27k3xd7r@mwanda>

On Sat, May 20, 2017 at 01:00:17AM +0530, srishti sharma wrote:
> Was the format of this patch acceptable ,the "from" matches the
> "signed-off-by" right , so this should be correct , were there any
> errors in this ? Should I resend it ?
> 
> Regards,
> Srishti
> 

You should capitalize your name in both since you're doing that here.

Also I really think you can figure out how to fix your email headers so
you don't need to use a From header.  Lots of people use gmail and they
were able to figure it out.

But yeah, the way you sent it is also fine.

regards,
dan carpenter



From srishtishar at gmail.com  Fri May 19 12:56:39 2017
From: srishtishar at gmail.com (srishti sharma)
Date: Sat, 20 May 2017 01:26:39 +0530
Subject: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment
 coding style issue
In-Reply-To: <20170519193333.5sfsripy27k3xd7r@mwanda>
References: <1495104615-4752-1-git-send-email-srishtishar@gmail.com>
 <20170518135850.GA24513@kroah.com>
 <CAB3L5ozKAq7rj71UdK0GpRTmk72eSpAwXEgUFq4uKrfB8Hrs9g@mail.gmail.com>
 <20170519193333.5sfsripy27k3xd7r@mwanda>
Message-ID: <CAB3L5ox+h2HqFxv7SwF2BOSQSgOh10x5c--SeM=hzKE8wOOKzA@mail.gmail.com>

On Sat, May 20, 2017 at 1:03 AM, Dan Carpenter <dan.carpenter at oracle.com> wrote:
> On Sat, May 20, 2017 at 01:00:17AM +0530, srishti sharma wrote:
>> Was the format of this patch acceptable ,the "from" matches the
>> "signed-off-by" right , so this should be correct , were there any
>> errors in this ? Should I resend it ?
>>
>> Regards,
>> Srishti
>>
>
> You should capitalize your name in both since you're doing that here.
>
> Also I really think you can figure out how to fix your email headers so
> you don't need to use a From header.  Lots of people use gmail and they
> were able to figure it out.
>
> But yeah, the way you sent it is also fine.
>
> regards,
> dan carpenter
>


Okay , Thanks a lot !


From srishtishar at gmail.com  Fri May 19 13:30:24 2017
From: srishtishar at gmail.com (srishti sharma)
Date: Sat, 20 May 2017 02:00:24 +0530
Subject: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment coding
 style issue.
Message-ID: <1495225824-4422-1-git-send-email-srishtishar@gmail.com>

fixed a trailing */ issue .

Signed-off-by: srishti sharma <srishtishar at gmail.com>
---
 drivers/staging/bcm2835-audio/bcm2835-ctl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/bcm2835-ctl.c b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
index a4ffa1b..38fabab 100644
--- a/drivers/staging/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
@@ -247,8 +247,8 @@ static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol *kcontrol,
 	struct snd_ctl_elem_value *ucontrol)
 {
 	/* bcm2835 supports only consumer mode and sets all other format flags
-	 * automatically. So the only thing left is signalling non-audio
-	 * content */
+	 * automatically. So the only thing left is signalling non-audio content
+	 */
 	ucontrol->value.iec958.status[0] = IEC958_AES0_NONAUDIO;
 	return 0;
 }
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:21:58 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:21:58 +0200
Subject: [PATCH 01/16] staging: vchiq_core: Use return value of
 mutex_lock_killable directly
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-2-git-send-email-stefan.wahren@i2se.com>

Instead of saving the return value of mutex_lock_killable in a
local variable we could use the value directly.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 4f9e738..6b24651 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -1376,7 +1376,6 @@ resolve_bulks(VCHIQ_SERVICE_T *service, VCHIQ_BULK_QUEUE_T *queue)
 {
 	VCHIQ_STATE_T *state = service->state;
 	int resolved = 0;
-	int rc;
 
 	while ((queue->process != queue->local_insert) &&
 		(queue->process != queue->remote_insert)) {
@@ -1392,8 +1391,7 @@ resolve_bulks(VCHIQ_SERVICE_T *service, VCHIQ_BULK_QUEUE_T *queue)
 		WARN_ON(!((int)(queue->local_insert - queue->process) > 0));
 		WARN_ON(!((int)(queue->remote_insert - queue->process) > 0));
 
-		rc = mutex_lock_killable(&state->bulk_transfer_mutex);
-		if (rc != 0)
+		if (mutex_lock_killable(&state->bulk_transfer_mutex))
 			break;
 
 		vchiq_transfer_bulk(bulk);
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:05 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:05 +0200
Subject: [PATCH 08/16] staging: vchiq_2835_arm: Use PAGE_MASK macro
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-9-git-send-email-stefan.wahren@i2se.com>

Use the PAGE_MASK instead of open code it.

Signed-off-by: Stefan Wahren <stefa.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index eeeee1b..1fea2b6 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -474,7 +474,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
 	} else {
 		down_read(&task->mm->mmap_sem);
 		actual_pages = get_user_pages(
-				          (unsigned long)buf & ~(PAGE_SIZE - 1),
+					  (unsigned long)buf & PAGE_MASK,
 					  num_pages,
 					  (type == PAGELIST_READ) ? FOLL_WRITE : 0,
 					  pages,
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:21:59 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:21:59 +0200
Subject: [PATCH 02/16] staging: vchiq_2835_arm: Reduce scope of i in
 free_pagelist
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-3-git-send-email-stefan.wahren@i2se.com>

We can reduce the scope of the counting variable i. This has
been found by CppCheck.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index d04db3f..9105545 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -577,7 +577,6 @@ static void
 free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
 	      int actual)
 {
-	unsigned int i;
 	PAGELIST_T *pagelist   = pagelistinfo->pagelist;
 	struct page **pages    = pagelistinfo->pages;
 	unsigned int num_pages = pagelistinfo->num_pages;
@@ -633,6 +632,8 @@ free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
 	/* Need to mark all the pages dirty. */
 	if (pagelist->type != PAGELIST_WRITE &&
 	    pagelistinfo->pages_need_release) {
+		unsigned int i;
+
 		for (i = 0; i < num_pages; i++)
 			set_page_dirty(pages[i]);
 	}
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:04 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:04 +0200
Subject: [PATCH 07/16] staging: vchiq_2835_arm: Handle vmalloc_to_page error
 case
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-8-git-send-email-stefan.wahren@i2se.com>

In case vmalloc_to_page returns NULL create_pagelist must abort
immediately.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 8911e86..eeeee1b 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -459,6 +459,11 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
 								 PAGE_SIZE));
 			size_t bytes = PAGE_SIZE - off;
 
+			if (!pg) {
+				cleanup_pagelistinfo(pagelistinfo);
+				return NULL;
+			}
+
 			if (bytes > length)
 				bytes = length;
 			pages[actual_pages] = pg;
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:02 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:02 +0200
Subject: [PATCH 05/16] staging: vchiq_arm: Avoid multiline dereference
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-6-git-send-email-stefan.wahren@i2se.com>

Reduce the indentation within vchiq_dump_service_use_state in order
to avoid a multiline dereference.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 .../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c    | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 49d1ee2..030bec8 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -3276,12 +3276,12 @@ vchiq_dump_service_use_state(VCHIQ_STATE_T *state)
 		if (only_nonzero && !service_ptr->service_use_count)
 			continue;
 
-		if (service_ptr->srvstate != VCHIQ_SRVSTATE_FREE) {
-			service_data[j].fourcc = service_ptr->base.fourcc;
-			service_data[j].clientid = service_ptr->client_id;
-			service_data[j++].use_count = service_ptr->
-							service_use_count;
-		}
+		if (service_ptr->srvstate == VCHIQ_SRVSTATE_FREE)
+			continue;
+
+		service_data[j].fourcc = service_ptr->base.fourcc;
+		service_data[j].clientid = service_ptr->client_id;
+		service_data[j++].use_count = service_ptr->service_use_count;
 	}
 
 	read_unlock_bh(&arm_state->susp_res_lock);
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:00 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:00 +0200
Subject: [PATCH 03/16] staging: vchiq_2835_arm: Remove unnecessary assignment
 to slot_mem_size
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-4-git-send-email-stefan.wahren@i2se.com>

The variable slot_mem_size is assigned a value which is never used.
This issue has been found by CppCheck.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 9105545..9406d1c 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -153,7 +153,6 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
 		MAX_FRAGMENTS;
 
 	g_fragments_base = (char *)slot_mem + slot_mem_size;
-	slot_mem_size += frag_mem_size;
 
 	g_free_fragments = g_fragments_base;
 	for (i = 0; i < (MAX_FRAGMENTS - 1); i++) {
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:10 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:10 +0200
Subject: [PATCH 13/16] staging: vchiq_core: Bail out if ref_count is unexpected
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-14-git-send-email-stefan.wahren@i2se.com>

If the ref counter of service has an unexpected value then we better
bail out.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 .../vc04_services/interface/vchiq_arm/vchiq_core.c      | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index a84b4ef3..9cdc9857 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -175,7 +175,7 @@ find_service_by_handle(VCHIQ_SERVICE_HANDLE_T handle)
 	service = handle_to_service(handle);
 	if (service && (service->srvstate != VCHIQ_SRVSTATE_FREE) &&
 		(service->handle == handle)) {
-		BUG_ON(service->ref_count == 0);
+		WARN_ON(service->ref_count == 0);
 		service->ref_count++;
 	} else
 		service = NULL;
@@ -197,7 +197,7 @@ find_service_by_port(VCHIQ_STATE_T *state, int localport)
 		spin_lock(&service_spinlock);
 		service = state->services[localport];
 		if (service && (service->srvstate != VCHIQ_SRVSTATE_FREE)) {
-			BUG_ON(service->ref_count == 0);
+			WARN_ON(service->ref_count == 0);
 			service->ref_count++;
 		} else
 			service = NULL;
@@ -221,7 +221,7 @@ find_service_for_instance(VCHIQ_INSTANCE_T instance,
 	if (service && (service->srvstate != VCHIQ_SRVSTATE_FREE) &&
 		(service->handle == handle) &&
 		(service->instance == instance)) {
-		BUG_ON(service->ref_count == 0);
+		WARN_ON(service->ref_count == 0);
 		service->ref_count++;
 	} else
 		service = NULL;
@@ -246,7 +246,7 @@ find_closed_service_for_instance(VCHIQ_INSTANCE_T instance,
 		 (service->srvstate == VCHIQ_SRVSTATE_CLOSED)) &&
 		(service->handle == handle) &&
 		(service->instance == instance)) {
-		BUG_ON(service->ref_count == 0);
+		WARN_ON(service->ref_count == 0);
 		service->ref_count++;
 	} else
 		service = NULL;
@@ -273,7 +273,7 @@ next_service_by_instance(VCHIQ_STATE_T *state, VCHIQ_INSTANCE_T instance,
 		if (srv && (srv->srvstate != VCHIQ_SRVSTATE_FREE) &&
 			(srv->instance == instance)) {
 			service = srv;
-			BUG_ON(service->ref_count == 0);
+			WARN_ON(service->ref_count == 0);
 			service->ref_count++;
 			break;
 		}
@@ -291,7 +291,7 @@ lock_service(VCHIQ_SERVICE_T *service)
 	spin_lock(&service_spinlock);
 	WARN_ON(!service);
 	if (service) {
-		BUG_ON(service->ref_count == 0);
+		WARN_ON(service->ref_count == 0);
 		service->ref_count++;
 	}
 	spin_unlock(&service_spinlock);
@@ -305,7 +305,10 @@ unlock_service(VCHIQ_SERVICE_T *service)
 		WARN(1, "%s: service is NULL\n", __func__);
 		goto unlock;
 	}
-	BUG_ON(service->ref_count == 0);
+	if (!service->ref_count) {
+		WARN(1, "%s: ref_count is zero\n", __func__);
+		goto unlock;
+	}
 	service->ref_count--;
 	if (!service->ref_count) {
 		VCHIQ_STATE_T *state = service->state;
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:07 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:07 +0200
Subject: [PATCH 10/16] staging: vchiq_core: Bailout if VCHIQ state is already
 initialized
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-11-git-send-email-stefan.wahren@i2se.com>

In case VCHIQ state is already initialized we need to bailout
in order to aovid a memory leak.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index c47de96..0a46e15 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -2355,6 +2355,11 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero,
 		"%s: slot_zero = %pK, is_master = %d",
 		__func__, slot_zero, is_master);
 
+	if (vchiq_states[0]) {
+		pr_err("%s: VCHIQ state already initialized\n", __func__);
+		return VCHIQ_ERROR;
+	}
+
 	/* Check the input configuration */
 
 	if (slot_zero->magic != VCHIQ_MAGIC) {
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:01 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:01 +0200
Subject: [PATCH 04/16] staging: vchiq_arm: Fix variable names in comment
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-5-git-send-email-stefan.wahren@i2se.com>

This comment was apparently forgotten in the correction of CamelCase.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index e823f1d..49d1ee2 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -2070,7 +2070,7 @@ dump_phys_mem(void *virt_addr, u32 num_bytes)
 	struct page  **pages;
 	u8            *kmapped_virt_ptr;
 
-	/* Align virtAddr and endVirtAddr to 16 byte boundaries. */
+	/* Align virt_addr and end_virt_addr to 16 byte boundaries. */
 
 	virt_addr = (void *)((unsigned long)virt_addr & ~0x0fuL);
 	end_virt_addr = (void *)(((unsigned long)end_virt_addr + 15uL) &
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:11 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:11 +0200
Subject: [PATCH 14/16] staging: vchiq_core: Don't BUG if process is unexpected
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-15-git-send-email-stefan.wahren@i2se.com>

Bail out properly if the process index doesn't match the remote insert.
We also drop the BUG in case the process index is at local insert,
so we can trigger the WARN_ON again some steps later.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 .../staging/vc04_services/interface/vchiq_arm/vchiq_core.c    | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 9cdc9857..b0119b8 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -1963,9 +1963,14 @@ parse_rx_slots(VCHIQ_STATE_T *state)
 					mutex_unlock(&service->bulk_mutex);
 					break;
 				}
-
-				BUG_ON(queue->process == queue->local_insert);
-				BUG_ON(queue->process != queue->remote_insert);
+				if (queue->process != queue->remote_insert) {
+					pr_err("%s: p %x != ri %x\n",
+					       __func__,
+					       queue->process,
+					       queue->remote_insert);
+					mutex_unlock(&service->bulk_mutex);
+					goto bail_not_ready;
+				}
 
 				bulk = &queue->bulks[
 					BULK_INDEX(queue->remote_insert)];
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:03 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:03 +0200
Subject: [PATCH 06/16] staging: vchiq_2835_arm: Fix function name
 cleaup_pagelistinfo
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-7-git-send-email-stefan.wahren@i2se.com>

Assuming the intension of the function is to clean up, so fix the function
name accordingly.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 .../staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 9406d1c..8911e86 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -364,7 +364,7 @@ vchiq_doorbell_irq(int irq, void *dev_id)
 }
 
 static void
-cleaup_pagelistinfo(struct vchiq_pagelist_info *pagelistinfo)
+cleanup_pagelistinfo(struct vchiq_pagelist_info *pagelistinfo)
 {
 	if (pagelistinfo->scatterlist_mapped) {
 		dma_unmap_sg(g_dev, pagelistinfo->scatterlist,
@@ -488,7 +488,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
 				actual_pages--;
 				put_page(pages[actual_pages]);
 			}
-			cleaup_pagelistinfo(pagelistinfo);
+			cleanup_pagelistinfo(pagelistinfo);
 			return NULL;
 		}
 		 /* release user pages */
@@ -517,7 +517,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
 				 pagelistinfo->dma_dir);
 
 	if (dma_buffers == 0) {
-		cleaup_pagelistinfo(pagelistinfo);
+		cleanup_pagelistinfo(pagelistinfo);
 		return NULL;
 	}
 
@@ -554,7 +554,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
 		char *fragments;
 
 		if (down_interruptible(&g_free_fragments_sema) != 0) {
-			cleaup_pagelistinfo(pagelistinfo);
+			cleanup_pagelistinfo(pagelistinfo);
 			return NULL;
 		}
 
@@ -637,5 +637,5 @@ free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
 			set_page_dirty(pages[i]);
 	}
 
-	cleaup_pagelistinfo(pagelistinfo);
+	cleanup_pagelistinfo(pagelistinfo);
 }
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:09 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:09 +0200
Subject: [PATCH 12/16] staging: vchiq_core: Bail out if service is NULL
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-13-git-send-email-stefan.wahren@i2se.com>

In the unlikely case that service is NULL we should bail out instead
of calling BUG_ON(). The other BUG_ON calls will be fixed in separate
patches.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 .../vc04_services/interface/vchiq_arm/vchiq_core.c | 38 ++++++++++++++--------
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index d40366c..a84b4ef3 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -289,9 +289,11 @@ void
 lock_service(VCHIQ_SERVICE_T *service)
 {
 	spin_lock(&service_spinlock);
-	BUG_ON(!service || (service->ref_count == 0));
-	if (service)
+	WARN_ON(!service);
+	if (service) {
+		BUG_ON(service->ref_count == 0);
 		service->ref_count++;
+	}
 	spin_unlock(&service_spinlock);
 }
 
@@ -299,17 +301,21 @@ void
 unlock_service(VCHIQ_SERVICE_T *service)
 {
 	spin_lock(&service_spinlock);
-	BUG_ON(!service || (service->ref_count == 0));
-	if (service && service->ref_count) {
-		service->ref_count--;
-		if (!service->ref_count) {
-			VCHIQ_STATE_T *state = service->state;
-
-			BUG_ON(service->srvstate != VCHIQ_SRVSTATE_FREE);
-			state->services[service->localport] = NULL;
-		} else
-			service = NULL;
+	if (!service) {
+		WARN(1, "%s: service is NULL\n", __func__);
+		goto unlock;
 	}
+	BUG_ON(service->ref_count == 0);
+	service->ref_count--;
+	if (!service->ref_count) {
+		VCHIQ_STATE_T *state = service->state;
+
+		BUG_ON(service->srvstate != VCHIQ_SRVSTATE_FREE);
+		state->services[service->localport] = NULL;
+	} else {
+		service = NULL;
+	}
+unlock:
 	spin_unlock(&service_spinlock);
 
 	if (service && service->userdata_term)
@@ -822,7 +828,12 @@ queue_message(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service,
 	if (type == VCHIQ_MSG_DATA) {
 		int tx_end_index;
 
-		BUG_ON(!service);
+		if (!service) {
+			WARN(1, "%s: service is NULL\n", __func__);
+			mutex_unlock(&state->slot_mutex);
+			return VCHIQ_ERROR;
+		}
+
 		BUG_ON((flags & (QMFLAGS_NO_MUTEX_LOCK |
 				 QMFLAGS_NO_MUTEX_UNLOCK)) != 0);
 
@@ -923,7 +934,6 @@ queue_message(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service,
 			header, size, VCHIQ_MSG_SRCPORT(msgid),
 			VCHIQ_MSG_DSTPORT(msgid));
 
-		BUG_ON(!service);
 		BUG_ON((flags & (QMFLAGS_NO_MUTEX_LOCK |
 				 QMFLAGS_NO_MUTEX_UNLOCK)) != 0);
 
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:21:57 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:21:57 +0200
Subject: [PATCH 00/16] staging: vchiq_arm: several cleanups
Message-ID: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>

This patch series addresses mostly minor issues. It based on top of
the latest vchiq bugfix [1].

[1] - https://lkml.org/lkml/2017/5/4/228

Stefan Wahren (16):
  staging: vchiq_core: Use return value of mutex_lock_killable directly
  staging: vchiq_2835_arm: Reduce scope of i in free_pagelist
  staging: vchiq_2835_arm: Remove unnecessary assignment to
    slot_mem_size
  staging: vchiq_arm: Fix variable names in comment
  staging: vchiq_arm: Avoid multiline dereference
  staging: vchiq_2835_arm: Fix function name cleaup_pagelistinfo
  staging: vchiq_2835_arm: Handle vmalloc_to_page error case
  staging: vchiq_2835_arm: Use PAGE_MASK macro
  staging: vchiq_core: Simplify VCHIQ init
  staging: vchiq_core: Bailout if VCHIQ state is already initialized
  staging: vchiq_core: Don't BUG if sending RESUME fails
  staging: vchiq_core: Bail out if service is NULL
  staging: vchiq_core: Bail out if ref_count is unexpected
  staging: vchiq_core: Don't BUG if process is unexpected
  staging: vchiq_core: Bail out in case of invalid tx_pos
  staging: vchiq_core: Replace remaining BUG_ON with WARN_ON

 .../interface/vchiq_arm/vchiq_2835_arm.c           | 21 +++--
 .../vc04_services/interface/vchiq_arm/vchiq_arm.c  | 14 ++--
 .../vc04_services/interface/vchiq_arm/vchiq_core.c | 95 +++++++++++++---------
 3 files changed, 77 insertions(+), 53 deletions(-)

-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:06 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:06 +0200
Subject: [PATCH 09/16] staging: vchiq_core: Simplify VCHIQ init
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-10-git-send-email-stefan.wahren@i2se.com>

Since the ARM side of VCHIQ support only 1 state, we could simplify
the init code. This makes it possible to avoid BUG_ON and a theoretical
overflow of id.

Signed-off-by: Stefan Wahren <stefan at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 6b24651..c47de96 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -2349,7 +2349,6 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero,
 	VCHIQ_SHARED_STATE_T *remote;
 	VCHIQ_STATUS_T status;
 	char threadname[16];
-	static int id;
 	int i;
 
 	vchiq_log_warning(vchiq_core_log_level,
@@ -2437,7 +2436,6 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero,
 
 	memset(state, 0, sizeof(VCHIQ_STATE_T));
 
-	state->id = id++;
 	state->is_master = is_master;
 
 	/*
@@ -2556,8 +2554,7 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero,
 	set_user_nice(state->sync_thread, -20);
 	wake_up_process(state->sync_thread);
 
-	BUG_ON(state->id >= VCHIQ_MAX_STATES);
-	vchiq_states[state->id] = state;
+	vchiq_states[0] = state;
 
 	/* Indicate readiness to the other side */
 	local->initialised = 1;
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:12 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:12 +0200
Subject: [PATCH 15/16] staging: vchiq_core: Bail out in case of invalid tx_pos
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-16-git-send-email-stefan.wahren@i2se.com>

Properly handle the error case in case of an invalid tx_pos.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index b0119b8..c61f5ac 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -600,8 +600,10 @@ reserve_space(VCHIQ_STATE_T *state, size_t space, int is_blocking)
 				return NULL; /* No space available */
 		}
 
-		BUG_ON(tx_pos ==
-			(state->slot_queue_available * VCHIQ_SLOT_SIZE));
+		if (tx_pos == (state->slot_queue_available * VCHIQ_SLOT_SIZE)) {
+			pr_warn("%s: invalid tx_pos: %d\n", __func__, tx_pos);
+			return NULL;
+		}
 
 		slot_index = local->slot_queue[
 			SLOT_QUEUE_INDEX_FROM_POS(tx_pos) &
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:13 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:13 +0200
Subject: [PATCH 16/16] staging: vchiq_core: Replace remaining BUG_ON with
 WARN_ON
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-17-git-send-email-stefan.wahren@i2se.com>

This replaces all remaining BUG_ON with WARN_ON. So in case of
a VCHIQ bug the system is still usable.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 .../staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index c61f5ac..486be99 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -313,7 +313,7 @@ unlock_service(VCHIQ_SERVICE_T *service)
 	if (!service->ref_count) {
 		VCHIQ_STATE_T *state = service->state;
 
-		BUG_ON(service->srvstate != VCHIQ_SRVSTATE_FREE);
+		WARN_ON(service->srvstate != VCHIQ_SRVSTATE_FREE);
 		state->services[service->localport] = NULL;
 	} else {
 		service = NULL;
@@ -839,8 +839,8 @@ queue_message(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service,
 			return VCHIQ_ERROR;
 		}
 
-		BUG_ON((flags & (QMFLAGS_NO_MUTEX_LOCK |
-				 QMFLAGS_NO_MUTEX_UNLOCK)) != 0);
+		WARN_ON((flags & (QMFLAGS_NO_MUTEX_LOCK |
+				  QMFLAGS_NO_MUTEX_UNLOCK)) != 0);
 
 		if (service->closing) {
 			/* The service has been closed */
@@ -939,8 +939,8 @@ queue_message(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service,
 			header, size, VCHIQ_MSG_SRCPORT(msgid),
 			VCHIQ_MSG_DSTPORT(msgid));
 
-		BUG_ON((flags & (QMFLAGS_NO_MUTEX_LOCK |
-				 QMFLAGS_NO_MUTEX_UNLOCK)) != 0);
+		WARN_ON((flags & (QMFLAGS_NO_MUTEX_LOCK |
+				  QMFLAGS_NO_MUTEX_UNLOCK)) != 0);
 
 		callback_result =
 			copy_message_data(copy_callback, context,
@@ -3204,7 +3204,7 @@ vchiq_close_service(VCHIQ_SERVICE_HANDLE_T handle)
 	if (current == service->state->slot_handler_thread) {
 		status = vchiq_close_service_internal(service,
 			0/*!close_recvd*/);
-		BUG_ON(status == VCHIQ_RETRY);
+		WARN_ON(status == VCHIQ_RETRY);
 	} else {
 	/* Mark the service for termination by the slot handler */
 		request_poll(service->state, service, VCHIQ_POLL_TERMINATE);
@@ -3266,7 +3266,7 @@ vchiq_remove_service(VCHIQ_SERVICE_HANDLE_T handle)
 
 		status = vchiq_close_service_internal(service,
 			0/*!close_recvd*/);
-		BUG_ON(status == VCHIQ_RETRY);
+		WARN_ON(status == VCHIQ_RETRY);
 	} else {
 		/* Mark the service for removal by the slot handler */
 		request_poll(service->state, service, VCHIQ_POLL_REMOVE);
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 05:22:08 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 14:22:08 +0200
Subject: [PATCH 11/16] staging: vchiq_core: Don't BUG if sending RESUME fails
In-Reply-To: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495282933-13271-12-git-send-email-stefan.wahren@i2se.com>

VCHIQ suspend and resume isn't implemented, but even it was
there is no need to call BUG().

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 0a46e15..d40366c 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -2137,7 +2137,6 @@ slot_handler_func(void *v)
 					vchiq_log_error(vchiq_core_log_level,
 						"Failed to send RESUME "
 						"message");
-					BUG();
 				}
 				break;
 
-- 
2.7.4



From stefan.wahren at i2se.com  Sat May 20 14:29:09 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 23:29:09 +0200 (CEST)
Subject: [PATCH 08/16] staging: vchiq_2835_arm: Use PAGE_MASK macro
In-Reply-To: <1495282933-13271-9-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
 <1495282933-13271-9-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1021565313.673167.1495315749123@email.1und1.de>


> Stefan Wahren <stefan.wahren at i2se.com> hat am 20. Mai 2017 um 14:22 geschrieben:
> 
> 
> Use the PAGE_MASK instead of open code it.
> 
> Signed-off-by: Stefan Wahren <stefa.wahren at i2se.com>

Sorry, for the typo in the mail address.


From stefan.wahren at i2se.com  Sat May 20 14:30:33 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 20 May 2017 23:30:33 +0200 (CEST)
Subject: [PATCH 09/16] staging: vchiq_core: Simplify VCHIQ init
In-Reply-To: <1495282933-13271-10-git-send-email-stefan.wahren@i2se.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
 <1495282933-13271-10-git-send-email-stefan.wahren@i2se.com>
Message-ID: <771147548.673176.1495315833864@email.1und1.de>


> Stefan Wahren <stefan.wahren at i2se.com> hat am 20. Mai 2017 um 14:22 geschrieben:
> 
> 
> Since the ARM side of VCHIQ support only 1 state, we could simplify
> the init code. This makes it possible to avoid BUG_ON and a theoretical
> overflow of id.
> 
> Signed-off-by: Stefan Wahren <stefan at i2se.com>

It should be

Stefan Wahren <stefan.wahren at i2se.com>


From stefan.wahren at i2se.com  Sun May 21 09:44:38 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sun, 21 May 2017 18:44:38 +0200
Subject: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero: Enable OTG mode
In-Reply-To: <1495385079-3697-1-git-send-email-stefan.wahren@i2se.com>
References: <1495385079-3697-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495385079-3697-4-git-send-email-stefan.wahren@i2se.com>

Since 635c21068cf ("usb: dwc2: gadget: Fix WARN_ON messages
during FIFO init") the dwc2 driver is able to handle OTG and gadget
mode for bcm2835. So enable this feature for the Raspberry Pi Zero.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 arch/arm/boot/dts/bcm2835-rpi-zero.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero.dts b/arch/arm/boot/dts/bcm2835-rpi-zero.dts
index cc8b832..79a20d5 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-zero.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-zero.dts
@@ -12,7 +12,7 @@
 /dts-v1/;
 #include "bcm2835.dtsi"
 #include "bcm2835-rpi.dtsi"
-#include "bcm283x-rpi-usb-host.dtsi"
+#include "bcm283x-rpi-usb-otg.dtsi"
 
 / {
 	compatible = "raspberrypi,model-zero", "brcm,bcm2835";
-- 
2.7.4



From stefan.wahren at i2se.com  Sun May 21 09:44:36 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sun, 21 May 2017 18:44:36 +0200
Subject: [PATCH 1/4] ARM: dts: bcm283x: Add dtsi for OTG mode
In-Reply-To: <1495385079-3697-1-git-send-email-stefan.wahren@i2se.com>
References: <1495385079-3697-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495385079-3697-2-git-send-email-stefan.wahren@i2se.com>

The Raspberry Pi Zero also supports OTG mode. So provide a dtsi file
to configure the USB interface accordingly. The fifo sizes are optimized
for device endpoint 6 and 7 with the maximum of 768.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 arch/arm/boot/dts/bcm283x-rpi-usb-otg.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm283x-rpi-usb-otg.dtsi

diff --git a/arch/arm/boot/dts/bcm283x-rpi-usb-otg.dtsi b/arch/arm/boot/dts/bcm283x-rpi-usb-otg.dtsi
new file mode 100644
index 0000000..e7d217c
--- /dev/null
+++ b/arch/arm/boot/dts/bcm283x-rpi-usb-otg.dtsi
@@ -0,0 +1,10 @@
+&usb {
+	dr_mode = "otg";
+	g-rx-fifo-size = <256>;
+	g-np-tx-fifo-size = <32>;
+	/*
+	 * According to dwc2 the sum of all device EP
+	 * fifo sizes shouldn't exceed 3776 bytes.
+	 */
+	g-tx-fifo-size = <256 256 512 512 512 768 768>;
+};
-- 
2.7.4



From stefan.wahren at i2se.com  Sun May 21 09:44:39 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sun, 21 May 2017 18:44:39 +0200
Subject: [PATCH 4/4] ARM: bcm2835_defconfig: Enable serial & ethernet USB
 gadget support
In-Reply-To: <1495385079-3697-1-git-send-email-stefan.wahren@i2se.com>
References: <1495385079-3697-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495385079-3697-5-git-send-email-stefan.wahren@i2se.com>

In order to use the serial and ethernet USB gadget support on
Raspberry Zero, we also need to enable the PHY driver, kernel module
and OTG support.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 arch/arm/configs/bcm2835_defconfig | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 3ba8cd3..3ee9d78 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -24,6 +24,8 @@ CONFIG_PROFILING=y
 CONFIG_OPROFILE=y
 CONFIG_JUMP_LABEL=y
 CONFIG_CC_STACKPROTECTOR_REGULAR=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
 CONFIG_ARCH_MULTI_V6=y
 CONFIG_ARCH_BCM=y
 CONFIG_ARCH_BCM2835=y
@@ -86,8 +88,14 @@ CONFIG_SND=y
 CONFIG_SND_SOC=y
 CONFIG_SND_BCM2835_SOC_I2S=y
 CONFIG_USB=y
+CONFIG_USB_OTG=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_DWC2=y
+CONFIG_NOP_USB_XCEIV=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_ETH=m
+CONFIG_USB_ETH_EEM=y
+CONFIG_USB_G_SERIAL=m
 CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
-- 
2.7.4



From stefan.wahren at i2se.com  Sun May 21 09:44:37 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sun, 21 May 2017 18:44:37 +0200
Subject: [PATCH 2/4] ARM: dts: bcm283x: Add generic USB PHY
In-Reply-To: <1495385079-3697-1-git-send-email-stefan.wahren@i2se.com>
References: <1495385079-3697-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495385079-3697-3-git-send-email-stefan.wahren@i2se.com>

In order to use dwc2 in OTG or gadget mode the USB PHY should be
specified. Since there is no bcm283x USB PHY driver use the generic
one.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
Acked-by: Stephen Warren <swarren at nvidia.com>
---
 arch/arm/boot/dts/bcm283x.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 86a5db5..9a05cde 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -589,6 +589,8 @@
 			#size-cells = <0>;
 			clocks = <&clk_usb>;
 			clock-names = "otg";
+			phys = <&usbphy>;
+			phy-names = "usb2-phy";
 		};
 
 		v3d: v3d at 7ec00000 {
@@ -624,4 +626,8 @@
 			clock-frequency = <480000000>;
 		};
 	};
+
+	usbphy: phy {
+		compatible = "usb-nop-xceiv";
+	};
 };
-- 
2.7.4



From stefan.wahren at i2se.com  Sun May 21 09:44:35 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sun, 21 May 2017 18:44:35 +0200
Subject: [PATCH 0/4] ARM: dts: bcm2835-rpi-zero: Enable OTG mode
Message-ID: <1495385079-3697-1-git-send-email-stefan.wahren@i2se.com>

This patch series enable OTG mode for Raspberry Pi Zero because dwc2 driver
has been fixed now.

Patch 1 adds a new dtsi file to setup OTG mode (could also be used for boards
like RPi Zero W or the Compute Module). The second patch adds the USB PHY and
was part of Raspberry Pi Zero support patch series before split up [1].
The enabling of OTG mode of RPi Zero is done by patch number 3. The last patch
updates the BCM2835 defconfig.

[1] - http://lists.infradead.org/pipermail/linux-rpi-kernel/2016-July/004153.html

Stefan Wahren (4):
  ARM: dts: bcm283x: Add dtsi for OTG mode
  ARM: dts: bcm283x: Add generic USB PHY
  ARM: dts: bcm2835-rpi-zero: Enable OTG mode
  ARM: bcm2835_defconfig: Enable serial & ethernet USB gadget support

 arch/arm/boot/dts/bcm2835-rpi-zero.dts     |  2 +-
 arch/arm/boot/dts/bcm283x-rpi-usb-otg.dtsi | 10 ++++++++++
 arch/arm/boot/dts/bcm283x.dtsi             |  6 ++++++
 arch/arm/configs/bcm2835_defconfig         |  8 ++++++++
 4 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/bcm283x-rpi-usb-otg.dtsi

-- 
2.7.4



From tiwai at suse.de  Sun May 21 12:02:51 2017
From: tiwai at suse.de (Takashi Iwai)
Date: Sun, 21 May 2017 21:02:51 +0200
Subject: [PATCH 0/7] ALSA: Fix/improve PCM ack callback
Message-ID: <20170521190258.1178-1-tiwai@suse.de>

Hi,

this is a series of patches to fix the potential bugs in PCM ack
callback using the pcm-indirect helper functions, and also to enhance
the ack callback to be called properly in all appl_ptr updates, as
similarly done by Pierre and Subhransu's patches.

The changes in the pcm-indirect helper code and its users are fairly
trivial, just passing the error code back.

ARM/R-Pi people are Cc'ed because of bcm2835-audio driver.


Takashi

===

Takashi Iwai (7):
  ALSA: pcm: Fix negative appl_ptr handling in pcm-indirect helpers
  ALSA: mips: Deliver indirect-PCM transfer error
  ALSA: cs46xx: Deliver indirect-PCM transfer error
  ALSA: emu10k1: Deliver indirect-PCM transfer error
  ALSA: rme32: Deliver indirect-PCM transfer error
  staging: bcm2835-audio: Deliver indirect-PCM transfer error
  ALSA: pcm: Call ack() whenever appl_ptr is updated

 .../vc04_services/bcm2835-audio/bcm2835-pcm.c      |  5 +--
 include/sound/pcm-indirect.h                       | 10 ++++-
 sound/core/pcm_native.c                            | 46 +++++++++++++++++-----
 sound/mips/hal2.c                                  | 14 +++----
 sound/pci/cs46xx/cs46xx_lib.c                      |  8 ++--
 sound/pci/emu10k1/emupcm.c                         |  4 +-
 sound/pci/rme32.c                                  | 10 ++---
 7 files changed, 63 insertions(+), 34 deletions(-)

-- 
2.13.0



From tiwai at suse.de  Sun May 21 12:02:55 2017
From: tiwai at suse.de (Takashi Iwai)
Date: Sun, 21 May 2017 21:02:55 +0200
Subject: [PATCH 4/7] ALSA: emu10k1: Deliver indirect-PCM transfer error
In-Reply-To: <20170521190258.1178-1-tiwai@suse.de>
References: <20170521190258.1178-1-tiwai@suse.de>
Message-ID: <20170521190258.1178-5-tiwai@suse.de>

Now that the indirect-PCM transfer helper gives back an error, we
should return the error from ack callbacks.

Signed-off-by: Takashi Iwai <tiwai at suse.de>
---
 sound/pci/emu10k1/emupcm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/pci/emu10k1/emupcm.c b/sound/pci/emu10k1/emupcm.c
index ef1cf530c929..bdda29f335f6 100644
--- a/sound/pci/emu10k1/emupcm.c
+++ b/sound/pci/emu10k1/emupcm.c
@@ -1632,8 +1632,8 @@ static int snd_emu10k1_fx8010_playback_transfer(struct snd_pcm_substream *substr
 	struct snd_emu10k1 *emu = snd_pcm_substream_chip(substream);
 	struct snd_emu10k1_fx8010_pcm *pcm = &emu->fx8010.pcm[substream->number];
 
-	snd_pcm_indirect_playback_transfer(substream, &pcm->pcm_rec, fx8010_pb_trans_copy);
-	return 0;
+	return snd_pcm_indirect_playback_transfer(substream, &pcm->pcm_rec,
+						  fx8010_pb_trans_copy);
 }
 
 static int snd_emu10k1_fx8010_playback_hw_params(struct snd_pcm_substream *substream,
-- 
2.13.0



From tiwai at suse.de  Sun May 21 12:02:53 2017
From: tiwai at suse.de (Takashi Iwai)
Date: Sun, 21 May 2017 21:02:53 +0200
Subject: [PATCH 2/7] ALSA: mips: Deliver indirect-PCM transfer error
In-Reply-To: <20170521190258.1178-1-tiwai@suse.de>
References: <20170521190258.1178-1-tiwai@suse.de>
Message-ID: <20170521190258.1178-3-tiwai@suse.de>

Now that the indirect-PCM transfer helper gives back an error, we
should return the error from ack callbacks.

Signed-off-by: Takashi Iwai <tiwai at suse.de>
---
 sound/mips/hal2.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/sound/mips/hal2.c b/sound/mips/hal2.c
index 00fc9241d266..684dc4ddef41 100644
--- a/sound/mips/hal2.c
+++ b/sound/mips/hal2.c
@@ -616,10 +616,9 @@ static int hal2_playback_ack(struct snd_pcm_substream *substream)
 	struct hal2_codec *dac = &hal2->dac;
 
 	dac->pcm_indirect.hw_queue_size = H2_BUF_SIZE / 2;
-	snd_pcm_indirect_playback_transfer(substream,
-					   &dac->pcm_indirect,
-					   hal2_playback_transfer);
-	return 0;
+	return snd_pcm_indirect_playback_transfer(substream,
+						  &dac->pcm_indirect,
+						  hal2_playback_transfer);
 }
 
 static int hal2_capture_open(struct snd_pcm_substream *substream)
@@ -707,10 +706,9 @@ static int hal2_capture_ack(struct snd_pcm_substream *substream)
 	struct snd_hal2 *hal2 = snd_pcm_substream_chip(substream);
 	struct hal2_codec *adc = &hal2->adc;
 
-	snd_pcm_indirect_capture_transfer(substream,
-					  &adc->pcm_indirect,
-					  hal2_capture_transfer);
-	return 0;
+	return snd_pcm_indirect_capture_transfer(substream,
+						 &adc->pcm_indirect,
+						 hal2_capture_transfer);
 }
 
 static struct snd_pcm_ops hal2_playback_ops = {
-- 
2.13.0



From tiwai at suse.de  Sun May 21 12:02:52 2017
From: tiwai at suse.de (Takashi Iwai)
Date: Sun, 21 May 2017 21:02:52 +0200
Subject: [PATCH 1/7] ALSA: pcm: Fix negative appl_ptr handling in pcm-indirect
 helpers
In-Reply-To: <20170521190258.1178-1-tiwai@suse.de>
References: <20170521190258.1178-1-tiwai@suse.de>
Message-ID: <20170521190258.1178-2-tiwai@suse.de>

The indirect-PCM helper codes have an implicit assumption that the
appl_ptr always increases.  But the PCM core may deal with the
decrement of appl_ptr via rewind ioctls, and it may screw up the
buffer pointer management.

This patch adds the negative appl_ptr diff in transfer functions and
let returning an error instead of always accepting the appl_ptr
updates.  The callers are usually PCM ack callbacks, and they pass the
error to the upper layer accordingly.

Signed-off-by: Takashi Iwai <tiwai at suse.de>
---
 include/sound/pcm-indirect.h | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/sound/pcm-indirect.h b/include/sound/pcm-indirect.h
index 1df7acaaa535..7ade285328cf 100644
--- a/include/sound/pcm-indirect.h
+++ b/include/sound/pcm-indirect.h
@@ -43,7 +43,7 @@ typedef void (*snd_pcm_indirect_copy_t)(struct snd_pcm_substream *substream,
 /*
  * helper function for playback ack callback
  */
-static inline void
+static inline int
 snd_pcm_indirect_playback_transfer(struct snd_pcm_substream *substream,
 				   struct snd_pcm_indirect *rec,
 				   snd_pcm_indirect_copy_t copy)
@@ -56,6 +56,8 @@ snd_pcm_indirect_playback_transfer(struct snd_pcm_substream *substream,
 	if (diff) {
 		if (diff < -(snd_pcm_sframes_t) (runtime->boundary / 2))
 			diff += runtime->boundary;
+		if (diff < 0)
+			return -EINVAL;
 		rec->sw_ready += (int)frames_to_bytes(runtime, diff);
 		rec->appl_ptr = appl_ptr;
 	}
@@ -82,6 +84,7 @@ snd_pcm_indirect_playback_transfer(struct snd_pcm_substream *substream,
 		rec->hw_ready += bytes;
 		rec->sw_ready -= bytes;
 	}
+	return 0;
 }
 
 /*
@@ -109,7 +112,7 @@ snd_pcm_indirect_playback_pointer(struct snd_pcm_substream *substream,
 /*
  * helper function for capture ack callback
  */
-static inline void
+static inline int
 snd_pcm_indirect_capture_transfer(struct snd_pcm_substream *substream,
 				  struct snd_pcm_indirect *rec,
 				  snd_pcm_indirect_copy_t copy)
@@ -121,6 +124,8 @@ snd_pcm_indirect_capture_transfer(struct snd_pcm_substream *substream,
 	if (diff) {
 		if (diff < -(snd_pcm_sframes_t) (runtime->boundary / 2))
 			diff += runtime->boundary;
+		if (diff < 0)
+			return -EINVAL;
 		rec->sw_ready -= frames_to_bytes(runtime, diff);
 		rec->appl_ptr = appl_ptr;
 	}
@@ -147,6 +152,7 @@ snd_pcm_indirect_capture_transfer(struct snd_pcm_substream *substream,
 		rec->hw_ready -= bytes;
 		rec->sw_ready += bytes;
 	}
+	return 0;
 }
 
 /*
-- 
2.13.0



From tiwai at suse.de  Sun May 21 12:02:54 2017
From: tiwai at suse.de (Takashi Iwai)
Date: Sun, 21 May 2017 21:02:54 +0200
Subject: [PATCH 3/7] ALSA: cs46xx: Deliver indirect-PCM transfer error
In-Reply-To: <20170521190258.1178-1-tiwai@suse.de>
References: <20170521190258.1178-1-tiwai@suse.de>
Message-ID: <20170521190258.1178-4-tiwai@suse.de>

Now that the indirect-PCM transfer helper gives back an error, we
should return the error from ack callbacks.

Signed-off-by: Takashi Iwai <tiwai at suse.de>
---
 sound/pci/cs46xx/cs46xx_lib.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/pci/cs46xx/cs46xx_lib.c b/sound/pci/cs46xx/cs46xx_lib.c
index 00fa52e9a2f2..ae2aad52ea6f 100644
--- a/sound/pci/cs46xx/cs46xx_lib.c
+++ b/sound/pci/cs46xx/cs46xx_lib.c
@@ -887,8 +887,8 @@ static int snd_cs46xx_playback_transfer(struct snd_pcm_substream *substream)
 {
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	struct snd_cs46xx_pcm * cpcm = runtime->private_data;
-	snd_pcm_indirect_playback_transfer(substream, &cpcm->pcm_rec, snd_cs46xx_pb_trans_copy);
-	return 0;
+	return snd_pcm_indirect_playback_transfer(substream, &cpcm->pcm_rec,
+						  snd_cs46xx_pb_trans_copy);
 }
 
 static void snd_cs46xx_cp_trans_copy(struct snd_pcm_substream *substream,
@@ -903,8 +903,8 @@ static void snd_cs46xx_cp_trans_copy(struct snd_pcm_substream *substream,
 static int snd_cs46xx_capture_transfer(struct snd_pcm_substream *substream)
 {
 	struct snd_cs46xx *chip = snd_pcm_substream_chip(substream);
-	snd_pcm_indirect_capture_transfer(substream, &chip->capt.pcm_rec, snd_cs46xx_cp_trans_copy);
-	return 0;
+	return snd_pcm_indirect_capture_transfer(substream, &chip->capt.pcm_rec,
+						 snd_cs46xx_cp_trans_copy);
 }
 
 static snd_pcm_uframes_t snd_cs46xx_playback_direct_pointer(struct snd_pcm_substream *substream)
-- 
2.13.0



From tiwai at suse.de  Sun May 21 12:02:56 2017
From: tiwai at suse.de (Takashi Iwai)
Date: Sun, 21 May 2017 21:02:56 +0200
Subject: [PATCH 5/7] ALSA: rme32: Deliver indirect-PCM transfer error
In-Reply-To: <20170521190258.1178-1-tiwai@suse.de>
References: <20170521190258.1178-1-tiwai@suse.de>
Message-ID: <20170521190258.1178-6-tiwai@suse.de>

Now that the indirect-PCM transfer helper gives back an error, we
should return the error from ack callbacks.

Signed-off-by: Takashi Iwai <tiwai at suse.de>
---
 sound/pci/rme32.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/sound/pci/rme32.c b/sound/pci/rme32.c
index 96d15db65dfd..f9b424056d0f 100644
--- a/sound/pci/rme32.c
+++ b/sound/pci/rme32.c
@@ -1157,9 +1157,8 @@ static int snd_rme32_playback_fd_ack(struct snd_pcm_substream *substream)
 	if (rme32->running & (1 << SNDRV_PCM_STREAM_CAPTURE))
 		rec->hw_queue_size -= cprec->hw_ready;
 	spin_unlock(&rme32->lock);
-	snd_pcm_indirect_playback_transfer(substream, rec,
-					   snd_rme32_pb_trans_copy);
-	return 0;
+	return snd_pcm_indirect_playback_transfer(substream, rec,
+						  snd_rme32_pb_trans_copy);
 }
 
 static void snd_rme32_cp_trans_copy(struct snd_pcm_substream *substream,
@@ -1174,9 +1173,8 @@ static void snd_rme32_cp_trans_copy(struct snd_pcm_substream *substream,
 static int snd_rme32_capture_fd_ack(struct snd_pcm_substream *substream)
 {
 	struct rme32 *rme32 = snd_pcm_substream_chip(substream);
-	snd_pcm_indirect_capture_transfer(substream, &rme32->capture_pcm,
-					  snd_rme32_cp_trans_copy);
-	return 0;
+	return snd_pcm_indirect_capture_transfer(substream, &rme32->capture_pcm,
+						 snd_rme32_cp_trans_copy);
 }
 
 static snd_pcm_uframes_t
-- 
2.13.0



From tiwai at suse.de  Sun May 21 12:02:57 2017
From: tiwai at suse.de (Takashi Iwai)
Date: Sun, 21 May 2017 21:02:57 +0200
Subject: [PATCH 6/7] staging: bcm2835-audio: Deliver indirect-PCM transfer
 error
In-Reply-To: <20170521190258.1178-1-tiwai@suse.de>
References: <20170521190258.1178-1-tiwai@suse.de>
Message-ID: <20170521190258.1178-7-tiwai@suse.de>

Now that the indirect-PCM transfer helper gives back an error, we
should return the error from ack callbacks.

Signed-off-by: Takashi Iwai <tiwai at suse.de>
---
 drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
index e8cf0b97bf02..3637ddf909a4 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
@@ -353,9 +353,8 @@ static int snd_bcm2835_pcm_ack(struct snd_pcm_substream *substream)
 	struct snd_pcm_indirect *pcm_indirect = &alsa_stream->pcm_indirect;
 
 	pcm_indirect->hw_queue_size = runtime->hw.buffer_bytes_max;
-	snd_pcm_indirect_playback_transfer(substream, pcm_indirect,
-					   snd_bcm2835_pcm_transfer);
-	return 0;
+	return snd_pcm_indirect_playback_transfer(substream, pcm_indirect,
+						  snd_bcm2835_pcm_transfer);
 }
 
 /* trigger callback */
-- 
2.13.0



From tiwai at suse.de  Sun May 21 12:02:58 2017
From: tiwai at suse.de (Takashi Iwai)
Date: Sun, 21 May 2017 21:02:58 +0200
Subject: [PATCH 7/7] ALSA: pcm: Call ack() whenever appl_ptr is updated
In-Reply-To: <20170521190258.1178-1-tiwai@suse.de>
References: <20170521190258.1178-1-tiwai@suse.de>
Message-ID: <20170521190258.1178-8-tiwai@suse.de>

Although the ack callback is supposed to be called at each appl_ptr or
hw_ptr update, we missed a few opportunities: namely, forward, rewind
and sync_ptr.

Formerly calling ack at rewind may have leaded to unexpected results
due to the forgotten negative appl_ptr update in indirect-PCM helper,
which is the major user of the PCM ack callback.  But now we fixed
this oversights, thus we can call ack callback safely even at rewind
callback -- of course with the proper handling of the error from the
callback.

This patch adds the calls of ack callback in the places mentioned in
the above.

Signed-off-by: Takashi Iwai <tiwai at suse.de>
---
 sound/core/pcm_native.c | 46 +++++++++++++++++++++++++++++++++++++---------
 1 file changed, 37 insertions(+), 9 deletions(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index ecde57afa45a..7bc4a0bbad6f 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -2455,13 +2455,35 @@ static int do_pcm_hwsync(struct snd_pcm_substream *substream)
 	}
 }
 
-/* increase the appl_ptr; returns the processed frames */
+/* update to the given appl_ptr and call ack callback if needed;
+ * when an error is returned, take back to the original value
+ */
+static int apply_appl_ptr(struct snd_pcm_substream *substream,
+			  snd_pcm_uframes_t appl_ptr)
+{
+	struct snd_pcm_runtime *runtime = substream->runtime;
+	snd_pcm_uframes_t old_appl_ptr = runtime->control->appl_ptr;
+	int ret;
+
+	runtime->control->appl_ptr = appl_ptr;
+	if (substream->ops->ack) {
+		ret = substream->ops->ack(substream);
+		if (ret < 0) {
+			runtime->control->appl_ptr = old_appl_ptr;
+			return ret;
+		}
+	}
+	return 0;
+}
+
+/* increase the appl_ptr; returns the processed frames or a negative error */
 static snd_pcm_sframes_t forward_appl_ptr(struct snd_pcm_substream *substream,
 					  snd_pcm_uframes_t frames,
 					   snd_pcm_sframes_t avail)
 {
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	snd_pcm_sframes_t appl_ptr;
+	int ret;
 
 	if (avail <= 0)
 		return 0;
@@ -2470,17 +2492,18 @@ static snd_pcm_sframes_t forward_appl_ptr(struct snd_pcm_substream *substream,
 	appl_ptr = runtime->control->appl_ptr + frames;
 	if (appl_ptr >= (snd_pcm_sframes_t)runtime->boundary)
 		appl_ptr -= runtime->boundary;
-	runtime->control->appl_ptr = appl_ptr;
-	return frames;
+	ret = apply_appl_ptr(substream, appl_ptr);
+	return ret < 0 ? ret : frames;
 }
 
-/* decrease the appl_ptr; returns the processed frames */
+/* decrease the appl_ptr; returns the processed frames or a negative error */
 static snd_pcm_sframes_t rewind_appl_ptr(struct snd_pcm_substream *substream,
 					 snd_pcm_uframes_t frames,
 					 snd_pcm_sframes_t avail)
 {
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	snd_pcm_sframes_t appl_ptr;
+	int ret;
 
 	if (avail <= 0)
 		return 0;
@@ -2489,8 +2512,8 @@ static snd_pcm_sframes_t rewind_appl_ptr(struct snd_pcm_substream *substream,
 	appl_ptr = runtime->control->appl_ptr - frames;
 	if (appl_ptr < 0)
 		appl_ptr += runtime->boundary;
-	runtime->control->appl_ptr = appl_ptr;
-	return frames;
+	ret = apply_appl_ptr(substream, appl_ptr);
+	return ret < 0 ? ret : frames;
 }
 
 static snd_pcm_sframes_t snd_pcm_playback_rewind(struct snd_pcm_substream *substream,
@@ -2620,10 +2643,15 @@ static int snd_pcm_sync_ptr(struct snd_pcm_substream *substream,
 			return err;
 	}
 	snd_pcm_stream_lock_irq(substream);
-	if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_APPL))
-		control->appl_ptr = sync_ptr.c.control.appl_ptr;
-	else
+	if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_APPL)) {
+		err = apply_appl_ptr(substream, sync_ptr.c.control.appl_ptr);
+		if (err < 0) {
+			snd_pcm_stream_unlock_irq(substream);
+			return err;
+		}
+	} else {
 		sync_ptr.c.control.appl_ptr = control->appl_ptr;
+	}
 	if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN))
 		control->avail_min = sync_ptr.c.control.avail_min;
 	else
-- 
2.13.0



From stefan.wahren at i2se.com  Mon May 22 08:38:21 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Mon, 22 May 2017 17:38:21 +0200
Subject: [PATCH 1/4] ARM: dts: bcm283x: Add dtsi for OTG mode
In-Reply-To: <28172.1495465191@obiwan.sandelman.ca>
References: <1495385079-3697-1-git-send-email-stefan.wahren@i2se.com>
 <1495385079-3697-2-git-send-email-stefan.wahren@i2se.com>
 <28172.1495465191@obiwan.sandelman.ca>
Message-ID: <e5dbdfd7-f0e1-2abb-574f-bad3bddfefd3@i2se.com>

Am 22.05.2017 um 16:59 schrieb Michael Richardson:
> Stefan Wahren <stefan.wahren at i2se.com> wrote:
>     > The Raspberry Pi Zero also supports OTG mode. So provide a dtsi file
>     > to configure the USB interface accordingly. The fifo sizes are optimized
>     > for device endpoint 6 and 7 with the maximum of 768.
>
> So, in theory, one could wire Pi0 together via OTG cables and run
> USB/ethernet between them, right?
>

I assume you are speaking of two Raspberry Pi Zero. At least one RPi
Zero must be configured as host (dr_mode = host) explicit via DTS file.
Configure both as OTG shouldn't work. But i didn't test it in the lack
of two RPi Zero.

Stefan


From eric at anholt.net  Mon May 22 09:33:19 2017
From: eric at anholt.net (Eric Anholt)
Date: Mon, 22 May 2017 09:33:19 -0700
Subject: [PATCH 6/7] staging: bcm2835-audio: Deliver indirect-PCM transfer
 error
In-Reply-To: <20170521190258.1178-7-tiwai@suse.de>
References: <20170521190258.1178-1-tiwai@suse.de>
 <20170521190258.1178-7-tiwai@suse.de>
Message-ID: <87tw4cn968.fsf@eliezer.anholt.net>

Takashi Iwai <tiwai at suse.de> writes:

> Now that the indirect-PCM transfer helper gives back an error, we
> should return the error from ack callbacks.

As far as bcm2835 goes:

Acked-by: Eric Anholt <eric at anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170522/e51eb81a/attachment.sig>

From o-takashi at sakamocchi.jp  Sun May 21 20:49:00 2017
From: o-takashi at sakamocchi.jp (Takashi Sakamoto)
Date: Mon, 22 May 2017 12:49:00 +0900
Subject: [PATCH 0/7] ALSA: Fix/improve PCM ack callback
In-Reply-To: <20170521190258.1178-1-tiwai@suse.de>
References: <20170521190258.1178-1-tiwai@suse.de>
Message-ID: <7685a366-5b2f-0a96-a686-c49b79975c56@sakamocchi.jp>

Hi,

On May 22 2017 04:02, Takashi Iwai wrote:
> Hi,
> 
> this is a series of patches to fix the potential bugs in PCM ack
> callback using the pcm-indirect helper functions, and also to enhance
> the ack callback to be called properly in all appl_ptr updates, as
> similarly done by Pierre and Subhransu's patches.
> 
> The changes in the pcm-indirect helper code and its users are fairly
> trivial, just passing the error code back.
> 
> ARM/R-Pi people are Cc'ed because of bcm2835-audio driver.
> 
> 
> Takashi
> 
> ===
> 
> Takashi Iwai (7):
>    ALSA: pcm: Fix negative appl_ptr handling in pcm-indirect helpers
>    ALSA: mips: Deliver indirect-PCM transfer error
>    ALSA: cs46xx: Deliver indirect-PCM transfer error
>    ALSA: emu10k1: Deliver indirect-PCM transfer error
>    ALSA: rme32: Deliver indirect-PCM transfer error
>    staging: bcm2835-audio: Deliver indirect-PCM transfer error
>    ALSA: pcm: Call ack() whenever appl_ptr is updated
> 
>   .../vc04_services/bcm2835-audio/bcm2835-pcm.c      |  5 +--
>   include/sound/pcm-indirect.h                       | 10 ++++-
>   sound/core/pcm_native.c                            | 46 +++++++++++++++++-----
>   sound/mips/hal2.c                                  | 14 +++----
>   sound/pci/cs46xx/cs46xx_lib.c                      |  8 ++--
>   sound/pci/emu10k1/emupcm.c                         |  4 +-
>   sound/pci/rme32.c                                  | 10 ++---
>   7 files changed, 63 insertions(+), 34 deletions(-)

I mostly agree with this patchset, except for one point.

The added helper function, apply_appl_ptr(), copies given data to the 
runtime for application-side pointer, then call 'struct 
snd_pcm_ops.ack'. We have similar code block in 'sound/core/pcm_lib.c', 
as well. See 'snd_pcm_lib_write1()' and 'snd_pcm_lib_read1()'.

In a point of code maintenance, it's better to share the function 
between two objects; pcm_native.o and pcm_lib.o.

For instance, I can propose a below patch. I expect you to squash it up 
within one of your patches.

========== 8< ----------

diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index ab4b1d1e44ee..9d048f91bd3f 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -2010,6 +2010,12 @@ typedef int (*transfer_f)(struct 
snd_pcm_substream *substream, unsigned int hwof
  			  unsigned long data, unsigned int off,
  			  snd_pcm_uframes_t size);

+/* This symbol is shared by several relocatable objects for the same shared
+ * object.
+ */
+int snd_pcm_apply_appl_ptr(struct snd_pcm_substream *substream,
+			  snd_pcm_uframes_t appl_ptr);
+
  static snd_pcm_sframes_t snd_pcm_lib_write1(struct snd_pcm_substream 
*substream,
  					    unsigned long data,
  					    snd_pcm_uframes_t size,
@@ -2087,11 +2093,9 @@ static snd_pcm_sframes_t 
snd_pcm_lib_write1(struct snd_pcm_substream *substream,
  			break;
  		}
  		appl_ptr += frames;
-		if (appl_ptr >= runtime->boundary)
-			appl_ptr -= runtime->boundary;
-		runtime->control->appl_ptr = appl_ptr;
-		if (substream->ops->ack)
-			substream->ops->ack(substream);
+		err = snd_pcm_apply_appl_ptr(substream, appl_ptr);
+		if (err < 0)
+			goto _end_unlock;

  		offset += frames;
  		size -= frames;
@@ -2321,9 +2325,9 @@ static snd_pcm_sframes_t snd_pcm_lib_read1(struct 
snd_pcm_substream *substream,
  		appl_ptr += frames;
  		if (appl_ptr >= runtime->boundary)
  			appl_ptr -= runtime->boundary;
-		runtime->control->appl_ptr = appl_ptr;
-		if (substream->ops->ack)
-			substream->ops->ack(substream);
+		err = snd_pcm_apply_appl_ptr(substream, appl_ptr);
+		if (err < 0)
+			goto _end_unlock;

  		offset += frames;
  		size -= frames;
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 7bc4a0bbad6f..0b176b35ade1 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -2456,9 +2456,11 @@ static int do_pcm_hwsync(struct snd_pcm_substream 
*substream)
  }

  /* update to the given appl_ptr and call ack callback if needed;
- * when an error is returned, take back to the original value
+ * when an error is returned, take back to the original value.
+ * The given argument should have valid value as application pointer on PCM
+ * buffer.
   */
-static int apply_appl_ptr(struct snd_pcm_substream *substream,
+int snd_pcm_apply_appl_ptr(struct snd_pcm_substream *substream,
  			  snd_pcm_uframes_t appl_ptr)
  {
  	struct snd_pcm_runtime *runtime = substream->runtime;
@@ -2492,7 +2494,7 @@ static snd_pcm_sframes_t forward_appl_ptr(struct 
snd_pcm_substream *substream,
  	appl_ptr = runtime->control->appl_ptr + frames;
  	if (appl_ptr >= (snd_pcm_sframes_t)runtime->boundary)
  		appl_ptr -= runtime->boundary;
-	ret = apply_appl_ptr(substream, appl_ptr);
+	ret = snd_pcm_apply_appl_ptr(substream, appl_ptr);
  	return ret < 0 ? ret : frames;
  }

@@ -2512,7 +2514,7 @@ static snd_pcm_sframes_t rewind_appl_ptr(struct 
snd_pcm_substream *substream,
  	appl_ptr = runtime->control->appl_ptr - frames;
  	if (appl_ptr < 0)
  		appl_ptr += runtime->boundary;
-	ret = apply_appl_ptr(substream, appl_ptr);
+	ret = snd_pcm_apply_appl_ptr(substream, appl_ptr);
  	return ret < 0 ? ret : frames;
  }

@@ -2644,7 +2646,8 @@ static int snd_pcm_sync_ptr(struct 
snd_pcm_substream *substream,
  	}
  	snd_pcm_stream_lock_irq(substream);
  	if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_APPL)) {
-		err = apply_appl_ptr(substream, sync_ptr.c.control.appl_ptr);
+		err = snd_pcm_apply_appl_ptr(substream,
+					     sync_ptr.c.control.appl_ptr);
  		if (err < 0) {
  			snd_pcm_stream_unlock_irq(substream);
  			return err;


Regards

Takashi Sakamoto


From tiwai at suse.de  Sun May 21 22:27:40 2017
From: tiwai at suse.de (Takashi Iwai)
Date: Mon, 22 May 2017 07:27:40 +0200
Subject: [PATCH 0/7] ALSA: Fix/improve PCM ack callback
In-Reply-To: <7685a366-5b2f-0a96-a686-c49b79975c56@sakamocchi.jp>
References: <20170521190258.1178-1-tiwai@suse.de>
 <7685a366-5b2f-0a96-a686-c49b79975c56@sakamocchi.jp>
Message-ID: <s5htw4dihpv.wl-tiwai@suse.de>

On Mon, 22 May 2017 05:49:00 +0200,
Takashi Sakamoto wrote:
> 
> Hi,
> 
> On May 22 2017 04:02, Takashi Iwai wrote:
> > Hi,
> >
> > this is a series of patches to fix the potential bugs in PCM ack
> > callback using the pcm-indirect helper functions, and also to enhance
> > the ack callback to be called properly in all appl_ptr updates, as
> > similarly done by Pierre and Subhransu's patches.
> >
> > The changes in the pcm-indirect helper code and its users are fairly
> > trivial, just passing the error code back.
> >
> > ARM/R-Pi people are Cc'ed because of bcm2835-audio driver.
> >
> >
> > Takashi
> >
> > ===
> >
> > Takashi Iwai (7):
> >    ALSA: pcm: Fix negative appl_ptr handling in pcm-indirect helpers
> >    ALSA: mips: Deliver indirect-PCM transfer error
> >    ALSA: cs46xx: Deliver indirect-PCM transfer error
> >    ALSA: emu10k1: Deliver indirect-PCM transfer error
> >    ALSA: rme32: Deliver indirect-PCM transfer error
> >    staging: bcm2835-audio: Deliver indirect-PCM transfer error
> >    ALSA: pcm: Call ack() whenever appl_ptr is updated
> >
> >   .../vc04_services/bcm2835-audio/bcm2835-pcm.c      |  5 +--
> >   include/sound/pcm-indirect.h                       | 10 ++++-
> >   sound/core/pcm_native.c                            | 46 +++++++++++++++++-----
> >   sound/mips/hal2.c                                  | 14 +++----
> >   sound/pci/cs46xx/cs46xx_lib.c                      |  8 ++--
> >   sound/pci/emu10k1/emupcm.c                         |  4 +-
> >   sound/pci/rme32.c                                  | 10 ++---
> >   7 files changed, 63 insertions(+), 34 deletions(-)
> 
> I mostly agree with this patchset, except for one point.
> 
> The added helper function, apply_appl_ptr(), copies given data to the
> runtime for application-side pointer, then call 'struct
> snd_pcm_ops.ack'. We have similar code block in
> 'sound/core/pcm_lib.c', as well. See 'snd_pcm_lib_write1()' and
> 'snd_pcm_lib_read1()'.
> 
> In a point of code maintenance, it's better to share the function
> between two objects; pcm_native.o and pcm_lib.o.
> 
> For instance, I can propose a below patch. I expect you to squash it
> up within one of your patches.
> 
> ========== 8< ----------
> 
> diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
> index ab4b1d1e44ee..9d048f91bd3f 100644
> --- a/sound/core/pcm_lib.c
> +++ b/sound/core/pcm_lib.c
> @@ -2010,6 +2010,12 @@ typedef int (*transfer_f)(struct
> snd_pcm_substream *substream, unsigned int hwof
>  			  unsigned long data, unsigned int off,
>  			  snd_pcm_uframes_t size);
> 
> +/* This symbol is shared by several relocatable objects for the same shared
> + * object.
> + */
> +int snd_pcm_apply_appl_ptr(struct snd_pcm_substream *substream,
> +			  snd_pcm_uframes_t appl_ptr);
> +
>  static snd_pcm_sframes_t snd_pcm_lib_write1(struct snd_pcm_substream
> *substream,
>  					    unsigned long data,
>  					    snd_pcm_uframes_t size,
> @@ -2087,11 +2093,9 @@ static snd_pcm_sframes_t
> snd_pcm_lib_write1(struct snd_pcm_substream *substream,
>  			break;
>  		}
>  		appl_ptr += frames;
> -		if (appl_ptr >= runtime->boundary)
> -			appl_ptr -= runtime->boundary;
> -		runtime->control->appl_ptr = appl_ptr;
> -		if (substream->ops->ack)
> -			substream->ops->ack(substream);
> +		err = snd_pcm_apply_appl_ptr(substream, appl_ptr);
> +		if (err < 0)
> +			goto _end_unlock;
> 
>  		offset += frames;
>  		size -= frames;
> @@ -2321,9 +2325,9 @@ static snd_pcm_sframes_t
> snd_pcm_lib_read1(struct snd_pcm_substream *substream,
>  		appl_ptr += frames;
>  		if (appl_ptr >= runtime->boundary)
>  			appl_ptr -= runtime->boundary;
> -		runtime->control->appl_ptr = appl_ptr;
> -		if (substream->ops->ack)
> -			substream->ops->ack(substream);
> +		err = snd_pcm_apply_appl_ptr(substream, appl_ptr);
> +		if (err < 0)
> +			goto _end_unlock;
> 
>  		offset += frames;
>  		size -= frames;
> diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
> index 7bc4a0bbad6f..0b176b35ade1 100644
> --- a/sound/core/pcm_native.c
> +++ b/sound/core/pcm_native.c
> @@ -2456,9 +2456,11 @@ static int do_pcm_hwsync(struct
> snd_pcm_substream *substream)
>  }
> 
>  /* update to the given appl_ptr and call ack callback if needed;
> - * when an error is returned, take back to the original value
> + * when an error is returned, take back to the original value.
> + * The given argument should have valid value as application pointer on PCM
> + * buffer.
>   */
> -static int apply_appl_ptr(struct snd_pcm_substream *substream,
> +int snd_pcm_apply_appl_ptr(struct snd_pcm_substream *substream,
>  			  snd_pcm_uframes_t appl_ptr)
>  {
>  	struct snd_pcm_runtime *runtime = substream->runtime;
> @@ -2492,7 +2494,7 @@ static snd_pcm_sframes_t forward_appl_ptr(struct
> snd_pcm_substream *substream,
>  	appl_ptr = runtime->control->appl_ptr + frames;
>  	if (appl_ptr >= (snd_pcm_sframes_t)runtime->boundary)
>  		appl_ptr -= runtime->boundary;
> -	ret = apply_appl_ptr(substream, appl_ptr);
> +	ret = snd_pcm_apply_appl_ptr(substream, appl_ptr);
>  	return ret < 0 ? ret : frames;
>  }
> 
> @@ -2512,7 +2514,7 @@ static snd_pcm_sframes_t rewind_appl_ptr(struct
> snd_pcm_substream *substream,
>  	appl_ptr = runtime->control->appl_ptr - frames;
>  	if (appl_ptr < 0)
>  		appl_ptr += runtime->boundary;
> -	ret = apply_appl_ptr(substream, appl_ptr);
> +	ret = snd_pcm_apply_appl_ptr(substream, appl_ptr);
>  	return ret < 0 ? ret : frames;
>  }
> 
> @@ -2644,7 +2646,8 @@ static int snd_pcm_sync_ptr(struct
> snd_pcm_substream *substream,
>  	}
>  	snd_pcm_stream_lock_irq(substream);
>  	if (!(sync_ptr.flags & SNDRV_PCM_SYNC_PTR_APPL)) {
> -		err = apply_appl_ptr(substream, sync_ptr.c.control.appl_ptr);
> +		err = snd_pcm_apply_appl_ptr(substream,
> +					     sync_ptr.c.control.appl_ptr);
>  		if (err < 0) {
>  			snd_pcm_stream_unlock_irq(substream);
>  			return err;

These functions will be modified again by other upcoming patchsets, so
I'd like not to touch so much for minor optimization at this stage.
Let's postpone that after all settled down.


thanks,

Takashi


From o-takashi at sakamocchi.jp  Sun May 21 23:31:13 2017
From: o-takashi at sakamocchi.jp (Takashi Sakamoto)
Date: Mon, 22 May 2017 15:31:13 +0900
Subject: [PATCH 0/7] ALSA: Fix/improve PCM ack callback
In-Reply-To: <s5htw4dihpv.wl-tiwai@suse.de>
References: <20170521190258.1178-1-tiwai@suse.de>
 <7685a366-5b2f-0a96-a686-c49b79975c56@sakamocchi.jp>
 <s5htw4dihpv.wl-tiwai@suse.de>
Message-ID: <6cb4bbc8-2d5f-45d0-0635-37f1737972c3@sakamocchi.jp>

On May 22 2017 14:27, Takashi Iwai wrote:
> These functions will be modified again by other upcoming patchsets, so
> I'd like not to touch so much for minor optimization at this stage.

If you address to your latest patchset[1], it might not be applied 
promptly because I have some comments (not posted yet, in this night). 
It's not good to avoid better bahaviour in a reason of patchset 
dependency, at least you seems to be too hasty.


[1] [alsa-devel] [PATCH 00/16] ALSA: Convert to new copy_silence PCM ops

Regards

Takashi Sakamoto


From tiwai at suse.de  Sun May 21 23:46:56 2017
From: tiwai at suse.de (Takashi Iwai)
Date: Mon, 22 May 2017 08:46:56 +0200
Subject: [PATCH 0/7] ALSA: Fix/improve PCM ack callback
In-Reply-To: <6cb4bbc8-2d5f-45d0-0635-37f1737972c3@sakamocchi.jp>
References: <20170521190258.1178-1-tiwai@suse.de>
 <7685a366-5b2f-0a96-a686-c49b79975c56@sakamocchi.jp>
 <s5htw4dihpv.wl-tiwai@suse.de>
 <6cb4bbc8-2d5f-45d0-0635-37f1737972c3@sakamocchi.jp>
Message-ID: <s5hmva5ie1r.wl-tiwai@suse.de>

On Mon, 22 May 2017 08:31:13 +0200,
Takashi Sakamoto wrote:
> 
> On May 22 2017 14:27, Takashi Iwai wrote:
> > These functions will be modified again by other upcoming patchsets, so
> > I'd like not to touch so much for minor optimization at this stage.
> 
> If you address to your latest patchset[1], it might not be applied
> promptly because I have some comments (not posted yet, in this
> night). It's not good to avoid better bahaviour in a reason of
> patchset dependency, at least you seems to be too hasty.

Come on, your suggestion is an optimization change that can be applied
anytime later easily.  If it were a mandatory fix, we should apply or
fold it immediately, but that's not the case.  The only necessary
thing is not to forget it.


Takashi

> 
> 
> [1] [alsa-devel] [PATCH 00/16] ALSA: Convert to new copy_silence PCM ops
> 
> Regards
> 
> Takashi Sakamoto
> 


From tiwai at suse.de  Mon May 22 00:07:28 2017
From: tiwai at suse.de (Takashi Iwai)
Date: Mon, 22 May 2017 09:07:28 +0200
Subject: [PATCH 0/7] ALSA: Fix/improve PCM ack callback
In-Reply-To: <s5hmva5ie1r.wl-tiwai@suse.de>
References: <20170521190258.1178-1-tiwai@suse.de>
 <7685a366-5b2f-0a96-a686-c49b79975c56@sakamocchi.jp>
 <s5htw4dihpv.wl-tiwai@suse.de>
 <6cb4bbc8-2d5f-45d0-0635-37f1737972c3@sakamocchi.jp>
 <s5hmva5ie1r.wl-tiwai@suse.de>
Message-ID: <s5hh90did3j.wl-tiwai@suse.de>

On Mon, 22 May 2017 08:46:56 +0200,
Takashi Iwai wrote:
> 
> On Mon, 22 May 2017 08:31:13 +0200,
> Takashi Sakamoto wrote:
> > 
> > On May 22 2017 14:27, Takashi Iwai wrote:
> > > These functions will be modified again by other upcoming patchsets, so
> > > I'd like not to touch so much for minor optimization at this stage.
> > 
> > If you address to your latest patchset[1], it might not be applied
> > promptly because I have some comments (not posted yet, in this
> > night). It's not good to avoid better bahaviour in a reason of
> > patchset dependency, at least you seems to be too hasty.
> 
> Come on, your suggestion is an optimization change that can be applied
> anytime later easily.  If it were a mandatory fix, we should apply or
> fold it immediately, but that's not the case.  The only necessary
> thing is not to forget it.

That implies: just submit your proposed change as an incremental patch
on top of mine.  Then I'll queue it.


thanks,

Takashi


From paul.gortmaker at windriver.com  Mon May 22 13:56:45 2017
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Mon, 22 May 2017 16:56:45 -0400
Subject: [PATCH 0/3] pinctrl: bcm/samsung/tegra: make bool code non-modular
Message-ID: <20170522205648.23545-1-paul.gortmaker@windriver.com>

This is the last of the pinctrl cleanups I have in my queue.  So
hopefully once these are in and any current but out-of-tree drivers
are submitted, there won't be any more examples of non-modular code
using modular infrastructure for people to inadvertently copy off of.

Nothing really new here -- if the Kconfig and/or the Makefile does
not allow building the code as modular, then we don't need to be
using module_xyz() functions and/or MODULE_XYZ macros.

Here we audit and remove such instances in three subdirectories of
the pinctrl subsystem: bcm, samsung, and tegra, which allows us
to have a positive net removal of unused code as per the diffstat.

Rather than do one commit per driver, we take advantage of the
fact that the drivers are grouped already and bundle the changes
per family, since the changes are not really deeply technical.

Build tested for allmodconfig on linux-next for arm, arm64; also
explicitly compiled each file for both arch to ensure nobody got
missed on the allmodconfig.  (there are missing renesas_sdhi syms
in today's linux-next arm but that is not caused by these changes.)

Linus - thanks for your patience in merging all these to date.

Paul.

---

Cc: Alexandre Courbot <gnurou at gmail.com>
Cc: Ashwini Ghuge <aghuge at nvidia.com>
Cc: bcm-kernel-feedback-list at broadcom.com
Cc: Eric Anholt <eric at anholt.net>
Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: Jon Mason <jonmason at broadcom.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Pritesh Raithatha <praithatha at nvidia.com>
Cc: Ray Jui <rjui at broadcom.com>
Cc: Scott Branden <sbranden at broadcom.com>
Cc: Sherman Yin <syin at broadcom.com>
Cc: Stefan Wahren <stefan.wahren at i2se.com>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Cc: Thierry Reding <thierry.reding at gmail.com>
Cc: Thomas Abraham <thomas.ab at samsung.com>
Cc: Tomasz Figa <tomasz.figa at gmail.com>
Cc: linux-gpio at vger.kernel.org
Cc: linux-rpi-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-tegra at vger.kernel.org

Paul Gortmaker (3):
  pinctrl: samsung: clean up modular vs. non-modular distinctions
  pinctrl: tegra: clean up modular vs. non-modular distinctions
  pinctrl: bcm: clean up modular vs. non-modular distinctions

 drivers/pinctrl/bcm/pinctrl-bcm281xx.c       | 16 ++++++++--------
 drivers/pinctrl/bcm/pinctrl-bcm2835.c        | 20 +++-----------------
 drivers/pinctrl/bcm/pinctrl-cygnus-mux.c     | 11 +++++------
 drivers/pinctrl/samsung/pinctrl-exynos.c     |  1 -
 drivers/pinctrl/samsung/pinctrl-exynos5440.c | 15 +++------------
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c    |  2 +-
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c    |  2 +-
 drivers/pinctrl/samsung/pinctrl-samsung.c    | 13 +------------
 drivers/pinctrl/tegra/pinctrl-tegra.c        |  1 -
 drivers/pinctrl/tegra/pinctrl-tegra114.c     | 11 ++++-------
 drivers/pinctrl/tegra/pinctrl-tegra124.c     | 11 ++++-------
 drivers/pinctrl/tegra/pinctrl-tegra20.c      | 11 ++++-------
 drivers/pinctrl/tegra/pinctrl-tegra210.c     |  9 ++-------
 drivers/pinctrl/tegra/pinctrl-tegra30.c      | 11 ++++-------
 14 files changed, 40 insertions(+), 94 deletions(-)

-- 
2.11.0



From paul.gortmaker at windriver.com  Mon May 22 13:56:48 2017
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Mon, 22 May 2017 16:56:48 -0400
Subject: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular
 distinctions
In-Reply-To: <20170522205648.23545-1-paul.gortmaker@windriver.com>
References: <20170522205648.23545-1-paul.gortmaker@windriver.com>
Message-ID: <20170522205648.23545-4-paul.gortmaker@windriver.com>

Fixups here tend to be more of a conglomerate of some of the other
repeated/systematic ones we've seen in the earlier pinctrl cleanups.

We remove module.h from code that isn't doing anything modular at
all;  if they have __init sections, then replace it with init.h

One driver has a .remove that would be dispatched on module_exit,
and as that code is essentially orphaned, so we remove it.  In case
anyone was previously doing the (pointless) unbind to get to that
function, we disable unbind for this one driver as well.

A couple bool drivers (hence non-modular) are converted over to
to builtin_platform_driver().

Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.

Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.

We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.

Cc: Eric Anholt <eric at anholt.net>
Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: Jon Mason <jonmason at broadcom.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Ray Jui <rjui at broadcom.com>
Cc: Scott Branden <sbranden at broadcom.com>
Cc: Stefan Wahren <stefan.wahren at i2se.com>
Cc: Sherman Yin <syin at broadcom.com>
Cc: bcm-kernel-feedback-list at broadcom.com
Cc: linux-gpio at vger.kernel.org
Cc: linux-rpi-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
---
 drivers/pinctrl/bcm/pinctrl-bcm281xx.c   | 16 ++++++++--------
 drivers/pinctrl/bcm/pinctrl-bcm2835.c    | 20 +++-----------------
 drivers/pinctrl/bcm/pinctrl-cygnus-mux.c | 11 +++++------
 3 files changed, 16 insertions(+), 31 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
index 810a81786f62..e630f4d5f4c7 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
@@ -1,4 +1,10 @@
 /*
+ * Broadcom BCM281xx pinctrl driver
+ *
+ * Author(s):
+ *	Sherman Yin <syin at broadcom.com>
+ *	Broadcom Corporation <bcm-kernel-feedback-list at broadcom.com>
+ *
  * Copyright (C) 2013 Broadcom Corporation
  *
  * This program is free software; you can redistribute it and/or
@@ -12,7 +18,7 @@
  */
 #include <linux/err.h>
 #include <linux/io.h>
-#include <linux/module.h>
+#include <linux/init.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/pinctrl/pinctrl.h>
@@ -1444,10 +1450,4 @@ static struct platform_driver bcm281xx_pinctrl_driver = {
 		.of_match_table = bcm281xx_pinctrl_of_match,
 	},
 };
-
-module_platform_driver_probe(bcm281xx_pinctrl_driver, bcm281xx_pinctrl_probe);
-
-MODULE_AUTHOR("Broadcom Corporation <bcm-kernel-feedback-list at broadcom.com>");
-MODULE_AUTHOR("Sherman Yin <syin at broadcom.com>");
-MODULE_DESCRIPTION("Broadcom BCM281xx pinctrl driver");
-MODULE_LICENSE("GPL v2");
+builtin_platform_driver_probe(bcm281xx_pinctrl_driver, bcm281xx_pinctrl_probe);
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 85d009112864..1eb7a1a5a4bb 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -27,7 +27,7 @@
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/irqdesc.h>
-#include <linux/module.h>
+#include <linux/init.h>
 #include <linux/of_address.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
@@ -1075,31 +1075,17 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int bcm2835_pinctrl_remove(struct platform_device *pdev)
-{
-	struct bcm2835_pinctrl *pc = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&pc->gpio_chip);
-
-	return 0;
-}
-
 static const struct of_device_id bcm2835_pinctrl_match[] = {
 	{ .compatible = "brcm,bcm2835-gpio" },
 	{}
 };
-MODULE_DEVICE_TABLE(of, bcm2835_pinctrl_match);
 
 static struct platform_driver bcm2835_pinctrl_driver = {
 	.probe = bcm2835_pinctrl_probe,
-	.remove = bcm2835_pinctrl_remove,
 	.driver = {
 		.name = MODULE_NAME,
 		.of_match_table = bcm2835_pinctrl_match,
+		.suppress_bind_attrs = true,
 	},
 };
-module_platform_driver(bcm2835_pinctrl_driver);
-
-MODULE_AUTHOR("Chris Boot, Simon Arlott, Stephen Warren");
-MODULE_DESCRIPTION("BCM2835 Pin control driver");
-MODULE_LICENSE("GPL");
+builtin_platform_driver(bcm2835_pinctrl_driver);
diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
index d31c95701a92..3684cca277ad 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
@@ -1,4 +1,8 @@
-/* Copyright (C) 2014-2015 Broadcom Corporation
+/*
+ * Broadcom Cygnus IOMUX driver
+ *
+ * Author: Ray Jui <rjui at broadcom.com>
+ * Copyright (C) 2014-2015 Broadcom Corporation
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License as
@@ -17,7 +21,6 @@
 
 #include <linux/err.h>
 #include <linux/io.h>
-#include <linux/module.h>
 #include <linux/of.h>
 #include <linux/slab.h>
 #include <linux/platform_device.h>
@@ -1016,7 +1019,3 @@ static int __init cygnus_pinmux_init(void)
 	return platform_driver_register(&cygnus_pinmux_driver);
 }
 arch_initcall(cygnus_pinmux_init);
-
-MODULE_AUTHOR("Ray Jui <rjui at broadcom.com>");
-MODULE_DESCRIPTION("Broadcom Cygnus IOMUX driver");
-MODULE_LICENSE("GPL v2");
-- 
2.11.0



From mcr at sandelman.ca  Tue May 23 06:45:36 2017
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 23 May 2017 09:45:36 -0400
Subject: [PATCH 1/4] ARM: dts: bcm283x: Add dtsi for OTG mode
In-Reply-To: <e5dbdfd7-f0e1-2abb-574f-bad3bddfefd3@i2se.com>
References: <1495385079-3697-1-git-send-email-stefan.wahren@i2se.com>
 <1495385079-3697-2-git-send-email-stefan.wahren@i2se.com>
 <28172.1495465191@obiwan.sandelman.ca>
 <e5dbdfd7-f0e1-2abb-574f-bad3bddfefd3@i2se.com>
Message-ID: <20921.1495547136@obiwan.sandelman.ca>

Stefan Wahren <stefan.wahren at i2se.com> wrote:
    >> Stefan Wahren <stefan.wahren at i2se.com> wrote:
    >> > The Raspberry Pi Zero also supports OTG mode. So provide a dtsi file
    >> > to configure the USB interface accordingly. The fifo sizes are optimized
    >> > for device endpoint 6 and 7 with the maximum of 768.
    >>
    >> So, in theory, one could wire Pi0 together via OTG cables and run
    >> USB/ethernet between them, right?
    >>

    > I assume you are speaking of two Raspberry Pi Zero. At least one RPi
    > Zero must be configured as host (dr_mode = host) explicit via DTS file.
    > Configure both as OTG shouldn't work. But i didn't test it in the lack
    > of two RPi Zero.

RPI0, or OrangePi0, etc.
We have to configure it via DTS file... hmm.
Not dynamically... that's less fun as it means different devices.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [



From stefan.wahren at i2se.com  Tue May 23 13:11:55 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Tue, 23 May 2017 22:11:55 +0200 (CEST)
Subject: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular
 distinctions
In-Reply-To: <20170522205648.23545-4-paul.gortmaker@windriver.com>
References: <20170522205648.23545-1-paul.gortmaker@windriver.com>
 <20170522205648.23545-4-paul.gortmaker@windriver.com>
Message-ID: <812482107.237697.1495570315919@email.1und1.de>


> Paul Gortmaker <paul.gortmaker at windriver.com> hat am 22. Mai 2017 um 22:56 geschrieben:
> 
> 
> Fixups here tend to be more of a conglomerate of some of the other
> repeated/systematic ones we've seen in the earlier pinctrl cleanups.
> 
> We remove module.h from code that isn't doing anything modular at
> all;  if they have __init sections, then replace it with init.h
> 
> One driver has a .remove that would be dispatched on module_exit,
> and as that code is essentially orphaned, so we remove it.  In case
> anyone was previously doing the (pointless) unbind to get to that
> function, we disable unbind for this one driver as well.
> 
> A couple bool drivers (hence non-modular) are converted over to
> to builtin_platform_driver().
> 
> Since module_platform_driver() uses the same init level priority as
> builtin_platform_driver() the init ordering remains unchanged with
> this commit.
> 
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We also delete the MODULE_LICENSE tag etc. since all that information
> was (or is now) contained at the top of the file in the comments.
> 
> Cc: Eric Anholt <eric at anholt.net>
> Cc: Florian Fainelli <f.fainelli at gmail.com>
> Cc: Jon Mason <jonmason at broadcom.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Ray Jui <rjui at broadcom.com>
> Cc: Scott Branden <sbranden at broadcom.com>
> Cc: Stefan Wahren <stefan.wahren at i2se.com>
> Cc: Sherman Yin <syin at broadcom.com>
> Cc: bcm-kernel-feedback-list at broadcom.com
> Cc: linux-gpio at vger.kernel.org
> Cc: linux-rpi-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> ---
>  drivers/pinctrl/bcm/pinctrl-bcm281xx.c   | 16 ++++++++--------
>  drivers/pinctrl/bcm/pinctrl-bcm2835.c    | 20 +++-----------------

Tested-by: Stefan Wahren <stefan.wahren at i2se.com>

for pinctrl-bcm2835


From scott.branden at broadcom.com  Tue May 23 15:15:15 2017
From: scott.branden at broadcom.com (Scott Branden)
Date: Tue, 23 May 2017 15:15:15 -0700
Subject: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular
 distinctions
In-Reply-To: <20170522205648.23545-4-paul.gortmaker@windriver.com>
References: <20170522205648.23545-1-paul.gortmaker@windriver.com>
 <20170522205648.23545-4-paul.gortmaker@windriver.com>
Message-ID: <804d9519-5e1b-d9b1-4591-010dcafa2ff1@broadcom.com>

Hi Paul,

Some comments - leave our file headers intact.  If you want to add a new 
comment do so after the existing file header in another comment.  But, I 
don't think any of that information is needed by us.


On 17-05-22 01:56 PM, Paul Gortmaker wrote:
> Fixups here tend to be more of a conglomerate of some of the other
> repeated/systematic ones we've seen in the earlier pinctrl cleanups.
>
> We remove module.h from code that isn't doing anything modular at
> all;  if they have __init sections, then replace it with init.h
>
> One driver has a .remove that would be dispatched on module_exit,
> and as that code is essentially orphaned, so we remove it.  In case
> anyone was previously doing the (pointless) unbind to get to that
> function, we disable unbind for this one driver as well.
>
> A couple bool drivers (hence non-modular) are converted over to
> to builtin_platform_driver().
>
> Since module_platform_driver() uses the same init level priority as
> builtin_platform_driver() the init ordering remains unchanged with
> this commit.
>
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>
> We also delete the MODULE_LICENSE tag etc. since all that information
> was (or is now) contained at the top of the file in the comments.
>
> Cc: Eric Anholt <eric at anholt.net>
> Cc: Florian Fainelli <f.fainelli at gmail.com>
> Cc: Jon Mason <jonmason at broadcom.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Ray Jui <rjui at broadcom.com>
> Cc: Scott Branden <sbranden at broadcom.com>
> Cc: Stefan Wahren <stefan.wahren at i2se.com>
> Cc: Sherman Yin <syin at broadcom.com>
> Cc: bcm-kernel-feedback-list at broadcom.com
> Cc: linux-gpio at vger.kernel.org
> Cc: linux-rpi-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> ---
>   drivers/pinctrl/bcm/pinctrl-bcm281xx.c   | 16 ++++++++--------
>   drivers/pinctrl/bcm/pinctrl-bcm2835.c    | 20 +++-----------------
>   drivers/pinctrl/bcm/pinctrl-cygnus-mux.c | 11 +++++------
>   3 files changed, 16 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
> index 810a81786f62..e630f4d5f4c7 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
> @@ -1,4 +1,10 @@
>   /*
> + * Broadcom BCM281xx pinctrl driver
> + *
> + * Author(s):
> + *	Sherman Yin <syin at broadcom.com>
> + *	Broadcom Corporation <bcm-kernel-feedback-list at broadcom.com>
> + *
Please do not add anything to the header above - leave it as is.
>    * Copyright (C) 2013 Broadcom Corporation
>    *
>    * This program is free software; you can redistribute it and/or
> @@ -12,7 +18,7 @@
>    */
>   #include <linux/err.h>
>   #include <linux/io.h>
> -#include <linux/module.h>
> +#include <linux/init.h>
>   #include <linux/of.h>
>   #include <linux/platform_device.h>
>   #include <linux/pinctrl/pinctrl.h>
> @@ -1444,10 +1450,4 @@ static struct platform_driver bcm281xx_pinctrl_driver = {
>   		.of_match_table = bcm281xx_pinctrl_of_match,
>   	},
>   };
> -
> -module_platform_driver_probe(bcm281xx_pinctrl_driver, bcm281xx_pinctrl_probe);
> -
> -MODULE_AUTHOR("Broadcom Corporation <bcm-kernel-feedback-list at broadcom.com>");
> -MODULE_AUTHOR("Sherman Yin <syin at broadcom.com>");
> -MODULE_DESCRIPTION("Broadcom BCM281xx pinctrl driver");
> -MODULE_LICENSE("GPL v2");
Fine to remove this if it's not need any more.
> +builtin_platform_driver_probe(bcm281xx_pinctrl_driver, bcm281xx_pinctrl_probe);
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index 85d009112864..1eb7a1a5a4bb 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> @@ -27,7 +27,7 @@
>   #include <linux/io.h>
>   #include <linux/irq.h>
>   #include <linux/irqdesc.h>
> -#include <linux/module.h>
> +#include <linux/init.h>
>   #include <linux/of_address.h>
>   #include <linux/of.h>
>   #include <linux/of_irq.h>
> @@ -1075,31 +1075,17 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
>   	return 0;
>   }
>   
> -static int bcm2835_pinctrl_remove(struct platform_device *pdev)
> -{
> -	struct bcm2835_pinctrl *pc = platform_get_drvdata(pdev);
> -
> -	gpiochip_remove(&pc->gpio_chip);
> -
> -	return 0;
> -}
> -
>   static const struct of_device_id bcm2835_pinctrl_match[] = {
>   	{ .compatible = "brcm,bcm2835-gpio" },
>   	{}
>   };
> -MODULE_DEVICE_TABLE(of, bcm2835_pinctrl_match);
>   
>   static struct platform_driver bcm2835_pinctrl_driver = {
>   	.probe = bcm2835_pinctrl_probe,
> -	.remove = bcm2835_pinctrl_remove,
>   	.driver = {
>   		.name = MODULE_NAME,
>   		.of_match_table = bcm2835_pinctrl_match,
> +		.suppress_bind_attrs = true,
>   	},
>   };
> -module_platform_driver(bcm2835_pinctrl_driver);
> -
> -MODULE_AUTHOR("Chris Boot, Simon Arlott, Stephen Warren");
> -MODULE_DESCRIPTION("BCM2835 Pin control driver");
> -MODULE_LICENSE("GPL");
> +builtin_platform_driver(bcm2835_pinctrl_driver);
> diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
> index d31c95701a92..3684cca277ad 100644
> --- a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
> +++ b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
> @@ -1,4 +1,8 @@
> -/* Copyright (C) 2014-2015 Broadcom Corporation
> +/*
> + * Broadcom Cygnus IOMUX driver
> + *
> + * Author: Ray Jui <rjui at broadcom.com>
> + * Copyright (C) 2014-2015 Broadcom Corporation
Please do not add any of the above to the file header.
>    *
>    * This program is free software; you can redistribute it and/or
>    * modify it under the terms of the GNU General Public License as
> @@ -17,7 +21,6 @@
>   
>   #include <linux/err.h>
>   #include <linux/io.h>
> -#include <linux/module.h>
>   #include <linux/of.h>
>   #include <linux/slab.h>
>   #include <linux/platform_device.h>
> @@ -1016,7 +1019,3 @@ static int __init cygnus_pinmux_init(void)
>   	return platform_driver_register(&cygnus_pinmux_driver);
>   }
>   arch_initcall(cygnus_pinmux_init);
> -
> -MODULE_AUTHOR("Ray Jui <rjui at broadcom.com>");
> -MODULE_DESCRIPTION("Broadcom Cygnus IOMUX driver");
> -MODULE_LICENSE("GPL v2");
Fine with this modification.

Thanks,
  scott


From garsilva at embeddedor.com  Tue May 23 16:42:27 2017
From: garsilva at embeddedor.com (Gustavo A. R. Silva)
Date: Tue, 23 May 2017 18:42:27 -0500
Subject: [PATCH] mmc: host: fix potential null pointer dereference
Message-ID: <20170523234227.GA13018@embeddedgus>

Null check at line 1165: if (mrq->cmd), implies that mrq->cmd might
be NULL.
Add null checks before dereferencing pointer mrq->cmd in order to avoid
any potential NULL pointer dereference.

Addresses-Coverity-ID: 1408740
Signed-off-by: Gustavo A. R. Silva <garsilva at embeddedor.com>
---
 drivers/mmc/host/bcm2835.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/bcm2835.c b/drivers/mmc/host/bcm2835.c
index 1f343a4..abba9a2 100644
--- a/drivers/mmc/host/bcm2835.c
+++ b/drivers/mmc/host/bcm2835.c
@@ -1172,7 +1172,10 @@ static void bcm2835_request(struct mmc_host *mmc, struct mmc_request *mrq)
 	if (mrq->data && !is_power_of_2(mrq->data->blksz)) {
 		dev_err(dev, "unsupported block size (%d bytes)\n",
 			mrq->data->blksz);
-		mrq->cmd->error = -EINVAL;
+
+		if (mrq->cmd)
+			mrq->cmd->error = -EINVAL;
+
 		mmc_request_done(mmc, mrq);
 		return;
 	}
@@ -1194,7 +1197,10 @@ static void bcm2835_request(struct mmc_host *mmc, struct mmc_request *mrq)
 			readl(host->ioaddr + SDCMD) & SDCMD_CMD_MASK,
 			edm);
 		bcm2835_dumpregs(host);
-		mrq->cmd->error = -EILSEQ;
+
+		if (mrq->cmd)
+			mrq->cmd->error = -EILSEQ;
+
 		bcm2835_finish_request(host);
 		mutex_unlock(&host->mutex);
 		return;
@@ -1207,7 +1213,7 @@ static void bcm2835_request(struct mmc_host *mmc, struct mmc_request *mrq)
 			if (!host->use_busy)
 				bcm2835_finish_command(host);
 		}
-	} else if (bcm2835_send_command(host, mrq->cmd)) {
+	} else if (mrq->cmd && bcm2835_send_command(host, mrq->cmd)) {
 		if (host->data && host->dma_desc) {
 			/* DMA transfer starts now, PIO starts after irq */
 			bcm2835_start_dma(host);
-- 
2.5.0



From paul.gortmaker at windriver.com  Tue May 23 17:12:30 2017
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Tue, 23 May 2017 20:12:30 -0400
Subject: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular
 distinctions
In-Reply-To: <804d9519-5e1b-d9b1-4591-010dcafa2ff1@broadcom.com>
References: <20170522205648.23545-1-paul.gortmaker@windriver.com>
 <20170522205648.23545-4-paul.gortmaker@windriver.com>
 <804d9519-5e1b-d9b1-4591-010dcafa2ff1@broadcom.com>
Message-ID: <20170524001230.GJ11504@windriver.com>

[Re: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular distinctions] On 23/05/2017 (Tue 15:15) Scott Branden wrote:

> Hi Paul,
> 
> Some comments - leave our file headers intact.  If you want to add a new
> comment do so after the existing file header in another comment.  But, I
> don't think any of that information is needed by us.

OK, no problem, if that is what is desired for your driver.  I just
normally move the author information from the bottom of the file to the
top of the file.  As a lot of the linux driver work was (is?) done for
kudos and not for career, I can't just delete author information.  That
would not be fair to most of those contributors.

It hasn't been a problem before in all of the other similar commits I've
made, but I can imagine a tool that does a check on the comment block on
the top of a file and complains if it changes, or similar.

Would you prefer something like this instead?  It leaves your header
completely untouched, and still gives credit to the original author,
and those lines are also untouched.

I've not re-done build coverage on this yet, but let me know if this is
what you'd prefer.

Thanks,
Paul
--

 From 3f8bf38bcdbf38484182222965aac2748cc1d5cd Mon Sep 17 00:00:00 2001
From: Paul Gortmaker <paul.gortmaker at windriver.com>
Date: Mon, 31 Aug 2015 17:35:47 -0400
Subject: [PATCH] pinctrl: bcm: clean up modular vs. non-modular distinctions

Fixups here tend to be more of a conglomerate of some of the other
repeated/systematic ones we've seen in the earlier pinctrl cleanups.

We remove module.h from code that isn't doing anything modular at
all;  if they have __init sections, then replace it with init.h

One driver has a .remove that would be dispatched on module_exit,
and as that code is essentially orphaned, so we remove it.  In case
anyone was previously doing the (pointless) unbind to get to that
function, we disable unbind for this one driver as well.

A couple bool drivers (hence non-modular) are converted over to
to builtin_platform_driver().

Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.

Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.

We leave the MODULE_AUTHOR and MODULE_LICENSE tag etc. at the bottom
of the file since Broadcom would prefer the comment block at the top
of the file remain unchanged.  We just use CPP to take it out of the
picture with an #if 0 / #endif instead.

Cc: Eric Anholt <eric at anholt.net>
Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: Jon Mason <jonmason at broadcom.com>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Ray Jui <rjui at broadcom.com>
Cc: Scott Branden <sbranden at broadcom.com>
Cc: Stefan Wahren <stefan.wahren at i2se.com>
Cc: Sherman Yin <syin at broadcom.com>
Cc: bcm-kernel-feedback-list at broadcom.com
Cc: linux-gpio at vger.kernel.org
Cc: linux-rpi-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
---
 drivers/pinctrl/bcm/pinctrl-bcm281xx.c   |  7 ++++---
 drivers/pinctrl/bcm/pinctrl-bcm2835.c    | 18 +++++-------------
 drivers/pinctrl/bcm/pinctrl-cygnus-mux.c |  3 ++-
 3 files changed, 11 insertions(+), 17 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
index 810a81786f62..cc01acc988d0 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
@@ -12,7 +12,7 @@
  */
 #include <linux/err.h>
 #include <linux/io.h>
-#include <linux/module.h>
+#include <linux/init.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/pinctrl/pinctrl.h>
@@ -1444,10 +1444,11 @@ static struct platform_driver bcm281xx_pinctrl_driver = {
 		.of_match_table = bcm281xx_pinctrl_of_match,
 	},
 };
+builtin_platform_driver_probe(bcm281xx_pinctrl_driver, bcm281xx_pinctrl_probe);
 
-module_platform_driver_probe(bcm281xx_pinctrl_driver, bcm281xx_pinctrl_probe);
-
+#if 0 /* ...def MODULE ; never supported as such; kept for documentation. */
 MODULE_AUTHOR("Broadcom Corporation <bcm-kernel-feedback-list at broadcom.com>");
 MODULE_AUTHOR("Sherman Yin <syin at broadcom.com>");
 MODULE_DESCRIPTION("Broadcom BCM281xx pinctrl driver");
 MODULE_LICENSE("GPL v2");
+#endif
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 85d009112864..3924ff17e955 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -27,7 +27,7 @@
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/irqdesc.h>
-#include <linux/module.h>
+#include <linux/init.h>
 #include <linux/of_address.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
@@ -1075,31 +1075,23 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int bcm2835_pinctrl_remove(struct platform_device *pdev)
-{
-	struct bcm2835_pinctrl *pc = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&pc->gpio_chip);
-
-	return 0;
-}
-
 static const struct of_device_id bcm2835_pinctrl_match[] = {
 	{ .compatible = "brcm,bcm2835-gpio" },
 	{}
 };
-MODULE_DEVICE_TABLE(of, bcm2835_pinctrl_match);
 
 static struct platform_driver bcm2835_pinctrl_driver = {
 	.probe = bcm2835_pinctrl_probe,
-	.remove = bcm2835_pinctrl_remove,
 	.driver = {
 		.name = MODULE_NAME,
 		.of_match_table = bcm2835_pinctrl_match,
+		.suppress_bind_attrs = true,
 	},
 };
-module_platform_driver(bcm2835_pinctrl_driver);
+builtin_platform_driver(bcm2835_pinctrl_driver);
 
+#if 0 /* ...def MODULE ; never supported as such; kept for documentation. */
 MODULE_AUTHOR("Chris Boot, Simon Arlott, Stephen Warren");
 MODULE_DESCRIPTION("BCM2835 Pin control driver");
 MODULE_LICENSE("GPL");
+#endif
diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
index d31c95701a92..84c2a182a5b7 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
@@ -17,7 +17,6 @@
 
 #include <linux/err.h>
 #include <linux/io.h>
-#include <linux/module.h>
 #include <linux/of.h>
 #include <linux/slab.h>
 #include <linux/platform_device.h>
@@ -1017,6 +1016,8 @@ static int __init cygnus_pinmux_init(void)
 }
 arch_initcall(cygnus_pinmux_init);
 
+#if 0 /* ...def MODULE ; never supported as such; kept for documentation. */
 MODULE_AUTHOR("Ray Jui <rjui at broadcom.com>");
 MODULE_DESCRIPTION("Broadcom Cygnus IOMUX driver");
 MODULE_LICENSE("GPL v2");
+#endif
-- 
2.11.0




From f.fainelli at gmail.com  Tue May 23 17:25:54 2017
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 23 May 2017 17:25:54 -0700
Subject: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular
 distinctions
In-Reply-To: <20170524001230.GJ11504@windriver.com>
References: <20170522205648.23545-1-paul.gortmaker@windriver.com>
 <20170522205648.23545-4-paul.gortmaker@windriver.com>
 <804d9519-5e1b-d9b1-4591-010dcafa2ff1@broadcom.com>
 <20170524001230.GJ11504@windriver.com>
Message-ID: <f653cf1f-87d9-7549-6e3b-aa0ca388579c@gmail.com>

On 05/23/2017 05:12 PM, Paul Gortmaker wrote:
> [Re: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular distinctions] On 23/05/2017 (Tue 15:15) Scott Branden wrote:
> 
>> Hi Paul,
>>
>> Some comments - leave our file headers intact.  If you want to add a new
>> comment do so after the existing file header in another comment.  But, I
>> don't think any of that information is needed by us.
> 
> OK, no problem, if that is what is desired for your driver.  I just
> normally move the author information from the bottom of the file to the
> top of the file.  As a lot of the linux driver work was (is?) done for
> kudos and not for career, I can't just delete author information.  That
> would not be fair to most of those contributors.
> 
> It hasn't been a problem before in all of the other similar commits I've
> made, but I can imagine a tool that does a check on the comment block on
> the top of a file and complains if it changes, or similar.
> 
> Would you prefer something like this instead?  It leaves your header
> completely untouched, and still gives credit to the original author,
> and those lines are also untouched.

This looks horrible, sorry. Scott, what's the matter with moving the
authors listed in MODULE_AUTHOR() into the header?

If it was up to me, I would just remove the MODULE_* parts and if I need
to look up the author, git log is my friend.

> 
> I've not re-done build coverage on this yet, but let me know if this is
> what you'd prefer.
> 
> Thanks,
> Paul
> --
> 
>  From 3f8bf38bcdbf38484182222965aac2748cc1d5cd Mon Sep 17 00:00:00 2001
> From: Paul Gortmaker <paul.gortmaker at windriver.com>
> Date: Mon, 31 Aug 2015 17:35:47 -0400
> Subject: [PATCH] pinctrl: bcm: clean up modular vs. non-modular distinctions
> 
> Fixups here tend to be more of a conglomerate of some of the other
> repeated/systematic ones we've seen in the earlier pinctrl cleanups.
> 
> We remove module.h from code that isn't doing anything modular at
> all;  if they have __init sections, then replace it with init.h
> 
> One driver has a .remove that would be dispatched on module_exit,
> and as that code is essentially orphaned, so we remove it.  In case
> anyone was previously doing the (pointless) unbind to get to that
> function, we disable unbind for this one driver as well.
> 
> A couple bool drivers (hence non-modular) are converted over to
> to builtin_platform_driver().
> 
> Since module_platform_driver() uses the same init level priority as
> builtin_platform_driver() the init ordering remains unchanged with
> this commit.
> 
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We leave the MODULE_AUTHOR and MODULE_LICENSE tag etc. at the bottom
> of the file since Broadcom would prefer the comment block at the top
> of the file remain unchanged.  We just use CPP to take it out of the
> picture with an #if 0 / #endif instead.
> 
> Cc: Eric Anholt <eric at anholt.net>
> Cc: Florian Fainelli <f.fainelli at gmail.com>
> Cc: Jon Mason <jonmason at broadcom.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Ray Jui <rjui at broadcom.com>
> Cc: Scott Branden <sbranden at broadcom.com>
> Cc: Stefan Wahren <stefan.wahren at i2se.com>
> Cc: Sherman Yin <syin at broadcom.com>
> Cc: bcm-kernel-feedback-list at broadcom.com
> Cc: linux-gpio at vger.kernel.org
> Cc: linux-rpi-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> ---
>  drivers/pinctrl/bcm/pinctrl-bcm281xx.c   |  7 ++++---
>  drivers/pinctrl/bcm/pinctrl-bcm2835.c    | 18 +++++-------------
>  drivers/pinctrl/bcm/pinctrl-cygnus-mux.c |  3 ++-
>  3 files changed, 11 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
> index 810a81786f62..cc01acc988d0 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
> @@ -12,7 +12,7 @@
>   */
>  #include <linux/err.h>
>  #include <linux/io.h>
> -#include <linux/module.h>
> +#include <linux/init.h>
>  #include <linux/of.h>
>  #include <linux/platform_device.h>
>  #include <linux/pinctrl/pinctrl.h>
> @@ -1444,10 +1444,11 @@ static struct platform_driver bcm281xx_pinctrl_driver = {
>  		.of_match_table = bcm281xx_pinctrl_of_match,
>  	},
>  };
> +builtin_platform_driver_probe(bcm281xx_pinctrl_driver, bcm281xx_pinctrl_probe);
>  
> -module_platform_driver_probe(bcm281xx_pinctrl_driver, bcm281xx_pinctrl_probe);
> -
> +#if 0 /* ...def MODULE ; never supported as such; kept for documentation. */
>  MODULE_AUTHOR("Broadcom Corporation <bcm-kernel-feedback-list at broadcom.com>");
>  MODULE_AUTHOR("Sherman Yin <syin at broadcom.com>");
>  MODULE_DESCRIPTION("Broadcom BCM281xx pinctrl driver");
>  MODULE_LICENSE("GPL v2");
> +#endif
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index 85d009112864..3924ff17e955 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> @@ -27,7 +27,7 @@
>  #include <linux/io.h>
>  #include <linux/irq.h>
>  #include <linux/irqdesc.h>
> -#include <linux/module.h>
> +#include <linux/init.h>
>  #include <linux/of_address.h>
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
> @@ -1075,31 +1075,23 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
>  	return 0;
>  }
>  
> -static int bcm2835_pinctrl_remove(struct platform_device *pdev)
> -{
> -	struct bcm2835_pinctrl *pc = platform_get_drvdata(pdev);
> -
> -	gpiochip_remove(&pc->gpio_chip);
> -
> -	return 0;
> -}
> -
>  static const struct of_device_id bcm2835_pinctrl_match[] = {
>  	{ .compatible = "brcm,bcm2835-gpio" },
>  	{}
>  };
> -MODULE_DEVICE_TABLE(of, bcm2835_pinctrl_match);
>  
>  static struct platform_driver bcm2835_pinctrl_driver = {
>  	.probe = bcm2835_pinctrl_probe,
> -	.remove = bcm2835_pinctrl_remove,
>  	.driver = {
>  		.name = MODULE_NAME,
>  		.of_match_table = bcm2835_pinctrl_match,
> +		.suppress_bind_attrs = true,
>  	},
>  };
> -module_platform_driver(bcm2835_pinctrl_driver);
> +builtin_platform_driver(bcm2835_pinctrl_driver);
>  
> +#if 0 /* ...def MODULE ; never supported as such; kept for documentation. */
>  MODULE_AUTHOR("Chris Boot, Simon Arlott, Stephen Warren");
>  MODULE_DESCRIPTION("BCM2835 Pin control driver");
>  MODULE_LICENSE("GPL");
> +#endif
> diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
> index d31c95701a92..84c2a182a5b7 100644
> --- a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
> +++ b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
> @@ -17,7 +17,6 @@
>  
>  #include <linux/err.h>
>  #include <linux/io.h>
> -#include <linux/module.h>
>  #include <linux/of.h>
>  #include <linux/slab.h>
>  #include <linux/platform_device.h>
> @@ -1017,6 +1016,8 @@ static int __init cygnus_pinmux_init(void)
>  }
>  arch_initcall(cygnus_pinmux_init);
>  
> +#if 0 /* ...def MODULE ; never supported as such; kept for documentation. */
>  MODULE_AUTHOR("Ray Jui <rjui at broadcom.com>");
>  MODULE_DESCRIPTION("Broadcom Cygnus IOMUX driver");
>  MODULE_LICENSE("GPL v2");
> +#endif
> 


-- 
Florian


From scott.branden at broadcom.com  Tue May 23 17:34:18 2017
From: scott.branden at broadcom.com (Scott Branden)
Date: Tue, 23 May 2017 17:34:18 -0700
Subject: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular
 distinctions
In-Reply-To: <20170524001230.GJ11504@windriver.com>
References: <20170522205648.23545-1-paul.gortmaker@windriver.com>
 <20170522205648.23545-4-paul.gortmaker@windriver.com>
 <804d9519-5e1b-d9b1-4591-010dcafa2ff1@broadcom.com>
 <20170524001230.GJ11504@windriver.com>
Message-ID: <9bd56644-48b4-3765-3fb7-ccd4353daf9f@broadcom.com>

Hi Paul,


On 17-05-23 05:12 PM, Paul Gortmaker wrote:
> [Re: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular distinctions] On 23/05/2017 (Tue 15:15) Scott Branden wrote:
>
>> Hi Paul,
>>
>> Some comments - leave our file headers intact.  If you want to add a new
>> comment do so after the existing file header in another comment.  But, I
>> don't think any of that information is needed by us.
> OK, no problem, if that is what is desired for your driver.  I just
> normally move the author information from the bottom of the file to the
> top of the file.  As a lot of the linux driver work was (is?) done for
> kudos and not for career, I can't just delete author information.  That
> would not be fair to most of those contributors.
>
> It hasn't been a problem before in all of the other similar commits I've
> made, but I can imagine a tool that does a check on the comment block on
> the top of a file and complains if it changes, or similar.
>
> Would you prefer something like this instead?  It leaves your header
> completely untouched, and still gives credit to the original author,
> and those lines are also untouched.
I don't think you should add #if 0 in the code either.  Otherwise a
search for stale code in #if 0's will have these searches come up.

How about just a regular style comment giving kudos to the author if you
so desire.  Just move your original comment into a new comment block 
after the header.
>
> I've not re-done build coverage on this yet, but let me know if this is
> what you'd prefer.
>
> Thanks,
> Paul
> --
>
>   From 3f8bf38bcdbf38484182222965aac2748cc1d5cd Mon Sep 17 00:00:00 2001
> From: Paul Gortmaker <paul.gortmaker at windriver.com>
> Date: Mon, 31 Aug 2015 17:35:47 -0400
> Subject: [PATCH] pinctrl: bcm: clean up modular vs. non-modular distinctions
>
> Fixups here tend to be more of a conglomerate of some of the other
> repeated/systematic ones we've seen in the earlier pinctrl cleanups.
>
> We remove module.h from code that isn't doing anything modular at
> all;  if they have __init sections, then replace it with init.h
>
> One driver has a .remove that would be dispatched on module_exit,
> and as that code is essentially orphaned, so we remove it.  In case
> anyone was previously doing the (pointless) unbind to get to that
> function, we disable unbind for this one driver as well.
>
> A couple bool drivers (hence non-modular) are converted over to
> to builtin_platform_driver().
>
> Since module_platform_driver() uses the same init level priority as
> builtin_platform_driver() the init ordering remains unchanged with
> this commit.
>
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>
> We leave the MODULE_AUTHOR and MODULE_LICENSE tag etc. at the bottom
> of the file since Broadcom would prefer the comment block at the top
> of the file remain unchanged.  We just use CPP to take it out of the
> picture with an #if 0 / #endif instead.
>
> Cc: Eric Anholt <eric at anholt.net>
> Cc: Florian Fainelli <f.fainelli at gmail.com>
> Cc: Jon Mason <jonmason at broadcom.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Ray Jui <rjui at broadcom.com>
> Cc: Scott Branden <sbranden at broadcom.com>
> Cc: Stefan Wahren <stefan.wahren at i2se.com>
> Cc: Sherman Yin <syin at broadcom.com>
> Cc: bcm-kernel-feedback-list at broadcom.com
> Cc: linux-gpio at vger.kernel.org
> Cc: linux-rpi-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> ---
>   drivers/pinctrl/bcm/pinctrl-bcm281xx.c   |  7 ++++---
>   drivers/pinctrl/bcm/pinctrl-bcm2835.c    | 18 +++++-------------
>   drivers/pinctrl/bcm/pinctrl-cygnus-mux.c |  3 ++-
>   3 files changed, 11 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
> index 810a81786f62..cc01acc988d0 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
> @@ -12,7 +12,7 @@
>    */
>   #include <linux/err.h>
>   #include <linux/io.h>
> -#include <linux/module.h>
> +#include <linux/init.h>
>   #include <linux/of.h>
>   #include <linux/platform_device.h>
>   #include <linux/pinctrl/pinctrl.h>
> @@ -1444,10 +1444,11 @@ static struct platform_driver bcm281xx_pinctrl_driver = {
>   		.of_match_table = bcm281xx_pinctrl_of_match,
>   	},
>   };
> +builtin_platform_driver_probe(bcm281xx_pinctrl_driver, bcm281xx_pinctrl_probe);
>   
> -module_platform_driver_probe(bcm281xx_pinctrl_driver, bcm281xx_pinctrl_probe);
> -
> +#if 0 /* ...def MODULE ; never supported as such; kept for documentation. */
>   MODULE_AUTHOR("Broadcom Corporation <bcm-kernel-feedback-list at broadcom.com>");
>   MODULE_AUTHOR("Sherman Yin <syin at broadcom.com>");
>   MODULE_DESCRIPTION("Broadcom BCM281xx pinctrl driver");
>   MODULE_LICENSE("GPL v2");
> +#endif
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index 85d009112864..3924ff17e955 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> @@ -27,7 +27,7 @@
>   #include <linux/io.h>
>   #include <linux/irq.h>
>   #include <linux/irqdesc.h>
> -#include <linux/module.h>
> +#include <linux/init.h>
>   #include <linux/of_address.h>
>   #include <linux/of.h>
>   #include <linux/of_irq.h>
> @@ -1075,31 +1075,23 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
>   	return 0;
>   }
>   
> -static int bcm2835_pinctrl_remove(struct platform_device *pdev)
> -{
> -	struct bcm2835_pinctrl *pc = platform_get_drvdata(pdev);
> -
> -	gpiochip_remove(&pc->gpio_chip);
> -
> -	return 0;
> -}
> -
>   static const struct of_device_id bcm2835_pinctrl_match[] = {
>   	{ .compatible = "brcm,bcm2835-gpio" },
>   	{}
>   };
> -MODULE_DEVICE_TABLE(of, bcm2835_pinctrl_match);
>   
>   static struct platform_driver bcm2835_pinctrl_driver = {
>   	.probe = bcm2835_pinctrl_probe,
> -	.remove = bcm2835_pinctrl_remove,
>   	.driver = {
>   		.name = MODULE_NAME,
>   		.of_match_table = bcm2835_pinctrl_match,
> +		.suppress_bind_attrs = true,
>   	},
>   };
> -module_platform_driver(bcm2835_pinctrl_driver);
> +builtin_platform_driver(bcm2835_pinctrl_driver);
>   
> +#if 0 /* ...def MODULE ; never supported as such; kept for documentation. */
>   MODULE_AUTHOR("Chris Boot, Simon Arlott, Stephen Warren");
>   MODULE_DESCRIPTION("BCM2835 Pin control driver");
>   MODULE_LICENSE("GPL");
> +#endif
> diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
> index d31c95701a92..84c2a182a5b7 100644
> --- a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
> +++ b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
> @@ -17,7 +17,6 @@
>   
>   #include <linux/err.h>
>   #include <linux/io.h>
> -#include <linux/module.h>
>   #include <linux/of.h>
>   #include <linux/slab.h>
>   #include <linux/platform_device.h>
> @@ -1017,6 +1016,8 @@ static int __init cygnus_pinmux_init(void)
>   }
>   arch_initcall(cygnus_pinmux_init);
>   
> +#if 0 /* ...def MODULE ; never supported as such; kept for documentation. */
>   MODULE_AUTHOR("Ray Jui <rjui at broadcom.com>");
>   MODULE_DESCRIPTION("Broadcom Cygnus IOMUX driver");
>   MODULE_LICENSE("GPL v2");
> +#endif



From scott.branden at broadcom.com  Tue May 23 17:37:35 2017
From: scott.branden at broadcom.com (Scott Branden)
Date: Tue, 23 May 2017 17:37:35 -0700
Subject: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular
 distinctions
In-Reply-To: <f653cf1f-87d9-7549-6e3b-aa0ca388579c@gmail.com>
References: <20170522205648.23545-1-paul.gortmaker@windriver.com>
 <20170522205648.23545-4-paul.gortmaker@windriver.com>
 <804d9519-5e1b-d9b1-4591-010dcafa2ff1@broadcom.com>
 <20170524001230.GJ11504@windriver.com>
 <f653cf1f-87d9-7549-6e3b-aa0ca388579c@gmail.com>
Message-ID: <89839690-ab46-c091-dff6-30b50aea499b@broadcom.com>



On 17-05-23 05:25 PM, Florian Fainelli wrote:
> On 05/23/2017 05:12 PM, Paul Gortmaker wrote:
>> [Re: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular distinctions] On 23/05/2017 (Tue 15:15) Scott Branden wrote:
>>
>>> Hi Paul,
>>>
>>> Some comments - leave our file headers intact.  If you want to add a new
>>> comment do so after the existing file header in another comment.  But, I
>>> don't think any of that information is needed by us.
>> OK, no problem, if that is what is desired for your driver.  I just
>> normally move the author information from the bottom of the file to the
>> top of the file.  As a lot of the linux driver work was (is?) done for
>> kudos and not for career, I can't just delete author information.  That
>> would not be fair to most of those contributors.
>>
>> It hasn't been a problem before in all of the other similar commits I've
>> made, but I can imagine a tool that does a check on the comment block on
>> the top of a file and complains if it changes, or similar.
>>
>> Would you prefer something like this instead?  It leaves your header
>> completely untouched, and still gives credit to the original author,
>> and those lines are also untouched.
> This looks horrible, sorry. Scott, what's the matter with moving the
> authors listed in MODULE_AUTHOR() into the header?
We have tools for scanning headers.  Mucking with the headers
is not desirable as tools may need to change.  Just place additional
comments in new comments blocks.
>
> If it was up to me, I would just remove the MODULE_* parts and if I need
> to look up the author, git log is my friend.
>
>> I've not re-done build coverage on this yet, but let me know if this is
>> what you'd prefer.
>>
>> Thanks,
>> Paul
>> --
>>
>>   From 3f8bf38bcdbf38484182222965aac2748cc1d5cd Mon Sep 17 00:00:00 2001
>> From: Paul Gortmaker <paul.gortmaker at windriver.com>
>> Date: Mon, 31 Aug 2015 17:35:47 -0400
>> Subject: [PATCH] pinctrl: bcm: clean up modular vs. non-modular distinctions
>>
>> Fixups here tend to be more of a conglomerate of some of the other
>> repeated/systematic ones we've seen in the earlier pinctrl cleanups.
>>
>> We remove module.h from code that isn't doing anything modular at
>> all;  if they have __init sections, then replace it with init.h
>>
>> One driver has a .remove that would be dispatched on module_exit,
>> and as that code is essentially orphaned, so we remove it.  In case
>> anyone was previously doing the (pointless) unbind to get to that
>> function, we disable unbind for this one driver as well.
>>
>> A couple bool drivers (hence non-modular) are converted over to
>> to builtin_platform_driver().
>>
>> Since module_platform_driver() uses the same init level priority as
>> builtin_platform_driver() the init ordering remains unchanged with
>> this commit.
>>
>> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>>
>> We leave the MODULE_AUTHOR and MODULE_LICENSE tag etc. at the bottom
>> of the file since Broadcom would prefer the comment block at the top
>> of the file remain unchanged.  We just use CPP to take it out of the
>> picture with an #if 0 / #endif instead.
>>
>> Cc: Eric Anholt <eric at anholt.net>
>> Cc: Florian Fainelli <f.fainelli at gmail.com>
>> Cc: Jon Mason <jonmason at broadcom.com>
>> Cc: Linus Walleij <linus.walleij at linaro.org>
>> Cc: Ray Jui <rjui at broadcom.com>
>> Cc: Scott Branden <sbranden at broadcom.com>
>> Cc: Stefan Wahren <stefan.wahren at i2se.com>
>> Cc: Sherman Yin <syin at broadcom.com>
>> Cc: bcm-kernel-feedback-list at broadcom.com
>> Cc: linux-gpio at vger.kernel.org
>> Cc: linux-rpi-kernel at lists.infradead.org
>> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
>> ---
>>   drivers/pinctrl/bcm/pinctrl-bcm281xx.c   |  7 ++++---
>>   drivers/pinctrl/bcm/pinctrl-bcm2835.c    | 18 +++++-------------
>>   drivers/pinctrl/bcm/pinctrl-cygnus-mux.c |  3 ++-
>>   3 files changed, 11 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
>> index 810a81786f62..cc01acc988d0 100644
>> --- a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
>> +++ b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
>> @@ -12,7 +12,7 @@
>>    */
>>   #include <linux/err.h>
>>   #include <linux/io.h>
>> -#include <linux/module.h>
>> +#include <linux/init.h>
>>   #include <linux/of.h>
>>   #include <linux/platform_device.h>
>>   #include <linux/pinctrl/pinctrl.h>
>> @@ -1444,10 +1444,11 @@ static struct platform_driver bcm281xx_pinctrl_driver = {
>>   		.of_match_table = bcm281xx_pinctrl_of_match,
>>   	},
>>   };
>> +builtin_platform_driver_probe(bcm281xx_pinctrl_driver, bcm281xx_pinctrl_probe);
>>   
>> -module_platform_driver_probe(bcm281xx_pinctrl_driver, bcm281xx_pinctrl_probe);
>> -
>> +#if 0 /* ...def MODULE ; never supported as such; kept for documentation. */
>>   MODULE_AUTHOR("Broadcom Corporation <bcm-kernel-feedback-list at broadcom.com>");
>>   MODULE_AUTHOR("Sherman Yin <syin at broadcom.com>");
>>   MODULE_DESCRIPTION("Broadcom BCM281xx pinctrl driver");
>>   MODULE_LICENSE("GPL v2");
>> +#endif
>> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> index 85d009112864..3924ff17e955 100644
>> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> @@ -27,7 +27,7 @@
>>   #include <linux/io.h>
>>   #include <linux/irq.h>
>>   #include <linux/irqdesc.h>
>> -#include <linux/module.h>
>> +#include <linux/init.h>
>>   #include <linux/of_address.h>
>>   #include <linux/of.h>
>>   #include <linux/of_irq.h>
>> @@ -1075,31 +1075,23 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
>>   	return 0;
>>   }
>>   
>> -static int bcm2835_pinctrl_remove(struct platform_device *pdev)
>> -{
>> -	struct bcm2835_pinctrl *pc = platform_get_drvdata(pdev);
>> -
>> -	gpiochip_remove(&pc->gpio_chip);
>> -
>> -	return 0;
>> -}
>> -
>>   static const struct of_device_id bcm2835_pinctrl_match[] = {
>>   	{ .compatible = "brcm,bcm2835-gpio" },
>>   	{}
>>   };
>> -MODULE_DEVICE_TABLE(of, bcm2835_pinctrl_match);
>>   
>>   static struct platform_driver bcm2835_pinctrl_driver = {
>>   	.probe = bcm2835_pinctrl_probe,
>> -	.remove = bcm2835_pinctrl_remove,
>>   	.driver = {
>>   		.name = MODULE_NAME,
>>   		.of_match_table = bcm2835_pinctrl_match,
>> +		.suppress_bind_attrs = true,
>>   	},
>>   };
>> -module_platform_driver(bcm2835_pinctrl_driver);
>> +builtin_platform_driver(bcm2835_pinctrl_driver);
>>   
>> +#if 0 /* ...def MODULE ; never supported as such; kept for documentation. */
>>   MODULE_AUTHOR("Chris Boot, Simon Arlott, Stephen Warren");
>>   MODULE_DESCRIPTION("BCM2835 Pin control driver");
>>   MODULE_LICENSE("GPL");
>> +#endif
>> diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
>> index d31c95701a92..84c2a182a5b7 100644
>> --- a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
>> +++ b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
>> @@ -17,7 +17,6 @@
>>   
>>   #include <linux/err.h>
>>   #include <linux/io.h>
>> -#include <linux/module.h>
>>   #include <linux/of.h>
>>   #include <linux/slab.h>
>>   #include <linux/platform_device.h>
>> @@ -1017,6 +1016,8 @@ static int __init cygnus_pinmux_init(void)
>>   }
>>   arch_initcall(cygnus_pinmux_init);
>>   
>> +#if 0 /* ...def MODULE ; never supported as such; kept for documentation. */
>>   MODULE_AUTHOR("Ray Jui <rjui at broadcom.com>");
>>   MODULE_DESCRIPTION("Broadcom Cygnus IOMUX driver");
>>   MODULE_LICENSE("GPL v2");
>> +#endif
>>
>



From f.fainelli at gmail.com  Tue May 23 17:42:39 2017
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 23 May 2017 17:42:39 -0700
Subject: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular
 distinctions
In-Reply-To: <89839690-ab46-c091-dff6-30b50aea499b@broadcom.com>
References: <20170522205648.23545-1-paul.gortmaker@windriver.com>
 <20170522205648.23545-4-paul.gortmaker@windriver.com>
 <804d9519-5e1b-d9b1-4591-010dcafa2ff1@broadcom.com>
 <20170524001230.GJ11504@windriver.com>
 <f653cf1f-87d9-7549-6e3b-aa0ca388579c@gmail.com>
 <89839690-ab46-c091-dff6-30b50aea499b@broadcom.com>
Message-ID: <290c657d-5c40-882a-5a74-b5844709ada5@gmail.com>

On 05/23/2017 05:37 PM, Scott Branden wrote:
> 
> 
> On 17-05-23 05:25 PM, Florian Fainelli wrote:
>> On 05/23/2017 05:12 PM, Paul Gortmaker wrote:
>>> [Re: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular
>>> distinctions] On 23/05/2017 (Tue 15:15) Scott Branden wrote:
>>>
>>>> Hi Paul,
>>>>
>>>> Some comments - leave our file headers intact.  If you want to add a
>>>> new
>>>> comment do so after the existing file header in another comment. 
>>>> But, I
>>>> don't think any of that information is needed by us.
>>> OK, no problem, if that is what is desired for your driver.  I just
>>> normally move the author information from the bottom of the file to the
>>> top of the file.  As a lot of the linux driver work was (is?) done for
>>> kudos and not for career, I can't just delete author information.  That
>>> would not be fair to most of those contributors.
>>>
>>> It hasn't been a problem before in all of the other similar commits I've
>>> made, but I can imagine a tool that does a check on the comment block on
>>> the top of a file and complains if it changes, or similar.
>>>
>>> Would you prefer something like this instead?  It leaves your header
>>> completely untouched, and still gives credit to the original author,
>>> and those lines are also untouched.
>> This looks horrible, sorry. Scott, what's the matter with moving the
>> authors listed in MODULE_AUTHOR() into the header?
> We have tools for scanning headers.  Mucking with the headers
> is not desirable as tools may need to change.  Just place additional
> comments in new comments blocks.

That's a pretty moot explanation. These tools will have to deal with
random changes being done to the kernel as the project keeps seeing more
changes.

Plus, you may get Paul to do what you him to do here and not put
anything in the header, but there is no guarantee someone else won't be
doing it, and even if you are CC'd on the patches, what if you are not,
and what if you can't defend this "breaks our tools" position, does not
scale to me.

If it's an internal tool, it can certainly be fixed, if it's coming from
an external vendor, I'd be seriously concerned if their scanning/logic
started to break in 4.13 because Paul's patches got included...

At any rate, I'd just drop the MODULE_AUTHOR() altogether, we can use
the SCM to tell us who did what exactly in a much more powerful way
(like line by line).
-- 
Florian


From gregkh at linuxfoundation.org  Thu May 25 09:35:37 2017
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 25 May 2017 18:35:37 +0200
Subject: [PATCH 09/16] staging: vchiq_core: Simplify VCHIQ init
In-Reply-To: <771147548.673176.1495315833864@email.1und1.de>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
 <1495282933-13271-10-git-send-email-stefan.wahren@i2se.com>
 <771147548.673176.1495315833864@email.1und1.de>
Message-ID: <20170525163537.GA13376@kroah.com>

On Sat, May 20, 2017 at 11:30:33PM +0200, Stefan Wahren wrote:
> 
> > Stefan Wahren <stefan.wahren at i2se.com> hat am 20. Mai 2017 um 14:22 geschrieben:
> > 
> > 
> > Since the ARM side of VCHIQ support only 1 state, we could simplify
> > the init code. This makes it possible to avoid BUG_ON and a theoretical
> > overflow of id.
> > 
> > Signed-off-by: Stefan Wahren <stefan at i2se.com>
> 
> It should be
> 
> Stefan Wahren <stefan.wahren at i2se.com>

I don't want to hand-edit these patches, can you please fix up and
resend v2 of the series?

thanks,

greg k-h


From stefan.wahren at i2se.com  Thu May 25 15:02:04 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:02:04 +0200 (CEST)
Subject: [PATCH 09/16] staging: vchiq_core: Simplify VCHIQ init
In-Reply-To: <20170525163537.GA13376@kroah.com>
References: <1495282933-13271-1-git-send-email-stefan.wahren@i2se.com>
 <1495282933-13271-10-git-send-email-stefan.wahren@i2se.com>
 <771147548.673176.1495315833864@email.1und1.de>
 <20170525163537.GA13376@kroah.com>
Message-ID: <1541502727.711746.1495749724925@email.1und1.de>


> Greg Kroah-Hartman <gregkh at linuxfoundation.org> hat am 25. Mai 2017 um 18:35 geschrieben:
> 
> 
> On Sat, May 20, 2017 at 11:30:33PM +0200, Stefan Wahren wrote:
> > 
> > > Stefan Wahren <stefan.wahren at i2se.com> hat am 20. Mai 2017 um 14:22 geschrieben:
> > > 
> > > 
> > > Since the ARM side of VCHIQ support only 1 state, we could simplify
> > > the init code. This makes it possible to avoid BUG_ON and a theoretical
> > > overflow of id.
> > > 
> > > Signed-off-by: Stefan Wahren <stefan at i2se.com>
> > 
> > It should be
> > 
> > Stefan Wahren <stefan.wahren at i2se.com>
> 
> I don't want to hand-edit these patches, can you please fix up and
> resend v2 of the series?

Sure, this was just a kind sorry. I will send a v2 soon.

> 
> thanks,
> 
> greg k-h


From stefan.wahren at i2se.com  Thu May 25 15:26:14 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:14 +0200
Subject: [PATCH v2 04/16] staging: vchiq_arm: Fix variable names in comment
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-5-git-send-email-stefan.wahren@i2se.com>

This comment was apparently forgotten in the correction of CamelCase.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index e823f1d..49d1ee2 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -2070,7 +2070,7 @@ dump_phys_mem(void *virt_addr, u32 num_bytes)
 	struct page  **pages;
 	u8            *kmapped_virt_ptr;
 
-	/* Align virtAddr and endVirtAddr to 16 byte boundaries. */
+	/* Align virt_addr and end_virt_addr to 16 byte boundaries. */
 
 	virt_addr = (void *)((unsigned long)virt_addr & ~0x0fuL);
 	end_virt_addr = (void *)(((unsigned long)end_virt_addr + 15uL) &
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:12 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:12 +0200
Subject: [PATCH v2 02/16] staging: vchiq_2835_arm: Reduce scope of i in
 free_pagelist
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-3-git-send-email-stefan.wahren@i2se.com>

We can reduce the scope of the counting variable i. This has
been found by CppCheck.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index d04db3f..9105545 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -577,7 +577,6 @@ static void
 free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
 	      int actual)
 {
-	unsigned int i;
 	PAGELIST_T *pagelist   = pagelistinfo->pagelist;
 	struct page **pages    = pagelistinfo->pages;
 	unsigned int num_pages = pagelistinfo->num_pages;
@@ -633,6 +632,8 @@ free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
 	/* Need to mark all the pages dirty. */
 	if (pagelist->type != PAGELIST_WRITE &&
 	    pagelistinfo->pages_need_release) {
+		unsigned int i;
+
 		for (i = 0; i < num_pages; i++)
 			set_page_dirty(pages[i]);
 	}
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:23 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:23 +0200
Subject: [PATCH v2 13/16] staging: vchiq_core: Bail out if ref_count is
 unexpected
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-14-git-send-email-stefan.wahren@i2se.com>

If the ref counter of service has an unexpected value then we better
bail out.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 .../vc04_services/interface/vchiq_arm/vchiq_core.c      | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index a84b4ef3..9cdc9857 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -175,7 +175,7 @@ find_service_by_handle(VCHIQ_SERVICE_HANDLE_T handle)
 	service = handle_to_service(handle);
 	if (service && (service->srvstate != VCHIQ_SRVSTATE_FREE) &&
 		(service->handle == handle)) {
-		BUG_ON(service->ref_count == 0);
+		WARN_ON(service->ref_count == 0);
 		service->ref_count++;
 	} else
 		service = NULL;
@@ -197,7 +197,7 @@ find_service_by_port(VCHIQ_STATE_T *state, int localport)
 		spin_lock(&service_spinlock);
 		service = state->services[localport];
 		if (service && (service->srvstate != VCHIQ_SRVSTATE_FREE)) {
-			BUG_ON(service->ref_count == 0);
+			WARN_ON(service->ref_count == 0);
 			service->ref_count++;
 		} else
 			service = NULL;
@@ -221,7 +221,7 @@ find_service_for_instance(VCHIQ_INSTANCE_T instance,
 	if (service && (service->srvstate != VCHIQ_SRVSTATE_FREE) &&
 		(service->handle == handle) &&
 		(service->instance == instance)) {
-		BUG_ON(service->ref_count == 0);
+		WARN_ON(service->ref_count == 0);
 		service->ref_count++;
 	} else
 		service = NULL;
@@ -246,7 +246,7 @@ find_closed_service_for_instance(VCHIQ_INSTANCE_T instance,
 		 (service->srvstate == VCHIQ_SRVSTATE_CLOSED)) &&
 		(service->handle == handle) &&
 		(service->instance == instance)) {
-		BUG_ON(service->ref_count == 0);
+		WARN_ON(service->ref_count == 0);
 		service->ref_count++;
 	} else
 		service = NULL;
@@ -273,7 +273,7 @@ next_service_by_instance(VCHIQ_STATE_T *state, VCHIQ_INSTANCE_T instance,
 		if (srv && (srv->srvstate != VCHIQ_SRVSTATE_FREE) &&
 			(srv->instance == instance)) {
 			service = srv;
-			BUG_ON(service->ref_count == 0);
+			WARN_ON(service->ref_count == 0);
 			service->ref_count++;
 			break;
 		}
@@ -291,7 +291,7 @@ lock_service(VCHIQ_SERVICE_T *service)
 	spin_lock(&service_spinlock);
 	WARN_ON(!service);
 	if (service) {
-		BUG_ON(service->ref_count == 0);
+		WARN_ON(service->ref_count == 0);
 		service->ref_count++;
 	}
 	spin_unlock(&service_spinlock);
@@ -305,7 +305,10 @@ unlock_service(VCHIQ_SERVICE_T *service)
 		WARN(1, "%s: service is NULL\n", __func__);
 		goto unlock;
 	}
-	BUG_ON(service->ref_count == 0);
+	if (!service->ref_count) {
+		WARN(1, "%s: ref_count is zero\n", __func__);
+		goto unlock;
+	}
 	service->ref_count--;
 	if (!service->ref_count) {
 		VCHIQ_STATE_T *state = service->state;
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:10 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:10 +0200
Subject: [PATCH v2 00/16] staging: vchiq_arm: several cleanups
Message-ID: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>

This patch series addresses mostly minor issues. It's based on top of
the latest vchiq bugfix [1].

[1] - https://lkml.org/lkml/2017/5/4/228

Changes in v2:
* fix the signed-off-by in patches 8 and 9

Stefan Wahren (16):
  staging: vchiq_core: Use return value of mutex_lock_killable directly
  staging: vchiq_2835_arm: Reduce scope of i in free_pagelist
  staging: vchiq_2835_arm: Remove unnecessary assignment to
    slot_mem_size
  staging: vchiq_arm: Fix variable names in comment
  staging: vchiq_arm: Avoid multiline dereference
  staging: vchiq_2835_arm: Fix function name cleaup_pagelistinfo
  staging: vchiq_2835_arm: Handle vmalloc_to_page error case
  staging: vchiq_2835_arm: Use PAGE_MASK macro
  staging: vchiq_core: Simplify VCHIQ init
  staging: vchiq_core: Bailout if VCHIQ state is already initialized
  staging: vchiq_core: Don't BUG if sending RESUME fails
  staging: vchiq_core: Bail out if service is NULL
  staging: vchiq_core: Bail out if ref_count is unexpected
  staging: vchiq_core: Don't BUG if process is unexpected
  staging: vchiq_core: Bail out in case of invalid tx_pos
  staging: vchiq_core: Replace remaining BUG_ON with WARN_ON

 .../interface/vchiq_arm/vchiq_2835_arm.c           | 21 +++--
 .../vc04_services/interface/vchiq_arm/vchiq_arm.c  | 14 ++--
 .../vc04_services/interface/vchiq_arm/vchiq_core.c | 95 +++++++++++++---------
 3 files changed, 77 insertions(+), 53 deletions(-)

-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:24 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:24 +0200
Subject: [PATCH v2 14/16] staging: vchiq_core: Don't BUG if process is
 unexpected
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-15-git-send-email-stefan.wahren@i2se.com>

Bail out properly if the process index doesn't match the remote insert.
We also drop the BUG in case the process index is at local insert,
so we can trigger the WARN_ON again some steps later.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 .../staging/vc04_services/interface/vchiq_arm/vchiq_core.c    | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 9cdc9857..b0119b8 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -1963,9 +1963,14 @@ parse_rx_slots(VCHIQ_STATE_T *state)
 					mutex_unlock(&service->bulk_mutex);
 					break;
 				}
-
-				BUG_ON(queue->process == queue->local_insert);
-				BUG_ON(queue->process != queue->remote_insert);
+				if (queue->process != queue->remote_insert) {
+					pr_err("%s: p %x != ri %x\n",
+					       __func__,
+					       queue->process,
+					       queue->remote_insert);
+					mutex_unlock(&service->bulk_mutex);
+					goto bail_not_ready;
+				}
 
 				bulk = &queue->bulks[
 					BULK_INDEX(queue->remote_insert)];
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:19 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:19 +0200
Subject: [PATCH v2 09/16] staging: vchiq_core: Simplify VCHIQ init
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-10-git-send-email-stefan.wahren@i2se.com>

Since the ARM side of VCHIQ support only 1 state, we could simplify
the init code. This makes it possible to avoid BUG_ON and a theoretical
overflow of id.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 6b24651..c47de96 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -2349,7 +2349,6 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero,
 	VCHIQ_SHARED_STATE_T *remote;
 	VCHIQ_STATUS_T status;
 	char threadname[16];
-	static int id;
 	int i;
 
 	vchiq_log_warning(vchiq_core_log_level,
@@ -2437,7 +2436,6 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero,
 
 	memset(state, 0, sizeof(VCHIQ_STATE_T));
 
-	state->id = id++;
 	state->is_master = is_master;
 
 	/*
@@ -2556,8 +2554,7 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero,
 	set_user_nice(state->sync_thread, -20);
 	wake_up_process(state->sync_thread);
 
-	BUG_ON(state->id >= VCHIQ_MAX_STATES);
-	vchiq_states[state->id] = state;
+	vchiq_states[0] = state;
 
 	/* Indicate readiness to the other side */
 	local->initialised = 1;
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:17 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:17 +0200
Subject: [PATCH v2 07/16] staging: vchiq_2835_arm: Handle vmalloc_to_page
 error case
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-8-git-send-email-stefan.wahren@i2se.com>

In case vmalloc_to_page returns NULL create_pagelist must abort
imediatly.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 8911e86..eeeee1b 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -459,6 +459,11 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
 								 PAGE_SIZE));
 			size_t bytes = PAGE_SIZE - off;
 
+			if (!pg) {
+				cleanup_pagelistinfo(pagelistinfo);
+				return NULL;
+			}
+
 			if (bytes > length)
 				bytes = length;
 			pages[actual_pages] = pg;
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:13 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:13 +0200
Subject: [PATCH v2 03/16] staging: vchiq_2835_arm: Remove unnecessary
 assignment to slot_mem_size
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-4-git-send-email-stefan.wahren@i2se.com>

The variable slot_mem_size is assigned a value which is never used.
This issue has been found by CppCheck.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 9105545..9406d1c 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -153,7 +153,6 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
 		MAX_FRAGMENTS;
 
 	g_fragments_base = (char *)slot_mem + slot_mem_size;
-	slot_mem_size += frag_mem_size;
 
 	g_free_fragments = g_fragments_base;
 	for (i = 0; i < (MAX_FRAGMENTS - 1); i++) {
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:21 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:21 +0200
Subject: [PATCH v2 11/16] staging: vchiq_core: Don't BUG if sending RESUME
 fails
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-12-git-send-email-stefan.wahren@i2se.com>

VCHIQ suspend and resume isn't implemented, but even it was
there is no need to call BUG().

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 0a46e15..d40366c 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -2137,7 +2137,6 @@ slot_handler_func(void *v)
 					vchiq_log_error(vchiq_core_log_level,
 						"Failed to send RESUME "
 						"message");
-					BUG();
 				}
 				break;
 
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:25 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:25 +0200
Subject: [PATCH v2 15/16] staging: vchiq_core: Bail out in case of invalid
 tx_pos
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-16-git-send-email-stefan.wahren@i2se.com>

Properly handle the error case in case of an invalid tx_pos.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index b0119b8..c61f5ac 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -600,8 +600,10 @@ reserve_space(VCHIQ_STATE_T *state, size_t space, int is_blocking)
 				return NULL; /* No space available */
 		}
 
-		BUG_ON(tx_pos ==
-			(state->slot_queue_available * VCHIQ_SLOT_SIZE));
+		if (tx_pos == (state->slot_queue_available * VCHIQ_SLOT_SIZE)) {
+			pr_warn("%s: invalid tx_pos: %d\n", __func__, tx_pos);
+			return NULL;
+		}
 
 		slot_index = local->slot_queue[
 			SLOT_QUEUE_INDEX_FROM_POS(tx_pos) &
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:11 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:11 +0200
Subject: [PATCH v2 01/16] staging: vchiq_core: Use return value of
 mutex_lock_killable directly
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-2-git-send-email-stefan.wahren@i2se.com>

Instead of saving the return value of mutex_lock_killable in a
local variable we could use the value directly.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 4f9e738..6b24651 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -1376,7 +1376,6 @@ resolve_bulks(VCHIQ_SERVICE_T *service, VCHIQ_BULK_QUEUE_T *queue)
 {
 	VCHIQ_STATE_T *state = service->state;
 	int resolved = 0;
-	int rc;
 
 	while ((queue->process != queue->local_insert) &&
 		(queue->process != queue->remote_insert)) {
@@ -1392,8 +1391,7 @@ resolve_bulks(VCHIQ_SERVICE_T *service, VCHIQ_BULK_QUEUE_T *queue)
 		WARN_ON(!((int)(queue->local_insert - queue->process) > 0));
 		WARN_ON(!((int)(queue->remote_insert - queue->process) > 0));
 
-		rc = mutex_lock_killable(&state->bulk_transfer_mutex);
-		if (rc != 0)
+		if (mutex_lock_killable(&state->bulk_transfer_mutex))
 			break;
 
 		vchiq_transfer_bulk(bulk);
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:26 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:26 +0200
Subject: [PATCH v2 16/16] staging: vchiq_core: Replace remaining BUG_ON with
 WARN_ON
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-17-git-send-email-stefan.wahren@i2se.com>

This replaces all remaining BUG_ON with WARN_ON. So in case of
a VCHIQ bug the system is still usable.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 .../staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index c61f5ac..486be99 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -313,7 +313,7 @@ unlock_service(VCHIQ_SERVICE_T *service)
 	if (!service->ref_count) {
 		VCHIQ_STATE_T *state = service->state;
 
-		BUG_ON(service->srvstate != VCHIQ_SRVSTATE_FREE);
+		WARN_ON(service->srvstate != VCHIQ_SRVSTATE_FREE);
 		state->services[service->localport] = NULL;
 	} else {
 		service = NULL;
@@ -839,8 +839,8 @@ queue_message(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service,
 			return VCHIQ_ERROR;
 		}
 
-		BUG_ON((flags & (QMFLAGS_NO_MUTEX_LOCK |
-				 QMFLAGS_NO_MUTEX_UNLOCK)) != 0);
+		WARN_ON((flags & (QMFLAGS_NO_MUTEX_LOCK |
+				  QMFLAGS_NO_MUTEX_UNLOCK)) != 0);
 
 		if (service->closing) {
 			/* The service has been closed */
@@ -939,8 +939,8 @@ queue_message(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service,
 			header, size, VCHIQ_MSG_SRCPORT(msgid),
 			VCHIQ_MSG_DSTPORT(msgid));
 
-		BUG_ON((flags & (QMFLAGS_NO_MUTEX_LOCK |
-				 QMFLAGS_NO_MUTEX_UNLOCK)) != 0);
+		WARN_ON((flags & (QMFLAGS_NO_MUTEX_LOCK |
+				  QMFLAGS_NO_MUTEX_UNLOCK)) != 0);
 
 		callback_result =
 			copy_message_data(copy_callback, context,
@@ -3204,7 +3204,7 @@ vchiq_close_service(VCHIQ_SERVICE_HANDLE_T handle)
 	if (current == service->state->slot_handler_thread) {
 		status = vchiq_close_service_internal(service,
 			0/*!close_recvd*/);
-		BUG_ON(status == VCHIQ_RETRY);
+		WARN_ON(status == VCHIQ_RETRY);
 	} else {
 	/* Mark the service for termination by the slot handler */
 		request_poll(service->state, service, VCHIQ_POLL_TERMINATE);
@@ -3266,7 +3266,7 @@ vchiq_remove_service(VCHIQ_SERVICE_HANDLE_T handle)
 
 		status = vchiq_close_service_internal(service,
 			0/*!close_recvd*/);
-		BUG_ON(status == VCHIQ_RETRY);
+		WARN_ON(status == VCHIQ_RETRY);
 	} else {
 		/* Mark the service for removal by the slot handler */
 		request_poll(service->state, service, VCHIQ_POLL_REMOVE);
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:16 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:16 +0200
Subject: [PATCH v2 06/16] staging: vchiq_2835_arm: Fix function name
 cleaup_pagelistinfo
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-7-git-send-email-stefan.wahren@i2se.com>

Assuming the intension of the function is to clean up, so fix the function
name accordingly.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 .../staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 9406d1c..8911e86 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -364,7 +364,7 @@ vchiq_doorbell_irq(int irq, void *dev_id)
 }
 
 static void
-cleaup_pagelistinfo(struct vchiq_pagelist_info *pagelistinfo)
+cleanup_pagelistinfo(struct vchiq_pagelist_info *pagelistinfo)
 {
 	if (pagelistinfo->scatterlist_mapped) {
 		dma_unmap_sg(g_dev, pagelistinfo->scatterlist,
@@ -488,7 +488,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
 				actual_pages--;
 				put_page(pages[actual_pages]);
 			}
-			cleaup_pagelistinfo(pagelistinfo);
+			cleanup_pagelistinfo(pagelistinfo);
 			return NULL;
 		}
 		 /* release user pages */
@@ -517,7 +517,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
 				 pagelistinfo->dma_dir);
 
 	if (dma_buffers == 0) {
-		cleaup_pagelistinfo(pagelistinfo);
+		cleanup_pagelistinfo(pagelistinfo);
 		return NULL;
 	}
 
@@ -554,7 +554,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
 		char *fragments;
 
 		if (down_interruptible(&g_free_fragments_sema) != 0) {
-			cleaup_pagelistinfo(pagelistinfo);
+			cleanup_pagelistinfo(pagelistinfo);
 			return NULL;
 		}
 
@@ -637,5 +637,5 @@ free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
 			set_page_dirty(pages[i]);
 	}
 
-	cleaup_pagelistinfo(pagelistinfo);
+	cleanup_pagelistinfo(pagelistinfo);
 }
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:15 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:15 +0200
Subject: [PATCH v2 05/16] staging: vchiq_arm: Avoid multiline dereference
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-6-git-send-email-stefan.wahren@i2se.com>

Reduce the indentation within vchiq_dump_service_use_state in order
to avoid a multiline derefernce.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 .../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c    | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 49d1ee2..030bec8 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -3276,12 +3276,12 @@ vchiq_dump_service_use_state(VCHIQ_STATE_T *state)
 		if (only_nonzero && !service_ptr->service_use_count)
 			continue;
 
-		if (service_ptr->srvstate != VCHIQ_SRVSTATE_FREE) {
-			service_data[j].fourcc = service_ptr->base.fourcc;
-			service_data[j].clientid = service_ptr->client_id;
-			service_data[j++].use_count = service_ptr->
-							service_use_count;
-		}
+		if (service_ptr->srvstate == VCHIQ_SRVSTATE_FREE)
+			continue;
+
+		service_data[j].fourcc = service_ptr->base.fourcc;
+		service_data[j].clientid = service_ptr->client_id;
+		service_data[j++].use_count = service_ptr->service_use_count;
 	}
 
 	read_unlock_bh(&arm_state->susp_res_lock);
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:22 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:22 +0200
Subject: [PATCH v2 12/16] staging: vchiq_core: Bail out if service is NULL
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-13-git-send-email-stefan.wahren@i2se.com>

In the unlikely case that service is NULL we should bail out instead
of calling BUG_ON(). The other BUG_ON calls will be fixed in separate
patches.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 .../vc04_services/interface/vchiq_arm/vchiq_core.c | 38 ++++++++++++++--------
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index d40366c..a84b4ef3 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -289,9 +289,11 @@ void
 lock_service(VCHIQ_SERVICE_T *service)
 {
 	spin_lock(&service_spinlock);
-	BUG_ON(!service || (service->ref_count == 0));
-	if (service)
+	WARN_ON(!service);
+	if (service) {
+		BUG_ON(service->ref_count == 0);
 		service->ref_count++;
+	}
 	spin_unlock(&service_spinlock);
 }
 
@@ -299,17 +301,21 @@ void
 unlock_service(VCHIQ_SERVICE_T *service)
 {
 	spin_lock(&service_spinlock);
-	BUG_ON(!service || (service->ref_count == 0));
-	if (service && service->ref_count) {
-		service->ref_count--;
-		if (!service->ref_count) {
-			VCHIQ_STATE_T *state = service->state;
-
-			BUG_ON(service->srvstate != VCHIQ_SRVSTATE_FREE);
-			state->services[service->localport] = NULL;
-		} else
-			service = NULL;
+	if (!service) {
+		WARN(1, "%s: service is NULL\n", __func__);
+		goto unlock;
 	}
+	BUG_ON(service->ref_count == 0);
+	service->ref_count--;
+	if (!service->ref_count) {
+		VCHIQ_STATE_T *state = service->state;
+
+		BUG_ON(service->srvstate != VCHIQ_SRVSTATE_FREE);
+		state->services[service->localport] = NULL;
+	} else {
+		service = NULL;
+	}
+unlock:
 	spin_unlock(&service_spinlock);
 
 	if (service && service->userdata_term)
@@ -822,7 +828,12 @@ queue_message(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service,
 	if (type == VCHIQ_MSG_DATA) {
 		int tx_end_index;
 
-		BUG_ON(!service);
+		if (!service) {
+			WARN(1, "%s: service is NULL\n", __func__);
+			mutex_unlock(&state->slot_mutex);
+			return VCHIQ_ERROR;
+		}
+
 		BUG_ON((flags & (QMFLAGS_NO_MUTEX_LOCK |
 				 QMFLAGS_NO_MUTEX_UNLOCK)) != 0);
 
@@ -923,7 +934,6 @@ queue_message(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service,
 			header, size, VCHIQ_MSG_SRCPORT(msgid),
 			VCHIQ_MSG_DSTPORT(msgid));
 
-		BUG_ON(!service);
 		BUG_ON((flags & (QMFLAGS_NO_MUTEX_LOCK |
 				 QMFLAGS_NO_MUTEX_UNLOCK)) != 0);
 
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:20 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:20 +0200
Subject: [PATCH v2 10/16] staging: vchiq_core: Bailout if VCHIQ state is
 already initialized
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-11-git-send-email-stefan.wahren@i2se.com>

In case VCHIQ state is already initialized we need to bailout
in order to aovid a memory leak.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index c47de96..0a46e15 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -2355,6 +2355,11 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero,
 		"%s: slot_zero = %pK, is_master = %d",
 		__func__, slot_zero, is_master);
 
+	if (vchiq_states[0]) {
+		pr_err("%s: VCHIQ state already initialized\n", __func__);
+		return VCHIQ_ERROR;
+	}
+
 	/* Check the input configuration */
 
 	if (slot_zero->magic != VCHIQ_MAGIC) {
-- 
2.7.4



From stefan.wahren at i2se.com  Thu May 25 15:26:18 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 00:26:18 +0200
Subject: [PATCH v2 08/16] staging: vchiq_2835_arm: Use PAGE_MASK macro
In-Reply-To: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
References: <1495751186-3543-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1495751186-3543-9-git-send-email-stefan.wahren@i2se.com>

Use the PAGE_MASK instead of open code it.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index eeeee1b..1fea2b6 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -474,7 +474,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
 	} else {
 		down_read(&task->mm->mmap_sem);
 		actual_pages = get_user_pages(
-				          (unsigned long)buf & ~(PAGE_SIZE - 1),
+					  (unsigned long)buf & PAGE_MASK,
 					  num_pages,
 					  (type == PAGELIST_READ) ? FOLL_WRITE : 0,
 					  pages,
-- 
2.7.4



From stefan.wahren at i2se.com  Fri May 26 08:50:40 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Fri, 26 May 2017 17:50:40 +0200 (CEST)
Subject: Bug: sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware
 interrupt.
Message-ID: <433605218.311867.1495813840749@email.1und1.de>

Hi,

i noticed that the RPI2 with next-20170526 and bcm2835_defconfig doesn't boot from SD card [1]. At least i was able to fix the NULL pointer dereference [2]. Now i'm getting the output see below. I try to narrow this down, but maybe someone already has an idea.

Regards
Stefan

[1] - https://storage.kernelci.org/next/master/next-20170526/arm/bcm2835_defconfig/lab-collabora/boot-bcm2836-rpi-2-b.txt
[2] - https://github.com/lategoodbye/rpi-zero/commit/ff0b8c7e3f6a4d1b6dfe99710fa9ee333e2b8886

[    0.328506] sdhci: Secure Digital Host Controller Interface driver
[    0.330949] sdhci: Copyright(c) Pierre Ossman
[    0.471038] sdhost-bcm2835 3f202000.mmc: loaded - DMA enabled (>1)
[    0.473582] sdhci-pltfm: SDHCI platform and OF driver helper
[    0.476764] ledtrig-cpu: registered to indicate activity on CPUs
[    0.479552] usbcore: registered new interface driver usbhid
[    0.481930] usbhid: USB HID core driver
[    0.484411] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
[    0.488231] oprofile: using timer interrupt.
[    0.492227] NET: Registered protocol family 10
[    0.496233] Segment Routing with IPv6
[    0.498773] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    0.502518] NET: Registered protocol family 17
[    0.510802] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2
[    0.852460] mmc0: host does not support reading read-only switch, assuming write-enable
[    0.860971] mmc0: new high speed SDHC card at address 0001
[    0.875465] mmcblk0: mmc0:0001 00000 29.8 GiB
[    1.397285] console [ttyAMA0] enabled
[    1.406137] raspberrypi-firmware soc:firmware: Attached to firmware from 2017-04-27 17:19
[    1.423787] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok
[    1.434811]  mmcblk0: p1 p2
[    1.441932] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops)
[    1.452869] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops)
[    1.462502] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops)
[    1.472183] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops)
[    1.482493] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops)
[    1.492658] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops)
[    1.502596] cma: cma_alloc: alloc failed, req-size: 4096 pages, ret: -12
[    1.512404] vc4-drm soc:gpu: failed to allocate buffer with size 16777216
[    1.522337] cma: cma_alloc: alloc failed, req-size: 4096 pages, ret: -12
[    1.532182] vc4-drm soc:gpu: failed to allocate buffer with size 16777216
[    1.542155] [drm:vc4_bo_create] *ERROR* Failed to allocate from CMA:
[    1.551681] [drm] num bos allocated: 0
[    1.558530] [drm] size bos allocated: 0kb
[    1.565612] [drm] num bos used: 0
[    1.571938] [drm] size bos used: 0kb
[    1.578483] [drm] num bos cached: 0
[    1.584922] [drm] size bos cached: 0kb
[    1.591580] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.
[    1.609589] vc4-drm soc:gpu: failed to bind 3fc00000.v3d (ops vc4_v3d_ops): -12
[    1.621480] vc4-drm soc:gpu: master bind failed: -12
[    1.629515] vc4_v3d: probe of 3fc00000.v3d failed with error -12
[    1.715334] dwc2 3f980000.usb: DWC OTG Controller
[    1.723064] dwc2 3f980000.usb: new USB bus registered, assigned bus number 1
[    1.733085] dwc2 3f980000.usb: irq 39, io mem 0x3f980000
[    1.742503] hub 1-0:1.0: USB hub found
[    1.749074] hub 1-0:1.0: 1 port detected
[    1.756656] ALSA device list:
[    1.762420]   No soundcards found.
[    1.798146] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[    1.812372] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    1.830538] devtmpfs: mounted
[    1.841464] Freeing unused kernel memory: 1024K
[  223.667700] sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware interrupt.
[  223.667701] sdhost-bcm2835 3f202000.mmc: =========== REGISTER DUMP ===========
[  223.667702] sdhost-bcm2835 3f202000.mmc: SDCMD  0x00004052
[  223.667702] sdhost-bcm2835 3f202000.mmc: SDARG  0x00021e18
[  223.667699] sdhost-bcm2835 3f202000.mmc: SDTOUT 0x017d2a20
[  223.667702] sdhost-bcm2835 3f202000.mmc: SDCDIV 0x00000003
[  223.667705] sdhost-bcm2835 3f202000.mmc: SDRSP0 0x00000900
[  223.667703] sdhost-bcm2835 3f202000.mmc: SDRSP1 0x00001269
[  223.667703] sdhost-bcm2835 3f202000.mmc: SDRSP2 0x7fffffff
[  223.667705] sdhost-bcm2835 3f202000.mmc: SDRSP3 0x00024007
[  223.667705] sdhost-bcm2835 3f202000.mmc: SDHSTS 0x00000081
[  223.667701] sdhost-bcm2835 3f202000.mmc: SDVDD  0x00000001
[  223.667702] sdhost-bcm2835 3f202000.mmc: SDEDM  0x00010831
[  223.667702] sdhost-bcm2835 3f202000.mmc: SDHCFG 0x0000040e
[  223.667700] sdhost-bcm2835 3f202000.mmc: SDHBCT 0x00000200
[  223.667699] sdhost-bcm2835 3f202000.mmc: SDHBLC 0x00000001
[  223.667699] sdhost-bcm2835 3f202000.mmc: ===========================================


From srishtishar at gmail.com  Wed May 24 07:33:14 2017
From: srishtishar at gmail.com (srishti sharma)
Date: Wed, 24 May 2017 20:03:14 +0530
Subject: [PATCH] Staging: bcm2835-audio: bcm2835-ctl.c: Fixed a comment coding
 style issue.
Message-ID: <1495636394-2431-1-git-send-email-srishtishar@gmail.com>

fixed a trailing */ issue

Signed-off-by: srishti sharma <srishtishar at gmail.com>
---
 drivers/staging/bcm2835-audio/bcm2835-ctl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/bcm2835-ctl.c b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
index a4ffa1b..38fabab 100644
--- a/drivers/staging/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
@@ -247,8 +247,8 @@ static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol *kcontrol,
 	struct snd_ctl_elem_value *ucontrol)
 {
 	/* bcm2835 supports only consumer mode and sets all other format flags
-	 * automatically. So the only thing left is signalling non-audio
-	 * content */
+	 * automatically. So the only thing left is signalling non-audio content
+	 */
 	ucontrol->value.iec958.status[0] = IEC958_AES0_NONAUDIO;
 	return 0;
 }
2.7.4



From me at tobin.cc  Wed May 24 16:28:18 2017
From: me at tobin.cc (Tobin C. Harding)
Date: Thu, 25 May 2017 09:28:18 +1000
Subject: [PATCH] Staging: bcm2835-audio: bcm2835-ctl.c: Fixed a comment
 coding style issue.
In-Reply-To: <1495636394-2431-1-git-send-email-srishtishar@gmail.com>
References: <1495636394-2431-1-git-send-email-srishtishar@gmail.com>
Message-ID: <20170524232818.GF2319@eros>

On Wed, May 24, 2017 at 08:03:14PM +0530, srishti sharma wrote:

This driver is not in Greg KH's staging tree. You may like to work off
of that tree when doing staging patches.

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/

To aid you future patches here are a couple of minor comments for you.

> fixed a trailing */ issue

You may like to be more explicit here using the format described in
Documentation/process/submitting-patches.rst (Section 2 Describe your
changes). This goes for your subject line as well.

> Signed-off-by: srishti sharma <srishtishar at gmail.com>
> ---
>  drivers/staging/bcm2835-audio/bcm2835-ctl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/bcm2835-audio/bcm2835-ctl.c b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
> index a4ffa1b..38fabab 100644
> --- a/drivers/staging/bcm2835-audio/bcm2835-ctl.c
> +++ b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
> @@ -247,8 +247,8 @@ static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol *kcontrol,
>  	struct snd_ctl_elem_value *ucontrol)
>  {
>  	/* bcm2835 supports only consumer mode and sets all other format flags
> -	 * automatically. So the only thing left is signalling non-audio
> -	 * content */
> +	 * automatically. So the only thing left is signalling non-audio content
> +	 */

And for completeness this is the block comment style in networking
code, the rest of the kernel uses the format

/*
 * block comment blah blah
 * on multiple lines
 */

Good luck,
Tobin.


From srishtishar at gmail.com  Wed May 24 22:22:22 2017
From: srishtishar at gmail.com (srishti sharma)
Date: Thu, 25 May 2017 10:52:22 +0530
Subject: [PATCH] Staging: bcm2835-audio: bcm2835-ctl.c: Fixed a comment
 coding style issue.
In-Reply-To: <20170524232818.GF2319@eros>
References: <1495636394-2431-1-git-send-email-srishtishar@gmail.com>
 <20170524232818.GF2319@eros>
Message-ID: <CAB3L5oxbhiUUV63aMh+G-6VZb8TgpG=f9d3pYDB0WXCWp5pWPg@mail.gmail.com>

On Thu, May 25, 2017 at 4:58 AM, Tobin C. Harding <me at tobin.cc> wrote:
> On Wed, May 24, 2017 at 08:03:14PM +0530, srishti sharma wrote:
>
> This driver is not in Greg KH's staging tree. You may like to work off
> of that tree when doing staging patches.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/
>
> To aid you future patches here are a couple of minor comments for you.
>
>> fixed a trailing */ issue
>
> You may like to be more explicit here using the format described in
> Documentation/process/submitting-patches.rst (Section 2 Describe your
> changes). This goes for your subject line as well.
>
>> Signed-off-by: srishti sharma <srishtishar at gmail.com>
>> ---
>>  drivers/staging/bcm2835-audio/bcm2835-ctl.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/bcm2835-audio/bcm2835-ctl.c b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
>> index a4ffa1b..38fabab 100644
>> --- a/drivers/staging/bcm2835-audio/bcm2835-ctl.c
>> +++ b/drivers/staging/bcm2835-audio/bcm2835-ctl.c
>> @@ -247,8 +247,8 @@ static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol *kcontrol,
>>       struct snd_ctl_elem_value *ucontrol)
>>  {
>>       /* bcm2835 supports only consumer mode and sets all other format flags
>> -      * automatically. So the only thing left is signalling non-audio
>> -      * content */
>> +      * automatically. So the only thing left is signalling non-audio content
>> +      */
>
> And for completeness this is the block comment style in networking
> code, the rest of the kernel uses the format
>
> /*
>  * block comment blah blah
>  * on multiple lines
>  */
>
> Good luck,
> Tobin.




Okay, Thanks a lot .

Regards ,
Srishti


From stefan.wahren at i2se.com  Wed May 24 23:59:07 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Thu, 25 May 2017 08:59:07 +0200 (CEST)
Subject: [PATCH] Staging: bcm2835-audio: bcm2835-ctl.c: Fixed a comment
 coding style issue.
In-Reply-To: <20170524232818.GF2319@eros>
References: <1495636394-2431-1-git-send-email-srishtishar@gmail.com>
 <20170524232818.GF2319@eros>
Message-ID: <1216962271.894604.1495695547149@email.1und1.de>


> "Tobin C. Harding" <me at tobin.cc> hat am 25. Mai 2017 um 01:28 geschrieben:
> 
> 
> On Wed, May 24, 2017 at 08:03:14PM +0530, srishti sharma wrote:
> 
> This driver is not in Greg KH's staging tree.

The driver has moved to drivers/staging/vc04_services/bcm2835-audio

> You may like to work off
> of that tree when doing staging patches.
>


From stefan.wahren at i2se.com  Thu May 25 02:12:08 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Thu, 25 May 2017 11:12:08 +0200 (CEST)
Subject: [PATCH] mmc: host: fix potential null pointer dereference
In-Reply-To: <20170523234227.GA13018@embeddedgus>
References: <20170523234227.GA13018@embeddedgus>
Message-ID: <746018130.108142.1495703528403@email.1und1.de>

Hi Gustavo,

> "Gustavo A. R. Silva" <garsilva at embeddedor.com> hat am 24. Mai 2017 um 01:42 geschrieben:
> 
> 
> Null check at line 1165: if (mrq->cmd), implies that mrq->cmd might
> be NULL.
> Add null checks before dereferencing pointer mrq->cmd in order to avoid
> any potential NULL pointer dereference.
> 
> Addresses-Coverity-ID: 1408740
> Signed-off-by: Gustavo A. R. Silva <garsilva at embeddedor.com>

Tested-by: Stefan Wahren <stefan.wahren at i2se.com>

with a Raspberry Pi Zero.

But please change the subject to make sure it's bcm2835 related:

mmc: bcm2835: fix potential null pointer dereferences

Thanks
Stefan


From garsilva at embeddedor.com  Thu May 25 09:46:38 2017
From: garsilva at embeddedor.com (Gustavo A. R. Silva)
Date: Thu, 25 May 2017 11:46:38 -0500
Subject: [PATCH] mmc: host: fix potential null pointer dereference
In-Reply-To: <746018130.108142.1495703528403@email.1und1.de>
References: <20170523234227.GA13018@embeddedgus>
 <746018130.108142.1495703528403@email.1und1.de>
Message-ID: <20170525114638.Horde.wq7PLKWCg8CwLM5WiWj1Obm@gator4166.hostgator.com>

Hi Stefan,

Quoting Stefan Wahren <stefan.wahren at i2se.com>:

> Hi Gustavo,
>
>> "Gustavo A. R. Silva" <garsilva at embeddedor.com> hat am 24. Mai 2017  
>> um 01:42 geschrieben:
>>
>>
>> Null check at line 1165: if (mrq->cmd), implies that mrq->cmd might
>> be NULL.
>> Add null checks before dereferencing pointer mrq->cmd in order to avoid
>> any potential NULL pointer dereference.
>>
>> Addresses-Coverity-ID: 1408740
>> Signed-off-by: Gustavo A. R. Silva <garsilva at embeddedor.com>
>
> Tested-by: Stefan Wahren <stefan.wahren at i2se.com>
>
> with a Raspberry Pi Zero.
>
> But please change the subject to make sure it's bcm2835 related:
>
> mmc: bcm2835: fix potential null pointer dereferences
>

OK, I'll send v2 shortly.

Thank you
--
Gustavo A. R. Silva







From gregkh at linuxfoundation.org  Thu May 25 09:57:07 2017
From: gregkh at linuxfoundation.org (Greg KH)
Date: Thu, 25 May 2017 18:57:07 +0200
Subject: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment
 coding style issue.
In-Reply-To: <1495225824-4422-1-git-send-email-srishtishar@gmail.com>
References: <1495225824-4422-1-git-send-email-srishtishar@gmail.com>
Message-ID: <20170525165706.GA1201@kroah.com>

On Sat, May 20, 2017 at 02:00:24AM +0530, srishti sharma wrote:
> fixed a trailing */ issue .
> 
> Signed-off-by: srishti sharma <srishtishar at gmail.com>
> ---
>  drivers/staging/bcm2835-audio/bcm2835-ctl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

This file isn't in my tree, always work against linux-next please...

thanks,

greg k-h


From garsilva at embeddedor.com  Thu May 25 10:04:55 2017
From: garsilva at embeddedor.com (Gustavo A. R. Silva)
Date: Thu, 25 May 2017 12:04:55 -0500
Subject: [PATCH v2] mmc: bcm2835: fix potential null pointer dereferences
In-Reply-To: <20170525114638.Horde.wq7PLKWCg8CwLM5WiWj1Obm@gator4166.hostgator.com>
Message-ID: <20170525170455.GA6904@embeddedgus>

Null check at line 1165: if (mrq->cmd), implies that mrq->cmd might
be NULL.
Add null checks before dereferencing pointer mrq->cmd in order to avoid
any potential NULL pointer dereference.

Addresses-Coverity-ID: 1408740
Tested-by: Stefan Wahren <stefan.wahren at i2se.com>
Signed-off-by: Gustavo A. R. Silva <garsilva at embeddedor.com>
---
Changes in v2:
 Change subject to make it clear the patch is bcm2835 related.

 drivers/mmc/host/bcm2835.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/bcm2835.c b/drivers/mmc/host/bcm2835.c
index 1f343a4..abba9a2 100644
--- a/drivers/mmc/host/bcm2835.c
+++ b/drivers/mmc/host/bcm2835.c
@@ -1172,7 +1172,10 @@ static void bcm2835_request(struct mmc_host *mmc, struct mmc_request *mrq)
 	if (mrq->data && !is_power_of_2(mrq->data->blksz)) {
 		dev_err(dev, "unsupported block size (%d bytes)\n",
 			mrq->data->blksz);
-		mrq->cmd->error = -EINVAL;
+
+		if (mrq->cmd)
+			mrq->cmd->error = -EINVAL;
+
 		mmc_request_done(mmc, mrq);
 		return;
 	}
@@ -1194,7 +1197,10 @@ static void bcm2835_request(struct mmc_host *mmc, struct mmc_request *mrq)
 			readl(host->ioaddr + SDCMD) & SDCMD_CMD_MASK,
 			edm);
 		bcm2835_dumpregs(host);
-		mrq->cmd->error = -EILSEQ;
+
+		if (mrq->cmd)
+			mrq->cmd->error = -EILSEQ;
+
 		bcm2835_finish_request(host);
 		mutex_unlock(&host->mutex);
 		return;
@@ -1207,7 +1213,7 @@ static void bcm2835_request(struct mmc_host *mmc, struct mmc_request *mrq)
 			if (!host->use_busy)
 				bcm2835_finish_command(host);
 		}
-	} else if (bcm2835_send_command(host, mrq->cmd)) {
+	} else if (mrq->cmd && bcm2835_send_command(host, mrq->cmd)) {
 		if (host->data && host->dma_desc) {
 			/* DMA transfer starts now, PIO starts after irq */
 			bcm2835_start_dma(host);
-- 
2.5.0



From srishtishar at gmail.com  Thu May 25 12:27:19 2017
From: srishtishar at gmail.com (srishti sharma)
Date: Fri, 26 May 2017 00:57:19 +0530
Subject: [PATCH] Staging: bcm2835-audio: bcm2835_ctl.c: Fixed a comment
 coding style issue.
In-Reply-To: <20170525165706.GA1201@kroah.com>
References: <1495225824-4422-1-git-send-email-srishtishar@gmail.com>
 <20170525165706.GA1201@kroah.com>
Message-ID: <CAB3L5owkEt4=Cz=S03ZtKxZOjLCHBqkM8W5GB0G01NBHn=7vDg@mail.gmail.com>

On Thu, May 25, 2017 at 10:27 PM, Greg KH <gregkh at linuxfoundation.org> wrote:
> On Sat, May 20, 2017 at 02:00:24AM +0530, srishti sharma wrote:
>> fixed a trailing */ issue .
>>
>> Signed-off-by: srishti sharma <srishtishar at gmail.com>
>> ---
>>  drivers/staging/bcm2835-audio/bcm2835-ctl.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> This file isn't in my tree, always work against linux-next please...
>
> thanks,
>
> greg k-h


Thanks for letting me know !

Regards,
Srishti


From stefan.wahren at i2se.com  Sun May 28 06:00:41 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sun, 28 May 2017 15:00:41 +0200 (CEST)
Subject: Bug: sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware
 interrupt.
In-Reply-To: <433605218.311867.1495813840749@email.1und1.de>
References: <433605218.311867.1495813840749@email.1und1.de>
Message-ID: <1657024502.940561.1495976441798@email.1und1.de>


> Stefan Wahren <stefan.wahren at i2se.com> hat am 26. Mai 2017 um 17:50 geschrieben:
> 
> 
> Hi,
> 
> i noticed that the RPI2 with next-20170526 and bcm2835_defconfig doesn't boot from SD card [1]. At least i was able to fix the NULL pointer dereference [2]. Now i'm getting the output see below. I try to narrow this down, but maybe someone already has an idea.
> 

Okay this issue doesn't seems to be related to the bcm2835-sdhost driver.

Test results on RPI 2:

bcm2835-sdhost + bcm2835_defconfig + next-20170526 => boot hang
sdhci-iproc + bcm2835_defconfig + next-20170526 => boot hang
bcm2835-sdhost + bcm2835_defconfig + v4.12-rc2 => boot hang
sdhci-iproc + bcm2835_defconfig + v4.12-rc2 => boot hang
bcm2835-sdhost + bcm2835_defconfig + v4.11 => boot hang
sdhci-iproc + bcm2835_defconfig + v4.11 => boot hang
bcm2835-sdhost + multi_v7_defconfig + v4.12-rc2 => no boot hang
sdhci-iproc + multi_v7_defconfig + v4.12-rc2 => no boot hang

I will send the fix for the NULL pointer dereference as a RFC patch soon.

Stefan


From daniel.lezcano at linaro.org  Sat May 27 02:58:43 2017
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sat, 27 May 2017 11:58:43 +0200
Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
In-Reply-To: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>

The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the
clocksource at early stage. However, this macro is also used to initialize
the clockevent if any, or the clockevent only.

It was originally suggested to declare another macro to initialize a
clockevent, so in order to separate the two entities even they belong to the
same IP. This was not accepted because of the impact on the DT where splitting
a clocksource/clockevent definition does not make sense as it is a Linux
concept not a hardware description.

On the other side, the clocksource has not interrupt declared while the
clockevent has, so it is easy from the driver to know if the description is
for a clockevent or a clocksource, IOW it could be implemented at the driver
level.

So instead of dealing with a named clocksource macro, let's use a more generic
one: TIMER_OF_DECLARE.

The patch has not functional changes.

Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 arch/arm/kernel/smp_twd.c                 |  6 +++---
 arch/microblaze/kernel/timer.c            |  2 +-
 arch/mips/ralink/cevt-rt3352.c            |  2 +-
 arch/nios2/kernel/time.c                  |  2 +-
 drivers/clocksource/arc_timer.c           |  6 +++---
 drivers/clocksource/arm_arch_timer.c      |  6 +++---
 drivers/clocksource/arm_global_timer.c    |  2 +-
 drivers/clocksource/armv7m_systick.c      |  2 +-
 drivers/clocksource/asm9260_timer.c       |  2 +-
 drivers/clocksource/bcm2835_timer.c       |  2 +-
 drivers/clocksource/bcm_kona_timer.c      |  4 ++--
 drivers/clocksource/cadence_ttc_timer.c   |  2 +-
 drivers/clocksource/clksrc-dbx500-prcmu.c |  2 +-
 drivers/clocksource/clksrc_st_lpc.c       |  2 +-
 drivers/clocksource/clps711x-timer.c      |  2 +-
 drivers/clocksource/dw_apb_timer_of.c     |  8 ++++----
 drivers/clocksource/exynos_mct.c          |  4 ++--
 drivers/clocksource/fsl_ftm_timer.c       |  2 +-
 drivers/clocksource/h8300_timer16.c       |  2 +-
 drivers/clocksource/h8300_timer8.c        |  2 +-
 drivers/clocksource/h8300_tpu.c           |  2 +-
 drivers/clocksource/jcore-pit.c           |  2 +-
 drivers/clocksource/meson6_timer.c        |  2 +-
 drivers/clocksource/mips-gic-timer.c      |  2 +-
 drivers/clocksource/mps2-timer.c          |  2 +-
 drivers/clocksource/mtk_timer.c           |  2 +-
 drivers/clocksource/mxs_timer.c           |  2 +-
 drivers/clocksource/nomadik-mtu.c         |  2 +-
 drivers/clocksource/pxa_timer.c           |  2 +-
 drivers/clocksource/qcom-timer.c          |  4 ++--
 drivers/clocksource/renesas-ostm.c        |  2 +-
 drivers/clocksource/rockchip_timer.c      |  4 ++--
 drivers/clocksource/samsung_pwm_timer.c   |  8 ++++----
 drivers/clocksource/sun4i_timer.c         |  2 +-
 drivers/clocksource/tango_xtal.c          |  2 +-
 drivers/clocksource/tegra20_timer.c       |  4 ++--
 drivers/clocksource/time-armada-370-xp.c  |  6 +++---
 drivers/clocksource/time-efm32.c          |  4 ++--
 drivers/clocksource/time-lpc32xx.c        |  2 +-
 drivers/clocksource/time-orion.c          |  2 +-
 drivers/clocksource/time-pistachio.c      |  2 +-
 drivers/clocksource/timer-atlas7.c        |  2 +-
 drivers/clocksource/timer-atmel-pit.c     |  2 +-
 drivers/clocksource/timer-atmel-st.c      |  2 +-
 drivers/clocksource/timer-digicolor.c     |  2 +-
 drivers/clocksource/timer-fttmr010.c      | 10 +++++-----
 drivers/clocksource/timer-imx-gpt.c       | 24 ++++++++++++------------
 drivers/clocksource/timer-integrator-ap.c |  2 +-
 drivers/clocksource/timer-keystone.c      |  2 +-
 drivers/clocksource/timer-nps.c           |  6 +++---
 drivers/clocksource/timer-oxnas-rps.c     |  4 ++--
 drivers/clocksource/timer-prima2.c        |  2 +-
 drivers/clocksource/timer-sp804.c         |  4 ++--
 drivers/clocksource/timer-stm32.c         |  2 +-
 drivers/clocksource/timer-sun5i.c         |  4 ++--
 drivers/clocksource/timer-ti-32k.c        |  2 +-
 drivers/clocksource/timer-u300.c          |  2 +-
 drivers/clocksource/versatile.c           |  4 ++--
 drivers/clocksource/vf_pit_timer.c        |  2 +-
 drivers/clocksource/vt8500_timer.c        |  2 +-
 drivers/clocksource/zevio-timer.c         |  2 +-
 include/linux/clocksource.h               |  2 +-
 62 files changed, 103 insertions(+), 103 deletions(-)

diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 895ae51..b30eafe 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -403,7 +403,7 @@ static int __init twd_local_timer_of_register(struct device_node *np)
 	WARN(err, "twd_local_timer_of_register failed (%d)\n", err);
 	return err;
 }
-CLOCKSOURCE_OF_DECLARE(arm_twd_a9, "arm,cortex-a9-twd-timer", twd_local_timer_of_register);
-CLOCKSOURCE_OF_DECLARE(arm_twd_a5, "arm,cortex-a5-twd-timer", twd_local_timer_of_register);
-CLOCKSOURCE_OF_DECLARE(arm_twd_11mp, "arm,arm11mp-twd-timer", twd_local_timer_of_register);
+TIMER_OF_DECLARE(arm_twd_a9, "arm,cortex-a9-twd-timer", twd_local_timer_of_register);
+TIMER_OF_DECLARE(arm_twd_a5, "arm,cortex-a5-twd-timer", twd_local_timer_of_register);
+TIMER_OF_DECLARE(arm_twd_11mp, "arm,arm11mp-twd-timer", twd_local_timer_of_register);
 #endif
diff --git a/arch/microblaze/kernel/timer.c b/arch/microblaze/kernel/timer.c
index 9990661..873a1cc 100644
--- a/arch/microblaze/kernel/timer.c
+++ b/arch/microblaze/kernel/timer.c
@@ -333,5 +333,5 @@ static int __init xilinx_timer_init(struct device_node *timer)
 	return 0;
 }
 
-CLOCKSOURCE_OF_DECLARE(xilinx_timer, "xlnx,xps-timer-1.00.a",
+TIMER_OF_DECLARE(xilinx_timer, "xlnx,xps-timer-1.00.a",
 		       xilinx_timer_init);
diff --git a/arch/mips/ralink/cevt-rt3352.c b/arch/mips/ralink/cevt-rt3352.c
index b8a1376..92f284d 100644
--- a/arch/mips/ralink/cevt-rt3352.c
+++ b/arch/mips/ralink/cevt-rt3352.c
@@ -152,4 +152,4 @@ static int __init ralink_systick_init(struct device_node *np)
 	return 0;
 }
 
-CLOCKSOURCE_OF_DECLARE(systick, "ralink,cevt-systick", ralink_systick_init);
+TIMER_OF_DECLARE(systick, "ralink,cevt-systick", ralink_systick_init);
diff --git a/arch/nios2/kernel/time.c b/arch/nios2/kernel/time.c
index 6e2bdc9..2954b66 100644
--- a/arch/nios2/kernel/time.c
+++ b/arch/nios2/kernel/time.c
@@ -353,4 +353,4 @@ void __init time_init(void)
 	clocksource_probe();
 }
 
-CLOCKSOURCE_OF_DECLARE(nios2_timer, ALTR_TIMER_COMPATIBLE, nios2_time_init);
+TIMER_OF_DECLARE(nios2_timer, ALTR_TIMER_COMPATIBLE, nios2_time_init);
diff --git a/drivers/clocksource/arc_timer.c b/drivers/clocksource/arc_timer.c
index 2164973..4927355 100644
--- a/drivers/clocksource/arc_timer.c
+++ b/drivers/clocksource/arc_timer.c
@@ -99,7 +99,7 @@ static int __init arc_cs_setup_gfrc(struct device_node *node)
 
 	return clocksource_register_hz(&arc_counter_gfrc, arc_timer_freq);
 }
-CLOCKSOURCE_OF_DECLARE(arc_gfrc, "snps,archs-timer-gfrc", arc_cs_setup_gfrc);
+TIMER_OF_DECLARE(arc_gfrc, "snps,archs-timer-gfrc", arc_cs_setup_gfrc);
 
 #define AUX_RTC_CTRL	0x103
 #define AUX_RTC_LOW	0x104
@@ -158,7 +158,7 @@ static int __init arc_cs_setup_rtc(struct device_node *node)
 
 	return clocksource_register_hz(&arc_counter_rtc, arc_timer_freq);
 }
-CLOCKSOURCE_OF_DECLARE(arc_rtc, "snps,archs-timer-rtc", arc_cs_setup_rtc);
+TIMER_OF_DECLARE(arc_rtc, "snps,archs-timer-rtc", arc_cs_setup_rtc);
 
 #endif
 
@@ -333,4 +333,4 @@ static int __init arc_of_timer_init(struct device_node *np)
 
 	return ret;
 }
-CLOCKSOURCE_OF_DECLARE(arc_clkevt, "snps,arc-timer", arc_of_timer_init);
+TIMER_OF_DECLARE(arc_clkevt, "snps,arc-timer", arc_of_timer_init);
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index a1fb918..9a41958 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -1194,8 +1194,8 @@ static int __init arch_timer_of_init(struct device_node *np)
 
 	return arch_timer_common_init();
 }
-CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_of_init);
-CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_of_init);
+TIMER_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_of_init);
+TIMER_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_of_init);
 
 static u32 __init
 arch_timer_mem_frame_get_cntfrq(struct arch_timer_mem_frame *frame)
@@ -1382,7 +1382,7 @@ static int __init arch_timer_mem_of_init(struct device_node *np)
 	kfree(timer_mem);
 	return ret;
 }
-CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
+TIMER_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
 		       arch_timer_mem_of_init);
 
 #ifdef CONFIG_ACPI_GTDT
diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c
index 123ed20..095bb96 100644
--- a/drivers/clocksource/arm_global_timer.c
+++ b/drivers/clocksource/arm_global_timer.c
@@ -339,5 +339,5 @@ static int __init global_timer_of_register(struct device_node *np)
 }
 
 /* Only tested on r2p2 and r3p0  */
-CLOCKSOURCE_OF_DECLARE(arm_gt, "arm,cortex-a9-global-timer",
+TIMER_OF_DECLARE(arm_gt, "arm,cortex-a9-global-timer",
 			global_timer_of_register);
diff --git a/drivers/clocksource/armv7m_systick.c b/drivers/clocksource/armv7m_systick.c
index a315491..ac046d6 100644
--- a/drivers/clocksource/armv7m_systick.c
+++ b/drivers/clocksource/armv7m_systick.c
@@ -82,5 +82,5 @@ static int __init system_timer_of_register(struct device_node *np)
 	return ret;
 }
 
-CLOCKSOURCE_OF_DECLARE(arm_systick, "arm,armv7m-systick",
+TIMER_OF_DECLARE(arm_systick, "arm,armv7m-systick",
 			system_timer_of_register);
diff --git a/drivers/clocksource/asm9260_timer.c b/drivers/clocksource/asm9260_timer.c
index c678083..38cd2fe 100644
--- a/drivers/clocksource/asm9260_timer.c
+++ b/drivers/clocksource/asm9260_timer.c
@@ -238,5 +238,5 @@ static int __init asm9260_timer_init(struct device_node *np)
 
 	return 0;
 }
-CLOCKSOURCE_OF_DECLARE(asm9260_timer, "alphascale,asm9260-timer",
+TIMER_OF_DECLARE(asm9260_timer, "alphascale,asm9260-timer",
 		asm9260_timer_init);
diff --git a/drivers/clocksource/bcm2835_timer.c b/drivers/clocksource/bcm2835_timer.c
index dce4430..82828d3 100644
--- a/drivers/clocksource/bcm2835_timer.c
+++ b/drivers/clocksource/bcm2835_timer.c
@@ -148,5 +148,5 @@ static int __init bcm2835_timer_init(struct device_node *node)
 	iounmap(base);
 	return ret;
 }
-CLOCKSOURCE_OF_DECLARE(bcm2835, "brcm,bcm2835-system-timer",
+TIMER_OF_DECLARE(bcm2835, "brcm,bcm2835-system-timer",
 			bcm2835_timer_init);
diff --git a/drivers/clocksource/bcm_kona_timer.c b/drivers/clocksource/bcm_kona_timer.c
index fda5e147..5c40be9 100644
--- a/drivers/clocksource/bcm_kona_timer.c
+++ b/drivers/clocksource/bcm_kona_timer.c
@@ -198,9 +198,9 @@ static int __init kona_timer_init(struct device_node *node)
 	return 0;
 }
 
-CLOCKSOURCE_OF_DECLARE(brcm_kona, "brcm,kona-timer", kona_timer_init);
+TIMER_OF_DECLARE(brcm_kona, "brcm,kona-timer", kona_timer_init);
 /*
  * bcm,kona-timer is deprecated by brcm,kona-timer
  * being kept here for driver compatibility
  */
-CLOCKSOURCE_OF_DECLARE(bcm_kona, "bcm,kona-timer", kona_timer_init);
+TIMER_OF_DECLARE(bcm_kona, "bcm,kona-timer", kona_timer_init);
diff --git a/drivers/clocksource/cadence_ttc_timer.c b/drivers/clocksource/cadence_ttc_timer.c
index 44e5e95..a144dfc 100644
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@ -539,4 +539,4 @@ static int __init ttc_timer_init(struct device_node *timer)
 	return 0;
 }
 
-CLOCKSOURCE_OF_DECLARE(ttc, "cdns,ttc", ttc_timer_init);
+TIMER_OF_DECLARE(ttc, "cdns,ttc", ttc_timer_init);
diff --git a/drivers/clocksource/clksrc-dbx500-prcmu.c b/drivers/clocksource/clksrc-dbx500-prcmu.c
index c69e277..c1b96dc 100644
--- a/drivers/clocksource/clksrc-dbx500-prcmu.c
+++ b/drivers/clocksource/clksrc-dbx500-prcmu.c
@@ -86,5 +86,5 @@ static int __init clksrc_dbx500_prcmu_init(struct device_node *node)
 #endif
 	return clocksource_register_hz(&clocksource_dbx500_prcmu, RATE_32K);
 }
-CLOCKSOURCE_OF_DECLARE(dbx500_prcmu, "stericsson,db8500-prcmu-timer-4",
+TIMER_OF_DECLARE(dbx500_prcmu, "stericsson,db8500-prcmu-timer-4",
 		       clksrc_dbx500_prcmu_init);
diff --git a/drivers/clocksource/clksrc_st_lpc.c b/drivers/clocksource/clksrc_st_lpc.c
index 03cc492..a1d01eb 100644
--- a/drivers/clocksource/clksrc_st_lpc.c
+++ b/drivers/clocksource/clksrc_st_lpc.c
@@ -132,4 +132,4 @@ static int __init st_clksrc_of_register(struct device_node *np)
 
 	return ret;
 }
-CLOCKSOURCE_OF_DECLARE(ddata, "st,stih407-lpc", st_clksrc_of_register);
+TIMER_OF_DECLARE(ddata, "st,stih407-lpc", st_clksrc_of_register);
diff --git a/drivers/clocksource/clps711x-timer.c b/drivers/clocksource/clps711x-timer.c
index 24db6d6..fc9e025 100644
--- a/drivers/clocksource/clps711x-timer.c
+++ b/drivers/clocksource/clps711x-timer.c
@@ -119,5 +119,5 @@ static int __init clps711x_timer_init(struct device_node *np)
 		return -EINVAL;
 	}
 }
-CLOCKSOURCE_OF_DECLARE(clps711x, "cirrus,ep7209-timer", clps711x_timer_init);
+TIMER_OF_DECLARE(clps711x, "cirrus,ep7209-timer", clps711x_timer_init);
 #endif
diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
index aee6c0d..69866cd 100644
--- a/drivers/clocksource/dw_apb_timer_of.c
+++ b/drivers/clocksource/dw_apb_timer_of.c
@@ -167,7 +167,7 @@ static int __init dw_apb_timer_init(struct device_node *timer)
 
 	return 0;
 }
-CLOCKSOURCE_OF_DECLARE(pc3x2_timer, "picochip,pc3x2-timer", dw_apb_timer_init);
-CLOCKSOURCE_OF_DECLARE(apb_timer_osc, "snps,dw-apb-timer-osc", dw_apb_timer_init);
-CLOCKSOURCE_OF_DECLARE(apb_timer_sp, "snps,dw-apb-timer-sp", dw_apb_timer_init);
-CLOCKSOURCE_OF_DECLARE(apb_timer, "snps,dw-apb-timer", dw_apb_timer_init);
+TIMER_OF_DECLARE(pc3x2_timer, "picochip,pc3x2-timer", dw_apb_timer_init);
+TIMER_OF_DECLARE(apb_timer_osc, "snps,dw-apb-timer-osc", dw_apb_timer_init);
+TIMER_OF_DECLARE(apb_timer_sp, "snps,dw-apb-timer-sp", dw_apb_timer_init);
+TIMER_OF_DECLARE(apb_timer, "snps,dw-apb-timer", dw_apb_timer_init);
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 670ff0f..7a244b6 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -610,5 +610,5 @@ static int __init mct_init_ppi(struct device_node *np)
 {
 	return mct_init_dt(np, MCT_INT_PPI);
 }
-CLOCKSOURCE_OF_DECLARE(exynos4210, "samsung,exynos4210-mct", mct_init_spi);
-CLOCKSOURCE_OF_DECLARE(exynos4412, "samsung,exynos4412-mct", mct_init_ppi);
+TIMER_OF_DECLARE(exynos4210, "samsung,exynos4210-mct", mct_init_spi);
+TIMER_OF_DECLARE(exynos4412, "samsung,exynos4412-mct", mct_init_ppi);
diff --git a/drivers/clocksource/fsl_ftm_timer.c b/drivers/clocksource/fsl_ftm_timer.c
index 738515b..3121e2d 100644
--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -369,4 +369,4 @@ static int __init ftm_timer_init(struct device_node *np)
 	kfree(priv);
 	return ret;
 }
-CLOCKSOURCE_OF_DECLARE(flextimer, "fsl,ftm-timer", ftm_timer_init);
+TIMER_OF_DECLARE(flextimer, "fsl,ftm-timer", ftm_timer_init);
diff --git a/drivers/clocksource/h8300_timer16.c b/drivers/clocksource/h8300_timer16.c
index 5b27fb9..dfbd4f8 100644
--- a/drivers/clocksource/h8300_timer16.c
+++ b/drivers/clocksource/h8300_timer16.c
@@ -187,5 +187,5 @@ static int __init h8300_16timer_init(struct device_node *node)
 	return ret;
 }
 
-CLOCKSOURCE_OF_DECLARE(h8300_16bit, "renesas,16bit-timer",
+TIMER_OF_DECLARE(h8300_16bit, "renesas,16bit-timer",
 			   h8300_16timer_init);
diff --git a/drivers/clocksource/h8300_timer8.c b/drivers/clocksource/h8300_timer8.c
index 804c489..f6ffb0c 100644
--- a/drivers/clocksource/h8300_timer8.c
+++ b/drivers/clocksource/h8300_timer8.c
@@ -207,4 +207,4 @@ static int __init h8300_8timer_init(struct device_node *node)
 	return ret;
 }
 
-CLOCKSOURCE_OF_DECLARE(h8300_8bit, "renesas,8bit-timer", h8300_8timer_init);
+TIMER_OF_DECLARE(h8300_8bit, "renesas,8bit-timer", h8300_8timer_init);
diff --git a/drivers/clocksource/h8300_tpu.c b/drivers/clocksource/h8300_tpu.c
index 72e1cf2..45a8d17 100644
--- a/drivers/clocksource/h8300_tpu.c
+++ b/drivers/clocksource/h8300_tpu.c
@@ -154,4 +154,4 @@ static int __init h8300_tpu_init(struct device_node *node)
 	return ret;
 }
 
-CLOCKSOURCE_OF_DECLARE(h8300_tpu, "renesas,tpu", h8300_tpu_init);
+TIMER_OF_DECLARE(h8300_tpu, "renesas,tpu", h8300_tpu_init);
diff --git a/drivers/clocksource/jcore-pit.c b/drivers/clocksource/jcore-pit.c
index 7c61226..5d3d88e0f 100644
--- a/drivers/clocksource/jcore-pit.c
+++ b/drivers/clocksource/jcore-pit.c
@@ -246,4 +246,4 @@ static int __init jcore_pit_init(struct device_node *node)
 	return 0;
 }
 
-CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
+TIMER_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
diff --git a/drivers/clocksource/meson6_timer.c b/drivers/clocksource/meson6_timer.c
index 39d21f6..92f2099 100644
--- a/drivers/clocksource/meson6_timer.c
+++ b/drivers/clocksource/meson6_timer.c
@@ -174,5 +174,5 @@ static int __init meson6_timer_init(struct device_node *node)
 					1, 0xfffe);
 	return 0;
 }
-CLOCKSOURCE_OF_DECLARE(meson6, "amlogic,meson6-timer",
+TIMER_OF_DECLARE(meson6, "amlogic,meson6-timer",
 		       meson6_timer_init);
diff --git a/drivers/clocksource/mips-gic-timer.c b/drivers/clocksource/mips-gic-timer.c
index 3f52ee2..e31e083 100644
--- a/drivers/clocksource/mips-gic-timer.c
+++ b/drivers/clocksource/mips-gic-timer.c
@@ -200,5 +200,5 @@ static int __init gic_clocksource_of_init(struct device_node *node)
 
 	return 0;
 }
-CLOCKSOURCE_OF_DECLARE(mips_gic_timer, "mti,gic-timer",
+TIMER_OF_DECLARE(mips_gic_timer, "mti,gic-timer",
 		       gic_clocksource_of_init);
diff --git a/drivers/clocksource/mps2-timer.c b/drivers/clocksource/mps2-timer.c
index 3e4431e..aa4d63af 100644
--- a/drivers/clocksource/mps2-timer.c
+++ b/drivers/clocksource/mps2-timer.c
@@ -274,4 +274,4 @@ static int __init mps2_timer_init(struct device_node *np)
 	return 0;
 }
 
-CLOCKSOURCE_OF_DECLARE(mps2_timer, "arm,mps2-timer", mps2_timer_init);
+TIMER_OF_DECLARE(mps2_timer, "arm,mps2-timer", mps2_timer_init);
diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
index 9065949..f9b724f 100644
--- a/drivers/clocksource/mtk_timer.c
+++ b/drivers/clocksource/mtk_timer.c
@@ -265,4 +265,4 @@ static int __init mtk_timer_init(struct device_node *node)
 
 	return -EINVAL;
 }
-CLOCKSOURCE_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_timer_init);
+TIMER_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_timer_init);
diff --git a/drivers/clocksource/mxs_timer.c b/drivers/clocksource/mxs_timer.c
index 99b77af..a03434e 100644
--- a/drivers/clocksource/mxs_timer.c
+++ b/drivers/clocksource/mxs_timer.c
@@ -293,4 +293,4 @@ static int __init mxs_timer_init(struct device_node *np)
 
 	return setup_irq(irq, &mxs_timer_irq);
 }
-CLOCKSOURCE_OF_DECLARE(mxs, "fsl,timrot", mxs_timer_init);
+TIMER_OF_DECLARE(mxs, "fsl,timrot", mxs_timer_init);
diff --git a/drivers/clocksource/nomadik-mtu.c b/drivers/clocksource/nomadik-mtu.c
index 7d44de3..8e4ddb9 100644
--- a/drivers/clocksource/nomadik-mtu.c
+++ b/drivers/clocksource/nomadik-mtu.c
@@ -284,5 +284,5 @@ static int __init nmdk_timer_of_init(struct device_node *node)
 
 	return nmdk_timer_init(base, irq, pclk, clk);
 }
-CLOCKSOURCE_OF_DECLARE(nomadik_mtu, "st,nomadik-mtu",
+TIMER_OF_DECLARE(nomadik_mtu, "st,nomadik-mtu",
 		       nmdk_timer_of_init);
diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
index a10fa667..08cd6eaf 100644
--- a/drivers/clocksource/pxa_timer.c
+++ b/drivers/clocksource/pxa_timer.c
@@ -216,7 +216,7 @@ static int __init pxa_timer_dt_init(struct device_node *np)
 
 	return pxa_timer_common_init(irq, clk_get_rate(clk));
 }
-CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);
+TIMER_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);
 
 /*
  * Legacy timer init for non device-tree boards.
diff --git a/drivers/clocksource/qcom-timer.c b/drivers/clocksource/qcom-timer.c
index ee358cd..89816f8 100644
--- a/drivers/clocksource/qcom-timer.c
+++ b/drivers/clocksource/qcom-timer.c
@@ -254,5 +254,5 @@ static int __init msm_dt_timer_init(struct device_node *np)
 
 	return msm_timer_init(freq, 32, irq, !!percpu_offset);
 }
-CLOCKSOURCE_OF_DECLARE(kpss_timer, "qcom,kpss-timer", msm_dt_timer_init);
-CLOCKSOURCE_OF_DECLARE(scss_timer, "qcom,scss-timer", msm_dt_timer_init);
+TIMER_OF_DECLARE(kpss_timer, "qcom,kpss-timer", msm_dt_timer_init);
+TIMER_OF_DECLARE(scss_timer, "qcom,scss-timer", msm_dt_timer_init);
diff --git a/drivers/clocksource/renesas-ostm.c b/drivers/clocksource/renesas-ostm.c
index c76f576..6cffd7c 100644
--- a/drivers/clocksource/renesas-ostm.c
+++ b/drivers/clocksource/renesas-ostm.c
@@ -262,4 +262,4 @@ static int __init ostm_init(struct device_node *np)
 	return 0;
 }
 
-CLOCKSOURCE_OF_DECLARE(ostm, "renesas,ostm", ostm_init);
+TIMER_OF_DECLARE(ostm, "renesas,ostm", ostm_init);
diff --git a/drivers/clocksource/rockchip_timer.c b/drivers/clocksource/rockchip_timer.c
index 49c02be..c27f4c8 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -303,5 +303,5 @@ static int __init rk_timer_init(struct device_node *np)
 	return -EINVAL;
 }
 
-CLOCKSOURCE_OF_DECLARE(rk3288_timer, "rockchip,rk3288-timer", rk_timer_init);
-CLOCKSOURCE_OF_DECLARE(rk3399_timer, "rockchip,rk3399-timer", rk_timer_init);
+TIMER_OF_DECLARE(rk3288_timer, "rockchip,rk3288-timer", rk_timer_init);
+TIMER_OF_DECLARE(rk3399_timer, "rockchip,rk3399-timer", rk_timer_init);
diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
index a68e653..21cd72c 100644
--- a/drivers/clocksource/samsung_pwm_timer.c
+++ b/drivers/clocksource/samsung_pwm_timer.c
@@ -466,7 +466,7 @@ static int __init s3c2410_pwm_clocksource_init(struct device_node *np)
 {
 	return samsung_pwm_alloc(np, &s3c24xx_variant);
 }
-CLOCKSOURCE_OF_DECLARE(s3c2410_pwm, "samsung,s3c2410-pwm", s3c2410_pwm_clocksource_init);
+TIMER_OF_DECLARE(s3c2410_pwm, "samsung,s3c2410-pwm", s3c2410_pwm_clocksource_init);
 
 static const struct samsung_pwm_variant s3c64xx_variant = {
 	.bits		= 32,
@@ -479,7 +479,7 @@ static int __init s3c64xx_pwm_clocksource_init(struct device_node *np)
 {
 	return samsung_pwm_alloc(np, &s3c64xx_variant);
 }
-CLOCKSOURCE_OF_DECLARE(s3c6400_pwm, "samsung,s3c6400-pwm", s3c64xx_pwm_clocksource_init);
+TIMER_OF_DECLARE(s3c6400_pwm, "samsung,s3c6400-pwm", s3c64xx_pwm_clocksource_init);
 
 static const struct samsung_pwm_variant s5p64x0_variant = {
 	.bits		= 32,
@@ -492,7 +492,7 @@ static int __init s5p64x0_pwm_clocksource_init(struct device_node *np)
 {
 	return samsung_pwm_alloc(np, &s5p64x0_variant);
 }
-CLOCKSOURCE_OF_DECLARE(s5p6440_pwm, "samsung,s5p6440-pwm", s5p64x0_pwm_clocksource_init);
+TIMER_OF_DECLARE(s5p6440_pwm, "samsung,s5p6440-pwm", s5p64x0_pwm_clocksource_init);
 
 static const struct samsung_pwm_variant s5p_variant = {
 	.bits		= 32,
@@ -505,5 +505,5 @@ static int __init s5p_pwm_clocksource_init(struct device_node *np)
 {
 	return samsung_pwm_alloc(np, &s5p_variant);
 }
-CLOCKSOURCE_OF_DECLARE(s5pc100_pwm, "samsung,s5pc100-pwm", s5p_pwm_clocksource_init);
+TIMER_OF_DECLARE(s5pc100_pwm, "samsung,s5pc100-pwm", s5p_pwm_clocksource_init);
 #endif
diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
index 4452d5c..3e4bc64 100644
--- a/drivers/clocksource/sun4i_timer.c
+++ b/drivers/clocksource/sun4i_timer.c
@@ -233,5 +233,5 @@ static int __init sun4i_timer_init(struct device_node *node)
 
 	return ret;
 }
-CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-a10-timer",
+TIMER_OF_DECLARE(sun4i, "allwinner,sun4i-a10-timer",
 		       sun4i_timer_init);
diff --git a/drivers/clocksource/tango_xtal.c b/drivers/clocksource/tango_xtal.c
index 12fcef8..c4e1c2e 100644
--- a/drivers/clocksource/tango_xtal.c
+++ b/drivers/clocksource/tango_xtal.c
@@ -53,4 +53,4 @@ static int __init tango_clocksource_init(struct device_node *np)
 	return 0;
 }
 
-CLOCKSOURCE_OF_DECLARE(tango, "sigma,tick-counter", tango_clocksource_init);
+TIMER_OF_DECLARE(tango, "sigma,tick-counter", tango_clocksource_init);
diff --git a/drivers/clocksource/tegra20_timer.c b/drivers/clocksource/tegra20_timer.c
index b9990b9..c337a81 100644
--- a/drivers/clocksource/tegra20_timer.c
+++ b/drivers/clocksource/tegra20_timer.c
@@ -237,7 +237,7 @@ static int __init tegra20_init_timer(struct device_node *np)
 
 	return 0;
 }
-CLOCKSOURCE_OF_DECLARE(tegra20_timer, "nvidia,tegra20-timer", tegra20_init_timer);
+TIMER_OF_DECLARE(tegra20_timer, "nvidia,tegra20-timer", tegra20_init_timer);
 
 static int __init tegra20_init_rtc(struct device_node *np)
 {
@@ -261,4 +261,4 @@ static int __init tegra20_init_rtc(struct device_node *np)
 
 	return register_persistent_clock(NULL, tegra_read_persistent_clock64);
 }
-CLOCKSOURCE_OF_DECLARE(tegra20_rtc, "nvidia,tegra20-rtc", tegra20_init_rtc);
+TIMER_OF_DECLARE(tegra20_rtc, "nvidia,tegra20-rtc", tegra20_init_rtc);
diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index aea4380..edf1a46 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -351,7 +351,7 @@ static int __init armada_xp_timer_init(struct device_node *np)
 
 	return armada_370_xp_timer_common_init(np);
 }
-CLOCKSOURCE_OF_DECLARE(armada_xp, "marvell,armada-xp-timer",
+TIMER_OF_DECLARE(armada_xp, "marvell,armada-xp-timer",
 		       armada_xp_timer_init);
 
 static int __init armada_375_timer_init(struct device_node *np)
@@ -389,7 +389,7 @@ static int __init armada_375_timer_init(struct device_node *np)
 
 	return armada_370_xp_timer_common_init(np);
 }
-CLOCKSOURCE_OF_DECLARE(armada_375, "marvell,armada-375-timer",
+TIMER_OF_DECLARE(armada_375, "marvell,armada-375-timer",
 		       armada_375_timer_init);
 
 static int __init armada_370_timer_init(struct device_node *np)
@@ -412,5 +412,5 @@ static int __init armada_370_timer_init(struct device_node *np)
 
 	return armada_370_xp_timer_common_init(np);
 }
-CLOCKSOURCE_OF_DECLARE(armada_370, "marvell,armada-370-timer",
+TIMER_OF_DECLARE(armada_370, "marvell,armada-370-timer",
 		       armada_370_timer_init);
diff --git a/drivers/clocksource/time-efm32.c b/drivers/clocksource/time-efm32.c
index ce0f97b..257e810 100644
--- a/drivers/clocksource/time-efm32.c
+++ b/drivers/clocksource/time-efm32.c
@@ -283,5 +283,5 @@ static int __init efm32_timer_init(struct device_node *np)
 
 	return ret;
 }
-CLOCKSOURCE_OF_DECLARE(efm32compat, "efm32,timer", efm32_timer_init);
-CLOCKSOURCE_OF_DECLARE(efm32, "energymicro,efm32-timer", efm32_timer_init);
+TIMER_OF_DECLARE(efm32compat, "efm32,timer", efm32_timer_init);
+TIMER_OF_DECLARE(efm32, "energymicro,efm32-timer", efm32_timer_init);
diff --git a/drivers/clocksource/time-lpc32xx.c b/drivers/clocksource/time-lpc32xx.c
index 9649cfd..d51a62a 100644
--- a/drivers/clocksource/time-lpc32xx.c
+++ b/drivers/clocksource/time-lpc32xx.c
@@ -311,4 +311,4 @@ static int __init lpc32xx_timer_init(struct device_node *np)
 
 	return ret;
 }
-CLOCKSOURCE_OF_DECLARE(lpc32xx_timer, "nxp,lpc3220-timer", lpc32xx_timer_init);
+TIMER_OF_DECLARE(lpc32xx_timer, "nxp,lpc3220-timer", lpc32xx_timer_init);
diff --git a/drivers/clocksource/time-orion.c b/drivers/clocksource/time-orion.c
index b9b97f6..1220206 100644
--- a/drivers/clocksource/time-orion.c
+++ b/drivers/clocksource/time-orion.c
@@ -189,4 +189,4 @@ static int __init orion_timer_init(struct device_node *np)
 
 	return 0;
 }
-CLOCKSOURCE_OF_DECLARE(orion_timer, "marvell,orion-timer", orion_timer_init);
+TIMER_OF_DECLARE(orion_timer, "marvell,orion-timer", orion_timer_init);
diff --git a/drivers/clocksource/time-pistachio.c b/drivers/clocksource/time-pistachio.c
index 3710e4d..a2dd85d 100644
--- a/drivers/clocksource/time-pistachio.c
+++ b/drivers/clocksource/time-pistachio.c
@@ -214,5 +214,5 @@ static int __init pistachio_clksrc_of_init(struct device_node *node)
 	sched_clock_register(pistachio_read_sched_clock, 32, rate);
 	return clocksource_register_hz(&pcs_gpt.cs, rate);
 }
-CLOCKSOURCE_OF_DECLARE(pistachio_gptimer, "img,pistachio-gptimer",
+TIMER_OF_DECLARE(pistachio_gptimer, "img,pistachio-gptimer",
 		       pistachio_clksrc_of_init);
diff --git a/drivers/clocksource/timer-atlas7.c b/drivers/clocksource/timer-atlas7.c
index 50300ee..62c4bbc 100644
--- a/drivers/clocksource/timer-atlas7.c
+++ b/drivers/clocksource/timer-atlas7.c
@@ -283,4 +283,4 @@ static int __init sirfsoc_of_timer_init(struct device_node *np)
 
 	return sirfsoc_atlas7_timer_init(np);
 }
-CLOCKSOURCE_OF_DECLARE(sirfsoc_atlas7_timer, "sirf,atlas7-tick", sirfsoc_of_timer_init);
+TIMER_OF_DECLARE(sirfsoc_atlas7_timer, "sirf,atlas7-tick", sirfsoc_of_timer_init);
diff --git a/drivers/clocksource/timer-atmel-pit.c b/drivers/clocksource/timer-atmel-pit.c
index cc11235..ec8a437 100644
--- a/drivers/clocksource/timer-atmel-pit.c
+++ b/drivers/clocksource/timer-atmel-pit.c
@@ -255,5 +255,5 @@ static int __init at91sam926x_pit_dt_init(struct device_node *node)
 
 	return 0;
 }
-CLOCKSOURCE_OF_DECLARE(at91sam926x_pit, "atmel,at91sam9260-pit",
+TIMER_OF_DECLARE(at91sam926x_pit, "atmel,at91sam9260-pit",
 		       at91sam926x_pit_dt_init);
diff --git a/drivers/clocksource/timer-atmel-st.c b/drivers/clocksource/timer-atmel-st.c
index be4ac76..d2e660f 100644
--- a/drivers/clocksource/timer-atmel-st.c
+++ b/drivers/clocksource/timer-atmel-st.c
@@ -260,5 +260,5 @@ static int __init atmel_st_timer_init(struct device_node *node)
 	/* register clocksource */
 	return clocksource_register_hz(&clk32k, sclk_rate);
 }
-CLOCKSOURCE_OF_DECLARE(atmel_st_timer, "atmel,at91rm9200-st",
+TIMER_OF_DECLARE(atmel_st_timer, "atmel,at91rm9200-st",
 		       atmel_st_timer_init);
diff --git a/drivers/clocksource/timer-digicolor.c b/drivers/clocksource/timer-digicolor.c
index 94a161e..1e984a4 100644
--- a/drivers/clocksource/timer-digicolor.c
+++ b/drivers/clocksource/timer-digicolor.c
@@ -203,5 +203,5 @@ static int __init digicolor_timer_init(struct device_node *node)
 
 	return 0;
 }
-CLOCKSOURCE_OF_DECLARE(conexant_digicolor, "cnxt,cx92755-timer",
+TIMER_OF_DECLARE(conexant_digicolor, "cnxt,cx92755-timer",
 		       digicolor_timer_init);
diff --git a/drivers/clocksource/timer-fttmr010.c b/drivers/clocksource/timer-fttmr010.c
index d96190e..a21020c 100644
--- a/drivers/clocksource/timer-fttmr010.c
+++ b/drivers/clocksource/timer-fttmr010.c
@@ -364,8 +364,8 @@ static __init int fttmr010_timer_init(struct device_node *np)
 	return fttmr010_common_init(np, false);
 }
 
-CLOCKSOURCE_OF_DECLARE(fttmr010, "faraday,fttmr010", fttmr010_timer_init);
-CLOCKSOURCE_OF_DECLARE(gemini, "cortina,gemini-timer", fttmr010_timer_init);
-CLOCKSOURCE_OF_DECLARE(moxart, "moxa,moxart-timer", fttmr010_timer_init);
-CLOCKSOURCE_OF_DECLARE(ast2400, "aspeed,ast2400-timer", aspeed_timer_init);
-CLOCKSOURCE_OF_DECLARE(ast2500, "aspeed,ast2500-timer", aspeed_timer_init);
+TIMER_OF_DECLARE(fttmr010, "faraday,fttmr010", fttmr010_timer_init);
+TIMER_OF_DECLARE(gemini, "cortina,gemini-timer", fttmr010_timer_init);
+TIMER_OF_DECLARE(moxart, "moxa,moxart-timer", fttmr010_timer_init);
+TIMER_OF_DECLARE(ast2400, "aspeed,ast2400-timer", aspeed_timer_init);
+TIMER_OF_DECLARE(ast2500, "aspeed,ast2500-timer", aspeed_timer_init);
diff --git a/drivers/clocksource/timer-imx-gpt.c b/drivers/clocksource/timer-imx-gpt.c
index f595460..6ec6d79 100644
--- a/drivers/clocksource/timer-imx-gpt.c
+++ b/drivers/clocksource/timer-imx-gpt.c
@@ -545,15 +545,15 @@ static int __init imx6dl_timer_init_dt(struct device_node *np)
 	return mxc_timer_init_dt(np, GPT_TYPE_IMX6DL);
 }
 
-CLOCKSOURCE_OF_DECLARE(imx1_timer, "fsl,imx1-gpt", imx1_timer_init_dt);
-CLOCKSOURCE_OF_DECLARE(imx21_timer, "fsl,imx21-gpt", imx21_timer_init_dt);
-CLOCKSOURCE_OF_DECLARE(imx27_timer, "fsl,imx27-gpt", imx21_timer_init_dt);
-CLOCKSOURCE_OF_DECLARE(imx31_timer, "fsl,imx31-gpt", imx31_timer_init_dt);
-CLOCKSOURCE_OF_DECLARE(imx25_timer, "fsl,imx25-gpt", imx31_timer_init_dt);
-CLOCKSOURCE_OF_DECLARE(imx50_timer, "fsl,imx50-gpt", imx31_timer_init_dt);
-CLOCKSOURCE_OF_DECLARE(imx51_timer, "fsl,imx51-gpt", imx31_timer_init_dt);
-CLOCKSOURCE_OF_DECLARE(imx53_timer, "fsl,imx53-gpt", imx31_timer_init_dt);
-CLOCKSOURCE_OF_DECLARE(imx6q_timer, "fsl,imx6q-gpt", imx31_timer_init_dt);
-CLOCKSOURCE_OF_DECLARE(imx6dl_timer, "fsl,imx6dl-gpt", imx6dl_timer_init_dt);
-CLOCKSOURCE_OF_DECLARE(imx6sl_timer, "fsl,imx6sl-gpt", imx6dl_timer_init_dt);
-CLOCKSOURCE_OF_DECLARE(imx6sx_timer, "fsl,imx6sx-gpt", imx6dl_timer_init_dt);
+TIMER_OF_DECLARE(imx1_timer, "fsl,imx1-gpt", imx1_timer_init_dt);
+TIMER_OF_DECLARE(imx21_timer, "fsl,imx21-gpt", imx21_timer_init_dt);
+TIMER_OF_DECLARE(imx27_timer, "fsl,imx27-gpt", imx21_timer_init_dt);
+TIMER_OF_DECLARE(imx31_timer, "fsl,imx31-gpt", imx31_timer_init_dt);
+TIMER_OF_DECLARE(imx25_timer, "fsl,imx25-gpt", imx31_timer_init_dt);
+TIMER_OF_DECLARE(imx50_timer, "fsl,imx50-gpt", imx31_timer_init_dt);
+TIMER_OF_DECLARE(imx51_timer, "fsl,imx51-gpt", imx31_timer_init_dt);
+TIMER_OF_DECLARE(imx53_timer, "fsl,imx53-gpt", imx31_timer_init_dt);
+TIMER_OF_DECLARE(imx6q_timer, "fsl,imx6q-gpt", imx31_timer_init_dt);
+TIMER_OF_DECLARE(imx6dl_timer, "fsl,imx6dl-gpt", imx6dl_timer_init_dt);
+TIMER_OF_DECLARE(imx6sl_timer, "fsl,imx6sl-gpt", imx6dl_timer_init_dt);
+TIMER_OF_DECLARE(imx6sx_timer, "fsl,imx6sx-gpt", imx6dl_timer_init_dt);
diff --git a/drivers/clocksource/timer-integrator-ap.c b/drivers/clocksource/timer-integrator-ap.c
index 04ad306..2ff64d9 100644
--- a/drivers/clocksource/timer-integrator-ap.c
+++ b/drivers/clocksource/timer-integrator-ap.c
@@ -232,5 +232,5 @@ static int __init integrator_ap_timer_init_of(struct device_node *node)
 	return 0;
 }
 
-CLOCKSOURCE_OF_DECLARE(integrator_ap_timer, "arm,integrator-timer",
+TIMER_OF_DECLARE(integrator_ap_timer, "arm,integrator-timer",
 		       integrator_ap_timer_init_of);
diff --git a/drivers/clocksource/timer-keystone.c b/drivers/clocksource/timer-keystone.c
index ab68a47..0eee032 100644
--- a/drivers/clocksource/timer-keystone.c
+++ b/drivers/clocksource/timer-keystone.c
@@ -226,5 +226,5 @@ static int __init keystone_timer_init(struct device_node *np)
 	return error;
 }
 
-CLOCKSOURCE_OF_DECLARE(keystone_timer, "ti,keystone-timer",
+TIMER_OF_DECLARE(keystone_timer, "ti,keystone-timer",
 			   keystone_timer_init);
diff --git a/drivers/clocksource/timer-nps.c b/drivers/clocksource/timer-nps.c
index e74ea17..7b6bb0d 100644
--- a/drivers/clocksource/timer-nps.c
+++ b/drivers/clocksource/timer-nps.c
@@ -110,9 +110,9 @@ static int __init nps_setup_clocksource(struct device_node *node)
 	return ret;
 }
 
-CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
+TIMER_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
 		       nps_setup_clocksource);
-CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_src, "ezchip,nps400-timer1",
+TIMER_OF_DECLARE(ezchip_nps400_clk_src, "ezchip,nps400-timer1",
 		       nps_setup_clocksource);
 
 #ifdef CONFIG_EZNPS_MTM_EXT
@@ -279,6 +279,6 @@ static int __init nps_setup_clockevent(struct device_node *node)
 	return 0;
 }
 
-CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_evt, "ezchip,nps400-timer0",
+TIMER_OF_DECLARE(ezchip_nps400_clk_evt, "ezchip,nps400-timer0",
 		       nps_setup_clockevent);
 #endif /* CONFIG_EZNPS_MTM_EXT */
diff --git a/drivers/clocksource/timer-oxnas-rps.c b/drivers/clocksource/timer-oxnas-rps.c
index d630bf4..eed6fef 100644
--- a/drivers/clocksource/timer-oxnas-rps.c
+++ b/drivers/clocksource/timer-oxnas-rps.c
@@ -293,7 +293,7 @@ static int __init oxnas_rps_timer_init(struct device_node *np)
 	return ret;
 }
 
-CLOCKSOURCE_OF_DECLARE(ox810se_rps,
+TIMER_OF_DECLARE(ox810se_rps,
 		       "oxsemi,ox810se-rps-timer", oxnas_rps_timer_init);
-CLOCKSOURCE_OF_DECLARE(ox820_rps,
+TIMER_OF_DECLARE(ox820_rps,
 		       "oxsemi,ox820se-rps-timer", oxnas_rps_timer_init);
diff --git a/drivers/clocksource/timer-prima2.c b/drivers/clocksource/timer-prima2.c
index b4122ed..20ff33b 100644
--- a/drivers/clocksource/timer-prima2.c
+++ b/drivers/clocksource/timer-prima2.c
@@ -245,5 +245,5 @@ static int __init sirfsoc_prima2_timer_init(struct device_node *np)
 
 	return 0;
 }
-CLOCKSOURCE_OF_DECLARE(sirfsoc_prima2_timer,
+TIMER_OF_DECLARE(sirfsoc_prima2_timer,
 	"sirf,prima2-tick", sirfsoc_prima2_timer_init);
diff --git a/drivers/clocksource/timer-sp804.c b/drivers/clocksource/timer-sp804.c
index 2d575a8c..3ac9dec 100644
--- a/drivers/clocksource/timer-sp804.c
+++ b/drivers/clocksource/timer-sp804.c
@@ -287,7 +287,7 @@ static int __init sp804_of_init(struct device_node *np)
 	iounmap(base);
 	return ret;
 }
-CLOCKSOURCE_OF_DECLARE(sp804, "arm,sp804", sp804_of_init);
+TIMER_OF_DECLARE(sp804, "arm,sp804", sp804_of_init);
 
 static int __init integrator_cp_of_init(struct device_node *np)
 {
@@ -335,4 +335,4 @@ static int __init integrator_cp_of_init(struct device_node *np)
 	iounmap(base);
 	return ret;
 }
-CLOCKSOURCE_OF_DECLARE(intcp, "arm,integrator-cp-timer", integrator_cp_of_init);
+TIMER_OF_DECLARE(intcp, "arm,integrator-cp-timer", integrator_cp_of_init);
diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
index 1b2574c..174d1243 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -187,4 +187,4 @@ static int __init stm32_clockevent_init(struct device_node *np)
 	return ret;
 }
 
-CLOCKSOURCE_OF_DECLARE(stm32, "st,stm32-timer", stm32_clockevent_init);
+TIMER_OF_DECLARE(stm32, "st,stm32-timer", stm32_clockevent_init);
diff --git a/drivers/clocksource/timer-sun5i.c b/drivers/clocksource/timer-sun5i.c
index 2e9c830..a4ebc8f 100644
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -358,7 +358,7 @@ static int __init sun5i_timer_init(struct device_node *node)
 
 	return sun5i_setup_clockevent(node, timer_base, clk, irq);
 }
-CLOCKSOURCE_OF_DECLARE(sun5i_a13, "allwinner,sun5i-a13-hstimer",
+TIMER_OF_DECLARE(sun5i_a13, "allwinner,sun5i-a13-hstimer",
 			   sun5i_timer_init);
-CLOCKSOURCE_OF_DECLARE(sun7i_a20, "allwinner,sun7i-a20-hstimer",
+TIMER_OF_DECLARE(sun7i_a20, "allwinner,sun7i-a20-hstimer",
 			   sun5i_timer_init);
diff --git a/drivers/clocksource/timer-ti-32k.c b/drivers/clocksource/timer-ti-32k.c
index 6240677..880a861 100644
--- a/drivers/clocksource/timer-ti-32k.c
+++ b/drivers/clocksource/timer-ti-32k.c
@@ -124,5 +124,5 @@ static int __init ti_32k_timer_init(struct device_node *np)
 
 	return 0;
 }
-CLOCKSOURCE_OF_DECLARE(ti_32k_timer, "ti,omap-counter32k",
+TIMER_OF_DECLARE(ti_32k_timer, "ti,omap-counter32k",
 		ti_32k_timer_init);
diff --git a/drivers/clocksource/timer-u300.c b/drivers/clocksource/timer-u300.c
index 704e40c..be34b11 100644
--- a/drivers/clocksource/timer-u300.c
+++ b/drivers/clocksource/timer-u300.c
@@ -458,5 +458,5 @@ static int __init u300_timer_init_of(struct device_node *np)
 	return 0;
 }
 
-CLOCKSOURCE_OF_DECLARE(u300_timer, "stericsson,u300-apptimer",
+TIMER_OF_DECLARE(u300_timer, "stericsson,u300-apptimer",
 		       u300_timer_init_of);
diff --git a/drivers/clocksource/versatile.c b/drivers/clocksource/versatile.c
index 220b490..39725d3 100644
--- a/drivers/clocksource/versatile.c
+++ b/drivers/clocksource/versatile.c
@@ -38,7 +38,7 @@ static int __init versatile_sched_clock_init(struct device_node *node)
 
 	return 0;
 }
-CLOCKSOURCE_OF_DECLARE(vexpress, "arm,vexpress-sysreg",
+TIMER_OF_DECLARE(vexpress, "arm,vexpress-sysreg",
 		       versatile_sched_clock_init);
-CLOCKSOURCE_OF_DECLARE(versatile, "arm,versatile-sysreg",
+TIMER_OF_DECLARE(versatile, "arm,versatile-sysreg",
 		       versatile_sched_clock_init);
diff --git a/drivers/clocksource/vf_pit_timer.c b/drivers/clocksource/vf_pit_timer.c
index e0849e2..0f92089 100644
--- a/drivers/clocksource/vf_pit_timer.c
+++ b/drivers/clocksource/vf_pit_timer.c
@@ -201,4 +201,4 @@ static int __init pit_timer_init(struct device_node *np)
 
 	return pit_clockevent_init(clk_rate, irq);
 }
-CLOCKSOURCE_OF_DECLARE(vf610, "fsl,vf610-pit", pit_timer_init);
+TIMER_OF_DECLARE(vf610, "fsl,vf610-pit", pit_timer_init);
diff --git a/drivers/clocksource/vt8500_timer.c b/drivers/clocksource/vt8500_timer.c
index d02b510..e0f7489 100644
--- a/drivers/clocksource/vt8500_timer.c
+++ b/drivers/clocksource/vt8500_timer.c
@@ -165,4 +165,4 @@ static int __init vt8500_timer_init(struct device_node *np)
 	return 0;
 }
 
-CLOCKSOURCE_OF_DECLARE(vt8500, "via,vt8500-timer", vt8500_timer_init);
+TIMER_OF_DECLARE(vt8500, "via,vt8500-timer", vt8500_timer_init);
diff --git a/drivers/clocksource/zevio-timer.c b/drivers/clocksource/zevio-timer.c
index 9a53f5e..a6a0338 100644
--- a/drivers/clocksource/zevio-timer.c
+++ b/drivers/clocksource/zevio-timer.c
@@ -215,4 +215,4 @@ static int __init zevio_timer_init(struct device_node *node)
 	return zevio_timer_add(node);
 }
 
-CLOCKSOURCE_OF_DECLARE(zevio_timer, "lsi,zevio-timer", zevio_timer_init);
+TIMER_OF_DECLARE(zevio_timer, "lsi,zevio-timer", zevio_timer_init);
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index f2b10d9..a86b65f 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -249,7 +249,7 @@ extern int clocksource_mmio_init(void __iomem *, const char *,
 
 extern int clocksource_i8253_init(void);
 
-#define CLOCKSOURCE_OF_DECLARE(name, compat, fn) \
+#define TIMER_OF_DECLARE(name, compat, fn) \
 	OF_DECLARE_1_RET(clksrc, name, compat, fn)
 
 #ifdef CONFIG_CLKSRC_PROBE
-- 
2.7.4



From linus.walleij at linaro.org  Sun May 28 06:48:18 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 28 May 2017 15:48:18 +0200
Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
In-Reply-To: <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
 <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <CACRpkdZbVv94hE9Gg+xiH2dxJANo-fPwLSek+BE4QwWWWWUixw@mail.gmail.com>

On Sat, May 27, 2017 at 11:58 AM, Daniel Lezcano
<daniel.lezcano at linaro.org> wrote:

> The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the
> clocksource at early stage. However, this macro is also used to initialize
> the clockevent if any, or the clockevent only.
>
> It was originally suggested to declare another macro to initialize a
> clockevent, so in order to separate the two entities even they belong to the
> same IP. This was not accepted because of the impact on the DT where splitting
> a clocksource/clockevent definition does not make sense as it is a Linux
> concept not a hardware description.
>
> On the other side, the clocksource has not interrupt declared while the
> clockevent has, so it is easy from the driver to know if the description is
> for a clockevent or a clocksource, IOW it could be implemented at the driver
> level.
>
> So instead of dealing with a named clocksource macro, let's use a more generic
> one: TIMER_OF_DECLARE.
>
> The patch has not functional changes.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>'

This makes the macro make sense and I had this idea one time too.
Awesome.
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij

> ---
>  arch/arm/kernel/smp_twd.c                 |  6 +++---
>  arch/microblaze/kernel/timer.c            |  2 +-
>  arch/mips/ralink/cevt-rt3352.c            |  2 +-
>  arch/nios2/kernel/time.c                  |  2 +-
>  drivers/clocksource/arc_timer.c           |  6 +++---
>  drivers/clocksource/arm_arch_timer.c      |  6 +++---
>  drivers/clocksource/arm_global_timer.c    |  2 +-
>  drivers/clocksource/armv7m_systick.c      |  2 +-
>  drivers/clocksource/asm9260_timer.c       |  2 +-
>  drivers/clocksource/bcm2835_timer.c       |  2 +-
>  drivers/clocksource/bcm_kona_timer.c      |  4 ++--
>  drivers/clocksource/cadence_ttc_timer.c   |  2 +-
>  drivers/clocksource/clksrc-dbx500-prcmu.c |  2 +-
>  drivers/clocksource/clksrc_st_lpc.c       |  2 +-
>  drivers/clocksource/clps711x-timer.c      |  2 +-
>  drivers/clocksource/dw_apb_timer_of.c     |  8 ++++----
>  drivers/clocksource/exynos_mct.c          |  4 ++--
>  drivers/clocksource/fsl_ftm_timer.c       |  2 +-
>  drivers/clocksource/h8300_timer16.c       |  2 +-
>  drivers/clocksource/h8300_timer8.c        |  2 +-
>  drivers/clocksource/h8300_tpu.c           |  2 +-
>  drivers/clocksource/jcore-pit.c           |  2 +-
>  drivers/clocksource/meson6_timer.c        |  2 +-
>  drivers/clocksource/mips-gic-timer.c      |  2 +-
>  drivers/clocksource/mps2-timer.c          |  2 +-
>  drivers/clocksource/mtk_timer.c           |  2 +-
>  drivers/clocksource/mxs_timer.c           |  2 +-
>  drivers/clocksource/nomadik-mtu.c         |  2 +-
>  drivers/clocksource/pxa_timer.c           |  2 +-
>  drivers/clocksource/qcom-timer.c          |  4 ++--
>  drivers/clocksource/renesas-ostm.c        |  2 +-
>  drivers/clocksource/rockchip_timer.c      |  4 ++--
>  drivers/clocksource/samsung_pwm_timer.c   |  8 ++++----
>  drivers/clocksource/sun4i_timer.c         |  2 +-
>  drivers/clocksource/tango_xtal.c          |  2 +-
>  drivers/clocksource/tegra20_timer.c       |  4 ++--
>  drivers/clocksource/time-armada-370-xp.c  |  6 +++---
>  drivers/clocksource/time-efm32.c          |  4 ++--
>  drivers/clocksource/time-lpc32xx.c        |  2 +-
>  drivers/clocksource/time-orion.c          |  2 +-
>  drivers/clocksource/time-pistachio.c      |  2 +-
>  drivers/clocksource/timer-atlas7.c        |  2 +-
>  drivers/clocksource/timer-atmel-pit.c     |  2 +-
>  drivers/clocksource/timer-atmel-st.c      |  2 +-
>  drivers/clocksource/timer-digicolor.c     |  2 +-
>  drivers/clocksource/timer-fttmr010.c      | 10 +++++-----
>  drivers/clocksource/timer-imx-gpt.c       | 24 ++++++++++++------------
>  drivers/clocksource/timer-integrator-ap.c |  2 +-
>  drivers/clocksource/timer-keystone.c      |  2 +-
>  drivers/clocksource/timer-nps.c           |  6 +++---
>  drivers/clocksource/timer-oxnas-rps.c     |  4 ++--
>  drivers/clocksource/timer-prima2.c        |  2 +-
>  drivers/clocksource/timer-sp804.c         |  4 ++--
>  drivers/clocksource/timer-stm32.c         |  2 +-
>  drivers/clocksource/timer-sun5i.c         |  4 ++--
>  drivers/clocksource/timer-ti-32k.c        |  2 +-
>  drivers/clocksource/timer-u300.c          |  2 +-
>  drivers/clocksource/versatile.c           |  4 ++--
>  drivers/clocksource/vf_pit_timer.c        |  2 +-
>  drivers/clocksource/vt8500_timer.c        |  2 +-
>  drivers/clocksource/zevio-timer.c         |  2 +-
>  include/linux/clocksource.h               |  2 +-
>  62 files changed, 103 insertions(+), 103 deletions(-)
>
> diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
> index 895ae51..b30eafe 100644
> --- a/arch/arm/kernel/smp_twd.c
> +++ b/arch/arm/kernel/smp_twd.c
> @@ -403,7 +403,7 @@ static int __init twd_local_timer_of_register(struct device_node *np)
>         WARN(err, "twd_local_timer_of_register failed (%d)\n", err);
>         return err;
>  }
> -CLOCKSOURCE_OF_DECLARE(arm_twd_a9, "arm,cortex-a9-twd-timer", twd_local_timer_of_register);
> -CLOCKSOURCE_OF_DECLARE(arm_twd_a5, "arm,cortex-a5-twd-timer", twd_local_timer_of_register);
> -CLOCKSOURCE_OF_DECLARE(arm_twd_11mp, "arm,arm11mp-twd-timer", twd_local_timer_of_register);
> +TIMER_OF_DECLARE(arm_twd_a9, "arm,cortex-a9-twd-timer", twd_local_timer_of_register);
> +TIMER_OF_DECLARE(arm_twd_a5, "arm,cortex-a5-twd-timer", twd_local_timer_of_register);
> +TIMER_OF_DECLARE(arm_twd_11mp, "arm,arm11mp-twd-timer", twd_local_timer_of_register);
>  #endif
> diff --git a/arch/microblaze/kernel/timer.c b/arch/microblaze/kernel/timer.c
> index 9990661..873a1cc 100644
> --- a/arch/microblaze/kernel/timer.c
> +++ b/arch/microblaze/kernel/timer.c
> @@ -333,5 +333,5 @@ static int __init xilinx_timer_init(struct device_node *timer)
>         return 0;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(xilinx_timer, "xlnx,xps-timer-1.00.a",
> +TIMER_OF_DECLARE(xilinx_timer, "xlnx,xps-timer-1.00.a",
>                        xilinx_timer_init);
> diff --git a/arch/mips/ralink/cevt-rt3352.c b/arch/mips/ralink/cevt-rt3352.c
> index b8a1376..92f284d 100644
> --- a/arch/mips/ralink/cevt-rt3352.c
> +++ b/arch/mips/ralink/cevt-rt3352.c
> @@ -152,4 +152,4 @@ static int __init ralink_systick_init(struct device_node *np)
>         return 0;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(systick, "ralink,cevt-systick", ralink_systick_init);
> +TIMER_OF_DECLARE(systick, "ralink,cevt-systick", ralink_systick_init);
> diff --git a/arch/nios2/kernel/time.c b/arch/nios2/kernel/time.c
> index 6e2bdc9..2954b66 100644
> --- a/arch/nios2/kernel/time.c
> +++ b/arch/nios2/kernel/time.c
> @@ -353,4 +353,4 @@ void __init time_init(void)
>         clocksource_probe();
>  }
>
> -CLOCKSOURCE_OF_DECLARE(nios2_timer, ALTR_TIMER_COMPATIBLE, nios2_time_init);
> +TIMER_OF_DECLARE(nios2_timer, ALTR_TIMER_COMPATIBLE, nios2_time_init);
> diff --git a/drivers/clocksource/arc_timer.c b/drivers/clocksource/arc_timer.c
> index 2164973..4927355 100644
> --- a/drivers/clocksource/arc_timer.c
> +++ b/drivers/clocksource/arc_timer.c
> @@ -99,7 +99,7 @@ static int __init arc_cs_setup_gfrc(struct device_node *node)
>
>         return clocksource_register_hz(&arc_counter_gfrc, arc_timer_freq);
>  }
> -CLOCKSOURCE_OF_DECLARE(arc_gfrc, "snps,archs-timer-gfrc", arc_cs_setup_gfrc);
> +TIMER_OF_DECLARE(arc_gfrc, "snps,archs-timer-gfrc", arc_cs_setup_gfrc);
>
>  #define AUX_RTC_CTRL   0x103
>  #define AUX_RTC_LOW    0x104
> @@ -158,7 +158,7 @@ static int __init arc_cs_setup_rtc(struct device_node *node)
>
>         return clocksource_register_hz(&arc_counter_rtc, arc_timer_freq);
>  }
> -CLOCKSOURCE_OF_DECLARE(arc_rtc, "snps,archs-timer-rtc", arc_cs_setup_rtc);
> +TIMER_OF_DECLARE(arc_rtc, "snps,archs-timer-rtc", arc_cs_setup_rtc);
>
>  #endif
>
> @@ -333,4 +333,4 @@ static int __init arc_of_timer_init(struct device_node *np)
>
>         return ret;
>  }
> -CLOCKSOURCE_OF_DECLARE(arc_clkevt, "snps,arc-timer", arc_of_timer_init);
> +TIMER_OF_DECLARE(arc_clkevt, "snps,arc-timer", arc_of_timer_init);
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index a1fb918..9a41958 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -1194,8 +1194,8 @@ static int __init arch_timer_of_init(struct device_node *np)
>
>         return arch_timer_common_init();
>  }
> -CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_of_init);
> -CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_of_init);
> +TIMER_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_of_init);
> +TIMER_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_of_init);
>
>  static u32 __init
>  arch_timer_mem_frame_get_cntfrq(struct arch_timer_mem_frame *frame)
> @@ -1382,7 +1382,7 @@ static int __init arch_timer_mem_of_init(struct device_node *np)
>         kfree(timer_mem);
>         return ret;
>  }
> -CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
> +TIMER_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
>                        arch_timer_mem_of_init);
>
>  #ifdef CONFIG_ACPI_GTDT
> diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c
> index 123ed20..095bb96 100644
> --- a/drivers/clocksource/arm_global_timer.c
> +++ b/drivers/clocksource/arm_global_timer.c
> @@ -339,5 +339,5 @@ static int __init global_timer_of_register(struct device_node *np)
>  }
>
>  /* Only tested on r2p2 and r3p0  */
> -CLOCKSOURCE_OF_DECLARE(arm_gt, "arm,cortex-a9-global-timer",
> +TIMER_OF_DECLARE(arm_gt, "arm,cortex-a9-global-timer",
>                         global_timer_of_register);
> diff --git a/drivers/clocksource/armv7m_systick.c b/drivers/clocksource/armv7m_systick.c
> index a315491..ac046d6 100644
> --- a/drivers/clocksource/armv7m_systick.c
> +++ b/drivers/clocksource/armv7m_systick.c
> @@ -82,5 +82,5 @@ static int __init system_timer_of_register(struct device_node *np)
>         return ret;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(arm_systick, "arm,armv7m-systick",
> +TIMER_OF_DECLARE(arm_systick, "arm,armv7m-systick",
>                         system_timer_of_register);
> diff --git a/drivers/clocksource/asm9260_timer.c b/drivers/clocksource/asm9260_timer.c
> index c678083..38cd2fe 100644
> --- a/drivers/clocksource/asm9260_timer.c
> +++ b/drivers/clocksource/asm9260_timer.c
> @@ -238,5 +238,5 @@ static int __init asm9260_timer_init(struct device_node *np)
>
>         return 0;
>  }
> -CLOCKSOURCE_OF_DECLARE(asm9260_timer, "alphascale,asm9260-timer",
> +TIMER_OF_DECLARE(asm9260_timer, "alphascale,asm9260-timer",
>                 asm9260_timer_init);
> diff --git a/drivers/clocksource/bcm2835_timer.c b/drivers/clocksource/bcm2835_timer.c
> index dce4430..82828d3 100644
> --- a/drivers/clocksource/bcm2835_timer.c
> +++ b/drivers/clocksource/bcm2835_timer.c
> @@ -148,5 +148,5 @@ static int __init bcm2835_timer_init(struct device_node *node)
>         iounmap(base);
>         return ret;
>  }
> -CLOCKSOURCE_OF_DECLARE(bcm2835, "brcm,bcm2835-system-timer",
> +TIMER_OF_DECLARE(bcm2835, "brcm,bcm2835-system-timer",
>                         bcm2835_timer_init);
> diff --git a/drivers/clocksource/bcm_kona_timer.c b/drivers/clocksource/bcm_kona_timer.c
> index fda5e147..5c40be9 100644
> --- a/drivers/clocksource/bcm_kona_timer.c
> +++ b/drivers/clocksource/bcm_kona_timer.c
> @@ -198,9 +198,9 @@ static int __init kona_timer_init(struct device_node *node)
>         return 0;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(brcm_kona, "brcm,kona-timer", kona_timer_init);
> +TIMER_OF_DECLARE(brcm_kona, "brcm,kona-timer", kona_timer_init);
>  /*
>   * bcm,kona-timer is deprecated by brcm,kona-timer
>   * being kept here for driver compatibility
>   */
> -CLOCKSOURCE_OF_DECLARE(bcm_kona, "bcm,kona-timer", kona_timer_init);
> +TIMER_OF_DECLARE(bcm_kona, "bcm,kona-timer", kona_timer_init);
> diff --git a/drivers/clocksource/cadence_ttc_timer.c b/drivers/clocksource/cadence_ttc_timer.c
> index 44e5e95..a144dfc 100644
> --- a/drivers/clocksource/cadence_ttc_timer.c
> +++ b/drivers/clocksource/cadence_ttc_timer.c
> @@ -539,4 +539,4 @@ static int __init ttc_timer_init(struct device_node *timer)
>         return 0;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(ttc, "cdns,ttc", ttc_timer_init);
> +TIMER_OF_DECLARE(ttc, "cdns,ttc", ttc_timer_init);
> diff --git a/drivers/clocksource/clksrc-dbx500-prcmu.c b/drivers/clocksource/clksrc-dbx500-prcmu.c
> index c69e277..c1b96dc 100644
> --- a/drivers/clocksource/clksrc-dbx500-prcmu.c
> +++ b/drivers/clocksource/clksrc-dbx500-prcmu.c
> @@ -86,5 +86,5 @@ static int __init clksrc_dbx500_prcmu_init(struct device_node *node)
>  #endif
>         return clocksource_register_hz(&clocksource_dbx500_prcmu, RATE_32K);
>  }
> -CLOCKSOURCE_OF_DECLARE(dbx500_prcmu, "stericsson,db8500-prcmu-timer-4",
> +TIMER_OF_DECLARE(dbx500_prcmu, "stericsson,db8500-prcmu-timer-4",
>                        clksrc_dbx500_prcmu_init);
> diff --git a/drivers/clocksource/clksrc_st_lpc.c b/drivers/clocksource/clksrc_st_lpc.c
> index 03cc492..a1d01eb 100644
> --- a/drivers/clocksource/clksrc_st_lpc.c
> +++ b/drivers/clocksource/clksrc_st_lpc.c
> @@ -132,4 +132,4 @@ static int __init st_clksrc_of_register(struct device_node *np)
>
>         return ret;
>  }
> -CLOCKSOURCE_OF_DECLARE(ddata, "st,stih407-lpc", st_clksrc_of_register);
> +TIMER_OF_DECLARE(ddata, "st,stih407-lpc", st_clksrc_of_register);
> diff --git a/drivers/clocksource/clps711x-timer.c b/drivers/clocksource/clps711x-timer.c
> index 24db6d6..fc9e025 100644
> --- a/drivers/clocksource/clps711x-timer.c
> +++ b/drivers/clocksource/clps711x-timer.c
> @@ -119,5 +119,5 @@ static int __init clps711x_timer_init(struct device_node *np)
>                 return -EINVAL;
>         }
>  }
> -CLOCKSOURCE_OF_DECLARE(clps711x, "cirrus,ep7209-timer", clps711x_timer_init);
> +TIMER_OF_DECLARE(clps711x, "cirrus,ep7209-timer", clps711x_timer_init);
>  #endif
> diff --git a/drivers/clocksource/dw_apb_timer_of.c b/drivers/clocksource/dw_apb_timer_of.c
> index aee6c0d..69866cd 100644
> --- a/drivers/clocksource/dw_apb_timer_of.c
> +++ b/drivers/clocksource/dw_apb_timer_of.c
> @@ -167,7 +167,7 @@ static int __init dw_apb_timer_init(struct device_node *timer)
>
>         return 0;
>  }
> -CLOCKSOURCE_OF_DECLARE(pc3x2_timer, "picochip,pc3x2-timer", dw_apb_timer_init);
> -CLOCKSOURCE_OF_DECLARE(apb_timer_osc, "snps,dw-apb-timer-osc", dw_apb_timer_init);
> -CLOCKSOURCE_OF_DECLARE(apb_timer_sp, "snps,dw-apb-timer-sp", dw_apb_timer_init);
> -CLOCKSOURCE_OF_DECLARE(apb_timer, "snps,dw-apb-timer", dw_apb_timer_init);
> +TIMER_OF_DECLARE(pc3x2_timer, "picochip,pc3x2-timer", dw_apb_timer_init);
> +TIMER_OF_DECLARE(apb_timer_osc, "snps,dw-apb-timer-osc", dw_apb_timer_init);
> +TIMER_OF_DECLARE(apb_timer_sp, "snps,dw-apb-timer-sp", dw_apb_timer_init);
> +TIMER_OF_DECLARE(apb_timer, "snps,dw-apb-timer", dw_apb_timer_init);
> diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
> index 670ff0f..7a244b6 100644
> --- a/drivers/clocksource/exynos_mct.c
> +++ b/drivers/clocksource/exynos_mct.c
> @@ -610,5 +610,5 @@ static int __init mct_init_ppi(struct device_node *np)
>  {
>         return mct_init_dt(np, MCT_INT_PPI);
>  }
> -CLOCKSOURCE_OF_DECLARE(exynos4210, "samsung,exynos4210-mct", mct_init_spi);
> -CLOCKSOURCE_OF_DECLARE(exynos4412, "samsung,exynos4412-mct", mct_init_ppi);
> +TIMER_OF_DECLARE(exynos4210, "samsung,exynos4210-mct", mct_init_spi);
> +TIMER_OF_DECLARE(exynos4412, "samsung,exynos4412-mct", mct_init_ppi);
> diff --git a/drivers/clocksource/fsl_ftm_timer.c b/drivers/clocksource/fsl_ftm_timer.c
> index 738515b..3121e2d 100644
> --- a/drivers/clocksource/fsl_ftm_timer.c
> +++ b/drivers/clocksource/fsl_ftm_timer.c
> @@ -369,4 +369,4 @@ static int __init ftm_timer_init(struct device_node *np)
>         kfree(priv);
>         return ret;
>  }
> -CLOCKSOURCE_OF_DECLARE(flextimer, "fsl,ftm-timer", ftm_timer_init);
> +TIMER_OF_DECLARE(flextimer, "fsl,ftm-timer", ftm_timer_init);
> diff --git a/drivers/clocksource/h8300_timer16.c b/drivers/clocksource/h8300_timer16.c
> index 5b27fb9..dfbd4f8 100644
> --- a/drivers/clocksource/h8300_timer16.c
> +++ b/drivers/clocksource/h8300_timer16.c
> @@ -187,5 +187,5 @@ static int __init h8300_16timer_init(struct device_node *node)
>         return ret;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(h8300_16bit, "renesas,16bit-timer",
> +TIMER_OF_DECLARE(h8300_16bit, "renesas,16bit-timer",
>                            h8300_16timer_init);
> diff --git a/drivers/clocksource/h8300_timer8.c b/drivers/clocksource/h8300_timer8.c
> index 804c489..f6ffb0c 100644
> --- a/drivers/clocksource/h8300_timer8.c
> +++ b/drivers/clocksource/h8300_timer8.c
> @@ -207,4 +207,4 @@ static int __init h8300_8timer_init(struct device_node *node)
>         return ret;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(h8300_8bit, "renesas,8bit-timer", h8300_8timer_init);
> +TIMER_OF_DECLARE(h8300_8bit, "renesas,8bit-timer", h8300_8timer_init);
> diff --git a/drivers/clocksource/h8300_tpu.c b/drivers/clocksource/h8300_tpu.c
> index 72e1cf2..45a8d17 100644
> --- a/drivers/clocksource/h8300_tpu.c
> +++ b/drivers/clocksource/h8300_tpu.c
> @@ -154,4 +154,4 @@ static int __init h8300_tpu_init(struct device_node *node)
>         return ret;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(h8300_tpu, "renesas,tpu", h8300_tpu_init);
> +TIMER_OF_DECLARE(h8300_tpu, "renesas,tpu", h8300_tpu_init);
> diff --git a/drivers/clocksource/jcore-pit.c b/drivers/clocksource/jcore-pit.c
> index 7c61226..5d3d88e0f 100644
> --- a/drivers/clocksource/jcore-pit.c
> +++ b/drivers/clocksource/jcore-pit.c
> @@ -246,4 +246,4 @@ static int __init jcore_pit_init(struct device_node *node)
>         return 0;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
> +TIMER_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
> diff --git a/drivers/clocksource/meson6_timer.c b/drivers/clocksource/meson6_timer.c
> index 39d21f6..92f2099 100644
> --- a/drivers/clocksource/meson6_timer.c
> +++ b/drivers/clocksource/meson6_timer.c
> @@ -174,5 +174,5 @@ static int __init meson6_timer_init(struct device_node *node)
>                                         1, 0xfffe);
>         return 0;
>  }
> -CLOCKSOURCE_OF_DECLARE(meson6, "amlogic,meson6-timer",
> +TIMER_OF_DECLARE(meson6, "amlogic,meson6-timer",
>                        meson6_timer_init);
> diff --git a/drivers/clocksource/mips-gic-timer.c b/drivers/clocksource/mips-gic-timer.c
> index 3f52ee2..e31e083 100644
> --- a/drivers/clocksource/mips-gic-timer.c
> +++ b/drivers/clocksource/mips-gic-timer.c
> @@ -200,5 +200,5 @@ static int __init gic_clocksource_of_init(struct device_node *node)
>
>         return 0;
>  }
> -CLOCKSOURCE_OF_DECLARE(mips_gic_timer, "mti,gic-timer",
> +TIMER_OF_DECLARE(mips_gic_timer, "mti,gic-timer",
>                        gic_clocksource_of_init);
> diff --git a/drivers/clocksource/mps2-timer.c b/drivers/clocksource/mps2-timer.c
> index 3e4431e..aa4d63af 100644
> --- a/drivers/clocksource/mps2-timer.c
> +++ b/drivers/clocksource/mps2-timer.c
> @@ -274,4 +274,4 @@ static int __init mps2_timer_init(struct device_node *np)
>         return 0;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(mps2_timer, "arm,mps2-timer", mps2_timer_init);
> +TIMER_OF_DECLARE(mps2_timer, "arm,mps2-timer", mps2_timer_init);
> diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
> index 9065949..f9b724f 100644
> --- a/drivers/clocksource/mtk_timer.c
> +++ b/drivers/clocksource/mtk_timer.c
> @@ -265,4 +265,4 @@ static int __init mtk_timer_init(struct device_node *node)
>
>         return -EINVAL;
>  }
> -CLOCKSOURCE_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_timer_init);
> +TIMER_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_timer_init);
> diff --git a/drivers/clocksource/mxs_timer.c b/drivers/clocksource/mxs_timer.c
> index 99b77af..a03434e 100644
> --- a/drivers/clocksource/mxs_timer.c
> +++ b/drivers/clocksource/mxs_timer.c
> @@ -293,4 +293,4 @@ static int __init mxs_timer_init(struct device_node *np)
>
>         return setup_irq(irq, &mxs_timer_irq);
>  }
> -CLOCKSOURCE_OF_DECLARE(mxs, "fsl,timrot", mxs_timer_init);
> +TIMER_OF_DECLARE(mxs, "fsl,timrot", mxs_timer_init);
> diff --git a/drivers/clocksource/nomadik-mtu.c b/drivers/clocksource/nomadik-mtu.c
> index 7d44de3..8e4ddb9 100644
> --- a/drivers/clocksource/nomadik-mtu.c
> +++ b/drivers/clocksource/nomadik-mtu.c
> @@ -284,5 +284,5 @@ static int __init nmdk_timer_of_init(struct device_node *node)
>
>         return nmdk_timer_init(base, irq, pclk, clk);
>  }
> -CLOCKSOURCE_OF_DECLARE(nomadik_mtu, "st,nomadik-mtu",
> +TIMER_OF_DECLARE(nomadik_mtu, "st,nomadik-mtu",
>                        nmdk_timer_of_init);
> diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
> index a10fa667..08cd6eaf 100644
> --- a/drivers/clocksource/pxa_timer.c
> +++ b/drivers/clocksource/pxa_timer.c
> @@ -216,7 +216,7 @@ static int __init pxa_timer_dt_init(struct device_node *np)
>
>         return pxa_timer_common_init(irq, clk_get_rate(clk));
>  }
> -CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);
> +TIMER_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);
>
>  /*
>   * Legacy timer init for non device-tree boards.
> diff --git a/drivers/clocksource/qcom-timer.c b/drivers/clocksource/qcom-timer.c
> index ee358cd..89816f8 100644
> --- a/drivers/clocksource/qcom-timer.c
> +++ b/drivers/clocksource/qcom-timer.c
> @@ -254,5 +254,5 @@ static int __init msm_dt_timer_init(struct device_node *np)
>
>         return msm_timer_init(freq, 32, irq, !!percpu_offset);
>  }
> -CLOCKSOURCE_OF_DECLARE(kpss_timer, "qcom,kpss-timer", msm_dt_timer_init);
> -CLOCKSOURCE_OF_DECLARE(scss_timer, "qcom,scss-timer", msm_dt_timer_init);
> +TIMER_OF_DECLARE(kpss_timer, "qcom,kpss-timer", msm_dt_timer_init);
> +TIMER_OF_DECLARE(scss_timer, "qcom,scss-timer", msm_dt_timer_init);
> diff --git a/drivers/clocksource/renesas-ostm.c b/drivers/clocksource/renesas-ostm.c
> index c76f576..6cffd7c 100644
> --- a/drivers/clocksource/renesas-ostm.c
> +++ b/drivers/clocksource/renesas-ostm.c
> @@ -262,4 +262,4 @@ static int __init ostm_init(struct device_node *np)
>         return 0;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(ostm, "renesas,ostm", ostm_init);
> +TIMER_OF_DECLARE(ostm, "renesas,ostm", ostm_init);
> diff --git a/drivers/clocksource/rockchip_timer.c b/drivers/clocksource/rockchip_timer.c
> index 49c02be..c27f4c8 100644
> --- a/drivers/clocksource/rockchip_timer.c
> +++ b/drivers/clocksource/rockchip_timer.c
> @@ -303,5 +303,5 @@ static int __init rk_timer_init(struct device_node *np)
>         return -EINVAL;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(rk3288_timer, "rockchip,rk3288-timer", rk_timer_init);
> -CLOCKSOURCE_OF_DECLARE(rk3399_timer, "rockchip,rk3399-timer", rk_timer_init);
> +TIMER_OF_DECLARE(rk3288_timer, "rockchip,rk3288-timer", rk_timer_init);
> +TIMER_OF_DECLARE(rk3399_timer, "rockchip,rk3399-timer", rk_timer_init);
> diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c
> index a68e653..21cd72c 100644
> --- a/drivers/clocksource/samsung_pwm_timer.c
> +++ b/drivers/clocksource/samsung_pwm_timer.c
> @@ -466,7 +466,7 @@ static int __init s3c2410_pwm_clocksource_init(struct device_node *np)
>  {
>         return samsung_pwm_alloc(np, &s3c24xx_variant);
>  }
> -CLOCKSOURCE_OF_DECLARE(s3c2410_pwm, "samsung,s3c2410-pwm", s3c2410_pwm_clocksource_init);
> +TIMER_OF_DECLARE(s3c2410_pwm, "samsung,s3c2410-pwm", s3c2410_pwm_clocksource_init);
>
>  static const struct samsung_pwm_variant s3c64xx_variant = {
>         .bits           = 32,
> @@ -479,7 +479,7 @@ static int __init s3c64xx_pwm_clocksource_init(struct device_node *np)
>  {
>         return samsung_pwm_alloc(np, &s3c64xx_variant);
>  }
> -CLOCKSOURCE_OF_DECLARE(s3c6400_pwm, "samsung,s3c6400-pwm", s3c64xx_pwm_clocksource_init);
> +TIMER_OF_DECLARE(s3c6400_pwm, "samsung,s3c6400-pwm", s3c64xx_pwm_clocksource_init);
>
>  static const struct samsung_pwm_variant s5p64x0_variant = {
>         .bits           = 32,
> @@ -492,7 +492,7 @@ static int __init s5p64x0_pwm_clocksource_init(struct device_node *np)
>  {
>         return samsung_pwm_alloc(np, &s5p64x0_variant);
>  }
> -CLOCKSOURCE_OF_DECLARE(s5p6440_pwm, "samsung,s5p6440-pwm", s5p64x0_pwm_clocksource_init);
> +TIMER_OF_DECLARE(s5p6440_pwm, "samsung,s5p6440-pwm", s5p64x0_pwm_clocksource_init);
>
>  static const struct samsung_pwm_variant s5p_variant = {
>         .bits           = 32,
> @@ -505,5 +505,5 @@ static int __init s5p_pwm_clocksource_init(struct device_node *np)
>  {
>         return samsung_pwm_alloc(np, &s5p_variant);
>  }
> -CLOCKSOURCE_OF_DECLARE(s5pc100_pwm, "samsung,s5pc100-pwm", s5p_pwm_clocksource_init);
> +TIMER_OF_DECLARE(s5pc100_pwm, "samsung,s5pc100-pwm", s5p_pwm_clocksource_init);
>  #endif
> diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
> index 4452d5c..3e4bc64 100644
> --- a/drivers/clocksource/sun4i_timer.c
> +++ b/drivers/clocksource/sun4i_timer.c
> @@ -233,5 +233,5 @@ static int __init sun4i_timer_init(struct device_node *node)
>
>         return ret;
>  }
> -CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-a10-timer",
> +TIMER_OF_DECLARE(sun4i, "allwinner,sun4i-a10-timer",
>                        sun4i_timer_init);
> diff --git a/drivers/clocksource/tango_xtal.c b/drivers/clocksource/tango_xtal.c
> index 12fcef8..c4e1c2e 100644
> --- a/drivers/clocksource/tango_xtal.c
> +++ b/drivers/clocksource/tango_xtal.c
> @@ -53,4 +53,4 @@ static int __init tango_clocksource_init(struct device_node *np)
>         return 0;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(tango, "sigma,tick-counter", tango_clocksource_init);
> +TIMER_OF_DECLARE(tango, "sigma,tick-counter", tango_clocksource_init);
> diff --git a/drivers/clocksource/tegra20_timer.c b/drivers/clocksource/tegra20_timer.c
> index b9990b9..c337a81 100644
> --- a/drivers/clocksource/tegra20_timer.c
> +++ b/drivers/clocksource/tegra20_timer.c
> @@ -237,7 +237,7 @@ static int __init tegra20_init_timer(struct device_node *np)
>
>         return 0;
>  }
> -CLOCKSOURCE_OF_DECLARE(tegra20_timer, "nvidia,tegra20-timer", tegra20_init_timer);
> +TIMER_OF_DECLARE(tegra20_timer, "nvidia,tegra20-timer", tegra20_init_timer);
>
>  static int __init tegra20_init_rtc(struct device_node *np)
>  {
> @@ -261,4 +261,4 @@ static int __init tegra20_init_rtc(struct device_node *np)
>
>         return register_persistent_clock(NULL, tegra_read_persistent_clock64);
>  }
> -CLOCKSOURCE_OF_DECLARE(tegra20_rtc, "nvidia,tegra20-rtc", tegra20_init_rtc);
> +TIMER_OF_DECLARE(tegra20_rtc, "nvidia,tegra20-rtc", tegra20_init_rtc);
> diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
> index aea4380..edf1a46 100644
> --- a/drivers/clocksource/time-armada-370-xp.c
> +++ b/drivers/clocksource/time-armada-370-xp.c
> @@ -351,7 +351,7 @@ static int __init armada_xp_timer_init(struct device_node *np)
>
>         return armada_370_xp_timer_common_init(np);
>  }
> -CLOCKSOURCE_OF_DECLARE(armada_xp, "marvell,armada-xp-timer",
> +TIMER_OF_DECLARE(armada_xp, "marvell,armada-xp-timer",
>                        armada_xp_timer_init);
>
>  static int __init armada_375_timer_init(struct device_node *np)
> @@ -389,7 +389,7 @@ static int __init armada_375_timer_init(struct device_node *np)
>
>         return armada_370_xp_timer_common_init(np);
>  }
> -CLOCKSOURCE_OF_DECLARE(armada_375, "marvell,armada-375-timer",
> +TIMER_OF_DECLARE(armada_375, "marvell,armada-375-timer",
>                        armada_375_timer_init);
>
>  static int __init armada_370_timer_init(struct device_node *np)
> @@ -412,5 +412,5 @@ static int __init armada_370_timer_init(struct device_node *np)
>
>         return armada_370_xp_timer_common_init(np);
>  }
> -CLOCKSOURCE_OF_DECLARE(armada_370, "marvell,armada-370-timer",
> +TIMER_OF_DECLARE(armada_370, "marvell,armada-370-timer",
>                        armada_370_timer_init);
> diff --git a/drivers/clocksource/time-efm32.c b/drivers/clocksource/time-efm32.c
> index ce0f97b..257e810 100644
> --- a/drivers/clocksource/time-efm32.c
> +++ b/drivers/clocksource/time-efm32.c
> @@ -283,5 +283,5 @@ static int __init efm32_timer_init(struct device_node *np)
>
>         return ret;
>  }
> -CLOCKSOURCE_OF_DECLARE(efm32compat, "efm32,timer", efm32_timer_init);
> -CLOCKSOURCE_OF_DECLARE(efm32, "energymicro,efm32-timer", efm32_timer_init);
> +TIMER_OF_DECLARE(efm32compat, "efm32,timer", efm32_timer_init);
> +TIMER_OF_DECLARE(efm32, "energymicro,efm32-timer", efm32_timer_init);
> diff --git a/drivers/clocksource/time-lpc32xx.c b/drivers/clocksource/time-lpc32xx.c
> index 9649cfd..d51a62a 100644
> --- a/drivers/clocksource/time-lpc32xx.c
> +++ b/drivers/clocksource/time-lpc32xx.c
> @@ -311,4 +311,4 @@ static int __init lpc32xx_timer_init(struct device_node *np)
>
>         return ret;
>  }
> -CLOCKSOURCE_OF_DECLARE(lpc32xx_timer, "nxp,lpc3220-timer", lpc32xx_timer_init);
> +TIMER_OF_DECLARE(lpc32xx_timer, "nxp,lpc3220-timer", lpc32xx_timer_init);
> diff --git a/drivers/clocksource/time-orion.c b/drivers/clocksource/time-orion.c
> index b9b97f6..1220206 100644
> --- a/drivers/clocksource/time-orion.c
> +++ b/drivers/clocksource/time-orion.c
> @@ -189,4 +189,4 @@ static int __init orion_timer_init(struct device_node *np)
>
>         return 0;
>  }
> -CLOCKSOURCE_OF_DECLARE(orion_timer, "marvell,orion-timer", orion_timer_init);
> +TIMER_OF_DECLARE(orion_timer, "marvell,orion-timer", orion_timer_init);
> diff --git a/drivers/clocksource/time-pistachio.c b/drivers/clocksource/time-pistachio.c
> index 3710e4d..a2dd85d 100644
> --- a/drivers/clocksource/time-pistachio.c
> +++ b/drivers/clocksource/time-pistachio.c
> @@ -214,5 +214,5 @@ static int __init pistachio_clksrc_of_init(struct device_node *node)
>         sched_clock_register(pistachio_read_sched_clock, 32, rate);
>         return clocksource_register_hz(&pcs_gpt.cs, rate);
>  }
> -CLOCKSOURCE_OF_DECLARE(pistachio_gptimer, "img,pistachio-gptimer",
> +TIMER_OF_DECLARE(pistachio_gptimer, "img,pistachio-gptimer",
>                        pistachio_clksrc_of_init);
> diff --git a/drivers/clocksource/timer-atlas7.c b/drivers/clocksource/timer-atlas7.c
> index 50300ee..62c4bbc 100644
> --- a/drivers/clocksource/timer-atlas7.c
> +++ b/drivers/clocksource/timer-atlas7.c
> @@ -283,4 +283,4 @@ static int __init sirfsoc_of_timer_init(struct device_node *np)
>
>         return sirfsoc_atlas7_timer_init(np);
>  }
> -CLOCKSOURCE_OF_DECLARE(sirfsoc_atlas7_timer, "sirf,atlas7-tick", sirfsoc_of_timer_init);
> +TIMER_OF_DECLARE(sirfsoc_atlas7_timer, "sirf,atlas7-tick", sirfsoc_of_timer_init);
> diff --git a/drivers/clocksource/timer-atmel-pit.c b/drivers/clocksource/timer-atmel-pit.c
> index cc11235..ec8a437 100644
> --- a/drivers/clocksource/timer-atmel-pit.c
> +++ b/drivers/clocksource/timer-atmel-pit.c
> @@ -255,5 +255,5 @@ static int __init at91sam926x_pit_dt_init(struct device_node *node)
>
>         return 0;
>  }
> -CLOCKSOURCE_OF_DECLARE(at91sam926x_pit, "atmel,at91sam9260-pit",
> +TIMER_OF_DECLARE(at91sam926x_pit, "atmel,at91sam9260-pit",
>                        at91sam926x_pit_dt_init);
> diff --git a/drivers/clocksource/timer-atmel-st.c b/drivers/clocksource/timer-atmel-st.c
> index be4ac76..d2e660f 100644
> --- a/drivers/clocksource/timer-atmel-st.c
> +++ b/drivers/clocksource/timer-atmel-st.c
> @@ -260,5 +260,5 @@ static int __init atmel_st_timer_init(struct device_node *node)
>         /* register clocksource */
>         return clocksource_register_hz(&clk32k, sclk_rate);
>  }
> -CLOCKSOURCE_OF_DECLARE(atmel_st_timer, "atmel,at91rm9200-st",
> +TIMER_OF_DECLARE(atmel_st_timer, "atmel,at91rm9200-st",
>                        atmel_st_timer_init);
> diff --git a/drivers/clocksource/timer-digicolor.c b/drivers/clocksource/timer-digicolor.c
> index 94a161e..1e984a4 100644
> --- a/drivers/clocksource/timer-digicolor.c
> +++ b/drivers/clocksource/timer-digicolor.c
> @@ -203,5 +203,5 @@ static int __init digicolor_timer_init(struct device_node *node)
>
>         return 0;
>  }
> -CLOCKSOURCE_OF_DECLARE(conexant_digicolor, "cnxt,cx92755-timer",
> +TIMER_OF_DECLARE(conexant_digicolor, "cnxt,cx92755-timer",
>                        digicolor_timer_init);
> diff --git a/drivers/clocksource/timer-fttmr010.c b/drivers/clocksource/timer-fttmr010.c
> index d96190e..a21020c 100644
> --- a/drivers/clocksource/timer-fttmr010.c
> +++ b/drivers/clocksource/timer-fttmr010.c
> @@ -364,8 +364,8 @@ static __init int fttmr010_timer_init(struct device_node *np)
>         return fttmr010_common_init(np, false);
>  }
>
> -CLOCKSOURCE_OF_DECLARE(fttmr010, "faraday,fttmr010", fttmr010_timer_init);
> -CLOCKSOURCE_OF_DECLARE(gemini, "cortina,gemini-timer", fttmr010_timer_init);
> -CLOCKSOURCE_OF_DECLARE(moxart, "moxa,moxart-timer", fttmr010_timer_init);
> -CLOCKSOURCE_OF_DECLARE(ast2400, "aspeed,ast2400-timer", aspeed_timer_init);
> -CLOCKSOURCE_OF_DECLARE(ast2500, "aspeed,ast2500-timer", aspeed_timer_init);
> +TIMER_OF_DECLARE(fttmr010, "faraday,fttmr010", fttmr010_timer_init);
> +TIMER_OF_DECLARE(gemini, "cortina,gemini-timer", fttmr010_timer_init);
> +TIMER_OF_DECLARE(moxart, "moxa,moxart-timer", fttmr010_timer_init);
> +TIMER_OF_DECLARE(ast2400, "aspeed,ast2400-timer", aspeed_timer_init);
> +TIMER_OF_DECLARE(ast2500, "aspeed,ast2500-timer", aspeed_timer_init);
> diff --git a/drivers/clocksource/timer-imx-gpt.c b/drivers/clocksource/timer-imx-gpt.c
> index f595460..6ec6d79 100644
> --- a/drivers/clocksource/timer-imx-gpt.c
> +++ b/drivers/clocksource/timer-imx-gpt.c
> @@ -545,15 +545,15 @@ static int __init imx6dl_timer_init_dt(struct device_node *np)
>         return mxc_timer_init_dt(np, GPT_TYPE_IMX6DL);
>  }
>
> -CLOCKSOURCE_OF_DECLARE(imx1_timer, "fsl,imx1-gpt", imx1_timer_init_dt);
> -CLOCKSOURCE_OF_DECLARE(imx21_timer, "fsl,imx21-gpt", imx21_timer_init_dt);
> -CLOCKSOURCE_OF_DECLARE(imx27_timer, "fsl,imx27-gpt", imx21_timer_init_dt);
> -CLOCKSOURCE_OF_DECLARE(imx31_timer, "fsl,imx31-gpt", imx31_timer_init_dt);
> -CLOCKSOURCE_OF_DECLARE(imx25_timer, "fsl,imx25-gpt", imx31_timer_init_dt);
> -CLOCKSOURCE_OF_DECLARE(imx50_timer, "fsl,imx50-gpt", imx31_timer_init_dt);
> -CLOCKSOURCE_OF_DECLARE(imx51_timer, "fsl,imx51-gpt", imx31_timer_init_dt);
> -CLOCKSOURCE_OF_DECLARE(imx53_timer, "fsl,imx53-gpt", imx31_timer_init_dt);
> -CLOCKSOURCE_OF_DECLARE(imx6q_timer, "fsl,imx6q-gpt", imx31_timer_init_dt);
> -CLOCKSOURCE_OF_DECLARE(imx6dl_timer, "fsl,imx6dl-gpt", imx6dl_timer_init_dt);
> -CLOCKSOURCE_OF_DECLARE(imx6sl_timer, "fsl,imx6sl-gpt", imx6dl_timer_init_dt);
> -CLOCKSOURCE_OF_DECLARE(imx6sx_timer, "fsl,imx6sx-gpt", imx6dl_timer_init_dt);
> +TIMER_OF_DECLARE(imx1_timer, "fsl,imx1-gpt", imx1_timer_init_dt);
> +TIMER_OF_DECLARE(imx21_timer, "fsl,imx21-gpt", imx21_timer_init_dt);
> +TIMER_OF_DECLARE(imx27_timer, "fsl,imx27-gpt", imx21_timer_init_dt);
> +TIMER_OF_DECLARE(imx31_timer, "fsl,imx31-gpt", imx31_timer_init_dt);
> +TIMER_OF_DECLARE(imx25_timer, "fsl,imx25-gpt", imx31_timer_init_dt);
> +TIMER_OF_DECLARE(imx50_timer, "fsl,imx50-gpt", imx31_timer_init_dt);
> +TIMER_OF_DECLARE(imx51_timer, "fsl,imx51-gpt", imx31_timer_init_dt);
> +TIMER_OF_DECLARE(imx53_timer, "fsl,imx53-gpt", imx31_timer_init_dt);
> +TIMER_OF_DECLARE(imx6q_timer, "fsl,imx6q-gpt", imx31_timer_init_dt);
> +TIMER_OF_DECLARE(imx6dl_timer, "fsl,imx6dl-gpt", imx6dl_timer_init_dt);
> +TIMER_OF_DECLARE(imx6sl_timer, "fsl,imx6sl-gpt", imx6dl_timer_init_dt);
> +TIMER_OF_DECLARE(imx6sx_timer, "fsl,imx6sx-gpt", imx6dl_timer_init_dt);
> diff --git a/drivers/clocksource/timer-integrator-ap.c b/drivers/clocksource/timer-integrator-ap.c
> index 04ad306..2ff64d9 100644
> --- a/drivers/clocksource/timer-integrator-ap.c
> +++ b/drivers/clocksource/timer-integrator-ap.c
> @@ -232,5 +232,5 @@ static int __init integrator_ap_timer_init_of(struct device_node *node)
>         return 0;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(integrator_ap_timer, "arm,integrator-timer",
> +TIMER_OF_DECLARE(integrator_ap_timer, "arm,integrator-timer",
>                        integrator_ap_timer_init_of);
> diff --git a/drivers/clocksource/timer-keystone.c b/drivers/clocksource/timer-keystone.c
> index ab68a47..0eee032 100644
> --- a/drivers/clocksource/timer-keystone.c
> +++ b/drivers/clocksource/timer-keystone.c
> @@ -226,5 +226,5 @@ static int __init keystone_timer_init(struct device_node *np)
>         return error;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(keystone_timer, "ti,keystone-timer",
> +TIMER_OF_DECLARE(keystone_timer, "ti,keystone-timer",
>                            keystone_timer_init);
> diff --git a/drivers/clocksource/timer-nps.c b/drivers/clocksource/timer-nps.c
> index e74ea17..7b6bb0d 100644
> --- a/drivers/clocksource/timer-nps.c
> +++ b/drivers/clocksource/timer-nps.c
> @@ -110,9 +110,9 @@ static int __init nps_setup_clocksource(struct device_node *node)
>         return ret;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
> +TIMER_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
>                        nps_setup_clocksource);
> -CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_src, "ezchip,nps400-timer1",
> +TIMER_OF_DECLARE(ezchip_nps400_clk_src, "ezchip,nps400-timer1",
>                        nps_setup_clocksource);
>
>  #ifdef CONFIG_EZNPS_MTM_EXT
> @@ -279,6 +279,6 @@ static int __init nps_setup_clockevent(struct device_node *node)
>         return 0;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_evt, "ezchip,nps400-timer0",
> +TIMER_OF_DECLARE(ezchip_nps400_clk_evt, "ezchip,nps400-timer0",
>                        nps_setup_clockevent);
>  #endif /* CONFIG_EZNPS_MTM_EXT */
> diff --git a/drivers/clocksource/timer-oxnas-rps.c b/drivers/clocksource/timer-oxnas-rps.c
> index d630bf4..eed6fef 100644
> --- a/drivers/clocksource/timer-oxnas-rps.c
> +++ b/drivers/clocksource/timer-oxnas-rps.c
> @@ -293,7 +293,7 @@ static int __init oxnas_rps_timer_init(struct device_node *np)
>         return ret;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(ox810se_rps,
> +TIMER_OF_DECLARE(ox810se_rps,
>                        "oxsemi,ox810se-rps-timer", oxnas_rps_timer_init);
> -CLOCKSOURCE_OF_DECLARE(ox820_rps,
> +TIMER_OF_DECLARE(ox820_rps,
>                        "oxsemi,ox820se-rps-timer", oxnas_rps_timer_init);
> diff --git a/drivers/clocksource/timer-prima2.c b/drivers/clocksource/timer-prima2.c
> index b4122ed..20ff33b 100644
> --- a/drivers/clocksource/timer-prima2.c
> +++ b/drivers/clocksource/timer-prima2.c
> @@ -245,5 +245,5 @@ static int __init sirfsoc_prima2_timer_init(struct device_node *np)
>
>         return 0;
>  }
> -CLOCKSOURCE_OF_DECLARE(sirfsoc_prima2_timer,
> +TIMER_OF_DECLARE(sirfsoc_prima2_timer,
>         "sirf,prima2-tick", sirfsoc_prima2_timer_init);
> diff --git a/drivers/clocksource/timer-sp804.c b/drivers/clocksource/timer-sp804.c
> index 2d575a8c..3ac9dec 100644
> --- a/drivers/clocksource/timer-sp804.c
> +++ b/drivers/clocksource/timer-sp804.c
> @@ -287,7 +287,7 @@ static int __init sp804_of_init(struct device_node *np)
>         iounmap(base);
>         return ret;
>  }
> -CLOCKSOURCE_OF_DECLARE(sp804, "arm,sp804", sp804_of_init);
> +TIMER_OF_DECLARE(sp804, "arm,sp804", sp804_of_init);
>
>  static int __init integrator_cp_of_init(struct device_node *np)
>  {
> @@ -335,4 +335,4 @@ static int __init integrator_cp_of_init(struct device_node *np)
>         iounmap(base);
>         return ret;
>  }
> -CLOCKSOURCE_OF_DECLARE(intcp, "arm,integrator-cp-timer", integrator_cp_of_init);
> +TIMER_OF_DECLARE(intcp, "arm,integrator-cp-timer", integrator_cp_of_init);
> diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
> index 1b2574c..174d1243 100644
> --- a/drivers/clocksource/timer-stm32.c
> +++ b/drivers/clocksource/timer-stm32.c
> @@ -187,4 +187,4 @@ static int __init stm32_clockevent_init(struct device_node *np)
>         return ret;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(stm32, "st,stm32-timer", stm32_clockevent_init);
> +TIMER_OF_DECLARE(stm32, "st,stm32-timer", stm32_clockevent_init);
> diff --git a/drivers/clocksource/timer-sun5i.c b/drivers/clocksource/timer-sun5i.c
> index 2e9c830..a4ebc8f 100644
> --- a/drivers/clocksource/timer-sun5i.c
> +++ b/drivers/clocksource/timer-sun5i.c
> @@ -358,7 +358,7 @@ static int __init sun5i_timer_init(struct device_node *node)
>
>         return sun5i_setup_clockevent(node, timer_base, clk, irq);
>  }
> -CLOCKSOURCE_OF_DECLARE(sun5i_a13, "allwinner,sun5i-a13-hstimer",
> +TIMER_OF_DECLARE(sun5i_a13, "allwinner,sun5i-a13-hstimer",
>                            sun5i_timer_init);
> -CLOCKSOURCE_OF_DECLARE(sun7i_a20, "allwinner,sun7i-a20-hstimer",
> +TIMER_OF_DECLARE(sun7i_a20, "allwinner,sun7i-a20-hstimer",
>                            sun5i_timer_init);
> diff --git a/drivers/clocksource/timer-ti-32k.c b/drivers/clocksource/timer-ti-32k.c
> index 6240677..880a861 100644
> --- a/drivers/clocksource/timer-ti-32k.c
> +++ b/drivers/clocksource/timer-ti-32k.c
> @@ -124,5 +124,5 @@ static int __init ti_32k_timer_init(struct device_node *np)
>
>         return 0;
>  }
> -CLOCKSOURCE_OF_DECLARE(ti_32k_timer, "ti,omap-counter32k",
> +TIMER_OF_DECLARE(ti_32k_timer, "ti,omap-counter32k",
>                 ti_32k_timer_init);
> diff --git a/drivers/clocksource/timer-u300.c b/drivers/clocksource/timer-u300.c
> index 704e40c..be34b11 100644
> --- a/drivers/clocksource/timer-u300.c
> +++ b/drivers/clocksource/timer-u300.c
> @@ -458,5 +458,5 @@ static int __init u300_timer_init_of(struct device_node *np)
>         return 0;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(u300_timer, "stericsson,u300-apptimer",
> +TIMER_OF_DECLARE(u300_timer, "stericsson,u300-apptimer",
>                        u300_timer_init_of);
> diff --git a/drivers/clocksource/versatile.c b/drivers/clocksource/versatile.c
> index 220b490..39725d3 100644
> --- a/drivers/clocksource/versatile.c
> +++ b/drivers/clocksource/versatile.c
> @@ -38,7 +38,7 @@ static int __init versatile_sched_clock_init(struct device_node *node)
>
>         return 0;
>  }
> -CLOCKSOURCE_OF_DECLARE(vexpress, "arm,vexpress-sysreg",
> +TIMER_OF_DECLARE(vexpress, "arm,vexpress-sysreg",
>                        versatile_sched_clock_init);
> -CLOCKSOURCE_OF_DECLARE(versatile, "arm,versatile-sysreg",
> +TIMER_OF_DECLARE(versatile, "arm,versatile-sysreg",
>                        versatile_sched_clock_init);
> diff --git a/drivers/clocksource/vf_pit_timer.c b/drivers/clocksource/vf_pit_timer.c
> index e0849e2..0f92089 100644
> --- a/drivers/clocksource/vf_pit_timer.c
> +++ b/drivers/clocksource/vf_pit_timer.c
> @@ -201,4 +201,4 @@ static int __init pit_timer_init(struct device_node *np)
>
>         return pit_clockevent_init(clk_rate, irq);
>  }
> -CLOCKSOURCE_OF_DECLARE(vf610, "fsl,vf610-pit", pit_timer_init);
> +TIMER_OF_DECLARE(vf610, "fsl,vf610-pit", pit_timer_init);
> diff --git a/drivers/clocksource/vt8500_timer.c b/drivers/clocksource/vt8500_timer.c
> index d02b510..e0f7489 100644
> --- a/drivers/clocksource/vt8500_timer.c
> +++ b/drivers/clocksource/vt8500_timer.c
> @@ -165,4 +165,4 @@ static int __init vt8500_timer_init(struct device_node *np)
>         return 0;
>  }
>
> -CLOCKSOURCE_OF_DECLARE(vt8500, "via,vt8500-timer", vt8500_timer_init);
> +TIMER_OF_DECLARE(vt8500, "via,vt8500-timer", vt8500_timer_init);
> diff --git a/drivers/clocksource/zevio-timer.c b/drivers/clocksource/zevio-timer.c
> index 9a53f5e..a6a0338 100644
> --- a/drivers/clocksource/zevio-timer.c
> +++ b/drivers/clocksource/zevio-timer.c
> @@ -215,4 +215,4 @@ static int __init zevio_timer_init(struct device_node *node)
>         return zevio_timer_add(node);
>  }
>
> -CLOCKSOURCE_OF_DECLARE(zevio_timer, "lsi,zevio-timer", zevio_timer_init);
> +TIMER_OF_DECLARE(zevio_timer, "lsi,zevio-timer", zevio_timer_init);
> diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
> index f2b10d9..a86b65f 100644
> --- a/include/linux/clocksource.h
> +++ b/include/linux/clocksource.h
> @@ -249,7 +249,7 @@ extern int clocksource_mmio_init(void __iomem *, const char *,
>
>  extern int clocksource_i8253_init(void);
>
> -#define CLOCKSOURCE_OF_DECLARE(name, compat, fn) \
> +#define TIMER_OF_DECLARE(name, compat, fn) \
>         OF_DECLARE_1_RET(clksrc, name, compat, fn)
>
>  #ifdef CONFIG_CLKSRC_PROBE
> --
> 2.7.4
>


From daniel.lezcano at linaro.org  Sun May 28 07:20:03 2017
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Sun, 28 May 2017 16:20:03 +0200
Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
In-Reply-To: <CACRpkdZbVv94hE9Gg+xiH2dxJANo-fPwLSek+BE4QwWWWWUixw@mail.gmail.com>
References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
 <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
 <CACRpkdZbVv94hE9Gg+xiH2dxJANo-fPwLSek+BE4QwWWWWUixw@mail.gmail.com>
Message-ID: <376de2ec-c557-8541-9480-66472bd153a5@linaro.org>

On 28/05/2017 15:48, Linus Walleij wrote:
> On Sat, May 27, 2017 at 11:58 AM, Daniel Lezcano
> <daniel.lezcano at linaro.org> wrote:
> 
>> The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the
>> clocksource at early stage. However, this macro is also used to initialize
>> the clockevent if any, or the clockevent only.
>>
>> It was originally suggested to declare another macro to initialize a
>> clockevent, so in order to separate the two entities even they belong to the
>> same IP. This was not accepted because of the impact on the DT where splitting
>> a clocksource/clockevent definition does not make sense as it is a Linux
>> concept not a hardware description.
>>
>> On the other side, the clocksource has not interrupt declared while the
>> clockevent has, so it is easy from the driver to know if the description is
>> for a clockevent or a clocksource, IOW it could be implemented at the driver
>> level.
>>
>> So instead of dealing with a named clocksource macro, let's use a more generic
>> one: TIMER_OF_DECLARE.
>>
>> The patch has not functional changes.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>'
> 
> This makes the macro make sense and I had this idea one time too.
> Awesome.
> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
Thanks Linus for reviewing the series.

  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From heiko at sntech.de  Mon May 29 00:39:09 2017
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Mon, 29 May 2017 09:39:09 +0200
Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
In-Reply-To: <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
 <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1710049.UcE0hxO5ny@diego>

Am Samstag, 27. Mai 2017, 11:58:43 CEST schrieb Daniel Lezcano:
> The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the
> clocksource at early stage. However, this macro is also used to initialize
> the clockevent if any, or the clockevent only.
> 
> It was originally suggested to declare another macro to initialize a
> clockevent, so in order to separate the two entities even they belong to the
> same IP. This was not accepted because of the impact on the DT where
> splitting a clocksource/clockevent definition does not make sense as it is
> a Linux concept not a hardware description.
> 
> On the other side, the clocksource has not interrupt declared while the
> clockevent has, so it is easy from the driver to know if the description is
> for a clockevent or a clocksource, IOW it could be implemented at the driver
> level.
> 
> So instead of dealing with a named clocksource macro, let's use a more
> generic one: TIMER_OF_DECLARE.
> 
> The patch has not functional changes.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
[...]
> diff --git a/drivers/clocksource/rockchip_timer.c
> b/drivers/clocksource/rockchip_timer.c index 49c02be..c27f4c8 100644
> --- a/drivers/clocksource/rockchip_timer.c
> +++ b/drivers/clocksource/rockchip_timer.c
> @@ -303,5 +303,5 @@ static int __init rk_timer_init(struct device_node *np)
>  	return -EINVAL;
>  }
> 
> -CLOCKSOURCE_OF_DECLARE(rk3288_timer, "rockchip,rk3288-timer",
> rk_timer_init); -CLOCKSOURCE_OF_DECLARE(rk3399_timer,
> "rockchip,rk3399-timer", rk_timer_init); +TIMER_OF_DECLARE(rk3288_timer,
> "rockchip,rk3288-timer", rk_timer_init); +TIMER_OF_DECLARE(rk3399_timer,
> "rockchip,rk3399-timer", rk_timer_init); diff --git
> a/drivers/clocksource/samsung_pwm_timer.c
> b/drivers/clocksource/samsung_pwm_timer.c index a68e653..21cd72c 100644

Acked-by: Heiko Stuebner <heiko at sntech.de>


From narmstrong at baylibre.com  Mon May 29 01:00:46 2017
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Mon, 29 May 2017 10:00:46 +0200
Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
In-Reply-To: <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
 <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <4ccb7cac-1663-792a-7912-d9ee803c7e2b@baylibre.com>

On 05/27/2017 11:58 AM, Daniel Lezcano wrote:
> The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the
> clocksource at early stage. However, this macro is also used to initialize
> the clockevent if any, or the clockevent only.
> 
> It was originally suggested to declare another macro to initialize a
> clockevent, so in order to separate the two entities even they belong to the
> same IP. This was not accepted because of the impact on the DT where splitting
> a clocksource/clockevent definition does not make sense as it is a Linux
> concept not a hardware description.
> 
> On the other side, the clocksource has not interrupt declared while the
> clockevent has, so it is easy from the driver to know if the description is
> for a clockevent or a clocksource, IOW it could be implemented at the driver
> level.
> 
> So instead of dealing with a named clocksource macro, let's use a more generic
> one: TIMER_OF_DECLARE.
> 
> The patch has not functional changes.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/kernel/smp_twd.c                 |  6 +++---
>  arch/microblaze/kernel/timer.c            |  2 +-
>  arch/mips/ralink/cevt-rt3352.c            |  2 +-
>  arch/nios2/kernel/time.c                  |  2 +-
>  drivers/clocksource/arc_timer.c           |  6 +++---
>  drivers/clocksource/arm_arch_timer.c      |  6 +++---
>  drivers/clocksource/arm_global_timer.c    |  2 +-
>  drivers/clocksource/armv7m_systick.c      |  2 +-
>  drivers/clocksource/asm9260_timer.c       |  2 +-
>  drivers/clocksource/bcm2835_timer.c       |  2 +-
>  drivers/clocksource/bcm_kona_timer.c      |  4 ++--
>  drivers/clocksource/cadence_ttc_timer.c   |  2 +-
>  drivers/clocksource/clksrc-dbx500-prcmu.c |  2 +-
>  drivers/clocksource/clksrc_st_lpc.c       |  2 +-
>  drivers/clocksource/clps711x-timer.c      |  2 +-
>  drivers/clocksource/dw_apb_timer_of.c     |  8 ++++----
>  drivers/clocksource/exynos_mct.c          |  4 ++--
>  drivers/clocksource/fsl_ftm_timer.c       |  2 +-
>  drivers/clocksource/h8300_timer16.c       |  2 +-
>  drivers/clocksource/h8300_timer8.c        |  2 +-
>  drivers/clocksource/h8300_tpu.c           |  2 +-
>  drivers/clocksource/jcore-pit.c           |  2 +-
>  drivers/clocksource/meson6_timer.c        |  2 +-
>  drivers/clocksource/mips-gic-timer.c      |  2 +-
>  drivers/clocksource/mps2-timer.c          |  2 +-
>  drivers/clocksource/mtk_timer.c           |  2 +-
>  drivers/clocksource/mxs_timer.c           |  2 +-
>  drivers/clocksource/nomadik-mtu.c         |  2 +-
>  drivers/clocksource/pxa_timer.c           |  2 +-
>  drivers/clocksource/qcom-timer.c          |  4 ++--
>  drivers/clocksource/renesas-ostm.c        |  2 +-
>  drivers/clocksource/rockchip_timer.c      |  4 ++--
>  drivers/clocksource/samsung_pwm_timer.c   |  8 ++++----
>  drivers/clocksource/sun4i_timer.c         |  2 +-
>  drivers/clocksource/tango_xtal.c          |  2 +-
>  drivers/clocksource/tegra20_timer.c       |  4 ++--
>  drivers/clocksource/time-armada-370-xp.c  |  6 +++---
>  drivers/clocksource/time-efm32.c          |  4 ++--
>  drivers/clocksource/time-lpc32xx.c        |  2 +-
>  drivers/clocksource/time-orion.c          |  2 +-
>  drivers/clocksource/time-pistachio.c      |  2 +-
>  drivers/clocksource/timer-atlas7.c        |  2 +-
>  drivers/clocksource/timer-atmel-pit.c     |  2 +-
>  drivers/clocksource/timer-atmel-st.c      |  2 +-
>  drivers/clocksource/timer-digicolor.c     |  2 +-
>  drivers/clocksource/timer-fttmr010.c      | 10 +++++-----
>  drivers/clocksource/timer-imx-gpt.c       | 24 ++++++++++++------------
>  drivers/clocksource/timer-integrator-ap.c |  2 +-
>  drivers/clocksource/timer-keystone.c      |  2 +-
>  drivers/clocksource/timer-nps.c           |  6 +++---
>  drivers/clocksource/timer-oxnas-rps.c     |  4 ++--
>  drivers/clocksource/timer-prima2.c        |  2 +-
>  drivers/clocksource/timer-sp804.c         |  4 ++--
>  drivers/clocksource/timer-stm32.c         |  2 +-
>  drivers/clocksource/timer-sun5i.c         |  4 ++--
>  drivers/clocksource/timer-ti-32k.c        |  2 +-
>  drivers/clocksource/timer-u300.c          |  2 +-
>  drivers/clocksource/versatile.c           |  4 ++--
>  drivers/clocksource/vf_pit_timer.c        |  2 +-
>  drivers/clocksource/vt8500_timer.c        |  2 +-
>  drivers/clocksource/zevio-timer.c         |  2 +-
>  include/linux/clocksource.h               |  2 +-
>  62 files changed, 103 insertions(+), 103 deletions(-)
> 
[...]
> diff --git a/drivers/clocksource/timer-oxnas-rps.c b/drivers/clocksource/timer-oxnas-rps.c
> index d630bf4..eed6fef 100644
> --- a/drivers/clocksource/timer-oxnas-rps.c
> +++ b/drivers/clocksource/timer-oxnas-rps.c
> @@ -293,7 +293,7 @@ static int __init oxnas_rps_timer_init(struct device_node *np)
>  	return ret;
>  }
>  
> -CLOCKSOURCE_OF_DECLARE(ox810se_rps,
> +TIMER_OF_DECLARE(ox810se_rps,
>  		       "oxsemi,ox810se-rps-timer", oxnas_rps_timer_init);
> -CLOCKSOURCE_OF_DECLARE(ox820_rps,
> +TIMER_OF_DECLARE(ox820_rps,
>  		       "oxsemi,ox820se-rps-timer", oxnas_rps_timer_init);
[...]

For the timer-oxnas-rps driver,

Acked-by: Neil Armstrong <narmstrong at baylibre.com>

Thanks for the rework,
Neil



From linus.walleij at linaro.org  Mon May 29 01:31:22 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 May 2017 10:31:22 +0200
Subject: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular
 distinctions
In-Reply-To: <20170522205648.23545-4-paul.gortmaker@windriver.com>
References: <20170522205648.23545-1-paul.gortmaker@windriver.com>
 <20170522205648.23545-4-paul.gortmaker@windriver.com>
Message-ID: <CACRpkdbQTDkqy+ChBq=pg1BnHH5ARL0+J-zL_gipEEotujOxbA@mail.gmail.com>

On Mon, May 22, 2017 at 10:56 PM, Paul Gortmaker
<paul.gortmaker at windriver.com> wrote:

> Fixups here tend to be more of a conglomerate of some of the other
> repeated/systematic ones we've seen in the earlier pinctrl cleanups.
>
> We remove module.h from code that isn't doing anything modular at
> all;  if they have __init sections, then replace it with init.h
>
> One driver has a .remove that would be dispatched on module_exit,
> and as that code is essentially orphaned, so we remove it.  In case
> anyone was previously doing the (pointless) unbind to get to that
> function, we disable unbind for this one driver as well.
>
> A couple bool drivers (hence non-modular) are converted over to
> to builtin_platform_driver().
>
> Since module_platform_driver() uses the same init level priority as
> builtin_platform_driver() the init ordering remains unchanged with
> this commit.
>
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>
> We also delete the MODULE_LICENSE tag etc. since all that information
> was (or is now) contained at the top of the file in the comments.
>
> Cc: Eric Anholt <eric at anholt.net>
> Cc: Florian Fainelli <f.fainelli at gmail.com>
> Cc: Jon Mason <jonmason at broadcom.com>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Ray Jui <rjui at broadcom.com>
> Cc: Scott Branden <sbranden at broadcom.com>
> Cc: Stefan Wahren <stefan.wahren at i2se.com>
> Cc: Sherman Yin <syin at broadcom.com>
> Cc: bcm-kernel-feedback-list at broadcom.com
> Cc: linux-gpio at vger.kernel.org
> Cc: linux-rpi-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>

Patch applied with Stefan Wahren's Tested-by tag.

I can't take header standardization into account, header files are not
ABI, further see
Documentation/process/stable-api-nonsense.rst

Yours,
Linus Walleij


From linus.walleij at linaro.org  Mon May 29 01:33:26 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 29 May 2017 10:33:26 +0200
Subject: [PATCH 0/3] pinctrl: bcm/samsung/tegra: make bool code non-modular
In-Reply-To: <20170522205648.23545-1-paul.gortmaker@windriver.com>
References: <20170522205648.23545-1-paul.gortmaker@windriver.com>
Message-ID: <CACRpkdZhdu2Z2cA3AvnV0Cxp=KAFGOMSwnWpaVDaqv1ZJXLpQA@mail.gmail.com>

On Mon, May 22, 2017 at 10:56 PM, Paul Gortmaker
<paul.gortmaker at windriver.com> wrote:

> This is the last of the pinctrl cleanups I have in my queue.

Awesome.

> Linus - thanks for your patience in merging all these to date.

You are the patient one. I'm just merging...

I was sold on the technical merit if these patches once it was
explained to me that #include <linux/module.h> actually has a
significant impact on compile time when accumulated across the
kernel. This just needs to be done right and you make it so.

Yours,
Linus Walleij


From arnd at arndb.de  Mon May 29 01:41:52 2017
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 29 May 2017 10:41:52 +0200
Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
In-Reply-To: <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
 <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <CAK8P3a3QACHYqtCO1z_FpW0nXEtx356wCDha_=SNXU872=q1UQ@mail.gmail.com>

On Sat, May 27, 2017 at 11:58 AM, Daniel Lezcano
<daniel.lezcano at linaro.org> wrote:
> The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the
> clocksource at early stage. However, this macro is also used to initialize
> the clockevent if any, or the clockevent only.
>
> It was originally suggested to declare another macro to initialize a
> clockevent, so in order to separate the two entities even they belong to the
> same IP. This was not accepted because of the impact on the DT where splitting
> a clocksource/clockevent definition does not make sense as it is a Linux
> concept not a hardware description.
>
> On the other side, the clocksource has not interrupt declared while the
> clockevent has, so it is easy from the driver to know if the description is
> for a clockevent or a clocksource, IOW it could be implemented at the driver
> level.
>
> So instead of dealing with a named clocksource macro, let's use a more generic
> one: TIMER_OF_DECLARE.
>
> The patch has not functional changes.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>

Could you either leave the old name as an alias for one release, or introduce
the new name as an alias now for 4.13?

I think that that would make it easier to merge new drivers. Otherwise this
looks good to me,

Acked-by: Arnd Bergmann <arnd at arndb.de>


From daniel.lezcano at linaro.org  Mon May 29 01:48:09 2017
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 29 May 2017 10:48:09 +0200
Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
In-Reply-To: <CAK8P3a3QACHYqtCO1z_FpW0nXEtx356wCDha_=SNXU872=q1UQ@mail.gmail.com>
References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
 <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
 <CAK8P3a3QACHYqtCO1z_FpW0nXEtx356wCDha_=SNXU872=q1UQ@mail.gmail.com>
Message-ID: <20170529084809.GA2192@mai>

On Mon, May 29, 2017 at 10:41:52AM +0200, Arnd Bergmann wrote:
> On Sat, May 27, 2017 at 11:58 AM, Daniel Lezcano
> <daniel.lezcano at linaro.org> wrote:
> > The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the
> > clocksource at early stage. However, this macro is also used to initialize
> > the clockevent if any, or the clockevent only.
> >
> > It was originally suggested to declare another macro to initialize a
> > clockevent, so in order to separate the two entities even they belong to the
> > same IP. This was not accepted because of the impact on the DT where splitting
> > a clocksource/clockevent definition does not make sense as it is a Linux
> > concept not a hardware description.
> >
> > On the other side, the clocksource has not interrupt declared while the
> > clockevent has, so it is easy from the driver to know if the description is
> > for a clockevent or a clocksource, IOW it could be implemented at the driver
> > level.
> >
> > So instead of dealing with a named clocksource macro, let's use a more generic
> > one: TIMER_OF_DECLARE.
> >
> > The patch has not functional changes.
> >
> > Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> 
> Could you either leave the old name as an alias for one release, or introduce
> the new name as an alias now for 4.13?
> 
> I think that that would make it easier to merge new drivers. Otherwise this
> looks good to me,


New drivers should go through my tree, so I can catch them with the old macro
name and do the change.

> Acked-by: Arnd Bergmann <arnd at arndb.de>

Thanks for the review.

-- 

 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


From phil at raspberrypi.org  Tue May 30 05:23:43 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Tue, 30 May 2017 13:23:43 +0100
Subject: CLK_OF_DECLARE advice required
Message-ID: <ae427c15-330f-6f8d-e2ac-62a8deacbdc5@raspberrypi.org>

Hi,

I've run into a problem using the fixed-factor clock on Raspberry Pi and I'd
like some advice before I submit a patch.

Some context: the aim is to use a standard UART and some external circuitry
as a MIDI interface. This would be straightforward except that Linux doesn't
recognise the required 31.25KHz as a valid UART baud rate. Rhe workaround is
to declare the UART clock such that the reported rate differs from the actual
rate. If one sets the reported rate to be (actual*38400)/31250 then
requesting a 38400 baud rate will result in an actual 31250 baud signal.

The fixed-factor-clock device is perfect for such a deception, but when one
is inserted between the clock source and the UART the probe function of the
UART always returns -EPROBE_DEFER because its input clock isn't available.
This is due to an initialisation order problem that requires code changes to
resolve.

fixed-factor-clock has two ways to initialise and register its clock. One is
via a standard module probe method, and the other is through the CLK_OF_DECLARE
macro, adding a registration to the __clk_of_table section. of_clk_init walks
the list of clocks, calling the initialisation functions for nodes that either
have no parent (input) clock or where the parent clock is ready. The init
function itself has no return value, so is assumed to succeed. In the event
that the parent never becomes ready, the initialisation function is called
anyway and the clock node is marked as being populated, preventing the probe
function from ever being called.

In this MIDI application using UART 1 on a Raspberry Pi, the parent clock is
provided by the clk-bcm2835-aux driver which registers using a probe function.
Because regular platform drivers are probed long after of_clk_init returns, the
parent clock for the fixed-factor clock doesn't become available early enough,
resulting in a failing call to the initialisation and no subsequent probe,
even after the parent finally becomes available.

My questions are:

1. Should all system clock drivers use OF_CLK_DECLARE? Doing so would probably
avoid this problem, but further initialisation order dependencies may
require more drivers to be initialised early.

2. Why does the clock initialisation hook registered by OF_CLK_DECLARE not
return any indication of success? If it did, and if the OF_POPULATED flag
was only set after successful initialisation then the normal retrying of
a deferred probe would also avoid this problem.

3. Would adding the OF_CLK_DECLARE hook prevent the use of the devm_ managed
functions like devm_kzalloc? If not, why doesn't fixed-factor-clock use it?

Thank you for your time,

Phil


From phil at raspberrypi.org  Tue May 30 09:27:56 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Tue, 30 May 2017 17:27:56 +0100
Subject: [PATCH 0/2] clk: bcm2835: PCM clock improvements
Message-ID: <4c11ad43-ef4e-3fbd-500a-02b2b46e0fbd@raspberrypi.org>

The switch to using the upstream bcm2835_cprman clock driver caused a
few problems for users of PCM (I2S) peripherals. Audio applications
require accurate, stable clocks, and the cprman driver wasn't
conservative enough in its choice of clock sources.

These patches restrict the clock sources for the PCM peripheral in two
ways: the first causes all possible sources except OSC and PLLD_PER
to be ignored, while the second allows clocks to be specified as
"low_jitter", causing the effects of fractional divisors to be taken
into account when comparing potential clocks for accuracy. In practice,
the combined effect of the two patches is to choose OSC as a source if
an integer divisor can be used, otherwise PLLD_PER is chosen.

Phil Elwell (2):
  clk: bcm2835: Limit PCM clock to OSC and PLLD_PER
  clk: bcm2835: Minimise clock jitter for PCM clock

 drivers/clk/bcm/clk-bcm2835.c | 50 ++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 45 insertions(+), 5 deletions(-)

-- 
1.9.1



From phil at raspberrypi.org  Tue May 30 09:28:06 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Tue, 30 May 2017 17:28:06 +0100
Subject: [PATCH 1/2] clk: bcm2835: Limit PCM clock to OSC and PLLD_PER
Message-ID: <866b60bb-d1c8-726e-3a2d-11a34f9e8ac7@raspberrypi.org>

Restrict clock sources for the PCM peripheral to the oscillator and
PLLD_PER because other source may have varying rates or be switched off.
Prevent other sources from being selected by replacing their names in
the list of potential parents with dummy entries (entry index is
significant).

Signed-off-by: Phil Elwell <phil at raspberrypi.org>
---
 drivers/clk/bcm/clk-bcm2835.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 0258538..facc346 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -1511,6 +1511,16 @@ struct bcm2835_clk_desc {
 	"pllh_aux",
 };
 
+static const char *const bcm2835_pcm_per_parents[] = {
+	"-",
+	"xosc",
+	"-",
+	"-",
+	"-",
+	"-",
+	"plld_per",
+};
+
 #define REGISTER_PER_CLK(...)	REGISTER_CLK(				\
 	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),	\
 	.parents = bcm2835_clock_per_parents,				\
@@ -2000,6 +2010,7 @@ struct bcm2835_clk_desc {
 		.int_bits = 12,
 		.frac_bits = 12,
 		.is_mash_clock = true,
+		.parents = bcm2835_pcm_per_parents,
 		.tcnt_mux = 23),
 	[BCM2835_CLOCK_PWM]	= REGISTER_PER_CLK(
 		.name = "pwm",
-- 
1.9.1



From phil at raspberrypi.org  Tue May 30 09:28:14 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Tue, 30 May 2017 17:28:14 +0100
Subject: [PATCH 2/2] clk: bcm2835: Minimise clock jitter for PCM clock
Message-ID: <b9208d9b-c7bb-49a3-85d9-231c8b41eb8c@raspberrypi.org>

Fractional clock dividers generate accurate average frequencies but
with jitter, particularly when the integer divisor is small.

Introduce a new metric of clock accuracy to penalise clocks with a good
average but worse jitter compared to clocks with an average which is no
better but with lower jitter. The metric is the ideal rate minus the
worse deviation from that ideal using the nearest integer divisors.

Use this metric for parent selection for clocks requiring low jitter
(currently just PCM).

Signed-off-by: Phil Elwell <phil at raspberrypi.org>
---
 drivers/clk/bcm/clk-bcm2835.c | 39 ++++++++++++++++++++++++++++++++++-----
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index facc346..e0ce5e7 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -530,6 +530,7 @@ struct bcm2835_clock_data {
 
 	bool is_vpu_clock;
 	bool is_mash_clock;
+	bool low_jitter;
 
 	u32 tcnt_mux;
 };
@@ -1124,7 +1125,8 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
 							int parent_idx,
 							unsigned long rate,
 							u32 *div,
-							unsigned long *prate)
+							unsigned long *prate,
+							unsigned long *avgrate)
 {
 	struct bcm2835_clock *clock = bcm2835_clock_from_hw(hw);
 	struct bcm2835_cprman *cprman = clock->cprman;
@@ -1136,11 +1138,33 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
 	parent = clk_hw_get_parent_by_index(hw, parent_idx);
 
 	if (!(BIT(parent_idx) & data->set_rate_parent)) {
+		unsigned long tmp_rate;
+
 		*prate = clk_hw_get_rate(parent);
 		*div = bcm2835_clock_choose_div(hw, rate, *prate, true);
 
-		return bcm2835_clock_rate_from_divisor(clock, *prate,
-						       *div);
+		tmp_rate = bcm2835_clock_rate_from_divisor(clock, *prate, *div);
+		*avgrate = tmp_rate;
+
+		if (data->low_jitter && (*div & CM_DIV_FRAC_MASK)) {
+			unsigned long high, low;
+			u32 idiv = *div & ~CM_DIV_FRAC_MASK;
+
+			high = bcm2835_clock_rate_from_divisor(clock, *prate,
+							       idiv);
+			idiv += CM_DIV_FRAC_MASK + 1;
+			low = bcm2835_clock_rate_from_divisor(clock, *prate,
+							      idiv);
+
+			/* Return a value which is the maximum deviation
+			 * below the ideal rate, for use as a metric.
+			 */
+			if ((tmp_rate - low) < (high - tmp_rate))
+				tmp_rate = low;
+			else
+				tmp_rate -= high - tmp_rate;
+		}
+		return tmp_rate;
 	}
 
 	if (data->frac_bits)
@@ -1167,6 +1191,7 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
 
 	*div = curdiv << CM_DIV_FRAC_BITS;
 	*prate = curdiv * best_rate;
+	*avgrate = best_rate;
 
 	return best_rate;
 }
@@ -1178,6 +1203,7 @@ static int bcm2835_clock_determine_rate(struct clk_hw *hw,
 	bool current_parent_is_pllc;
 	unsigned long rate, best_rate = 0;
 	unsigned long prate, best_prate = 0;
+	unsigned long avgrate, best_avgrate = 0;
 	size_t i;
 	u32 div;
 
@@ -1202,11 +1228,13 @@ static int bcm2835_clock_determine_rate(struct clk_hw *hw,
 			continue;
 
 		rate = bcm2835_clock_choose_div_and_prate(hw, i, req->rate,
-							  &div, &prate);
+							  &div, &prate,
+							  &avgrate);
 		if (rate > best_rate && rate <= req->rate) {
 			best_parent = parent;
 			best_prate = prate;
 			best_rate = rate;
+			best_avgrate = avgrate;
 		}
 	}
 
@@ -1216,7 +1244,7 @@ static int bcm2835_clock_determine_rate(struct clk_hw *hw,
 	req->best_parent_hw = best_parent;
 	req->best_parent_rate = best_prate;
 
-	req->rate = best_rate;
+	req->rate = best_avgrate;
 
 	return 0;
 }
@@ -2010,6 +2038,7 @@ struct bcm2835_clk_desc {
 		.int_bits = 12,
 		.frac_bits = 12,
 		.is_mash_clock = true,
+		.low_jitter = true,
 		.parents = bcm2835_pcm_per_parents,
 		.tcnt_mux = 23),
 	[BCM2835_CLOCK_PWM]	= REGISTER_PER_CLK(
-- 
1.9.1



From stefan.wahren at i2se.com  Tue May 30 11:41:05 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Tue, 30 May 2017 20:41:05 +0200 (CEST)
Subject: [PATCH 1/2] clk: bcm2835: Limit PCM clock to OSC and PLLD_PER
In-Reply-To: <866b60bb-d1c8-726e-3a2d-11a34f9e8ac7@raspberrypi.org>
References: <866b60bb-d1c8-726e-3a2d-11a34f9e8ac7@raspberrypi.org>
Message-ID: <684006892.45085.1496169665454@email.1und1.de>

Hi Phil,

> Phil Elwell <phil at raspberrypi.org> hat am 30. Mai 2017 um 18:28 geschrieben:
> 
> 
> Restrict clock sources for the PCM peripheral to the oscillator and
> PLLD_PER because other source may have varying rates or be switched off.

> Prevent other sources from being selected by replacing their names in
> the list of potential parents with dummy entries (entry index is
> significant).

i like to have this as a comment above the definition of bcm2835_pcm_per_parents.

> 
> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
> ---
>  drivers/clk/bcm/clk-bcm2835.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index 0258538..facc346 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -1511,6 +1511,16 @@ struct bcm2835_clk_desc {
>  	"pllh_aux",
>  };
>
> +static const char *const bcm2835_pcm_per_parents[] = {

As mentioned above, there should be a comment like all the others. 

> +	"-",
> +	"xosc",
> +	"-",
> +	"-",
> +	"-",
> +	"-",
> +	"plld_per",
> +};

Is there a dummy entry for "pllh_aux" missing?

> +
>  #define REGISTER_PER_CLK(...)	REGISTER_CLK(				\
>  	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),	\
>  	.parents = bcm2835_clock_per_parents,				\
> @@ -2000,6 +2010,7 @@ struct bcm2835_clk_desc {
>  		.int_bits = 12,
>  		.frac_bits = 12,
>  		.is_mash_clock = true,
> +		.parents = bcm2835_pcm_per_parents,

This looks a little bit hacky to me. Not sure, but can we do something like this?

#define REGISTER_PCM_CLK(...)	REGISTER_CLK(				\
	.num_mux_parents = ARRAY_SIZE(bcm2835_pcm_per_parents),	\
	.parents = bcm2835_pcm_per_parents,				\
	__VA_ARGS__)

Regards
Stefan

>  		.tcnt_mux = 23),
>  	[BCM2835_CLOCK_PWM]	= REGISTER_PER_CLK(
>  		.name = "pwm",
> -- 
> 1.9.1
>


From stefan.wahren at i2se.com  Tue May 30 12:04:41 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Tue, 30 May 2017 21:04:41 +0200 (CEST)
Subject: [PATCH 2/2] clk: bcm2835: Minimise clock jitter for PCM clock
In-Reply-To: <b9208d9b-c7bb-49a3-85d9-231c8b41eb8c@raspberrypi.org>
References: <b9208d9b-c7bb-49a3-85d9-231c8b41eb8c@raspberrypi.org>
Message-ID: <1412052002.45738.1496171081779@email.1und1.de>

Hi Phil,

> Phil Elwell <phil at raspberrypi.org> hat am 30. Mai 2017 um 18:28 geschrieben:
> 
> 
> Fractional clock dividers generate accurate average frequencies but
> with jitter, particularly when the integer divisor is small.
> 
> Introduce a new metric of clock accuracy to penalise clocks with a good
> average but worse jitter compared to clocks with an average which is no
> better but with lower jitter. The metric is the ideal rate minus the
> worse deviation from that ideal using the nearest integer divisors.
> 
> Use this metric for parent selection for clocks requiring low jitter
> (currently just PCM).
> 
> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
> ---
>  drivers/clk/bcm/clk-bcm2835.c | 39 ++++++++++++++++++++++++++++++++++-----
>  1 file changed, 34 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index facc346..e0ce5e7 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -530,6 +530,7 @@ struct bcm2835_clock_data {
>  
>  	bool is_vpu_clock;
>  	bool is_mash_clock;
> +	bool low_jitter;
>  
>  	u32 tcnt_mux;
>  };
> @@ -1124,7 +1125,8 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
>  							int parent_idx,
>  							unsigned long rate,
>  							u32 *div,
> -							unsigned long *prate)
> +							unsigned long *prate,
> +							unsigned long *avgrate)
>  {
>  	struct bcm2835_clock *clock = bcm2835_clock_from_hw(hw);
>  	struct bcm2835_cprman *cprman = clock->cprman;
> @@ -1136,11 +1138,33 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
>  	parent = clk_hw_get_parent_by_index(hw, parent_idx);
>  
>  	if (!(BIT(parent_idx) & data->set_rate_parent)) {
> +		unsigned long tmp_rate;
> +
>  		*prate = clk_hw_get_rate(parent);
>  		*div = bcm2835_clock_choose_div(hw, rate, *prate, true);
>  
> -		return bcm2835_clock_rate_from_divisor(clock, *prate,
> -						       *div);
> +		tmp_rate = bcm2835_clock_rate_from_divisor(clock, *prate, *div);
> +		*avgrate = tmp_rate;
> +
> +		if (data->low_jitter && (*div & CM_DIV_FRAC_MASK)) {
> +			unsigned long high, low;
> +			u32 idiv = *div & ~CM_DIV_FRAC_MASK;
> +
> +			high = bcm2835_clock_rate_from_divisor(clock, *prate,
> +							       idiv);
> +			idiv += CM_DIV_FRAC_MASK + 1;
> +			low = bcm2835_clock_rate_from_divisor(clock, *prate,
> +							      idiv);

What about int_div or intdiv instead of idiv as variable name?

> +
> +			/* Return a value which is the maximum deviation
> +			 * below the ideal rate, for use as a metric.
> +			 */

Please fix coding style of the comment.

Thanks
Stefan


From arnd at arndb.de  Mon May 29 02:57:25 2017
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 29 May 2017 11:57:25 +0200
Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
In-Reply-To: <20170529084809.GA2192@mai>
References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
 <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
 <CAK8P3a3QACHYqtCO1z_FpW0nXEtx356wCDha_=SNXU872=q1UQ@mail.gmail.com>
 <20170529084809.GA2192@mai>
Message-ID: <CAK8P3a1Kv_RhKL43ie6co_N5pDXvRHd7Uq8g70qt80WkxuhzLw@mail.gmail.com>

On Mon, May 29, 2017 at 10:48 AM, Daniel Lezcano
<daniel.lezcano at linaro.org> wrote:
> On Mon, May 29, 2017 at 10:41:52AM +0200, Arnd Bergmann wrote:
>> On Sat, May 27, 2017 at 11:58 AM, Daniel Lezcano
>> <daniel.lezcano at linaro.org> wrote:
>> > The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the
>> > clocksource at early stage. However, this macro is also used to initialize
>> > the clockevent if any, or the clockevent only.
>> >
>> > It was originally suggested to declare another macro to initialize a
>> > clockevent, so in order to separate the two entities even they belong to the
>> > same IP. This was not accepted because of the impact on the DT where splitting
>> > a clocksource/clockevent definition does not make sense as it is a Linux
>> > concept not a hardware description.
>> >
>> > On the other side, the clocksource has not interrupt declared while the
>> > clockevent has, so it is easy from the driver to know if the description is
>> > for a clockevent or a clocksource, IOW it could be implemented at the driver
>> > level.
>> >
>> > So instead of dealing with a named clocksource macro, let's use a more generic
>> > one: TIMER_OF_DECLARE.
>> >
>> > The patch has not functional changes.
>> >
>> > Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
>>
>> Could you either leave the old name as an alias for one release, or introduce
>> the new name as an alias now for 4.13?
>>
>> I think that that would make it easier to merge new drivers. Otherwise this
>> looks good to me,
>
>
> New drivers should go through my tree, so I can catch them with the old macro
> name and do the change.

Sure, they should, and it's quite likely that you won't even need the fallback,
I've just seen too many cases where a similar assumption turned out wrong,
that I'd just pick the safer option just in case whenever I do an API change.

Things that could go wrong include:

- A platform maintainer wants to add a new platform and has a for-next
  branch that gets merged into linux-next, with parts of it going through
  different maintainers, and now they have to choose between a branch
  that doesn't build without the timer branch, or one that break for-next
  unless Stephen applies a fixup

- Some architecture maintainer didn't get the memo and adds an instance of
  CLOCKSOUCE_OF_DECLARE in architecture specific code without asking
  having the patch reviewed first

- A platform has a branch with complex cross-tree dependencies and
  it need to get merged in an unconventional way.

- You make a mistake and accidentally merge one driver for an unusual
  architecture that escapes your test matrix.

While those all are unlikely to happen in a particular merge window, they do
happen occasionally and tend to cause a lot of pain.

       Arnd


From daniel.lezcano at linaro.org  Mon May 29 03:55:09 2017
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 29 May 2017 12:55:09 +0200
Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
In-Reply-To: <CAK8P3a1Kv_RhKL43ie6co_N5pDXvRHd7Uq8g70qt80WkxuhzLw@mail.gmail.com>
References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
 <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
 <CAK8P3a3QACHYqtCO1z_FpW0nXEtx356wCDha_=SNXU872=q1UQ@mail.gmail.com>
 <20170529084809.GA2192@mai>
 <CAK8P3a1Kv_RhKL43ie6co_N5pDXvRHd7Uq8g70qt80WkxuhzLw@mail.gmail.com>
Message-ID: <20170529105509.GC2192@mai>

On Mon, May 29, 2017 at 11:57:25AM +0200, Arnd Bergmann wrote:
> On Mon, May 29, 2017 at 10:48 AM, Daniel Lezcano
> <daniel.lezcano at linaro.org> wrote:
> > On Mon, May 29, 2017 at 10:41:52AM +0200, Arnd Bergmann wrote:
> >> On Sat, May 27, 2017 at 11:58 AM, Daniel Lezcano
> >> <daniel.lezcano at linaro.org> wrote:
> >> > The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the
> >> > clocksource at early stage. However, this macro is also used to initialize
> >> > the clockevent if any, or the clockevent only.
> >> >
> >> > It was originally suggested to declare another macro to initialize a
> >> > clockevent, so in order to separate the two entities even they belong to the
> >> > same IP. This was not accepted because of the impact on the DT where splitting
> >> > a clocksource/clockevent definition does not make sense as it is a Linux
> >> > concept not a hardware description.
> >> >
> >> > On the other side, the clocksource has not interrupt declared while the
> >> > clockevent has, so it is easy from the driver to know if the description is
> >> > for a clockevent or a clocksource, IOW it could be implemented at the driver
> >> > level.
> >> >
> >> > So instead of dealing with a named clocksource macro, let's use a more generic
> >> > one: TIMER_OF_DECLARE.
> >> >
> >> > The patch has not functional changes.
> >> >
> >> > Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> >>
> >> Could you either leave the old name as an alias for one release, or introduce
> >> the new name as an alias now for 4.13?
> >>
> >> I think that that would make it easier to merge new drivers. Otherwise this
> >> looks good to me,
> >
> >
> > New drivers should go through my tree, so I can catch them with the old macro
> > name and do the change.
> 
> Sure, they should, and it's quite likely that you won't even need the fallback,
> I've just seen too many cases where a similar assumption turned out wrong,
> that I'd just pick the safer option just in case whenever I do an API change.
> 
> Things that could go wrong include:
> 
> - A platform maintainer wants to add a new platform and has a for-next
>   branch that gets merged into linux-next, with parts of it going through
>   different maintainers, and now they have to choose between a branch
>   that doesn't build without the timer branch, or one that break for-next
>   unless Stephen applies a fixup
> 
> - Some architecture maintainer didn't get the memo and adds an instance of
>   CLOCKSOUCE_OF_DECLARE in architecture specific code without asking
>   having the patch reviewed first
> 
> - A platform has a branch with complex cross-tree dependencies and
>   it need to get merged in an unconventional way.
> 
> - You make a mistake and accidentally merge one driver for an unusual
>   architecture that escapes your test matrix.
> 
> While those all are unlikely to happen in a particular merge window, they do
> happen occasionally and tend to cause a lot of pain.

Hmm, that sounds scary :)

There is no guarantee, when removing the alias, none of the above happens,
right?

If the timer branch is in linux-next, that could be caugth before any of the
above happens, no?

I'm not against adding an alias, just checking out if it is worth to.

-- 

 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


From arnd at arndb.de  Mon May 29 04:21:54 2017
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 29 May 2017 13:21:54 +0200
Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
In-Reply-To: <20170529105509.GC2192@mai>
References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
 <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
 <CAK8P3a3QACHYqtCO1z_FpW0nXEtx356wCDha_=SNXU872=q1UQ@mail.gmail.com>
 <20170529084809.GA2192@mai>
 <CAK8P3a1Kv_RhKL43ie6co_N5pDXvRHd7Uq8g70qt80WkxuhzLw@mail.gmail.com>
 <20170529105509.GC2192@mai>
Message-ID: <CAK8P3a3MdvWMJyVqE63Ur330mC2wPZO7nFXjd_LukbTjiZtGdg@mail.gmail.com>

On Mon, May 29, 2017 at 12:55 PM, Daniel Lezcano
<daniel.lezcano at linaro.org> wrote:
> On Mon, May 29, 2017 at 11:57:25AM +0200, Arnd Bergmann wrote:
>> On Mon, May 29, 2017 at 10:48 AM, Daniel Lezcano
>> <daniel.lezcano at linaro.org> wrote:
>> Things that could go wrong include:
>>
>> - A platform maintainer wants to add a new platform and has a for-next
>>   branch that gets merged into linux-next, with parts of it going through
>>   different maintainers, and now they have to choose between a branch
>>   that doesn't build without the timer branch, or one that break for-next
>>   unless Stephen applies a fixup
>>
>> - Some architecture maintainer didn't get the memo and adds an instance of
>>   CLOCKSOUCE_OF_DECLARE in architecture specific code without asking
>>   having the patch reviewed first
>>
>> - A platform has a branch with complex cross-tree dependencies and
>>   it need to get merged in an unconventional way.
>>
>> - You make a mistake and accidentally merge one driver for an unusual
>>   architecture that escapes your test matrix.
>>
>> While those all are unlikely to happen in a particular merge window, they do
>> happen occasionally and tend to cause a lot of pain.
>
> Hmm, that sounds scary :)
>
> There is no guarantee, when removing the alias, none of the above happens,
> right?

No, it's just both less likely and easier to work around.

> If the timer branch is in linux-next, that could be caugth before any of the
> above happens, no?

linux-next will find most of these problems, but it will still be more work
for the people that run into build failures when testing linux-next.

     Arnd


From matthias.bgg at gmail.com  Mon May 29 06:25:12 2017
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 29 May 2017 15:25:12 +0200
Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
In-Reply-To: <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
 <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <5d5d1f1b-0948-f28d-0c52-adcdbdf89244@gmail.com>



On 27/05/17 11:58, Daniel Lezcano wrote:
> The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the
> clocksource at early stage. However, this macro is also used to initialize
> the clockevent if any, or the clockevent only.
> 
> It was originally suggested to declare another macro to initialize a
> clockevent, so in order to separate the two entities even they belong to the
> same IP. This was not accepted because of the impact on the DT where splitting
> a clocksource/clockevent definition does not make sense as it is a Linux
> concept not a hardware description.
> 
> On the other side, the clocksource has not interrupt declared while the
> clockevent has, so it is easy from the driver to know if the description is
> for a clockevent or a clocksource, IOW it could be implemented at the driver
> level.
> 
> So instead of dealing with a named clocksource macro, let's use a more generic
> one: TIMER_OF_DECLARE.
> 
> The patch has not functional changes.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---

[...]

> diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
> index 9065949..f9b724f 100644
> --- a/drivers/clocksource/mtk_timer.c
> +++ b/drivers/clocksource/mtk_timer.c
> @@ -265,4 +265,4 @@ static int __init mtk_timer_init(struct device_node *node)
>   
>   	return -EINVAL;
>   }
> -CLOCKSOURCE_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_timer_init);
> +TIMER_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_timer_init);

For the mediatek driver:

Acked-by: Matthias Brugger <matthias.bgg at gmail.com>


From ulf.hansson at linaro.org  Mon May 29 07:42:45 2017
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Mon, 29 May 2017 16:42:45 +0200
Subject: [PATCH v2] mmc: bcm2835: fix potential null pointer dereferences
In-Reply-To: <20170525170455.GA6904@embeddedgus>
References: <20170525114638.Horde.wq7PLKWCg8CwLM5WiWj1Obm@gator4166.hostgator.com>
 <20170525170455.GA6904@embeddedgus>
Message-ID: <CAPDyKFo2+YL=nk=SmTKG1gPwVPWaOTth++1WUqRXL2+meZ72pg@mail.gmail.com>

On 25 May 2017 at 19:04, Gustavo A. R. Silva <garsilva at embeddedor.com> wrote:
> Null check at line 1165: if (mrq->cmd), implies that mrq->cmd might
> be NULL.
> Add null checks before dereferencing pointer mrq->cmd in order to avoid
> any potential NULL pointer dereference.
>
> Addresses-Coverity-ID: 1408740
> Tested-by: Stefan Wahren <stefan.wahren at i2se.com>
> Signed-off-by: Gustavo A. R. Silva <garsilva at embeddedor.com>

Thanks, applied for next!

Kind regards
Uffe

> ---
> Changes in v2:
>  Change subject to make it clear the patch is bcm2835 related.
>
>  drivers/mmc/host/bcm2835.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/bcm2835.c b/drivers/mmc/host/bcm2835.c
> index 1f343a4..abba9a2 100644
> --- a/drivers/mmc/host/bcm2835.c
> +++ b/drivers/mmc/host/bcm2835.c
> @@ -1172,7 +1172,10 @@ static void bcm2835_request(struct mmc_host *mmc, struct mmc_request *mrq)
>         if (mrq->data && !is_power_of_2(mrq->data->blksz)) {
>                 dev_err(dev, "unsupported block size (%d bytes)\n",
>                         mrq->data->blksz);
> -               mrq->cmd->error = -EINVAL;
> +
> +               if (mrq->cmd)
> +                       mrq->cmd->error = -EINVAL;
> +
>                 mmc_request_done(mmc, mrq);
>                 return;
>         }
> @@ -1194,7 +1197,10 @@ static void bcm2835_request(struct mmc_host *mmc, struct mmc_request *mrq)
>                         readl(host->ioaddr + SDCMD) & SDCMD_CMD_MASK,
>                         edm);
>                 bcm2835_dumpregs(host);
> -               mrq->cmd->error = -EILSEQ;
> +
> +               if (mrq->cmd)
> +                       mrq->cmd->error = -EILSEQ;
> +
>                 bcm2835_finish_request(host);
>                 mutex_unlock(&host->mutex);
>                 return;
> @@ -1207,7 +1213,7 @@ static void bcm2835_request(struct mmc_host *mmc, struct mmc_request *mrq)
>                         if (!host->use_busy)
>                                 bcm2835_finish_command(host);
>                 }
> -       } else if (bcm2835_send_command(host, mrq->cmd)) {
> +       } else if (mrq->cmd && bcm2835_send_command(host, mrq->cmd)) {
>                 if (host->data && host->dma_desc) {
>                         /* DMA transfer starts now, PIO starts after irq */
>                         bcm2835_start_dma(host);
> --
> 2.5.0
>


From scott.branden at broadcom.com  Mon May 29 09:35:27 2017
From: scott.branden at broadcom.com (Scott Branden)
Date: Mon, 29 May 2017 09:35:27 -0700
Subject: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular
 distinctions
In-Reply-To: <CACRpkdbQTDkqy+ChBq=pg1BnHH5ARL0+J-zL_gipEEotujOxbA@mail.gmail.com>
References: <20170522205648.23545-1-paul.gortmaker@windriver.com>
 <20170522205648.23545-4-paul.gortmaker@windriver.com>
 <CACRpkdbQTDkqy+ChBq=pg1BnHH5ARL0+J-zL_gipEEotujOxbA@mail.gmail.com>
Message-ID: <4eb8be51-8cf9-31b9-c6e6-52fdb9cd202d@broadcom.com>

Hi Linus,


On 17-05-29 01:31 AM, Linus Walleij wrote:
> On Mon, May 22, 2017 at 10:56 PM, Paul Gortmaker
> <paul.gortmaker at windriver.com> wrote:
>
>> Fixups here tend to be more of a conglomerate of some of the other
>> repeated/systematic ones we've seen in the earlier pinctrl cleanups.
>>
>> We remove module.h from code that isn't doing anything modular at
>> all;  if they have __init sections, then replace it with init.h
>>
>> One driver has a .remove that would be dispatched on module_exit,
>> and as that code is essentially orphaned, so we remove it.  In case
>> anyone was previously doing the (pointless) unbind to get to that
>> function, we disable unbind for this one driver as well.
>>
>> A couple bool drivers (hence non-modular) are converted over to
>> to builtin_platform_driver().
>>
>> Since module_platform_driver() uses the same init level priority as
>> builtin_platform_driver() the init ordering remains unchanged with
>> this commit.
>>
>> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>>
>> We also delete the MODULE_LICENSE tag etc. since all that information
>> was (or is now) contained at the top of the file in the comments.
>>
>> Cc: Eric Anholt <eric at anholt.net>
>> Cc: Florian Fainelli <f.fainelli at gmail.com>
>> Cc: Jon Mason <jonmason at broadcom.com>
>> Cc: Linus Walleij <linus.walleij at linaro.org>
>> Cc: Ray Jui <rjui at broadcom.com>
>> Cc: Scott Branden <sbranden at broadcom.com>
>> Cc: Stefan Wahren <stefan.wahren at i2se.com>
>> Cc: Sherman Yin <syin at broadcom.com>
>> Cc: bcm-kernel-feedback-list at broadcom.com
>> Cc: linux-gpio at vger.kernel.org
>> Cc: linux-rpi-kernel at lists.infradead.org
>> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> Patch applied with Stefan Wahren's Tested-by tag.
>
> I can't take header standardization into account, header files are not
> ABI, further see
> Documentation/process/stable-api-nonsense.rst
It is a simple ask to place the new information in a new comment after 
the legal header.

An aim at consistency helps reduce confusion (internal and external)
of what license header template to apply to files.  Modifying these 
headers and placing
information in the middle of them does not help in this effort.

> Yours,
> Linus Walleij
Regards,
Scott


From linus.walleij at linaro.org  Tue May 30 00:41:40 2017
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 30 May 2017 09:41:40 +0200
Subject: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular
 distinctions
In-Reply-To: <4eb8be51-8cf9-31b9-c6e6-52fdb9cd202d@broadcom.com>
References: <20170522205648.23545-1-paul.gortmaker@windriver.com>
 <20170522205648.23545-4-paul.gortmaker@windriver.com>
 <CACRpkdbQTDkqy+ChBq=pg1BnHH5ARL0+J-zL_gipEEotujOxbA@mail.gmail.com>
 <4eb8be51-8cf9-31b9-c6e6-52fdb9cd202d@broadcom.com>
Message-ID: <CACRpkdYeKvMwjBNZ40nS3R9Wp9fVNfTn2-8zPegt==ODGT44ig@mail.gmail.com>

On Mon, May 29, 2017 at 6:35 PM, Scott Branden
<scott.branden at broadcom.com> wrote:

> It is a simple ask to place the new information in a new comment after the
> legal header.

OK send a patch fixing the headers the way you want them.

I don't mind if you want a certain order on your desk as a figure
of speak, I am the same.

> An aim at consistency helps reduce confusion (internal and external)
> of what license header template to apply to files.  Modifying these headers
> and placing
> information in the middle of them does not help in this effort.

Aha, I understand it if a human is reading the files.

If it is a machine, not so much, as we should not serve the machines
but the other way around.

Yours,
Linus Walleij


From phil at raspberrypi.org  Wed May 31 01:28:31 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Wed, 31 May 2017 09:28:31 +0100
Subject: [PATCH 1/2] clk: bcm2835: Limit PCM clock to OSC and PLLD_PER
In-Reply-To: <684006892.45085.1496169665454@email.1und1.de>
References: <866b60bb-d1c8-726e-3a2d-11a34f9e8ac7@raspberrypi.org>
 <684006892.45085.1496169665454@email.1und1.de>
Message-ID: <56d5f9c5-ba15-4d3e-7956-fb697fe12114@raspberrypi.org>

Hi Stefan,

On 30/05/2017 19:41, Stefan Wahren wrote:
> Hi Phil,
> 
>> Phil Elwell <phil at raspberrypi.org> hat am 30. Mai 2017 um 18:28 geschrieben:
>>
>>
>> Restrict clock sources for the PCM peripheral to the oscillator and
>> PLLD_PER because other source may have varying rates or be switched off.
> 
>> Prevent other sources from being selected by replacing their names in
>> the list of potential parents with dummy entries (entry index is
>> significant).
> 
> i like to have this as a comment above the definition of bcm2835_pcm_per_parents.

Sure - good idea.

>>
>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>> ---
>>  drivers/clk/bcm/clk-bcm2835.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
>> index 0258538..facc346 100644
>> --- a/drivers/clk/bcm/clk-bcm2835.c
>> +++ b/drivers/clk/bcm/clk-bcm2835.c
>> @@ -1511,6 +1511,16 @@ struct bcm2835_clk_desc {
>>  	"pllh_aux",
>>  };
>>
>> +static const char *const bcm2835_pcm_per_parents[] = {
> 
> As mentioned above, there should be a comment like all the others.

Yes, will do.

>> +	"-",
>> +	"xosc",
>> +	"-",
>> +	"-",
>> +	"-",
>> +	"-",
>> +	"plld_per",
>> +};
> 
> Is there a dummy entry for "pllh_aux" missing?

Yes and no - adding it will cause an extra iteration around the loop, but 
perhaps it's less confusing. I'll add one.

>> +
>>  #define REGISTER_PER_CLK(...)	REGISTER_CLK(				\
>>  	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),	\
>>  	.parents = bcm2835_clock_per_parents,				\
>> @@ -2000,6 +2010,7 @@ struct bcm2835_clk_desc {
>>  		.int_bits = 12,
>>  		.frac_bits = 12,
>>  		.is_mash_clock = true,
>> +		.parents = bcm2835_pcm_per_parents,
> 
> This looks a little bit hacky to me. Not sure, but can we do something like this?
> 
> #define REGISTER_PCM_CLK(...)	REGISTER_CLK(				\
> 	.num_mux_parents = ARRAY_SIZE(bcm2835_pcm_per_parents),	\
> 	.parents = bcm2835_pcm_per_parents,				\
> 	__VA_ARGS__)

Of course - no problem.

Thanks for the feedback - it will be incorporated into V2.

Phil


From phil at raspberrypi.org  Wed May 31 01:33:26 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Wed, 31 May 2017 09:33:26 +0100
Subject: [PATCH 2/2] clk: bcm2835: Minimise clock jitter for PCM clock
In-Reply-To: <1412052002.45738.1496171081779@email.1und1.de>
References: <b9208d9b-c7bb-49a3-85d9-231c8b41eb8c@raspberrypi.org>
 <1412052002.45738.1496171081779@email.1und1.de>
Message-ID: <7aa4fb5f-65e3-56ed-9792-e38a947346b9@raspberrypi.org>

Hi Stefan,

On 30/05/2017 20:04, Stefan Wahren wrote:
> Hi Phil,
> 
>> Phil Elwell <phil at raspberrypi.org> hat am 30. Mai 2017 um 18:28 geschrieben:
>>
>>
>> Fractional clock dividers generate accurate average frequencies but
>> with jitter, particularly when the integer divisor is small.
>>
>> Introduce a new metric of clock accuracy to penalise clocks with a good
>> average but worse jitter compared to clocks with an average which is no
>> better but with lower jitter. The metric is the ideal rate minus the
>> worse deviation from that ideal using the nearest integer divisors.
>>
>> Use this metric for parent selection for clocks requiring low jitter
>> (currently just PCM).
>>
>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>> ---
>>  drivers/clk/bcm/clk-bcm2835.c | 39 ++++++++++++++++++++++++++++++++++-----
>>  1 file changed, 34 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
>> index facc346..e0ce5e7 100644
>> --- a/drivers/clk/bcm/clk-bcm2835.c
>> +++ b/drivers/clk/bcm/clk-bcm2835.c
>> @@ -530,6 +530,7 @@ struct bcm2835_clock_data {
>>  
>>  	bool is_vpu_clock;
>>  	bool is_mash_clock;
>> +	bool low_jitter;
>>  
>>  	u32 tcnt_mux;
>>  };
>> @@ -1124,7 +1125,8 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
>>  							int parent_idx,
>>  							unsigned long rate,
>>  							u32 *div,
>> -							unsigned long *prate)
>> +							unsigned long *prate,
>> +							unsigned long *avgrate)
>>  {
>>  	struct bcm2835_clock *clock = bcm2835_clock_from_hw(hw);
>>  	struct bcm2835_cprman *cprman = clock->cprman;
>> @@ -1136,11 +1138,33 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
>>  	parent = clk_hw_get_parent_by_index(hw, parent_idx);
>>  
>>  	if (!(BIT(parent_idx) & data->set_rate_parent)) {
>> +		unsigned long tmp_rate;
>> +
>>  		*prate = clk_hw_get_rate(parent);
>>  		*div = bcm2835_clock_choose_div(hw, rate, *prate, true);
>>  
>> -		return bcm2835_clock_rate_from_divisor(clock, *prate,
>> -						       *div);
>> +		tmp_rate = bcm2835_clock_rate_from_divisor(clock, *prate, *div);
>> +		*avgrate = tmp_rate;
>> +
>> +		if (data->low_jitter && (*div & CM_DIV_FRAC_MASK)) {
>> +			unsigned long high, low;
>> +			u32 idiv = *div & ~CM_DIV_FRAC_MASK;
>> +
>> +			high = bcm2835_clock_rate_from_divisor(clock, *prate,
>> +							       idiv);
>> +			idiv += CM_DIV_FRAC_MASK + 1;
>> +			low = bcm2835_clock_rate_from_divisor(clock, *prate,
>> +							      idiv);
> 
> What about int_div or intdiv instead of idiv as variable name?

OK - int_div matches tmp_rate.

>> +
>> +			/* Return a value which is the maximum deviation
>> +			 * below the ideal rate, for use as a metric.
>> +			 */
> 
> Please fix coding style of the comment.

Oops. I'm surprised checkpatch didn't complain about that.

Thanks,

Phil


From stefan.wahren at i2se.com  Wed May 31 01:59:46 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 31 May 2017 10:59:46 +0200
Subject: [PATCH 1/2] clk: bcm2835: Limit PCM clock to OSC and PLLD_PER
In-Reply-To: <56d5f9c5-ba15-4d3e-7956-fb697fe12114@raspberrypi.org>
References: <866b60bb-d1c8-726e-3a2d-11a34f9e8ac7@raspberrypi.org>
 <684006892.45085.1496169665454@email.1und1.de>
 <56d5f9c5-ba15-4d3e-7956-fb697fe12114@raspberrypi.org>
Message-ID: <6741c61b-e557-5063-2bad-2464eccfc639@i2se.com>

Am 31.05.2017 um 10:28 schrieb Phil Elwell:
> Hi Stefan,
>
> On 30/05/2017 19:41, Stefan Wahren wrote:
>> Hi Phil,
>>
>>> Phil Elwell <phil at raspberrypi.org> hat am 30. Mai 2017 um 18:28 geschrieben:
>>>
>>>
>>> Restrict clock sources for the PCM peripheral to the oscillator and
>>> PLLD_PER because other source may have varying rates or be switched off.
>>> Prevent other sources from being selected by replacing their names in
>>> the list of potential parents with dummy entries (entry index is
>>> significant).
>> i like to have this as a comment above the definition of bcm2835_pcm_per_parents.
> Sure - good idea.
>
>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>> ---
>>>  drivers/clk/bcm/clk-bcm2835.c | 11 +++++++++++
>>>  1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
>>> index 0258538..facc346 100644
>>> --- a/drivers/clk/bcm/clk-bcm2835.c
>>> +++ b/drivers/clk/bcm/clk-bcm2835.c
>>> @@ -1511,6 +1511,16 @@ struct bcm2835_clk_desc {
>>>  	"pllh_aux",
>>>  };
>>>
>>> +static const char *const bcm2835_pcm_per_parents[] = {
>> As mentioned above, there should be a comment like all the others.
> Yes, will do.
>
>>> +	"-",
>>> +	"xosc",
>>> +	"-",
>>> +	"-",
>>> +	"-",
>>> +	"-",
>>> +	"plld_per",
>>> +};
>> Is there a dummy entry for "pllh_aux" missing?
> Yes and no - adding it will cause an extra iteration around the loop, but 
> perhaps it's less confusing. I'll add one.

In case you want to save an iteration, you could add short comment
instead of a dummy entry.

>
>>> +
>>>  #define REGISTER_PER_CLK(...)	REGISTER_CLK(				\
>>>  	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),	\
>>>  	.parents = bcm2835_clock_per_parents,				\
>>> @@ -2000,6 +2010,7 @@ struct bcm2835_clk_desc {
>>>  		.int_bits = 12,
>>>  		.frac_bits = 12,
>>>  		.is_mash_clock = true,
>>> +		.parents = bcm2835_pcm_per_parents,
>> This looks a little bit hacky to me. Not sure, but can we do something like this?
>>
>> #define REGISTER_PCM_CLK(...)	REGISTER_CLK(				\
>> 	.num_mux_parents = ARRAY_SIZE(bcm2835_pcm_per_parents),	\
>> 	.parents = bcm2835_pcm_per_parents,				\
>> 	__VA_ARGS__)
> Of course - no problem.
>
> Thanks for the feedback - it will be incorporated into V2.
>
> Phil




From phil at raspberrypi.org  Wed May 31 02:18:19 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Wed, 31 May 2017 10:18:19 +0100
Subject: [PATCH v2 0/2] clk: bcm2835: PCM clock improvements
In-Reply-To: <4c11ad43-ef4e-3fbd-500a-02b2b46e0fbd@raspberrypi.org>
References: <4c11ad43-ef4e-3fbd-500a-02b2b46e0fbd@raspberrypi.org>
Message-ID: <c44d1f29-4ec6-6b87-59a4-71aeb1f5c4d7@raspberrypi.org>

The switch to using the upstream bcm2835_cprman clock driver caused a
few problems for users of PCM (I2S) peripherals. Audio applications
require accurate, stable clocks, and the cprman driver wasn't
conservative enough in its choice of clock sources.

These patches restrict the clock sources for the PCM peripheral in two
ways: the first causes all possible sources except OSC and PLLD_PER
to be ignored, while the second allows clocks to be specified as
"low_jitter", causing the effects of fractional divisors to be taken
into account when comparing potential clocks for accuracy. In practice,
the combined effect of the two patches is to choose OSC as a source if
an integer divisor can be used, otherwise PLLD_PER is chosen.

Changes in v2:
* Extended bcm2835_pcm_per_parents to cover the pllh_aux slot, and gave
  it a comment in patch 1.
* Added a REGISTER_PCM_CLK analagous to REGISTER_PER_CLK in patch 1.
* Renamed temporary variable idiv to int_div in patch 2.

Phil Elwell (2):
  clk: bcm2835: Limit PCM clock to OSC and PLLD_PER
  clk: bcm2835: Minimise clock jitter for PCM clock

 drivers/clk/bcm/clk-bcm2835.c | 50 ++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 45 insertions(+), 5 deletions(-)

-- 
1.9.1




From phil at raspberrypi.org  Wed May 31 02:18:25 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Wed, 31 May 2017 10:18:25 +0100
Subject: [PATCH v2 1/2] clk: bcm2835: Limit PCM clock to OSC and PLLD_PER
In-Reply-To: <866b60bb-d1c8-726e-3a2d-11a34f9e8ac7@raspberrypi.org>
References: <866b60bb-d1c8-726e-3a2d-11a34f9e8ac7@raspberrypi.org>
Message-ID: <8a9ebac4-b299-b887-27b2-86f4f61846fd@raspberrypi.org>

Restrict clock sources for the PCM peripheral to the oscillator and
PLLD_PER because other source may have varying rates or be switched off.
Prevent other sources from being selected by replacing their names in
the list of potential parents with dummy entries (entry index is
significant).

Signed-off-by: Phil Elwell <phil at raspberrypi.org>
---
 drivers/clk/bcm/clk-bcm2835.c | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 0258538..81ecd4c 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -1516,6 +1516,31 @@ struct bcm2835_clk_desc {
 	.parents = bcm2835_clock_per_parents,				\
 	__VA_ARGS__)
 
+/*
+ * Restrict clock sources for the PCM peripheral to the oscillator and
+ * PLLD_PER because other source may have varying rates or be switched
+ * off.
+ *
+ * Prevent other sources from being selected by replacing their names in
+ * the list of potential parents with dummy entries (entry index is
+ * significant).
+ */
+static const char *const bcm2835_pcm_per_parents[] = {
+	"-",
+	"xosc",
+	"-",
+	"-",
+	"-",
+	"-",
+	"plld_per",
+	"-",
+};
+
+#define REGISTER_PCM_CLK(...)	REGISTER_CLK(				\
+	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_pcm_per_parents),	\
+	.parents = bcm2835_clock_pcm_per_parents,			\
+	__VA_ARGS__)
+
 /* main vpu parent mux */
 static const char *const bcm2835_clock_vpu_parents[] = {
 	"gnd",
@@ -1993,7 +2018,7 @@ struct bcm2835_clk_desc {
 		.int_bits = 4,
 		.frac_bits = 8,
 		.tcnt_mux = 22),
-	[BCM2835_CLOCK_PCM]	= REGISTER_PER_CLK(
+	[BCM2835_CLOCK_PCM]	= REGISTER_PCM_CLK(
 		.name = "pcm",
 		.ctl_reg = CM_PCMCTL,
 		.div_reg = CM_PCMDIV,
-- 
1.9.1



From phil at raspberrypi.org  Wed May 31 02:18:33 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Wed, 31 May 2017 10:18:33 +0100
Subject: [PATCH v2 2/2] clk: bcm2835: Minimise clock jitter for PCM clock
In-Reply-To: <b9208d9b-c7bb-49a3-85d9-231c8b41eb8c@raspberrypi.org>
References: <b9208d9b-c7bb-49a3-85d9-231c8b41eb8c@raspberrypi.org>
Message-ID: <a507a7e7-3c64-1dcb-98f1-a7f94364f26c@raspberrypi.org>

Fractional clock dividers generate accurate average frequencies but
with jitter, particularly when the integer divisor is small.

Introduce a new metric of clock accuracy to penalise clocks with a good
average but worse jitter compared to clocks with an average which is no
better but with lower jitter. The metric is the ideal rate minus the
worse deviation from that ideal using the nearest integer divisors.

Use this metric for parent selection for clocks requiring low jitter
(currently just PCM).

Signed-off-by: Phil Elwell <phil at raspberrypi.org>
---
 drivers/clk/bcm/clk-bcm2835.c | 40 +++++++++++++++++++++++++++++++++++-----
 1 file changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 81ecd4c..c7ee951 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -530,6 +530,7 @@ struct bcm2835_clock_data {
 
 	bool is_vpu_clock;
 	bool is_mash_clock;
+	bool low_jitter;
 
 	u32 tcnt_mux;
 };
@@ -1124,7 +1125,8 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
 							int parent_idx,
 							unsigned long rate,
 							u32 *div,
-							unsigned long *prate)
+							unsigned long *prate,
+							unsigned long *avgrate)
 {
 	struct bcm2835_clock *clock = bcm2835_clock_from_hw(hw);
 	struct bcm2835_cprman *cprman = clock->cprman;
@@ -1136,11 +1138,34 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
 	parent = clk_hw_get_parent_by_index(hw, parent_idx);
 
 	if (!(BIT(parent_idx) & data->set_rate_parent)) {
+		unsigned long tmp_rate;
+
 		*prate = clk_hw_get_rate(parent);
 		*div = bcm2835_clock_choose_div(hw, rate, *prate, true);
 
-		return bcm2835_clock_rate_from_divisor(clock, *prate,
-						       *div);
+		tmp_rate = bcm2835_clock_rate_from_divisor(clock, *prate, *div);
+		*avgrate = tmp_rate;
+
+		if (data->low_jitter && (*div & CM_DIV_FRAC_MASK)) {
+			unsigned long high, low;
+			u32 int_div = *div & ~CM_DIV_FRAC_MASK;
+
+			high = bcm2835_clock_rate_from_divisor(clock, *prate,
+							       int_div);
+			int_div += CM_DIV_FRAC_MASK + 1;
+			low = bcm2835_clock_rate_from_divisor(clock, *prate,
+							      int_div);
+
+			/*
+			 * Return a value which is the maximum deviation
+			 * below the ideal rate, for use as a metric.
+			 */
+			if ((tmp_rate - low) < (high - tmp_rate))
+				tmp_rate = low;
+			else
+				tmp_rate -= high - tmp_rate;
+		}
+		return tmp_rate;
 	}
 
 	if (data->frac_bits)
@@ -1167,6 +1192,7 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
 
 	*div = curdiv << CM_DIV_FRAC_BITS;
 	*prate = curdiv * best_rate;
+	*avgrate = best_rate;
 
 	return best_rate;
 }
@@ -1178,6 +1204,7 @@ static int bcm2835_clock_determine_rate(struct clk_hw *hw,
 	bool current_parent_is_pllc;
 	unsigned long rate, best_rate = 0;
 	unsigned long prate, best_prate = 0;
+	unsigned long avgrate, best_avgrate = 0;
 	size_t i;
 	u32 div;
 
@@ -1202,11 +1229,13 @@ static int bcm2835_clock_determine_rate(struct clk_hw *hw,
 			continue;
 
 		rate = bcm2835_clock_choose_div_and_prate(hw, i, req->rate,
-							  &div, &prate);
+							  &div, &prate,
+							  &avgrate);
 		if (rate > best_rate && rate <= req->rate) {
 			best_parent = parent;
 			best_prate = prate;
 			best_rate = rate;
+			best_avgrate = avgrate;
 		}
 	}
 
@@ -1216,7 +1245,7 @@ static int bcm2835_clock_determine_rate(struct clk_hw *hw,
 	req->best_parent_hw = best_parent;
 	req->best_parent_rate = best_prate;
 
-	req->rate = best_rate;
+	req->rate = best_avgrate;
 
 	return 0;
 }
@@ -2025,6 +2054,7 @@ struct bcm2835_clk_desc {
 		.int_bits = 12,
 		.frac_bits = 12,
 		.is_mash_clock = true,
+		.low_jitter = true,
 		.tcnt_mux = 23),
 	[BCM2835_CLOCK_PWM]	= REGISTER_PER_CLK(
 		.name = "pwm",
-- 
1.9.1




From stefan.wahren at i2se.com  Wed May 31 02:19:11 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 31 May 2017 11:19:11 +0200
Subject: [PATCH 2/2] clk: bcm2835: Minimise clock jitter for PCM clock
In-Reply-To: <7aa4fb5f-65e3-56ed-9792-e38a947346b9@raspberrypi.org>
References: <b9208d9b-c7bb-49a3-85d9-231c8b41eb8c@raspberrypi.org>
 <1412052002.45738.1496171081779@email.1und1.de>
 <7aa4fb5f-65e3-56ed-9792-e38a947346b9@raspberrypi.org>
Message-ID: <461fec8c-f8ee-e6d6-ab72-0ac735fa4605@i2se.com>

Am 31.05.2017 um 10:33 schrieb Phil Elwell:
> Hi Stefan,
>
> On 30/05/2017 20:04, Stefan Wahren wrote:
>> Hi Phil,
>>
>>> Phil Elwell <phil at raspberrypi.org> hat am 30. Mai 2017 um 18:28 geschrieben:
>>>
>>>
>>> Fractional clock dividers generate accurate average frequencies but
>>> with jitter, particularly when the integer divisor is small.
>>>
>>> Introduce a new metric of clock accuracy to penalise clocks with a good
>>> average but worse jitter compared to clocks with an average which is no
>>> better but with lower jitter. The metric is the ideal rate minus the
>>> worse deviation from that ideal using the nearest integer divisors.
>>>
>>> Use this metric for parent selection for clocks requiring low jitter
>>> (currently just PCM).
>>>
>>> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
>>> ---
>>>  drivers/clk/bcm/clk-bcm2835.c | 39 ++++++++++++++++++++++++++++++++++-----
>>>  1 file changed, 34 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
>>> index facc346..e0ce5e7 100644
>>> --- a/drivers/clk/bcm/clk-bcm2835.c
>>> +++ b/drivers/clk/bcm/clk-bcm2835.c
>>> @@ -530,6 +530,7 @@ struct bcm2835_clock_data {
>>>  
>>>  	bool is_vpu_clock;
>>>  	bool is_mash_clock;
>>> +	bool low_jitter;
>>>  
>>>  	u32 tcnt_mux;
>>>  };
>>> @@ -1124,7 +1125,8 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
>>>  							int parent_idx,
>>>  							unsigned long rate,
>>>  							u32 *div,
>>> -							unsigned long *prate)
>>> +							unsigned long *prate,
>>> +							unsigned long *avgrate)
>>>  {
>>>  	struct bcm2835_clock *clock = bcm2835_clock_from_hw(hw);
>>>  	struct bcm2835_cprman *cprman = clock->cprman;
>>> @@ -1136,11 +1138,33 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
>>>  	parent = clk_hw_get_parent_by_index(hw, parent_idx);
>>>  
>>>  	if (!(BIT(parent_idx) & data->set_rate_parent)) {
>>> +		unsigned long tmp_rate;
>>> +
>>>  		*prate = clk_hw_get_rate(parent);
>>>  		*div = bcm2835_clock_choose_div(hw, rate, *prate, true);
>>>  
>>> -		return bcm2835_clock_rate_from_divisor(clock, *prate,
>>> -						       *div);
>>> +		tmp_rate = bcm2835_clock_rate_from_divisor(clock, *prate, *div);
>>> +		*avgrate = tmp_rate;
>>> +
>>> +		if (data->low_jitter && (*div & CM_DIV_FRAC_MASK)) {
>>> +			unsigned long high, low;
>>> +			u32 idiv = *div & ~CM_DIV_FRAC_MASK;
>>> +
>>> +			high = bcm2835_clock_rate_from_divisor(clock, *prate,
>>> +							       idiv);
>>> +			idiv += CM_DIV_FRAC_MASK + 1;
>>> +			low = bcm2835_clock_rate_from_divisor(clock, *prate,
>>> +							      idiv);
>> What about int_div or intdiv instead of idiv as variable name?
> OK - int_div matches tmp_rate.
>
>>> +
>>> +			/* Return a value which is the maximum deviation
>>> +			 * below the ideal rate, for use as a metric.
>>> +			 */
>> Please fix coding style of the comment.
> Oops. I'm surprised checkpatch didn't complain about that.

The style above is only used for netdev.

>
> Thanks,
>
> Phil


From phil at raspberrypi.org  Wed May 31 03:17:24 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Wed, 31 May 2017 11:17:24 +0100
Subject: Bug: sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware
 interrupt.
In-Reply-To: <433605218.311867.1495813840749@email.1und1.de>
References: <433605218.311867.1495813840749@email.1und1.de>
Message-ID: <bc3e84df-1d06-9e46-9f13-0e2b293ce716@raspberrypi.org>

Hi Stefan,

On 26/05/2017 16:50, Stefan Wahren wrote:
> Hi,
> 
> i noticed that the RPI2 with next-20170526 and bcm2835_defconfig doesn't boot from SD card [1]. At least i was able to fix the NULL pointer dereference [2]. Now i'm getting the output see below. I try to narrow this down, but maybe someone already has an idea.
>
> Regards
> Stefan
> 
> [1] - https://storage.kernelci.org/next/master/next-20170526/arm/bcm2835_defconfig/lab-collabora/boot-bcm2836-rpi-2-b.txt
> [2] - https://github.com/lategoodbye/rpi-zero/commit/ff0b8c7e3f6a4d1b6dfe99710fa9ee333e2b8886
> 
> [    0.328506] sdhci: Secure Digital Host Controller Interface driver
> [    0.330949] sdhci: Copyright(c) Pierre Ossman
> [    0.471038] sdhost-bcm2835 3f202000.mmc: loaded - DMA enabled (>1)
> [    0.473582] sdhci-pltfm: SDHCI platform and OF driver helper
> [    0.476764] ledtrig-cpu: registered to indicate activity on CPUs
> [    0.479552] usbcore: registered new interface driver usbhid
> [    0.481930] usbhid: USB HID core driver
> [    0.484411] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
> [    0.488231] oprofile: using timer interrupt.
> [    0.492227] NET: Registered protocol family 10
> [    0.496233] Segment Routing with IPv6
> [    0.498773] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> [    0.502518] NET: Registered protocol family 17
> [    0.510802] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2
> [    0.852460] mmc0: host does not support reading read-only switch, assuming write-enable
> [    0.860971] mmc0: new high speed SDHC card at address 0001
> [    0.875465] mmcblk0: mmc0:0001 00000 29.8 GiB
> [    1.397285] console [ttyAMA0] enabled
> [    1.406137] raspberrypi-firmware soc:firmware: Attached to firmware from 2017-04-27 17:19
> [    1.423787] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok
> [    1.434811]  mmcblk0: p1 p2
> [    1.441932] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops)
> [    1.452869] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops)
> [    1.462502] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops)
> [    1.472183] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops)
> [    1.482493] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops)
> [    1.492658] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops)
> [    1.502596] cma: cma_alloc: alloc failed, req-size: 4096 pages, ret: -12
> [    1.512404] vc4-drm soc:gpu: failed to allocate buffer with size 16777216
> [    1.522337] cma: cma_alloc: alloc failed, req-size: 4096 pages, ret: -12
> [    1.532182] vc4-drm soc:gpu: failed to allocate buffer with size 16777216
> [    1.542155] [drm:vc4_bo_create] *ERROR* Failed to allocate from CMA:
> [    1.551681] [drm] num bos allocated: 0
> [    1.558530] [drm] size bos allocated: 0kb
> [    1.565612] [drm] num bos used: 0
> [    1.571938] [drm] size bos used: 0kb
> [    1.578483] [drm] num bos cached: 0
> [    1.584922] [drm] size bos cached: 0kb
> [    1.591580] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.
> [    1.609589] vc4-drm soc:gpu: failed to bind 3fc00000.v3d (ops vc4_v3d_ops): -12
> [    1.621480] vc4-drm soc:gpu: master bind failed: -12
> [    1.629515] vc4_v3d: probe of 3fc00000.v3d failed with error -12
> [    1.715334] dwc2 3f980000.usb: DWC OTG Controller
> [    1.723064] dwc2 3f980000.usb: new USB bus registered, assigned bus number 1
> [    1.733085] dwc2 3f980000.usb: irq 39, io mem 0x3f980000
> [    1.742503] hub 1-0:1.0: USB hub found
> [    1.749074] hub 1-0:1.0: 1 port detected
> [    1.756656] ALSA device list:
> [    1.762420]   No soundcards found.
> [    1.798146] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
> [    1.812372] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
> [    1.830538] devtmpfs: mounted
> [    1.841464] Freeing unused kernel memory: 1024K

Does this jump in time look reasonable to you? To me it looks like the problem we had with max_cpus=1 on an SMP configuration before we marked the first page as reserved. The kernel allocator would eventually allocate page zero for some application (it was usually audio-related), at which point the remaining spinning CPUs would execute semi-random code with interesting side effects. A bogus update to the system clock would be enough to trigger an apparent timeout when in fact the interval was much shorter.

> [  223.667700] sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware interrupt.
> [  223.667701] sdhost-bcm2835 3f202000.mmc: =========== REGISTER DUMP ===========
> [  223.667702] sdhost-bcm2835 3f202000.mmc: SDCMD  0x00004052
> [  223.667702] sdhost-bcm2835 3f202000.mmc: SDARG  0x00021e18
> [  223.667699] sdhost-bcm2835 3f202000.mmc: SDTOUT 0x017d2a20
> [  223.667702] sdhost-bcm2835 3f202000.mmc: SDCDIV 0x00000003
> [  223.667705] sdhost-bcm2835 3f202000.mmc: SDRSP0 0x00000900
> [  223.667703] sdhost-bcm2835 3f202000.mmc: SDRSP1 0x00001269
> [  223.667703] sdhost-bcm2835 3f202000.mmc: SDRSP2 0x7fffffff
> [  223.667705] sdhost-bcm2835 3f202000.mmc: SDRSP3 0x00024007
> [  223.667705] sdhost-bcm2835 3f202000.mmc: SDHSTS 0x00000081
> [  223.667701] sdhost-bcm2835 3f202000.mmc: SDVDD  0x00000001
> [  223.667702] sdhost-bcm2835 3f202000.mmc: SDEDM  0x00010831
> [  223.667702] sdhost-bcm2835 3f202000.mmc: SDHCFG 0x0000040e
> [  223.667700] sdhost-bcm2835 3f202000.mmc: SDHBCT 0x00000200
> [  223.667699] sdhost-bcm2835 3f202000.mmc: SDHBLC 0x00000001
> [  223.667699] sdhost-bcm2835 3f202000.mmc: ===========================================
> 

Phil


From stefan.wahren at i2se.com  Wed May 31 07:58:01 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 31 May 2017 16:58:01 +0200
Subject: [PATCH v2 0/2] clk: bcm2835: PCM clock improvements
In-Reply-To: <c44d1f29-4ec6-6b87-59a4-71aeb1f5c4d7@raspberrypi.org>
References: <4c11ad43-ef4e-3fbd-500a-02b2b46e0fbd@raspberrypi.org>
 <c44d1f29-4ec6-6b87-59a4-71aeb1f5c4d7@raspberrypi.org>
Message-ID: <d9c1303d-a170-bb83-f9a9-94f201e4ac2c@i2se.com>

Am 31.05.2017 um 11:18 schrieb Phil Elwell:
> The switch to using the upstream bcm2835_cprman clock driver caused a
> few problems for users of PCM (I2S) peripherals. Audio applications
> require accurate, stable clocks, and the cprman driver wasn't
> conservative enough in its choice of clock sources.
>
> These patches restrict the clock sources for the PCM peripheral in two
> ways: the first causes all possible sources except OSC and PLLD_PER
> to be ignored, while the second allows clocks to be specified as
> "low_jitter", causing the effects of fractional divisors to be taken
> into account when comparing potential clocks for accuracy. In practice,
> the combined effect of the two patches is to choose OSC as a source if
> an integer divisor can be used, otherwise PLLD_PER is chosen.
>
> Changes in v2:
> * Extended bcm2835_pcm_per_parents to cover the pllh_aux slot, and gave
>   it a comment in patch 1.
> * Added a REGISTER_PCM_CLK analagous to REGISTER_PER_CLK in patch 1.
> * Renamed temporary variable idiv to int_div in patch 2.
>
> Phil Elwell (2):
>   clk: bcm2835: Limit PCM clock to OSC and PLLD_PER
>   clk: bcm2835: Minimise clock jitter for PCM clock
>
>  drivers/clk/bcm/clk-bcm2835.c | 50 ++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 45 insertions(+), 5 deletions(-)
>
For the whole series:

Acked-by: Stefan Wahren <stefan.wahren at i2se.com>

I hope Eric as the author of the driver has a chance to look over the
patches.

Stefan



From swarren at wwwdotorg.org  Wed May 31 08:27:07 2017
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 May 2017 09:27:07 -0600
Subject: CLK_OF_DECLARE advice required
In-Reply-To: <ae427c15-330f-6f8d-e2ac-62a8deacbdc5@raspberrypi.org>
References: <ae427c15-330f-6f8d-e2ac-62a8deacbdc5@raspberrypi.org>
Message-ID: <8b65e551-e6dd-cf5c-1b22-e1f1a5996d73@wwwdotorg.org>

On 05/30/2017 06:23 AM, Phil Elwell wrote:
> Hi,
> 
> I've run into a problem using the fixed-factor clock on Raspberry Pi and I'd
> like some advice before I submit a patch.
> 
> Some context: the aim is to use a standard UART and some external circuitry
> as a MIDI interface. This would be straightforward except that Linux doesn't
> recognise the required 31.25KHz as a valid UART baud rate. Rhe workaround is
> to declare the UART clock such that the reported rate differs from the actual
> rate. If one sets the reported rate to be (actual*38400)/31250 then
> requesting a 38400 baud rate will result in an actual 31250 baud signal.

This sounds like the wrong approach. Forcing the port to use a different 
clock rate than the user requests would prevent anyone from using that 
port for its standard purpose; it'd turn what should be a runtime 
decision into a compile-time decision.

Are you sure there's no way to simply select the correct baud rate on 
the port? I see plenty of references to configuring custom baud rates 
under Linux when I search Google, e.g.:

> https://stackoverflow.com/questions/12646324/how-to-set-a-custom-baud-rate-on-linux
"How to set a custom baud rate on Linux?"

> https://sourceware.org/ml/libc-help/2009-06/msg00016.html
"Re: Terminal interface and non-standard baudrates"


From stefan.wahren at i2se.com  Wed May 31 08:58:08 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 31 May 2017 17:58:08 +0200
Subject: CLK_OF_DECLARE advice required
In-Reply-To: <8b65e551-e6dd-cf5c-1b22-e1f1a5996d73@wwwdotorg.org>
References: <ae427c15-330f-6f8d-e2ac-62a8deacbdc5@raspberrypi.org>
 <8b65e551-e6dd-cf5c-1b22-e1f1a5996d73@wwwdotorg.org>
Message-ID: <0794f430-9761-c855-9a89-13d9871c5831@i2se.com>

Am 31.05.2017 um 17:27 schrieb Stephen Warren:
> On 05/30/2017 06:23 AM, Phil Elwell wrote:
>> Hi,
>>
>> I've run into a problem using the fixed-factor clock on Raspberry Pi
>> and I'd
>> like some advice before I submit a patch.
>>
>> Some context: the aim is to use a standard UART and some external
>> circuitry
>> as a MIDI interface. This would be straightforward except that Linux
>> doesn't
>> recognise the required 31.25KHz as a valid UART baud rate. Rhe
>> workaround is
>> to declare the UART clock such that the reported rate differs from
>> the actual
>> rate. If one sets the reported rate to be (actual*38400)/31250 then
>> requesting a 38400 baud rate will result in an actual 31250 baud signal.
>
> This sounds like the wrong approach. Forcing the port to use a
> different clock rate than the user requests would prevent anyone from
> using that port for its standard purpose; it'd turn what should be a
> runtime decision into a compile-time decision.
>
> Are you sure there's no way to simply select the correct baud rate on
> the port? I see plenty of references to configuring custom baud rates
> under Linux when I search Google, e.g.:
>
>> https://stackoverflow.com/questions/12646324/how-to-set-a-custom-baud-rate-on-linux
>>
> "How to set a custom baud rate on Linux?"
>
>> https://sourceware.org/ml/libc-help/2009-06/msg00016.html
> "Re: Terminal interface and non-standard baudrates"
>

I remember this gist from Peter Hurley:

https://gist.github.com/peterhurley/fbace59b55d87306a5b8


From phil at raspberrypi.org  Wed May 31 09:28:58 2017
From: phil at raspberrypi.org (Phil Elwell)
Date: Wed, 31 May 2017 17:28:58 +0100
Subject: CLK_OF_DECLARE advice required
In-Reply-To: <0794f430-9761-c855-9a89-13d9871c5831@i2se.com>
References: <ae427c15-330f-6f8d-e2ac-62a8deacbdc5@raspberrypi.org>
 <8b65e551-e6dd-cf5c-1b22-e1f1a5996d73@wwwdotorg.org>
 <0794f430-9761-c855-9a89-13d9871c5831@i2se.com>
Message-ID: <6765be64-9cf6-4663-4182-5b63f27bfb93@raspberrypi.org>

On 31/05/2017 16:58, Stefan Wahren wrote:
> Am 31.05.2017 um 17:27 schrieb Stephen Warren:
>> On 05/30/2017 06:23 AM, Phil Elwell wrote:
>>> Hi,
>>>
>>> I've run into a problem using the fixed-factor clock on Raspberry Pi
>>> and I'd
>>> like some advice before I submit a patch.
>>>
>>> Some context: the aim is to use a standard UART and some external
>>> circuitry
>>> as a MIDI interface. This would be straightforward except that Linux
>>> doesn't
>>> recognise the required 31.25KHz as a valid UART baud rate. Rhe
>>> workaround is
>>> to declare the UART clock such that the reported rate differs from
>>> the actual
>>> rate. If one sets the reported rate to be (actual*38400)/31250 then
>>> requesting a 38400 baud rate will result in an actual 31250 baud signal.
>>
>> This sounds like the wrong approach. Forcing the port to use a
>> different clock rate than the user requests would prevent anyone from
>> using that port for its standard purpose; it'd turn what should be a
>> runtime decision into a compile-time decision.
>>
>> Are you sure there's no way to simply select the correct baud rate on
>> the port? I see plenty of references to configuring custom baud rates
>> under Linux when I search Google, e.g.:
>>
>>> https://stackoverflow.com/questions/12646324/how-to-set-a-custom-baud-rate-on-linux
>>>
>> "How to set a custom baud rate on Linux?"
>>
>>> https://sourceware.org/ml/libc-help/2009-06/msg00016.html
>> "Re: Terminal interface and non-standard baudrates"
>>
> 
> I remember this gist from Peter Hurley:
> 
> https://gist.github.com/peterhurley/fbace59b55d87306a5b8

Thank you, Stephen and Stephan. Stephen - the clock scaling is applied by a DT overlay so
it effectively a runtime setting, but I take your point about the elegance of the solution.
Stefan - anybaud looks promising, although I would have preferred for users to continue to
use the existing user-space tools - kernel changes can be deployed more easily.

For my edification, can you pretend for a moment that the application was a valid one and
answer any of my original questions?:

1. Should all system clock drivers use OF_CLK_DECLARE? Doing so would probably
avoid this problem, but further initialisation order dependencies may
require more drivers to be initialised early.

2. Why does the clock initialisation hook registered by OF_CLK_DECLARE not
return any indication of success? If it did, and if the OF_POPULATED flag
was only set after successful initialisation then the normal retrying of
a deferred probe would also avoid this problem.

3. Would adding the OF_CLK_DECLARE hook prevent the use of the devm_ managed
functions like devm_kzalloc? If not, why doesn't fixed-factor-clock use it?

Thanks,

Phil


From swarren at wwwdotorg.org  Wed May 31 09:47:50 2017
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 31 May 2017 10:47:50 -0600
Subject: CLK_OF_DECLARE advice required
In-Reply-To: <6765be64-9cf6-4663-4182-5b63f27bfb93@raspberrypi.org>
References: <ae427c15-330f-6f8d-e2ac-62a8deacbdc5@raspberrypi.org>
 <8b65e551-e6dd-cf5c-1b22-e1f1a5996d73@wwwdotorg.org>
 <0794f430-9761-c855-9a89-13d9871c5831@i2se.com>
 <6765be64-9cf6-4663-4182-5b63f27bfb93@raspberrypi.org>
Message-ID: <256cf892-cf3f-155e-05d7-eaed7728000a@wwwdotorg.org>

On 05/31/2017 10:28 AM, Phil Elwell wrote:
> On 31/05/2017 16:58, Stefan Wahren wrote:
>> Am 31.05.2017 um 17:27 schrieb Stephen Warren:
>>> On 05/30/2017 06:23 AM, Phil Elwell wrote:
>>>> Hi,
>>>>
>>>> I've run into a problem using the fixed-factor clock on Raspberry Pi
>>>> and I'd
>>>> like some advice before I submit a patch.
>>>>
>>>> Some context: the aim is to use a standard UART and some external
>>>> circuitry
>>>> as a MIDI interface. This would be straightforward except that Linux
>>>> doesn't
>>>> recognise the required 31.25KHz as a valid UART baud rate. Rhe
>>>> workaround is
>>>> to declare the UART clock such that the reported rate differs from
>>>> the actual
>>>> rate. If one sets the reported rate to be (actual*38400)/31250 then
>>>> requesting a 38400 baud rate will result in an actual 31250 baud signal.
>>>
>>> This sounds like the wrong approach. Forcing the port to use a
>>> different clock rate than the user requests would prevent anyone from
>>> using that port for its standard purpose; it'd turn what should be a
>>> runtime decision into a compile-time decision.
>>>
>>> Are you sure there's no way to simply select the correct baud rate on
>>> the port? I see plenty of references to configuring custom baud rates
>>> under Linux when I search Google, e.g.:
>>>
>>>> https://stackoverflow.com/questions/12646324/how-to-set-a-custom-baud-rate-on-linux
>>>>
>>> "How to set a custom baud rate on Linux?"
>>>
>>>> https://sourceware.org/ml/libc-help/2009-06/msg00016.html
>>> "Re: Terminal interface and non-standard baudrates"
>>>
>>
>> I remember this gist from Peter Hurley:
>>
>> https://gist.github.com/peterhurley/fbace59b55d87306a5b8
> 
> Thank you, Stephen and Stephan. Stephen - the clock scaling is applied by a DT overlay so
> it effectively a runtime setting, but I take your point about the elegance of the solution.
> Stefan - anybaud looks promising, although I would have preferred for users to continue to
> use the existing user-space tools - kernel changes can be deployed more easily.
> 
> For my edification, can you pretend for a moment that the application was a valid one and
> answer any of my original questions?:
> 
> 1. Should all system clock drivers use OF_CLK_DECLARE? Doing so would probably
> avoid this problem, but further initialisation order dependencies may
> require more drivers to be initialised early.
> 
> 2. Why does the clock initialisation hook registered by OF_CLK_DECLARE not
> return any indication of success? If it did, and if the OF_POPULATED flag
> was only set after successful initialisation then the normal retrying of
> a deferred probe would also avoid this problem.
> 
> 3. Would adding the OF_CLK_DECLARE hook prevent the use of the devm_ managed
> functions like devm_kzalloc? If not, why doesn't fixed-factor-clock use it?

Sorry, I don't know the answers to these questions; I expect the clock 
subsystem maintainers will have to chime in. My only general comment is 
that probe deferral is the typical mechanism to handle 
driver/device/object dependencies, but I have no idea how that would 
interact with static initialization hooks like OF_CLK_DECLARE.


From stefan.wahren at i2se.com  Wed May 31 10:20:46 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 31 May 2017 19:20:46 +0200 (CEST)
Subject: [GIT PULL] bcm2835 DT fixes for 4.12
In-Reply-To: <d16bf00b-d058-08d1-ed6a-2f369d1fd611@gmail.com>
References: <20170516221931.31292-1-eric@anholt.net>
 <d16bf00b-d058-08d1-ed6a-2f369d1fd611@gmail.com>
Message-ID: <1791886363.81865.1496251246175@email.1und1.de>

Hi Florian,

> Florian Fainelli <f.fainelli at gmail.com> hat am 19. Mai 2017 um 20:17 geschrieben:
> 
> 
> On 05/16/2017 03:19 PM, Eric Anholt wrote:
> > Hi Florian,
> > 
> > The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
> > 
> >   Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://github.com/anholt/linux tags/bcm2835-dt-fixes-2017-05-16
> > 
> > for you to fetch changes up to b0804ed0cadd7e38d94d2f15cdcc0d9695818856:
> > 
> >   ARM: dts: bcm283x: Reserve first page for firmware (2017-05-15 15:05:29 -0700)
> > 
> > ----------------------------------------------------------------
> > This pull request brings in a fix for booting on SMP Raspberry Pis,
> > particularly with maxcpus=1
> > 
> > ----------------------------------------------------------------
> 
> Merged, thanks Eric

when it's planned to send this fix to Olof?

Thanks
Stefan

> -- 
> -- 
> Florian


From f.fainelli at gmail.com  Wed May 31 10:44:05 2017
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Wed, 31 May 2017 10:44:05 -0700
Subject: [GIT PULL] bcm2835 DT fixes for 4.12
In-Reply-To: <1791886363.81865.1496251246175@email.1und1.de>
References: <20170516221931.31292-1-eric@anholt.net>
 <d16bf00b-d058-08d1-ed6a-2f369d1fd611@gmail.com>
 <1791886363.81865.1496251246175@email.1und1.de>
Message-ID: <98834BF8-FEC0-4DCB-B2C1-C2B1838AF5B6@gmail.com>

On May 31, 2017 10:20:46 AM PDT, Stefan Wahren <stefan.wahren at i2se.com> wrote:
>Hi Florian,
>
>> Florian Fainelli <f.fainelli at gmail.com> hat am 19. Mai 2017 um 20:17
>geschrieben:
>> 
>> 
>> On 05/16/2017 03:19 PM, Eric Anholt wrote:
>> > Hi Florian,
>> > 
>> > The following changes since commit
>2ea659a9ef488125eb46da6eb571de5eae5c43f6:
>> > 
>> >   Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
>> > 
>> > are available in the git repository at:
>> > 
>> >   git://github.com/anholt/linux tags/bcm2835-dt-fixes-2017-05-16
>> > 
>> > for you to fetch changes up to
>b0804ed0cadd7e38d94d2f15cdcc0d9695818856:
>> > 
>> >   ARM: dts: bcm283x: Reserve first page for firmware (2017-05-15
>15:05:29 -0700)
>> > 
>> > ----------------------------------------------------------------
>> > This pull request brings in a fix for booting on SMP Raspberry Pis,
>> > particularly with maxcpus=1
>> > 
>> > ----------------------------------------------------------------
>> 
>> Merged, thanks Eric
>
>when it's planned to send this fix to Olof?

It's been sent and merged already but I realized lakml was not copied:

https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=fixes
Hi,
-- 
Florian


From stefan.wahren at i2se.com  Wed May 31 11:19:37 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 31 May 2017 20:19:37 +0200 (CEST)
Subject: [GIT PULL] bcm2835 DT fixes for 4.12
In-Reply-To: <98834BF8-FEC0-4DCB-B2C1-C2B1838AF5B6@gmail.com>
References: <20170516221931.31292-1-eric@anholt.net>
 <d16bf00b-d058-08d1-ed6a-2f369d1fd611@gmail.com>
 <1791886363.81865.1496251246175@email.1und1.de>
 <98834BF8-FEC0-4DCB-B2C1-C2B1838AF5B6@gmail.com>
Message-ID: <89540641.83197.1496254777407@email.1und1.de>


> Florian Fainelli <f.fainelli at gmail.com> hat am 31. Mai 2017 um 19:44 geschrieben:
> 
> 
> On May 31, 2017 10:20:46 AM PDT, Stefan Wahren <stefan.wahren at i2se.com> wrote:
> >Hi Florian,
> >
> >> Florian Fainelli <f.fainelli at gmail.com> hat am 19. Mai 2017 um 20:17
> >geschrieben:
> >> 
> >> 
> >> On 05/16/2017 03:19 PM, Eric Anholt wrote:
> >> > Hi Florian,
> >> > 
> >> > The following changes since commit
> >2ea659a9ef488125eb46da6eb571de5eae5c43f6:
> >> > 
> >> >   Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
> >> > 
> >> > are available in the git repository at:
> >> > 
> >> >   git://github.com/anholt/linux tags/bcm2835-dt-fixes-2017-05-16
> >> > 
> >> > for you to fetch changes up to
> >b0804ed0cadd7e38d94d2f15cdcc0d9695818856:
> >> > 
> >> >   ARM: dts: bcm283x: Reserve first page for firmware (2017-05-15
> >15:05:29 -0700)
> >> > 
> >> > ----------------------------------------------------------------
> >> > This pull request brings in a fix for booting on SMP Raspberry Pis,
> >> > particularly with maxcpus=1
> >> > 
> >> > ----------------------------------------------------------------
> >> 
> >> Merged, thanks Eric
> >
> >when it's planned to send this fix to Olof?
> 
> It's been sent and merged already but I realized lakml was not copied:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=fixes

Thanks


From stefan.wahren at i2se.com  Wed May 31 12:02:30 2017
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 31 May 2017 21:02:30 +0200 (CEST)
Subject: Bug: sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware
 interrupt.
In-Reply-To: <bc3e84df-1d06-9e46-9f13-0e2b293ce716@raspberrypi.org>
References: <433605218.311867.1495813840749@email.1und1.de>
 <bc3e84df-1d06-9e46-9f13-0e2b293ce716@raspberrypi.org>
Message-ID: <151854876.72134.1496257350702@email.1und1.de>


> Phil Elwell <phil at raspberrypi.org> hat am 31. Mai 2017 um 12:17 geschrieben:
> 
> 
> Hi Stefan,
> 
> On 26/05/2017 16:50, Stefan Wahren wrote:
> > Hi,
> > 
> > i noticed that the RPI2 with next-20170526 and bcm2835_defconfig doesn't boot from SD card [1]. At least i was able to fix the NULL pointer dereference [2]. Now i'm getting the output see below. I try to narrow this down, but maybe someone already has an idea.
> >
> > Regards
> > Stefan
> > 
> > [1] - https://storage.kernelci.org/next/master/next-20170526/arm/bcm2835_defconfig/lab-collabora/boot-bcm2836-rpi-2-b.txt
> > [2] - https://github.com/lategoodbye/rpi-zero/commit/ff0b8c7e3f6a4d1b6dfe99710fa9ee333e2b8886
> > 
> > [    0.328506] sdhci: Secure Digital Host Controller Interface driver
> > [    0.330949] sdhci: Copyright(c) Pierre Ossman
> > [    0.471038] sdhost-bcm2835 3f202000.mmc: loaded - DMA enabled (>1)
> > [    0.473582] sdhci-pltfm: SDHCI platform and OF driver helper
> > [    0.476764] ledtrig-cpu: registered to indicate activity on CPUs
> > [    0.479552] usbcore: registered new interface driver usbhid
> > [    0.481930] usbhid: USB HID core driver
> > [    0.484411] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
> > [    0.488231] oprofile: using timer interrupt.
> > [    0.492227] NET: Registered protocol family 10
> > [    0.496233] Segment Routing with IPv6
> > [    0.498773] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> > [    0.502518] NET: Registered protocol family 17
> > [    0.510802] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2
> > [    0.852460] mmc0: host does not support reading read-only switch, assuming write-enable
> > [    0.860971] mmc0: new high speed SDHC card at address 0001
> > [    0.875465] mmcblk0: mmc0:0001 00000 29.8 GiB
> > [    1.397285] console [ttyAMA0] enabled
> > [    1.406137] raspberrypi-firmware soc:firmware: Attached to firmware from 2017-04-27 17:19
> > [    1.423787] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok
> > [    1.434811]  mmcblk0: p1 p2
> > [    1.441932] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops)
> > [    1.452869] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops)
> > [    1.462502] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops)
> > [    1.472183] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops)
> > [    1.482493] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops)
> > [    1.492658] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops)
> > [    1.502596] cma: cma_alloc: alloc failed, req-size: 4096 pages, ret: -12
> > [    1.512404] vc4-drm soc:gpu: failed to allocate buffer with size 16777216
> > [    1.522337] cma: cma_alloc: alloc failed, req-size: 4096 pages, ret: -12
> > [    1.532182] vc4-drm soc:gpu: failed to allocate buffer with size 16777216
> > [    1.542155] [drm:vc4_bo_create] *ERROR* Failed to allocate from CMA:
> > [    1.551681] [drm] num bos allocated: 0
> > [    1.558530] [drm] size bos allocated: 0kb
> > [    1.565612] [drm] num bos used: 0
> > [    1.571938] [drm] size bos used: 0kb
> > [    1.578483] [drm] num bos cached: 0
> > [    1.584922] [drm] size bos cached: 0kb
> > [    1.591580] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.
> > [    1.609589] vc4-drm soc:gpu: failed to bind 3fc00000.v3d (ops vc4_v3d_ops): -12
> > [    1.621480] vc4-drm soc:gpu: master bind failed: -12
> > [    1.629515] vc4_v3d: probe of 3fc00000.v3d failed with error -12
> > [    1.715334] dwc2 3f980000.usb: DWC OTG Controller
> > [    1.723064] dwc2 3f980000.usb: new USB bus registered, assigned bus number 1
> > [    1.733085] dwc2 3f980000.usb: irq 39, io mem 0x3f980000
> > [    1.742503] hub 1-0:1.0: USB hub found
> > [    1.749074] hub 1-0:1.0: 1 port detected
> > [    1.756656] ALSA device list:
> > [    1.762420]   No soundcards found.
> > [    1.798146] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
> > [    1.812372] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
> > [    1.830538] devtmpfs: mounted
> > [    1.841464] Freeing unused kernel memory: 1024K
> 
> Does this jump in time look reasonable to you? To me it looks like the problem we had with max_cpus=1 on an SMP configuration before we marked the first page as reserved. The kernel allocator would eventually allocate page zero for some application (it was usually audio-related), at which point the remaining spinning CPUs would execute semi-random code with interesting side effects. A bogus update to the system clock would be enough to trigger an apparent timeout when in fact the interval was much shorter.

Thanks for the hint. I wrongly assumed that the patch was already in linux-next. With patch applied the hang isn't reproducible.


From eric at anholt.net  Wed May 31 14:24:26 2017
From: eric at anholt.net (Eric Anholt)
Date: Wed, 31 May 2017 14:24:26 -0700
Subject: [PATCH 1/2] clk: bcm2835: Limit PCM clock to OSC and PLLD_PER
In-Reply-To: <866b60bb-d1c8-726e-3a2d-11a34f9e8ac7@raspberrypi.org>
References: <866b60bb-d1c8-726e-3a2d-11a34f9e8ac7@raspberrypi.org>
Message-ID: <87efv4btyt.fsf@eliezer.anholt.net>

Phil Elwell <phil at raspberrypi.org> writes:

> Restrict clock sources for the PCM peripheral to the oscillator and
> PLLD_PER because other source may have varying rates or be switched off.
> Prevent other sources from being selected by replacing their names in
> the list of potential parents with dummy entries (entry index is
> significant).

I might be up for giving my r-b on this, but first I'd like to check if
we can simplify even more.  Looking through this list:

static const char *const bcm2835_clock_per_parents[] = {
	"gnd",
	"xosc",
	"testdebug0",
	"testdebug1",
	"plla_per",
	"pllc_per",
	"plld_per",
	"pllh_aux",
};

PLLA is off and unused and we don't want any peripheral to turn it on
(unless we wanted PCM to do so, but we aren't doing that here).

PLLC's rate gets changed by the VPU and so it isn't reliable.
67615c588a059b731df9d019edc3c561d8006ec9 made it so that nobody uses it
that isn't using it by firmware setup, and EMMC is the only one that the
firmware is having use PLLC.  Would we be better off just having EMMC
always be on PLLD?  Or, we could special-case EMMC to be the only one to
use PLLC.

PLLD is stable.

PLLH should only be used as a parent by VEC (or HSM, assuming that
drm/vc4 rate-sets PLLH_PIX first, but I don't know of a reason for HSM
to not just be fractionally divided off of PLLD).  If you've got
firmware display in use, it may change rate or be disabled behind
Linux's back, so we don't want anything but Linux-controlled VEC to use
it.  We could special-case VEC to be the only one that had PLLH_AUX as
parent.

So, my proposal would be to basically make everything but VEC and maybe
EMMC use your new list, and drop the code in
67615c588a059b731df9d019edc3c561d8006ec9.  That said, if you want to do
this first for PCM and then extend it to the rest of the clock
consumers, I'm fine with that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170531/ce0d46d9/attachment.sig>

From eric at anholt.net  Wed May 31 14:36:05 2017
From: eric at anholt.net (Eric Anholt)
Date: Wed, 31 May 2017 14:36:05 -0700
Subject: [PATCH v2 2/2] clk: bcm2835: Minimise clock jitter for PCM clock
In-Reply-To: <a507a7e7-3c64-1dcb-98f1-a7f94364f26c@raspberrypi.org>
References: <b9208d9b-c7bb-49a3-85d9-231c8b41eb8c@raspberrypi.org>
 <a507a7e7-3c64-1dcb-98f1-a7f94364f26c@raspberrypi.org>
Message-ID: <87bmq8btfe.fsf@eliezer.anholt.net>

Phil Elwell <phil at raspberrypi.org> writes:

> Fractional clock dividers generate accurate average frequencies but
> with jitter, particularly when the integer divisor is small.
>
> Introduce a new metric of clock accuracy to penalise clocks with a good
> average but worse jitter compared to clocks with an average which is no
> better but with lower jitter. The metric is the ideal rate minus the
> worse deviation from that ideal using the nearest integer divisors.

"worst" the second time

> Use this metric for parent selection for clocks requiring low jitter
> (currently just PCM).
>
> Signed-off-by: Phil Elwell <phil at raspberrypi.org>
> ---
>  drivers/clk/bcm/clk-bcm2835.c | 40 +++++++++++++++++++++++++++++++++++-----
>  1 file changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index 81ecd4c..c7ee951 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -530,6 +530,7 @@ struct bcm2835_clock_data {
>  
>  	bool is_vpu_clock;
>  	bool is_mash_clock;
> +	bool low_jitter;
>  
>  	u32 tcnt_mux;
>  };
> @@ -1124,7 +1125,8 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
>  							int parent_idx,
>  							unsigned long rate,
>  							u32 *div,
> -							unsigned long *prate)
> +							unsigned long *prate,
> +							unsigned long *avgrate)
>  {
>  	struct bcm2835_clock *clock = bcm2835_clock_from_hw(hw);
>  	struct bcm2835_cprman *cprman = clock->cprman;
> @@ -1136,11 +1138,34 @@ static unsigned long bcm2835_clock_choose_div_and_prate(struct clk_hw *hw,
>  	parent = clk_hw_get_parent_by_index(hw, parent_idx);
>  
>  	if (!(BIT(parent_idx) & data->set_rate_parent)) {
> +		unsigned long tmp_rate;
> +
>  		*prate = clk_hw_get_rate(parent);
>  		*div = bcm2835_clock_choose_div(hw, rate, *prate, true);
>  
> -		return bcm2835_clock_rate_from_divisor(clock, *prate,
> -						       *div);
> +		tmp_rate = bcm2835_clock_rate_from_divisor(clock, *prate, *div);
> +		*avgrate = tmp_rate;
> +
> +		if (data->low_jitter && (*div & CM_DIV_FRAC_MASK)) {
> +			unsigned long high, low;
> +			u32 int_div = *div & ~CM_DIV_FRAC_MASK;
> +
> +			high = bcm2835_clock_rate_from_divisor(clock, *prate,
> +							       int_div);
> +			int_div += CM_DIV_FRAC_MASK + 1;
> +			low = bcm2835_clock_rate_from_divisor(clock, *prate,
> +							      int_div);
> +
> +			/*
> +			 * Return a value which is the maximum deviation
> +			 * below the ideal rate, for use as a metric.
> +			 */
> +			if ((tmp_rate - low) < (high - tmp_rate))
> +				tmp_rate = low;
> +			else
> +				tmp_rate -= high - tmp_rate;

Simplification suggestion: Remove tmp_rate variable, just assign to
rate_from_divisor result to *avgrate.  At the end of the low_jitter
block, just "return *avgrate - max(*avgrate - low, high - *avgrate)".

With that, feel free to add:

Reviewed-by: Eric Anholt <eric at anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170531/9687faee/attachment.sig>

From sboyd at codeaurora.org  Wed May 31 23:39:37 2017
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 31 May 2017 23:39:37 -0700
Subject: CLK_OF_DECLARE advice required
In-Reply-To: <6765be64-9cf6-4663-4182-5b63f27bfb93@raspberrypi.org>
References: <ae427c15-330f-6f8d-e2ac-62a8deacbdc5@raspberrypi.org>
 <8b65e551-e6dd-cf5c-1b22-e1f1a5996d73@wwwdotorg.org>
 <0794f430-9761-c855-9a89-13d9871c5831@i2se.com>
 <6765be64-9cf6-4663-4182-5b63f27bfb93@raspberrypi.org>
Message-ID: <20170601063937.GN20170@codeaurora.org>

On 05/31, Phil Elwell wrote:
> On 31/05/2017 16:58, Stefan Wahren wrote:
> > Am 31.05.2017 um 17:27 schrieb Stephen Warren:
> >> On 05/30/2017 06:23 AM, Phil Elwell wrote:
> >>> Hi,
> >>>
> >>> I've run into a problem using the fixed-factor clock on Raspberry Pi
> >>> and I'd
> >>> like some advice before I submit a patch.
> >>>
> >>> Some context: the aim is to use a standard UART and some external
> >>> circuitry
> >>> as a MIDI interface. This would be straightforward except that Linux
> >>> doesn't
> >>> recognise the required 31.25KHz as a valid UART baud rate. Rhe
> >>> workaround is
> >>> to declare the UART clock such that the reported rate differs from
> >>> the actual
> >>> rate. If one sets the reported rate to be (actual*38400)/31250 then
> >>> requesting a 38400 baud rate will result in an actual 31250 baud signal.
> >>
> >> This sounds like the wrong approach. Forcing the port to use a
> >> different clock rate than the user requests would prevent anyone from
> >> using that port for its standard purpose; it'd turn what should be a
> >> runtime decision into a compile-time decision.
> >>
> >> Are you sure there's no way to simply select the correct baud rate on
> >> the port? I see plenty of references to configuring custom baud rates
> >> under Linux when I search Google, e.g.:
> >>
> >>> https://stackoverflow.com/questions/12646324/how-to-set-a-custom-baud-rate-on-linux
> >>>
> >> "How to set a custom baud rate on Linux?"
> >>
> >>> https://sourceware.org/ml/libc-help/2009-06/msg00016.html
> >> "Re: Terminal interface and non-standard baudrates"
> >>
> > 
> > I remember this gist from Peter Hurley:
> > 
> > https://gist.github.com/peterhurley/fbace59b55d87306a5b8
> 
> Thank you, Stephen and Stephan. Stephen - the clock scaling is applied by a DT overlay so
> it effectively a runtime setting, but I take your point about the elegance of the solution.
> Stefan - anybaud looks promising, although I would have preferred for users to continue to
> use the existing user-space tools - kernel changes can be deployed more easily.
> 
> For my edification, can you pretend for a moment that the application was a valid one and
> answer any of my original questions?:
> 
> 1. Should all system clock drivers use OF_CLK_DECLARE? Doing so would probably
> avoid this problem, but further initialisation order dependencies may
> require more drivers to be initialised early.

No. CLK_OF_DECLARE() is only there to register clks early for
things that need them early, i.e. interrupts and timers.
Otherwise they should be plain drivers (platform or some other
bus). If the same node has both then we have
CLK_OF_DECLARE for that.

> 
> 2. Why does the clock initialisation hook registered by OF_CLK_DECLARE not
> return any indication of success? If it did, and if the OF_POPULATED flag
> was only set after successful initialisation then the normal retrying of
> a deferred probe would also avoid this problem.

Historical raisins. Honestly if it fails the whole system should
probably panic because we aren't going to get interrupts or
schedule properly. Of course, we have whole drivers that register
with CLK_OF_DECLARE() though when they should really be a driver
that can do probe defer, etc., so making a change isn't really
feasible right now.

> 
> 3. Would adding the OF_CLK_DECLARE hook prevent the use of the devm_ managed
> functions like devm_kzalloc? If not, why doesn't fixed-factor-clock use it?
> 

If you use CLK_OF_DECLARE() then you don't get a struct device to
pass to devm functions and thus you can't use them. I don't
follow the question.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From patrice.chotard at st.com  Wed May 31 00:11:41 2017
From: patrice.chotard at st.com (Patrice CHOTARD)
Date: Wed, 31 May 2017 07:11:41 +0000
Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
In-Reply-To: <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
 <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <e6ebd144-414a-51da-d2b4-8d7877eb5d99@st.com>

Hi Daniel

On 05/27/2017 11:58 AM, Daniel Lezcano wrote:
> The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the
> clocksource at early stage. However, this macro is also used to initialize
> the clockevent if any, or the clockevent only.
> 
> It was originally suggested to declare another macro to initialize a
> clockevent, so in order to separate the two entities even they belong to the
> same IP. This was not accepted because of the impact on the DT where splitting
> a clocksource/clockevent definition does not make sense as it is a Linux
> concept not a hardware description.
> 
> On the other side, the clocksource has not interrupt declared while the
> clockevent has, so it is easy from the driver to know if the description is
> for a clockevent or a clocksource, IOW it could be implemented at the driver
> level.
> 
> So instead of dealing with a named clocksource macro, let's use a more generic
> one: TIMER_OF_DECLARE.
> 
> The patch has not functional changes.
> 
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---

[...]

> diff --git a/drivers/clocksource/clksrc_st_lpc.c b/drivers/clocksource/clksrc_st_lpc.c
> index 03cc492..a1d01eb 100644
> --- a/drivers/clocksource/clksrc_st_lpc.c
> +++ b/drivers/clocksource/clksrc_st_lpc.c
> @@ -132,4 +132,4 @@ static int __init st_clksrc_of_register(struct device_node *np)
>   
>   	return ret;
>   }
> -CLOCKSOURCE_OF_DECLARE(ddata, "st,stih407-lpc", st_clksrc_of_register);
> +TIMER_OF_DECLARE(ddata, "st,stih407-lpc", st_clksrc_of_register);

For the STi driver:

Acked-by: Patrice Chotard <patrice.chotard at st.com>

Thanks


From krzk at kernel.org  Wed May 31 01:19:37 2017
From: krzk at kernel.org (Krzysztof Kozlowski)
Date: Wed, 31 May 2017 10:19:37 +0200
Subject: [PATCH 2/7] clocksource: Rename CLOCKSOURCE_OF_DECLARE
In-Reply-To: <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
References: <1495879129-28109-1-git-send-email-daniel.lezcano@linaro.org>
 <1495879129-28109-2-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <CAJKOXPd6GGPCD1L2LtwzpJbcWeJS9d23iJUd6f3RbuBP1h+-Hw@mail.gmail.com>

On Sat, May 27, 2017 at 11:58 AM, Daniel Lezcano
<daniel.lezcano at linaro.org> wrote:
> The CLOCKSOUCE_OF_DECLARE macro is used widely for the timers to declare the
> clocksource at early stage. However, this macro is also used to initialize
> the clockevent if any, or the clockevent only.
>
> It was originally suggested to declare another macro to initialize a
> clockevent, so in order to separate the two entities even they belong to the
> same IP. This was not accepted because of the impact on the DT where splitting
> a clocksource/clockevent definition does not make sense as it is a Linux
> concept not a hardware description.
>
> On the other side, the clocksource has not interrupt declared while the
> clockevent has, so it is easy from the driver to know if the description is
> for a clockevent or a clocksource, IOW it could be implemented at the driver
> level.
>
> So instead of dealing with a named clocksource macro, let's use a more generic
> one: TIMER_OF_DECLARE.
>
> The patch has not functional changes.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  arch/arm/kernel/smp_twd.c                 |  6 +++---
>  arch/microblaze/kernel/timer.c            |  2 +-
>  arch/mips/ralink/cevt-rt3352.c            |  2 +-
>  arch/nios2/kernel/time.c                  |  2 +-
>  drivers/clocksource/arc_timer.c           |  6 +++---
>  drivers/clocksource/arm_arch_timer.c      |  6 +++---
>  drivers/clocksource/arm_global_timer.c    |  2 +-
>  drivers/clocksource/armv7m_systick.c      |  2 +-
>  drivers/clocksource/asm9260_timer.c       |  2 +-
>  drivers/clocksource/bcm2835_timer.c       |  2 +-
>  drivers/clocksource/bcm_kona_timer.c      |  4 ++--
>  drivers/clocksource/cadence_ttc_timer.c   |  2 +-
>  drivers/clocksource/clksrc-dbx500-prcmu.c |  2 +-
>  drivers/clocksource/clksrc_st_lpc.c       |  2 +-
>  drivers/clocksource/clps711x-timer.c      |  2 +-
>  drivers/clocksource/dw_apb_timer_of.c     |  8 ++++----
>  drivers/clocksource/exynos_mct.c          |  4 ++--
>  drivers/clocksource/fsl_ftm_timer.c       |  2 +-
>  drivers/clocksource/h8300_timer16.c       |  2 +-
>  drivers/clocksource/h8300_timer8.c        |  2 +-
>  drivers/clocksource/h8300_tpu.c           |  2 +-
>  drivers/clocksource/jcore-pit.c           |  2 +-
>  drivers/clocksource/meson6_timer.c        |  2 +-
>  drivers/clocksource/mips-gic-timer.c      |  2 +-
>  drivers/clocksource/mps2-timer.c          |  2 +-
>  drivers/clocksource/mtk_timer.c           |  2 +-
>  drivers/clocksource/mxs_timer.c           |  2 +-
>  drivers/clocksource/nomadik-mtu.c         |  2 +-
>  drivers/clocksource/pxa_timer.c           |  2 +-
>  drivers/clocksource/qcom-timer.c          |  4 ++--
>  drivers/clocksource/renesas-ostm.c        |  2 +-
>  drivers/clocksource/rockchip_timer.c      |  4 ++--
>  drivers/clocksource/samsung_pwm_timer.c   |  8 ++++----

For exynos_mct and samsung_pwm_timer:
Acked-by: Krzysztof Kozlowski <krzk at kernel.org>

Best regards,
Krzysztof


