[PATCH] usb: host: plat: Enable xHCI plat runtime PM

Enable the xHCI plat runtime PM for parent device to suspend/resume xHCI. Also call pm_runtime_forbid() in probe() function to force users to explicitly enable runtime pm using power/control in sysfs, in case some parent devices didn't implement runtime PM callbacks. Signed-off-by: Baolin Wang

Re: [RFC PATCH 1/3] of/pci: dma-ranges to account highest possible host bridge dma_mask

On Wed, Mar 29, 2017 at 10:13 AM, Oza Oza wrote: > On Tue, Mar 28, 2017 at 7:59 PM, Robin Murphy wrote: >> On 28/03/17 06:27, Oza Oza wrote: >>> On Mon, Mar 27, 2017 at 8:16 PM, Rob Herring wrote: On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep wrote: > it is possible that PCI

Re: [PATCH v2 2/2] usb: phy: phy-qcom-8x16-usb: Remove redundant extcon register/unregister

Hi, On 28 March 2017 at 21:42, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> Since usb phy core has added common code to register or unregister >> extcon device, then phy-qcom-8x16-usb driver does not need its own >> code to register/unregister

Re: [PATCH v2 2/2] usb: phy: phy-qcom-8x16-usb: Remove redundant extcon register/unregister

Hi, On 28 March 2017 at 21:42, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> Since usb phy core has added common code to register or unregister >> extcon device, then phy-qcom-8x16-usb driver does not need its own >> code to register/unregister extcon device, then remove them. >> >>

[RESEND][PATCH v2] i2c: designwear: Fix clk warning on suspend/resume

On my HiKey board, I'm seeing clk warnings on suspend/resume, which seem to be caused by runtime pm suspending the device, then the same suspend hook being called again on suspend time. This patch fixes this by setting the SYSTEM_SLEEP_PM_OPS to using pm_runtime_force_suspend and

[PATCH v6 3/5] test: add new driver_data load tester

This adds a load tester driver test_driver_data a for the new extensible driver_data loader API, part of firmware_class. This test driver enables you to build your tests in userspace by exposing knobs of the exported API to userspace and enables a trigger action to mimic a one time use of the

[RESEND][PATCH v2] i2c: designwear: Fix clk warning on suspend/resume

On my HiKey board, I'm seeing clk warnings on suspend/resume, which seem to be caused by runtime pm suspending the device, then the same suspend hook being called again on suspend time. This patch fixes this by setting the SYSTEM_SLEEP_PM_OPS to using pm_runtime_force_suspend and

[PATCH v6 3/5] test: add new driver_data load tester

This adds a load tester driver test_driver_data a for the new extensible driver_data loader API, part of firmware_class. This test driver enables you to build your tests in userspace by exposing knobs of the exported API to userspace and enables a trigger action to mimic a one time use of the

Re: [PATCH] percpu: drop useless macro PER_CPU_DEF_ATTRIBUTES

On 03/29/2017 11:28 PM, Tejun Heo wrote: > On Wed, Mar 29, 2017 at 10:38:17AM +0800, Cao jin wrote: >> On 03/29/2017 12:00 AM, Tejun Heo wrote: >>> On Tue, Mar 28, 2017 at 04:35:07PM +0800, Cao jin wrote: Signed-off-by: Cao jin >>> >>> I'm not sure. I think I

[PATCH v6 5/5] brcmfmac: don't warn user if requested nvram fails

The requested nvram is optional, don't nag users about this. Additionally, the new driver data API enables us to let the API deal with the freeing of the nvram for us if we happen to free it immediately on the consumer callback, this driver does that so take advantage of this feature. Originally

Re: [PATCH] percpu: drop useless macro PER_CPU_DEF_ATTRIBUTES

On 03/29/2017 11:28 PM, Tejun Heo wrote: > On Wed, Mar 29, 2017 at 10:38:17AM +0800, Cao jin wrote: >> On 03/29/2017 12:00 AM, Tejun Heo wrote: >>> On Tue, Mar 28, 2017 at 04:35:07PM +0800, Cao jin wrote: Signed-off-by: Cao jin >>> >>> I'm not sure. I think I used it during development

[PATCH v6 5/5] brcmfmac: don't warn user if requested nvram fails

The requested nvram is optional, don't nag users about this. Additionally, the new driver data API enables us to let the API deal with the freeing of the nvram for us if we happen to free it immediately on the consumer callback, this driver does that so take advantage of this feature. Originally

