[PATCH v4 3/3] Documentation: hwmon: Document the IBM CFF power supply

From: "Edward A. James" Signed-off-by: Edward A. James --- Documentation/hwmon/ibm-cffps | 54 +++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/hwmon/ibm-cffps diff --git a/Documentation/hwmon/ibm-cffps

[PATCH v4 0/3] hwmon: (pmbus): Add IBM Common Form Factor (CFF) power supply driver

From: "Edward A. James" This series adds a hwmon pmbus driver for a POWER System power supply. The core monitoring functionality is provided by pmbus. Changes since v3: * Change "fault" to "alarm" in the documentation. Changes since v2: * Renamed the driver again... * Remove debugfs bool

Re: [PATCH] pciehp: Fix infinite interupt handler loop

On Mon, Aug 14, 2017 at 06:11:23PM -0400, Keith Busch wrote: > On Mon, Aug 14, 2017 at 03:59:48PM -0500, Bjorn Helgaas wrote: > > On Tue, Aug 01, 2017 at 03:11:52AM -0400, Keith Busch wrote: > > > We've encountered a particular platform that under some circumstances > > > always has the power

Re: [PATCH] pciehp: Fix infinite interupt handler loop

On Mon, Aug 14, 2017 at 06:11:23PM -0400, Keith Busch wrote: > On Mon, Aug 14, 2017 at 03:59:48PM -0500, Bjorn Helgaas wrote: > > On Tue, Aug 01, 2017 at 03:11:52AM -0400, Keith Busch wrote: > > > We've encountered a particular platform that under some circumstances > > > always has the power

Re: [PATCH v3 12/13] xen/pvcalls: implement release command

On 07/31/2017 06:57 PM, Stefano Stabellini wrote: > Send PVCALLS_RELEASE to the backend and wait for a reply. Take both > in_mutex and out_mutex to avoid concurrent accesses. Then, free the > socket. > > For passive sockets, check whether we have already pre-allocated an > active socket for the

Re: [PATCH v3 12/13] xen/pvcalls: implement release command

On 07/31/2017 06:57 PM, Stefano Stabellini wrote: > Send PVCALLS_RELEASE to the backend and wait for a reply. Take both > in_mutex and out_mutex to avoid concurrent accesses. Then, free the > socket. > > For passive sockets, check whether we have already pre-allocated an > active socket for the

Re: [PATCH v4 0/4] OF phandle nexus support + GPIO nexus

On Fri, Aug 11, 2017 at 10:42 AM, Stephen Boyd wrote: > This is a continutation of my phandle remapping/nexus node series > from a while ago. I finally got around to writing the documentation > in the spec for this, but it's really rough around the edges and > could use

Re: [PATCH v4 0/4] OF phandle nexus support + GPIO nexus

On Fri, Aug 11, 2017 at 10:42 AM, Stephen Boyd wrote: > This is a continutation of my phandle remapping/nexus node series > from a while ago. I finally got around to writing the documentation > in the spec for this, but it's really rough around the edges and > could use some review/suggestions to

Re: [PATCH v3 3/3] Documentation: hwmon: Document the IBM CFF power supply

On 08/14/2017 05:37 PM, Guenter Roeck wrote: On Mon, Aug 14, 2017 at 02:26:20PM -0500, Eddie James wrote: On 08/14/2017 01:53 PM, Guenter Roeck wrote: On Mon, Aug 14, 2017 at 10:26:30AM -0500, Eddie James wrote: From: "Edward A. James" Signed-off-by: Edward A. James

Re: [PATCH v3 3/3] Documentation: hwmon: Document the IBM CFF power supply

On 08/14/2017 05:37 PM, Guenter Roeck wrote: On Mon, Aug 14, 2017 at 02:26:20PM -0500, Eddie James wrote: On 08/14/2017 01:53 PM, Guenter Roeck wrote: On Mon, Aug 14, 2017 at 10:26:30AM -0500, Eddie James wrote: From: "Edward A. James" Signed-off-by: Edward A. James ---

Re: [PATCH v3 11/13] xen/pvcalls: implement poll command

On 07/31/2017 06:57 PM, Stefano Stabellini wrote: > For active sockets, check the indexes and use the inflight_conn_req > waitqueue to wait. > > For passive sockets if an accept is outstanding > (PVCALLS_FLAG_ACCEPT_INFLIGHT), check if it has been answered by looking > at bedata->rsp[req_id]. If

Re: [PATCH v3 11/13] xen/pvcalls: implement poll command

