Re: [PATCH v2] mm/swap.c: make functions and their kernel-doc agree

[Matthew Wilcox]

On Tue, Jan 30, 2018 at 01:34:00PM +0100, Michal Hocko wrote:
> On Mon 29-01-18 16:43:55, Randy Dunlap wrote:
> > - for function pagevec_lookup_entries(), change the function parameter
> >   name from nr_pages to nr_entries since that is more descriptive of
> >   what the parameter actually is and then it matches the kernel-doc
> >   comments also
> 
> I know what is nr_pages because I do expect pages to be returned. What
> are entries? Can it be something different from pages?

entries are any page cache entries -- pages or exceptional entries.
calling this parameter nr_pages tricks you into thinking that you'll
only get pages back.

Re: [PATCH v2] mm/swap.c: make functions and their kernel-doc agree

[Matthew Wilcox]

On Tue, Jan 30, 2018 at 01:34:00PM +0100, Michal Hocko wrote:
> On Mon 29-01-18 16:43:55, Randy Dunlap wrote:
> > - for function pagevec_lookup_entries(), change the function parameter
> >   name from nr_pages to nr_entries since that is more descriptive of
> >   what the parameter actually is and then it matches the kernel-doc
> >   comments also
> 
> I know what is nr_pages because I do expect pages to be returned. What
> are entries? Can it be something different from pages?

entries are any page cache entries -- pages or exceptional entries.
calling this parameter nr_pages tricks you into thinking that you'll
only get pages back.

Re: [RFC] mm/migrate: Add new migration reason MR_HUGETLB

[Michal Hocko]

On Wed 31-01-18 07:55:05, Anshuman Khandual wrote:
> On 01/30/2018 01:29 PM, Michal Hocko wrote:
> > On Tue 30-01-18 08:37:14, Anshuman Khandual wrote:
> >> alloc_contig_range() initiates compaction and eventual migration for
> >> the purpose of either CMA or HugeTLB allocation. At present, reason
> >> code remains the same MR_CMA for either of those cases. Lets add a
> >> new reason code which will differentiate the purpose of migration
> >> as HugeTLB allocation instead.
> > Why do we need it?
> 
> The same reason why we have MR_CMA (maybe some other ones as well) at
> present, for reporting purpose through traces at the least. It just
> seemed like same reason code is being used for two different purpose
> of migration.

But do we have any real user asking for this kind of information?

-- 
Michal Hocko
SUSE Labs

Re: [RFC] mm/migrate: Add new migration reason MR_HUGETLB

[Michal Hocko]

On Wed 31-01-18 07:55:05, Anshuman Khandual wrote:
> On 01/30/2018 01:29 PM, Michal Hocko wrote:
> > On Tue 30-01-18 08:37:14, Anshuman Khandual wrote:
> >> alloc_contig_range() initiates compaction and eventual migration for
> >> the purpose of either CMA or HugeTLB allocation. At present, reason
> >> code remains the same MR_CMA for either of those cases. Lets add a
> >> new reason code which will differentiate the purpose of migration
> >> as HugeTLB allocation instead.
> > Why do we need it?
> 
> The same reason why we have MR_CMA (maybe some other ones as well) at
> present, for reporting purpose through traces at the least. It just
> seemed like same reason code is being used for two different purpose
> of migration.

But do we have any real user asking for this kind of information?

-- 
Michal Hocko
SUSE Labs

Re: 4.15: WARNING: CPU: 3 PID: 258 at kernel/irq/chip.c:244 __irq_startup+0x80/0x100

[Thomas Gleixner]

On Wed, 31 Jan 2018, Meelis Roos wrote:
> > > Your supply of vintage hardware is amazing.
> 
> :-)
> 
> > Does the patch below fix the issue for you?
> 
>   CC  kernel/irq/autoprobe.o
> kernel/irq/autoprobe.c: In function ‘probe_irq_on’:
> kernel/irq/autoprobe.c:74:8: error: void value not ignored as it ought to be
> if (irq_activate_and_startup(desc, IRQ_NORESEND))
> ^~~~

Duh.

> Just 
> irq_activate_and_startup(desc, IRQ_NORESEND);

Indeed. 

> cures the warning and at least the first bootup was working otherwise 
> too.

I'll do a proper fix and queue it so your museum is kept alive.

Thanks,

tglx

Re: 4.15: WARNING: CPU: 3 PID: 258 at kernel/irq/chip.c:244 __irq_startup+0x80/0x100

[Thomas Gleixner]

On Wed, 31 Jan 2018, Meelis Roos wrote:
> > > Your supply of vintage hardware is amazing.
> 
> :-)
> 
> > Does the patch below fix the issue for you?
> 
>   CC  kernel/irq/autoprobe.o
> kernel/irq/autoprobe.c: In function ‘probe_irq_on’:
> kernel/irq/autoprobe.c:74:8: error: void value not ignored as it ought to be
> if (irq_activate_and_startup(desc, IRQ_NORESEND))
> ^~~~

Duh.

> Just 
> irq_activate_and_startup(desc, IRQ_NORESEND);

Indeed. 

> cures the warning and at least the first bootup was working otherwise 
> too.

I'll do a proper fix and queue it so your museum is kept alive.

Thanks,

tglx

[PATCH] powerpc/epapr: Move register keyword at the beginning of declaration

[Mathieu Malaterre]

Fix warning for all register unsigned long (0,3-12) that appear during W=1
compilation:

./arch/powerpc/include/asm/epapr_hcalls.h:479:2: warning: ‘register’ is not at 
beginning of declaration [-Wold-style-declaration]
  unsigned long register r[\d] asm("r[\d]");

Signed-off-by: Mathieu Malaterre 
---
 arch/powerpc/include/asm/epapr_hcalls.h | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/include/asm/epapr_hcalls.h 
b/arch/powerpc/include/asm/epapr_hcalls.h
index 90863245df53..d3a7e36f1402 100644
--- a/arch/powerpc/include/asm/epapr_hcalls.h
+++ b/arch/powerpc/include/asm/epapr_hcalls.h
@@ -466,17 +466,17 @@ static inline unsigned long epapr_hypercall(unsigned long 
*in,
unsigned long *out,
unsigned long nr)
 {
-   unsigned long register r0 asm("r0");
-   unsigned long register r3 asm("r3") = in[0];
-   unsigned long register r4 asm("r4") = in[1];
-   unsigned long register r5 asm("r5") = in[2];
-   unsigned long register r6 asm("r6") = in[3];
-   unsigned long register r7 asm("r7") = in[4];
-   unsigned long register r8 asm("r8") = in[5];
-   unsigned long register r9 asm("r9") = in[6];
-   unsigned long register r10 asm("r10") = in[7];
-   unsigned long register r11 asm("r11") = nr;
-   unsigned long register r12 asm("r12");
+   register unsigned long r0 asm("r0");
+   register unsigned long r3 asm("r3") = in[0];
+   register unsigned long r4 asm("r4") = in[1];
+   register unsigned long r5 asm("r5") = in[2];
+   register unsigned long r6 asm("r6") = in[3];
+   register unsigned long r7 asm("r7") = in[4];
+   register unsigned long r8 asm("r8") = in[5];
+   register unsigned long r9 asm("r9") = in[6];
+   register unsigned long r10 asm("r10") = in[7];
+   register unsigned long r11 asm("r11") = nr;
+   register unsigned long r12 asm("r12");
 
asm volatile("blepapr_hypercall_start"
 : "=r"(r0), "=r"(r3), "=r"(r4), "=r"(r5), "=r"(r6),
-- 
2.11.0

[PATCH] powerpc/epapr: Move register keyword at the beginning of declaration

[Mathieu Malaterre]

Fix warning for all register unsigned long (0,3-12) that appear during W=1
compilation:

./arch/powerpc/include/asm/epapr_hcalls.h:479:2: warning: ‘register’ is not at 
beginning of declaration [-Wold-style-declaration]
  unsigned long register r[\d] asm("r[\d]");

Signed-off-by: Mathieu Malaterre 
---
 arch/powerpc/include/asm/epapr_hcalls.h | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/include/asm/epapr_hcalls.h 
b/arch/powerpc/include/asm/epapr_hcalls.h
index 90863245df53..d3a7e36f1402 100644
--- a/arch/powerpc/include/asm/epapr_hcalls.h
+++ b/arch/powerpc/include/asm/epapr_hcalls.h
@@ -466,17 +466,17 @@ static inline unsigned long epapr_hypercall(unsigned long 
*in,
unsigned long *out,
unsigned long nr)
 {
-   unsigned long register r0 asm("r0");
-   unsigned long register r3 asm("r3") = in[0];
-   unsigned long register r4 asm("r4") = in[1];
-   unsigned long register r5 asm("r5") = in[2];
-   unsigned long register r6 asm("r6") = in[3];
-   unsigned long register r7 asm("r7") = in[4];
-   unsigned long register r8 asm("r8") = in[5];
-   unsigned long register r9 asm("r9") = in[6];
-   unsigned long register r10 asm("r10") = in[7];
-   unsigned long register r11 asm("r11") = nr;
-   unsigned long register r12 asm("r12");
+   register unsigned long r0 asm("r0");
+   register unsigned long r3 asm("r3") = in[0];
+   register unsigned long r4 asm("r4") = in[1];
+   register unsigned long r5 asm("r5") = in[2];
+   register unsigned long r6 asm("r6") = in[3];
+   register unsigned long r7 asm("r7") = in[4];
+   register unsigned long r8 asm("r8") = in[5];
+   register unsigned long r9 asm("r9") = in[6];
+   register unsigned long r10 asm("r10") = in[7];
+   register unsigned long r11 asm("r11") = nr;
+   register unsigned long r12 asm("r12");
 
asm volatile("blepapr_hypercall_start"
 : "=r"(r0), "=r"(r3), "=r"(r4), "=r"(r5), "=r"(r6),
-- 
2.11.0

Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Tomasz Figa]

Hi Rob,

On Wed, Jan 31, 2018 at 2:05 AM, Rob Herring  wrote:
> On Wed, Jan 24, 2018 at 06:35:11PM +0800, Jeffy Chen wrote:
>> From: Tomasz Figa 
>>
>> Current code relies on master driver enabling necessary clocks before
>> IOMMU is accessed, however there are cases when the IOMMU should be
>> accessed while the master is not running yet, for example allocating
>> V4L2 videobuf2 buffers, which is done by the VB2 framework using DMA
>> mapping API and doesn't engage the master driver at all.
>>
>> This patch fixes the problem by letting clocks needed for IOMMU
>> operation to be listed in Device Tree and making the driver enable them
>> for the time of accessing the hardware.
>>
>> Signed-off-by: Jeffy Chen 
>> Signed-off-by: Tomasz Figa 
>> ---
>>
>> Changes in v5:
>> Use clk_bulk APIs.
>>
>> Changes in v4: None
>> Changes in v3: None
>> Changes in v2: None
>>
>>  .../devicetree/bindings/iommu/rockchip,iommu.txt   |  8 +++
>
> Please split binding patches to a separate patch.
>
>>  drivers/iommu/rockchip-iommu.c | 74 
>> --
>>  2 files changed, 76 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt 
>> b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
>> index 2098f7732264..33dd853359fa 100644
>> --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
>> +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
>> @@ -14,6 +14,13 @@ Required properties:
>>  "single-master" device, and needs no additional 
>> information
>>  to associate with its master device.  See:
>>  Documentation/devicetree/bindings/iommu/iommu.txt
>> +Optional properties:
>> +- clocks : A list of master clocks requires for the IOMMU to be accessible
>> +   by the host CPU. The number of clocks depends on the master
>> +   block and might as well be zero. See [1] for generic clock
>> +   bindings description.
>
> Hardware blocks don't have a variable number of clock connections.

I think you underestimate the imagination of hardware designers. :)

For Rockchip IOMMU, there is a set of clocks, which all need to be
enabled for IOMMU register access to succeed. The clocks are not
directly fed to the IOMMU, but they are needed for the various buses
and intermediate blocks on the way to the IOMMU to work.

And the set varies based on next to which master block the IOMMU block
is located, because the hierarchy of buses and intermediate blocks is
different.

Best regards,
Tomasz

Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Tomasz Figa]

Hi Rob,

On Wed, Jan 31, 2018 at 2:05 AM, Rob Herring  wrote:
> On Wed, Jan 24, 2018 at 06:35:11PM +0800, Jeffy Chen wrote:
>> From: Tomasz Figa 
>>
>> Current code relies on master driver enabling necessary clocks before
>> IOMMU is accessed, however there are cases when the IOMMU should be
>> accessed while the master is not running yet, for example allocating
>> V4L2 videobuf2 buffers, which is done by the VB2 framework using DMA
>> mapping API and doesn't engage the master driver at all.
>>
>> This patch fixes the problem by letting clocks needed for IOMMU
>> operation to be listed in Device Tree and making the driver enable them
>> for the time of accessing the hardware.
>>
>> Signed-off-by: Jeffy Chen 
>> Signed-off-by: Tomasz Figa 
>> ---
>>
>> Changes in v5:
>> Use clk_bulk APIs.
>>
>> Changes in v4: None
>> Changes in v3: None
>> Changes in v2: None
>>
>>  .../devicetree/bindings/iommu/rockchip,iommu.txt   |  8 +++
>
> Please split binding patches to a separate patch.
>
>>  drivers/iommu/rockchip-iommu.c | 74 
>> --
>>  2 files changed, 76 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt 
>> b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
>> index 2098f7732264..33dd853359fa 100644
>> --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
>> +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
>> @@ -14,6 +14,13 @@ Required properties:
>>  "single-master" device, and needs no additional 
>> information
>>  to associate with its master device.  See:
>>  Documentation/devicetree/bindings/iommu/iommu.txt
>> +Optional properties:
>> +- clocks : A list of master clocks requires for the IOMMU to be accessible
>> +   by the host CPU. The number of clocks depends on the master
>> +   block and might as well be zero. See [1] for generic clock
>> +   bindings description.
>
> Hardware blocks don't have a variable number of clock connections.

I think you underestimate the imagination of hardware designers. :)

For Rockchip IOMMU, there is a set of clocks, which all need to be
enabled for IOMMU register access to succeed. The clocks are not
directly fed to the IOMMU, but they are needed for the various buses
and intermediate blocks on the way to the IOMMU to work.

And the set varies based on next to which master block the IOMMU block
is located, because the hierarchy of buses and intermediate blocks is
different.

Best regards,
Tomasz

Re: [RFC PATCH 0/8] [media] Request API, take three

[Hans Verkuil]

On 01/30/2018 07:31 AM, Alexandre Courbot wrote:
> Hi Hans,
> 
> On Mon, Jan 29, 2018 at 8:21 PM, Hans Verkuil  wrote:
>> On 01/26/2018 07:02 AM, Alexandre Courbot wrote:
>>> Howdy. Here is your bi-weekly request API redesign! ;)
>>>
>>> Again, this is a simple version that only implements the flow of requests,
>>> without applying controls. The intent is to get an agreement on a base to 
>>> work
>>> on, since the previous versions went straight back to the redesign board.
>>>
>>> Highlights of this version:
>>>
>>> * As requested by Hans, request-bound buffers are now passed earlier to 
>>> drivers,
>>> as early as the request itself is submitted. Doing it earlier is not be 
>>> useful
>>> since the driver would not know the state of the request, and thus cannot do
>>> anything with the buffer. Drivers are now responsible for applying request
>>> parameters themselves.
>>>
>>> * As a consequence, there is no such thing as a "request queue" anymore. The
>>> flow of buffers decides the order in which requests are processed. 
>>> Individual
>>> devices of the same pipeline can implement synchronization if needed, but 
>>> this
>>> is beyond this first version.
>>>
>>> * VB2 code is still a bit shady. Some of it will interfere with the fences
>>> series, so I am waiting for the latter to land to do it properly.
>>>
>>> * Requests that are not yet submitted effectively act as fences on the 
>>> buffers
>>> they own, resulting in the buffer queue being blocked until the request is
>>> submitted. An alternate design would be to only block the
>>> not-submitted-request's buffer and let further buffers pass before it, but 
>>> since
>>> buffer order is becoming increasingly important I have decided to just 
>>> block the
>>> queue. This is open to discussion though.
>>
>> I don't think we should mess with the order.
> 
> Agreed, let's keep it that way then.
> 
>>
>>>
>>> * Documentation! Also described usecases for codec and simple (i.e. not 
>>> part of
>>> a complex pipeline) capture device.
>>
>> I'll concentrate on reviewing that.
>>
>>>
>>> Still remaining to do:
>>>
>>> * As pointed out by Hans on the previous revision, do not assume that 
>>> drivers
>>> using v4l2_fh have a per-handle state. I have not yet found a good way to
>>> differenciate both usages.
>>
>> I suspect we need to add a flag or something for this.
> 
> I hope we don't need to, let's see if I can find a pattern...
> 
>>
>>> * Integrate Hans' patchset for control handling: as said above, this is 
>>> futile
>>> unless we can agree on the basic design, which I hope we can do this time.
>>> Chrome OS needs this really badly now and will have to move forward no 
>>> matter
>>> what, so I hope this will be considered good enough for a common base of 
>>> work.
>>
>> I am not sure there is any reason to not move forward with the control 
>> handling.
>> You need this anyway IMHO, regardless of any public API considerations.
> 
> Only reasons are my lazyness and because I wanted to focus on the
> request flow first. But you're right. I have a version with your
> control framework changes integrated (they worked on the first attempt
> btw! :)), let me create a clean patchset from this and send another
> RFC.

Scary that it worked on the first attempt :-)

> 
>>
>>> A few thoughts/questions that emerged when writing this patchset:
>>>
>>> * Since requests are exposed as file descriptors, we could easily move the
>>> MEDIA_REQ_CMD_SUBMIT and MEDIA_REQ_CMD_REININT commands as ioctls on the
>>> requests themselves, instead of having to perform them on the media device 
>>> that
>>> provided the request in the first place. That would add a bit more 
>>> flexibility
>>> if/when passing requests around and means the media device only needs to 
>>> handle
>>> MEDIA_REQ_CMD_ALLOC. Conceptually speaking, this seems to make sense to me.
>>> Any comment for/against that?
>>
>> Makes sense IMHO.
> 
> Glad to hear it, that was my preferred design. :)
> 
>>
>>> * For the codec usecase, I have experimented a bit marking CAPTURE buffers 
>>> with
>>> the request FD that produced them (vim2m acts that way). This seems to work
>>> well, however FDs are process-local and could be closed before the CAPTURE
>>> buffer is dequeued, rendering that information less meaningful, if not
>>> dangerous.
>>
>> I don't follow this. Once the fd is passed to the kernel its refcount should 
>> be
>> increased so the data it represents won't be released if userspace closes 
>> the fd.
> 
> The refcount of the request is increased. The refcount of the FD is
> not, since it is only a userspace reference to the request.

I don't think that's right. Looking at how dma-buf does this (dma_buf_get in
dma-buf.c) it calls fget(fd) which increases the fd refcount. In fact, as far as
I can see the struct dma_buf doesn't have a refcount, it is solely refcounted
through the fd. That's probably the model you want to follow.

> 
>>
>> Obviously if userspace closes the fd it 

Re: [RFC PATCH 0/8] [media] Request API, take three

[Hans Verkuil]

On 01/30/2018 07:31 AM, Alexandre Courbot wrote:
> Hi Hans,
> 
> On Mon, Jan 29, 2018 at 8:21 PM, Hans Verkuil  wrote:
>> On 01/26/2018 07:02 AM, Alexandre Courbot wrote:
>>> Howdy. Here is your bi-weekly request API redesign! ;)
>>>
>>> Again, this is a simple version that only implements the flow of requests,
>>> without applying controls. The intent is to get an agreement on a base to 
>>> work
>>> on, since the previous versions went straight back to the redesign board.
>>>
>>> Highlights of this version:
>>>
>>> * As requested by Hans, request-bound buffers are now passed earlier to 
>>> drivers,
>>> as early as the request itself is submitted. Doing it earlier is not be 
>>> useful
>>> since the driver would not know the state of the request, and thus cannot do
>>> anything with the buffer. Drivers are now responsible for applying request
>>> parameters themselves.
>>>
>>> * As a consequence, there is no such thing as a "request queue" anymore. The
>>> flow of buffers decides the order in which requests are processed. 
>>> Individual
>>> devices of the same pipeline can implement synchronization if needed, but 
>>> this
>>> is beyond this first version.
>>>
>>> * VB2 code is still a bit shady. Some of it will interfere with the fences
>>> series, so I am waiting for the latter to land to do it properly.
>>>
>>> * Requests that are not yet submitted effectively act as fences on the 
>>> buffers
>>> they own, resulting in the buffer queue being blocked until the request is
>>> submitted. An alternate design would be to only block the
>>> not-submitted-request's buffer and let further buffers pass before it, but 
>>> since
>>> buffer order is becoming increasingly important I have decided to just 
>>> block the
>>> queue. This is open to discussion though.
>>
>> I don't think we should mess with the order.
> 
> Agreed, let's keep it that way then.
> 
>>
>>>
>>> * Documentation! Also described usecases for codec and simple (i.e. not 
>>> part of
>>> a complex pipeline) capture device.
>>
>> I'll concentrate on reviewing that.
>>
>>>
>>> Still remaining to do:
>>>
>>> * As pointed out by Hans on the previous revision, do not assume that 
>>> drivers
>>> using v4l2_fh have a per-handle state. I have not yet found a good way to
>>> differenciate both usages.
>>
>> I suspect we need to add a flag or something for this.
> 
> I hope we don't need to, let's see if I can find a pattern...
> 
>>
>>> * Integrate Hans' patchset for control handling: as said above, this is 
>>> futile
>>> unless we can agree on the basic design, which I hope we can do this time.
>>> Chrome OS needs this really badly now and will have to move forward no 
>>> matter
>>> what, so I hope this will be considered good enough for a common base of 
>>> work.
>>
>> I am not sure there is any reason to not move forward with the control 
>> handling.
>> You need this anyway IMHO, regardless of any public API considerations.
> 
> Only reasons are my lazyness and because I wanted to focus on the
> request flow first. But you're right. I have a version with your
> control framework changes integrated (they worked on the first attempt
> btw! :)), let me create a clean patchset from this and send another
> RFC.

Scary that it worked on the first attempt :-)

> 
>>
>>> A few thoughts/questions that emerged when writing this patchset:
>>>
>>> * Since requests are exposed as file descriptors, we could easily move the
>>> MEDIA_REQ_CMD_SUBMIT and MEDIA_REQ_CMD_REININT commands as ioctls on the
>>> requests themselves, instead of having to perform them on the media device 
>>> that
>>> provided the request in the first place. That would add a bit more 
>>> flexibility
>>> if/when passing requests around and means the media device only needs to 
>>> handle
>>> MEDIA_REQ_CMD_ALLOC. Conceptually speaking, this seems to make sense to me.
>>> Any comment for/against that?
>>
>> Makes sense IMHO.
> 
> Glad to hear it, that was my preferred design. :)
> 
>>
>>> * For the codec usecase, I have experimented a bit marking CAPTURE buffers 
>>> with
>>> the request FD that produced them (vim2m acts that way). This seems to work
>>> well, however FDs are process-local and could be closed before the CAPTURE
>>> buffer is dequeued, rendering that information less meaningful, if not
>>> dangerous.
>>
>> I don't follow this. Once the fd is passed to the kernel its refcount should 
>> be
>> increased so the data it represents won't be released if userspace closes 
>> the fd.
> 
> The refcount of the request is increased. The refcount of the FD is
> not, since it is only a userspace reference to the request.

I don't think that's right. Looking at how dma-buf does this (dma_buf_get in
dma-buf.c) it calls fget(fd) which increases the fd refcount. In fact, as far as
I can see the struct dma_buf doesn't have a refcount, it is solely refcounted
through the fd. That's probably the model you want to follow.

> 
>>
>> Obviously if userspace closes the fd it cannot do anything 

Re: [PATCH v2] MIPS: fix incorrect mem=X@Y handling

[Mathieu Malaterre]

Hi Marcin,

Since it's been a week, could you confirm the patch is ok as-is or do
you think some comment(s) from James should be incorporated ?

On Tue, Jan 23, 2018 at 3:17 PM, James Hogan  wrote:
> On Thu, Dec 21, 2017 at 10:00:59PM +0100, Mathieu Malaterre wrote:
>> From: Marcin Nowakowski 
>>
>> Change 73fbc1eba7ff added a fix to ensure that the memory range between
>
> Please refer to commits with e.g. commit 73fbc1eba7ff ("MIPS: fix
> mem=X@Y commandline processing").
>
>> PHYS_OFFSET and low memory address specified by mem= cmdline argument is
>> not later processed by free_all_bootmem.
>> This change was incorrect for systems where the commandline specifies
>> more than 1 mem argument, as it will cause all memory between
>> PHYS_OFFSET and each of the memory offsets to be marked as reserved,
>> which results in parts of the RAM marked as reserved (Creator CI20's
>> u-boot has a default commandline argument 'mem=256M@0x0
>> mem=768M@0x3000').
>>
>> Change the behaviour to ensure that only the range between PHYS_OFFSET
>> and the lowest start address of the memories is marked as protected.
>>
>> This change also ensures that the range is marked protected even if it's
>> only defined through the devicetree and not only via commandline
>> arguments.
>>
>> Reported-by: Mathieu Malaterre 
>> Signed-off-by: Marcin Nowakowski 
>> Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing")
>> Cc:  # v4.11
>
> I'm guessing that should technically be v4.11+

My fault, if this is the only change, I can re-submit.

>> ---
>> v2: Use updated email adress, add tag for stable.
>>  arch/mips/kernel/setup.c | 19 ---
>>  1 file changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
>> index 702c678de116..f19d61224c71 100644
>> --- a/arch/mips/kernel/setup.c
>> +++ b/arch/mips/kernel/setup.c
>> @@ -375,6 +375,7 @@ static void __init bootmem_init(void)
>>   unsigned long reserved_end;
>>   unsigned long mapstart = ~0UL;
>>   unsigned long bootmap_size;
>> + phys_addr_t ramstart = ~0UL;
>
> Although practically it might not matter, technically phys_addr_t may be
> 64-bits (CONFIG_PHYS_ADDR_T_64BIT) even on a 32-bit kernels, in which
> case ~0UL may not be sufficiently large.
>
> Maybe that should be ~(phys_addr_t)0, or perhaps (phys_addr_t)ULLONG_MAX
> to match add_memory_region().
>
>>   bool bootmap_valid = false;
>>   int i;
>>
>> @@ -395,6 +396,21 @@ static void __init bootmem_init(void)
>>   max_low_pfn = 0;
>>
>>   /*
>> +  * Reserve any memory between the start of RAM and PHYS_OFFSET
>> +  */
>> + for (i = 0; i < boot_mem_map.nr_map; i++) {
>> + if (boot_mem_map.map[i].type != BOOT_MEM_RAM)
>> + continue;
>> +
>> + ramstart = min(ramstart, boot_mem_map.map[i].addr);
>
> Is it worth incorporating this into the existing loop below ...
>
>> + }
>> +
>> + if (ramstart > PHYS_OFFSET)
>> + add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
>> +   BOOT_MEM_RESERVED);
>
> ... and this then placed below that loop?
>
> Otherwise I can't find fault with this patch, though i'm not intimately
> familiar with bootmem.
>
> Cheers
> James
>
>> +
>> +
>> + /*
>>* Find the highest page frame number we have available.
>>*/
>>   for (i = 0; i < boot_mem_map.nr_map; i++) {
>> @@ -664,9 +680,6 @@ static int __init early_parse_mem(char *p)
>>
>>   add_memory_region(start, size, BOOT_MEM_RAM);
>>
>> - if (start && start > PHYS_OFFSET)
>> - add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
>> - BOOT_MEM_RESERVED);
>>   return 0;
>>  }
>>  early_param("mem", early_parse_mem);
>> --
>> 2.11.0
>>

Re: [PATCH v2] MIPS: fix incorrect mem=X@Y handling

[Mathieu Malaterre]

Hi Marcin,

Since it's been a week, could you confirm the patch is ok as-is or do
you think some comment(s) from James should be incorporated ?