[PATCH v6 1/5] firmware: add extensible driver data params

As the firmware API evolves we keep extending functions with more arguments. Stop this nonsense by proving an extensible data structure which can be used to represent both user parameters and private internal parameters. We introduce 3 data structures: o struct driver_data_req_params - used

[PATCH v6 1/5] firmware: add extensible driver data params

As the firmware API evolves we keep extending functions with more arguments. Stop this nonsense by proving an extensible data structure which can be used to represent both user parameters and private internal parameters. We introduce 3 data structures: o struct driver_data_req_params - used

[PATCH v6 2/5] firmware: add extensible driver data API

The firmware API does not scale well: when new features are added we either add a new exported symbol or extend the arguments of existing routines. For the later case this means we need to traverse the kernel with a slew of collateral evolutions to adjust old driver users. The firmware API is also

[PATCH 5/5] firmware: move umh try locks into the umh code

This moves the usermode helper locks into only code paths that use the usermode helper API from the kernel. The usermode helper locks were originally added to prevent stalling suspend, later the firmware cache was added to help with this, and further later direct filesystem lookup was added by

[PATCH v6 4/5] iwlwifi: convert to use driver data API

The driver data API provides support for looking for firmware from a specific set of API ranges, so just use that. Since we free the firmware on the callback immediately after consuming it, this also takes avantage of that feature. Signed-off-by: Luis R. Rodriguez ---

[PATCH v6 0/5] firmware: add driver data API

are based on next-20170329. This series depends on the series which moves the UMH locks onto the fallback code which I also just sent. If you want this in tree form you can get it all here: https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170329-driver-data-v2-try3 Luis

[PATCH v6 2/5] firmware: add extensible driver data API

The firmware API does not scale well: when new features are added we either add a new exported symbol or extend the arguments of existing routines. For the later case this means we need to traverse the kernel with a slew of collateral evolutions to adjust old driver users. The firmware API is also

[PATCH 5/5] firmware: move umh try locks into the umh code

This moves the usermode helper locks into only code paths that use the usermode helper API from the kernel. The usermode helper locks were originally added to prevent stalling suspend, later the firmware cache was added to help with this, and further later direct filesystem lookup was added by

[PATCH v6 4/5] iwlwifi: convert to use driver data API

The driver data API provides support for looking for firmware from a specific set of API ranges, so just use that. Since we free the firmware on the callback immediately after consuming it, this also takes avantage of that feature. Signed-off-by: Luis R. Rodriguez ---

[PATCH v6 0/5] firmware: add driver data API

are based on next-20170329. This series depends on the series which moves the UMH locks onto the fallback code which I also just sent. If you want this in tree form you can get it all here: https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170329-driver-data-v2-try3 Luis

[PATCH 4/5] firmware: move assign_firmware_buf() further up

This will make subsequent changes easier to read. Signed-off-by: Luis R. Rodriguez --- drivers/base/firmware_class.c | 77 +-- 1 file changed, 38 insertions(+), 39 deletions(-) diff --git a/drivers/base/firmware_class.c

[PATCH 2/5] firmware: always enable the reboot notifier

Now that we've have proper wrappers for the fallback mechanism we can easily share the reboot notifier for the firmware_class at all times. This change will make subsequent modifications to the reboot notifier easier to review. Signed-off-by: Luis R. Rodriguez ---

[PATCH 4/5] firmware: move assign_firmware_buf() further up

This will make subsequent changes easier to read. Signed-off-by: Luis R. Rodriguez --- drivers/base/firmware_class.c | 77 +-- 1 file changed, 38 insertions(+), 39 deletions(-) diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c

[PATCH 2/5] firmware: always enable the reboot notifier

Now that we've have proper wrappers for the fallback mechanism we can easily share the reboot notifier for the firmware_class at all times. This change will make subsequent modifications to the reboot notifier easier to review. Signed-off-by: Luis R. Rodriguez --- drivers/base/firmware_class.c

[PATCH 1/5] firmware: share fw fallback killing on reboot/suspend

We kill pending fallback requests on suspend and reboot, the only difference is that on suspend we only kill custom fallback requests. Provide a wrapper that lets us customize the request with a flag. This also lets us simplify the #ifdef'ery over the calls. Signed-off-by: Luis R. Rodriguez

[PATCH 1/5] firmware: share fw fallback killing on reboot/suspend