On 07/31/2017 06:57 PM, Stefano Stabellini wrote: > For active sockets, check the indexes and use the inflight_conn_req > waitqueue to wait. > > For passive sockets if an accept is outstanding > (PVCALLS_FLAG_ACCEPT_INFLIGHT), check if it has been answered by looking > at bedata->rsp[req_id]. If

Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors

> On Tue, Aug 15, 2017 at 05:54:27PM +0300, Meelis Roos wrote: > > I noticed that in 4.13.0-rc4 there is a new error in dmesg on my sparc64 > > t5120 server: can't allocate MSI-X affinity masks. > > > > [ 30.274284] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA > > Driver:

Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors

> On Tue, Aug 15, 2017 at 05:54:27PM +0300, Meelis Roos wrote: > > I noticed that in 4.13.0-rc4 there is a new error in dmesg on my sparc64 > > t5120 server: can't allocate MSI-X affinity masks. > > > > [ 30.274284] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA > > Driver:

[PATCH] scsi: cxlflash: Fix an error handling path in 'cxlflash_disk_attach()'

'rc' is known to be 0 at this point. If 'create_context()' fails, returns -ENOMEM instead of 0 which means success. Signed-off-by: Christophe JAILLET --- drivers/scsi/cxlflash/superpipe.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] scsi: cxlflash: Fix an error handling path in 'cxlflash_disk_attach()'

'rc' is known to be 0 at this point. If 'create_context()' fails, returns -ENOMEM instead of 0 which means success. Signed-off-by: Christophe JAILLET --- drivers/scsi/cxlflash/superpipe.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/cxlflash/superpipe.c

[PATCH v2] tpm_tis: fix stall after iowrite*()s

ioread8() operations to TPM MMIO addresses can stall the cpu when immediately following a sequence of iowrite*()'s to the same region. For example, cyclitest measures ~400us latency spikes when a non-RT usermode application communicates with an SPI-based TPM chip (Intel Atom E3940 system,

[PATCH v2] tpm_tis: fix stall after iowrite*()s

ioread8() operations to TPM MMIO addresses can stall the cpu when immediately following a sequence of iowrite*()'s to the same region. For example, cyclitest measures ~400us latency spikes when a non-RT usermode application communicates with an SPI-based TPM chip (Intel Atom E3940 system,

[PATCH] KVM: SVM: refactor avic VM ID allocation

2017-08-11 22:11+0200, Denys Vlasenko: > With lightly tweaked defconfig: > > textdata bss dec hex filename > 11259661 5109408 2981888 19350957 12745ad vmlinux.before > 11259661 5109408 884736 17253805 10745ad vmlinux.after > > Only compile-tested. > > Signed-off-by: Denys

[PATCH] KVM: SVM: refactor avic VM ID allocation

2017-08-11 22:11+0200, Denys Vlasenko: > With lightly tweaked defconfig: > > textdata bss dec hex filename > 11259661 5109408 2981888 19350957 12745ad vmlinux.before > 11259661 5109408 884736 17253805 10745ad vmlinux.after > > Only compile-tested. > > Signed-off-by: Denys

Re: [PATCH] tpm_tis: fix stall after iowrite*()s