On Tue, Jan 23, 2018 at 3:17 PM, James Hogan  wrote:
> On Thu, Dec 21, 2017 at 10:00:59PM +0100, Mathieu Malaterre wrote:
>> From: Marcin Nowakowski 
>>
>> Change 73fbc1eba7ff added a fix to ensure that the memory range between
>
> Please refer to commits with e.g. commit 73fbc1eba7ff ("MIPS: fix
> mem=X@Y commandline processing").
>
>> PHYS_OFFSET and low memory address specified by mem= cmdline argument is
>> not later processed by free_all_bootmem.
>> This change was incorrect for systems where the commandline specifies
>> more than 1 mem argument, as it will cause all memory between
>> PHYS_OFFSET and each of the memory offsets to be marked as reserved,
>> which results in parts of the RAM marked as reserved (Creator CI20's
>> u-boot has a default commandline argument 'mem=256M@0x0
>> mem=768M@0x3000').
>>
>> Change the behaviour to ensure that only the range between PHYS_OFFSET
>> and the lowest start address of the memories is marked as protected.
>>
>> This change also ensures that the range is marked protected even if it's
>> only defined through the devicetree and not only via commandline
>> arguments.
>>
>> Reported-by: Mathieu Malaterre 
>> Signed-off-by: Marcin Nowakowski 
>> Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing")
>> Cc:  # v4.11
>
> I'm guessing that should technically be v4.11+

My fault, if this is the only change, I can re-submit.

>> ---
>> v2: Use updated email adress, add tag for stable.
>>  arch/mips/kernel/setup.c | 19 ---
>>  1 file changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
>> index 702c678de116..f19d61224c71 100644
>> --- a/arch/mips/kernel/setup.c
>> +++ b/arch/mips/kernel/setup.c
>> @@ -375,6 +375,7 @@ static void __init bootmem_init(void)
>>   unsigned long reserved_end;
>>   unsigned long mapstart = ~0UL;
>>   unsigned long bootmap_size;
>> + phys_addr_t ramstart = ~0UL;
>
> Although practically it might not matter, technically phys_addr_t may be
> 64-bits (CONFIG_PHYS_ADDR_T_64BIT) even on a 32-bit kernels, in which
> case ~0UL may not be sufficiently large.
>
> Maybe that should be ~(phys_addr_t)0, or perhaps (phys_addr_t)ULLONG_MAX
> to match add_memory_region().
>
>>   bool bootmap_valid = false;
>>   int i;
>>
>> @@ -395,6 +396,21 @@ static void __init bootmem_init(void)
>>   max_low_pfn = 0;
>>
>>   /*
>> +  * Reserve any memory between the start of RAM and PHYS_OFFSET
>> +  */
>> + for (i = 0; i < boot_mem_map.nr_map; i++) {
>> + if (boot_mem_map.map[i].type != BOOT_MEM_RAM)
>> + continue;
>> +
>> + ramstart = min(ramstart, boot_mem_map.map[i].addr);
>
> Is it worth incorporating this into the existing loop below ...
>
>> + }
>> +
>> + if (ramstart > PHYS_OFFSET)
>> + add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
>> +   BOOT_MEM_RESERVED);
>
> ... and this then placed below that loop?
>
> Otherwise I can't find fault with this patch, though i'm not intimately
> familiar with bootmem.
>
> Cheers
> James
>
>> +
>> +
>> + /*
>>* Find the highest page frame number we have available.
>>*/
>>   for (i = 0; i < boot_mem_map.nr_map; i++) {
>> @@ -664,9 +680,6 @@ static int __init early_parse_mem(char *p)
>>
>>   add_memory_region(start, size, BOOT_MEM_RAM);
>>
>> - if (start && start > PHYS_OFFSET)
>> - add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
>> - BOOT_MEM_RESERVED);
>>   return 0;
>>  }
>>  early_param("mem", early_parse_mem);
>> --
>> 2.11.0
>>

[PATCH v2 2/5] clk: mediatek: modify MT7622 audsys to adapt MFD device

[Ryder Lee]

As the new MFD parent is in place, switch probing method to adapt it.

Signed-off-by: Ryder Lee 
---
 drivers/clk/mediatek/clk-mt7622-aud.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c 
b/drivers/clk/mediatek/clk-mt7622-aud.c
index 13f752d..8c18536 100644
--- a/drivers/clk/mediatek/clk-mt7622-aud.c
+++ b/drivers/clk/mediatek/clk-mt7622-aud.c
@@ -142,11 +142,12 @@ static int clk_mt7622_audiosys_init(struct 
platform_device *pdev)
 {
struct clk_onecell_data *clk_data;
struct device_node *node = pdev->dev.of_node;
+   struct device_node *pnode = pdev->dev.parent->of_node;
int r;
 
clk_data = mtk_alloc_clk_data(CLK_AUDIO_NR_CLK);
 
-   mtk_clk_register_gates(node, audio_clks, ARRAY_SIZE(audio_clks),
+   mtk_clk_register_gates(pnode, audio_clks, ARRAY_SIZE(audio_clks),
   clk_data);
 
r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
-- 
1.9.1

[PATCH v2 2/5] clk: mediatek: modify MT7622 audsys to adapt MFD device

[Ryder Lee]

As the new MFD parent is in place, switch probing method to adapt it.

Signed-off-by: Ryder Lee 
---
 drivers/clk/mediatek/clk-mt7622-aud.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c 
b/drivers/clk/mediatek/clk-mt7622-aud.c
index 13f752d..8c18536 100644
--- a/drivers/clk/mediatek/clk-mt7622-aud.c
+++ b/drivers/clk/mediatek/clk-mt7622-aud.c
@@ -142,11 +142,12 @@ static int clk_mt7622_audiosys_init(struct 
platform_device *pdev)
 {
struct clk_onecell_data *clk_data;
struct device_node *node = pdev->dev.of_node;
+   struct device_node *pnode = pdev->dev.parent->of_node;
int r;
 
clk_data = mtk_alloc_clk_data(CLK_AUDIO_NR_CLK);
 
-   mtk_clk_register_gates(node, audio_clks, ARRAY_SIZE(audio_clks),
+   mtk_clk_register_gates(pnode, audio_clks, ARRAY_SIZE(audio_clks),
   clk_data);
 
r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
-- 
1.9.1

[PATCH v2 0/5] add MFD support for MediaTek audio subsystem

[Ryder Lee]

Hi,

This is the 2nd version of the patch sets which modify clock driver to adapt
audio subsystem.  I still keeping 'simple-mfd' in the binding for discussion.
Rob, let me know if there is any problem with this.

changes since v2:
 - Drop useless changes in clk-mt7622-aud.c.
 - Revise binding text: 
- Add more information about audio subsystem.
- Separate clock node and AFE node.
 - Update license header.
changes since v1:
 - To avoid writing an MFD driver, we add "simple-mfd" in the audsys binding.
 - Move three top clocks to audio driver [1] as we remove mfd/mtk-audsys.c in 
v1.

Ryder Lee (5):
  clk: mediatek: update missing clock data for MT7622 audsys
  clk: mediatek: modify MT7622 audsys to adapt MFD device
  clk: mediatek: add audsys support for MT2701
  dt-bindings: clock: mediatek: update audsys documentation to adapt MFD
device
  arm: dts: mediatek: add audio-subsystem node for both MT2701 and
MT7623

 .../bindings/arm/mediatek/mediatek,audsys.txt  |  37 +++-
 arch/arm/boot/dts/mt2701.dtsi  | 192 ++--
 arch/arm/boot/dts/mt7623.dtsi  | 193 ++---
 drivers/clk/mediatek/Kconfig   |   6 +
 drivers/clk/mediatek/Makefile  |   1 +
 drivers/clk/mediatek/clk-mt2701-aud.c  | 175 +++
 drivers/clk/mediatek/clk-mt7622-aud.c  |   4 +-
 include/dt-bindings/clock/mt7622-clk.h |   3 +-
 8 files changed, 406 insertions(+), 205 deletions(-)
 create mode 100644 drivers/clk/mediatek/clk-mt2701-aud.c

-- 
1.9.1

[PATCH v2 0/5] add MFD support for MediaTek audio subsystem

[Ryder Lee]

Hi,

This is the 2nd version of the patch sets which modify clock driver to adapt
audio subsystem.  I still keeping 'simple-mfd' in the binding for discussion.
Rob, let me know if there is any problem with this.

changes since v2:
 - Drop useless changes in clk-mt7622-aud.c.
 - Revise binding text: 
- Add more information about audio subsystem.
- Separate clock node and AFE node.
 - Update license header.
changes since v1:
 - To avoid writing an MFD driver, we add "simple-mfd" in the audsys binding.
 - Move three top clocks to audio driver [1] as we remove mfd/mtk-audsys.c in 
v1.

Ryder Lee (5):
  clk: mediatek: update missing clock data for MT7622 audsys
  clk: mediatek: modify MT7622 audsys to adapt MFD device
  clk: mediatek: add audsys support for MT2701
  dt-bindings: clock: mediatek: update audsys documentation to adapt MFD
device
  arm: dts: mediatek: add audio-subsystem node for both MT2701 and
MT7623

 .../bindings/arm/mediatek/mediatek,audsys.txt  |  37 +++-
 arch/arm/boot/dts/mt2701.dtsi  | 192 ++--
 arch/arm/boot/dts/mt7623.dtsi  | 193 ++---
 drivers/clk/mediatek/Kconfig   |   6 +
 drivers/clk/mediatek/Makefile  |   1 +
 drivers/clk/mediatek/clk-mt2701-aud.c  | 175 +++
 drivers/clk/mediatek/clk-mt7622-aud.c  |   4 +-
 include/dt-bindings/clock/mt7622-clk.h |   3 +-
 8 files changed, 406 insertions(+), 205 deletions(-)
 create mode 100644 drivers/clk/mediatek/clk-mt2701-aud.c

-- 
1.9.1

[PATCH v2 1/5] clk: mediatek: update missing clock data for MT7622 audsys

[Ryder Lee]

Add missing clock data 'CLK_AUDIO_AFE_CONN' for MT7622 audsys.

Signed-off-by: Ryder Lee 
---
 drivers/clk/mediatek/clk-mt7622-aud.c  | 1 +
 include/dt-bindings/clock/mt7622-clk.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c 
b/drivers/clk/mediatek/clk-mt7622-aud.c
index fad7d9f..13f752d 100644
--- a/drivers/clk/mediatek/clk-mt7622-aud.c
+++ b/drivers/clk/mediatek/clk-mt7622-aud.c
@@ -106,6 +106,7 @@
GATE_AUDIO1(CLK_AUDIO_INTDIR, "audio_intdir", "intdir_sel", 20),
GATE_AUDIO1(CLK_AUDIO_A1SYS, "audio_a1sys", "a1sys_hp_sel", 21),
GATE_AUDIO1(CLK_AUDIO_A2SYS, "audio_a2sys", "a2sys_hp_sel", 22),
+   GATE_AUDIO1(CLK_AUDIO_AFE_CONN, "audio_afe_conn", "a1sys_hp_sel", 23),
/* AUDIO2 */
GATE_AUDIO2(CLK_AUDIO_UL1, "audio_ul1", "a1sys_hp_sel", 0),
GATE_AUDIO2(CLK_AUDIO_UL2, "audio_ul2", "a1sys_hp_sel", 1),
diff --git a/include/dt-bindings/clock/mt7622-clk.h 
b/include/dt-bindings/clock/mt7622-clk.h
index 3e514ed..e9d77f0 100644
--- a/include/dt-bindings/clock/mt7622-clk.h
+++ b/include/dt-bindings/clock/mt7622-clk.h
@@ -235,7 +235,8 @@
 #define CLK_AUDIO_MEM_ASRC343
 #define CLK_AUDIO_MEM_ASRC444
 #define CLK_AUDIO_MEM_ASRC545
-#define CLK_AUDIO_NR_CLK   46
+#define CLK_AUDIO_AFE_CONN 46
+#define CLK_AUDIO_NR_CLK   47
 
 /* SSUSBSYS */
 
-- 
1.9.1

[PATCH v2 1/5] clk: mediatek: update missing clock data for MT7622 audsys

[Ryder Lee]

Add missing clock data 'CLK_AUDIO_AFE_CONN' for MT7622 audsys.

Signed-off-by: Ryder Lee 
---
 drivers/clk/mediatek/clk-mt7622-aud.c  | 1 +
 include/dt-bindings/clock/mt7622-clk.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c 
b/drivers/clk/mediatek/clk-mt7622-aud.c
index fad7d9f..13f752d 100644
--- a/drivers/clk/mediatek/clk-mt7622-aud.c
+++ b/drivers/clk/mediatek/clk-mt7622-aud.c
@@ -106,6 +106,7 @@
GATE_AUDIO1(CLK_AUDIO_INTDIR, "audio_intdir", "intdir_sel", 20),
GATE_AUDIO1(CLK_AUDIO_A1SYS, "audio_a1sys", "a1sys_hp_sel", 21),
GATE_AUDIO1(CLK_AUDIO_A2SYS, "audio_a2sys", "a2sys_hp_sel", 22),
+   GATE_AUDIO1(CLK_AUDIO_AFE_CONN, "audio_afe_conn", "a1sys_hp_sel", 23),
/* AUDIO2 */
GATE_AUDIO2(CLK_AUDIO_UL1, "audio_ul1", "a1sys_hp_sel", 0),
GATE_AUDIO2(CLK_AUDIO_UL2, "audio_ul2", "a1sys_hp_sel", 1),
diff --git a/include/dt-bindings/clock/mt7622-clk.h 
b/include/dt-bindings/clock/mt7622-clk.h
index 3e514ed..e9d77f0 100644
--- a/include/dt-bindings/clock/mt7622-clk.h
+++ b/include/dt-bindings/clock/mt7622-clk.h
@@ -235,7 +235,8 @@
 #define CLK_AUDIO_MEM_ASRC343
 #define CLK_AUDIO_MEM_ASRC444
 #define CLK_AUDIO_MEM_ASRC545
-#define CLK_AUDIO_NR_CLK   46
+#define CLK_AUDIO_AFE_CONN 46
+#define CLK_AUDIO_NR_CLK   47
 
 /* SSUSBSYS */
 
-- 
1.9.1

[PATCH v4] Fix loading of module radeonfb on PowerMac

[Mathieu Malaterre]

When the linux kernel is build with (typical kernel ship with Debian
installer):

CONFIG_FB_OF=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_FB_RADEON=m

The offb driver takes precedence over module radeonfb. It is then
impossible to load the module, error reported is:

[   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
[   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
0x9800-0x9fff pref]
[   96.551531] radeonfb (:00:10.0): cannot request region 0.
[   96.551545] radeonfb: probe of :00:10.0 failed with error -16

This patch reproduce the behavior of the module radeon, so as to make it
possible to load radeonfb when offb is first loaded, see commit a56f7428d753
("drm/radeon: Add early unregister of firmware fb's").

It should be noticed that `offb_destroy` is never called which explain the
need to skip error detection on the radeon side.

Signed-off-by: Mathieu Malaterre 
Link: https://bugs.debian.org/826629#57
Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
Suggested-by: Lennart Sorensen 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Benjamin Herrenschmidt 
Cc: Tomi Valkeinen 
---
v2: Only fails when CONFIG_PCC is not set
v3: Only fails when CONFIG_FB_OF is not set, CONFIG_PCC was too broad. Since 
the conflicts in region is due to OFfb explicitly refers to it.
v4: Use drm_fb_helper_remove_conflicting_framebuffers from drm_fb_helper

 drivers/video/fbdev/aty/radeon_base.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/video/fbdev/aty/radeon_base.c 
b/drivers/video/fbdev/aty/radeon_base.c
index 4d77daeecf99..ae669f424537 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -70,6 +70,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -2259,6 +2260,23 @@ static const struct bin_attribute edid2_attr = {
.read   = radeon_show_edid2,
 };
 
+static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+   struct apertures_struct *ap;
+
+   ap = alloc_apertures(1);
+   if (!ap)
+   return -ENOMEM;
+
+   ap->ranges[0].base = pci_resource_start(pdev, 0);
+   ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+   drm_fb_helper_remove_conflicting_framebuffers(ap, KBUILD_MODNAME, 
false);
+
+   kfree(ap);
+
+   return 0;
+}
 
 static int radeonfb_pci_register(struct pci_dev *pdev,
 const struct pci_device_id *ent)
@@ -2312,19 +2330,27 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
rinfo->fb_base_phys = pci_resource_start (pdev, 0);
rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
 
+   ret = radeon_kick_out_firmware_fb(pdev);
+   if (ret)
+   return ret;
+
/* request the mem regions */
ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
if (ret < 0) {
+#ifndef CONFIG_FB_OF
printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
pci_name(rinfo->pdev));
goto err_release_fb;
+#endif
}
 
ret = pci_request_region(pdev, 2, "radeonfb mmio");
if (ret < 0) {
+#ifndef CONFIG_FB_OF
printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
pci_name(rinfo->pdev));
goto err_release_pci0;
+#endif
}
 
/* map the regions */
@@ -2509,10 +2535,12 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
iounmap(rinfo->mmio_base);
 err_release_pci2:
pci_release_region(pdev, 2);
+#ifndef CONFIG_FB_OF
 err_release_pci0:
pci_release_region(pdev, 0);
 err_release_fb:
 framebuffer_release(info);
+#endif
 err_disable:
 err_out:
return ret;
-- 
2.11.0

[PATCH v4] Fix loading of module radeonfb on PowerMac

[Mathieu Malaterre]

When the linux kernel is build with (typical kernel ship with Debian
installer):

CONFIG_FB_OF=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_FB_RADEON=m

The offb driver takes precedence over module radeonfb. It is then
impossible to load the module, error reported is:

[   96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
[   96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem 
0x9800-0x9fff pref]
[   96.551531] radeonfb (:00:10.0): cannot request region 0.
[   96.551545] radeonfb: probe of :00:10.0 failed with error -16

This patch reproduce the behavior of the module radeon, so as to make it
possible to load radeonfb when offb is first loaded, see commit a56f7428d753
("drm/radeon: Add early unregister of firmware fb's").

It should be noticed that `offb_destroy` is never called which explain the
need to skip error detection on the radeon side.

Signed-off-by: Mathieu Malaterre 
Link: https://bugs.debian.org/826629#57
Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
Suggested-by: Lennart Sorensen 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Benjamin Herrenschmidt 
Cc: Tomi Valkeinen 
---
v2: Only fails when CONFIG_PCC is not set
v3: Only fails when CONFIG_FB_OF is not set, CONFIG_PCC was too broad. Since 
the conflicts in region is due to OFfb explicitly refers to it.
v4: Use drm_fb_helper_remove_conflicting_framebuffers from drm_fb_helper

 drivers/video/fbdev/aty/radeon_base.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/video/fbdev/aty/radeon_base.c 
b/drivers/video/fbdev/aty/radeon_base.c
index 4d77daeecf99..ae669f424537 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -70,6 +70,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -2259,6 +2260,23 @@ static const struct bin_attribute edid2_attr = {
.read   = radeon_show_edid2,
 };
 
+static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+   struct apertures_struct *ap;
+
+   ap = alloc_apertures(1);
+   if (!ap)
+   return -ENOMEM;
+
+   ap->ranges[0].base = pci_resource_start(pdev, 0);
+   ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+   drm_fb_helper_remove_conflicting_framebuffers(ap, KBUILD_MODNAME, 
false);
+
+   kfree(ap);
+
+   return 0;
+}
 
 static int radeonfb_pci_register(struct pci_dev *pdev,
 const struct pci_device_id *ent)
@@ -2312,19 +2330,27 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
rinfo->fb_base_phys = pci_resource_start (pdev, 0);
rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
 
+   ret = radeon_kick_out_firmware_fb(pdev);
+   if (ret)
+   return ret;
+
/* request the mem regions */
ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
if (ret < 0) {
+#ifndef CONFIG_FB_OF
printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
pci_name(rinfo->pdev));
goto err_release_fb;
+#endif
}
 
ret = pci_request_region(pdev, 2, "radeonfb mmio");
if (ret < 0) {
+#ifndef CONFIG_FB_OF
printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
pci_name(rinfo->pdev));
goto err_release_pci0;
+#endif
}
 
/* map the regions */
@@ -2509,10 +2535,12 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
iounmap(rinfo->mmio_base);
 err_release_pci2:
pci_release_region(pdev, 2);
+#ifndef CONFIG_FB_OF
 err_release_pci0:
pci_release_region(pdev, 0);
 err_release_fb:
 framebuffer_release(info);
+#endif
 err_disable:
 err_out:
return ret;
-- 
2.11.0

[PATCH v2 4/5] dt-bindings: clock: mediatek: update audsys documentation to adapt MFD device

[Ryder Lee]

As the MediaTek audio hardware block that expose functionalities that are
handled by separate subsystems in the kernel, and there are registers that
are shared between related drivers.

Switch the current device to an MFD device, add more descriptions about the
subsystem and modify example accordingly.

Signed-off-by: Ryder Lee 
---
 .../bindings/arm/mediatek/mediatek,audsys.txt  | 37 ++
 1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
index 9b8f578..677af40 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
@@ -1,22 +1,45 @@
-MediaTek AUDSYS controller
+MediaTek Audio Subsystem
 
+The audio subsystem is one of the multi-function blocks of MediaTek SoCs.
+It contains a system controller, which provides a number registers giving
+access to two features: AUDSYS clocks and Audio Front End (AFE) components.
 
+For the top level node:
+- compatible: must be: "syscon", "simple-mfd";
+- reg: register area of the Audio Subsystem
+
+Required sub-nodes:
+
+AUDSYS clocks:
+---
 The MediaTek AUDSYS controller provides various clocks to the system.
 
 Required Properties:
 
 - compatible: Should be one of:
-   - "mediatek,mt7622-audsys", "syscon"
+   - "mediatek,mt2701-audsys";
+   - "mediatek,mt7622-audsys";
 - #clock-cells: Must be 1
 
 The AUDSYS controller uses the common clk binding from
 Documentation/devicetree/bindings/clock/clock-bindings.txt
 The available clocks are defined in dt-bindings/clock/mt*-clk.h.
 
+AFE components:
+---
+For common binding part and usage, refer to
+../sonud/mt2701-afe-pcm.txt.
+
 Example:
 
-audsys: audsys@1122 {
-   compatible = "mediatek,mt7622-audsys", "syscon";
-   reg = <0 0x1122 0 0x1000>;
-   #clock-cells = <1>;
-};
+   audio-subsystem@1122 {
+   compatible = "syscon", "simple-mfd";
+   reg = <0 0x1122 0 0x2000>;
+
+   audsys: clock {
+   compatible = "mediatek,mt2701-audsys";
+   #clock-cells = <1>;
+   };
+
+   ...
+   };
-- 
1.9.1

[PATCH v2 4/5] dt-bindings: clock: mediatek: update audsys documentation to adapt MFD device

[Ryder Lee]

As the MediaTek audio hardware block that expose functionalities that are
handled by separate subsystems in the kernel, and there are registers that
are shared between related drivers.

Switch the current device to an MFD device, add more descriptions about the
subsystem and modify example accordingly.

Signed-off-by: Ryder Lee 
---
 .../bindings/arm/mediatek/mediatek,audsys.txt  | 37 ++
 1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
index 9b8f578..677af40 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
@@ -1,22 +1,45 @@
-MediaTek AUDSYS controller
+MediaTek Audio Subsystem
 
+The audio subsystem is one of the multi-function blocks of MediaTek SoCs.
+It contains a system controller, which provides a number registers giving
+access to two features: AUDSYS clocks and Audio Front End (AFE) components.
 
+For the top level node:
+- compatible: must be: "syscon", "simple-mfd";
+- reg: register area of the Audio Subsystem
+
+Required sub-nodes:
+
+AUDSYS clocks:
+---
 The MediaTek AUDSYS controller provides various clocks to the system.
 
 Required Properties:
 
 - compatible: Should be one of:
-   - "mediatek,mt7622-audsys", "syscon"
+   - "mediatek,mt2701-audsys";
+   - "mediatek,mt7622-audsys";
 - #clock-cells: Must be 1
 
 The AUDSYS controller uses the common clk binding from
 Documentation/devicetree/bindings/clock/clock-bindings.txt
 The available clocks are defined in dt-bindings/clock/mt*-clk.h.
 
+AFE components:
+---
+For common binding part and usage, refer to
+../sonud/mt2701-afe-pcm.txt.
+
 Example:
 
-audsys: audsys@1122 {
-   compatible = "mediatek,mt7622-audsys", "syscon";
-   reg = <0 0x1122 0 0x1000>;
-   #clock-cells = <1>;
-};
+   audio-subsystem@1122 {
+   compatible = "syscon", "simple-mfd";
+   reg = <0 0x1122 0 0x2000>;
+
+   audsys: clock {
+   compatible = "mediatek,mt2701-audsys";
+   #clock-cells = <1>;
+   };
+
+   ...
+   };
-- 
1.9.1

[PATCH v2 3/5] clk: mediatek: add audsys support for MT2701

[Ryder Lee]

Add clock driver support for MT2701 audsys.

Signed-off-by: Ryder Lee 
---
 drivers/clk/mediatek/Kconfig  |   6 ++
 drivers/clk/mediatek/Makefile |   1 +
 drivers/clk/mediatek/clk-mt2701-aud.c | 175 ++
 3 files changed, 182 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt2701-aud.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 59dc0aa..efb6f58 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -50,6 +50,12 @@ config COMMON_CLK_MT2701_BDPSYS
---help---
  This driver supports Mediatek MT2701 bdpsys clocks.
 
+config COMMON_CLK_MT2701_AUDSYS
+   bool "Clock driver for Mediatek MT2701 audsys"
+   depends on COMMON_CLK_MT2701
+   ---help---
+ This driver supports Mediatek MT2701 audsys clocks.
+
 config COMMON_CLK_MT2712
bool "Clock driver for Mediatek MT2712"
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index c421ffc..c4ab7d3 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_COMMON_CLK_MT6797_MMSYS) += clk-mt6797-mm.o
 obj-$(CONFIG_COMMON_CLK_MT6797_VDECSYS) += clk-mt6797-vdec.o
 obj-$(CONFIG_COMMON_CLK_MT6797_VENCSYS) += clk-mt6797-venc.o
 obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
+obj-$(CONFIG_COMMON_CLK_MT2701_AUDSYS) += clk-mt2701-aud.o
 obj-$(CONFIG_COMMON_CLK_MT2701_BDPSYS) += clk-mt2701-bdp.o
 obj-$(CONFIG_COMMON_CLK_MT2701_ETHSYS) += clk-mt2701-eth.o
 obj-$(CONFIG_COMMON_CLK_MT2701_HIFSYS) += clk-mt2701-hif.o
diff --git a/drivers/clk/mediatek/clk-mt2701-aud.c 
b/drivers/clk/mediatek/clk-mt2701-aud.c
new file mode 100644
index 000..d8005b3
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt2701-aud.c
@@ -0,0 +1,175 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ryder Lee 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk-mtk.h"
+#include "clk-gate.h"
+
+#include 
+
+#define GATE_AUDIO0(_id, _name, _parent, _shift) { \
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = _cg_regs,\
+   .shift = _shift,\
+   .ops = _clk_gate_ops_no_setclr, \
+   }
+
+#define GATE_AUDIO1(_id, _name, _parent, _shift) { \
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = _cg_regs,\
+   .shift = _shift,\
+   .ops = _clk_gate_ops_no_setclr, \
+   }
+
+#define GATE_AUDIO2(_id, _name, _parent, _shift) { \
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = _cg_regs,\
+   .shift = _shift,\
+   .ops = _clk_gate_ops_no_setclr, \
+   }
+
+#define GATE_AUDIO3(_id, _name, _parent, _shift) { \
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = _cg_regs,\
+   .shift = _shift,\
+   .ops = _clk_gate_ops_no_setclr, \
+   }
+
+static const struct mtk_gate_regs audio0_cg_regs = {
+   .set_ofs = 0x0,
+   .clr_ofs = 0x0,
+   .sta_ofs = 0x0,
+};
+
+static const struct mtk_gate_regs audio1_cg_regs = {
+   .set_ofs = 0x10,
+   .clr_ofs = 0x10,
+   .sta_ofs = 0x10,
+};
+
+static const struct mtk_gate_regs audio2_cg_regs = {
+   .set_ofs = 0x14,
+   .clr_ofs = 0x14,
+   .sta_ofs = 0x14,
+};
+
+static const struct mtk_gate_regs audio3_cg_regs = {
+   .set_ofs = 0x634,
+   .clr_ofs = 0x634,
+   .sta_ofs = 0x634,
+};
+
+static const struct mtk_gate audio_clks[] = {
+   /* AUDIO0 */
+   GATE_AUDIO0(CLK_AUD_AFE, "audio_afe", "aud_intbus_sel", 2),
+   GATE_AUDIO0(CLK_AUD_HDMI, "audio_hdmi", "audpll_sel", 20),
+   GATE_AUDIO0(CLK_AUD_SPDF, "audio_spdf", "audpll_sel", 21),
+   GATE_AUDIO0(CLK_AUD_SPDF2, "audio_spdf2", "audpll_sel", 22),
+   GATE_AUDIO0(CLK_AUD_APLL, "audio_apll", "audpll_sel", 23),
+   /* AUDIO1 */
+   GATE_AUDIO1(CLK_AUD_I2SIN1, "audio_i2sin1", "aud_mux1_sel", 0),
+   GATE_AUDIO1(CLK_AUD_I2SIN2, "audio_i2sin2", "aud_mux1_sel", 1),
+   GATE_AUDIO1(CLK_AUD_I2SIN3, "audio_i2sin3", "aud_mux1_sel", 2),
+   

[PATCH v2 3/5] clk: mediatek: add audsys support for MT2701

[Ryder Lee]

Add clock driver support for MT2701 audsys.

Signed-off-by: Ryder Lee 
---
 drivers/clk/mediatek/Kconfig  |   6 ++
 drivers/clk/mediatek/Makefile |   1 +
 drivers/clk/mediatek/clk-mt2701-aud.c | 175 ++
 3 files changed, 182 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt2701-aud.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 59dc0aa..efb6f58 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -50,6 +50,12 @@ config COMMON_CLK_MT2701_BDPSYS
---help---
  This driver supports Mediatek MT2701 bdpsys clocks.
 
+config COMMON_CLK_MT2701_AUDSYS
+   bool "Clock driver for Mediatek MT2701 audsys"
+   depends on COMMON_CLK_MT2701
+   ---help---
+ This driver supports Mediatek MT2701 audsys clocks.
+
 config COMMON_CLK_MT2712
bool "Clock driver for Mediatek MT2712"
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index c421ffc..c4ab7d3 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_COMMON_CLK_MT6797_MMSYS) += clk-mt6797-mm.o
 obj-$(CONFIG_COMMON_CLK_MT6797_VDECSYS) += clk-mt6797-vdec.o
 obj-$(CONFIG_COMMON_CLK_MT6797_VENCSYS) += clk-mt6797-venc.o
 obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