We kill pending fallback requests on suspend and reboot, the only difference is that on suspend we only kill custom fallback requests. Provide a wrapper that lets us customize the request with a flag. This also lets us simplify the #ifdef'ery over the calls. Signed-off-by: Luis R. Rodriguez ---

[PATCH v2] usb: dwc2: Make sure we disconnect the gadget state

I had seen some odd behavior with HiKey's usb-gadget interface that I finally seemed to have chased down. Basically every other time I plugged in the OTG port, the gadget interface would properly initialize. The other times, I'd get a big WARN_ON in dwc2_hsotg_init_fifo() about the fifo_map not

[PATCH v2] usb: dwc2: Make sure we disconnect the gadget state

I had seen some odd behavior with HiKey's usb-gadget interface that I finally seemed to have chased down. Basically every other time I plugged in the OTG port, the gadget interface would properly initialize. The other times, I'd get a big WARN_ON in dwc2_hsotg_init_fifo() about the fifo_map not

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

Hi, On 29 March 2017 at 07:04, NeilBrown wrote: > On Tue, Mar 07 2017, Baolin Wang wrote: > >> On 3 March 2017 at 10:23, NeilBrown wrote: >> >>> >>> I understand your reluctance to change drivers that you cannot test. >>> An alternative it do change all the >>>

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

Hi, On 29 March 2017 at 07:04, NeilBrown wrote: > On Tue, Mar 07 2017, Baolin Wang wrote: > >> On 3 March 2017 at 10:23, NeilBrown wrote: >> >>> >>> I understand your reluctance to change drivers that you cannot test. >>> An alternative it do change all the >>>

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Wed, 2017-03-29 at 23:10 +0300, Michael S. Tsirkin wrote: > Poking at this some more, I was able to reproduce at > least some warnings. I still do not see a spin > but is there a chance this helps your case too? Well, it's down to one warning, clean on the way back up. WRT spin, you should

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Wed, 2017-03-29 at 23:10 +0300, Michael S. Tsirkin wrote: > Poking at this some more, I was able to reproduce at > least some warnings. I still do not see a spin > but is there a chance this helps your case too? Well, it's down to one warning, clean on the way back up. WRT spin, you should

Re: [RFC PATCH 0/6] Unify the Interrupt Mode and setup it as soon as possible

At 03/30/2017 11:03 AM, Dou Liyang wrote: Hi Baoquan, At 03/30/2017 10:08 AM, Baoquan He wrote: Hi Liyang, This is awesome. I planned to do this after kaslr back porting, glad to see your posting. I like below diagram and the idea of patch 2/6 framework. Will review and see what I can do to

Re: [RFC PATCH 0/6] Unify the Interrupt Mode and setup it as soon as possible

At 03/30/2017 11:03 AM, Dou Liyang wrote: Hi Baoquan, At 03/30/2017 10:08 AM, Baoquan He wrote: Hi Liyang, This is awesome. I planned to do this after kaslr back porting, glad to see your posting. I like below diagram and the idea of patch 2/6 framework. Will review and see what I can do to

Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT

On 03/30/2017 01:32 AM, Lorenzo Pieralisi wrote: On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote: On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote: On 29/03/17 14:00, Hanjun Guo wrote: On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote: On Wed, Mar 29, 2017 at

Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT

On 03/30/2017 01:32 AM, Lorenzo Pieralisi wrote: On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote: On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote: On 29/03/17 14:00, Hanjun Guo wrote: On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote: On Wed, Mar 29, 2017 at

Re: [RFC PATCH 0/6] Unify the Interrupt Mode and setup it as soon as possible

Hi Baoquan, At 03/30/2017 10:08 AM, Baoquan He wrote: Hi Liyang, This is awesome. I planned to do this after kaslr back porting, glad to see your posting. I like below diagram and the idea of patch 2/6 framework. Will review and see what I can do to help since rhel bug from FJ is assigned to

Re: [RFC PATCH 0/6] Unify the Interrupt Mode and setup it as soon as possible

Hi Baoquan, At 03/30/2017 10:08 AM, Baoquan He wrote: Hi Liyang, This is awesome. I planned to do this after kaslr back porting, glad to see your posting. I like below diagram and the idea of patch 2/6 framework. Will review and see what I can do to help since rhel bug from FJ is assigned to

Re: [PATCH v2 1/2] usb: phy: Introduce one extcon device into usb phy

Hi, On 29 March 2017 at 06:56, NeilBrown wrote: > On Thu, Mar 23 2017, Baolin Wang wrote: > >> Usually usb phy need register one extcon device to get the connection >> notifications. It will remove some duplicate code if the extcon device >> is registered using common code

