[PATCH] sched/deadline: make function ‘grub_reclaim’ static

[Mathieu Malaterre]

Since function ‘grub_reclaim’ can be made static, make it so.
Silence the following gcc warning (W=1):

  kernel/sched/deadline.c:1120:5: warning: no previous prototype for 
‘grub_reclaim’ [-Wmissing-prototypes]

Signed-off-by: Mathieu Malaterre 
---
 kernel/sched/deadline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index d6196bc6cbb5..1356afd1eeb6 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1117,7 +1117,7 @@ extern bool sched_rt_bandwidth_account(struct rt_rq 
*rt_rq);
  * should be larger than 2^(64 - 20 - 8), which is more than 64 seconds.
  * So, overflow is not an issue here.
  */
-u64 grub_reclaim(u64 delta, struct rq *rq, struct sched_dl_entity *dl_se)
+static u64 grub_reclaim(u64 delta, struct rq *rq, struct sched_dl_entity 
*dl_se)
 {
u64 u_inact = rq->dl.this_bw - rq->dl.running_bw; /* Utot - Uact */
u64 u_act;
-- 
2.11.0

[PATCH] sched/deadline: make function ‘grub_reclaim’ static

[Mathieu Malaterre]

Since function ‘grub_reclaim’ can be made static, make it so.
Silence the following gcc warning (W=1):

  kernel/sched/deadline.c:1120:5: warning: no previous prototype for 
‘grub_reclaim’ [-Wmissing-prototypes]

Signed-off-by: Mathieu Malaterre 
---
 kernel/sched/deadline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index d6196bc6cbb5..1356afd1eeb6 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1117,7 +1117,7 @@ extern bool sched_rt_bandwidth_account(struct rt_rq 
*rt_rq);
  * should be larger than 2^(64 - 20 - 8), which is more than 64 seconds.
  * So, overflow is not an issue here.
  */
-u64 grub_reclaim(u64 delta, struct rq *rq, struct sched_dl_entity *dl_se)
+static u64 grub_reclaim(u64 delta, struct rq *rq, struct sched_dl_entity 
*dl_se)
 {
u64 u_inact = rq->dl.this_bw - rq->dl.running_bw; /* Utot - Uact */
u64 u_act;
-- 
2.11.0

Re: [PATCH v4 0/8] Introduce the for_each_set_clump macro

[Andy Shevchenko]

On Wed, May 16, 2018 at 5:03 PM, Linus Walleij  wrote:
> On Tue, May 15, 2018 at 6:22 PM, William Breathitt Gray
>  wrote:
>
>> For example, suppose you would like to iterate over a 16-bit integer 4
>> bits at a time, skipping over 4-bit groups with no set bit, where 
>> represents the current 4-bit group:
>>
>> Example:1011 1110  
>> First loop: 1011 1110  
>> Second loop:1011   
>> Third loop:  1110  
>>
>> Each iteration of the loop returns the next 4-bit group that has at
>> least one set bit.
>>
>> The for_each_set_clump macro has six parameters:
>>
>> * clump: set to current clump index for the iteration
>> * index: set to current bitmap word index for the iteration
>> * offset: bits offset of the found clump in the bitmap word
>> * bits: bitmap to search within
>> * size: bitmap size in number of clumps
>> * clump_size: clump size in number of bits
>>
>> The clump_size argument can be an arbitrary number of bits and is not
>> required to be a multiple of 2.
>
> I must say I'm impressed. Very nice arithmetics going on there.
>
> If I can get some ACK for the bitops patch I'd be happy to merge
> it all through the GPIO tree. The users are pretty clear cut.

Give me also some time to go through proposed API, I think it might
have needed more alignment with existing find_* and for_* helpers.

> BTW: if I could, I would pull out Donald Knuth's "The Art of Computer
> Programming vol 4A" chapter 7.1.3 "Bitwise Tricks and Techniques"
> to see what he has to say about the subject, but I don't have
> that book as it turns out.

I can also add the Standford collection of bit algos here:

https://graphics.stanford.edu/~seander/bithacks.html

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 0/8] Introduce the for_each_set_clump macro

[Andy Shevchenko]

On Wed, May 16, 2018 at 5:03 PM, Linus Walleij  wrote:
> On Tue, May 15, 2018 at 6:22 PM, William Breathitt Gray
>  wrote:
>
>> For example, suppose you would like to iterate over a 16-bit integer 4
>> bits at a time, skipping over 4-bit groups with no set bit, where 
>> represents the current 4-bit group:
>>
>> Example:1011 1110  
>> First loop: 1011 1110  
>> Second loop:1011   
>> Third loop:  1110  
>>
>> Each iteration of the loop returns the next 4-bit group that has at
>> least one set bit.
>>
>> The for_each_set_clump macro has six parameters:
>>
>> * clump: set to current clump index for the iteration
>> * index: set to current bitmap word index for the iteration
>> * offset: bits offset of the found clump in the bitmap word
>> * bits: bitmap to search within
>> * size: bitmap size in number of clumps
>> * clump_size: clump size in number of bits
>>
>> The clump_size argument can be an arbitrary number of bits and is not
>> required to be a multiple of 2.
>
> I must say I'm impressed. Very nice arithmetics going on there.
>
> If I can get some ACK for the bitops patch I'd be happy to merge
> it all through the GPIO tree. The users are pretty clear cut.

Give me also some time to go through proposed API, I think it might
have needed more alignment with existing find_* and for_* helpers.

> BTW: if I could, I would pull out Donald Knuth's "The Art of Computer
> Programming vol 4A" chapter 7.1.3 "Bitwise Tricks and Techniques"
> to see what he has to say about the subject, but I don't have
> that book as it turns out.

I can also add the Standford collection of bit algos here:

https://graphics.stanford.edu/~seander/bithacks.html

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH -mm] mm, hugetlb: Pass fault address to no page handler

[Mike Kravetz]

On 05/16/2018 02:12 AM, Michal Hocko wrote:
> On Tue 15-05-18 08:57:56, Huang, Ying wrote:
>> From: Huang Ying 
>>
>> This is to take better advantage of huge page clearing
>> optimization (c79b57e462b5d, "mm: hugetlb: clear target sub-page last
>> when clearing huge page").  Which will clear to access sub-page last
>> to avoid the cache lines of to access sub-page to be evicted when
>> clearing other sub-pages.  This needs to get the address of the
>> sub-page to access, that is, the fault address inside of the huge
>> page.  So the hugetlb no page fault handler is changed to pass that
>> information.  This will benefit workloads which don't access the begin
>> of the huge page after page fault.
>>
>> With this patch, the throughput increases ~28.1% in vm-scalability
>> anon-w-seq test case with 88 processes on a 2 socket Xeon E5 2699 v4
>> system (44 cores, 88 threads).  The test case creates 88 processes,
>> each process mmap a big anonymous memory area and writes to it from
>> the end to the begin.  For each process, other processes could be seen
>> as other workload which generates heavy cache pressure.  At the same
>> time, the cache miss rate reduced from ~36.3% to ~25.6%, the
>> IPC (instruction per cycle) increased from 0.3 to 0.37, and the time
>> spent in user space is reduced ~19.3%
> 
> This paragraph is confusing as Mike mentioned already. It would be
> probably more helpful to see how was the test configured to use hugetlb
> pages and what is the end benefit.
> 
> I do not have any real objection to the implementation so feel free to
> add
> Acked-by: Michal Hocko 
> I am just wondering what is the usecase driving this. Or is it just a
> generic optimization that always makes sense to do? Indicating that in
> the changelog would be helpful as well.

I just noticed that the optimization was not added for 'gigantic' pages.
Should we consider adding support for gigantic pages as well?  It may be
that the cache miss cost is insignificant when added to the time required
to clear a 1GB (for x86) gigantic page.

One more thing, I'm guessing the copy_huge/gigantic_page() routines would
see a similar benefit.  Specifically, for copies as a result of a COW.
Is that another area to consider?

That gets back to Michal's question of a specific use case or generic
optimization.  Unless code is simple (as in this patch), seems like we should
hold off on considering additional optimizations unless there is a specific
use case.

I'm still OK with this change.
-- 
Mike Kravetz

Re: [PATCH -mm] mm, hugetlb: Pass fault address to no page handler

[Mike Kravetz]

On 05/16/2018 02:12 AM, Michal Hocko wrote:
> On Tue 15-05-18 08:57:56, Huang, Ying wrote:
>> From: Huang Ying 
>>
>> This is to take better advantage of huge page clearing
>> optimization (c79b57e462b5d, "mm: hugetlb: clear target sub-page last
>> when clearing huge page").  Which will clear to access sub-page last
>> to avoid the cache lines of to access sub-page to be evicted when
>> clearing other sub-pages.  This needs to get the address of the
>> sub-page to access, that is, the fault address inside of the huge
>> page.  So the hugetlb no page fault handler is changed to pass that
>> information.  This will benefit workloads which don't access the begin
>> of the huge page after page fault.
>>
>> With this patch, the throughput increases ~28.1% in vm-scalability
>> anon-w-seq test case with 88 processes on a 2 socket Xeon E5 2699 v4
>> system (44 cores, 88 threads).  The test case creates 88 processes,
>> each process mmap a big anonymous memory area and writes to it from
>> the end to the begin.  For each process, other processes could be seen
>> as other workload which generates heavy cache pressure.  At the same
>> time, the cache miss rate reduced from ~36.3% to ~25.6%, the
>> IPC (instruction per cycle) increased from 0.3 to 0.37, and the time
>> spent in user space is reduced ~19.3%
> 
> This paragraph is confusing as Mike mentioned already. It would be
> probably more helpful to see how was the test configured to use hugetlb
> pages and what is the end benefit.
> 
> I do not have any real objection to the implementation so feel free to
> add
> Acked-by: Michal Hocko 
> I am just wondering what is the usecase driving this. Or is it just a
> generic optimization that always makes sense to do? Indicating that in
> the changelog would be helpful as well.

I just noticed that the optimization was not added for 'gigantic' pages.
Should we consider adding support for gigantic pages as well?  It may be
that the cache miss cost is insignificant when added to the time required
to clear a 1GB (for x86) gigantic page.

One more thing, I'm guessing the copy_huge/gigantic_page() routines would
see a similar benefit.  Specifically, for copies as a result of a COW.
Is that another area to consider?

That gets back to Michal's question of a specific use case or generic
optimization.  Unless code is simple (as in this patch), seems like we should
hold off on considering additional optimizations unless there is a specific
use case.

I'm still OK with this change.
-- 
Mike Kravetz

Re: [PATCH v16 8/9] PCI/DPC: Unify and plumb error handling into DPC

[Bjorn Helgaas]

On Wed, May 16, 2018 at 08:28:39PM +0530, p...@codeaurora.org wrote:
> On 2018-05-16 18:34, Bjorn Helgaas wrote:
> > On Wed, May 16, 2018 at 05:45:58PM +0530, p...@codeaurora.org wrote:
> > > On 2018-05-16 16:22, Bjorn Helgaas wrote:
> > > > On Wed, May 16, 2018 at 01:46:25PM +0530, p...@codeaurora.org wrote:

> > > > > I am sorry I pasted the wrong snippet.
> > > > > following needs to be fixed in v17.
> > > > > from:
> > > > >if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> > > > > /*
> > > > >  * If the error is reported by a bridge, we think
> > > > > this error
> > > > >  * is related to the downstream link of the bridge,
> > > > > so we
> > > > >  * do error recovery on all subordinates of the bridge
> > > > > instead
> > > > >  * of the bridge and clear the error status of the
> > > > > bridge.
> > > > >  */
> > > > > pci_walk_bus(dev->subordinate, report_resume,
> > > > > _data);
> > > > > pci_cleanup_aer_uncorrect_error_status(dev);
> > > > > }
> > > > >
> > > > >
> > > > > to
> > > > >
> > > > >if (service==AER  && dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> > > > > /*
> > > > >  * If the error is reported by a bridge, we think
> > > > > this error
> > > > >  * is related to the downstream link of the bridge,
> > > > > so we
> > > > >  * do error recovery on all subordinates of the bridge
> > > > > instead
> > > > >  * of the bridge and clear the error status of the
> > > > > bridge.
> > > > >  */
> > > > > pci_walk_bus(dev->subordinate, report_resume,
> > > > > _data);
> > > > > pci_cleanup_aer_uncorrect_error_status(dev);
> > > > > }
> > > > >
> > > > > this is only needed in case of AER.
> > > >
> > > > Oh, I missed this before.  It makes sense to clear the AER status
> > > > here, but why do we need to call report_resume()?  We just called all
> > > > the driver .remove() methods and detached the drivers from the
> > > > devices.  So I don't think report_resume() will do anything
> > > > ("dev->driver" should be NULL) except set the dev->error_state to
> > > > pci_channel_io_normal.  We probably don't need that because we didn't
> > > > change error_state in this fatal error path.
> > > 
> > > if you remember, the path ends up calling
> > > aer_error_resume
> > > 
> > > the existing code ends up calling aer_error_resume as follows.
> > > 
> > > do_recovery(pci_dev)
> > > broadcast_error_message(..., error_detected, ...)
> > > if (AER_FATAL)
> > >   reset_link(pci_dev)
> > > udev = BRIDGE ? pci_dev : pci_dev->bus->self
> > > driver->reset_link(udev)
> > >   aer_root_reset(udev)
> > > if (CAN_RECOVER)
> > >   broadcast_error_message(..., mmio_enabled, ...)
> > > if (NEED_RESET)
> > >   broadcast_error_message(..., slot_reset, ...)
> > > broadcast_error_message(dev, ..., report_resume, ...)
> > >   if (BRIDGE)
> > > report_resume
> > >   driver->resume
> > > pcie_portdrv_err_resume
> > >   device_for_each_child(..., resume_iter)
> > > resume_iter
> > >   driver->error_resume
> > > aer_error_resume
> > > pci_cleanup_aer_uncorrect_error_status(pci_dev)   # only
> > > if
> > > BRIDGE
> > >   pci_write_config_dword(PCI_ERR_UNCOR_STATUS)
> > > 
> > > hence I think we have to call it in order to clear the root port
> > > PCI_ERR_UNCOR_STATUS and PCI_EXP_DEVSTA.
> > > makes sense ?
> > 
> > I know I sent you the call graph above, so you would think I might
> > understand it, but you would be mistaken :)  This still doesn't make
> > sense to me.
> > 
> > I think your point is that we need to call aer_error_resume().  That
> > is the aerdriver.error_resume() method.  The AER driver only binds to
> > root ports.
> > 
> > This path:
> > 
> >   pcie_do_fatal_recovery
> > pci_walk_bus(dev->subordinate, report_resume, _data)
> > 
> > calls report_resume() for every device on the dev->subordinate bus
> > (and for anything below those devices).  There are no root ports on
> > that dev->subordinate bus, because root ports are always on a root
> > bus, never on a subordinate bus.
> > 
> > So I don't see how report_resume() can ever get to aer_error_resume().
> > Can you instrument that path and verify that it actually does get
> > there somehow?
> 
> you are rightthe call
> pci_walk_bus(dev->subordinate, report_resume, _data);
> does not call aer_error_resume()
> 
> but
> pci_walk_bus(udev->bus, report_resume, _data);
> does call aer_error_resume()
> 
> now if you look at the comment of the function:
> /**
>  * aer_error_resume - clean up corresponding error status bits
>  * @dev: pointer to Root Port's pci_dev data structure
>  *
>  * Invoked by Port Bus 

Re: [PATCH v16 8/9] PCI/DPC: Unify and plumb error handling into DPC

[Bjorn Helgaas]

On Wed, May 16, 2018 at 08:28:39PM +0530, p...@codeaurora.org wrote:
> On 2018-05-16 18:34, Bjorn Helgaas wrote:
> > On Wed, May 16, 2018 at 05:45:58PM +0530, p...@codeaurora.org wrote:
> > > On 2018-05-16 16:22, Bjorn Helgaas wrote:
> > > > On Wed, May 16, 2018 at 01:46:25PM +0530, p...@codeaurora.org wrote:

> > > > > I am sorry I pasted the wrong snippet.
> > > > > following needs to be fixed in v17.
> > > > > from:
> > > > >if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> > > > > /*
> > > > >  * If the error is reported by a bridge, we think
> > > > > this error
> > > > >  * is related to the downstream link of the bridge,
> > > > > so we
> > > > >  * do error recovery on all subordinates of the bridge
> > > > > instead
> > > > >  * of the bridge and clear the error status of the
> > > > > bridge.
> > > > >  */
> > > > > pci_walk_bus(dev->subordinate, report_resume,
> > > > > _data);
> > > > > pci_cleanup_aer_uncorrect_error_status(dev);
> > > > > }
> > > > >
> > > > >
> > > > > to
> > > > >
> > > > >if (service==AER  && dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> > > > > /*
> > > > >  * If the error is reported by a bridge, we think
> > > > > this error
> > > > >  * is related to the downstream link of the bridge,
> > > > > so we
> > > > >  * do error recovery on all subordinates of the bridge
> > > > > instead
> > > > >  * of the bridge and clear the error status of the
> > > > > bridge.
> > > > >  */
> > > > > pci_walk_bus(dev->subordinate, report_resume,
> > > > > _data);
> > > > > pci_cleanup_aer_uncorrect_error_status(dev);
> > > > > }
> > > > >
> > > > > this is only needed in case of AER.
> > > >
> > > > Oh, I missed this before.  It makes sense to clear the AER status
> > > > here, but why do we need to call report_resume()?  We just called all
> > > > the driver .remove() methods and detached the drivers from the
> > > > devices.  So I don't think report_resume() will do anything
> > > > ("dev->driver" should be NULL) except set the dev->error_state to
> > > > pci_channel_io_normal.  We probably don't need that because we didn't
> > > > change error_state in this fatal error path.
> > > 
> > > if you remember, the path ends up calling
> > > aer_error_resume
> > > 
> > > the existing code ends up calling aer_error_resume as follows.
> > > 
> > > do_recovery(pci_dev)
> > > broadcast_error_message(..., error_detected, ...)
> > > if (AER_FATAL)
> > >   reset_link(pci_dev)
> > > udev = BRIDGE ? pci_dev : pci_dev->bus->self
> > > driver->reset_link(udev)
> > >   aer_root_reset(udev)
> > > if (CAN_RECOVER)
> > >   broadcast_error_message(..., mmio_enabled, ...)
> > > if (NEED_RESET)
> > >   broadcast_error_message(..., slot_reset, ...)
> > > broadcast_error_message(dev, ..., report_resume, ...)
> > >   if (BRIDGE)
> > > report_resume
> > >   driver->resume
> > > pcie_portdrv_err_resume
> > >   device_for_each_child(..., resume_iter)
> > > resume_iter
> > >   driver->error_resume
> > > aer_error_resume
> > > pci_cleanup_aer_uncorrect_error_status(pci_dev)   # only
> > > if
> > > BRIDGE
> > >   pci_write_config_dword(PCI_ERR_UNCOR_STATUS)
> > > 
> > > hence I think we have to call it in order to clear the root port
> > > PCI_ERR_UNCOR_STATUS and PCI_EXP_DEVSTA.
> > > makes sense ?
> > 
> > I know I sent you the call graph above, so you would think I might
> > understand it, but you would be mistaken :)  This still doesn't make
> > sense to me.
> > 
> > I think your point is that we need to call aer_error_resume().  That
> > is the aerdriver.error_resume() method.  The AER driver only binds to
> > root ports.
> > 
> > This path:
> > 
> >   pcie_do_fatal_recovery
> > pci_walk_bus(dev->subordinate, report_resume, _data)
> > 
> > calls report_resume() for every device on the dev->subordinate bus
> > (and for anything below those devices).  There are no root ports on
> > that dev->subordinate bus, because root ports are always on a root
> > bus, never on a subordinate bus.
> > 
> > So I don't see how report_resume() can ever get to aer_error_resume().
> > Can you instrument that path and verify that it actually does get
> > there somehow?
> 
> you are rightthe call
> pci_walk_bus(dev->subordinate, report_resume, _data);
> does not call aer_error_resume()
> 
> but
> pci_walk_bus(udev->bus, report_resume, _data);
> does call aer_error_resume()
> 
> now if you look at the comment of the function:
> /**
>  * aer_error_resume - clean up corresponding error status bits
>  * @dev: pointer to Root Port's pci_dev data structure
>  *
>  * Invoked by Port Bus 

Sometimes unusable i2c-hid devices in 4.17-rcX

[Mario.Limonciello]

Hi All,

I've been running 4.16-rc7 on an XPS 9365 for some time and recently moved up 
to 4.17-rc5.
Immediately I noticed that i2c-hid devices (both touchscreen and touchpad) were 
not working.
Also when shutting the system down or rebooting it would just hang. (magic 
sysrq still worked).

I figured it was an easy to identify regression so I started a bisect but it 
came up with garbage
that ended in selftests shortly after 4.17-rc2.  I realized that's because is 
still will fail on 4.17-rc2
occasionally, seemingly after trying something newer and warm rebooting.
So it seems like it's "worse" after 4.17-rc2 (doesn't work at all) but semi 
reproducible on 4.17-rc2.

Not sure if I'm chasing some initialization race, but wanted to see if anyone 
else was running into this
or has some ideas?

#dmesg | grep 'i2c\|hid' doesn't show any obvious errors when in this state of 
non functional hid stuff.
[2.398649] i2c /dev entries driver
[2.881651] hidraw: raw HID events driver (C) Jiri Kosina
[3.683583] ish-hid {33AECD58-B679-4E54-9BD9-A04D34F0C226}: [hid-ish]: 
enum_devices_done OK, num_hid_devices=5
[3.701259] hid-generic 001F:8086:22D8.0001: hidraw0:  HID v2.00 
Device [hid-ishtp 8086:22D8] on 
[3.702204] hid-generic 001F:8086:22D8.0002: hidraw1:  HID v2.00 
Device [hid-ishtp 8086:22D8] on 
[3.703063] hid-generic 001F:8086:22D8.0003: hidraw2:  HID v2.00 
Device [hid-ishtp 8086:22D8] on 
[3.704276] hid-generic 001F:8086:22D8.0004: hidraw3:  HID v2.00 
Device [hid-ishtp 8086:22D8] on 
[3.704557] hid-generic 001F:8086:22D8.0005: hidraw4:  HID v2.00 
Device [hid-ishtp 8086:22D8] on 
[3.750710] psmouse serio1: synaptics: Your touchpad (PNP: DLL077a PNP0f13) 
says it can support a different bus. If i2c-hid and hid-rmi are not used, you 
might want to try setting psmouse.synaptics_intertouch to 1 and report this to 
linux-in...@vger.kernel.org.
[7.030446] acpi INT33D5:00: intel-hid: created platform device
[7.199178] i2c_hid i2c-WCOM482F:00: i2c-WCOM482F:00 supply vdd not found, 
using dummy regulator
[7.246638] input: WCOM482F:00 056A:482F as 
/devices/pci:00/:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM482F:00/0018:056A:482F.0006/input/input11
[7.246873] hid-generic 0018:056A:482F.0006: input,hidraw0: I2C HID v1.00 
Mouse [WCOM482F:00 056A:482F] on i2c-WCOM482F:00
[7.275279] i2c_hid i2c-DLL077A:01: i2c-DLL077A:01 supply vdd not found, 
using dummy regulator
[7.304107] input: DLL077A:01 06CB:76AF as 
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-7/i2c-DLL077A:01/0018:06CB:76AF.0007/input/input14
[7.304212] hid-generic 0018:06CB:76AF.0007: input,hidraw1: I2C HID v1.00 
Mouse [DLL077A:01 06CB:76AF] on i2c-DLL077A:01
[7.657123] usbcore: registered new interface driver usbhid
[7.657124] usbhid: USB HID core driver
[7.722876] input: Wacom HID 482F Pen as 
/devices/pci:00/:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM482F:00/0018:056A:482F.0006/input/input15
[7.723148] input: Wacom HID 482F Finger as 
/devices/pci:00/:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM482F:00/0018:056A:482F.0006/input/input16
[7.723611] wacom 0018:056A:482F.0006: hidraw0: I2C HID v1.00 Mouse 
[WCOM482F:00 056A:482F] on i2c-WCOM482F:00
[7.768275] input: DLL077A:01 06CB:76AF Touchpad as 
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-7/i2c-DLL077A:01/0018:06CB:76AF.0007/input/input19
[7.864201] hid-multitouch 0018:06CB:76AF.0007: input,hidraw0: I2C HID v1.00 
Mouse [DLL077A:01 06CB:76AF] on i2c-DLL077A:01

However in this state, I can't rmmod i2c-hid.  It just hangs the system with 
this trace:
[  243.033779] INFO: task kworker/u8:0:6 blocked for more than 120 seconds.
[  243.033793]   Not tainted 4.17.0-rc1+ #37
[  243.033798] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  243.033804] kworker/u8:0D0 6  2 0x8000
[  243.033826] Workqueue: events_power_efficient 
power_supply_deferred_register_work
[  243.033832] Call Trace:
[  243.033850]  __schedule+0x3c2/0x890
[  243.033861]  ? __switch_to_asm+0x40/0x70
[  243.033868]  schedule+0x36/0x80
[  243.033875]  schedule_preempt_disabled+0xe/0x10
[  243.033882]  __mutex_lock.isra.4+0x2ae/0x4e0
[  243.033890]  ? __switch_to_asm+0x34/0x70
[  243.033899]  ? __switch_to_asm+0x40/0x70
[  243.033906]  ? __switch_to_asm+0x40/0x70
[  243.033914]  __mutex_lock_slowpath+0x13/0x20
[  243.033920]  ? __mutex_lock_slowpath+0x13/0x20
[  243.033927]  mutex_lock+0x2f/0x40
[  243.033933]  power_supply_deferred_register_work+0x2b/0x50
[  243.033944]  process_one_work+0x148/0x3d0
[  243.033952]  worker_thread+0x4b/0x460
[  243.033960]  kthread+0x102/0x140
[  243.033967]  ? rescuer_thread+0x380/0x380
[  243.033973]  ? kthread_associate_blkcg+0xa0/0xa0
[  243.033982]  ret_from_fork+0x35/0x40
[  243.034012] INFO: task systemd-udevd:308 blocked for more than 120 seconds.
[  243.034018]   Not tainted 4.17.0-rc1+ #37
[  243.034022] "echo 0 > 

Sometimes unusable i2c-hid devices in 4.17-rcX

[Mario.Limonciello]

Hi All,

I've been running 4.16-rc7 on an XPS 9365 for some time and recently moved up 
to 4.17-rc5.
Immediately I noticed that i2c-hid devices (both touchscreen and touchpad) were 
not working.
Also when shutting the system down or rebooting it would just hang. (magic 
sysrq still worked).

I figured it was an easy to identify regression so I started a bisect but it 
came up with garbage
that ended in selftests shortly after 4.17-rc2.  I realized that's because is 
still will fail on 4.17-rc2
occasionally, seemingly after trying something newer and warm rebooting.
So it seems like it's "worse" after 4.17-rc2 (doesn't work at all) but semi 
reproducible on 4.17-rc2.

Not sure if I'm chasing some initialization race, but wanted to see if anyone 
else was running into this
or has some ideas?

#dmesg | grep 'i2c\|hid' doesn't show any obvious errors when in this state of 
non functional hid stuff.
[2.398649] i2c /dev entries driver
[2.881651] hidraw: raw HID events driver (C) Jiri Kosina
[3.683583] ish-hid {33AECD58-B679-4E54-9BD9-A04D34F0C226}: [hid-ish]: 
enum_devices_done OK, num_hid_devices=5
[3.701259] hid-generic 001F:8086:22D8.0001: hidraw0:  HID v2.00 
Device [hid-ishtp 8086:22D8] on 
[3.702204] hid-generic 001F:8086:22D8.0002: hidraw1:  HID v2.00 
Device [hid-ishtp 8086:22D8] on 
[3.703063] hid-generic 001F:8086:22D8.0003: hidraw2:  HID v2.00 
Device [hid-ishtp 8086:22D8] on 
[3.704276] hid-generic 001F:8086:22D8.0004: hidraw3:  HID v2.00 
Device [hid-ishtp 8086:22D8] on 
[3.704557] hid-generic 001F:8086:22D8.0005: hidraw4:  HID v2.00 
Device [hid-ishtp 8086:22D8] on 
[3.750710] psmouse serio1: synaptics: Your touchpad (PNP: DLL077a PNP0f13) 
says it can support a different bus. If i2c-hid and hid-rmi are not used, you 
might want to try setting psmouse.synaptics_intertouch to 1 and report this to 
linux-in...@vger.kernel.org.
[7.030446] acpi INT33D5:00: intel-hid: created platform device
[7.199178] i2c_hid i2c-WCOM482F:00: i2c-WCOM482F:00 supply vdd not found, 
using dummy regulator
[7.246638] input: WCOM482F:00 056A:482F as 
/devices/pci:00/:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM482F:00/0018:056A:482F.0006/input/input11
[7.246873] hid-generic 0018:056A:482F.0006: input,hidraw0: I2C HID v1.00 
Mouse [WCOM482F:00 056A:482F] on i2c-WCOM482F:00
[7.275279] i2c_hid i2c-DLL077A:01: i2c-DLL077A:01 supply vdd not found, 
using dummy regulator
[7.304107] input: DLL077A:01 06CB:76AF as 
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-7/i2c-DLL077A:01/0018:06CB:76AF.0007/input/input14
[7.304212] hid-generic 0018:06CB:76AF.0007: input,hidraw1: I2C HID v1.00 
Mouse [DLL077A:01 06CB:76AF] on i2c-DLL077A:01
[7.657123] usbcore: registered new interface driver usbhid
[7.657124] usbhid: USB HID core driver
[7.722876] input: Wacom HID 482F Pen as 
/devices/pci:00/:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM482F:00/0018:056A:482F.0006/input/input15
[7.723148] input: Wacom HID 482F Finger as 
/devices/pci:00/:00:15.0/i2c_designware.0/i2c-6/i2c-WCOM482F:00/0018:056A:482F.0006/input/input16
[7.723611] wacom 0018:056A:482F.0006: hidraw0: I2C HID v1.00 Mouse 
[WCOM482F:00 056A:482F] on i2c-WCOM482F:00
[7.768275] input: DLL077A:01 06CB:76AF Touchpad as 
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-7/i2c-DLL077A:01/0018:06CB:76AF.0007/input/input19
[7.864201] hid-multitouch 0018:06CB:76AF.0007: input,hidraw0: I2C HID v1.00 
Mouse [DLL077A:01 06CB:76AF] on i2c-DLL077A:01

However in this state, I can't rmmod i2c-hid.  It just hangs the system with 
this trace:
[  243.033779] INFO: task kworker/u8:0:6 blocked for more than 120 seconds.
[  243.033793]   Not tainted 4.17.0-rc1+ #37
[  243.033798] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  243.033804] kworker/u8:0D0 6  2 0x8000
[  243.033826] Workqueue: events_power_efficient 
power_supply_deferred_register_work
[  243.033832] Call Trace:
[  243.033850]  __schedule+0x3c2/0x890
[  243.033861]  ? __switch_to_asm+0x40/0x70
[  243.033868]  schedule+0x36/0x80
[  243.033875]  schedule_preempt_disabled+0xe/0x10
[  243.033882]  __mutex_lock.isra.4+0x2ae/0x4e0
[  243.033890]  ? __switch_to_asm+0x34/0x70
[  243.033899]  ? __switch_to_asm+0x40/0x70
[  243.033906]  ? __switch_to_asm+0x40/0x70
[  243.033914]  __mutex_lock_slowpath+0x13/0x20
[  243.033920]  ? __mutex_lock_slowpath+0x13/0x20
[  243.033927]  mutex_lock+0x2f/0x40
[  243.033933]  power_supply_deferred_register_work+0x2b/0x50
[  243.033944]  process_one_work+0x148/0x3d0
[  243.033952]  worker_thread+0x4b/0x460
[  243.033960]  kthread+0x102/0x140
[  243.033967]  ? rescuer_thread+0x380/0x380
[  243.033973]  ? kthread_associate_blkcg+0xa0/0xa0
[  243.033982]  ret_from_fork+0x35/0x40
[  243.034012] INFO: task systemd-udevd:308 blocked for more than 120 seconds.
[  243.034018]   Not tainted 4.17.0-rc1+ #37
[  243.034022] "echo 0 > 

[PATCH] clocksource: Move the inline keyword at the beginning of function declarations

[Mathieu Malaterre]

The inline keyword was not at the beginning of the function declarations.
Fix the following warnings triggered when using W=1:

  kernel/time/clocksource.c:456:1: warning: ‘inline’ is not at beginning of 
declaration [-Wold-style-declaration]
  kernel/time/clocksource.c:457:1: warning: ‘inline’ is not at beginning of 
declaration [-Wold-style-declaration]

Signed-off-by: Mathieu Malaterre 
---
 kernel/time/clocksource.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 84f37420fcf5..e0ff8f94f237 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -453,8 +453,8 @@ static inline int __clocksource_watchdog_kthread(void) { 
return 0; }
 static bool clocksource_is_watchdog(struct clocksource *cs) { return false; }
 void clocksource_mark_unstable(struct clocksource *cs) { }
 
-static void inline clocksource_watchdog_lock(unsigned long *flags) { }
-static void inline clocksource_watchdog_unlock(unsigned long *flags) { }
+static inline void clocksource_watchdog_lock(unsigned long *flags) { }
+static inline void clocksource_watchdog_unlock(unsigned long *flags) { }
 
 #endif /* CONFIG_CLOCKSOURCE_WATCHDOG */
 
