Re: [PATCH v9 2/2] ARM: dts: add TOPEET itop elite based board

[Krzysztof Kozlowski]

On Wed, Oct 19, 2016 at 4:15 AM, Ayaka  wrote:
>
>
> 從我的 iPad 傳送
>
>> Krzysztof Kozlowski  於 2016年10月19日 上午1:37 寫道：
>>
>>> On Wed, Oct 19, 2016 at 01:18:49AM +0800, Randy Li wrote:
>>> The TOPEET itop exynos 4412 have three versions base board. The
>>> Elite version is the cheap one without too much peripheral devices
>>> on it.
>>>
>>> Currently supported are serial console, wired networking(USB),
>>> USB OTG in peripheral mode, USB host, SD storage, GPIO buttons,
>>> PWM beeper, ADC and LEDs. The WM8960 analog audio codec is also
>>> enabled.
>>>
>>> The FIMC is not used for camera currently, I enabled it just for a
>>> colorspace converter.
>>>
>>> Signed-off-by: Randy Li 
>>> Reviewed-by: Krzysztof Kozlowski 
>>
>> Thanks, applied, with missing Rob's ack, minor changes in commit msg and
>> fix in pin function (you used macro for pull up/down instead of
>> function).
> The last time I saw the other dts have applied that, but they are not now. A 
> header file is also missed reported by kbuild, but I didn't meet that.

I wonder why I didn't encounter the build error on my machine... This
needs a follow up fix.

Best regards,
Krzysztof

Re: [PATCH v9 2/2] ARM: dts: add TOPEET itop elite based board

[Krzysztof Kozlowski]

On Wed, Oct 19, 2016 at 4:15 AM, Ayaka  wrote:
>
>
> 從我的 iPad 傳送
>
>> Krzysztof Kozlowski  於 2016年10月19日 上午1:37 寫道：
>>
>>> On Wed, Oct 19, 2016 at 01:18:49AM +0800, Randy Li wrote:
>>> The TOPEET itop exynos 4412 have three versions base board. The
>>> Elite version is the cheap one without too much peripheral devices
>>> on it.
>>>
>>> Currently supported are serial console, wired networking(USB),
>>> USB OTG in peripheral mode, USB host, SD storage, GPIO buttons,
>>> PWM beeper, ADC and LEDs. The WM8960 analog audio codec is also
>>> enabled.
>>>
>>> The FIMC is not used for camera currently, I enabled it just for a
>>> colorspace converter.
>>>
>>> Signed-off-by: Randy Li 
>>> Reviewed-by: Krzysztof Kozlowski 
>>
>> Thanks, applied, with missing Rob's ack, minor changes in commit msg and
>> fix in pin function (you used macro for pull up/down instead of
>> function).
> The last time I saw the other dts have applied that, but they are not now. A 
> header file is also missed reported by kbuild, but I didn't meet that.

I wonder why I didn't encounter the build error on my machine... This
needs a follow up fix.

Best regards,
Krzysztof

Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

[Juergen Gross]

On 18/10/16 18:40, Boris Ostrovsky wrote:
> On 10/18/2016 12:08 PM, Juergen Gross wrote:
>> On 14/10/16 22:02, Boris Ostrovsky wrote:
>>> On 10/14/2016 03:51 PM, Konrad Rzeszutek Wilk wrote:
 On Fri, Oct 14, 2016 at 03:43:19PM -0400, Boris Ostrovsky wrote:
> On 10/14/2016 03:19 PM, Konrad Rzeszutek Wilk wrote:
>> On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:
>>
>> Perhaps add in here:
>>
>> PVH is like PV in that there are no PCI devices - which HVM
>> code would piggyback on to find the Xen PCI platform device and
>> use its MMIO space to stash the grants in.
>>
>> For PVH we balloon out memory and stash the grants in there.
>>
>> (Which begs the next question - where and when do we balloon out the
>> normal memory back in?)
> Are you saying that we should get back memory that we gave to grant 
> tables?
 Yes.

 In pure HVM that area is MMIO - which hvmloader has balloonned out.

 The hvmloader then balloons that number of pages back  at the end of
 guest memory (after 4GB).
>>> We don't do this for PV though, do we?
>> Uuh, kind of. We try to allocate granted pages from the ballooned area.
>> See gnttab_alloc_pages().
> 
> 
> I meant that we don't give memory back for PV.

That's right AFAIK.

>> So for PV(H) we don't need to balloon this memory back in as it was
>> never shadowed by a grant.
> 
> 
> Is it *never* or *may or may not be* shadowed? (I assume "shadowed"
> means "used for" here.)

"shadowed" means a pte is being used for a granted page which was
referencing a RAM page before. So the RAM page is unusable as long as
the grant is active.

A page is shadowed by a grant only if there is no ballooning space
available, so ballooning that page out would serve no purpose as we
would have no way to balloon it in at another address.


Juergen

Re: [Xen-devel] [PATCH 6/8] xen/pvh: Initialize grant table for PVH guests

[Juergen Gross]

On 18/10/16 18:40, Boris Ostrovsky wrote:
> On 10/18/2016 12:08 PM, Juergen Gross wrote:
>> On 14/10/16 22:02, Boris Ostrovsky wrote:
>>> On 10/14/2016 03:51 PM, Konrad Rzeszutek Wilk wrote:
 On Fri, Oct 14, 2016 at 03:43:19PM -0400, Boris Ostrovsky wrote:
> On 10/14/2016 03:19 PM, Konrad Rzeszutek Wilk wrote:
>> On Fri, Oct 14, 2016 at 02:05:16PM -0400, Boris Ostrovsky wrote:
>>
>> Perhaps add in here:
>>
>> PVH is like PV in that there are no PCI devices - which HVM
>> code would piggyback on to find the Xen PCI platform device and
>> use its MMIO space to stash the grants in.
>>
>> For PVH we balloon out memory and stash the grants in there.
>>
>> (Which begs the next question - where and when do we balloon out the
>> normal memory back in?)
> Are you saying that we should get back memory that we gave to grant 
> tables?
 Yes.

 In pure HVM that area is MMIO - which hvmloader has balloonned out.

 The hvmloader then balloons that number of pages back  at the end of
 guest memory (after 4GB).
>>> We don't do this for PV though, do we?
>> Uuh, kind of. We try to allocate granted pages from the ballooned area.
>> See gnttab_alloc_pages().
> 
> 
> I meant that we don't give memory back for PV.

That's right AFAIK.

>> So for PV(H) we don't need to balloon this memory back in as it was
>> never shadowed by a grant.
> 
> 
> Is it *never* or *may or may not be* shadowed? (I assume "shadowed"
> means "used for" here.)

"shadowed" means a pte is being used for a granted page which was
referencing a RAM page before. So the RAM page is unusable as long as
the grant is active.

A page is shadowed by a grant only if there is no ballooning space
available, so ballooning that page out would serve no purpose as we
would have no way to balloon it in at another address.


Juergen

Re: [PATCH] staging: greybus: audio: Rename cport with intf_id

[Vaibhav Agarwal]

On Mon, Oct 17, 2016 at 9:01 PM, Johan Hovold  wrote:
> On Sun, Oct 16, 2016 at 03:29:14PM +0530, Pankaj Bharadiya wrote:
>> gb_audio_manager_module_descriptor's cport field is actually used to
>> manage and pass interface id to user space.
>>
>> Thus rename gb_audio_manager_module_descriptor's 'cport' field and
>> few other things to avoid confusion.
>
> Please be more specific about what these other things are; in this case
> sysfs attributes, uevent vars, and an odd-looking sysfs-string
> interface (more?).
>
> Wouldn't this change break any current user-space implementation?

Yes, it would require changes in user space code as well. For now, it
should be GMP-Audio HAL only.

>
> Also why aren't any of these attributes documented as they should be?

Currently, none of GB Audio specific sysfs entries are documented.
I'll share another patch for this.

--
thanks,
./va

>
> Thanks,
> Johan

Re: [PATCH] staging: greybus: audio: Rename cport with intf_id

[Vaibhav Agarwal]

On Mon, Oct 17, 2016 at 9:01 PM, Johan Hovold  wrote:
> On Sun, Oct 16, 2016 at 03:29:14PM +0530, Pankaj Bharadiya wrote:
>> gb_audio_manager_module_descriptor's cport field is actually used to
>> manage and pass interface id to user space.
>>
>> Thus rename gb_audio_manager_module_descriptor's 'cport' field and
>> few other things to avoid confusion.
>
> Please be more specific about what these other things are; in this case
> sysfs attributes, uevent vars, and an odd-looking sysfs-string
> interface (more?).
>
> Wouldn't this change break any current user-space implementation?

Yes, it would require changes in user space code as well. For now, it
should be GMP-Audio HAL only.

>
> Also why aren't any of these attributes documented as they should be?

Currently, none of GB Audio specific sysfs entries are documented.
I'll share another patch for this.

--
thanks,
./va

>
> Thanks,
> Johan

Intel H81 Chipset PCIe configuration question

[Steve Kenton]

A while back I posted about a motherboard network controller that
disappeared when the firmware on a PCIe card was upgraded which
converted the card from a 32-bit BAR to a 64-bit BAR. That seems to be a
BIOS bug rather than a kernel issue. But, I would really like to be able
to upgrade the systems in the field so I'm still chasing the BIOS issue
and I'm puzzled by a programming issue when configuring the PCIe
settings of the Intel 8-Series/C220 chipset. I'm hoping someone here can
shine a bit of light on it. The device of interest is the Realtek Lan at
1c.5 which is "Port6" in Intel nomencature.
http://www.intel.com/content/www/us/en/chipsets/8-series-chipset-pch-datasheet.html

The BIOS has an ME-Disable option so I disabled the Intel Management
Engine and then used flashrom to create an 8MB "oem.bin" image of the
bios. At the beginning of oem.bin is an SPI Flash Descriptor Signature
0FF0A55Ah so I used the coreboot ifdtool program to dump the SPI Flash
Descriptor information below. It appears to be both valid and sane. In
particular, soft strap 9 (PCHSTRP9:  0x30540580) looks like it sets all
the PCIe lanes to an x1 configuration. On the other hand "lspci -s 1c.5
xxx" shows the Link Capabilities Register (LCAP: 0x06323C12) which means
Port5 with x2 lanes, Port6 disabled and Ports7/8 (which do not exist on
the H81 SKU) as x1 lanes. This is the working configuration so something
strange is going on. To the best of my understanding it is not possible
to change the port width and override the soft strap settings in ROM by
rewriting any chipset registers. Anybody have any ideas how the BIOS
could be doing this?

After the firmware is upgraded on the card the the motherboard network
controller disappears from lspci output and the bridge reports an x0
width link status instead of the x1 width previously shown with the
working configuration. Very odd.

Steve Kenton


LnkCap: Port #6, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s
<1us, L1 <16us
ClockPM- Surprise- LLActRep+ BwNot+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train+ SlotClk+ DLActive-
BWMgmt- ABWMgmt-

$ lspci -tv
-[:00]-+-00.0  Intel Corporation 4th Gen Core Processor DRAM Controller
   +-01.0-[01]00.0  Blackmagic Design Intensity Pro 4K
   +-02.0  Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor Integrated Graphics Controller
   +-03.0  Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor HD Audio Controller
   +-14.0  Intel Corporation 8 Series/C220 Series Chipset Family
USB xHCI
   +-1a.0  Intel Corporation 8 Series/C220 Series Chipset Family
USB EHCI #2
   +-1b.0  Intel Corporation 8 Series/C220 Series Chipset High
Definition Audio Controller
   +-1c.0-[02]--
   +-1c.5-[03]00.0  Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
   +-1d.0  Intel Corporation 8 Series/C220 Series Chipset Family
USB EHCI #1
   +-1f.0  Intel Corporation C220 Series Chipset Family H81
Express LPC Controller
   +-1f.2  Intel Corporation 8 Series/C220 Series Chipset Family
6-port SATA Controller 1 [AHCI mode]
   \-1f.3  Intel Corporation 8 Series/C220 Series Chipset Family
SMBus Controller

sudo lspci -s 1c.5 -xxx >lspcis1c5xxxgood.txt

00:1c.5 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #6 (rev d5)
00: 86 80 1a 8c 07 04 10 00 d5 00 04 06 10 00 81 00
10: 00 00 00 00 00 00 00 00 00 03 03 00 e0 e0 00 00
20: c0 f7 c0 f7 01 f0 01 f0 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 03 02 10 00
40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 32 06 ==> 06323C12:
LCAP@4Ch–4Fh = 0110 00 1 1 0 0 100 011 11 01 0010   
Port6
from 1 x2 and 2 x1s: Port 5 (x2), Port 7 (x1) and Port 8 (x1)
50: 40 00 11 70 00 b2 2c 00 00 00 40 00 08 00 00 00 ==> 7011:
LSTS@52h–53h = 01 1 1 0 0 01 0001 = x1 Negotiated Link Width NW
60: 00 00 00 00 17 08 00 00 00 04 00 00 00 00 00 00
70: 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 05 90 01 00 18 03 e0 fe 00 00 00 00 00 00 00 00
90: 0d a0 00 00 19 10 cf 7e 00 00 00 00 00 00 00 00
a0: 01 00 03 c8 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 01 42 18 00 00 08 80 11 0b 00 00 00 00
e0: 00 03 00 00 00 00 3c 88 11 00 00 00 00 00 00 00
f0: 50 00 00 00 40 00 00 0c b1 0f 06 08 b0 03 00 06 ==> 060003b0:
PECR4@FCh–FFh = 00 000110 00 00 0 000 00 00 00 11101100 00
Root Port Configuration 
Strap RPC_STRAP ???

File oem.bin is 8388608 bytes
FLMAP0:0x02040003
  NR:  2
  FRBA:0x40
  NC:  1
  FCBA:0x30
FLMAP1:0x15100206
  ISL: 0x15
  FPSBA:   0x100
  NM:  2
  FMBA:0x60
FLMAP2:

Intel H81 Chipset PCIe configuration question

[Steve Kenton]

A while back I posted about a motherboard network controller that
disappeared when the firmware on a PCIe card was upgraded which
converted the card from a 32-bit BAR to a 64-bit BAR. That seems to be a
BIOS bug rather than a kernel issue. But, I would really like to be able
to upgrade the systems in the field so I'm still chasing the BIOS issue
and I'm puzzled by a programming issue when configuring the PCIe
settings of the Intel 8-Series/C220 chipset. I'm hoping someone here can
shine a bit of light on it. The device of interest is the Realtek Lan at
1c.5 which is "Port6" in Intel nomencature.
http://www.intel.com/content/www/us/en/chipsets/8-series-chipset-pch-datasheet.html

The BIOS has an ME-Disable option so I disabled the Intel Management
Engine and then used flashrom to create an 8MB "oem.bin" image of the
bios. At the beginning of oem.bin is an SPI Flash Descriptor Signature
0FF0A55Ah so I used the coreboot ifdtool program to dump the SPI Flash
Descriptor information below. It appears to be both valid and sane. In
particular, soft strap 9 (PCHSTRP9:  0x30540580) looks like it sets all
the PCIe lanes to an x1 configuration. On the other hand "lspci -s 1c.5
xxx" shows the Link Capabilities Register (LCAP: 0x06323C12) which means
Port5 with x2 lanes, Port6 disabled and Ports7/8 (which do not exist on
the H81 SKU) as x1 lanes. This is the working configuration so something
strange is going on. To the best of my understanding it is not possible
to change the port width and override the soft strap settings in ROM by
rewriting any chipset registers. Anybody have any ideas how the BIOS
could be doing this?

After the firmware is upgraded on the card the the motherboard network
controller disappears from lspci output and the bridge reports an x0
width link status instead of the x1 width previously shown with the
working configuration. Very odd.

Steve Kenton


LnkCap: Port #6, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s
<1us, L1 <16us
ClockPM- Surprise- LLActRep+ BwNot+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train+ SlotClk+ DLActive-
BWMgmt- ABWMgmt-

$ lspci -tv
-[:00]-+-00.0  Intel Corporation 4th Gen Core Processor DRAM Controller
   +-01.0-[01]00.0  Blackmagic Design Intensity Pro 4K
   +-02.0  Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor Integrated Graphics Controller
   +-03.0  Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor HD Audio Controller
   +-14.0  Intel Corporation 8 Series/C220 Series Chipset Family
USB xHCI
   +-1a.0  Intel Corporation 8 Series/C220 Series Chipset Family
USB EHCI #2
   +-1b.0  Intel Corporation 8 Series/C220 Series Chipset High
Definition Audio Controller
   +-1c.0-[02]--
   +-1c.5-[03]00.0  Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
   +-1d.0  Intel Corporation 8 Series/C220 Series Chipset Family
USB EHCI #1
   +-1f.0  Intel Corporation C220 Series Chipset Family H81
Express LPC Controller
   +-1f.2  Intel Corporation 8 Series/C220 Series Chipset Family
6-port SATA Controller 1 [AHCI mode]
   \-1f.3  Intel Corporation 8 Series/C220 Series Chipset Family
SMBus Controller

sudo lspci -s 1c.5 -xxx >lspcis1c5xxxgood.txt

00:1c.5 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #6 (rev d5)
00: 86 80 1a 8c 07 04 10 00 d5 00 04 06 10 00 81 00
10: 00 00 00 00 00 00 00 00 00 03 03 00 e0 e0 00 00
20: c0 f7 c0 f7 01 f0 01 f0 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 03 02 10 00
40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 32 06 ==> 06323C12:
LCAP@4Ch–4Fh = 0110 00 1 1 0 0 100 011 11 01 0010   
Port6
from 1 x2 and 2 x1s: Port 5 (x2), Port 7 (x1) and Port 8 (x1)
50: 40 00 11 70 00 b2 2c 00 00 00 40 00 08 00 00 00 ==> 7011:
LSTS@52h–53h = 01 1 1 0 0 01 0001 = x1 Negotiated Link Width NW
60: 00 00 00 00 17 08 00 00 00 04 00 00 00 00 00 00
70: 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 05 90 01 00 18 03 e0 fe 00 00 00 00 00 00 00 00
90: 0d a0 00 00 19 10 cf 7e 00 00 00 00 00 00 00 00
a0: 01 00 03 c8 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 01 42 18 00 00 08 80 11 0b 00 00 00 00
e0: 00 03 00 00 00 00 3c 88 11 00 00 00 00 00 00 00
f0: 50 00 00 00 40 00 00 0c b1 0f 06 08 b0 03 00 06 ==> 060003b0:
PECR4@FCh–FFh = 00 000110 00 00 0 000 00 00 00 11101100 00
Root Port Configuration 
Strap RPC_STRAP ???

File oem.bin is 8388608 bytes
FLMAP0:0x02040003
  NR:  2
  FRBA:0x40
  NC:  1
  FCBA:0x30
FLMAP1:0x15100206
  ISL: 0x15
  FPSBA:   0x100
  NM:  2
  FMBA:0x60
FLMAP2:

Re: [PATCH] mm/hugetlb: Use the right pte val for compare in hugetlb_cow

[Aneesh Kumar K.V]

Andrew Morton  writes:

> On Tue, 18 Oct 2016 21:12:45 +0530 "Aneesh Kumar K.V" 
>  wrote:
>
>> We cannot use the pte value used in set_pte_at for pte_same comparison,
>> because archs like ppc64, filter/add new pte flag in set_pte_at. Instead
>> fetch the pte value inside hugetlb_cow. We are comparing pte value to
>> make sure the pte didn't change since we dropped the page table lock.
>> hugetlb_cow get called with page table lock held, and we can take a copy
>> of the pte value before we drop the page table lock.
>> 
>> With hugetlbfs, we optimize the MAP_PRIVATE write fault path with no
>> previous mapping (huge_pte_none entries), by forcing a cow in the fault
>> path. This avoid take an addition fault to covert a read-only mapping
>> to read/write. Here we were comparing a recently instantiated pte (via
>> set_pte_at) to the pte values from linux page table. As explained above
>> on ppc64 such pte_same check returned wrong result, resulting in us
>> taking an additional fault on ppc64.
>
> From my reading this is a minor performance improvement and a -stable
> backport isn't needed.  But it is unclear whether the impact warrants a
> 4.9 merge.

This patch workaround the issue reported at 
https://lkml.kernel.org/r/57ff7bb4.1070...@redhat.com
The reason for that OOM was a reserve count accounting issue which
happens in the error path of hugetlb_cow. Not this patch avoid us taking
the error path and hence we don't have the reported OOM.

An actual fix for that issue is being worked on by Mike Kravetz.

>
> Please be careful about describing end-user visible impacts when fixing
> bugs, thanks.

-aneesh

Re: [PATCH] mm/hugetlb: Use the right pte val for compare in hugetlb_cow

[Aneesh Kumar K.V]

Andrew Morton  writes:

> On Tue, 18 Oct 2016 21:12:45 +0530 "Aneesh Kumar K.V" 
>  wrote:
>
>> We cannot use the pte value used in set_pte_at for pte_same comparison,
>> because archs like ppc64, filter/add new pte flag in set_pte_at. Instead
>> fetch the pte value inside hugetlb_cow. We are comparing pte value to
>> make sure the pte didn't change since we dropped the page table lock.
>> hugetlb_cow get called with page table lock held, and we can take a copy
>> of the pte value before we drop the page table lock.
>> 
>> With hugetlbfs, we optimize the MAP_PRIVATE write fault path with no
>> previous mapping (huge_pte_none entries), by forcing a cow in the fault
>> path. This avoid take an addition fault to covert a read-only mapping
>> to read/write. Here we were comparing a recently instantiated pte (via
>> set_pte_at) to the pte values from linux page table. As explained above
>> on ppc64 such pte_same check returned wrong result, resulting in us
>> taking an additional fault on ppc64.
>
> From my reading this is a minor performance improvement and a -stable
> backport isn't needed.  But it is unclear whether the impact warrants a
> 4.9 merge.

This patch workaround the issue reported at 
https://lkml.kernel.org/r/57ff7bb4.1070...@redhat.com
The reason for that OOM was a reserve count accounting issue which
happens in the error path of hugetlb_cow. Not this patch avoid us taking
the error path and hence we don't have the reported OOM.

An actual fix for that issue is being worked on by Mike Kravetz.

>
> Please be careful about describing end-user visible impacts when fixing
> bugs, thanks.

-aneesh

Re: [lkp] [tcp] 3613b3dbd1: netpipe.bigger_5M_Mbps.avg -5.5% regression

[Eric Dumazet]

On Wed, Oct 19, 2016 at 3:54 AM, kernel test robot
 wrote:
>
> FYI, we noticed a -5.5% regression of netpipe.bigger_5M_Mbps.avg due to 
> commit:
>
> commit 3613b3dbd1ade9a6a626dae1f608c57638eb5e8a ("tcp: prepare skbs for 
> better sack shifting")
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> in testcase: netpipe
> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 4 -m 6G
> with following parameters:
>
> test: tcp
> cluster: cs-localhost
>
> NetPIPE is a protocol independent performance tool that encapsulates the best 
> of ttcp and netperf and visually represents the network performance under a 
> variety of conditions.
>
>
> Disclaimer:
> Results have been estimated based on internal Intel analysis and are provided
> for informational purposes only. Any difference in system hardware or software
> design or configuration may affect actual performance.
>
> Details are as below:
> -->
>
>
> To reproduce:
>
> git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml  # job file is attached in this email
> bin/lkp run job.yaml
>
> =
> cluster/compiler/kconfig/rootfs/tbox_group/test/testcase:
>   
> cs-localhost/gcc-6/x86_64-rhel-7.2/debian-x86_64-2016-08-31.cgz/vm-lkp-a08/tcp/netpipe
>
> commit:
>   e812bd905a (" wireless-drivers-next patches for 4.9")
>   3613b3dbd1 ("tcp: prepare skbs for better sack shifting")
>
> e812bd905a5cf00f 3613b3dbd1ade9a6a626dae1f6
>  --
>fail:runs  %reproductionfail:runs
>| | |
>  %stddev %change %stddev
>  \  |\
>   2427 ą  0%  -5.5%   2294 ą  0%  netpipe.bigger_5M_Mbps.avg
>   1764 ą  1%  +5.0%   1853 ą  0%  netpipe.time.elapsed_time
>   1764 ą  1%  +5.0%   1853 ą  0%  netpipe.time.elapsed_time.max
>  84.75 ą  0%  -2.1%  83.00 ą  0%  
> netpipe.time.percent_of_cpu_this_job_got
>   1497 ą  1%  +3.2%   1546 ą  0%  netpipe.time.system_time
>1378335 ą  1% +28.6%1772455 ą  1%  
> netpipe.time.voluntary_context_switches
>  14140 ą  3%  +6.6%  15079 ą  2%  
> interrupts.CAL:Function_call_interrupts
> 393.25 ą  2% -29.1% 279.00 ą  2%  
> slabinfo.kmalloc-2048.active_objs
> 412.00 ą  1% -32.3% 279.00 ą  2%  slabinfo.kmalloc-2048.num_objs
>   4069 ą  0% +17.5%   4779 ą  0%  vmstat.system.cs
>   2961 ą  0%  +5.3%   3118 ą  0%  vmstat.system.in
> 229439 ą 94%   +6926.4%   16121408 ą172%  latency_stats.avg.max
> 141971 ą160%  +11239.9%   16099418 ą172%  
> latency_stats.avg.nfs_wait_on_request.nfs_writepage_setup.nfs_updatepage.nfs_write_end.generic_perform_write.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
>  90183 ą153% -55.4%  40178 ą 84%  
> latency_stats.avg.proc_cgroup_show.proc_single_show.seq_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
> 839.25 ą 21%   +1114.0%  10188 ą125%  
> latency_stats.avg.rpc_wait_bit_killable.__rpc_execute.rpc_execute.rpc_run_task.nfs4_call_sync_sequence.[nfsv4]._nfs4_proc_lookup.[nfsv4].nfs4_proc_lookup_common.[nfsv4].nfs4_proc_lookup.[nfsv4].nfs_lookup.lookup_slow.walk_component.path_lookupat
> 414419 ą 86%   +7661.1%   32163484 ą172%  latency_stats.max.max
> 257867 ą166%  +12362.7%   32137192 ą172%  
> latency_stats.max.nfs_wait_on_request.nfs_writepage_setup.nfs_updatepage.nfs_write_end.generic_perform_write.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
>  81137 ą155% -94.7%   4265 ą 45%  
> latency_stats.max.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
>  90183 ą153% -55.4%  40178 ą 84%  
> latency_stats.max.proc_cgroup_show.proc_single_show.seq_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
> 839.25 ą 21%   +1114.0%  10188 ą125%  
> latency_stats.max.rpc_wait_bit_killable.__rpc_execute.rpc_execute.rpc_run_task.nfs4_call_sync_sequence.[nfsv4]._nfs4_proc_lookup.[nfsv4].nfs4_proc_lookup_common.[nfsv4].nfs4_proc_lookup.[nfsv4].nfs_lookup.lookup_slow.walk_component.path_lookupat
>   6232 ą 87%-100.0%   0.00 ą -1%  
> latency_stats.sum.call_rwsem_down_read_failed.__do_page_fault.trace_do_page_fault.do_async_page_fault.async_page_fault.skb_copy_datagram_iter.tcp_rcv_established.tcp_v4_do_rcv.tcp_prequeue_process.tcp_recvmsg.inet_recvmsg.sock_recvmsg
>   1107 ą 62%+964.9%  11788 ą 55%  
> latency_stats.sum.call_rwsem_down_read_failed.proc_pid_cmdline_read.__vfs_read.vfs_read.SyS_read.do_syscall_64.return_from_SYSCALL_64
> 276091 

Re: [lkp] [tcp] 3613b3dbd1: netpipe.bigger_5M_Mbps.avg -5.5% regression

[Eric Dumazet]

On Wed, Oct 19, 2016 at 3:54 AM, kernel test robot
 wrote:
>
> FYI, we noticed a -5.5% regression of netpipe.bigger_5M_Mbps.avg due to 
> commit:
>
> commit 3613b3dbd1ade9a6a626dae1f608c57638eb5e8a ("tcp: prepare skbs for 
> better sack shifting")
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> in testcase: netpipe
> on test machine: qemu-system-x86_64 -enable-kvm -cpu host -smp 4 -m 6G
> with following parameters:
>
> test: tcp
> cluster: cs-localhost
>
> NetPIPE is a protocol independent performance tool that encapsulates the best 
> of ttcp and netperf and visually represents the network performance under a 
> variety of conditions.
>
>
> Disclaimer:
> Results have been estimated based on internal Intel analysis and are provided
> for informational purposes only. Any difference in system hardware or software
> design or configuration may affect actual performance.
>
> Details are as below:
> -->
>
>
> To reproduce:
>
> git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml  # job file is attached in this email
> bin/lkp run job.yaml
>
> =
> cluster/compiler/kconfig/rootfs/tbox_group/test/testcase:
>   
> cs-localhost/gcc-6/x86_64-rhel-7.2/debian-x86_64-2016-08-31.cgz/vm-lkp-a08/tcp/netpipe
>
> commit:
>   e812bd905a (" wireless-drivers-next patches for 4.9")
>   3613b3dbd1 ("tcp: prepare skbs for better sack shifting")
>
> e812bd905a5cf00f 3613b3dbd1ade9a6a626dae1f6
>  --
>fail:runs  %reproductionfail:runs
>| | |
>  %stddev %change %stddev
>  \  |\
>   2427 ą  0%  -5.5%   2294 ą  0%  netpipe.bigger_5M_Mbps.avg
>   1764 ą  1%  +5.0%   1853 ą  0%  netpipe.time.elapsed_time
>   1764 ą  1%  +5.0%   1853 ą  0%  netpipe.time.elapsed_time.max
>  84.75 ą  0%  -2.1%  83.00 ą  0%  
> netpipe.time.percent_of_cpu_this_job_got
>   1497 ą  1%  +3.2%   1546 ą  0%  netpipe.time.system_time
>1378335 ą  1% +28.6%1772455 ą  1%  
> netpipe.time.voluntary_context_switches
>  14140 ą  3%  +6.6%  15079 ą  2%  
> interrupts.CAL:Function_call_interrupts
> 393.25 ą  2% -29.1% 279.00 ą  2%  
> slabinfo.kmalloc-2048.active_objs
> 412.00 ą  1% -32.3% 279.00 ą  2%  slabinfo.kmalloc-2048.num_objs
>   4069 ą  0% +17.5%   4779 ą  0%  vmstat.system.cs
>   2961 ą  0%  +5.3%   3118 ą  0%  vmstat.system.in
> 229439 ą 94%   +6926.4%   16121408 ą172%  latency_stats.avg.max
> 141971 ą160%  +11239.9%   16099418 ą172%  
> latency_stats.avg.nfs_wait_on_request.nfs_writepage_setup.nfs_updatepage.nfs_write_end.generic_perform_write.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
>  90183 ą153% -55.4%  40178 ą 84%  
> latency_stats.avg.proc_cgroup_show.proc_single_show.seq_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
> 839.25 ą 21%   +1114.0%  10188 ą125%  
> latency_stats.avg.rpc_wait_bit_killable.__rpc_execute.rpc_execute.rpc_run_task.nfs4_call_sync_sequence.[nfsv4]._nfs4_proc_lookup.[nfsv4].nfs4_proc_lookup_common.[nfsv4].nfs4_proc_lookup.[nfsv4].nfs_lookup.lookup_slow.walk_component.path_lookupat
> 414419 ą 86%   +7661.1%   32163484 ą172%  latency_stats.max.max
> 257867 ą166%  +12362.7%   32137192 ą172%  
> latency_stats.max.nfs_wait_on_request.nfs_writepage_setup.nfs_updatepage.nfs_write_end.generic_perform_write.nfs_file_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
>  81137 ą155% -94.7%   4265 ą 45%  
> latency_stats.max.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
>  90183 ą153% -55.4%  40178 ą 84%  
> latency_stats.max.proc_cgroup_show.proc_single_show.seq_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
> 839.25 ą 21%   +1114.0%  10188 ą125%  
> latency_stats.max.rpc_wait_bit_killable.__rpc_execute.rpc_execute.rpc_run_task.nfs4_call_sync_sequence.[nfsv4]._nfs4_proc_lookup.[nfsv4].nfs4_proc_lookup_common.[nfsv4].nfs4_proc_lookup.[nfsv4].nfs_lookup.lookup_slow.walk_component.path_lookupat
>   6232 ą 87%-100.0%   0.00 ą -1%  
> latency_stats.sum.call_rwsem_down_read_failed.__do_page_fault.trace_do_page_fault.do_async_page_fault.async_page_fault.skb_copy_datagram_iter.tcp_rcv_established.tcp_v4_do_rcv.tcp_prequeue_process.tcp_recvmsg.inet_recvmsg.sock_recvmsg
>   1107 ą 62%+964.9%  11788 ą 55%  
> latency_stats.sum.call_rwsem_down_read_failed.proc_pid_cmdline_read.__vfs_read.vfs_read.SyS_read.do_syscall_64.return_from_SYSCALL_64
> 276091 ą166%  +11542.5%   

Re: [PATCH 4/4] i2c: digicolor: Fix module autoload

[Baruch Siach]

Hi Javier Martinez Canillas,

On Tue, Oct 18, 2016 at 06:01:48PM -0300, Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
> 
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
> 
> Before this patch:
> 
> $ modinfo drivers/i2c/busses/i2c-digicolor.ko | grep alias
> $
> 
> After this patch:
> 
> $ modinfo drivers/i2c/busses/i2c-digicolor.ko | grep alias
> alias:  of:N*T*Ccnxt,cx92755-i2cC*
> alias:  of:N*T*Ccnxt,cx92755-i2c
> 
> Signed-off-by: Javier Martinez Canillas 

Acked-by: Baruch Siach 

Thanks,
baruch

>  drivers/i2c/busses/i2c-digicolor.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/i2c/busses/i2c-digicolor.c 
> b/drivers/i2c/busses/i2c-digicolor.c
> index 9604024e0eb0..49f2084f7bb5 100644
> --- a/drivers/i2c/busses/i2c-digicolor.c
> +++ b/drivers/i2c/busses/i2c-digicolor.c
> @@ -368,6 +368,7 @@ static const struct of_device_id dc_i2c_match[] = {
>   { .compatible = "cnxt,cx92755-i2c" },
>   { },
>  };
> +MODULE_DEVICE_TABLE(of, dc_i2c_match);
>  
>  static struct platform_driver dc_i2c_driver = {
>   .probe   = dc_i2c_probe,

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

Re: [PATCH 4/4] i2c: digicolor: Fix module autoload

[Baruch Siach]

Hi Javier Martinez Canillas,

On Tue, Oct 18, 2016 at 06:01:48PM -0300, Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
> 
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
> 
> Before this patch:
> 
> $ modinfo drivers/i2c/busses/i2c-digicolor.ko | grep alias
> $
> 
> After this patch:
> 
> $ modinfo drivers/i2c/busses/i2c-digicolor.ko | grep alias
> alias:  of:N*T*Ccnxt,cx92755-i2cC*
> alias:  of:N*T*Ccnxt,cx92755-i2c
> 
> Signed-off-by: Javier Martinez Canillas 

Acked-by: Baruch Siach 

Thanks,
baruch

>  drivers/i2c/busses/i2c-digicolor.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/i2c/busses/i2c-digicolor.c 
> b/drivers/i2c/busses/i2c-digicolor.c
> index 9604024e0eb0..49f2084f7bb5 100644
> --- a/drivers/i2c/busses/i2c-digicolor.c
> +++ b/drivers/i2c/busses/i2c-digicolor.c
> @@ -368,6 +368,7 @@ static const struct of_device_id dc_i2c_match[] = {
>   { .compatible = "cnxt,cx92755-i2c" },
>   { },
>  };
> +MODULE_DEVICE_TABLE(of, dc_i2c_match);
>  
>  static struct platform_driver dc_i2c_driver = {
>   .probe   = dc_i2c_probe,

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[PATCH 2/5] selftests: ftrace: Fix test cases to enable tracing

[Masami Hiramatsu]

Fix some test cases to enable tracing before starting
trace test. This can avoid false-positive failure when
previous testcase fails while disabling tracing.

Signed-off-by: Masami Hiramatsu 
---
 .../selftests/ftrace/test.d/event/event-enable.tc  |1 +
 .../selftests/ftrace/test.d/event/event-pid.tc |1 +
 .../ftrace/test.d/event/subsystem-enable.tc|1 +
 .../ftrace/test.d/event/toplevel-enable.tc |1 +
 .../ftrace/test.d/ftrace/func_profiler.tc  |1 +
 .../ftrace/test.d/kprobe/kprobe_ftrace.tc  |1 +
 6 files changed, 6 insertions(+)

diff --git a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc 
b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
index 87eb9d6..ee7ea0a 100644
--- a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
@@ -23,6 +23,7 @@ fi
 
 reset_tracer
 do_reset
+enable_tracing
 
 echo 'sched:sched_switch' > set_event
 
diff --git a/tools/testing/selftests/ftrace/test.d/event/event-pid.tc 
b/tools/testing/selftests/ftrace/test.d/event/event-pid.tc
index d4ab27b..1477e5e 100644
--- a/tools/testing/selftests/ftrace/test.d/event/event-pid.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/event-pid.tc
@@ -30,6 +30,7 @@ fi
 
 reset_tracer
 do_reset
+enable_tracing
 
 echo 1 > events/sched/sched_switch/enable
 
diff --git a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc 
b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
index ced27ef..f4a64f9 100644
--- a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
@@ -23,6 +23,7 @@ fi
 
 reset_tracer
 do_reset
+enable_tracing
 
 echo 'sched:*' > set_event
 
diff --git a/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc 
b/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc
index 0bb5df3..037a82e 100644
--- a/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc
@@ -23,6 +23,7 @@ fi
 
 reset_tracer
 do_reset
+enable_tracing
 
 echo '*:*' > set_event
 
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc 
b/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc
index 7808336..d10d6e0 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc
@@ -36,6 +36,7 @@ fail() { # mesg
 
 echo "Testing function tracer with profiler:"
 echo "enable function tracer"
+enable_tracing
 echo function > current_tracer
 echo "enable profiler"
 echo 1 > function_profile_enabled
diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_ftrace.tc 
b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_ftrace.tc
index d6f2f49..bdbd385 100644
--- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_ftrace.tc
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_ftrace.tc
@@ -10,6 +10,7 @@ echo _do_fork > set_ftrace_filter
 echo 0 > events/enable
 echo > kprobe_events
 echo 'p:testprobe _do_fork' > kprobe_events
+enable_tracing
 
 # kprobe on / ftrace off
 echo 1 > events/kprobes/testprobe/enable

[PATCH 5/5] selftests: ftrace: Add a testcase for types of kprobe event

[Masami Hiramatsu]

Add a testcase for types of kprobe event. This checks
kprobe event can accept and correctly expressed the
arguments typed as s32, u32, x32 and bitfield.

Here is the test result.
  -
  # ./ftracetest test.d/kprobe/kprobe_args_type.tc
  === Ftrace unit tests ===
  [1] Kprobes event arguments with types[PASS]

  # of passed:  1
  # of failed:  0
  # of unresolved:  0
  # of untested:  0
  # of unsupported:  0
  # of xfailed:  0
  # of undefined(test bug):  0
-

Signed-off-by: Masami Hiramatsu 
---
 .../ftrace/test.d/kprobe/kprobe_args_type.tc   |   37 
 1 file changed, 37 insertions(+)
 create mode 100644 
tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc

diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc 
b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc
new file mode 100644
index 000..0a78705
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc
@@ -0,0 +1,37 @@
+#!/bin/sh
+# description: Kprobes event arguments with types
+
+[ -f kprobe_events ] || exit_unsupported # this is configurable
+
+grep "x8/16/32/64" README > /dev/null || exit_unsupported # version issue
+
+echo 0 > events/enable
+echo > kprobe_events
+enable_tracing
+
+echo 'p:testprobe _do_fork $stack0:s32 $stack0:u32 $stack0:x32 
$stack0:b8@4/32' > kprobe_events
+grep testprobe kprobe_events
+test -d events/kprobes/testprobe
+
+echo 1 > events/kprobes/testprobe/enable
+( echo "forked")
+echo 0 > events/kprobes/testprobe/enable
+ARGS=`tail -n 1 trace | sed -e 's/.* arg1=\(.*\) arg2=\(.*\) arg3=\(.*\) 
arg4=\(.*\)/\1 \2 \3 \4/'`
+
+check_types() {
+  X1=`printf "%x" $1 | tail -c 8`
+  X2=`printf "%x" $2`
+  X3=`printf "%x" $3`
+  test $X1 = $X2
+  test $X2 = $X3
+  test 0x$X3 = $3
+
+  B4=`printf "%x" $4`
+  B3=`echo -n $X3 | tail -c 3 | head -c 2`
+  test $B3 = $B4
+}
+check_types $ARGS
+
+echo "-:testprobe" >> kprobe_events
+clear_trace
+test -d events/kprobes/testprobe && exit 1 || exit 0

[PATCH 4/5] selftests: ftrace: Add a testcase for function filter glob match

[Masami Hiramatsu]

Add function filter glob matching test case.
This checks whether the kernel supports glob matching
(front match, end match, middle match, side match,
character class and '?').

Here is the test result.
  -
  ./ftracetest test.d/ftrace/func-filter-glob.tc
  === Ftrace unit tests ===
  [1] ftrace - function glob filters[PASS]

  # of passed:  1
  # of failed:  0
  # of unresolved:  0
  # of untested:  0
  # of unsupported:  0
  # of xfailed:  0
  # of undefined(test bug):  0
  -

Signed-off-by: Masami Hiramatsu 
---
 .../ftrace/test.d/ftrace/func-filter-glob.tc   |   49 
 1 file changed, 49 insertions(+)
 create mode 100644 
tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc

diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc 
b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
new file mode 100644
index 000..9dcd0ca
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
@@ -0,0 +1,49 @@
+#!/bin/sh
+# description: ftrace - function glob filters
+
+# Make sure that function glob matching filter works.
+
+if ! grep -q function available_tracers; then
+echo "no function tracer configured"
+exit_unsupported
+fi
+
+disable_tracing
+clear_trace
+
+# filter by ?, schedule is always good
+if ! echo "sch?dule" > set_ftrace_filter; then
+# test for powerpc 64
+if ! echo ".sch?dule" > set_ftrace_filter; then
+   fail "can not enable schedule filter"
+fi
+cat set_ftrace_filter | grep '^.schedule$'
+else
+cat set_ftrace_filter | grep '^schedule$'
+fi
+
+ftrace_filter_check() { # glob grep
+  echo "$1" > set_ftrace_filter
+  cut -f1 -d" " set_ftrace_filter > $TMPDIR/actual
+  cut -f1 -d" " available_filter_functions | grep "$2" > $TMPDIR/expected
+  DIFF=`diff $TMPDIR/actual $TMPDIR/expected`
+  test -z "$DIFF"
+}
+
+# filter by *, front match
+ftrace_filter_check '*schedule' '^.*schedule$'
+
+# filter by *, middle match
+ftrace_filter_check '*schedule*' '^.*schedule.*$'
+
+# filter by *, end match
+ftrace_filter_check 'schedule*' '^schedule.*$'
+
+# filter by *, both side match
+ftrace_filter_check 'sch*ule' '^sch.*ule$'
+
+# filter by char class.
+ftrace_filter_check '[Ss]y[Ss]_*' '^[Ss]y[Ss]_.*$'
+
+echo > set_ftrace_filter
+enable_tracing

[PATCH 2/5] selftests: ftrace: Fix test cases to enable tracing

[Masami Hiramatsu]

Fix some test cases to enable tracing before starting
trace test. This can avoid false-positive failure when
previous testcase fails while disabling tracing.

Signed-off-by: Masami Hiramatsu 
---
 .../selftests/ftrace/test.d/event/event-enable.tc  |1 +
 .../selftests/ftrace/test.d/event/event-pid.tc |1 +
 .../ftrace/test.d/event/subsystem-enable.tc|1 +
 .../ftrace/test.d/event/toplevel-enable.tc |1 +
 .../ftrace/test.d/ftrace/func_profiler.tc  |1 +
 .../ftrace/test.d/kprobe/kprobe_ftrace.tc  |1 +
 6 files changed, 6 insertions(+)

diff --git a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc 
b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
index 87eb9d6..ee7ea0a 100644
--- a/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/event-enable.tc
@@ -23,6 +23,7 @@ fi
 
 reset_tracer
 do_reset
+enable_tracing
 
 echo 'sched:sched_switch' > set_event
 
diff --git a/tools/testing/selftests/ftrace/test.d/event/event-pid.tc 
b/tools/testing/selftests/ftrace/test.d/event/event-pid.tc
index d4ab27b..1477e5e 100644
--- a/tools/testing/selftests/ftrace/test.d/event/event-pid.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/event-pid.tc
@@ -30,6 +30,7 @@ fi
 
 reset_tracer
 do_reset
+enable_tracing
 
 echo 1 > events/sched/sched_switch/enable
 
diff --git a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc 
b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
index ced27ef..f4a64f9 100644
--- a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc
@@ -23,6 +23,7 @@ fi
 
 reset_tracer
 do_reset
+enable_tracing
 
 echo 'sched:*' > set_event
 
diff --git a/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc 
b/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc
index 0bb5df3..037a82e 100644
--- a/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc
@@ -23,6 +23,7 @@ fi
 
 reset_tracer
 do_reset
+enable_tracing
 
 echo '*:*' > set_event
 
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc 
b/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc
index 7808336..d10d6e0 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc
@@ -36,6 +36,7 @@ fail() { # mesg
 
 echo "Testing function tracer with profiler:"
 echo "enable function tracer"
+enable_tracing
 echo function > current_tracer
 echo "enable profiler"
 echo 1 > function_profile_enabled
diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_ftrace.tc 
b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_ftrace.tc
index d6f2f49..bdbd385 100644
--- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_ftrace.tc
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_ftrace.tc
@@ -10,6 +10,7 @@ echo _do_fork > set_ftrace_filter
 echo 0 > events/enable
 echo > kprobe_events
 echo 'p:testprobe _do_fork' > kprobe_events
+enable_tracing
 
 # kprobe on / ftrace off
 echo 1 > events/kprobes/testprobe/enable

[PATCH 5/5] selftests: ftrace: Add a testcase for types of kprobe event

[Masami Hiramatsu]

Add a testcase for types of kprobe event. This checks
kprobe event can accept and correctly expressed the
arguments typed as s32, u32, x32 and bitfield.

Here is the test result.
  -
  # ./ftracetest test.d/kprobe/kprobe_args_type.tc
  === Ftrace unit tests ===
  [1] Kprobes event arguments with types[PASS]

  # of passed:  1
  # of failed:  0
  # of unresolved:  0
  # of untested:  0
  # of unsupported:  0
  # of xfailed:  0
  # of undefined(test bug):  0
-

Signed-off-by: Masami Hiramatsu 
---
 .../ftrace/test.d/kprobe/kprobe_args_type.tc   |   37 
 1 file changed, 37 insertions(+)
 create mode 100644 
tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc

diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc 
b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc
new file mode 100644
index 000..0a78705
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc
@@ -0,0 +1,37 @@
+#!/bin/sh
+# description: Kprobes event arguments with types
+
+[ -f kprobe_events ] || exit_unsupported # this is configurable
+
+grep "x8/16/32/64" README > /dev/null || exit_unsupported # version issue
+
+echo 0 > events/enable
+echo > kprobe_events
+enable_tracing
+
+echo 'p:testprobe _do_fork $stack0:s32 $stack0:u32 $stack0:x32 
$stack0:b8@4/32' > kprobe_events
+grep testprobe kprobe_events
+test -d events/kprobes/testprobe
+
+echo 1 > events/kprobes/testprobe/enable
+( echo "forked")
+echo 0 > events/kprobes/testprobe/enable
+ARGS=`tail -n 1 trace | sed -e 's/.* arg1=\(.*\) arg2=\(.*\) arg3=\(.*\) 
arg4=\(.*\)/\1 \2 \3 \4/'`
+
+check_types() {
+  X1=`printf "%x" $1 | tail -c 8`
+  X2=`printf "%x" $2`
+  X3=`printf "%x" $3`
+  test $X1 = $X2
+  test $X2 = $X3
+  test 0x$X3 = $3
+
+  B4=`printf "%x" $4`
+  B3=`echo -n $X3 | tail -c 3 | head -c 2`
+  test $B3 = $B4
+}
+check_types $ARGS
+
+echo "-:testprobe" >> kprobe_events
+clear_trace
+test -d events/kprobes/testprobe && exit 1 || exit 0

[PATCH 4/5] selftests: ftrace: Add a testcase for function filter glob match

[Masami Hiramatsu]

Add function filter glob matching test case.
This checks whether the kernel supports glob matching
(front match, end match, middle match, side match,
character class and '?').

Here is the test result.
  -
  ./ftracetest test.d/ftrace/func-filter-glob.tc
  === Ftrace unit tests ===
  [1] ftrace - function glob filters[PASS]

  # of passed:  1
  # of failed:  0
  # of unresolved:  0
  # of untested:  0
  # of unsupported:  0
  # of xfailed:  0
  # of undefined(test bug):  0
  -

Signed-off-by: Masami Hiramatsu 
---
 .../ftrace/test.d/ftrace/func-filter-glob.tc   |   49 
 1 file changed, 49 insertions(+)
 create mode 100644 
tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc

diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc 
b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
new file mode 100644
index 000..9dcd0ca
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
@@ -0,0 +1,49 @@
+#!/bin/sh
+# description: ftrace - function glob filters
+
+# Make sure that function glob matching filter works.
+
+if ! grep -q function available_tracers; then
+echo "no function tracer configured"
+exit_unsupported
+fi
+
+disable_tracing
+clear_trace
+
+# filter by ?, schedule is always good
+if ! echo "sch?dule" > set_ftrace_filter; then
+# test for powerpc 64
+if ! echo ".sch?dule" > set_ftrace_filter; then
+   fail "can not enable schedule filter"
+fi
+cat set_ftrace_filter | grep '^.schedule$'
+else
+cat set_ftrace_filter | grep '^schedule$'
+fi
+
+ftrace_filter_check() { # glob grep
+  echo "$1" > set_ftrace_filter
+  cut -f1 -d" " set_ftrace_filter > $TMPDIR/actual
+  cut -f1 -d" " available_filter_functions | grep "$2" > $TMPDIR/expected
+  DIFF=`diff $TMPDIR/actual $TMPDIR/expected`
+  test -z "$DIFF"
+}
+
+# filter by *, front match
+ftrace_filter_check '*schedule' '^.*schedule$'
+
+# filter by *, middle match
+ftrace_filter_check '*schedule*' '^.*schedule.*$'
+
+# filter by *, end match
+ftrace_filter_check 'schedule*' '^schedule.*$'
+
+# filter by *, both side match
+ftrace_filter_check 'sch*ule' '^sch.*ule$'
+
+# filter by char class.
+ftrace_filter_check '[Ss]y[Ss]_*' '^[Ss]y[Ss]_.*$'
+
+echo > set_ftrace_filter
+enable_tracing

[PATCH 3/5] selftests: ftrace: Introduce TMPDIR for temporary files

[Masami Hiramatsu]

Introduce TMPDIR variable which is removed after each test
is done, so that the test script can put their temporary
files in that.

Signed-off-by: Masami Hiramatsu 
---
 tools/testing/selftests/ftrace/ftracetest |2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/testing/selftests/ftrace/ftracetest 
b/tools/testing/selftests/ftrace/ftracetest
index 4c6a0bf..172750f 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -236,6 +236,7 @@ __run_test() { # testfile
 run_test() { # testfile
   local testname=`basename $1`
   local testlog=`mktemp $LOG_DIR/${testname}-log.XX`
+  export TMPDIR=`mktemp -d /tmp/ftracetest-dir.XX`
   testcase $1
   echo "execute: "$1 > $testlog
   SIG_RESULT=0
@@ -252,6 +253,7 @@ run_test() { # testfile
 catlog $testlog
 TOTAL_RESULT=1
   fi
+  rm -rf $TMPDIR
 }
 
 # load in the helper functions

[PATCH 1/5] ftrace: Support full glob matching

[Masami Hiramatsu]

Use glob_match() to support flexible glob wildcards (*,?)
and character classes ([) for ftrace.
Since the full glob matching is slower than the current
partial matching routines(*pat, pat*, *pat*), this leaves
those routines and just add MATCH_GLOB for complex glob
expression.

e.g.

[root@localhost tracing]# echo 'sched*group' > set_ftrace_filter
[root@localhost tracing]# cat set_ftrace_filter
sched_free_group
sched_change_group
sched_create_group
sched_online_group
sched_destroy_group
sched_offline_group
[root@localhost tracing]# echo '[Ss]y[Ss]_*' > set_ftrace_filter
[root@localhost tracing]# head set_ftrace_filter
sys_arch_prctl
sys_rt_sigreturn
sys_ioperm
SyS_iopl
sys_modify_ldt
SyS_mmap
SyS_set_thread_area
SyS_get_thread_area
SyS_set_tid_address
sys_fork


Signed-off-by: Masami Hiramatsu 
---
 Documentation/trace/events.txt |9 +++--
 Documentation/trace/ftrace.txt |9 +++--
 kernel/trace/Kconfig   |2 ++
 kernel/trace/ftrace.c  |4 
 kernel/trace/trace.c   |2 +-
 kernel/trace/trace.h   |2 ++
 kernel/trace/trace_events_filter.c |   17 -
 7 files changed, 31 insertions(+), 14 deletions(-)

diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt
index 08d74d7..2cc08d4 100644
--- a/Documentation/trace/events.txt
+++ b/Documentation/trace/events.txt
@@ -189,16 +189,13 @@ And for string fields they are:
 
 ==, !=, ~
 
-The glob (~) only accepts a wild card character (*) at the start and or
-end of the string. For example:
+The glob (~) accepts a wild card character (*,?) and character classes
+([). For example:
 
   prev_comm ~ "*sh"
   prev_comm ~ "sh*"
   prev_comm ~ "*sh*"
-
-But does not allow for it to be within the string:
-
-  prev_comm ~ "ba*sh"   <-- is invalid
+  prev_comm ~ "ba*sh"
 
 5.2 Setting filters
 ---
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index a6b3705..b26abc7 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -2218,16 +2218,13 @@ hrtimer_interrupt
 sys_nanosleep
 
 
-Perhaps this is not enough. The filters also allow simple wild
-cards. Only the following are currently available
+Perhaps this is not enough. The filters also allow glob(7) matching.
 
   *  - will match functions that begin with 
   *  - will match functions that end with 
   ** - will match functions that have  in it
-
-These are the only wild cards which are supported.
-
-  * will not work.
+  * - will match functions that begin with
+   and end with 
 
 Note: It is better to use quotes to enclose the wild cards,
   otherwise the shell may expand the parameters into names
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index ba33267..aa6eb15 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -70,6 +70,7 @@ config FTRACE_NMI_ENTER
 
 config EVENT_TRACING
select CONTEXT_SWITCH_TRACER
+select GLOB
bool
 
 config CONTEXT_SWITCH_TRACER
@@ -133,6 +134,7 @@ config FUNCTION_TRACER
select KALLSYMS
select GENERIC_TRACER
select CONTEXT_SWITCH_TRACER
+select GLOB
help
  Enable the kernel to trace every kernel function. This is done
  by using a compiler feature to insert a small, 5-byte No-Operation
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 84752c8..5741184 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3493,6 +3493,10 @@ static int ftrace_match(char *str, struct ftrace_glob *g)
memcmp(str + slen - g->len, g->search, g->len) == 0)
matched = 1;
break;
+   case MATCH_GLOB:
+   if (glob_match(g->search, str))
+   matched = 1;
+   break;
}
 
return matched;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 37824d9..ae343e7 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4065,7 +4065,7 @@ static const char readme_msg[] =
"\n  available_filter_functions - list of functions that can be 
filtered on\n"
"  set_ftrace_filter\t- echo function name in here to only trace 
these\n"
"\t\t\t  functions\n"
-   "\t accepts: func_full_name, *func_end, func_begin*, 
*func_middle*\n"
+   "\t accepts: func_full_name or glob-matching-pattern\n"
"\t modules: Can select a group via module\n"
"\t  Format: :mod:\n"
"\t example: echo :mod:ext3 > set_ftrace_filter\n"
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index f783df4..eac2eda 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_FTRACE_SYSCALLS
 #include /* For NR_SYSCALLS   */
@@ -1252,6 +1253,7 @@ enum regex_type {
MATCH_FRONT_ONLY,

[PATCH 3/5] selftests: ftrace: Introduce TMPDIR for temporary files

[Masami Hiramatsu]

Introduce TMPDIR variable which is removed after each test
is done, so that the test script can put their temporary
files in that.

Signed-off-by: Masami Hiramatsu 
---
 tools/testing/selftests/ftrace/ftracetest |2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/testing/selftests/ftrace/ftracetest 
b/tools/testing/selftests/ftrace/ftracetest
index 4c6a0bf..172750f 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -236,6 +236,7 @@ __run_test() { # testfile
 run_test() { # testfile
   local testname=`basename $1`
   local testlog=`mktemp $LOG_DIR/${testname}-log.XX`
+  export TMPDIR=`mktemp -d /tmp/ftracetest-dir.XX`
   testcase $1
   echo "execute: "$1 > $testlog
   SIG_RESULT=0
@@ -252,6 +253,7 @@ run_test() { # testfile
 catlog $testlog
 TOTAL_RESULT=1
   fi
+  rm -rf $TMPDIR
 }
 
 # load in the helper functions

[PATCH 1/5] ftrace: Support full glob matching

[Masami Hiramatsu]

Use glob_match() to support flexible glob wildcards (*,?)
and character classes ([) for ftrace.
Since the full glob matching is slower than the current
partial matching routines(*pat, pat*, *pat*), this leaves
those routines and just add MATCH_GLOB for complex glob
expression.

e.g.

[root@localhost tracing]# echo 'sched*group' > set_ftrace_filter
[root@localhost tracing]# cat set_ftrace_filter
sched_free_group
sched_change_group
sched_create_group
sched_online_group
sched_destroy_group
sched_offline_group
[root@localhost tracing]# echo '[Ss]y[Ss]_*' > set_ftrace_filter
[root@localhost tracing]# head set_ftrace_filter
sys_arch_prctl
sys_rt_sigreturn
sys_ioperm
SyS_iopl
sys_modify_ldt
SyS_mmap
SyS_set_thread_area
SyS_get_thread_area
SyS_set_tid_address
sys_fork


Signed-off-by: Masami Hiramatsu 
---
 Documentation/trace/events.txt |9 +++--
 Documentation/trace/ftrace.txt |9 +++--
 kernel/trace/Kconfig   |2 ++
 kernel/trace/ftrace.c  |4 
 kernel/trace/trace.c   |2 +-
 kernel/trace/trace.h   |2 ++
 kernel/trace/trace_events_filter.c |   17 -
 7 files changed, 31 insertions(+), 14 deletions(-)

diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt
index 08d74d7..2cc08d4 100644
--- a/Documentation/trace/events.txt
+++ b/Documentation/trace/events.txt
@@ -189,16 +189,13 @@ And for string fields they are:
 
 ==, !=, ~
 
-The glob (~) only accepts a wild card character (*) at the start and or
-end of the string. For example:
+The glob (~) accepts a wild card character (*,?) and character classes
+([). For example:
 
   prev_comm ~ "*sh"
   prev_comm ~ "sh*"
   prev_comm ~ "*sh*"
-
-But does not allow for it to be within the string:
-
-  prev_comm ~ "ba*sh"   <-- is invalid
+  prev_comm ~ "ba*sh"
 
 5.2 Setting filters
 ---
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index a6b3705..b26abc7 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -2218,16 +2218,13 @@ hrtimer_interrupt
 sys_nanosleep
 
 
-Perhaps this is not enough. The filters also allow simple wild
-cards. Only the following are currently available
+Perhaps this is not enough. The filters also allow glob(7) matching.
 
   *  - will match functions that begin with 
   *  - will match functions that end with 
   ** - will match functions that have  in it
-
-These are the only wild cards which are supported.
-
-  * will not work.
+  * - will match functions that begin with
+   and end with 
 
 Note: It is better to use quotes to enclose the wild cards,
   otherwise the shell may expand the parameters into names
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index ba33267..aa6eb15 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -70,6 +70,7 @@ config FTRACE_NMI_ENTER
 
 config EVENT_TRACING
select CONTEXT_SWITCH_TRACER
+select GLOB
bool
 
 config CONTEXT_SWITCH_TRACER
@@ -133,6 +134,7 @@ config FUNCTION_TRACER
select KALLSYMS
select GENERIC_TRACER
select CONTEXT_SWITCH_TRACER
+select GLOB
help
  Enable the kernel to trace every kernel function. This is done
  by using a compiler feature to insert a small, 5-byte No-Operation
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 84752c8..5741184 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3493,6 +3493,10 @@ static int ftrace_match(char *str, struct ftrace_glob *g)
memcmp(str + slen - g->len, g->search, g->len) == 0)
matched = 1;
break;
+   case MATCH_GLOB:
+   if (glob_match(g->search, str))
+   matched = 1;
+   break;
}
 
return matched;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 37824d9..ae343e7 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4065,7 +4065,7 @@ static const char readme_msg[] =
"\n  available_filter_functions - list of functions that can be 
filtered on\n"
"  set_ftrace_filter\t- echo function name in here to only trace 
these\n"
"\t\t\t  functions\n"
-   "\t accepts: func_full_name, *func_end, func_begin*, 
*func_middle*\n"
+   "\t accepts: func_full_name or glob-matching-pattern\n"
"\t modules: Can select a group via module\n"
"\t  Format: :mod:\n"
"\t example: echo :mod:ext3 > set_ftrace_filter\n"
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index f783df4..eac2eda 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_FTRACE_SYSCALLS
 #include /* For NR_SYSCALLS   */
@@ -1252,6 +1253,7 @@ enum regex_type {
MATCH_FRONT_ONLY,
MATCH_MIDDLE_ONLY,
   

[PATCH 0/5] ftrace: selftests: Add full glob matching and update ftracetest

[Masami Hiramatsu]

Hi,

Here is a series of patches to add full glob matching
support in ftrace and update ftracetest to test the
glob matching and hexadecimal types.

The first patch is same one as I sent before
(https://lkml.org/lkml/2016/10/5/149)
I've added patches for updating ftracetest to test
this feature and previous hexadecimal type feature.
Since I've found an issue (if tracing_on is set to 0,
some test cases fail) on ftracetest, this also
fixes the issue.

[1/5] Add full glob matching support on ftrace's
 function filter and event filter expression.
[2/5] Fix some testcases to enable tracing_on before
 start tracing.
[3/5] Introduce temporary directory for test cases,
 which is used for storing temporary test data.
[4/5] Add a testcase for function-name glob matching
[5/5] Add a testcase for types of event arguments 

Thanks,
---

Masami Hiramatsu (5):
  ftrace: Support full glob matching
  selftests: ftrace: Fix test cases to enable tracing
  selftests: ftrace: Introduce TMPDIR for temporary files
  selftests: ftrace: Add a testcase for function filter glob match
  selftests: ftrace: Add a testcase for types of kprobe event


 Documentation/trace/events.txt |9 +---
 Documentation/trace/ftrace.txt |9 +---
 kernel/trace/Kconfig   |2 +
 kernel/trace/ftrace.c  |4 ++
 kernel/trace/trace.c   |2 -
 kernel/trace/trace.h   |2 +
 kernel/trace/trace_events_filter.c |   17 +++
 tools/testing/selftests/ftrace/ftracetest  |2 +
 .../selftests/ftrace/test.d/event/event-enable.tc  |1 
 .../selftests/ftrace/test.d/event/event-pid.tc |1 
 .../ftrace/test.d/event/subsystem-enable.tc|1 
 .../ftrace/test.d/event/toplevel-enable.tc |1 
 .../ftrace/test.d/ftrace/func-filter-glob.tc   |   49 
 .../ftrace/test.d/ftrace/func_profiler.tc  |1 
 .../ftrace/test.d/kprobe/kprobe_args_type.tc   |   37 +++
 .../ftrace/test.d/kprobe/kprobe_ftrace.tc  |1 
 16 files changed, 125 insertions(+), 14 deletions(-)
 create mode 100644 
tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
 create mode 100644 
tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc

--
Masami Hiramatsu (Linaro Ltd.) 

[PATCH 0/5] ftrace: selftests: Add full glob matching and update ftracetest

[Masami Hiramatsu]

Hi,

Here is a series of patches to add full glob matching
support in ftrace and update ftracetest to test the
glob matching and hexadecimal types.

The first patch is same one as I sent before
(https://lkml.org/lkml/2016/10/5/149)
I've added patches for updating ftracetest to test
this feature and previous hexadecimal type feature.
Since I've found an issue (if tracing_on is set to 0,
some test cases fail) on ftracetest, this also
fixes the issue.

[1/5] Add full glob matching support on ftrace's
 function filter and event filter expression.
[2/5] Fix some testcases to enable tracing_on before
 start tracing.
[3/5] Introduce temporary directory for test cases,
 which is used for storing temporary test data.
[4/5] Add a testcase for function-name glob matching
[5/5] Add a testcase for types of event arguments 

Thanks,
---

Masami Hiramatsu (5):
  ftrace: Support full glob matching
  selftests: ftrace: Fix test cases to enable tracing
  selftests: ftrace: Introduce TMPDIR for temporary files
  selftests: ftrace: Add a testcase for function filter glob match
  selftests: ftrace: Add a testcase for types of kprobe event


 Documentation/trace/events.txt |9 +---
 Documentation/trace/ftrace.txt |9 +---
 kernel/trace/Kconfig   |2 +
 kernel/trace/ftrace.c  |4 ++
 kernel/trace/trace.c   |2 -
 kernel/trace/trace.h   |2 +
 kernel/trace/trace_events_filter.c |   17 +++
 tools/testing/selftests/ftrace/ftracetest  |2 +
 .../selftests/ftrace/test.d/event/event-enable.tc  |1 
 .../selftests/ftrace/test.d/event/event-pid.tc |1 
 .../ftrace/test.d/event/subsystem-enable.tc|1 
 .../ftrace/test.d/event/toplevel-enable.tc |1 
 .../ftrace/test.d/ftrace/func-filter-glob.tc   |   49 
 .../ftrace/test.d/ftrace/func_profiler.tc  |1 
 .../ftrace/test.d/kprobe/kprobe_args_type.tc   |   37 +++
 .../ftrace/test.d/kprobe/kprobe_ftrace.tc  |1 
 16 files changed, 125 insertions(+), 14 deletions(-)
 create mode 100644 
tools/testing/selftests/ftrace/test.d/ftrace/func-filter-glob.tc
 create mode 100644 
tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_type.tc

--
Masami Hiramatsu (Linaro Ltd.) 

Re: tg3 BUG: spinlock lockup suspected

[Siva Reddy Kallam]

On Mon, Oct 17, 2016 at 6:35 PM, Meelis Roos  wrote:
>> > Now I reproduced the bug even with 4.7-rc1 so it is older than 4.7. Will
>> > test further.
>>
>> It gets stranger and stranger - my old 4.7 image worked fine, freshly
>> compiled 4.7 exhibits the same problem.
>>
>> Toolchain has not changed, that I know for sure.
>>
>> What may have changed is kernel .config. My old conf was with whatever I
>> had during 4.7. Then I upgraded to 4.8-rc3 and then 4.8 and selected
>> values for "make oldconfig" new entries. Then went back to 4.7-rc1 and
>> then to 4.7 with this config, answering quiestion about new options when
>> any appeared. Diff is not available since I do not have the old configs
>> archived.
>
> I did some more digging. Found an older configuration that is working
> and recreated a newer one that is bad, for the same 4.7 kernel. This is
> reproducible now, from "make clean" state.
>
> Working config from 4.7-rc4 attached as config-4.7, broken config from
> 4.7 attached as config-4.7-bad.
>
> Will try to bisect the configs as time permits. But looking at the
> stack traces, the issue is probably timing related, when ip and dhclient
> do something with the same lock. seq_read that outputs stats could be
> reading /proc/net/dev that reads counters from each interface.
>
> ifupdown seems to use the following for dhcp interfaces:
>   up
> [[/bin/ip link set dev %iface% address %hwaddress%]]
> /sbin/dhclient -v -pf /run/dhclient.%iface%.pid -lf 
> /var/lib/dhcp/dhclient.%iface%.leases -I -df 
> /var/lib/dhcp/dhclient6.%iface%.leases %iface% \
> ...
>
> so ip link is setting link up, this creates some work for the
> background, and the dhclient goes adn reads /proc/net/dev, and lockup is
> suspected but not proven?
>
> I started a loop for test, doing cat /proc/net/dev in a loop and at the
> same link link up and down from console, but up and down is slow process
> and the loop did not seem to trigger the warning over night, so it was
> not so simple.
>
I am busy with other priority tasks. One of my colleague Deepak will
work this with you.
I added him to CC list.
Thanks.
>
>> > > [   83.716570] BUG: spinlock lockup suspected on CPU#0, dhclient/1014
>> > > [   83.797819]  lock: 0xfff000123c8e4a08, .magic: dead4ead, .owner: 
>> > > ip/1001, .owner_cpu: 1
>> > > [   83.903130] CPU: 0 PID: 1014 Comm: dhclient Not tainted 4.8.0 #4
>> > > [   83.982129] Call Trace:
>> > > [   84.014160]  [004b7220] spin_dump+0x60/0xa0
>> > > [   84.078203]  [004b73a0] do_raw_spin_lock+0xa0/0x120
>> > > [   84.106344] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> > > [   84.107193] ip (1001) used greatest stack depth: 2168 bytes left
>> > > [   84.306955]  [0092c0d0] _raw_spin_lock_bh+0x30/0x40
>> > > [   84.380188]  [100822cc] tg3_get_stats64+0xc/0x80 [tg3]
>> > > [   84.456885]  [007fac8c] dev_get_stats+0x2c/0xc0
>> > > [   84.525506]  [0081a4e8] dev_seq_printf_stats+0x8/0xe0
>> > > [   84.600986]  [0081a5e4] dev_seq_show+0x24/0x40
>> > > [   84.668467]  [005cb6c4] seq_read+0x2c4/0x440
>> > > [   84.733656]  [0060b97c] proc_reg_read+0x3c/0x80
>> > > [   84.802282]  [005a219c] __vfs_read+0x1c/0x140
>> > > [   84.868613]  [005a2310] vfs_read+0x50/0x100
>> > > [   84.932662]  [005a265c] SyS_read+0x3c/0xa0
>> > > [   84.995573]  [004061d4] linux_sparc_syscall32+0x34/0x60
>> > > [   85.073748] * CPU[  0]: TSTATE[0044f0001a22] 
>> > > TPC[f79a16b0] TNPC[f79a16b4] TASK[dhclient:1014]
>> > > [   85.208732]  TPC[f79a16b0] O7[f79405c8] I7[0] RPC[0]
>> > > [   85.287633]   CPU[  1]: TSTATE[004480001605] 
>> > > TPC[004b26f0] TNPC[004d0b0c] TASK[swapper/1:0]
>> > > [   85.420338]  TPC[trace_hardirqs_off+0x10/0x20] 
>> > > O7[rcu_idle_enter+0x64/0xa0] I7[cpu_startup_entry+0x1b0/0x240] 
>> > > RPC[rest_init+0x178/0x1a0]
>> > > [   85.664600] tg3 :00:02.0 eth0: Link is up at 100 Mbps, full duplex
>> > > [   85.750515] tg3 :00:02.0 eth0: Flow control is off for TX and off 
>> > > for RX
>> > > [   85.843994] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> --
> Meelis Roos (mr...@linux.ee)

Re: tg3 BUG: spinlock lockup suspected

[Siva Reddy Kallam]

On Mon, Oct 17, 2016 at 6:35 PM, Meelis Roos  wrote:
>> > Now I reproduced the bug even with 4.7-rc1 so it is older than 4.7. Will
>> > test further.
>>
>> It gets stranger and stranger - my old 4.7 image worked fine, freshly
>> compiled 4.7 exhibits the same problem.
>>
>> Toolchain has not changed, that I know for sure.
>>
>> What may have changed is kernel .config. My old conf was with whatever I
>> had during 4.7. Then I upgraded to 4.8-rc3 and then 4.8 and selected
>> values for "make oldconfig" new entries. Then went back to 4.7-rc1 and
>> then to 4.7 with this config, answering quiestion about new options when
>> any appeared. Diff is not available since I do not have the old configs
>> archived.
>
> I did some more digging. Found an older configuration that is working
> and recreated a newer one that is bad, for the same 4.7 kernel. This is
> reproducible now, from "make clean" state.
>
> Working config from 4.7-rc4 attached as config-4.7, broken config from
> 4.7 attached as config-4.7-bad.
>
> Will try to bisect the configs as time permits. But looking at the
> stack traces, the issue is probably timing related, when ip and dhclient
> do something with the same lock. seq_read that outputs stats could be
> reading /proc/net/dev that reads counters from each interface.
>
> ifupdown seems to use the following for dhcp interfaces:
>   up
> [[/bin/ip link set dev %iface% address %hwaddress%]]
> /sbin/dhclient -v -pf /run/dhclient.%iface%.pid -lf 
> /var/lib/dhcp/dhclient.%iface%.leases -I -df 
> /var/lib/dhcp/dhclient6.%iface%.leases %iface% \
> ...
>
> so ip link is setting link up, this creates some work for the
> background, and the dhclient goes adn reads /proc/net/dev, and lockup is
> suspected but not proven?
>
> I started a loop for test, doing cat /proc/net/dev in a loop and at the
> same link link up and down from console, but up and down is slow process
> and the loop did not seem to trigger the warning over night, so it was
> not so simple.
>
I am busy with other priority tasks. One of my colleague Deepak will
work this with you.
I added him to CC list.
Thanks.
>
>> > > [   83.716570] BUG: spinlock lockup suspected on CPU#0, dhclient/1014
>> > > [   83.797819]  lock: 0xfff000123c8e4a08, .magic: dead4ead, .owner: 
>> > > ip/1001, .owner_cpu: 1
>> > > [   83.903130] CPU: 0 PID: 1014 Comm: dhclient Not tainted 4.8.0 #4
>> > > [   83.982129] Call Trace:
>> > > [   84.014160]  [004b7220] spin_dump+0x60/0xa0
>> > > [   84.078203]  [004b73a0] do_raw_spin_lock+0xa0/0x120
>> > > [   84.106344] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> > > [   84.107193] ip (1001) used greatest stack depth: 2168 bytes left
>> > > [   84.306955]  [0092c0d0] _raw_spin_lock_bh+0x30/0x40
>> > > [   84.380188]  [100822cc] tg3_get_stats64+0xc/0x80 [tg3]
>> > > [   84.456885]  [007fac8c] dev_get_stats+0x2c/0xc0
>> > > [   84.525506]  [0081a4e8] dev_seq_printf_stats+0x8/0xe0
>> > > [   84.600986]  [0081a5e4] dev_seq_show+0x24/0x40
>> > > [   84.668467]  [005cb6c4] seq_read+0x2c4/0x440
>> > > [   84.733656]  [0060b97c] proc_reg_read+0x3c/0x80
>> > > [   84.802282]  [005a219c] __vfs_read+0x1c/0x140
>> > > [   84.868613]  [005a2310] vfs_read+0x50/0x100
>> > > [   84.932662]  [005a265c] SyS_read+0x3c/0xa0
>> > > [   84.995573]  [004061d4] linux_sparc_syscall32+0x34/0x60
>> > > [   85.073748] * CPU[  0]: TSTATE[0044f0001a22] 
>> > > TPC[f79a16b0] TNPC[f79a16b4] TASK[dhclient:1014]
>> > > [   85.208732]  TPC[f79a16b0] O7[f79405c8] I7[0] RPC[0]
>> > > [   85.287633]   CPU[  1]: TSTATE[004480001605] 
>> > > TPC[004b26f0] TNPC[004d0b0c] TASK[swapper/1:0]
>> > > [   85.420338]  TPC[trace_hardirqs_off+0x10/0x20] 
>> > > O7[rcu_idle_enter+0x64/0xa0] I7[cpu_startup_entry+0x1b0/0x240] 
>> > > RPC[rest_init+0x178/0x1a0]
>> > > [   85.664600] tg3 :00:02.0 eth0: Link is up at 100 Mbps, full duplex
>> > > [   85.750515] tg3 :00:02.0 eth0: Flow control is off for TX and off 
>> > > for RX
>> > > [   85.843994] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> --
> Meelis Roos (mr...@linux.ee)

Re: [lkp] [ipc/sem.c] 5864a2fd30: aim9.shared_memory.ops_per_sec -13.0%

[Manfred Spraul]

Hi,

as discussed before:
The root cause for the performance regression is the smp_mb() that was
added into the fast path.

I see two options:
1) switch to full spin_lock()/spin_unlock() for the rare codepath,
  then the fast path doesn't need the smp_mb() anymore.

2) confirm that no arch needs the smp_mb(), then remove it.
  - powerpc is ok after commit
 6262db7c088b ("powerpc/spinlock: Fix spin_unlock_wait()")
  - arm is ok after commit
 d86b8da04dfa ("arm64: spinlock: serialise spin_unlock_wait against 
concurrent lockers")
  - for x86 is ok after commit
 2c6100227116 ("locking/qspinlock: Fix spin_unlock_wait() some more")
  - for the remaining SMP architectures, I don't have a status.

I would prefer the approach 1:
The memory ordering provided by spin_lock()/spin_unlock() is clear.

Thus:
Attached are patches for approach 1:

- Patch 1 replaces spin_unlock_wait() with spin_lock()/spin_unlock() and
  removes all memory barriers that are then unnecessary.

- Patch 2 adds the hysteresis code: This makes the rare codepath
  extremely rare.
  It also corrects some wrong comments, e.g. regarding switching
  from global lock to per-sem lock (we "must' switch, not we "can"
  switch as written right now).

The patches passed stress-testing.

What do you think?
My initial idea was to aim for 4.10, then we have more time to decide.

--
Manfred

[PATCH 2/2] ipc/sem: Add hysteresis.

[Manfred Spraul]

sysv sem has two lock modes: One with per-semaphore locks, one lock mode
with a single global lock for the whole array.
When switching from the per-semaphore locks to the global lock, all
per-semaphore locks must be scanned for ongoing operations.

The patch adds a hysteresis for switching from the global lock to the
per semaphore locks. This reduces how often the per-semaphore locks
must be scanned.

Compared to the initial patch, this is a simplified solution:
Setting USE_GLOBAL_LOCK_HYSTERESIS to 1 restores the current behavior.

In theory, a workload with exactly 10 simple sops and then
one complex op now scales a bit worse, but this is pure theory:
If there is concurrency, the it won't be exactly 10:1:10:1:10:1:...
If there is no concurrency, then there is no need for scalability.

Signed-off-by: Manfred Spraul 
---
 include/linux/sem.h |  2 +-
 ipc/sem.c   | 86 +
 2 files changed, 62 insertions(+), 26 deletions(-)

diff --git a/include/linux/sem.h b/include/linux/sem.h
index d0efd6e..4fc222f 100644
--- a/include/linux/sem.h
+++ b/include/linux/sem.h
@@ -21,7 +21,7 @@ struct sem_array {
struct list_headlist_id;/* undo requests on this array 
*/
int sem_nsems;  /* no. of semaphores in array */
int complex_count;  /* pending complex operations */
-   boolcomplex_mode;   /* no parallel simple ops */
+   unsigned intuse_global_lock;/* >0: global lock required */
 };
 
 #ifdef CONFIG_SYSVIPC
diff --git a/ipc/sem.c b/ipc/sem.c
index 94df1bf..e84703d 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -161,22 +161,42 @@ static int sysvipc_sem_proc_show(struct seq_file *s, void 
*it);
 #define SEMOPM_FAST64  /* ~ 372 bytes on stack */
 
 /*
+ * Switching from the mode suitable for simple ops
+ * to the mode for complex ops is costly. Therefore:
+ * use some hysteresis
+ */
+#define USE_GLOBAL_LOCK_HYSTERESIS 10
+
+/*
  * Locking:
  * a) global sem_lock() for read/write
  * sem_undo.id_next,
  * sem_array.complex_count,
- * sem_array.complex_mode
  * sem_array.pending{_alter,_const},
  * sem_array.sem_undo
  *
  * b) global or semaphore sem_lock() for read/write:
  * sem_array.sem_base[i].pending_{const,alter}:
- * sem_array.complex_mode (for read)
  *
  * c) special:
  * sem_undo_list.list_proc:
  * * undo_list->lock for write
  * * rcu for read
+ * use_global_lock:
+ * * global sem_lock() for write
+ * * either local or global sem_lock() for read.
+ *
+ * Memory ordering:
+ * Most ordering is enforced by using spin_lock() and spin_unlock().
+ * The special case is use_global_lock:
+ * Setting it from non-zero to 0 is a RELEASE, this is ensured by
+ * using smp_store_release().
+ * Testing if it is non-zero is an ACQUIRE, this is ensured by using
+ * smp_load_acquire().
+ * Setting it from 0 to non-zero must be ordered with regards to
+ * this smp_load_acquire(), this is guaranteed because the smp_load_acquire()
+ * is inside a spin_lock() and after a write from 0 to non-zero a
+ * spin_lock()+spin_unlock() is done.
  */
 
 #define sc_semmsl  sem_ctls[0]
@@ -275,12 +295,16 @@ static void complexmode_enter(struct sem_array *sma)
int i;
struct sem *sem;
 
-   if (sma->complex_mode)  {
-   /* We are already in complex_mode. Nothing to do */
+   if (sma->use_global_lock > 0)  {
+   /*
+* We are already in global lock mode.
+* Nothing to do, just reset the
+* counter until we return to simple mode.
+*/
+   sma->use_global_lock = USE_GLOBAL_LOCK_HYSTERESIS;
return;
}
-
-   sma->complex_mode = true;
+   sma->use_global_lock = USE_GLOBAL_LOCK_HYSTERESIS;
 
for (i = 0; i < sma->sem_nsems; i++) {
sem = sma->sem_base + i;
@@ -301,13 +325,17 @@ static void complexmode_tryleave(struct sem_array *sma)
 */
return;
}
-   /*
-* Immediately after setting complex_mode to false,
-* a simple op can start. Thus: all memory writes
-* performed by the current operation must be visible
-* before we set complex_mode to false.
-*/
-   smp_store_release(>complex_mode, false);
+   if (sma->use_global_lock == 1) {
+   /*
+* Immediately after setting use_global_lock to 0,
+* a simple op can start. Thus: all memory writes
+* performed by the current operation must be visible
+* before we set use_global_lock to 0.
+*/
+   smp_store_release(>use_global_lock, 0);
+   } else {
+   sma->use_global_lock--;
+   }
 }
 
 #define SEM_GLOBAL_LOCK(-1)
@@ -337,22 +365,23 @@ static inline int 

Re: [lkp] [ipc/sem.c] 5864a2fd30: aim9.shared_memory.ops_per_sec -13.0%

[Manfred Spraul]

Hi,

as discussed before:
The root cause for the performance regression is the smp_mb() that was
added into the fast path.

I see two options:
1) switch to full spin_lock()/spin_unlock() for the rare codepath,
  then the fast path doesn't need the smp_mb() anymore.

2) confirm that no arch needs the smp_mb(), then remove it.
  - powerpc is ok after commit
 6262db7c088b ("powerpc/spinlock: Fix spin_unlock_wait()")
  - arm is ok after commit
 d86b8da04dfa ("arm64: spinlock: serialise spin_unlock_wait against 
concurrent lockers")
  - for x86 is ok after commit
 2c6100227116 ("locking/qspinlock: Fix spin_unlock_wait() some more")
  - for the remaining SMP architectures, I don't have a status.

I would prefer the approach 1:
The memory ordering provided by spin_lock()/spin_unlock() is clear.

Thus:
Attached are patches for approach 1:

- Patch 1 replaces spin_unlock_wait() with spin_lock()/spin_unlock() and
  removes all memory barriers that are then unnecessary.

- Patch 2 adds the hysteresis code: This makes the rare codepath
  extremely rare.
  It also corrects some wrong comments, e.g. regarding switching
  from global lock to per-sem lock (we "must' switch, not we "can"
  switch as written right now).

The patches passed stress-testing.

What do you think?
My initial idea was to aim for 4.10, then we have more time to decide.

--
Manfred

[PATCH 2/2] ipc/sem: Add hysteresis.

[Manfred Spraul]

sysv sem has two lock modes: One with per-semaphore locks, one lock mode
with a single global lock for the whole array.
When switching from the per-semaphore locks to the global lock, all
per-semaphore locks must be scanned for ongoing operations.

The patch adds a hysteresis for switching from the global lock to the
per semaphore locks. This reduces how often the per-semaphore locks
must be scanned.

Compared to the initial patch, this is a simplified solution:
Setting USE_GLOBAL_LOCK_HYSTERESIS to 1 restores the current behavior.

In theory, a workload with exactly 10 simple sops and then
one complex op now scales a bit worse, but this is pure theory:
If there is concurrency, the it won't be exactly 10:1:10:1:10:1:...
If there is no concurrency, then there is no need for scalability.

Signed-off-by: Manfred Spraul 
---
 include/linux/sem.h |  2 +-
 ipc/sem.c   | 86 +
 2 files changed, 62 insertions(+), 26 deletions(-)

diff --git a/include/linux/sem.h b/include/linux/sem.h
index d0efd6e..4fc222f 100644
--- a/include/linux/sem.h
+++ b/include/linux/sem.h
@@ -21,7 +21,7 @@ struct sem_array {
struct list_headlist_id;/* undo requests on this array 
*/
int sem_nsems;  /* no. of semaphores in array */
int complex_count;  /* pending complex operations */
-   boolcomplex_mode;   /* no parallel simple ops */
+   unsigned intuse_global_lock;/* >0: global lock required */
 };
 
 #ifdef CONFIG_SYSVIPC
diff --git a/ipc/sem.c b/ipc/sem.c
index 94df1bf..e84703d 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -161,22 +161,42 @@ static int sysvipc_sem_proc_show(struct seq_file *s, void 
*it);
 #define SEMOPM_FAST64  /* ~ 372 bytes on stack */
 
 /*
+ * Switching from the mode suitable for simple ops
+ * to the mode for complex ops is costly. Therefore:
+ * use some hysteresis
+ */
+#define USE_GLOBAL_LOCK_HYSTERESIS 10
+
+/*
  * Locking:
  * a) global sem_lock() for read/write
  * sem_undo.id_next,
  * sem_array.complex_count,
- * sem_array.complex_mode
  * sem_array.pending{_alter,_const},
  * sem_array.sem_undo
  *
  * b) global or semaphore sem_lock() for read/write:
  * sem_array.sem_base[i].pending_{const,alter}:
- * sem_array.complex_mode (for read)
  *
  * c) special:
  * sem_undo_list.list_proc:
  * * undo_list->lock for write
  * * rcu for read
+ * use_global_lock:
+ * * global sem_lock() for write
+ * * either local or global sem_lock() for read.
+ *
+ * Memory ordering:
+ * Most ordering is enforced by using spin_lock() and spin_unlock().
+ * The special case is use_global_lock:
+ * Setting it from non-zero to 0 is a RELEASE, this is ensured by
+ * using smp_store_release().
+ * Testing if it is non-zero is an ACQUIRE, this is ensured by using
+ * smp_load_acquire().
+ * Setting it from 0 to non-zero must be ordered with regards to
+ * this smp_load_acquire(), this is guaranteed because the smp_load_acquire()
+ * is inside a spin_lock() and after a write from 0 to non-zero a
+ * spin_lock()+spin_unlock() is done.
  */
 
 #define sc_semmsl  sem_ctls[0]
@@ -275,12 +295,16 @@ static void complexmode_enter(struct sem_array *sma)
int i;
struct sem *sem;
 
-   if (sma->complex_mode)  {
-   /* We are already in complex_mode. Nothing to do */
+   if (sma->use_global_lock > 0)  {
+   /*
+* We are already in global lock mode.
+* Nothing to do, just reset the
+* counter until we return to simple mode.
+*/
+   sma->use_global_lock = USE_GLOBAL_LOCK_HYSTERESIS;
return;
}
-
-   sma->complex_mode = true;
+   sma->use_global_lock = USE_GLOBAL_LOCK_HYSTERESIS;
 
for (i = 0; i < sma->sem_nsems; i++) {
sem = sma->sem_base + i;
@@ -301,13 +325,17 @@ static void complexmode_tryleave(struct sem_array *sma)
 */
return;
}
-   /*
-* Immediately after setting complex_mode to false,
-* a simple op can start. Thus: all memory writes
-* performed by the current operation must be visible
-* before we set complex_mode to false.
-*/
-   smp_store_release(>complex_mode, false);
+   if (sma->use_global_lock == 1) {
+   /*
+* Immediately after setting use_global_lock to 0,
+* a simple op can start. Thus: all memory writes
+* performed by the current operation must be visible
+* before we set use_global_lock to 0.
+*/
+   smp_store_release(>use_global_lock, 0);
+   } else {
+   sma->use_global_lock--;
+   }
 }
 
 #define SEM_GLOBAL_LOCK(-1)
@@ -337,22 +365,23 @@ static inline int sem_lock(struct sem_array *sma, 

[PATCH 1/2] ipc/sem.c: Avoid using spin_unlock_wait()

[Manfred Spraul]

a) The ACQUIRE in spin_lock() applies to the read, not to the store,
at least for powerpc. This forces to add a smp_mb() into the fast
path.

b) The memory barrier provided by spin_unlock_wait() is right now
arch dependent.

Therefore: Use spin_lock()/spin_unlock() instead of spin_unlock_wait().

Advantage: faster single op semop calls(), observed +8.9% on
x86. (the other solution would be arch dependencies in ipc/sem).

Disadvantage: slower complex op semop calls, if (and only if)
there are no sleeping operations.

The next patch adds hysteresis, this further reduces the
probability that the slow path is used.

Signed-off-by: Manfred Spraul 
---
 ipc/sem.c | 25 +++--
 1 file changed, 3 insertions(+), 22 deletions(-)

diff --git a/ipc/sem.c b/ipc/sem.c
index 5e318c5..d5f2710 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -280,24 +280,13 @@ static void complexmode_enter(struct sem_array *sma)
return;
}
 
-   /* We need a full barrier after seting complex_mode:
-* The write to complex_mode must be visible
-* before we read the first sem->lock spinlock state.
-*/
-   smp_store_mb(sma->complex_mode, true);
+   sma->complex_mode = true;
 
for (i = 0; i < sma->sem_nsems; i++) {
sem = sma->sem_base + i;
-   spin_unlock_wait(>lock);
+   spin_lock(>lock);
+   spin_unlock(>lock);
}
-   /*
-* spin_unlock_wait() is not a memory barriers, it is only a
-* control barrier. The code must pair with spin_unlock(>lock),
-* thus just the control barrier is insufficient.
-*
-* smp_rmb() is sufficient, as writes cannot pass the control barrier.
-*/
-   smp_rmb();
 }
 
 /*
@@ -363,14 +352,6 @@ static inline int sem_lock(struct sem_array *sma, struct 
sembuf *sops,
 */
spin_lock(>lock);
 
-   /*
-* See 51d7d5205d33
-* ("powerpc: Add smp_mb() to arch_spin_is_locked()"):
-* A full barrier is required: the write of sem->lock
-* must be visible before the read is executed
-*/
-   smp_mb();
-
if (!smp_load_acquire(>complex_mode)) {
/* fast path successful! */
return sops->sem_num;
-- 
2.7.4

[PATCH 1/2] ipc/sem.c: Avoid using spin_unlock_wait()

[Manfred Spraul]

a) The ACQUIRE in spin_lock() applies to the read, not to the store,
at least for powerpc. This forces to add a smp_mb() into the fast
path.

b) The memory barrier provided by spin_unlock_wait() is right now
arch dependent.

Therefore: Use spin_lock()/spin_unlock() instead of spin_unlock_wait().

Advantage: faster single op semop calls(), observed +8.9% on
x86. (the other solution would be arch dependencies in ipc/sem).

Disadvantage: slower complex op semop calls, if (and only if)
there are no sleeping operations.

The next patch adds hysteresis, this further reduces the
probability that the slow path is used.

Signed-off-by: Manfred Spraul 
---
 ipc/sem.c | 25 +++--
 1 file changed, 3 insertions(+), 22 deletions(-)

diff --git a/ipc/sem.c b/ipc/sem.c
index 5e318c5..d5f2710 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -280,24 +280,13 @@ static void complexmode_enter(struct sem_array *sma)
return;
}
 
-   /* We need a full barrier after seting complex_mode:
-* The write to complex_mode must be visible
-* before we read the first sem->lock spinlock state.
-*/
-   smp_store_mb(sma->complex_mode, true);
+   sma->complex_mode = true;
 
for (i = 0; i < sma->sem_nsems; i++) {
sem = sma->sem_base + i;
-   spin_unlock_wait(>lock);
+   spin_lock(>lock);
+   spin_unlock(>lock);
}
-   /*
-* spin_unlock_wait() is not a memory barriers, it is only a
-* control barrier. The code must pair with spin_unlock(>lock),
-* thus just the control barrier is insufficient.
-*
-* smp_rmb() is sufficient, as writes cannot pass the control barrier.
-*/
-   smp_rmb();
 }
 
 /*
@@ -363,14 +352,6 @@ static inline int sem_lock(struct sem_array *sma, struct 
sembuf *sops,
 */
spin_lock(>lock);
 
-   /*
-* See 51d7d5205d33
-* ("powerpc: Add smp_mb() to arch_spin_is_locked()"):
-* A full barrier is required: the write of sem->lock
-* must be visible before the read is executed
-*/
-   smp_mb();
-
if (!smp_load_acquire(>complex_mode)) {
/* fast path successful! */
return sops->sem_num;
-- 
2.7.4

[PATCH] i2c: uniphier[-f]: fix bool logic calculation

[Masahiro Yamada]

This code is working, but it should not depend on how "bool" is
typedef'ed, or the bit position of I2C_M_RD.

Signed-off-by: Masahiro Yamada 
---

 drivers/i2c/busses/i2c-uniphier-f.c | 2 +-
 drivers/i2c/busses/i2c-uniphier.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-uniphier-f.c 
b/drivers/i2c/busses/i2c-uniphier-f.c
index db9105e..b54448e 100644
--- a/drivers/i2c/busses/i2c-uniphier-f.c
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -309,7 +309,7 @@ static int uniphier_fi2c_master_xfer_one(struct i2c_adapter 
*adap,
 struct i2c_msg *msg, bool stop)
 {
struct uniphier_fi2c_priv *priv = i2c_get_adapdata(adap);
-   bool is_read = msg->flags & I2C_M_RD;
+   bool is_read = !!(msg->flags & I2C_M_RD);
unsigned long time_left;
 
dev_dbg(>dev, "%s: addr=0x%02x, len=%d, stop=%d\n",
diff --git a/drivers/i2c/busses/i2c-uniphier.c 
b/drivers/i2c/busses/i2c-uniphier.c
index 56e92af..cc80bb2 100644
--- a/drivers/i2c/busses/i2c-uniphier.c
+++ b/drivers/i2c/busses/i2c-uniphier.c
@@ -177,7 +177,7 @@ static int uniphier_i2c_stop(struct i2c_adapter *adap)
 static int uniphier_i2c_master_xfer_one(struct i2c_adapter *adap,
struct i2c_msg *msg, bool stop)
 {
-   bool is_read = msg->flags & I2C_M_RD;
+   bool is_read = !!(msg->flags & I2C_M_RD);
bool recovery = false;
int ret;
 
-- 
1.9.1

[PATCH] i2c: uniphier[-f]: fix bool logic calculation

[Masahiro Yamada]

This code is working, but it should not depend on how "bool" is
typedef'ed, or the bit position of I2C_M_RD.

Signed-off-by: Masahiro Yamada 
---

 drivers/i2c/busses/i2c-uniphier-f.c | 2 +-
 drivers/i2c/busses/i2c-uniphier.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-uniphier-f.c 
b/drivers/i2c/busses/i2c-uniphier-f.c
index db9105e..b54448e 100644
--- a/drivers/i2c/busses/i2c-uniphier-f.c
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -309,7 +309,7 @@ static int uniphier_fi2c_master_xfer_one(struct i2c_adapter 
*adap,
 struct i2c_msg *msg, bool stop)
 {
struct uniphier_fi2c_priv *priv = i2c_get_adapdata(adap);
-   bool is_read = msg->flags & I2C_M_RD;
+   bool is_read = !!(msg->flags & I2C_M_RD);
unsigned long time_left;
 
dev_dbg(>dev, "%s: addr=0x%02x, len=%d, stop=%d\n",
diff --git a/drivers/i2c/busses/i2c-uniphier.c 
b/drivers/i2c/busses/i2c-uniphier.c
index 56e92af..cc80bb2 100644
--- a/drivers/i2c/busses/i2c-uniphier.c
+++ b/drivers/i2c/busses/i2c-uniphier.c
@@ -177,7 +177,7 @@ static int uniphier_i2c_stop(struct i2c_adapter *adap)
 static int uniphier_i2c_master_xfer_one(struct i2c_adapter *adap,
struct i2c_msg *msg, bool stop)
 {
-   bool is_read = msg->flags & I2C_M_RD;
+   bool is_read = !!(msg->flags & I2C_M_RD);
bool recovery = false;
int ret;
 
-- 
1.9.1

Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk() recursive calls

[Sergey Senozhatsky]

On (10/19/16 00:40), Sergey Senozhatsky wrote:
[..]
> Deadlock scenarios that printk_safe can handle:
> 
> a) printk recursion from logbuf_lock spin_lock section in printk()
>   printk()
> raw_spin_lock(_lock);
> WARN_ON(1);
> raw_spin_unlock(_lock);
> 
> b) printk from sem->lock spin_lock section
>   printk()
> console_trylock()
>   down_trylock()
> raw_spin_lock_irqsave(>lock, flags);
> WARN_ON(1);
> raw_spin_unlock_irqrestore(>lock, flags);
> 
> c) printk from logbuf_lock spin_lock section in console_unlock()
>   printk()
> console_unlock()
>   raw_spin_lock(_lock);
>   WARN_ON(1);
>   raw_spin_unlock(_lock);
> 
> d) printk from ->pi_lock from semaphore up
>   printk()
> console_unlock()
>   up()
> try_to_wake_up()
>   raw_spin_lock_irqsave(>pi_lock, flags);
>   WARN_ON(1);
>   raw_spin_unlock_irqrestore(>pi_lock, flags);

and

e) anything from call_console_drivers() should be fine as well.
   console_unlock() big printing loop is covered by printk_safe,
   need to protect console_cont_flush()->call_console_drivers().

   so printk "direct path" seems to be safe now:

   printk -> .. -> console_unlock() -> call_console_drivers() -> 
serial_console_write()

   anything that is "indirect" is not covered in this patch set.


-ss

Re: [RFC][PATCHv3 0/6] printk: use printk_safe to handle printk() recursive calls

[Sergey Senozhatsky]

On (10/19/16 00:40), Sergey Senozhatsky wrote:
[..]
> Deadlock scenarios that printk_safe can handle:
> 
> a) printk recursion from logbuf_lock spin_lock section in printk()
>   printk()
> raw_spin_lock(_lock);
> WARN_ON(1);
> raw_spin_unlock(_lock);
> 
> b) printk from sem->lock spin_lock section
>   printk()
> console_trylock()
>   down_trylock()
> raw_spin_lock_irqsave(>lock, flags);
> WARN_ON(1);
> raw_spin_unlock_irqrestore(>lock, flags);
> 
> c) printk from logbuf_lock spin_lock section in console_unlock()
>   printk()
> console_unlock()
>   raw_spin_lock(_lock);
>   WARN_ON(1);
>   raw_spin_unlock(_lock);
> 
> d) printk from ->pi_lock from semaphore up
>   printk()
> console_unlock()
>   up()
> try_to_wake_up()
>   raw_spin_lock_irqsave(>pi_lock, flags);
>   WARN_ON(1);
>   raw_spin_unlock_irqrestore(>pi_lock, flags);

and

e) anything from call_console_drivers() should be fine as well.
   console_unlock() big printing loop is covered by printk_safe,
   need to protect console_cont_flush()->call_console_drivers().

   so printk "direct path" seems to be safe now:

   printk -> .. -> console_unlock() -> call_console_drivers() -> 
serial_console_write()

   anything that is "indirect" is not covered in this patch set.


-ss

Re: [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC

[Jiancheng Xue]

在 2016/10/19 10:45, Rob Herring 写道:
> On Tue, Oct 18, 2016 at 9:38 PM, Jiancheng Xue
>  wrote:
>>
>>
>> 在 2016/10/18 23:58, Rob Herring 写道:
>>> On Mon, Oct 17, 2016 at 08:07:04PM +0800, Pan Wen wrote:
 Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset
 Generator) module generates clock and reset signals used
 by other module blocks on SoC.

 Signed-off-by: Pan Wen 
 ---
  .../devicetree/bindings/clock/hisi-crg.txt |  50 
  drivers/clk/hisilicon/Kconfig  |   8 +
  drivers/clk/hisilicon/Makefile |   1 +
  drivers/clk/hisilicon/crg-hi3516cv300.c| 330 
 +
  drivers/clk/hisilicon/crg.h|  34 +++
  include/dt-bindings/clock/hi3516cv300-clock.h  |  48 +++
  6 files changed, 471 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/clock/hisi-crg.txt
  create mode 100644 drivers/clk/hisilicon/crg-hi3516cv300.c
  create mode 100644 drivers/clk/hisilicon/crg.h
  create mode 100644 include/dt-bindings/clock/hi3516cv300-clock.h

 diff --git a/Documentation/devicetree/bindings/clock/hisi-crg.txt 
 b/Documentation/devicetree/bindings/clock/hisi-crg.txt
 new file mode 100644
 index 000..cc60b3d
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/clock/hisi-crg.txt
 @@ -0,0 +1,50 @@
 +* HiSilicon Clock and Reset Generator(CRG)
>>>
>>> Seems kind of generic given there's already various HiSi clock bindings
>>> documented.
>>>
 +
 +The CRG module provides clock and reset signals to various
 +modules within the SoC.
 +
 +This binding uses the following bindings:
 +Documentation/devicetree/bindings/clock/clock-bindings.txt
 +Documentation/devicetree/bindings/reset/reset.txt
 +
 +Required Properties:
 +
 +- compatible: should be one of the following.
 +  - "hisilicon,hi3516cv300-crg"
 +  - "hisilicon,hi3516cv300-sysctrl"
 +  - "hisilicon,hi3519-crg"
>>>
>>> There is already a binding for this. Please merge them.
>>>
>> Hi Rob,
>>
>> Pan Wen and I work together. There's really a same file included in the patch
>> https://lkml.org/lkml/2016/9/18/42 ([PATCH v2] clk: hisilicon: add CRG 
>> driver for Hi3798CV200 SoC).
>> But that patch has not been acked. This binding file will be merged if that
>> patch is accepted first. Could you give me more comments on that patch or
>> help me to ack it?  Thank you very much.
> 
> If I haven't commented, then likely it was not sent to the DT list.
Hi,