Re: [PATCH v2 1/2] usb: phy: Introduce one extcon device into usb phy

Hi, On 29 March 2017 at 06:56, NeilBrown wrote: > On Thu, Mar 23 2017, Baolin Wang wrote: > >> Usually usb phy need register one extcon device to get the connection >> notifications. It will remove some duplicate code if the extcon device >> is registered using common code instead of each phy

Re: [PATCH v2 1/2] usb: phy: Introduce one extcon device into usb phy

Hi, On 28 March 2017 at 21:40, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> Usually usb phy need register one extcon device to get the connection >> notifications. It will remove some duplicate code if the extcon device >> is registered using

Re: [PATCH v2 1/2] usb: phy: Introduce one extcon device into usb phy

Hi, On 28 March 2017 at 21:40, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> Usually usb phy need register one extcon device to get the connection >> notifications. It will remove some duplicate code if the extcon device >> is registered using common code instead of each phy driver

[PATCH 0/2] Support new Alps HID I2C Touchpad device

Hi, Jiri, This is the patch for new Alps HID I2C Touchpad device. These devices are used for HP Laptop. Best Regards, Masaki Ota

[PATCH 0/2] Support new Alps HID I2C Touchpad device

Hi, Jiri, This is the patch for new Alps HID I2C Touchpad device. These devices are used for HP Laptop. Best Regards, Masaki Ota

[PATCH 2/2] Add new U1 device ID

-Add new Alps U1 Touchpad device ID -Laptop names that use this Touchpad:HP Elitebook x360 1030 G2 Signed-off-by: Masaki Ota --- drivers/hid/hid-alps.c | 3 +++ drivers/hid/hid-core.c | 1 + drivers/hid/hid-ids.h | 1 + 3 files changed, 5 insertions(+) diff --git

[PATCH 1/2] Alps HID I2C T4 device support

>From Masaki Ota -Support Alps HID I2C T4 Touchpad device. -Laptop names that use this Touchpad:HP Zbook Studio, Elitebook Folio G1, Elitebook 1030 G1, Elitebook 1040 G3 Signed-off-by: Masaki Ota --- drivers/hid/hid-alps.c | 500

[PATCH 2/2] Add new U1 device ID

-Add new Alps U1 Touchpad device ID -Laptop names that use this Touchpad:HP Elitebook x360 1030 G2 Signed-off-by: Masaki Ota --- drivers/hid/hid-alps.c | 3 +++ drivers/hid/hid-core.c | 1 + drivers/hid/hid-ids.h | 1 + 3 files changed, 5 insertions(+) diff --git a/drivers/hid/hid-alps.c

[PATCH 1/2] Alps HID I2C T4 device support

>From Masaki Ota -Support Alps HID I2C T4 Touchpad device. -Laptop names that use this Touchpad:HP Zbook Studio, Elitebook Folio G1, Elitebook 1030 G1, Elitebook 1040 G3 Signed-off-by: Masaki Ota --- drivers/hid/hid-alps.c | 500 +++--

[GIT PULL] Thermal management updates for v4.11-rc5