+obj-$(CONFIG_COMMON_CLK_MT2701_AUDSYS) += clk-mt2701-aud.o
 obj-$(CONFIG_COMMON_CLK_MT2701_BDPSYS) += clk-mt2701-bdp.o
 obj-$(CONFIG_COMMON_CLK_MT2701_ETHSYS) += clk-mt2701-eth.o
 obj-$(CONFIG_COMMON_CLK_MT2701_HIFSYS) += clk-mt2701-hif.o
diff --git a/drivers/clk/mediatek/clk-mt2701-aud.c 
b/drivers/clk/mediatek/clk-mt2701-aud.c
new file mode 100644
index 000..d8005b3
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt2701-aud.c
@@ -0,0 +1,175 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ryder Lee 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk-mtk.h"
+#include "clk-gate.h"
+
+#include 
+
+#define GATE_AUDIO0(_id, _name, _parent, _shift) { \
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = _cg_regs,\
+   .shift = _shift,\
+   .ops = _clk_gate_ops_no_setclr, \
+   }
+
+#define GATE_AUDIO1(_id, _name, _parent, _shift) { \
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = _cg_regs,\
+   .shift = _shift,\
+   .ops = _clk_gate_ops_no_setclr, \
+   }
+
+#define GATE_AUDIO2(_id, _name, _parent, _shift) { \
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = _cg_regs,\
+   .shift = _shift,\
+   .ops = _clk_gate_ops_no_setclr, \
+   }
+
+#define GATE_AUDIO3(_id, _name, _parent, _shift) { \
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = _cg_regs,\
+   .shift = _shift,\
+   .ops = _clk_gate_ops_no_setclr, \
+   }
+
+static const struct mtk_gate_regs audio0_cg_regs = {
+   .set_ofs = 0x0,
+   .clr_ofs = 0x0,
+   .sta_ofs = 0x0,
+};
+
+static const struct mtk_gate_regs audio1_cg_regs = {
+   .set_ofs = 0x10,
+   .clr_ofs = 0x10,
+   .sta_ofs = 0x10,
+};
+
+static const struct mtk_gate_regs audio2_cg_regs = {
+   .set_ofs = 0x14,
+   .clr_ofs = 0x14,
+   .sta_ofs = 0x14,
+};
+
+static const struct mtk_gate_regs audio3_cg_regs = {
+   .set_ofs = 0x634,
+   .clr_ofs = 0x634,
+   .sta_ofs = 0x634,
+};
+
+static const struct mtk_gate audio_clks[] = {
+   /* AUDIO0 */
+   GATE_AUDIO0(CLK_AUD_AFE, "audio_afe", "aud_intbus_sel", 2),
+   GATE_AUDIO0(CLK_AUD_HDMI, "audio_hdmi", "audpll_sel", 20),
+   GATE_AUDIO0(CLK_AUD_SPDF, "audio_spdf", "audpll_sel", 21),
+   GATE_AUDIO0(CLK_AUD_SPDF2, "audio_spdf2", "audpll_sel", 22),
+   GATE_AUDIO0(CLK_AUD_APLL, "audio_apll", "audpll_sel", 23),
+   /* AUDIO1 */
+   GATE_AUDIO1(CLK_AUD_I2SIN1, "audio_i2sin1", "aud_mux1_sel", 0),
+   GATE_AUDIO1(CLK_AUD_I2SIN2, "audio_i2sin2", "aud_mux1_sel", 1),
+   GATE_AUDIO1(CLK_AUD_I2SIN3, "audio_i2sin3", "aud_mux1_sel", 2),
+   GATE_AUDIO1(CLK_AUD_I2SIN4, "audio_i2sin4", 

[PATCH v2 5/5] arm: dts: mediatek: add audio-subsystem node for both MT2701 and MT7623

[Ryder Lee]

Add audio-subsystem node and its clock support for both MT2701/MT7623.
Then modify afe node to adapt it.

Signed-off-by: Ryder Lee 
---
 arch/arm/boot/dts/mt2701.dtsi | 192 -
 arch/arm/boot/dts/mt7623.dtsi | 193 +-
 2 files changed, 189 insertions(+), 196 deletions(-)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 965ddfb..4780aa9 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -426,104 +426,100 @@
status = "disabled";
};
 
-   afe: audio-controller@1122 {
-   compatible = "mediatek,mt2701-audio";
-   reg = <0 0x1122 0 0x2000>,
- <0 0x112a 0 0x2>;
-   interrupts =  ,
- ;
-   interrupt-names = "afe", "asys";
-   power-domains = < MT2701_POWER_DOMAIN_IFR_MSC>;
-
-   clocks = < CLK_INFRA_AUDIO>,
-< CLK_TOP_AUD_MUX1_SEL>,
-< CLK_TOP_AUD_MUX2_SEL>,
-< CLK_TOP_AUD_MUX1_DIV>,
-< CLK_TOP_AUD_MUX2_DIV>,
-< CLK_TOP_AUD_48K_TIMING>,
-< CLK_TOP_AUD_44K_TIMING>,
-< CLK_TOP_AUDPLL_MUX_SEL>,
-< CLK_TOP_APLL_SEL>,
-< CLK_TOP_AUD1PLL_98M>,
-< CLK_TOP_AUD2PLL_90M>,
-< CLK_TOP_HADDS2PLL_98M>,
-< CLK_TOP_HADDS2PLL_294M>,
-< CLK_TOP_AUDPLL>,
-< CLK_TOP_AUDPLL_D4>,
-< CLK_TOP_AUDPLL_D8>,
-< CLK_TOP_AUDPLL_D16>,
-< CLK_TOP_AUDPLL_D24>,
-< CLK_TOP_AUDINTBUS_SEL>,
-<>,
-< CLK_TOP_SYSPLL1_D4>,
-< CLK_TOP_AUD_K1_SRC_SEL>,
-< CLK_TOP_AUD_K2_SRC_SEL>,
-< CLK_TOP_AUD_K3_SRC_SEL>,
-< CLK_TOP_AUD_K4_SRC_SEL>,
-< CLK_TOP_AUD_K5_SRC_SEL>,
-< CLK_TOP_AUD_K6_SRC_SEL>,
-< CLK_TOP_AUD_K1_SRC_DIV>,
-< CLK_TOP_AUD_K2_SRC_DIV>,
-< CLK_TOP_AUD_K3_SRC_DIV>,
-< CLK_TOP_AUD_K4_SRC_DIV>,
-< CLK_TOP_AUD_K5_SRC_DIV>,
-< CLK_TOP_AUD_K6_SRC_DIV>,
-< CLK_TOP_AUD_I2S1_MCLK>,
-< CLK_TOP_AUD_I2S2_MCLK>,
-< CLK_TOP_AUD_I2S3_MCLK>,
-< CLK_TOP_AUD_I2S4_MCLK>,
-< CLK_TOP_AUD_I2S5_MCLK>,
-< CLK_TOP_AUD_I2S6_MCLK>,
-< CLK_TOP_ASM_M_SEL>,
-< CLK_TOP_ASM_H_SEL>,
-< CLK_TOP_UNIVPLL2_D4>,
-< CLK_TOP_UNIVPLL2_D2>,
-< CLK_TOP_SYSPLL_D5>;
-
-   clock-names = "infra_sys_audio_clk",
-"top_audio_mux1_sel",
-"top_audio_mux2_sel",
-"top_audio_mux1_div",
-"top_audio_mux2_div",
-"top_audio_48k_timing",
-"top_audio_44k_timing",
-"top_audpll_mux_sel",
-"top_apll_sel",
-"top_aud1_pll_98M",
-"top_aud2_pll_90M",
-"top_hadds2_pll_98M",
-"top_hadds2_pll_294M",
-"top_audpll",
-"top_audpll_d4",
-"top_audpll_d8",
-"top_audpll_d16",
-"top_audpll_d24",
-"top_audintbus_sel",
-"clk_26m",
-"top_syspll1_d4",
-"top_aud_k1_src_sel",
-"top_aud_k2_src_sel",
-"top_aud_k3_src_sel",
-"top_aud_k4_src_sel",
-"top_aud_k5_src_sel",
-"top_aud_k6_src_sel",
-"top_aud_k1_src_div",
-"top_aud_k2_src_div",
-"top_aud_k3_src_div",
-"top_aud_k4_src_div",
-"top_aud_k5_src_div",
-"top_aud_k6_src_div",
-"top_aud_i2s1_mclk",
-"top_aud_i2s2_mclk",
-"top_aud_i2s3_mclk",
-"top_aud_i2s4_mclk",
-"top_aud_i2s5_mclk",
-"top_aud_i2s6_mclk",
-

[PATCH v2 5/5] arm: dts: mediatek: add audio-subsystem node for both MT2701 and MT7623

[Ryder Lee]

Add audio-subsystem node and its clock support for both MT2701/MT7623.
Then modify afe node to adapt it.

Signed-off-by: Ryder Lee 
---
 arch/arm/boot/dts/mt2701.dtsi | 192 -
 arch/arm/boot/dts/mt7623.dtsi | 193 +-
 2 files changed, 189 insertions(+), 196 deletions(-)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 965ddfb..4780aa9 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -426,104 +426,100 @@
status = "disabled";
};
 
-   afe: audio-controller@1122 {
-   compatible = "mediatek,mt2701-audio";
-   reg = <0 0x1122 0 0x2000>,
- <0 0x112a 0 0x2>;
-   interrupts =  ,
- ;
-   interrupt-names = "afe", "asys";
-   power-domains = < MT2701_POWER_DOMAIN_IFR_MSC>;
-
-   clocks = < CLK_INFRA_AUDIO>,
-< CLK_TOP_AUD_MUX1_SEL>,
-< CLK_TOP_AUD_MUX2_SEL>,
-< CLK_TOP_AUD_MUX1_DIV>,
-< CLK_TOP_AUD_MUX2_DIV>,
-< CLK_TOP_AUD_48K_TIMING>,
-< CLK_TOP_AUD_44K_TIMING>,
-< CLK_TOP_AUDPLL_MUX_SEL>,
-< CLK_TOP_APLL_SEL>,
-< CLK_TOP_AUD1PLL_98M>,
-< CLK_TOP_AUD2PLL_90M>,
-< CLK_TOP_HADDS2PLL_98M>,
-< CLK_TOP_HADDS2PLL_294M>,
-< CLK_TOP_AUDPLL>,
-< CLK_TOP_AUDPLL_D4>,
-< CLK_TOP_AUDPLL_D8>,
-< CLK_TOP_AUDPLL_D16>,
-< CLK_TOP_AUDPLL_D24>,
-< CLK_TOP_AUDINTBUS_SEL>,
-<>,
-< CLK_TOP_SYSPLL1_D4>,
-< CLK_TOP_AUD_K1_SRC_SEL>,
-< CLK_TOP_AUD_K2_SRC_SEL>,
-< CLK_TOP_AUD_K3_SRC_SEL>,
-< CLK_TOP_AUD_K4_SRC_SEL>,
-< CLK_TOP_AUD_K5_SRC_SEL>,
-< CLK_TOP_AUD_K6_SRC_SEL>,
-< CLK_TOP_AUD_K1_SRC_DIV>,
-< CLK_TOP_AUD_K2_SRC_DIV>,
-< CLK_TOP_AUD_K3_SRC_DIV>,
-< CLK_TOP_AUD_K4_SRC_DIV>,
-< CLK_TOP_AUD_K5_SRC_DIV>,
-< CLK_TOP_AUD_K6_SRC_DIV>,
-< CLK_TOP_AUD_I2S1_MCLK>,
-< CLK_TOP_AUD_I2S2_MCLK>,
-< CLK_TOP_AUD_I2S3_MCLK>,
-< CLK_TOP_AUD_I2S4_MCLK>,
-< CLK_TOP_AUD_I2S5_MCLK>,
-< CLK_TOP_AUD_I2S6_MCLK>,
-< CLK_TOP_ASM_M_SEL>,
-< CLK_TOP_ASM_H_SEL>,
-< CLK_TOP_UNIVPLL2_D4>,
-< CLK_TOP_UNIVPLL2_D2>,
-< CLK_TOP_SYSPLL_D5>;
-
-   clock-names = "infra_sys_audio_clk",
-"top_audio_mux1_sel",
-"top_audio_mux2_sel",
-"top_audio_mux1_div",
-"top_audio_mux2_div",
-"top_audio_48k_timing",
-"top_audio_44k_timing",
-"top_audpll_mux_sel",
-"top_apll_sel",
-"top_aud1_pll_98M",
-"top_aud2_pll_90M",
-"top_hadds2_pll_98M",
-"top_hadds2_pll_294M",
-"top_audpll",
-"top_audpll_d4",
-"top_audpll_d8",
-"top_audpll_d16",
-"top_audpll_d24",
-"top_audintbus_sel",
-"clk_26m",
-"top_syspll1_d4",
-"top_aud_k1_src_sel",
-"top_aud_k2_src_sel",
-"top_aud_k3_src_sel",
-"top_aud_k4_src_sel",
-"top_aud_k5_src_sel",
-"top_aud_k6_src_sel",
-"top_aud_k1_src_div",
-"top_aud_k2_src_div",
-"top_aud_k3_src_div",
-"top_aud_k4_src_div",
-"top_aud_k5_src_div",
-"top_aud_k6_src_div",
-"top_aud_i2s1_mclk",
-"top_aud_i2s2_mclk",
-"top_aud_i2s3_mclk",
-"top_aud_i2s4_mclk",
-"top_aud_i2s5_mclk",
-"top_aud_i2s6_mclk",
-"top_asm_m_sel",
-   

Re: [linux-sunxi] Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

[Maxime Ripard]

Hi Liviu,

On Wed, Jan 31, 2018 at 03:08:08AM +, Liviu Dudau wrote:
> On Fri, Jan 26, 2018 at 11:00:41AM +0800, Yong wrote:
> > Hi Maxime,
> > 
> > On Fri, 26 Jan 2018 09:46:58 +0800
> > Yong  wrote:
> > 
> > > Hi Maxime,
> > > 
> > > Do you have any experience in solving this problem?
> > > It seems the PHYS_OFFSET maybe undeclared when the ARCH is not arm.
> > 
> > Got it.
> > Should I add 'depends on ARM' in Kconfig?
> 
> No, I don't think you should do that, you should fix the code.
> 
> The dma_addr_t addr that you've got is ideally coming from 
> dma_alloc_coherent(),
> in which case the addr is already "suitable" for use by the device (because 
> the
> bus where the device is attached to does all the address translations).

Like we're discussing in that other part of the thread with Thierry
and Arnd, things are slightly more complicated than that :)

In our case, the bus where the device is attached will not do the
address translations, and shouldn't.

> If you apply PHYS_OFFSET forcefully to it you might get unexpected
> results.

Out of curiosity, what would be these unexpected results?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [linux-sunxi] Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

[Maxime Ripard]

Hi Liviu,

On Wed, Jan 31, 2018 at 03:08:08AM +, Liviu Dudau wrote:
> On Fri, Jan 26, 2018 at 11:00:41AM +0800, Yong wrote:
> > Hi Maxime,
> > 
> > On Fri, 26 Jan 2018 09:46:58 +0800
> > Yong  wrote:
> > 
> > > Hi Maxime,
> > > 
> > > Do you have any experience in solving this problem?
> > > It seems the PHYS_OFFSET maybe undeclared when the ARCH is not arm.
> > 
> > Got it.
> > Should I add 'depends on ARM' in Kconfig?
> 
> No, I don't think you should do that, you should fix the code.
> 
> The dma_addr_t addr that you've got is ideally coming from 
> dma_alloc_coherent(),
> in which case the addr is already "suitable" for use by the device (because 
> the
> bus where the device is attached to does all the address translations).

Like we're discussing in that other part of the thread with Thierry
and Arnd, things are slightly more complicated than that :)

In our case, the bus where the device is attached will not do the
address translations, and shouldn't.

> If you apply PHYS_OFFSET forcefully to it you might get unexpected
> results.

Out of curiosity, what would be these unexpected results?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH 2/2] dt-bindings: PCI: MediaTek: Correct the interrupt-map properties

[Ryder Lee]

Move the interrupt-map properties from the child nodes to the root node
and update each entry accordingly.

Signed-off-by: Ryder Lee 
---
 .../devicetree/bindings/pci/mediatek-pcie.txt  | 28 --
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt 
b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
index 3a6ce55..b15ea2d 100644
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
@@ -89,10 +89,21 @@ Examples for MT7623:
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
-   interrupt-map-mask = <0xf800 0 0 0>;
-   interrupt-map = <0x 0 0 0  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW>,
-   <0x0800 0 0 0  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW>,
-   <0x1000 0 0 0  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <0x 0 0 1  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW
+   0x 0 0 2  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW
+   0x 0 0 3  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW
+   0x 0 0 4  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW
+
+   0x0800 0 0 1  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW
+   0x0800 0 0 2  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW
+   0x0800 0 0 3  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW
+   0x0800 0 0 4  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW
+
+   0x1000 0 0 1  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW
+   0x1000 0 0 2  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW
+   0x1000 0 0 3  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW
+   0x1000 0 0 4  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW>;
clocks = < CLK_TOP_ETHIF_SEL>,
 < CLK_HIFSYS_PCIE0>,
 < CLK_HIFSYS_PCIE1>,
@@ -115,9 +126,6 @@ Examples for MT7623:
reg = <0x 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
-   #interrupt-cells = <1>;
-   interrupt-map-mask = <0 0 0 0>;
-   interrupt-map = <0 0 0 0  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW>;
ranges;
num-lanes = <1>;
};
@@ -127,9 +135,6 @@ Examples for MT7623:
reg = <0x0800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
-   #interrupt-cells = <1>;
-   interrupt-map-mask = <0 0 0 0>;
-   interrupt-map = <0 0 0 0  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW>;
ranges;
num-lanes = <1>;
};
@@ -139,9 +144,6 @@ Examples for MT7623:
reg = <0x1000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
-   #interrupt-cells = <1>;
-   interrupt-map-mask = <0 0 0 0>;
-   interrupt-map = <0 0 0 0  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW>;
ranges;
num-lanes = <1>;
};
-- 
1.9.1

[PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

[Ryder Lee]

A root complex usually consist of a host bridge and multiple P2P bridges,
and someone may express that in the form of a root node with many subnodes
and list all four interrupts for each slot (child node) in the root node
like this:

pcie-controller {
...
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <0x 0 0 {INTx} &{interrupt parent} ...>
 0x0800 0 0 {INTx} &{interrupt parent} ...>;

pcie@0,0 {
reg = <0x 0 0 0 0>;
...
};

pcie@1,0 {
reg = <0x0800 0 0 0 0>;
...
};
};

As shown above, we'd like to propagate IRQs from a root port to the devices
in the hierarchy below it in this way.  However, it seems that the current
parser couldn't handle such cases and will get something unexpected below:

pcieport :00:01.0: assign IRQ: got 213
igb :01:00.0: assign IRQ: got 212

There is a device which is connected to 2nd slot, but the port doesn't share
the same IRQ with its downstream devices.  The problem here is that, if the
loop found a P2P bridge, it wouldn't check whether the reg property exists
in ppnode or not but just pass the subordinate devfn to of_irq_parse_raw(),
thus the subsequent flow couldn't correctly resolve them.

Fix this by adding a check to fallback to standard device tree parsing.

Signed-off-by: Ryder Lee 
---
Please refer to the previous discussion thread: 
https://patchwork.ozlabs.org/patch/829108/
---
 drivers/of/of_pci_irq.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
index 3a05568..e445866 100644
--- a/drivers/of/of_pci_irq.c
+++ b/drivers/of/of_pci_irq.c
@@ -86,8 +86,18 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq
out_irq->np = ppnode;
out_irq->args_count = 1;
out_irq->args[0] = pin;
-   laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
-   laddr[1] = laddr[2] = cpu_to_be32(0);
+
+   if (!dn && ppnode) {
+   const __be32 *addr;
+
+   addr = of_get_property(ppnode, "reg", NULL);
+   if (addr)
+   memcpy(laddr, addr, 3);
+   } else {
+   laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn 
<< 8));
+   laddr[1] = laddr[2] = cpu_to_be32(0);
+   }
+
rc = of_irq_parse_raw(laddr, out_irq);
if (rc)
goto err;
-- 
1.9.1

[PATCH 2/2] dt-bindings: PCI: MediaTek: Correct the interrupt-map properties

[Ryder Lee]

Move the interrupt-map properties from the child nodes to the root node
and update each entry accordingly.

Signed-off-by: Ryder Lee 
---
 .../devicetree/bindings/pci/mediatek-pcie.txt  | 28 --
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt 
b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
index 3a6ce55..b15ea2d 100644
--- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
@@ -89,10 +89,21 @@ Examples for MT7623:
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
-   interrupt-map-mask = <0xf800 0 0 0>;
-   interrupt-map = <0x 0 0 0  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW>,
-   <0x0800 0 0 0  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW>,
-   <0x1000 0 0 0  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <0x 0 0 1  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW
+   0x 0 0 2  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW
+   0x 0 0 3  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW
+   0x 0 0 4  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW
+
+   0x0800 0 0 1  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW
+   0x0800 0 0 2  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW
+   0x0800 0 0 3  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW
+   0x0800 0 0 4  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW
+
+   0x1000 0 0 1  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW
+   0x1000 0 0 2  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW
+   0x1000 0 0 3  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW
+   0x1000 0 0 4  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW>;
clocks = < CLK_TOP_ETHIF_SEL>,
 < CLK_HIFSYS_PCIE0>,
 < CLK_HIFSYS_PCIE1>,
@@ -115,9 +126,6 @@ Examples for MT7623:
reg = <0x 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
-   #interrupt-cells = <1>;
-   interrupt-map-mask = <0 0 0 0>;
-   interrupt-map = <0 0 0 0  GIC_SPI 193 
IRQ_TYPE_LEVEL_LOW>;
ranges;
num-lanes = <1>;
};
@@ -127,9 +135,6 @@ Examples for MT7623:
reg = <0x0800 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
-   #interrupt-cells = <1>;
-   interrupt-map-mask = <0 0 0 0>;
-   interrupt-map = <0 0 0 0  GIC_SPI 194 
IRQ_TYPE_LEVEL_LOW>;
ranges;
num-lanes = <1>;
};
@@ -139,9 +144,6 @@ Examples for MT7623:
reg = <0x1000 0 0 0 0>;
#address-cells = <3>;
#size-cells = <2>;
-   #interrupt-cells = <1>;
-   interrupt-map-mask = <0 0 0 0>;
-   interrupt-map = <0 0 0 0  GIC_SPI 195 
IRQ_TYPE_LEVEL_LOW>;
ranges;
num-lanes = <1>;
};
-- 
1.9.1

[PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

[Ryder Lee]

A root complex usually consist of a host bridge and multiple P2P bridges,
and someone may express that in the form of a root node with many subnodes
and list all four interrupts for each slot (child node) in the root node
like this:

pcie-controller {
...
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <0x 0 0 {INTx} &{interrupt parent} ...>
 0x0800 0 0 {INTx} &{interrupt parent} ...>;

pcie@0,0 {
reg = <0x 0 0 0 0>;
...
};

pcie@1,0 {
reg = <0x0800 0 0 0 0>;
...
};
};

As shown above, we'd like to propagate IRQs from a root port to the devices
in the hierarchy below it in this way.  However, it seems that the current
parser couldn't handle such cases and will get something unexpected below:

pcieport :00:01.0: assign IRQ: got 213
igb :01:00.0: assign IRQ: got 212

There is a device which is connected to 2nd slot, but the port doesn't share
the same IRQ with its downstream devices.  The problem here is that, if the
loop found a P2P bridge, it wouldn't check whether the reg property exists
in ppnode or not but just pass the subordinate devfn to of_irq_parse_raw(),
thus the subsequent flow couldn't correctly resolve them.

Fix this by adding a check to fallback to standard device tree parsing.

Signed-off-by: Ryder Lee 
---
Please refer to the previous discussion thread: 
https://patchwork.ozlabs.org/patch/829108/
---
 drivers/of/of_pci_irq.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
index 3a05568..e445866 100644
--- a/drivers/of/of_pci_irq.c
+++ b/drivers/of/of_pci_irq.c
@@ -86,8 +86,18 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq
out_irq->np = ppnode;
out_irq->args_count = 1;
out_irq->args[0] = pin;
-   laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
-   laddr[1] = laddr[2] = cpu_to_be32(0);
+
+   if (!dn && ppnode) {
+   const __be32 *addr;
+
+   addr = of_get_property(ppnode, "reg", NULL);
+   if (addr)
+   memcpy(laddr, addr, 3);
+   } else {
+   laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn 
<< 8));
+   laddr[1] = laddr[2] = cpu_to_be32(0);
+   }
+
rc = of_irq_parse_raw(laddr, out_irq);
if (rc)
goto err;
-- 
1.9.1

RE: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

[Avri Altman]

Hi,
Can you elaborate how this can even happen?
Isn't the interrupt aggregation capability should attend for those cases?

Thanks,
Avri

> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Asutosh Das
> Sent: Tuesday, January 30, 2018 6:54 AM
> To: subha...@codeaurora.org; c...@codeaurora.org;
> vivek.gau...@codeaurora.org; rna...@codeaurora.org;
> vinholika...@gmail.com; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com
> Cc: linux-s...@vger.kernel.org; Venkat Gopalakrishnan
> ; Asutosh Das ; open
> list 
> Subject: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed
> 
> From: Venkat Gopalakrishnan 
> 
> As multiple requests are submitted to the ufs host controller in parallel 
> there
> could be instances where the command completion interrupt arrives later for a
> request that is already processed earlier as the corresponding doorbell was
> cleared when handling the previous interrupt. Read the interrupt status in a
> loop after processing the received interrupt to catch such interrupts and 
> handle
> it.
> 
> Signed-off-by: Venkat Gopalakrishnan 
> Signed-off-by: Asutosh Das 
> ---
>  drivers/scsi/ufs/ufshcd.c | 27 +++
>  1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
> 8af2af3..58d81de 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -5357,19 +5357,30 @@ static irqreturn_t ufshcd_intr(int irq, void *__hba)
>   u32 intr_status, enabled_intr_status;
>   irqreturn_t retval = IRQ_NONE;
>   struct ufs_hba *hba = __hba;
> + int retries = hba->nutrs;
> 
>   spin_lock(hba->host->host_lock);
>   intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
> - enabled_intr_status =
> - intr_status & ufshcd_readl(hba, REG_INTERRUPT_ENABLE);
> 
> - if (intr_status)
> - ufshcd_writel(hba, intr_status, REG_INTERRUPT_STATUS);
> + /*
> +  * There could be max of hba->nutrs reqs in flight and in worst case
> +  * if the reqs get finished 1 by 1 after the interrupt status is
> +  * read, make sure we handle them by checking the interrupt status
> +  * again in a loop until we process all of the reqs before returning.
> +  */
> + do {
> + enabled_intr_status =
> + intr_status & ufshcd_readl(hba,
> REG_INTERRUPT_ENABLE);
> + if (intr_status)
> + ufshcd_writel(hba, intr_status,
> REG_INTERRUPT_STATUS);
> + if (enabled_intr_status) {
> + ufshcd_sl_intr(hba, enabled_intr_status);
> + retval = IRQ_HANDLED;
> + }
> +
> + intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
> + } while (intr_status && --retries);
> 
> - if (enabled_intr_status) {
> - ufshcd_sl_intr(hba, enabled_intr_status);
> - retval = IRQ_HANDLED;
> - }
>   spin_unlock(hba->host->host_lock);
>   return retval;
>  }
> --
> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
> Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project.