I'm pretty sure that the patch was sent to the DT list 
devicet...@vger.kernel.org.
You had asked a question about "hi3798cv200-sysctrl" and I replied 
(https://lkml.org/lkml/2016/10/10/517).
I'm waiting for your new comments. If there's some misunderstatnding, please 
let me know.

Thanks,
Jiancheng

> 
> Rob
> 
> .
> 

Re: [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC

[Jiancheng Xue]

在 2016/10/19 10:45, Rob Herring 写道:
> On Tue, Oct 18, 2016 at 9:38 PM, Jiancheng Xue
>  wrote:
>>
>>
>> 在 2016/10/18 23:58, Rob Herring 写道:
>>> On Mon, Oct 17, 2016 at 08:07:04PM +0800, Pan Wen wrote:
 Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset
 Generator) module generates clock and reset signals used
 by other module blocks on SoC.

 Signed-off-by: Pan Wen 
 ---
  .../devicetree/bindings/clock/hisi-crg.txt |  50 
  drivers/clk/hisilicon/Kconfig  |   8 +
  drivers/clk/hisilicon/Makefile |   1 +
  drivers/clk/hisilicon/crg-hi3516cv300.c| 330 
 +
  drivers/clk/hisilicon/crg.h|  34 +++
  include/dt-bindings/clock/hi3516cv300-clock.h  |  48 +++
  6 files changed, 471 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/clock/hisi-crg.txt
  create mode 100644 drivers/clk/hisilicon/crg-hi3516cv300.c
  create mode 100644 drivers/clk/hisilicon/crg.h
  create mode 100644 include/dt-bindings/clock/hi3516cv300-clock.h

 diff --git a/Documentation/devicetree/bindings/clock/hisi-crg.txt 
 b/Documentation/devicetree/bindings/clock/hisi-crg.txt
 new file mode 100644
 index 000..cc60b3d
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/clock/hisi-crg.txt
 @@ -0,0 +1,50 @@
 +* HiSilicon Clock and Reset Generator(CRG)
>>>
>>> Seems kind of generic given there's already various HiSi clock bindings
>>> documented.
>>>
 +
 +The CRG module provides clock and reset signals to various
 +modules within the SoC.
 +
 +This binding uses the following bindings:
 +Documentation/devicetree/bindings/clock/clock-bindings.txt
 +Documentation/devicetree/bindings/reset/reset.txt
 +
 +Required Properties:
 +
 +- compatible: should be one of the following.
 +  - "hisilicon,hi3516cv300-crg"
 +  - "hisilicon,hi3516cv300-sysctrl"
 +  - "hisilicon,hi3519-crg"
>>>
>>> There is already a binding for this. Please merge them.
>>>
>> Hi Rob,
>>
>> Pan Wen and I work together. There's really a same file included in the patch
>> https://lkml.org/lkml/2016/9/18/42 ([PATCH v2] clk: hisilicon: add CRG 
>> driver for Hi3798CV200 SoC).
>> But that patch has not been acked. This binding file will be merged if that
>> patch is accepted first. Could you give me more comments on that patch or
>> help me to ack it?  Thank you very much.
> 
> If I haven't commented, then likely it was not sent to the DT list.
Hi,