-- 
2.11.0

[PATCH] clocksource: Move the inline keyword at the beginning of function declarations

[Mathieu Malaterre]

The inline keyword was not at the beginning of the function declarations.
Fix the following warnings triggered when using W=1:

  kernel/time/clocksource.c:456:1: warning: ‘inline’ is not at beginning of 
declaration [-Wold-style-declaration]
  kernel/time/clocksource.c:457:1: warning: ‘inline’ is not at beginning of 
declaration [-Wold-style-declaration]

Signed-off-by: Mathieu Malaterre 
---
 kernel/time/clocksource.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 84f37420fcf5..e0ff8f94f237 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -453,8 +453,8 @@ static inline int __clocksource_watchdog_kthread(void) { 
return 0; }
 static bool clocksource_is_watchdog(struct clocksource *cs) { return false; }
 void clocksource_mark_unstable(struct clocksource *cs) { }
 
-static void inline clocksource_watchdog_lock(unsigned long *flags) { }
-static void inline clocksource_watchdog_unlock(unsigned long *flags) { }
+static inline void clocksource_watchdog_lock(unsigned long *flags) { }
+static inline void clocksource_watchdog_unlock(unsigned long *flags) { }
 
 #endif /* CONFIG_CLOCKSOURCE_WATCHDOG */
 
-- 
2.11.0

Re: [PATCH v6 2/3] gpio: pca953x: define masks for addressing common and extended registers

[H. Nikolaus Schaller]

> Am 16.05.2018 um 21:50 schrieb Andy Shevchenko :
> 
> On Wed, May 16, 2018 at 8:01 PM, H. Nikolaus Schaller  
> wrote:
>> These mask bits are to be used to map the extended register
>> addreseses (which are defined for an unsupported 8-bit pcal chip)
>> to 16 and 24 bit chips (pcal6524).
>> 
>> Reviewed-by: Andy Shevchenko 
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> drivers/gpio/gpio-pca953x.c | 4 
>> 1 file changed, 4 insertions(+)
>> 
>> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
>> index 2b667166e855..c0eb679e60d4 100644
>> --- a/drivers/gpio/gpio-pca953x.c
>> +++ b/drivers/gpio/gpio-pca953x.c
>> @@ -56,6 +56,10 @@
>> #define PCAL6524_DEBOUNCE  0x2d
>> 
>> #define PCA_GPIO_MASK  0x00FF
>> +
>> +#define PCAL_GPIO_MASK GENMASK(4, 0)
>> +#define PCAL_PINCTRL_MASK  (~PCAL_GPIO_MASK)
>> +
> 
> I give second thought about it, and think
> either plain values, or second converted to its own explicit GENMASK
> would be better.
> 
> (most confusing part to me is unknowness of the side of PINCTRL part
> in the mask)

I see.

Then, I'd also prefer plain values.

If ok, I can send a v7 tomorrow.

BR,
Nikolaus

Re: [PATCH v6 2/3] gpio: pca953x: define masks for addressing common and extended registers

[H. Nikolaus Schaller]

> Am 16.05.2018 um 21:50 schrieb Andy Shevchenko :
> 
> On Wed, May 16, 2018 at 8:01 PM, H. Nikolaus Schaller  
> wrote:
>> These mask bits are to be used to map the extended register
>> addreseses (which are defined for an unsupported 8-bit pcal chip)
>> to 16 and 24 bit chips (pcal6524).
>> 
>> Reviewed-by: Andy Shevchenko 
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> drivers/gpio/gpio-pca953x.c | 4 
>> 1 file changed, 4 insertions(+)
>> 
>> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
>> index 2b667166e855..c0eb679e60d4 100644
>> --- a/drivers/gpio/gpio-pca953x.c
>> +++ b/drivers/gpio/gpio-pca953x.c
>> @@ -56,6 +56,10 @@
>> #define PCAL6524_DEBOUNCE  0x2d
>> 
>> #define PCA_GPIO_MASK  0x00FF
>> +
>> +#define PCAL_GPIO_MASK GENMASK(4, 0)
>> +#define PCAL_PINCTRL_MASK  (~PCAL_GPIO_MASK)
>> +
> 
> I give second thought about it, and think
> either plain values, or second converted to its own explicit GENMASK
> would be better.
> 
> (most confusing part to me is unknowness of the side of PINCTRL part
> in the mask)

I see.

Then, I'd also prefer plain values.

If ok, I can send a v7 tomorrow.

BR,
Nikolaus

[PATCH] sched/debug: Move print_rt_rq and print_dl_rq declarations to kernel/sched/sched.h

[Mathieu Malaterre]