RE: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

[Avri Altman]

Hi,
Can you elaborate how this can even happen?
Isn't the interrupt aggregation capability should attend for those cases?

Thanks,
Avri

> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Asutosh Das
> Sent: Tuesday, January 30, 2018 6:54 AM
> To: subha...@codeaurora.org; c...@codeaurora.org;
> vivek.gau...@codeaurora.org; rna...@codeaurora.org;
> vinholika...@gmail.com; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com
> Cc: linux-s...@vger.kernel.org; Venkat Gopalakrishnan
> ; Asutosh Das ; open
> list 
> Subject: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed
> 
> From: Venkat Gopalakrishnan 
> 
> As multiple requests are submitted to the ufs host controller in parallel 
> there
> could be instances where the command completion interrupt arrives later for a
> request that is already processed earlier as the corresponding doorbell was
> cleared when handling the previous interrupt. Read the interrupt status in a
> loop after processing the received interrupt to catch such interrupts and 
> handle
> it.
> 
> Signed-off-by: Venkat Gopalakrishnan 
> Signed-off-by: Asutosh Das 
> ---
>  drivers/scsi/ufs/ufshcd.c | 27 +++
>  1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
> 8af2af3..58d81de 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -5357,19 +5357,30 @@ static irqreturn_t ufshcd_intr(int irq, void *__hba)
>   u32 intr_status, enabled_intr_status;
>   irqreturn_t retval = IRQ_NONE;
>   struct ufs_hba *hba = __hba;
> + int retries = hba->nutrs;
> 
>   spin_lock(hba->host->host_lock);
>   intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
> - enabled_intr_status =
> - intr_status & ufshcd_readl(hba, REG_INTERRUPT_ENABLE);
> 
> - if (intr_status)
> - ufshcd_writel(hba, intr_status, REG_INTERRUPT_STATUS);
> + /*
> +  * There could be max of hba->nutrs reqs in flight and in worst case
> +  * if the reqs get finished 1 by 1 after the interrupt status is
> +  * read, make sure we handle them by checking the interrupt status
> +  * again in a loop until we process all of the reqs before returning.
> +  */
> + do {
> + enabled_intr_status =
> + intr_status & ufshcd_readl(hba,
> REG_INTERRUPT_ENABLE);
> + if (intr_status)
> + ufshcd_writel(hba, intr_status,
> REG_INTERRUPT_STATUS);
> + if (enabled_intr_status) {
> + ufshcd_sl_intr(hba, enabled_intr_status);
> + retval = IRQ_HANDLED;
> + }
> +
> + intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
> + } while (intr_status && --retries);
> 
> - if (enabled_intr_status) {
> - ufshcd_sl_intr(hba, enabled_intr_status);
> - retval = IRQ_HANDLED;
> - }
>   spin_unlock(hba->host->host_lock);
>   return retval;
>  }
> --
> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
> Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project.

Re: [PATCH v6 4/6] media: i2c: Add TDA1997x HDMI receiver driver

[Hans Verkuil]

On 01/31/2018 05:51 AM, Tim Harvey wrote:
> On Mon, Jan 29, 2018 at 4:00 AM, Hans Verkuil  wrote:
>> On 01/25/2018 05:15 PM, Tim Harvey wrote:
> 

 Hmm. This receiver supports multiple output formats, but you advertise 
 only one.
 That looks wrong. If nothing else, you should be able to switch between 
 RGB and
 YUV 4:4:4 since they use the same port config.

 It's a common use-case that you want to switch between RGB and YUV 
 depending on
 the source material (i.e. if you receive a desktop/graphics then RGB is 
 best, if
 you receive video then YUV 4:2:2 or 4:2:0 is best).

 Hardcoding just one format won't do.

>>>
>>> I've been thinking about this a bit. I had hard-coded a single format
>>> for now because I haven't had any good ideas on how to deal with the
>>> fact that the port mappings would need to differ if you change from
>>> the RGB888/YUV444 (I think these are referred to as 'planar' formats?)
>>> to YUV422 (semi-planar) and BT656 formats. It is true though that the
>>> 36bit (TDA19973) RGB888/YUV444 and 24bit (TDA19971/2) formats can both
>>> be supported with the same port mappings / pinout.
>>
>> Regarding terminology:
>>
>> RGB and YUV are typically interleaved, i.e. the color components are
>> (for two pixels) either RGBRGB for RGB888, YUVYUV for YUV444 or YUYV
>> for YUV422.
>>
>> Planar formats are in practice only seen for YUV and will first output
>> all Y samples, and then the UV samples. This requires that the hardware
>> buffers the frame and that's not normally done by HDMI receivers.
>>
>> The DMA engine, however, is often able to split up the interleaved YUV
>> samples that it receives and DMA them to separate buffers, thus turning
>> an interleaved media bus format to a planar memory format.
>>
>> BT656 doesn't refer to how the samples are transferred, instead it
>> refers to how the hsync and vsync are reported. The enum v4l2_mbus_type
>> has various options, one of them being BT656.
>>
>> Which mbus type is used is board specific (and should come from the
>> device tree). Whether to transmit RGB888, YUV444 or YUV422 (or possibly
>> even YUV420) is dynamic and is up to userspace since it is use-case
>> dependent.
>>
>> So you'll never switch between BT656 and CSI, but you can switch between
>> BT656+RGB and BT656+YUV, or between CSI+RGB and CSI+YUV.
>>
>>>
>>> For example the GW5400 has a TDA19971 mapped to IMX6 CSI_DATA[19:4]
>>> (16bit) for YUV422. However if you want to use BT656 you have to shift
>>> the TDA19971 port mappings to get the YCbCr pins mapped to
>>> CSI_DATA[19:x] and those pin groups are at the bottom of the bus for
>>> the RGB888/YUV444 format.
>>
>> As mentioned above, you wouldn't switch between mbus types.
>>
>>>
>>> I suppose however that perhaps for the example above if I have a 16bit
>>> width required to support YUV422 there would never be a useful case
>>> for supporting 8-bit/10-bit/12-bit BT656 on the same board?
>>
>> You wouldn't switch between mbus types, but if the device tree configures
>> BT.656 with a bus width of 24 bits, then the application might very well
>> want to dynamically switch between 8, 10 and 12 bits per color component.
>>
> 
> Hans,
> 
> I just submitted a v7 with multiple format support. Your point about
> bus_type being specified by dt is exactly what I needed to help make
> sense of the formats.

Ah, good. It took me some time as well before I realized that the confusion
was in mixing up bus types and formats.

> That said, I'm unsure how to properly test the enum_mbus_code() pad op
> function. How do you obtain a list of valid formats on a subdev?
> 
> I tried the following:
> root@ventana:~# media-ctl -e 'tda19971 2-0048'
> /dev/v4l-subdev1
> root@ventana:~# media-ctl --get-v4l2 '"tda19971 2-0048":0'
> [fmt:UYVY8_2X8/1280x720 field:none colorspace:srgb]
>  calls get_format and returns the 1 and only format available for
> my tda19971 with 16bit parallel bus
> root@ventana:~# v4l2-ctl -d /dev/v4l-subdev1 --get-fmt-video-out
> VIDIOC_G_FMT: failed: Inappropriate ioctl for device
> root@ventana:~# v4l2-ctl -d /dev/v4l-subdev1 --list-formats-out
> ioctl: VIDIOC_ENUM_FMT
> 
> I'm thinking perhaps enumerating the list of possible formats is a
> missing feature in media-ctl?

Yeah, it is. Surprising, really. Ditto for the SUBDEV_ENUM_FRAME_SIZE/INTERVAL
ioctls.

I wonder whether this should be added to v4l2-ctl, media-ctl or both. I always
felt that media-ctl is more about setting up the whole pipeline, whereas 
v4l2-ctl
is specific to a V4L2 device.

Regards,

Hans

Re: Re: [PATCH 2/2] dmaengine: dmatest: add norandom option

[Yang, Shunyong]

Hi, Vinod

On Wed, 2018-01-31 at 13:04 +0530, Vinod Koul wrote:
> On Mon, Jan 22, 2018 at 06:44:41PM +0800, Yang Shunyong wrote:
> > 
> > Existing option noverify disables both random src/dst address
> > offset
> > setup and data verification. Sometimes, we need to control random
> > src/dst address setup and verification separately, such as
> > disabling
> > random to make sure that test covers addresses in all interleaving
> > banks in one run. This patch adds option norandom to disable random
> > offset setup. Option noverify has been changed to disable data
> > verification only.
> This doesn't apply for me due to dependency on previous patch. Please
> rebase
> and resend.
> 

Thanks. I have finished the rebase. I will send out v2 patch when I
finish test.

Thanks.
Shunyong.

Re: [PATCH v6 4/6] media: i2c: Add TDA1997x HDMI receiver driver

[Hans Verkuil]

On 01/31/2018 05:51 AM, Tim Harvey wrote:
> On Mon, Jan 29, 2018 at 4:00 AM, Hans Verkuil  wrote:
>> On 01/25/2018 05:15 PM, Tim Harvey wrote:
> 

 Hmm. This receiver supports multiple output formats, but you advertise 
 only one.
 That looks wrong. If nothing else, you should be able to switch between 
 RGB and
 YUV 4:4:4 since they use the same port config.

 It's a common use-case that you want to switch between RGB and YUV 
 depending on
 the source material (i.e. if you receive a desktop/graphics then RGB is 
 best, if
 you receive video then YUV 4:2:2 or 4:2:0 is best).

 Hardcoding just one format won't do.

>>>
>>> I've been thinking about this a bit. I had hard-coded a single format
>>> for now because I haven't had any good ideas on how to deal with the
>>> fact that the port mappings would need to differ if you change from
>>> the RGB888/YUV444 (I think these are referred to as 'planar' formats?)
>>> to YUV422 (semi-planar) and BT656 formats. It is true though that the
>>> 36bit (TDA19973) RGB888/YUV444 and 24bit (TDA19971/2) formats can both
>>> be supported with the same port mappings / pinout.
>>
>> Regarding terminology:
>>
>> RGB and YUV are typically interleaved, i.e. the color components are
>> (for two pixels) either RGBRGB for RGB888, YUVYUV for YUV444 or YUYV
>> for YUV422.
>>
>> Planar formats are in practice only seen for YUV and will first output
>> all Y samples, and then the UV samples. This requires that the hardware
>> buffers the frame and that's not normally done by HDMI receivers.
>>
>> The DMA engine, however, is often able to split up the interleaved YUV
>> samples that it receives and DMA them to separate buffers, thus turning
>> an interleaved media bus format to a planar memory format.
>>
>> BT656 doesn't refer to how the samples are transferred, instead it
>> refers to how the hsync and vsync are reported. The enum v4l2_mbus_type
>> has various options, one of them being BT656.
>>
>> Which mbus type is used is board specific (and should come from the
>> device tree). Whether to transmit RGB888, YUV444 or YUV422 (or possibly
>> even YUV420) is dynamic and is up to userspace since it is use-case
>> dependent.
>>
>> So you'll never switch between BT656 and CSI, but you can switch between
>> BT656+RGB and BT656+YUV, or between CSI+RGB and CSI+YUV.
>>
>>>
>>> For example the GW5400 has a TDA19971 mapped to IMX6 CSI_DATA[19:4]
>>> (16bit) for YUV422. However if you want to use BT656 you have to shift
>>> the TDA19971 port mappings to get the YCbCr pins mapped to
>>> CSI_DATA[19:x] and those pin groups are at the bottom of the bus for
>>> the RGB888/YUV444 format.
>>
>> As mentioned above, you wouldn't switch between mbus types.
>>
>>>
>>> I suppose however that perhaps for the example above if I have a 16bit
>>> width required to support YUV422 there would never be a useful case
>>> for supporting 8-bit/10-bit/12-bit BT656 on the same board?
>>
>> You wouldn't switch between mbus types, but if the device tree configures
>> BT.656 with a bus width of 24 bits, then the application might very well
>> want to dynamically switch between 8, 10 and 12 bits per color component.
>>
> 
> Hans,
> 
> I just submitted a v7 with multiple format support. Your point about
> bus_type being specified by dt is exactly what I needed to help make
> sense of the formats.

Ah, good. It took me some time as well before I realized that the confusion
was in mixing up bus types and formats.

> That said, I'm unsure how to properly test the enum_mbus_code() pad op
> function. How do you obtain a list of valid formats on a subdev?
> 
> I tried the following:
> root@ventana:~# media-ctl -e 'tda19971 2-0048'
> /dev/v4l-subdev1
> root@ventana:~# media-ctl --get-v4l2 '"tda19971 2-0048":0'
> [fmt:UYVY8_2X8/1280x720 field:none colorspace:srgb]
>  calls get_format and returns the 1 and only format available for
> my tda19971 with 16bit parallel bus
> root@ventana:~# v4l2-ctl -d /dev/v4l-subdev1 --get-fmt-video-out
> VIDIOC_G_FMT: failed: Inappropriate ioctl for device
> root@ventana:~# v4l2-ctl -d /dev/v4l-subdev1 --list-formats-out
> ioctl: VIDIOC_ENUM_FMT
> 
> I'm thinking perhaps enumerating the list of possible formats is a
> missing feature in media-ctl?

Yeah, it is. Surprising, really. Ditto for the SUBDEV_ENUM_FRAME_SIZE/INTERVAL
ioctls.

I wonder whether this should be added to v4l2-ctl, media-ctl or both. I always
felt that media-ctl is more about setting up the whole pipeline, whereas 
v4l2-ctl
is specific to a V4L2 device.

Regards,

Hans

Re: Re: [PATCH 2/2] dmaengine: dmatest: add norandom option

[Yang, Shunyong]

Hi, Vinod

On Wed, 2018-01-31 at 13:04 +0530, Vinod Koul wrote:
> On Mon, Jan 22, 2018 at 06:44:41PM +0800, Yang Shunyong wrote:
> > 
> > Existing option noverify disables both random src/dst address
> > offset
> > setup and data verification. Sometimes, we need to control random
> > src/dst address setup and verification separately, such as
> > disabling
> > random to make sure that test covers addresses in all interleaving
> > banks in one run. This patch adds option norandom to disable random
> > offset setup. Option noverify has been changed to disable data
> > verification only.
> This doesn't apply for me due to dependency on previous patch. Please
> rebase
> and resend.
> 

Thanks. I have finished the rebase. I will send out v2 patch when I
finish test.

Thanks.
Shunyong.

Re: [PATCH 4.14 00/71] 4.14.16-stable review

[Ozkan Sezer]

> This is the start of the stable review cycle for the 4.14.16 release.
> There are 71 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.

The "futex Fix OWNER_DEAD fixup" patch still isn't in ?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/futex.c?id=a97cb0e7b3f4c6297fd857055ae8e895f402f501

Re: [PATCH 7/8] Input: mms114 - add SPDX identifier

[Marcus Folkesson]

Hi Andy,

On Wed, Jan 31, 2018 at 03:07:26PM +0900, Andi Shyti wrote:
> Hi Dmitry,
> 
> > > -/*
> > > - * Copyright (C) 2012 Samsung Electronics Co.Ltd
> > > - * Author: Joonyoung Shim 
> > > - *
> > > - * This program is free software; you can redistribute it and/or modify
> > > - * it under the terms of the GNU General Public License version 2 as
> > > - * published by the Free Software Foundation.
> > > - */
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +// Samsung S6SY761 Touchscreen device driver
> 
> I'm very sorry, but my distrcation will kill me one day.

More coffee or sleep - your choice ;-)

> 
> Is it possible to revert this patch or do you want me to send a
> fix?

When you are on it;

Change
MODULE_LICENSE("GPL");

to 
MODULE_LICENSE("GPL v2");
To match the former license text and SPDX-identifier.

See include/linux/module.h:
 *  "GPL"   [GNU Public License v2 or later]
 *  "GPL v2"[GNU Public License v2]


Thanks,

> 
> Sorry,
> Andi

Best regards
Marcus Folkesson


signature.asc
Description: PGP signature

Re: [PATCH 4.14 00/71] 4.14.16-stable review

[Ozkan Sezer]

> This is the start of the stable review cycle for the 4.14.16 release.
> There are 71 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.

The "futex Fix OWNER_DEAD fixup" patch still isn't in ?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/futex.c?id=a97cb0e7b3f4c6297fd857055ae8e895f402f501

Re: [PATCH 7/8] Input: mms114 - add SPDX identifier

[Marcus Folkesson]

Hi Andy,

On Wed, Jan 31, 2018 at 03:07:26PM +0900, Andi Shyti wrote:
> Hi Dmitry,
> 
> > > -/*
> > > - * Copyright (C) 2012 Samsung Electronics Co.Ltd
> > > - * Author: Joonyoung Shim 
> > > - *
> > > - * This program is free software; you can redistribute it and/or modify
> > > - * it under the terms of the GNU General Public License version 2 as
> > > - * published by the Free Software Foundation.
> > > - */
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +// Samsung S6SY761 Touchscreen device driver
> 
> I'm very sorry, but my distrcation will kill me one day.

More coffee or sleep - your choice ;-)

> 
> Is it possible to revert this patch or do you want me to send a
> fix?

When you are on it;

Change
MODULE_LICENSE("GPL");

to 
MODULE_LICENSE("GPL v2");
To match the former license text and SPDX-identifier.

See include/linux/module.h:
 *  "GPL"   [GNU Public License v2 or later]
 *  "GPL v2"[GNU Public License v2]


Thanks,

> 
> Sorry,
> Andi

Best regards
Marcus Folkesson


signature.asc
Description: PGP signature

Re: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.

[Benjamin Poirier]

On 2018/01/30 11:46, Alexander Duyck wrote:
> On Wed, Jan 17, 2018 at 10:50 PM, Benjamin Poirier  wrote:
> > It was reported that emulated e1000e devices in vmware esxi 6.5 Build
> > 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver
> > overrun interrupt bursts", v4.15-rc1). Some tracing shows that after
> > e1000e_trigger_lsc() is called, ICR reads out as 0x0 in e1000_msix_other()
> > on emulated e1000e devices. In comparison, on real e1000e 82574 hardware,
> > icr=0x8004 (_INT_ASSERTED | _OTHER) in the same situation.
> >
> > Some experimentation showed that this flaw in vmware e1000e emulation can
> > be worked around by not setting Other in EIAC. This is how it was before
> > 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1).
> >
> > Fixes: 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts")
> > Signed-off-by: Benjamin Poirier 
> > ---
> 
> Hi Benjamin,
> 
> How would you feel about resubmitting this patch for net?
> 
> We have some issues that have come up and it would be useful to have
> this fixed in the kernel sooner rather than later. I would be okay
> with us applying it for now while we work on coming up with a more
> complete solution.

Ok, I've resent it in its original form. Once it's in mainline I'll
rebase the cleanups.

Re: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.

[Benjamin Poirier]

On 2018/01/30 11:46, Alexander Duyck wrote:
> On Wed, Jan 17, 2018 at 10:50 PM, Benjamin Poirier  wrote:
> > It was reported that emulated e1000e devices in vmware esxi 6.5 Build
> > 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver
> > overrun interrupt bursts", v4.15-rc1). Some tracing shows that after
> > e1000e_trigger_lsc() is called, ICR reads out as 0x0 in e1000_msix_other()
> > on emulated e1000e devices. In comparison, on real e1000e 82574 hardware,
> > icr=0x8004 (_INT_ASSERTED | _OTHER) in the same situation.
> >
> > Some experimentation showed that this flaw in vmware e1000e emulation can
> > be worked around by not setting Other in EIAC. This is how it was before
> > 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1).
> >
> > Fixes: 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts")
> > Signed-off-by: Benjamin Poirier 
> > ---
> 
> Hi Benjamin,
> 
> How would you feel about resubmitting this patch for net?
> 
> We have some issues that have come up and it would be useful to have
> this fixed in the kernel sooner rather than later. I would be okay
> with us applying it for now while we work on coming up with a more
> complete solution.

Ok, I've resent it in its original form. Once it's in mainline I'll
rebase the cleanups.

Re: [PATCH 2/2] dmaengine: dmatest: add norandom option

[Vinod Koul]

On Mon, Jan 22, 2018 at 06:44:41PM +0800, Yang Shunyong wrote:
> Existing option noverify disables both random src/dst address offset
> setup and data verification. Sometimes, we need to control random
> src/dst address setup and verification separately, such as disabling
> random to make sure that test covers addresses in all interleaving
> banks in one run. This patch adds option norandom to disable random
> offset setup. Option noverify has been changed to disable data
> verification only.

This doesn't apply for me due to dependency on previous patch. Please rebase
and resend.

-- 
~Vinod

Re: [PATCH 2/2] dmaengine: dmatest: add norandom option

[Vinod Koul]

On Mon, Jan 22, 2018 at 06:44:41PM +0800, Yang Shunyong wrote:
> Existing option noverify disables both random src/dst address offset
> setup and data verification. Sometimes, we need to control random
> src/dst address setup and verification separately, such as disabling
> random to make sure that test covers addresses in all interleaving
> banks in one run. This patch adds option norandom to disable random
> offset setup. Option noverify has been changed to disable data
> verification only.

This doesn't apply for me due to dependency on previous patch. Please rebase
and resend.

-- 
~Vinod

[PATCH v21 4/4] soc: mediatek: Add Mediatek CMDQ helper

[houlong.wei]

From: "hs.l...@mediatek.com" 

Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.

Signed-off-by: Houlong Wei 
Signed-off-by: HS Liao 
---
 drivers/soc/mediatek/Kconfig   |   12 ++
 drivers/soc/mediatek/Makefile  |1 +
 drivers/soc/mediatek/mtk-cmdq-helper.c |  322 
 include/linux/soc/mediatek/mtk-cmdq.h  |  174 +
 4 files changed, 509 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
 create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index a7d0667..e66582e 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -4,6 +4,18 @@
 menu "MediaTek SoC drivers"
depends on ARCH_MEDIATEK || COMPILE_TEST
 
+config MTK_CMDQ
+   bool "MediaTek CMDQ Support"
+   depends on ARM64 && ( ARCH_MEDIATEK || COMPILE_TEST )
+   select MAILBOX
+   select MTK_CMDQ_MBOX
+   select MTK_INFRACFG
+   help
+ Say yes here to add support for the MediaTek Command Queue (CMDQ)
+ driver. The CMDQ is used to help read/write registers with critical
+ time limitation, such as updating display configuration during the
+ vblank.
+
 config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
select REGMAP
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 12998b0..64ce5ee 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
new file mode 100644
index 000..80d0558
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -0,0 +1,322 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMDQ_ARG_A_WRITE_MASK  0x
+#define CMDQ_WRITE_ENABLE_MASK BIT(0)
+#define CMDQ_EOC_IRQ_ENBIT(0)
+#define CMDQ_EOC_CMD   ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
+   << 32 | CMDQ_EOC_IRQ_EN)
+
+struct cmdq_subsys {
+   u32 base;
+   int id;
+};
+
+static const struct cmdq_subsys gce_subsys[] = {
+   {0x1400, 1},
+   {0x1401, 2},
+   {0x1402, 3},
+};
+
+static int cmdq_subsys_base_to_id(u32 base)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(gce_subsys); i++)
+   if (gce_subsys[i].base == base)
+   return gce_subsys[i].id;
+   return -EFAULT;
+}
+
+static int cmdq_pkt_realloc_cmd_buffer(struct cmdq_pkt *pkt, size_t size)
+{
+   void *new_buf;
+
+   new_buf = krealloc(pkt->va_base, size, GFP_KERNEL | __GFP_ZERO);
+   if (!new_buf)
+   return -ENOMEM;
+   pkt->va_base = new_buf;
+   pkt->buf_size = size;
+   return 0;
+}
+
+struct cmdq_base *cmdq_register_device(struct device *dev)
+{
+   struct cmdq_base *cmdq_base;
+   struct resource res;
+   int subsys;
+   u32 base;
+
+   if (of_address_to_resource(dev->of_node, 0, ))
+   return NULL;
+   base = (u32)res.start;
+
+   subsys = cmdq_subsys_base_to_id(base >> 16);
+   if (subsys < 0)
+   return NULL;
+
+   cmdq_base = devm_kmalloc(dev, sizeof(*cmdq_base), GFP_KERNEL);
+   if (!cmdq_base)
+   return NULL;
+   cmdq_base->subsys = subsys;
+   cmdq_base->base = base;
+
+   return cmdq_base;
+}
+EXPORT_SYMBOL(cmdq_register_device);
+
+struct cmdq_client *cmdq_mbox_create(struct device *dev, int index)
+{
+   struct cmdq_client *client;
+
+   client = kzalloc(sizeof(*client), GFP_KERNEL);
+   client->client.dev = dev;
+   client->client.tx_block = false;
+   client->chan = mbox_request_channel(>client, index);
+   return client;
+}
+EXPORT_SYMBOL(cmdq_mbox_create);
+
+void cmdq_mbox_destroy(struct cmdq_client *client)
+{
+   mbox_free_channel(client->chan);
+   kfree(client);
+}
+EXPORT_SYMBOL(cmdq_mbox_destroy);
+
+int cmdq_pkt_create(struct cmdq_pkt **pkt_ptr)
+{
+   struct cmdq_pkt *pkt;
+   int err;
+
+   pkt = kzalloc(sizeof(*pkt), GFP_KERNEL);
+   if (!pkt)
+   return -ENOMEM;
+   err 

[PATCH v21 4/4] soc: mediatek: Add Mediatek CMDQ helper

[houlong.wei]

From: "hs.l...@mediatek.com" 

Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code.

Signed-off-by: Houlong Wei 
Signed-off-by: HS Liao 
---
 drivers/soc/mediatek/Kconfig   |   12 ++
 drivers/soc/mediatek/Makefile  |1 +
 drivers/soc/mediatek/mtk-cmdq-helper.c |  322 
 include/linux/soc/mediatek/mtk-cmdq.h  |  174 +
 4 files changed, 509 insertions(+)
 create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
 create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index a7d0667..e66582e 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -4,6 +4,18 @@
 menu "MediaTek SoC drivers"
depends on ARCH_MEDIATEK || COMPILE_TEST
 
+config MTK_CMDQ
+   bool "MediaTek CMDQ Support"
+   depends on ARM64 && ( ARCH_MEDIATEK || COMPILE_TEST )
+   select MAILBOX
+   select MTK_CMDQ_MBOX
+   select MTK_INFRACFG
+   help
+ Say yes here to add support for the MediaTek Command Queue (CMDQ)
+ driver. The CMDQ is used to help read/write registers with critical
+ time limitation, such as updating display configuration during the
+ vblank.
+
 config MTK_INFRACFG
bool "MediaTek INFRACFG Support"
select REGMAP
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 12998b0..64ce5ee 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
 obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
 obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
 obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
new file mode 100644
index 000..80d0558
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -0,0 +1,322 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMDQ_ARG_A_WRITE_MASK  0x
+#define CMDQ_WRITE_ENABLE_MASK BIT(0)
+#define CMDQ_EOC_IRQ_ENBIT(0)
+#define CMDQ_EOC_CMD   ((u64)((CMDQ_CODE_EOC << CMDQ_OP_CODE_SHIFT)) \
+   << 32 | CMDQ_EOC_IRQ_EN)
+
+struct cmdq_subsys {
+   u32 base;
+   int id;
+};
+
+static const struct cmdq_subsys gce_subsys[] = {
+   {0x1400, 1},
+   {0x1401, 2},
+   {0x1402, 3},
+};
+
+static int cmdq_subsys_base_to_id(u32 base)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(gce_subsys); i++)
+   if (gce_subsys[i].base == base)
+   return gce_subsys[i].id;
+   return -EFAULT;
+}
+
+static int cmdq_pkt_realloc_cmd_buffer(struct cmdq_pkt *pkt, size_t size)
+{
+   void *new_buf;
+
+   new_buf = krealloc(pkt->va_base, size, GFP_KERNEL | __GFP_ZERO);
+   if (!new_buf)
+   return -ENOMEM;
+   pkt->va_base = new_buf;
+   pkt->buf_size = size;
+   return 0;
+}
+
+struct cmdq_base *cmdq_register_device(struct device *dev)
+{
+   struct cmdq_base *cmdq_base;
+   struct resource res;
+   int subsys;
+   u32 base;
+
+   if (of_address_to_resource(dev->of_node, 0, ))
+   return NULL;
+   base = (u32)res.start;
+
+   subsys = cmdq_subsys_base_to_id(base >> 16);
+   if (subsys < 0)
+   return NULL;
+
+   cmdq_base = devm_kmalloc(dev, sizeof(*cmdq_base), GFP_KERNEL);
+   if (!cmdq_base)
+   return NULL;
+   cmdq_base->subsys = subsys;
+   cmdq_base->base = base;
+
+   return cmdq_base;
+}
+EXPORT_SYMBOL(cmdq_register_device);
+
+struct cmdq_client *cmdq_mbox_create(struct device *dev, int index)
+{
+   struct cmdq_client *client;
+
+   client = kzalloc(sizeof(*client), GFP_KERNEL);
+   client->client.dev = dev;
+   client->client.tx_block = false;
+   client->chan = mbox_request_channel(>client, index);
+   return client;
+}
+EXPORT_SYMBOL(cmdq_mbox_create);
+
+void cmdq_mbox_destroy(struct cmdq_client *client)
+{
+   mbox_free_channel(client->chan);
+   kfree(client);
+}
+EXPORT_SYMBOL(cmdq_mbox_destroy);
+
+int cmdq_pkt_create(struct cmdq_pkt **pkt_ptr)
+{
+   struct cmdq_pkt *pkt;
+   int err;
+
+   pkt = kzalloc(sizeof(*pkt), GFP_KERNEL);
+   if (!pkt)
+   return -ENOMEM;
+   err = cmdq_pkt_realloc_cmd_buffer(pkt, PAGE_SIZE);
+   if (err < 0) {

[PATCH v21 3/4] arm64: dts: mt8173: Add GCE node

[houlong.wei]

From: "hs.l...@mediatek.com" 

This patch adds the device node of the GCE hardware for CMDQ module.

Signed-off-by: Houlong Wei 
Signed-off-by: HS Liao 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 26396ef..51c3d6e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -427,6 +427,16 @@
status = "disabled";
};
 
+   gce: gce@10212000 {
+   compatible = "mediatek,mt8173-gce";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_GCE>;
+   clock-names = "gce";
+
+   #mbox-cells = <2>;
+   };
+
mipi_tx0: mipi-dphy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
-- 
1.7.9.5

[PATCH v21 3/4] arm64: dts: mt8173: Add GCE node

[houlong.wei]

From: "hs.l...@mediatek.com" 

This patch adds the device node of the GCE hardware for CMDQ module.

Signed-off-by: Houlong Wei 
Signed-off-by: HS Liao 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 26396ef..51c3d6e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -427,6 +427,16 @@
status = "disabled";
};
 