I'm pretty sure that the patch was sent to the DT list 
devicet...@vger.kernel.org.
You had asked a question about "hi3798cv200-sysctrl" and I replied 
(https://lkml.org/lkml/2016/10/10/517).
I'm waiting for your new comments. If there's some misunderstatnding, please 
let me know.

Thanks,
Jiancheng

> 
> Rob
> 
> .
> 

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

[Dan Williams]

[ adding Ashok and David for potential iommu comments ]

On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates  wrote:
> This patch follows from an RFC we did earlier this year [1]. This
> patchset applies cleanly to v4.9-rc1.
>
> Updates since RFC
> -
>   Rebased.
>   Included the iopmem driver in the submission.
>
> History
> ---
>
> There have been several attempts to upstream patchsets that enable
> DMAs between PCIe peers. These include Peer-Direct [2] and DMA-Buf
> style patches [3]. None have been successful to date. Haggai Eran
> gives a nice overview of the prior art in this space in his cover
> letter [3].
>
> Motivation and Use Cases
> 
>
> PCIe IO devices are getting faster. It is not uncommon now to find PCIe
> network and storage devices that can generate and consume several GB/s.
> Almost always these devices have either a high performance DMA engine, a
> number of exposed PCIe BARs or both.
>
> Until this patch, any high-performance transfer of information between
> two PICe devices has required the use of a staging buffer in system
> memory. With this patch the bandwidth to system memory is not compromised
> when high-throughput transfers occurs between PCIe devices. This means
> that more system memory bandwidth is available to the CPU cores for data
> processing and manipulation. In addition, in systems where the two PCIe
> devices reside behind a PCIe switch the datapath avoids the CPU
> entirely.

I agree with the motivation and the need for a solution, but I have
some questions about this implementation.

>
> Consumers
> -
>
> We provide a PCIe device driver in an accompanying patch that can be
> used to map any PCIe BAR into a DAX capable block device. For
> non-persistent BARs this simply serves as an alternative to using
> system memory bounce buffers. For persistent BARs this can serve as an
> additional storage device in the system.

Why block devices?  I wonder if iopmem was initially designed back
when we were considering enabling DAX for raw block devices.  However,
that support has since been ripped out / abandoned.  You currently
need a filesystem on top of a block-device to get DAX operation.
Putting xfs or ext4 on top of PCI-E memory mapped range seems awkward
if all you want is a way to map the bar for another PCI-E device in
the topology.

If you're only using the block-device as a entry-point to create
dax-mappings then a device-dax (drivers/dax/) character-device might
be a better fit.

>
> Testing and Performance
> ---
>
> We have done a moderate about of testing of this patch on a QEMU
> environment and on real hardware. On real hardware we have observed
> peer-to-peer writes of up to 4GB/s and reads of up to 1.2 GB/s. In
> both cases these numbers are limitations of our consumer hardware. In
> addition, we have observed that the CPU DRAM bandwidth is not impacted
> when using IOPMEM which is not the case when a traditional path
> through system memory is taken.
>
> For more information on the testing and performance results see the
> GitHub site [4].
>
> Known Issues
> 
>
> 1. Address Translation. Suggestions have been made that in certain
> architectures and topologies the dma_addr_t passed to the DMA master
> in a peer-2-peer transfer will not correctly route to the IO memory
> intended. However in our testing to date we have not seen this to be
> an issue, even in systems with IOMMUs and PCIe switches. It is our
> understanding that an IOMMU only maps system memory and would not
> interfere with device memory regions. (It certainly has no opportunity
> to do so if the transfer gets routed through a switch).
>

There may still be platforms where peer-to-peer cycles are routed up
through the root bridge and then back down to target device, but we
can address that when / if it happens.  I wonder if we could (ab)use a
software-defined 'pasid' as the requester id for a peer-to-peer
mapping that needs address translation.

> 2. Memory Segment Spacing. This patch has the same limitations that
> ZONE_DEVICE does in that memory regions must be spaces at least
> SECTION_SIZE bytes part. On x86 this is 128MB and there are cases where
> BARs can be placed closer together than this. Thus ZONE_DEVICE would not
> be usable on neighboring BARs. For our purposes, this is not an issue as
> we'd only be looking at enabling a single BAR in a given PCIe device.
> More exotic use cases may have problems with this.

I'm working on patches for 4.10 to allow mixing multiple
devm_memremap_pages() allocations within the same physical section.
Hopefully this won't be a problem going forward.

> 3. Coherency Issues. When IOMEM is written from both the CPU and a PCIe
> peer there is potential for coherency issues and for writes to occur out
> of order. This is something that users of this feature need to be
> cognizant of. Though really, this isn't much different than the
> existing situation 

Re: [PATCH 0/3] iopmem : A block device for PCIe memory

[Dan Williams]

[ adding Ashok and David for potential iommu comments ]

On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates  wrote:
> This patch follows from an RFC we did earlier this year [1]. This
> patchset applies cleanly to v4.9-rc1.
>
> Updates since RFC
> -
>   Rebased.
>   Included the iopmem driver in the submission.
>
> History
> ---
>
> There have been several attempts to upstream patchsets that enable
> DMAs between PCIe peers. These include Peer-Direct [2] and DMA-Buf
> style patches [3]. None have been successful to date. Haggai Eran
> gives a nice overview of the prior art in this space in his cover
> letter [3].
>
> Motivation and Use Cases
> 
>
> PCIe IO devices are getting faster. It is not uncommon now to find PCIe
> network and storage devices that can generate and consume several GB/s.
> Almost always these devices have either a high performance DMA engine, a
> number of exposed PCIe BARs or both.
>
> Until this patch, any high-performance transfer of information between
> two PICe devices has required the use of a staging buffer in system
> memory. With this patch the bandwidth to system memory is not compromised
> when high-throughput transfers occurs between PCIe devices. This means
> that more system memory bandwidth is available to the CPU cores for data
> processing and manipulation. In addition, in systems where the two PCIe
> devices reside behind a PCIe switch the datapath avoids the CPU
> entirely.

I agree with the motivation and the need for a solution, but I have
some questions about this implementation.

>
> Consumers
> -
>
> We provide a PCIe device driver in an accompanying patch that can be
> used to map any PCIe BAR into a DAX capable block device. For
> non-persistent BARs this simply serves as an alternative to using
> system memory bounce buffers. For persistent BARs this can serve as an
> additional storage device in the system.

Why block devices?  I wonder if iopmem was initially designed back
when we were considering enabling DAX for raw block devices.  However,
that support has since been ripped out / abandoned.  You currently
need a filesystem on top of a block-device to get DAX operation.
Putting xfs or ext4 on top of PCI-E memory mapped range seems awkward
if all you want is a way to map the bar for another PCI-E device in
the topology.

If you're only using the block-device as a entry-point to create
dax-mappings then a device-dax (drivers/dax/) character-device might
be a better fit.

>
> Testing and Performance
> ---
>
> We have done a moderate about of testing of this patch on a QEMU
> environment and on real hardware. On real hardware we have observed
> peer-to-peer writes of up to 4GB/s and reads of up to 1.2 GB/s. In
> both cases these numbers are limitations of our consumer hardware. In
> addition, we have observed that the CPU DRAM bandwidth is not impacted
> when using IOPMEM which is not the case when a traditional path
> through system memory is taken.
>
> For more information on the testing and performance results see the
> GitHub site [4].
>
> Known Issues
> 
>
> 1. Address Translation. Suggestions have been made that in certain
> architectures and topologies the dma_addr_t passed to the DMA master
> in a peer-2-peer transfer will not correctly route to the IO memory
> intended. However in our testing to date we have not seen this to be
> an issue, even in systems with IOMMUs and PCIe switches. It is our
> understanding that an IOMMU only maps system memory and would not
> interfere with device memory regions. (It certainly has no opportunity
> to do so if the transfer gets routed through a switch).
>

There may still be platforms where peer-to-peer cycles are routed up
through the root bridge and then back down to target device, but we
can address that when / if it happens.  I wonder if we could (ab)use a
software-defined 'pasid' as the requester id for a peer-to-peer
mapping that needs address translation.

> 2. Memory Segment Spacing. This patch has the same limitations that
> ZONE_DEVICE does in that memory regions must be spaces at least
> SECTION_SIZE bytes part. On x86 this is 128MB and there are cases where
> BARs can be placed closer together than this. Thus ZONE_DEVICE would not
> be usable on neighboring BARs. For our purposes, this is not an issue as
> we'd only be looking at enabling a single BAR in a given PCIe device.
> More exotic use cases may have problems with this.

I'm working on patches for 4.10 to allow mixing multiple
devm_memremap_pages() allocations within the same physical section.
Hopefully this won't be a problem going forward.

> 3. Coherency Issues. When IOMEM is written from both the CPU and a PCIe
> peer there is potential for coherency issues and for writes to occur out
> of order. This is something that users of this feature need to be
> cognizant of. Though really, this isn't much different than the
> existing situation with things like RDMA: 

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

[Herbert Xu]

On Mon, Oct 17, 2016 at 10:06:27AM -0700, Andy Lutomirski wrote:
> hw_random carefully avoids using a stack buffer except in
> add_early_randomness().  This causes a crash in virtio_rng if
> CONFIG_VMAP_STACK=y.
> 
> Reported-by: Matt Mullins 
> Tested-by: Matt Mullins 
> Fixes: d3cc7996473a ("hwrng: fetch randomness only after device init")
> Signed-off-by: Andy Lutomirski 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

[Herbert Xu]

On Mon, Oct 17, 2016 at 10:06:27AM -0700, Andy Lutomirski wrote:
> hw_random carefully avoids using a stack buffer except in
> add_early_randomness().  This causes a crash in virtio_rng if
> CONFIG_VMAP_STACK=y.
> 
> Reported-by: Matt Mullins 
> Tested-by: Matt Mullins 
> Fixes: d3cc7996473a ("hwrng: fetch randomness only after device init")
> Signed-off-by: Andy Lutomirski 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[REVIEW][PATCH] mount: In propagate_umount handle overlapping mount propagation trees

[Eric W. Biederman]

Adrei Vagin pointed out that time to executue propagate_umount can go
non-linear (and take a ludicrious amount of time) when the mount
propogation trees of the mounts to be unmunted by a lazy unmount
overlap.

While investigating the horrible performance I realized that in
the case overlapping mount trees since the addition of locked
mount support the code has been failing to unmount all of the
mounts it should have been unmounting.

Make the walk of the mount propagation trees nearly linear by using
MNT_MARK to mark pieces of the mount propagation trees that have
already been visited, allowing subsequent walks to skip over
subtrees.

Make the processing of mounts order independent by adding a list of
mount entries that need to be unmounted, and simply adding a mount to
that list when it becomes apparent the mount can safely be unmounted.
For mounts that are locked on other mounts but otherwise could be
unmounted move them from their parnets mnt_mounts to mnt_umounts so
that if and when their parent becomes unmounted these mounts can be
added to the list of mounts to unmount.

Add a final pass to clear MNT_MARK and to restore mnt_mounts
from mnt_umounts for anything that did not get unmounted.

Add the functions propagation_visit_next and propagation_revisit_next
to coordinate walking of the mount tree and setting and clearing the
mount mark.

The skipping of already unmounted mounts has been moved from
__lookup_mnt_last to mark_umount_candidates, so that the new
propagation functions can notice when the propagation tree passes
through the initial set of unmounted mounts.  Except in umount_tree as
part of the unmounting process the only place where unmounted mounts
should be found are in unmounted subtrees.  All of the other callers
of __lookup_mnt_last are from mounted subtrees so the not checking for
unmounted mounts should not affect them.

A script to generate overlapping mount propagation trees:
$ cat run.sh
mount -t tmpfs test-mount /mnt
mount --make-shared /mnt
for i in `seq $1`; do
mkdir /mnt/test.$i
mount --bind /mnt /mnt/test.$i
done
cat /proc/mounts | grep test-mount | wc -l
time umount -l /mnt
$ for i in `seq 10 16`; do echo $i; unshare -Urm bash ./run.sh $i; done

Here are the performance numbers with and without the patch:

mhash  |  8192   |  8192  |  8192   | 131072 | 131072  | 104857 | 104857
mounts | before  | after  | after (sys) | after  | after (sys) |  after | after 
(sys)
-
  1024 |  0.071s | 0.020s | 0.000s  | 0.022s | 0.004s  | 0.020s | 0.004s
  2048 |  0.184s | 0.022s | 0.004s  | 0.023s | 0.004s  | 0.022s | 0.008s
  4096 |  0.604s | 0.025s | 0.020s  | 0.029s | 0.008s  | 0.026s | 0.004s
  8912 |  4.471s | 0.053s | 0.020s  | 0.051s | 0.024s  | 0.047s | 0.016s
 16384 | 34.826s | 0.088s | 0.060s  | 0.081s | 0.048s  | 0.082s | 0.052s
 32768 | | 0.216s | 0.172s  | 0.160s | 0.124s  | 0.160s | 0.096s
 65536 | | 0.819s | 0.726s  | 0.330s | 0.260s  | 0.338s | 0.256s
131072 | | 4.502s | 4.168s  | 0.707s | 0.580s  | 0.709s | 0.592s

Andrei Vagin reports fixing the performance problem is part of the
work to fix CVE-2016-6213.

A script for a pathlogical set of mounts:

$ cat pathological.sh

mount -t tmpfs base /mnt
mount --make-shared /mnt
mkdir -p /mnt/b

mount -t tmpfs test1 /mnt/b
mount --make-shared /mnt/b
mkdir -p /mnt/b/10

mount -t tmpfs test2 /mnt/b/10
mount --make-shared /mnt/b/10
mkdir -p /mnt/b/10/20

mount --rbind /mnt/b /mnt/b/10/20

unshare -Urm sleep 2
umount -l /mnt/b
wait %%

$ unsahre -Urm pathlogical.sh

Cc: sta...@vger.kernel.org
Fixes: a05964f3917c ("[PATCH] shared mounts handling: umount")
Fixes: 0c56fe31420c ("mnt: Don't propagate unmounts to locked mounts")
Reported-by: Andrei Vagin 
Signed-off-by: "Eric W. Biederman" 
---

Barring some stupid mistake this looks like it fixes both the performance
and the correctness issues I was able to spot earlier.  Andrei if you
could give this version a look over I would appreciate it.

Unless we can find a problem I am going to call this the final version.

 fs/mount.h |   1 +
 fs/namespace.c |   7 +-
 fs/pnode.c | 198 ++---
 fs/pnode.h |   2 +-
 4 files changed, 165 insertions(+), 43 deletions(-)

diff --git a/fs/mount.h b/fs/mount.h
index d2e25d7b64b3..00fe0d1d6ba7 100644
--- a/fs/mount.h
+++ b/fs/mount.h
@@ -58,6 +58,7 @@ struct mount {
struct mnt_namespace *mnt_ns;   /* containing namespace */
struct mountpoint *mnt_mp;  /* where is it mounted */
struct hlist_node mnt_mp_list;  /* list mounts with the same mountpoint 
*/
+   struct list_head mnt_umounts;   /* list of children that are being 
unmounted */
 #ifdef CONFIG_FSNOTIFY
struct hlist_head mnt_fsnotify_marks;
__u32 

[REVIEW][PATCH] mount: In propagate_umount handle overlapping mount propagation trees

[Eric W. Biederman]

Adrei Vagin pointed out that time to executue propagate_umount can go
non-linear (and take a ludicrious amount of time) when the mount
propogation trees of the mounts to be unmunted by a lazy unmount
overlap.

While investigating the horrible performance I realized that in
the case overlapping mount trees since the addition of locked
mount support the code has been failing to unmount all of the
mounts it should have been unmounting.

Make the walk of the mount propagation trees nearly linear by using
MNT_MARK to mark pieces of the mount propagation trees that have
already been visited, allowing subsequent walks to skip over
subtrees.

Make the processing of mounts order independent by adding a list of
mount entries that need to be unmounted, and simply adding a mount to
that list when it becomes apparent the mount can safely be unmounted.
For mounts that are locked on other mounts but otherwise could be
unmounted move them from their parnets mnt_mounts to mnt_umounts so
that if and when their parent becomes unmounted these mounts can be
added to the list of mounts to unmount.

Add a final pass to clear MNT_MARK and to restore mnt_mounts
from mnt_umounts for anything that did not get unmounted.

Add the functions propagation_visit_next and propagation_revisit_next
to coordinate walking of the mount tree and setting and clearing the
mount mark.

The skipping of already unmounted mounts has been moved from
__lookup_mnt_last to mark_umount_candidates, so that the new
propagation functions can notice when the propagation tree passes
through the initial set of unmounted mounts.  Except in umount_tree as
part of the unmounting process the only place where unmounted mounts
should be found are in unmounted subtrees.  All of the other callers
of __lookup_mnt_last are from mounted subtrees so the not checking for
unmounted mounts should not affect them.

A script to generate overlapping mount propagation trees:
$ cat run.sh
mount -t tmpfs test-mount /mnt
mount --make-shared /mnt
for i in `seq $1`; do
mkdir /mnt/test.$i
mount --bind /mnt /mnt/test.$i
done
cat /proc/mounts | grep test-mount | wc -l
time umount -l /mnt
$ for i in `seq 10 16`; do echo $i; unshare -Urm bash ./run.sh $i; done

Here are the performance numbers with and without the patch:

mhash  |  8192   |  8192  |  8192   | 131072 | 131072  | 104857 | 104857
mounts | before  | after  | after (sys) | after  | after (sys) |  after | after 
(sys)
-
  1024 |  0.071s | 0.020s | 0.000s  | 0.022s | 0.004s  | 0.020s | 0.004s
  2048 |  0.184s | 0.022s | 0.004s  | 0.023s | 0.004s  | 0.022s | 0.008s
  4096 |  0.604s | 0.025s | 0.020s  | 0.029s | 0.008s  | 0.026s | 0.004s
  8912 |  4.471s | 0.053s | 0.020s  | 0.051s | 0.024s  | 0.047s | 0.016s
 16384 | 34.826s | 0.088s | 0.060s  | 0.081s | 0.048s  | 0.082s | 0.052s
 32768 | | 0.216s | 0.172s  | 0.160s | 0.124s  | 0.160s | 0.096s
 65536 | | 0.819s | 0.726s  | 0.330s | 0.260s  | 0.338s | 0.256s
131072 | | 4.502s | 4.168s  | 0.707s | 0.580s  | 0.709s | 0.592s

Andrei Vagin reports fixing the performance problem is part of the
work to fix CVE-2016-6213.

A script for a pathlogical set of mounts:

$ cat pathological.sh

mount -t tmpfs base /mnt
mount --make-shared /mnt
mkdir -p /mnt/b

mount -t tmpfs test1 /mnt/b
mount --make-shared /mnt/b
mkdir -p /mnt/b/10

mount -t tmpfs test2 /mnt/b/10
mount --make-shared /mnt/b/10
mkdir -p /mnt/b/10/20

mount --rbind /mnt/b /mnt/b/10/20

unshare -Urm sleep 2
umount -l /mnt/b
wait %%

$ unsahre -Urm pathlogical.sh

Cc: sta...@vger.kernel.org
Fixes: a05964f3917c ("[PATCH] shared mounts handling: umount")
Fixes: 0c56fe31420c ("mnt: Don't propagate unmounts to locked mounts")
Reported-by: Andrei Vagin 
Signed-off-by: "Eric W. Biederman" 
---

Barring some stupid mistake this looks like it fixes both the performance
and the correctness issues I was able to spot earlier.  Andrei if you
could give this version a look over I would appreciate it.

Unless we can find a problem I am going to call this the final version.

 fs/mount.h |   1 +
 fs/namespace.c |   7 +-
 fs/pnode.c | 198 ++---
 fs/pnode.h |   2 +-
 4 files changed, 165 insertions(+), 43 deletions(-)

diff --git a/fs/mount.h b/fs/mount.h
index d2e25d7b64b3..00fe0d1d6ba7 100644
--- a/fs/mount.h
+++ b/fs/mount.h
@@ -58,6 +58,7 @@ struct mount {
struct mnt_namespace *mnt_ns;   /* containing namespace */
struct mountpoint *mnt_mp;  /* where is it mounted */
struct hlist_node mnt_mp_list;  /* list mounts with the same mountpoint 
*/
+   struct list_head mnt_umounts;   /* list of children that are being 
unmounted */
 #ifdef CONFIG_FSNOTIFY
struct hlist_head mnt_fsnotify_marks;
__u32 mnt_fsnotify_mask;
diff --git a/fs/namespace.c 

[PATCH] tools: hv: clean up code, remove unnecessary header files and link flags

[Weibing Zhang]

Remove unnecessary header files and netlink related code as the daemons
do not use netlink to communicate with the kernel now.
Fix a compile warning in snprintf.
Pthread is also not needed.

Signed-off-by: Weibing Zhang 
---
 tools/hv/Makefile  | 3 +--
 tools/hv/hv_fcopy_daemon.c | 7 ---
 tools/hv/hv_kvp_daemon.c   | 9 +
 3 files changed, 2 insertions(+), 17 deletions(-)

diff --git a/tools/hv/Makefile b/tools/hv/Makefile
index a8c4644..0d1e61b 100644
--- a/tools/hv/Makefile
+++ b/tools/hv/Makefile
@@ -1,9 +1,8 @@
 # Makefile for Hyper-V tools
 
 CC = $(CROSS_COMPILE)gcc
-PTHREAD_LIBS = -lpthread
 WARNINGS = -Wall -Wextra
-CFLAGS = $(WARNINGS) -g $(PTHREAD_LIBS) $(shell getconf LFS_CFLAGS)
+CFLAGS = $(WARNINGS) -g $(shell getconf LFS_CFLAGS)
 
 CFLAGS += -D__EXPORTED_HEADERS__ -I../../include/uapi -I../../include
 
diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv/hv_fcopy_daemon.c
index fdc9ca4..26ae609 100644
--- a/tools/hv/hv_fcopy_daemon.c
+++ b/tools/hv/hv_fcopy_daemon.c
@@ -18,21 +18,14 @@
 
 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 static int target_fd;
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index bc7adb8..d791dbf 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -22,8 +22,6 @@
  */
 
 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -34,7 +32,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -99,10 +96,6 @@ static struct utsname uts_buf;
 #define MAX_FILE_NAME 100
 #define ENTRIES_PER_BLOCK 50
 
-#ifndef SOL_NETLINK
-#define SOL_NETLINK 270
-#endif
-
 struct kvp_record {
char key[HV_KVP_EXCHANGE_MAX_KEY_SIZE];
char value[HV_KVP_EXCHANGE_MAX_VALUE_SIZE];
@@ -702,7 +695,7 @@ static char *kvp_mac_to_if_name(char *mac)
if (dir == NULL)
return NULL;
 
-   snprintf(dev_id, sizeof(dev_id), kvp_net_dir);
+   snprintf(dev_id, sizeof(dev_id), "%s", kvp_net_dir);
q = dev_id + strlen(kvp_net_dir);
 
while ((entry = readdir(dir)) != NULL) {
-- 
2.7.4

[PATCH] tools: hv: clean up code, remove unnecessary header files and link flags

[Weibing Zhang]

Remove unnecessary header files and netlink related code as the daemons
do not use netlink to communicate with the kernel now.
Fix a compile warning in snprintf.
Pthread is also not needed.

Signed-off-by: Weibing Zhang 
---
 tools/hv/Makefile  | 3 +--
 tools/hv/hv_fcopy_daemon.c | 7 ---
 tools/hv/hv_kvp_daemon.c   | 9 +
 3 files changed, 2 insertions(+), 17 deletions(-)

diff --git a/tools/hv/Makefile b/tools/hv/Makefile
index a8c4644..0d1e61b 100644
--- a/tools/hv/Makefile
+++ b/tools/hv/Makefile
@@ -1,9 +1,8 @@
 # Makefile for Hyper-V tools
 
 CC = $(CROSS_COMPILE)gcc
-PTHREAD_LIBS = -lpthread
 WARNINGS = -Wall -Wextra
-CFLAGS = $(WARNINGS) -g $(PTHREAD_LIBS) $(shell getconf LFS_CFLAGS)
+CFLAGS = $(WARNINGS) -g $(shell getconf LFS_CFLAGS)
 
 CFLAGS += -D__EXPORTED_HEADERS__ -I../../include/uapi -I../../include
 
diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv/hv_fcopy_daemon.c
index fdc9ca4..26ae609 100644
--- a/tools/hv/hv_fcopy_daemon.c
+++ b/tools/hv/hv_fcopy_daemon.c
@@ -18,21 +18,14 @@
 
 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 static int target_fd;
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index bc7adb8..d791dbf 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -22,8 +22,6 @@
  */
 
 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -34,7 +32,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -99,10 +96,6 @@ static struct utsname uts_buf;
 #define MAX_FILE_NAME 100
 #define ENTRIES_PER_BLOCK 50
 
-#ifndef SOL_NETLINK
-#define SOL_NETLINK 270
-#endif
-
 struct kvp_record {
char key[HV_KVP_EXCHANGE_MAX_KEY_SIZE];
char value[HV_KVP_EXCHANGE_MAX_VALUE_SIZE];
@@ -702,7 +695,7 @@ static char *kvp_mac_to_if_name(char *mac)
if (dir == NULL)
return NULL;
 
-   snprintf(dev_id, sizeof(dev_id), kvp_net_dir);
+   snprintf(dev_id, sizeof(dev_id), "%s", kvp_net_dir);
q = dev_id + strlen(kvp_net_dir);
 
while ((entry = readdir(dir)) != NULL) {
-- 
2.7.4

Re: [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200 speed from rk3288-veyron-speedy.

[Vagrant Cascadian]

On 2016-10-18, Paul Kocialkowski wrote:
> Le mardi 18 octobre 2016 à 11:21 +0200, Heiko Stübner a écrit :
>> Am Sonntag, 16. Oktober 2016, 21:49:43 schrieb Paul Kocialkowski:
>> > Le mardi 27 septembre 2016 à 13:53 -0700, Vagrant Cascadian a écrit :
>> > > 
>> > > This essentially mimics what was done with rk3288-veyron-minnie in
>> > > commit 984926781122f034d5bc9962815d135b6c4a8e1d.
>> > > 
>> > > The eMMC of the speedy Chromebook also appears to need the same tuning
>> > > workaround, as it frequently fails to recognize the eMMC without it.
>> > 
>> > I have a device where (without this patch) eMMC sometimes fails, with:
>> > [3.561010] dwmmc_rockchip ff0f.dwmmc: Successfully tuned phase to
>> > 175 [3.571742] mmc2: new HS200 MMC card at address 0001
>> > [3.571943] mmcblk2: mmc2:0001 HAG2e 14.7 GiB 
>> > [3.572026] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
>> > [3.572107] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
>> > [3.572181] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
>> > [3.685647] mmcblk2: error -110 transferring data, sector 0, nr 8, cmd
>> > response 0x900, card status 0x0

>> > And sometimes works, with:
>> > [3.451058] dwmmc_rockchip ff0f.dwmmc: Successfully tuned phase to
>> > 176 [3.491093] mmc2: new HS200 MMC card at address 0001
>> > [3.491277] mmcblk2: mmc2:0001 HAG2e 14.7 GiB 
>> > [3.491345] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
>> > [3.491409] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
>> > [3.491474] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
>> > [3.493548]  mmcblk2: p1 p2

This is similar behavior to my veyron-speedy. Here are several boot logs
From running 4.8.0-rc7, with some failures and some successes:

  https://cascadia.aikidev.net/~vagrant/veyron-speedy/


>> > However, with this change, it always fails, with:
>> > [3.322129] mmc_host mmc2: Bus speed (slot 0) = 5000Hz (slot req
>> > 5200Hz, actual 5000HZ div = 0) [3.333174] mmc2: error -110
>> > whilst initialising MMC card
>> > 
>> > I don't have so much time to investigate this issue, but it's clear that
>> > this patch doesn't fix the issue (and actually worsens it) for my device.

Well, that makes things more complicated.


>> As discussed on IRC we now have varying reports of the emmc working or not 
>> working with and without that patch applied. So it's not really a bandaid 
>> fix 
>> and I've thus dropped this patch again.
>
> Thanks for dropping it! For the record, my eMMC shows up as:
> mmcblk2: mmc2:0001 HAG2e 14.7 GiB

Mine looks similar, although reporting as mmc0:

  [3.166550] mmcblk0: mmc0:0001 HAG2e 14.7 GiB


> Maybe it could help to share what each tested device reports as eMMC model and
> associate that with the current behavior, in spite of getting a clearer idea 
> of
> what issue affects what model.

FWIW, I'm using a veyron-speedy with 4GB of ram, not sure what other
information might be useful to distinguish between different models.

On the bottom of the case, it claims to be a C201P. Near the serial,
it's marked as C201PA-DS02-LG.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200 speed from rk3288-veyron-speedy.

[Vagrant Cascadian]

On 2016-10-18, Paul Kocialkowski wrote:
> Le mardi 18 octobre 2016 à 11:21 +0200, Heiko Stübner a écrit :
>> Am Sonntag, 16. Oktober 2016, 21:49:43 schrieb Paul Kocialkowski:
>> > Le mardi 27 septembre 2016 à 13:53 -0700, Vagrant Cascadian a écrit :
>> > > 
>> > > This essentially mimics what was done with rk3288-veyron-minnie in
>> > > commit 984926781122f034d5bc9962815d135b6c4a8e1d.
>> > > 
>> > > The eMMC of the speedy Chromebook also appears to need the same tuning
>> > > workaround, as it frequently fails to recognize the eMMC without it.
>> > 
>> > I have a device where (without this patch) eMMC sometimes fails, with:
>> > [3.561010] dwmmc_rockchip ff0f.dwmmc: Successfully tuned phase to
>> > 175 [3.571742] mmc2: new HS200 MMC card at address 0001
>> > [3.571943] mmcblk2: mmc2:0001 HAG2e 14.7 GiB 
>> > [3.572026] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
>> > [3.572107] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
>> > [3.572181] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
>> > [3.685647] mmcblk2: error -110 transferring data, sector 0, nr 8, cmd
>> > response 0x900, card status 0x0

>> > And sometimes works, with:
>> > [3.451058] dwmmc_rockchip ff0f.dwmmc: Successfully tuned phase to
>> > 176 [3.491093] mmc2: new HS200 MMC card at address 0001
>> > [3.491277] mmcblk2: mmc2:0001 HAG2e 14.7 GiB 
>> > [3.491345] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
>> > [3.491409] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
>> > [3.491474] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
>> > [3.493548]  mmcblk2: p1 p2

This is similar behavior to my veyron-speedy. Here are several boot logs
From running 4.8.0-rc7, with some failures and some successes:

  https://cascadia.aikidev.net/~vagrant/veyron-speedy/


>> > However, with this change, it always fails, with:
>> > [3.322129] mmc_host mmc2: Bus speed (slot 0) = 5000Hz (slot req
>> > 5200Hz, actual 5000HZ div = 0) [3.333174] mmc2: error -110
>> > whilst initialising MMC card
>> > 
>> > I don't have so much time to investigate this issue, but it's clear that
>> > this patch doesn't fix the issue (and actually worsens it) for my device.

Well, that makes things more complicated.


>> As discussed on IRC we now have varying reports of the emmc working or not 
>> working with and without that patch applied. So it's not really a bandaid 
>> fix 
>> and I've thus dropped this patch again.
>
> Thanks for dropping it! For the record, my eMMC shows up as:
> mmcblk2: mmc2:0001 HAG2e 14.7 GiB

Mine looks similar, although reporting as mmc0:

  [3.166550] mmcblk0: mmc0:0001 HAG2e 14.7 GiB


> Maybe it could help to share what each tested device reports as eMMC model and
> associate that with the current behavior, in spite of getting a clearer idea 
> of
> what issue affects what model.

FWIW, I'm using a veyron-speedy with 4GB of ram, not sure what other
information might be useful to distinguish between different models.

On the bottom of the case, it claims to be a C201P. Near the serial,
it's marked as C201PA-DS02-LG.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [patch] power: supply: lp8788: remove an unneeded NULL check

[Sebastian Reichel]

Hi Dan,

On Fri, Oct 14, 2016 at 10:33:28AM +0300, Dan Carpenter wrote:
> We checked that "pdata->chg_params" is non-NULL earlier in this function
> so when we add "i" to it, it's still non-NULL.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/power/supply/lp8788-charger.c 
> b/drivers/power/supply/lp8788-charger.c
> index 7321b72..509e2b3 100644
> --- a/drivers/power/supply/lp8788-charger.c
> +++ b/drivers/power/supply/lp8788-charger.c
> @@ -384,9 +384,6 @@ static int lp8788_update_charger_params(struct 
> platform_device *pdev,
>   for (i = 0; i < pdata->num_chg_params; i++) {
>   param = pdata->chg_params + i;
>  
> - if (!param)
> - continue;
> -
>   if (lp8788_is_valid_charger_register(param->addr)) {
>   ret = lp8788_write_byte(lp, param->addr, param->val);
>   if (ret)

Thanks, queued.

-- Sebastian


signature.asc
Description: PGP signature

Re: [patch] power: supply: lp8788: remove an unneeded NULL check

[Sebastian Reichel]

Hi Dan,

On Fri, Oct 14, 2016 at 10:33:28AM +0300, Dan Carpenter wrote:
> We checked that "pdata->chg_params" is non-NULL earlier in this function
> so when we add "i" to it, it's still non-NULL.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/power/supply/lp8788-charger.c 
> b/drivers/power/supply/lp8788-charger.c
> index 7321b72..509e2b3 100644
> --- a/drivers/power/supply/lp8788-charger.c
> +++ b/drivers/power/supply/lp8788-charger.c
> @@ -384,9 +384,6 @@ static int lp8788_update_charger_params(struct 
> platform_device *pdev,
>   for (i = 0; i < pdata->num_chg_params; i++) {
>   param = pdata->chg_params + i;
>  
> - if (!param)
> - continue;
> -
>   if (lp8788_is_valid_charger_register(param->addr)) {
>   ret = lp8788_write_byte(lp, param->addr, param->val);
>   if (ret)

Thanks, queued.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 0/2] power: supply: Fix module autoload for some platform drivers

[Sebastian Reichel]

Hi Javier,

On Mon, Oct 17, 2016 at 04:13:34PM -0300, Javier Martinez Canillas wrote:
> Hello Sebastian,
> 
> I noticed that module autoload won't be working for some of the power
> supply platform drivers. This patch series contains fixes for these.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (2):
>   power: supply: max8997_charger: Fix module autoload
>   power: supply: axp288_fuel_gauge: Fix module autoload
> 
>  drivers/power/supply/axp288_fuel_gauge.c | 1 +
>  drivers/power/supply/max8997_charger.c   | 1 +
>  2 files changed, 2 insertions(+)

Thanks, queued.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 0/2] power: supply: Fix module autoload for some platform drivers

[Sebastian Reichel]

Hi Javier,

On Mon, Oct 17, 2016 at 04:13:34PM -0300, Javier Martinez Canillas wrote:
> Hello Sebastian,
> 
> I noticed that module autoload won't be working for some of the power
> supply platform drivers. This patch series contains fixes for these.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (2):
>   power: supply: max8997_charger: Fix module autoload
>   power: supply: axp288_fuel_gauge: Fix module autoload
> 
>  drivers/power/supply/axp288_fuel_gauge.c | 1 +
>  drivers/power/supply/max8997_charger.c   | 1 +
>  2 files changed, 2 insertions(+)

Thanks, queued.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 0/4] power: reset: Fix module autoload for some platform drivers

[Sebastian Reichel]

Hi Javier,

On Mon, Oct 17, 2016 at 03:36:11PM -0300, Javier Martinez Canillas wrote:
> I noticed that module autoload won't be working in a some of the reset
> platform drivers This patch series contains the fixes for these.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (4):
>   power: reset: at91-reset: Fix module autoload
>   power: reset: at91-poweroff: Fix module autoload
>   power: reset: syscon-reboot-mode: Fix module autoload
>   power: reset: zx-reboot: Fix module autoload
> 
>  drivers/power/reset/at91-poweroff.c  | 1 +
>  drivers/power/reset/at91-reset.c | 2 ++
>  drivers/power/reset/syscon-reboot-mode.c | 1 +
>  drivers/power/reset/zx-reboot.c  | 1 +
>  4 files changed, 5 insertions(+)

Thanks, queued.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 0/4] power: reset: Fix module autoload for some platform drivers

[Sebastian Reichel]

Hi Javier,

On Mon, Oct 17, 2016 at 03:36:11PM -0300, Javier Martinez Canillas wrote:
> I noticed that module autoload won't be working in a some of the reset
> platform drivers This patch series contains the fixes for these.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (4):
>   power: reset: at91-reset: Fix module autoload
>   power: reset: at91-poweroff: Fix module autoload
>   power: reset: syscon-reboot-mode: Fix module autoload
>   power: reset: zx-reboot: Fix module autoload
> 
>  drivers/power/reset/at91-poweroff.c  | 1 +
>  drivers/power/reset/at91-reset.c | 2 ++
>  drivers/power/reset/syscon-reboot-mode.c | 1 +
>  drivers/power/reset/zx-reboot.c  | 1 +
>  4 files changed, 5 insertions(+)

Thanks, queued.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

[Herbert Xu]

On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote:
>
> Annoyingly, all this complication with scatterlists etc is for doing
> asynchronous crypto via DMA capable crypto accelerators, and the
> networking code (ipsec as well as mac80211, afaik) only allow
> synchronous in the first place, given that they execute in softirq
> context.

I'm still thinking about the issue (in particular, whether we
should continue to rely on the request context being SG-capable
or allow it to be on the stack for AEAD).

But IPsec definitely supports async crypto.  In fact it was the
very first user of async crypto.

mac80211 on the other hand is currently sync-only.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

[Herbert Xu]

On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote:
>
> Annoyingly, all this complication with scatterlists etc is for doing
> asynchronous crypto via DMA capable crypto accelerators, and the
> networking code (ipsec as well as mac80211, afaik) only allow
> synchronous in the first place, given that they execute in softirq
> context.

I'm still thinking about the issue (in particular, whether we
should continue to rely on the request context being SG-capable
or allow it to be on the stack for AEAD).

But IPsec definitely supports async crypto.  In fact it was the
very first user of async crypto.

mac80211 on the other hand is currently sync-only.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] dmaengine: dmatest: Restore "memcpy" as default mode

[Vinod Koul]

On Tue, Oct 18, 2016 at 11:14:08AM -0700, Dave Jiang wrote:
> On 09/15/2016 08:48 AM, Vinod Koul wrote:
> > On Wed, Sep 14, 2016 at 08:40:38PM +0300, Eugeniy Paltsev wrote:
> >> Commit 0d4cb44da6ca0e8 ("dmaengine: dmatest: Add support for
> >> scatter-gather DMA mode") changes default "dmatest" behavior by
> >> changing default mode from "memcpy" to "scatter-gather".
> >> Now "memcpy" gets back as default mode.
> > 
> > Applied, thanks
> 
> Did that go into stable? It's breaking the default expected behavior in
> 4.8 without the fix.

No it wasnt, and it should have...

I send to stable and lokks like it should applied on 4.7 and 4.8.
Commit 0d4cb44da6ca0e8 ("dmaengine: dmatest: Add support for scatter-gather
DMA mode") came in 4.7 IIUC..

Thanks
-- 
~Vinod

Re: [PATCH] dmaengine: dmatest: Restore "memcpy" as default mode

[Vinod Koul]

On Tue, Oct 18, 2016 at 11:14:08AM -0700, Dave Jiang wrote:
> On 09/15/2016 08:48 AM, Vinod Koul wrote:
> > On Wed, Sep 14, 2016 at 08:40:38PM +0300, Eugeniy Paltsev wrote:
> >> Commit 0d4cb44da6ca0e8 ("dmaengine: dmatest: Add support for
> >> scatter-gather DMA mode") changes default "dmatest" behavior by
> >> changing default mode from "memcpy" to "scatter-gather".
> >> Now "memcpy" gets back as default mode.
> > 
> > Applied, thanks
> 
> Did that go into stable? It's breaking the default expected behavior in
> 4.8 without the fix.

No it wasnt, and it should have...

I send to stable and lokks like it should applied on 4.7 and 4.8.
Commit 0d4cb44da6ca0e8 ("dmaengine: dmatest: Add support for scatter-gather
DMA mode") came in 4.7 IIUC..

Thanks
-- 
~Vinod

Re: [PATCH] mm/hugetlb: Use the right pte val for compare in hugetlb_cow

[Hillf Danton]

On Tuesday, October 18, 2016 11:43 PM Aneesh Kumar K.V wrote:
> 
> We cannot use the pte value used in set_pte_at for pte_same comparison,
> because archs like ppc64, filter/add new pte flag in set_pte_at. Instead
> fetch the pte value inside hugetlb_cow. We are comparing pte value to
> make sure the pte didn't change since we dropped the page table lock.
> hugetlb_cow get called with page table lock held, and we can take a copy
> of the pte value before we drop the page table lock.
> 
> With hugetlbfs, we optimize the MAP_PRIVATE write fault path with no
> previous mapping (huge_pte_none entries), by forcing a cow in the fault
> path. This avoid take an addition fault to covert a read-only mapping
> to read/write. Here we were comparing a recently instantiated pte (via
> set_pte_at) to the pte values from linux page table. As explained above
> on ppc64 such pte_same check returned wrong result, resulting in us
> taking an additional fault on ppc64.
> 
> Fixes: 6a119eae942c ("powerpc/mm: Add a _PAGE_PTE bit")
> 
> Reported-by: Jan Stancek 
> Signed-off-by: Aneesh Kumar K.V 
> ---

Acked-by: Hillf Danton 

>  mm/hugetlb.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index ec49d9ef1eef..da8fbd02b92e 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3386,15 +3386,17 @@ static void unmap_ref_private(struct mm_struct *mm, 
> struct vm_area_struct *vma,
>   * Keep the pte_same checks anyway to make transition from the mutex easier.
>   */
>  static int hugetlb_cow(struct mm_struct *mm, struct vm_area_struct *vma,
> - unsigned long address, pte_t *ptep, pte_t pte,
> - struct page *pagecache_page, spinlock_t *ptl)
> +unsigned long address, pte_t *ptep,
> +struct page *pagecache_page, spinlock_t *ptl)
>  {
> + pte_t pte;
>   struct hstate *h = hstate_vma(vma);
>   struct page *old_page, *new_page;
>   int ret = 0, outside_reserve = 0;
>   unsigned long mmun_start;   /* For mmu_notifiers */
>   unsigned long mmun_end; /* For mmu_notifiers */
> 
> + pte = huge_ptep_get(ptep);
>   old_page = pte_page(pte);
> 
>  retry_avoidcopy:
> @@ -3668,7 +3670,7 @@ static int hugetlb_no_page(struct mm_struct *mm, struct 
> vm_area_struct *vma,
>   hugetlb_count_add(pages_per_huge_page(h), mm);
>   if ((flags & FAULT_FLAG_WRITE) && !(vma->vm_flags & VM_SHARED)) {
>   /* Optimization, do the COW without a second fault */
> - ret = hugetlb_cow(mm, vma, address, ptep, new_pte, page, ptl);
> + ret = hugetlb_cow(mm, vma, address, ptep, page, ptl);
>   }
> 
>   spin_unlock(ptl);
> @@ -3822,8 +3824,8 @@ int hugetlb_fault(struct mm_struct *mm, struct 
> vm_area_struct *vma,
> 
>   if (flags & FAULT_FLAG_WRITE) {
>   if (!huge_pte_write(entry)) {
> - ret = hugetlb_cow(mm, vma, address, ptep, entry,
> - pagecache_page, ptl);
> + ret = hugetlb_cow(mm, vma, address, ptep,
> +   pagecache_page, ptl);
>   goto out_put_page;
>   }
>   entry = huge_pte_mkdirty(entry);
> --
> 2.10.1

Re: [PATCH] mm/hugetlb: Use the right pte val for compare in hugetlb_cow

[Hillf Danton]

On Tuesday, October 18, 2016 11:43 PM Aneesh Kumar K.V wrote:
> 
> We cannot use the pte value used in set_pte_at for pte_same comparison,
> because archs like ppc64, filter/add new pte flag in set_pte_at. Instead
> fetch the pte value inside hugetlb_cow. We are comparing pte value to
> make sure the pte didn't change since we dropped the page table lock.
> hugetlb_cow get called with page table lock held, and we can take a copy
> of the pte value before we drop the page table lock.
> 
> With hugetlbfs, we optimize the MAP_PRIVATE write fault path with no
> previous mapping (huge_pte_none entries), by forcing a cow in the fault
> path. This avoid take an addition fault to covert a read-only mapping
> to read/write. Here we were comparing a recently instantiated pte (via
> set_pte_at) to the pte values from linux page table. As explained above
> on ppc64 such pte_same check returned wrong result, resulting in us
> taking an additional fault on ppc64.
> 
> Fixes: 6a119eae942c ("powerpc/mm: Add a _PAGE_PTE bit")
> 
> Reported-by: Jan Stancek 
> Signed-off-by: Aneesh Kumar K.V 
> ---

Acked-by: Hillf Danton 

>  mm/hugetlb.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index ec49d9ef1eef..da8fbd02b92e 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3386,15 +3386,17 @@ static void unmap_ref_private(struct mm_struct *mm, 
> struct vm_area_struct *vma,
>   * Keep the pte_same checks anyway to make transition from the mutex easier.
>   */
>  static int hugetlb_cow(struct mm_struct *mm, struct vm_area_struct *vma,
> - unsigned long address, pte_t *ptep, pte_t pte,
> - struct page *pagecache_page, spinlock_t *ptl)
> +unsigned long address, pte_t *ptep,
> +struct page *pagecache_page, spinlock_t *ptl)
>  {
> + pte_t pte;
>   struct hstate *h = hstate_vma(vma);
>   struct page *old_page, *new_page;
>   int ret = 0, outside_reserve = 0;
>   unsigned long mmun_start;   /* For mmu_notifiers */
>   unsigned long mmun_end; /* For mmu_notifiers */
> 
> + pte = huge_ptep_get(ptep);
>   old_page = pte_page(pte);
> 
>  retry_avoidcopy:
> @@ -3668,7 +3670,7 @@ static int hugetlb_no_page(struct mm_struct *mm, struct 
> vm_area_struct *vma,
>   hugetlb_count_add(pages_per_huge_page(h), mm);
>   if ((flags & FAULT_FLAG_WRITE) && !(vma->vm_flags & VM_SHARED)) {
>   /* Optimization, do the COW without a second fault */
> - ret = hugetlb_cow(mm, vma, address, ptep, new_pte, page, ptl);
> + ret = hugetlb_cow(mm, vma, address, ptep, page, ptl);
>   }
> 
>   spin_unlock(ptl);
> @@ -3822,8 +3824,8 @@ int hugetlb_fault(struct mm_struct *mm, struct 
> vm_area_struct *vma,
> 
>   if (flags & FAULT_FLAG_WRITE) {
>   if (!huge_pte_write(entry)) {
> - ret = hugetlb_cow(mm, vma, address, ptep, entry,
> - pagecache_page, ptl);
> + ret = hugetlb_cow(mm, vma, address, ptep,
> +   pagecache_page, ptl);
>   goto out_put_page;
>   }
>   entry = huge_pte_mkdirty(entry);
> --
> 2.10.1

Re: [PATCH] dt-bindings: usb: atmel: fix a couple of copy-paste style typos

[Rob Herring]

On Tue, Oct 18, 2016 at 01:05:18PM +0200, Peter Rosin wrote:
> Signed-off-by: Peter Rosin 
> ---
>  Documentation/devicetree/bindings/usb/atmel-usb.txt | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH] dt-bindings: usb: atmel: fix a couple of copy-paste style typos

[Rob Herring]

On Tue, Oct 18, 2016 at 01:05:18PM +0200, Peter Rosin wrote:
> Signed-off-by: Peter Rosin 
> ---
>  Documentation/devicetree/bindings/usb/atmel-usb.txt | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Acked-by: Rob Herring 

Re: [RFC PATCH] mtd: nand: Add OX820 NAND Support

[Rob Herring]

On Tue, Oct 18, 2016 at 11:09:27AM +0200, Neil Armstrong wrote:
> Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
> This is a simple memory mapped NAND controller with single chip select and
> software ECC.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../devicetree/bindings/mtd/oxnas-nand.txt |  24 

Acked-by: Rob Herring 

>  drivers/mtd/nand/Kconfig   |   5 +
>  drivers/mtd/nand/Makefile  |   1 +
>  drivers/mtd/nand/oxnas_nand.c  | 144 
> +
>  4 files changed, 174 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt
>  create mode 100644 drivers/mtd/nand/oxnas_nand.c

Re: [RFC PATCH] mtd: nand: Add OX820 NAND Support

[Rob Herring]

On Tue, Oct 18, 2016 at 11:09:27AM +0200, Neil Armstrong wrote:
> Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
> This is a simple memory mapped NAND controller with single chip select and
> software ECC.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../devicetree/bindings/mtd/oxnas-nand.txt |  24 

Acked-by: Rob Herring 

>  drivers/mtd/nand/Kconfig   |   5 +
>  drivers/mtd/nand/Makefile  |   1 +
>  drivers/mtd/nand/oxnas_nand.c  | 144 
> +
>  4 files changed, 174 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt
>  create mode 100644 drivers/mtd/nand/oxnas_nand.c

Re: [PATCH] power: max17040: Change register transaction length from 8 bits to 16 bits

[Sebastian Reichel]

Hi,

On Wed, Sep 21, 2016 at 10:17:34PM +0800, Liu Xiang wrote:
> According to the datasheet, MAX17040 has six 16-bit registers.
> Register reads and writes are only valid if all 16 bits are transferred.
> Any write command that is terminated early is ignored.
> So it's better to change register transacton length from 8 bits to 16 bits.
> 
> Signed-off-by: Liu Xiang 
> ---
>  drivers/power/max17040_battery.c | 52 
> 
>  1 file changed, 20 insertions(+), 32 deletions(-)

Thanks, queued to for-next.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] power: max17040: Change register transaction length from 8 bits to 16 bits

[Sebastian Reichel]

Hi,

On Wed, Sep 21, 2016 at 10:17:34PM +0800, Liu Xiang wrote:
> According to the datasheet, MAX17040 has six 16-bit registers.
> Register reads and writes are only valid if all 16 bits are transferred.
> Any write command that is terminated early is ignored.
> So it's better to change register transacton length from 8 bits to 16 bits.
> 
> Signed-off-by: Liu Xiang 
> ---
>  drivers/power/max17040_battery.c | 52 
> 
>  1 file changed, 20 insertions(+), 32 deletions(-)

Thanks, queued to for-next.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] power: bq27xxx_battery: don't update poll_interval param if same

[Sebastian Reichel]

Hi,

On Fri, Sep 30, 2016 at 09:45:30PM -0700, Matt Ranostay wrote:
> To avoid canceling the delayed workqueue needlessly, and scheduling an
> immediate polling. Check if the new poll_interval value is different
> than the previous setting.
> 
> Cc: Tony Lindgren 
> Cc: Sebastian Reichel 
> Signed-off-by: Matt Ranostay 

Thanks, queued to for-next.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] power: bq27xxx_battery: don't update poll_interval param if same

[Sebastian Reichel]

Hi,

On Fri, Sep 30, 2016 at 09:45:30PM -0700, Matt Ranostay wrote:
> To avoid canceling the delayed workqueue needlessly, and scheduling an
> immediate polling. Check if the new poll_interval value is different
> than the previous setting.
> 
> Cc: Tony Lindgren 
> Cc: Sebastian Reichel 
> Signed-off-by: Matt Ranostay 

Thanks, queued to for-next.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 08/15] power: improve function-level documentation

[Sebastian Reichel]

Hi Julia,

On Sat, Oct 01, 2016 at 09:46:25PM +0200, Julia Lawall wrote:
> In drivers/power/supply/ab8500_fg.c, fix two typos and adjust the function
> name in two cases to correspond to the names of the defined functions.
> 
> In drivers/power/supply/power_supply_core.c, change two variable names to
> the names of the corresponding parameters.
> 
> Issue detected using Coccinelle (http://coccinelle.lip6.fr/)
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  drivers/power/supply/ab8500_fg.c |8 
>  drivers/power/supply/power_supply_core.c |4 ++--
>  2 files changed, 6 insertions(+), 6 deletions(-)

Thanks, queued to for-next.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 08/15] power: improve function-level documentation

[Sebastian Reichel]

Hi Julia,

On Sat, Oct 01, 2016 at 09:46:25PM +0200, Julia Lawall wrote:
> In drivers/power/supply/ab8500_fg.c, fix two typos and adjust the function
> name in two cases to correspond to the names of the defined functions.
> 
> In drivers/power/supply/power_supply_core.c, change two variable names to
> the names of the corresponding parameters.
> 
> Issue detected using Coccinelle (http://coccinelle.lip6.fr/)
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  drivers/power/supply/ab8500_fg.c |8 
>  drivers/power/supply/power_supply_core.c |4 ++--
>  2 files changed, 6 insertions(+), 6 deletions(-)

Thanks, queued to for-next.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH v2] arm64: kernel: numa: fix ACPI boot cpu numa node mapping

[Leizhen (ThunderTown)]

On 2016/10/18 16:39, Hanjun Guo wrote:
> On 2016/10/17 22:56, Lorenzo Pieralisi wrote:
>> Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must
>> bind to node0") removed the numa cpu<->node mapping restriction whereby
>> logical cpu 0 always corresponds to numa node 0; removing the
>> restriction was correct, in that it does not really exist in practice
>> but the commit only updated the early mapping of logical cpu 0 to its
>> real numa node for the DT boot path, missing the ACPI one, leading to
>> boot failures on ACPI systems owing to missing cpu<->node map for
>> logical cpu 0.
>>
>> Fix the issue by updating the ACPI boot path with code that carries out
>> the early cpu<->node mapping also for the boot cpu (ie cpu 0), mirroring
>> what is currently done in the DT boot path.
>>
>> Fixes: 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind 
>> to node0")
>> Signed-off-by: Lorenzo Pieralisi 
>> Tested-by: Laszlo Ersek 
>> Reported-by: Laszlo Ersek 
>> Cc: Will Deacon 
>> Cc: Laszlo Ersek 
>> Cc: Hanjun Guo 
> 
> Thanks for the quick response and fix,
> 
> Acked-by: Hanjun Guo 
> 
> By the way, I got another boot failure [1] when we have multi
> NUMA nodes system with some memory-less nodes (only one node
> have memory), we are looking into it now, this patch needs
> to be merged first.
You should apply my numa MEMORYLESS patches first, because the two patches have 
not been upstreamed yet.
I just tested it base on 4.9-rc1 for dt numa, it worked well. I will connect 
you to check what's wrong on ACPI numa.

> 
> Thanks
> Hanjun
> 
> [1]: boot failure log:
> [0.00] NUMA: Adding memblock [0x0 - 0x3fff] on node 0
> [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x3fff]
> [0.00] NUMA: Adding memblock [0x14 - 0x17] on node 1
> [0.00] ACPI: SRAT: Node 1 PXM 1 [mem 0x14-0x17]
> [0.00] NUMA: Adding memblock [0x10 - 0x13] on node 0
> [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x10-0x13]
> [0.00] NUMA: Initmem setup node 0 [mem 0x-0x13fbff]
> [0.00] NUMA: NODE_DATA [mem 0x13fbffe500-0x13fbff]
> [0.00] NUMA: Initmem setup node 1 [mem 0x14-0x17fbff]
> [0.00] NUMA: NODE_DATA [mem 0x17fbfec500-0x17fbfedfff]
> [0.00] NUMA: Initmem setup node 2 [mem 0x-0x]
> [0.00] NUMA: NODE_DATA [mem 0x17fbfeaa00-0x17fbfec4ff]
> [0.00] NUMA: NODE_DATA(2) on node 1
> [0.00] NUMA: Initmem setup node 3 [mem 0x-0x]
> [0.00] NUMA: NODE_DATA [mem 0x17fbfe8f00-0x17fbfea9ff]
> [0.00] NUMA: NODE_DATA(3) on node 1
> [0.00] Zone ranges:
> [0.00]   DMA  [mem 0x-0x]
> [0.00]   Normal   [mem 0x0001-0x0017fbff]
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x-0x00024fff]
> [0.00]   node   0: [mem 0x00026000-0x319d]
> [0.00]   node   0: [mem 0x319e-0x31a4]
> [0.00]   node   0: [mem 0x31a5-0x31b2]
> [0.00]   node   0: [mem 0x31b3-0x31b3]
> [0.00]   node   0: [mem 0x31b4-0x39ba]
> [0.00]   node   0: [mem 0x39bb-0x3a143fff]
> [0.00]   node   0: [mem 0x3a144000-0x3f12]
> [0.00]   node   0: [mem 0x3f13-0x3f15]
> [0.00]   node   0: [mem 0x3f16-0x3fbf]
> [0.00]   node   0: [mem 0x00104000-0x0013fbff]
> [0.00]   node   1: [mem 0x0014-0x0017fbff]
> [0.00] Initmem setup node 0 [mem 
> 0x-0x0013fbff]
> [0.00] Initmem setup node 1 [mem 
> 0x0014-0x0017fbff]
> [0.00] Could not find start_pfn for node 2
> [0.00] Initmem setup node 2 [mem 
> 0x-0x]
> [0.00] Could not find start_pfn for node 3
> [0.00] Initmem setup node 3 [mem 
> 0x-0x]
> [0.00] psci: probing for conduit method from ACPI.
> [0.00] [ cut here ]
> [0.00] kernel BUG at mm/percpu.c:1916!
> [0.00] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
> 4.9.0-rc1-00083-g3dd62e5 #680
> [0.00] Hardware name: Hisilicon Hi1616 Evaluation Board (DT)
> [0.00] task: 08d5e980 task.stack: 08d5
> [0.00] PC is at 

Re: [PATCH v2] arm64: kernel: numa: fix ACPI boot cpu numa node mapping

[Leizhen (ThunderTown)]

On 2016/10/18 16:39, Hanjun Guo wrote:
> On 2016/10/17 22:56, Lorenzo Pieralisi wrote:
>> Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must
>> bind to node0") removed the numa cpu<->node mapping restriction whereby
>> logical cpu 0 always corresponds to numa node 0; removing the
>> restriction was correct, in that it does not really exist in practice
>> but the commit only updated the early mapping of logical cpu 0 to its
>> real numa node for the DT boot path, missing the ACPI one, leading to
>> boot failures on ACPI systems owing to missing cpu<->node map for
>> logical cpu 0.
>>
>> Fix the issue by updating the ACPI boot path with code that carries out
>> the early cpu<->node mapping also for the boot cpu (ie cpu 0), mirroring
>> what is currently done in the DT boot path.
>>
>> Fixes: 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind 
>> to node0")
>> Signed-off-by: Lorenzo Pieralisi 
>> Tested-by: Laszlo Ersek 
>> Reported-by: Laszlo Ersek 
>> Cc: Will Deacon 
>> Cc: Laszlo Ersek 
>> Cc: Hanjun Guo 
> 
> Thanks for the quick response and fix,
> 
> Acked-by: Hanjun Guo 
> 
> By the way, I got another boot failure [1] when we have multi
> NUMA nodes system with some memory-less nodes (only one node
> have memory), we are looking into it now, this patch needs
> to be merged first.
You should apply my numa MEMORYLESS patches first, because the two patches have 
not been upstreamed yet.
I just tested it base on 4.9-rc1 for dt numa, it worked well. I will connect 
you to check what's wrong on ACPI numa.

> 
> Thanks
> Hanjun
> 
> [1]: boot failure log:
> [0.00] NUMA: Adding memblock [0x0 - 0x3fff] on node 0
> [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x3fff]
> [0.00] NUMA: Adding memblock [0x14 - 0x17] on node 1
> [0.00] ACPI: SRAT: Node 1 PXM 1 [mem 0x14-0x17]
> [0.00] NUMA: Adding memblock [0x10 - 0x13] on node 0
> [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x10-0x13]
> [0.00] NUMA: Initmem setup node 0 [mem 0x-0x13fbff]
> [0.00] NUMA: NODE_DATA [mem 0x13fbffe500-0x13fbff]
> [0.00] NUMA: Initmem setup node 1 [mem 0x14-0x17fbff]
> [0.00] NUMA: NODE_DATA [mem 0x17fbfec500-0x17fbfedfff]
> [0.00] NUMA: Initmem setup node 2 [mem 0x-0x]
> [0.00] NUMA: NODE_DATA [mem 0x17fbfeaa00-0x17fbfec4ff]
> [0.00] NUMA: NODE_DATA(2) on node 1
> [0.00] NUMA: Initmem setup node 3 [mem 0x-0x]
> [0.00] NUMA: NODE_DATA [mem 0x17fbfe8f00-0x17fbfea9ff]
> [0.00] NUMA: NODE_DATA(3) on node 1
> [0.00] Zone ranges:
> [0.00]   DMA  [mem 0x-0x]
> [0.00]   Normal   [mem 0x0001-0x0017fbff]
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x-0x00024fff]
> [0.00]   node   0: [mem 0x00026000-0x319d]
> [0.00]   node   0: [mem 0x319e-0x31a4]
> [0.00]   node   0: [mem 0x31a5-0x31b2]
> [0.00]   node   0: [mem 0x31b3-0x31b3]
> [0.00]   node   0: [mem 0x31b4-0x39ba]
> [0.00]   node   0: [mem 0x39bb-0x3a143fff]
> [0.00]   node   0: [mem 0x3a144000-0x3f12]
> [0.00]   node   0: [mem 0x3f13-0x3f15]
> [0.00]   node   0: [mem 0x3f16-0x3fbf]
> [0.00]   node   0: [mem 0x00104000-0x0013fbff]
> [0.00]   node   1: [mem 0x0014-0x0017fbff]
> [0.00] Initmem setup node 0 [mem 
> 0x-0x0013fbff]
> [0.00] Initmem setup node 1 [mem 
> 0x0014-0x0017fbff]
> [0.00] Could not find start_pfn for node 2
> [0.00] Initmem setup node 2 [mem 
> 0x-0x]
> [0.00] Could not find start_pfn for node 3
> [0.00] Initmem setup node 3 [mem 
> 0x-0x]
> [0.00] psci: probing for conduit method from ACPI.
> [0.00] [ cut here ]
> [0.00] kernel BUG at mm/percpu.c:1916!
> [0.00] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
> 4.9.0-rc1-00083-g3dd62e5 #680
> [0.00] Hardware name: Hisilicon Hi1616 Evaluation Board (DT)
> [0.00] task: 08d5e980 task.stack: 08d5
> [0.00] PC is at pcpu_embed_first_chunk+0x464/0x754
> [0.00] LR is at pcpu_embed_first_chunk+0x3f8/0x754
> [0.00] pc : [] lr : [] pstate: 
> 20c5
> [

Re: [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC

[Rob Herring]

On Tue, Oct 18, 2016 at 9:38 PM, Jiancheng Xue
 wrote:
>
>
> 在 2016/10/18 23:58, Rob Herring 写道:
>> On Mon, Oct 17, 2016 at 08:07:04PM +0800, Pan Wen wrote:
>>> Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset
>>> Generator) module generates clock and reset signals used
>>> by other module blocks on SoC.
>>>
>>> Signed-off-by: Pan Wen 
>>> ---
>>>  .../devicetree/bindings/clock/hisi-crg.txt |  50 
>>>  drivers/clk/hisilicon/Kconfig  |   8 +
>>>  drivers/clk/hisilicon/Makefile |   1 +
>>>  drivers/clk/hisilicon/crg-hi3516cv300.c| 330 
>>> +
>>>  drivers/clk/hisilicon/crg.h|  34 +++
>>>  include/dt-bindings/clock/hi3516cv300-clock.h  |  48 +++
>>>  6 files changed, 471 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/clock/hisi-crg.txt
>>>  create mode 100644 drivers/clk/hisilicon/crg-hi3516cv300.c
>>>  create mode 100644 drivers/clk/hisilicon/crg.h
>>>  create mode 100644 include/dt-bindings/clock/hi3516cv300-clock.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/hisi-crg.txt 
>>> b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>>> new file mode 100644
>>> index 000..cc60b3d
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>>> @@ -0,0 +1,50 @@
>>> +* HiSilicon Clock and Reset Generator(CRG)
>>
>> Seems kind of generic given there's already various HiSi clock bindings
>> documented.
>>
>>> +
>>> +The CRG module provides clock and reset signals to various
>>> +modules within the SoC.
>>> +
>>> +This binding uses the following bindings:
>>> +Documentation/devicetree/bindings/clock/clock-bindings.txt
>>> +Documentation/devicetree/bindings/reset/reset.txt
>>> +
>>> +Required Properties:
>>> +
>>> +- compatible: should be one of the following.
>>> +  - "hisilicon,hi3516cv300-crg"
>>> +  - "hisilicon,hi3516cv300-sysctrl"
>>> +  - "hisilicon,hi3519-crg"
>>
>> There is already a binding for this. Please merge them.
>>
> Hi Rob,
>
> Pan Wen and I work together. There's really a same file included in the patch
> https://lkml.org/lkml/2016/9/18/42 ([PATCH v2] clk: hisilicon: add CRG driver 
> for Hi3798CV200 SoC).
> But that patch has not been acked. This binding file will be merged if that
> patch is accepted first. Could you give me more comments on that patch or
> help me to ack it?  Thank you very much.

If I haven't commented, then likely it was not sent to the DT list.

Rob

Re: [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC

[Rob Herring]

On Tue, Oct 18, 2016 at 9:38 PM, Jiancheng Xue
 wrote:
>
>
> 在 2016/10/18 23:58, Rob Herring 写道:
>> On Mon, Oct 17, 2016 at 08:07:04PM +0800, Pan Wen wrote:
>>> Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset
>>> Generator) module generates clock and reset signals used
>>> by other module blocks on SoC.
>>>
>>> Signed-off-by: Pan Wen 
>>> ---
>>>  .../devicetree/bindings/clock/hisi-crg.txt |  50 
>>>  drivers/clk/hisilicon/Kconfig  |   8 +
>>>  drivers/clk/hisilicon/Makefile |   1 +
>>>  drivers/clk/hisilicon/crg-hi3516cv300.c| 330 
>>> +
>>>  drivers/clk/hisilicon/crg.h|  34 +++
>>>  include/dt-bindings/clock/hi3516cv300-clock.h  |  48 +++
>>>  6 files changed, 471 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/clock/hisi-crg.txt
>>>  create mode 100644 drivers/clk/hisilicon/crg-hi3516cv300.c
>>>  create mode 100644 drivers/clk/hisilicon/crg.h
>>>  create mode 100644 include/dt-bindings/clock/hi3516cv300-clock.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/hisi-crg.txt 
>>> b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>>> new file mode 100644
>>> index 000..cc60b3d
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>>> @@ -0,0 +1,50 @@
>>> +* HiSilicon Clock and Reset Generator(CRG)
>>
>> Seems kind of generic given there's already various HiSi clock bindings
>> documented.
>>
>>> +
>>> +The CRG module provides clock and reset signals to various
>>> +modules within the SoC.
>>> +
>>> +This binding uses the following bindings:
>>> +Documentation/devicetree/bindings/clock/clock-bindings.txt
>>> +Documentation/devicetree/bindings/reset/reset.txt
>>> +
>>> +Required Properties:
>>> +
>>> +- compatible: should be one of the following.
>>> +  - "hisilicon,hi3516cv300-crg"
>>> +  - "hisilicon,hi3516cv300-sysctrl"
>>> +  - "hisilicon,hi3519-crg"
>>
>> There is already a binding for this. Please merge them.
>>
> Hi Rob,
>
> Pan Wen and I work together. There's really a same file included in the patch
> https://lkml.org/lkml/2016/9/18/42 ([PATCH v2] clk: hisilicon: add CRG driver 
> for Hi3798CV200 SoC).
> But that patch has not been acked. This binding file will be merged if that
> patch is accepted first. Could you give me more comments on that patch or
> help me to ack it?  Thank you very much.

If I haven't commented, then likely it was not sent to the DT list.

Rob

Re: [PATCH v2] mm: exclude isolated non-lru pages from NR_ISOLATED_ANON or NR_ISOLATED_FILE.

[Ming Ling]

二, 10月 18, 2016 at 02:52:47下午 +0200, Michal Hocko wrote:
hi,
> On Tue 18-10-16 15:29:50, Minchan Kim wrote:
> > On Mon, Oct 17, 2016 at 10:42:45AM +0200, Michal Hocko wrote:
> [...]
> > > Sure, what do you think about the following? I haven't marked it for
> > > stable because there was no bug report for it AFAIU.
> > > ---
> > > From 3b2bd4486f36ada9f6dc86d3946855281455ba9f Mon Sep 17 00:00:00 2001
> > > From: Ming Ling 
> > > Date: Mon, 17 Oct 2016 10:26:50 +0200
> > > Subject: [PATCH] mm, compaction: fix NR_ISOLATED_* stats for pfn based
> > >  migration
> > > 
> > > Since bda807d44454 ("mm: migrate: support non-lru movable page
> > > migration") isolate_migratepages_block) can isolate !PageLRU pages which
> > > would acct_isolated account as NR_ISOLATED_*. Accounting these non-lru
> > > pages NR_ISOLATED_{ANON,FILE} doesn't make any sense and it can misguide
> > > heuristics based on those counters such as pgdat_reclaimable_pages resp.
> > > too_many_isolated which would lead to unexpected stalls during the
> > > direct reclaim without any good reason. Note that
> > > __alloc_contig_migrate_range can isolate a lot of pages at once.
> > > 
> > > On mobile devices such as 512M ram android Phone, it may use a big zram
> > > swap. In some cases zram(zsmalloc) uses too many non-lru but migratedable
> > > pages, such as:
> > > 
> > >   MemTotal: 468148 kB
> > >   Normal free:5620kB
> > >   Free swap:4736kB
> > >   Total swap:409596kB
> > >   ZRAM: 164616kB(zsmalloc non-lru pages)
> > >   active_anon:60700kB
> > >   inactive_anon:60744kB
> > >   active_file:34420kB
> > >   inactive_file:37532kB
> > > 
> > > Fix this by only accounting lru pages to NR_ISOLATED_* in
> > > isolate_migratepages_block right after they were isolated and we still
> > > know they were on LRU. Drop acct_isolated because it is called after the
> > > fact and we've lost that information. Batching per-cpu counter doesn't
> > > make much improvement anyway. Also make sure that we uncharge only LRU
> > > pages when putting them back on the LRU in putback_movable_pages resp.
> > > when unmap_and_move migrates the page.
> > > 
> > > Fixes: bda807d44454 ("mm: migrate: support non-lru movable page 
> > > migration")
> > > Signed-off-by: Ming Ling 
> > > Signed-off-by: Michal Hocko 
> > 
> > Acked-by: Minchan Kim 
> > 
> > with folding other fix patch you posted.
> 
> Thanks.
> 
> Ming, are you OK with this patch? Can I post it to Andrew?
> --
I think that's fine. Just do it.
Thank you.
> Michal Hocko
> SUSE Labs

Re: [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC

[Jiancheng Xue]

在 2016/10/18 23:58, Rob Herring 写道:
> On Mon, Oct 17, 2016 at 08:07:04PM +0800, Pan Wen wrote:
>> Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset
>> Generator) module generates clock and reset signals used
>> by other module blocks on SoC.
>>
>> Signed-off-by: Pan Wen 
>> ---
>>  .../devicetree/bindings/clock/hisi-crg.txt |  50 
>>  drivers/clk/hisilicon/Kconfig  |   8 +
>>  drivers/clk/hisilicon/Makefile |   1 +
>>  drivers/clk/hisilicon/crg-hi3516cv300.c| 330 
>> +
>>  drivers/clk/hisilicon/crg.h|  34 +++
>>  include/dt-bindings/clock/hi3516cv300-clock.h  |  48 +++
>>  6 files changed, 471 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/clock/hisi-crg.txt
>>  create mode 100644 drivers/clk/hisilicon/crg-hi3516cv300.c
>>  create mode 100644 drivers/clk/hisilicon/crg.h
>>  create mode 100644 include/dt-bindings/clock/hi3516cv300-clock.h
>>
>> diff --git a/Documentation/devicetree/bindings/clock/hisi-crg.txt 
>> b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>> new file mode 100644
>> index 000..cc60b3d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>> @@ -0,0 +1,50 @@
>> +* HiSilicon Clock and Reset Generator(CRG)
> 
> Seems kind of generic given there's already various HiSi clock bindings 
> documented.
> 
>> +
>> +The CRG module provides clock and reset signals to various
>> +modules within the SoC.
>> +
>> +This binding uses the following bindings:
>> +Documentation/devicetree/bindings/clock/clock-bindings.txt
>> +Documentation/devicetree/bindings/reset/reset.txt
>> +
>> +Required Properties:
>> +
>> +- compatible: should be one of the following.
>> +  - "hisilicon,hi3516cv300-crg"
>> +  - "hisilicon,hi3516cv300-sysctrl"
>> +  - "hisilicon,hi3519-crg"
> 
> There is already a binding for this. Please merge them.
> 
Hi Rob,

Pan Wen and I work together. There's really a same file included in the patch
https://lkml.org/lkml/2016/9/18/42 ([PATCH v2] clk: hisilicon: add CRG driver 
for Hi3798CV200 SoC).
But that patch has not been acked. This binding file will be merged if that
patch is accepted first. Could you give me more comments on that patch or
help me to ack it?  Thank you very much.

Regards,
Jiancheng


>> +  - "hisilicon,hi3798cv200-crg"
>> +  - "hisilicon,hi3798cv200-sysctrl"
>> +
>> +- reg: physical base address of the controller and length of memory mapped
>> +  region.
>> +
>> +- #clock-cells: should be 1.
>> +
>> +Each clock is assigned an identifier and client nodes use this identifier
>> +to specify the clock which they consume.
>> +
>> +All these identifier could be found in .
>> +
>> +- #reset-cells: should be 2.
>> +
>> +A reset signal can be controlled by writing a bit register in the CRG 
>> module.
>> +The reset specifier consists of two cells. The first cell represents the
>> +register offset relative to the base address. The second cell represents the
>> +bit index in the register.
>> +
>> +Example: CRG nodes
>> +CRG: clock-reset-controller@1201 {
>> +compatible = "hisilicon,hi3519-crg";
>> +reg = <0x1201 0x1>;
>> +#clock-cells = <1>;
>> +#reset-cells = <2>;
>> +};
>> +
>> +Example: consumer nodes
>> +i2c0: i2c@1211 {
>> +compatible = "hisilicon,hi3519-i2c";
>> +reg = <0x1211 0x1000>;
>> +clocks = < HI3519_I2C0_RST>;
>> +resets = < 0xe4 0>;
>> +};
> 
> .
> 

Re: [PATCH v2] mm: exclude isolated non-lru pages from NR_ISOLATED_ANON or NR_ISOLATED_FILE.

[Ming Ling]

二, 10月 18, 2016 at 02:52:47下午 +0200, Michal Hocko wrote:
hi,
> On Tue 18-10-16 15:29:50, Minchan Kim wrote:
> > On Mon, Oct 17, 2016 at 10:42:45AM +0200, Michal Hocko wrote:
> [...]
> > > Sure, what do you think about the following? I haven't marked it for
> > > stable because there was no bug report for it AFAIU.
> > > ---
> > > From 3b2bd4486f36ada9f6dc86d3946855281455ba9f Mon Sep 17 00:00:00 2001
> > > From: Ming Ling 
> > > Date: Mon, 17 Oct 2016 10:26:50 +0200
> > > Subject: [PATCH] mm, compaction: fix NR_ISOLATED_* stats for pfn based
> > >  migration
> > > 
> > > Since bda807d44454 ("mm: migrate: support non-lru movable page
> > > migration") isolate_migratepages_block) can isolate !PageLRU pages which
> > > would acct_isolated account as NR_ISOLATED_*. Accounting these non-lru
> > > pages NR_ISOLATED_{ANON,FILE} doesn't make any sense and it can misguide
> > > heuristics based on those counters such as pgdat_reclaimable_pages resp.
> > > too_many_isolated which would lead to unexpected stalls during the
> > > direct reclaim without any good reason. Note that
> > > __alloc_contig_migrate_range can isolate a lot of pages at once.
> > > 
> > > On mobile devices such as 512M ram android Phone, it may use a big zram
> > > swap. In some cases zram(zsmalloc) uses too many non-lru but migratedable
> > > pages, such as:
> > > 
> > >   MemTotal: 468148 kB
> > >   Normal free:5620kB
> > >   Free swap:4736kB
> > >   Total swap:409596kB
> > >   ZRAM: 164616kB(zsmalloc non-lru pages)
> > >   active_anon:60700kB
> > >   inactive_anon:60744kB
> > >   active_file:34420kB
> > >   inactive_file:37532kB
> > > 
> > > Fix this by only accounting lru pages to NR_ISOLATED_* in
> > > isolate_migratepages_block right after they were isolated and we still
> > > know they were on LRU. Drop acct_isolated because it is called after the
> > > fact and we've lost that information. Batching per-cpu counter doesn't
> > > make much improvement anyway. Also make sure that we uncharge only LRU
> > > pages when putting them back on the LRU in putback_movable_pages resp.
> > > when unmap_and_move migrates the page.
> > > 
> > > Fixes: bda807d44454 ("mm: migrate: support non-lru movable page 
> > > migration")
> > > Signed-off-by: Ming Ling 
> > > Signed-off-by: Michal Hocko 
> > 
> > Acked-by: Minchan Kim 
> > 
> > with folding other fix patch you posted.
> 
> Thanks.
> 
> Ming, are you OK with this patch? Can I post it to Andrew?
> --
I think that's fine. Just do it.
Thank you.
> Michal Hocko
> SUSE Labs

Re: [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC

[Jiancheng Xue]

在 2016/10/18 23:58, Rob Herring 写道:
> On Mon, Oct 17, 2016 at 08:07:04PM +0800, Pan Wen wrote:
>> Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset
>> Generator) module generates clock and reset signals used
>> by other module blocks on SoC.
>>
>> Signed-off-by: Pan Wen 
>> ---
>>  .../devicetree/bindings/clock/hisi-crg.txt |  50 
>>  drivers/clk/hisilicon/Kconfig  |   8 +
>>  drivers/clk/hisilicon/Makefile |   1 +
>>  drivers/clk/hisilicon/crg-hi3516cv300.c| 330 
>> +
>>  drivers/clk/hisilicon/crg.h|  34 +++
>>  include/dt-bindings/clock/hi3516cv300-clock.h  |  48 +++
>>  6 files changed, 471 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/clock/hisi-crg.txt
>>  create mode 100644 drivers/clk/hisilicon/crg-hi3516cv300.c
>>  create mode 100644 drivers/clk/hisilicon/crg.h
>>  create mode 100644 include/dt-bindings/clock/hi3516cv300-clock.h
>>
>> diff --git a/Documentation/devicetree/bindings/clock/hisi-crg.txt 
>> b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>> new file mode 100644
>> index 000..cc60b3d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>> @@ -0,0 +1,50 @@
>> +* HiSilicon Clock and Reset Generator(CRG)
> 
> Seems kind of generic given there's already various HiSi clock bindings 
> documented.
> 
>> +
>> +The CRG module provides clock and reset signals to various
>> +modules within the SoC.
>> +
>> +This binding uses the following bindings:
>> +Documentation/devicetree/bindings/clock/clock-bindings.txt
>> +Documentation/devicetree/bindings/reset/reset.txt
>> +
>> +Required Properties:
>> +
>> +- compatible: should be one of the following.
>> +  - "hisilicon,hi3516cv300-crg"
>> +  - "hisilicon,hi3516cv300-sysctrl"
>> +  - "hisilicon,hi3519-crg"
> 
> There is already a binding for this. Please merge them.
> 
Hi Rob,

Pan Wen and I work together. There's really a same file included in the patch
https://lkml.org/lkml/2016/9/18/42 ([PATCH v2] clk: hisilicon: add CRG driver 
for Hi3798CV200 SoC).
But that patch has not been acked. This binding file will be merged if that
patch is accepted first. Could you give me more comments on that patch or
help me to ack it?  Thank you very much.

Regards,
Jiancheng


>> +  - "hisilicon,hi3798cv200-crg"
>> +  - "hisilicon,hi3798cv200-sysctrl"
>> +
>> +- reg: physical base address of the controller and length of memory mapped
>> +  region.
>> +
>> +- #clock-cells: should be 1.
>> +
>> +Each clock is assigned an identifier and client nodes use this identifier
>> +to specify the clock which they consume.
>> +
>> +All these identifier could be found in .
>> +
>> +- #reset-cells: should be 2.
>> +
>> +A reset signal can be controlled by writing a bit register in the CRG 
>> module.
>> +The reset specifier consists of two cells. The first cell represents the
>> +register offset relative to the base address. The second cell represents the
>> +bit index in the register.
>> +
>> +Example: CRG nodes
>> +CRG: clock-reset-controller@1201 {
>> +compatible = "hisilicon,hi3519-crg";
>> +reg = <0x1201 0x1>;
>> +#clock-cells = <1>;
>> +#reset-cells = <2>;
>> +};
>> +
>> +Example: consumer nodes
>> +i2c0: i2c@1211 {
>> +compatible = "hisilicon,hi3519-i2c";
>> +reg = <0x1211 0x1000>;
>> +clocks = < HI3519_I2C0_RST>;
>> +resets = < 0xe4 0>;
>> +};
> 
> .
> 

[PATCH v18 4/4] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown 
Signed-off-by: Baolin Wang 
Acked-by: Lee Jones 
Acked-by: Charles Keepax 
Acked-by: Peter Chen 
Acked-by: Sebastian Reichel 
---
 drivers/power/wm831x_power.c |   75 ++
 include/linux/mfd/wm831x/pdata.h |3 ++
 2 files changed, 78 insertions(+)

diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
index 7082301..2bcd775 100644
--- a/drivers/power/wm831x_power.c
+++ b/drivers/power/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_charger *usb_charger;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,49 @@ static enum power_supply_property wm831x_usb_props[] = {
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long state, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   struct usb_charger *uchger = (struct usb_charger *)data;
+   unsigned int i, best, min, limit;
+
+   if (state == USB_CHARGER_PRESENT)
+   usb_charger_get_current(uchger, , );
+   else
+   limit = 0;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,8 +653,31 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   if (wm831x_pdata && wm831x_pdata->usb_gadget) {
+   power->usb_charger =
+   usb_charger_find_by_name(wm831x_pdata->usb_gadget);
+   if (IS_ERR(power->usb_charger)) {
+   ret = PTR_ERR(power->usb_charger);
+   dev_err(>dev,
+   "Failed to find USB gadget: %d\n", ret);
+   goto err_bat_irq;
+   }
+
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+
+   ret = usb_charger_register_notify(power->usb_charger,
+ >usb_notify);
+   if (ret != 0) {
+   dev_err(>dev,
+   "Failed to register notifier: %d\n", ret);
+   goto err_usb_charger;
+   }
+   }
+
return ret;
 
+err_usb_charger:
+   /* put_device on charger */
 err_bat_irq:
--i;
for (; i >= 0; i--) {
@@ -637,6 +706,12 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_charger) {
+   usb_charger_unregister_notify(wm831x_power->usb_charger,
+ _power->usb_notify);
+   /* Free charger */
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
diff --git a/include/linux/mfd/wm831x/pdata.h b/include/linux/mfd/wm831x/pdata.h
index dcc9631..5af8399 100644
--- a/include/linux/mfd/wm831x/pdata.h
+++ b/include/linux/mfd/wm831x/pdata.h
@@ -126,6 +126,9 @@ struct wm831x_pdata {
/** The driver should initiate a power off sequence during shutdown */
bool soft_shutdown;
 
+   /** dev_name of USB charger gadget to 

[PATCH v18 1/4] usb: gadget: Introduce the usb charger framework

[Baolin Wang]

This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.

The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.

The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state. It also supplies the
notification mechanism to userspace When the usb charger state is changed.

Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.

This patch doesn't yet integrate with the gadget code, so some functions
which rely on the 'gadget' are not completed, that will be implemented
in the following patches.

Signed-off-by: Baolin Wang 
Reviewed-by: Li Jun 
Tested-by: Li Jun 
---
 drivers/usb/gadget/Kconfig   |8 +
 drivers/usb/gadget/udc/Makefile  |1 +
 drivers/usb/gadget/udc/charger.c |  782 ++
 include/linux/usb/charger.h  |  185 +
 include/uapi/linux/usb/charger.h |   31 ++
 5 files changed, 1007 insertions(+)
 create mode 100644 drivers/usb/gadget/udc/charger.c
 create mode 100644 include/linux/usb/charger.h
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 2ea3fc3..7520677 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -134,6 +134,14 @@ config U_SERIAL_CONSOLE
help
   It supports the serial gadget can be used as a console.
 
+config USB_CHARGER
+   bool "USB charger support"
+   select EXTCON
+   help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index 98e74ed..ede2351 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -2,6 +2,7 @@
 CFLAGS_trace.o := -I$(src)
 
 udc-core-y := core.o trace.o
+udc-core-$(CONFIG_USB_CHARGER) += charger.o
 
 #
 # USB peripheral controller drivers
diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
new file mode 100644
index 000..d885e86
--- /dev/null
+++ b/drivers/usb/gadget/udc/charger.c
@@ -0,0 +1,782 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN2
+#define DEFAULT_SDP_CUR_MAX500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN500
+#define DEFAULT_DCP_CUR_MAX5000
+#define DEFAULT_CDP_CUR_MIN1500
+#define DEFAULT_CDP_CUR_MAX5000
+#define DEFAULT_ACA_CUR_MIN1500
+#define DEFAULT_ACA_CUR_MAX5000
+
+static DEFINE_IDA(usb_charger_ida);
+static LIST_HEAD(charger_list);
+static DEFINE_MUTEX(charger_lock);
+
+static struct usb_charger *dev_to_uchger(struct device *dev)
+{
+   return NULL;
+}
+
+/*
+ * charger_current_show() - Show the charger current.
+ */
+static ssize_t charger_current_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   unsigned int min, max;
+
+   usb_charger_get_current(uchger, , );
+   return sprintf(buf, "%u-%u\n", min, max);
+}
+static DEVICE_ATTR_RO(charger_current);
+
+/*
+ * charger_type_show() - Show the charger type.
+ *
+ * It can be SDP/DCP/CDP/ACA type, else for unknown type.
+ */
+static ssize_t charger_type_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   int cnt;
+
+   switch (uchger->type) {
+   case SDP_TYPE:
+   cnt = sprintf(buf, "%s\n", "SDP");
+   break;
+   case DCP_TYPE:
+   cnt = sprintf(buf, "%s\n", "DCP");
+   break;
+   case CDP_TYPE:
+   cnt = 

[PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Currently the Linux kernel does not provide any standard integration of this
feature that integrates the USB subsystem with the system power regulation
provided by PMICs meaning that either vendors must add this in their kernels
or USB gadget devices based on Linux (such as mobile phones) may not behave
as they should. Thus provide a standard framework for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger,
which is pending testing. Moreover there may be other potential users will use
it in future.

Changes since v17:
 - Remove goto section in usb_charger_register() function.
 - Remove 'extern' in charger.h file.
 - Move the kfree() to usb_charger_exit() function.

Changes since v16:
 - Modify the charger current range with introducing the maximum and minimum
 current.
 - Remove the getting charger type method from power supply.
 - Add the getting charger type method from extcon system.
 - Introduce new usb_charger_get_current() API for users to get the maximum and
 minimum current.
 - Rename some APIs and other optimization.

Changes since v15:
 - Add charger state checking to avoid sending out duplicate notifies to users.
 - Add one work to notify power users the current has been changed.

Changes since v14:
 - Add kernel documentation for struct usb_cahrger.
 - Remove some redundant WARN() functions.

Changes since v13:
 - Remove the charger checking in usb_gadget_vbus_draw() function.
 - Rename some functions in charger.c file.
 - Rebase on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
tags/usb-for-v4.8

Changes since v12:
 - Remove the class and device things.
 - Link usb charger to udc-core.ko.
 - Create one "charger" subdirectory which holds all charger-related attributes.

Changes since v11:
 - Reviewed and tested by Li Jun.

Changes since v10:
 - Introduce usb_charger_get_state() function to check charger state.
 - Remove the mutex lock in usb_charger_set_cur_limit_by_type() function
 in case will be issued in atomic context.

Baolin Wang (4):
  usb: gadget: Introduce the usb charger framework
  usb: gadget: Support for the usb charger framework
  usb: gadget: Integrate with the usb gadget supporting for usb charger
  power: wm831x_power: Support USB charger current limit management

 drivers/power/wm831x_power.c |   75 
 drivers/usb/gadget/Kconfig   |8 +
 drivers/usb/gadget/udc/Makefile  |1 +
 drivers/usb/gadget/udc/charger.c |  877 ++
 drivers/usb/gadget/udc/core.c|   19 +-
 include/linux/mfd/wm831x/pdata.h |3 +
 include/linux/usb/charger.h  |  185 
 include/linux/usb/gadget.h   |3 +
 include/uapi/linux/usb/charger.h |   31 ++
 9 files changed, 1201 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/gadget/udc/charger.c
 create mode 100644 include/linux/usb/charger.h
 create mode 100644 include/uapi/linux/usb/charger.h

-- 
1.7.9.5

[PATCH v18 2/4] usb: gadget: Support for the usb charger framework

[Baolin Wang]

For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.

It will report to the usb charger when the gadget state is changed,
then the usb charger can do the power things.

Signed-off-by: Baolin Wang 
Reviewed-by: Li Jun 
Tested-by: Li Jun 
---
 drivers/usb/gadget/udc/core.c |   19 ++-
 include/linux/usb/gadget.h|3 +++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 9483489..90df022 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -576,12 +577,17 @@ EXPORT_SYMBOL_GPL(usb_gadget_vbus_connect);
  * reporting how much power the device may consume.  For example, this
  * could affect how quickly batteries are recharged.
  *
+ * It will also notify the USB charger how much power the device may
+ * consume if there is a USB charger linking with the gadget.
+ *
  * Returns zero on success, else negative errno.
  */
 int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
 {
int ret = 0;
 
+   usb_charger_set_cur_limit_by_gadget(gadget, mA);
+
if (!gadget->ops->vbus_draw) {
ret = -EOPNOTSUPP;
goto out;
@@ -963,6 +969,9 @@ static void usb_gadget_state_work(struct work_struct *work)
struct usb_gadget *gadget = work_to_gadget(work);
struct usb_udc *udc = gadget->udc;
 
+   /* when the gadget state is changed, then report to USB charger */
+   usb_charger_plug_by_gadget(gadget, gadget->state);
+
if (udc)
sysfs_notify(>dev.kobj, NULL, "state");
 }
@@ -1132,6 +1141,10 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
if (ret)
goto err4;
 
+   ret = usb_charger_init(gadget);
+   if (ret)
+   goto err5;
+
usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
udc->vbus = true;
 
@@ -1143,7 +1156,7 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
if (ret != -EPROBE_DEFER)
list_del(>pending);
if (ret)
-   goto err5;
+   goto err6;
break;
}
}
@@ -1152,6 +1165,9 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
 
return 0;
 
+err6:
+   usb_charger_exit(gadget);
+
 err5:
device_del(>dev);
 
@@ -1263,6 +1279,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
kobject_uevent(>dev.kobj, KOBJ_REMOVE);
flush_work(>work);
device_unregister(>dev);
+   usb_charger_exit(gadget);
device_unregister(>dev);
 }
 EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 8e81f9e..82a0d63 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define UDC_TRACE_STR_MAX  512
 
@@ -328,6 +329,7 @@ struct usb_gadget_ops {
  * @in_epnum: last used in ep number
  * @mA: last set mA value
  * @otg_caps: OTG capabilities of this gadget.
+ * @charger: Negotiate the power with the usb charger.
  * @sg_supported: true if we can handle scatter-gather
  * @is_otg: True if the USB device port uses a Mini-AB jack, so that the
  * gadget driver must provide a USB OTG descriptor.
@@ -387,6 +389,7 @@ struct usb_gadget {
unsignedin_epnum;
unsignedmA;
struct usb_otg_caps *otg_caps;
+   struct usb_charger  *charger;
 
unsignedsg_supported:1;
unsignedis_otg:1;
-- 
1.7.9.5

[PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Currently the Linux kernel does not provide any standard integration of this
feature that integrates the USB subsystem with the system power regulation
provided by PMICs meaning that either vendors must add this in their kernels
or USB gadget devices based on Linux (such as mobile phones) may not behave
as they should. Thus provide a standard framework for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger,
which is pending testing. Moreover there may be other potential users will use
it in future.

Changes since v17:
 - Remove goto section in usb_charger_register() function.
 - Remove 'extern' in charger.h file.
 - Move the kfree() to usb_charger_exit() function.

Changes since v16:
 - Modify the charger current range with introducing the maximum and minimum
 current.
 - Remove the getting charger type method from power supply.
 - Add the getting charger type method from extcon system.
 - Introduce new usb_charger_get_current() API for users to get the maximum and
 minimum current.
 - Rename some APIs and other optimization.

Changes since v15:
 - Add charger state checking to avoid sending out duplicate notifies to users.
 - Add one work to notify power users the current has been changed.

Changes since v14:
 - Add kernel documentation for struct usb_cahrger.
 - Remove some redundant WARN() functions.

Changes since v13:
 - Remove the charger checking in usb_gadget_vbus_draw() function.
 - Rename some functions in charger.c file.
 - Rebase on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
tags/usb-for-v4.8

Changes since v12:
 - Remove the class and device things.
 - Link usb charger to udc-core.ko.
 - Create one "charger" subdirectory which holds all charger-related attributes.

Changes since v11:
 - Reviewed and tested by Li Jun.

Changes since v10:
 - Introduce usb_charger_get_state() function to check charger state.
 - Remove the mutex lock in usb_charger_set_cur_limit_by_type() function
 in case will be issued in atomic context.

Baolin Wang (4):
  usb: gadget: Introduce the usb charger framework
  usb: gadget: Support for the usb charger framework
  usb: gadget: Integrate with the usb gadget supporting for usb charger
  power: wm831x_power: Support USB charger current limit management

 drivers/power/wm831x_power.c |   75 
 drivers/usb/gadget/Kconfig   |8 +
 drivers/usb/gadget/udc/Makefile  |1 +
 drivers/usb/gadget/udc/charger.c |  877 ++
 drivers/usb/gadget/udc/core.c|   19 +-
 include/linux/mfd/wm831x/pdata.h |3 +
 include/linux/usb/charger.h  |  185 
 include/linux/usb/gadget.h   |3 +
 include/uapi/linux/usb/charger.h |   31 ++
 9 files changed, 1201 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/gadget/udc/charger.c
 create mode 100644 include/linux/usb/charger.h
 create mode 100644 include/uapi/linux/usb/charger.h

-- 
1.7.9.5

[PATCH v18 2/4] usb: gadget: Support for the usb charger framework

[Baolin Wang]

For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.

It will report to the usb charger when the gadget state is changed,
then the usb charger can do the power things.

Signed-off-by: Baolin Wang 
Reviewed-by: Li Jun 
Tested-by: Li Jun 
---
 drivers/usb/gadget/udc/core.c |   19 ++-
 include/linux/usb/gadget.h|3 +++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 9483489..90df022 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -576,12 +577,17 @@ EXPORT_SYMBOL_GPL(usb_gadget_vbus_connect);
  * reporting how much power the device may consume.  For example, this
  * could affect how quickly batteries are recharged.
  *
+ * It will also notify the USB charger how much power the device may
+ * consume if there is a USB charger linking with the gadget.
+ *
  * Returns zero on success, else negative errno.
  */
 int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
 {
int ret = 0;
 
+   usb_charger_set_cur_limit_by_gadget(gadget, mA);
+
if (!gadget->ops->vbus_draw) {
ret = -EOPNOTSUPP;
goto out;
@@ -963,6 +969,9 @@ static void usb_gadget_state_work(struct work_struct *work)
struct usb_gadget *gadget = work_to_gadget(work);
struct usb_udc *udc = gadget->udc;
 
+   /* when the gadget state is changed, then report to USB charger */
+   usb_charger_plug_by_gadget(gadget, gadget->state);
+
if (udc)
sysfs_notify(>dev.kobj, NULL, "state");
 }
@@ -1132,6 +1141,10 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
if (ret)
goto err4;
 
+   ret = usb_charger_init(gadget);
+   if (ret)
+   goto err5;
+
usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
udc->vbus = true;
 
@@ -1143,7 +1156,7 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
if (ret != -EPROBE_DEFER)
list_del(>pending);
if (ret)
-   goto err5;
+   goto err6;
break;
}
}
@@ -1152,6 +1165,9 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
 
return 0;
 
+err6:
+   usb_charger_exit(gadget);
+
 err5:
device_del(>dev);
 
@@ -1263,6 +1279,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
kobject_uevent(>dev.kobj, KOBJ_REMOVE);
flush_work(>work);
device_unregister(>dev);
+   usb_charger_exit(gadget);
device_unregister(>dev);
 }
 EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 8e81f9e..82a0d63 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define UDC_TRACE_STR_MAX  512
 
@@ -328,6 +329,7 @@ struct usb_gadget_ops {
  * @in_epnum: last used in ep number
  * @mA: last set mA value
  * @otg_caps: OTG capabilities of this gadget.
+ * @charger: Negotiate the power with the usb charger.
  * @sg_supported: true if we can handle scatter-gather
  * @is_otg: True if the USB device port uses a Mini-AB jack, so that the
  * gadget driver must provide a USB OTG descriptor.
@@ -387,6 +389,7 @@ struct usb_gadget {
unsignedin_epnum;
unsignedmA;
struct usb_otg_caps *otg_caps;
+   struct usb_charger  *charger;
 
unsignedsg_supported:1;
unsignedis_otg:1;
-- 
1.7.9.5

[PATCH v18 4/4] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown 
Signed-off-by: Baolin Wang 
Acked-by: Lee Jones 
Acked-by: Charles Keepax 
Acked-by: Peter Chen 
Acked-by: Sebastian Reichel 
---
 drivers/power/wm831x_power.c |   75 ++
 include/linux/mfd/wm831x/pdata.h |3 ++
 2 files changed, 78 insertions(+)

diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
index 7082301..2bcd775 100644
--- a/drivers/power/wm831x_power.c
+++ b/drivers/power/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_charger *usb_charger;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,49 @@ static enum power_supply_property wm831x_usb_props[] = {
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long state, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   struct usb_charger *uchger = (struct usb_charger *)data;
+   unsigned int i, best, min, limit;
+
+   if (state == USB_CHARGER_PRESENT)
+   usb_charger_get_current(uchger, , );
+   else
+   limit = 0;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,8 +653,31 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   if (wm831x_pdata && wm831x_pdata->usb_gadget) {
+   power->usb_charger =
+   usb_charger_find_by_name(wm831x_pdata->usb_gadget);
+   if (IS_ERR(power->usb_charger)) {
+   ret = PTR_ERR(power->usb_charger);
+   dev_err(>dev,
+   "Failed to find USB gadget: %d\n", ret);
+   goto err_bat_irq;
+   }
+
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+
+   ret = usb_charger_register_notify(power->usb_charger,
+ >usb_notify);
+   if (ret != 0) {
+   dev_err(>dev,
+   "Failed to register notifier: %d\n", ret);
+   goto err_usb_charger;
+   }
+   }
+
return ret;
 
+err_usb_charger:
+   /* put_device on charger */
 err_bat_irq:
--i;
for (; i >= 0; i--) {
@@ -637,6 +706,12 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_charger) {
+   usb_charger_unregister_notify(wm831x_power->usb_charger,
+ _power->usb_notify);
+   /* Free charger */
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
diff --git a/include/linux/mfd/wm831x/pdata.h b/include/linux/mfd/wm831x/pdata.h
index dcc9631..5af8399 100644
--- a/include/linux/mfd/wm831x/pdata.h
+++ b/include/linux/mfd/wm831x/pdata.h
@@ -126,6 +126,9 @@ struct wm831x_pdata {
/** The driver should initiate a power off sequence during shutdown */
bool soft_shutdown;
 
+   /** dev_name of USB charger gadget to integrate with */
+   const char *usb_gadget;
+
int irq_base;
int gpio_base;
int gpio_defaults[WM831X_GPIO_NUM];
-- 
1.7.9.5

[PATCH v18 1/4] usb: gadget: Introduce the usb charger framework

[Baolin Wang]

This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.

The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.

The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state. It also supplies the
notification mechanism to userspace When the usb charger state is changed.

Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.

This patch doesn't yet integrate with the gadget code, so some functions
which rely on the 'gadget' are not completed, that will be implemented
in the following patches.

Signed-off-by: Baolin Wang 
Reviewed-by: Li Jun 
Tested-by: Li Jun 
---
 drivers/usb/gadget/Kconfig   |8 +
 drivers/usb/gadget/udc/Makefile  |1 +
 drivers/usb/gadget/udc/charger.c |  782 ++
 include/linux/usb/charger.h  |  185 +
 include/uapi/linux/usb/charger.h |   31 ++
 5 files changed, 1007 insertions(+)
 create mode 100644 drivers/usb/gadget/udc/charger.c
 create mode 100644 include/linux/usb/charger.h
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 2ea3fc3..7520677 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -134,6 +134,14 @@ config U_SERIAL_CONSOLE
help
   It supports the serial gadget can be used as a console.
 
+config USB_CHARGER
+   bool "USB charger support"
+   select EXTCON
+   help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index 98e74ed..ede2351 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -2,6 +2,7 @@
 CFLAGS_trace.o := -I$(src)
 
 udc-core-y := core.o trace.o
+udc-core-$(CONFIG_USB_CHARGER) += charger.o
 
 #
 # USB peripheral controller drivers
diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
new file mode 100644
index 000..d885e86
--- /dev/null
+++ b/drivers/usb/gadget/udc/charger.c
@@ -0,0 +1,782 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN2
+#define DEFAULT_SDP_CUR_MAX500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN500
+#define DEFAULT_DCP_CUR_MAX5000
+#define DEFAULT_CDP_CUR_MIN1500
+#define DEFAULT_CDP_CUR_MAX5000
+#define DEFAULT_ACA_CUR_MIN1500
+#define DEFAULT_ACA_CUR_MAX5000
+
+static DEFINE_IDA(usb_charger_ida);
+static LIST_HEAD(charger_list);
+static DEFINE_MUTEX(charger_lock);
+
+static struct usb_charger *dev_to_uchger(struct device *dev)
+{
+   return NULL;
+}
+
+/*
+ * charger_current_show() - Show the charger current.
+ */
+static ssize_t charger_current_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   unsigned int min, max;
+
+   usb_charger_get_current(uchger, , );
+   return sprintf(buf, "%u-%u\n", min, max);
+}
+static DEVICE_ATTR_RO(charger_current);
+
+/*
+ * charger_type_show() - Show the charger type.
+ *
+ * It can be SDP/DCP/CDP/ACA type, else for unknown type.
+ */
+static ssize_t charger_type_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   int cnt;
+
+   switch (uchger->type) {
+   case SDP_TYPE:
+   cnt = sprintf(buf, "%s\n", "SDP");
+   break;
+   case DCP_TYPE:
+   cnt = sprintf(buf, "%s\n", "DCP");
+   break;
+   case CDP_TYPE:
+   cnt = sprintf(buf, "%s\n", "CDP");
+   break;
+   

Re: [PATCH 20/23] ASoC: add simple-graph-card document

[Rob Herring]

On Tue, Oct 18, 2016 at 8:36 PM, Kuninori Morimoto
 wrote:
>
> Hi Rob
>
>> > +   type = "sound";
>>
>> I'm still not convinced this is necessary. This is implied either by
>> the fact there is only one port or perhaps the compatible string.
>
> Do you mean "on this sample" ? or in general ?
> Indeed this sample is definitely for sound, so type is very clear
> without property.
> But in general, for example HDMI, it want to know port type.
> Anyway, I can remove above "type" from this new sound driver.

For HDMI, the port number should dictate which one is video and which is audio.

>> > +rcar_sound {
>> > +   ...
>> > +   port {
>> > +   compatible = "asoc-simple-graph-card";
>> > +
>> > +   simple-audio-card,format = "left_j";
>> > +   simple-audio-card,bitclock-master = <_port>;
>> > +   simple-audio-card,frame-master = <_port>;
>>
>> Don't add a bunch of properties with in port and endpoint nodes. The
>> purpose is to describe the graph. Put these in the parent node or
>> perhaps the codec node.
>
> These properties are needed on each ports/endpoints on sound at this point.
> If ports/endpoints can't include these, I need to separate these,
> is it correct approach ? ?? see below

Uhh, no. Not at all what I had in mind.

> -- current style --
>
> ports {
> compatible = "asoc-simple-graph-card";

I think your problems start with trying to extend simple-card. This
binding is anything but simple. I think using OF graph is a good idea,
but trying to make it completely generic is not.

> simple-audio-card,name = "graph-sound";
>
> port@0 {
> simple-audio-card,format = "left_j";
> simple-audio-card,bitclock-master = 
> <_ak4613_port>;
> simple-audio-card,frame-master = <_ak4613_port>;

These look like properties of the ak4613 to me, so put them in the
ak4613 node. If they are standard property names, then you just walk
the graph and get them.

>
> type = "sound";
> rcar_ak4613_port: endpoint {
> remote-endpoint = <_port>;
> playback = <  >;
> capture  = <  >;

Not really sure how you are using these to comment.

> };
> };
> port@1 {
> simple-audio-card,format = "i2s";
> simple-audio-card,bitclock-master = 
> <_hdmi0_port>;
> simple-audio-card,frame-master = <_hdmi0_port>;
> type = "sound";
> rcar_hdmi0_port: endpoint {
> remote-endpoint = <_out_hdmi_snd0>;
> playback = <>;

If you are trying to describe a connection between hdmi_snd0 and ssi2,
then do just that. Add a port to ssi2 and connect it to hdmi_snd0.

> };
> };
> port@2 {
> simple-audio-card,format = "i2s";
> simple-audio-card,bitclock-master = 
> <_hdmi1_port>;
> simple-audio-card,frame-master = <_hdmi1_port>;
> type = "sound";
> rcar_hdmi1_port: endpoint {
> remote-endpoint = <_out_hdmi_snd1>;
> playback = <>;
> };
> };
> };
>
> -- separate style --
>
> ports {
> port@0 {
> rcar_ak4613_port: endpoint {
> }
> };
> port@1 {
> rcar_hdmi0_port: endpoint {
> }
> };
> port@2 {
> rcar_hdmi1_port: endpoint {
> }
> };
> };
>
> sound-xxx {
> compatible = "asoc-simple-graph-card";
>
> port@0 {
> simple-audio-card,format = "left_j";
> simple-audio-card,bitclock-master = 
> <_ak4613_port>;
> simple-audio-card,frame-master = <_ak4613_port>;
> };
> port@1 {
> simple-audio-card,format = "i2s";
> simple-audio-card,bitclock-master = 
> <_hdmi0_port>;
> simple-audio-card,frame-master = <_hdmi0_port>;
> };
> port@2 {
> simple-audio-card,format = "i2s";
> simple-audio-card,bitclock-master = 
> <_hdmi1_port>;
> simple-audio-card,frame-master = <_hdmi1_port>;
> };
> };
>
> Best regards
> ---
> 

linux-next: Tree for Oct 19

[Stephen Rothwell]

Hi all,

Changes since 20161018:

The drm-intel tree lost its build failures.

The akpm-current tree still had its build failures for which I applied
2 patches.

Non-merge commits (relative to Linus' tree): 1218
 1521 files changed, 58816 insertions(+), 23659 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 243 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1a1891d762d6 Merge tag 'for-f2fs-4.9-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (27f3d2a3b59f ARC: [build] Support gz, lzma 
compressed uImage)
Merging arm-current/fixes (6df1f75cfe0c ARM: Fix oops when using older ARMv4T 
CPUs)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks 
for SR-IOV and window alignment)
Merging sparc/master (4c1fad64eff4 Merge tag 'for-f2fs-4.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs)
Merging net/master (b4f0fd4baa90 qed: Use list_move_tail instead of 
list_del/list_add_tail)
CONFLICT (content): Merge conflict in drivers/net/ethernet/qlogic/Kconfig
Applying: qed*: merge fix for CONFIG_INFINIBAND_QEDR Kconfig move
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (6d3a4c404648 strparser: Propagate correct error code 
in strp_recv())
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (1ea2643961b0 ath6kl: add Dell OEM SDIO I/O for 
the Venue 8 Pro)
Merging mac80211/master (f4a067f9ffca mac80211: move struct aead_req off the 
stack)
Merging sound-current/for-linus (d69bb92e402f ALSA: asihpi: fix kernel memory 
disclosure)
Merging pci-current/for-linus (15480f3ab7a8 PCI: layerscape: Fix drvdata usage 
before assignment)
Merging driver-core.current/driver-core-linus (1001354ca341 Linux 4.9-rc1)
Merging tty.current/tty-linus (1001354ca341 Linux 4.9-rc1)
Merging usb.current/usb-linus (a19b882c07a6 wusb: Stop using the stack for sg 
crypto scratch space)
Merging usb-gadget-fixes/fixes (a1aa8cf6471b Revert "Documentation: devicetree: 
dwc2: Deprecate g-tx-fifo-size")
Merging usb-serial-fixes/usb-linus (ca006f785fbf USB: serial: ftdi_sio: add 
support for Infineon TriBoard TC2X7)
Merging usb-chipidea-fixes/ci-for-usb-stable (6b7f456e67a1 usb: chipidea: host: 
fix NULL ptr dereference during shutdown)
Merging staging.current/staging-linus (c89d98e224b4 staging/lustre/llite: Move 
unstable_stats from sysfs to debugfs)
Merging char-misc.current/char-misc-linus (1001354ca341 Linux 4.9-rc1)
Merging input-current/for-linus (1134ca268e73 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (c3afafa47898 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fi

[PATCH v18 3/4] usb: gadget: Integrate with the usb gadget supporting for usb charger

[Baolin Wang]

When the usb gadget supporting for usb charger is ready, the usb charger
can implement the usb_charger_plug_by_gadget() function, usb_charger_exit()
function and dev_to_uchger() function by getting 'struct usb_charger' from
'struct gadget'.

Signed-off-by: Baolin Wang 
Reviewed-by: Li Jun 
Tested-by: Li Jun 
---
 drivers/usb/gadget/udc/charger.c |   97 +-
 1 file changed, 96 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
index d885e86..56aee28 100644
--- a/drivers/usb/gadget/udc/charger.c
+++ b/drivers/usb/gadget/udc/charger.c
@@ -38,7 +38,9 @@ static DEFINE_MUTEX(charger_lock);
 
 static struct usb_charger *dev_to_uchger(struct device *dev)
 {
-   return NULL;
+   struct usb_gadget *gadget = container_of(dev, struct usb_gadget, dev);
+
+   return gadget->charger;
 }
 
 /*
@@ -308,6 +310,18 @@ static int __usb_charger_set_cur_limit_by_type(struct 
usb_charger *uchger,
 int usb_charger_set_cur_limit_by_gadget(struct usb_gadget *gadget,
unsigned int cur_limit)
 {
+   struct usb_charger *uchger = gadget->charger;
+   int ret;
+
+   if (!uchger)
+   return -EINVAL;
+
+   ret = __usb_charger_set_cur_limit_by_type(uchger, uchger->type,
+ cur_limit);
+   if (ret)
+   return ret;
+
+   schedule_work(>work);
return 0;
 }
 EXPORT_SYMBOL_GPL(usb_charger_set_cur_limit_by_gadget);
@@ -625,11 +639,66 @@ static int usb_charger_plug_by_extcon(struct 
notifier_block *nb,
 int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
   unsigned long state)
 {
+   struct usb_charger *uchger = gadget->charger;
+   enum usb_charger_state uchger_state;
+
+   if (WARN(!uchger, "charger can not be NULL"))
+   return -EINVAL;
+
+   /*
+* Report event to power to setting the current limitation
+* for this usb charger when one usb charger state is changed
+* with detecting by usb gadget state.
+*/
+   if (uchger->old_gadget_state != state) {
+   uchger->old_gadget_state = state;
+
+   if (state >= USB_STATE_ATTACHED) {
+   uchger_state = USB_CHARGER_PRESENT;
+   } else if (state == USB_STATE_NOTATTACHED) {
+   mutex_lock(>lock);
+
+   /*
+* Need check the charger type to make sure the usb
+* cable is removed, in case it just changes the usb
+* function with configfs.
+*/
+   uchger->type = __usb_charger_get_type(uchger);
+   if (uchger->type != UNKNOWN_TYPE) {
+   mutex_unlock(>lock);
+   return 0;
+   }
+
+   mutex_unlock(>lock);
+   uchger_state = USB_CHARGER_REMOVE;
+   } else {
+   uchger_state = USB_CHARGER_DEFAULT;
+   }
+
+   usb_charger_notify_state(uchger, uchger_state);
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(usb_charger_plug_by_gadget);
 
 /*
+ * usb_charger_unregister() - Unregister a usb charger.
+ * @uchger - the usb charger to be unregistered.
+ */
+static int usb_charger_unregister(struct usb_charger *uchger)
+{
+   ida_simple_remove(_charger_ida, uchger->id);
+   sysfs_remove_groups(>gadget->dev.kobj, usb_charger_groups);
+
+   mutex_lock(_lock);
+   list_del(>list);
+   mutex_unlock(_lock);
+
+   return 0;
+}
+
+/*
  * usb_charger_register() - Register a new usb charger.
  * @uchger - the new usb charger instance.
  */
@@ -737,6 +806,7 @@ int usb_charger_init(struct usb_gadget *ugadget)
}
 
uchger->gadget = ugadget;
+   ugadget->charger = uchger;
uchger->old_gadget_state = USB_STATE_NOTATTACHED;
 
/* Register a new usb charger */
@@ -774,6 +844,31 @@ fail_extcon:
 
 int usb_charger_exit(struct usb_gadget *ugadget)
 {
+   struct usb_charger *uchger = ugadget->charger;
+
+   if (!uchger)
+   return -EINVAL;
+
+   usb_charger_unregister(uchger);
+   ugadget->charger = NULL;
+
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_USB,
+  >extcon_nb.nb);
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_CHG_USB_SDP,
+  >extcon_type_nb.nb);
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_CHG_USB_CDP,
+  >extcon_type_nb.nb);
+   extcon_unregister_notifier(uchger->extcon_dev,
+

Re: [PATCH 20/23] ASoC: add simple-graph-card document

[Rob Herring]

On Tue, Oct 18, 2016 at 8:36 PM, Kuninori Morimoto
 wrote:
>
> Hi Rob
>
>> > +   type = "sound";
>>
>> I'm still not convinced this is necessary. This is implied either by
>> the fact there is only one port or perhaps the compatible string.
>
> Do you mean "on this sample" ? or in general ?
> Indeed this sample is definitely for sound, so type is very clear
> without property.
> But in general, for example HDMI, it want to know port type.
> Anyway, I can remove above "type" from this new sound driver.

For HDMI, the port number should dictate which one is video and which is audio.

>> > +rcar_sound {
>> > +   ...
>> > +   port {
>> > +   compatible = "asoc-simple-graph-card";
>> > +
>> > +   simple-audio-card,format = "left_j";
>> > +   simple-audio-card,bitclock-master = <_port>;
>> > +   simple-audio-card,frame-master = <_port>;
>>
>> Don't add a bunch of properties with in port and endpoint nodes. The
>> purpose is to describe the graph. Put these in the parent node or
>> perhaps the codec node.
>
> These properties are needed on each ports/endpoints on sound at this point.
> If ports/endpoints can't include these, I need to separate these,
> is it correct approach ? ?? see below

Uhh, no. Not at all what I had in mind.

> -- current style --
>
> ports {
> compatible = "asoc-simple-graph-card";

I think your problems start with trying to extend simple-card. This
binding is anything but simple. I think using OF graph is a good idea,
but trying to make it completely generic is not.

> simple-audio-card,name = "graph-sound";
>
> port@0 {
> simple-audio-card,format = "left_j";
> simple-audio-card,bitclock-master = 
> <_ak4613_port>;
> simple-audio-card,frame-master = <_ak4613_port>;

These look like properties of the ak4613 to me, so put them in the
ak4613 node. If they are standard property names, then you just walk
the graph and get them.

>
> type = "sound";
> rcar_ak4613_port: endpoint {
> remote-endpoint = <_port>;
> playback = <  >;
> capture  = <  >;

Not really sure how you are using these to comment.

> };
> };
> port@1 {
> simple-audio-card,format = "i2s";
> simple-audio-card,bitclock-master = 
> <_hdmi0_port>;
> simple-audio-card,frame-master = <_hdmi0_port>;
> type = "sound";
> rcar_hdmi0_port: endpoint {
> remote-endpoint = <_out_hdmi_snd0>;
> playback = <>;

If you are trying to describe a connection between hdmi_snd0 and ssi2,
then do just that. Add a port to ssi2 and connect it to hdmi_snd0.

> };
> };
> port@2 {
> simple-audio-card,format = "i2s";
> simple-audio-card,bitclock-master = 
> <_hdmi1_port>;
> simple-audio-card,frame-master = <_hdmi1_port>;
> type = "sound";
> rcar_hdmi1_port: endpoint {
> remote-endpoint = <_out_hdmi_snd1>;
> playback = <>;
> };
> };
> };
>
> -- separate style --
>
> ports {
> port@0 {
> rcar_ak4613_port: endpoint {
> }
> };
> port@1 {
> rcar_hdmi0_port: endpoint {
> }
> };
> port@2 {
> rcar_hdmi1_port: endpoint {
> }
> };
> };
>
> sound-xxx {
> compatible = "asoc-simple-graph-card";
>
> port@0 {
> simple-audio-card,format = "left_j";
> simple-audio-card,bitclock-master = 
> <_ak4613_port>;
> simple-audio-card,frame-master = <_ak4613_port>;
> };
> port@1 {
> simple-audio-card,format = "i2s";
> simple-audio-card,bitclock-master = 
> <_hdmi0_port>;
> simple-audio-card,frame-master = <_hdmi0_port>;
> };
> port@2 {
> simple-audio-card,format = "i2s";
> simple-audio-card,bitclock-master = 
> <_hdmi1_port>;
> simple-audio-card,frame-master = <_hdmi1_port>;
> };
> };
>
> Best regards
> ---
> Kuninori Morimoto

linux-next: Tree for Oct 19

[Stephen Rothwell]

Hi all,

Changes since 20161018:

The drm-intel tree lost its build failures.

The akpm-current tree still had its build failures for which I applied
2 patches.

Non-merge commits (relative to Linus' tree): 1218
 1521 files changed, 58816 insertions(+), 23659 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 243 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1a1891d762d6 Merge tag 'for-f2fs-4.9-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (27f3d2a3b59f ARC: [build] Support gz, lzma 
compressed uImage)
Merging arm-current/fixes (6df1f75cfe0c ARM: Fix oops when using older ARMv4T 
CPUs)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks 
for SR-IOV and window alignment)
Merging sparc/master (4c1fad64eff4 Merge tag 'for-f2fs-4.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs)
Merging net/master (b4f0fd4baa90 qed: Use list_move_tail instead of 
list_del/list_add_tail)
CONFLICT (content): Merge conflict in drivers/net/ethernet/qlogic/Kconfig
Applying: qed*: merge fix for CONFIG_INFINIBAND_QEDR Kconfig move
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (6d3a4c404648 strparser: Propagate correct error code 
in strp_recv())
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (1ea2643961b0 ath6kl: add Dell OEM SDIO I/O for 
the Venue 8 Pro)
Merging mac80211/master (f4a067f9ffca mac80211: move struct aead_req off the 
stack)
Merging sound-current/for-linus (d69bb92e402f ALSA: asihpi: fix kernel memory 
disclosure)
Merging pci-current/for-linus (15480f3ab7a8 PCI: layerscape: Fix drvdata usage 
before assignment)
Merging driver-core.current/driver-core-linus (1001354ca341 Linux 4.9-rc1)
Merging tty.current/tty-linus (1001354ca341 Linux 4.9-rc1)
Merging usb.current/usb-linus (a19b882c07a6 wusb: Stop using the stack for sg 
crypto scratch space)
Merging usb-gadget-fixes/fixes (a1aa8cf6471b Revert "Documentation: devicetree: 
dwc2: Deprecate g-tx-fifo-size")
Merging usb-serial-fixes/usb-linus (ca006f785fbf USB: serial: ftdi_sio: add 
support for Infineon TriBoard TC2X7)
Merging usb-chipidea-fixes/ci-for-usb-stable (6b7f456e67a1 usb: chipidea: host: 
fix NULL ptr dereference during shutdown)
Merging staging.current/staging-linus (c89d98e224b4 staging/lustre/llite: Move 
unstable_stats from sysfs to debugfs)
Merging char-misc.current/char-misc-linus (1001354ca341 Linux 4.9-rc1)
Merging input-current/for-linus (1134ca268e73 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (c3afafa47898 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fi

[PATCH v18 3/4] usb: gadget: Integrate with the usb gadget supporting for usb charger

[Baolin Wang]

When the usb gadget supporting for usb charger is ready, the usb charger
can implement the usb_charger_plug_by_gadget() function, usb_charger_exit()
function and dev_to_uchger() function by getting 'struct usb_charger' from
'struct gadget'.

Signed-off-by: Baolin Wang 
Reviewed-by: Li Jun 
Tested-by: Li Jun 
---
 drivers/usb/gadget/udc/charger.c |   97 +-
 1 file changed, 96 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
index d885e86..56aee28 100644
--- a/drivers/usb/gadget/udc/charger.c
+++ b/drivers/usb/gadget/udc/charger.c
@@ -38,7 +38,9 @@ static DEFINE_MUTEX(charger_lock);
 
 static struct usb_charger *dev_to_uchger(struct device *dev)
 {
-   return NULL;
+   struct usb_gadget *gadget = container_of(dev, struct usb_gadget, dev);
+
+   return gadget->charger;
 }
 
 /*
@@ -308,6 +310,18 @@ static int __usb_charger_set_cur_limit_by_type(struct 
usb_charger *uchger,
 int usb_charger_set_cur_limit_by_gadget(struct usb_gadget *gadget,
unsigned int cur_limit)
 {
+   struct usb_charger *uchger = gadget->charger;
+   int ret;
+
+   if (!uchger)
+   return -EINVAL;
+
+   ret = __usb_charger_set_cur_limit_by_type(uchger, uchger->type,
+ cur_limit);
+   if (ret)
+   return ret;
+
+   schedule_work(>work);
return 0;
 }
 EXPORT_SYMBOL_GPL(usb_charger_set_cur_limit_by_gadget);
@@ -625,11 +639,66 @@ static int usb_charger_plug_by_extcon(struct 
notifier_block *nb,
 int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
   unsigned long state)
 {
+   struct usb_charger *uchger = gadget->charger;
+   enum usb_charger_state uchger_state;
+
+   if (WARN(!uchger, "charger can not be NULL"))
+   return -EINVAL;
+
+   /*
+* Report event to power to setting the current limitation
+* for this usb charger when one usb charger state is changed
+* with detecting by usb gadget state.
+*/
+   if (uchger->old_gadget_state != state) {
+   uchger->old_gadget_state = state;
+
+   if (state >= USB_STATE_ATTACHED) {
+   uchger_state = USB_CHARGER_PRESENT;
+   } else if (state == USB_STATE_NOTATTACHED) {
+   mutex_lock(>lock);
+
+   /*
+* Need check the charger type to make sure the usb
+* cable is removed, in case it just changes the usb
+* function with configfs.
+*/
+   uchger->type = __usb_charger_get_type(uchger);
+   if (uchger->type != UNKNOWN_TYPE) {
+   mutex_unlock(>lock);
+   return 0;
+   }
+
+   mutex_unlock(>lock);
+   uchger_state = USB_CHARGER_REMOVE;
+   } else {
+   uchger_state = USB_CHARGER_DEFAULT;
+   }
+
+   usb_charger_notify_state(uchger, uchger_state);
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(usb_charger_plug_by_gadget);
 
 /*
+ * usb_charger_unregister() - Unregister a usb charger.
+ * @uchger - the usb charger to be unregistered.
+ */
+static int usb_charger_unregister(struct usb_charger *uchger)
+{
+   ida_simple_remove(_charger_ida, uchger->id);
+   sysfs_remove_groups(>gadget->dev.kobj, usb_charger_groups);
+
+   mutex_lock(_lock);
+   list_del(>list);
+   mutex_unlock(_lock);
+
+   return 0;
+}
+
+/*
  * usb_charger_register() - Register a new usb charger.
  * @uchger - the new usb charger instance.
  */
@@ -737,6 +806,7 @@ int usb_charger_init(struct usb_gadget *ugadget)
}
 
uchger->gadget = ugadget;
+   ugadget->charger = uchger;
uchger->old_gadget_state = USB_STATE_NOTATTACHED;
 
/* Register a new usb charger */
@@ -774,6 +844,31 @@ fail_extcon:
 
 int usb_charger_exit(struct usb_gadget *ugadget)
 {
+   struct usb_charger *uchger = ugadget->charger;
+
+   if (!uchger)
+   return -EINVAL;
+
+   usb_charger_unregister(uchger);
+   ugadget->charger = NULL;
+
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_USB,
+  >extcon_nb.nb);
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_CHG_USB_SDP,
+  >extcon_type_nb.nb);
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_CHG_USB_CDP,
+  >extcon_type_nb.nb);
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_CHG_USB_DCP,
+ 

Re: [PATCH net-next 00/15] ethernet: use core min/max MTU checking

[Jarod Wilson]

On Tue, Oct 18, 2016 at 06:28:20PM -0400, Jarod Wilson wrote:
> On Tue, Oct 18, 2016 at 11:33:27AM -0400, David Miller wrote:
> > From: Jarod Wilson 
> > Date: Mon, 17 Oct 2016 16:29:43 -0400
> > 
> > > On Mon, Oct 17, 2016 at 04:03:41PM -0400, David Miller wrote:
> > >> From: Jarod Wilson 
> > >> Date: Mon, 17 Oct 2016 15:54:02 -0400
> > >> 
> > >> > For the most part, every patch does the same essential thing: removes 
> > >> > the
> > >> > MTU range checking from the drivers' ndo_change_mtu function, puts 
> > >> > those
> > >> > ranges into the core net_device min_mtu and max_mtu fields, and where
> > >> > possible, removes ndo_change_mtu functions entirely.
> > >> 
> > >> Jarod, please read my other posting.
> > > 
> > > Done, didn't see it until just after I'd hit send, have replied there as
> > > well.
> > > 
> > >> You've positively broken the maximum MTU for all of these drivers.
> > >> 
> > >> That's not cool.
> > >>
> > >> And this series fixing things doesn't make things better, because now
> > >> we've significanyly broken bisection for anyone running into this
> > >> regression.
> > > 
> > > Agreed, and my suggestion right now is to revert the 2nd patch from the
> > > prior series. I believe it can be resubmitted after all other callers of
> > > ether_setup() have been converted to have their own min/max_mtu.
> > > 
> > >> You should have arranged this in such a way that the drivers needing
> > >> > 1500 byte MTU were not impacted at all by your changes, but that
> > >> isn't what happened.
> > > 
> > > Yeah, I must admit to not looking closely enough at the state the first
> > > two patches left things in. It was absolutely my intention to not alter
> > > behaviour in any way, but I neglected to test sufficiently without this
> > > additional set applied.
> > 
> > So what I'm going to do now it simply just apply your current patch series
> > to net-next and hope this gets everything working again.
> 
> Unfortunately, no, it doesn't get *everything* working again, because...
> 
> direct ether_setup() callers:
> 
> drivers/misc/sgi-xp/xpnet.c
> drivers/net/geneve.c
> drivers/net/macvlan.c
> drivers/net/tun.c
> drivers/net/vxlan.c
> drivers/net/wan/hdlc.c
> drivers/net/wan/hdlc_fr.c
> drivers/net/wireless/ath/wil6210/netdev.c
> drivers/net/wireless/cisco/airo.c
> drivers/staging/wlan-ng/p80211netdev.c
> net/batman-adv/soft-interface.c
> net/bridge/br_device.c
> net/openvswitch/vport-internal_dev.c
> 
> alloc_etherdev*() callers:
> drivers/infiniband/hw/nes/nes_nic.c
> drivers/net/hyperv/netvsc_drv.c
> drivers/net/rionet.c
> drivers/net/usb/lan78xx.c
> drivers/net/usb/r8152.c
> drivers/net/usb/usbnet.c
> drivers/net/virtio_net.c
> drivers/net/vmxnet3/vmxnet3_drv.c
> drivers/net/wireless/atmel/atmel.c
> drivers/net/wireless/cisco/airo.c
> drivers/net/wireless/intel/ipw2x00/libipw_module.c
> net/atm/lec.c
> 
> I have additional patches for all of these that I haven't yet posted, so
> I'd still suggest backing out the one patch to keep the above working too
> until the subsequent patches are posted.

They're all posted now, just 6 more relatively small patches, though the
ones touching geneve and vxlan are a bit more involved than any others,
and could use a very close look (relevant people should all be cc'd).
Still wouldn't have any objection at all to backing out the patch that
touches min/max_mtu in ether_setup() though.

-- 
Jarod Wilson
ja...@redhat.com

Re: [PATCH net-next 00/15] ethernet: use core min/max MTU checking

[Jarod Wilson]

On Tue, Oct 18, 2016 at 06:28:20PM -0400, Jarod Wilson wrote:
> On Tue, Oct 18, 2016 at 11:33:27AM -0400, David Miller wrote:
> > From: Jarod Wilson 
> > Date: Mon, 17 Oct 2016 16:29:43 -0400
> > 
> > > On Mon, Oct 17, 2016 at 04:03:41PM -0400, David Miller wrote:
> > >> From: Jarod Wilson 
> > >> Date: Mon, 17 Oct 2016 15:54:02 -0400
> > >> 
> > >> > For the most part, every patch does the same essential thing: removes 
> > >> > the
> > >> > MTU range checking from the drivers' ndo_change_mtu function, puts 
> > >> > those
> > >> > ranges into the core net_device min_mtu and max_mtu fields, and where
> > >> > possible, removes ndo_change_mtu functions entirely.
> > >> 
> > >> Jarod, please read my other posting.
> > > 
> > > Done, didn't see it until just after I'd hit send, have replied there as
> > > well.
> > > 
> > >> You've positively broken the maximum MTU for all of these drivers.
> > >> 
> > >> That's not cool.
> > >>
> > >> And this series fixing things doesn't make things better, because now
> > >> we've significanyly broken bisection for anyone running into this
> > >> regression.
> > > 
> > > Agreed, and my suggestion right now is to revert the 2nd patch from the
> > > prior series. I believe it can be resubmitted after all other callers of
> > > ether_setup() have been converted to have their own min/max_mtu.
> > > 
> > >> You should have arranged this in such a way that the drivers needing
> > >> > 1500 byte MTU were not impacted at all by your changes, but that
> > >> isn't what happened.
> > > 
> > > Yeah, I must admit to not looking closely enough at the state the first
> > > two patches left things in. It was absolutely my intention to not alter
> > > behaviour in any way, but I neglected to test sufficiently without this
> > > additional set applied.
> > 
> > So what I'm going to do now it simply just apply your current patch series
> > to net-next and hope this gets everything working again.
> 
> Unfortunately, no, it doesn't get *everything* working again, because...
> 
> direct ether_setup() callers:
> 
> drivers/misc/sgi-xp/xpnet.c
> drivers/net/geneve.c
> drivers/net/macvlan.c
> drivers/net/tun.c
> drivers/net/vxlan.c
> drivers/net/wan/hdlc.c
> drivers/net/wan/hdlc_fr.c
> drivers/net/wireless/ath/wil6210/netdev.c
> drivers/net/wireless/cisco/airo.c
> drivers/staging/wlan-ng/p80211netdev.c
> net/batman-adv/soft-interface.c
> net/bridge/br_device.c
> net/openvswitch/vport-internal_dev.c
> 
> alloc_etherdev*() callers:
> drivers/infiniband/hw/nes/nes_nic.c
> drivers/net/hyperv/netvsc_drv.c
> drivers/net/rionet.c
> drivers/net/usb/lan78xx.c
> drivers/net/usb/r8152.c
> drivers/net/usb/usbnet.c
> drivers/net/virtio_net.c
> drivers/net/vmxnet3/vmxnet3_drv.c
> drivers/net/wireless/atmel/atmel.c
> drivers/net/wireless/cisco/airo.c
> drivers/net/wireless/intel/ipw2x00/libipw_module.c
> net/atm/lec.c
> 
> I have additional patches for all of these that I haven't yet posted, so
> I'd still suggest backing out the one patch to keep the above working too
> until the subsequent patches are posted.

They're all posted now, just 6 more relatively small patches, though the
ones touching geneve and vxlan are a bit more involved than any others,
and could use a very close look (relevant people should all be cc'd).
Still wouldn't have any objection at all to backing out the patch that
touches min/max_mtu in ether_setup() though.

-- 
Jarod Wilson
ja...@redhat.com

[PATCH net-next 6/6] net: use core MTU range checking in misc drivers

[Jarod Wilson]

firewire-net:
- set min/max_mtu
- remove fwnet_change_mtu

nes:
- set max_mtu
- clean up nes_netdev_change_mtu

xpnet:
- set min/max_mtu
- remove xpnet_dev_change_mtu

hippi:
- set min/max_mtu
- remove hippi_change_mtu

batman-adv:
- set max_mtu
- remove batadv_interface_change_mtu
- initialization is a little async, not 100% certain that max_mtu is set
  in the optimal place, don't have hardware to test with

rionet:
- set min/max_mtu
- remove rionet_change_mtu

slip:
- set min/max_mtu
- streamline sl_change_mtu

CC: net...@vger.kernel.org
CC: Stefan Richter 
CC: Faisal Latif 
CC: linux-r...@vger.kernel.org
CC: Cliff Whickman 
CC: Robin Holt 
CC: Jes Sorensen 
CC: Marek Lindner 
CC: Simon Wunderlich 
CC: Antonio Quartulli 
Signed-off-by: Jarod Wilson 
---
 drivers/firewire/net.c  | 12 ++--
 drivers/infiniband/hw/nes/nes.c |  1 -
 drivers/infiniband/hw/nes/nes.h |  4 ++--
 drivers/infiniband/hw/nes/nes_nic.c | 10 +++---
 drivers/misc/sgi-xp/xpnet.c | 21 -
 drivers/net/hippi/rrunner.c |  1 -
 drivers/net/rionet.c| 15 +++
 drivers/net/slip/slip.c | 11 +--
 include/linux/hippidevice.h |  1 -
 net/802/hippi.c | 14 ++
 net/batman-adv/soft-interface.c | 13 +
 11 files changed, 22 insertions(+), 81 deletions(-)

diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index 309311b..b5f125c 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -1349,15 +1349,6 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, struct 
net_device *net)
return NETDEV_TX_OK;
 }
 
-static int fwnet_change_mtu(struct net_device *net, int new_mtu)
-{
-   if (new_mtu < 68)
-   return -EINVAL;
-
-   net->mtu = new_mtu;
-   return 0;
-}
-
 static const struct ethtool_ops fwnet_ethtool_ops = {
.get_link   = ethtool_op_get_link,
 };
@@ -1366,7 +1357,6 @@ static const struct net_device_ops fwnet_netdev_ops = {
.ndo_open   = fwnet_open,
.ndo_stop   = fwnet_stop,
.ndo_start_xmit = fwnet_tx,
-   .ndo_change_mtu = fwnet_change_mtu,
 };
 
 static void fwnet_init_dev(struct net_device *net)
@@ -1481,6 +1471,8 @@ static int fwnet_probe(struct fw_unit *unit,
max_mtu = (1 << (card->max_receive + 1))
  - sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE;
net->mtu = min(1500U, max_mtu);
+   net->min_mtu = ETH_MIN_MTU;
+   net->max_mtu = net->mtu;
 
/* Set our hardware address while we're at it */
ha = (union fwnet_hwaddr *)net->dev_addr;
diff --git a/drivers/infiniband/hw/nes/nes.c b/drivers/infiniband/hw/nes/nes.c
index 35cbb17..2baa45a 100644
--- a/drivers/infiniband/hw/nes/nes.c
+++ b/drivers/infiniband/hw/nes/nes.c
@@ -65,7 +65,6 @@ MODULE_DESCRIPTION("NetEffect RNIC Low-level iWARP Driver");
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_VERSION(DRV_VERSION);
 
-int max_mtu = 9000;
 int interrupt_mod_interval = 0;
 
 /* Interoperability */
diff --git a/drivers/infiniband/hw/nes/nes.h b/drivers/infiniband/hw/nes/nes.h
index e7430c9..85acd08 100644
--- a/drivers/infiniband/hw/nes/nes.h
+++ b/drivers/infiniband/hw/nes/nes.h
@@ -83,6 +83,8 @@
 #define NES_FIRST_QPN   64
 #define NES_SW_CONTEXT_ALIGN1024
 
+#define NES_MAX_MTU9000
+
 #define NES_NIC_MAX_NICS16
 #define NES_MAX_ARP_TABLE_SIZE  4096
 
@@ -169,8 +171,6 @@ do { \
 #include "nes_cm.h"
 #include "nes_mgt.h"
 
-extern int max_mtu;
-#define max_frame_len (max_mtu+ETH_HLEN)
 extern int interrupt_mod_interval;
 extern int nes_if_count;
 extern int mpa_version;
diff --git a/drivers/infiniband/hw/nes/nes_nic.c 
b/drivers/infiniband/hw/nes/nes_nic.c
index 2b27d13..7f8597d 100644
--- a/drivers/infiniband/hw/nes/nes_nic.c
+++ b/drivers/infiniband/hw/nes/nes_nic.c
@@ -981,20 +981,16 @@ static int nes_netdev_change_mtu(struct net_device 
*netdev, int new_mtu)
 {
struct nes_vnic *nesvnic = netdev_priv(netdev);
struct nes_device *nesdev = nesvnic->nesdev;
-   int ret = 0;
u8 jumbomode = 0;
u32 nic_active;
u32 nic_active_bit;
u32 uc_all_active;
u32 mc_all_active;
 
-   if ((new_mtu < ETH_ZLEN) || (new_mtu > max_mtu))
-   return -EINVAL;
-
netdev->mtu = new_mtu;
nesvnic->max_frame_size = new_mtu + VLAN_ETH_HLEN;
 
-   if (netdev->mtu > 1500) {
+   if (netdev->mtu > ETH_DATA_LEN) {
jumbomode=1;
}
nes_nic_init_timer_defaults(nesdev, jumbomode);
@@ -1020,7 +1016,7 @@ static int nes_netdev_change_mtu(struct net_device 
*netdev, int new_mtu)
nes_write_indexed(nesdev, NES_IDX_NIC_UNICAST_ALL, nic_active);
}
 

[PATCH net-next 5/6] net: use core MTU range checking in virt drivers

[Jarod Wilson]

hyperv_net:
- set min/max_mtu

virtio_net:
- set min/max_mtu
- remove virtnet_change_mtu

vmxnet3:
- set min/max_mtu

CC: net...@vger.kernel.org
CC: virtualizat...@lists.linux-foundation.org
CC: "K. Y. Srinivasan" 
CC: Haiyang Zhang 
CC: "Michael S. Tsirkin" 
CC: Shrikrishna Khare 
CC: "VMware, Inc." 
Signed-off-by: Jarod Wilson 
---
 drivers/net/hyperv/hyperv_net.h   |  4 ++--
 drivers/net/hyperv/netvsc_drv.c   | 14 +++---
 drivers/net/virtio_net.c  | 23 ++-
 drivers/net/vmxnet3/vmxnet3_drv.c |  7 ---
 4 files changed, 23 insertions(+), 25 deletions(-)

diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index f4fbcb5..3958ada 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -606,8 +606,8 @@ struct nvsp_message {
 } __packed;
 
 
-#define NETVSC_MTU 65536
-#define NETVSC_MTU_MIN 68
+#define NETVSC_MTU 65535
+#define NETVSC_MTU_MIN ETH_MIN_MTU
 
 #define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024*16)  /* 16MB */
 #define NETVSC_RECEIVE_BUFFER_SIZE_LEGACY  (1024*1024*15)  /* 15MB */
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index f0919bd..3dc9679 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -872,19 +872,12 @@ static int netvsc_change_mtu(struct net_device *ndev, int 
mtu)
struct netvsc_device *nvdev = ndevctx->nvdev;
struct hv_device *hdev = ndevctx->device_ctx;
struct netvsc_device_info device_info;
-   int limit = ETH_DATA_LEN;
u32 num_chn;
int ret = 0;
 
if (ndevctx->start_remove || !nvdev || nvdev->destroy)
return -ENODEV;
 
-   if (nvdev->nvsp_version >= NVSP_PROTOCOL_VERSION_2)
-   limit = NETVSC_MTU - ETH_HLEN;
-
-   if (mtu < NETVSC_MTU_MIN || mtu > limit)
-   return -EINVAL;
-
ret = netvsc_close(ndev);
if (ret)
goto out;
@@ -1343,6 +1336,13 @@ static int netvsc_probe(struct hv_device *dev,
 
netif_carrier_off(net);
 
+   /* MTU range: 68 - 1500 or 65521 */
+   net->min_mtu = NETVSC_MTU_MIN;
+   if (nvdev->nvsp_version >= NVSP_PROTOCOL_VERSION_2)
+   net->max_mtu = NETVSC_MTU - ETH_HLEN;
+   else
+   net->max_mtu = ETH_DATA_LEN;
+
netvsc_init_settings(net);
 
net_device_ctx = netdev_priv(net);
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index fad84f3..4885a42 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1419,17 +1419,6 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
.set_settings = virtnet_set_settings,
 };
 
-#define MIN_MTU 68
-#define MAX_MTU 65535
-
-static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
-{
-   if (new_mtu < MIN_MTU || new_mtu > MAX_MTU)
-   return -EINVAL;
-   dev->mtu = new_mtu;
-   return 0;
-}
-
 static const struct net_device_ops virtnet_netdev = {
.ndo_open= virtnet_open,
.ndo_stop= virtnet_close,
@@ -1437,7 +1426,6 @@ static const struct net_device_ops virtnet_netdev = {
.ndo_validate_addr   = eth_validate_addr,
.ndo_set_mac_address = virtnet_set_mac_address,
.ndo_set_rx_mode = virtnet_set_rx_mode,
-   .ndo_change_mtu  = virtnet_change_mtu,
.ndo_get_stats64 = virtnet_stats,
.ndo_vlan_rx_add_vid = virtnet_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = virtnet_vlan_rx_kill_vid,
@@ -1748,6 +1736,9 @@ static bool virtnet_validate_features(struct 
virtio_device *vdev)
return true;
 }
 
+#define MIN_MTU ETH_MIN_MTU
+#define MAX_MTU 65535
+
 static int virtnet_probe(struct virtio_device *vdev)
 {
int i, err;
@@ -1821,6 +1812,10 @@ static int virtnet_probe(struct virtio_device *vdev)
 
dev->vlan_features = dev->features;
 
+   /* MTU range: 68 - 65535 */
+   dev->min_mtu = MIN_MTU;
+   dev->max_mtu = MAX_MTU;
+
/* Configuration may specify what MAC to use.  Otherwise random. */
if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC))
virtio_cread_bytes(vdev,
@@ -1875,8 +1870,10 @@ static int virtnet_probe(struct virtio_device *vdev)
mtu = virtio_cread16(vdev,
 offsetof(struct virtio_net_config,
  mtu));
-   if (virtnet_change_mtu(dev, mtu))
+   if (mtu >= dev->min_mtu && mtu <= dev->max_mtu) {
+   dev->mtu = mtu;
__virtio_clear_bit(vdev, VIRTIO_NET_F_MTU);
+   }
}
 
if (vi->any_header_sg)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c 
b/drivers/net/vmxnet3/vmxnet3_drv.c
index b5554f2..0c36de1 100644
--- 

[PATCH net-next 6/6] net: use core MTU range checking in misc drivers

[Jarod Wilson]

firewire-net:
- set min/max_mtu
- remove fwnet_change_mtu

nes:
- set max_mtu
- clean up nes_netdev_change_mtu

xpnet:
- set min/max_mtu
- remove xpnet_dev_change_mtu

hippi:
- set min/max_mtu
- remove hippi_change_mtu

batman-adv:
- set max_mtu
- remove batadv_interface_change_mtu
- initialization is a little async, not 100% certain that max_mtu is set
  in the optimal place, don't have hardware to test with

rionet:
- set min/max_mtu
- remove rionet_change_mtu

slip:
- set min/max_mtu
- streamline sl_change_mtu

CC: net...@vger.kernel.org
CC: Stefan Richter 
CC: Faisal Latif 
CC: linux-r...@vger.kernel.org
CC: Cliff Whickman 
CC: Robin Holt 
CC: Jes Sorensen 
CC: Marek Lindner 
CC: Simon Wunderlich 
CC: Antonio Quartulli 
Signed-off-by: Jarod Wilson 
---
 drivers/firewire/net.c  | 12 ++--
 drivers/infiniband/hw/nes/nes.c |  1 -
 drivers/infiniband/hw/nes/nes.h |  4 ++--
 drivers/infiniband/hw/nes/nes_nic.c | 10 +++---
 drivers/misc/sgi-xp/xpnet.c | 21 -
 drivers/net/hippi/rrunner.c |  1 -
 drivers/net/rionet.c| 15 +++
 drivers/net/slip/slip.c | 11 +--
 include/linux/hippidevice.h |  1 -
 net/802/hippi.c | 14 ++
 net/batman-adv/soft-interface.c | 13 +
 11 files changed, 22 insertions(+), 81 deletions(-)

diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index 309311b..b5f125c 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -1349,15 +1349,6 @@ static netdev_tx_t fwnet_tx(struct sk_buff *skb, struct 
net_device *net)
return NETDEV_TX_OK;
 }
 
-static int fwnet_change_mtu(struct net_device *net, int new_mtu)
-{
-   if (new_mtu < 68)
-   return -EINVAL;
-
-   net->mtu = new_mtu;
-   return 0;
-}
-
 static const struct ethtool_ops fwnet_ethtool_ops = {
.get_link   = ethtool_op_get_link,
 };
@@ -1366,7 +1357,6 @@ static const struct net_device_ops fwnet_netdev_ops = {
.ndo_open   = fwnet_open,
.ndo_stop   = fwnet_stop,
.ndo_start_xmit = fwnet_tx,
-   .ndo_change_mtu = fwnet_change_mtu,
 };
 
 static void fwnet_init_dev(struct net_device *net)
@@ -1481,6 +1471,8 @@ static int fwnet_probe(struct fw_unit *unit,
max_mtu = (1 << (card->max_receive + 1))
  - sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE;
net->mtu = min(1500U, max_mtu);
+   net->min_mtu = ETH_MIN_MTU;
+   net->max_mtu = net->mtu;
 
/* Set our hardware address while we're at it */
ha = (union fwnet_hwaddr *)net->dev_addr;
diff --git a/drivers/infiniband/hw/nes/nes.c b/drivers/infiniband/hw/nes/nes.c
index 35cbb17..2baa45a 100644
--- a/drivers/infiniband/hw/nes/nes.c
+++ b/drivers/infiniband/hw/nes/nes.c
@@ -65,7 +65,6 @@ MODULE_DESCRIPTION("NetEffect RNIC Low-level iWARP Driver");
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_VERSION(DRV_VERSION);
 
-int max_mtu = 9000;
 int interrupt_mod_interval = 0;
 
 /* Interoperability */
diff --git a/drivers/infiniband/hw/nes/nes.h b/drivers/infiniband/hw/nes/nes.h
index e7430c9..85acd08 100644
--- a/drivers/infiniband/hw/nes/nes.h
+++ b/drivers/infiniband/hw/nes/nes.h
@@ -83,6 +83,8 @@
 #define NES_FIRST_QPN   64
 #define NES_SW_CONTEXT_ALIGN1024
 
+#define NES_MAX_MTU9000
+
 #define NES_NIC_MAX_NICS16
 #define NES_MAX_ARP_TABLE_SIZE  4096
 
@@ -169,8 +171,6 @@ do { \
 #include "nes_cm.h"
 #include "nes_mgt.h"
 
-extern int max_mtu;
-#define max_frame_len (max_mtu+ETH_HLEN)
 extern int interrupt_mod_interval;
 extern int nes_if_count;
 extern int mpa_version;
diff --git a/drivers/infiniband/hw/nes/nes_nic.c 
b/drivers/infiniband/hw/nes/nes_nic.c
index 2b27d13..7f8597d 100644
--- a/drivers/infiniband/hw/nes/nes_nic.c
+++ b/drivers/infiniband/hw/nes/nes_nic.c
@@ -981,20 +981,16 @@ static int nes_netdev_change_mtu(struct net_device 
*netdev, int new_mtu)
 {
struct nes_vnic *nesvnic = netdev_priv(netdev);
struct nes_device *nesdev = nesvnic->nesdev;
-   int ret = 0;
u8 jumbomode = 0;
u32 nic_active;
u32 nic_active_bit;
u32 uc_all_active;
u32 mc_all_active;
 
-   if ((new_mtu < ETH_ZLEN) || (new_mtu > max_mtu))
-   return -EINVAL;
-
netdev->mtu = new_mtu;
nesvnic->max_frame_size = new_mtu + VLAN_ETH_HLEN;
 
-   if (netdev->mtu > 1500) {
+   if (netdev->mtu > ETH_DATA_LEN) {
jumbomode=1;
}
nes_nic_init_timer_defaults(nesdev, jumbomode);
@@ -1020,7 +1016,7 @@ static int nes_netdev_change_mtu(struct net_device 
*netdev, int new_mtu)
nes_write_indexed(nesdev, NES_IDX_NIC_UNICAST_ALL, nic_active);
}
 
-   return ret;
+   return 0;
 }
 
 
@@ -1658,7 +1654,7 @@ struct net_device *nes_netdev_init(struct nes_device 
*nesdev,
 
netdev->watchdog_timeo = NES_TX_TIMEOUT;
netdev->irq 

[PATCH net-next 5/6] net: use core MTU range checking in virt drivers

[Jarod Wilson]

hyperv_net:
- set min/max_mtu

virtio_net:
- set min/max_mtu
- remove virtnet_change_mtu

vmxnet3:
- set min/max_mtu

CC: net...@vger.kernel.org
CC: virtualizat...@lists.linux-foundation.org
CC: "K. Y. Srinivasan" 
CC: Haiyang Zhang 
CC: "Michael S. Tsirkin" 
CC: Shrikrishna Khare 
CC: "VMware, Inc." 
Signed-off-by: Jarod Wilson 
---
 drivers/net/hyperv/hyperv_net.h   |  4 ++--
 drivers/net/hyperv/netvsc_drv.c   | 14 +++---
 drivers/net/virtio_net.c  | 23 ++-
 drivers/net/vmxnet3/vmxnet3_drv.c |  7 ---
 4 files changed, 23 insertions(+), 25 deletions(-)

diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index f4fbcb5..3958ada 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -606,8 +606,8 @@ struct nvsp_message {
 } __packed;
 
 
-#define NETVSC_MTU 65536
-#define NETVSC_MTU_MIN 68
+#define NETVSC_MTU 65535
+#define NETVSC_MTU_MIN ETH_MIN_MTU
 
 #define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024*16)  /* 16MB */
 #define NETVSC_RECEIVE_BUFFER_SIZE_LEGACY  (1024*1024*15)  /* 15MB */
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index f0919bd..3dc9679 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -872,19 +872,12 @@ static int netvsc_change_mtu(struct net_device *ndev, int 
mtu)
struct netvsc_device *nvdev = ndevctx->nvdev;
struct hv_device *hdev = ndevctx->device_ctx;
struct netvsc_device_info device_info;
-   int limit = ETH_DATA_LEN;
u32 num_chn;
int ret = 0;
 
if (ndevctx->start_remove || !nvdev || nvdev->destroy)
return -ENODEV;
 
-   if (nvdev->nvsp_version >= NVSP_PROTOCOL_VERSION_2)
-   limit = NETVSC_MTU - ETH_HLEN;
-
-   if (mtu < NETVSC_MTU_MIN || mtu > limit)
-   return -EINVAL;
-
ret = netvsc_close(ndev);
if (ret)
goto out;
@@ -1343,6 +1336,13 @@ static int netvsc_probe(struct hv_device *dev,
 
netif_carrier_off(net);
 
+   /* MTU range: 68 - 1500 or 65521 */
+   net->min_mtu = NETVSC_MTU_MIN;
+   if (nvdev->nvsp_version >= NVSP_PROTOCOL_VERSION_2)
+   net->max_mtu = NETVSC_MTU - ETH_HLEN;
+   else
+   net->max_mtu = ETH_DATA_LEN;
+
netvsc_init_settings(net);
 
net_device_ctx = netdev_priv(net);
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index fad84f3..4885a42 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1419,17 +1419,6 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
.set_settings = virtnet_set_settings,
 };
 
-#define MIN_MTU 68
-#define MAX_MTU 65535
-
-static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
-{
-   if (new_mtu < MIN_MTU || new_mtu > MAX_MTU)
-   return -EINVAL;
-   dev->mtu = new_mtu;
-   return 0;
-}
-
 static const struct net_device_ops virtnet_netdev = {
.ndo_open= virtnet_open,
.ndo_stop= virtnet_close,
@@ -1437,7 +1426,6 @@ static const struct net_device_ops virtnet_netdev = {
.ndo_validate_addr   = eth_validate_addr,
.ndo_set_mac_address = virtnet_set_mac_address,
.ndo_set_rx_mode = virtnet_set_rx_mode,
-   .ndo_change_mtu  = virtnet_change_mtu,
.ndo_get_stats64 = virtnet_stats,
.ndo_vlan_rx_add_vid = virtnet_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = virtnet_vlan_rx_kill_vid,
@@ -1748,6 +1736,9 @@ static bool virtnet_validate_features(struct 
virtio_device *vdev)
return true;
 }
 
+#define MIN_MTU ETH_MIN_MTU
+#define MAX_MTU 65535
+
 static int virtnet_probe(struct virtio_device *vdev)
 {
int i, err;
@@ -1821,6 +1812,10 @@ static int virtnet_probe(struct virtio_device *vdev)
 
dev->vlan_features = dev->features;
 
+   /* MTU range: 68 - 65535 */
+   dev->min_mtu = MIN_MTU;
+   dev->max_mtu = MAX_MTU;
+
/* Configuration may specify what MAC to use.  Otherwise random. */
if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC))
virtio_cread_bytes(vdev,
@@ -1875,8 +1870,10 @@ static int virtnet_probe(struct virtio_device *vdev)
mtu = virtio_cread16(vdev,
 offsetof(struct virtio_net_config,
  mtu));
-   if (virtnet_change_mtu(dev, mtu))
+   if (mtu >= dev->min_mtu && mtu <= dev->max_mtu) {
+   dev->mtu = mtu;
__virtio_clear_bit(vdev, VIRTIO_NET_F_MTU);
+   }
}
 
if (vi->any_header_sg)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c 
b/drivers/net/vmxnet3/vmxnet3_drv.c
index b5554f2..0c36de1 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2969,9 +2969,6 @@ vmxnet3_change_mtu(struct net_device *netdev, int