Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset

[Russell King - ARM Linux]

On Wed, Nov 14, 2018 at 02:35:29PM +1300, Michael Schmitz wrote:
> So we'd still have to use jiffies + interpolation from the current timer
> rundown counter as clocksource (since that will be monotonous and won't
> wrap)?
> 
> The way Finn did the clocksource for m68k, the clocksource counter does
> behave as it should (monotonous, doesn't wrap) at least so far as I've
> tested. Using the same timer for clocksource and clock events will degrade
> timekeeping based on timer events to jiffies resolution, as you point out.
> That would already have been the case before, so no gain in resolution.

... and that is where you are wrong.

RPC, for example, has gettimeofday() resolution of 500ns.  Removing
gettimeoffset() will result in a resolution of 1/HZ since there is
no longer any interpolation between interrupts.

> Other timekeeping would have worked at higher resolution before
> (interpolating through arch_gettimeoffset) just the same as now
> (interpolating through clocksource reads). Finn's clocksource read code
> essentially is arch_gettimeoffset under a new name.

Where is this code - all I've seen is code adding IRQ exclusion in
the gettimeoffset method.  If some other solution is being proposed,
then it's no good beating about the bush - show the damn code, and
then that can be considered.

However, what has been said in this thread is basically "remove the
gettimeoffset method", which is _not_ acceptable, it will cause
gettimeofday() on these platforms to lose resolution, which is a
user visible REGRESSION, plain and simple.

If what is actually meant is "we have a replacement for gettimeoffset"
then, and I'm sure we all know this, there needs to be a patch
proposed showing what is being proposed, rather than waffling around
the issue.

> Are you saying that's not possible on arm, because the current timer rundown
> counter can't be read while the timer is running?
> 
> If I were to run a second timer at higher rate for clocksource, but keeping
> the 10 ms timer as clock event (could easily do that by using timer D on
> Atari Falcon) - how would that improve my timekeeping? Clock events still
> only happen 10 ms apart ...

Ah, I think you're talking about something else.

You seem to be talking about what happens when time keeping interrupts
happen.

I'm talking about the resolution of gettimeofday() and the other
interfaces that are used (eg) for packet capture timestamping and
the like - the _user_ visible effects of the timekeeping system.

With the existing implementation, all these have better-than-jiffy
resolution - in the case of RPC, that's 500ns, rather than 10ms
which would be the case without gettimeoffset().  Removing
gettimeoffset() as Finn has proposed without preserving that
resolution is simply completely unacceptable.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset

[Russell King - ARM Linux]

On Wed, Nov 14, 2018 at 02:35:29PM +1300, Michael Schmitz wrote:
> So we'd still have to use jiffies + interpolation from the current timer
> rundown counter as clocksource (since that will be monotonous and won't
> wrap)?
> 
> The way Finn did the clocksource for m68k, the clocksource counter does
> behave as it should (monotonous, doesn't wrap) at least so far as I've
> tested. Using the same timer for clocksource and clock events will degrade
> timekeeping based on timer events to jiffies resolution, as you point out.
> That would already have been the case before, so no gain in resolution.

... and that is where you are wrong.

RPC, for example, has gettimeofday() resolution of 500ns.  Removing
gettimeoffset() will result in a resolution of 1/HZ since there is
no longer any interpolation between interrupts.

> Other timekeeping would have worked at higher resolution before
> (interpolating through arch_gettimeoffset) just the same as now
> (interpolating through clocksource reads). Finn's clocksource read code
> essentially is arch_gettimeoffset under a new name.

Where is this code - all I've seen is code adding IRQ exclusion in
the gettimeoffset method.  If some other solution is being proposed,
then it's no good beating about the bush - show the damn code, and
then that can be considered.

However, what has been said in this thread is basically "remove the
gettimeoffset method", which is _not_ acceptable, it will cause
gettimeofday() on these platforms to lose resolution, which is a
user visible REGRESSION, plain and simple.

If what is actually meant is "we have a replacement for gettimeoffset"
then, and I'm sure we all know this, there needs to be a patch
proposed showing what is being proposed, rather than waffling around
the issue.

> Are you saying that's not possible on arm, because the current timer rundown
> counter can't be read while the timer is running?
> 
> If I were to run a second timer at higher rate for clocksource, but keeping
> the 10 ms timer as clock event (could easily do that by using timer D on
> Atari Falcon) - how would that improve my timekeeping? Clock events still
> only happen 10 ms apart ...

Ah, I think you're talking about something else.

You seem to be talking about what happens when time keeping interrupts
happen.

I'm talking about the resolution of gettimeofday() and the other
interfaces that are used (eg) for packet capture timestamping and
the like - the _user_ visible effects of the timekeeping system.

With the existing implementation, all these have better-than-jiffy
resolution - in the case of RPC, that's 500ns, rather than 10ms
which would be the case without gettimeoffset().  Removing
gettimeoffset() as Finn has proposed without preserving that
resolution is simply completely unacceptable.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

Re: [PATCH 2/8] pstore: Do not use crash buffer for decompression

[Kees Cook]

On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes  wrote:
> On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
>>  static void decompress_record(struct pstore_record *record)
>>  {
>> + int ret;
>>   int unzipped_len;
>
> nit: We could get rid of the unzipped_len variable now I think.

I didn't follow this -- it gets used quite a bit. I don't see a clean
way to remove it?

>> + workspace = kmalloc(unzipped_len + record->ecc_notice_size,
>
> Should tihs be unzipped_len + record->ecc_notice_size + 1. The extra byte
> being for the NULL character of the ecc notice?
>
> This occurred to me when I saw the + 1 in ram.c. It could be better to just
> abstract the size as a macro.

Ooh, yes, good catch. I'll get this fixed.

Thanks for the review!

-- 
Kees Cook

Re: [PATCH 2/8] pstore: Do not use crash buffer for decompression

[Kees Cook]

On Fri, Nov 2, 2018 at 1:24 PM, Joel Fernandes  wrote:
> On Thu, Nov 01, 2018 at 04:51:54PM -0700, Kees Cook wrote:
>>  static void decompress_record(struct pstore_record *record)
>>  {
>> + int ret;
>>   int unzipped_len;
>
> nit: We could get rid of the unzipped_len variable now I think.

I didn't follow this -- it gets used quite a bit. I don't see a clean
way to remove it?

>> + workspace = kmalloc(unzipped_len + record->ecc_notice_size,
>
> Should tihs be unzipped_len + record->ecc_notice_size + 1. The extra byte
> being for the NULL character of the ecc notice?
>
> This occurred to me when I saw the + 1 in ram.c. It could be better to just
> abstract the size as a macro.

Ooh, yes, good catch. I'll get this fixed.

Thanks for the review!

-- 
Kees Cook

Re: [PATCH 1/1] Bluetooth: make the balance of judgement condition to fix a false report

[Marcel Holtmann]

Hi Zumeng,

> This patch is to balance the condition scope between hci_get_cmd_complete and
> hci_event_packet about orig_skb as follows: 
> 
>if (req_complete_skb || event == HCI_EV_CMD_STATUS ||
>event == HCI_EV_CMD_COMPLETE)
>orig_skb = skb_clone(skb, GFP_KERNEL);
> 
> And hci_get_cmd_complete will bt_dev_err out when HCI_EV_CMD_STATUS, so a lot
> of asymmetric conditions are triggered. Since both of them are the entry into
> hci_get_cmd_complete, we'd better get STATUS into judge the false out there.
> 
> Signed-off-by: Zumeng Chen 
> ---
> 
> Hi expert,
> 
> This issue existed whether or not T_DBG had been changed into bt_dev_err, 
> which
> just shows the issue explicitly. I noticed actually that opcode doesn't match
> ev->opcode either at the same time. And there might be some logic issue about
> HCI_EV_CMD_COMPLETE between protocol and drivers. I'm not familar with the 
> whole
> bluetooth protocol, and not gonna to dig more, so all yours guys~
> 
> Cheers,
> Zumeng
> 
> net/bluetooth/hci_event.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 235b5aa..d848663 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -5217,7 +5217,8 @@ static bool hci_get_cmd_complete(struct hci_dev *hdev, 
> u16 opcode,
>   return true;
>   }
> 
> - if (hdr->evt != HCI_EV_CMD_COMPLETE) {
> + if (!((hdr->evt == HCI_EV_CMD_COMPLETE) ||
> + (hdr->evt == HCI_EV_CMD_STATUS))) {

this indentation is messed up. Also some braces are not needed.

if (!(hdr->evt == HCI_EV_CMD_COMPLETE ||
  hdr->evt == HCI_EV_CMD_STATUS)) {

>   bt_dev_err(hdev, "last event is not cmd complete (0x%2.2x)",
>  hdr->evt);
>   return false;

Regards

Marcel

Re: [PATCH 1/1] Bluetooth: make the balance of judgement condition to fix a false report

[Marcel Holtmann]

Hi Zumeng,

> This patch is to balance the condition scope between hci_get_cmd_complete and
> hci_event_packet about orig_skb as follows: 
> 
>if (req_complete_skb || event == HCI_EV_CMD_STATUS ||
>event == HCI_EV_CMD_COMPLETE)
>orig_skb = skb_clone(skb, GFP_KERNEL);
> 
> And hci_get_cmd_complete will bt_dev_err out when HCI_EV_CMD_STATUS, so a lot
> of asymmetric conditions are triggered. Since both of them are the entry into
> hci_get_cmd_complete, we'd better get STATUS into judge the false out there.
> 
> Signed-off-by: Zumeng Chen 
> ---
> 
> Hi expert,
> 
> This issue existed whether or not T_DBG had been changed into bt_dev_err, 
> which
> just shows the issue explicitly. I noticed actually that opcode doesn't match
> ev->opcode either at the same time. And there might be some logic issue about
> HCI_EV_CMD_COMPLETE between protocol and drivers. I'm not familar with the 
> whole
> bluetooth protocol, and not gonna to dig more, so all yours guys~
> 
> Cheers,
> Zumeng
> 
> net/bluetooth/hci_event.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 235b5aa..d848663 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -5217,7 +5217,8 @@ static bool hci_get_cmd_complete(struct hci_dev *hdev, 
> u16 opcode,
>   return true;
>   }
> 
> - if (hdr->evt != HCI_EV_CMD_COMPLETE) {
> + if (!((hdr->evt == HCI_EV_CMD_COMPLETE) ||
> + (hdr->evt == HCI_EV_CMD_STATUS))) {

this indentation is messed up. Also some braces are not needed.

if (!(hdr->evt == HCI_EV_CMD_COMPLETE ||
  hdr->evt == HCI_EV_CMD_STATUS)) {

>   bt_dev_err(hdev, "last event is not cmd complete (0x%2.2x)",
>  hdr->evt);
>   return false;

Regards

Marcel

Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree

[Marcel Holtmann]

Hi Andreas,

> Am 12.11.2018 um 21:59 schrieb Andreas Kemnade :
> On Sun, 11 Nov 2018 03:46:48 +0100
> Sebastian Reichel  wrote:  
>> On Sun, Nov 11, 2018 at 12:20:34AM +0100, Andreas Kemnade wrote:  
>>> This is a first try to be able to use h4 devices specified in
>>> the devicetree, so you do not need to call hciattach and
>>> it can be automatically probed.
>>> 
>>> Of course, proper devicetree bindings documentation is
>>> missing. And also you would extend that by regulator/
>>> enable gpio settings.
>>> 
>>> But before proceeding further it should be checked if the
>>> general way of doing things is right.
>>> 
>>> Signed-off-by: Andreas Kemnade 
>>> ---  
>> 
>> Patch looks good to me, just one note
>> 
> I found one thing myself:
> Shouldn't we have a generic compatible string like "generic-h4".
> ehci-platform.c has for example:
>   { .compatible = "generic-ehci", },  
 
 There might be differences in h4 compatible devices (e.g. default
 baud rate) so that I would not bet there a "generic-h4" suffices
 in the long run.  
>> 
>> It will not because that doesn't define clocks, resets, gpios,
>> supplies, etc. and the interactions of all those.
>> 
> well, we need a simple supply being on when the device is on.
> Nothing more.
> 
>>> My suggestion is to use this in DT:
>>> 
>>> compatible = "wi2wi,w2cbw003-bluetooth", "";
>>> 
> That would be my slight preference here.
> 
>>> The driver can start with supporting just the generic compatible
>>> string. If somebody finds some incompatible differences, the driver
>>> can add a custom handler for the wi2wi chip without breaking DT
>>> ABI.  
>> 
>> Any idea how many H4 devices there are? Somehow I doubt there are that
>> many to be unmanageable.
>> 
> Well, many devices are h4 devices with some more or less important
> vendor-specific commands. Well, "hciattach any" uses simple h4 protocol.
> 
> those firmware download commands and they have their own drivers.
> Most devices I had used bluetooth uart from the command line with, were
> simple enough. The other question is whether those devices will run a
> modern kernel.
> 
> No strong opinion here. 

doing the firmware load from user space via some magic tool is no longer going 
to work smoothly. It will be actually almost impossible with serdev. However I 
did post btuart.c driver which is pretty much just plain H:4. You would still 
somehow define the default baudraute since just picking 115200 is not always 
going to work.

Btw. I see nothing standing in the way of merging btuart.c driver and then go 
from there. Either I dig this out and submit or someone else does.

Regards

Marcel

Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree

[Marcel Holtmann]

Hi Andreas,

> Am 12.11.2018 um 21:59 schrieb Andreas Kemnade :
> On Sun, 11 Nov 2018 03:46:48 +0100
> Sebastian Reichel  wrote:  
>> On Sun, Nov 11, 2018 at 12:20:34AM +0100, Andreas Kemnade wrote:  
>>> This is a first try to be able to use h4 devices specified in
>>> the devicetree, so you do not need to call hciattach and
>>> it can be automatically probed.
>>> 
>>> Of course, proper devicetree bindings documentation is
>>> missing. And also you would extend that by regulator/
>>> enable gpio settings.
>>> 
>>> But before proceeding further it should be checked if the
>>> general way of doing things is right.
>>> 
>>> Signed-off-by: Andreas Kemnade 
>>> ---  
>> 
>> Patch looks good to me, just one note
>> 
> I found one thing myself:
> Shouldn't we have a generic compatible string like "generic-h4".
> ehci-platform.c has for example:
>   { .compatible = "generic-ehci", },  
 
 There might be differences in h4 compatible devices (e.g. default
 baud rate) so that I would not bet there a "generic-h4" suffices
 in the long run.  
>> 
>> It will not because that doesn't define clocks, resets, gpios,
>> supplies, etc. and the interactions of all those.
>> 
> well, we need a simple supply being on when the device is on.
> Nothing more.
> 
>>> My suggestion is to use this in DT:
>>> 
>>> compatible = "wi2wi,w2cbw003-bluetooth", "";
>>> 
> That would be my slight preference here.
> 
>>> The driver can start with supporting just the generic compatible
>>> string. If somebody finds some incompatible differences, the driver
>>> can add a custom handler for the wi2wi chip without breaking DT
>>> ABI.  
>> 
>> Any idea how many H4 devices there are? Somehow I doubt there are that
>> many to be unmanageable.
>> 
> Well, many devices are h4 devices with some more or less important
> vendor-specific commands. Well, "hciattach any" uses simple h4 protocol.
> 
> those firmware download commands and they have their own drivers.
> Most devices I had used bluetooth uart from the command line with, were
> simple enough. The other question is whether those devices will run a
> modern kernel.
> 
> No strong opinion here. 

doing the firmware load from user space via some magic tool is no longer going 
to work smoothly. It will be actually almost impossible with serdev. However I 
did post btuart.c driver which is pretty much just plain H:4. You would still 
somehow define the default baudraute since just picking 115200 is not always 
going to work.

Btw. I see nothing standing in the way of merging btuart.c driver and then go 
from there. Either I dig this out and submit or someone else does.

Regards

Marcel

Re: [PATCH v1 3/4] Bluetooth: hci_qca: clear HCI_QUIRK_RESET_ON_CLOSE flag

[Marcel Holtmann]

Hi Balakrishna,

>> During hci down we are sending reset command to chip, which
>> is not required for wcn3990, as hdev->shutdown() will turn off the
>> regulators.
>> Signed-off-by: Balakrishna Godavarthi 
>> ---
>> drivers/bluetooth/hci_qca.c | 1 +
>> 1 file changed, 1 insertion(+)
>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>> index 8301663f0004..97b57e0f4725 100644
>> --- a/drivers/bluetooth/hci_qca.c
>> +++ b/drivers/bluetooth/hci_qca.c
>> @@ -1190,6 +1190,7 @@ static int qca_setup(struct hci_uart *hu)
>>   */
>>  set_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, >quirks);
>>  set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, >quirks);
>> +clear_bit(HCI_QUIRK_RESET_ON_CLOSE, >quirks);
>>  hu->hdev->shutdown = qca_power_off;
>>  ret = qca_wcn3990_init(hu);
>>  if (ret)
> I am pretty certain that you didn’t want this quirk:
>   /* When this quirk is set, the HCI Reset command is send when
>* closing the transport instead of when opening it.
> This quirk is for Bluetooth 1.0b devices where the HCI_Reset behavior
> was not clear or for devices that actually misbehave with the initial
> HCI_Reset.
> In addition, you commit message is totally misleading. That is not
> what is happening with this quirk.
> Regards
> Marcel
 My intention was reset command is not required when we do an hci down.
 this is because of hdev->shutdown will turn off the regulators.
 It is like turning off the chip. sending reset command after turning off 
 the chip is not required.
 I understand the usage of the quirk, will update the commit text.
>>> you are papering over the issue. Actually
>>> hci_serdev.c:hci_uart_register_device() is the culprit with the legacy
>>> code copied over from hci_ldisc.c:hci_uart_register_dev(). I think
>>> there is no point doing all this legacy line discipline quirk handling
>>> until it is really needed. The serdev drivers are all for recent
>>> hardware.
>>> That said, having moved over to a btuart.c approach and killed the
>>> whole hci_serdev.c thing would have been a lot better here. You will
>>> keep running in weird situations where 18 year old code keeps
>>> surprising you.
>> [Bala]: even i feel the same. they are lot such kind of HACK's we need
>> to do with current arch.
>>when can we expect btuart.c merged to bt-next. i think having
>> btuart will helps us to have the control of
>>vendor porto's call's like in btusb.c
>>> Regards
>>> Marcel
> 
> I need some clarification, do you expect some thing like this 
> https://github.com/torvalds/linux/blob/master/drivers/bluetooth/btmtkuart.c 
> for Qualcomm BT chip too.
> it looks it is completely avoided hci_serdev.c interface.

you tell me actually. Are you using the H:4 transport or do you have an extra 
protocol layer / framing below it. If you do, then use your own driver, but if 
the transport is H:4 with vendor packets and vendor setup, then btuart.c (which 
is not yet upstream) should be your target.

For the MTK hardware it was obvious that it was better served as a separate 
driver. For QCA serial it really depends on how much extra protocol you have to 
run. So this might be an exercise in trying QCA serial as a separate driver and 
then go from there.

It is clear that the baggage from hci_ldisc.c etc is in the way for serdev 
based systems.

Regards

Marcel

Re: [PATCH v1 3/4] Bluetooth: hci_qca: clear HCI_QUIRK_RESET_ON_CLOSE flag

[Marcel Holtmann]

Hi Balakrishna,

>> During hci down we are sending reset command to chip, which
>> is not required for wcn3990, as hdev->shutdown() will turn off the
>> regulators.
>> Signed-off-by: Balakrishna Godavarthi 
>> ---
>> drivers/bluetooth/hci_qca.c | 1 +
>> 1 file changed, 1 insertion(+)
>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>> index 8301663f0004..97b57e0f4725 100644
>> --- a/drivers/bluetooth/hci_qca.c
>> +++ b/drivers/bluetooth/hci_qca.c
>> @@ -1190,6 +1190,7 @@ static int qca_setup(struct hci_uart *hu)
>>   */
>>  set_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, >quirks);
>>  set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, >quirks);
>> +clear_bit(HCI_QUIRK_RESET_ON_CLOSE, >quirks);
>>  hu->hdev->shutdown = qca_power_off;
>>  ret = qca_wcn3990_init(hu);
>>  if (ret)
> I am pretty certain that you didn’t want this quirk:
>   /* When this quirk is set, the HCI Reset command is send when
>* closing the transport instead of when opening it.
> This quirk is for Bluetooth 1.0b devices where the HCI_Reset behavior
> was not clear or for devices that actually misbehave with the initial
> HCI_Reset.
> In addition, you commit message is totally misleading. That is not
> what is happening with this quirk.
> Regards
> Marcel
 My intention was reset command is not required when we do an hci down.
 this is because of hdev->shutdown will turn off the regulators.
 It is like turning off the chip. sending reset command after turning off 
 the chip is not required.
 I understand the usage of the quirk, will update the commit text.
>>> you are papering over the issue. Actually
>>> hci_serdev.c:hci_uart_register_device() is the culprit with the legacy
>>> code copied over from hci_ldisc.c:hci_uart_register_dev(). I think
>>> there is no point doing all this legacy line discipline quirk handling
>>> until it is really needed. The serdev drivers are all for recent
>>> hardware.
>>> That said, having moved over to a btuart.c approach and killed the
>>> whole hci_serdev.c thing would have been a lot better here. You will
>>> keep running in weird situations where 18 year old code keeps
>>> surprising you.
>> [Bala]: even i feel the same. they are lot such kind of HACK's we need
>> to do with current arch.
>>when can we expect btuart.c merged to bt-next. i think having
>> btuart will helps us to have the control of
>>vendor porto's call's like in btusb.c
>>> Regards
>>> Marcel
> 
> I need some clarification, do you expect some thing like this 
> https://github.com/torvalds/linux/blob/master/drivers/bluetooth/btmtkuart.c 
> for Qualcomm BT chip too.
> it looks it is completely avoided hci_serdev.c interface.

you tell me actually. Are you using the H:4 transport or do you have an extra 
protocol layer / framing below it. If you do, then use your own driver, but if 
the transport is H:4 with vendor packets and vendor setup, then btuart.c (which 
is not yet upstream) should be your target.

For the MTK hardware it was obvious that it was better served as a separate 
driver. For QCA serial it really depends on how much extra protocol you have to 
run. So this might be an exercise in trying QCA serial as a separate driver and 
then go from there.

It is clear that the baggage from hci_ldisc.c etc is in the way for serdev 
based systems.

Regards

Marcel

[PATCH v3 0/2] Add device driver for APU2/APU3 GPIOs

[Florian Eckert]

Changes v2:
- Update SPDX short identifier
- Remove gpio-keys-polled device moved to arch/x86/platform
- Fix styling
- Use spinnlock only there where it is useful
- Removed useless output on driver load
- Do bit manipulation later not on IO
- Add additional GPIOs handling mpci2_reset and mpcie3_reset.
- Add name to GPIOs exported via sysfs

Changes v3:
- Add a new platform device for the frontpanel push button.
- Get global variables from the heap
- Fix errors/warnings generated by ./scripts/checkpatch.pl

Until now it was not possible to get more information to detect the
MMIO_BASE address from the ACPI subsystem.


Florian Eckert (2):
  gpio: Add driver for PC Engines APU2/APU3 GPIOs
  kernel: Add reset button platform device for APU2/APU3

 arch/x86/Kconfig   |  14 ++
 arch/x86/platform/Makefile |   1 +
 arch/x86/platform/amd/Makefile |   1 +
 arch/x86/platform/amd/apu.c|  72 ++
 drivers/gpio/Kconfig   |   8 ++
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-apu.c| 316 +
 7 files changed, 413 insertions(+)
 create mode 100644 arch/x86/platform/amd/Makefile
 create mode 100644 arch/x86/platform/amd/apu.c
 create mode 100644 drivers/gpio/gpio-apu.c

-- 
2.11.0

[PATCH v3 0/2] Add device driver for APU2/APU3 GPIOs

[Florian Eckert]

Changes v2:
- Update SPDX short identifier
- Remove gpio-keys-polled device moved to arch/x86/platform
- Fix styling
- Use spinnlock only there where it is useful
- Removed useless output on driver load
- Do bit manipulation later not on IO
- Add additional GPIOs handling mpci2_reset and mpcie3_reset.
- Add name to GPIOs exported via sysfs

Changes v3:
- Add a new platform device for the frontpanel push button.
- Get global variables from the heap
- Fix errors/warnings generated by ./scripts/checkpatch.pl

Until now it was not possible to get more information to detect the
MMIO_BASE address from the ACPI subsystem.


Florian Eckert (2):
  gpio: Add driver for PC Engines APU2/APU3 GPIOs
  kernel: Add reset button platform device for APU2/APU3

 arch/x86/Kconfig   |  14 ++
 arch/x86/platform/Makefile |   1 +
 arch/x86/platform/amd/Makefile |   1 +
 arch/x86/platform/amd/apu.c|  72 ++
 drivers/gpio/Kconfig   |   8 ++
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-apu.c| 316 +
 7 files changed, 413 insertions(+)
 create mode 100644 arch/x86/platform/amd/Makefile
 create mode 100644 arch/x86/platform/amd/apu.c
 create mode 100644 drivers/gpio/gpio-apu.c

-- 
2.11.0

[PATCH v3 1/2] gpio: Add driver for PC Engines APU2/APU3 GPIOs

[Florian Eckert]

Add a new device driver "gpio-apu" which will handle the GPIOs onAPU2
and APU3 devices from PC Engines.

APU2 (https://pcengines.ch/schema/apu2c.pdf page 7):
- G32 is "button_reset" connected to the smd-button on the frontpanel
- G50 is "mpcie2_reset" connected to mPCIe2 reset line
- G51 is "mpcie3_reset" connected to mPCIe3 reset line

APU3 (https://pcengines.ch/schema/apu3c.pdf page 7):
- G32 is "button_reset" connected to the smd-button on the frontpanel
- G50 is "mpcie2_reset" connected to mPCIe2 reset line
- G51 is "mpcie3_reset" connected to mPCIe3 reset line
- G33 is "simswap" connected to SIM switch IC to swap the SIM between
  mPCIe2 and mPCIe3 slot

Signed-off-by: Florian Eckert 
---
 drivers/gpio/Kconfig|   8 ++
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-apu.c | 312 
 3 files changed, 321 insertions(+)
 create mode 100644 drivers/gpio/gpio-apu.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 833a1b51c948..f9e603d5670c 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -117,6 +117,14 @@ config GPIO_AMDPT
  driver for GPIO functionality on Promontory IOHub
  Require ACPI ASL code to enumerate as a platform device.
 
+config GPIO_APU
+   tristate "PC Engines APU2/APU3 GPIO support"
+   depends on X86
+   select GPIO_GENERIC
+   help
+ Say Y here to support GPIO functionality on APU2/APU3 boards
+ from PC Engines.
+
 config GPIO_ASPEED
tristate "Aspeed GPIO support"
depends on (ARCH_ASPEED || COMPILE_TEST) && OF_GPIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 671c4477c951..9c27523fb189 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_GPIO_ALTERA) += gpio-altera.o
 obj-$(CONFIG_GPIO_ALTERA_A10SR)+= gpio-altera-a10sr.o
 obj-$(CONFIG_GPIO_AMD8111) += gpio-amd8111.o
 obj-$(CONFIG_GPIO_AMDPT)   += gpio-amdpt.o
+obj-$(CONFIG_GPIO_APU) += gpio-apu.o
 obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
 obj-$(CONFIG_GPIO_ATH79)   += gpio-ath79.o
 obj-$(CONFIG_GPIO_ASPEED)  += gpio-aspeed.o
diff --git a/drivers/gpio/gpio-apu.c b/drivers/gpio/gpio-apu.c
new file mode 100644
index ..df166c0d8258
--- /dev/null
+++ b/drivers/gpio/gpio-apu.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: GPL-2.0
+/* PC Engines APU2/APU3 GPIO device driver
+ *
+ * Copyright (C) 2018 Florian Eckert 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEVNAME"gpio-apu"
+
+#define APU_FCH_ACPI_MMIO_BASE 0xFED8
+#define APU_FCH_GPIO_BASE  (APU_FCH_ACPI_MMIO_BASE + 0x1500)
+#define APU_GPIO_BIT_RD16
+#define APU_GPIO_BIT_WR22
+#define APU_GPIO_BIT_DIR   23
+
+struct apu_gpio_pdata {
+   struct platform_device *pdev;
+   struct gpio_chip *chip;
+   unsigned long *offset;  /* base register offset */
+   void __iomem **addr;/* remapped iomem addresses */
+   spinlock_t lock;/* lock register access */
+};
+
+static struct apu_gpio_pdata *apu_gpio;
+
+/* APU2 */
+static unsigned long apu2_gpio_offset[] = {
+   APU_FCH_GPIO_BASE + 89 * sizeof(u32),
+   APU_FCH_GPIO_BASE + 67 * sizeof(u32),
+   APU_FCH_GPIO_BASE + 66 * sizeof(u32),
+};
+static const char * const apu2_gpio_names[] = {
+   "button_reset",
+   "mpcie2_reset",
+   "mpcie3_reset",
+};
+
+/* APU3 */
+static unsigned long apu3_gpio_offset[] = {
+   APU_FCH_GPIO_BASE + 89 * sizeof(u32),
+   APU_FCH_GPIO_BASE + 67 * sizeof(u32),
+   APU_FCH_GPIO_BASE + 66 * sizeof(u32),
+   APU_FCH_GPIO_BASE + 90 * sizeof(u32),
+};
+static const char * const apu3_gpio_names[] = {
+   "button_reset",
+   "mpcie2_reset",
+   "mpcie3_reset",
+   "simswap",
+};
+
+static int gpio_apu_get_dir(struct gpio_chip *chip, unsigned int offset)
+{
+   u32 val;
+
+   spin_lock(_gpio->lock);
+
+   val = ~ioread32(apu_gpio->addr[offset]);
+   val = (val >> APU_GPIO_BIT_DIR) & 1;
+
+   spin_unlock(_gpio->lock);
+
+   return val;
+}
+
+static int gpio_apu_dir_in(struct gpio_chip *chip, unsigned int offset)
+{
+   u32 val;
+
+   spin_lock(_gpio->lock);
+
+   val = ioread32(apu_gpio->addr[offset]);
+   val &= ~BIT(APU_GPIO_BIT_DIR);
+   iowrite32(val, apu_gpio->addr[offset]);
+
+   spin_unlock(_gpio->lock);
+
+   return 0;
+}
+
+static int gpio_apu_dir_out(struct gpio_chip *chip, unsigned int offset,
+   int value)
+{
+   u32 val;
+
+   spin_lock(_gpio->lock);
+
+   val = ioread32(apu_gpio->addr[offset]);
+   val |= BIT(APU_GPIO_BIT_DIR);
+   iowrite32(val, apu_gpio->addr[offset]);
+
+   spin_unlock(_gpio->lock);
+
+   return 0;
+}
+
+static int gpio_apu_get_data(struct gpio_chip *chip, unsigned int offset)
+{
+   u32 val;
+
+   spin_lock(_gpio->lock);
+
+   

[PATCH v3 1/2] gpio: Add driver for PC Engines APU2/APU3 GPIOs

[Florian Eckert]

Add a new device driver "gpio-apu" which will handle the GPIOs onAPU2
and APU3 devices from PC Engines.

APU2 (https://pcengines.ch/schema/apu2c.pdf page 7):
- G32 is "button_reset" connected to the smd-button on the frontpanel
- G50 is "mpcie2_reset" connected to mPCIe2 reset line
- G51 is "mpcie3_reset" connected to mPCIe3 reset line

APU3 (https://pcengines.ch/schema/apu3c.pdf page 7):
- G32 is "button_reset" connected to the smd-button on the frontpanel
- G50 is "mpcie2_reset" connected to mPCIe2 reset line
- G51 is "mpcie3_reset" connected to mPCIe3 reset line
- G33 is "simswap" connected to SIM switch IC to swap the SIM between
  mPCIe2 and mPCIe3 slot

Signed-off-by: Florian Eckert 
---
 drivers/gpio/Kconfig|   8 ++
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-apu.c | 312 
 3 files changed, 321 insertions(+)
 create mode 100644 drivers/gpio/gpio-apu.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 833a1b51c948..f9e603d5670c 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -117,6 +117,14 @@ config GPIO_AMDPT
  driver for GPIO functionality on Promontory IOHub
  Require ACPI ASL code to enumerate as a platform device.
 
+config GPIO_APU
+   tristate "PC Engines APU2/APU3 GPIO support"
+   depends on X86
+   select GPIO_GENERIC
+   help
+ Say Y here to support GPIO functionality on APU2/APU3 boards
+ from PC Engines.
+
 config GPIO_ASPEED
tristate "Aspeed GPIO support"
depends on (ARCH_ASPEED || COMPILE_TEST) && OF_GPIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 671c4477c951..9c27523fb189 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_GPIO_ALTERA) += gpio-altera.o
 obj-$(CONFIG_GPIO_ALTERA_A10SR)+= gpio-altera-a10sr.o
 obj-$(CONFIG_GPIO_AMD8111) += gpio-amd8111.o
 obj-$(CONFIG_GPIO_AMDPT)   += gpio-amdpt.o
+obj-$(CONFIG_GPIO_APU) += gpio-apu.o
 obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
 obj-$(CONFIG_GPIO_ATH79)   += gpio-ath79.o
 obj-$(CONFIG_GPIO_ASPEED)  += gpio-aspeed.o
diff --git a/drivers/gpio/gpio-apu.c b/drivers/gpio/gpio-apu.c
new file mode 100644
index ..df166c0d8258
--- /dev/null
+++ b/drivers/gpio/gpio-apu.c
@@ -0,0 +1,312 @@
+// SPDX-License-Identifier: GPL-2.0
+/* PC Engines APU2/APU3 GPIO device driver
+ *
+ * Copyright (C) 2018 Florian Eckert 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEVNAME"gpio-apu"
+
+#define APU_FCH_ACPI_MMIO_BASE 0xFED8
+#define APU_FCH_GPIO_BASE  (APU_FCH_ACPI_MMIO_BASE + 0x1500)
+#define APU_GPIO_BIT_RD16
+#define APU_GPIO_BIT_WR22
+#define APU_GPIO_BIT_DIR   23
+
+struct apu_gpio_pdata {
+   struct platform_device *pdev;
+   struct gpio_chip *chip;
+   unsigned long *offset;  /* base register offset */
+   void __iomem **addr;/* remapped iomem addresses */
+   spinlock_t lock;/* lock register access */
+};
+
+static struct apu_gpio_pdata *apu_gpio;
+
+/* APU2 */
+static unsigned long apu2_gpio_offset[] = {
+   APU_FCH_GPIO_BASE + 89 * sizeof(u32),
+   APU_FCH_GPIO_BASE + 67 * sizeof(u32),
+   APU_FCH_GPIO_BASE + 66 * sizeof(u32),
+};
+static const char * const apu2_gpio_names[] = {
+   "button_reset",
+   "mpcie2_reset",
+   "mpcie3_reset",
+};
+
+/* APU3 */
+static unsigned long apu3_gpio_offset[] = {
+   APU_FCH_GPIO_BASE + 89 * sizeof(u32),
+   APU_FCH_GPIO_BASE + 67 * sizeof(u32),
+   APU_FCH_GPIO_BASE + 66 * sizeof(u32),
+   APU_FCH_GPIO_BASE + 90 * sizeof(u32),
+};
+static const char * const apu3_gpio_names[] = {
+   "button_reset",
+   "mpcie2_reset",
+   "mpcie3_reset",
+   "simswap",
+};
+
+static int gpio_apu_get_dir(struct gpio_chip *chip, unsigned int offset)
+{
+   u32 val;
+
+   spin_lock(_gpio->lock);
+
+   val = ~ioread32(apu_gpio->addr[offset]);
+   val = (val >> APU_GPIO_BIT_DIR) & 1;
+
+   spin_unlock(_gpio->lock);
+
+   return val;
+}
+
+static int gpio_apu_dir_in(struct gpio_chip *chip, unsigned int offset)
+{
+   u32 val;
+
+   spin_lock(_gpio->lock);
+
+   val = ioread32(apu_gpio->addr[offset]);
+   val &= ~BIT(APU_GPIO_BIT_DIR);
+   iowrite32(val, apu_gpio->addr[offset]);
+
+   spin_unlock(_gpio->lock);
+
+   return 0;
+}
+
+static int gpio_apu_dir_out(struct gpio_chip *chip, unsigned int offset,
+   int value)
+{
+   u32 val;
+
+   spin_lock(_gpio->lock);
+
+   val = ioread32(apu_gpio->addr[offset]);
+   val |= BIT(APU_GPIO_BIT_DIR);
+   iowrite32(val, apu_gpio->addr[offset]);
+
+   spin_unlock(_gpio->lock);
+
+   return 0;
+}
+
+static int gpio_apu_get_data(struct gpio_chip *chip, unsigned int offset)
+{
+   u32 val;
+
+   spin_lock(_gpio->lock);
+
+   

[PATCH v3 2/2] kernel: Add reset button platform device for APU2/APU3

[Florian Eckert]

This will add a x86 platform device "gpio-keys-polled" which uses the
new gpio-apu drive for APU2 and APU3 boards from PC Engines.

Signed-off-by: Florian Eckert 
---
 arch/x86/Kconfig   | 14 
 arch/x86/platform/Makefile |  1 +
 arch/x86/platform/amd/Makefile |  1 +
 arch/x86/platform/amd/apu.c| 72 ++
 4 files changed, 88 insertions(+)
 create mode 100644 arch/x86/platform/amd/Makefile
 create mode 100644 arch/x86/platform/amd/apu.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9d734f3c8234..97c53286fdb6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2820,6 +2820,20 @@ config TS5500
 
 endif # X86_32
 
+if X86_64
+config APU
+   bool "PCEngines APU System Support"
+   help
+ This option enables system support for the PCEngines APU platform.
+ At present this just sets up the reset button control on
+ APU2/APU3 boards. However, other system specific setup should
+ get added here.
+
+ Note: You must still enable the drivers for GPIO and LED support
+ (GPIO_APU & LEDS_APU) to actually use the LEDs and the GPIOs
+
+endif # X86_64
+
 config AMD_NB
def_bool y
depends on CPU_SUP_AMD && PCI
diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
index d0e835470d01..a95d18810c29 100644
--- a/arch/x86/platform/Makefile
+++ b/arch/x86/platform/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 # Platform specific code goes here
 obj-y  += atom/
+obj-y  += amd/
 obj-y  += ce4100/
 obj-y  += efi/
 obj-y  += geode/
diff --git a/arch/x86/platform/amd/Makefile b/arch/x86/platform/amd/Makefile
new file mode 100644
index ..bf04c5799d7f
--- /dev/null
+++ b/arch/x86/platform/amd/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_APU)  +=apu.o
diff --git a/arch/x86/platform/amd/apu.c b/arch/x86/platform/amd/apu.c
new file mode 100644
index ..a4b695881177
--- /dev/null
+++ b/arch/x86/platform/amd/apu.c
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * System Specific setup for PC-Engines APU2/APU3 devices
+ *
+ * Copyright (C) 2018 Florian Eckert 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct gpio_keys_button apu_gpio_buttons[] = {
+   {
+   .code   = KEY_RESTART,
+   .gpio   = 20,
+   .active_low = 1,
+   .desc   = "Reset button",
+   .type   = EV_KEY,
+   .debounce_interval  = 60,
+   }
+};
+
+static struct gpio_keys_platform_data apu_buttons_data = {
+   .buttons= apu_gpio_buttons,
+   .nbuttons   = ARRAY_SIZE(apu_gpio_buttons),
+   .poll_interval  = 20,
+};
+
+static struct platform_device apu_buttons_dev = {
+   .name   = "gpio-keys-polled",
+   .id = 1,
+   .dev = {
+   .platform_data  = _buttons_data,
+   }
+};
+
+static struct platform_device *apu_devs[] __initdata = {
+   _buttons_dev,
+};
+
+static void __init register_apu(void)
+{
+   /* Setup push button control through gpio-apu driver */
+   platform_add_devices(apu_devs, ARRAY_SIZE(apu_devs));
+}
+
+static int __init apu_init(void)
+{
+   if (!dmi_match(DMI_SYS_VENDOR, "PC Engines")) {
+   pr_err("No PC Engines board detected\n");
+   return -ENODEV;
+   }
+
+   if (!(dmi_match(DMI_PRODUCT_NAME, "APU2") ||
+ dmi_match(DMI_PRODUCT_NAME, "apu2") ||
+ dmi_match(DMI_PRODUCT_NAME, "PC Engines apu2") ||
+ dmi_match(DMI_PRODUCT_NAME, "APU3") ||
+ dmi_match(DMI_PRODUCT_NAME, "apu3") ||
+ dmi_match(DMI_PRODUCT_NAME, "PC Engines apu3"))) {
+   pr_err("Unknown PC Engines board: %s\n",
+   dmi_get_system_info(DMI_PRODUCT_NAME));
+   return -ENODEV;
+   }
+
+   register_apu();
+
+   return 0;
+}
+
+device_initcall(apu_init);
-- 
2.11.0

[PATCH v3 2/2] kernel: Add reset button platform device for APU2/APU3

[Florian Eckert]

This will add a x86 platform device "gpio-keys-polled" which uses the
new gpio-apu drive for APU2 and APU3 boards from PC Engines.

Signed-off-by: Florian Eckert 
---
 arch/x86/Kconfig   | 14 
 arch/x86/platform/Makefile |  1 +
 arch/x86/platform/amd/Makefile |  1 +
 arch/x86/platform/amd/apu.c| 72 ++
 4 files changed, 88 insertions(+)
 create mode 100644 arch/x86/platform/amd/Makefile
 create mode 100644 arch/x86/platform/amd/apu.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9d734f3c8234..97c53286fdb6 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2820,6 +2820,20 @@ config TS5500
 
 endif # X86_32
 
+if X86_64
+config APU
+   bool "PCEngines APU System Support"
+   help
+ This option enables system support for the PCEngines APU platform.
+ At present this just sets up the reset button control on
+ APU2/APU3 boards. However, other system specific setup should
+ get added here.
+
+ Note: You must still enable the drivers for GPIO and LED support
+ (GPIO_APU & LEDS_APU) to actually use the LEDs and the GPIOs
+
+endif # X86_64
+
 config AMD_NB
def_bool y
depends on CPU_SUP_AMD && PCI
diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
index d0e835470d01..a95d18810c29 100644
--- a/arch/x86/platform/Makefile
+++ b/arch/x86/platform/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 # Platform specific code goes here
 obj-y  += atom/
+obj-y  += amd/
 obj-y  += ce4100/
 obj-y  += efi/
 obj-y  += geode/
diff --git a/arch/x86/platform/amd/Makefile b/arch/x86/platform/amd/Makefile
new file mode 100644
index ..bf04c5799d7f
--- /dev/null
+++ b/arch/x86/platform/amd/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_APU)  +=apu.o
diff --git a/arch/x86/platform/amd/apu.c b/arch/x86/platform/amd/apu.c
new file mode 100644
index ..a4b695881177
--- /dev/null
+++ b/arch/x86/platform/amd/apu.c
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * System Specific setup for PC-Engines APU2/APU3 devices
+ *
+ * Copyright (C) 2018 Florian Eckert 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct gpio_keys_button apu_gpio_buttons[] = {
+   {
+   .code   = KEY_RESTART,
+   .gpio   = 20,
+   .active_low = 1,
+   .desc   = "Reset button",
+   .type   = EV_KEY,
+   .debounce_interval  = 60,
+   }
+};
+
+static struct gpio_keys_platform_data apu_buttons_data = {
+   .buttons= apu_gpio_buttons,
+   .nbuttons   = ARRAY_SIZE(apu_gpio_buttons),
+   .poll_interval  = 20,
+};
+
+static struct platform_device apu_buttons_dev = {
+   .name   = "gpio-keys-polled",
+   .id = 1,
+   .dev = {
+   .platform_data  = _buttons_data,
+   }
+};
+
+static struct platform_device *apu_devs[] __initdata = {
+   _buttons_dev,
+};
+
+static void __init register_apu(void)
+{
+   /* Setup push button control through gpio-apu driver */
+   platform_add_devices(apu_devs, ARRAY_SIZE(apu_devs));
+}
+
+static int __init apu_init(void)
+{
+   if (!dmi_match(DMI_SYS_VENDOR, "PC Engines")) {
+   pr_err("No PC Engines board detected\n");
+   return -ENODEV;
+   }
+
+   if (!(dmi_match(DMI_PRODUCT_NAME, "APU2") ||
+ dmi_match(DMI_PRODUCT_NAME, "apu2") ||
+ dmi_match(DMI_PRODUCT_NAME, "PC Engines apu2") ||
+ dmi_match(DMI_PRODUCT_NAME, "APU3") ||
+ dmi_match(DMI_PRODUCT_NAME, "apu3") ||
+ dmi_match(DMI_PRODUCT_NAME, "PC Engines apu3"))) {
+   pr_err("Unknown PC Engines board: %s\n",
+   dmi_get_system_info(DMI_PRODUCT_NAME));
+   return -ENODEV;
+   }
+
+   register_apu();
+
+   return 0;
+}
+
+device_initcall(apu_init);
-- 
2.11.0

Re: [PATCH] l1tf: drop the swap storage limit restriction when l1tf=off

[Michal Hocko]

On Tue 13-11-18 20:56:54, Jiri Kosina wrote:
> On Tue, 13 Nov 2018, Michal Hocko wrote:
> 
> > From: Michal Hocko 
> > 
> > Swap storage is restricted to max_swapfile_size (~16TB on x86_64)
> > whenever the system is deemed affected by L1TF vulnerability. Even
> > though the limit is quite high for most deployments it seems to be
> > too restrictive for deployments which are willing to live with the
> > mitigation disabled.
> > 
> > We have a customer to deploy 8x 6,4TB PCIe/NVMe SSD swap devices
> > which is clearly out of the limit.
> > 
> > Drop the swap restriction when l1tf=off is specified. It also doesn't
> > make much sense to warn about too much memory for the l1tf mitigation
> > when it is forcefully disabled by the administrator.
> > 
> > Signed-off-by: Michal Hocko 
> > ---
> >  Documentation/admin-guide/kernel-parameters.txt | 2 ++
> >  Documentation/admin-guide/l1tf.rst  | 5 -
> >  arch/x86/kernel/cpu/bugs.c  | 3 ++-
> >  arch/x86/mm/init.c  | 2 +-
> >  4 files changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index 81d1d5a74728..a54f2bd39e77 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -2095,6 +2095,8 @@
> > off
> > Disables hypervisor mitigations and doesn't
> > emit any warnings.
> > +   It also drops the swap size and available
> > +   RAM limit restriction.
> 
> Minor nit: I think this should explicitly mention that those two things 
> are related to bare metal mitigation, to avoid any confusion (as otherwise 
> the l1tf cmdline parameter is purely about hypervisor mitigations).

Do you have any specific wording in mind?

It also drops the swap size and available RAM limit restrictions on both
hypervisor and bare metal.

Sounds better?

> With that
> 
>   Acked-by: Jiri Kosina 

Thanks!
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] l1tf: drop the swap storage limit restriction when l1tf=off

[Michal Hocko]

On Tue 13-11-18 20:56:54, Jiri Kosina wrote:
> On Tue, 13 Nov 2018, Michal Hocko wrote:
> 
> > From: Michal Hocko 
> > 
> > Swap storage is restricted to max_swapfile_size (~16TB on x86_64)
> > whenever the system is deemed affected by L1TF vulnerability. Even
> > though the limit is quite high for most deployments it seems to be
> > too restrictive for deployments which are willing to live with the
> > mitigation disabled.
> > 
> > We have a customer to deploy 8x 6,4TB PCIe/NVMe SSD swap devices
> > which is clearly out of the limit.
> > 
> > Drop the swap restriction when l1tf=off is specified. It also doesn't
> > make much sense to warn about too much memory for the l1tf mitigation
> > when it is forcefully disabled by the administrator.
> > 
> > Signed-off-by: Michal Hocko 
> > ---
> >  Documentation/admin-guide/kernel-parameters.txt | 2 ++
> >  Documentation/admin-guide/l1tf.rst  | 5 -
> >  arch/x86/kernel/cpu/bugs.c  | 3 ++-
> >  arch/x86/mm/init.c  | 2 +-
> >  4 files changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index 81d1d5a74728..a54f2bd39e77 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -2095,6 +2095,8 @@
> > off
> > Disables hypervisor mitigations and doesn't
> > emit any warnings.
> > +   It also drops the swap size and available
> > +   RAM limit restriction.
> 
> Minor nit: I think this should explicitly mention that those two things 
> are related to bare metal mitigation, to avoid any confusion (as otherwise 
> the l1tf cmdline parameter is purely about hypervisor mitigations).

Do you have any specific wording in mind?

It also drops the swap size and available RAM limit restrictions on both
hypervisor and bare metal.

Sounds better?

> With that
> 
>   Acked-by: Jiri Kosina 

Thanks!
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 1/2] Makefile: Fix distcc compilation with x86 macros

[Logan Gunthorpe]

On 13/11/18 11:34 AM, Nadav Amit wrote:
> Just one question before I send v2, since I have second thoughts. Does it
> make sense to require the “DISTCC” make parameter, or should it be set in
> the Kconfig? It can be detected automatically, the same way gcc/clang are
> detected or manually through a config option.

I very much prefer the make variable as it can be set in the environment
without having to change the Kconfig.

Logan

Re: [PATCH 1/2] Makefile: Fix distcc compilation with x86 macros

[Logan Gunthorpe]

On 13/11/18 11:34 AM, Nadav Amit wrote:
> Just one question before I send v2, since I have second thoughts. Does it
> make sense to require the “DISTCC” make parameter, or should it be set in
> the Kconfig? It can be detected automatically, the same way gcc/clang are
> detected or manually through a config option.

I very much prefer the make variable as it can be set in the environment
without having to change the Kconfig.

Logan

RE: [PATCH v3] thermal: qoriq: add multiple sensors support

[Andy Tang]

PING.

BR,
Andy

> -Original Message-
> From: andy.t...@nxp.com 
> Sent: 2018年10月30日 9:00
> To: rui.zh...@intel.com; daniel.lezc...@linaro.org
> Cc: edubez...@gmail.com; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Andy Tang 
> Subject: [PATCH v3] thermal: qoriq: add multiple sensors support
> 
> From: Yuantian Tang 
> 
> The QorIQ Layerscape SoC has several thermal sensors but the current
> driver only supports one.
> 
> Massage the code to be sensor oriented and allow the support for
> multiple sensors.
> 
> Signed-off-by: Yuantian Tang 
> Reviewed-by: Daniel Lezcano 
> ---
> v3:
>   - add Reviewed-by
> v2:
>   - update the commit message
>   - refine the qoriq_tmu_register_tmu_zone()
> 
>  drivers/thermal/qoriq_thermal.c |  100
> ++-
>  1 files changed, 46 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/thermal/qoriq_thermal.c
> b/drivers/thermal/qoriq_thermal.c index 450ed66..8beb344 100644
> --- a/drivers/thermal/qoriq_thermal.c
> +++ b/drivers/thermal/qoriq_thermal.c
> @@ -59,14 +59,21 @@ struct qoriq_tmu_regs {
>   u32 ttr3cr; /* Temperature Range 3 Control Register */
>  };
> 
> +struct qoriq_tmu_data;
> +
>  /*
>   * Thermal zone data
>   */
> +struct qoriq_sensor {
> + struct thermal_zone_device  *tzd;
> + struct qoriq_tmu_data   *qdata;
> + int id;
> +};
> +
>  struct qoriq_tmu_data {
> - struct thermal_zone_device *tz;
>   struct qoriq_tmu_regs __iomem *regs;
> - int sensor_id;
>   bool little_endian;
> + struct qoriq_sensor *sensor[SITES_MAX];
>  };
> 
>  static void tmu_write(struct qoriq_tmu_data *p, u32 val, void __iomem
> *addr) @@ -87,48 +94,51 @@ static u32 tmu_read(struct
> qoriq_tmu_data *p, void __iomem *addr)
> 
>  static int tmu_get_temp(void *p, int *temp)  {
> + struct qoriq_sensor *qsensor = p;
> + struct qoriq_tmu_data *qdata = qsensor->qdata;
>   u32 val;
> - struct qoriq_tmu_data *data = p;
> 
> - val = tmu_read(data, >regs->site[data->sensor_id].tritsr);
> + val = tmu_read(qdata, >regs->site[qsensor->id].tritsr);
>   *temp = (val & 0xff) * 1000;
> 
>   return 0;
>  }
> 
> -static int qoriq_tmu_get_sensor_id(void)
> +static const struct thermal_zone_of_device_ops tmu_tz_ops = {
> + .get_temp = tmu_get_temp,
> +};
> +
> +static int qoriq_tmu_register_tmu_zone(struct platform_device *pdev)
>  {
> - int ret, id;
> - struct of_phandle_args sensor_specs;
> - struct device_node *np, *sensor_np;
> + struct qoriq_tmu_data *qdata = platform_get_drvdata(pdev);
> + int id, sites = 0;
> 
> - np = of_find_node_by_name(NULL, "thermal-zones");
> - if (!np)
> - return -ENODEV;
> + for (id = 0; id < SITES_MAX; id++) {
> + qdata->sensor[id] = devm_kzalloc(>dev,
> + sizeof(struct qoriq_sensor), GFP_KERNEL);
> + if (!qdata->sensor[id])
> + return -ENOMEM;
> 
> - sensor_np = of_get_next_child(np, NULL);
> - ret = of_parse_phandle_with_args(sensor_np, "thermal-sensors",
> - "#thermal-sensor-cells",
> - 0, _specs);
> - if (ret) {
> - of_node_put(np);
> - of_node_put(sensor_np);
> - return ret;
> - }
> + qdata->sensor[id]->id = id;
> + qdata->sensor[id]->qdata = qdata;
> 
> - if (sensor_specs.args_count >= 1) {
> - id = sensor_specs.args[0];
> - WARN(sensor_specs.args_count > 1,
> - "%s: too many cells in sensor specifier %d\n",
> - sensor_specs.np->name, sensor_specs.args_count);
> - } else {
> - id = 0;
> - }
> + qdata->sensor[id]->tzd =
> devm_thermal_zone_of_sensor_register(
> + >dev, id, qdata->sensor[id], _tz_ops);
> + if (IS_ERR(qdata->sensor[id]->tzd)) {
> + if (PTR_ERR(qdata->sensor[id]->tzd) == -ENODEV)
> + continue;
> + else
> + return PTR_ERR(qdata->sensor[id]->tzd);
> 
> - of_node_put(np);
> - of_node_put(sensor_np);
> + }
> +
> + sites |= 0x1 << (15 - id);
> + }
> + /* Enable monitoring */
> + if (sites != 0)
> + tmu_write(qdata, sites | TMR_ME | TMR_ALPF,
> >regs->tmr);
> 
> - return id;
> + return 0;
>  }
> 
>  static int qoriq_tmu_calibration(struct platform_device *pdev) @@
> -178,16 +188,11 @@ static void qoriq_tmu_init_device(struct
> qoriq_tmu_data *data)
>   tmu_write(data, TMR_DISABLE, >regs->tmr);  }
> 
> -static const struct thermal_zone_of_device_ops tmu_tz_ops = {
> - .get_temp = tmu_get_temp,
> -};
> -
>  static int qoriq_tmu_probe(struct platform_device *pdev)  {
>   int ret;
>   struct qoriq_tmu_data *data;
>   struct 

RE: [PATCH v3] thermal: qoriq: add multiple sensors support

[Andy Tang]

PING.

BR,
Andy

> -Original Message-
> From: andy.t...@nxp.com 
> Sent: 2018年10月30日 9:00
> To: rui.zh...@intel.com; daniel.lezc...@linaro.org
> Cc: edubez...@gmail.com; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Andy Tang 
> Subject: [PATCH v3] thermal: qoriq: add multiple sensors support
> 
> From: Yuantian Tang 
> 
> The QorIQ Layerscape SoC has several thermal sensors but the current
> driver only supports one.
> 
> Massage the code to be sensor oriented and allow the support for
> multiple sensors.
> 
> Signed-off-by: Yuantian Tang 
> Reviewed-by: Daniel Lezcano 
> ---
> v3:
>   - add Reviewed-by
> v2:
>   - update the commit message
>   - refine the qoriq_tmu_register_tmu_zone()
> 
>  drivers/thermal/qoriq_thermal.c |  100
> ++-
>  1 files changed, 46 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/thermal/qoriq_thermal.c
> b/drivers/thermal/qoriq_thermal.c index 450ed66..8beb344 100644
> --- a/drivers/thermal/qoriq_thermal.c
> +++ b/drivers/thermal/qoriq_thermal.c
> @@ -59,14 +59,21 @@ struct qoriq_tmu_regs {
>   u32 ttr3cr; /* Temperature Range 3 Control Register */
>  };
> 
> +struct qoriq_tmu_data;
> +
>  /*
>   * Thermal zone data
>   */
> +struct qoriq_sensor {
> + struct thermal_zone_device  *tzd;
> + struct qoriq_tmu_data   *qdata;
> + int id;
> +};
> +
>  struct qoriq_tmu_data {
> - struct thermal_zone_device *tz;
>   struct qoriq_tmu_regs __iomem *regs;
> - int sensor_id;
>   bool little_endian;
> + struct qoriq_sensor *sensor[SITES_MAX];
>  };
> 
>  static void tmu_write(struct qoriq_tmu_data *p, u32 val, void __iomem
> *addr) @@ -87,48 +94,51 @@ static u32 tmu_read(struct
> qoriq_tmu_data *p, void __iomem *addr)
> 
>  static int tmu_get_temp(void *p, int *temp)  {
> + struct qoriq_sensor *qsensor = p;
> + struct qoriq_tmu_data *qdata = qsensor->qdata;
>   u32 val;
> - struct qoriq_tmu_data *data = p;
> 
> - val = tmu_read(data, >regs->site[data->sensor_id].tritsr);
> + val = tmu_read(qdata, >regs->site[qsensor->id].tritsr);
>   *temp = (val & 0xff) * 1000;
> 
>   return 0;
>  }
> 
> -static int qoriq_tmu_get_sensor_id(void)
> +static const struct thermal_zone_of_device_ops tmu_tz_ops = {
> + .get_temp = tmu_get_temp,
> +};
> +
> +static int qoriq_tmu_register_tmu_zone(struct platform_device *pdev)
>  {
> - int ret, id;
> - struct of_phandle_args sensor_specs;
> - struct device_node *np, *sensor_np;
> + struct qoriq_tmu_data *qdata = platform_get_drvdata(pdev);
> + int id, sites = 0;
> 
> - np = of_find_node_by_name(NULL, "thermal-zones");
> - if (!np)
> - return -ENODEV;
> + for (id = 0; id < SITES_MAX; id++) {
> + qdata->sensor[id] = devm_kzalloc(>dev,
> + sizeof(struct qoriq_sensor), GFP_KERNEL);
> + if (!qdata->sensor[id])
> + return -ENOMEM;
> 
> - sensor_np = of_get_next_child(np, NULL);
> - ret = of_parse_phandle_with_args(sensor_np, "thermal-sensors",
> - "#thermal-sensor-cells",
> - 0, _specs);
> - if (ret) {
> - of_node_put(np);
> - of_node_put(sensor_np);
> - return ret;
> - }
> + qdata->sensor[id]->id = id;
> + qdata->sensor[id]->qdata = qdata;
> 
> - if (sensor_specs.args_count >= 1) {
> - id = sensor_specs.args[0];
> - WARN(sensor_specs.args_count > 1,
> - "%s: too many cells in sensor specifier %d\n",
> - sensor_specs.np->name, sensor_specs.args_count);
> - } else {
> - id = 0;
> - }
> + qdata->sensor[id]->tzd =
> devm_thermal_zone_of_sensor_register(
> + >dev, id, qdata->sensor[id], _tz_ops);
> + if (IS_ERR(qdata->sensor[id]->tzd)) {
> + if (PTR_ERR(qdata->sensor[id]->tzd) == -ENODEV)
> + continue;
> + else
> + return PTR_ERR(qdata->sensor[id]->tzd);
> 
> - of_node_put(np);
> - of_node_put(sensor_np);
> + }
> +
> + sites |= 0x1 << (15 - id);
> + }
> + /* Enable monitoring */
> + if (sites != 0)
> + tmu_write(qdata, sites | TMR_ME | TMR_ALPF,
> >regs->tmr);
> 
> - return id;
> + return 0;
>  }
> 
>  static int qoriq_tmu_calibration(struct platform_device *pdev) @@
> -178,16 +188,11 @@ static void qoriq_tmu_init_device(struct
> qoriq_tmu_data *data)
>   tmu_write(data, TMR_DISABLE, >regs->tmr);  }
> 
> -static const struct thermal_zone_of_device_ops tmu_tz_ops = {
> - .get_temp = tmu_get_temp,
> -};
> -
>  static int qoriq_tmu_probe(struct platform_device *pdev)  {
>   int ret;
>   struct qoriq_tmu_data *data;
>   struct 

Re: [PATCH v2] UAPI: move RENAME_* definitions to separated file

[Yury Norov]

Hi all, 

It seems that I forgot to rename guards in v2. This is the correct
version. My apologize for noise.

Yury

>From 61215b1cb559e69fb57f2a82864e72e3a1ef4b12 Mon Sep 17 00:00:00 2001
From: Yury Norov 
Date: Wed, 14 Nov 2018 09:51:49 +0300
To: Andrew Morton ,
Alexander Viro ,
Florian Weimer 
CC: linux-kernel@vger.kernel.org, linux-fsde...@vger.kernel.org,
linux-...@vger.kernel.org, libc-al...@sourceware.org
Subject: [PATCH v2] UAPI: move RENAME_* definitions to separated file

Discussion:
https://lore.kernel.org/lkml/20180702084622.GA15274@yury-thinkpad/

Although RENAME_* macros are exposed in kernel headers, they are not
used by glibc. That's because linux/fs.h which hosts RENAME_* is
considered unsuitable by glibc developers:

As Florian Weimer wrote:

>  undefines and defines macros not mentioned in the standards
> (and it even contains a few unrelated structs), so we cannot include it
> without _GNU_SOURCE.
>
> It might be possible to include it only for _GNU_SOURCE, but there are a
> lot of things in , so that does not seem to be particularly
> advisable.

In this patch RENAME_* is removed to a separated header file that
conforms the standards and therefore is suitable for inclusion by glibc.

v2:
 - rename dedicated file to 'rename-flags.h', as requested by Florian.

Signed-off-by: Yury Norov 
---
 include/uapi/linux/fs.h   |  4 +---
 include/uapi/linux/rename-flags.h | 12 
 2 files changed, 13 insertions(+), 3 deletions(-)
 create mode 100644 include/uapi/linux/rename-flags.h

diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 73e01918f996..34c308203746 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -39,9 +39,7 @@
 #define SEEK_HOLE  4   /* seek to the next hole */
 #define SEEK_MAX   SEEK_HOLE
 
-#define RENAME_NOREPLACE   (1 << 0)/* Don't overwrite target */
-#define RENAME_EXCHANGE(1 << 1)/* Exchange source and 
dest */
-#define RENAME_WHITEOUT(1 << 2)/* Whiteout source */
+#include 
 
 struct file_clone_range {
__s64 src_fd;
diff --git a/include/uapi/linux/rename-flags.h 
b/include/uapi/linux/rename-flags.h
new file mode 100644
index ..7178f0565657
--- /dev/null
+++ b/include/uapi/linux/rename-flags.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_RENAME_FLAGS_H
+#define _UAPI_LINUX_RENAME_FLAGS_H
+
+/*
+ * Definitions for rename syscall family.
+ */
+#define RENAME_NOREPLACE   (1 << 0)/* Don't overwrite target */
+#define RENAME_EXCHANGE(1 << 1)/* Exchange source and 
dest */
+#define RENAME_WHITEOUT(1 << 2)/* Whiteout source */
+
+#endif /* _UAPI_LINUX_RENAME_FLAGS_H */
-- 
2.17.1

Re: [PATCH v2] UAPI: move RENAME_* definitions to separated file

[Yury Norov]

Hi all, 

It seems that I forgot to rename guards in v2. This is the correct
version. My apologize for noise.

Yury

>From 61215b1cb559e69fb57f2a82864e72e3a1ef4b12 Mon Sep 17 00:00:00 2001
From: Yury Norov 
Date: Wed, 14 Nov 2018 09:51:49 +0300
To: Andrew Morton ,
Alexander Viro ,
Florian Weimer 
CC: linux-kernel@vger.kernel.org, linux-fsde...@vger.kernel.org,
linux-...@vger.kernel.org, libc-al...@sourceware.org
Subject: [PATCH v2] UAPI: move RENAME_* definitions to separated file

Discussion:
https://lore.kernel.org/lkml/20180702084622.GA15274@yury-thinkpad/

Although RENAME_* macros are exposed in kernel headers, they are not
used by glibc. That's because linux/fs.h which hosts RENAME_* is
considered unsuitable by glibc developers:

As Florian Weimer wrote:

>  undefines and defines macros not mentioned in the standards
> (and it even contains a few unrelated structs), so we cannot include it
> without _GNU_SOURCE.
>
> It might be possible to include it only for _GNU_SOURCE, but there are a
> lot of things in , so that does not seem to be particularly
> advisable.

In this patch RENAME_* is removed to a separated header file that
conforms the standards and therefore is suitable for inclusion by glibc.

v2:
 - rename dedicated file to 'rename-flags.h', as requested by Florian.

Signed-off-by: Yury Norov 
---
 include/uapi/linux/fs.h   |  4 +---
 include/uapi/linux/rename-flags.h | 12 
 2 files changed, 13 insertions(+), 3 deletions(-)
 create mode 100644 include/uapi/linux/rename-flags.h

diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 73e01918f996..34c308203746 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -39,9 +39,7 @@
 #define SEEK_HOLE  4   /* seek to the next hole */
 #define SEEK_MAX   SEEK_HOLE
 
-#define RENAME_NOREPLACE   (1 << 0)/* Don't overwrite target */
-#define RENAME_EXCHANGE(1 << 1)/* Exchange source and 
dest */
-#define RENAME_WHITEOUT(1 << 2)/* Whiteout source */
+#include 
 
 struct file_clone_range {
__s64 src_fd;
diff --git a/include/uapi/linux/rename-flags.h 
b/include/uapi/linux/rename-flags.h
new file mode 100644
index ..7178f0565657
--- /dev/null
+++ b/include/uapi/linux/rename-flags.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_RENAME_FLAGS_H
+#define _UAPI_LINUX_RENAME_FLAGS_H
+
+/*
+ * Definitions for rename syscall family.
+ */
+#define RENAME_NOREPLACE   (1 << 0)/* Don't overwrite target */
+#define RENAME_EXCHANGE(1 << 1)/* Exchange source and 
dest */
+#define RENAME_WHITEOUT(1 << 2)/* Whiteout source */
+
+#endif /* _UAPI_LINUX_RENAME_FLAGS_H */
-- 
2.17.1

[PATCH] HID: i2c-hid: Disable runtime PM for LG touchscreen

[Kai-Heng Feng]

LG touchscreen (1fd2:8001) stops working after reboot:
[ 4.859153] i2c_hid i2c-SAPS2101:00: i2c_hid_get_input: incomplete report 
(64/66)
[ 4.936070] i2c_hid i2c-SAPS2101:00: i2c_hid_get_input: incomplete report 
(64/66)
[ 9.948224] i2c_hid i2c-SAPS2101:00: failed to reset device.

The device in question stops working after receives SLEEP, ON, SLEEP
commands in a short period. The scenario is like this:
- Once the desktop session closes, it also closed the hid device, so the
device gets runtime suspended and receives a SLEEP command.
- Before calling shutdown callback, it gets runtime resumed and received
an ON command.
- In the shutdown callback, it receives another SLEEP command.

I failed to find a reliable interval between ON/SLEEP commands that can
make it work, so let's simply disable runtime PM for the device.

Signed-off-by: Kai-Heng Feng 
---
 drivers/hid/hid-ids.h  | 1 +
 drivers/hid/i2c-hid/i2c-hid-core.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index c0d668944dbe..bd636f529fad 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -707,6 +707,7 @@
 #define USB_VENDOR_ID_LG   0x1fd2
 #define USB_DEVICE_ID_LG_MULTITOUCH0x0064
 #define USB_DEVICE_ID_LG_MELFAS_MT 0x6007
+#define I2C_DEVICE_ID_LG_8001  0x8001
 
 #define USB_VENDOR_ID_LOGITECH 0x046d
 #define USB_DEVICE_ID_LOGITECH_AUDIOHUB 0x0a0e
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c 
b/drivers/hid/i2c-hid/i2c-hid-core.c
index 3cde7c1b9c33..8555ce7e737b 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -177,6 +177,8 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_NO_RUNTIME_PM },
{ I2C_VENDOR_ID_RAYDIUM, I2C_PRODUCT_ID_RAYDIUM_4B33,
I2C_HID_QUIRK_DELAY_AFTER_SLEEP },
+   { USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_8001,
+   I2C_HID_QUIRK_NO_RUNTIME_PM },
{ 0, 0 }
 };
 
-- 
2.17.1

[PATCH] HID: i2c-hid: Disable runtime PM for LG touchscreen

[Kai-Heng Feng]

LG touchscreen (1fd2:8001) stops working after reboot:
[ 4.859153] i2c_hid i2c-SAPS2101:00: i2c_hid_get_input: incomplete report 
(64/66)
[ 4.936070] i2c_hid i2c-SAPS2101:00: i2c_hid_get_input: incomplete report 
(64/66)
[ 9.948224] i2c_hid i2c-SAPS2101:00: failed to reset device.

The device in question stops working after receives SLEEP, ON, SLEEP
commands in a short period. The scenario is like this:
- Once the desktop session closes, it also closed the hid device, so the
device gets runtime suspended and receives a SLEEP command.
- Before calling shutdown callback, it gets runtime resumed and received
an ON command.
- In the shutdown callback, it receives another SLEEP command.

I failed to find a reliable interval between ON/SLEEP commands that can
make it work, so let's simply disable runtime PM for the device.

Signed-off-by: Kai-Heng Feng 
---
 drivers/hid/hid-ids.h  | 1 +
 drivers/hid/i2c-hid/i2c-hid-core.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index c0d668944dbe..bd636f529fad 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -707,6 +707,7 @@
 #define USB_VENDOR_ID_LG   0x1fd2
 #define USB_DEVICE_ID_LG_MULTITOUCH0x0064
 #define USB_DEVICE_ID_LG_MELFAS_MT 0x6007
+#define I2C_DEVICE_ID_LG_8001  0x8001
 
 #define USB_VENDOR_ID_LOGITECH 0x046d
 #define USB_DEVICE_ID_LOGITECH_AUDIOHUB 0x0a0e
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c 
b/drivers/hid/i2c-hid/i2c-hid-core.c
index 3cde7c1b9c33..8555ce7e737b 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -177,6 +177,8 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_NO_RUNTIME_PM },
{ I2C_VENDOR_ID_RAYDIUM, I2C_PRODUCT_ID_RAYDIUM_4B33,
I2C_HID_QUIRK_DELAY_AFTER_SLEEP },
+   { USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_8001,
+   I2C_HID_QUIRK_NO_RUNTIME_PM },
{ 0, 0 }
 };
 
-- 
2.17.1

kernel BUG at mm/slab.c:LINE! (3)

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:3e536cff3424 net: phy: check if advertising is zero using ..
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16f95b8340
kernel config:  https://syzkaller.appspot.com/x/.config?x=4a0a89f12ca9b0f5
dashboard link: https://syzkaller.appspot.com/bug?extid=2182db487a523d86bf34
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=148d46d540
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15c6a22540

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2182db487a523d86b...@syzkaller.appspotmail.com

[ cut here ]
DEBUG_LOCKS_WARN_ON(depth >= MAX_LOCK_DEPTH)
[ cut here ]
kernel BUG at mm/slab.c:4425!
invalid opcode:  [#1] PREEMPT SMP KASAN
CPU: 0 PID: -642842048 Comm: ksoftirqd/0 Not tainted 4.20.0-rc2+ #294
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:__check_heap_object+0xa7/0xb5 mm/slab.c:4450
Code: 48 c7 c7 15 73 12 89 e8 97 e3 0a 00 5d c3 41 8b 91 04 01 00 00 48 29  
c7 48 39 d7 77 be 48 01 d0 48 29 c8 48 39 f0 72 b3 5d c3 <0f> 0b 48 c7 c7  
15 73 12 89 e8 fd eb 0a 00 44 89 e9 48 c7 c7 d0 73

RSP: 0018:8881d9af0030 EFLAGS: 00010093
RAX: 000a57eb RBX: 11103b35e00d RCX: 000c
RDX: 8881d9af0240 RSI: 0002 RDI: 8881d9af01d8
RBP: 8881d9af0030 R08: 8881d9af0240 R09: 8881da970180
R10: 4afd69e7 R11:  R12: 8881d9af01d8
R13: 0002 R14: ea000766bc00 R15: 0001
FS:  () GS:8881dae0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0068 CR3: 0001bb987000 CR4: 001406f0
Call Trace:
Modules linked in:
---[ end trace 1c9eb38e9e38ee03 ]---
RIP: 0010:__check_heap_object+0xa7/0xb5 mm/slab.c:4450
Code: 48 c7 c7 15 73 12 89 e8 97 e3 0a 00 5d c3 41 8b 91 04 01 00 00 48 29  
c7 48 39 d7 77 be 48 01 d0 48 29 c8 48 39 f0 72 b3 5d c3 <0f> 0b 48 c7 c7  
15 73 12 89 e8 fd eb 0a 00 44 89 e9 48 c7 c7 d0 73

RSP: 0018:8881d9af0030 EFLAGS: 00010093
RAX: 000a57eb RBX: 11103b35e00d RCX: 000c
RDX: 8881d9af0240 RSI: 0002 RDI: 8881d9af01d8
RBP: 8881d9af0030 R08: 8881d9af0240 R09: 8881da970180
R10: 4afd69e7 R11:  R12: 8881d9af01d8
R13: 0002 R14: ea000766bc00 R15: 0001
FS:  () GS:8881dae0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0068 CR3: 0001bb987000 CR4: 001406f0


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.

syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

kernel BUG at mm/slab.c:LINE! (3)

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:3e536cff3424 net: phy: check if advertising is zero using ..
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16f95b8340
kernel config:  https://syzkaller.appspot.com/x/.config?x=4a0a89f12ca9b0f5
dashboard link: https://syzkaller.appspot.com/bug?extid=2182db487a523d86bf34
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=148d46d540
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15c6a22540

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2182db487a523d86b...@syzkaller.appspotmail.com

[ cut here ]
DEBUG_LOCKS_WARN_ON(depth >= MAX_LOCK_DEPTH)
[ cut here ]
kernel BUG at mm/slab.c:4425!
invalid opcode:  [#1] PREEMPT SMP KASAN
CPU: 0 PID: -642842048 Comm: ksoftirqd/0 Not tainted 4.20.0-rc2+ #294
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:__check_heap_object+0xa7/0xb5 mm/slab.c:4450
Code: 48 c7 c7 15 73 12 89 e8 97 e3 0a 00 5d c3 41 8b 91 04 01 00 00 48 29  
c7 48 39 d7 77 be 48 01 d0 48 29 c8 48 39 f0 72 b3 5d c3 <0f> 0b 48 c7 c7  
15 73 12 89 e8 fd eb 0a 00 44 89 e9 48 c7 c7 d0 73

RSP: 0018:8881d9af0030 EFLAGS: 00010093
RAX: 000a57eb RBX: 11103b35e00d RCX: 000c
RDX: 8881d9af0240 RSI: 0002 RDI: 8881d9af01d8
RBP: 8881d9af0030 R08: 8881d9af0240 R09: 8881da970180
R10: 4afd69e7 R11:  R12: 8881d9af01d8
R13: 0002 R14: ea000766bc00 R15: 0001
FS:  () GS:8881dae0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0068 CR3: 0001bb987000 CR4: 001406f0
Call Trace:
Modules linked in:
---[ end trace 1c9eb38e9e38ee03 ]---
RIP: 0010:__check_heap_object+0xa7/0xb5 mm/slab.c:4450
Code: 48 c7 c7 15 73 12 89 e8 97 e3 0a 00 5d c3 41 8b 91 04 01 00 00 48 29  
c7 48 39 d7 77 be 48 01 d0 48 29 c8 48 39 f0 72 b3 5d c3 <0f> 0b 48 c7 c7  
15 73 12 89 e8 fd eb 0a 00 44 89 e9 48 c7 c7 d0 73

RSP: 0018:8881d9af0030 EFLAGS: 00010093
RAX: 000a57eb RBX: 11103b35e00d RCX: 000c
RDX: 8881d9af0240 RSI: 0002 RDI: 8881d9af01d8
RBP: 8881d9af0030 R08: 8881d9af0240 R09: 8881da970180
R10: 4afd69e7 R11:  R12: 8881d9af01d8
R13: 0002 R14: ea000766bc00 R15: 0001
FS:  () GS:8881dae0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0068 CR3: 0001bb987000 CR4: 001406f0


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.

syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [PATCH RFC v2 0/3] cleanups for pstore and ramoops

[Kees Cook]

On Sat, Nov 3, 2018 at 6:38 PM, Joel Fernandes (Google)
 wrote:
> Here are some simple cleanups and fixes for ramoops in pstore. Let me know
> what you think, thanks.

I took these and slightly tweaked code locations for the first one.
I'll send out the series for review when I'm back from Plumber's.

-Kees

>
> Joel Fernandes (Google) (3):
> pstore: map pstore types to names
> pstore: simplify ramoops_get_next_prz arguments
> pstore: donot treat empty buffers as valid
>
> fs/pstore/inode.c  | 53 +-
> fs/pstore/ram.c| 52 +++--
> fs/pstore/ram_core.c   |  2 +-
> include/linux/pstore.h | 37 ++
> include/linux/pstore_ram.h |  2 ++
> 5 files changed, 67 insertions(+), 79 deletions(-)
>
> --
> 2.19.1.930.g4563a0d9d0-goog
>



-- 
Kees Cook

Re: [PATCH RFC v2 0/3] cleanups for pstore and ramoops

[Kees Cook]

On Sat, Nov 3, 2018 at 6:38 PM, Joel Fernandes (Google)
 wrote:
> Here are some simple cleanups and fixes for ramoops in pstore. Let me know
> what you think, thanks.

I took these and slightly tweaked code locations for the first one.
I'll send out the series for review when I'm back from Plumber's.

-Kees

>
> Joel Fernandes (Google) (3):
> pstore: map pstore types to names
> pstore: simplify ramoops_get_next_prz arguments
> pstore: donot treat empty buffers as valid
>
> fs/pstore/inode.c  | 53 +-
> fs/pstore/ram.c| 52 +++--
> fs/pstore/ram_core.c   |  2 +-
> include/linux/pstore.h | 37 ++
> include/linux/pstore_ram.h |  2 ++
> 5 files changed, 67 insertions(+), 79 deletions(-)
>
> --
> 2.19.1.930.g4563a0d9d0-goog
>



-- 
Kees Cook

Re: [RFC PATCH] mm, memory_hotplug: do not clear numa_node association after hot_remove

[Michal Hocko]

It seems there were no objections here. So can we have it in linux-next
for a wider testing a possibly target the next merge window?

On Thu 08-11-18 11:04:13, Michal Hocko wrote:
> From: Michal Hocko 
> 
> Per-cpu numa_node provides a default node for each possible cpu. The
> association gets initialized during the boot when the architecture
> specific code explores cpu->NUMA affinity. When the whole NUMA node is
> removed though we are clearing this association
> 
> try_offline_node
>   check_and_unmap_cpu_on_node
> unmap_cpu_on_node
>   numa_clear_node
> numa_set_node(cpu, NUMA_NO_NODE)
> 
> This means that whoever calls cpu_to_node for a cpu associated with such
> a node will get NUMA_NO_NODE. This is problematic for two reasons. First
> it is fragile because __alloc_pages_node would simply blow up on an
> out-of-bound access. We have encountered this when loading kvm module
> BUG: unable to handle kernel paging request at 21c0
> IP: [] __alloc_pages_nodemask+0x93/0xb70
> PGD 80ffe853e067 PUD 7336bbc067 PMD 0
> Oops:  [#1] SMP
> [...]
> CPU: 88 PID: 1223749 Comm: modprobe Tainted: GW  
> 4.4.156-94.64-default #1
> task: 88727eff1880 ti: 88735449 task.ti: 88735449
> RIP: 0010:[]  [] 
> __alloc_pages_nodemask+0x93/0xb70
> RSP: 0018:887354493b40  EFLAGS: 00010202
> RAX: 21c0 RBX:  RCX: 
> RDX:  RSI: 0002 RDI: 014000c0
> RBP: 014000c0 R08:  R09: 
> R10: 88fffc89e790 R11: 00014000 R12: 0101
> R13: a0772cd4 R14: a0769ac0 R15: 
> FS:  7fdf2f2f1700() GS:88fffc88() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 21c0 CR3: 0077205ee000 CR4: 00360670
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Stack:
>  0086 014000c014d20400 887354493bb8 882614d20f4c
>   0046 0046 810ac0c9
>  88ffe78c 009f e8ffe82d3500 88ff8ac55000
> Call Trace:
>  [] alloc_vmcs_cpu+0x3d/0x90 [kvm_intel]
>  [] hardware_setup+0x781/0x849 [kvm_intel]
>  [] kvm_arch_hardware_setup+0x28/0x190 [kvm]
>  [] kvm_init+0x7c/0x2d0 [kvm]
>  [] vmx_init+0x1e/0x32c [kvm_intel]
>  [] do_one_initcall+0xca/0x1f0
>  [] do_init_module+0x5a/0x1d7
>  [] load_module+0x1393/0x1c90
>  [] SYSC_finit_module+0x70/0xa0
>  [] entry_SYSCALL_64_fastpath+0x1e/0xb7
> DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x1e/0xb7
> 
> on an older kernel but the code is basically the same in the current
> Linus tree as well. alloc_vmcs_cpu could use alloc_pages_nodemask which
> would recognize NUMA_NO_NODE and use alloc_pages_node which would translate
> it to numa_mem_id but that is wrong as well because it would use a cpu
> affinity of the local CPU which might be quite far from the original node.
> It is also reasonable to expect that cpu_to_node will provide a sane value
> and there might be many more callers like that.
> 
> The second problem is that __register_one_node relies on cpu_to_node
> to properly associate cpus back to the node when it is onlined. We do
> not want to lose that link as there is no arch independent way to get it
> from the early boot time AFAICS.
> 
> Drop the whole check_and_unmap_cpu_on_node machinery and keep the
> association to fix both issues. The NODE_DATA(nid) is not deallocated
> so it will stay in place and if anybody wants to allocate from that node
> then a fallback node will be used.
> 
> Thanks to Vlastimil Babka for his live system debugging skills that
> helped debugging the issue.
> 
> Debugged-by: Vlastimil Babka 
> Reported-by: Miroslav Benes 
> Fixes: e13fe8695c57 ("cpu-hotplug,memory-hotplug: clear cpu_to_node() when 
> offlining the node")
> Cc: Wen Congyang 
> Cc: Tang Chen 
> Signed-off-by: Michal Hocko 
> ---
> 
> Hi,
> please note that I am sending this as an RFC even though this has been
> confirmed to fix the oops in kvm_intel module because I cannot simply
> tell that there are no other side effect that I do not see from the code
> reading. I would appreciate some background from people who have
> introduced this code e13fe8695c57 ("cpu-hotplug,memory-hotplug: clear
> cpu_to_node() when offlining the node") because the changelog doesn't
> really explain the motivation much.
> 
>  mm/memory_hotplug.c | 30 +-
>  1 file changed, 1 insertion(+), 29 deletions(-)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 2b2b3ccbbfb5..87aeafac54ee 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1753,34 +1753,6 @@ static int check_cpu_on_node(pg_data_t *pgdat)
>   return 0;
>  }
>  
> -static void unmap_cpu_on_node(pg_data_t *pgdat)
> -{
> -#ifdef 

Re: [RFC PATCH] mm, memory_hotplug: do not clear numa_node association after hot_remove

[Michal Hocko]

It seems there were no objections here. So can we have it in linux-next
for a wider testing a possibly target the next merge window?

On Thu 08-11-18 11:04:13, Michal Hocko wrote:
> From: Michal Hocko 
> 
> Per-cpu numa_node provides a default node for each possible cpu. The
> association gets initialized during the boot when the architecture
> specific code explores cpu->NUMA affinity. When the whole NUMA node is
> removed though we are clearing this association
> 
> try_offline_node
>   check_and_unmap_cpu_on_node
> unmap_cpu_on_node
>   numa_clear_node
> numa_set_node(cpu, NUMA_NO_NODE)
> 
> This means that whoever calls cpu_to_node for a cpu associated with such
> a node will get NUMA_NO_NODE. This is problematic for two reasons. First
> it is fragile because __alloc_pages_node would simply blow up on an
> out-of-bound access. We have encountered this when loading kvm module
> BUG: unable to handle kernel paging request at 21c0
> IP: [] __alloc_pages_nodemask+0x93/0xb70
> PGD 80ffe853e067 PUD 7336bbc067 PMD 0
> Oops:  [#1] SMP
> [...]
> CPU: 88 PID: 1223749 Comm: modprobe Tainted: GW  
> 4.4.156-94.64-default #1
> task: 88727eff1880 ti: 88735449 task.ti: 88735449
> RIP: 0010:[]  [] 
> __alloc_pages_nodemask+0x93/0xb70
> RSP: 0018:887354493b40  EFLAGS: 00010202
> RAX: 21c0 RBX:  RCX: 
> RDX:  RSI: 0002 RDI: 014000c0
> RBP: 014000c0 R08:  R09: 
> R10: 88fffc89e790 R11: 00014000 R12: 0101
> R13: a0772cd4 R14: a0769ac0 R15: 
> FS:  7fdf2f2f1700() GS:88fffc88() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 21c0 CR3: 0077205ee000 CR4: 00360670
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Stack:
>  0086 014000c014d20400 887354493bb8 882614d20f4c
>   0046 0046 810ac0c9
>  88ffe78c 009f e8ffe82d3500 88ff8ac55000
> Call Trace:
>  [] alloc_vmcs_cpu+0x3d/0x90 [kvm_intel]
>  [] hardware_setup+0x781/0x849 [kvm_intel]
>  [] kvm_arch_hardware_setup+0x28/0x190 [kvm]
>  [] kvm_init+0x7c/0x2d0 [kvm]
>  [] vmx_init+0x1e/0x32c [kvm_intel]
>  [] do_one_initcall+0xca/0x1f0
>  [] do_init_module+0x5a/0x1d7
>  [] load_module+0x1393/0x1c90
>  [] SYSC_finit_module+0x70/0xa0
>  [] entry_SYSCALL_64_fastpath+0x1e/0xb7
> DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x1e/0xb7
> 
> on an older kernel but the code is basically the same in the current
> Linus tree as well. alloc_vmcs_cpu could use alloc_pages_nodemask which
> would recognize NUMA_NO_NODE and use alloc_pages_node which would translate
> it to numa_mem_id but that is wrong as well because it would use a cpu
> affinity of the local CPU which might be quite far from the original node.
> It is also reasonable to expect that cpu_to_node will provide a sane value
> and there might be many more callers like that.
> 
> The second problem is that __register_one_node relies on cpu_to_node
> to properly associate cpus back to the node when it is onlined. We do
> not want to lose that link as there is no arch independent way to get it
> from the early boot time AFAICS.
> 
> Drop the whole check_and_unmap_cpu_on_node machinery and keep the
> association to fix both issues. The NODE_DATA(nid) is not deallocated
> so it will stay in place and if anybody wants to allocate from that node
> then a fallback node will be used.
> 
> Thanks to Vlastimil Babka for his live system debugging skills that
> helped debugging the issue.
> 
> Debugged-by: Vlastimil Babka 
> Reported-by: Miroslav Benes 
> Fixes: e13fe8695c57 ("cpu-hotplug,memory-hotplug: clear cpu_to_node() when 
> offlining the node")
> Cc: Wen Congyang 
> Cc: Tang Chen 
> Signed-off-by: Michal Hocko 
> ---
> 
> Hi,
> please note that I am sending this as an RFC even though this has been
> confirmed to fix the oops in kvm_intel module because I cannot simply
> tell that there are no other side effect that I do not see from the code
> reading. I would appreciate some background from people who have
> introduced this code e13fe8695c57 ("cpu-hotplug,memory-hotplug: clear
> cpu_to_node() when offlining the node") because the changelog doesn't
> really explain the motivation much.
> 
>  mm/memory_hotplug.c | 30 +-
>  1 file changed, 1 insertion(+), 29 deletions(-)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 2b2b3ccbbfb5..87aeafac54ee 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1753,34 +1753,6 @@ static int check_cpu_on_node(pg_data_t *pgdat)
>   return 0;
>  }
>  
> -static void unmap_cpu_on_node(pg_data_t *pgdat)
> -{
> -#ifdef 

[PATCH v2] UAPI: move RENAME_* definitions to separated file

[Yury Norov]

Discussion:
https://lore.kernel.org/lkml/20180702084622.GA15274@yury-thinkpad/

Although RENAME_* macros are exposed in kernel headers, they are not
used by glibc. That's because linux/fs.h which hosts RENAME_* is
considered unsuitable by glibc developers:

As Florian Weimer wrote:

>  undefines and defines macros not mentioned in the standards
> (and it even contains a few unrelated structs), so we cannot include it
> without _GNU_SOURCE.
>
> It might be possible to include it only for _GNU_SOURCE, but there are a
> lot of things in , so that does not seem to be particularly
> advisable.

In this patch RENAME_* is removed to a separated header file that
conforms the standards and therefore is suitable for inclusion by glibc.

v2:
 - rename dedicated file to 'rename-flags.h', as requested by Florian.

Signed-off-by: Yury Norov 
---
 include/uapi/linux/fs.h   |  4 +---
 include/uapi/linux/rename-flags.h | 12 
 2 files changed, 13 insertions(+), 3 deletions(-)
 create mode 100644 include/uapi/linux/rename-flags.h

diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 73e01918f996..34c308203746 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -39,9 +39,7 @@
 #define SEEK_HOLE  4   /* seek to the next hole */
 #define SEEK_MAX   SEEK_HOLE
 
-#define RENAME_NOREPLACE   (1 << 0)/* Don't overwrite target */
-#define RENAME_EXCHANGE(1 << 1)/* Exchange source and 
dest */
-#define RENAME_WHITEOUT(1 << 2)/* Whiteout source */
+#include 
 
 struct file_clone_range {
__s64 src_fd;
diff --git a/include/uapi/linux/rename-flags.h 
b/include/uapi/linux/rename-flags.h
new file mode 100644
index ..7178f0565657
--- /dev/null
+++ b/include/uapi/linux/rename-flags.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_RENAME_H
+#define _UAPI_LINUX_RENAME_H
+
+/*
+ * Definitions for rename syscall family.
+ */
+#define RENAME_NOREPLACE   (1 << 0)/* Don't overwrite target */
+#define RENAME_EXCHANGE(1 << 1)/* Exchange source and 
dest */
+#define RENAME_WHITEOUT(1 << 2)/* Whiteout source */
+
+#endif /* _UAPI_LINUX_RENAME_H */
-- 
2.17.1

[PATCH v2] UAPI: move RENAME_* definitions to separated file

[Yury Norov]

Discussion:
https://lore.kernel.org/lkml/20180702084622.GA15274@yury-thinkpad/

Although RENAME_* macros are exposed in kernel headers, they are not
used by glibc. That's because linux/fs.h which hosts RENAME_* is
considered unsuitable by glibc developers:

As Florian Weimer wrote:

>  undefines and defines macros not mentioned in the standards
> (and it even contains a few unrelated structs), so we cannot include it
> without _GNU_SOURCE.
>
> It might be possible to include it only for _GNU_SOURCE, but there are a
> lot of things in , so that does not seem to be particularly
> advisable.

In this patch RENAME_* is removed to a separated header file that
conforms the standards and therefore is suitable for inclusion by glibc.

v2:
 - rename dedicated file to 'rename-flags.h', as requested by Florian.

Signed-off-by: Yury Norov 
---
 include/uapi/linux/fs.h   |  4 +---
 include/uapi/linux/rename-flags.h | 12 
 2 files changed, 13 insertions(+), 3 deletions(-)
 create mode 100644 include/uapi/linux/rename-flags.h

diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 73e01918f996..34c308203746 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -39,9 +39,7 @@
 #define SEEK_HOLE  4   /* seek to the next hole */
 #define SEEK_MAX   SEEK_HOLE
 
-#define RENAME_NOREPLACE   (1 << 0)/* Don't overwrite target */
-#define RENAME_EXCHANGE(1 << 1)/* Exchange source and 
dest */
-#define RENAME_WHITEOUT(1 << 2)/* Whiteout source */
+#include 
 
 struct file_clone_range {
__s64 src_fd;
diff --git a/include/uapi/linux/rename-flags.h 
b/include/uapi/linux/rename-flags.h
new file mode 100644
index ..7178f0565657
--- /dev/null
+++ b/include/uapi/linux/rename-flags.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_RENAME_H
+#define _UAPI_LINUX_RENAME_H
+
+/*
+ * Definitions for rename syscall family.
+ */
+#define RENAME_NOREPLACE   (1 << 0)/* Don't overwrite target */
+#define RENAME_EXCHANGE(1 << 1)/* Exchange source and 
dest */
+#define RENAME_WHITEOUT(1 << 2)/* Whiteout source */
+
+#endif /* _UAPI_LINUX_RENAME_H */
-- 
2.17.1

Re: Applied "ASoC: pcm3060: Add DT property for single-ended output" to the asoc tree

[Kirill Marinushkin]

Hello Mark,

Thank you for applying this patch series.

I think you forgot one patch in the series: patch [1] is a documentation for
patch [2]. It has a different naming scheme, because that's how the document [3]
recommends. That's why it was not obvious that they relate to each other.

Document [3] also says:

> The Documentation/ portion of the patch should come in the series before
> the code implementing the binding.

Therefore, could you to apply patch [1] to the same branch as [2]?

Best Regards,
Kirill

[1] [PATCH v2 1/3] dt-bindings: sound: Add documentation for pcm3060 property
out-single-ended
[2] [PATCH v2 2/3] ASoC: pcm3060: Add DT property for single-ended output
[3] Documentation/devicetree/bindings/submitting-patches.txt

On 11/14/18 01:37, Mark Brown wrote:
> The patch
> 
>ASoC: pcm3060: Add DT property for single-ended output
> 
> has been applied to the asoc tree at
> 
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
> 
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.  
> 
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
> 
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
> 
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
> 
> Thanks,
> Mark
> 
> From b1cbde8fb287f4fd3493ca4167efee344c3e Mon Sep 17 00:00:00 2001
> From: Kirill Marinushkin 
> Date: Mon, 12 Nov 2018 08:08:33 +0100
> Subject: [PATCH] ASoC: pcm3060: Add DT property for single-ended output
> 
> DAC output may be differential (default) or single-ended.
> 
> Signed-off-by: Kirill Marinushkin 
> Signed-off-by: Mark Brown 
> ---
>  sound/soc/codecs/pcm3060.c | 14 ++
>  sound/soc/codecs/pcm3060.h |  1 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/sound/soc/codecs/pcm3060.c b/sound/soc/codecs/pcm3060.c
> index 771b46e1974b..1dd851a7b43b 100644
> --- a/sound/soc/codecs/pcm3060.c
> +++ b/sound/soc/codecs/pcm3060.c
> @@ -270,9 +270,23 @@ EXPORT_SYMBOL(pcm3060_regmap);
>  
>  /* device */
>  
> +static void pcm3060_parse_dt(const struct device_node *np,
> +  struct pcm3060_priv *priv)
> +{
> + priv->out_se = of_property_read_bool(np, "ti,out-single-ended");
> +}
> +
>  int pcm3060_probe(struct device *dev)
>  {
>   int rc;
> + struct pcm3060_priv *priv = dev_get_drvdata(dev);
> +
> + if (dev->of_node)
> + pcm3060_parse_dt(dev->of_node, priv);
> +
> + if (priv->out_se)
> + regmap_update_bits(priv->regmap, PCM3060_REG64,
> +PCM3060_REG_SE, PCM3060_REG_SE);
>  
>   rc = devm_snd_soc_register_component(dev, _soc_comp_driver,
>pcm3060_dai,
> diff --git a/sound/soc/codecs/pcm3060.h b/sound/soc/codecs/pcm3060.h
> index fd89a68aa8a7..c895cf40ee10 100644
> --- a/sound/soc/codecs/pcm3060.h
> +++ b/sound/soc/codecs/pcm3060.h
> @@ -25,6 +25,7 @@ struct pcm3060_priv_dai {
>  struct pcm3060_priv {
>   struct regmap *regmap;
>   struct pcm3060_priv_dai dai[PCM3060_DAI_IDS_NUM];
> + u8 out_se: 1;
>  };
>  
>  int pcm3060_probe(struct device *dev);
> 

Re: Applied "ASoC: pcm3060: Add DT property for single-ended output" to the asoc tree

[Kirill Marinushkin]

Hello Mark,

Thank you for applying this patch series.

I think you forgot one patch in the series: patch [1] is a documentation for
patch [2]. It has a different naming scheme, because that's how the document [3]
recommends. That's why it was not obvious that they relate to each other.

Document [3] also says:

> The Documentation/ portion of the patch should come in the series before
> the code implementing the binding.

Therefore, could you to apply patch [1] to the same branch as [2]?

Best Regards,
Kirill

[1] [PATCH v2 1/3] dt-bindings: sound: Add documentation for pcm3060 property
out-single-ended
[2] [PATCH v2 2/3] ASoC: pcm3060: Add DT property for single-ended output
[3] Documentation/devicetree/bindings/submitting-patches.txt

On 11/14/18 01:37, Mark Brown wrote:
> The patch
> 
>ASoC: pcm3060: Add DT property for single-ended output
> 
> has been applied to the asoc tree at
> 
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
> 
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.  
> 
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
> 
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
> 
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
> 
> Thanks,
> Mark
> 
> From b1cbde8fb287f4fd3493ca4167efee344c3e Mon Sep 17 00:00:00 2001
> From: Kirill Marinushkin 
> Date: Mon, 12 Nov 2018 08:08:33 +0100
> Subject: [PATCH] ASoC: pcm3060: Add DT property for single-ended output
> 
> DAC output may be differential (default) or single-ended.
> 
> Signed-off-by: Kirill Marinushkin 
> Signed-off-by: Mark Brown 
> ---
>  sound/soc/codecs/pcm3060.c | 14 ++
>  sound/soc/codecs/pcm3060.h |  1 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/sound/soc/codecs/pcm3060.c b/sound/soc/codecs/pcm3060.c
> index 771b46e1974b..1dd851a7b43b 100644
> --- a/sound/soc/codecs/pcm3060.c
> +++ b/sound/soc/codecs/pcm3060.c
> @@ -270,9 +270,23 @@ EXPORT_SYMBOL(pcm3060_regmap);
>  
>  /* device */
>  
> +static void pcm3060_parse_dt(const struct device_node *np,
> +  struct pcm3060_priv *priv)
> +{
> + priv->out_se = of_property_read_bool(np, "ti,out-single-ended");
> +}
> +
>  int pcm3060_probe(struct device *dev)
>  {
>   int rc;
> + struct pcm3060_priv *priv = dev_get_drvdata(dev);
> +
> + if (dev->of_node)
> + pcm3060_parse_dt(dev->of_node, priv);
> +
> + if (priv->out_se)
> + regmap_update_bits(priv->regmap, PCM3060_REG64,
> +PCM3060_REG_SE, PCM3060_REG_SE);
>  
>   rc = devm_snd_soc_register_component(dev, _soc_comp_driver,
>pcm3060_dai,
> diff --git a/sound/soc/codecs/pcm3060.h b/sound/soc/codecs/pcm3060.h
> index fd89a68aa8a7..c895cf40ee10 100644
> --- a/sound/soc/codecs/pcm3060.h
> +++ b/sound/soc/codecs/pcm3060.h
> @@ -25,6 +25,7 @@ struct pcm3060_priv_dai {
>  struct pcm3060_priv {
>   struct regmap *regmap;
>   struct pcm3060_priv_dai dai[PCM3060_DAI_IDS_NUM];
> + u8 out_se: 1;
>  };
>  
>  int pcm3060_probe(struct device *dev);
> 

Re: UBSAN: Undefined behaviour in mm/page_alloc.c

[Michal Hocko]

On Tue 13-11-18 15:29:41, Andrew Morton wrote:
[...]
> But do we really need to do this?  Are there any other known potential
> callsites?

The main point is that the code as it stands is quite fragile, isn't it?
Fixing up all the callers is possible but can you actually think of a
reason why this would cause any measurable effect in the fast path?
The order argument is usually in a register and comparing it to a number
with unlikely branch should be hardly something visible.

Besides that we are talking few cycles at best compared to a fragile
code that got broken by accident without anybody noticing for quite some
time.

I vote for the maintainability over few cycles here. Should anybody find
this measurable we can rework the code by other means.

-- 
Michal Hocko
SUSE Labs

Re: UBSAN: Undefined behaviour in mm/page_alloc.c

[Michal Hocko]

On Tue 13-11-18 15:29:41, Andrew Morton wrote:
[...]
> But do we really need to do this?  Are there any other known potential
> callsites?

The main point is that the code as it stands is quite fragile, isn't it?
Fixing up all the callers is possible but can you actually think of a
reason why this would cause any measurable effect in the fast path?
The order argument is usually in a register and comparing it to a number
with unlikely branch should be hardly something visible.

Besides that we are talking few cycles at best compared to a fragile
code that got broken by accident without anybody noticing for quite some
time.

I vote for the maintainability over few cycles here. Should anybody find
this measurable we can rework the code by other means.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] zram: close udev startup race condition as default groups

[Hannes Reinecke]

On 11/14/18 6:52 AM, Minchan Kim wrote:

commit fef912bf860e upstream.
commit 98af4d4df889 upstream.

I got a report from Howard Chen that he saw zram and sysfs race(ie,
zram block device file is created but sysfs for it isn't yet)
when he tried to create new zram devices via hotadd knob.

v4.20 kernel fixes it by [1, 2] but it's too large size to merge
into -stable so this patch fixes the problem by registering defualt
group by Greg KH's approach[3].

This patch should be applied to every stable tree [3.16+] currently
existing from kernel.org because the problem was introduced at 2.6.37
by [4].

[1] fef912bf860e, block: genhd: add 'groups' argument to device_add_disk
[2] 98af4d4df889, zram: register default groups with device_add_disk()
[3] http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/
[4] 33863c21e69e9, Staging: zram: Replace ioctls with sysfs interface

Cc: Sergey Senozhatsky 
Cc: Hannes Reinecke 
Tested-by: Howard Chen 
Signed-off-by: Minchan Kim 
---
  drivers/block/zram/zram_drv.c | 26 ++
  1 file changed, 6 insertions(+), 20 deletions(-)

Actually, I have a similar patch for NVMe in older revisions, so maybe I 
should push it to -stable, too.


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.com  +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH] zram: close udev startup race condition as default groups

[Hannes Reinecke]

On 11/14/18 6:52 AM, Minchan Kim wrote:

commit fef912bf860e upstream.
commit 98af4d4df889 upstream.

I got a report from Howard Chen that he saw zram and sysfs race(ie,
zram block device file is created but sysfs for it isn't yet)
when he tried to create new zram devices via hotadd knob.

v4.20 kernel fixes it by [1, 2] but it's too large size to merge
into -stable so this patch fixes the problem by registering defualt
group by Greg KH's approach[3].

This patch should be applied to every stable tree [3.16+] currently
existing from kernel.org because the problem was introduced at 2.6.37
by [4].

[1] fef912bf860e, block: genhd: add 'groups' argument to device_add_disk
[2] 98af4d4df889, zram: register default groups with device_add_disk()
[3] http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/
[4] 33863c21e69e9, Staging: zram: Replace ioctls with sysfs interface

Cc: Sergey Senozhatsky 
Cc: Hannes Reinecke 
Tested-by: Howard Chen 
Signed-off-by: Minchan Kim 
---
  drivers/block/zram/zram_drv.c | 26 ++
  1 file changed, 6 insertions(+), 20 deletions(-)

Actually, I have a similar patch for NVMe in older revisions, so maybe I 
should push it to -stable, too.


Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.com  +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v1 3/4] Bluetooth: hci_qca: clear HCI_QUIRK_RESET_ON_CLOSE flag

[Balakrishna Godavarthi]

Hi Matthias,

On 2018-11-14 07:44, Matthias Kaehlcke wrote:

On Tue, Nov 06, 2018 at 06:44:07PM +0530, Balakrishna Godavarthi wrote:

Hi Marcel,

On 2018-11-06 18:32, Marcel Holtmann wrote:
> Hi Balakrishna,
>
> > > > During hci down we are sending reset command to chip, which
> > > > is not required for wcn3990, as hdev->shutdown() will turn off the
> > > > regulators.
> > > > Signed-off-by: Balakrishna Godavarthi 
> > > > ---
> > > > drivers/bluetooth/hci_qca.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > > diff --git a/drivers/bluetooth/hci_qca.c
> > > > b/drivers/bluetooth/hci_qca.c
> > > > index 8301663f0004..97b57e0f4725 100644
> > > > --- a/drivers/bluetooth/hci_qca.c
> > > > +++ b/drivers/bluetooth/hci_qca.c
> > > > @@ -1190,6 +1190,7 @@ static int qca_setup(struct hci_uart *hu)
> > > >  */
> > > > set_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, >quirks);
> > > > set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, >quirks);
> > > > +   clear_bit(HCI_QUIRK_RESET_ON_CLOSE, >quirks);


This patch doesn't apply cleanly against bluetooth-next, looks like
you have the unrelated "Bluetooth: hci_qca: Set
HCI_QUIRK_USE_BDADDR_PROPERTY for wcn3990"
(https://lore.kernel.org/patchwork/patch/1004372/) in your tree.

[Bala]: this patch is on top of 
https://lore.kernel.org/patchwork/patch/1004372/.

will remove the dependency and update the patch.


> > > > hu->hdev->shutdown = qca_power_off;
> > > > ret = qca_wcn3990_init(hu);
> > > > if (ret)
> > > I am pretty certain that you didn’t want this quirk:
> > >/* When this quirk is set, the HCI Reset command is send when
> > > * closing the transport instead of when opening it.
> > > This quirk is for Bluetooth 1.0b devices where the HCI_Reset behavior
> > > was not clear or for devices that actually misbehave with the initial
> > > HCI_Reset.
> > > In addition, you commit message is totally misleading. That is not
> > > what is happening with this quirk.
> > > Regards
> > > Marcel
> >
> > My intention was reset command is not required when we do an hci down.
> > this is because of hdev->shutdown will turn off the regulators.
> > It is like turning off the chip. sending reset command after turning
> > off the chip is not required.
> >
> > I understand the usage of the quirk, will update the commit text.
>
> you are papering over the issue. Actually
> hci_serdev.c:hci_uart_register_device() is the culprit with the legacy
> code copied over from hci_ldisc.c:hci_uart_register_dev(). I think
> there is no point doing all this legacy line discipline quirk handling
> until it is really needed. The serdev drivers are all for recent
> hardware.
>
> That said, having moved over to a btuart.c approach and killed the
> whole hci_serdev.c thing would have been a lot better here. You will
> keep running in weird situations where 18 year old code keeps
> surprising you.

[Bala]: even i feel the same. they are lot such kind of HACK's we need 
to do

with current arch.
when can we expect btuart.c merged to bt-next. i think having 
btuart

will helps us to have the control of
vendor porto's call's like in btusb.c


btuart was initially part of the 'add support for Bluetooth on MT7622
SoC' series (https://lore.kernel.org/patchwork/patch/960806/), but was
dropped with v6
(https://lore.kernel.org/patchwork/project/lkml/list/?series=360046)
upon Marcel's request: 'Frankly I prefer to keep the btuart.c driver
for drivers that really just use H:4 as transport protocol. If the
protocol is only H:4 alike and has extra headers, then it should be a
separate driver.' 
(https://lore.kernel.org/patchwork/patch/960806/#1148426).


Cheers

Matthias


[Bala]: currently our main moto is to make this driver to be stable for 
both rome and wcn3990.
we will look into working on btuart.c type driver for future 
qualcomm BT devices.


--
Regards
Balakrishna.

Re: [PATCH v1 3/4] Bluetooth: hci_qca: clear HCI_QUIRK_RESET_ON_CLOSE flag

[Balakrishna Godavarthi]

Hi Matthias,

On 2018-11-14 07:44, Matthias Kaehlcke wrote:

On Tue, Nov 06, 2018 at 06:44:07PM +0530, Balakrishna Godavarthi wrote:

Hi Marcel,

On 2018-11-06 18:32, Marcel Holtmann wrote:
> Hi Balakrishna,
>
> > > > During hci down we are sending reset command to chip, which
> > > > is not required for wcn3990, as hdev->shutdown() will turn off the
> > > > regulators.
> > > > Signed-off-by: Balakrishna Godavarthi 
> > > > ---
> > > > drivers/bluetooth/hci_qca.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > > diff --git a/drivers/bluetooth/hci_qca.c
> > > > b/drivers/bluetooth/hci_qca.c
> > > > index 8301663f0004..97b57e0f4725 100644
> > > > --- a/drivers/bluetooth/hci_qca.c
> > > > +++ b/drivers/bluetooth/hci_qca.c
> > > > @@ -1190,6 +1190,7 @@ static int qca_setup(struct hci_uart *hu)
> > > >  */
> > > > set_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, >quirks);
> > > > set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, >quirks);
> > > > +   clear_bit(HCI_QUIRK_RESET_ON_CLOSE, >quirks);


This patch doesn't apply cleanly against bluetooth-next, looks like
you have the unrelated "Bluetooth: hci_qca: Set
HCI_QUIRK_USE_BDADDR_PROPERTY for wcn3990"
(https://lore.kernel.org/patchwork/patch/1004372/) in your tree.

[Bala]: this patch is on top of 
https://lore.kernel.org/patchwork/patch/1004372/.

will remove the dependency and update the patch.


> > > > hu->hdev->shutdown = qca_power_off;
> > > > ret = qca_wcn3990_init(hu);
> > > > if (ret)
> > > I am pretty certain that you didn’t want this quirk:
> > >/* When this quirk is set, the HCI Reset command is send when
> > > * closing the transport instead of when opening it.
> > > This quirk is for Bluetooth 1.0b devices where the HCI_Reset behavior
> > > was not clear or for devices that actually misbehave with the initial
> > > HCI_Reset.
> > > In addition, you commit message is totally misleading. That is not
> > > what is happening with this quirk.
> > > Regards
> > > Marcel
> >
> > My intention was reset command is not required when we do an hci down.
> > this is because of hdev->shutdown will turn off the regulators.
> > It is like turning off the chip. sending reset command after turning
> > off the chip is not required.
> >
> > I understand the usage of the quirk, will update the commit text.
>
> you are papering over the issue. Actually
> hci_serdev.c:hci_uart_register_device() is the culprit with the legacy
> code copied over from hci_ldisc.c:hci_uart_register_dev(). I think
> there is no point doing all this legacy line discipline quirk handling
> until it is really needed. The serdev drivers are all for recent
> hardware.
>
> That said, having moved over to a btuart.c approach and killed the
> whole hci_serdev.c thing would have been a lot better here. You will
> keep running in weird situations where 18 year old code keeps
> surprising you.

[Bala]: even i feel the same. they are lot such kind of HACK's we need 
to do

with current arch.
when can we expect btuart.c merged to bt-next. i think having 
btuart

will helps us to have the control of
vendor porto's call's like in btusb.c


btuart was initially part of the 'add support for Bluetooth on MT7622
SoC' series (https://lore.kernel.org/patchwork/patch/960806/), but was
dropped with v6
(https://lore.kernel.org/patchwork/project/lkml/list/?series=360046)
upon Marcel's request: 'Frankly I prefer to keep the btuart.c driver
for drivers that really just use H:4 as transport protocol. If the
protocol is only H:4 alike and has extra headers, then it should be a
separate driver.' 
(https://lore.kernel.org/patchwork/patch/960806/#1148426).


Cheers

Matthias


[Bala]: currently our main moto is to make this driver to be stable for 
both rome and wcn3990.
we will look into working on btuart.c type driver for future 
qualcomm BT devices.


--
Regards
Balakrishna.

Re: [PATCH v6 0/2] mtd: rawnand: meson: add Amlogic NAND driver support

[Jianxin Pan]

Hi Miquel,

I sorry to miss you in the CC list before, I will CC you in the next version.
Thank you very much.

On 2018/11/12 4:57, Miquel Raynal wrote:
> Hi Jianxin,
> 
> Jianxin Pan  wrote on Fri, 2 Nov 2018 00:42:19
> +0800:
> 
>> These two patches try to add initial NAND driver support for Amlogic Meson
>> SoCs, current it has been tested on GXL(p212) and AXG(s400) platform.
>>
> 
> Would you mind Cc:'ing me when you send NAND related patches? Otherwise
> there is a chance that it will take ages before I notice your series
> in the middle of the MTD patches flo
> 
> Thanks,
> Miquèl
> 
> .
> 

Re: [PATCH v6 0/2] mtd: rawnand: meson: add Amlogic NAND driver support

[Jianxin Pan]

Hi Miquel,

I sorry to miss you in the CC list before, I will CC you in the next version.
Thank you very much.

On 2018/11/12 4:57, Miquel Raynal wrote:
> Hi Jianxin,
> 
> Jianxin Pan  wrote on Fri, 2 Nov 2018 00:42:19
> +0800:
> 
>> These two patches try to add initial NAND driver support for Amlogic Meson
>> SoCs, current it has been tested on GXL(p212) and AXG(s400) platform.
>>
> 
> Would you mind Cc:'ing me when you send NAND related patches? Otherwise
> there is a chance that it will take ages before I notice your series
> in the middle of the MTD patches flo
> 
> Thanks,
> Miquèl
> 
> .
> 

Re: [PATCH v1 2/4] Bluetooth: hci_qca: Pull RTS line high for baudrate change command

[Balakrishna Godavarthi]

Hi Matthias,

On 2018-11-14 07:25, Matthias Kaehlcke wrote:

On Tue, Nov 06, 2018 at 05:35:26PM +0530, Balakrishna Godavarthi wrote:

This patch will pull the RTS line high instead of turning off the
flow control, while changing baudrate of host and chip.


Please don't only describe what is changed, but also why this change
is necessary.

IIUC the BT chip honors flow control during baudrate changes, however
it sometimes sends 'garbage' which results in "Bluetooth: hci0: Frame
reassembly failed (-84)" messages.



[Bala]: will update the commit text.


Signed-off-by: Balakrishna Godavarthi 
---
 drivers/bluetooth/hci_qca.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 051f081d1835..8301663f0004 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -963,7 +963,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, 
uint8_t baudrate)

struct hci_uart *hu = hci_get_drvdata(hdev);
struct qca_data *qca = hu->priv;
struct sk_buff *skb;
-   struct qca_serdev *qcadev;
u8 cmd[] = { 0x01, 0x48, 0xFC, 0x01, 0x00 };

if (baudrate > QCA_BAUDRATE_320)
@@ -977,13 +976,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, 
uint8_t baudrate)

return -ENOMEM;
}

-   /* Disabling hardware flow control is mandatory while
-* sending change baudrate request to wcn3990 SoC.
-*/
-   qcadev = serdev_device_get_drvdata(hu->serdev);
-   if (qcadev->btsoc_type == QCA_WCN3990)
-   hci_uart_set_flow_control(hu, true);
-
/* Assign commands to change baudrate and packet type. */
skb_put_data(skb, cmd, sizeof(cmd));
hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
@@ -999,9 +991,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, 
uint8_t baudrate)

schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS));
set_current_state(TASK_RUNNING);

-   if (qcadev->btsoc_type == QCA_WCN3990)
-   hci_uart_set_flow_control(hu, false);
-
return 0;
 }

@@ -1086,6 +1075,7 @@ static int qca_check_speeds(struct hci_uart *hu)
 static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type 
speed_type)

 {
unsigned int speed, qca_baudrate;
+   struct qca_serdev *qcadev;
int ret;

if (speed_type == QCA_INIT_SPEED) {
@@ -1097,6 +1087,14 @@ static int qca_set_speed(struct hci_uart *hu, 
enum qca_speed_type speed_type)

if (!speed)
return 0;

+   /* Pulling RTS line to high is mandatory while sending change
+* baudrate request to SoC and also while setting the host
+* baudrate.
+*/


Instead of just stating that this is 'mandatory' explain why it is
needed. Also better say 'Deassert RTS' instead of the more lower level
'Pulling RTS line to high'. It could be something like 'Deassert RTS
to prevent the BT controller from sending garbage during the baudrate
change.'



[Bala]: will update the comment.


+   qcadev = serdev_device_get_drvdata(hu->serdev);
+   if (qcadev->btsoc_type == QCA_WCN3990)
+   serdev_device_set_rts(hu->serdev, false);
+
qca_baudrate = qca_get_baudrate_value(speed);
bt_dev_dbg(hu->hdev, "Set UART speed to %d", speed);
ret = qca_set_baudrate(hu->hdev, qca_baudrate);
@@ -1104,6 +1102,9 @@ static int qca_set_speed(struct hci_uart *hu, 
enum qca_speed_type speed_type)

return ret;

host_set_baudrate(hu, speed);
+
+   if (qcadev->btsoc_type == QCA_WCN3990)
+   serdev_device_set_rts(hu->serdev, true);
}

return 0;


Tested-by: Matthias Kaehlcke 


Thanks for testing.

--
Regards
Balakrishna.

Re: [PATCH v1 2/4] Bluetooth: hci_qca: Pull RTS line high for baudrate change command

[Balakrishna Godavarthi]

Hi Matthias,

On 2018-11-14 07:25, Matthias Kaehlcke wrote:

On Tue, Nov 06, 2018 at 05:35:26PM +0530, Balakrishna Godavarthi wrote:

This patch will pull the RTS line high instead of turning off the
flow control, while changing baudrate of host and chip.


Please don't only describe what is changed, but also why this change
is necessary.

IIUC the BT chip honors flow control during baudrate changes, however
it sometimes sends 'garbage' which results in "Bluetooth: hci0: Frame
reassembly failed (-84)" messages.



[Bala]: will update the commit text.


Signed-off-by: Balakrishna Godavarthi 
---
 drivers/bluetooth/hci_qca.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 051f081d1835..8301663f0004 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -963,7 +963,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, 
uint8_t baudrate)

struct hci_uart *hu = hci_get_drvdata(hdev);
struct qca_data *qca = hu->priv;
struct sk_buff *skb;
-   struct qca_serdev *qcadev;
u8 cmd[] = { 0x01, 0x48, 0xFC, 0x01, 0x00 };

if (baudrate > QCA_BAUDRATE_320)
@@ -977,13 +976,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, 
uint8_t baudrate)

return -ENOMEM;
}

-   /* Disabling hardware flow control is mandatory while
-* sending change baudrate request to wcn3990 SoC.
-*/
-   qcadev = serdev_device_get_drvdata(hu->serdev);
-   if (qcadev->btsoc_type == QCA_WCN3990)
-   hci_uart_set_flow_control(hu, true);
-
/* Assign commands to change baudrate and packet type. */
skb_put_data(skb, cmd, sizeof(cmd));
hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
@@ -999,9 +991,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, 
uint8_t baudrate)

schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS));
set_current_state(TASK_RUNNING);

-   if (qcadev->btsoc_type == QCA_WCN3990)
-   hci_uart_set_flow_control(hu, false);
-
return 0;
 }

@@ -1086,6 +1075,7 @@ static int qca_check_speeds(struct hci_uart *hu)
 static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type 
speed_type)

 {
unsigned int speed, qca_baudrate;
+   struct qca_serdev *qcadev;
int ret;

if (speed_type == QCA_INIT_SPEED) {
@@ -1097,6 +1087,14 @@ static int qca_set_speed(struct hci_uart *hu, 
enum qca_speed_type speed_type)

if (!speed)
return 0;

+   /* Pulling RTS line to high is mandatory while sending change
+* baudrate request to SoC and also while setting the host
+* baudrate.
+*/


Instead of just stating that this is 'mandatory' explain why it is
needed. Also better say 'Deassert RTS' instead of the more lower level
'Pulling RTS line to high'. It could be something like 'Deassert RTS
to prevent the BT controller from sending garbage during the baudrate
change.'



[Bala]: will update the comment.


+   qcadev = serdev_device_get_drvdata(hu->serdev);
+   if (qcadev->btsoc_type == QCA_WCN3990)
+   serdev_device_set_rts(hu->serdev, false);
+
qca_baudrate = qca_get_baudrate_value(speed);
bt_dev_dbg(hu->hdev, "Set UART speed to %d", speed);
ret = qca_set_baudrate(hu->hdev, qca_baudrate);
@@ -1104,6 +1102,9 @@ static int qca_set_speed(struct hci_uart *hu, 
enum qca_speed_type speed_type)

return ret;

host_set_baudrate(hu, speed);
+
+   if (qcadev->btsoc_type == QCA_WCN3990)
+   serdev_device_set_rts(hu->serdev, true);
}

return 0;


Tested-by: Matthias Kaehlcke 


Thanks for testing.

--
Regards
Balakrishna.

Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until_sent() for power pulses

[Balakrishna Godavarthi]

Hi Matthias,

On 2018-11-14 05:47, Matthias Kaehlcke wrote:

On Tue, Nov 06, 2018 at 05:35:25PM +0530, Balakrishna Godavarthi wrote:

wcn3990 requires a power pulse to turn ON/OFF along with
regulators. Sometimes we are observing the power pulses are sent
out with some time delay, due to queuing these commands. This is
causing synchronization issues with chip, which intern delay the
chip setup or may end up with communication issues.

Signed-off-by: Balakrishna Godavarthi 
---
 drivers/bluetooth/hci_qca.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index f72ded4ec9ae..051f081d1835 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1016,8 +1016,7 @@ static inline void host_set_baudrate(struct 
hci_uart *hu, unsigned int speed)

 static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
 {
struct hci_uart *hu = hci_get_drvdata(hdev);
-   struct qca_data *qca = hu->priv;
-   struct sk_buff *skb;
+   int ret;

/* These power pulses are single byte command which are sent
 * at required baudrate to wcn3990. On wcn3990, we have an external
@@ -1030,18 +1029,14 @@ static int qca_send_power_pulse(struct hci_dev 
*hdev, u8 cmd)

 * sending power pulses to SoC.
 */
bt_dev_dbg(hdev, "sending power pulse %02x to SoC", cmd);
-
-   skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
-   if (!skb)
-   return -ENOMEM;
-
hci_uart_set_flow_control(hu, true);
+   ret = serdev_device_write(hu->serdev, , sizeof(cmd), 0);
+   if (ret < 0) {
+   bt_dev_err(hdev, "failed to send power pulse %02x to SoC", cmd);
+   return ret;
+   }

-   skb_put_u8(skb, cmd);
-   hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
-
-   skb_queue_tail(>txq, skb);
-   hci_uart_tx_wakeup(hu);
+   serdev_device_wait_until_sent(hu->serdev, 0);

/* Wait for 100 uS for SoC to settle down */
usleep_range(100, 200);


Is the delay still needed now that we wait for the pulse to be sent? I
didn't observe any problems without it in a few dozens of iterations.


[Bala]: chip require some time to boot up
so this delay will helps us to be in sync with the chip. for now
we will go with this delay, if really required we can change 
100us to some where

around 10us.

@@ -1283,7 +1278,8 @@ static void qca_power_shutdown(struct hci_uart 
*hu)


host_set_baudrate(hu, 2400);
hci_uart_set_flow_control(hu, true);
-   serdev_device_write_buf(serdev, , sizeof(cmd));
+   serdev_device_write(serdev, , sizeof(cmd), 0);
+   serdev_device_wait_until_sent(serdev, 0);
hci_uart_set_flow_control(hu, false);


You could call qca_send_power_pulse(hdev, QCA_WCN3990_POWEROFF_PULSE)
instead, as an earlier patch set did before skbs were used to send the
power pulse.



[Bala]: will update.


You can also consider to set the baudrate in qca_send_power_pulse()
depending on the power pulse. On the plus side this would reduce a bit
of clutter in the callers of qca_send_power_pulse(), on the negative
side it would be harder to follow when baudrate changes occur (not
sure this is a problem). Up to you, just an idea.

[Bala]:  moving bd change request to power_pulse has both plus & minus 
side.
 but my opinion is let us we leave qca_send_power_pulse() to be 
generic
 might be feature chip will use the same function with an 
different bd.



Thanks

Matthias


--
Regards
Balakrishna.

Re: [PATCH v1 1/4] Bluetooth: hci_qca: use wait_until_sent() for power pulses

[Balakrishna Godavarthi]

Hi Matthias,

On 2018-11-14 05:47, Matthias Kaehlcke wrote:

On Tue, Nov 06, 2018 at 05:35:25PM +0530, Balakrishna Godavarthi wrote:

wcn3990 requires a power pulse to turn ON/OFF along with
regulators. Sometimes we are observing the power pulses are sent
out with some time delay, due to queuing these commands. This is
causing synchronization issues with chip, which intern delay the
chip setup or may end up with communication issues.

Signed-off-by: Balakrishna Godavarthi 
---
 drivers/bluetooth/hci_qca.c | 22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index f72ded4ec9ae..051f081d1835 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1016,8 +1016,7 @@ static inline void host_set_baudrate(struct 
hci_uart *hu, unsigned int speed)

 static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
 {
struct hci_uart *hu = hci_get_drvdata(hdev);
-   struct qca_data *qca = hu->priv;
-   struct sk_buff *skb;
+   int ret;

/* These power pulses are single byte command which are sent
 * at required baudrate to wcn3990. On wcn3990, we have an external
@@ -1030,18 +1029,14 @@ static int qca_send_power_pulse(struct hci_dev 
*hdev, u8 cmd)

 * sending power pulses to SoC.
 */
bt_dev_dbg(hdev, "sending power pulse %02x to SoC", cmd);
-
-   skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
-   if (!skb)
-   return -ENOMEM;
-
hci_uart_set_flow_control(hu, true);
+   ret = serdev_device_write(hu->serdev, , sizeof(cmd), 0);
+   if (ret < 0) {
+   bt_dev_err(hdev, "failed to send power pulse %02x to SoC", cmd);
+   return ret;
+   }

-   skb_put_u8(skb, cmd);
-   hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
-
-   skb_queue_tail(>txq, skb);
-   hci_uart_tx_wakeup(hu);
+   serdev_device_wait_until_sent(hu->serdev, 0);

/* Wait for 100 uS for SoC to settle down */
usleep_range(100, 200);


Is the delay still needed now that we wait for the pulse to be sent? I
didn't observe any problems without it in a few dozens of iterations.


[Bala]: chip require some time to boot up
so this delay will helps us to be in sync with the chip. for now
we will go with this delay, if really required we can change 
100us to some where

around 10us.

@@ -1283,7 +1278,8 @@ static void qca_power_shutdown(struct hci_uart 
*hu)


host_set_baudrate(hu, 2400);
hci_uart_set_flow_control(hu, true);
-   serdev_device_write_buf(serdev, , sizeof(cmd));
+   serdev_device_write(serdev, , sizeof(cmd), 0);
+   serdev_device_wait_until_sent(serdev, 0);
hci_uart_set_flow_control(hu, false);


You could call qca_send_power_pulse(hdev, QCA_WCN3990_POWEROFF_PULSE)
instead, as an earlier patch set did before skbs were used to send the
power pulse.



[Bala]: will update.


You can also consider to set the baudrate in qca_send_power_pulse()
depending on the power pulse. On the plus side this would reduce a bit
of clutter in the callers of qca_send_power_pulse(), on the negative
side it would be harder to follow when baudrate changes occur (not
sure this is a problem). Up to you, just an idea.

[Bala]:  moving bd change request to power_pulse has both plus & minus 
side.
 but my opinion is let us we leave qca_send_power_pulse() to be 
generic
 might be feature chip will use the same function with an 
different bd.



Thanks

Matthias


--
Regards
Balakrishna.

RE: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

[Doug Smythies]

On 2018.11.08 00:00 Rafael J. Wysocki wrote:
> On Wednesday, November 7, 2018 6:04:12 PM CET Doug Smythies wrote:
>> On 2018.11.04 08:31 Rafael J. Wysocki wrote:

...[snip]...
>> The results are:
>> http://fast.smythies.com/linux-pm/k420/k420-dbench-teo3.htm
>> http://fast.smythies.com/linux-pm/k420/histo_compare.htm

...[snip]...

>> There are some odd long idle durations with TEOv3 for idle
>> states 1, 2, and 3 that I'll watch for with v4 testing.
>
> That unfortunately is a result of bugs in the v4 (and v2 - v3 too).
>
> Namely, it doesn't take the cases when the tick has been stopped already
> into account correctly.  IOW, all of the data points beyond the tick boundary
> should go into the "final" peak.
>
> I'll send a v5.

With v5 there were no long idle durations for idle states 1, 2, and 3 for
this same Phoronix dbench test.

... Doug

RE: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

[Doug Smythies]

On 2018.11.08 00:00 Rafael J. Wysocki wrote:
> On Wednesday, November 7, 2018 6:04:12 PM CET Doug Smythies wrote:
>> On 2018.11.04 08:31 Rafael J. Wysocki wrote:

...[snip]...
>> The results are:
>> http://fast.smythies.com/linux-pm/k420/k420-dbench-teo3.htm
>> http://fast.smythies.com/linux-pm/k420/histo_compare.htm

...[snip]...

>> There are some odd long idle durations with TEOv3 for idle
>> states 1, 2, and 3 that I'll watch for with v4 testing.
>
> That unfortunately is a result of bugs in the v4 (and v2 - v3 too).
>
> Namely, it doesn't take the cases when the tick has been stopped already
> into account correctly.  IOW, all of the data points beyond the tick boundary
> should go into the "final" peak.
>
> I'll send a v5.

With v5 there were no long idle durations for idle states 1, 2, and 3 for
this same Phoronix dbench test.

... Doug

Re: [PATCH v1 08/11] clk: mediatek: Add MT8183 clock support

[Nicolas Boichat]

On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu  wrote:
>
> Add MT8183 clock support, include topckgen, apmixedsys,
> infracfg, mcucfg and subsystem clocks.
>
> Signed-off-by: Weiyi Lu 
> ---
>  drivers/clk/mediatek/Kconfig   |   75 ++
>  drivers/clk/mediatek/Makefile  |   12 +
>  drivers/clk/mediatek/clk-mt8183-audio.c|  112 ++
>  drivers/clk/mediatek/clk-mt8183-cam.c  |   75 ++
>  drivers/clk/mediatek/clk-mt8183-img.c  |   75 ++
>  drivers/clk/mediatek/clk-mt8183-ipu0.c |   68 +
>  drivers/clk/mediatek/clk-mt8183-ipu1.c |   68 +
>  drivers/clk/mediatek/clk-mt8183-ipu_adl.c  |   66 +
>  drivers/clk/mediatek/clk-mt8183-ipu_conn.c |  155 +++
>  drivers/clk/mediatek/clk-mt8183-mfgcfg.c   |   66 +
>  drivers/clk/mediatek/clk-mt8183-mm.c   |  128 ++
>  drivers/clk/mediatek/clk-mt8183-vdec.c |   84 ++
>  drivers/clk/mediatek/clk-mt8183-venc.c |   71 ++
>  drivers/clk/mediatek/clk-mt8183.c  | 1334 
>  14 files changed, 2389 insertions(+)
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-audio.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-cam.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-img.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu0.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu1.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_adl.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_conn.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-mfgcfg.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-mm.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-vdec.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-venc.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183.c

Can you look at how clk-mt8173.c did this?

I think you can avoid a lot of this duplicated code and most of the
extra files by using something like:
CLK_OF_DECLARE(mtk_audio, "mediatek,mt8183-audiosys", clk_mt8183_audio_init);

Some more comments below.

> diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
> index 3dd1dab92223..5d4fd67fa259 100644
> --- a/drivers/clk/mediatek/Kconfig
> +++ b/drivers/clk/mediatek/Kconfig
> @@ -193,4 +193,79 @@ config COMMON_CLK_MT8173
> default ARCH_MEDIATEK
> ---help---
>   This driver supports MediaTek MT8173 clocks.
> +
> +config COMMON_CLK_MT8183
> +   bool "Clock driver for MediaTek MT8183"
> +   depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
> +   select COMMON_CLK_MEDIATEK
> +   default ARCH_MEDIATEK && ARM64
> +   help
> + This driver supports MediaTek MT8183 basic clocks.
> +
> +config COMMON_CLK_MT8183_AUDIOSYS
> +   bool "Clock driver for MediaTek MT8183 audiosys"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 audiosys clocks.
> +
> +config COMMON_CLK_MT8183_CAMSYS
> +   bool "Clock driver for MediaTek MT8183 camsys"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 camsys clocks.
> +
> +config COMMON_CLK_MT8183_IMGSYS
> +   bool "Clock driver for MediaTek MT8183 imgsys"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 imgsys clocks.
> +
> +config COMMON_CLK_MT8183_IPU_CORE0
> +   bool "Clock driver for MediaTek MT8183 ipu_core0"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 ipu_core0 clocks.
> +
> +config COMMON_CLK_MT8183_IPU_CORE1
> +   bool "Clock driver for MediaTek MT8183 ipu_core1"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 ipu_core1 clocks.
> +
> +config COMMON_CLK_MT8183_IPU_ADL
> +   bool "Clock driver for MediaTek MT8183 ipu_adl"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 ipu_adl clocks.
> +
> +config COMMON_CLK_MT8183_IPU_CONN
> +   bool "Clock driver for MediaTek MT8183 ipu_conn"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 ipu_conn clocks.
> +
> +config COMMON_CLK_MT8183_MFGCFG
> +   bool "Clock driver for MediaTek MT8183 mfgcfg"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 mfgcfg clocks.
> +
> +config COMMON_CLK_MT8183_MMSYS
> +   bool "Clock driver for MediaTek MT8183 mmsys"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 mmsys clocks.
> +
> +config COMMON_CLK_MT8183_VDECSYS
> +   bool "Clock driver for MediaTek MT8183 vdecsys"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 vdecsys clocks.
> +
> +config COMMON_CLK_MT8183_VENCSYS
> +   bool "Clock driver for MediaTek MT8183 vencsys"
> +   depends on COMMON_CLK_MT8183
> +   help
> + 

Re: [PATCH v1 08/11] clk: mediatek: Add MT8183 clock support

[Nicolas Boichat]

On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu  wrote:
>
> Add MT8183 clock support, include topckgen, apmixedsys,
> infracfg, mcucfg and subsystem clocks.
>
> Signed-off-by: Weiyi Lu 
> ---
>  drivers/clk/mediatek/Kconfig   |   75 ++
>  drivers/clk/mediatek/Makefile  |   12 +
>  drivers/clk/mediatek/clk-mt8183-audio.c|  112 ++
>  drivers/clk/mediatek/clk-mt8183-cam.c  |   75 ++
>  drivers/clk/mediatek/clk-mt8183-img.c  |   75 ++
>  drivers/clk/mediatek/clk-mt8183-ipu0.c |   68 +
>  drivers/clk/mediatek/clk-mt8183-ipu1.c |   68 +
>  drivers/clk/mediatek/clk-mt8183-ipu_adl.c  |   66 +
>  drivers/clk/mediatek/clk-mt8183-ipu_conn.c |  155 +++
>  drivers/clk/mediatek/clk-mt8183-mfgcfg.c   |   66 +
>  drivers/clk/mediatek/clk-mt8183-mm.c   |  128 ++
>  drivers/clk/mediatek/clk-mt8183-vdec.c |   84 ++
>  drivers/clk/mediatek/clk-mt8183-venc.c |   71 ++
>  drivers/clk/mediatek/clk-mt8183.c  | 1334 
>  14 files changed, 2389 insertions(+)
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-audio.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-cam.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-img.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu0.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu1.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_adl.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_conn.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-mfgcfg.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-mm.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-vdec.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183-venc.c
>  create mode 100644 drivers/clk/mediatek/clk-mt8183.c

Can you look at how clk-mt8173.c did this?

I think you can avoid a lot of this duplicated code and most of the
extra files by using something like:
CLK_OF_DECLARE(mtk_audio, "mediatek,mt8183-audiosys", clk_mt8183_audio_init);

Some more comments below.

> diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
> index 3dd1dab92223..5d4fd67fa259 100644
> --- a/drivers/clk/mediatek/Kconfig
> +++ b/drivers/clk/mediatek/Kconfig
> @@ -193,4 +193,79 @@ config COMMON_CLK_MT8173
> default ARCH_MEDIATEK
> ---help---
>   This driver supports MediaTek MT8173 clocks.
> +
> +config COMMON_CLK_MT8183
> +   bool "Clock driver for MediaTek MT8183"
> +   depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
> +   select COMMON_CLK_MEDIATEK
> +   default ARCH_MEDIATEK && ARM64
> +   help
> + This driver supports MediaTek MT8183 basic clocks.
> +
> +config COMMON_CLK_MT8183_AUDIOSYS
> +   bool "Clock driver for MediaTek MT8183 audiosys"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 audiosys clocks.
> +
> +config COMMON_CLK_MT8183_CAMSYS
> +   bool "Clock driver for MediaTek MT8183 camsys"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 camsys clocks.
> +
> +config COMMON_CLK_MT8183_IMGSYS
> +   bool "Clock driver for MediaTek MT8183 imgsys"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 imgsys clocks.
> +
> +config COMMON_CLK_MT8183_IPU_CORE0
> +   bool "Clock driver for MediaTek MT8183 ipu_core0"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 ipu_core0 clocks.
> +
> +config COMMON_CLK_MT8183_IPU_CORE1
> +   bool "Clock driver for MediaTek MT8183 ipu_core1"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 ipu_core1 clocks.
> +
> +config COMMON_CLK_MT8183_IPU_ADL
> +   bool "Clock driver for MediaTek MT8183 ipu_adl"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 ipu_adl clocks.
> +
> +config COMMON_CLK_MT8183_IPU_CONN
> +   bool "Clock driver for MediaTek MT8183 ipu_conn"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 ipu_conn clocks.
> +
> +config COMMON_CLK_MT8183_MFGCFG
> +   bool "Clock driver for MediaTek MT8183 mfgcfg"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 mfgcfg clocks.
> +
> +config COMMON_CLK_MT8183_MMSYS
> +   bool "Clock driver for MediaTek MT8183 mmsys"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 mmsys clocks.
> +
> +config COMMON_CLK_MT8183_VDECSYS
> +   bool "Clock driver for MediaTek MT8183 vdecsys"
> +   depends on COMMON_CLK_MT8183
> +   help
> + This driver supports MediaTek MT8183 vdecsys clocks.
> +
> +config COMMON_CLK_MT8183_VENCSYS
> +   bool "Clock driver for MediaTek MT8183 vencsys"
> +   depends on COMMON_CLK_MT8183
> +   help
> + 

[GIT PULL] PCI fixes for v4.20

[Bjorn Helgaas]

PCI fixes:

  - Revert a _PXM change that causes silent early boot failure on some AMD
ThreadRipper systems (Bjorn Helgaas)


The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:

  Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)

are available in the Git repository at:

  ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
tags/pci-v4.20-fixes-1

for you to fetch changes up to 0d76bcc960e6057750fcf556b65da13f8bbdfd2b:

  Revert "ACPI/PCI: Pay attention to device-specific _PXM node values" 
(2018-11-13 08:38:17 -0600)


pci-v4.20-fixes-1


Bjorn Helgaas (1):
  Revert "ACPI/PCI: Pay attention to device-specific _PXM node values"

 drivers/pci/pci-acpi.c | 5 -
 1 file changed, 5 deletions(-)

[GIT PULL] PCI fixes for v4.20

[Bjorn Helgaas]

PCI fixes:

  - Revert a _PXM change that causes silent early boot failure on some AMD
ThreadRipper systems (Bjorn Helgaas)


The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:

  Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)

are available in the Git repository at:

  ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
tags/pci-v4.20-fixes-1

for you to fetch changes up to 0d76bcc960e6057750fcf556b65da13f8bbdfd2b:

  Revert "ACPI/PCI: Pay attention to device-specific _PXM node values" 
(2018-11-13 08:38:17 -0600)


pci-v4.20-fixes-1


Bjorn Helgaas (1):
  Revert "ACPI/PCI: Pay attention to device-specific _PXM node values"

 drivers/pci/pci-acpi.c | 5 -
 1 file changed, 5 deletions(-)

[PATCH -next] i3c: master: Remove set but not used variable 'old_i3c_scl_lim'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/i3c/master/i3c-master-cdns.c: In function 'cdns_i3c_master_do_daa':
drivers/i3c/master/i3c-master-cdns.c:1137:16: warning:
 variable 'old_i3c_scl_lim' set but not used [-Wunused-but-set-variable]

It never used since introdution in commit
  acfab7d324b2 ("i3c: master: Add driver for Cadence IP")

Signed-off-by: YueHaibing 
---
 drivers/i3c/master/i3c-master-cdns.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/i3c/master/i3c-master-cdns.c 
b/drivers/i3c/master/i3c-master-cdns.c
index ad40162..e828921 100644
--- a/drivers/i3c/master/i3c-master-cdns.c
+++ b/drivers/i3c/master/i3c-master-cdns.c
@@ -1133,7 +1133,6 @@ static void cdns_i3c_master_upd_i3c_scl_lim(struct 
cdns_i3c_master *master)
 static int cdns_i3c_master_do_daa(struct i3c_master_controller *m)
 {
struct cdns_i3c_master *master = to_cdns_i3c_master(m);
-   unsigned long old_i3c_scl_lim;
u32 olddevs, newdevs;
int ret, slot;
u8 addrs[MAX_DEVS] = { };
@@ -1165,9 +1164,6 @@ static int cdns_i3c_master_do_daa(struct 
i3c_master_controller *m)
newdevs = readl(master->regs + DEVS_CTRL) & DEVS_CTRL_DEVS_ACTIVE_MASK;
newdevs &= ~olddevs;
 
-   /* Save the old limitation before add devices. */
-   old_i3c_scl_lim = master->i3c_scl_lim;
-
/*
 * Clear all retaining registers filled during DAA. We already
 * have the addressed assigned to them in the addrs array.

[PATCH -next] i3c: master: Remove set but not used variable 'old_i3c_scl_lim'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/i3c/master/i3c-master-cdns.c: In function 'cdns_i3c_master_do_daa':
drivers/i3c/master/i3c-master-cdns.c:1137:16: warning:
 variable 'old_i3c_scl_lim' set but not used [-Wunused-but-set-variable]

It never used since introdution in commit
  acfab7d324b2 ("i3c: master: Add driver for Cadence IP")

Signed-off-by: YueHaibing 
---
 drivers/i3c/master/i3c-master-cdns.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/i3c/master/i3c-master-cdns.c 
b/drivers/i3c/master/i3c-master-cdns.c
index ad40162..e828921 100644
--- a/drivers/i3c/master/i3c-master-cdns.c
+++ b/drivers/i3c/master/i3c-master-cdns.c
@@ -1133,7 +1133,6 @@ static void cdns_i3c_master_upd_i3c_scl_lim(struct 
cdns_i3c_master *master)
 static int cdns_i3c_master_do_daa(struct i3c_master_controller *m)
 {
struct cdns_i3c_master *master = to_cdns_i3c_master(m);
-   unsigned long old_i3c_scl_lim;
u32 olddevs, newdevs;
int ret, slot;
u8 addrs[MAX_DEVS] = { };
@@ -1165,9 +1164,6 @@ static int cdns_i3c_master_do_daa(struct 
i3c_master_controller *m)
newdevs = readl(master->regs + DEVS_CTRL) & DEVS_CTRL_DEVS_ACTIVE_MASK;
newdevs &= ~olddevs;
 
-   /* Save the old limitation before add devices. */
-   old_i3c_scl_lim = master->i3c_scl_lim;
-
/*
 * Clear all retaining registers filled during DAA. We already
 * have the addressed assigned to them in the addrs array.

Re: [PATCH 4/6] autofs - use struct for mount params

[Ian Kent]

On Wed, 2018-11-14 at 09:54 +0800, kbuild test robot wrote:
> Hi Ian,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.20-rc2]
> [cannot apply to next-20181113]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Ian-Kent/autofs-improve-ioctl-sbi-checks/20181114-021150
> config: i386-allmodconfig (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All errors (new ones prefixed by >>):
> 
>fs/autofs/inode.c: In function 'autofs_fill_super':
> > > fs/autofs/inode.c:361:28: error: invalid type argument of '->' (have
> > > 'struct autofs_fs_params')
> 
>  root_inode->i_uid = params->uid;
>^~
>fs/autofs/inode.c:362:28: error: invalid type argument of '->' (have
> 'struct autofs_fs_params')
>  root_inode->i_gid = params->gid;
>^~

Oh, I fixed that, I must have messed up somewhere, I'll check what I have
again.

Andrew, due to the patch order dependencies I think it would be best for
me to re-post the series so please ignore this series.

I'll put a v2 in the title of the re-posted series so they can be identified
(is that the right thing to do?).

> 
> vim +361 fs/autofs/inode.c
> 
>313
>314int autofs_fill_super(struct super_block *s, void *data, int
> silent)
>315{
>316struct inode *root_inode;
>317struct dentry *root;
>318struct autofs_fs_params params;
>319struct autofs_sb_info *sbi;
>320struct autofs_info *ino;
>321int ret = -EINVAL;
>322
>323sbi = autofs_alloc_sbi(s);
>324if (!sbi)
>325return -ENOMEM;
>326
>327pr_debug("starting up, sbi = %p\n", sbi);
>328
>329s->s_fs_info = sbi;
>330s->s_blocksize = 1024;
>331s->s_blocksize_bits = 10;
>332s->s_magic = AUTOFS_SUPER_MAGIC;
>333s->s_op = _sops;
>334s->s_d_op = _dentry_operations;
>335s->s_time_gran = 1;
>336
>337/*
>338 * Get the root inode and dentry, but defer checking for
> errors.
>339 */
>340ino = autofs_new_ino(sbi);
>341if (!ino) {
>342ret = -ENOMEM;
>343goto fail_free;
>344}
>345root_inode = autofs_get_inode(s, S_IFDIR | 0755);
>346if (!root_inode) {
>347ret = -ENOMEM;
>348goto fail_ino;
>349}
>350root = d_make_root(root_inode);
>351if (!root)
>352goto fail_iput;
>353
>354root->d_fsdata = ino;
>355
>356memset(, 0, sizeof(struct autofs_fs_params));
>357if (autofs_parse_options(data, )) {
>358pr_err("called with bogus options\n");
>359goto fail_dput;
>360}
>  > 361root_inode->i_uid = params->uid;
>362root_inode->i_gid = params->gid;
>363
>364ret = autofs_apply_sbi_options(sbi, );
>365if (ret)
>366goto fail_dput;
>367
>368if (autofs_type_trigger(sbi->type))
>369__managed_dentry_set_managed(root);
>370
>371root_inode->i_fop = _root_operations;
>372root_inode->i_op = _dir_inode_operations;
>373
>374/*
>375 * Success! Install the root dentry now to indicate
> completion.
>376 */
>377s->s_root = root;
>378return 0;
>379
>380/*
>381 * Failure ... clean up.
>382 */
>383fail_dput:
>384dput(root);

Re: [PATCH 4/6] autofs - use struct for mount params

[Ian Kent]

On Wed, 2018-11-14 at 09:54 +0800, kbuild test robot wrote:
> Hi Ian,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.20-rc2]
> [cannot apply to next-20181113]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Ian-Kent/autofs-improve-ioctl-sbi-checks/20181114-021150
> config: i386-allmodconfig (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All errors (new ones prefixed by >>):
> 
>fs/autofs/inode.c: In function 'autofs_fill_super':
> > > fs/autofs/inode.c:361:28: error: invalid type argument of '->' (have
> > > 'struct autofs_fs_params')
> 
>  root_inode->i_uid = params->uid;
>^~
>fs/autofs/inode.c:362:28: error: invalid type argument of '->' (have
> 'struct autofs_fs_params')
>  root_inode->i_gid = params->gid;
>^~

Oh, I fixed that, I must have messed up somewhere, I'll check what I have
again.

Andrew, due to the patch order dependencies I think it would be best for
me to re-post the series so please ignore this series.

I'll put a v2 in the title of the re-posted series so they can be identified
(is that the right thing to do?).

> 
> vim +361 fs/autofs/inode.c
> 
>313
>314int autofs_fill_super(struct super_block *s, void *data, int
> silent)
>315{
>316struct inode *root_inode;
>317struct dentry *root;
>318struct autofs_fs_params params;
>319struct autofs_sb_info *sbi;
>320struct autofs_info *ino;
>321int ret = -EINVAL;
>322
>323sbi = autofs_alloc_sbi(s);
>324if (!sbi)
>325return -ENOMEM;
>326
>327pr_debug("starting up, sbi = %p\n", sbi);
>328
>329s->s_fs_info = sbi;
>330s->s_blocksize = 1024;
>331s->s_blocksize_bits = 10;
>332s->s_magic = AUTOFS_SUPER_MAGIC;
>333s->s_op = _sops;
>334s->s_d_op = _dentry_operations;
>335s->s_time_gran = 1;
>336
>337/*
>338 * Get the root inode and dentry, but defer checking for
> errors.
>339 */
>340ino = autofs_new_ino(sbi);
>341if (!ino) {
>342ret = -ENOMEM;
>343goto fail_free;
>344}
>345root_inode = autofs_get_inode(s, S_IFDIR | 0755);
>346if (!root_inode) {
>347ret = -ENOMEM;
>348goto fail_ino;
>349}
>350root = d_make_root(root_inode);
>351if (!root)
>352goto fail_iput;
>353
>354root->d_fsdata = ino;
>355
>356memset(, 0, sizeof(struct autofs_fs_params));
>357if (autofs_parse_options(data, )) {
>358pr_err("called with bogus options\n");
>359goto fail_dput;
>360}
>  > 361root_inode->i_uid = params->uid;
>362root_inode->i_gid = params->gid;
>363
>364ret = autofs_apply_sbi_options(sbi, );
>365if (ret)
>366goto fail_dput;
>367
>368if (autofs_type_trigger(sbi->type))
>369__managed_dentry_set_managed(root);
>370
>371root_inode->i_fop = _root_operations;
>372root_inode->i_op = _dir_inode_operations;
>373
>374/*
>375 * Success! Install the root dentry now to indicate
> completion.
>376 */
>377s->s_root = root;
>378return 0;
>379
>380/*
>381 * Failure ... clean up.
>382 */
>383fail_dput:
>384dput(root);

[PATCH] zram: close udev startup race condition as default groups

[Minchan Kim]

commit fef912bf860e upstream.
commit 98af4d4df889 upstream.

I got a report from Howard Chen that he saw zram and sysfs race(ie,
zram block device file is created but sysfs for it isn't yet)
when he tried to create new zram devices via hotadd knob.

v4.20 kernel fixes it by [1, 2] but it's too large size to merge
into -stable so this patch fixes the problem by registering defualt
group by Greg KH's approach[3].

This patch should be applied to every stable tree [3.16+] currently
existing from kernel.org because the problem was introduced at 2.6.37
by [4].

[1] fef912bf860e, block: genhd: add 'groups' argument to device_add_disk
[2] 98af4d4df889, zram: register default groups with device_add_disk()
[3] http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/
[4] 33863c21e69e9, Staging: zram: Replace ioctls with sysfs interface

Cc: Sergey Senozhatsky 
Cc: Hannes Reinecke 
Tested-by: Howard Chen 
Signed-off-by: Minchan Kim 
---
 drivers/block/zram/zram_drv.c | 26 ++
 1 file changed, 6 insertions(+), 20 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index a1d6b5597c17..66921427d109 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1636,6 +1636,11 @@ static const struct attribute_group zram_disk_attr_group 
= {
.attrs = zram_disk_attrs,
 };
 
+static const struct attribute_group *zram_disk_attr_groups[] = {
+   _disk_attr_group,
+   NULL,
+};
+
 /*
  * Allocate and initialize new zram device. the function returns
  * '>= 0' device_id upon success, and negative value otherwise.
@@ -1716,24 +1721,15 @@ static int zram_add(void)
 
zram->disk->queue->backing_dev_info->capabilities |=
(BDI_CAP_STABLE_WRITES | BDI_CAP_SYNCHRONOUS_IO);
+   disk_to_dev(zram->disk)->groups = zram_disk_attr_groups;
add_disk(zram->disk);
 
-   ret = sysfs_create_group(_to_dev(zram->disk)->kobj,
-   _disk_attr_group);
-   if (ret < 0) {
-   pr_err("Error creating sysfs group for device %d\n",
-   device_id);
-   goto out_free_disk;
-   }
strlcpy(zram->compressor, default_compressor, sizeof(zram->compressor));
 
zram_debugfs_register(zram);
pr_info("Added device: %s\n", zram->disk->disk_name);
return device_id;
 
-out_free_disk:
-   del_gendisk(zram->disk);
-   put_disk(zram->disk);
 out_free_queue:
blk_cleanup_queue(queue);
 out_free_idr:
@@ -1762,16 +1758,6 @@ static int zram_remove(struct zram *zram)
mutex_unlock(>bd_mutex);
 
zram_debugfs_unregister(zram);
-   /*
-* Remove sysfs first, so no one will perform a disksize
-* store while we destroy the devices. This also helps during
-* hot_remove -- zram_reset_device() is the last holder of
-* ->init_lock, no later/concurrent disksize_store() or any
-* other sysfs handlers are possible.
-*/
-   sysfs_remove_group(_to_dev(zram->disk)->kobj,
-   _disk_attr_group);
-
/* Make sure all the pending I/O are finished */
fsync_bdev(bdev);
zram_reset_device(zram);
-- 
2.19.1.930.g4563a0d9d0-goog

[PATCH] zram: close udev startup race condition as default groups

[Minchan Kim]

commit fef912bf860e upstream.
commit 98af4d4df889 upstream.

I got a report from Howard Chen that he saw zram and sysfs race(ie,
zram block device file is created but sysfs for it isn't yet)
when he tried to create new zram devices via hotadd knob.

v4.20 kernel fixes it by [1, 2] but it's too large size to merge
into -stable so this patch fixes the problem by registering defualt
group by Greg KH's approach[3].

This patch should be applied to every stable tree [3.16+] currently
existing from kernel.org because the problem was introduced at 2.6.37
by [4].

[1] fef912bf860e, block: genhd: add 'groups' argument to device_add_disk
[2] 98af4d4df889, zram: register default groups with device_add_disk()
[3] http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/
[4] 33863c21e69e9, Staging: zram: Replace ioctls with sysfs interface

Cc: Sergey Senozhatsky 
Cc: Hannes Reinecke 
Tested-by: Howard Chen 
Signed-off-by: Minchan Kim 
---
 drivers/block/zram/zram_drv.c | 26 ++
 1 file changed, 6 insertions(+), 20 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index a1d6b5597c17..66921427d109 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1636,6 +1636,11 @@ static const struct attribute_group zram_disk_attr_group 
= {
.attrs = zram_disk_attrs,
 };
 
+static const struct attribute_group *zram_disk_attr_groups[] = {
+   _disk_attr_group,
+   NULL,
+};
+
 /*
  * Allocate and initialize new zram device. the function returns
  * '>= 0' device_id upon success, and negative value otherwise.
@@ -1716,24 +1721,15 @@ static int zram_add(void)
 
zram->disk->queue->backing_dev_info->capabilities |=
(BDI_CAP_STABLE_WRITES | BDI_CAP_SYNCHRONOUS_IO);
+   disk_to_dev(zram->disk)->groups = zram_disk_attr_groups;
add_disk(zram->disk);
 
-   ret = sysfs_create_group(_to_dev(zram->disk)->kobj,
-   _disk_attr_group);
-   if (ret < 0) {
-   pr_err("Error creating sysfs group for device %d\n",
-   device_id);
-   goto out_free_disk;
-   }
strlcpy(zram->compressor, default_compressor, sizeof(zram->compressor));
 
zram_debugfs_register(zram);
pr_info("Added device: %s\n", zram->disk->disk_name);
return device_id;
 
-out_free_disk:
-   del_gendisk(zram->disk);
-   put_disk(zram->disk);
 out_free_queue:
blk_cleanup_queue(queue);
 out_free_idr:
@@ -1762,16 +1758,6 @@ static int zram_remove(struct zram *zram)
mutex_unlock(>bd_mutex);
 
zram_debugfs_unregister(zram);
-   /*
-* Remove sysfs first, so no one will perform a disksize
-* store while we destroy the devices. This also helps during
-* hot_remove -- zram_reset_device() is the last holder of
-* ->init_lock, no later/concurrent disksize_store() or any
-* other sysfs handlers are possible.
-*/
-   sysfs_remove_group(_to_dev(zram->disk)->kobj,
-   _disk_attr_group);
-
/* Make sure all the pending I/O are finished */
fsync_bdev(bdev);
zram_reset_device(zram);
-- 
2.19.1.930.g4563a0d9d0-goog

[PATCH] HID: multitouch: Add pointstick support for Cirque Touchpad

[Kai-Heng Feng]

Cirque Touchpad/Pointstick combo is similar to Alps devices, it requires
MT_CLS_WIN_8_DUAL to expose its pointstick as a mouse.

Signed-off-by: Kai-Heng Feng 
---
 drivers/hid/hid-ids.h| 3 +++
 drivers/hid/hid-multitouch.c | 6 ++
 2 files changed, 9 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index c0d668944dbe..9f59a0a1500b 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -275,6 +275,9 @@
 
 #define USB_VENDOR_ID_CIDC 0x1677
 
+#define I2C_VENDOR_ID_CIRQUE   0x0488
+#define I2C_PRODUCT_ID_CIRQUE_121F 0x121F
+
 #define USB_VENDOR_ID_CJTOUCH  0x24b8
 #define USB_DEVICE_ID_CJTOUCH_MULTI_TOUCH_0020 0x0020
 #define USB_DEVICE_ID_CJTOUCH_MULTI_TOUCH_0040 0x0040
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index f7c6de2b6730..dca0a3a90fb8 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1814,6 +1814,12 @@ static const struct hid_device_id mt_devices[] = {
MT_USB_DEVICE(USB_VENDOR_ID_CHUNGHWAT,
USB_DEVICE_ID_CHUNGHWAT_MULTITOUCH) },
 
+   /* Cirque devices */
+   { .driver_data = MT_CLS_WIN_8_DUAL,
+   HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+   I2C_VENDOR_ID_CIRQUE,
+   I2C_PRODUCT_ID_CIRQUE_121F) },
+
/* CJTouch panels */
{ .driver_data = MT_CLS_NSMU,
MT_USB_DEVICE(USB_VENDOR_ID_CJTOUCH,
-- 
2.17.1

[PATCH] HID: multitouch: Add pointstick support for Cirque Touchpad

[Kai-Heng Feng]

Cirque Touchpad/Pointstick combo is similar to Alps devices, it requires
MT_CLS_WIN_8_DUAL to expose its pointstick as a mouse.

Signed-off-by: Kai-Heng Feng 
---
 drivers/hid/hid-ids.h| 3 +++
 drivers/hid/hid-multitouch.c | 6 ++
 2 files changed, 9 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index c0d668944dbe..9f59a0a1500b 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -275,6 +275,9 @@
 
 #define USB_VENDOR_ID_CIDC 0x1677
 
+#define I2C_VENDOR_ID_CIRQUE   0x0488
+#define I2C_PRODUCT_ID_CIRQUE_121F 0x121F
+
 #define USB_VENDOR_ID_CJTOUCH  0x24b8
 #define USB_DEVICE_ID_CJTOUCH_MULTI_TOUCH_0020 0x0020
 #define USB_DEVICE_ID_CJTOUCH_MULTI_TOUCH_0040 0x0040
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index f7c6de2b6730..dca0a3a90fb8 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -1814,6 +1814,12 @@ static const struct hid_device_id mt_devices[] = {
MT_USB_DEVICE(USB_VENDOR_ID_CHUNGHWAT,
USB_DEVICE_ID_CHUNGHWAT_MULTITOUCH) },
 
+   /* Cirque devices */
+   { .driver_data = MT_CLS_WIN_8_DUAL,
+   HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+   I2C_VENDOR_ID_CIRQUE,
+   I2C_PRODUCT_ID_CIRQUE_121F) },
+
/* CJTouch panels */
{ .driver_data = MT_CLS_NSMU,
MT_USB_DEVICE(USB_VENDOR_ID_CJTOUCH,
-- 
2.17.1

Re: [PATCH v2 2/2] platform/chrome: don't report EC_MKBP_EVENT_SENSOR_FIFO as wakeup

[Benson Leung]

Hi Brian,

On Wed, Nov 07, 2018 at 06:49:39PM -0800, Brian Norris wrote:
> EC_MKBP_EVENT_SENSOR_FIFO events can be triggered for a variety of
> reasons, and there are very few cases in which they should be treated as
> wakeup interrupts (particularly, when a certain
> MOTIONSENSE_MODULE_FLAG_* is set, but this is not even supported in the
> mainline cros_ec_sensor driver yet). Most of the time, they are benign
> sensor readings. In any case, the top-level cros_ec device doesn't know
> enough to determine that they should wake the system, and so it should
> not report the event. This would be the job of the cros_ec_sensors
> driver to parse.
> 
> This patch adds checks to cros_ec_get_next_event() such that it doesn't
> signal 'wakeup' for events of type EC_MKBP_EVENT_SENSOR_FIFO.
> 
> This patch is particularly relevant on devices like Scarlet (Rockchip
> RK3399 tablet, known as Acer Chromebook Tab 10), where the EC firmware
> reports sensor events much more frequently. This was causing
> /sys/power/wakeup_count to increase very frequently, often needlessly
> interrupting our ability to suspend the system.
> 
> Signed-off-by: Brian Norris 

Applied. Thanks!

Benson

> ---
> v1 -> v2:
>  * no change
> ---
>  drivers/platform/chrome/cros_ec_proto.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index fff67b389c87..cc7baf0ecb3c 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -575,6 +575,7 @@ static int get_keyboard_state_event(struct cros_ec_device 
> *ec_dev)
>  
>  int cros_ec_get_next_event(struct cros_ec_device *ec_dev, bool *wake_event)
>  {
> + u8 event_type;
>   u32 host_event;
>   int ret;
>  
> @@ -594,11 +595,22 @@ int cros_ec_get_next_event(struct cros_ec_device 
> *ec_dev, bool *wake_event)
>   return ret;
>  
>   if (wake_event) {
> + event_type = ec_dev->event_data.event_type;
>   host_event = cros_ec_get_host_event(ec_dev);
>  
> - /* Consider non-host_event as wake event */
> - *wake_event = !host_event ||
> -   !!(host_event & ec_dev->host_event_wake_mask);
> + /*
> +  * Sensor events need to be parsed by the sensor sub-device.
> +  * Defer them, and don't report the wakeup here.
> +  */
> + if (event_type == EC_MKBP_EVENT_SENSOR_FIFO)
> + *wake_event = false;
> + /* Masked host-events should not count as wake events. */
> + else if (host_event &&
> +  !(host_event & ec_dev->host_event_wake_mask))
> + *wake_event = false;
> + /* Consider all other events as wake events. */
> + else
> + *wake_event = true;
>   }
>  
>   return ret;
> -- 
> 2.19.1.930.g4563a0d9d0-goog
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] platform/chrome: don't report EC_MKBP_EVENT_SENSOR_FIFO as wakeup

[Benson Leung]

Hi Brian,

On Wed, Nov 07, 2018 at 06:49:39PM -0800, Brian Norris wrote:
> EC_MKBP_EVENT_SENSOR_FIFO events can be triggered for a variety of
> reasons, and there are very few cases in which they should be treated as
> wakeup interrupts (particularly, when a certain
> MOTIONSENSE_MODULE_FLAG_* is set, but this is not even supported in the
> mainline cros_ec_sensor driver yet). Most of the time, they are benign
> sensor readings. In any case, the top-level cros_ec device doesn't know
> enough to determine that they should wake the system, and so it should
> not report the event. This would be the job of the cros_ec_sensors
> driver to parse.
> 
> This patch adds checks to cros_ec_get_next_event() such that it doesn't
> signal 'wakeup' for events of type EC_MKBP_EVENT_SENSOR_FIFO.
> 
> This patch is particularly relevant on devices like Scarlet (Rockchip
> RK3399 tablet, known as Acer Chromebook Tab 10), where the EC firmware
> reports sensor events much more frequently. This was causing
> /sys/power/wakeup_count to increase very frequently, often needlessly
> interrupting our ability to suspend the system.
> 
> Signed-off-by: Brian Norris 

Applied. Thanks!

Benson

> ---
> v1 -> v2:
>  * no change
> ---
>  drivers/platform/chrome/cros_ec_proto.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index fff67b389c87..cc7baf0ecb3c 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -575,6 +575,7 @@ static int get_keyboard_state_event(struct cros_ec_device 
> *ec_dev)
>  
>  int cros_ec_get_next_event(struct cros_ec_device *ec_dev, bool *wake_event)
>  {
> + u8 event_type;
>   u32 host_event;
>   int ret;
>  
> @@ -594,11 +595,22 @@ int cros_ec_get_next_event(struct cros_ec_device 
> *ec_dev, bool *wake_event)
>   return ret;
>  
>   if (wake_event) {
> + event_type = ec_dev->event_data.event_type;
>   host_event = cros_ec_get_host_event(ec_dev);
>  
> - /* Consider non-host_event as wake event */
> - *wake_event = !host_event ||
> -   !!(host_event & ec_dev->host_event_wake_mask);
> + /*
> +  * Sensor events need to be parsed by the sensor sub-device.
> +  * Defer them, and don't report the wakeup here.
> +  */
> + if (event_type == EC_MKBP_EVENT_SENSOR_FIFO)
> + *wake_event = false;
> + /* Masked host-events should not count as wake events. */
> + else if (host_event &&
> +  !(host_event & ec_dev->host_event_wake_mask))
> + *wake_event = false;
> + /* Consider all other events as wake events. */
> + else
> + *wake_event = true;
>   }
>  
>   return ret;
> -- 
> 2.19.1.930.g4563a0d9d0-goog
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] platform/chrome: straighten out cros_ec_get_{next,host}_event() error codes

[Benson Leung]

Hi Brian,

On Wed, Nov 07, 2018 at 06:49:38PM -0800, Brian Norris wrote:
> cros_ec_get_next_event() is documented to return 0 for success and
> negative for errors. It currently returns negative for some errors, and
> non-negative (number of bytes received) for success (including some "no
> data available" responses as zero). This mostly works out OK, because the
> callers were more or less ignoring the documentation, and only treating
> positive values as success (and indepdently checking the modification of
> 'wakeup').
> 
> Let's button this up by avoiding pretending to handle event/wakeup
> distinctions when no event info was retrieved (i.e., returned 0 bytes).
> And fix the documentation of cros_ec_get_host_event() and
> cros_ec_get_next_event() to accurately describe their behavior.
> 
> Signed-off-by: Brian Norris 

Applied.

Thanks,
Benson

> ---
> v1 -> v2:
>  * don't make as many changes to the API -- just fix the documentation
>and a few corner cases instead
> ---
>  drivers/platform/chrome/cros_ec_proto.c | 4 ++--
>  include/linux/mfd/cros_ec.h | 6 --
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index b6fd4838f60f..fff67b389c87 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -580,7 +580,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev, 
> bool *wake_event)
>  
>   if (!ec_dev->mkbp_event_supported) {
>   ret = get_keyboard_state_event(ec_dev);
> - if (ret < 0)
> + if (ret <= 0)
>   return ret;
>  
>   if (wake_event)
> @@ -590,7 +590,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev, 
> bool *wake_event)
>   }
>  
>   ret = get_next_event(ec_dev);
> - if (ret < 0)
> + if (ret <= 0)
>   return ret;
>  
>   if (wake_event) {
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index e44e3ec8a9c7..de8b588c8776 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -317,7 +317,9 @@ int cros_ec_query_all(struct cros_ec_device *ec_dev);
>   * @wake_event: Pointer to a bool set to true upon return if the event might 
> be
>   *  treated as a wake event. Ignored if null.
>   *
> - * Return: 0 on success or negative error code.
> + * Return: negative error code on errors; 0 for no data; or else number of
> + * bytes received (i.e., an event was retrieved successfully). Event types 
> are
> + * written out to @ec_dev->event_data.event_type on success.
>   */
>  int cros_ec_get_next_event(struct cros_ec_device *ec_dev, bool *wake_event);
>  
> @@ -329,7 +331,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev, 
> bool *wake_event);
>   * events raised and call the functions in the ec notifier. This function
>   * is a helper to know which events are raised.
>   *
> - * Return: 0 on success or negative error code.
> + * Return: 0 on error or non-zero bitmask of one or more EC_HOST_EVENT_*.
>   */
>  u32 cros_ec_get_host_event(struct cros_ec_device *ec_dev);
>  
> -- 
> 2.19.1.930.g4563a0d9d0-goog
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] platform/chrome: straighten out cros_ec_get_{next,host}_event() error codes

[Benson Leung]

Hi Brian,

On Wed, Nov 07, 2018 at 06:49:38PM -0800, Brian Norris wrote:
> cros_ec_get_next_event() is documented to return 0 for success and
> negative for errors. It currently returns negative for some errors, and
> non-negative (number of bytes received) for success (including some "no
> data available" responses as zero). This mostly works out OK, because the
> callers were more or less ignoring the documentation, and only treating
> positive values as success (and indepdently checking the modification of
> 'wakeup').
> 
> Let's button this up by avoiding pretending to handle event/wakeup
> distinctions when no event info was retrieved (i.e., returned 0 bytes).
> And fix the documentation of cros_ec_get_host_event() and
> cros_ec_get_next_event() to accurately describe their behavior.
> 
> Signed-off-by: Brian Norris 

Applied.

Thanks,
Benson

> ---
> v1 -> v2:
>  * don't make as many changes to the API -- just fix the documentation
>and a few corner cases instead
> ---
>  drivers/platform/chrome/cros_ec_proto.c | 4 ++--
>  include/linux/mfd/cros_ec.h | 6 --
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index b6fd4838f60f..fff67b389c87 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -580,7 +580,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev, 
> bool *wake_event)
>  
>   if (!ec_dev->mkbp_event_supported) {
>   ret = get_keyboard_state_event(ec_dev);
> - if (ret < 0)
> + if (ret <= 0)
>   return ret;
>  
>   if (wake_event)
> @@ -590,7 +590,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev, 
> bool *wake_event)
>   }
>  
>   ret = get_next_event(ec_dev);
> - if (ret < 0)
> + if (ret <= 0)
>   return ret;
>  
>   if (wake_event) {
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index e44e3ec8a9c7..de8b588c8776 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -317,7 +317,9 @@ int cros_ec_query_all(struct cros_ec_device *ec_dev);
>   * @wake_event: Pointer to a bool set to true upon return if the event might 
> be
>   *  treated as a wake event. Ignored if null.
>   *
> - * Return: 0 on success or negative error code.
> + * Return: negative error code on errors; 0 for no data; or else number of
> + * bytes received (i.e., an event was retrieved successfully). Event types 
> are
> + * written out to @ec_dev->event_data.event_type on success.
>   */
>  int cros_ec_get_next_event(struct cros_ec_device *ec_dev, bool *wake_event);
>  
> @@ -329,7 +331,7 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev, 
> bool *wake_event);
>   * events raised and call the functions in the ec notifier. This function
>   * is a helper to know which events are raised.
>   *
> - * Return: 0 on success or negative error code.
> + * Return: 0 on error or non-zero bitmask of one or more EC_HOST_EVENT_*.
>   */
>  u32 cros_ec_get_host_event(struct cros_ec_device *ec_dev);
>  
> -- 
> 2.19.1.930.g4563a0d9d0-goog
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

linux-next: Tree for Nov 14

[Stephen Rothwell]

Hi all,

Changes since 20181113:

The tip tree still had its build failure for which I applied a fix patch.

Non-merge commits (relative to Linus' tree): 2696
 2835 files changed, 114088 insertions(+), 98851 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, an allmodconfig 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 and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 296 trees (counting Linus' and 67 trees of bug
fix patches pending for the current merge release).

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 (ccda4af0f4b9 Linux 4.20-rc2)
Merging fixes/master (7c6c54b505b8 Merge branch 'i2c/for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux)
Merging kbuild-current/fixes (f9af851aa8e7 kernel hacking: support building 
kernel with -Og optimization level)
Merging arc-current/for-curr (121e38e5acdc ARC: mm: fix uninitialised signal 
code in do_page_fault)
Merging arm-current/fixes (e46daee53bb5 ARM: 8806/1: kprobes: Fix false 
positive with FORTIFY_SOURCE)
Merging arm64-fixes/for-next/fixes (24cc61d8cb5a arm64: memblock: don't permit 
memblock resizing until linear mapping is up)
Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and 
m68k_pgtable_cachemode)
Merging powerpc-fixes/fixes (2c7645b0f7d1 selftests/powerpc: Fix wild_bctr test 
to work on ppc64)
Merging sparc/master (1f2b5b8e2df4 sparc64: Wire up compat getpeername and 
getsockname.)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (77e461d14ed1 bnx2x: Assign unique DMAE channel number for 
FW DMAE transactions.)
Merging bpf/master (da85d8bfd151 kselftests/bpf: use ping6 as the default ipv6 
ping binary when it exists)
Merging ipsec/master (ca92e173ab34 xfrm: Fix bucket count reported to userspace)
Merging netfilter/master (29e3880109e3 netfilter: nf_tables: fix use-after-free 
when deleting compat expressions)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (b374e8686fc3 mt76: fix building without 
CONFIG_LEDS_CLASS)
Merging mac80211/master (113f3aaa81bd cfg80211: Prevent regulatory restore 
during STA disconnect in concurrent interfaces)
Merging rdma-fixes/for-rc (99b77fef3c6c net/mlx5: Fix XRC SRQ umem valid bits)
Merging sound-current/for-linus (d99501b8575d ALSA: hda/ca0132 - Call 
pci_iounmap() instead of iounmap())
Merging sound-asoc-fixes/for-linus (fed9aaa78a5f Merge branch 'asoc-4.20' into 
asoc-linus)
Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8)
Merging regulator-fixes/for-linus (4a6432ade8ba Merge branch 'regulator-4.20' 
into regulator-linus)
Merging spi-fixes/for-linus (f8303a12bb45 Merge branch 'spi-4.20' into 
spi-linus)
Merging pci-current/for-linus (1a87119b7bcf Revert "ACPI/PCI: Pay attention to 
device-specific _PXM node values")
Merging driver-core.current/driver-core-linus (a66d972465d1 devres: Align 
data[] to ARCH_KMALLOC_MINALIGN)
Merging tty.current/tty-linus (ccda4af0f4b9 Linux 4.20-rc2)
Merging usb.current/usb-linus (11644a765952 xhci: Add quirk to workaround the 
errata seen on Cavium Thunder-X2 Soc)
Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of 
dwc2_check_core_endianness)
Merging usb-serial-fixes/usb-linus (ccda4af0f4b9 Linux 4.20-rc2)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (778

linux-next: Tree for Nov 14

[Stephen Rothwell]

Hi all,

Changes since 20181113:

The tip tree still had its build failure for which I applied a fix patch.

Non-merge commits (relative to Linus' tree): 2696
 2835 files changed, 114088 insertions(+), 98851 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, an allmodconfig 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 and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 296 trees (counting Linus' and 67 trees of bug
fix patches pending for the current merge release).

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 (ccda4af0f4b9 Linux 4.20-rc2)
Merging fixes/master (7c6c54b505b8 Merge branch 'i2c/for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux)
Merging kbuild-current/fixes (f9af851aa8e7 kernel hacking: support building 
kernel with -Og optimization level)
Merging arc-current/for-curr (121e38e5acdc ARC: mm: fix uninitialised signal 
code in do_page_fault)
Merging arm-current/fixes (e46daee53bb5 ARM: 8806/1: kprobes: Fix false 
positive with FORTIFY_SOURCE)
Merging arm64-fixes/for-next/fixes (24cc61d8cb5a arm64: memblock: don't permit 
memblock resizing until linear mapping is up)
Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and 
m68k_pgtable_cachemode)
Merging powerpc-fixes/fixes (2c7645b0f7d1 selftests/powerpc: Fix wild_bctr test 
to work on ppc64)
Merging sparc/master (1f2b5b8e2df4 sparc64: Wire up compat getpeername and 
getsockname.)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (77e461d14ed1 bnx2x: Assign unique DMAE channel number for 
FW DMAE transactions.)
Merging bpf/master (da85d8bfd151 kselftests/bpf: use ping6 as the default ipv6 
ping binary when it exists)
Merging ipsec/master (ca92e173ab34 xfrm: Fix bucket count reported to userspace)
Merging netfilter/master (29e3880109e3 netfilter: nf_tables: fix use-after-free 
when deleting compat expressions)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (b374e8686fc3 mt76: fix building without 
CONFIG_LEDS_CLASS)
Merging mac80211/master (113f3aaa81bd cfg80211: Prevent regulatory restore 
during STA disconnect in concurrent interfaces)
Merging rdma-fixes/for-rc (99b77fef3c6c net/mlx5: Fix XRC SRQ umem valid bits)
Merging sound-current/for-linus (d99501b8575d ALSA: hda/ca0132 - Call 
pci_iounmap() instead of iounmap())
Merging sound-asoc-fixes/for-linus (fed9aaa78a5f Merge branch 'asoc-4.20' into 
asoc-linus)
Merging regmap-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8)
Merging regulator-fixes/for-linus (4a6432ade8ba Merge branch 'regulator-4.20' 
into regulator-linus)
Merging spi-fixes/for-linus (f8303a12bb45 Merge branch 'spi-4.20' into 
spi-linus)
Merging pci-current/for-linus (1a87119b7bcf Revert "ACPI/PCI: Pay attention to 
device-specific _PXM node values")
Merging driver-core.current/driver-core-linus (a66d972465d1 devres: Align 
data[] to ARCH_KMALLOC_MINALIGN)
Merging tty.current/tty-linus (ccda4af0f4b9 Linux 4.20-rc2)
Merging usb.current/usb-linus (11644a765952 xhci: Add quirk to workaround the 
errata seen on Cavium Thunder-X2 Soc)
Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of 
dwc2_check_core_endianness)
Merging usb-serial-fixes/usb-linus (ccda4af0f4b9 Linux 4.20-rc2)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (778

Re: [PATCH] ideapad-laptop: Add Lenovo Yoga 2 13 to the no_hw_rfkill DMI list

[Darren Hart]

On Tue, Nov 13, 2018 at 06:22:45PM -0800, Loic WEI YU NENG wrote:
> Some Lenovo ideapad models lack a physical rfkill switch.
> On Lenovo models Yoga 2 13, ideapad-laptop would wrongly report all
> radios as blocked by hardware which caused wireless network connections
> to fail.
> Add these models without an rfkill switch to the no_hw_rfkill list.
> 
> Signed-off-by: Loic WEI YU NENG 

Thank you for the patch.

In the future, please be sure to check MAINTAINERS and include the
relevant lists, now Cc'd.

I see this in the context of your patch, but can you confirm the current
driver fails to match your system? It contains the following, which I
would expect to match:

   .ident = "Lenovo Yoga 2 11 / 13 / Pro",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_BOARD_NAME, "Yoga2"),
},

If it doesn't match, what does dmidecode report for SYS_VENDOR and
BOARD_NAME on your system? Perhaps we need to make the above more
generic.

> ---
>  drivers/platform/x86/ideapad-laptop.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/platform/x86/ideapad-laptop.c 
> b/drivers/platform/x86/ideapad-laptop.c
> index b6489cba2985..1589dffab9fa 100644
> --- a/drivers/platform/x86/ideapad-laptop.c
> +++ b/drivers/platform/x86/ideapad-laptop.c
> @@ -1188,6 +1188,13 @@ static const struct dmi_system_id no_hw_rfkill_list[] 
> = {
>   DMI_MATCH(DMI_BOARD_NAME, "Yoga2"),
>   },
>   },
> + {
> + .ident = "Lenovo Yoga 2 13",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> + DMI_MATCH(DMI_PRODUCT_VERSION, "Yoga 2 13"),
> + },
> + },
>   {
>   .ident = "Lenovo Yoga 3 1170 / 1470",
>   .matches = {
> -- 
> 2.17.1
> 
> 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH] ideapad-laptop: Add Lenovo Yoga 2 13 to the no_hw_rfkill DMI list

[Darren Hart]

On Tue, Nov 13, 2018 at 06:22:45PM -0800, Loic WEI YU NENG wrote:
> Some Lenovo ideapad models lack a physical rfkill switch.
> On Lenovo models Yoga 2 13, ideapad-laptop would wrongly report all
> radios as blocked by hardware which caused wireless network connections
> to fail.
> Add these models without an rfkill switch to the no_hw_rfkill list.
> 
> Signed-off-by: Loic WEI YU NENG 

Thank you for the patch.

In the future, please be sure to check MAINTAINERS and include the
relevant lists, now Cc'd.

I see this in the context of your patch, but can you confirm the current
driver fails to match your system? It contains the following, which I
would expect to match:

   .ident = "Lenovo Yoga 2 11 / 13 / Pro",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_BOARD_NAME, "Yoga2"),
},

If it doesn't match, what does dmidecode report for SYS_VENDOR and
BOARD_NAME on your system? Perhaps we need to make the above more
generic.

> ---
>  drivers/platform/x86/ideapad-laptop.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/platform/x86/ideapad-laptop.c 
> b/drivers/platform/x86/ideapad-laptop.c
> index b6489cba2985..1589dffab9fa 100644
> --- a/drivers/platform/x86/ideapad-laptop.c
> +++ b/drivers/platform/x86/ideapad-laptop.c
> @@ -1188,6 +1188,13 @@ static const struct dmi_system_id no_hw_rfkill_list[] 
> = {
>   DMI_MATCH(DMI_BOARD_NAME, "Yoga2"),
>   },
>   },
> + {
> + .ident = "Lenovo Yoga 2 13",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> + DMI_MATCH(DMI_PRODUCT_VERSION, "Yoga 2 13"),
> + },
> + },
>   {
>   .ident = "Lenovo Yoga 3 1170 / 1470",
>   .matches = {
> -- 
> 2.17.1
> 
> 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH v3] mm: Create the new vm_fault_t type

[Souptick Joarder]

On Tue, Nov 6, 2018 at 5:33 PM Souptick Joarder  wrote:
>
> Page fault handlers are supposed to return VM_FAULT codes,
> but some drivers/file systems mistakenly return error
> numbers. Now that all drivers/file systems have been converted
> to use the vm_fault_t return type, change the type definition
> to no longer be compatible with 'int'. By making it an unsigned
> int, the function prototype becomes incompatible with a function
> which returns int. Sparse will detect any attempts to return a
> value which is not a VM_FAULT code.
>
> VM_FAULT_SET_HINDEX and VM_FAULT_GET_HINDEX values are changed
> to avoid conflict with other VM_FAULT codes.
>
> Signed-off-by: Souptick Joarder 

Any further comment on this patch ?
> ---
> v2: Updated the change log and corrected the document part.
> name added to the enum that kernel-doc able to parse it.
>
> v3: Corrected the documentation.
>
>  include/linux/mm.h   | 46 --
>  include/linux/mm_types.h | 73 
> +++-
>  2 files changed, 72 insertions(+), 47 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index fcf9cc9..511a3ce 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1267,52 +1267,6 @@ static inline void clear_page_pfmemalloc(struct page 
> *page)
>  }
>
>  /*
> - * Different kinds of faults, as returned by handle_mm_fault().
> - * Used to decide whether a process gets delivered SIGBUS or
> - * just gets major/minor fault counters bumped up.
> - */
> -
> -#define VM_FAULT_OOM   0x0001
> -#define VM_FAULT_SIGBUS0x0002
> -#define VM_FAULT_MAJOR 0x0004
> -#define VM_FAULT_WRITE 0x0008  /* Special case for get_user_pages */
> -#define VM_FAULT_HWPOISON 0x0010   /* Hit poisoned small page */
> -#define VM_FAULT_HWPOISON_LARGE 0x0020  /* Hit poisoned large page. Index 
> encoded in upper bits */
> -#define VM_FAULT_SIGSEGV 0x0040
> -
> -#define VM_FAULT_NOPAGE0x0100  /* ->fault installed the pte, not 
> return page */
> -#define VM_FAULT_LOCKED0x0200  /* ->fault locked the returned page */
> -#define VM_FAULT_RETRY 0x0400  /* ->fault blocked, must retry */
> -#define VM_FAULT_FALLBACK 0x0800   /* huge page fault failed, fall back 
> to small */
> -#define VM_FAULT_DONE_COW   0x1000 /* ->fault has fully handled COW */
> -#define VM_FAULT_NEEDDSYNC  0x2000 /* ->fault did not modify page tables
> -* and needs fsync() to complete (for
> -* synchronous page faults in DAX) */
> -
> -#define VM_FAULT_ERROR (VM_FAULT_OOM | VM_FAULT_SIGBUS | VM_FAULT_SIGSEGV | \
> -VM_FAULT_HWPOISON | VM_FAULT_HWPOISON_LARGE | \
> -VM_FAULT_FALLBACK)
> -
> -#define VM_FAULT_RESULT_TRACE \
> -   { VM_FAULT_OOM, "OOM" }, \
> -   { VM_FAULT_SIGBUS,  "SIGBUS" }, \
> -   { VM_FAULT_MAJOR,   "MAJOR" }, \
> -   { VM_FAULT_WRITE,   "WRITE" }, \
> -   { VM_FAULT_HWPOISON,"HWPOISON" }, \
> -   { VM_FAULT_HWPOISON_LARGE,  "HWPOISON_LARGE" }, \
> -   { VM_FAULT_SIGSEGV, "SIGSEGV" }, \
> -   { VM_FAULT_NOPAGE,  "NOPAGE" }, \
> -   { VM_FAULT_LOCKED,  "LOCKED" }, \
> -   { VM_FAULT_RETRY,   "RETRY" }, \
> -   { VM_FAULT_FALLBACK,"FALLBACK" }, \
> -   { VM_FAULT_DONE_COW,"DONE_COW" }, \
> -   { VM_FAULT_NEEDDSYNC,   "NEEDDSYNC" }
> -
> -/* Encode hstate index for a hwpoisoned large page */
> -#define VM_FAULT_SET_HINDEX(x) ((x) << 12)
> -#define VM_FAULT_GET_HINDEX(x) (((x) >> 12) & 0xf)
> -
> -/*
>   * Can be called by the pagefault handler when it gets a VM_FAULT_OOM.
>   */
>  extern void pagefault_out_of_memory(void);
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 5ed8f62..cb25016 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -22,7 +22,6 @@
>  #endif
>  #define AT_VECTOR_SIZE (2*(AT_VECTOR_SIZE_ARCH + AT_VECTOR_SIZE_BASE + 1))
>
> -typedef int vm_fault_t;
>
>  struct address_space;
>  struct mem_cgroup;
> @@ -609,6 +608,78 @@ static inline bool mm_tlb_flush_nested(struct mm_struct 
> *mm)
>
>  struct vm_fault;
>
> +/**
> + * typedef vm_fault_t - Return type for page fault handlers.
> + *
> + * Page fault handlers return a bitmask of %VM_FAULT values.
> + */
> +typedef __bitwise unsigned int vm_fault_t;
> +
> +/**
> + * enum vm_fault_reason - Page fault handlers return a bitmask of
> + * these values to tell the core VM what happened when handling the
> + * fault. Used to decide whether a process gets delivered SIGBUS or
> + * just gets major/minor fault counters bumped up.
> + *
> + * @VM_FAULT_OOM:  Out Of Memory
> + * @VM_FAULT_SIGBUS:   Bad access
> + * @VM_FAULT_MAJOR:Page read from storage
> + * @VM_FAULT_WRITE:

Re: [PATCH v3] mm: Create the new vm_fault_t type

[Souptick Joarder]

On Tue, Nov 6, 2018 at 5:33 PM Souptick Joarder  wrote:
>
> Page fault handlers are supposed to return VM_FAULT codes,
> but some drivers/file systems mistakenly return error
> numbers. Now that all drivers/file systems have been converted
> to use the vm_fault_t return type, change the type definition
> to no longer be compatible with 'int'. By making it an unsigned
> int, the function prototype becomes incompatible with a function
> which returns int. Sparse will detect any attempts to return a
> value which is not a VM_FAULT code.
>
> VM_FAULT_SET_HINDEX and VM_FAULT_GET_HINDEX values are changed
> to avoid conflict with other VM_FAULT codes.
>
> Signed-off-by: Souptick Joarder 

Any further comment on this patch ?
> ---
> v2: Updated the change log and corrected the document part.
> name added to the enum that kernel-doc able to parse it.
>
> v3: Corrected the documentation.
>
>  include/linux/mm.h   | 46 --
>  include/linux/mm_types.h | 73 
> +++-
>  2 files changed, 72 insertions(+), 47 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index fcf9cc9..511a3ce 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1267,52 +1267,6 @@ static inline void clear_page_pfmemalloc(struct page 
> *page)
>  }
>
>  /*
> - * Different kinds of faults, as returned by handle_mm_fault().
> - * Used to decide whether a process gets delivered SIGBUS or
> - * just gets major/minor fault counters bumped up.
> - */
> -
> -#define VM_FAULT_OOM   0x0001
> -#define VM_FAULT_SIGBUS0x0002
> -#define VM_FAULT_MAJOR 0x0004
> -#define VM_FAULT_WRITE 0x0008  /* Special case for get_user_pages */
> -#define VM_FAULT_HWPOISON 0x0010   /* Hit poisoned small page */
> -#define VM_FAULT_HWPOISON_LARGE 0x0020  /* Hit poisoned large page. Index 
> encoded in upper bits */
> -#define VM_FAULT_SIGSEGV 0x0040
> -
> -#define VM_FAULT_NOPAGE0x0100  /* ->fault installed the pte, not 
> return page */
> -#define VM_FAULT_LOCKED0x0200  /* ->fault locked the returned page */
> -#define VM_FAULT_RETRY 0x0400  /* ->fault blocked, must retry */
> -#define VM_FAULT_FALLBACK 0x0800   /* huge page fault failed, fall back 
> to small */
> -#define VM_FAULT_DONE_COW   0x1000 /* ->fault has fully handled COW */
> -#define VM_FAULT_NEEDDSYNC  0x2000 /* ->fault did not modify page tables
> -* and needs fsync() to complete (for
> -* synchronous page faults in DAX) */
> -
> -#define VM_FAULT_ERROR (VM_FAULT_OOM | VM_FAULT_SIGBUS | VM_FAULT_SIGSEGV | \
> -VM_FAULT_HWPOISON | VM_FAULT_HWPOISON_LARGE | \
> -VM_FAULT_FALLBACK)
> -
> -#define VM_FAULT_RESULT_TRACE \
> -   { VM_FAULT_OOM, "OOM" }, \
> -   { VM_FAULT_SIGBUS,  "SIGBUS" }, \
> -   { VM_FAULT_MAJOR,   "MAJOR" }, \
> -   { VM_FAULT_WRITE,   "WRITE" }, \
> -   { VM_FAULT_HWPOISON,"HWPOISON" }, \
> -   { VM_FAULT_HWPOISON_LARGE,  "HWPOISON_LARGE" }, \
> -   { VM_FAULT_SIGSEGV, "SIGSEGV" }, \
> -   { VM_FAULT_NOPAGE,  "NOPAGE" }, \
> -   { VM_FAULT_LOCKED,  "LOCKED" }, \
> -   { VM_FAULT_RETRY,   "RETRY" }, \
> -   { VM_FAULT_FALLBACK,"FALLBACK" }, \
> -   { VM_FAULT_DONE_COW,"DONE_COW" }, \
> -   { VM_FAULT_NEEDDSYNC,   "NEEDDSYNC" }
> -
> -/* Encode hstate index for a hwpoisoned large page */
> -#define VM_FAULT_SET_HINDEX(x) ((x) << 12)
> -#define VM_FAULT_GET_HINDEX(x) (((x) >> 12) & 0xf)
> -
> -/*
>   * Can be called by the pagefault handler when it gets a VM_FAULT_OOM.
>   */
>  extern void pagefault_out_of_memory(void);
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 5ed8f62..cb25016 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -22,7 +22,6 @@
>  #endif
>  #define AT_VECTOR_SIZE (2*(AT_VECTOR_SIZE_ARCH + AT_VECTOR_SIZE_BASE + 1))
>
> -typedef int vm_fault_t;
>
>  struct address_space;
>  struct mem_cgroup;
> @@ -609,6 +608,78 @@ static inline bool mm_tlb_flush_nested(struct mm_struct 
> *mm)
>
>  struct vm_fault;
>
> +/**
> + * typedef vm_fault_t - Return type for page fault handlers.
> + *
> + * Page fault handlers return a bitmask of %VM_FAULT values.
> + */
> +typedef __bitwise unsigned int vm_fault_t;
> +
> +/**
> + * enum vm_fault_reason - Page fault handlers return a bitmask of
> + * these values to tell the core VM what happened when handling the
> + * fault. Used to decide whether a process gets delivered SIGBUS or
> + * just gets major/minor fault counters bumped up.
> + *
> + * @VM_FAULT_OOM:  Out Of Memory
> + * @VM_FAULT_SIGBUS:   Bad access
> + * @VM_FAULT_MAJOR:Page read from storage
> + * @VM_FAULT_WRITE:

Re: [PATCH] nvme: utilize two queue maps, one for reads and one for writes

[Guenter Roeck]

On Tue, Nov 13, 2018 at 05:51:08PM -0700, Jens Axboe wrote:
> On 11/13/18 5:41 PM, Guenter Roeck wrote:
> > Hi,
> > 
> > On Wed, Oct 31, 2018 at 08:36:31AM -0600, Jens Axboe wrote:
> >> NVMe does round-robin between queues by default, which means that
> >> sharing a queue map for both reads and writes can be problematic
> >> in terms of read servicing. It's much easier to flood the queue
> >> with writes and reduce the read servicing.
> >>
> >> Implement two queue maps, one for reads and one for writes. The
> >> write queue count is configurable through the 'write_queues'
> >> parameter.
> >>
> >> By default, we retain the previous behavior of having a single
> >> queue set, shared between reads and writes. Setting 'write_queues'
> >> to a non-zero value will create two queue sets, one for reads and
> >> one for writes, the latter using the configurable number of
> >> queues (hardware queue counts permitting).
> >>
> >> Reviewed-by: Hannes Reinecke 
> >> Reviewed-by: Keith Busch 
> >> Signed-off-by: Jens Axboe 
> > 
> > This patch causes hangs when running recent versions of
> > -next with several architectures; see the -next column at
> > kerneltests.org/builders for details.  Bisect log below; this
> > was run with qemu on alpha. Reverting this patch as well as
> > "nvme: add separate poll queue map" fixes the problem.
> 
> I don't see anything related to what hung, the trace, and so on.
> Can you clue me in? Where are the test results with dmesg?
> 
alpha just stalls during boot. parisc reports a hung task
in nvme_reset_work. sparc64 reports EIO when instantiating
the nvme driver, called from nvme_reset_work, and then stalls.
In all three cases, reverting the two mentioned patches fixes
the problem.

https://kerneltests.org/builders/qemu-parisc-next/builds/173/steps/qemubuildcommand_1/logs/stdio

is an example log for parisc.

I didn't check if the other boot failures (ppc looks bad)
have the same root cause.

> How to reproduce?
> 
parisc:

qemu-system-hppa -kernel vmlinux -no-reboot \
-snapshot -device nvme,serial=foo,drive=d0 \
-drive file=rootfs.ext2,if=none,format=raw,id=d0 \
-append 'root=/dev/nvme0n1 rw rootwait panic=-1 console=ttyS0,115200 ' \
-nographic -monitor null

alpha:

qemu-system-alpha -M clipper -kernel arch/alpha/boot/vmlinux -no-reboot \
-snapshot -device nvme,serial=foo,drive=d0 \
-drive file=rootfs.ext2,if=none,format=raw,id=d0 \
-append 'root=/dev/nvme0n1 rw rootwait panic=-1 console=ttyS0' \
-m 128M -nographic -monitor null -serial stdio

sparc64:

qemu-system-sparc64 -M sun4u -cpu 'TI UltraSparc IIi' -m 512 \
-snapshot -device nvme,serial=foo,drive=d0,bus=pciB \
-drive file=rootfs.ext2,if=none,format=raw,id=d0 \
-kernel arch/sparc/boot/image -no-reboot \
-append 'root=/dev/nvme0n1 rw rootwait panic=-1 console=ttyS0' \
-nographic -monitor none

The root file systems are available from the respective subdirectories
of:

https://github.com/groeck/linux-build-test/tree/master/rootfs

Guenter

Re: [PATCH] nvme: utilize two queue maps, one for reads and one for writes

[Guenter Roeck]

On Tue, Nov 13, 2018 at 05:51:08PM -0700, Jens Axboe wrote:
> On 11/13/18 5:41 PM, Guenter Roeck wrote:
> > Hi,
> > 
> > On Wed, Oct 31, 2018 at 08:36:31AM -0600, Jens Axboe wrote:
> >> NVMe does round-robin between queues by default, which means that
> >> sharing a queue map for both reads and writes can be problematic
> >> in terms of read servicing. It's much easier to flood the queue
> >> with writes and reduce the read servicing.
> >>
> >> Implement two queue maps, one for reads and one for writes. The
> >> write queue count is configurable through the 'write_queues'
> >> parameter.
> >>
> >> By default, we retain the previous behavior of having a single
> >> queue set, shared between reads and writes. Setting 'write_queues'
> >> to a non-zero value will create two queue sets, one for reads and
> >> one for writes, the latter using the configurable number of
> >> queues (hardware queue counts permitting).
> >>
> >> Reviewed-by: Hannes Reinecke 
> >> Reviewed-by: Keith Busch 
> >> Signed-off-by: Jens Axboe 
> > 
> > This patch causes hangs when running recent versions of
> > -next with several architectures; see the -next column at
> > kerneltests.org/builders for details.  Bisect log below; this
> > was run with qemu on alpha. Reverting this patch as well as
> > "nvme: add separate poll queue map" fixes the problem.
> 
> I don't see anything related to what hung, the trace, and so on.
> Can you clue me in? Where are the test results with dmesg?
> 
alpha just stalls during boot. parisc reports a hung task
in nvme_reset_work. sparc64 reports EIO when instantiating
the nvme driver, called from nvme_reset_work, and then stalls.
In all three cases, reverting the two mentioned patches fixes
the problem.

https://kerneltests.org/builders/qemu-parisc-next/builds/173/steps/qemubuildcommand_1/logs/stdio

is an example log for parisc.

I didn't check if the other boot failures (ppc looks bad)
have the same root cause.

> How to reproduce?
> 
parisc:

qemu-system-hppa -kernel vmlinux -no-reboot \
-snapshot -device nvme,serial=foo,drive=d0 \
-drive file=rootfs.ext2,if=none,format=raw,id=d0 \
-append 'root=/dev/nvme0n1 rw rootwait panic=-1 console=ttyS0,115200 ' \
-nographic -monitor null

alpha:

qemu-system-alpha -M clipper -kernel arch/alpha/boot/vmlinux -no-reboot \
-snapshot -device nvme,serial=foo,drive=d0 \
-drive file=rootfs.ext2,if=none,format=raw,id=d0 \
-append 'root=/dev/nvme0n1 rw rootwait panic=-1 console=ttyS0' \
-m 128M -nographic -monitor null -serial stdio

sparc64:

qemu-system-sparc64 -M sun4u -cpu 'TI UltraSparc IIi' -m 512 \
-snapshot -device nvme,serial=foo,drive=d0,bus=pciB \
-drive file=rootfs.ext2,if=none,format=raw,id=d0 \
-kernel arch/sparc/boot/image -no-reboot \
-append 'root=/dev/nvme0n1 rw rootwait panic=-1 console=ttyS0' \
-nographic -monitor none

The root file systems are available from the respective subdirectories
of:

https://github.com/groeck/linux-build-test/tree/master/rootfs

Guenter

[PATCH v2] fork: Fix some -Wmissing-prototypes warnings

[Yi Wang]

We get a warning when building kernel with W=1:
kernel/fork.c:167:13: warning: no previous prototype for 
‘arch_release_thread_stack’ [-Wmissing-prototypes]
kernel/fork.c:779:13: warning: no previous prototype for ‘fork_init’ 
[-Wmissing-prototypes]

Add the missing declaration in head file to fix this.

Also, remove arch_release_thread_stack() completely because no
arch seems to implement it since bb9d81264 (arch: remove tile port).

Signed-off-by: Yi Wang 
---
v2: remove arch_release_thread_stack(). Thanks to Rasmus.
---
 include/linux/sched/task.h | 2 ++
 init/main.c| 1 -
 kernel/fork.c  | 5 -
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
index 108ede9..44c6f15 100644
--- a/include/linux/sched/task.h
+++ b/include/linux/sched/task.h
@@ -39,6 +39,8 @@
 
 extern void proc_caches_init(void);
 
+extern void fork_init(void);
+
 extern void release_task(struct task_struct * p);
 
 #ifdef CONFIG_HAVE_COPY_THREAD_TLS
diff --git a/init/main.c b/init/main.c
index ee14710..8feda42 100644
--- a/init/main.c
+++ b/init/main.c
@@ -105,7 +105,6 @@
 static int kernel_init(void *);
 
 extern void init_IRQ(void);
-extern void fork_init(void);
 extern void radix_tree_init(void);
 
 /*
diff --git a/kernel/fork.c b/kernel/fork.c
index 07cddff..c6d02be 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -164,10 +164,6 @@ static inline void free_task_struct(struct task_struct 
*tsk)
 }
 #endif
 
-void __weak arch_release_thread_stack(unsigned long *stack)
-{
-}
-
 #ifndef CONFIG_ARCH_THREAD_STACK_ALLOCATOR
 
 /*
@@ -417,7 +413,6 @@ static void release_task_stack(struct task_struct *tsk)
return;  /* Better to leak the stack than to free prematurely */
 
account_kernel_stack(tsk, -1);
-   arch_release_thread_stack(tsk->stack);
free_thread_stack(tsk);
tsk->stack = NULL;
 #ifdef CONFIG_VMAP_STACK
-- 
1.8.3.1

[PATCH v2] fork: Fix some -Wmissing-prototypes warnings

[Yi Wang]

We get a warning when building kernel with W=1:
kernel/fork.c:167:13: warning: no previous prototype for 
‘arch_release_thread_stack’ [-Wmissing-prototypes]
kernel/fork.c:779:13: warning: no previous prototype for ‘fork_init’ 
[-Wmissing-prototypes]

Add the missing declaration in head file to fix this.

Also, remove arch_release_thread_stack() completely because no
arch seems to implement it since bb9d81264 (arch: remove tile port).

Signed-off-by: Yi Wang 
---
v2: remove arch_release_thread_stack(). Thanks to Rasmus.
---
 include/linux/sched/task.h | 2 ++
 init/main.c| 1 -
 kernel/fork.c  | 5 -
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
index 108ede9..44c6f15 100644
--- a/include/linux/sched/task.h
+++ b/include/linux/sched/task.h
@@ -39,6 +39,8 @@
 
 extern void proc_caches_init(void);
 
+extern void fork_init(void);
+
 extern void release_task(struct task_struct * p);
 
 #ifdef CONFIG_HAVE_COPY_THREAD_TLS
diff --git a/init/main.c b/init/main.c
index ee14710..8feda42 100644
--- a/init/main.c
+++ b/init/main.c
@@ -105,7 +105,6 @@
 static int kernel_init(void *);
 
 extern void init_IRQ(void);
-extern void fork_init(void);
 extern void radix_tree_init(void);
 
 /*
diff --git a/kernel/fork.c b/kernel/fork.c
index 07cddff..c6d02be 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -164,10 +164,6 @@ static inline void free_task_struct(struct task_struct 
*tsk)
 }
 #endif
 
-void __weak arch_release_thread_stack(unsigned long *stack)
-{
-}
-
 #ifndef CONFIG_ARCH_THREAD_STACK_ALLOCATOR
 
 /*
@@ -417,7 +413,6 @@ static void release_task_stack(struct task_struct *tsk)
return;  /* Better to leak the stack than to free prematurely */
 
account_kernel_stack(tsk, -1);
-   arch_release_thread_stack(tsk->stack);
free_thread_stack(tsk);
tsk->stack = NULL;
 #ifdef CONFIG_VMAP_STACK
-- 
1.8.3.1

Re: [PATCH v4] cpufreq: ti-cpufreq: Only register platform_device when supported

[Viresh Kumar]

On 13-11-18, 13:30, Dave Gerlach wrote:
> Currently the ti-cpufreq driver blindly registers a 'ti-cpufreq' to force
> the driver to probe on any platforms where the driver is built in.
> However, this should only happen on platforms that actually can make use
> of the driver. There is already functionality in place to match the
> SoC compatible so let's factor this out into a separate call and
> make sure we find a match before creating the ti-cpufreq platform device.
> 
> Reviewed-by: Johan Hovold 
> Signed-off-by: Dave Gerlach 
> ---
> v3->v4: Use platform_device_register_data rather than
>   platform_device_register_resndata as we are only passing data.
> 
>   v3: https://patchwork.kernel.org/patch/10681161/
> 
>  drivers/cpufreq/ti-cpufreq.c | 26 +-
>  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
> index 3f0e2a14895a..22b53bf26817 100644
> --- a/drivers/cpufreq/ti-cpufreq.c
> +++ b/drivers/cpufreq/ti-cpufreq.c
> @@ -201,19 +201,28 @@ static const struct of_device_id ti_cpufreq_of_match[] 
> = {
>   {},
>  };
>  
> +static const struct of_device_id *ti_cpufreq_match_node(void)
> +{
> + struct device_node *np;
> + const struct of_device_id *match;
> +
> + np = of_find_node_by_path("/");
> + match = of_match_node(ti_cpufreq_of_match, np);
> + of_node_put(np);
> +
> + return match;
> +}
> +
>  static int ti_cpufreq_probe(struct platform_device *pdev)
>  {
>   u32 version[VERSION_COUNT];
> - struct device_node *np;
>   const struct of_device_id *match;
>   struct opp_table *ti_opp_table;
>   struct ti_cpufreq_data *opp_data;
>   const char * const reg_names[] = {"vdd", "vbb"};
>   int ret;
>  
> - np = of_find_node_by_path("/");
> - match = of_match_node(ti_cpufreq_of_match, np);
> - of_node_put(np);
> + match = dev_get_platdata(>dev);
>   if (!match)
>   return -ENODEV;
>  
> @@ -290,7 +299,14 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
>  
>  static int ti_cpufreq_init(void)
>  {
> - platform_device_register_simple("ti-cpufreq", -1, NULL, 0);
> + const struct of_device_id *match;
> +
> + /* Check to ensure we are on a compatible platform */
> + match = ti_cpufreq_match_node();
> + if (match)
> + platform_device_register_data(NULL, "ti-cpufreq", -1, match,
> +   sizeof(*match));
> +
>   return 0;
>  }
>  module_init(ti_cpufreq_init);

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v4] cpufreq: ti-cpufreq: Only register platform_device when supported

[Viresh Kumar]

On 13-11-18, 13:30, Dave Gerlach wrote:
> Currently the ti-cpufreq driver blindly registers a 'ti-cpufreq' to force
> the driver to probe on any platforms where the driver is built in.
> However, this should only happen on platforms that actually can make use
> of the driver. There is already functionality in place to match the
> SoC compatible so let's factor this out into a separate call and
> make sure we find a match before creating the ti-cpufreq platform device.
> 
> Reviewed-by: Johan Hovold 
> Signed-off-by: Dave Gerlach 
> ---
> v3->v4: Use platform_device_register_data rather than
>   platform_device_register_resndata as we are only passing data.
> 
>   v3: https://patchwork.kernel.org/patch/10681161/
> 
>  drivers/cpufreq/ti-cpufreq.c | 26 +-
>  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
> index 3f0e2a14895a..22b53bf26817 100644
> --- a/drivers/cpufreq/ti-cpufreq.c
> +++ b/drivers/cpufreq/ti-cpufreq.c
> @@ -201,19 +201,28 @@ static const struct of_device_id ti_cpufreq_of_match[] 
> = {
>   {},
>  };
>  
> +static const struct of_device_id *ti_cpufreq_match_node(void)
> +{
> + struct device_node *np;
> + const struct of_device_id *match;
> +
> + np = of_find_node_by_path("/");
> + match = of_match_node(ti_cpufreq_of_match, np);
> + of_node_put(np);
> +
> + return match;
> +}
> +
>  static int ti_cpufreq_probe(struct platform_device *pdev)
>  {
>   u32 version[VERSION_COUNT];
> - struct device_node *np;
>   const struct of_device_id *match;
>   struct opp_table *ti_opp_table;
>   struct ti_cpufreq_data *opp_data;
>   const char * const reg_names[] = {"vdd", "vbb"};
>   int ret;
>  
> - np = of_find_node_by_path("/");
> - match = of_match_node(ti_cpufreq_of_match, np);
> - of_node_put(np);
> + match = dev_get_platdata(>dev);
>   if (!match)
>   return -ENODEV;
>  
> @@ -290,7 +299,14 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
>  
>  static int ti_cpufreq_init(void)
>  {
> - platform_device_register_simple("ti-cpufreq", -1, NULL, 0);
> + const struct of_device_id *match;
> +
> + /* Check to ensure we are on a compatible platform */
> + match = ti_cpufreq_match_node();
> + if (match)
> + platform_device_register_data(NULL, "ti-cpufreq", -1, match,
> +   sizeof(*match));
> +
>   return 0;
>  }
>  module_init(ti_cpufreq_init);

Acked-by: Viresh Kumar 

-- 
viresh

Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset

[Finn Thain]

On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:

> 
> A clocksource provides a cycle counter that monotonically changes and 
> does not wrap between clockevent events.
> 
> A clock event is responsible for providing events to the system when 
> some work is needing to be done, limited by the wrap interval of the 
> clocksource.
> 
> Each time the clock event triggers an interrupt, the clocksource is
> read to determine how much time has passed, using:
> 
>   count = (new_value - old_value) & available_bits
>   nanosecs = count * scale >> shift;
> 
> If you try to combine the clocksource and clockevent because you only
> have a single counter, and the counter has the behaviour of:
> - counting down towards zero
> - when reaching zero, triggers an interrupt, and reloads with N
> 
> then this provides your clockevent, but you can't use this as a clock
> source, because each time you receive an interrupt and try to read the
> counter value, it will be approximately the same value.  This means
> that the above calculation fails to register the correct number of
> nanoseconds passing.  Hence, this does not work.
> 
> Also note where I said above that the clock event device must be able
> to provide an interrupt _before_ the clocksource wraps - clearly with
> such a timer, that is utterly impossible.
> 
> The simple solution is to not use such a counter as the clocksource,
> which means you fall back to using the jiffies clocksource, and your
> timekeeping has jiffy resolution - so 10ms, or possibly 1ms if you
> want a 1kHz timer interval.  For most applications, that's simply way
> to coarse, as was realised in the very early days of Linux.
> 
> If only there was a way to interpolate between timer interrupts...
> which is exactly what arch_gettimeoffset() does, and is a historical
> reminant of the pre-clocksource/clockevent days of the kernel - but
> it is the only way to get better resolution from this sort of setup.
> 

Both of the platforms in question (RPC and EBSA110) have not 
defined(CONFIG_GENERIC_CLOCKEVENTS) and have not defined any struct 
clock_event_device, AFAICT.

So, even assuming that you're right about the limitations of single-timer 
platforms in general, removal of arch_gettimeoffset wouldn't require the 
removal of any platforms, AFAICT.

-- 

Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset

[Finn Thain]

On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:

> 
> A clocksource provides a cycle counter that monotonically changes and 
> does not wrap between clockevent events.
> 
> A clock event is responsible for providing events to the system when 
> some work is needing to be done, limited by the wrap interval of the 
> clocksource.
> 
> Each time the clock event triggers an interrupt, the clocksource is
> read to determine how much time has passed, using:
> 
>   count = (new_value - old_value) & available_bits
>   nanosecs = count * scale >> shift;
> 
> If you try to combine the clocksource and clockevent because you only
> have a single counter, and the counter has the behaviour of:
> - counting down towards zero
> - when reaching zero, triggers an interrupt, and reloads with N
> 
> then this provides your clockevent, but you can't use this as a clock
> source, because each time you receive an interrupt and try to read the
> counter value, it will be approximately the same value.  This means
> that the above calculation fails to register the correct number of
> nanoseconds passing.  Hence, this does not work.
> 
> Also note where I said above that the clock event device must be able
> to provide an interrupt _before_ the clocksource wraps - clearly with
> such a timer, that is utterly impossible.
> 
> The simple solution is to not use such a counter as the clocksource,
> which means you fall back to using the jiffies clocksource, and your
> timekeeping has jiffy resolution - so 10ms, or possibly 1ms if you
> want a 1kHz timer interval.  For most applications, that's simply way
> to coarse, as was realised in the very early days of Linux.
> 
> If only there was a way to interpolate between timer interrupts...
> which is exactly what arch_gettimeoffset() does, and is a historical
> reminant of the pre-clocksource/clockevent days of the kernel - but
> it is the only way to get better resolution from this sort of setup.
> 

Both of the platforms in question (RPC and EBSA110) have not 
defined(CONFIG_GENERIC_CLOCKEVENTS) and have not defined any struct 
clock_event_device, AFAICT.

So, even assuming that you're right about the limitations of single-timer 
platforms in general, removal of arch_gettimeoffset wouldn't require the 
removal of any platforms, AFAICT.

-- 

Re: [PATCH] ARM: dts: i.MX25: add the clocks for the EPIT blocks

[Shawn Guo]

On Thu, Nov 01, 2018 at 06:32:47PM +0100, Martin Kaiser wrote:
> The i.MX25 contains two EPIT (Enhanced Periodic Interrupt Timer)
> function blocks. Add their ipg and per clocks to the device tree.
> 
> Signed-off-by: Martin Kaiser 

Applied, thanks.

Re: [PATCH] ARM: dts: i.MX25: add the clocks for the EPIT blocks

[Shawn Guo]

On Thu, Nov 01, 2018 at 06:32:47PM +0100, Martin Kaiser wrote:
> The i.MX25 contains two EPIT (Enhanced Periodic Interrupt Timer)
> function blocks. Add their ipg and per clocks to the device tree.
> 
> Signed-off-by: Martin Kaiser 

Applied, thanks.

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

[Michael Schmitz]

Hi Finn,

Am 14.11.2018 um 14:08 schrieb Michael Schmitz:

Can you also test tree fbf8405cd982 please?


My tests were on c606b5cf902 in case it wasn't clear. I've now seen
fbf8405cd982, one moment please ...

That one does appear to work - different versions of ARAnyM, and
different userland versions though. I'll test that again with the setup
that saw c606b5cf902 fail.


Still fails on that emulator / userland.

Cheers,

Michael




Cheers,

Michael

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

[Michael Schmitz]

Hi Finn,

Am 14.11.2018 um 14:08 schrieb Michael Schmitz:

Can you also test tree fbf8405cd982 please?


My tests were on c606b5cf902 in case it wasn't clear. I've now seen
fbf8405cd982, one moment please ...

That one does appear to work - different versions of ARAnyM, and
different userland versions though. I'll test that again with the setup
that saw c606b5cf902 fail.


Still fails on that emulator / userland.

Cheers,

Michael




Cheers,

Michael

BUG: KASAN: slab-out-of-bounds in try_to_unmap_one+0x1c4/0x1af0

[Qian Cai]

Compiling kernel on an aarch64 server with the latest mainline (rc2) triggered 
this,

[ 1463.931841] BUG: KASAN: slab-out-of-bounds in try_to_unmap_one+0x1c4/0x1af0
[ 1463.938969] Write of size 32 at addr 80897ce87b58 by task 
kworker/u513:0/5209
[ 1463.946678] 
[ 1463.948656] CPU: 38 PID: 5209 Comm: kworker/u513:0 Kdump: loaded Tainted: G  
  WL4.20.0-rc2+ #4
[ 1463.958485] Hardware name: HPE Apollo 70 /C01_APACHE_MB 
, BIOS L50_5.13_1.0.6 07/10/2018
[ 1463.968450] Workqueue: writeback wb_workfn (flush-253:0)
[ 1463.973848] Call trace:
[ 1463.976622]  dump_backtrace+0x0/0x2c8
[ 1463.980642] 
[ 1463.982239] Allocated by task 2:
[ 1463.985528]  kasan_kmalloc.part.1+0x40/0x108
[ 1463.989842]  kasan_kmalloc+0xb4/0xc8
[ 1463.993500]  kasan_slab_alloc+0x14/0x20
[ 1463.997630]  kmem_cache_alloc_node+0x140/0x430
[ 1464.002241]  copy_process.isra.2+0x39c/0x2e20
[ 1464.007009]  _do_fork+0x120/0xa28
[ 1464.010595]  kernel_thread+0x48/0x58
[ 1464.014206]  kthreadd+0x3dc/0x478
[ 1464.017698]  ret_from_fork+0x10/0x1c
[ 1464.021466] 
[ 1464.022981] Freed by task 1391:
[ 1464.026214]  __kasan_slab_free+0x114/0x228
[ 1464.030447]  kasan_slab_free+0x10/0x18
[ 1464.034305]  kmem_cache_free+0x9c/0x3a8
[ 1464.038284]  put_task_stack+0x94/0x110
[ 1464.042169]  finish_task_switch+0x3b0/0x488
[ 1464.046850]  __schedule+0x5e4/0xda0
[ 1464.050665]  schedule+0xdc/0x240
[ 1464.054012]  worker_thread+0x278/0xa70
[ 1464.058021]  kthread+0x1c4/0x1d0
[ 1464.061393]  ret_from_fork+0x10/0x1c
[ 1464.065051] 
[ 1464.067005] The buggy address belongs to the object at 80897ce88000
[ 1464.067005]  which belongs to the cache thread_stack of size 32768
[ 1464.080107] The buggy address is located 1192 bytes to the left of
[ 1464.080107]  32768-byte region [80897ce88000, 80897ce9)
[ 1464.092578] The buggy address belongs to the page:
[ 1464.097529] page:7fe0225f3a00 count:1 mapcount:0 
mapping:8089c0014d80 index:0x0 compound_mapcount: 0
[ 1464.107724] flags: 0x1f010200(slab|head)
[ 1464.112648] raw: 1f010200 7fe02266a408 7fe022459408 
8089c0014d80
[ 1464.120496] raw:  00050005 0001 

[ 1464.128284] page dumped because: kasan: bad access detected
[ 1464.134011] 
[ 1464.135619] Memory state around the buggy address:
[ 1464.140576]  80897ce87a00: fc fc fc fc fc fc fc fc fc fc fc fc f1 f1 f1 
f1
[ 1464.148063]  00 f2 f2 f2 f2 f2^
[ 1464.168846]7c00: f2 f2 f2 f2

BUG: KASAN: slab-out-of-bounds in try_to_unmap_one+0x1c4/0x1af0

[Qian Cai]

Compiling kernel on an aarch64 server with the latest mainline (rc2) triggered 
this,

[ 1463.931841] BUG: KASAN: slab-out-of-bounds in try_to_unmap_one+0x1c4/0x1af0
[ 1463.938969] Write of size 32 at addr 80897ce87b58 by task 
kworker/u513:0/5209
[ 1463.946678] 
[ 1463.948656] CPU: 38 PID: 5209 Comm: kworker/u513:0 Kdump: loaded Tainted: G  
  WL4.20.0-rc2+ #4
[ 1463.958485] Hardware name: HPE Apollo 70 /C01_APACHE_MB 
, BIOS L50_5.13_1.0.6 07/10/2018
[ 1463.968450] Workqueue: writeback wb_workfn (flush-253:0)
[ 1463.973848] Call trace:
[ 1463.976622]  dump_backtrace+0x0/0x2c8
[ 1463.980642] 
[ 1463.982239] Allocated by task 2:
[ 1463.985528]  kasan_kmalloc.part.1+0x40/0x108
[ 1463.989842]  kasan_kmalloc+0xb4/0xc8
[ 1463.993500]  kasan_slab_alloc+0x14/0x20
[ 1463.997630]  kmem_cache_alloc_node+0x140/0x430
[ 1464.002241]  copy_process.isra.2+0x39c/0x2e20
[ 1464.007009]  _do_fork+0x120/0xa28
[ 1464.010595]  kernel_thread+0x48/0x58
[ 1464.014206]  kthreadd+0x3dc/0x478
[ 1464.017698]  ret_from_fork+0x10/0x1c
[ 1464.021466] 
[ 1464.022981] Freed by task 1391:
[ 1464.026214]  __kasan_slab_free+0x114/0x228
[ 1464.030447]  kasan_slab_free+0x10/0x18
[ 1464.034305]  kmem_cache_free+0x9c/0x3a8
[ 1464.038284]  put_task_stack+0x94/0x110
[ 1464.042169]  finish_task_switch+0x3b0/0x488
[ 1464.046850]  __schedule+0x5e4/0xda0
[ 1464.050665]  schedule+0xdc/0x240
[ 1464.054012]  worker_thread+0x278/0xa70
[ 1464.058021]  kthread+0x1c4/0x1d0
[ 1464.061393]  ret_from_fork+0x10/0x1c
[ 1464.065051] 
[ 1464.067005] The buggy address belongs to the object at 80897ce88000
[ 1464.067005]  which belongs to the cache thread_stack of size 32768
[ 1464.080107] The buggy address is located 1192 bytes to the left of
[ 1464.080107]  32768-byte region [80897ce88000, 80897ce9)
[ 1464.092578] The buggy address belongs to the page:
[ 1464.097529] page:7fe0225f3a00 count:1 mapcount:0 
mapping:8089c0014d80 index:0x0 compound_mapcount: 0
[ 1464.107724] flags: 0x1f010200(slab|head)
[ 1464.112648] raw: 1f010200 7fe02266a408 7fe022459408 
8089c0014d80
[ 1464.120496] raw:  00050005 0001 

[ 1464.128284] page dumped because: kasan: bad access detected
[ 1464.134011] 
[ 1464.135619] Memory state around the buggy address:
[ 1464.140576]  80897ce87a00: fc fc fc fc fc fc fc fc fc fc fc fc f1 f1 f1 
f1
[ 1464.148063]  00 f2 f2 f2 f2 f2^
[ 1464.168846]7c00: f2 f2 f2 f2

[PATCH 16/25] sched/cputime: Allow to pass cputime index on user/guest accounting

[Frederic Weisbecker]

When we account user or guest cputime, we decide to add the delta either
to the nice fields or the normal fields of kcpustat and this depends on
the nice value for the task passed in parameter.

Since we are going to track the nice-ness from vtime instead, we'll need
to be able to use a different source than the task passed in parameter
on accounting time. So allow the callers of account_user/guest_time() to
pass custom kcpustat destination index fields.

Signed-off-by: Frederic Weisbecker 
Cc: Yauheni Kaliuta 
Cc: Thomas Gleixner 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Wanpeng Li 
Cc: Ingo Molnar 
---
 kernel/sched/cputime.c | 50 --
 1 file changed, 32 insertions(+), 18 deletions(-)

diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 61aa7ba..63c4f0b 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -108,6 +108,20 @@ static inline void task_group_account_field(struct 
task_struct *p, int index,
cgroup_account_cputime_field(p, index, tmp);
 }
 
+static void account_user_time_index(struct task_struct *p,
+   u64 cputime, enum cpu_usage_stat index)
+{
+   /* Add user time to process. */
+   p->utime += cputime;
+   account_group_user_time(p, cputime);
+
+   /* Add user time to cpustat. */
+   task_group_account_field(p, index, cputime);
+
+   /* Account for user time used */
+   acct_account_cputime(p);
+}
+
 /*
  * Account user CPU time to a process.
  * @p: the process that the CPU time gets accounted to
@@ -115,27 +129,14 @@ static inline void task_group_account_field(struct 
task_struct *p, int index,
  */
 void account_user_time(struct task_struct *p, u64 cputime)
 {
-   int index;
-
-   /* Add user time to process. */
-   p->utime += cputime;
-   account_group_user_time(p, cputime);
+   enum cpu_usage_stat index;
 
index = (task_nice(p) > 0) ? CPUTIME_NICE : CPUTIME_USER;
-
-   /* Add user time to cpustat. */
-   task_group_account_field(p, index, cputime);
-
-   /* Account for user time used */
-   acct_account_cputime(p);
+   account_user_time_index(p, cputime, index);
 }
 
-/*
- * Account guest CPU time to a process.
- * @p: the process that the CPU time gets accounted to
- * @cputime: the CPU time spent in virtual machine since the last update
- */
-void account_guest_time(struct task_struct *p, u64 cputime)
+static void account_guest_time_index(struct task_struct *p,
+u64 cputime, enum cpu_usage_stat index)
 {
u64 *cpustat = kcpustat_this_cpu->cpustat;
 
@@ -145,7 +146,7 @@ void account_guest_time(struct task_struct *p, u64 cputime)
p->gtime += cputime;
 
/* Add guest time to cpustat. */
-   if (task_nice(p) > 0) {
+   if (index == CPUTIME_GUEST_NICE) {
cpustat[CPUTIME_NICE] += cputime;
cpustat[CPUTIME_GUEST_NICE] += cputime;
} else {
@@ -155,6 +156,19 @@ void account_guest_time(struct task_struct *p, u64 cputime)
 }
 
 /*
+ * Account guest CPU time to a process.
+ * @p: the process that the CPU time gets accounted to
+ * @cputime: the CPU time spent in virtual machine since the last update
+ */
+void account_guest_time(struct task_struct *p, u64 cputime)
+{
+   enum cpu_usage_stat index;
+
+   index = (task_nice(p) > 0) ? CPUTIME_GUEST_NICE : CPUTIME_GUEST;
+   account_guest_time_index(p, cputime, index);
+}
+
+/*
  * Account system CPU time to a process and desired cpustat field
  * @p: the process that the CPU time gets accounted to
  * @cputime: the CPU time spent in kernel space since the last update
-- 
2.7.4

RE: scsi_set_medium_removal timeout issue

[Zengtao (B)]

Hi Alan:

>-Original Message-
>From: Alan Stern [mailto:st...@rowland.harvard.edu]
>Sent: Monday, November 12, 2018 11:33 PM
>To: Zengtao (B) 
>Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com;
>gre...@linuxfoundation.org; linux-s...@vger.kernel.org;
>linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
>usb-stor...@lists.one-eyed-alien.net
>Subject: RE: scsi_set_medium_removal timeout issue
>
>On Mon, 12 Nov 2018, Zengtao (B) wrote:
>
>> >> >Something is wrong here.  Before sending PREVENT-ALLOW
>MEDIUM
>> >> >REMOVAL, the host should issue SYNCHRONIZE CACHE.  This will
>force
>> >> >fsg_lun_fsync_sub to run, and the host should allow a long timeout
>> >> >for this command.  Then when PREVENT-ALLOW MEDIUM
>REMOVAL
>> >is sent,
>> >> >nothing will need to be flushed.
>> >> >
>> >>
>> >> Definitely, I haven't seen the SYNCHRONIZE CACHE from the host, it
>> >> directly issued the PREVENT-ALLOW MEDIUM REMOVAL, so maybe
>> >something
>> >> wrong with the scsi layer or something wrong with the mass storage
>> >class driver?
>> >
>> >Or it could be something else.  Can you please post the dmesg log
>> >from the host, showing what happens when the device is first plugged
>in?
>> >
>>
>> I have enabled the SCSI log for the host, please refer to the attachment.
>
>The log you attached was incomplete -- it was missing some commands

I just enabled the scsi log in the middle of the umount operation, otherwise I 
can't
reproduce the issue when the scsi log is enabled.

>from the beginning.  In any case, it wasn't what I wanted.  I asked you to
>post the dmesg log, not the SCSI log.

Please refer to the new attachment for dmesg log.

Thanks 
Zengtao 

~ # dmesg 
Booting Linux on physical CPU 0x0
Linux version 4.9.37 (lpcheng@osdrv) (gcc version 6.3.0 (HC 
V100R002C00B021_20180917) ) #5 SMP Mon Nov 12 19:35:04 HKT 2018
CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
CPU: div instructions available: patching division code
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt:Machine model: Hisilicon Hi3519AV100 SMP Board
cma: dma_contiguous_reserve(limit )
cma: dma_contiguous_reserve: reserving 16 MiB for global area
cma: cma_declare_contiguous(size 0x0100, base 0x, limit 0x 
alignment 0x)
cma: Reserved 16 MiB at 0x3100
Memory policy: Data cache writealloc
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c092d580, node_mem_map cedf1000
  Normal zone: 512 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 65536 pages, LIFO batch:15
percpu: Embedded 13 pages/cpu @cedc6000 s22028 r8192 d23028 u53248
pcpu-alloc: s22028 r8192 d23028 u53248 alloc=13*4096
pcpu-alloc: [0] 0 [0] 1 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: mem=256M console=ttyAMA0,115200 clk_ignore_unused 
root=/dev/mtdblock2 rw rootfstype=yaffs2 
mtdparts=hinand:1M(boot),4M(kernel),60M(rootfs) nosmp
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 234544K/262144K available (5120K kernel code, 184K rwdata, 1368K 
rodata, 1024K init, 321K bss, 11216K reserved, 16384K cma-reserved, 0K highmem)
Virtual kernel memory layout:
vector  : 0x - 0x1000   (   4 kB)
fixmap  : 0xffc0 - 0xfff0   (3072 kB)
vmalloc : 0xd080 - 0xff80   ( 752 MB)
lowmem  : 0xc000 - 0xd000   ( 256 MB)
pkmap   : 0xbfe0 - 0xc000   (   2 MB)
modules : 0xbf00 - 0xbfe0   (  14 MB)
  .text : 0xc0008000 - 0xc060   (6112 kB)
  .init : 0xc080 - 0xc090   (1024 kB)
  .data : 0xc090 - 0xc092e180   ( 185 kB)
   .bss : 0xc093 - 0xc098072c   ( 322 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Hierarchical RCU implementation.
Build-time adjustment of leaf fanout to 32.
RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
NR_IRQS:16 nr_irqs:16 16
arm_arch_timer: Architected cp15 timer(s) running at 24.00MHz (phys).
clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x588fe9dc0, 
max_idle_ns: 440795202592 ns
sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
Switching to timer-based delay loop, resolution 41ns
clocksource: hisp804: mask: 0x max_cycles: 0x, max_idle_ns: 
637086815595 ns
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 
48.00 BogoMIPS (lpj=12)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 8000
Setting up static identity map for 0x2210 - 0x22100058
Brought up 1 

[PATCH 16/25] sched/cputime: Allow to pass cputime index on user/guest accounting

[Frederic Weisbecker]

When we account user or guest cputime, we decide to add the delta either
to the nice fields or the normal fields of kcpustat and this depends on
the nice value for the task passed in parameter.

Since we are going to track the nice-ness from vtime instead, we'll need
to be able to use a different source than the task passed in parameter
on accounting time. So allow the callers of account_user/guest_time() to
pass custom kcpustat destination index fields.

Signed-off-by: Frederic Weisbecker 
Cc: Yauheni Kaliuta 
Cc: Thomas Gleixner 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Wanpeng Li 
Cc: Ingo Molnar 
---
 kernel/sched/cputime.c | 50 --
 1 file changed, 32 insertions(+), 18 deletions(-)

diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 61aa7ba..63c4f0b 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -108,6 +108,20 @@ static inline void task_group_account_field(struct 
task_struct *p, int index,
cgroup_account_cputime_field(p, index, tmp);
 }
 
+static void account_user_time_index(struct task_struct *p,
+   u64 cputime, enum cpu_usage_stat index)
+{
+   /* Add user time to process. */
+   p->utime += cputime;
+   account_group_user_time(p, cputime);
+
+   /* Add user time to cpustat. */
+   task_group_account_field(p, index, cputime);
+
+   /* Account for user time used */
+   acct_account_cputime(p);
+}
+
 /*
  * Account user CPU time to a process.
  * @p: the process that the CPU time gets accounted to
@@ -115,27 +129,14 @@ static inline void task_group_account_field(struct 
task_struct *p, int index,
  */
 void account_user_time(struct task_struct *p, u64 cputime)
 {
-   int index;
-
-   /* Add user time to process. */
-   p->utime += cputime;
-   account_group_user_time(p, cputime);
+   enum cpu_usage_stat index;
 
index = (task_nice(p) > 0) ? CPUTIME_NICE : CPUTIME_USER;
-
-   /* Add user time to cpustat. */
-   task_group_account_field(p, index, cputime);
-
-   /* Account for user time used */
-   acct_account_cputime(p);
+   account_user_time_index(p, cputime, index);
 }
 
-/*
- * Account guest CPU time to a process.
- * @p: the process that the CPU time gets accounted to
- * @cputime: the CPU time spent in virtual machine since the last update
- */
-void account_guest_time(struct task_struct *p, u64 cputime)
+static void account_guest_time_index(struct task_struct *p,
+u64 cputime, enum cpu_usage_stat index)
 {
u64 *cpustat = kcpustat_this_cpu->cpustat;
 
@@ -145,7 +146,7 @@ void account_guest_time(struct task_struct *p, u64 cputime)
p->gtime += cputime;
 
/* Add guest time to cpustat. */
-   if (task_nice(p) > 0) {
+   if (index == CPUTIME_GUEST_NICE) {
cpustat[CPUTIME_NICE] += cputime;
cpustat[CPUTIME_GUEST_NICE] += cputime;
} else {
@@ -155,6 +156,19 @@ void account_guest_time(struct task_struct *p, u64 cputime)
 }
 
 /*
+ * Account guest CPU time to a process.
+ * @p: the process that the CPU time gets accounted to
+ * @cputime: the CPU time spent in virtual machine since the last update
+ */
+void account_guest_time(struct task_struct *p, u64 cputime)
+{
+   enum cpu_usage_stat index;
+
+   index = (task_nice(p) > 0) ? CPUTIME_GUEST_NICE : CPUTIME_GUEST;
+   account_guest_time_index(p, cputime, index);
+}
+
+/*
  * Account system CPU time to a process and desired cpustat field
  * @p: the process that the CPU time gets accounted to
  * @cputime: the CPU time spent in kernel space since the last update
-- 
2.7.4

RE: scsi_set_medium_removal timeout issue

[Zengtao (B)]

Hi Alan:

>-Original Message-
>From: Alan Stern [mailto:st...@rowland.harvard.edu]
>Sent: Monday, November 12, 2018 11:33 PM
>To: Zengtao (B) 
>Cc: j...@linux.vnet.ibm.com; martin.peter...@oracle.com;
>gre...@linuxfoundation.org; linux-s...@vger.kernel.org;
>linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
>usb-stor...@lists.one-eyed-alien.net
>Subject: RE: scsi_set_medium_removal timeout issue
>
>On Mon, 12 Nov 2018, Zengtao (B) wrote:
>
>> >> >Something is wrong here.  Before sending PREVENT-ALLOW
>MEDIUM
>> >> >REMOVAL, the host should issue SYNCHRONIZE CACHE.  This will
>force
>> >> >fsg_lun_fsync_sub to run, and the host should allow a long timeout
>> >> >for this command.  Then when PREVENT-ALLOW MEDIUM
>REMOVAL
>> >is sent,
>> >> >nothing will need to be flushed.
>> >> >
>> >>
>> >> Definitely, I haven't seen the SYNCHRONIZE CACHE from the host, it
>> >> directly issued the PREVENT-ALLOW MEDIUM REMOVAL, so maybe
>> >something
>> >> wrong with the scsi layer or something wrong with the mass storage
>> >class driver?
>> >
>> >Or it could be something else.  Can you please post the dmesg log
>> >from the host, showing what happens when the device is first plugged
>in?
>> >
>>
>> I have enabled the SCSI log for the host, please refer to the attachment.
>
>The log you attached was incomplete -- it was missing some commands

I just enabled the scsi log in the middle of the umount operation, otherwise I 
can't
reproduce the issue when the scsi log is enabled.

>from the beginning.  In any case, it wasn't what I wanted.  I asked you to
>post the dmesg log, not the SCSI log.

Please refer to the new attachment for dmesg log.

Thanks 
Zengtao 

~ # dmesg 
Booting Linux on physical CPU 0x0
Linux version 4.9.37 (lpcheng@osdrv) (gcc version 6.3.0 (HC 
V100R002C00B021_20180917) ) #5 SMP Mon Nov 12 19:35:04 HKT 2018
CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
CPU: div instructions available: patching division code
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt:Machine model: Hisilicon Hi3519AV100 SMP Board
cma: dma_contiguous_reserve(limit )
cma: dma_contiguous_reserve: reserving 16 MiB for global area
cma: cma_declare_contiguous(size 0x0100, base 0x, limit 0x 
alignment 0x)
cma: Reserved 16 MiB at 0x3100
Memory policy: Data cache writealloc
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c092d580, node_mem_map cedf1000
  Normal zone: 512 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 65536 pages, LIFO batch:15
percpu: Embedded 13 pages/cpu @cedc6000 s22028 r8192 d23028 u53248
pcpu-alloc: s22028 r8192 d23028 u53248 alloc=13*4096
pcpu-alloc: [0] 0 [0] 1 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: mem=256M console=ttyAMA0,115200 clk_ignore_unused 
root=/dev/mtdblock2 rw rootfstype=yaffs2 
mtdparts=hinand:1M(boot),4M(kernel),60M(rootfs) nosmp
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 234544K/262144K available (5120K kernel code, 184K rwdata, 1368K 
rodata, 1024K init, 321K bss, 11216K reserved, 16384K cma-reserved, 0K highmem)
Virtual kernel memory layout:
vector  : 0x - 0x1000   (   4 kB)
fixmap  : 0xffc0 - 0xfff0   (3072 kB)
vmalloc : 0xd080 - 0xff80   ( 752 MB)
lowmem  : 0xc000 - 0xd000   ( 256 MB)
pkmap   : 0xbfe0 - 0xc000   (   2 MB)
modules : 0xbf00 - 0xbfe0   (  14 MB)
  .text : 0xc0008000 - 0xc060   (6112 kB)
  .init : 0xc080 - 0xc090   (1024 kB)
  .data : 0xc090 - 0xc092e180   ( 185 kB)
   .bss : 0xc093 - 0xc098072c   ( 322 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Hierarchical RCU implementation.
Build-time adjustment of leaf fanout to 32.
RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
NR_IRQS:16 nr_irqs:16 16
arm_arch_timer: Architected cp15 timer(s) running at 24.00MHz (phys).
clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x588fe9dc0, 
max_idle_ns: 440795202592 ns
sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
Switching to timer-based delay loop, resolution 41ns
clocksource: hisp804: mask: 0x max_cycles: 0x, max_idle_ns: 
637086815595 ns
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 
48.00 BogoMIPS (lpj=12)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 8000
Setting up static identity map for 0x2210 - 0x22100058
Brought up 1 

[PATCH 23/25] leds: Use vtime aware kcpustat accessors

[Frederic Weisbecker]

Now that we have a vtime safe kcpustat accessor, use it to fix frozen
kcpustat values on nohz_full CPUs.

Reported-by: Yauheni Kaliuta 
Signed-off-by: Frederic Weisbecker 
Cc: Yauheni Kaliuta 
Cc: Thomas Gleixner 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Wanpeng Li 
Cc: Ingo Molnar 
---
 drivers/leds/trigger/ledtrig-activity.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/leds/trigger/ledtrig-activity.c 
b/drivers/leds/trigger/ledtrig-activity.c
index bcbf41c..b4a1f66 100644
--- a/drivers/leds/trigger/ledtrig-activity.c
+++ b/drivers/leds/trigger/ledtrig-activity.c
@@ -60,9 +60,12 @@ static void led_activity_function(struct timer_list *t)
curr_used = 0;
 
for_each_possible_cpu(i) {
-   curr_used += kcpustat_cpu(i).cpustat[CPUTIME_USER]
- +  kcpustat_cpu(i).cpustat[CPUTIME_NICE]
- +  kcpustat_cpu(i).cpustat[CPUTIME_SYSTEM]
+   u64 user, nice, sys, guest, guest_nice;
+
+   kcpustat_cputime(_cpu(i), i, , , ,
+, _nice);
+
+   curr_used += user + nice + sys
  +  kcpustat_cpu(i).cpustat[CPUTIME_SOFTIRQ]
  +  kcpustat_cpu(i).cpustat[CPUTIME_IRQ];
cpus++;
-- 
2.7.4

[PATCH 24/25] rackmeter: Use vtime aware kcpustat accessors

[Frederic Weisbecker]

Now that we have a vtime safe kcpustat accessor, use it to fix frozen
kcpustat values on nohz_full CPUs.

Reported-by: Yauheni Kaliuta 
Signed-off-by: Frederic Weisbecker 
Cc: Yauheni Kaliuta 
Cc: Thomas Gleixner 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Wanpeng Li 
Cc: Ingo Molnar 
---
 drivers/macintosh/rack-meter.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/macintosh/rack-meter.c b/drivers/macintosh/rack-meter.c
index 1f29d24..1936e0ec 100644
--- a/drivers/macintosh/rack-meter.c
+++ b/drivers/macintosh/rack-meter.c
@@ -83,13 +83,19 @@ static int rackmeter_ignore_nice;
  */
 static inline u64 get_cpu_idle_time(unsigned int cpu)
 {
+   struct kernel_cpustat *kcpustat = _cpu(cpu);
u64 retval;
 
-   retval = kcpustat_cpu(cpu).cpustat[CPUTIME_IDLE] +
-kcpustat_cpu(cpu).cpustat[CPUTIME_IOWAIT];
+   retval = kcpustat->cpustat[CPUTIME_IDLE] +
+kcpustat->cpustat[CPUTIME_IOWAIT];
 
-   if (rackmeter_ignore_nice)
-   retval += kcpustat_cpu(cpu).cpustat[CPUTIME_NICE];
+   if (rackmeter_ignore_nice) {
+   u64 user, nice, sys, guest, guest_nice;
+
+   kcpustat_cputime(kcpustat, cpu, , , ,
+, _nice);
+   retval += nice;
+   }
 
return retval;
 }
-- 
2.7.4

[PATCH 25/25] sched/vtime: Clarify vtime_task_switch() argument layout

[Frederic Weisbecker]

This function deals with the previous and next tasks during a context
switch. But only the previous is passed as an argument, the next task
being deduced from current. Make the code clearer by passing both
previous and next as arguments.

Signed-off-by: Frederic Weisbecker 
Cc: Yauheni Kaliuta 
Cc: Thomas Gleixner 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Wanpeng Li 
Cc: Ingo Molnar 
---
 arch/ia64/include/asm/cputime.h|  3 ++-
 arch/ia64/kernel/time.c|  5 +++--
 arch/powerpc/include/asm/cputime.h |  8 +---
 arch/s390/kernel/vtime.c   | 13 +++--
 include/linux/vtime.h  | 17 +++--
 kernel/sched/core.c|  2 +-
 kernel/sched/cputime.c | 18 ++
 7 files changed, 39 insertions(+), 27 deletions(-)

diff --git a/arch/ia64/include/asm/cputime.h b/arch/ia64/include/asm/cputime.h
index 3d665c0..0bc90a1 100644
--- a/arch/ia64/include/asm/cputime.h
+++ b/arch/ia64/include/asm/cputime.h
@@ -19,7 +19,8 @@
 #define __IA64_CPUTIME_H
 
 #ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
-extern void arch_vtime_task_switch(struct task_struct *tsk);
+extern void arch_vtime_task_switch(struct task_struct *prev,
+  struct task_struct *next);
 #endif /* CONFIG_VIRT_CPU_ACCOUNTING_NATIVE */
 
 #endif /* __IA64_CPUTIME_H */
diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c
index 46a9798..908bd4f 100644
--- a/arch/ia64/kernel/time.c
+++ b/arch/ia64/kernel/time.c
@@ -105,10 +105,11 @@ void vtime_flush(struct task_struct *tsk)
  * accumulated times to the current process, and to prepare accounting on
  * the next process.
  */
-void arch_vtime_task_switch(struct task_struct *prev)
+void arch_vtime_task_switch(struct task_struct *prev,
+   struct task_struct *next)
 {
struct thread_info *pi = task_thread_info(prev);
-   struct thread_info *ni = task_thread_info(current);
+   struct thread_info *ni = task_thread_info(next);
 
ni->ac_stamp = pi->ac_stamp;
ni->ac_stime = ni->ac_utime = 0;
diff --git a/arch/powerpc/include/asm/cputime.h 
b/arch/powerpc/include/asm/cputime.h
index ae73dc8..9d68040 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -47,7 +47,8 @@ static inline unsigned long cputime_to_usecs(const cputime_t 
ct)
  */
 #ifdef CONFIG_PPC64
 #define get_accounting(tsk)(_paca()->accounting)
-static inline void arch_vtime_task_switch(struct task_struct *tsk) { }
+static inline void arch_vtime_task_switch(struct task_struct *prev,
+ struct task_struct *next) { }
 #else
 #define get_accounting(tsk)(_thread_info(tsk)->accounting)
 /*
@@ -55,9 +56,10 @@ static inline void arch_vtime_task_switch(struct task_struct 
*tsk) { }
  * accumulated times to the current process, and to prepare accounting on
  * the next process.
  */
-static inline void arch_vtime_task_switch(struct task_struct *prev)
+static inline void arch_vtime_task_switch(struct task_struct *prev,
+ struct task_struct *next)
 {
-   struct cpu_accounting_data *acct = get_accounting(current);
+   struct cpu_accounting_data *acct = get_accounting(next);
struct cpu_accounting_data *acct0 = get_accounting(prev);
 
acct->starttime = acct0->starttime;
diff --git a/arch/s390/kernel/vtime.c b/arch/s390/kernel/vtime.c
index b6b888d..fcfeb63 100644
--- a/arch/s390/kernel/vtime.c
+++ b/arch/s390/kernel/vtime.c
@@ -191,7 +191,8 @@ static int do_account_vtime(struct task_struct *tsk)
return virt_timer_forward(user + guest + system + hardirq + softirq);
 }
 
-void vtime_task_switch(struct task_struct *prev)
+void vtime_task_switch(struct task_struct *prev,
+  struct task_struct *next)
 {
do_account_vtime(prev);
prev->thread.user_timer = S390_lowcore.user_timer;
@@ -199,11 +200,11 @@ void vtime_task_switch(struct task_struct *prev)
prev->thread.system_timer = S390_lowcore.system_timer;
prev->thread.hardirq_timer = S390_lowcore.hardirq_timer;
prev->thread.softirq_timer = S390_lowcore.softirq_timer;
-   S390_lowcore.user_timer = current->thread.user_timer;
-   S390_lowcore.guest_timer = current->thread.guest_timer;
-   S390_lowcore.system_timer = current->thread.system_timer;
-   S390_lowcore.hardirq_timer = current->thread.hardirq_timer;
-   S390_lowcore.softirq_timer = current->thread.softirq_timer;
+   S390_lowcore.user_timer = next->thread.user_timer;
+   S390_lowcore.guest_timer = next->thread.guest_timer;
+   S390_lowcore.system_timer = next->thread.system_timer;
+   S390_lowcore.hardirq_timer = next->thread.hardirq_timer;
+   S390_lowcore.softirq_timer = next->thread.softirq_timer;
 }
 
 /*
diff --git a/include/linux/vtime.h b/include/linux/vtime.h
index b4566d5..188eace 100644
--- a/include/linux/vtime.h
+++ b/include/linux/vtime.h

[PATCH 22/25] cpufreq: Use vtime aware kcpustat accessor

[Frederic Weisbecker]

Now that we have a vtime safe kcpustat accessor, use it to fix frozen
kcpustat values on nohz_full CPUs.

Reported-by: Yauheni Kaliuta 
Signed-off-by: Frederic Weisbecker 
Cc: Yauheni Kaliuta 
Cc: Thomas Gleixner 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Wanpeng Li 
Cc: Ingo Molnar 
---
 drivers/cpufreq/cpufreq.c  | 18 +++---
 drivers/cpufreq/cpufreq_governor.c | 27 ---
 2 files changed, 31 insertions(+), 14 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 7aa3dca..e9cff3f 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -119,18 +119,22 @@ EXPORT_SYMBOL_GPL(get_governor_parent_kobj);
 
 static inline u64 get_cpu_idle_time_jiffy(unsigned int cpu, u64 *wall)
 {
-   u64 idle_time;
+   struct kernel_cpustat *kcpustat = _cpu(cpu);
+   u64 user, nice, sys, guest, guest_nice;
u64 cur_wall_time;
+   u64 idle_time;
u64 busy_time;
 
cur_wall_time = jiffies64_to_nsecs(get_jiffies_64());
 
-   busy_time = kcpustat_cpu(cpu).cpustat[CPUTIME_USER];
-   busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_SYSTEM];
-   busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_IRQ];
-   busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_SOFTIRQ];
-   busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_STEAL];
-   busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_NICE];
+   kcpustat_cputime(kcpustat, cpu, , , ,
+, _nice);
+   busy_time = user;
+   busy_time += sys;
+   busy_time += kcpustat->cpustat[CPUTIME_IRQ];
+   busy_time += kcpustat->cpustat[CPUTIME_SOFTIRQ];
+   busy_time += kcpustat->cpustat[CPUTIME_STEAL];
+   busy_time += nice;
 
idle_time = cur_wall_time - busy_time;
if (wall)
diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index 6d53f7d..5ebe726 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -107,8 +107,13 @@ void gov_update_cpu_data(struct dbs_data *dbs_data)
 
j_cdbs->prev_cpu_idle = get_cpu_idle_time(j, 
_cdbs->prev_update_time,
  
dbs_data->io_is_busy);
-   if (dbs_data->ignore_nice_load)
-   j_cdbs->prev_cpu_nice = 
kcpustat_cpu(j).cpustat[CPUTIME_NICE];
+   if (dbs_data->ignore_nice_load) {
+   u64 user, nice, sys, guest, guest_nice;
+
+   kcpustat_cputime(_cpu(j), j, , 
, ,
+, _nice);
+   j_cdbs->prev_cpu_nice = nice;
+   }
}
}
 }
@@ -152,10 +157,13 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
j_cdbs->prev_cpu_idle = cur_idle_time;
 
if (ignore_nice) {
-   u64 cur_nice = kcpustat_cpu(j).cpustat[CPUTIME_NICE];
+   u64 user, nice, sys, guest, guest_nice;
 
-   idle_time += div_u64(cur_nice - j_cdbs->prev_cpu_nice, 
NSEC_PER_USEC);
-   j_cdbs->prev_cpu_nice = cur_nice;
+   kcpustat_cputime(_cpu(j), j, , , 
,
+, _nice);
+
+   idle_time += div_u64(nice - j_cdbs->prev_cpu_nice, 
NSEC_PER_USEC);
+   j_cdbs->prev_cpu_nice = nice;
}
 
if (unlikely(!time_elapsed)) {
@@ -530,8 +538,13 @@ int cpufreq_dbs_governor_start(struct cpufreq_policy 
*policy)
 */
j_cdbs->prev_load = 0;
 
-   if (ignore_nice)
-   j_cdbs->prev_cpu_nice = 
kcpustat_cpu(j).cpustat[CPUTIME_NICE];
+   if (ignore_nice) {
+   u64 user, nice, sys, guest, guest_nice;
+
+   kcpustat_cputime(_cpu(j), j, , , 
,
+, _nice);
+   j_cdbs->prev_cpu_nice = nice;
+   }
}
 
gov->start(policy);
-- 
2.7.4

[PATCH 23/25] leds: Use vtime aware kcpustat accessors

[Frederic Weisbecker]

Now that we have a vtime safe kcpustat accessor, use it to fix frozen
kcpustat values on nohz_full CPUs.

Reported-by: Yauheni Kaliuta 
Signed-off-by: Frederic Weisbecker 
Cc: Yauheni Kaliuta 
Cc: Thomas Gleixner 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Wanpeng Li 
Cc: Ingo Molnar 
---
 drivers/leds/trigger/ledtrig-activity.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/leds/trigger/ledtrig-activity.c 
b/drivers/leds/trigger/ledtrig-activity.c
index bcbf41c..b4a1f66 100644
--- a/drivers/leds/trigger/ledtrig-activity.c
+++ b/drivers/leds/trigger/ledtrig-activity.c
@@ -60,9 +60,12 @@ static void led_activity_function(struct timer_list *t)
curr_used = 0;
 
for_each_possible_cpu(i) {
-   curr_used += kcpustat_cpu(i).cpustat[CPUTIME_USER]
- +  kcpustat_cpu(i).cpustat[CPUTIME_NICE]
- +  kcpustat_cpu(i).cpustat[CPUTIME_SYSTEM]
+   u64 user, nice, sys, guest, guest_nice;
+
+   kcpustat_cputime(_cpu(i), i, , , ,
+, _nice);
+
+   curr_used += user + nice + sys
  +  kcpustat_cpu(i).cpustat[CPUTIME_SOFTIRQ]
  +  kcpustat_cpu(i).cpustat[CPUTIME_IRQ];
cpus++;
-- 
2.7.4

[PATCH 24/25] rackmeter: Use vtime aware kcpustat accessors

[Frederic Weisbecker]

Now that we have a vtime safe kcpustat accessor, use it to fix frozen
kcpustat values on nohz_full CPUs.

Reported-by: Yauheni Kaliuta 
Signed-off-by: Frederic Weisbecker 
Cc: Yauheni Kaliuta 
Cc: Thomas Gleixner 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Wanpeng Li 
Cc: Ingo Molnar 
---
 drivers/macintosh/rack-meter.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/macintosh/rack-meter.c b/drivers/macintosh/rack-meter.c
index 1f29d24..1936e0ec 100644
--- a/drivers/macintosh/rack-meter.c
+++ b/drivers/macintosh/rack-meter.c
@@ -83,13 +83,19 @@ static int rackmeter_ignore_nice;
  */
 static inline u64 get_cpu_idle_time(unsigned int cpu)
 {
+   struct kernel_cpustat *kcpustat = _cpu(cpu);
u64 retval;
 
-   retval = kcpustat_cpu(cpu).cpustat[CPUTIME_IDLE] +
-kcpustat_cpu(cpu).cpustat[CPUTIME_IOWAIT];
+   retval = kcpustat->cpustat[CPUTIME_IDLE] +
+kcpustat->cpustat[CPUTIME_IOWAIT];
 
-   if (rackmeter_ignore_nice)
-   retval += kcpustat_cpu(cpu).cpustat[CPUTIME_NICE];
+   if (rackmeter_ignore_nice) {
+   u64 user, nice, sys, guest, guest_nice;
+
+   kcpustat_cputime(kcpustat, cpu, , , ,
+, _nice);
+   retval += nice;
+   }
 
return retval;
 }
-- 
2.7.4

[PATCH 25/25] sched/vtime: Clarify vtime_task_switch() argument layout

[Frederic Weisbecker]

This function deals with the previous and next tasks during a context
switch. But only the previous is passed as an argument, the next task
being deduced from current. Make the code clearer by passing both
previous and next as arguments.

Signed-off-by: Frederic Weisbecker 
Cc: Yauheni Kaliuta 
Cc: Thomas Gleixner 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Wanpeng Li 
Cc: Ingo Molnar 
---
 arch/ia64/include/asm/cputime.h|  3 ++-
 arch/ia64/kernel/time.c|  5 +++--
 arch/powerpc/include/asm/cputime.h |  8 +---
 arch/s390/kernel/vtime.c   | 13 +++--
 include/linux/vtime.h  | 17 +++--
 kernel/sched/core.c|  2 +-
 kernel/sched/cputime.c | 18 ++
 7 files changed, 39 insertions(+), 27 deletions(-)

diff --git a/arch/ia64/include/asm/cputime.h b/arch/ia64/include/asm/cputime.h
index 3d665c0..0bc90a1 100644
--- a/arch/ia64/include/asm/cputime.h
+++ b/arch/ia64/include/asm/cputime.h
@@ -19,7 +19,8 @@
 #define __IA64_CPUTIME_H
 
 #ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
-extern void arch_vtime_task_switch(struct task_struct *tsk);
+extern void arch_vtime_task_switch(struct task_struct *prev,
+  struct task_struct *next);
 #endif /* CONFIG_VIRT_CPU_ACCOUNTING_NATIVE */
 
 #endif /* __IA64_CPUTIME_H */
diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c
index 46a9798..908bd4f 100644
--- a/arch/ia64/kernel/time.c
+++ b/arch/ia64/kernel/time.c
@@ -105,10 +105,11 @@ void vtime_flush(struct task_struct *tsk)
  * accumulated times to the current process, and to prepare accounting on
  * the next process.
  */
-void arch_vtime_task_switch(struct task_struct *prev)
+void arch_vtime_task_switch(struct task_struct *prev,
+   struct task_struct *next)
 {
struct thread_info *pi = task_thread_info(prev);
-   struct thread_info *ni = task_thread_info(current);
+   struct thread_info *ni = task_thread_info(next);
 
ni->ac_stamp = pi->ac_stamp;
ni->ac_stime = ni->ac_utime = 0;
diff --git a/arch/powerpc/include/asm/cputime.h 
b/arch/powerpc/include/asm/cputime.h
index ae73dc8..9d68040 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
@@ -47,7 +47,8 @@ static inline unsigned long cputime_to_usecs(const cputime_t 
ct)
  */
 #ifdef CONFIG_PPC64
 #define get_accounting(tsk)(_paca()->accounting)
-static inline void arch_vtime_task_switch(struct task_struct *tsk) { }
+static inline void arch_vtime_task_switch(struct task_struct *prev,
+ struct task_struct *next) { }
 #else
 #define get_accounting(tsk)(_thread_info(tsk)->accounting)
 /*
@@ -55,9 +56,10 @@ static inline void arch_vtime_task_switch(struct task_struct 
*tsk) { }
  * accumulated times to the current process, and to prepare accounting on
  * the next process.
  */
-static inline void arch_vtime_task_switch(struct task_struct *prev)
+static inline void arch_vtime_task_switch(struct task_struct *prev,
+ struct task_struct *next)
 {
-   struct cpu_accounting_data *acct = get_accounting(current);
+   struct cpu_accounting_data *acct = get_accounting(next);
struct cpu_accounting_data *acct0 = get_accounting(prev);
 
acct->starttime = acct0->starttime;
diff --git a/arch/s390/kernel/vtime.c b/arch/s390/kernel/vtime.c
index b6b888d..fcfeb63 100644
--- a/arch/s390/kernel/vtime.c
+++ b/arch/s390/kernel/vtime.c
@@ -191,7 +191,8 @@ static int do_account_vtime(struct task_struct *tsk)
return virt_timer_forward(user + guest + system + hardirq + softirq);
 }
 
-void vtime_task_switch(struct task_struct *prev)
+void vtime_task_switch(struct task_struct *prev,
+  struct task_struct *next)
 {
do_account_vtime(prev);
prev->thread.user_timer = S390_lowcore.user_timer;
@@ -199,11 +200,11 @@ void vtime_task_switch(struct task_struct *prev)
prev->thread.system_timer = S390_lowcore.system_timer;
prev->thread.hardirq_timer = S390_lowcore.hardirq_timer;
prev->thread.softirq_timer = S390_lowcore.softirq_timer;
-   S390_lowcore.user_timer = current->thread.user_timer;
-   S390_lowcore.guest_timer = current->thread.guest_timer;
-   S390_lowcore.system_timer = current->thread.system_timer;
-   S390_lowcore.hardirq_timer = current->thread.hardirq_timer;
-   S390_lowcore.softirq_timer = current->thread.softirq_timer;
+   S390_lowcore.user_timer = next->thread.user_timer;
+   S390_lowcore.guest_timer = next->thread.guest_timer;
+   S390_lowcore.system_timer = next->thread.system_timer;
+   S390_lowcore.hardirq_timer = next->thread.hardirq_timer;
+   S390_lowcore.softirq_timer = next->thread.softirq_timer;
 }
 
 /*
diff --git a/include/linux/vtime.h b/include/linux/vtime.h
index b4566d5..188eace 100644
--- a/include/linux/vtime.h
+++ b/include/linux/vtime.h

[PATCH 22/25] cpufreq: Use vtime aware kcpustat accessor

[Frederic Weisbecker]

Now that we have a vtime safe kcpustat accessor, use it to fix frozen
kcpustat values on nohz_full CPUs.

Reported-by: Yauheni Kaliuta 
Signed-off-by: Frederic Weisbecker 
Cc: Yauheni Kaliuta 
Cc: Thomas Gleixner 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Wanpeng Li 
Cc: Ingo Molnar 
---
 drivers/cpufreq/cpufreq.c  | 18 +++---
 drivers/cpufreq/cpufreq_governor.c | 27 ---
 2 files changed, 31 insertions(+), 14 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 7aa3dca..e9cff3f 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -119,18 +119,22 @@ EXPORT_SYMBOL_GPL(get_governor_parent_kobj);
 
 static inline u64 get_cpu_idle_time_jiffy(unsigned int cpu, u64 *wall)
 {
-   u64 idle_time;
+   struct kernel_cpustat *kcpustat = _cpu(cpu);
+   u64 user, nice, sys, guest, guest_nice;
u64 cur_wall_time;
+   u64 idle_time;
u64 busy_time;
 
cur_wall_time = jiffies64_to_nsecs(get_jiffies_64());
 
-   busy_time = kcpustat_cpu(cpu).cpustat[CPUTIME_USER];
-   busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_SYSTEM];
-   busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_IRQ];
-   busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_SOFTIRQ];
-   busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_STEAL];
-   busy_time += kcpustat_cpu(cpu).cpustat[CPUTIME_NICE];
+   kcpustat_cputime(kcpustat, cpu, , , ,
+, _nice);
+   busy_time = user;
+   busy_time += sys;
+   busy_time += kcpustat->cpustat[CPUTIME_IRQ];
+   busy_time += kcpustat->cpustat[CPUTIME_SOFTIRQ];
+   busy_time += kcpustat->cpustat[CPUTIME_STEAL];
+   busy_time += nice;
 
idle_time = cur_wall_time - busy_time;
if (wall)
diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index 6d53f7d..5ebe726 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -107,8 +107,13 @@ void gov_update_cpu_data(struct dbs_data *dbs_data)
 
j_cdbs->prev_cpu_idle = get_cpu_idle_time(j, 
_cdbs->prev_update_time,
  
dbs_data->io_is_busy);
-   if (dbs_data->ignore_nice_load)
-   j_cdbs->prev_cpu_nice = 
kcpustat_cpu(j).cpustat[CPUTIME_NICE];
+   if (dbs_data->ignore_nice_load) {
+   u64 user, nice, sys, guest, guest_nice;
+
+   kcpustat_cputime(_cpu(j), j, , 
, ,
+, _nice);
+   j_cdbs->prev_cpu_nice = nice;
+   }
}
}
 }
@@ -152,10 +157,13 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
j_cdbs->prev_cpu_idle = cur_idle_time;
 
if (ignore_nice) {
-   u64 cur_nice = kcpustat_cpu(j).cpustat[CPUTIME_NICE];
+   u64 user, nice, sys, guest, guest_nice;
 
-   idle_time += div_u64(cur_nice - j_cdbs->prev_cpu_nice, 
NSEC_PER_USEC);
-   j_cdbs->prev_cpu_nice = cur_nice;
+   kcpustat_cputime(_cpu(j), j, , , 
,
+, _nice);
+
+   idle_time += div_u64(nice - j_cdbs->prev_cpu_nice, 
NSEC_PER_USEC);
+   j_cdbs->prev_cpu_nice = nice;
}
 
if (unlikely(!time_elapsed)) {
@@ -530,8 +538,13 @@ int cpufreq_dbs_governor_start(struct cpufreq_policy 
*policy)
 */
j_cdbs->prev_load = 0;
 
-   if (ignore_nice)
-   j_cdbs->prev_cpu_nice = 
kcpustat_cpu(j).cpustat[CPUTIME_NICE];
+   if (ignore_nice) {
+   u64 user, nice, sys, guest, guest_nice;
+
+   kcpustat_cputime(_cpu(j), j, , , 
,
+, _nice);
+   j_cdbs->prev_cpu_nice = nice;
+   }
}
 
gov->start(policy);
-- 
2.7.4

[PATCH 13/25] context_tracking: Introduce context_tracking_enabled_cpu()

[Frederic Weisbecker]

This allows us to check if a remote CPU runs context tracking
(ie: is nohz_full). We'll need that to reliably support "nice"
accounting on kcpustat.

Signed-off-by: Frederic Weisbecker 
Cc: Yauheni Kaliuta 
Cc: Thomas Gleixner 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Wanpeng Li 
Cc: Ingo Molnar 
---
 include/linux/context_tracking_state.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/context_tracking_state.h 
b/include/linux/context_tracking_state.h
index 08f125f..5877177 100644
--- a/include/linux/context_tracking_state.h
+++ b/include/linux/context_tracking_state.h
@@ -31,6 +31,11 @@ static inline bool context_tracking_enabled(void)
return static_branch_unlikely(_tracking_key);
 }
 
+static inline bool context_tracking_enabled_cpu(int cpu)
+{
+   return per_cpu(context_tracking.active, cpu);
+}
+
 static inline bool context_tracking_enabled_this_cpu(void)
 {
return __this_cpu_read(context_tracking.active);
@@ -43,6 +48,7 @@ static inline bool context_tracking_in_user(void)
 #else
 static inline bool context_tracking_in_user(void) { return false; }
 static inline bool context_tracking_enabled(void) { return false; }
+static inline bool context_tracking_enabled_cpu(int cpu) { return false; }
 static inline bool context_tracking_enabled_this_cpu(void) { return false; }
 #endif /* CONFIG_CONTEXT_TRACKING */
 
-- 
2.7.4

[PATCH 17/25] sched/cputime: Standardize the kcpustat index based accounting functions

[Frederic Weisbecker]

Sanitize a bit the functions that do cputime accounting with custom
kcpustat indexes:

* Rename account_system_index_time() to account_system_time_index() to
  comply with account_guest/user_time_index()

* Use proper enum cpu_usage_stat type in account_system_time()

* Reorder task_group_account_field() parameters to comply with those of
  account_*_time_index().

* Rename task_group_account_field()'s tmp parameter to cputime

* Precise the type of index in task_group_account_field(): enum cpu_usage_stat

Signed-off-by: Frederic Weisbecker 
Cc: Yauheni Kaliuta 
Cc: Thomas Gleixner 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Wanpeng Li 
Cc: Ingo Molnar 
---
 arch/ia64/kernel/time.c |  6 +++---
 arch/powerpc/kernel/time.c  |  6 +++---
 arch/s390/kernel/vtime.c|  2 +-
 include/linux/kernel_stat.h |  2 +-
 kernel/sched/cputime.c  | 22 +++---
 5 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c
index a3b09ea..46a9798 100644
--- a/arch/ia64/kernel/time.c
+++ b/arch/ia64/kernel/time.c
@@ -79,17 +79,17 @@ void vtime_flush(struct task_struct *tsk)
 
if (ti->stime) {
delta = cycle_to_nsec(ti->stime);
-   account_system_index_time(tsk, delta, CPUTIME_SYSTEM);
+   account_system_time_index(tsk, delta, CPUTIME_SYSTEM);
}
 
if (ti->hardirq_time) {
delta = cycle_to_nsec(ti->hardirq_time);
-   account_system_index_time(tsk, delta, CPUTIME_IRQ);
+   account_system_time_index(tsk, delta, CPUTIME_IRQ);
}
 
if (ti->softirq_time) {
delta = cycle_to_nsec(ti->softirq_time);
-   account_system_index_time(tsk, delta, CPUTIME_SOFTIRQ);
+   account_system_time_index(tsk, delta, CPUTIME_SOFTIRQ);
}
 
ti->utime = 0;
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index cc591a4..6e6e0c8 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -422,14 +422,14 @@ void vtime_flush(struct task_struct *tsk)
account_idle_time(cputime_to_nsecs(acct->idle_time));
 
if (acct->stime)
-   account_system_index_time(tsk, cputime_to_nsecs(acct->stime),
+   account_system_time_index(tsk, cputime_to_nsecs(acct->stime),
  CPUTIME_SYSTEM);
 
if (acct->hardirq_time)
-   account_system_index_time(tsk, 
cputime_to_nsecs(acct->hardirq_time),
+   account_system_time_index(tsk, 
cputime_to_nsecs(acct->hardirq_time),
  CPUTIME_IRQ);
if (acct->softirq_time)
-   account_system_index_time(tsk, 
cputime_to_nsecs(acct->softirq_time),
+   account_system_time_index(tsk, 
cputime_to_nsecs(acct->softirq_time),
  CPUTIME_SOFTIRQ);
 
vtime_flush_scaled(tsk, acct);
diff --git a/arch/s390/kernel/vtime.c b/arch/s390/kernel/vtime.c
index af48db3..b6b888d 100644
--- a/arch/s390/kernel/vtime.c
+++ b/arch/s390/kernel/vtime.c
@@ -115,7 +115,7 @@ static void account_system_index_scaled(struct task_struct 
*p, u64 cputime,
enum cpu_usage_stat index)
 {
p->stimescaled += cputime_to_nsecs(scale_vtime(cputime));
-   account_system_index_time(p, cputime_to_nsecs(cputime), index);
+   account_system_time_index(p, cputime_to_nsecs(cputime), index);
 }
 
 /*
diff --git a/include/linux/kernel_stat.h b/include/linux/kernel_stat.h
index 86fdbce..049d973 100644
--- a/include/linux/kernel_stat.h
+++ b/include/linux/kernel_stat.h
@@ -82,7 +82,7 @@ static inline unsigned int kstat_cpu_irqs_sum(unsigned int 
cpu)
 extern void account_user_time(struct task_struct *, u64);
 extern void account_guest_time(struct task_struct *, u64);
 extern void account_system_time(struct task_struct *, int, u64);
-extern void account_system_index_time(struct task_struct *, u64,
+extern void account_system_time_index(struct task_struct *, u64,
  enum cpu_usage_stat);
 extern void account_steal_time(u64);
 extern void account_idle_time(u64);
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 63c4f0b..8f5dee2 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -94,8 +94,8 @@ static u64 irqtime_tick_accounted(u64 dummy)
 
 #endif /* !CONFIG_IRQ_TIME_ACCOUNTING */
 
-static inline void task_group_account_field(struct task_struct *p, int index,
-   u64 tmp)
+static inline void task_group_account_field(struct task_struct *p, u64 cputime,
+   enum cpu_usage_stat index)
 {
/*
 * Since all updates are sure to touch the root cgroup, we
@@ -103,9 +103,9 @@ static inline void task_group_account_field(struct 
task_struct *p, int index,
 * is the only cgroup, then