+   gce: gce@10212000 {
+   compatible = "mediatek,mt8173-gce";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_GCE>;
+   clock-names = "gce";
+
+   #mbox-cells = <2>;
+   };
+
mipi_tx0: mipi-dphy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
-- 
1.7.9.5

[PATCH v21 2/4] mailbox: mediatek: Add Mediatek CMDQ driver

[houlong.wei]

From: "hs.l...@mediatek.com" 

This patch is first version of Mediatek Command Queue(CMDQ) driver. The
CMDQ is used to help write registers with critical time limitation,
such as updating display configuration during the vblank. It controls
Global Command Engine (GCE) hardware to achieve this requirement.
Currently, CMDQ only supports display related hardwares, but we expect
it can be extended to other hardwares for future requirements.

Signed-off-by: Houlong Wei 
Signed-off-by: HS Liao 
Signed-off-by: CK Hu 
---
 drivers/mailbox/Kconfig  |   10 +
 drivers/mailbox/Makefile |2 +
 drivers/mailbox/mtk-cmdq-mailbox.c   |  594 ++
 include/linux/mailbox/mtk-cmdq-mailbox.h |   77 
 4 files changed, 683 insertions(+)
 create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
 create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ba2f152..43bb26f 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -171,4 +171,14 @@ config BCM_FLEXRM_MBOX
  Mailbox implementation of the Broadcom FlexRM ring manager,
  which provides access to various offload engines on Broadcom
  SoCs. Say Y here if you want to use the Broadcom FlexRM.
+
+config MTK_CMDQ_MBOX
+   bool "MediaTek CMDQ Mailbox Support"
+   depends on ARM64 && ( ARCH_MEDIATEK || COMPILE_TEST )
+   select MTK_INFRACFG
+   help
+ Say yes here to add support for the MediaTek Command Queue (CMDQ)
+ mailbox driver. The CMDQ is used to help read/write registers with
+ critical time limitation, such as updating display configuration
+ during the vblank.
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 4896f8d..484d341 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -36,3 +36,5 @@ obj-$(CONFIG_BCM_FLEXRM_MBOX) += bcm-flexrm-mailbox.o
 obj-$(CONFIG_QCOM_APCS_IPC)+= qcom-apcs-ipc-mailbox.o
 
 obj-$(CONFIG_TEGRA_HSP_MBOX)   += tegra-hsp.o
+
+obj-$(CONFIG_MTK_CMDQ_MBOX)+= mtk-cmdq-mailbox.o
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c 
b/drivers/mailbox/mtk-cmdq-mailbox.c
new file mode 100644
index 000..394a335
--- /dev/null
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -0,0 +1,594 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMDQ_THR_MAX_COUNT 16
+#define CMDQ_OP_CODE_MASK  (0xff << CMDQ_OP_CODE_SHIFT)
+#define CMDQ_TIMEOUT_MS1000
+#define CMDQ_IRQ_MASK  0x
+#define CMDQ_NUM_CMD(t)(t->cmd_buf_size / 
CMDQ_INST_SIZE)
+
+#define CMDQ_CURR_IRQ_STATUS   0x10
+#define CMDQ_THR_SLOT_CYCLES   0x30
+
+#define CMDQ_THR_BASE  0x100
+#define CMDQ_THR_SIZE  0x80
+#define CMDQ_THR_WARM_RESET0x00
+#define CMDQ_THR_ENABLE_TASK   0x04
+#define CMDQ_THR_SUSPEND_TASK  0x08
+#define CMDQ_THR_CURR_STATUS   0x0c
+#define CMDQ_THR_IRQ_STATUS0x10
+#define CMDQ_THR_IRQ_ENABLE0x14
+#define CMDQ_THR_CURR_ADDR 0x20
+#define CMDQ_THR_END_ADDR  0x24
+#define CMDQ_THR_WAIT_TOKEN0x30
+
+#define CMDQ_THR_ENABLED   0x1
+#define CMDQ_THR_DISABLED  0x0
+#define CMDQ_THR_SUSPEND   0x1
+#define CMDQ_THR_RESUME0x0
+#define CMDQ_THR_STATUS_SUSPENDED  BIT(1)
+#define CMDQ_THR_DO_WARM_RESET BIT(0)
+#define CMDQ_THR_ACTIVE_SLOT_CYCLES0x3200
+#define CMDQ_THR_IRQ_DONE  0x1
+#define CMDQ_THR_IRQ_ERROR 0x12
+#define CMDQ_THR_IRQ_EN(CMDQ_THR_IRQ_ERROR | 
CMDQ_THR_IRQ_DONE)
+#define CMDQ_THR_IS_WAITINGBIT(31)
+
+#define CMDQ_JUMP_BY_OFFSET0x1000
+#define CMDQ_JUMP_BY_PA0x1001
+
+struct cmdq_thread {
+   struct mbox_chan*chan;
+   void __iomem*base;
+   struct list_headtask_busy_list;
+   struct timer_list   timeout;
+   boolatomic_exec;
+};
+
+struct cmdq_task {
+   struct cmdq *cmdq;
+   struct list_headlist_entry;
+   dma_addr_t  pa_base;
+ 

[PATCH v21 2/4] mailbox: mediatek: Add Mediatek CMDQ driver

[houlong.wei]

From: "hs.l...@mediatek.com" 

This patch is first version of Mediatek Command Queue(CMDQ) driver. The
CMDQ is used to help write registers with critical time limitation,
such as updating display configuration during the vblank. It controls
Global Command Engine (GCE) hardware to achieve this requirement.
Currently, CMDQ only supports display related hardwares, but we expect
it can be extended to other hardwares for future requirements.

Signed-off-by: Houlong Wei 
Signed-off-by: HS Liao 
Signed-off-by: CK Hu 
---
 drivers/mailbox/Kconfig  |   10 +
 drivers/mailbox/Makefile |2 +
 drivers/mailbox/mtk-cmdq-mailbox.c   |  594 ++
 include/linux/mailbox/mtk-cmdq-mailbox.h |   77 
 4 files changed, 683 insertions(+)
 create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
 create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ba2f152..43bb26f 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -171,4 +171,14 @@ config BCM_FLEXRM_MBOX
  Mailbox implementation of the Broadcom FlexRM ring manager,
  which provides access to various offload engines on Broadcom
  SoCs. Say Y here if you want to use the Broadcom FlexRM.
+
+config MTK_CMDQ_MBOX
+   bool "MediaTek CMDQ Mailbox Support"
+   depends on ARM64 && ( ARCH_MEDIATEK || COMPILE_TEST )
+   select MTK_INFRACFG
+   help
+ Say yes here to add support for the MediaTek Command Queue (CMDQ)
+ mailbox driver. The CMDQ is used to help read/write registers with
+ critical time limitation, such as updating display configuration
+ during the vblank.
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 4896f8d..484d341 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -36,3 +36,5 @@ obj-$(CONFIG_BCM_FLEXRM_MBOX) += bcm-flexrm-mailbox.o
 obj-$(CONFIG_QCOM_APCS_IPC)+= qcom-apcs-ipc-mailbox.o
 
 obj-$(CONFIG_TEGRA_HSP_MBOX)   += tegra-hsp.o
+
+obj-$(CONFIG_MTK_CMDQ_MBOX)+= mtk-cmdq-mailbox.o
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c 
b/drivers/mailbox/mtk-cmdq-mailbox.c
new file mode 100644
index 000..394a335
--- /dev/null
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -0,0 +1,594 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMDQ_THR_MAX_COUNT 16
+#define CMDQ_OP_CODE_MASK  (0xff << CMDQ_OP_CODE_SHIFT)
+#define CMDQ_TIMEOUT_MS1000
+#define CMDQ_IRQ_MASK  0x
+#define CMDQ_NUM_CMD(t)(t->cmd_buf_size / 
CMDQ_INST_SIZE)
+
+#define CMDQ_CURR_IRQ_STATUS   0x10
+#define CMDQ_THR_SLOT_CYCLES   0x30
+
+#define CMDQ_THR_BASE  0x100
+#define CMDQ_THR_SIZE  0x80
+#define CMDQ_THR_WARM_RESET0x00
+#define CMDQ_THR_ENABLE_TASK   0x04
+#define CMDQ_THR_SUSPEND_TASK  0x08
+#define CMDQ_THR_CURR_STATUS   0x0c
+#define CMDQ_THR_IRQ_STATUS0x10
+#define CMDQ_THR_IRQ_ENABLE0x14
+#define CMDQ_THR_CURR_ADDR 0x20
+#define CMDQ_THR_END_ADDR  0x24
+#define CMDQ_THR_WAIT_TOKEN0x30
+
+#define CMDQ_THR_ENABLED   0x1
+#define CMDQ_THR_DISABLED  0x0
+#define CMDQ_THR_SUSPEND   0x1
+#define CMDQ_THR_RESUME0x0
+#define CMDQ_THR_STATUS_SUSPENDED  BIT(1)
+#define CMDQ_THR_DO_WARM_RESET BIT(0)
+#define CMDQ_THR_ACTIVE_SLOT_CYCLES0x3200
+#define CMDQ_THR_IRQ_DONE  0x1
+#define CMDQ_THR_IRQ_ERROR 0x12
+#define CMDQ_THR_IRQ_EN(CMDQ_THR_IRQ_ERROR | 
CMDQ_THR_IRQ_DONE)
+#define CMDQ_THR_IS_WAITINGBIT(31)
+
+#define CMDQ_JUMP_BY_OFFSET0x1000
+#define CMDQ_JUMP_BY_PA0x1001
+
+struct cmdq_thread {
+   struct mbox_chan*chan;
+   void __iomem*base;
+   struct list_headtask_busy_list;
+   struct timer_list   timeout;
+   boolatomic_exec;
+};
+
+struct cmdq_task {
+   struct cmdq *cmdq;
+   struct list_headlist_entry;
+   dma_addr_t  pa_base;
+   struct cmdq_thread  *thread;
+   struct cmdq_pkt *pkt; /* the packet 

Re: [PATCH v2 2/2] ARM: dts: imx25-pinfunc: Always set SION for eSDHC CMD

[Uwe Kleine-König]

Hello Benoît,

On Wed, Jan 31, 2018 at 01:05:14AM +0100, Benoît Thébaudeau wrote:
> The eSDHC does not work properly if the SION bit is not set for the
> bidirectional CMD signal, whatever the eSDHC instance and the selected
> pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do
> this for MX25_PAD_*__ESDHCn_CMD in imx25-pinfunc.h in order to enforce
> this behavior for all boards.
> 
> This had already been done for eSDHC1, but not for eSDHC2. Also, define
> MX25_PAD_FEC_MDC__ESDHC2_CMD so that all the possible cases are covered
> from now on.
> 
> Cc: Uwe Kleine-König 
> Signed-off-by: Benoît Thébaudeau 
> Reviewed-by: Fabio Estevam 
> ---
> Changes v1 -> v2:
>  - Update eSDHC instance and port naming following the addition of "ARM:
>dts: imx25-pinfunc: Use consistent naming for eSDHC".
>  - Reference the more verbose comment for MX25_PAD_SD1_CMD__ESDHC1_CMD
>instead of copying the same less detailed comment everywhere
>(suggested by Uwe).
> ---
>  arch/arm/boot/dts/imx25-pinfunc.h | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx25-pinfunc.h 
> b/arch/arm/boot/dts/imx25-pinfunc.h
> index 2915c65a13c9..71a61c4c984f 100644
> --- a/arch/arm/boot/dts/imx25-pinfunc.h
> +++ b/arch/arm/boot/dts/imx25-pinfunc.h
> @@ -236,7 +236,8 @@
>  #define MX25_PAD_LD8__LD80x0e8 0x2e0 0x000 0x00 0x000
>  #define MX25_PAD_LD8__UART4_RXD  0x0e8 0x2e0 0x570 0x02 
> 0x000
>  #define MX25_PAD_LD8__FEC_TX_ERR 0x0e8 0x2e0 0x000 0x05 0x000
> -#define MX25_PAD_LD8__ESDHC2_CMD 0x0e8 0x2e0 0x4e0 0x06 0x000
> +/* See the comment for MX25_PAD_SD1_CMD__ESDHC1_CMD. */

I'd write:

/* SION must be set, see the comment for MX25_PAD_SD1_CMD__ESDHC1_CMD. 
*/

to at least mention SION here.

Other than that the commit looks fine.

Thanks
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH v2 2/2] ARM: dts: imx25-pinfunc: Always set SION for eSDHC CMD

[Uwe Kleine-König]

Hello Benoît,

On Wed, Jan 31, 2018 at 01:05:14AM +0100, Benoît Thébaudeau wrote:
> The eSDHC does not work properly if the SION bit is not set for the
> bidirectional CMD signal, whatever the eSDHC instance and the selected
> pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do
> this for MX25_PAD_*__ESDHCn_CMD in imx25-pinfunc.h in order to enforce
> this behavior for all boards.
> 
> This had already been done for eSDHC1, but not for eSDHC2. Also, define
> MX25_PAD_FEC_MDC__ESDHC2_CMD so that all the possible cases are covered
> from now on.
> 
> Cc: Uwe Kleine-König 
> Signed-off-by: Benoît Thébaudeau 
> Reviewed-by: Fabio Estevam 
> ---
> Changes v1 -> v2:
>  - Update eSDHC instance and port naming following the addition of "ARM:
>dts: imx25-pinfunc: Use consistent naming for eSDHC".
>  - Reference the more verbose comment for MX25_PAD_SD1_CMD__ESDHC1_CMD
>instead of copying the same less detailed comment everywhere
>(suggested by Uwe).
> ---
>  arch/arm/boot/dts/imx25-pinfunc.h | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx25-pinfunc.h 
> b/arch/arm/boot/dts/imx25-pinfunc.h
> index 2915c65a13c9..71a61c4c984f 100644
> --- a/arch/arm/boot/dts/imx25-pinfunc.h
> +++ b/arch/arm/boot/dts/imx25-pinfunc.h
> @@ -236,7 +236,8 @@
>  #define MX25_PAD_LD8__LD80x0e8 0x2e0 0x000 0x00 0x000
>  #define MX25_PAD_LD8__UART4_RXD  0x0e8 0x2e0 0x570 0x02 
> 0x000
>  #define MX25_PAD_LD8__FEC_TX_ERR 0x0e8 0x2e0 0x000 0x05 0x000
> -#define MX25_PAD_LD8__ESDHC2_CMD 0x0e8 0x2e0 0x4e0 0x06 0x000
> +/* See the comment for MX25_PAD_SD1_CMD__ESDHC1_CMD. */

I'd write:

/* SION must be set, see the comment for MX25_PAD_SD1_CMD__ESDHC1_CMD. 
*/

to at least mention SION here.

Other than that the commit looks fine.

Thanks
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

[PATCH v21 1/4] dt-bindings: soc: Add documentation for the MediaTek GCE unit

[houlong.wei]

From: "hs.l...@mediatek.com" 

This adds documentation for the MediaTek Global Command Engine (GCE) unit
found in MT8173 SoCs.

Signed-off-by: Houlong Wei 
Signed-off-by: HS Liao 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/mailbox/mtk-gce.txt|   43 
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt

diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt 
b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
new file mode 100644
index 000..d2d3ccb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
@@ -0,0 +1,43 @@
+MediaTek GCE
+===
+
+The Global Command Engine (GCE) is used to help read/write registers with
+critical time limitation, such as updating display configuration during the
+vblank. The GCE can be used to implement the Command Queue (CMDQ) driver.
+
+CMDQ driver uses mailbox framework for communication. Please refer to
+mailbox.txt for generic information about mailbox device-tree bindings.
+
+Required properties:
+- compatible: Must be "mediatek,mt8173-gce"
+- reg: Address range of the GCE unit
+- interrupts: The interrupt signal from the GCE block
+- clock: Clocks according to the common clock binding
+- clock-names: Must be "gce" to stand for GCE clock
+- #mbox-cells: Should be 2
+
+Required properties for a client device:
+- mboxes: client use mailbox to communicate with GCE, it should have this
+  property and list of phandle, mailbox channel specifiers, and atomic
+  execution flag.
+
+Example:
+
+   gce: gce@10212000 {
+   compatible = "mediatek,mt8173-gce";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_GCE>;
+   clock-names = "gce";
+
+   #mbox-cells = <2>;
+   };
+
+Example for a client device:
+
+   mmsys: clock-controller@1400 {
+   compatible = "mediatek,mt8173-mmsys";
+   mboxes = < 0 1 /* main display with atomic execution */
+  1 1>; /* sub display with atomic execution */
+   ...
+   };
-- 
1.7.9.5

[PATCH v21 1/4] dt-bindings: soc: Add documentation for the MediaTek GCE unit

[houlong.wei]

From: "hs.l...@mediatek.com" 

This adds documentation for the MediaTek Global Command Engine (GCE) unit
found in MT8173 SoCs.

Signed-off-by: Houlong Wei 
Signed-off-by: HS Liao 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/mailbox/mtk-gce.txt|   43 
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt

diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt 
b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
new file mode 100644
index 000..d2d3ccb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
@@ -0,0 +1,43 @@
+MediaTek GCE
+===
+
+The Global Command Engine (GCE) is used to help read/write registers with
+critical time limitation, such as updating display configuration during the
+vblank. The GCE can be used to implement the Command Queue (CMDQ) driver.
+
+CMDQ driver uses mailbox framework for communication. Please refer to
+mailbox.txt for generic information about mailbox device-tree bindings.
+
+Required properties:
+- compatible: Must be "mediatek,mt8173-gce"
+- reg: Address range of the GCE unit
+- interrupts: The interrupt signal from the GCE block
+- clock: Clocks according to the common clock binding
+- clock-names: Must be "gce" to stand for GCE clock
+- #mbox-cells: Should be 2
+
+Required properties for a client device:
+- mboxes: client use mailbox to communicate with GCE, it should have this
+  property and list of phandle, mailbox channel specifiers, and atomic
+  execution flag.
+
+Example:
+
+   gce: gce@10212000 {
+   compatible = "mediatek,mt8173-gce";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_GCE>;
+   clock-names = "gce";
+
+   #mbox-cells = <2>;
+   };
+
+Example for a client device:
+
+   mmsys: clock-controller@1400 {
+   compatible = "mediatek,mt8173-mmsys";
+   mboxes = < 0 1 /* main display with atomic execution */
+  1 1>; /* sub display with atomic execution */
+   ...
+   };
-- 
1.7.9.5

[PATCH v21 0/4] Mediatek MT8173 CMDQ support

[houlong.wei]

Hi,

This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
to help write registers with critical time limitation, such as
updating display configuration during the vblank. It controls Global
Command Engine (GCE) hardware to achieve this requirement.
 
Changes since v20:
 -rebase to v4.15-rc1
 -move dma_map_single outside of spinlock
Changes since v19:
 -rebase to v4.10-rc2

hs.l...@mediatek.com (4):
  dt-bindings: soc: Add documentation for the MediaTek GCE unit
  mailbox: mediatek: Add Mediatek CMDQ driver
  arm64: dts: mt8173: Add GCE node
  soc: mediatek: Add Mediatek CMDQ helper

 .../devicetree/bindings/mailbox/mtk-gce.txt|   43 ++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |   10 +
 drivers/mailbox/Kconfig|   10 +
 drivers/mailbox/Makefile   |2 +
 drivers/mailbox/mtk-cmdq-mailbox.c |  594 
 drivers/soc/mediatek/Kconfig   |   12 +
 drivers/soc/mediatek/Makefile  |1 +
 drivers/soc/mediatek/mtk-cmdq-helper.c |  322 +++
 include/linux/mailbox/mtk-cmdq-mailbox.h   |   77 +++
 include/linux/soc/mediatek/mtk-cmdq.h  |  174 ++
 10 files changed, 1245 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
 create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
 create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
 create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
 create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h

-- 
1.7.9.5 

Re: [PATCH v6 0/4] x86, kasan: add KASAN checks to atomic operations

[Ingo Molnar]

* Will Deacon  wrote:

> Hi Dmitry,
> 
> On Mon, Jan 29, 2018 at 06:26:03PM +0100, Dmitry Vyukov wrote:
> > KASAN uses compiler instrumentation to intercept all memory accesses.
> > But it does not see memory accesses done in assembly code.
> > One notable user of assembly code is atomic operations. Frequently,
> > for example, an atomic reference decrement is the last access to an
> > object and a good candidate for a racy use-after-free.
> > 
> > Atomic operations are defined in arch files, but KASAN instrumentation
> > is required for several archs that support KASAN. Later we will need
> > similar hooks for KMSAN (uninit use detector) and KTSAN (data race
> > detector).
> > 
> > This change introduces wrappers around atomic operations that can be
> > used to add KASAN/KMSAN/KTSAN instrumentation across several archs,
> > and adds KASAN checks to them.
> > 
> > This patch uses the wrappers only for x86 arch. Arm64 will be switched
> > later. And we also plan to instrument bitops in a similar way.
> 
> One way you could reduce the intrusivness for each architecture would be
> to leave the existing macro names as-is, and redefine them in the
> asm-generic header. It's certainly ugly, but it makes the porting work
> a lot smaller. Apologies if you've considered this approach before, but
> I figured it was worth mentioning just in case.
> 
> e.g. for atomic[64]_read, your asm-generic header looks like:
> 
> #ifndef _LINUX_ATOMIC_INSTRUMENTED_H
> #define _LINUX_ATOMIC_INSTRUMENTED_H
> 
> #include 
> #include 
> 
> static __always_inline int __atomic_read_instrumented(const atomic_t *v)
> {
>   kasan_check_read(v, sizeof(*v));
>   return atomic_read(v);
> }
> 
> static __always_inline s64 __atomic64_read_instrumented(const atomic64_t *v)
> {
>   kasan_check_read(v, sizeof(*v));
>   return atomic64_read(v);
> }
> 
> #undef atomic_read
> #undef atomic64_read
> 
> #define atomic_read   __atomic_read_instrumented
> #define atomic64_read __atomic64_read_instrumented
> 
> #endif /* _LINUX_ATOMIC_INSTRUMENTED_H */
> 
> and the arch code just includes that in asm/atomic.h once it's done with
> its definitions.
> 
> What do you think? Too stinky?

Hm, so while this could work - I actually *like* the low level changes: they 
are 
straightforward, trivial, easy to read and they add the arch_ prefix that makes 
it 
abundantly clear that this isn't the highest level interface.

The KASAN callbacks in the generic methods are also abundantly clear and very 
easy 
to read. I could literally verify the sanity of the series while still being 
only 
half awake. ;-)

Also note that the arch renaming should be 'trivial', in the sense that any 
missing rename results in a clear build breakage. Plus any architecture making 
use 
of this new KASAN feature should probably be tested before it's enabled - and 
the 
renaming of the low level atomic APIs kind of forces that too.

So while this approach creates some churn, this series is IMHO a marked 
improvement over the previous iterations.

Thanks,

Ingo

[PATCH v21 0/4] Mediatek MT8173 CMDQ support

[houlong.wei]

Hi,

This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
to help write registers with critical time limitation, such as
updating display configuration during the vblank. It controls Global
Command Engine (GCE) hardware to achieve this requirement.
 
Changes since v20:
 -rebase to v4.15-rc1
 -move dma_map_single outside of spinlock
Changes since v19:
 -rebase to v4.10-rc2

hs.l...@mediatek.com (4):
  dt-bindings: soc: Add documentation for the MediaTek GCE unit
  mailbox: mediatek: Add Mediatek CMDQ driver
  arm64: dts: mt8173: Add GCE node
  soc: mediatek: Add Mediatek CMDQ helper

 .../devicetree/bindings/mailbox/mtk-gce.txt|   43 ++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |   10 +
 drivers/mailbox/Kconfig|   10 +
 drivers/mailbox/Makefile   |2 +
 drivers/mailbox/mtk-cmdq-mailbox.c |  594 
 drivers/soc/mediatek/Kconfig   |   12 +
 drivers/soc/mediatek/Makefile  |1 +
 drivers/soc/mediatek/mtk-cmdq-helper.c |  322 +++
 include/linux/mailbox/mtk-cmdq-mailbox.h   |   77 +++
 include/linux/soc/mediatek/mtk-cmdq.h  |  174 ++
 10 files changed, 1245 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
 create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
 create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
 create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
 create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h

-- 
1.7.9.5 

Re: [PATCH v6 0/4] x86, kasan: add KASAN checks to atomic operations

[Ingo Molnar]

* Will Deacon  wrote:

> Hi Dmitry,
> 
> On Mon, Jan 29, 2018 at 06:26:03PM +0100, Dmitry Vyukov wrote:
> > KASAN uses compiler instrumentation to intercept all memory accesses.
> > But it does not see memory accesses done in assembly code.
> > One notable user of assembly code is atomic operations. Frequently,
> > for example, an atomic reference decrement is the last access to an
> > object and a good candidate for a racy use-after-free.
> > 
> > Atomic operations are defined in arch files, but KASAN instrumentation
> > is required for several archs that support KASAN. Later we will need
> > similar hooks for KMSAN (uninit use detector) and KTSAN (data race
> > detector).
> > 
> > This change introduces wrappers around atomic operations that can be
> > used to add KASAN/KMSAN/KTSAN instrumentation across several archs,
> > and adds KASAN checks to them.
> > 
> > This patch uses the wrappers only for x86 arch. Arm64 will be switched
> > later. And we also plan to instrument bitops in a similar way.
> 
> One way you could reduce the intrusivness for each architecture would be
> to leave the existing macro names as-is, and redefine them in the
> asm-generic header. It's certainly ugly, but it makes the porting work
> a lot smaller. Apologies if you've considered this approach before, but
> I figured it was worth mentioning just in case.
> 
> e.g. for atomic[64]_read, your asm-generic header looks like:
> 
> #ifndef _LINUX_ATOMIC_INSTRUMENTED_H
> #define _LINUX_ATOMIC_INSTRUMENTED_H
> 
> #include 
> #include 
> 
> static __always_inline int __atomic_read_instrumented(const atomic_t *v)
> {
>   kasan_check_read(v, sizeof(*v));
>   return atomic_read(v);
> }
> 
> static __always_inline s64 __atomic64_read_instrumented(const atomic64_t *v)
> {
>   kasan_check_read(v, sizeof(*v));
>   return atomic64_read(v);
> }
> 
> #undef atomic_read
> #undef atomic64_read
> 
> #define atomic_read   __atomic_read_instrumented
> #define atomic64_read __atomic64_read_instrumented
> 
> #endif /* _LINUX_ATOMIC_INSTRUMENTED_H */
> 
> and the arch code just includes that in asm/atomic.h once it's done with
> its definitions.
> 
> What do you think? Too stinky?