On 08/15/2017 01:11 AM, Alexander Stein wrote: On Monday 14 August 2017 17:53:47, Haris Okanovic wrote: --- a/drivers/char/tpm/tpm_tis.c +++ b/drivers/char/tpm/tpm_tis.c @@ -52,6 +52,22 @@ static inline struct tpm_tis_tcg_phy *to_tpm_tis_tcg_phy(struct tpm_tis_data *da return

Re: [PATCH] tpm_tis: fix stall after iowrite*()s

On 08/15/2017 01:11 AM, Alexander Stein wrote: On Monday 14 August 2017 17:53:47, Haris Okanovic wrote: --- a/drivers/char/tpm/tpm_tis.c +++ b/drivers/char/tpm/tpm_tis.c @@ -52,6 +52,22 @@ static inline struct tpm_tis_tcg_phy *to_tpm_tis_tcg_phy(struct tpm_tis_data *da return

Re: [PATCH 2/2] mtd: spi-nor: Altera ASMI Parallel II IP Core

Le 15/08/2017 à 19:20, matthew.gerl...@linux.intel.com a écrit : > > Hi Cyrille, > > Thanks for the great feedback. See my comments inline. > > Matthew Gerlach > > On Fri, 11 Aug 2017, Cyrille Pitchen wrote: > >> Hi Matthew, >> >> Le 06/08/2017 à 20:24, matthew.gerl...@linux.intel.com a

Re: [PATCH 2/2] mtd: spi-nor: Altera ASMI Parallel II IP Core

Le 15/08/2017 à 19:20, matthew.gerl...@linux.intel.com a écrit : > > Hi Cyrille, > > Thanks for the great feedback. See my comments inline. > > Matthew Gerlach > > On Fri, 11 Aug 2017, Cyrille Pitchen wrote: > >> Hi Matthew, >> >> Le 06/08/2017 à 20:24, matthew.gerl...@linux.intel.com a

[PATCH v2 05/14] staging: typec: fusb302: Use client->irq as irq if set

The fusb302 is also used on x86 systems where the platform code sets the irq in client->irq and there is no gpio named fcs,int_n. Cc: "Yueyao (Nathan) Zhu" Signed-off-by: Hans de Goede --- drivers/staging/typec/fusb302/fusb302.c | 10 +++--- 1 file

[PATCH v2 05/14] staging: typec: fusb302: Use client->irq as irq if set

The fusb302 is also used on x86 systems where the platform code sets the irq in client->irq and there is no gpio named fcs,int_n. Cc: "Yueyao (Nathan) Zhu" Signed-off-by: Hans de Goede --- drivers/staging/typec/fusb302/fusb302.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-)

[PATCH v2 14/14] platform/x86: intel_cht_int33fe: Update fusb302 type string, add properties

The fusb302 driver as merged in staging uses "typec_fusb302" as i2c-id rather then just "fusb302" and needs us to set a number of device- properties, adjust the intel_cht_int33fe driver accordingly. One of the properties set is max-snk-mv which makes the fusb302 driver negotiate up to 12V

[PATCH v2 14/14] platform/x86: intel_cht_int33fe: Update fusb302 type string, add properties

The fusb302 driver as merged in staging uses "typec_fusb302" as i2c-id rather then just "fusb302" and needs us to set a number of device- properties, adjust the intel_cht_int33fe driver accordingly. One of the properties set is max-snk-mv which makes the fusb302 driver negotiate up to 12V

Re: [PATCH v2 1/4] perf annotate stdio: Support --show-nr-samples option

Em Wed, Aug 16, 2017 at 12:13:09AM +0900, Taeung Song escreveu: > Add --show-nr-samples option to perf-annotate > so that it corresponds with perf-report. I'll fold the second patch (2/4) with this one, thanks. - Arnaldo > Cc: Namhyung Kim > Cc: Milian Wolff

Re: [PATCH v2 1/4] perf annotate stdio: Support --show-nr-samples option

Em Wed, Aug 16, 2017 at 12:13:09AM +0900, Taeung Song escreveu: > Add --show-nr-samples option to perf-annotate > so that it corresponds with perf-report. I'll fold the second patch (2/4) with this one, thanks. - Arnaldo > Cc: Namhyung Kim > Cc: Milian Wolff > Cc: Jiri Olsa > Signed-off-by:

[PATCH v2 13/14] i2c-cht-wc: Add device-properties for fusb302 integration

Add device-properties to make the bq24292i charger connected to the bus get its input-current-limit from the fusb302 Type-C port controller which is used on boards with the cht-wc PMIC, as well as regulator_init_data for the 5V boost converter on the bq24292i. Since this means we now hook-up the

[PATCH v2 13/14] i2c-cht-wc: Add device-properties for fusb302 integration

Add device-properties to make the bq24292i charger connected to the bus get its input-current-limit from the fusb302 Type-C port controller which is used on boards with the cht-wc PMIC, as well as regulator_init_data for the 5V boost converter on the bq24292i. Since this means we now hook-up the

[PATCH v2 11/14] power: supply: bq24190_charger: Get input_current_limit from our supplier

On some devices the USB Type-C port power (USB PD 2.0) negotiation is done by a separate port-controller IC, while the current limit is controlled through another (charger) IC. It has been decided to model this by modelling the external Type-C power brick (adapter/charger) as a power-supply class

[PATCH v2 11/14] power: supply: bq24190_charger: Get input_current_limit from our supplier

On some devices the USB Type-C port power (USB PD 2.0) negotiation is done by a separate port-controller IC, while the current limit is controlled through another (charger) IC. It has been decided to model this by modelling the external Type-C power brick (adapter/charger) as a power-supply class

[PATCH v2 12/14] power: supply: bq24190_charger: Remove extcon handling

Now that drivers/i2c/busses/i2c-cht-wc.c uses "input-current-limit-from-supplier" instead of "extcon-name" the last user of the bq24190 extcon code is gone, remove it. Signed-off-by: Hans de Goede --- Changes in v2: -Move the comment with the example code for passing

[PATCH v2 12/14] power: supply: bq24190_charger: Remove extcon handling

Now that drivers/i2c/busses/i2c-cht-wc.c uses "input-current-limit-from-supplier" instead of "extcon-name" the last user of the bq24190 extcon code is gone, remove it. Signed-off-by: Hans de Goede --- Changes in v2: -Move the comment with the example code for passing properties on i2c_client

[PATCH v2 10/14] power: supply: bq24190_charger: Add input_current_limit property

Export the input current limit of the charger as a POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT property on the charger power_supply class device. Signed-off-by: Hans de Goede --- drivers/power/supply/bq24190_charger.c | 35 ++ 1 file changed, 35

[PATCH v2 10/14] power: supply: bq24190_charger: Add input_current_limit property

Export the input current limit of the charger as a POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT property on the charger power_supply class device. Signed-off-by: Hans de Goede --- drivers/power/supply/bq24190_charger.c | 35 ++ 1 file changed, 35 insertions(+) diff

[PATCH v2 09/14] power: supply: bq24190_charger: Export 5V boost converter as regulator

Register the 5V boost converter as a regulator named "usb_otg_vbus". This commit also adds support for bq24190_platform_data, through which non device-tree platforms can pass the regulator_init_data (containing mappings for the consumer amongst other things). Signed-off-by: Hans de Goede

[PATCH v2 08/14] power: supply: Add power_supply_set_input_current_limit_from_supplier helper

On some devices the USB Type-C port power (USB PD 2.0) negotiation is done by a separate port-controller IC, while the current limit is controlled through another (charger) IC. It has been decided to model this by modelling the external Type-C power brick (adapter/charger) as a power-supply class

[PATCH v2 09/14] power: supply: bq24190_charger: Export 5V boost converter as regulator

Register the 5V boost converter as a regulator named "usb_otg_vbus". This commit also adds support for bq24190_platform_data, through which non device-tree platforms can pass the regulator_init_data (containing mappings for the consumer amongst other things). Signed-off-by: Hans de Goede ---

[PATCH v2 08/14] power: supply: Add power_supply_set_input_current_limit_from_supplier helper

On some devices the USB Type-C port power (USB PD 2.0) negotiation is done by a separate port-controller IC, while the current limit is controlled through another (charger) IC. It has been decided to model this by modelling the external Type-C power brick (adapter/charger) as a power-supply class

[PATCH v2 07/14] staging: typec: fusb302: Export current-limit through a power_supply class dev

The fusb302 Type-C port-controller cannot control the current-limit directly, so we need to exported the limit so that another driver (e.g. the charger driver) can pick the limit up and configure the system accordingly. The power-supply subsys already provides infrastructure for this,

[PATCH v2 07/14] staging: typec: fusb302: Export current-limit through a power_supply class dev

The fusb302 Type-C port-controller cannot control the current-limit directly, so we need to exported the limit so that another driver (e.g. the charger driver) can pick the limit up and configure the system accordingly. The power-supply subsys already provides infrastructure for this,

[PATCH v2 04/14] staging: typec: fusb302: Get max snk mv/ma/mw from device-properties

This is board specific info so it should come from board config, such as devicetree. I've chosen to prefix these with "fcs," treating them as fusb302 driver specific for now. We may want to revisit this and replace these with properties which are part of a (to be written) generic type-c

[PATCH v2 06/14] staging: typec: fusb302: Add support for USB2 charger detection through extcon

The fusb302 port-controller relies on an external device doing USB2 charger-type detection. The Intel Whiskey Cove PMIC with which the fusb302 is combined on some X86/ACPI platforms already has a charger-type detection driver which uses extcon to communicate the detected charger-type. This

[PATCH v2 04/14] staging: typec: fusb302: Get max snk mv/ma/mw from device-properties

This is board specific info so it should come from board config, such as devicetree. I've chosen to prefix these with "fcs," treating them as fusb302 driver specific for now. We may want to revisit this and replace these with properties which are part of a (to be written) generic type-c

[PATCH v2 06/14] staging: typec: fusb302: Add support for USB2 charger detection through extcon

The fusb302 port-controller relies on an external device doing USB2 charger-type detection. The Intel Whiskey Cove PMIC with which the fusb302 is combined on some X86/ACPI platforms already has a charger-type detection driver which uses extcon to communicate the detected charger-type. This

[PATCH v2 01/14] i2c: Allow overriding dev_name through board_info

For devices not instantiated through ACPI the i2c-client's device-name gets set to - by default, e.g. "0-0022" this means that the device-name is dependent on the order in which the i2c-busses are enumerated. In some cases having a predictable constant device-name is desirable, for example on non

[PATCH v2 01/14] i2c: Allow overriding dev_name through board_info

For devices not instantiated through ACPI the i2c-client's device-name gets set to - by default, e.g. "0-0022" this means that the device-name is dependent on the order in which the i2c-busses are enumerated. In some cases having a predictable constant device-name is desirable, for example on non

[PATCH v2 02/14] staging: typec: tcpm: Add get_current_limit tcpc_dev callback

A Rp signalling the default current limit indicates that we're possibly connected to an USB2 power-source. In some cases the type-c port-controller may provide the capability to detect the current-limit in this case, through e.g. BC1.2 detection. This commit adds an optional get_current_limit

[PATCH v2 00/14] Hookup typec power-negotation to the PMIC and charger

Hi All, This series implements a number of typec changes discussed a while back: - It exports the negotiated voltage and max-current in the form of a power-supply class device which represents the USB Type-C power-brick (adapter/charger) - It adds a

[PATCH v2 02/14] staging: typec: tcpm: Add get_current_limit tcpc_dev callback

A Rp signalling the default current limit indicates that we're possibly connected to an USB2 power-source. In some cases the type-c port-controller may provide the capability to detect the current-limit in this case, through e.g. BC1.2 detection. This commit adds an optional get_current_limit

[PATCH v2 00/14] Hookup typec power-negotation to the PMIC and charger

Hi All, This series implements a number of typec changes discussed a while back: - It exports the negotiated voltage and max-current in the form of a power-supply class device which represents the USB Type-C power-brick (adapter/charger) - It adds a

[PATCH v2 03/14] staging: typec: fusb302: Set max supply voltage to 5V

Anything higher then 5V may damage hardware not capable of it, so the only sane default here is 5V. If a board is able to handle a higher voltage that should come from board specific data such as device-tree and not be hard coded into the fusb302 code. Cc: "Yueyao (Nathan) Zhu"

[PATCH v2 03/14] staging: typec: fusb302: Set max supply voltage to 5V

Anything higher then 5V may damage hardware not capable of it, so the only sane default here is 5V. If a board is able to handle a higher voltage that should come from board specific data such as device-tree and not be hard coded into the fusb302 code. Cc: "Yueyao (Nathan) Zhu" Signed-off-by:

Re: [PATCH] printk-formats.txt: Add examples for %pS and %pF

On 15.08.2017 13:36, Petr Mladek wrote: > On Fri 2017-08-11 09:31:28, Helge Deller wrote: >> On 11.08.2017 02:15, Sergey Senozhatsky wrote: >>> On (08/10/17 19:35), Helge Deller wrote: Sometimes people seems unclear when to use the %pS or %pF printk format. Adding some examples may help

Re: [PATCH] printk-formats.txt: Add examples for %pS and %pF

On 15.08.2017 13:36, Petr Mladek wrote: > On Fri 2017-08-11 09:31:28, Helge Deller wrote: >> On 11.08.2017 02:15, Sergey Senozhatsky wrote: >>> On (08/10/17 19:35), Helge Deller wrote: Sometimes people seems unclear when to use the %pS or %pF printk format. Adding some examples may help

[PATCH v2] ipc: optimize semget/shmget/msgget for lots of keys

ding extra paths to panic() during boot. This implies that in this v2, .tables_initialized remains. - patch now based on next-20170815 include/linux/ipc.h | 3 ++ include/linux/ipc_namespace.h | 3 ++ ipc/msg.c | 10 +++-- ipc/namespace.c |

[PATCH v2] ipc: optimize semget/shmget/msgget for lots of keys

lized remains. - patch now based on next-20170815 include/linux/ipc.h | 3 ++ include/linux/ipc_namespace.h | 3 ++ ipc/msg.c | 10 +++-- ipc/namespace.c | 20 +++-- ipc/sem.c | 11 +++-- ipc/shm.c | 12 ++--

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Tue, Aug 15, 2017 at 12:41 PM, Linus Torvalds wrote: > > So if we have unnecessarily collisions because we have waiters looking > at different bits of the same page, we could just hash in the bit > number that we're waiting for too. Oh, nope, we can't do that,

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Tue, Aug 15, 2017 at 12:41 PM, Linus Torvalds wrote: > > So if we have unnecessarily collisions because we have waiters looking > at different bits of the same page, we could just hash in the bit > number that we're waiting for too. Oh, nope, we can't do that, because we only have one

Re: [PATCH] printk-formats.txt: Add examples for %pS and %pF

On 15.08.2017 21:41, Helge Deller wrote: > On 15.08.2017 14:46, Steven Rostedt wrote: >> On Thu, 10 Aug 2017 19:35:33 +0200 >> Helge Deller wrote: >> >>> Sometimes people seems unclear when to use the %pS or %pF printk format. >>> Adding some examples may help to avoid such

Re: [PATCH] printk-formats.txt: Add examples for %pS and %pF

On 15.08.2017 21:41, Helge Deller wrote: > On 15.08.2017 14:46, Steven Rostedt wrote: >> On Thu, 10 Aug 2017 19:35:33 +0200 >> Helge Deller wrote: >> >>> Sometimes people seems unclear when to use the %pS or %pF printk format. >>> Adding some examples may help to avoid such mistakes. >>> >>> See

[GIT PULL] lkdtm updates for next, part 2

Hi Greg, Please pull these additional lkdtm changes for next. Thanks! -Kees The following changes since commit c7fea48876773603721f545f8c1a2f894291ef85: lkdtm: Provide timing tests for atomic_t vs refcount_t (2017-07-26 14:38:04 -0700) are available in the git repository at:

[GIT PULL] lkdtm updates for next, part 2

Hi Greg, Please pull these additional lkdtm changes for next. Thanks! -Kees The following changes since commit c7fea48876773603721f545f8c1a2f894291ef85: lkdtm: Provide timing tests for atomic_t vs refcount_t (2017-07-26 14:38:04 -0700) are available in the git repository at:

Re: [PATCH] printk-formats.txt: Add examples for %pS and %pF

On 15.08.2017 14:46, Steven Rostedt wrote: > On Thu, 10 Aug 2017 19:35:33 +0200 > Helge Deller wrote: > >> Sometimes people seems unclear when to use the %pS or %pF printk format. >> Adding some examples may help to avoid such mistakes. >> >> See for example commit 51d96dc2e2dc

Re: [PATCH] printk-formats.txt: Add examples for %pS and %pF

On 15.08.2017 14:46, Steven Rostedt wrote: > On Thu, 10 Aug 2017 19:35:33 +0200 > Helge Deller wrote: > >> Sometimes people seems unclear when to use the %pS or %pF printk format. >> Adding some examples may help to avoid such mistakes. >> >> See for example commit 51d96dc2e2dc ("random: fix

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Tue, Aug 15, 2017 at 12:05 PM, Tim Chen wrote: > > We have a test case but it is a customer workload. We'll try to get > a bit more info. Ok. Being a customer workload is lovely in the sense that it is actually a real load, not just a microbecnhmark. But yeah, it

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Tue, Aug 15, 2017 at 12:05 PM, Tim Chen wrote: > > We have a test case but it is a customer workload. We'll try to get > a bit more info. Ok. Being a customer workload is lovely in the sense that it is actually a real load, not just a microbecnhmark. But yeah, it makes it harder to describe

[PATCH v3 net-next] bpf/verifier: track liveness for pruning

State of a register doesn't matter if it wasn't read in reaching an exit; a write screens off all reads downstream of it from all explored_states upstream of it. This allows us to prune many more branches; here are some processed insn counts for some Cilium programs: Program

[PATCH v3 net-next] bpf/verifier: track liveness for pruning

State of a register doesn't matter if it wasn't read in reaching an exit; a write screens off all reads downstream of it from all explored_states upstream of it. This allows us to prune many more branches; here are some processed insn counts for some Cilium programs: Program

[PATCH] crypto: inside-secure - fix an error handling path in safexcel_probe()

'ret' is known to be 0 at this point. If 'safexcel_request_ring_irq()' fails, it returns an error code. Return this value instead of 0 which means success. Signed-off-by: Christophe JAILLET --- drivers/crypto/inside-secure/safexcel.c | 5 +++-- 1 file changed, 3

[PATCH] crypto: inside-secure - fix an error handling path in safexcel_probe()

'ret' is known to be 0 at this point. If 'safexcel_request_ring_irq()' fails, it returns an error code. Return this value instead of 0 which means success. Signed-off-by: Christophe JAILLET --- drivers/crypto/inside-secure/safexcel.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

Re: [PATCH 2/9] ASoC: cygnus: Update bindings for audio clock changes

On 8/15/2017 10:14 AM, Mark Brown wrote: > On Mon, Aug 14, 2017 at 03:06:50PM -0700, Lori Hikichi wrote: >> Allow each audio port to select which clock (if any) it wants to use. > Why is this in DT for the port and not either using standard clock > bindings to configure the clock tree or allowing

Re: [PATCH 2/9] ASoC: cygnus: Update bindings for audio clock changes

On 8/15/2017 10:14 AM, Mark Brown wrote: > On Mon, Aug 14, 2017 at 03:06:50PM -0700, Lori Hikichi wrote: >> Allow each audio port to select which clock (if any) it wants to use. > Why is this in DT for the port and not either using standard clock > bindings to configure the clock tree or allowing

Re: [PATCH] ioctl_tty.2: add TIOCGPTPEER documentation

On 06/09/2017 07:01 PM, Aleksa Sarai wrote: > The feature this patch references has currently only been accepted into > tty-testing, but Greg told me to kick this down to man-pages. As a > result, I can't reference upstream commit id's because the code isn't in > Linus' tree yet -- should I resend

Re: [PATCH] ioctl_tty.2: add TIOCGPTPEER documentation

On 06/09/2017 07:01 PM, Aleksa Sarai wrote: > The feature this patch references has currently only been accepted into > tty-testing, but Greg told me to kick this down to man-pages. As a > result, I can't reference upstream commit id's because the code isn't in > Linus' tree yet -- should I resend

Re: [PATCH] earlycon: initialise baud field of earlycon device structure

On Tue, Aug 15, 2017 at 12:21 PM, Eugeniy Paltsev wrote: > For now baud field of earlycon structure device is't initialised at all > in of_setup_earlycon (in oppositе to register_earlycon). > > So when I use stdout-path to point earlycon device > (like stdout-path =

Re: [PATCH] earlycon: initialise baud field of earlycon device structure

On Tue, Aug 15, 2017 at 12:21 PM, Eugeniy Paltsev wrote: > For now baud field of earlycon structure device is't initialised at all > in of_setup_earlycon (in oppositе to register_earlycon). > > So when I use stdout-path to point earlycon device > (like stdout-path = or stdout-path =

[PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with cr3

From: Sai Praneeth Use helper function (efi_switch_mm()) to switch to/from efi_mm. We switch to efi_mm before calling 1. efi_set_virtual_address_map() and 2. Invoking any efi_runtime_service() Likewise, we need to switch back to previous mm (mm context stolen by

[PATCH 2/3] x86/efi: Replace efi_pgd with efi_mm.pgd

From: Sai Praneeth Since the previous patch added support for efi_mm, let's handle efi_pgd through efi_mm and remove global variable efi_pgd. Signed-off-by: Sai Praneeth Prakhya Cc: Lee, Chun-Yi Cc: Borislav Petkov

[PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with cr3

From: Sai Praneeth Use helper function (efi_switch_mm()) to switch to/from efi_mm. We switch to efi_mm before calling 1. efi_set_virtual_address_map() and 2. Invoking any efi_runtime_service() Likewise, we need to switch back to previous mm (mm context stolen by efi_mm) after the above calls

[PATCH 2/3] x86/efi: Replace efi_pgd with efi_mm.pgd

From: Sai Praneeth Since the previous patch added support for efi_mm, let's handle efi_pgd through efi_mm and remove global variable efi_pgd. Signed-off-by: Sai Praneeth Prakhya Cc: Lee, Chun-Yi Cc: Borislav Petkov Cc: Andy Lutomirski Cc: Michael S. Tsirkin Cc: Ricardo Neri Cc: Matt

[PATCH 1/3] efi: Use efi_mm in x86 as well as ARM

From: Sai Praneeth Presently, only ARM uses mm_struct to manage efi page tables and efi runtime region mappings. As this is the preferred approach, let's make this data structure common across architectures. Specially, for x86, using this data structure improves

[PATCH 1/3] efi: Use efi_mm in x86 as well as ARM

From: Sai Praneeth Presently, only ARM uses mm_struct to manage efi page tables and efi runtime region mappings. As this is the preferred approach, let's make this data structure common across architectures. Specially, for x86, using this data structure improves code maintainability and

[PATCH 0/3] Use mm_struct and switch_mm() instead of manually

From: Sai Praneeth Presently, in x86, to invoke any efi function like efi_set_virtual_address_map() or any efi_runtime_service() the code path typically involves read_cr3() (save previous pgd), write_cr3() (write efi_pgd) and calling efi function. Likewise after

[PATCH 0/3] Use mm_struct and switch_mm() instead of manually

From: Sai Praneeth Presently, in x86, to invoke any efi function like efi_set_virtual_address_map() or any efi_runtime_service() the code path typically involves read_cr3() (save previous pgd), write_cr3() (write efi_pgd) and calling efi function. Likewise after returning from efi function the

Re: [PATCH v2 1/3] dt-bindings: add eeprom "size" property

On Mon, Aug 14, 2017 at 1:41 PM, Divagar Mohandass wrote: > This adds eeprom "size" as optional property for i2c eeproms. > > "size" should be mentioned in byte and it should refer > to the eeprom size. This will be read by the driver and > used to calculating the

Re: [PATCH v2 1/3] dt-bindings: add eeprom "size" property

On Mon, Aug 14, 2017 at 1:41 PM, Divagar Mohandass wrote: > This adds eeprom "size" as optional property for i2c eeproms. > > "size" should be mentioned in byte and it should refer > to the eeprom size. This will be read by the driver and > used to calculating the number of bytes in read/write

Re: [PATCH v2] acpi: apei: fix the wrongly iterate generic error status block

On Tue, Aug 15, 2017 at 12:31:14PM -0600, Baicar, Tyler wrote: > His patch fixes the define for apei_estatus_for_each_section which in turn > should fix ghes_do_proc(). So my patch should no longer be needed. I see. We're keeping the macro, of course. > I'm going to test this out just to verify

Re: [PATCH v2] acpi: apei: fix the wrongly iterate generic error status block

On Tue, Aug 15, 2017 at 12:31:14PM -0600, Baicar, Tyler wrote: > His patch fixes the define for apei_estatus_for_each_section which in turn > should fix ghes_do_proc(). So my patch should no longer be needed. I see. We're keeping the macro, of course. > I'm going to test this out just to verify

Re: [PATCH] string.h: work around __builtin_constant_p quirk

On Mon, Aug 7, 2017 at 3:29 PM, Arnd Bergmann wrote: > On Mon, Aug 7, 2017 at 11:15 AM, Arnd Bergmann wrote: >> The compile-time check in the hardened memcpy() triggered a build >> error in code that should not have: >> >> In function 'memcpy', >> inlined from

Re: [PATCH] string.h: work around __builtin_constant_p quirk

On Mon, Aug 7, 2017 at 3:29 PM, Arnd Bergmann wrote: > On Mon, Aug 7, 2017 at 11:15 AM, Arnd Bergmann wrote: >> The compile-time check in the hardened memcpy() triggered a build >> error in code that should not have: >> >> In function 'memcpy', >> inlined from '__adfs_dir_put' at

Re: [PATCH 2/2] mm: Update NUMA counter threshold size

On Tue, Aug 15, 2017 at 10:51:21AM -0700, Tim Chen wrote: > On 08/15/2017 10:30 AM, Mel Gorman wrote: > > On Tue, Aug 15, 2017 at 09:55:39AM -0700, Tim Chen wrote: > > >> > >> Doubling the threshold and counter size will help, but not as much > >> as making them above u8 limit as seen in Kemi's

Re: [PATCH 2/2] mm: Update NUMA counter threshold size

On Tue, Aug 15, 2017 at 10:51:21AM -0700, Tim Chen wrote: > On 08/15/2017 10:30 AM, Mel Gorman wrote: > > On Tue, Aug 15, 2017 at 09:55:39AM -0700, Tim Chen wrote: > > >> > >> Doubling the threshold and counter size will help, but not as much > >> as making them above u8 limit as seen in Kemi's

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On 08/14/2017 08:28 PM, Linus Torvalds wrote: > On Mon, Aug 14, 2017 at 8:15 PM, Andi Kleen wrote: >> But what should we do when some other (non page) wait queue runs into the >> same problem? > > Hopefully the same: root-cause it. > > Once you have a test-case, it should

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On 08/14/2017 08:28 PM, Linus Torvalds wrote: > On Mon, Aug 14, 2017 at 8:15 PM, Andi Kleen wrote: >> But what should we do when some other (non page) wait queue runs into the >> same problem? > > Hopefully the same: root-cause it. > > Once you have a test-case, it should generally be fairly

Re: [PATCH 0/5] perf script: Add support for exporting to sqlite3

Em Tue, Aug 15, 2017 at 12:25:24PM +0300, Adrian Hunter escreveu: > On 03/08/17 11:31, Adrian Hunter wrote: > > Hi > > > > Here is a script for exporting to SQLite 3 the same data as the PostgreSQL > > export. The call-graph script is renamed and amended to work with both > > PostgreSQL and

Re: [PATCH 0/5] perf script: Add support for exporting to sqlite3

Em Tue, Aug 15, 2017 at 12:25:24PM +0300, Adrian Hunter escreveu: > On 03/08/17 11:31, Adrian Hunter wrote: > > Hi > > > > Here is a script for exporting to SQLite 3 the same data as the PostgreSQL > > export. The call-graph script is renamed and amended to work with both > > PostgreSQL and

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