In commit 6b55c9654fcc ("sched/debug: Move print_cfs_rq() declaration to
kernel/sched/sched.h"), ‘print_cfs_rq’ prototype was added to
 right next to prototypes for ‘print_cfs_stats’,
‘print_rt_stats’ and ‘print_dl_stats’. Update this previous commit
and also move related prototypes: ‘print_rt_rq’ and ‘print_dl_rq’.
Remove existing extern declarations now that they not needed anymore.

Silence the following gcc warning, triggered at W=1:

  kernel/sched/debug.c:573:6: warning: no previous prototype for ‘print_rt_rq’ 
[-Wmissing-prototypes]
  kernel/sched/debug.c:603:6: warning: no previous prototype for ‘print_dl_rq’ 
[-Wmissing-prototypes]

Signed-off-by: Mathieu Malaterre 
---
 kernel/sched/deadline.c | 2 --
 kernel/sched/rt.c   | 2 --
 kernel/sched/sched.h| 5 +++--
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 125703d9b25e..1356afd1eeb6 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -2731,8 +2731,6 @@ bool dl_cpu_busy(unsigned int cpu)
 #endif
 
 #ifdef CONFIG_SCHED_DEBUG
-extern void print_dl_rq(struct seq_file *m, int cpu, struct dl_rq *dl_rq);
-
 void print_dl_stats(struct seq_file *m, int cpu)
 {
print_dl_rq(m, cpu, _rq(cpu)->dl);
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 7aef6b4e885a..ef3c4e6f5345 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2701,8 +2701,6 @@ int sched_rr_handler(struct ctl_table *table, int write,
 }
 
 #ifdef CONFIG_SCHED_DEBUG
-extern void print_rt_rq(struct seq_file *m, int cpu, struct rt_rq *rt_rq);
-
 void print_rt_stats(struct seq_file *m, int cpu)
 {
rt_rq_iter_t iter;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 15750c222ca2..1f0a4bc6a39d 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2025,8 +2025,9 @@ extern bool sched_debug_enabled;
 extern void print_cfs_stats(struct seq_file *m, int cpu);
 extern void print_rt_stats(struct seq_file *m, int cpu);
 extern void print_dl_stats(struct seq_file *m, int cpu);
-extern void
-print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq);
+extern void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq);
+extern void print_rt_rq(struct seq_file *m, int cpu, struct rt_rq *rt_rq);
+extern void print_dl_rq(struct seq_file *m, int cpu, struct dl_rq *dl_rq);
 #ifdef CONFIG_NUMA_BALANCING
 extern void
 show_numa_stats(struct task_struct *p, struct seq_file *m);
-- 
2.11.0

[PATCH] sched/debug: Move print_rt_rq and print_dl_rq declarations to kernel/sched/sched.h

[Mathieu Malaterre]

In commit 6b55c9654fcc ("sched/debug: Move print_cfs_rq() declaration to
kernel/sched/sched.h"), ‘print_cfs_rq’ prototype was added to
 right next to prototypes for ‘print_cfs_stats’,
‘print_rt_stats’ and ‘print_dl_stats’. Update this previous commit
and also move related prototypes: ‘print_rt_rq’ and ‘print_dl_rq’.
Remove existing extern declarations now that they not needed anymore.

Silence the following gcc warning, triggered at W=1:

  kernel/sched/debug.c:573:6: warning: no previous prototype for ‘print_rt_rq’ 
[-Wmissing-prototypes]
  kernel/sched/debug.c:603:6: warning: no previous prototype for ‘print_dl_rq’ 
[-Wmissing-prototypes]

Signed-off-by: Mathieu Malaterre 
---
 kernel/sched/deadline.c | 2 --
 kernel/sched/rt.c   | 2 --
 kernel/sched/sched.h| 5 +++--
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 125703d9b25e..1356afd1eeb6 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -2731,8 +2731,6 @@ bool dl_cpu_busy(unsigned int cpu)
 #endif
 
 #ifdef CONFIG_SCHED_DEBUG
-extern void print_dl_rq(struct seq_file *m, int cpu, struct dl_rq *dl_rq);
-
 void print_dl_stats(struct seq_file *m, int cpu)
 {
print_dl_rq(m, cpu, _rq(cpu)->dl);
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 7aef6b4e885a..ef3c4e6f5345 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2701,8 +2701,6 @@ int sched_rr_handler(struct ctl_table *table, int write,
 }
 
 #ifdef CONFIG_SCHED_DEBUG
-extern void print_rt_rq(struct seq_file *m, int cpu, struct rt_rq *rt_rq);
-
 void print_rt_stats(struct seq_file *m, int cpu)
 {
rt_rq_iter_t iter;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 15750c222ca2..1f0a4bc6a39d 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2025,8 +2025,9 @@ extern bool sched_debug_enabled;
 extern void print_cfs_stats(struct seq_file *m, int cpu);
 extern void print_rt_stats(struct seq_file *m, int cpu);
 extern void print_dl_stats(struct seq_file *m, int cpu);
-extern void
-print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq);
+extern void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq);
+extern void print_rt_rq(struct seq_file *m, int cpu, struct rt_rq *rt_rq);
+extern void print_dl_rq(struct seq_file *m, int cpu, struct dl_rq *dl_rq);
 #ifdef CONFIG_NUMA_BALANCING
 extern void
 show_numa_stats(struct task_struct *p, struct seq_file *m);
-- 
2.11.0

Re: [PATCH 4.4 014/190] lockd: fix lockd shutdown race

[J. Bruce Fields]

On Tue, May 15, 2018 at 07:44:24PM +0100, Ben Hutchings wrote:
> On Wed, 2018-04-11 at 20:34 +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: "J. Bruce Fields" 
> > 
> > 
> > [ Upstream commit efda760fe95ea15291853c8fa9235c32d319cd98 ]
> [...]
> > --- a/fs/lockd/svc.c
> > +++ b/fs/lockd/svc.c
> > @@ -129,6 +129,8 @@ lockd(void *vrqstp)
> >  {
> >     int err = 0;
> >     struct svc_rqst *rqstp = vrqstp;
> > +   struct net *net = _net;
> > +   struct lockd_net *ln = net_generic(net, lockd_net_id);
> >  
> >     /* try_to_freeze() is called from svc_recv() */
> >     set_freezable();
> > @@ -173,6 +175,8 @@ lockd(void *vrqstp)
> >     if (nlmsvc_ops)
> >     nlmsvc_invalidate_all();
> > nlm_shutdown_hosts();
> > +   cancel_delayed_work_sync(>grace_period_end);
> > +   locks_end_grace(>lockd_manager);
> >     return 0;
> >  }
> >  
> > @@ -267,8 +271,6 @@ static void lockd_down_net(struct svc_se
> >     if (ln->nlmsvc_users) {
> >     if (--ln->nlmsvc_users == 0) {
> >     nlm_shutdown_hosts_net(net);
> > -   cancel_delayed_work_sync(>grace_period_end);
> > -   locks_end_grace(>lockd_manager);
> 
> Aren't these statements still needed for non-initial namespaces?

Looks like this this should be backported only if 3a2b19d1ee56 "lockd:
lost rollback of set_grace_period() in lockd_down_net()" is also.

--b.

Re: [PATCH v6 0/3] pcal6524 extensions and fixes for pca953x driver

[Andy Shevchenko]

On Wed, May 16, 2018 at 8:01 PM, H. Nikolaus Schaller  
wrote:
> V6:
> * added proper attribution to the formula used for fixing the
>   pcal6524 register address (changes commit message only)
> * add back missing first patch from V2 that defines the
>   PCA_LATCH_INT constant
> * removed patches already merged
>

Thanks for an update.
I think we still need to address the constant representation in patch 2.

For the rest take my
Reviewed-by: Andy Shevchenko 

> 2018-04-28 18:33:42: V5:
> * fix wrong split up between patches 1/7 and 2/7.
>
> 2018-04-26 19:35:07: V4:
> * introduced PCA_LATCH_INT constant to make of_table more
>   readable (suggested by Andy Shevchenko)
> * converted all register constants to hex in a separate
>   patch (suggested by Andy Shevchenko)
> * separated additional pcal953x and pcal6524 register
>   definitions into separate patches (suggested by Andy Shevchenko)
> * made special pcal6524 address adjustment more readable
>   (suggested by Andy Shevchenko)
> * moved gpio-controller and interrupt-controller to the
>   "required" section (reviewed by Rob Herring)
>
> 2018-04-10 18:07:07: V3:
> * add Reported-by: and Reviewed-by:
> * fix wording for bindings description and example
> * convert all register offsets to hex
> * omit the LEVEL-IRQ RFC/hack commit
>
> 2018-04-04 21:00:27: V2:
> * added PCA_PCAL flags if matched through of-table
> * fix address calculation for extended PCAL6524 registers
> * hack to map LEVEL_LOW to EDGE_FALLING to be able to
>   test in combination with ts3a227e driver
> * improve description of bindings for optional vcc-supply
>   and interrupt-controller;
>
> 2018-03-10 09:32:53: no initial description
>
> H. Nikolaus Schaller (3):
>   gpio: pca953x: set the PCA_PCAL flag also when matching by DT
>   gpio: pca953x: define masks for addressing common and extended
> registers
>   gpio: pca953x: fix address calculation for pcal6524
>
>  drivers/gpio/gpio-pca953x.c | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
>
> --
> 2.12.2
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 4.4 014/190] lockd: fix lockd shutdown race

[J. Bruce Fields]

On Tue, May 15, 2018 at 07:44:24PM +0100, Ben Hutchings wrote:
> On Wed, 2018-04-11 at 20:34 +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: "J. Bruce Fields" 
> > 
> > 
> > [ Upstream commit efda760fe95ea15291853c8fa9235c32d319cd98 ]
> [...]
> > --- a/fs/lockd/svc.c
> > +++ b/fs/lockd/svc.c
> > @@ -129,6 +129,8 @@ lockd(void *vrqstp)
> >  {
> >     int err = 0;
> >     struct svc_rqst *rqstp = vrqstp;
> > +   struct net *net = _net;
> > +   struct lockd_net *ln = net_generic(net, lockd_net_id);
> >  
> >     /* try_to_freeze() is called from svc_recv() */
> >     set_freezable();
> > @@ -173,6 +175,8 @@ lockd(void *vrqstp)
> >     if (nlmsvc_ops)
> >     nlmsvc_invalidate_all();
> > nlm_shutdown_hosts();
> > +   cancel_delayed_work_sync(>grace_period_end);
> > +   locks_end_grace(>lockd_manager);
> >     return 0;
> >  }
> >  
> > @@ -267,8 +271,6 @@ static void lockd_down_net(struct svc_se
> >     if (ln->nlmsvc_users) {
> >     if (--ln->nlmsvc_users == 0) {
> >     nlm_shutdown_hosts_net(net);
> > -   cancel_delayed_work_sync(>grace_period_end);
> > -   locks_end_grace(>lockd_manager);
> 
> Aren't these statements still needed for non-initial namespaces?

Looks like this this should be backported only if 3a2b19d1ee56 "lockd:
lost rollback of set_grace_period() in lockd_down_net()" is also.

--b.

Re: [PATCH v6 0/3] pcal6524 extensions and fixes for pca953x driver

[Andy Shevchenko]

On Wed, May 16, 2018 at 8:01 PM, H. Nikolaus Schaller  
wrote:
> V6:
> * added proper attribution to the formula used for fixing the
>   pcal6524 register address (changes commit message only)
> * add back missing first patch from V2 that defines the
>   PCA_LATCH_INT constant
> * removed patches already merged
>

Thanks for an update.
I think we still need to address the constant representation in patch 2.

For the rest take my
Reviewed-by: Andy Shevchenko 

> 2018-04-28 18:33:42: V5:
> * fix wrong split up between patches 1/7 and 2/7.
>
> 2018-04-26 19:35:07: V4:
> * introduced PCA_LATCH_INT constant to make of_table more
>   readable (suggested by Andy Shevchenko)
> * converted all register constants to hex in a separate
>   patch (suggested by Andy Shevchenko)
> * separated additional pcal953x and pcal6524 register
>   definitions into separate patches (suggested by Andy Shevchenko)
> * made special pcal6524 address adjustment more readable
>   (suggested by Andy Shevchenko)
> * moved gpio-controller and interrupt-controller to the
>   "required" section (reviewed by Rob Herring)
>
> 2018-04-10 18:07:07: V3:
> * add Reported-by: and Reviewed-by:
> * fix wording for bindings description and example
> * convert all register offsets to hex
> * omit the LEVEL-IRQ RFC/hack commit
>
> 2018-04-04 21:00:27: V2:
> * added PCA_PCAL flags if matched through of-table
> * fix address calculation for extended PCAL6524 registers
> * hack to map LEVEL_LOW to EDGE_FALLING to be able to
>   test in combination with ts3a227e driver
> * improve description of bindings for optional vcc-supply
>   and interrupt-controller;
>
> 2018-03-10 09:32:53: no initial description
>
> H. Nikolaus Schaller (3):
>   gpio: pca953x: set the PCA_PCAL flag also when matching by DT
>   gpio: pca953x: define masks for addressing common and extended
> registers
>   gpio: pca953x: fix address calculation for pcal6524
>
>  drivers/gpio/gpio-pca953x.c | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
>
> --
> 2.12.2
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 2/3] gpio: pca953x: define masks for addressing common and extended registers

[Andy Shevchenko]

On Wed, May 16, 2018 at 8:01 PM, H. Nikolaus Schaller  
wrote:
> These mask bits are to be used to map the extended register
> addreseses (which are defined for an unsupported 8-bit pcal chip)
> to 16 and 24 bit chips (pcal6524).
>
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  drivers/gpio/gpio-pca953x.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index 2b667166e855..c0eb679e60d4 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -56,6 +56,10 @@
>  #define PCAL6524_DEBOUNCE  0x2d
>
>  #define PCA_GPIO_MASK  0x00FF
> +
> +#define PCAL_GPIO_MASK GENMASK(4, 0)
> +#define PCAL_PINCTRL_MASK  (~PCAL_GPIO_MASK)
> +

I give second thought about it, and think
either plain values, or second converted to its own explicit GENMASK
would be better.

(most confusing part to me is unknowness of the side of PINCTRL part
in the mask)


>  #define PCA_INT0x0100
>  #define PCA_PCAL   0x0200
>  #define PCA_LATCH_INT (PCA_PCAL | PCA_INT)
> --
> 2.12.2
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 2/3] gpio: pca953x: define masks for addressing common and extended registers

[Andy Shevchenko]

On Wed, May 16, 2018 at 8:01 PM, H. Nikolaus Schaller  
wrote:
> These mask bits are to be used to map the extended register
> addreseses (which are defined for an unsupported 8-bit pcal chip)
> to 16 and 24 bit chips (pcal6524).
>
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  drivers/gpio/gpio-pca953x.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index 2b667166e855..c0eb679e60d4 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -56,6 +56,10 @@
>  #define PCAL6524_DEBOUNCE  0x2d
>
>  #define PCA_GPIO_MASK  0x00FF
> +
> +#define PCAL_GPIO_MASK GENMASK(4, 0)
> +#define PCAL_PINCTRL_MASK  (~PCAL_GPIO_MASK)
> +

I give second thought about it, and think
either plain values, or second converted to its own explicit GENMASK
would be better.

(most confusing part to me is unknowness of the side of PINCTRL part
in the mask)


>  #define PCA_INT0x0100
>  #define PCA_PCAL   0x0200
>  #define PCA_LATCH_INT (PCA_PCAL | PCA_INT)
> --
> 2.12.2
>



-- 
With Best Regards,
Andy Shevchenko

[PATCH] MAINTAINERS: update sound/soc/intel maintainers

[Pierre-Louis Bossart]

The information for Intel SoC drivers was not updated for several
years. Add myself, Liam and Keyon (Jie) as maintainers to get notified
of contributions and bug reports. As discussed with Mark and Takashi,
I'll also monitor alsa-devel and ack Intel patches as necessary.

Signed-off-by: Pierre-Louis Bossart 
---
 MAINTAINERS | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e83cee26e195..d70add4c253b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7030,14 +7030,13 @@ L:  linux-fb...@vger.kernel.org
 S: Maintained
 F: drivers/video/fbdev/i810/
 
-INTEL ASoC BDW/HSW DRIVERS
+INTEL ASoC DRIVERS
+M: Pierre-Louis Bossart 
+M: Liam Girdwood 
 M: Jie Yang 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
 S: Supported
-F: sound/soc/intel/common/sst-dsp*
-F: sound/soc/intel/common/sst-firmware.c
-F: sound/soc/intel/boards/broadwell.c
-F: sound/soc/intel/haswell/
+F: sound/soc/intel/
 
 INTEL C600 SERIES SAS CONTROLLER DRIVER
 M: Intel SCU Linux support 
-- 
2.14.1

[PATCH] MAINTAINERS: update sound/soc/intel maintainers

[Pierre-Louis Bossart]

The information for Intel SoC drivers was not updated for several
years. Add myself, Liam and Keyon (Jie) as maintainers to get notified
of contributions and bug reports. As discussed with Mark and Takashi,
I'll also monitor alsa-devel and ack Intel patches as necessary.

Signed-off-by: Pierre-Louis Bossart 
---
 MAINTAINERS | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e83cee26e195..d70add4c253b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7030,14 +7030,13 @@ L:  linux-fb...@vger.kernel.org
 S: Maintained
 F: drivers/video/fbdev/i810/
 
-INTEL ASoC BDW/HSW DRIVERS
+INTEL ASoC DRIVERS
+M: Pierre-Louis Bossart 
+M: Liam Girdwood 
 M: Jie Yang 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
 S: Supported
-F: sound/soc/intel/common/sst-dsp*
-F: sound/soc/intel/common/sst-firmware.c
-F: sound/soc/intel/boards/broadwell.c
-F: sound/soc/intel/haswell/
+F: sound/soc/intel/
 
 INTEL C600 SERIES SAS CONTROLLER DRIVER
 M: Intel SCU Linux support 
-- 
2.14.1

Re: [PATCH net-next 09/10] net: hns3: Add support of .sriov_configure in HNS3 driver

[kbuild test robot]

Hi Peng,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Salil-Mehta/Misc-Bug-Fixes-and-clean-ups-for-HNS3-Driver/20180516-211239
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:266:16: sparse: expression 
using sizeof(void)
   drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:266:16: sparse: expression 
using sizeof(void)
>> drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:1582:5: sparse: symbol 
>> 'hns3_pci_sriov_configure' was not declared. Should it be static?
   drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2513:21: sparse: expression 
using sizeof(void)
   drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2706:22: sparse: expression 
using sizeof(void)
   drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2706:22: sparse: expression 
using sizeof(void)

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH net-next 09/10] net: hns3: Add support of .sriov_configure in HNS3 driver

[kbuild test robot]

Hi Peng,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Salil-Mehta/Misc-Bug-Fixes-and-clean-ups-for-HNS3-Driver/20180516-211239
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:266:16: sparse: expression 
using sizeof(void)
   drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:266:16: sparse: expression 
using sizeof(void)
>> drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:1582:5: sparse: symbol 
>> 'hns3_pci_sriov_configure' was not declared. Should it be static?
   drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2513:21: sparse: expression 
using sizeof(void)
   drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2706:22: sparse: expression 
using sizeof(void)
   drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2706:22: sparse: expression 
using sizeof(void)

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

[RFC PATCH] net: hns3: hns3_pci_sriov_configure() can be static

[kbuild test robot]

Fixes: fdb793670a00 ("net: hns3: Add support of .sriov_configure in HNS3 
driver")
Signed-off-by: Fengguang Wu 
---
 hns3_enet.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index e85ff38..3617b9d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1579,7 +1579,7 @@ static void hns3_remove(struct pci_dev *pdev)
  * Enable or change the number of VFs. Called when the user updates the number
  * of VFs in sysfs.
  **/
-int hns3_pci_sriov_configure(struct pci_dev *pdev, int num_vfs)
+static int hns3_pci_sriov_configure(struct pci_dev *pdev, int num_vfs)
 {
int ret;
 

[RFC PATCH] net: hns3: hns3_pci_sriov_configure() can be static

[kbuild test robot]

Fixes: fdb793670a00 ("net: hns3: Add support of .sriov_configure in HNS3 
driver")
Signed-off-by: Fengguang Wu 
---
 hns3_enet.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index e85ff38..3617b9d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1579,7 +1579,7 @@ static void hns3_remove(struct pci_dev *pdev)
  * Enable or change the number of VFs. Called when the user updates the number
  * of VFs in sysfs.
  **/
-int hns3_pci_sriov_configure(struct pci_dev *pdev, int num_vfs)
+static int hns3_pci_sriov_configure(struct pci_dev *pdev, int num_vfs)
 {
int ret;
 

[PATCH v2 3/4] coresight: allow to build as modules

[Kim Phillips]

Allow to build coresight as modules.  This greatly enhances developer
efficiency by allowing the development to take place exclusively on the
target, and without needing to reboot in between changes.

- Kconfig bools become tristates, to allow =m

- MODULE_* macros added:  Please correct me if I'm wrong:
  - assume LICENSE is "GPL v2"
  - tried to get as close to original authors for MODULE_AUTHOR

- The 'select' Kconfig statements are replaced with 'depends on'
  clauses, to specify the dependencies between the modules including
  other fixes, e.g., coresight-stm unconditionally calls
  stm_register_device, it therefore depends on STM.

- use -objs to denote merge object directives in Makefile, adds a
  coresight-core nomenclature for the base module.

- add a coresight_exit() that unregisters the coresight bus, add remove
  fns for most others.

- fix up modules with ID tables for autoloading on boot, add missing
  __exit attributes

- move coresight_vpid_to_pid to an externed, single instance in
  coresight-core, to be used by all submodules.

Cc: Mathieu Poirier 
Cc: Alexander Shishkin 
Cc: Randy Dunlap 
Signed-off-by: Kim Phillips 
---
Changes from v1:
 - remove depends on coresight that are in the if CORESIGHT block
   (Randy Dunlap)
 - actually call tmc_read_unprepare() in tmc_remove() this time,
   instead of open-coding the kfree, dma_free_coherent calls.
 - rebased and removed coresight_vpid_to_pid relocation on this
   new series this patch now depends on:
https://www.spinics.net/lists/arm-kernel/msg652755.html
   That new series eliminates patch 2/4 from this series (patches
   1 and 4 of this series remain the same).

Changes from versions previous to v1, sent only to coresight mailing
list:

 - tmc_remove: free buffer used by TMC-ETR and TMC-ETF by calling
   tmc_read_unprepare()
 - fixed an unbalanced pm_runtime_enable in coresight-replicator
 - etm[4]_remove():  call cpuhp_remove_state_nocalls() and
   etm_perf_symlink(.., false) to clear up cpuhp and symlink state
 - add module parent checks for all enable/disable functions, source
   and sink modules
   - refactored device ptr dereferences by introducing a new parent_dev
 variable
 - corrected replicator author
 - whitespace fix in funnel driver

 - added user Kconfig help text with the names of the modules.
 - Addressed Mathieu's comments:
   - renamed coresight-link-sink-tmc coresight-tmc-core
   - prevent ability to crash the system by removing drivers from an
 active path by adding try_module_get() and module_put() calls in
 funnel and replicator drivers' enable and disable functions (thanks for
 figuring that out, Mathieu).

 - Addressed most of Mathieu's comments:
   - rm __inits causing linker section mismatch errors
   - barrier_pkt made static, moved to coresight_priv.h
   - rm unnecessary tmc_* EXPORT_SYMBOL leftovers
   - add some missing MODULE_AUTHORs

 drivers/hwtracing/coresight/Kconfig   | 60 +--
 drivers/hwtracing/coresight/Makefile  | 28 ++---
 .../hwtracing/coresight/coresight-cpu-debug.c |  2 +
 .../coresight/coresight-dynamic-replicator.c  | 30 +-
 drivers/hwtracing/coresight/coresight-etb10.c | 32 +-
 .../hwtracing/coresight/coresight-etm-cp14.c  |  4 ++
 .../hwtracing/coresight/coresight-etm-perf.c  | 13 +++-
 .../hwtracing/coresight/coresight-etm-perf.h  |  2 +-
 .../coresight/coresight-etm3x-sysfs.c |  6 ++
 drivers/hwtracing/coresight/coresight-etm3x.c | 37 +++-
 .../coresight/coresight-etm4x-sysfs.c |  6 ++
 drivers/hwtracing/coresight/coresight-etm4x.c | 38 +++-
 .../hwtracing/coresight/coresight-funnel.c| 30 +-
 drivers/hwtracing/coresight/coresight-priv.h  | 10 +++-
 .../coresight/coresight-replicator.c  | 33 +-
 drivers/hwtracing/coresight/coresight-stm.c   | 27 -
 .../hwtracing/coresight/coresight-tmc-etf.c   |  2 +
 .../hwtracing/coresight/coresight-tmc-etr.c   |  2 +
 drivers/hwtracing/coresight/coresight-tmc.c   | 22 ++-
 drivers/hwtracing/coresight/coresight-tpiu.c  | 31 +-
 drivers/hwtracing/coresight/coresight.c   | 26 +---
 include/linux/coresight.h |  2 +-
 22 files changed, 380 insertions(+), 63 deletions(-)

diff --git a/drivers/hwtracing/coresight/Kconfig 
b/drivers/hwtracing/coresight/Kconfig
index ef9cb3c164e1..c1e782d4c217 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -2,8 +2,8 @@
 # Coresight configuration
 #
 menuconfig CORESIGHT
-   bool "CoreSight Tracing Support"
-   select ARM_AMBA
+   tristate "CoreSight Tracing Support"
+   depends on ARM_AMBA
select PERF_EVENTS
help
  This framework provides a kernel interface for the CoreSight debug
@@ -12,17 +12,23 @@ menuconfig CORESIGHT
  specification and 

[PATCH v2 3/4] coresight: allow to build as modules

[Kim Phillips]

Allow to build coresight as modules.  This greatly enhances developer
efficiency by allowing the development to take place exclusively on the
target, and without needing to reboot in between changes.

- Kconfig bools become tristates, to allow =m

- MODULE_* macros added:  Please correct me if I'm wrong:
  - assume LICENSE is "GPL v2"
  - tried to get as close to original authors for MODULE_AUTHOR

- The 'select' Kconfig statements are replaced with 'depends on'
  clauses, to specify the dependencies between the modules including
  other fixes, e.g., coresight-stm unconditionally calls
  stm_register_device, it therefore depends on STM.

- use -objs to denote merge object directives in Makefile, adds a
  coresight-core nomenclature for the base module.

- add a coresight_exit() that unregisters the coresight bus, add remove
  fns for most others.

- fix up modules with ID tables for autoloading on boot, add missing
  __exit attributes

- move coresight_vpid_to_pid to an externed, single instance in
  coresight-core, to be used by all submodules.

Cc: Mathieu Poirier 
Cc: Alexander Shishkin 
Cc: Randy Dunlap 
Signed-off-by: Kim Phillips 
---
Changes from v1:
 - remove depends on coresight that are in the if CORESIGHT block
   (Randy Dunlap)
 - actually call tmc_read_unprepare() in tmc_remove() this time,
   instead of open-coding the kfree, dma_free_coherent calls.
 - rebased and removed coresight_vpid_to_pid relocation on this
   new series this patch now depends on:
https://www.spinics.net/lists/arm-kernel/msg652755.html
   That new series eliminates patch 2/4 from this series (patches
   1 and 4 of this series remain the same).

Changes from versions previous to v1, sent only to coresight mailing
list:

 - tmc_remove: free buffer used by TMC-ETR and TMC-ETF by calling
   tmc_read_unprepare()
 - fixed an unbalanced pm_runtime_enable in coresight-replicator
 - etm[4]_remove():  call cpuhp_remove_state_nocalls() and
   etm_perf_symlink(.., false) to clear up cpuhp and symlink state
 - add module parent checks for all enable/disable functions, source
   and sink modules
   - refactored device ptr dereferences by introducing a new parent_dev
 variable
 - corrected replicator author
 - whitespace fix in funnel driver

 - added user Kconfig help text with the names of the modules.
 - Addressed Mathieu's comments:
   - renamed coresight-link-sink-tmc coresight-tmc-core
   - prevent ability to crash the system by removing drivers from an
 active path by adding try_module_get() and module_put() calls in
 funnel and replicator drivers' enable and disable functions (thanks for
 figuring that out, Mathieu).

 - Addressed most of Mathieu's comments:
   - rm __inits causing linker section mismatch errors
   - barrier_pkt made static, moved to coresight_priv.h
   - rm unnecessary tmc_* EXPORT_SYMBOL leftovers
   - add some missing MODULE_AUTHORs

 drivers/hwtracing/coresight/Kconfig   | 60 +--
 drivers/hwtracing/coresight/Makefile  | 28 ++---
 .../hwtracing/coresight/coresight-cpu-debug.c |  2 +
 .../coresight/coresight-dynamic-replicator.c  | 30 +-
 drivers/hwtracing/coresight/coresight-etb10.c | 32 +-
 .../hwtracing/coresight/coresight-etm-cp14.c  |  4 ++
 .../hwtracing/coresight/coresight-etm-perf.c  | 13 +++-
 .../hwtracing/coresight/coresight-etm-perf.h  |  2 +-
 .../coresight/coresight-etm3x-sysfs.c |  6 ++
 drivers/hwtracing/coresight/coresight-etm3x.c | 37 +++-
 .../coresight/coresight-etm4x-sysfs.c |  6 ++
 drivers/hwtracing/coresight/coresight-etm4x.c | 38 +++-
 .../hwtracing/coresight/coresight-funnel.c| 30 +-
 drivers/hwtracing/coresight/coresight-priv.h  | 10 +++-
 .../coresight/coresight-replicator.c  | 33 +-
 drivers/hwtracing/coresight/coresight-stm.c   | 27 -
 .../hwtracing/coresight/coresight-tmc-etf.c   |  2 +
 .../hwtracing/coresight/coresight-tmc-etr.c   |  2 +
 drivers/hwtracing/coresight/coresight-tmc.c   | 22 ++-
 drivers/hwtracing/coresight/coresight-tpiu.c  | 31 +-
 drivers/hwtracing/coresight/coresight.c   | 26 +---
 include/linux/coresight.h |  2 +-
 22 files changed, 380 insertions(+), 63 deletions(-)

diff --git a/drivers/hwtracing/coresight/Kconfig 
b/drivers/hwtracing/coresight/Kconfig
index ef9cb3c164e1..c1e782d4c217 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -2,8 +2,8 @@
 # Coresight configuration
 #
 menuconfig CORESIGHT
-   bool "CoreSight Tracing Support"
-   select ARM_AMBA
+   tristate "CoreSight Tracing Support"
+   depends on ARM_AMBA
select PERF_EVENTS
help
  This framework provides a kernel interface for the CoreSight debug
@@ -12,17 +12,23 @@ menuconfig CORESIGHT
  specification and configure the right series of components when a
  trace source gets enabled.
 
+ To compile this code 

Re: [PATCH v2] vfio/mdev: Check globally for duplicate devices

[Kirti Wankhede]

On 5/16/2018 8:53 PM, Alex Williamson wrote:
> When we create an mdev device, we check for duplicates against the
> parent device and return -EEXIST if found, but the mdev device
> namespace is global since we'll link all devices from the bus.  We do
> catch this later in sysfs_do_create_link_sd() to return -EEXIST, but
> with it comes a kernel warning and stack trace for trying to create
> duplicate sysfs links, which makes it an undesirable response.
> 
> Therefore we should really be looking for duplicates across all mdev
> parent devices, or as implemented here, against our mdev device list.
> 
> Notably, mdev_parent.lock really only seems to be serializing device
> creation and removal per parent.  I'm not sure if this is necessary,
> mdev vendor drivers could easily provide this serialization if it
> is required, but a side-effect of holding the mdev_list_lock to
> protect the namespace is actually greater serialization across the
> create and remove paths,

Exactly for this reason more granular lock is used and that's the reason
mdev_parent.lock was introduced. Consider the max supported config for
vGPU: 8 GPUs in a system with 16 mdev devices on each GPUs, i.e. 128
mdev devices need to be created in a system, and this count will
increase in future, all mdev device creation/removal will get serialized
with this change.
I agree with your concern that if there are duplicates across parents,
its not caught earlier.

> so mdev_parent.lock is removed.  If we can
> show that vendor drivers handle the create/remove paths themselves,
> perhaps we can refine the locking granularity.
> 

Here lock is not for create/remove routines of vendor driver, its about
mdev device creation and device registration, which is a common code
path, and so is part of mdev core module.


> Reviewed-by: Cornelia Huck 
> Signed-off-by: Alex Williamson 
> ---
> 
> v2: Remove unnecessary ret init per Cornelia's review
> 
>  drivers/vfio/mdev/mdev_core.c|   77 
> +-
>  drivers/vfio/mdev/mdev_private.h |1 
>  2 files changed, 19 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index 126991046eb7..aaab3ef93e1c 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -66,34 +66,6 @@ uuid_le mdev_uuid(struct mdev_device *mdev)
>  }
>  EXPORT_SYMBOL(mdev_uuid);
>  
> -static int _find_mdev_device(struct device *dev, void *data)
> -{
> - struct mdev_device *mdev;
> -
> - if (!dev_is_mdev(dev))
> - return 0;
> -
> - mdev = to_mdev_device(dev);
> -
> - if (uuid_le_cmp(mdev->uuid, *(uuid_le *)data) == 0)
> - return 1;
> -
> - return 0;
> -}
> -
> -static bool mdev_device_exist(struct mdev_parent *parent, uuid_le uuid)
> -{
> - struct device *dev;
> -
> - dev = device_find_child(parent->dev, , _find_mdev_device);
> - if (dev) {
> - put_device(dev);
> - return true;
> - }
> -
> - return false;
> -}
> -
>  /* Should be called holding parent_list_lock */
>  static struct mdev_parent *__find_parent_device(struct device *dev)
>  {
> @@ -221,7 +193,6 @@ int mdev_register_device(struct device *dev, const struct 
> mdev_parent_ops *ops)
>   }
>  
>   kref_init(>ref);
> - mutex_init(>lock);
>  
>   parent->dev = dev;
>   parent->ops = ops;
> @@ -304,7 +275,7 @@ static void mdev_device_release(struct device *dev)
>  int mdev_device_create(struct kobject *kobj, struct device *dev, uuid_le 
> uuid)
>  {
>   int ret;
> - struct mdev_device *mdev;
> + struct mdev_device *mdev, *tmp;
>   struct mdev_parent *parent;
>   struct mdev_type *type = to_mdev_type(kobj);
>  
> @@ -312,12 +283,14 @@ int mdev_device_create(struct kobject *kobj, struct 
> device *dev, uuid_le uuid)
>   if (!parent)
>   return -EINVAL;
>  
> - mutex_lock(>lock);
> + mutex_lock(_list_lock);
>  
>   /* Check for duplicate */
> - if (mdev_device_exist(parent, uuid)) {
> - ret = -EEXIST;
> - goto create_err;
> + list_for_each_entry(tmp, _list, next) {
> + if (!uuid_le_cmp(tmp->uuid, uuid)) {
> + ret = -EEXIST;
> + goto create_err;
> + }
>   }
>
Is it possible to use mdev_list_lock for as minimal portion as possible?
By adding mdev device to mdev_list just after:
memcpy(>uuid, , sizeof(uuid_le));
and then unlock mdev_list_lock, but at the same time all later error
cases need to be handled properly in this function.

Thanks,
Kirti


>   mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
> @@ -354,9 +327,6 @@ int mdev_device_create(struct kobject *kobj, struct 
> device *dev, uuid_le uuid)
>   mdev->type_kobj = kobj;
>   dev_dbg(>dev, "MDEV: created\n");
>  
> - mutex_unlock(>lock);
> -
> - mutex_lock(_list_lock);
>   

Re: [PATCH v2] vfio/mdev: Check globally for duplicate devices

[Kirti Wankhede]

On 5/16/2018 8:53 PM, Alex Williamson wrote:
> When we create an mdev device, we check for duplicates against the
> parent device and return -EEXIST if found, but the mdev device
> namespace is global since we'll link all devices from the bus.  We do
> catch this later in sysfs_do_create_link_sd() to return -EEXIST, but
> with it comes a kernel warning and stack trace for trying to create
> duplicate sysfs links, which makes it an undesirable response.
> 
> Therefore we should really be looking for duplicates across all mdev
> parent devices, or as implemented here, against our mdev device list.
> 
> Notably, mdev_parent.lock really only seems to be serializing device
> creation and removal per parent.  I'm not sure if this is necessary,
> mdev vendor drivers could easily provide this serialization if it
> is required, but a side-effect of holding the mdev_list_lock to
> protect the namespace is actually greater serialization across the
> create and remove paths,

Exactly for this reason more granular lock is used and that's the reason
mdev_parent.lock was introduced. Consider the max supported config for
vGPU: 8 GPUs in a system with 16 mdev devices on each GPUs, i.e. 128
mdev devices need to be created in a system, and this count will
increase in future, all mdev device creation/removal will get serialized
with this change.
I agree with your concern that if there are duplicates across parents,
its not caught earlier.

> so mdev_parent.lock is removed.  If we can
> show that vendor drivers handle the create/remove paths themselves,
> perhaps we can refine the locking granularity.
> 

Here lock is not for create/remove routines of vendor driver, its about
mdev device creation and device registration, which is a common code
path, and so is part of mdev core module.


> Reviewed-by: Cornelia Huck 
> Signed-off-by: Alex Williamson 
> ---
> 
> v2: Remove unnecessary ret init per Cornelia's review
> 
>  drivers/vfio/mdev/mdev_core.c|   77 
> +-
>  drivers/vfio/mdev/mdev_private.h |1 
>  2 files changed, 19 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index 126991046eb7..aaab3ef93e1c 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -66,34 +66,6 @@ uuid_le mdev_uuid(struct mdev_device *mdev)
>  }
>  EXPORT_SYMBOL(mdev_uuid);
>  
> -static int _find_mdev_device(struct device *dev, void *data)
> -{
> - struct mdev_device *mdev;
> -
> - if (!dev_is_mdev(dev))
> - return 0;
> -
> - mdev = to_mdev_device(dev);
> -
> - if (uuid_le_cmp(mdev->uuid, *(uuid_le *)data) == 0)
> - return 1;
> -
> - return 0;
> -}
> -
> -static bool mdev_device_exist(struct mdev_parent *parent, uuid_le uuid)
> -{
> - struct device *dev;
> -
> - dev = device_find_child(parent->dev, , _find_mdev_device);
> - if (dev) {
> - put_device(dev);
> - return true;
> - }
> -
> - return false;
> -}
> -
>  /* Should be called holding parent_list_lock */
>  static struct mdev_parent *__find_parent_device(struct device *dev)
>  {
> @@ -221,7 +193,6 @@ int mdev_register_device(struct device *dev, const struct 
> mdev_parent_ops *ops)
>   }
>  
>   kref_init(>ref);
> - mutex_init(>lock);
>  
>   parent->dev = dev;
>   parent->ops = ops;
> @@ -304,7 +275,7 @@ static void mdev_device_release(struct device *dev)
>  int mdev_device_create(struct kobject *kobj, struct device *dev, uuid_le 
> uuid)
>  {
>   int ret;
> - struct mdev_device *mdev;
> + struct mdev_device *mdev, *tmp;
>   struct mdev_parent *parent;
>   struct mdev_type *type = to_mdev_type(kobj);
>  
> @@ -312,12 +283,14 @@ int mdev_device_create(struct kobject *kobj, struct 
> device *dev, uuid_le uuid)
>   if (!parent)
>   return -EINVAL;
>  
> - mutex_lock(>lock);
> + mutex_lock(_list_lock);
>  
>   /* Check for duplicate */
> - if (mdev_device_exist(parent, uuid)) {
> - ret = -EEXIST;
> - goto create_err;
> + list_for_each_entry(tmp, _list, next) {
> + if (!uuid_le_cmp(tmp->uuid, uuid)) {
> + ret = -EEXIST;
> + goto create_err;
> + }
>   }
>
Is it possible to use mdev_list_lock for as minimal portion as possible?
By adding mdev device to mdev_list just after:
memcpy(>uuid, , sizeof(uuid_le));
and then unlock mdev_list_lock, but at the same time all later error
cases need to be handled properly in this function.

Thanks,
Kirti


>   mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
> @@ -354,9 +327,6 @@ int mdev_device_create(struct kobject *kobj, struct 
> device *dev, uuid_le uuid)
>   mdev->type_kobj = kobj;
>   dev_dbg(>dev, "MDEV: created\n");
>  
> - mutex_unlock(>lock);
> -
> - mutex_lock(_list_lock);
>   list_add(>next, _list);
>   mutex_unlock(_list_lock);
>  

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

[Hal Rosenstock]

On 5/16/2018 3:22 PM, Håkon Bugge wrote:
> But, do we need an update to IBTA (that the BTH.PKey shall be that of the 
> VM's Port)?

Nothing in spec mentions shared (port) virtualization so that is an
exercise completely left to the reader...

Annex A19 is silent on this specific point but the virtual port model
has virtual port partition table so there's no ambiguity there.

Re: [PATCH IB/core 2/2] IB/cm: Send authentic pkey in REQ msg and check eligibility of the pkeys

[Hal Rosenstock]

On 5/16/2018 3:22 PM, Håkon Bugge wrote:
> But, do we need an update to IBTA (that the BTH.PKey shall be that of the 
> VM's Port)?

Nothing in spec mentions shared (port) virtualization so that is an
exercise completely left to the reader...

Annex A19 is silent on this specific point but the virtual port model
has virtual port partition table so there's no ambiguity there.

[PATCH] tracing: make function ‘ftrace_exports’ static

[Mathieu Malaterre]

In commit 478409dd683d ("tracing: Add hook to function tracing for other
subsystems to use"), a new function ‘ftrace_exports’ was added. Since
this function can be made static, make it so.

Silence the following warning triggered using W=1:

  kernel/trace/trace.c:2451:6: warning: no previous prototype for 
‘ftrace_exports’ [-Wmissing-prototypes]

Signed-off-by: Mathieu Malaterre 
---
 kernel/trace/trace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 414d7210b2ec..76b96f453cf7 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2448,7 +2448,7 @@ static inline void ftrace_exports_disable(void)
static_branch_disable(_exports_enabled);
 }
 
-void ftrace_exports(struct ring_buffer_event *event)
+static void ftrace_exports(struct ring_buffer_event *event)
 {
struct trace_export *export;
 
-- 
2.11.0

[PATCH] tracing: make function ‘ftrace_exports’ static

[Mathieu Malaterre]

In commit 478409dd683d ("tracing: Add hook to function tracing for other
subsystems to use"), a new function ‘ftrace_exports’ was added. Since
this function can be made static, make it so.

Silence the following warning triggered using W=1:

  kernel/trace/trace.c:2451:6: warning: no previous prototype for 
‘ftrace_exports’ [-Wmissing-prototypes]

Signed-off-by: Mathieu Malaterre 
---
 kernel/trace/trace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 414d7210b2ec..76b96f453cf7 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2448,7 +2448,7 @@ static inline void ftrace_exports_disable(void)
static_branch_disable(_exports_enabled);
 }
 
-void ftrace_exports(struct ring_buffer_event *event)
+static void ftrace_exports(struct ring_buffer_event *event)
 {
struct trace_export *export;
 
-- 
2.11.0

Re: [RFC/RFT] [PATCH 05/10] cpufreq: intel_pstate: HWP boost performance on IO Wake

[Srinivas Pandruvada]

On Wed, 2018-05-16 at 11:45 +0200, Rafael J. Wysocki wrote:

[...]
> 
> > +   if (time_before64(time, cpu->last_io_update + 2 *
> > TICK_NSEC) &&
> > +   intel_pstate_check_boost_threhold(cpu))
> > +   cpu->iowait_boost = true;
> > +
> > +   cpu->last_io_update = time;
> > +   cpu->last_update = time;
> 
> This is a shared data structure and it gets updated without
> synchronization, unless I'm missing something.
Good point.

> 
> How much does the cross-CPU case matter?
I was under impression that IOWAIT flag is set on local CPU calls only,
but I see IOWAIT flags set for remote CPU all the time. So we will miss
if we don't take care of cross CPU calls.

But I can lump them as part of smp async call for all cross cpu updates
to avoid sync issue.

> 
> > +   }
> > 
> > +   /*
> > +* If the boost is active, we will remove it after timeout
> > on local
> > +* CPU only.
> > +*/
> > +   if (cpu->hwp_boost_active) {
> > +   if (smp_processor_id() == cpu->cpu) {
> > +   bool expired;
> > +
> > +   expired = time_after64(time, cpu-
> > >last_update +
> > +  (hwp_boost_hold_time
> > _ms * NSEC_PER_MSEC));
> > +   if (expired) {
> > +   intel_pstate_hwp_boost_down(cpu);
> > +   cpu->hwp_boost_active = false;
> > +   cpu->iowait_boost = false;
> > +   }
> > +   }
> > +   return;
> > +   }
> > +
> > +   cpu->last_update = time;
> > +
> > +   if (cpu->iowait_boost) {
> > +   cpu->hwp_boost_active = true;
> > +   if (smp_processor_id() == cpu->cpu)
> > +   intel_pstate_hwp_boost_up(cpu);
> > +   else
> > +   smp_call_function_single_async(cpu->cpu,
> > >csd);
> > +   }
> >  }
> > 
> >  static inline void intel_pstate_calc_avg_perf(struct cpudata *cpu)
> > --
> > 2.9.5
> > 

Re: [RFC/RFT] [PATCH 05/10] cpufreq: intel_pstate: HWP boost performance on IO Wake

[Srinivas Pandruvada]

On Wed, 2018-05-16 at 11:45 +0200, Rafael J. Wysocki wrote:

[...]
> 
> > +   if (time_before64(time, cpu->last_io_update + 2 *
> > TICK_NSEC) &&
> > +   intel_pstate_check_boost_threhold(cpu))
> > +   cpu->iowait_boost = true;
> > +
> > +   cpu->last_io_update = time;
> > +   cpu->last_update = time;
> 
> This is a shared data structure and it gets updated without
> synchronization, unless I'm missing something.
Good point.

> 
> How much does the cross-CPU case matter?
I was under impression that IOWAIT flag is set on local CPU calls only,
but I see IOWAIT flags set for remote CPU all the time. So we will miss
if we don't take care of cross CPU calls.

But I can lump them as part of smp async call for all cross cpu updates
to avoid sync issue.

> 
> > +   }
> > 
> > +   /*
> > +* If the boost is active, we will remove it after timeout
> > on local
> > +* CPU only.
> > +*/
> > +   if (cpu->hwp_boost_active) {
> > +   if (smp_processor_id() == cpu->cpu) {
> > +   bool expired;
> > +
> > +   expired = time_after64(time, cpu-
> > >last_update +
> > +  (hwp_boost_hold_time
> > _ms * NSEC_PER_MSEC));
> > +   if (expired) {
> > +   intel_pstate_hwp_boost_down(cpu);
> > +   cpu->hwp_boost_active = false;
> > +   cpu->iowait_boost = false;
> > +   }
> > +   }
> > +   return;
> > +   }
> > +
> > +   cpu->last_update = time;
> > +
> > +   if (cpu->iowait_boost) {
> > +   cpu->hwp_boost_active = true;
> > +   if (smp_processor_id() == cpu->cpu)
> > +   intel_pstate_hwp_boost_up(cpu);
> > +   else
> > +   smp_call_function_single_async(cpu->cpu,
> > >csd);
> > +   }
> >  }
> > 
> >  static inline void intel_pstate_calc_avg_perf(struct cpudata *cpu)
> > --
> > 2.9.5
> > 

Re: [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order

[Florian Fainelli]

On 05/15/2018 09:32 PM, Viresh Kumar wrote:
> On 15-05-18, 20:49, Markus Mayer wrote:
>> From: Markus Mayer 
>>
>> Most CPUfreq drivers (at least on ARM) seem to be sorting the available
>> frequencies from lowest to highest. To match this behaviour, we reverse
>> the sorting order in brcmstb-avs-cpufreq, so it is now also lowest to
>> highest.
> 
> The reasoning isn't correct. Just because everyone else is doing it
> doesn't make it right and so you shouldn't change just because of
> that.
> 
> What you must written instead in the commit log is that the cpufreq
> core performs better if the table is sorted (in any order), and so we
> must sort it as well.

Is there a reason why set_freq_table_sorted() tries an ascending or
descending sort, but does not enforce one versus another for all drivers?

> 
> But I feel the table is already sorted for your platform, isn't it?
> And I don't see a clear advantage of merging this patch.

The patch changes the order to have the lowest to highest, whereas the
current implementation has them from highest to lowest. From what you
are saying, it sounds like this is unnecessary, since the sorting is
already making things efficient enough, so this is just a cosmetic thing?

> 
>> Signed-off-by: Markus Mayer 
>> ---
>>  drivers/cpufreq/brcmstb-avs-cpufreq.c | 9 +
>>  1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
>> b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> index b07559b9ed99..7dac3205d3eb 100644
>> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> @@ -403,7 +403,7 @@ brcm_avs_get_freq_table(struct device *dev, struct 
>> private_data *priv)
>>  {
>>  struct cpufreq_frequency_table *table;
>>  unsigned int pstate;
>> -int i, ret;
>> +int p, i, ret;
>>  
>>  /* Remember P-state for later */
>>  ret = brcm_avs_get_pstate(priv, );
>> @@ -415,12 +415,13 @@ brcm_avs_get_freq_table(struct device *dev, struct 
>> private_data *priv)
>>  if (!table)
>>  return ERR_PTR(-ENOMEM);
>>  
>> -for (i = AVS_PSTATE_P0; i <= AVS_PSTATE_MAX; i++) {
>> -ret = brcm_avs_set_pstate(priv, i);
>> +for (p = AVS_PSTATE_MAX, i = 0; p >= 0; p--, i++) {
>> +ret = brcm_avs_set_pstate(priv, p);
>>  if (ret)
>>  return ERR_PTR(ret);
>>  table[i].frequency = brcm_avs_get_frequency(priv->base);
>> -table[i].driver_data = i;
>> +/* Store the corresponding P-state with each frequency */
>> +table[i].driver_data = p;
>>  }
>>  table[i].frequency = CPUFREQ_TABLE_END;
>>  
>> -- 
>> 2.7.4
> 


-- 
Florian

Re: [PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order

[Florian Fainelli]

On 05/15/2018 09:32 PM, Viresh Kumar wrote:
> On 15-05-18, 20:49, Markus Mayer wrote:
>> From: Markus Mayer 
>>
>> Most CPUfreq drivers (at least on ARM) seem to be sorting the available
>> frequencies from lowest to highest. To match this behaviour, we reverse
>> the sorting order in brcmstb-avs-cpufreq, so it is now also lowest to
>> highest.
> 
> The reasoning isn't correct. Just because everyone else is doing it
> doesn't make it right and so you shouldn't change just because of
> that.
> 
> What you must written instead in the commit log is that the cpufreq
> core performs better if the table is sorted (in any order), and so we
> must sort it as well.

Is there a reason why set_freq_table_sorted() tries an ascending or
descending sort, but does not enforce one versus another for all drivers?

> 
> But I feel the table is already sorted for your platform, isn't it?
> And I don't see a clear advantage of merging this patch.

The patch changes the order to have the lowest to highest, whereas the
current implementation has them from highest to lowest. From what you
are saying, it sounds like this is unnecessary, since the sorting is
already making things efficient enough, so this is just a cosmetic thing?

> 
>> Signed-off-by: Markus Mayer 
>> ---
>>  drivers/cpufreq/brcmstb-avs-cpufreq.c | 9 +
>>  1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
>> b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> index b07559b9ed99..7dac3205d3eb 100644
>> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> @@ -403,7 +403,7 @@ brcm_avs_get_freq_table(struct device *dev, struct 
>> private_data *priv)
>>  {
>>  struct cpufreq_frequency_table *table;
>>  unsigned int pstate;
>> -int i, ret;
>> +int p, i, ret;
>>  
>>  /* Remember P-state for later */
>>  ret = brcm_avs_get_pstate(priv, );
>> @@ -415,12 +415,13 @@ brcm_avs_get_freq_table(struct device *dev, struct 
>> private_data *priv)
>>  if (!table)
>>  return ERR_PTR(-ENOMEM);
>>  
>> -for (i = AVS_PSTATE_P0; i <= AVS_PSTATE_MAX; i++) {
>> -ret = brcm_avs_set_pstate(priv, i);
>> +for (p = AVS_PSTATE_MAX, i = 0; p >= 0; p--, i++) {
>> +ret = brcm_avs_set_pstate(priv, p);
>>  if (ret)
>>  return ERR_PTR(ret);
>>  table[i].frequency = brcm_avs_get_frequency(priv->base);
>> -table[i].driver_data = i;
>> +/* Store the corresponding P-state with each frequency */
>> +table[i].driver_data = p;
>>  }
>>  table[i].frequency = CPUFREQ_TABLE_END;
>>  
>> -- 
>> 2.7.4
> 


-- 
Florian

[PATCH] mmc: block: propagate correct returned value in mmc_rpmb_ioctl

[Mathieu Malaterre]

In commit 97548575bef3 ("mmc: block: Convert RPMB to a character device") a
new function `mmc_rpmb_ioctl` was added. The final return is simply
returning a value of `0` instead of propagating the correct return code.

Discovered during a compilation with W=1, silence the following gcc warning

  drivers/mmc/core/block.c:2470:6: warning: variable ‘ret’ set but not used 
[-Wunused-but-set-variable]

Signed-off-by: Mathieu Malaterre 
---
 drivers/mmc/core/block.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 9e923cd1d80e..38a7586b00cc 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -2485,7 +2485,7 @@ static long mmc_rpmb_ioctl(struct file *filp, unsigned 
int cmd,
break;
}
 
-   return 0;
+   return ret;
 }
 
 #ifdef CONFIG_COMPAT
-- 
2.11.0

[PATCH] mmc: block: propagate correct returned value in mmc_rpmb_ioctl

[Mathieu Malaterre]

In commit 97548575bef3 ("mmc: block: Convert RPMB to a character device") a
new function `mmc_rpmb_ioctl` was added. The final return is simply
returning a value of `0` instead of propagating the correct return code.

Discovered during a compilation with W=1, silence the following gcc warning

  drivers/mmc/core/block.c:2470:6: warning: variable ‘ret’ set but not used 
[-Wunused-but-set-variable]

Signed-off-by: Mathieu Malaterre 
---
 drivers/mmc/core/block.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 9e923cd1d80e..38a7586b00cc 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -2485,7 +2485,7 @@ static long mmc_rpmb_ioctl(struct file *filp, unsigned 
int cmd,
break;
}
 
-   return 0;
+   return ret;
 }
 
 #ifdef CONFIG_COMPAT
-- 
2.11.0

RE: [PATCH 1/2] ACPICA: Introduce acpi_dispatch_gpe()

[Moore, Robert]

I'm not sure why this is necessary, please explain.

Is the implication here that some driver is going to poll on acpi_dispatch_gpe?

Bob


> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Wednesday, May 16, 2018 5:12 AM
> To: Linux ACPI 
> Cc: Zhang, Rui ; Linux PM  p...@vger.kernel.org>; LKML ; Schmauss, Erik
> ; Moore, Robert ; Wang,
> Wendy 
> Subject: [PATCH 1/2] ACPICA: Introduce acpi_dispatch_gpe()
> 
> From: Rafael J. Wysocki 
> 
> Introduce acpi_dispatch_gpe() as a wrapper around acpi_ev_detect_gpe()
> for checking if the given GPE (as represented by a GPE device handle and
> a GPE number) is currently active and dispatching it (if that's the
> case) outside of interrupt context.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/acpi/acpica/evgpe.c   |6 ++
>  drivers/acpi/acpica/evxfgpe.c |   22 ++
>  include/acpi/acpixf.h |1 +
>  3 files changed, 29 insertions(+)
> 
> Index: linux-pm/drivers/acpi/acpica/evgpe.c
> ===
> --- linux-pm.orig/drivers/acpi/acpica/evgpe.c
> +++ linux-pm/drivers/acpi/acpica/evgpe.c
> @@ -634,6 +634,12 @@ acpi_ev_detect_gpe(struct acpi_namespace
> 
>   flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
> 
> + if (!gpe_event_info) {
> + gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device,
> gpe_number);
> + if (!gpe_event_info)
> + goto error_exit;
> + }
> +
>   /* Get the info block for the entire GPE register */
> 
>   gpe_register_info = gpe_event_info->register_info;
> Index: linux-pm/drivers/acpi/acpica/evxfgpe.c
> ===
> --- linux-pm.orig/drivers/acpi/acpica/evxfgpe.c
> +++ linux-pm/drivers/acpi/acpica/evxfgpe.c
> @@ -639,6 +639,28 @@ ACPI_EXPORT_SYMBOL(acpi_get_gpe_status)
> 
> 
> /***
> 
>   *
> + * FUNCTION:acpi_gispatch_gpe
> + *
> + * PARAMETERS:  gpe_device  - Parent GPE Device. NULL for
> GPE0/GPE1
> + *  gpe_number  - GPE level within the GPE block
> + *
> + * RETURN:  None
> + *
> + * DESCRIPTION: Detect and dispatch a General Purpose Event to either a
> function
> + *  (e.g. EC) or method (e.g. _Lxx/_Exx) handler.
> + *
> +
> +***
> +***/ void acpi_dispatch_gpe(acpi_handle gpe_device, u32 gpe_number)
> +{
> + ACPI_FUNCTION_TRACE(acpi_dispatch_gpe);
> +
> + acpi_ev_detect_gpe(gpe_device, NULL, gpe_number); }
> +
> +ACPI_EXPORT_SYMBOL(acpi_dispatch_gpe)
> +
> +/**
> +*
> + *
>   * FUNCTION:acpi_finish_gpe
>   *
>   * PARAMETERS:  gpe_device  - Namespace node for the GPE Block
> Index: linux-pm/include/acpi/acpixf.h
> ===
> --- linux-pm.orig/include/acpi/acpixf.h
> +++ linux-pm/include/acpi/acpixf.h
> @@ -753,6 +753,7 @@ ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_sta
>u32 gpe_number,
>acpi_event_status
>*event_status))
> +void acpi_dispatch_gpe(acpi_handle gpe_device, u32 gpe_number);
>  ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_disable_all_gpes(void))
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_enable_all_runtime_gpes(void))
>  ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_enable_all_wakeup_gpes(void))

RE: [PATCH 1/2] ACPICA: Introduce acpi_dispatch_gpe()

[Moore, Robert]

I'm not sure why this is necessary, please explain.

Is the implication here that some driver is going to poll on acpi_dispatch_gpe?

Bob


> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Wednesday, May 16, 2018 5:12 AM
> To: Linux ACPI 
> Cc: Zhang, Rui ; Linux PM  p...@vger.kernel.org>; LKML ; Schmauss, Erik
> ; Moore, Robert ; Wang,
> Wendy 
> Subject: [PATCH 1/2] ACPICA: Introduce acpi_dispatch_gpe()
> 
> From: Rafael J. Wysocki 
> 
> Introduce acpi_dispatch_gpe() as a wrapper around acpi_ev_detect_gpe()
> for checking if the given GPE (as represented by a GPE device handle and
> a GPE number) is currently active and dispatching it (if that's the
> case) outside of interrupt context.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/acpi/acpica/evgpe.c   |6 ++
>  drivers/acpi/acpica/evxfgpe.c |   22 ++
>  include/acpi/acpixf.h |1 +
>  3 files changed, 29 insertions(+)
> 
> Index: linux-pm/drivers/acpi/acpica/evgpe.c
> ===
> --- linux-pm.orig/drivers/acpi/acpica/evgpe.c
> +++ linux-pm/drivers/acpi/acpica/evgpe.c
> @@ -634,6 +634,12 @@ acpi_ev_detect_gpe(struct acpi_namespace
> 
>   flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
> 
> + if (!gpe_event_info) {
> + gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device,
> gpe_number);
> + if (!gpe_event_info)
> + goto error_exit;
> + }
> +
>   /* Get the info block for the entire GPE register */
> 
>   gpe_register_info = gpe_event_info->register_info;
> Index: linux-pm/drivers/acpi/acpica/evxfgpe.c
> ===
> --- linux-pm.orig/drivers/acpi/acpica/evxfgpe.c
> +++ linux-pm/drivers/acpi/acpica/evxfgpe.c
> @@ -639,6 +639,28 @@ ACPI_EXPORT_SYMBOL(acpi_get_gpe_status)
> 
> 
> /***
> 
>   *
> + * FUNCTION:acpi_gispatch_gpe
> + *
> + * PARAMETERS:  gpe_device  - Parent GPE Device. NULL for
> GPE0/GPE1
> + *  gpe_number  - GPE level within the GPE block
> + *
> + * RETURN:  None
> + *
> + * DESCRIPTION: Detect and dispatch a General Purpose Event to either a
> function
> + *  (e.g. EC) or method (e.g. _Lxx/_Exx) handler.
> + *
> +
> +***
> +***/ void acpi_dispatch_gpe(acpi_handle gpe_device, u32 gpe_number)
> +{
> + ACPI_FUNCTION_TRACE(acpi_dispatch_gpe);
> +
> + acpi_ev_detect_gpe(gpe_device, NULL, gpe_number); }
> +
> +ACPI_EXPORT_SYMBOL(acpi_dispatch_gpe)
> +
> +/**
> +*
> + *
>   * FUNCTION:acpi_finish_gpe
>   *
>   * PARAMETERS:  gpe_device  - Namespace node for the GPE Block
> Index: linux-pm/include/acpi/acpixf.h
> ===
> --- linux-pm.orig/include/acpi/acpixf.h
> +++ linux-pm/include/acpi/acpixf.h
> @@ -753,6 +753,7 @@ ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_sta
>u32 gpe_number,
>acpi_event_status
>*event_status))
> +void acpi_dispatch_gpe(acpi_handle gpe_device, u32 gpe_number);
>  ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_disable_all_gpes(void))
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_enable_all_runtime_gpes(void))
>  ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_enable_all_wakeup_gpes(void))

Re: [PATCH v2] coresight: documentation: update sysfs section

[Jonathan Corbet]

On Mon, 14 May 2018 12:19:59 -0500
Kim Phillips  wrote:

> - Align and show updated ls devices output from the TC2, based on
>   current driver
> 
> - Provide an example from an ETMv4 based system (Juno)
> 
> - Reflect changes to the way the RAM write pointer is accessed since
>   it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS
>   management entries").

So I was going to apply this, but it's been pretty badly corrupted by
your mailer.  Could I ask you to retry, please?

Thanks,

jon

Re: [PATCH v2] coresight: documentation: update sysfs section

[Jonathan Corbet]

On Mon, 14 May 2018 12:19:59 -0500
Kim Phillips  wrote:

> - Align and show updated ls devices output from the TC2, based on
>   current driver
> 
> - Provide an example from an ETMv4 based system (Juno)
> 
> - Reflect changes to the way the RAM write pointer is accessed since
>   it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS
>   management entries").

So I was going to apply this, but it's been pretty badly corrupted by
your mailer.  Could I ask you to retry, please?

Thanks,

jon

Re: [PATCH net-next v2 0/3] net: Allow more drivers with COMPILE_TEST

[Florian Fainelli]

On 05/16/2018 12:07 PM, David Miller wrote:
> From: David Miller 
> Date: Wed, 16 May 2018 15:06:59 -0400 (EDT)
> 
>> So applied, thanks.
> 
> Nevermind, eventually got a build failure:
> 
> ERROR: "knav_queue_open" [drivers/net/ethernet/ti/keystone_netcp.ko] 
> undefined!
> make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1
> make: *** [Makefile:1276: modules] Error 2

Snap, ok, let me  do some more serious build testing with different
architectures here.

Sorry about that.
-- 
Florian

Re: [PATCH net-next v2 0/3] net: Allow more drivers with COMPILE_TEST

[Florian Fainelli]

On 05/16/2018 12:07 PM, David Miller wrote:
> From: David Miller 
> Date: Wed, 16 May 2018 15:06:59 -0400 (EDT)
> 
>> So applied, thanks.
> 
> Nevermind, eventually got a build failure:
> 
> ERROR: "knav_queue_open" [drivers/net/ethernet/ti/keystone_netcp.ko] 
> undefined!
> make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1
> make: *** [Makefile:1276: modules] Error 2

Snap, ok, let me  do some more serious build testing with different
architectures here.

Sorry about that.
-- 
Florian

Re: [PATCH] Documentation: arm: clean up Marvell Berlin family info

[Jonathan Corbet]

On Mon, 14 May 2018 17:55:10 -0400
Thomas Hebb  wrote:

> Remove dead links, make spacing consistent, and note that the family was
> acquired by Synaptics in 2017.
> 
> Signed-off-by: Thomas Hebb 

Applied to the docs tree, thanks.

jon

Re: [PATCH] Documentation: arm: clean up Marvell Berlin family info

[Jonathan Corbet]

On Mon, 14 May 2018 17:55:10 -0400
Thomas Hebb  wrote:

> Remove dead links, make spacing consistent, and note that the family was
> acquired by Synaptics in 2017.
> 
> Signed-off-by: Thomas Hebb 

Applied to the docs tree, thanks.

jon

[PATCH] rtc: nvmem: don't return an error when not enabled

[Alexandre Belloni]

Avoid reporting an error when RTC_NVMEM is not selected.

Reported-by: kernel test robot 
Signed-off-by: Alexandre Belloni 
---
 include/linux/rtc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 4c007f69082f..6268208760e9 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -285,7 +285,7 @@ void rtc_nvmem_unregister(struct rtc_device *rtc);
 static inline int rtc_nvmem_register(struct rtc_device *rtc,
 struct nvmem_config *nvmem_config)
 {
-   return -ENODEV;
+   return 0;
 }
 static inline void rtc_nvmem_unregister(struct rtc_device *rtc) {}
 #endif
-- 
2.17.0

[PATCH] rtc: nvmem: don't return an error when not enabled

[Alexandre Belloni]

Avoid reporting an error when RTC_NVMEM is not selected.

Reported-by: kernel test robot 
Signed-off-by: Alexandre Belloni 
---
 include/linux/rtc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 4c007f69082f..6268208760e9 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -285,7 +285,7 @@ void rtc_nvmem_unregister(struct rtc_device *rtc);
 static inline int rtc_nvmem_register(struct rtc_device *rtc,
 struct nvmem_config *nvmem_config)
 {
-   return -ENODEV;
+   return 0;
 }
 static inline void rtc_nvmem_unregister(struct rtc_device *rtc) {}
 #endif
-- 
2.17.0

Re: [PATCH] Documentation: gpio: driver: Fix a typo and some odd grammar

[Jonathan Corbet]

On Wed, 16 May 2018 14:08:00 +0200
Jonathan Neuschäfer  wrote:

> Signed-off-by: Jonathan Neuschäfer 

Applied, thanks.

jon

Re: [PATCH] Documentation: gpio: driver: Fix a typo and some odd grammar

[Jonathan Corbet]

On Wed, 16 May 2018 14:08:00 +0200
Jonathan Neuschäfer  wrote:

> Signed-off-by: Jonathan Neuschäfer 

Applied, thanks.

jon

Re: [PATCH net-next v2 0/3] net: Allow more drivers with COMPILE_TEST

[David Miller]

From: David Miller 
Date: Wed, 16 May 2018 15:06:59 -0400 (EDT)

> So applied, thanks.

Nevermind, eventually got a build failure:

ERROR: "knav_queue_open" [drivers/net/ethernet/ti/keystone_netcp.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1
make: *** [Makefile:1276: modules] Error 2

Reverted.

[PATCH v3] {net, IB}/mlx5: Use 'kvfree()' for memory allocated by 'kvzalloc()'

[Christophe JAILLET]

When 'kvzalloc()' is used to allocate memory, 'kvfree()' must be used to
free it.

Fixes: 1cbe6fc86ccfe ("IB/mlx5: Add support for CQE compressing")
Fixes: fed9ce22bf8ae ("net/mlx5: E-Switch, Add API to create vport rx rules")
Fixes: 9efa75254593d ("net/mlx5_core: Introduce access functions to query vport 
RoCE fields")
Signed-off-by: Christophe JAILLET 
---
v1 -> v2: More places to update have been added to the patch
v2 -> v3: Add Fixes tag

3 patches with one Fixes tag each should probably be better, but honestly, I 
won't send a v4.
Fill free to split it if needed.
---
 drivers/infiniband/hw/mlx5/cq.c| 2 +-
 drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 +-
 drivers/net/ethernet/mellanox/mlx5/core/vport.c| 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
index 77d257ec899b..6d52ea03574e 100644
--- a/drivers/infiniband/hw/mlx5/cq.c
+++ b/drivers/infiniband/hw/mlx5/cq.c
@@ -849,7 +849,7 @@ static int create_cq_user(struct mlx5_ib_dev *dev, struct 
ib_udata *udata,
return 0;
 
 err_cqb:
-   kfree(*cqb);
+   kvfree(*cqb);
 
 err_db:
mlx5_ib_db_unmap_user(to_mucontext(context), >db);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c 
b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 35e256eb2f6e..b123f8a52ad8 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -663,7 +663,7 @@ static int esw_create_vport_rx_group(struct mlx5_eswitch 
*esw)
 
esw->offloads.vport_rx_group = g;
 out:
-   kfree(flow_group_in);
+   kvfree(flow_group_in);
return err;
 }
 
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vport.c 
b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
index 177e076b8d17..719cecb182c6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/vport.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
@@ -511,7 +511,7 @@ int mlx5_query_nic_vport_system_image_guid(struct 
mlx5_core_dev *mdev,
*system_image_guid = MLX5_GET64(query_nic_vport_context_out, out,
nic_vport_context.system_image_guid);
 
-   kfree(out);
+   kvfree(out);
 
return 0;
 }
@@ -531,7 +531,7 @@ int mlx5_query_nic_vport_node_guid(struct mlx5_core_dev 
*mdev, u64 *node_guid)
*node_guid = MLX5_GET64(query_nic_vport_context_out, out,
nic_vport_context.node_guid);
 
-   kfree(out);
+   kvfree(out);
 
return 0;
 }
@@ -587,7 +587,7 @@ int mlx5_query_nic_vport_qkey_viol_cntr(struct 
mlx5_core_dev *mdev,
*qkey_viol_cntr = MLX5_GET(query_nic_vport_context_out, out,
   nic_vport_context.qkey_violation_counter);
 
-   kfree(out);
+   kvfree(out);
 
return 0;
 }
-- 
2.17.0

Re: [PATCH net-next v2 0/3] net: Allow more drivers with COMPILE_TEST

[David Miller]

From: David Miller 
Date: Wed, 16 May 2018 15:06:59 -0400 (EDT)

> So applied, thanks.

Nevermind, eventually got a build failure:

ERROR: "knav_queue_open" [drivers/net/ethernet/ti/keystone_netcp.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1
make: *** [Makefile:1276: modules] Error 2

Reverted.

[PATCH v3] {net, IB}/mlx5: Use 'kvfree()' for memory allocated by 'kvzalloc()'

[Christophe JAILLET]

When 'kvzalloc()' is used to allocate memory, 'kvfree()' must be used to
free it.

Fixes: 1cbe6fc86ccfe ("IB/mlx5: Add support for CQE compressing")
Fixes: fed9ce22bf8ae ("net/mlx5: E-Switch, Add API to create vport rx rules")
Fixes: 9efa75254593d ("net/mlx5_core: Introduce access functions to query vport 
RoCE fields")
Signed-off-by: Christophe JAILLET 
---
v1 -> v2: More places to update have been added to the patch
v2 -> v3: Add Fixes tag

3 patches with one Fixes tag each should probably be better, but honestly, I 
won't send a v4.
Fill free to split it if needed.
---
 drivers/infiniband/hw/mlx5/cq.c| 2 +-
 drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 +-
 drivers/net/ethernet/mellanox/mlx5/core/vport.c| 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
index 77d257ec899b..6d52ea03574e 100644
--- a/drivers/infiniband/hw/mlx5/cq.c
+++ b/drivers/infiniband/hw/mlx5/cq.c
@@ -849,7 +849,7 @@ static int create_cq_user(struct mlx5_ib_dev *dev, struct 
ib_udata *udata,
return 0;
 
 err_cqb:
-   kfree(*cqb);
+   kvfree(*cqb);
 
 err_db:
mlx5_ib_db_unmap_user(to_mucontext(context), >db);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c 
b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 35e256eb2f6e..b123f8a52ad8 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -663,7 +663,7 @@ static int esw_create_vport_rx_group(struct mlx5_eswitch 
*esw)
 
esw->offloads.vport_rx_group = g;
 out:
-   kfree(flow_group_in);
+   kvfree(flow_group_in);
return err;
 }
 
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vport.c 
b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
index 177e076b8d17..719cecb182c6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/vport.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
@@ -511,7 +511,7 @@ int mlx5_query_nic_vport_system_image_guid(struct 
mlx5_core_dev *mdev,
*system_image_guid = MLX5_GET64(query_nic_vport_context_out, out,
nic_vport_context.system_image_guid);
 
-   kfree(out);
+   kvfree(out);
 
return 0;
 }
@@ -531,7 +531,7 @@ int mlx5_query_nic_vport_node_guid(struct mlx5_core_dev 
*mdev, u64 *node_guid)
*node_guid = MLX5_GET64(query_nic_vport_context_out, out,
nic_vport_context.node_guid);
 
-   kfree(out);
+   kvfree(out);
 
return 0;
 }
@@ -587,7 +587,7 @@ int mlx5_query_nic_vport_qkey_viol_cntr(struct 
mlx5_core_dev *mdev,
*qkey_viol_cntr = MLX5_GET(query_nic_vport_context_out, out,
   nic_vport_context.qkey_violation_counter);
 
-   kfree(out);
+   kvfree(out);
 
return 0;
 }
-- 
2.17.0

Re: [PATCH net-next v2 0/3] net: Allow more drivers with COMPILE_TEST

[David Miller]

From: Florian Fainelli 
Date: Wed, 16 May 2018 11:52:55 -0700

> This patch series includes more drivers to be build tested with COMPILE_TEST
> enabled. This helps cover some of the issues I just ran into with missing
> a driver *sigh*.
> 
> Changes in v2:
> 
> - allow FEC to build outside of CONFIG_ARM/ARM64 by defining a layout of
>   registers, this is not meant to run, so this is not a real issue if we
>   are not matching the correct register layout

Ok, this is a lot better.

But man, some of these drivers...

drivers/net/ethernet/ti/davinci_cpdma.c: In function ‘cpdma_desc_pool_destroy’:
drivers/net/ethernet/ti/davinci_cpdma.c:194:7: warning: format ‘%d’ expects 
argument of type ‘int’, but argument 2 has type ‘size_t {aka long unsigned 
int}’ [-Wformat=]
   "cpdma_desc_pool size %d != avail %d",
   ^
   gen_pool_size(pool->gen_pool),
   ~

and on and on and on...

But I'm really happy to see FEC and others at least being build tested
in more scenerios.

So applied, thanks.

Re: [PATCH net-next v2 0/3] net: Allow more drivers with COMPILE_TEST

[David Miller]

From: Florian Fainelli 
Date: Wed, 16 May 2018 11:52:55 -0700

> This patch series includes more drivers to be build tested with COMPILE_TEST
> enabled. This helps cover some of the issues I just ran into with missing
> a driver *sigh*.
> 
> Changes in v2:
> 
> - allow FEC to build outside of CONFIG_ARM/ARM64 by defining a layout of
>   registers, this is not meant to run, so this is not a real issue if we
>   are not matching the correct register layout

Ok, this is a lot better.

But man, some of these drivers...

drivers/net/ethernet/ti/davinci_cpdma.c: In function ‘cpdma_desc_pool_destroy’:
drivers/net/ethernet/ti/davinci_cpdma.c:194:7: warning: format ‘%d’ expects 
argument of type ‘int’, but argument 2 has type ‘size_t {aka long unsigned 
int}’ [-Wformat=]
   "cpdma_desc_pool size %d != avail %d",
   ^
   gen_pool_size(pool->gen_pool),
   ~

and on and on and on...

But I'm really happy to see FEC and others at least being build tested
in more scenerios.

So applied, thanks.

[PATCH net-next v2 1/3] net: ethernet: ti: Allow most drivers with COMPILE_TEST

[Florian Fainelli]

Most of the TI drivers build just fine with COMPILE_TEST, cpmac (AR7) is
the exception because it uses a header file from
arch/mips/include/asm/mach-ar7/ar7.h.

Signed-off-by: Florian Fainelli 
---
 drivers/net/ethernet/ti/Kconfig | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index 48a541eb0af2..1f8626999ac6 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -18,7 +18,7 @@ if NET_VENDOR_TI
 
 config TI_DAVINCI_EMAC
tristate "TI DaVinci EMAC Support"
-   depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 )
+   depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 ) || COMPILE_TEST
select TI_DAVINCI_MDIO
select TI_DAVINCI_CPDMA
select PHYLIB
@@ -30,7 +30,7 @@ config TI_DAVINCI_EMAC
 
 config TI_DAVINCI_MDIO
tristate "TI DaVinci MDIO Support"
-   depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE
+   depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE || 
COMPILE_TEST
select PHYLIB
---help---
  This driver supports TI's DaVinci MDIO module.
@@ -40,7 +40,7 @@ config TI_DAVINCI_MDIO
 
 config TI_DAVINCI_CPDMA
tristate "TI DaVinci CPDMA Support"
-   depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
+   depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || COMPILE_TEST
---help---
  This driver supports TI's DaVinci CPDMA dma engine.
 
@@ -60,7 +60,7 @@ config TI_CPSW_ALE
 
 config TI_CPSW
tristate "TI CPSW Switch Support"
-   depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
+   depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || COMPILE_TEST
select TI_DAVINCI_CPDMA
select TI_DAVINCI_MDIO
select TI_CPSW_PHY_SEL
@@ -75,7 +75,7 @@ config TI_CPSW
 
 config TI_CPTS
bool "TI Common Platform Time Sync (CPTS) Support"
-   depends on TI_CPSW || TI_KEYSTONE_NETCP
+   depends on TI_CPSW || TI_KEYSTONE_NETCP || COMPILE_TEST
depends on POSIX_TIMERS
---help---
  This driver supports the Common Platform Time Sync unit of
@@ -95,8 +95,8 @@ config TI_KEYSTONE_NETCP
tristate "TI Keystone NETCP Core Support"
select TI_CPSW_ALE
select TI_DAVINCI_MDIO
-   depends on OF
-   depends on KEYSTONE_NAVIGATOR_DMA && KEYSTONE_NAVIGATOR_QMSS
+   depends on OF && KEYSTONE_NAVIGATOR_DMA && KEYSTONE_NAVIGATOR_QMSS || \
+  COMPILE_TEST
---help---
  This driver supports TI's Keystone NETCP Core.
 
-- 
2.14.1

[PATCH net-next v2 1/3] net: ethernet: ti: Allow most drivers with COMPILE_TEST

[Florian Fainelli]

Most of the TI drivers build just fine with COMPILE_TEST, cpmac (AR7) is
the exception because it uses a header file from
arch/mips/include/asm/mach-ar7/ar7.h.

Signed-off-by: Florian Fainelli 
---
 drivers/net/ethernet/ti/Kconfig | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index 48a541eb0af2..1f8626999ac6 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -18,7 +18,7 @@ if NET_VENDOR_TI
 
 config TI_DAVINCI_EMAC
tristate "TI DaVinci EMAC Support"
-   depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 )
+   depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 ) || COMPILE_TEST
select TI_DAVINCI_MDIO
select TI_DAVINCI_CPDMA
select PHYLIB
@@ -30,7 +30,7 @@ config TI_DAVINCI_EMAC
 
 config TI_DAVINCI_MDIO
tristate "TI DaVinci MDIO Support"
-   depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE
+   depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE || 
COMPILE_TEST
select PHYLIB
---help---
  This driver supports TI's DaVinci MDIO module.
@@ -40,7 +40,7 @@ config TI_DAVINCI_MDIO
 
 config TI_DAVINCI_CPDMA
tristate "TI DaVinci CPDMA Support"
-   depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
+   depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || COMPILE_TEST
---help---
  This driver supports TI's DaVinci CPDMA dma engine.
 
@@ -60,7 +60,7 @@ config TI_CPSW_ALE
 
 config TI_CPSW
tristate "TI CPSW Switch Support"
-   depends on ARCH_DAVINCI || ARCH_OMAP2PLUS
+   depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || COMPILE_TEST
select TI_DAVINCI_CPDMA
select TI_DAVINCI_MDIO
select TI_CPSW_PHY_SEL
@@ -75,7 +75,7 @@ config TI_CPSW
 
 config TI_CPTS
bool "TI Common Platform Time Sync (CPTS) Support"
-   depends on TI_CPSW || TI_KEYSTONE_NETCP
+   depends on TI_CPSW || TI_KEYSTONE_NETCP || COMPILE_TEST
depends on POSIX_TIMERS
---help---
  This driver supports the Common Platform Time Sync unit of
@@ -95,8 +95,8 @@ config TI_KEYSTONE_NETCP
tristate "TI Keystone NETCP Core Support"
select TI_CPSW_ALE
select TI_DAVINCI_MDIO
-   depends on OF
-   depends on KEYSTONE_NAVIGATOR_DMA && KEYSTONE_NAVIGATOR_QMSS
+   depends on OF && KEYSTONE_NAVIGATOR_DMA && KEYSTONE_NAVIGATOR_QMSS || \
+  COMPILE_TEST
---help---
  This driver supports TI's Keystone NETCP Core.
 
-- 
2.14.1

[PATCH net-next v2 0/3] net: Allow more drivers with COMPILE_TEST

[Florian Fainelli]

Hi David,

This patch series includes more drivers to be build tested with COMPILE_TEST
enabled. This helps cover some of the issues I just ran into with missing
a driver *sigh*.

Changes in v2:

- allow FEC to build outside of CONFIG_ARM/ARM64 by defining a layout of
  registers, this is not meant to run, so this is not a real issue if we
  are not matching the correct register layout

Florian Fainelli (3):
  net: ethernet: ti: Allow most drivers with COMPILE_TEST
  net: ethernet: freescale: Allow FEC with COMPILE_TEST
  net: phy: Allow MDIO_MOXART and MDIO_SUN4I with COMPILE_TEST

 drivers/net/ethernet/freescale/Kconfig|  2 +-
 drivers/net/ethernet/freescale/fec.h  |  2 +-
 drivers/net/ethernet/freescale/fec_main.c |  2 +-
 drivers/net/ethernet/ti/Kconfig   | 14 +++---
 drivers/net/phy/Kconfig   |  4 ++--
 5 files changed, 12 insertions(+), 12 deletions(-)

-- 
2.14.1

[PATCH net-next v2 0/3] net: Allow more drivers with COMPILE_TEST

[Florian Fainelli]

Hi David,

This patch series includes more drivers to be build tested with COMPILE_TEST
enabled. This helps cover some of the issues I just ran into with missing
a driver *sigh*.

Changes in v2:

- allow FEC to build outside of CONFIG_ARM/ARM64 by defining a layout of
  registers, this is not meant to run, so this is not a real issue if we
  are not matching the correct register layout

Florian Fainelli (3):
  net: ethernet: ti: Allow most drivers with COMPILE_TEST
  net: ethernet: freescale: Allow FEC with COMPILE_TEST
  net: phy: Allow MDIO_MOXART and MDIO_SUN4I with COMPILE_TEST

 drivers/net/ethernet/freescale/Kconfig|  2 +-
 drivers/net/ethernet/freescale/fec.h  |  2 +-
 drivers/net/ethernet/freescale/fec_main.c |  2 +-
 drivers/net/ethernet/ti/Kconfig   | 14 +++---
 drivers/net/phy/Kconfig   |  4 ++--
 5 files changed, 12 insertions(+), 12 deletions(-)

-- 
2.14.1

[PATCH net-next v2 3/3] net: phy: Allow MDIO_MOXART and MDIO_SUN4I with COMPILE_TEST

[Florian Fainelli]

Those drivers build just fine with COMPILE_TEST, so make that possible.

Signed-off-by: Florian Fainelli 
---
 drivers/net/phy/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 0e2305ccc91f..343989f9f9d9 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -118,7 +118,7 @@ config MDIO_I2C
 
 config MDIO_MOXART
tristate "MOXA ART MDIO interface support"
-   depends on ARCH_MOXART
+   depends on ARCH_MOXART || COMPILE_TEST
help
  This driver supports the MDIO interface found in the network
  interface units of the MOXA ART SoC
@@ -142,7 +142,7 @@ config MDIO_OCTEON
 
 config MDIO_SUN4I
tristate "Allwinner sun4i MDIO interface support"
-   depends on ARCH_SUNXI
+   depends on ARCH_SUNXI || COMPILE_TEST
help
  This driver supports the MDIO interface found in the network
  interface units of the Allwinner SoC that have an EMAC (A10,
-- 
2.14.1

[PATCH net-next v2 3/3] net: phy: Allow MDIO_MOXART and MDIO_SUN4I with COMPILE_TEST

[Florian Fainelli]

Those drivers build just fine with COMPILE_TEST, so make that possible.

Signed-off-by: Florian Fainelli 
---
 drivers/net/phy/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 0e2305ccc91f..343989f9f9d9 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -118,7 +118,7 @@ config MDIO_I2C
 
 config MDIO_MOXART
tristate "MOXA ART MDIO interface support"
-   depends on ARCH_MOXART
+   depends on ARCH_MOXART || COMPILE_TEST
help
  This driver supports the MDIO interface found in the network
  interface units of the MOXA ART SoC
@@ -142,7 +142,7 @@ config MDIO_OCTEON
 
 config MDIO_SUN4I
tristate "Allwinner sun4i MDIO interface support"
-   depends on ARCH_SUNXI
+   depends on ARCH_SUNXI || COMPILE_TEST
help
  This driver supports the MDIO interface found in the network
  interface units of the Allwinner SoC that have an EMAC (A10,
-- 
2.14.1

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

[Neil Armstrong]

Hi Ville,

On 16/05/2018 16:07, Ville Syrjälä wrote:
> On Wed, May 16, 2018 at 09:40:17AM +0200, Neil Armstrong wrote:
>> On 16/05/2018 09:31, Neil Armstrong wrote:
>>> Hi Ville,
>>>
>>> On 15/05/2018 17:35, Ville Syrjälä wrote:
 On Tue, May 15, 2018 at 04:42:19PM +0200, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to 
> differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> to an eventual CEC adapter.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/i915/Kconfig  |  1 +
>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 12 
>  3 files changed, 15 insertions(+)
>
>>>
>>> [..]
>>>
>  }
>  
> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct 
> intel_encoder *encoder,
>  
>  static void intel_hdmi_destroy(struct drm_connector *connector)
>  {
> + if (intel_attached_hdmi(connector)->notifier)
> + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
>   kfree(to_intel_connector(connector)->detect_edid);
>   drm_connector_cleanup(connector);
>   kfree(connector);
> @@ -2358,6 +2366,10 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>   u32 temp = I915_READ(PEG_BAND_GAP_DATA);
>   I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
>   }
> +
> + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);

 What are we doing with the connector name here? Those are not actually
 guaranteed to be stable, and any change in the connector probe order
 may cause the name to change.
>>>
>>> The i915 driver can expose multiple HDMI connectors, but each connected will
>>> have a different EDID and CEC physical address, so we will need a different 
>>> notifier
>>> for each connector.
>>>
>>> The connector name is DRM dependent, but user-space actually uses this name 
>>> for
>>> operations, so I supposed it was kind of stable.
>>>
>>> Anyway, is there another stable id/name/whatever that can be used to make a 
>>> name to
>>> distinguish the HDMI connectors ?
>>
>> Would "HDMI %c", port_name(port) be OK to use ?
> 
> Yeah, something like seems like a reasonable approach. That does mean
> we have to be a little careful with changing enum port or port_name()
> in the future, but I guess we could just add a small function to
> generated the name/id specifically for this thing.
> 
> We're also going to have to think what to do with enum port and
> port_name() on ICL+ though. There we won't just have A-F but also
> TC1-TC. Hmm. Looks like what we have for those ports in our
> codebase ATM is a bit wonky since we haven't even changed
> port_name() to give us the TC type names.
> 
> Also we might not want "HDMI" in the identifier since the physical
> port is not HDMI specific. There are different things we could call
> these but I think we could just go with a generic "Port A-F" and
> "Port TC1-TC" approach. I think something like that should work
> fine for current and upcoming hardware. And in theory that could
> then be used for other things as well which need a stable
> identifier.
> 
> Oh, and now I recall that input subsystem at least has some kind
> of "physical path" property on devices. So I guess what we're
> dicussing is a somewhat similar idea. I think input drivers
> generally include the pci/usb/etc. device in the path as well.
> Even though we currently only ever have the one pci device it
> would seem like decent idea to include that information in our
> identifiers as well. Or what do you think?
> 

Thanks for the clarifications !

Having a "Port " will be great indeed, no need to specify HDMI since
only HDMI connectors will get a CEC notifier anyway.

The issue is that port_name() returns a character, which is lame.
Would it be acceptable to introduce a :

const char *port_identifier(struct drm_i915_private *dev_priv,
enum port port)
{
char *id = devm_kzalloc(dev_priv->drm->dev, 16, GFP_KERNEL);

if (id)
return NULL;

snprintf("Port %c", port_name(port));

return id;
}

and use the result of this for the cec_notifier connector name ?

Neil

[PATCH net-next v2 2/3] net: ethernet: freescale: Allow FEC with COMPILE_TEST

[Florian Fainelli]

The Freescale FEC driver builds fine with COMPILE_TEST, so make that
possible.

Signed-off-by: Florian Fainelli 
---
 drivers/net/ethernet/freescale/Kconfig| 2 +-
 drivers/net/ethernet/freescale/fec.h  | 2 +-
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/freescale/Kconfig 
b/drivers/net/ethernet/freescale/Kconfig
index 6e490fd2345d..a580a3dcbe59 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -22,7 +22,7 @@ if NET_VENDOR_FREESCALE
 config FEC
tristate "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
depends on (M523x || M527x || M5272 || M528x || M520x || M532x || \
-  ARCH_MXC || SOC_IMX28)
+  ARCH_MXC || SOC_IMX28 || COMPILE_TEST)
default ARCH_MXC || SOC_IMX28 if ARM
select PHYLIB
imply PTP_1588_CLOCK
diff --git a/drivers/net/ethernet/freescale/fec.h 
b/drivers/net/ethernet/freescale/fec.h
index e7381f8ef89d..4778b663653e 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -21,7 +21,7 @@
 
 #if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || 
\
 defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM) || \
-defined(CONFIG_ARM64)
+defined(CONFIG_ARM64) || defined(CONFIG_COMPILE_TEST)
 /*
  * Just figures, Motorola would have to change the offsets for
  * registers in the same peripheral device on different models
diff --git a/drivers/net/ethernet/freescale/fec_main.c 
b/drivers/net/ethernet/freescale/fec_main.c
index d4604bc8eb5b..91e334b5a836 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2111,7 +2111,7 @@ static int fec_enet_get_regs_len(struct net_device *ndev)
 /* List of registers that can be safety be read to dump them with ethtool */
 #if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || 
\
defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM) 
|| \
-   defined(CONFIG_ARM64)
+   defined(CONFIG_ARM64) || defined(CONFIG_COMPILE_TEST)
 static u32 fec_enet_register_offset[] = {
FEC_IEVENT, FEC_IMASK, FEC_R_DES_ACTIVE_0, FEC_X_DES_ACTIVE_0,
FEC_ECNTRL, FEC_MII_DATA, FEC_MII_SPEED, FEC_MIB_CTRLSTAT, FEC_R_CNTRL,
-- 
2.14.1

Re: [PATCH net] tuntap: fix use after free during release

[David Miller]

From: Jason Wang 
Date: Wed, 16 May 2018 20:39:33 +0800

> After commit b196d88aba8a ("tun: fix use after free for ptr_ring") we
> need clean up tx ring during release(). But unfortunately, it tries to
> do the cleanup blindly after socket were destroyed which will lead
> another use-after-free. Fix this by doing the cleanup before dropping
> the last reference of the socket in __tun_detach().
> 
> Reported-by: Andrei Vagin 
> Acked-by: Andrei Vagin 
> Fixes: b196d88aba8a ("tun: fix use after free for ptr_ring")
> Signed-off-by: Jason Wang 

Applied and queued up for -stable.

Re: [PATCH net] tuntap: fix use after free during release

[David Miller]

From: Jason Wang 
Date: Wed, 16 May 2018 20:39:33 +0800

> After commit b196d88aba8a ("tun: fix use after free for ptr_ring") we
> need clean up tx ring during release(). But unfortunately, it tries to
> do the cleanup blindly after socket were destroyed which will lead
> another use-after-free. Fix this by doing the cleanup before dropping
> the last reference of the socket in __tun_detach().
> 
> Reported-by: Andrei Vagin 
> Acked-by: Andrei Vagin 
> Fixes: b196d88aba8a ("tun: fix use after free for ptr_ring")
> Signed-off-by: Jason Wang 

Applied and queued up for -stable.

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

[Neil Armstrong]

Hi Ville,

On 16/05/2018 16:07, Ville Syrjälä wrote:
> On Wed, May 16, 2018 at 09:40:17AM +0200, Neil Armstrong wrote:
>> On 16/05/2018 09:31, Neil Armstrong wrote:
>>> Hi Ville,
>>>
>>> On 15/05/2018 17:35, Ville Syrjälä wrote:
 On Tue, May 15, 2018 at 04:42:19PM +0200, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to 
> differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> to an eventual CEC adapter.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/i915/Kconfig  |  1 +
>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 12 
>  3 files changed, 15 insertions(+)
>
>>>
>>> [..]
>>>
>  }
>  
> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct 
> intel_encoder *encoder,
>  
>  static void intel_hdmi_destroy(struct drm_connector *connector)
>  {
> + if (intel_attached_hdmi(connector)->notifier)
> + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
>   kfree(to_intel_connector(connector)->detect_edid);
>   drm_connector_cleanup(connector);
>   kfree(connector);
> @@ -2358,6 +2366,10 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>   u32 temp = I915_READ(PEG_BAND_GAP_DATA);
>   I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
>   }
> +
> + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);

 What are we doing with the connector name here? Those are not actually
 guaranteed to be stable, and any change in the connector probe order
 may cause the name to change.
>>>
>>> The i915 driver can expose multiple HDMI connectors, but each connected will
>>> have a different EDID and CEC physical address, so we will need a different 
>>> notifier
>>> for each connector.
>>>
>>> The connector name is DRM dependent, but user-space actually uses this name 
>>> for
>>> operations, so I supposed it was kind of stable.
>>>
>>> Anyway, is there another stable id/name/whatever that can be used to make a 
>>> name to
>>> distinguish the HDMI connectors ?
>>
>> Would "HDMI %c", port_name(port) be OK to use ?
> 
> Yeah, something like seems like a reasonable approach. That does mean
> we have to be a little careful with changing enum port or port_name()
> in the future, but I guess we could just add a small function to
> generated the name/id specifically for this thing.
> 
> We're also going to have to think what to do with enum port and
> port_name() on ICL+ though. There we won't just have A-F but also
> TC1-TC. Hmm. Looks like what we have for those ports in our
> codebase ATM is a bit wonky since we haven't even changed
> port_name() to give us the TC type names.
> 
> Also we might not want "HDMI" in the identifier since the physical
> port is not HDMI specific. There are different things we could call
> these but I think we could just go with a generic "Port A-F" and
> "Port TC1-TC" approach. I think something like that should work
> fine for current and upcoming hardware. And in theory that could
> then be used for other things as well which need a stable
> identifier.
> 
> Oh, and now I recall that input subsystem at least has some kind
> of "physical path" property on devices. So I guess what we're
> dicussing is a somewhat similar idea. I think input drivers
> generally include the pci/usb/etc. device in the path as well.
> Even though we currently only ever have the one pci device it
> would seem like decent idea to include that information in our
> identifiers as well. Or what do you think?
> 

Thanks for the clarifications !

Having a "Port " will be great indeed, no need to specify HDMI since
only HDMI connectors will get a CEC notifier anyway.

The issue is that port_name() returns a character, which is lame.
Would it be acceptable to introduce a :

const char *port_identifier(struct drm_i915_private *dev_priv,
enum port port)
{
char *id = devm_kzalloc(dev_priv->drm->dev, 16, GFP_KERNEL);

if (id)
return NULL;

snprintf("Port %c", port_name(port));

return id;
}

and use the result of this for the cec_notifier connector name ?

Neil

[PATCH net-next v2 2/3] net: ethernet: freescale: Allow FEC with COMPILE_TEST

[Florian Fainelli]

The Freescale FEC driver builds fine with COMPILE_TEST, so make that
possible.

Signed-off-by: Florian Fainelli 
---
 drivers/net/ethernet/freescale/Kconfig| 2 +-
 drivers/net/ethernet/freescale/fec.h  | 2 +-
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/freescale/Kconfig 
b/drivers/net/ethernet/freescale/Kconfig
index 6e490fd2345d..a580a3dcbe59 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -22,7 +22,7 @@ if NET_VENDOR_FREESCALE
 config FEC
tristate "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
depends on (M523x || M527x || M5272 || M528x || M520x || M532x || \
-  ARCH_MXC || SOC_IMX28)
+  ARCH_MXC || SOC_IMX28 || COMPILE_TEST)
default ARCH_MXC || SOC_IMX28 if ARM
select PHYLIB
imply PTP_1588_CLOCK
diff --git a/drivers/net/ethernet/freescale/fec.h 
b/drivers/net/ethernet/freescale/fec.h
index e7381f8ef89d..4778b663653e 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -21,7 +21,7 @@
 
 #if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || 
\
 defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM) || \
-defined(CONFIG_ARM64)
+defined(CONFIG_ARM64) || defined(CONFIG_COMPILE_TEST)
 /*
  * Just figures, Motorola would have to change the offsets for
  * registers in the same peripheral device on different models
diff --git a/drivers/net/ethernet/freescale/fec_main.c 
b/drivers/net/ethernet/freescale/fec_main.c
index d4604bc8eb5b..91e334b5a836 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2111,7 +2111,7 @@ static int fec_enet_get_regs_len(struct net_device *ndev)
 /* List of registers that can be safety be read to dump them with ethtool */
 #if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || 
\
defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM) 
|| \
-   defined(CONFIG_ARM64)
+   defined(CONFIG_ARM64) || defined(CONFIG_COMPILE_TEST)
 static u32 fec_enet_register_offset[] = {
FEC_IEVENT, FEC_IMASK, FEC_R_DES_ACTIVE_0, FEC_X_DES_ACTIVE_0,
FEC_ECNTRL, FEC_MII_DATA, FEC_MII_SPEED, FEC_MIB_CTRLSTAT, FEC_R_CNTRL,
-- 
2.14.1

Re: [PATCH net-next] net: ethoc: Remove useless test before clk_disable_unprepare

[David Miller]

From: YueHaibing 
Date: Wed, 16 May 2018 19:18:22 +0800

> clk_disable_unprepare() already checks that the clock pointer is valid.
> No need to test it before calling it.
> 
> Signed-off-by: YueHaibing 

Applied.

Re: [PATCH net-next] net: ethoc: Remove useless test before clk_disable_unprepare

[David Miller]

From: YueHaibing 
Date: Wed, 16 May 2018 19:18:22 +0800

> clk_disable_unprepare() already checks that the clock pointer is valid.
> No need to test it before calling it.
> 
> Signed-off-by: YueHaibing 

Applied.

Re: [PATCH net-next] net: stmmac: Remove useless test before clk_disable_unprepare

[David Miller]

From: YueHaibing 
Date: Wed, 16 May 2018 18:59:19 +0800

> clk_disable_unprepare() already checks that the clock pointer is valid.
> No need to test it before calling it.
> 
> Signed-off-by: YueHaibing 

Applied.

Re: [PATCH net-next] net: stmmac: Remove useless test before clk_disable_unprepare

[David Miller]

From: YueHaibing 
Date: Wed, 16 May 2018 18:59:19 +0800

> clk_disable_unprepare() already checks that the clock pointer is valid.
> No need to test it before calling it.
> 
> Signed-off-by: YueHaibing 

Applied.

Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge

[Sinan Kaya]

On 5/16/2018 2:31 PM, Timur Tabi wrote:
> On 05/16/2018 01:23 PM, Sinan Kaya wrote:
>> +    win_start = window->res->start - window->offset;
> 
> Can you guarantee that window->res->start is always >= window->offset?
> 

Resource offset is generally 0 when not translating or a positive number
that you subtract from the resource start to reach to the translating window.

Having a bigger offset than resource start should be considered a BIOS bug.

>> +    win_size = window->res->end - window->res->start + 1;
> 
> Use resource_size() instead.
> 

I'll fix it.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge

[Sinan Kaya]

On 5/16/2018 2:31 PM, Timur Tabi wrote:
> On 05/16/2018 01:23 PM, Sinan Kaya wrote:
>> +    win_start = window->res->start - window->offset;
> 
> Can you guarantee that window->res->start is always >= window->offset?
> 

Resource offset is generally 0 when not translating or a positive number
that you subtract from the resource start to reach to the translating window.

Having a bigger offset than resource start should be considered a BIOS bug.

>> +    win_size = window->res->end - window->res->start + 1;
> 
> Use resource_size() instead.
> 

I'll fix it.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH] net: 8390: ne: Fix accidentally removed RBTX4927 support

[David Miller]

From: Geert Uytterhoeven 
Date: Wed, 16 May 2018 11:18:01 +0200

> The configuration settings for RBTX4927 were accidentally removed,
> leading to a silently broken network interface.
> 
> Re-add the missing settings to fix this.
> 
> Fixes: 8eb97ff5a4ec941d ("net: 8390: remove m32r specific bits")
> Signed-off-by: Geert Uytterhoeven 
> ---
> Bisected between v4.9-rc2 (doh) and v4.17-rc5.
> 
> Note to myself: I should do more boot testing on RBTX4927.
> Fortunately I caught it before it ends up in a point release ;-)

Better to go on a wild bisect ride than not be able to find the
bug at all :-)

Applied, thanks.

Re: [PATCH] net: 8390: ne: Fix accidentally removed RBTX4927 support

[David Miller]

From: Geert Uytterhoeven 
Date: Wed, 16 May 2018 11:18:01 +0200

> The configuration settings for RBTX4927 were accidentally removed,
> leading to a silently broken network interface.
> 
> Re-add the missing settings to fix this.
> 
> Fixes: 8eb97ff5a4ec941d ("net: 8390: remove m32r specific bits")
> Signed-off-by: Geert Uytterhoeven 
> ---
> Bisected between v4.9-rc2 (doh) and v4.17-rc5.
> 
> Note to myself: I should do more boot testing on RBTX4927.
> Fortunately I caught it before it ends up in a point release ;-)

Better to go on a wild bisect ride than not be able to find the
bug at all :-)

Applied, thanks.

Re: [PATCH V1 06/19] perf tools: Fix kernel_start for PTI on x86

[Arnaldo Carvalho de Melo]

Em Wed, May 16, 2018 at 09:16:57PM +0300, Adrian Hunter escreveu:
> On 05/16/2018 04:55 PM, Arnaldo Carvalho de Melo wrote:
> > Em Wed, May 16, 2018 at 04:45:41PM +0300, Adrian Hunter escreveu:
> >> On 16/05/18 16:00, Arnaldo Carvalho de Melo wrote:
> >>> 2303  bool machine__is(struct machine *machine, const char *arch)
> >>> 2304  {
> >>> 2305  return machine && machine->env && 
> >>> !strcmp(machine->env->arch, arch);
> >>> 2306  }
> >>> 2307  
> >>> 2308  int machine__get_kernel_start(struct machine *machine)
> >>> 2309  {
> >>> (gdb) p machine
> >>> $1 = (struct machine *) 0xc55548
> >>> (gdb) p machine->env
> >>> $2 = (struct perf_env *) 0xc06400 
> >>> (gdb) p machine-env->arch
> >>> No symbol "env" in current context.
> >>> (gdb) p machine->env->arch
> >>> $3 = 0x0
> >>> (gdb)
> >  
> >> If there is no perf_data then perf_session__new() uses perf_env but it 
> >> seems
> >> perf_env.arch is not initialized.  Would it be OK to initialize
> >> perf_env.arch and perf_env.nr_cpus_avail?
> > 
> > I guess so, to make that always available, i.e. no perf.data? Those
> > should reflect the running machine environment.
> > 
> > So a preparatory patch that makes that the case would be good, I think.
> 
> How about this:
> 
> From: Adrian Hunter 
> Date: Wed, 16 May 2018 19:58:19 +0300
> Subject: [PATCH] perf tools: Initialize perf_env.arch and
>  perf_env.nr_cpus_avail
> 
> Initialize perf_env.arch and perf_env.nr_cpus_avail so that they are
> available for tools to use, even for tools that are not processing a
> perf.data file.
> 
> Signed-off-by: Adrian Hunter 
> ---
>  tools/perf/perf.c |  4 
>  tools/perf/util/env.c | 36 
>  tools/perf/util/env.h |  2 ++
>  3 files changed, 42 insertions(+)
> 
> diff --git a/tools/perf/perf.c b/tools/perf/perf.c
> index 20a08cb32332..03ec7a3b996b 100644
> --- a/tools/perf/perf.c
> +++ b/tools/perf/perf.c
> @@ -300,7 +300,11 @@ static int run_builtin(struct cmd_struct *p, int argc, 
> const char **argv)
>   commit_pager_choice();
>  
>   perf_env__set_cmdline(_env, argc, argv);
> + status = perf_env__read_common(_env);
> + if (status < 0)
> + goto cleanup;


But this is being done unconditionally, right? We already do _tons_ of
stuff at startup, I think this should be done when we actually need it,
if not done before, i.e. either make tools that need it and know it is
not read because they don't read a perf.data file (perf-top) read it
explicitely or use perf_env__arch(machine->env) where one is not sure it
is already read, and that would do the read.

- Arnaldo

Re: [PATCH V1 06/19] perf tools: Fix kernel_start for PTI on x86

[Arnaldo Carvalho de Melo]

Em Wed, May 16, 2018 at 09:16:57PM +0300, Adrian Hunter escreveu:
> On 05/16/2018 04:55 PM, Arnaldo Carvalho de Melo wrote:
> > Em Wed, May 16, 2018 at 04:45:41PM +0300, Adrian Hunter escreveu:
> >> On 16/05/18 16:00, Arnaldo Carvalho de Melo wrote:
> >>> 2303  bool machine__is(struct machine *machine, const char *arch)
> >>> 2304  {
> >>> 2305  return machine && machine->env && 
> >>> !strcmp(machine->env->arch, arch);
> >>> 2306  }
> >>> 2307  
> >>> 2308  int machine__get_kernel_start(struct machine *machine)
> >>> 2309  {
> >>> (gdb) p machine
> >>> $1 = (struct machine *) 0xc55548
> >>> (gdb) p machine->env
> >>> $2 = (struct perf_env *) 0xc06400 
> >>> (gdb) p machine-env->arch
> >>> No symbol "env" in current context.
> >>> (gdb) p machine->env->arch
> >>> $3 = 0x0
> >>> (gdb)
> >  
> >> If there is no perf_data then perf_session__new() uses perf_env but it 
> >> seems
> >> perf_env.arch is not initialized.  Would it be OK to initialize
> >> perf_env.arch and perf_env.nr_cpus_avail?
> > 
> > I guess so, to make that always available, i.e. no perf.data? Those
> > should reflect the running machine environment.
> > 
> > So a preparatory patch that makes that the case would be good, I think.
> 
> How about this:
> 
> From: Adrian Hunter 
> Date: Wed, 16 May 2018 19:58:19 +0300
> Subject: [PATCH] perf tools: Initialize perf_env.arch and
>  perf_env.nr_cpus_avail
> 
> Initialize perf_env.arch and perf_env.nr_cpus_avail so that they are
> available for tools to use, even for tools that are not processing a
> perf.data file.
> 
> Signed-off-by: Adrian Hunter 
> ---
>  tools/perf/perf.c |  4 
>  tools/perf/util/env.c | 36 
>  tools/perf/util/env.h |  2 ++
>  3 files changed, 42 insertions(+)
> 
> diff --git a/tools/perf/perf.c b/tools/perf/perf.c
> index 20a08cb32332..03ec7a3b996b 100644
> --- a/tools/perf/perf.c
> +++ b/tools/perf/perf.c
> @@ -300,7 +300,11 @@ static int run_builtin(struct cmd_struct *p, int argc, 
> const char **argv)
>   commit_pager_choice();
>  
>   perf_env__set_cmdline(_env, argc, argv);
> + status = perf_env__read_common(_env);
> + if (status < 0)
> + goto cleanup;


But this is being done unconditionally, right? We already do _tons_ of
stuff at startup, I think this should be done when we actually need it,
if not done before, i.e. either make tools that need it and know it is
not read because they don't read a perf.data file (perf-top) read it
explicitely or use perf_env__arch(machine->env) where one is not sure it
is already read, and that would do the read.

- Arnaldo

Re: [PATCH] net: qcom/emac: Encapsulate sgmii ops under one structure

[David Miller]

From: Hemanth Puranik 
Date: Wed, 16 May 2018 06:40:53 +0530

> This patch introduces ops structure for sgmii, This by ensures that
> we do not need dummy functions in case of emulation platforms.
> 
> Signed-off-by: Hemanth Puranik 

Applied to net-next.

Re: [PATCH] net: qcom/emac: Encapsulate sgmii ops under one structure

[David Miller]

From: Hemanth Puranik 
Date: Wed, 16 May 2018 06:40:53 +0530

> This patch introduces ops structure for sgmii, This by ensures that
> we do not need dummy functions in case of emulation platforms.
> 
> Signed-off-by: Hemanth Puranik 

Applied to net-next.

Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[Geert Uytterhoeven]

Hi David,

On Wed, May 16, 2018 at 8:21 PM, David Miller  wrote:
> From: Florian Fainelli 
> Date: Tue, 15 May 2018 16:56:17 -0700
>
>> This patch series updates of_mdiobus_register() such that when the 
>> device_node
>> argument is NULL, it calls mdiobus_register() directly. This is consistent 
>> with
>> the behavior of of_mdiobus_register() when CONFIG_OF=n.
>>
>> I only converted the most obvious drivers, there are others that have a much
>> less obvious behavior and specifically attempt to deal with CONFIG_ACPI.
>>
>> Changes in v2:
>>
>> - fixed build error in davincin_mdio.c (Grygorii)
>> - reworked first patch a bit: commit message, subject and removed useless
>>   code comment
>
> Based upon Andrew's response to Geert's feedback, I'm applying this series.

Thanks, his feedback made perfect sense.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[Geert Uytterhoeven]

Hi David,

On Wed, May 16, 2018 at 8:21 PM, David Miller  wrote:
> From: Florian Fainelli 
> Date: Tue, 15 May 2018 16:56:17 -0700
>
>> This patch series updates of_mdiobus_register() such that when the 
>> device_node
>> argument is NULL, it calls mdiobus_register() directly. This is consistent 
>> with
>> the behavior of of_mdiobus_register() when CONFIG_OF=n.
>>
>> I only converted the most obvious drivers, there are others that have a much
>> less obvious behavior and specifically attempt to deal with CONFIG_ACPI.
>>
>> Changes in v2:
>>
>> - fixed build error in davincin_mdio.c (Grygorii)
>> - reworked first patch a bit: commit message, subject and removed useless
>>   code comment
>
> Based upon Andrew's response to Geert's feedback, I'm applying this series.

Thanks, his feedback made perfect sense.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[BUG] net: stmmac: dwmac-sun8i broken in linux-next

[Corentin Labbe]

Hello

The dwmac-sun8i driver is broken in next-20180515, symptom are no RX and TX 
errors as shown by ifconfig:
eth0: flags=4163  mtu 1500
inet 192.168.1.204  netmask 255.255.255.0  broadcast 192.168.1.255
ether 96:75:ff:0d:f6:d8  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 4956 (4.8 KiB)
TX errors 118  dropped 0 overruns 0  carrier 0  collisions 0

Reverting the following commit made the driver working:
4dbbe8dde8485b89bce8bbbe7564337fd7eed69f ("net: stmmac: Add support for U32 TC 
filter using Flexible RX Parser")
5f0456b43140af9413397cc11d03d18b9f2fc2fc ("net: stmmac: Implement logic to 
automatically select HW Interface")

Note that reverting only 4dbbe8dde8485b89bce8bbbe7564337fd7eed69f lead to crash:
[   31.385110] Backtrace: 
[   31.387576] [] (stmmac_open) from [] 
(__dev_open+0xe4/0x180)
[   31.394972]  r10:ed447d04 r9:edc5d010 r8:ef02002c r7:c08670a4 r6: 
r5:c0c08488
[   31.402793]  r4:ef02
[   31.405335] [] (__dev_open) from [] 
(__dev_change_flags+0x190/0x1e8)
[   31.413421]  r8:1002 r7:c0c08488 r6:1003 r5:0001 r4:ef02
[   31.420122] [] (__dev_change_flags) from [] 
(dev_change_flags+0x20/0x50)
[   31.428555]  r9:edc5d010 r8:ed447c18 r7:ef020134 r6: r5:1002 
r4:ef02
[   31.436300] [] (dev_change_flags) from [] 
(do_setlink+0x28c/0xbdc)
[   31.444213]  r9:edc5d010 r8:ed447c18 r7: r6:c0c08488 r5:ed447b50 
r4:ef02
[   31.451955] [] (do_setlink) from [] 
(rtnl_newlink+0x54c/0x7a8)
[   31.459522]  r10:ed447d04 r9: r8: r7: r6: 
r5:
[   31.467343]  r4:ef02
[   31.469885] [] (rtnl_newlink) from [] 
(rtnetlink_rcv_msg+0x38c/0x544)
[   31.478058]  r10:ed447d04 r9: r8:ee242840 r7: r6:edc5d000 
r5:c0c08488
[   31.485879]  r4:
[   31.488422] [] (rtnetlink_rcv_msg) from [] 
(netlink_rcv_skb+0xc0/0x118)
[   31.496768]  r10:c0c08488 r9: r8:0020 r7:edc5d000 r6:c064466c 
r5:c0c08488
[   31.504589]  r4:ee242840
[   31.507129] [] (netlink_rcv_skb) from [] 
(rtnetlink_rcv+0x18/0x1c)
[   31.515042]  r8:ed447d60 r7:ee242840 r6:0020 r5:ee37d800 r4:ee5fac00
[   31.521742] [] (rtnetlink_rcv) from [] 
(netlink_unicast+0x190/0x1fc)
[   31.529829] [] (netlink_unicast) from [] 
(netlink_sendmsg+0x3cc/0x410)
[   31.538089]  r10: r9:0020 r8:014000c0 r7:ee242840 r6:ee37d800 
r5:c0c08488
[   31.545910]  r4:ed447f44
[   31.548452] [] (netlink_sendmsg) from [] 
(sock_sendmsg+0x1c/0x2c)
[   31.556279]  r10: r9:ed447edc r8: r7:eefce640 r6: 
r5:c0c08488
[   31.564100]  r4:ed447f44
[   31.566640] [] (sock_sendmsg) from [] 
(___sys_sendmsg+0x250/0x264)
[   31.574555] [] (___sys_sendmsg) from [] 
(__sys_sendmsg+0x58/0x94)
[   31.582382]  r10: r9:ed446000 r8:c01011c4 r7:eefce640 r6: 
r5:bec25150
[   31.590203]  r4:c0c08488
[   31.592743] [] (__sys_sendmsg) from [] 
(sys_sendmsg+0x14/0x18)
[   31.600307]  r7:0128 r6:bec2d17c r5:bec25144 r4:00093ee0
[   31.605969] [] (sys_sendmsg) from [] 
(ret_fast_syscall+0x0/0x28)
[   31.613704] Exception stack(0xed447fa8 to 0xed447ff0)
[   31.618756] 7fa0:   00093ee0 bec25144 0003 bec25150 
 85ce
[   31.626929] 7fc0: 00093ee0 bec25144 bec2d17c 0128 000942a8 5afc783a 
00094000 bec25150
[   31.635099] 7fe0:  bec250f0 012c b6e10b5c
[   31.640152] Code: e59a261c e59a013c e50b306c e592300c (e593300c) 
[   31.646632] ---[ end trace 407964b7deb937bf ]---

For the moment, I stil didnt find the issue.
What to we do now ? do you want that I send revert patchs ?

Regards

[BUG] net: stmmac: dwmac-sun8i broken in linux-next

[Corentin Labbe]

Hello

The dwmac-sun8i driver is broken in next-20180515, symptom are no RX and TX 
errors as shown by ifconfig:
eth0: flags=4163  mtu 1500
inet 192.168.1.204  netmask 255.255.255.0  broadcast 192.168.1.255
ether 96:75:ff:0d:f6:d8  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 4956 (4.8 KiB)
TX errors 118  dropped 0 overruns 0  carrier 0  collisions 0

Reverting the following commit made the driver working:
4dbbe8dde8485b89bce8bbbe7564337fd7eed69f ("net: stmmac: Add support for U32 TC 
filter using Flexible RX Parser")
5f0456b43140af9413397cc11d03d18b9f2fc2fc ("net: stmmac: Implement logic to 
automatically select HW Interface")

Note that reverting only 4dbbe8dde8485b89bce8bbbe7564337fd7eed69f lead to crash:
[   31.385110] Backtrace: 
[   31.387576] [] (stmmac_open) from [] 
(__dev_open+0xe4/0x180)
[   31.394972]  r10:ed447d04 r9:edc5d010 r8:ef02002c r7:c08670a4 r6: 
r5:c0c08488
[   31.402793]  r4:ef02
[   31.405335] [] (__dev_open) from [] 
(__dev_change_flags+0x190/0x1e8)
[   31.413421]  r8:1002 r7:c0c08488 r6:1003 r5:0001 r4:ef02
[   31.420122] [] (__dev_change_flags) from [] 
(dev_change_flags+0x20/0x50)
[   31.428555]  r9:edc5d010 r8:ed447c18 r7:ef020134 r6: r5:1002 
r4:ef02
[   31.436300] [] (dev_change_flags) from [] 
(do_setlink+0x28c/0xbdc)
[   31.444213]  r9:edc5d010 r8:ed447c18 r7: r6:c0c08488 r5:ed447b50 
r4:ef02
[   31.451955] [] (do_setlink) from [] 
(rtnl_newlink+0x54c/0x7a8)
[   31.459522]  r10:ed447d04 r9: r8: r7: r6: 
r5:
[   31.467343]  r4:ef02
[   31.469885] [] (rtnl_newlink) from [] 
(rtnetlink_rcv_msg+0x38c/0x544)
[   31.478058]  r10:ed447d04 r9: r8:ee242840 r7: r6:edc5d000 
r5:c0c08488
[   31.485879]  r4:
[   31.488422] [] (rtnetlink_rcv_msg) from [] 
(netlink_rcv_skb+0xc0/0x118)
[   31.496768]  r10:c0c08488 r9: r8:0020 r7:edc5d000 r6:c064466c 
r5:c0c08488
[   31.504589]  r4:ee242840
[   31.507129] [] (netlink_rcv_skb) from [] 
(rtnetlink_rcv+0x18/0x1c)
[   31.515042]  r8:ed447d60 r7:ee242840 r6:0020 r5:ee37d800 r4:ee5fac00
[   31.521742] [] (rtnetlink_rcv) from [] 
(netlink_unicast+0x190/0x1fc)
[   31.529829] [] (netlink_unicast) from [] 
(netlink_sendmsg+0x3cc/0x410)
[   31.538089]  r10: r9:0020 r8:014000c0 r7:ee242840 r6:ee37d800 
r5:c0c08488
[   31.545910]  r4:ed447f44
[   31.548452] [] (netlink_sendmsg) from [] 
(sock_sendmsg+0x1c/0x2c)
[   31.556279]  r10: r9:ed447edc r8: r7:eefce640 r6: 
r5:c0c08488
[   31.564100]  r4:ed447f44
[   31.566640] [] (sock_sendmsg) from [] 
(___sys_sendmsg+0x250/0x264)
[   31.574555] [] (___sys_sendmsg) from [] 
(__sys_sendmsg+0x58/0x94)
[   31.582382]  r10: r9:ed446000 r8:c01011c4 r7:eefce640 r6: 
r5:bec25150
[   31.590203]  r4:c0c08488
[   31.592743] [] (__sys_sendmsg) from [] 
(sys_sendmsg+0x14/0x18)
[   31.600307]  r7:0128 r6:bec2d17c r5:bec25144 r4:00093ee0
[   31.605969] [] (sys_sendmsg) from [] 
(ret_fast_syscall+0x0/0x28)
[   31.613704] Exception stack(0xed447fa8 to 0xed447ff0)
[   31.618756] 7fa0:   00093ee0 bec25144 0003 bec25150 
 85ce
[   31.626929] 7fc0: 00093ee0 bec25144 bec2d17c 0128 000942a8 5afc783a 
00094000 bec25150
[   31.635099] 7fe0:  bec250f0 012c b6e10b5c
[   31.640152] Code: e59a261c e59a013c e50b306c e592300c (e593300c) 
[   31.646632] ---[ end trace 407964b7deb937bf ]---

For the moment, I stil didnt find the issue.
What to we do now ? do you want that I send revert patchs ?

Regards

Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge

[Timur Tabi]

On 05/16/2018 01:23 PM, Sinan Kaya wrote:

+   win_start = window->res->start - window->offset;


Can you guarantee that window->res->start is always >= window->offset?


+   win_size = window->res->end - window->res->start + 1;


Use resource_size() instead.

--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge

[Timur Tabi]

On 05/16/2018 01:23 PM, Sinan Kaya wrote:

+   win_start = window->res->start - window->offset;


Can you guarantee that window->res->start is always >= window->offset?


+   win_size = window->res->end - window->res->start + 1;


Use resource_size() instead.

--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge

[Sinan Kaya]

On 5/16/2018 2:23 PM, Sinan Kaya wrote:
> + if (win_start <= base && win_end >= base + win_size - 1) {
> + base += window->offset;
> + break;
> + }

I should probably add window->offset!=0 to the if statement in order not to
break non-translating case.

Any other comments?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge

[Sinan Kaya]

On 5/16/2018 2:23 PM, Sinan Kaya wrote:
> + if (win_start <= base && win_end >= base + win_size - 1) {
> + base += window->offset;
> + break;
> + }

I should probably add window->offset!=0 to the if statement in order not to
break non-translating case.

Any other comments?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 5/5] staging: lustre: Fix "from from"->"from"

[Sabin Mihai Rapan]

Trivial fix to spelling mistake in README.txt

Signed-off-by: Sabin Mihai Rapan 
---
 drivers/staging/lustre/README.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/README.txt 
b/drivers/staging/lustre/README.txt
index 0676243eea9e..783959240490 100644
--- a/drivers/staging/lustre/README.txt
+++ b/drivers/staging/lustre/README.txt
@@ -4,7 +4,7 @@ Lustre Parallel Filesystem Client
 The Lustre file system is an open-source, parallel file system
 that supports many requirements of leadership class HPC simulation
 environments.
-Born from from a research project at Carnegie Mellon University,
+Born from a research project at Carnegie Mellon University,
 the Lustre file system is a widely-used option in HPC.
 The Lustre file system provides a POSIX compliant file system interface,
 can scale to thousands of clients, petabytes of storage and
-- 
2.17.0

[PATCH 5/5] staging: lustre: Fix "from from"->"from"

[Sabin Mihai Rapan]

Trivial fix to spelling mistake in README.txt

Signed-off-by: Sabin Mihai Rapan 
---
 drivers/staging/lustre/README.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/README.txt 
b/drivers/staging/lustre/README.txt
index 0676243eea9e..783959240490 100644
--- a/drivers/staging/lustre/README.txt
+++ b/drivers/staging/lustre/README.txt
@@ -4,7 +4,7 @@ Lustre Parallel Filesystem Client
 The Lustre file system is an open-source, parallel file system
 that supports many requirements of leadership class HPC simulation
 environments.
-Born from from a research project at Carnegie Mellon University,
+Born from a research project at Carnegie Mellon University,
 the Lustre file system is a widely-used option in HPC.
 The Lustre file system provides a POSIX compliant file system interface,
 can scale to thousands of clients, petabytes of storage and
-- 
2.17.0

[PATCH 4/5] staging: lustre: Fix "Possible intergrate"->"Possibly integrate"

[Sabin Mihai Rapan]

Trivial fix to spelling mistake in TODO file.

Signed-off-by: Sabin Mihai Rapan 
---
 drivers/staging/lustre/TODO | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/TODO b/drivers/staging/lustre/TODO
index 94446487748a..5332cdb19bfa 100644
--- a/drivers/staging/lustre/TODO
+++ b/drivers/staging/lustre/TODO
@@ -12,7 +12,7 @@ addressed:
 * https://jira.hpdd.intel.com/browse/LU-9859
 *
 * Track all the cleanups and simplification of the libcfs module. Remove
-* functions the kernel provides. Possible intergrate some of the functionality
+* functions the kernel provides. Possibly integrate some of the functionality
 * into the kernel proper.
 *
 **
-- 
2.17.0

[PATCH 4/5] staging: lustre: Fix "Possible intergrate"->"Possibly integrate"

[Sabin Mihai Rapan]

Trivial fix to spelling mistake in TODO file.

Signed-off-by: Sabin Mihai Rapan 
---
 drivers/staging/lustre/TODO | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/TODO b/drivers/staging/lustre/TODO
index 94446487748a..5332cdb19bfa 100644
--- a/drivers/staging/lustre/TODO
+++ b/drivers/staging/lustre/TODO
@@ -12,7 +12,7 @@ addressed:
 * https://jira.hpdd.intel.com/browse/LU-9859
 *
 * Track all the cleanups and simplification of the libcfs module. Remove
-* functions the kernel provides. Possible intergrate some of the functionality
+* functions the kernel provides. Possibly integrate some of the functionality
 * into the kernel proper.
 *
 **
-- 
2.17.0

[PATCH 3/5] staging: lustre: Fix "unsigned"->"unsigned int"

[Sabin Mihai Rapan]

This patch fixes the checkpatch.pl warning:

WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'

Signed-off-by: Sabin Mihai Rapan 
---
 .../staging/lustre/include/uapi/linux/lustre/lustre_fiemap.h| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fiemap.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fiemap.h
index f5214dc33c60..d375a476f5ea 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fiemap.h
+++ b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fiemap.h
@@ -51,7 +51,7 @@ static inline size_t fiemap_count_to_size(size_t extent_count)
   sizeof(struct fiemap_extent);
 }
 
-static inline unsigned fiemap_size_to_count(size_t array_size)
+static inline unsigned int fiemap_size_to_count(size_t array_size)
 {
return (array_size - sizeof(struct fiemap)) /
sizeof(struct fiemap_extent);
-- 
2.17.0

[PATCH 3/5] staging: lustre: Fix "unsigned"->"unsigned int"

[Sabin Mihai Rapan]

This patch fixes the checkpatch.pl warning:

WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'

Signed-off-by: Sabin Mihai Rapan 
---
 .../staging/lustre/include/uapi/linux/lustre/lustre_fiemap.h| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fiemap.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fiemap.h
index f5214dc33c60..d375a476f5ea 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fiemap.h
+++ b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fiemap.h
@@ -51,7 +51,7 @@ static inline size_t fiemap_count_to_size(size_t extent_count)
   sizeof(struct fiemap_extent);
 }
 
-static inline unsigned fiemap_size_to_count(size_t array_size)
+static inline unsigned int fiemap_size_to_count(size_t array_size)
 {
return (array_size - sizeof(struct fiemap)) /
sizeof(struct fiemap_extent);
-- 
2.17.0

[PATCH 1/5] staging: lustre: Fix inclusion of local headers

[Sabin Mihai Rapan]

This patch fixes the checkpatch.pl error:

ERROR:UAPI_INCLUDE: No #include in ...include/uapi/... should use a uapi/ path
prefix

Signed-off-by: Sabin Mihai Rapan 
---
 drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h | 4 ++--
 drivers/staging/lustre/include/uapi/linux/lnet/lnetctl.h  | 2 +-
 drivers/staging/lustre/include/uapi/linux/lnet/nidstr.h   | 2 +-
 drivers/staging/lustre/include/uapi/linux/lustre/lustre_cfg.h | 2 +-
 drivers/staging/lustre/include/uapi/linux/lustre/lustre_fid.h | 2 +-
 drivers/staging/lustre/include/uapi/linux/lustre/lustre_idl.h | 4 ++--
 .../staging/lustre/include/uapi/linux/lustre/lustre_ioctl.h   | 2 +-
 .../staging/lustre/include/uapi/linux/lustre/lustre_ostid.h   | 2 +-
 .../staging/lustre/include/uapi/linux/lustre/lustre_user.h| 2 +-
 9 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h 
b/drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h
index c1619f411d81..1530ac26b449 100644
--- a/drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h
+++ b/drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h
@@ -29,8 +29,8 @@
 #ifndef LNET_DLC_H
 #define LNET_DLC_H
 
-#include 
-#include 
+#include "libcfs_ioctl.h"
+#include "lnet-types.h"
 
 #define MAX_NUM_SHOW_ENTRIES   32
 #define LNET_MAX_STR_LEN   128
diff --git a/drivers/staging/lustre/include/uapi/linux/lnet/lnetctl.h 
b/drivers/staging/lustre/include/uapi/linux/lnet/lnetctl.h
index cccb32dd28f2..c7be86610cc0 100644
--- a/drivers/staging/lustre/include/uapi/linux/lnet/lnetctl.h
+++ b/drivers/staging/lustre/include/uapi/linux/lnet/lnetctl.h
@@ -15,7 +15,7 @@
 #ifndef _LNETCTL_H_
 #define _LNETCTL_H_
 
-#include 
+#include "lnet-types.h"
 
 /** \addtogroup lnet_fault_simulation
  * @{
diff --git a/drivers/staging/lustre/include/uapi/linux/lnet/nidstr.h 
b/drivers/staging/lustre/include/uapi/linux/lnet/nidstr.h
index 882074ed6021..d153c97ea64d 100644
--- a/drivers/staging/lustre/include/uapi/linux/lnet/nidstr.h
+++ b/drivers/staging/lustre/include/uapi/linux/lnet/nidstr.h
@@ -28,7 +28,7 @@
 #ifndef _LNET_NIDSTRINGS_H
 #define _LNET_NIDSTRINGS_H
 
-#include 
+#include "lnet-types.h"
 
 /**
  *  Lustre Network Driver types.
diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_cfg.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_cfg.h
index 11b51d93f64c..a1dc912af960 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_cfg.h
+++ b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_cfg.h
@@ -35,7 +35,7 @@
 
 #include 
 #include 
-#include 
+#include "lustre_user.h"
 
 /** \defgroup cfg cfg
  *
diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fid.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fid.h
index 2e7a8d103777..1e347a86427c 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fid.h
+++ b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fid.h
@@ -37,7 +37,7 @@
 #ifndef _UAPI_LUSTRE_FID_H_
 #define _UAPI_LUSTRE_FID_H_
 
-#include 
+#include "lustre_idl.h"
 
 /** returns fid object sequence */
 static inline __u64 fid_seq(const struct lu_fid *fid)
diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_idl.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_idl.h
index aac98dbcf6e3..e6016a71ad23 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_idl.h
@@ -72,8 +72,8 @@
 
 #include 
 /* Defn's shared with user-space. */
-#include 
-#include 
+#include "lustre_user.h"
+#include "lustre_ver.h"
 
 /*
  *  GENERAL STUFF
diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ioctl.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ioctl.h
index 6e4e109fb874..54e8fbbe98c4 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ioctl.h
+++ b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ioctl.h
@@ -31,7 +31,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "lustre_idl.h"
 
 #if !defined(__KERNEL__) && !defined(LUSTRE_UTILS)
 # error This file is for Lustre internal use only.
diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ostid.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ostid.h
index 3343b602219b..9110229b0886 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ostid.h
+++ b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ostid.h
@@ -35,7 +35,7 @@
 #define _UAPI_LUSTRE_OSTID_H_
 
 #include 
-#include 
+#include "lustre_fid.h"
 
 static inline __u64 lmm_oi_id(const struct ost_id *oi)
 {
diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_user.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_user.h
index 5e332e3af68a..2fcfe2b2d365 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_user.h
+++ 

[PATCH 1/5] staging: lustre: Fix inclusion of local headers

[Sabin Mihai Rapan]

This patch fixes the checkpatch.pl error:

ERROR:UAPI_INCLUDE: No #include in ...include/uapi/... should use a uapi/ path
prefix

Signed-off-by: Sabin Mihai Rapan 
---
 drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h | 4 ++--
 drivers/staging/lustre/include/uapi/linux/lnet/lnetctl.h  | 2 +-
 drivers/staging/lustre/include/uapi/linux/lnet/nidstr.h   | 2 +-
 drivers/staging/lustre/include/uapi/linux/lustre/lustre_cfg.h | 2 +-
 drivers/staging/lustre/include/uapi/linux/lustre/lustre_fid.h | 2 +-
 drivers/staging/lustre/include/uapi/linux/lustre/lustre_idl.h | 4 ++--
 .../staging/lustre/include/uapi/linux/lustre/lustre_ioctl.h   | 2 +-
 .../staging/lustre/include/uapi/linux/lustre/lustre_ostid.h   | 2 +-
 .../staging/lustre/include/uapi/linux/lustre/lustre_user.h| 2 +-
 9 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h 
b/drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h
index c1619f411d81..1530ac26b449 100644
--- a/drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h
+++ b/drivers/staging/lustre/include/uapi/linux/lnet/lnet-dlc.h
@@ -29,8 +29,8 @@
 #ifndef LNET_DLC_H
 #define LNET_DLC_H
 
-#include 
-#include 
+#include "libcfs_ioctl.h"
+#include "lnet-types.h"
 
 #define MAX_NUM_SHOW_ENTRIES   32
 #define LNET_MAX_STR_LEN   128
diff --git a/drivers/staging/lustre/include/uapi/linux/lnet/lnetctl.h 
b/drivers/staging/lustre/include/uapi/linux/lnet/lnetctl.h
index cccb32dd28f2..c7be86610cc0 100644
--- a/drivers/staging/lustre/include/uapi/linux/lnet/lnetctl.h
+++ b/drivers/staging/lustre/include/uapi/linux/lnet/lnetctl.h
@@ -15,7 +15,7 @@
 #ifndef _LNETCTL_H_
 #define _LNETCTL_H_
 
-#include 
+#include "lnet-types.h"
 
 /** \addtogroup lnet_fault_simulation
  * @{
diff --git a/drivers/staging/lustre/include/uapi/linux/lnet/nidstr.h 
b/drivers/staging/lustre/include/uapi/linux/lnet/nidstr.h
index 882074ed6021..d153c97ea64d 100644
--- a/drivers/staging/lustre/include/uapi/linux/lnet/nidstr.h
+++ b/drivers/staging/lustre/include/uapi/linux/lnet/nidstr.h
@@ -28,7 +28,7 @@
 #ifndef _LNET_NIDSTRINGS_H
 #define _LNET_NIDSTRINGS_H
 
-#include 
+#include "lnet-types.h"
 
 /**
  *  Lustre Network Driver types.
diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_cfg.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_cfg.h
index 11b51d93f64c..a1dc912af960 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_cfg.h
+++ b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_cfg.h
@@ -35,7 +35,7 @@
 
 #include 
 #include 
-#include 
+#include "lustre_user.h"
 
 /** \defgroup cfg cfg
  *
diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fid.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fid.h
index 2e7a8d103777..1e347a86427c 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fid.h
+++ b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_fid.h
@@ -37,7 +37,7 @@
 #ifndef _UAPI_LUSTRE_FID_H_
 #define _UAPI_LUSTRE_FID_H_
 
-#include 
+#include "lustre_idl.h"
 
 /** returns fid object sequence */
 static inline __u64 fid_seq(const struct lu_fid *fid)
diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_idl.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_idl.h
index aac98dbcf6e3..e6016a71ad23 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_idl.h
@@ -72,8 +72,8 @@
 
 #include 
 /* Defn's shared with user-space. */
-#include 
-#include 
+#include "lustre_user.h"
+#include "lustre_ver.h"
 
 /*
  *  GENERAL STUFF
diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ioctl.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ioctl.h
index 6e4e109fb874..54e8fbbe98c4 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ioctl.h
+++ b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ioctl.h
@@ -31,7 +31,7 @@
 #include 
 #include 
 #include 
-#include 
+#include "lustre_idl.h"
 
 #if !defined(__KERNEL__) && !defined(LUSTRE_UTILS)
 # error This file is for Lustre internal use only.
diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ostid.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ostid.h
index 3343b602219b..9110229b0886 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ostid.h
+++ b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_ostid.h
@@ -35,7 +35,7 @@
 #define _UAPI_LUSTRE_OSTID_H_
 
 #include 
-#include 
+#include "lustre_fid.h"
 
 static inline __u64 lmm_oi_id(const struct ost_id *oi)
 {
diff --git a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_user.h 
b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_user.h
index 5e332e3af68a..2fcfe2b2d365 100644
--- a/drivers/staging/lustre/include/uapi/linux/lustre/lustre_user.h
+++ b/drivers/staging/lustre/include/uapi/linux/lustre/lustre_user.h