Hm, so while this could work - I actually *like* the low level changes: they 
are 
straightforward, trivial, easy to read and they add the arch_ prefix that makes 
it 
abundantly clear that this isn't the highest level interface.

The KASAN callbacks in the generic methods are also abundantly clear and very 
easy 
to read. I could literally verify the sanity of the series while still being 
only 
half awake. ;-)

Also note that the arch renaming should be 'trivial', in the sense that any 
missing rename results in a clear build breakage. Plus any architecture making 
use 
of this new KASAN feature should probably be tested before it's enabled - and 
the 
renaming of the low level atomic APIs kind of forces that too.

So while this approach creates some churn, this series is IMHO a marked 
improvement over the previous iterations.

Thanks,

Ingo

Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

[Maxime Ripard]

Hi Thierry,

On Tue, Jan 30, 2018 at 11:01:50AM +0100, Thierry Reding wrote:
> On Tue, Jan 30, 2018 at 10:59:16AM +0100, Thierry Reding wrote:
> > On Tue, Jan 30, 2018 at 10:24:48AM +0100, Arnd Bergmann wrote:
> > > On Tue, Jan 30, 2018 at 8:54 AM, Maxime Ripard
> > >  wrote:
> > > > On Mon, Jan 29, 2018 at 03:34:02PM +0100, Arnd Bergmann wrote:
> > > >> On Mon, Jan 29, 2018 at 10:25 AM, Linus Walleij
> > > >>  wrote:
> > > >> > On Mon, Jan 29, 2018 at 9:25 AM, Maxime Ripard
> > > >> >  wrote:
> > > >> >> On Sat, Jan 27, 2018 at 05:14:26PM +0100, Linus Walleij wrote:
> > > 
> > > >>
> > > >> At one point we had discussed adding a 'dma-masters' property that
> > > >> lists all the buses on which a device can be a dma master, and
> > > >> the respective properties of those masters (iommu, coherency,
> > > >> offset, ...).
> > > >>
> > > >> IIRC at the time we decided that we could live without that complexity,
> > > >> but perhaps we cannot.
> > > >
> > > > Are you talking about this ?
> > > > https://elixir.free-electrons.com/linux/latest/source/Documentation/devicetree/bindings/dma/dma.txt#L41
> > > >
> > > > It doesn't seem to be related to that issue to me. And in our
> > > > particular cases, all the devices are DMA masters, the RAM is just
> > > > mapped to another address.
> > > 
> > > No, that's not the one I was thinking of. The idea at the time was much
> > > more generic, and not limited to dma engines. I don't recall the details,
> > > but I think that Thierry was either involved or made the proposal at the
> > > time.
> > 
> > Yeah, I vaguely remember discussing something like this before. A quick
> > search through my inbox yielded these two threads, mostly related to
> > IOMMU but I think there were some mentions about dma-ranges and so on as
> > well. I'll have to dig deeper into those threads to refresh my memories,
> > but I won't get around to it until later today.
> > 
> > If someone wants to read up on this in the meantime, here are the links:
> > 
> > https://lkml.org/lkml/2014/4/27/346
> > 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/257200.html
> > 
> > From a quick glance the issue of dma-ranges was something that we hand-
> > waved at the time.
> 
> Also found this, which seems to be relevant as well:
> 
>   
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/252715.html
> 
> Adding Dave.

Thanks for the pointers, I started to read through it.

I guess we have to come up with two solutions here: a short term one
to address the users we already have in the kernel properly, and a
long term one where we could use that discussion as a starting point.

For the short term one, could we just set the device dma_pfn_offset to
PHYS_OFFSET at probe time, and use our dma_addr_t directly later on,
or would this also cause some issues?

For the long term plan, from what I read from the discussion, it's
mostly centered around IOMMU indeed, and we don't have that. What we
would actually need is to break the assumption that the DMA "parent"
bus is the DT node's parent bus.

And I guess this could be done quite easily by adding a dma-parent
property with a phandle to the bus controller, that would have a
dma-ranges property of its own with the proper mapping described
there. It should be simple enough to support, but is there anything
that could prevent something like that to work properly (such as
preventing further IOMMU-related developments that were described in
those mail threads).

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

[Maxime Ripard]

Hi Thierry,

On Tue, Jan 30, 2018 at 11:01:50AM +0100, Thierry Reding wrote:
> On Tue, Jan 30, 2018 at 10:59:16AM +0100, Thierry Reding wrote:
> > On Tue, Jan 30, 2018 at 10:24:48AM +0100, Arnd Bergmann wrote:
> > > On Tue, Jan 30, 2018 at 8:54 AM, Maxime Ripard
> > >  wrote:
> > > > On Mon, Jan 29, 2018 at 03:34:02PM +0100, Arnd Bergmann wrote:
> > > >> On Mon, Jan 29, 2018 at 10:25 AM, Linus Walleij
> > > >>  wrote:
> > > >> > On Mon, Jan 29, 2018 at 9:25 AM, Maxime Ripard
> > > >> >  wrote:
> > > >> >> On Sat, Jan 27, 2018 at 05:14:26PM +0100, Linus Walleij wrote:
> > > 
> > > >>
> > > >> At one point we had discussed adding a 'dma-masters' property that
> > > >> lists all the buses on which a device can be a dma master, and
> > > >> the respective properties of those masters (iommu, coherency,
> > > >> offset, ...).
> > > >>
> > > >> IIRC at the time we decided that we could live without that complexity,
> > > >> but perhaps we cannot.
> > > >
> > > > Are you talking about this ?
> > > > https://elixir.free-electrons.com/linux/latest/source/Documentation/devicetree/bindings/dma/dma.txt#L41
> > > >
> > > > It doesn't seem to be related to that issue to me. And in our
> > > > particular cases, all the devices are DMA masters, the RAM is just
> > > > mapped to another address.
> > > 
> > > No, that's not the one I was thinking of. The idea at the time was much
> > > more generic, and not limited to dma engines. I don't recall the details,
> > > but I think that Thierry was either involved or made the proposal at the
> > > time.
> > 
> > Yeah, I vaguely remember discussing something like this before. A quick
> > search through my inbox yielded these two threads, mostly related to
> > IOMMU but I think there were some mentions about dma-ranges and so on as
> > well. I'll have to dig deeper into those threads to refresh my memories,
> > but I won't get around to it until later today.
> > 
> > If someone wants to read up on this in the meantime, here are the links:
> > 
> > https://lkml.org/lkml/2014/4/27/346
> > 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/257200.html
> > 
> > From a quick glance the issue of dma-ranges was something that we hand-
> > waved at the time.
> 
> Also found this, which seems to be relevant as well:
> 
>   
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/252715.html
> 
> Adding Dave.

Thanks for the pointers, I started to read through it.

I guess we have to come up with two solutions here: a short term one
to address the users we already have in the kernel properly, and a
long term one where we could use that discussion as a starting point.

For the short term one, could we just set the device dma_pfn_offset to
PHYS_OFFSET at probe time, and use our dma_addr_t directly later on,
or would this also cause some issues?

For the long term plan, from what I read from the discussion, it's
mostly centered around IOMMU indeed, and we don't have that. What we
would actually need is to break the assumption that the DMA "parent"
bus is the DT node's parent bus.

And I guess this could be done quite easily by adding a dma-parent
property with a phandle to the bus controller, that would have a
dma-ranges property of its own with the proper mapping described
there. It should be simple enough to support, but is there anything
that could prevent something like that to work properly (such as
preventing further IOMMU-related developments that were described in
those mail threads).

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: WARNING in refcount_inc (2)

[Eric Biggers]

On Tue, Dec 19, 2017 at 11:26:01AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> audit: type=1400 audit(1513711436.700:7): avc:  denied  { map } for
> pid=3124 comm="syzkaller396275" path="/root/syzkaller396275826" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> [ cut here ]
> refcount_t: increment on 0; use-after-free.
> WARNING: CPU: 1 PID: 3125 at lib/refcount.c:153 refcount_inc+0x47/0x50
> lib/refcount.c:153
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 1 PID: 3125 Comm: syzkaller396275 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0xe9/0x14b lib/dump_stack.c:53
>  panic+0x10e/0x2f8 kernel/panic.c:183
>  __warn+0x14e/0x150 kernel/panic.c:547
>  report_bug+0x11e/0x1a0 lib/bug.c:184
>  fixup_bug.part.11+0x17/0x30 arch/x86/kernel/traps.c:177
>  fixup_bug arch/x86/kernel/traps.c:246 [inline]
>  do_error_trap+0x14a/0x180 arch/x86/kernel/traps.c:295
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
>  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
> RIP: 0010:refcount_inc+0x47/0x50 lib/refcount.c:153
> RSP: 0018:c9000186bb90 EFLAGS: 00010282
> RAX: 002b RBX: 880214e2f800 RCX: 8123dede
> RDX:  RSI: 880214d5f018 RDI: 0293
> RBP: c9000186bb98 R08:  R09: 
> R10: c9000186bb18 R11:  R12: 8162ef10
> R13: 8802156d2578 R14: 8802156d2600 R15: 0001
>  get_ipc_ns include/linux/ipc_namespace.h:129 [inline]
>  __get_ns_from_inode ipc/mqueue.c:110 [inline]
>  get_ns_from_inode ipc/mqueue.c:118 [inline]
>  mqueue_evict_inode+0x69/0x340 ipc/mqueue.c:402
>  evict+0x102/0x230 fs/inode.c:552
>  iput_final fs/inode.c:1514 [inline]
>  iput+0x32b/0x400 fs/inode.c:1541
>  dentry_unlink_inode+0x1ab/0x1e0 fs/dcache.c:375
>  __dentry_kill+0x12d/0x210 fs/dcache.c:572
>  shrink_dentry_list+0x140/0x660 fs/dcache.c:1019
>  shrink_dcache_parent+0x2f/0x90 fs/dcache.c:1453
>  do_one_tree+0x15/0x50 fs/dcache.c:1484
>  shrink_dcache_for_umount+0x37/0xb0 fs/dcache.c:1501
>  generic_shutdown_super+0x2d/0x170 fs/super.c:424
>  kill_anon_super fs/super.c:987 [inline]
>  kill_litter_super+0x36/0x50 fs/super.c:997
>  deactivate_locked_super+0x4d/0x80 fs/super.c:312
>  deactivate_super+0x61/0x90 fs/super.c:343
>  cleanup_mnt+0x49/0x90 fs/namespace.c:1173
>  __cleanup_mnt+0x16/0x20 fs/namespace.c:1180
>  task_work_run+0xa3/0xe0 kernel/task_work.c:113
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0x3e6/0x1050 kernel/exit.c:869
>  do_group_exit+0x60/0x100 kernel/exit.c:972
>  SYSC_exit_group kernel/exit.c:983 [inline]
>  SyS_exit_group+0x18/0x20 kernel/exit.c:981
>  entry_SYSCALL_64_fastpath+0x1f/0x96

I'm not able to reproduce this anymore.  Looks like it was another report of the
bug in the patch "ipc, mqueue: lazy call kern_mount_data in new namespaces"
which was present in linux-next for a while but was replaced by "mqueue: switch
to on-demand creation of internal mount" which no longer has the bug.

This report was also on the linux-next version where KASAN had accidentally
gotten disabled in the syzbot config.

So, I'm invalidating this bug so that syzbot can report similar crashes again:

#syz invalid

Also Dmitry, syzbot seems to be grouping together unrelated bugs under the
refcount_t WARNINGs; maybe those should be on a blacklist?

- Eric

Re: WARNING in refcount_inc (2)

[Eric Biggers]

On Tue, Dec 19, 2017 at 11:26:01AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> audit: type=1400 audit(1513711436.700:7): avc:  denied  { map } for
> pid=3124 comm="syzkaller396275" path="/root/syzkaller396275826" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> [ cut here ]
> refcount_t: increment on 0; use-after-free.
> WARNING: CPU: 1 PID: 3125 at lib/refcount.c:153 refcount_inc+0x47/0x50
> lib/refcount.c:153
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 1 PID: 3125 Comm: syzkaller396275 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0xe9/0x14b lib/dump_stack.c:53
>  panic+0x10e/0x2f8 kernel/panic.c:183
>  __warn+0x14e/0x150 kernel/panic.c:547
>  report_bug+0x11e/0x1a0 lib/bug.c:184
>  fixup_bug.part.11+0x17/0x30 arch/x86/kernel/traps.c:177
>  fixup_bug arch/x86/kernel/traps.c:246 [inline]
>  do_error_trap+0x14a/0x180 arch/x86/kernel/traps.c:295
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
>  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
> RIP: 0010:refcount_inc+0x47/0x50 lib/refcount.c:153
> RSP: 0018:c9000186bb90 EFLAGS: 00010282
> RAX: 002b RBX: 880214e2f800 RCX: 8123dede
> RDX:  RSI: 880214d5f018 RDI: 0293
> RBP: c9000186bb98 R08:  R09: 
> R10: c9000186bb18 R11:  R12: 8162ef10
> R13: 8802156d2578 R14: 8802156d2600 R15: 0001
>  get_ipc_ns include/linux/ipc_namespace.h:129 [inline]
>  __get_ns_from_inode ipc/mqueue.c:110 [inline]
>  get_ns_from_inode ipc/mqueue.c:118 [inline]
>  mqueue_evict_inode+0x69/0x340 ipc/mqueue.c:402
>  evict+0x102/0x230 fs/inode.c:552
>  iput_final fs/inode.c:1514 [inline]
>  iput+0x32b/0x400 fs/inode.c:1541
>  dentry_unlink_inode+0x1ab/0x1e0 fs/dcache.c:375
>  __dentry_kill+0x12d/0x210 fs/dcache.c:572
>  shrink_dentry_list+0x140/0x660 fs/dcache.c:1019
>  shrink_dcache_parent+0x2f/0x90 fs/dcache.c:1453
>  do_one_tree+0x15/0x50 fs/dcache.c:1484
>  shrink_dcache_for_umount+0x37/0xb0 fs/dcache.c:1501
>  generic_shutdown_super+0x2d/0x170 fs/super.c:424
>  kill_anon_super fs/super.c:987 [inline]
>  kill_litter_super+0x36/0x50 fs/super.c:997
>  deactivate_locked_super+0x4d/0x80 fs/super.c:312
>  deactivate_super+0x61/0x90 fs/super.c:343
>  cleanup_mnt+0x49/0x90 fs/namespace.c:1173
>  __cleanup_mnt+0x16/0x20 fs/namespace.c:1180
>  task_work_run+0xa3/0xe0 kernel/task_work.c:113
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0x3e6/0x1050 kernel/exit.c:869
>  do_group_exit+0x60/0x100 kernel/exit.c:972
>  SYSC_exit_group kernel/exit.c:983 [inline]
>  SyS_exit_group+0x18/0x20 kernel/exit.c:981
>  entry_SYSCALL_64_fastpath+0x1f/0x96

I'm not able to reproduce this anymore.  Looks like it was another report of the
bug in the patch "ipc, mqueue: lazy call kern_mount_data in new namespaces"
which was present in linux-next for a while but was replaced by "mqueue: switch
to on-demand creation of internal mount" which no longer has the bug.

This report was also on the linux-next version where KASAN had accidentally
gotten disabled in the syzbot config.

So, I'm invalidating this bug so that syzbot can report similar crashes again:

#syz invalid

Also Dmitry, syzbot seems to be grouping together unrelated bugs under the
refcount_t WARNINGs; maybe those should be on a blacklist?

- Eric

Re: [PATCH v2 1/2] ARM: dts: imx25-pinfunc: Use consistent naming for eSDHC

[Uwe Kleine-König]

Hello,

On Wed, Jan 31, 2018 at 01:05:13AM +0100, Benoît Thébaudeau wrote:
> This file had several naming inconsistencies for eSDHC:
>  - the instances were named sometimes SDn, sometimes SDHCn, whereas they
>are named ESDHCn in the reference manual, e.g.:
>  MX25_PAD_SD1_CMD__SD1_CMD
>  MX25_PAD_D15__SDHC1_DAT7
>  - the data ports were named sometimes DATAn, sometimes DATn like in the
>reference manual, e.g.:
>  MX25_PAD_SD1_DATA0__SD1_DATA0
>  MX25_PAD_D15__SDHC1_DAT7
>  - in one case, the clock port was named DAT_CLK instead of CLK:
>  MX25_PAD_CSI_D7__SDHC2_DAT_CLK
> 
> This change:
>  - introduces new definitions using the naming from the reference
>manual,
>  - keeps definitions using the legacy naming in order not to break
>compatibility for out-of-tree users (they can be removed later),
>  - updates the in-tree files that were using the legacy naming.
> 
> Cc: Uwe Kleine-König 
> Signed-off-by: Benoît Thébaudeau 
> ---
> Changes v1 -> v2:
>  - New patch (suggested by Uwe).
That's why I like it:

Acked-by: Uwe Kleine-König 

:-)
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH v2 1/2] ARM: dts: imx25-pinfunc: Use consistent naming for eSDHC

[Uwe Kleine-König]

Hello,

On Wed, Jan 31, 2018 at 01:05:13AM +0100, Benoît Thébaudeau wrote:
> This file had several naming inconsistencies for eSDHC:
>  - the instances were named sometimes SDn, sometimes SDHCn, whereas they
>are named ESDHCn in the reference manual, e.g.:
>  MX25_PAD_SD1_CMD__SD1_CMD
>  MX25_PAD_D15__SDHC1_DAT7
>  - the data ports were named sometimes DATAn, sometimes DATn like in the
>reference manual, e.g.:
>  MX25_PAD_SD1_DATA0__SD1_DATA0
>  MX25_PAD_D15__SDHC1_DAT7
>  - in one case, the clock port was named DAT_CLK instead of CLK:
>  MX25_PAD_CSI_D7__SDHC2_DAT_CLK
> 
> This change:
>  - introduces new definitions using the naming from the reference
>manual,
>  - keeps definitions using the legacy naming in order not to break
>compatibility for out-of-tree users (they can be removed later),
>  - updates the in-tree files that were using the legacy naming.
> 
> Cc: Uwe Kleine-König 
> Signed-off-by: Benoît Thébaudeau 
> ---
> Changes v1 -> v2:
>  - New patch (suggested by Uwe).
That's why I like it:

Acked-by: Uwe Kleine-König 

:-)
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

[PATCH net] e1000e: Remove Other from EIAC.

[Benjamin Poirier]

It was reported that emulated e1000e devices in vmware esxi 6.5 Build
7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver
overrun interrupt bursts", v4.15-rc1). Some tracing shows that after
e1000e_trigger_lsc() is called, ICR reads out as 0x0 in e1000_msix_other()
on emulated e1000e devices. In comparison, on real e1000e 82574 hardware,
icr=0x8004 (_INT_ASSERTED | _LSC) in the same situation.

Some experimentation showed that this flaw in vmware e1000e emulation can
be worked around by not setting Other in EIAC. This is how it was before
16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1).

Fixes: 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts")
Signed-off-by: Benjamin Poirier 
---
 drivers/net/ethernet/intel/e1000e/netdev.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 9f18d39bdc8f..625a4c9a86a4 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -1918,6 +1918,8 @@ static irqreturn_t e1000_msix_other(int __always_unused 
irq, void *data)
bool enable = true;
 
icr = er32(ICR);
+   ew32(ICR, E1000_ICR_OTHER);
+
if (icr & E1000_ICR_RXO) {
ew32(ICR, E1000_ICR_RXO);
enable = false;
@@ -2040,7 +2042,6 @@ static void e1000_configure_msix(struct e1000_adapter 
*adapter)
   hw->hw_addr + E1000_EITR_82574(vector));
else
writel(1, hw->hw_addr + E1000_EITR_82574(vector));
-   adapter->eiac_mask |= E1000_IMS_OTHER;
 
/* Cause Tx interrupts on every write back */
ivar |= BIT(31);
@@ -2265,7 +2266,7 @@ static void e1000_irq_enable(struct e1000_adapter 
*adapter)
 
if (adapter->msix_entries) {
ew32(EIAC_82574, adapter->eiac_mask & E1000_EIAC_MASK_82574);
-   ew32(IMS, adapter->eiac_mask | E1000_IMS_LSC);
+   ew32(IMS, adapter->eiac_mask | E1000_IMS_OTHER | E1000_IMS_LSC);
} else if (hw->mac.type >= e1000_pch_lpt) {
ew32(IMS, IMS_ENABLE_MASK | E1000_IMS_ECCER);
} else {
-- 
2.15.1

[PATCH net] e1000e: Remove Other from EIAC.

[Benjamin Poirier]

It was reported that emulated e1000e devices in vmware esxi 6.5 Build
7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver
overrun interrupt bursts", v4.15-rc1). Some tracing shows that after
e1000e_trigger_lsc() is called, ICR reads out as 0x0 in e1000_msix_other()
on emulated e1000e devices. In comparison, on real e1000e 82574 hardware,
icr=0x8004 (_INT_ASSERTED | _LSC) in the same situation.

Some experimentation showed that this flaw in vmware e1000e emulation can
be worked around by not setting Other in EIAC. This is how it was before
16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1).

Fixes: 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts")
Signed-off-by: Benjamin Poirier 
---
 drivers/net/ethernet/intel/e1000e/netdev.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 9f18d39bdc8f..625a4c9a86a4 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -1918,6 +1918,8 @@ static irqreturn_t e1000_msix_other(int __always_unused 
irq, void *data)
bool enable = true;
 
icr = er32(ICR);
+   ew32(ICR, E1000_ICR_OTHER);
+
if (icr & E1000_ICR_RXO) {
ew32(ICR, E1000_ICR_RXO);
enable = false;
@@ -2040,7 +2042,6 @@ static void e1000_configure_msix(struct e1000_adapter 
*adapter)
   hw->hw_addr + E1000_EITR_82574(vector));
else
writel(1, hw->hw_addr + E1000_EITR_82574(vector));
-   adapter->eiac_mask |= E1000_IMS_OTHER;
 
/* Cause Tx interrupts on every write back */
ivar |= BIT(31);
@@ -2265,7 +2266,7 @@ static void e1000_irq_enable(struct e1000_adapter 
*adapter)
 