Hi, Linus, Please pull from   git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git for-rc to receive the latest Thermal Management updates for v4.11-rc5 with top-most commit 3ea3217cf91804be6ed9b368ef4ac7911eb1dadc:   thermal: cpu_cooling: Check OPP for errors (2017-03-13 10:06:55

[GIT PULL] Thermal management updates for v4.11-rc5

Hi, Linus, Please pull from   git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git for-rc to receive the latest Thermal Management updates for v4.11-rc5 with top-most commit 3ea3217cf91804be6ed9b368ef4ac7911eb1dadc:   thermal: cpu_cooling: Check OPP for errors (2017-03-13 10:06:55

Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg()

Hi Peter, On Wed, Mar 29, 2017 at 12:41:26PM +0200, Peter Zijlstra wrote: > On Wed, Mar 29, 2017 at 08:04:42AM +0800, Yuyang Du wrote: > > Yes, you need to, and let me do it too and learn how you will rewrite > > it. > > I've meanwhile written this. Does that work for you? It works. You sort

Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg()

Hi Peter, On Wed, Mar 29, 2017 at 12:41:26PM +0200, Peter Zijlstra wrote: > On Wed, Mar 29, 2017 at 08:04:42AM +0800, Yuyang Du wrote: > > Yes, you need to, and let me do it too and learn how you will rewrite > > it. > > I've meanwhile written this. Does that work for you? It works. You sort

Re: [PATCH] scsi: hisi_sas: fix SATA dependency

Arnd Bergmann writes: > Removing the 'select SCSI_SAS_LIBSAS' statement in Kconfig resulted > in a link failure in configurations that have hisi_sas built-in > but libsas as a loadable module: Applied to 4.12/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux

Re: [PATCH] scsi: hisi_sas: fix SATA dependency

Arnd Bergmann writes: > Removing the 'select SCSI_SAS_LIBSAS' statement in Kconfig resulted > in a link failure in configurations that have hisi_sas built-in > but libsas as a loadable module: Applied to 4.12/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: hisi_sas: add missing break in switch statement

Colin King writes: Colin, > It appears that a break in the TRANS_TX_OPEN_CNX_ERR_NO_DESTINATION > case got accidentally removed in an earlier commit, as it stands, the > ts->stat and ts->open_rej_reason are being updated twice for this case > which looks incorrect.

Re: [PATCH] scsi: hisi_sas: add missing break in switch statement

Colin King writes: Colin, > It appears that a break in the TRANS_TX_OPEN_CNX_ERR_NO_DESTINATION > case got accidentally removed in an earlier commit, as it stands, the > ts->stat and ts->open_rej_reason are being updated twice for this case > which looks incorrect. Fix this by adding in the

Re: [PATCH v2] sd: Consider max_xfer_blocks if opt_xfer_blocks is unusable

Fam Zheng writes: Fam, > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c > index fcfeddc..a5c7e67 100644 > --- a/drivers/scsi/sd.c > +++ b/drivers/scsi/sd.c > @@ -2957,6 +2957,7 @@ static int sd_revalidate_disk(struct gendisk *disk) > rw_max =

Re: [PATCH v2] sd: Consider max_xfer_blocks if opt_xfer_blocks is unusable

Fam Zheng writes: Fam, > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c > index fcfeddc..a5c7e67 100644 > --- a/drivers/scsi/sd.c > +++ b/drivers/scsi/sd.c > @@ -2957,6 +2957,7 @@ static int sd_revalidate_disk(struct gendisk *disk) > rw_max = logical_to_sectors(sdp,

Re: [PATCH net-next 8/8] vhost_net: use lockless peeking for skb array during busy polling

On Thu, Mar 30, 2017 at 10:16:15AM +0800, Jason Wang wrote: > > > On 2017年03月29日 20:07, Michael S. Tsirkin wrote: > > On Tue, Mar 21, 2017 at 12:04:47PM +0800, Jason Wang wrote: > > > For the socket that exports its skb array, we can use lockless polling > > > to avoid touching spinlock during

Re: [PATCH net-next 8/8] vhost_net: use lockless peeking for skb array during busy polling

On Thu, Mar 30, 2017 at 10:16:15AM +0800, Jason Wang wrote: > > > On 2017年03月29日 20:07, Michael S. Tsirkin wrote: > > On Tue, Mar 21, 2017 at 12:04:47PM +0800, Jason Wang wrote: > > > For the socket that exports its skb array, we can use lockless polling > > > to avoid touching spinlock during

Re: [PATCH net-next 8/8] vhost_net: use lockless peeking for skb array during busy polling

On 2017年03月29日 20:07, Michael S. Tsirkin wrote: On Tue, Mar 21, 2017 at 12:04:47PM +0800, Jason Wang wrote: For the socket that exports its skb array, we can use lockless polling to avoid touching spinlock during busy polling. Signed-off-by: Jason Wang ---

Re: [PATCH net-next 8/8] vhost_net: use lockless peeking for skb array during busy polling

On 2017年03月29日 20:07, Michael S. Tsirkin wrote: On Tue, Mar 21, 2017 at 12:04:47PM +0800, Jason Wang wrote: For the socket that exports its skb array, we can use lockless polling to avoid touching spinlock during busy polling. Signed-off-by: Jason Wang --- drivers/vhost/net.c | 7 +--

Re: [BUG nohz]: wrong user and system time accounting

On Thu, 30 Mar 2017 06:46:30 +0800 Wanpeng Li wrote: > > So! Now we need to find a proper fix :o) > > > > Hmm, how bad would it be to revert to sched_clock() instead of jiffies in > > vtime_delta()? > > We could use nanosecond granularity to check deltas but only perform an

Re: [BUG nohz]: wrong user and system time accounting

On Thu, 30 Mar 2017 06:46:30 +0800 Wanpeng Li wrote: > > So! Now we need to find a proper fix :o) > > > > Hmm, how bad would it be to revert to sched_clock() instead of jiffies in > > vtime_delta()? > > We could use nanosecond granularity to check deltas but only perform an > > actual cputime

RE: [PATCH] ACPICA: use designated initializers

Hi, > From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees Cook > Subject: Re: [PATCH] ACPICA: use designated initializers > > On Sun, Dec 18, 2016 at 10:06 PM, Zheng, Lv wrote: > > Hi, > > > >> From: Kees Cook [mailto:keesc...@chromium.org] > >> Subject:

RE: [PATCH] ACPICA: use designated initializers

Hi, > From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees Cook > Subject: Re: [PATCH] ACPICA: use designated initializers > > On Sun, Dec 18, 2016 at 10:06 PM, Zheng, Lv wrote: > > Hi, > > > >> From: Kees Cook [mailto:keesc...@chromium.org] > >> Subject: [PATCH] ACPICA: use

Re: [RFC PATCH 0/6] Unify the Interrupt Mode and setup it as soon as possible

Hi Liyang, This is awesome. I planned to do this after kaslr back porting, glad to see your posting. I like below diagram and the idea of patch 2/6 framework. Will review and see what I can do to help since rhel bug from FJ is assigned to me. Thanks for the effort! And add Joerg to this thread

Re: [RFC PATCH 0/6] Unify the Interrupt Mode and setup it as soon as possible

Hi Liyang, This is awesome. I planned to do this after kaslr back porting, glad to see your posting. I like below diagram and the idea of patch 2/6 framework. Will review and see what I can do to help since rhel bug from FJ is assigned to me. Thanks for the effort! And add Joerg to this thread

[PATCH] staging:iio:accel:adis16029 fixed checkpatch issue - drop braces around single if statement

Fixed the followinf checkpatch warning: WARNING: braces {} are not necessary for single statement blocks #258: FILE: drivers/staging/iio/accel/adis16209.c:258: + if (ret) { + return ret; + } Signed-off-by: Andrea della Porta

[PATCH] staging:iio:accel:adis16029 fixed checkpatch issue - drop braces around single if statement

Fixed the followinf checkpatch warning: WARNING: braces {} are not necessary for single statement blocks #258: FILE: drivers/staging/iio/accel/adis16209.c:258: + if (ret) { + return ret; + } Signed-off-by: Andrea della Porta ---

Re: [PATCH v5 6/9] coresight: add support for CPU debug module

On Wed, Mar 29, 2017 at 10:55:35AM -0600, Mathieu Poirier wrote: [...] > > So this is why add "idle_constraint" as a central place to control > > power domain for CPU debug purpose and I also think this is more > > friendly for hardware design, e.g. some platforms can enable partial > > low

Re: [PATCH v5 6/9] coresight: add support for CPU debug module

On Wed, Mar 29, 2017 at 10:55:35AM -0600, Mathieu Poirier wrote: [...] > > So this is why add "idle_constraint" as a central place to control > > power domain for CPU debug purpose and I also think this is more > > friendly for hardware design, e.g. some platforms can enable partial > > low

Re: [BUG nohz]: wrong user and system time accounting

2017-03-30 4:08 GMT+08:00 Rik van Riel : > On Wed, 2017-03-29 at 13:16 -0400, Luiz Capitulino wrote: >> On Tue, 28 Mar 2017 13:24:06 -0400 >> Luiz Capitulino wrote: >> >> > 1. In my tracing I'm seeing that sometimes (always?) the >> > time interval

Re: [BUG nohz]: wrong user and system time accounting

2017-03-30 4:08 GMT+08:00 Rik van Riel : > On Wed, 2017-03-29 at 13:16 -0400, Luiz Capitulino wrote: >> On Tue, 28 Mar 2017 13:24:06 -0400 >> Luiz Capitulino wrote: >> >> > 1. In my tracing I'm seeing that sometimes (always?) the >> > time interval between two timer interrupts is less than

Re: [PATCH] kernel.h: add IS_PTR_ALIGNED() macro

Hi. 2017-03-30 6:24 GMT+09:00 H. Peter Anvin : > On 03/29/17 03:22, Masahiro Yamada wrote: >> We often check if a pointer has a specific alignment. Because the >> '&' (bitwise AND) operator cannot take a pointer for the operand, >> so we need a cast like, IS_ALIGNED((unsigned

Re: [PATCH] kernel.h: add IS_PTR_ALIGNED() macro

Hi. 2017-03-30 6:24 GMT+09:00 H. Peter Anvin : > On 03/29/17 03:22, Masahiro Yamada wrote: >> We often check if a pointer has a specific alignment. Because the >> '&' (bitwise AND) operator cannot take a pointer for the operand, >> so we need a cast like, IS_ALIGNED((unsigned long)p, a). >> >>

Re: [PATCH] Add checks for kmalloc allocation failures

Hello. On 03/29/2017 06:21 PM, Eric Dumazet wrote: On Wed, 2017-03-29 at 16:54 +0100, Colin King wrote: From: Colin Ian King Ensure we don't end up with a null pointer dereferences by checking for for allocation failures. Allocate by sizeof(*ptr) rather than the

Re: [PATCH] Add checks for kmalloc allocation failures

Hello. On 03/29/2017 06:21 PM, Eric Dumazet wrote: On Wed, 2017-03-29 at 16:54 +0100, Colin King wrote: From: Colin Ian King Ensure we don't end up with a null pointer dereferences by checking for for allocation failures. Allocate by sizeof(*ptr) rather than the type to fix checkpack

Re: [PATCH] x86/fpu: move FPU state into separate cache

On Wed, Mar 29, 2017 at 4:56 PM, Linus Torvalds wrote: > On Wed, Mar 29, 2017 at 3:28 PM, wrote: >> On March 29, 2017 2:41:00 PM PDT, Linus Torvalds >> wrote: >> >> An alternative is to wrap the randomized structure

Re: [PATCH] x86/fpu: move FPU state into separate cache

On Wed, Mar 29, 2017 at 4:56 PM, Linus Torvalds wrote: > On Wed, Mar 29, 2017 at 3:28 PM, wrote: >> On March 29, 2017 2:41:00 PM PDT, Linus Torvalds >> wrote: >> >> An alternative is to wrap the randomized structure inside a nonrandomized >> wrapper structure. > > That's probably a

Re: [BUG nohz]: wrong user and system time accounting

On Wed, 29 Mar 2017 23:12:00 +0200 Frederic Weisbecker wrote: > On Wed, Mar 29, 2017 at 09:23:57AM -0400, Luiz Capitulino wrote: > > > > There are various reproducers actually. I started off with the simple > > loop above, then wrote the attach program and then wrote the one

Re: [BUG nohz]: wrong user and system time accounting

On Wed, 29 Mar 2017 23:12:00 +0200 Frederic Weisbecker wrote: > On Wed, Mar 29, 2017 at 09:23:57AM -0400, Luiz Capitulino wrote: > > > > There are various reproducers actually. I started off with the simple > > loop above, then wrote the attach program and then wrote the one > > you're

Re: [alsa-devel] Question about of_clk_put ?

Hi Sorry for my noise. I could solve my issue. > Now, I'm using devm_get_clk_from_child() (= linux/drivers/clk/clk-devres.c) > and I got Oops if I do bind/unbind driver several times. > > [ 32.008847] Unable to handle kernel paging request at virtual > address d503201faa1e03e0 >

Re: [alsa-devel] Question about of_clk_put ?

Hi Sorry for my noise. I could solve my issue. > Now, I'm using devm_get_clk_from_child() (= linux/drivers/clk/clk-devres.c) > and I got Oops if I do bind/unbind driver several times. > > [ 32.008847] Unable to handle kernel paging request at virtual > address d503201faa1e03e0 >

Re: [PATCH] Fix IB va_start+ib_bytes range check on 32Bit systems

On 30/03/17 12:18 AM, Christian König wrote: > Am 29.03.2017 um 16:54 schrieb Michel Dänzer: >> On 29/03/17 10:22 PM, Christian König wrote: >>> Am 29.03.2017 um 11:18 schrieb Jan Burgmeier: Signed-off-by: Jan Burgmeier ---

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski wrote: > On Wed, Mar 29, 2017 at 11:15 AM, Kees Cook wrote: >> Based on PaX's x86 pax_{open,close}_kernel() implementation, this >> allows HAVE_ARCH_RARE_WRITE to work on x86. >> > >> + >> +static

Re: [PATCH] Fix IB va_start+ib_bytes range check on 32Bit systems

On 30/03/17 12:18 AM, Christian König wrote: > Am 29.03.2017 um 16:54 schrieb Michel Dänzer: >> On 29/03/17 10:22 PM, Christian König wrote: >>> Am 29.03.2017 um 11:18 schrieb Jan Burgmeier: Signed-off-by: Jan Burgmeier --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 +++-

Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

On Wed, Mar 29, 2017 at 3:38 PM, Andy Lutomirski wrote: > On Wed, Mar 29, 2017 at 11:15 AM, Kees Cook wrote: >> Based on PaX's x86 pax_{open,close}_kernel() implementation, this >> allows HAVE_ARCH_RARE_WRITE to work on x86. >> > >> + >> +static __always_inline unsigned long

Re: [PATCH 0/4] ftrace: Add 'function-fork' trace option (v1)

Hi Masami, On Thu, Mar 30, 2017 at 9:54 AM, Masami Hiramatsu wrote: > On Wed, 29 Mar 2017 10:46:21 +0900 > Namhyung Kim wrote: > >> Hello, >> >> This patchset add 'function-fork' option to function tracer which >> makes pid filter to be inherited like

Re: [PATCH 0/4] ftrace: Add 'function-fork' trace option (v1)

Hi Masami, On Thu, Mar 30, 2017 at 9:54 AM, Masami Hiramatsu wrote: > On Wed, 29 Mar 2017 10:46:21 +0900 > Namhyung Kim wrote: > >> Hello, >> >> This patchset add 'function-fork' option to function tracer which >> makes pid filter to be inherited like 'event-fork' does. During the >> test, I

Re: [drm] 4e64e5539d [ 1138.272031] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper:1]

Fengguang Wu writes: > Hi Chris, > >>+--+++---+---+ >>| | 17aad8a340 | 4e64e5539d | >>v4.11-rc3 | next-20170320 |

Re: [drm] 4e64e5539d [ 1138.272031] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper:1]

Fengguang Wu writes: > Hi Chris, > >>+--+++---+---+ >>| | 17aad8a340 | 4e64e5539d | >>v4.11-rc3 | next-20170320 |

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

Hi Christoffer/Laszlo, On 2017/3/30 1:44, Christoffer Dall wrote: > On Wed, Mar 29, 2017 at 05:37:49PM +0200, Laszlo Ersek wrote: >> On 03/29/17 16:48, Christoffer Dall wrote: >>> On Wed, Mar 29, 2017 at 10:36:51PM +0800, gengdongjiu wrote: 2017-03-29 18:36 GMT+08:00, Achin Gupta

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

Hi Christoffer/Laszlo, On 2017/3/30 1:44, Christoffer Dall wrote: > On Wed, Mar 29, 2017 at 05:37:49PM +0200, Laszlo Ersek wrote: >> On 03/29/17 16:48, Christoffer Dall wrote: >>> On Wed, Mar 29, 2017 at 10:36:51PM +0800, gengdongjiu wrote: 2017-03-29 18:36 GMT+08:00, Achin Gupta : >> >

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

11.03.2017 02:59, Ricardo Neri пишет: On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: Why would you need one? Or do you really want to allow these instructions in v86 by the means of emulation? If so - this wasn't clearly stated in the patch description, neither it was properly

Re: [v6 PATCH 00/21] x86: Enable User-Mode Instruction Prevention

11.03.2017 02:59, Ricardo Neri пишет: On Fri, 2017-03-10 at 14:33 +0300, Stas Sergeev wrote: Why would you need one? Or do you really want to allow these instructions in v86 by the means of emulation? If so - this wasn't clearly stated in the patch description, neither it was properly

Re: [PATCH v5 6/9] coresight: add support for CPU debug module

On Wed, Mar 29, 2017 at 04:17:19PM +0100, Mike Leach wrote: [...] > >> >+out_powered_up: > >> >+debug_os_unlock(drvdata); > >> > >> Question: Do we need a matching debug_os_lock() once we are done ? > > > > I have checked ARM ARMv8, but there have no detailed description for > > this. I

Re: [PATCH v5 6/9] coresight: add support for CPU debug module

On Wed, Mar 29, 2017 at 04:17:19PM +0100, Mike Leach wrote: [...] > >> >+out_powered_up: > >> >+debug_os_unlock(drvdata); > >> > >> Question: Do we need a matching debug_os_lock() once we are done ? > > > > I have checked ARM ARMv8, but there have no detailed description for > > this. I

<    1   2   3   4   5   6   7   8   9   10   >