if (adapter->msix_entries) {
ew32(EIAC_82574, adapter->eiac_mask & E1000_EIAC_MASK_82574);
-   ew32(IMS, adapter->eiac_mask | E1000_IMS_LSC);
+   ew32(IMS, adapter->eiac_mask | E1000_IMS_OTHER | E1000_IMS_LSC);
} else if (hw->mac.type >= e1000_pch_lpt) {
ew32(IMS, IMS_ENABLE_MASK | E1000_IMS_ECCER);
} else {
-- 
2.15.1

Re: BUG: unable to handle kernel NULL pointer dereference in sctp_stream_free

[Marcelo Ricardo Leitner]

On Tue, Jan 30, 2018 at 03:03:50PM -0800, Eric Biggers wrote:
> On Fri, Dec 22, 2017 at 01:31:26PM +0800, Xin Long wrote:
> > On Thu, Dec 21, 2017 at 9:13 PM, Marcelo Ricardo Leitner
> >  wrote:
> > > On Wed, Dec 20, 2017 at 12:51:01PM -0800, syzbot wrote:
> > >
> > > from the log:
> > > [   89.451366] FAULT_INJECTION: forcing a failure.^M
> > > [   89.451366] name failslab, interval 1, probability 0, space 0,
> > > times 0^M
> > > [   89.451374] CPU: 0 PID: 17287 Comm: syz-executor2 Not tainted
> > > +4.15.0-rc3-next-20171214+ #67^M
> > > [   89.451377] Hardware name: Google Google Compute Engine/Google
> > > Compute Engine, BIOS
> > > +Google 01/01/2011^M
> > > [   89.451380] Call Trace:^M
> > > [   89.451395]  dump_stack+0xe9/0x14b^M
> > > [   89.451408]  should_fail+0x1e5/0x220^M
> > > [   89.451419]  should_failslab+0x73/0x90^M
> > > [   89.451428]  __kmalloc+0x63/0x730^M
> > > [   89.451439]  ? rcu_read_lock_sched_held+0x74/0x80^M
> > > [   89.451446]  ? __kmalloc+0x4ac/0x730^M
> > > [   89.451452]  ? sctp_stream_alloc_in+0x2f/0x100^M
> > > [   89.451464]  sctp_stream_alloc_in+0x2f/0x100^M
> > > [   89.451473]  sctp_stream_init+0xfa/0x140^M
> > > [   89.451485]  sctp_process_init+0x676/0xc50^M
> > >
> > > this is what caused the panic later, because in the error path we free
> > > out but don't zero outcnt. This patch should fix it. Can you please
> > > try it? Thanks
> > >
> > > 8<---
> > >
> > > diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> > > index 06b644dd858c..50ab09029f00 100644
> > > --- a/net/sctp/stream.c
> > > +++ b/net/sctp/stream.c
> > > @@ -184,6 +184,7 @@ int sctp_stream_init(struct sctp_stream *stream, 
> > > __u16 outcnt, __u16 incnt,
> > > sched->free(stream);
> > > kfree(stream->out);
> > > stream->out = NULL;
> > > +   stream->outcnt = 0;
> > >  out:
> > > return ret;
> > >  }
> > 
> > In case it can't be verified due to no reproducer yet, I modified some
> > code in sctp_stream_init() to confirm Marcelo's deduction:
> > -   i = sctp_stream_alloc_in(stream, incnt, gfp);
> > +   i = 1;
> > if (i) {
> > ret = -ENOMEM;
> > goto free;
> > 
> > And got the same call trace as the mail:
> > 
> > [  301.488065] BUG: unable to handle kernel NULL pointer dereference
> > at 0008
> > [  301.488618] IP: sctp_stream_free+0x2c/0x60 [sctp]
> > [  301.488928] PGD 59a3b067 P4D 59a3b067 PUD 5994e067 PMD 0
> > [  301.489372] Oops:  [#1] SMP
> > [...]
> > [  301.497647] Call Trace:
> > [  301.497812]  
> > [  301.497955]  sctp_association_free+0xb8/0x210 [sctp]
> > [  301.498306]  sctp_sf_do_5_1B_init+0x1c4/0x360 [sctp]
> > [  301.498654]  sctp_do_sm+0x9a/0x2d0 [sctp]
> > [  301.498921]  ? sctp_has_association+0x130/0x130 [sctp]
> > [  301.499301]  ? kernel_text_address+0xba/0xe0
> > [  301.499615]  ? check_usage_backwards+0x88/0x150
> > [  301.499911]  ? __lock_acquire+0x280/0x1080
> > [  301.500200]  ? sctp_endpoint_lookup_assoc+0x95/0x140 [sctp]
> > [  301.500593]  sctp_endpoint_bh_rcv+0x11e/0x220 [sctp]
> > [  301.500923]  sctp_rcv+0x9f5/0xbe0 [sctp]
> > 
> > And Marcelo's patch could fix it.
> > 
> > Since the "free:" part only works for if (i), maybe the patch can also do:
> > if (i) {
> > sched->free(stream);
> > kfree(stream->out);
> > stream->out = NULL;
> > stream->outcnt = 0;
> > 
> > ret = -ENOMEM;
> > goto out;
> > }
> > 
> > and remove the "free:" path.
> 
> This crash seems to have stopped occurring now.  I presume it was fixed by the
> following commit, so let's tell syzbot to close the bug:

Yes, thanks Eric.

> 
> #syz fix: sctp: fix error path in sctp_stream_init

Re: BUG: unable to handle kernel NULL pointer dereference in sctp_stream_free

[Marcelo Ricardo Leitner]

On Tue, Jan 30, 2018 at 03:03:50PM -0800, Eric Biggers wrote:
> On Fri, Dec 22, 2017 at 01:31:26PM +0800, Xin Long wrote:
> > On Thu, Dec 21, 2017 at 9:13 PM, Marcelo Ricardo Leitner
> >  wrote:
> > > On Wed, Dec 20, 2017 at 12:51:01PM -0800, syzbot wrote:
> > >
> > > from the log:
> > > [   89.451366] FAULT_INJECTION: forcing a failure.^M
> > > [   89.451366] name failslab, interval 1, probability 0, space 0,
> > > times 0^M
> > > [   89.451374] CPU: 0 PID: 17287 Comm: syz-executor2 Not tainted
> > > +4.15.0-rc3-next-20171214+ #67^M
> > > [   89.451377] Hardware name: Google Google Compute Engine/Google
> > > Compute Engine, BIOS
> > > +Google 01/01/2011^M
> > > [   89.451380] Call Trace:^M
> > > [   89.451395]  dump_stack+0xe9/0x14b^M
> > > [   89.451408]  should_fail+0x1e5/0x220^M
> > > [   89.451419]  should_failslab+0x73/0x90^M
> > > [   89.451428]  __kmalloc+0x63/0x730^M
> > > [   89.451439]  ? rcu_read_lock_sched_held+0x74/0x80^M
> > > [   89.451446]  ? __kmalloc+0x4ac/0x730^M
> > > [   89.451452]  ? sctp_stream_alloc_in+0x2f/0x100^M
> > > [   89.451464]  sctp_stream_alloc_in+0x2f/0x100^M
> > > [   89.451473]  sctp_stream_init+0xfa/0x140^M
> > > [   89.451485]  sctp_process_init+0x676/0xc50^M
> > >
> > > this is what caused the panic later, because in the error path we free
> > > out but don't zero outcnt. This patch should fix it. Can you please
> > > try it? Thanks
> > >
> > > 8<---
> > >
> > > diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> > > index 06b644dd858c..50ab09029f00 100644
> > > --- a/net/sctp/stream.c
> > > +++ b/net/sctp/stream.c
> > > @@ -184,6 +184,7 @@ int sctp_stream_init(struct sctp_stream *stream, 
> > > __u16 outcnt, __u16 incnt,
> > > sched->free(stream);
> > > kfree(stream->out);
> > > stream->out = NULL;
> > > +   stream->outcnt = 0;
> > >  out:
> > > return ret;
> > >  }
> > 
> > In case it can't be verified due to no reproducer yet, I modified some
> > code in sctp_stream_init() to confirm Marcelo's deduction:
> > -   i = sctp_stream_alloc_in(stream, incnt, gfp);
> > +   i = 1;
> > if (i) {
> > ret = -ENOMEM;
> > goto free;
> > 
> > And got the same call trace as the mail:
> > 
> > [  301.488065] BUG: unable to handle kernel NULL pointer dereference
> > at 0008
> > [  301.488618] IP: sctp_stream_free+0x2c/0x60 [sctp]
> > [  301.488928] PGD 59a3b067 P4D 59a3b067 PUD 5994e067 PMD 0
> > [  301.489372] Oops:  [#1] SMP
> > [...]
> > [  301.497647] Call Trace:
> > [  301.497812]  
> > [  301.497955]  sctp_association_free+0xb8/0x210 [sctp]
> > [  301.498306]  sctp_sf_do_5_1B_init+0x1c4/0x360 [sctp]
> > [  301.498654]  sctp_do_sm+0x9a/0x2d0 [sctp]
> > [  301.498921]  ? sctp_has_association+0x130/0x130 [sctp]
> > [  301.499301]  ? kernel_text_address+0xba/0xe0
> > [  301.499615]  ? check_usage_backwards+0x88/0x150
> > [  301.499911]  ? __lock_acquire+0x280/0x1080
> > [  301.500200]  ? sctp_endpoint_lookup_assoc+0x95/0x140 [sctp]
> > [  301.500593]  sctp_endpoint_bh_rcv+0x11e/0x220 [sctp]
> > [  301.500923]  sctp_rcv+0x9f5/0xbe0 [sctp]
> > 
> > And Marcelo's patch could fix it.
> > 
> > Since the "free:" part only works for if (i), maybe the patch can also do:
> > if (i) {
> > sched->free(stream);
> > kfree(stream->out);
> > stream->out = NULL;
> > stream->outcnt = 0;
> > 
> > ret = -ENOMEM;
> > goto out;
> > }
> > 
> > and remove the "free:" path.
> 
> This crash seems to have stopped occurring now.  I presume it was fixed by the
> following commit, so let's tell syzbot to close the bug:

Yes, thanks Eric.

> 
> #syz fix: sctp: fix error path in sctp_stream_init

Re: 4.15: WARNING: CPU: 3 PID: 258 at kernel/irq/chip.c:244 __irq_startup+0x80/0x100

[Meelis Roos]

> > Your supply of vintage hardware is amazing.

:-)

> Does the patch below fix the issue for you?

  CC  kernel/irq/autoprobe.o
kernel/irq/autoprobe.c: In function ‘probe_irq_on’:
kernel/irq/autoprobe.c:74:8: error: void value not ignored as it ought to be
if (irq_activate_and_startup(desc, IRQ_NORESEND))
^~~~
Just 
irq_activate_and_startup(desc, IRQ_NORESEND);

cures the warning and at least the first bootup was working otherwise 
too.

-- 
Meelis Roos (mr...@linux.ee)

Re: 4.15: WARNING: CPU: 3 PID: 258 at kernel/irq/chip.c:244 __irq_startup+0x80/0x100

[Meelis Roos]

> > Your supply of vintage hardware is amazing.

:-)

> Does the patch below fix the issue for you?

  CC  kernel/irq/autoprobe.o
kernel/irq/autoprobe.c: In function ‘probe_irq_on’:
kernel/irq/autoprobe.c:74:8: error: void value not ignored as it ought to be
if (irq_activate_and_startup(desc, IRQ_NORESEND))
^~~~
Just 
irq_activate_and_startup(desc, IRQ_NORESEND);

cures the warning and at least the first bootup was working otherwise 
too.

-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH] Documentation/process: kernel maintainer PGP guide

[Jani Nikula]

On Tue, 30 Jan 2018, Konstantin Ryabitsev  
wrote:
> This guide is an adapted version of the more general "Protecting Code
> Integrity" guide written and maintained by The Linux Foundation IT for
> use with open-source projects. It provides the oft-lacking guidance on
> the following topics:
>
> - how to properly protect one's PGP keys to minimize the risks of them
>   being stolen and used maliciously to impersonate a kernel developer
> - how to configure Git to properly use GnuPG
> - when and how to use PGP with Git
> - how to verify fellow Linux Kernel developer identities
>
> I believe this document should live with the rest of the documentation
> describing proper processes one should follow when participating in
> kernel development. Placing it in a wiki on some place like kernel.org
> would be insufficient for a number of reasons -- primarily, because only
> a relatively small subset of maintainers have accounts on kernel.org,
> but also because even those who do rarely remember that such wiki
> exists. Keeping it with the rest of in-kernel docs should hopefully give
> it more visibility, but also help keep it up-to-date as tools and
> processes evolve.

FWIW, agreed on having this with the kernel documentation.

I can't say I reviewed it, but glancing through I didn't spot any errors
either. Lots of good stuff.

Just one nit, I think it would be better to move the Maintainer: bit
from the end near the top as a reStructuredText field list. See 'git
grep :Author:' under Documentation for examples. Could even add a
MAINTAINERS entry to improve your chances of being Cc'd on changes.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] Documentation/process: kernel maintainer PGP guide

[Jani Nikula]

On Tue, 30 Jan 2018, Konstantin Ryabitsev  
wrote:
> This guide is an adapted version of the more general "Protecting Code
> Integrity" guide written and maintained by The Linux Foundation IT for
> use with open-source projects. It provides the oft-lacking guidance on
> the following topics:
>
> - how to properly protect one's PGP keys to minimize the risks of them
>   being stolen and used maliciously to impersonate a kernel developer
> - how to configure Git to properly use GnuPG
> - when and how to use PGP with Git
> - how to verify fellow Linux Kernel developer identities
>
> I believe this document should live with the rest of the documentation
> describing proper processes one should follow when participating in
> kernel development. Placing it in a wiki on some place like kernel.org
> would be insufficient for a number of reasons -- primarily, because only
> a relatively small subset of maintainers have accounts on kernel.org,
> but also because even those who do rarely remember that such wiki
> exists. Keeping it with the rest of in-kernel docs should hopefully give
> it more visibility, but also help keep it up-to-date as tools and
> processes evolve.

FWIW, agreed on having this with the kernel documentation.

I can't say I reviewed it, but glancing through I didn't spot any errors
either. Lots of good stuff.

Just one nit, I think it would be better to move the Maintainer: bit
from the end near the top as a reStructuredText field list. See 'git
grep :Author:' under Documentation for examples. Could even add a
MAINTAINERS entry to improve your chances of being Cc'd on changes.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

[Chunming Zhou]

Hi Roger,

I think this patch isn't need at all. You can directly read 
total_swap_pages variable in TTM. See the comment:


/* protected with swap_lock. reading in vm_swap_full() doesn't need lock */
long total_swap_pages;

there are many places using it directly, you just couldn't change its 
value. Reading it doesn't need lock.



Regards,

David Zhou


On 2018年01月29日 16:29, Roger He wrote:

ttm module needs it to determine its internal parameter setting.

Signed-off-by: Roger He 
---
  include/linux/swap.h |  6 ++
  mm/swapfile.c| 15 +++
  2 files changed, 21 insertions(+)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index c2b8128..708d66f 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -484,6 +484,7 @@ extern int try_to_free_swap(struct page *);
  struct backing_dev_info;
  extern int init_swap_address_space(unsigned int type, unsigned long nr_pages);
  extern void exit_swap_address_space(unsigned int type);
+extern long get_total_swap_pages(void);
  
  #else /* CONFIG_SWAP */
  
@@ -516,6 +517,11 @@ static inline void show_swap_cache_info(void)

  {
  }
  
+long get_total_swap_pages(void)

+{
+   return 0;
+}
+
  #define free_swap_and_cache(e) ({(is_migration_entry(e) || 
is_device_private_entry(e));})
  #define swapcache_prepare(e) ({(is_migration_entry(e) || 
is_device_private_entry(e));})
  
diff --git a/mm/swapfile.c b/mm/swapfile.c

index 3074b02..a0062eb 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -98,6 +98,21 @@ static atomic_t proc_poll_event = ATOMIC_INIT(0);
  
  atomic_t nr_rotate_swap = ATOMIC_INIT(0);
  
+/*

+ * expose this value for others use
+ */
+long get_total_swap_pages(void)
+{
+   long ret;
+
+   spin_lock(_lock);
+   ret = total_swap_pages;
+   spin_unlock(_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(get_total_swap_pages);
+
  static inline unsigned char swap_count(unsigned char ent)
  {
return ent & ~SWAP_HAS_CACHE;   /* may include SWAP_HAS_CONT flag */

Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages

[Chunming Zhou]

Hi Roger,

I think this patch isn't need at all. You can directly read 
total_swap_pages variable in TTM. See the comment:


/* protected with swap_lock. reading in vm_swap_full() doesn't need lock */
long total_swap_pages;

there are many places using it directly, you just couldn't change its 
value. Reading it doesn't need lock.



Regards,

David Zhou


On 2018年01月29日 16:29, Roger He wrote:

ttm module needs it to determine its internal parameter setting.

Signed-off-by: Roger He 
---
  include/linux/swap.h |  6 ++
  mm/swapfile.c| 15 +++
  2 files changed, 21 insertions(+)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index c2b8128..708d66f 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -484,6 +484,7 @@ extern int try_to_free_swap(struct page *);
  struct backing_dev_info;
  extern int init_swap_address_space(unsigned int type, unsigned long nr_pages);
  extern void exit_swap_address_space(unsigned int type);
+extern long get_total_swap_pages(void);
  
  #else /* CONFIG_SWAP */
  
@@ -516,6 +517,11 @@ static inline void show_swap_cache_info(void)

  {
  }
  
+long get_total_swap_pages(void)

+{
+   return 0;
+}
+
  #define free_swap_and_cache(e) ({(is_migration_entry(e) || 
is_device_private_entry(e));})
  #define swapcache_prepare(e) ({(is_migration_entry(e) || 
is_device_private_entry(e));})
  
diff --git a/mm/swapfile.c b/mm/swapfile.c

index 3074b02..a0062eb 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -98,6 +98,21 @@ static atomic_t proc_poll_event = ATOMIC_INIT(0);
  
  atomic_t nr_rotate_swap = ATOMIC_INIT(0);
  
+/*

+ * expose this value for others use
+ */
+long get_total_swap_pages(void)
+{
+   long ret;
+
+   spin_lock(_lock);
+   ret = total_swap_pages;
+   spin_unlock(_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(get_total_swap_pages);
+
  static inline unsigned char swap_count(unsigned char ent)
  {
return ent & ~SWAP_HAS_CACHE;   /* may include SWAP_HAS_CONT flag */

Re: [PATCH 2/2] f2fs: support {d,id,did,x}node checksum

[Chao Yu]

On 2018/1/31 10:02, Jaegeuk Kim wrote:
> What if we want to add more entries in addition to node_checksum? Do we have
> to add a new feature flag at every time? How about adding a layout value 
> instead

Hmm.. for previous implementation, IMO, we'd better add a new feature flag at
every time, otherwise, w/ extra_nsize only, in current image, we can know a
valid range of extended area in node block, but we don't know which
fields/features are valid/enabled or not.

One more thing is that if we can add one feature flag for each field, we got one
more chance to disable it dynamically.

> of extra_nsize? For example, layout #1 means node_checksum with extra_nsize=X?
> 
> 
> What does 1017 mean? We need to make this structure more flexibly for new

Yes, using raw 1017 is not appropriate here.

> entries. Like this?
>   union {
>   struct node_v1;
>   struct node_v2;
>   struct node_v3;
>   ...
>   struct direct_node dn;
>   struct indirect_node in;
>   };
>   };
> 
>   struct node_v1 {
>   __le32 data[DEF_ADDRS_PER_BLOCK - V1_NSIZE=1];
>   __le32 node_checksum;
>   }
> 
>   struct node_v2 {
>   __le32 data[DEF_ADDRS_PER_BLOCK - V2_NSIZE=500];

Hmm.. If we only need to add one more 4 bytes field in struct node_v2, but
V2_NSIZE is defined as fixed 500, there must be 492 bytes wasted.

Or we can define V2_NSIZE as 8, but if there comes more and more extended
fields, node version count can be a large number, it results in complicated
version recognization and handling.

One more question is how can we control which fields are valid or not in
comp[Vx_NSIZE]?


Anyway, what I'm thinking is maybe we can restructure layout of node block like
the one used by f2fs_inode:

struct f2fs_node {
union {
struct f2fs_inode i;
union {
struct {
__le32 node_checksum;
__le32 feature_field_1;
__le32 feature_field_2;

__le32 addr[];

};
struct direct_node dn;
struct indirect_node in;
};
};
struct node_footer footer;
} __packed;

Moving all extended fields to the head of f2fs_node, so we don't have to use
macro to indicate actual size of addr.

Thanks,

>   __le32 comp[V2_NSIZE];
>   }
>   ...
> 
>> +};
>> +struct direct_node dn;
>> +struct indirect_node in;
>> +};
>>  };
>>  struct node_footer footer;
>>  } __packed;
>> -- 
>> 2.15.0.55.gc2ece9dc4de6
> 
> .
> 

Re: [PATCH 2/2] f2fs: support {d,id,did,x}node checksum

[Chao Yu]

On 2018/1/31 10:02, Jaegeuk Kim wrote:
> What if we want to add more entries in addition to node_checksum? Do we have
> to add a new feature flag at every time? How about adding a layout value 
> instead

Hmm.. for previous implementation, IMO, we'd better add a new feature flag at
every time, otherwise, w/ extra_nsize only, in current image, we can know a
valid range of extended area in node block, but we don't know which
fields/features are valid/enabled or not.

One more thing is that if we can add one feature flag for each field, we got one
more chance to disable it dynamically.

> of extra_nsize? For example, layout #1 means node_checksum with extra_nsize=X?
> 
> 
> What does 1017 mean? We need to make this structure more flexibly for new

Yes, using raw 1017 is not appropriate here.

> entries. Like this?
>   union {
>   struct node_v1;
>   struct node_v2;
>   struct node_v3;
>   ...
>   struct direct_node dn;
>   struct indirect_node in;
>   };
>   };
> 
>   struct node_v1 {
>   __le32 data[DEF_ADDRS_PER_BLOCK - V1_NSIZE=1];
>   __le32 node_checksum;
>   }
> 
>   struct node_v2 {
>   __le32 data[DEF_ADDRS_PER_BLOCK - V2_NSIZE=500];

Hmm.. If we only need to add one more 4 bytes field in struct node_v2, but
V2_NSIZE is defined as fixed 500, there must be 492 bytes wasted.

Or we can define V2_NSIZE as 8, but if there comes more and more extended
fields, node version count can be a large number, it results in complicated
version recognization and handling.

One more question is how can we control which fields are valid or not in
comp[Vx_NSIZE]?


Anyway, what I'm thinking is maybe we can restructure layout of node block like
the one used by f2fs_inode:

struct f2fs_node {
union {
struct f2fs_inode i;
union {
struct {
__le32 node_checksum;
__le32 feature_field_1;
__le32 feature_field_2;

__le32 addr[];

};
struct direct_node dn;
struct indirect_node in;
};
};
struct node_footer footer;
} __packed;

Moving all extended fields to the head of f2fs_node, so we don't have to use
macro to indicate actual size of addr.

Thanks,

>   __le32 comp[V2_NSIZE];
>   }
>   ...
> 
>> +};
>> +struct direct_node dn;
>> +struct indirect_node in;
>> +};
>>  };
>>  struct node_footer footer;
>>  } __packed;
>> -- 
>> 2.15.0.55.gc2ece9dc4de6
> 
> .
> 

[PATCH] binder: check for binder_thread allocation failure in binder_poll()

[Eric Biggers]

From: Eric Biggers 

If the kzalloc() in binder_get_thread() fails, binder_poll()
dereferences the resulting NULL pointer.

Fix it by returning POLLERR if the memory allocation failed.

This bug was found by syzkaller using fault injection.

Reported-by: syzbot 
Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers 
---
 drivers/android/binder.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index d21040c5d343f..326ca8ea9ebcf 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -4391,6 +4391,8 @@ static __poll_t binder_poll(struct file *filp,
bool wait_for_proc_work;
 
thread = binder_get_thread(proc);
+   if (!thread)
+   return POLLERR;
 
binder_inner_proc_lock(thread->proc);
thread->looper |= BINDER_LOOPER_STATE_POLL;
-- 
2.16.1

[PATCH] binder: check for binder_thread allocation failure in binder_poll()

[Eric Biggers]

From: Eric Biggers 

If the kzalloc() in binder_get_thread() fails, binder_poll()
dereferences the resulting NULL pointer.

Fix it by returning POLLERR if the memory allocation failed.

This bug was found by syzkaller using fault injection.

Reported-by: syzbot 
Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers 
---
 drivers/android/binder.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index d21040c5d343f..326ca8ea9ebcf 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -4391,6 +4391,8 @@ static __poll_t binder_poll(struct file *filp,
bool wait_for_proc_work;
 
thread = binder_get_thread(proc);
+   if (!thread)
+   return POLLERR;
 
binder_inner_proc_lock(thread->proc);
thread->looper |= BINDER_LOOPER_STATE_POLL;
-- 
2.16.1

Re: [PATCH v11 0/3] mm, x86, powerpc: Enhancements to Memory Protection Keys.

[Ingo Molnar]

* Ram Pai  wrote:

> This patch series provides arch-neutral enhancements to
> enable memory-keys on new architecutes, and the corresponding
> changes in x86 and powerpc specific code to support that.
> 
> a) Provides ability to support upto 32 keys.  PowerPC
>   can handle 32 keys and hence needs this.
> 
> b) Arch-neutral code; and not the arch-specific code,
>determines the format of the string, that displays the key
>for each vma in smaps.
> 
> PowerPC implementation of memory-keys is now in powerpc/next tree.
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=next=92e3da3cf193fd27996909956c12a23c0333da44

All three patches look sane to me. If you would like to carry these generic 
bits 
in the PowerPC tree as well then:

  Reviewed-by: Ingo Molnar 

Thanks,

Ingo

Re: [PATCH v11 0/3] mm, x86, powerpc: Enhancements to Memory Protection Keys.

[Ingo Molnar]

* Ram Pai  wrote:

> This patch series provides arch-neutral enhancements to
> enable memory-keys on new architecutes, and the corresponding
> changes in x86 and powerpc specific code to support that.
> 
> a) Provides ability to support upto 32 keys.  PowerPC
>   can handle 32 keys and hence needs this.
> 
> b) Arch-neutral code; and not the arch-specific code,
>determines the format of the string, that displays the key
>for each vma in smaps.
> 
> PowerPC implementation of memory-keys is now in powerpc/next tree.
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=next=92e3da3cf193fd27996909956c12a23c0333da44

All three patches look sane to me. If you would like to carry these generic 
bits 
in the PowerPC tree as well then:

  Reviewed-by: Ingo Molnar 

Thanks,

Ingo

Re: [tip:x86/pti] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

[Dominik Brodowski]

On Tue, Jan 30, 2018 at 02:39:45PM -0800, tip-bot for Tim Chen wrote:
> Commit-ID:  18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7
> Gitweb: 
> https://git.kernel.org/tip/18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7
> Author: Tim Chen 
> AuthorDate: Mon, 29 Jan 2018 22:04:47 +
> Committer:  Thomas Gleixner 
> CommitDate: Tue, 30 Jan 2018 23:09:21 +0100
> 
> x86/speculation: Use Indirect Branch Prediction Barrier in context switch
> 
> Flush indirect branches when switching into a process that marked itself
> non dumpable. This protects high value processes like gpg better,
> without having too high performance overhead.

For the record, I am still opposed to limit this to non-dumpable processes.
Whether a process needs protection by IBPB on context switches is a
different question to whether a process should be allowed to be dumped,
though the former may be a superset of the latter. In my opinion, IBPB
should be enabled on all context switches to userspace processes, until we
have a clear mitigation strategy for userspace against Spectre-v2 designed
and implemented.

Thanks,
Dominik

--
From: Dominik Brodowski 
Date: Wed, 31 Jan 2018 07:43:12 +0100
Subject: [PATCH] x86/speculation: Do not limit Indirect Branch Prediction 
Barrier to non-dumpable processes

Whether a process needs protection by IBPB on context switches is a
different question to whether a process should be allowed to be dumped,
though the former may be a superset of the latter. Enable IBPB on all
context switches to a different userspace process, until we have a clear
mitigation strategy for userspace against Spectre-v2 designed and
implemented.

Signed-off-by: Dominik Brodowski 

diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 012d02624848..f54897b68b16 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -255,19 +255,13 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct 
mm_struct *next,
 * predictor when switching between processes. This stops
 * one process from doing Spectre-v2 attacks on another.
 *
-* As an optimization, flush indirect branches only when
-* switching into processes that disable dumping. This
-* protects high value processes like gpg, without having
-* too high performance overhead. IBPB is *expensive*!
-*
 * This will not flush branches when switching into kernel
 * threads. It will also not flush if we switch to idle
 * thread and back to the same process. It will flush if we
-* switch to a different non-dumpable process.
+* switch to a different user process.
 */
if (tsk && tsk->mm &&
-   tsk->mm->context.ctx_id != last_ctx_id &&
-   get_dumpable(tsk->mm) != SUID_DUMP_USER)
+   tsk->mm->context.ctx_id != last_ctx_id)
indirect_branch_prediction_barrier();
 
if (IS_ENABLED(CONFIG_VMAP_STACK)) {

Re: [tip:x86/pti] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

[Dominik Brodowski]

On Tue, Jan 30, 2018 at 02:39:45PM -0800, tip-bot for Tim Chen wrote:
> Commit-ID:  18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7
> Gitweb: 
> https://git.kernel.org/tip/18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7
> Author: Tim Chen 
> AuthorDate: Mon, 29 Jan 2018 22:04:47 +
> Committer:  Thomas Gleixner 
> CommitDate: Tue, 30 Jan 2018 23:09:21 +0100
> 
> x86/speculation: Use Indirect Branch Prediction Barrier in context switch
> 
> Flush indirect branches when switching into a process that marked itself
> non dumpable. This protects high value processes like gpg better,
> without having too high performance overhead.

For the record, I am still opposed to limit this to non-dumpable processes.
Whether a process needs protection by IBPB on context switches is a
different question to whether a process should be allowed to be dumped,
though the former may be a superset of the latter. In my opinion, IBPB
should be enabled on all context switches to userspace processes, until we
have a clear mitigation strategy for userspace against Spectre-v2 designed
and implemented.

Thanks,
Dominik

--
From: Dominik Brodowski 
Date: Wed, 31 Jan 2018 07:43:12 +0100
Subject: [PATCH] x86/speculation: Do not limit Indirect Branch Prediction 
Barrier to non-dumpable processes

Whether a process needs protection by IBPB on context switches is a
different question to whether a process should be allowed to be dumped,
though the former may be a superset of the latter. Enable IBPB on all
context switches to a different userspace process, until we have a clear
mitigation strategy for userspace against Spectre-v2 designed and
implemented.

Signed-off-by: Dominik Brodowski 

diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 012d02624848..f54897b68b16 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -255,19 +255,13 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct 
mm_struct *next,
 * predictor when switching between processes. This stops
 * one process from doing Spectre-v2 attacks on another.
 *
-* As an optimization, flush indirect branches only when
-* switching into processes that disable dumping. This
-* protects high value processes like gpg, without having
-* too high performance overhead. IBPB is *expensive*!
-*
 * This will not flush branches when switching into kernel
 * threads. It will also not flush if we switch to idle
 * thread and back to the same process. It will flush if we
-* switch to a different non-dumpable process.
+* switch to a different user process.
 */
if (tsk && tsk->mm &&
-   tsk->mm->context.ctx_id != last_ctx_id &&
-   get_dumpable(tsk->mm) != SUID_DUMP_USER)
+   tsk->mm->context.ctx_id != last_ctx_id)
indirect_branch_prediction_barrier();
 
if (IS_ENABLED(CONFIG_VMAP_STACK)) {

Re: [PATCH 1/8] thermal/drivers/cpu_cooling: Fixup the header and copyright

[Daniel Lezcano]

On 31/01/2018 06:17, Viresh Kumar wrote:
> On 23-01-18, 16:34, Daniel Lezcano wrote:
>> The copyright format does not conform to the format requested by
>> Linaro: https://wiki.linaro.org/Copyright
>>
>> Fix it.
>>
>> Signed-off-by: Daniel Lezcano 
>> ---
>>  drivers/thermal/cpu_cooling.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
>> index dc63aba..988fc55 100644
>> --- a/drivers/thermal/cpu_cooling.c
>> +++ b/drivers/thermal/cpu_cooling.c
>> @@ -2,9 +2,11 @@
>>   *  linux/drivers/thermal/cpu_cooling.c
>>   *
>>   *  Copyright (C) 2012  Samsung Electronics Co., 
>> Ltd(http://www.samsung.com)
>> - *  Copyright (C) 2012  Amit Daniel 
>>   *
>> - *  Copyright (C) 2014  Viresh Kumar 
>> + *  Copyright (C) 2018 Linaro Limited.
>> + *
> 
> Shouldn't this be 2012-2018 ?

Yes, you are right.



-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 1/8] thermal/drivers/cpu_cooling: Fixup the header and copyright

[Daniel Lezcano]

On 31/01/2018 06:17, Viresh Kumar wrote:
> On 23-01-18, 16:34, Daniel Lezcano wrote:
>> The copyright format does not conform to the format requested by
>> Linaro: https://wiki.linaro.org/Copyright
>>
>> Fix it.
>>
>> Signed-off-by: Daniel Lezcano 
>> ---
>>  drivers/thermal/cpu_cooling.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
>> index dc63aba..988fc55 100644
>> --- a/drivers/thermal/cpu_cooling.c
>> +++ b/drivers/thermal/cpu_cooling.c
>> @@ -2,9 +2,11 @@
>>   *  linux/drivers/thermal/cpu_cooling.c
>>   *
>>   *  Copyright (C) 2012  Samsung Electronics Co., 
>> Ltd(http://www.samsung.com)
>> - *  Copyright (C) 2012  Amit Daniel 
>>   *
>> - *  Copyright (C) 2014  Viresh Kumar 
>> + *  Copyright (C) 2018 Linaro Limited.
>> + *
> 
> Shouldn't this be 2012-2018 ?

Yes, you are right.



-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: BUG: unable to handle kernel NULL pointer dereference in binder_poll

[Eric Biggers]

On Mon, Dec 18, 2017 at 08:23:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> RAX: ffda RBX: 0001 RCX: 00444119
> RDX: 0004 RSI: 0001 RDI: 0003
> RBP: 0005 R08: 0001 R09: 0032
> R10: 207a6000 R11: 0246 R12: 00401e60
> R13: 00401ef0 R14:  R15: 
> BUG: unable to handle kernel NULL pointer dereference at   (null)
> IP: binder_poll+0x28/0xf0 drivers/android/binder.c:4371
> PGD 2134c1067 P4D 2134c1067 PUD 214180067 PMD 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 3117 Comm: syzkaller406906 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:binder_poll+0x28/0xf0 drivers/android/binder.c:4371
> RSP: 0018:c900017d3df0 EFLAGS: 00010286
> RAX:  RBX: c900017d3ef0 RCX: 820258f3
> RDX:  RSI: 83080700 RDI: 0286
> RBP: c900017d3e20 R08:  R09: 
> R10:  R11:  R12: c900017d3ef0
> R13: 8802118fb000 R14: 82bb9f20 R15: 8802140d1c30
> FS:  00deb880() GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 000216bbc002 CR4: 001606f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  ep_item_poll.isra.10+0x49/0xf0 fs/eventpoll.c:885
>  ep_insert fs/eventpoll.c:1457 [inline]
>  SYSC_epoll_ctl fs/eventpoll.c:2104 [inline]
>  SyS_epoll_ctl+0x884/0x1010 fs/eventpoll.c:1990
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x444119
> RSP: 002b:7fffbc6b55b8 EFLAGS: 0246 ORIG_RAX: 00e9
> RAX: ffda RBX: 0001 RCX: 00444119
> RDX: 0004 RSI: 0001 RDI: 0003
> RBP: 0005 R08: 0001 R09: 0032
> R10: 207a6000 R11: 0246 R12: 00401e60
> R13: 00401ef0 R14:  R15: 
> Code: ff 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 fd 53 49 89 f4 48
> 83 ec 08 e8 24 49 29 ff 49 8b bd 90 01 00 00 e8 78 fd ff ff <48> 8b 38 48 89
> c3 be 15 11 00 00 e8 e8 7e ff ff 44 8b 73 34 44
> RIP: binder_poll+0x28/0xf0 drivers/android/binder.c:4371 RSP:
> c900017d3df0
> CR2: 

Duplicate of:

#syz dup: general protection fault in binder_poll

Re: BUG: unable to handle kernel NULL pointer dereference in binder_poll

[Eric Biggers]

On Mon, Dec 18, 2017 at 08:23:01AM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 6084b576dca2e898f5c101baef151f7bfdbb606d
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> RAX: ffda RBX: 0001 RCX: 00444119
> RDX: 0004 RSI: 0001 RDI: 0003
> RBP: 0005 R08: 0001 R09: 0032
> R10: 207a6000 R11: 0246 R12: 00401e60
> R13: 00401ef0 R14:  R15: 
> BUG: unable to handle kernel NULL pointer dereference at   (null)
> IP: binder_poll+0x28/0xf0 drivers/android/binder.c:4371
> PGD 2134c1067 P4D 2134c1067 PUD 214180067 PMD 0
> Oops:  [#1] SMP
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 3117 Comm: syzkaller406906 Not tainted 4.15.0-rc3-next-20171214+
> #67
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:binder_poll+0x28/0xf0 drivers/android/binder.c:4371
> RSP: 0018:c900017d3df0 EFLAGS: 00010286
> RAX:  RBX: c900017d3ef0 RCX: 820258f3
> RDX:  RSI: 83080700 RDI: 0286
> RBP: c900017d3e20 R08:  R09: 
> R10:  R11:  R12: c900017d3ef0
> R13: 8802118fb000 R14: 82bb9f20 R15: 8802140d1c30
> FS:  00deb880() GS:88021fc0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 000216bbc002 CR4: 001606f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  ep_item_poll.isra.10+0x49/0xf0 fs/eventpoll.c:885
>  ep_insert fs/eventpoll.c:1457 [inline]
>  SYSC_epoll_ctl fs/eventpoll.c:2104 [inline]
>  SyS_epoll_ctl+0x884/0x1010 fs/eventpoll.c:1990
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x444119
> RSP: 002b:7fffbc6b55b8 EFLAGS: 0246 ORIG_RAX: 00e9
> RAX: ffda RBX: 0001 RCX: 00444119
> RDX: 0004 RSI: 0001 RDI: 0003
> RBP: 0005 R08: 0001 R09: 0032
> R10: 207a6000 R11: 0246 R12: 00401e60
> R13: 00401ef0 R14:  R15: 
> Code: ff 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 fd 53 49 89 f4 48
> 83 ec 08 e8 24 49 29 ff 49 8b bd 90 01 00 00 e8 78 fd ff ff <48> 8b 38 48 89
> c3 be 15 11 00 00 e8 e8 7e ff ff 44 8b 73 34 44
> RIP: binder_poll+0x28/0xf0 drivers/android/binder.c:4371 RSP:
> c900017d3df0
> CR2: 

Duplicate of:

#syz dup: general protection fault in binder_poll

[PATCH] kbuild/gcc-plugin: drop randomize_layout_hash.h from targets

[Cao jin]

randomize_layout_hash.h is not used in plugin compilation, but locates in
include/generated/

Signed-off-by: Cao jin 
---
 scripts/gcc-plugins/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile
index e2ff425f4c7e..d3fff33cc996 100644
--- a/scripts/gcc-plugins/Makefile
+++ b/scripts/gcc-plugins/Makefile
@@ -25,7 +25,7 @@ cmd_create_randomize_layout_seed = \
   $(CONFIG_SHELL) $(srctree)/$(src)/gen-random-seed.sh $@ 
$(objtree)/include/generated/randomize_layout_hash.h
 $(objtree)/$(obj)/randomize_layout_seed.h: FORCE
$(call if_changed,create_randomize_layout_seed)
-targets = randomize_layout_seed.h randomize_layout_hash.h
+targets = randomize_layout_seed.h
 
 $(HOSTLIBS)-y := $(foreach p,$(GCC_PLUGIN),$(if $(findstring /,$(p)),,$(p)))
 always := $($(HOSTLIBS)-y)
-- 
2.14.3

[PATCH] kbuild/gcc-plugin: drop randomize_layout_hash.h from targets

[Cao jin]

randomize_layout_hash.h is not used in plugin compilation, but locates in
include/generated/

Signed-off-by: Cao jin 
---
 scripts/gcc-plugins/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile
index e2ff425f4c7e..d3fff33cc996 100644
--- a/scripts/gcc-plugins/Makefile
+++ b/scripts/gcc-plugins/Makefile
@@ -25,7 +25,7 @@ cmd_create_randomize_layout_seed = \
   $(CONFIG_SHELL) $(srctree)/$(src)/gen-random-seed.sh $@ 
$(objtree)/include/generated/randomize_layout_hash.h
 $(objtree)/$(obj)/randomize_layout_seed.h: FORCE
$(call if_changed,create_randomize_layout_seed)
-targets = randomize_layout_seed.h randomize_layout_hash.h
+targets = randomize_layout_seed.h
 
 $(HOSTLIBS)-y := $(foreach p,$(GCC_PLUGIN),$(if $(findstring /,$(p)),,$(p)))
 always := $($(HOSTLIBS)-y)
-- 
2.14.3

Re: [PATCH v3 0/4] KVM: Expose speculation control feature to guests

[Dave Hansen]

On 01/30/2018 04:16 PM, Paolo Bonzini wrote:
> On 30/01/2018 18:48, Raj, Ashok wrote:
>>> Certainly not every vmexit!  But doing it on every userspace vmexit and
>>> every sched_out would not be *that* bad.
>> Right.. agreed. We discussed the different scenarios that doing IBPB
>> on VMexit would help, and decided its really not required on every exit. 
>>
>> One obvious case is when there is a VMexit and return back to Qemu
>> process (witout a real context switch) do we need that to be 
>> protected from any poisoned BTB from guest?
> If the host is using retpolines, then some kind of barrier is needed.  I
> don't know if the full PRED_CMD barrier is needed, or two IBRS=1/IBRS=0
> writes back-to-back are enough.

I think the spec is pretty clear here: protection is only provided
*while* IBRS=1.  Once it goes back to 0, all bets are off.

Re: [PATCH v3 0/4] KVM: Expose speculation control feature to guests

[Dave Hansen]

On 01/30/2018 04:16 PM, Paolo Bonzini wrote:
> On 30/01/2018 18:48, Raj, Ashok wrote:
>>> Certainly not every vmexit!  But doing it on every userspace vmexit and
>>> every sched_out would not be *that* bad.
>> Right.. agreed. We discussed the different scenarios that doing IBPB
>> on VMexit would help, and decided its really not required on every exit. 
>>
>> One obvious case is when there is a VMexit and return back to Qemu
>> process (witout a real context switch) do we need that to be 
>> protected from any poisoned BTB from guest?
> If the host is using retpolines, then some kind of barrier is needed.  I
> don't know if the full PRED_CMD barrier is needed, or two IBRS=1/IBRS=0
> writes back-to-back are enough.

I think the spec is pretty clear here: protection is only provided
*while* IBRS=1.  Once it goes back to 0, all bets are off.

[GIT PULL] s390 patches for the 4.15 merge window

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

Bug fixes, small improvements and one notable change:

 * The system call table and the unistd.h header are now generated
   automatically with a shell script from a text file.

Christophe JAILLET (1):
  s390/dasd: Simplify code

Eugene Syromiatnikov (1):
  s390: fix handling of -1 in set{,fs}[gu]id16 syscalls

Heiko Carstens (1):
  s390: remove bogus system call table entries

Hendrik Brueckner (8):
  s390/kernel: emit CFI data in .debug_frame and discard .eh_frame sections
  s390/vdso: revise CFI annotations of vDSO functions
  s390/disassembler: add generated gen_opcode_table tool to .gitignore
  s390/syscalls: add system call table
  s390/syscalls: add syscalltbl script
  s390/syscalls: add Makefile to generate system call header files
  s390/syscalls: use generated syscall_table.h and unistd.h header files
  s390/tools: generate header files in arch/s390/include/generated/

Jan Höppner (1):
  s390/dasd: Remove dead return code checks

Pravin Shedge (1):
  s390/kprobes: remove duplicate includes

Vasily Gorbik (5):
  s390/head: replace hard coded values with constants
  s390/ipl: avoid usage of __section(.data)
  s390/sclp: fix .data section specification
  s390/decompressor: swap .text and .rodata.compressed sections
  s390/decompressor: discard __ksymtab and .eh_frame sections

 arch/s390/Makefile  |  14 +-
 arch/s390/boot/compressed/Makefile  |   1 +
 arch/s390/boot/compressed/vmlinux.lds.S |  12 +-
 arch/s390/include/asm/Kbuild|   5 +
 arch/s390/include/asm/dis.h |   2 +-
 arch/s390/include/asm/dwarf.h   |  37 +++
 arch/s390/include/asm/facility.h|   2 +-
 arch/s390/include/asm/unistd.h  |   1 +
 arch/s390/include/uapi/asm/Kbuild   |   3 +
 arch/s390/include/uapi/asm/unistd.h | 401 +---
 arch/s390/kernel/compat_linux.c |   8 +-
 arch/s390/kernel/entry.S|   4 +-
 arch/s390/kernel/head.S |  10 +-
 arch/s390/kernel/ipl.c  |  12 +-
 arch/s390/kernel/kprobes.c  |   1 -
 arch/s390/kernel/syscalls.S | 392 ---
 arch/s390/kernel/syscalls/Makefile  |  52 +
 arch/s390/kernel/syscalls/syscall.tbl   | 390 +++
 arch/s390/kernel/syscalls/syscalltbl| 232 ++
 arch/s390/kernel/vdso32/Makefile|   3 +
 arch/s390/kernel/vdso32/clock_getres.S  |   5 +-
 arch/s390/kernel/vdso32/clock_gettime.S |  17 +-
 arch/s390/kernel/vdso32/getcpu.S|   5 +-
 arch/s390/kernel/vdso32/gettimeofday.S  |   9 +-
 arch/s390/kernel/vdso64/Makefile|   3 +
 arch/s390/kernel/vdso64/clock_getres.S  |   5 +-
 arch/s390/kernel/vdso64/clock_gettime.S |  21 +-
 arch/s390/kernel/vdso64/getcpu.S|   5 +-
 arch/s390/kernel/vdso64/gettimeofday.S  |   9 +-
 arch/s390/kernel/vmlinux.lds.S  |   3 +
 arch/s390/tools/.gitignore  |   1 +
 arch/s390/tools/Makefile|  23 +-
 arch/s390/tools/gen_facilities.c|   4 +-
 arch/s390/tools/gen_opcode_table.c  |   4 +-
 drivers/s390/block/dasd.c   |  12 -
 drivers/s390/block/dasd_eckd.c  |   7 +-
 drivers/s390/char/sclp_early_core.c |   4 +-
 37 files changed, 856 insertions(+), 863 deletions(-)
 create mode 100644 arch/s390/include/asm/dwarf.h
 delete mode 100644 arch/s390/kernel/syscalls.S
 create mode 100644 arch/s390/kernel/syscalls/Makefile
 create mode 100644 arch/s390/kernel/syscalls/syscall.tbl
 create mode 100755 arch/s390/kernel/syscalls/syscalltbl

[GIT PULL] s390 patches for the 4.15 merge window

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

Bug fixes, small improvements and one notable change:

 * The system call table and the unistd.h header are now generated
   automatically with a shell script from a text file.

Christophe JAILLET (1):
  s390/dasd: Simplify code

Eugene Syromiatnikov (1):
  s390: fix handling of -1 in set{,fs}[gu]id16 syscalls

Heiko Carstens (1):
  s390: remove bogus system call table entries

Hendrik Brueckner (8):
  s390/kernel: emit CFI data in .debug_frame and discard .eh_frame sections
  s390/vdso: revise CFI annotations of vDSO functions
  s390/disassembler: add generated gen_opcode_table tool to .gitignore
  s390/syscalls: add system call table
  s390/syscalls: add syscalltbl script
  s390/syscalls: add Makefile to generate system call header files
  s390/syscalls: use generated syscall_table.h and unistd.h header files
  s390/tools: generate header files in arch/s390/include/generated/

Jan Höppner (1):
  s390/dasd: Remove dead return code checks

Pravin Shedge (1):
  s390/kprobes: remove duplicate includes

Vasily Gorbik (5):
  s390/head: replace hard coded values with constants
  s390/ipl: avoid usage of __section(.data)
  s390/sclp: fix .data section specification
  s390/decompressor: swap .text and .rodata.compressed sections
  s390/decompressor: discard __ksymtab and .eh_frame sections

 arch/s390/Makefile  |  14 +-
 arch/s390/boot/compressed/Makefile  |   1 +
 arch/s390/boot/compressed/vmlinux.lds.S |  12 +-
 arch/s390/include/asm/Kbuild|   5 +
 arch/s390/include/asm/dis.h |   2 +-
 arch/s390/include/asm/dwarf.h   |  37 +++
 arch/s390/include/asm/facility.h|   2 +-
 arch/s390/include/asm/unistd.h  |   1 +
 arch/s390/include/uapi/asm/Kbuild   |   3 +
 arch/s390/include/uapi/asm/unistd.h | 401 +---
 arch/s390/kernel/compat_linux.c |   8 +-
 arch/s390/kernel/entry.S|   4 +-
 arch/s390/kernel/head.S |  10 +-
 arch/s390/kernel/ipl.c  |  12 +-
 arch/s390/kernel/kprobes.c  |   1 -
 arch/s390/kernel/syscalls.S | 392 ---
 arch/s390/kernel/syscalls/Makefile  |  52 +
 arch/s390/kernel/syscalls/syscall.tbl   | 390 +++
 arch/s390/kernel/syscalls/syscalltbl| 232 ++
 arch/s390/kernel/vdso32/Makefile|   3 +
 arch/s390/kernel/vdso32/clock_getres.S  |   5 +-
 arch/s390/kernel/vdso32/clock_gettime.S |  17 +-
 arch/s390/kernel/vdso32/getcpu.S|   5 +-
 arch/s390/kernel/vdso32/gettimeofday.S  |   9 +-
 arch/s390/kernel/vdso64/Makefile|   3 +
 arch/s390/kernel/vdso64/clock_getres.S  |   5 +-
 arch/s390/kernel/vdso64/clock_gettime.S |  21 +-
 arch/s390/kernel/vdso64/getcpu.S|   5 +-
 arch/s390/kernel/vdso64/gettimeofday.S  |   9 +-
 arch/s390/kernel/vmlinux.lds.S  |   3 +
 arch/s390/tools/.gitignore  |   1 +
 arch/s390/tools/Makefile|  23 +-
 arch/s390/tools/gen_facilities.c|   4 +-
 arch/s390/tools/gen_opcode_table.c  |   4 +-
 drivers/s390/block/dasd.c   |  12 -
 drivers/s390/block/dasd_eckd.c  |   7 +-
 drivers/s390/char/sclp_early_core.c |   4 +-
 37 files changed, 856 insertions(+), 863 deletions(-)
 create mode 100644 arch/s390/include/asm/dwarf.h
 delete mode 100644 arch/s390/kernel/syscalls.S
 create mode 100644 arch/s390/kernel/syscalls/Makefile
 create mode 100644 arch/s390/kernel/syscalls/syscall.tbl
 create mode 100755 arch/s390/kernel/syscalls/syscalltbl

Re: KASAN: use-after-free Read in map_lookup_elem

[Eric Biggers]

On Fri, Jan 12, 2018 at 02:58:02PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 4147d50978df60f34d444c647dde9e5b34a4315e
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+d9b83ca6cd9450add...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1515719240.359:8): avc:  denied  { sys_admin } for
> pid=3510 comm="syzkaller886548" capability=21
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
> permissive=1
> audit: type=1400 audit(1515719240.417:9): avc:  denied  { sys_chroot } for
> pid=3511 comm="syzkaller886548" capability=18
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
> permissive=1
> ==
> BUG: KASAN: use-after-free in memcpy include/linux/string.h:344 [inline]
> BUG: KASAN: use-after-free in map_lookup_elem+0x4dc/0xbd0
> kernel/bpf/syscall.c:584
> Read of size 4 at addr 8801bf5a9858 by task syzkaller886548/3511
> 
> CPU: 0 PID: 3511 Comm: syzkaller886548 Not tainted 4.15.0-rc7-mm1+ #53
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report+0x23b/0x360 mm/kasan/report.c:412
>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>  memcpy+0x23/0x50 mm/kasan/kasan.c:302
>  memcpy include/linux/string.h:344 [inline]
>  map_lookup_elem+0x4dc/0xbd0 kernel/bpf/syscall.c:584
>  SYSC_bpf kernel/bpf/syscall.c:1808 [inline]
>  SyS_bpf+0x922/0x4400 kernel/bpf/syscall.c:1782
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x440ab9
> RSP: 002b:007dff68 EFLAGS: 0203 ORIG_RAX: 0141
> RAX: ffda RBX:  RCX: 00440ab9
> RDX: 0018 RSI: 20c3c000 RDI: 0001
> RBP:  R08:  R09: 
> R10:  R11: 0203 R12: 00402290
> R13: 00402320 R14:  R15: 
> 
> Allocated by task 3510:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
>  kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3607
>  kmalloc include/linux/slab.h:515 [inline]
>  kzalloc include/linux/slab.h:704 [inline]
>  do_execveat_common.isra.30+0x3ea/0x22a0 fs/exec.c:1730
>  do_execve fs/exec.c:1848 [inline]
>  SYSC_execve fs/exec.c:1929 [inline]
>  SyS_execve+0x39/0x50 fs/exec.c:1924
>  do_syscall_64+0x273/0x920 arch/x86/entry/common.c:285
>  return_from_SYSCALL_64+0x0/0x75
> 
> Freed by task 3510:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
>  __cache_free mm/slab.c:3485 [inline]
>  kfree+0xd9/0x260 mm/slab.c:3800
>  free_bprm+0x19d/0x200 fs/exec.c:1415
>  do_execveat_common.isra.30+0x19e1/0x22a0 fs/exec.c:1813
>  do_execve fs/exec.c:1848 [inline]
>  SYSC_execve fs/exec.c:1929 [inline]
>  SyS_execve+0x39/0x50 fs/exec.c:1924
>  do_syscall_64+0x273/0x920 arch/x86/entry/common.c:285
>  return_from_SYSCALL_64+0x0/0x75
> 
> The buggy address belongs to the object at 8801bf5a97c0
>  which belongs to the cache kmalloc-256 of size 256
> The buggy address is located 152 bytes inside of
>  256-byte region [8801bf5a97c0, 8801bf5a98c0)
> The buggy address belongs to the page:
> page:ea0006fd6a40 count:1 mapcount:0 mapping:8801bf5a9040 index:0x0
> flags: 0x2fffc000100(slab)
> raw: 02fffc000100 8801bf5a9040  0001000c
> raw: ea0006fd6920 ea0006fdc520 8801dac007c0 
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
>  8801bf5a9700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  8801bf5a9780: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> > 8801bf5a9800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
>  8801bf5a9880: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>  8801bf5a9900: fb fb fb 

Re: KASAN: use-after-free Read in map_lookup_elem

[Eric Biggers]

On Fri, Jan 12, 2018 at 02:58:02PM -0800, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on
> 4147d50978df60f34d444c647dde9e5b34a4315e
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
> 
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+d9b83ca6cd9450add...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1515719240.359:8): avc:  denied  { sys_admin } for
> pid=3510 comm="syzkaller886548" capability=21
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
> permissive=1
> audit: type=1400 audit(1515719240.417:9): avc:  denied  { sys_chroot } for
> pid=3511 comm="syzkaller886548" capability=18
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
> permissive=1
> ==
> BUG: KASAN: use-after-free in memcpy include/linux/string.h:344 [inline]
> BUG: KASAN: use-after-free in map_lookup_elem+0x4dc/0xbd0
> kernel/bpf/syscall.c:584
> Read of size 4 at addr 8801bf5a9858 by task syzkaller886548/3511
> 
> CPU: 0 PID: 3511 Comm: syzkaller886548 Not tainted 4.15.0-rc7-mm1+ #53
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report+0x23b/0x360 mm/kasan/report.c:412
>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>  memcpy+0x23/0x50 mm/kasan/kasan.c:302
>  memcpy include/linux/string.h:344 [inline]
>  map_lookup_elem+0x4dc/0xbd0 kernel/bpf/syscall.c:584
>  SYSC_bpf kernel/bpf/syscall.c:1808 [inline]
>  SyS_bpf+0x922/0x4400 kernel/bpf/syscall.c:1782
>  entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x440ab9
> RSP: 002b:007dff68 EFLAGS: 0203 ORIG_RAX: 0141
> RAX: ffda RBX:  RCX: 00440ab9
> RDX: 0018 RSI: 20c3c000 RDI: 0001
> RBP:  R08:  R09: 
> R10:  R11: 0203 R12: 00402290
> R13: 00402320 R14:  R15: 
> 
> Allocated by task 3510:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
>  kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3607
>  kmalloc include/linux/slab.h:515 [inline]
>  kzalloc include/linux/slab.h:704 [inline]
>  do_execveat_common.isra.30+0x3ea/0x22a0 fs/exec.c:1730
>  do_execve fs/exec.c:1848 [inline]
>  SYSC_execve fs/exec.c:1929 [inline]
>  SyS_execve+0x39/0x50 fs/exec.c:1924
>  do_syscall_64+0x273/0x920 arch/x86/entry/common.c:285
>  return_from_SYSCALL_64+0x0/0x75
> 
> Freed by task 3510:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
>  __cache_free mm/slab.c:3485 [inline]
>  kfree+0xd9/0x260 mm/slab.c:3800
>  free_bprm+0x19d/0x200 fs/exec.c:1415
>  do_execveat_common.isra.30+0x19e1/0x22a0 fs/exec.c:1813
>  do_execve fs/exec.c:1848 [inline]
>  SYSC_execve fs/exec.c:1929 [inline]
>  SyS_execve+0x39/0x50 fs/exec.c:1924
>  do_syscall_64+0x273/0x920 arch/x86/entry/common.c:285
>  return_from_SYSCALL_64+0x0/0x75
> 
> The buggy address belongs to the object at 8801bf5a97c0
>  which belongs to the cache kmalloc-256 of size 256
> The buggy address is located 152 bytes inside of
>  256-byte region [8801bf5a97c0, 8801bf5a98c0)
> The buggy address belongs to the page:
> page:ea0006fd6a40 count:1 mapcount:0 mapping:8801bf5a9040 index:0x0
> flags: 0x2fffc000100(slab)
> raw: 02fffc000100 8801bf5a9040  0001000c
> raw: ea0006fd6920 ea0006fdc520 8801dac007c0 
> page dumped because: kasan: bad access detected
> 
> Memory state around the buggy address:
>  8801bf5a9700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  8801bf5a9780: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> > 8801bf5a9800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
>  8801bf5a9880: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>  8801bf5a9900: fb fb fb 

Re: [GIT pull] Timer core updates for 4.16

[Ingo Molnar]

* Linus Torvalds  wrote:

> On Mon, Jan 29, 2018 at 10:30 PM, Ingo Molnar  wrote:
> >
> > These are in cases significant driver simplifications, but they also enable 
> > the
> > real deal, the elimination of the hrtimer tasklet:
> >
> >  softirq: Remove tasklet_hrtimer
> >
> >include/linux/interrupt.h | 25 ---
> >kernel/softirq.c  | 51 
> > ---
> >2 files changed, 76 deletions(-)
> >
> > ... which is a pretty nice thing in itself even without the driver
> > simplifications!
> >
> > Plus the _real_ secret motivation behind it all is the -rt kernel and
> > CONFIG_PREEMPT_RT=y and the ability to push most of the hrtimer processing 
> > into
> > softirq context - while it still keeps the main hrtimer machinery capable 
> > to run
> > in hard-RT hardirq domain. Turns out it was possible to implement this 
> > duality via
> > the softirq-hrtimers, with a good chunk of benefits to non-rt upstream as 
> > well.
> 
> So this is the kind of explanation that I would have liked in the
> "please pull" (and that would have been great in the merge message).
> Explaining not just the "what", but very much the "why".
> 
> Anyway, it's obviously pulled regardless, and I'm just pointing this
> out for "maybe next time".

Yeah, and there will be a next time: we'll apply those those networking code 
simplifications and the tasklet removal for the v4.17 merge window, and include 
the full description in that pull request.

That cannot retroactively make it easier for you to apply the first batch of 
patches, but at least we'll have the meta description in the next merge commit 
and 
it will be part of the v4.17 Git history.

Thanks,

Ingo

Re: [GIT pull] Timer core updates for 4.16

[Ingo Molnar]

* Linus Torvalds  wrote:

> On Mon, Jan 29, 2018 at 10:30 PM, Ingo Molnar  wrote:
> >
> > These are in cases significant driver simplifications, but they also enable 
> > the
> > real deal, the elimination of the hrtimer tasklet:
> >
> >  softirq: Remove tasklet_hrtimer
> >
> >include/linux/interrupt.h | 25 ---
> >kernel/softirq.c  | 51 
> > ---
> >2 files changed, 76 deletions(-)
> >
> > ... which is a pretty nice thing in itself even without the driver
> > simplifications!
> >
> > Plus the _real_ secret motivation behind it all is the -rt kernel and
> > CONFIG_PREEMPT_RT=y and the ability to push most of the hrtimer processing 
> > into
> > softirq context - while it still keeps the main hrtimer machinery capable 
> > to run
> > in hard-RT hardirq domain. Turns out it was possible to implement this 
> > duality via
> > the softirq-hrtimers, with a good chunk of benefits to non-rt upstream as 
> > well.
> 
> So this is the kind of explanation that I would have liked in the
> "please pull" (and that would have been great in the merge message).
> Explaining not just the "what", but very much the "why".
> 
> Anyway, it's obviously pulled regardless, and I'm just pointing this
> out for "maybe next time".

Yeah, and there will be a next time: we'll apply those those networking code 
simplifications and the tasklet removal for the v4.17 merge window, and include 
the full description in that pull request.

That cannot retroactively make it easier for you to apply the first batch of 
patches, but at least we'll have the meta description in the next merge commit 
and 
it will be part of the v4.17 Git history.

Thanks,

Ingo