Re: [PATCH v2 08/11] Documentation: phy: Let the rockchip eMMC PHY get an exported card clock

On Mon, Jun 13, 2016 at 04:04:32PM -0700, Douglas Anderson wrote: > As of an earlier change in this series ("Documentation: mmc: > sdhci-of-arasan: Add ability to export card clock") the SDHCI driver > used on Rockchip SoCs can now expose its clock. Let's now specify that > the PHY can use it. >

Re: [PATCH v2 08/11] Documentation: phy: Let the rockchip eMMC PHY get an exported card clock

On Mon, Jun 13, 2016 at 04:04:32PM -0700, Douglas Anderson wrote: > As of an earlier change in this series ("Documentation: mmc: > sdhci-of-arasan: Add ability to export card clock") the SDHCI driver > used on Rockchip SoCs can now expose its clock. Let's now specify that > the PHY can use it. >

Re: [PATCH 1/3] drivers/media/dvb-core/en50221: use kref to manage struct dvb_ca_private

On 2016/06/16 18:06, Shuah Khan wrote: > On 06/15/2016 02:15 PM, Max Kellermann wrote: > > Don't free the object until the file handle has been closed. Fixes > > use-after-free bug which occurs when I disconnect my DVB-S received > > while VDR is running. > > Which file

Re: [PATCH 1/3] drivers/media/dvb-core/en50221: use kref to manage struct dvb_ca_private

On 2016/06/16 18:06, Shuah Khan wrote: > On 06/15/2016 02:15 PM, Max Kellermann wrote: > > Don't free the object until the file handle has been closed. Fixes > > use-after-free bug which occurs when I disconnect my DVB-S received > > while VDR is running. > > Which file handle? /dev/dvb--- I

Re: [PATCH 10/13] x86/dumpstack: Try harder to get a call trace on stack overflow

On Thu, Jun 16, 2016 at 11:33 AM, Josh Poimboeuf wrote: > On Thu, Jun 16, 2016 at 11:22:14AM -0700, Andy Lutomirski wrote: >> On Thu, Jun 16, 2016 at 11:16 AM, Josh Poimboeuf wrote: >> > On Wed, Jun 15, 2016 at 05:28:32PM -0700, Andy Lutomirski wrote: >>

Re: [PATCH 10/13] x86/dumpstack: Try harder to get a call trace on stack overflow

On Thu, Jun 16, 2016 at 11:33 AM, Josh Poimboeuf wrote: > On Thu, Jun 16, 2016 at 11:22:14AM -0700, Andy Lutomirski wrote: >> On Thu, Jun 16, 2016 at 11:16 AM, Josh Poimboeuf wrote: >> > On Wed, Jun 15, 2016 at 05:28:32PM -0700, Andy Lutomirski wrote: >> >> If we overflow the stack,

Re: [PATCH 10/13] x86/dumpstack: Try harder to get a call trace on stack overflow

On Thu, Jun 16, 2016 at 11:22:14AM -0700, Andy Lutomirski wrote: > On Thu, Jun 16, 2016 at 11:16 AM, Josh Poimboeuf wrote: > > On Wed, Jun 15, 2016 at 05:28:32PM -0700, Andy Lutomirski wrote: > >> If we overflow the stack, print_context_stack will abort. Detect > >> this

Re: [PATCH 10/13] x86/dumpstack: Try harder to get a call trace on stack overflow

On Thu, Jun 16, 2016 at 11:22:14AM -0700, Andy Lutomirski wrote: > On Thu, Jun 16, 2016 at 11:16 AM, Josh Poimboeuf wrote: > > On Wed, Jun 15, 2016 at 05:28:32PM -0700, Andy Lutomirski wrote: > >> If we overflow the stack, print_context_stack will abort. Detect > >> this case and rewind back

[PATCH v2] tty: serial: msm: Don't reconfigure same baud rate

msm_set_termios() is called whenever the tty is opened. Setting the baud rate requires a full reset of the msm serial block, even when the rate is unchanged. In the case when the same uart is used as console this reset will discard any console output data still being clocked out of the TX fifo.

[PATCH v2] tty: serial: msm: Don't reconfigure same baud rate

msm_set_termios() is called whenever the tty is opened. Setting the baud rate requires a full reset of the msm serial block, even when the rate is unchanged. In the case when the same uart is used as console this reset will discard any console output data still being clocked out of the TX fifo.

Re: [PATCH 10/13] x86/dumpstack: Try harder to get a call trace on stack overflow

On Thu, Jun 16, 2016 at 11:16 AM, Josh Poimboeuf wrote: > On Wed, Jun 15, 2016 at 05:28:32PM -0700, Andy Lutomirski wrote: >> If we overflow the stack, print_context_stack will abort. Detect >> this case and rewind back into the valid part of the stack so that >> we can

Re: [PATCH 10/13] x86/dumpstack: Try harder to get a call trace on stack overflow

On Thu, Jun 16, 2016 at 11:16 AM, Josh Poimboeuf wrote: > On Wed, Jun 15, 2016 at 05:28:32PM -0700, Andy Lutomirski wrote: >> If we overflow the stack, print_context_stack will abort. Detect >> this case and rewind back into the valid part of the stack so that >> we can trace it. >> >>

Re: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival

On Thu 16-06-16 18:08:57, Odzioba, Lukasz wrote: > On Thru 09-06-16 02:22 PM Michal Hocko wrote: > > I agree it would be better to do the same for others as well. Even if > > this is not an immediate problem for those. > > I am not able to find clear reasons why we shouldn't do it for the rest. >

Re: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival

On Thu 16-06-16 18:08:57, Odzioba, Lukasz wrote: > On Thru 09-06-16 02:22 PM Michal Hocko wrote: > > I agree it would be better to do the same for others as well. Even if > > this is not an immediate problem for those. > > I am not able to find clear reasons why we shouldn't do it for the rest. >

Re: [PATCH 10/13] x86/dumpstack: Try harder to get a call trace on stack overflow

On Wed, Jun 15, 2016 at 05:28:32PM -0700, Andy Lutomirski wrote: > If we overflow the stack, print_context_stack will abort. Detect > this case and rewind back into the valid part of the stack so that > we can trace it. > > Signed-off-by: Andy Lutomirski > --- >

Re: [PATCH 10/13] x86/dumpstack: Try harder to get a call trace on stack overflow

On Wed, Jun 15, 2016 at 05:28:32PM -0700, Andy Lutomirski wrote: > If we overflow the stack, print_context_stack will abort. Detect > this case and rewind back into the valid part of the stack so that > we can trace it. > > Signed-off-by: Andy Lutomirski > --- > arch/x86/kernel/dumpstack.c | 7

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

Adding Paul, because RCU blew up. On Thu, Jun 16, 2016 at 10:50 AM, Andy Lutomirski wrote: > On Wed, Jun 15, 2016 at 11:05 PM, Heiko Carstens > wrote: >> On Wed, Jun 15, 2016 at 05:28:22PM -0700, Andy Lutomirski wrote: >>> Since the dawn of time,

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

Adding Paul, because RCU blew up. On Thu, Jun 16, 2016 at 10:50 AM, Andy Lutomirski wrote: > On Wed, Jun 15, 2016 at 11:05 PM, Heiko Carstens > wrote: >> On Wed, Jun 15, 2016 at 05:28:22PM -0700, Andy Lutomirski wrote: >>> Since the dawn of time, a kernel stack overflow has been a real PITA >>>

Re: [patch 13/20] timer: Switch to a non cascading wheel

On Thu, Jun 16, 2016 at 09:02:15AM -0700, Paul E. McKenney wrote: > > 2) When we do that right, we can make the tick frequency a command line > > option > >and just have a compiled in default. > > As long as there is something that tells RCU what the tick frequency > actually is at runtime,

Re: [patch 13/20] timer: Switch to a non cascading wheel

On Thu, Jun 16, 2016 at 09:02:15AM -0700, Paul E. McKenney wrote: > > 2) When we do that right, we can make the tick frequency a command line > > option > >and just have a compiled in default. > > As long as there is something that tells RCU what the tick frequency > actually is at runtime,

Re: linux-next: Tree for Jun 16 (linux/firmware.h)

Quoting Randy Dunlap (2016-06-16 09:46:43) > [adding Stephen Boyd] > > On 06/16/16 08:02, Randy Dunlap wrote: > > On 06/15/16 22:49, Stephen Rothwell wrote: > >> Hi all, > >> > >> Changes since 20160615: > >> > > > > on i386 and/or x86_64: > > > > In file included from

Re: linux-next: Tree for Jun 16 (linux/firmware.h)

Quoting Randy Dunlap (2016-06-16 09:46:43) > [adding Stephen Boyd] > > On 06/16/16 08:02, Randy Dunlap wrote: > > On 06/15/16 22:49, Stephen Rothwell wrote: > >> Hi all, > >> > >> Changes since 20160615: > >> > > > > on i386 and/or x86_64: > > > > In file included from

Re: [PATCH 6/8] net: gianfar: fix old-style declaration

On Thu, 2016-06-16 at 21:02 +0300, Sergei Shtylyov wrote: > On 06/16/2016 04:52 PM, Arnd Bergmann wrote: > > Modern C standards expect the '__inline__' keyword to come before the return > > type in a declaration, and we get a warning for this with "make W=1": [] > > diff --git

Re: [PATCH 6/8] net: gianfar: fix old-style declaration

On Thu, 2016-06-16 at 21:02 +0300, Sergei Shtylyov wrote: > On 06/16/2016 04:52 PM, Arnd Bergmann wrote: > > Modern C standards expect the '__inline__' keyword to come before the return > > type in a declaration, and we get a warning for this with "make W=1": [] > > diff --git

RE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival

On Thru 09-06-16 02:22 PM Michal Hocko wrote: > I agree it would be better to do the same for others as well. Even if > this is not an immediate problem for those. I am not able to find clear reasons why we shouldn't do it for the rest. Ok so what do we do now? I'll send v2 with proposed changes.

RE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival

On Thru 09-06-16 02:22 PM Michal Hocko wrote: > I agree it would be better to do the same for others as well. Even if > this is not an immediate problem for those. I am not able to find clear reasons why we shouldn't do it for the rest. Ok so what do we do now? I'll send v2 with proposed changes.

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

On Thu, 2016-06-16 at 10:55 -0700, Benjamin Poirier wrote: > On 2016/06/13 11:46, Netanel Belgazal wrote: [...] > > +static ssize_t ena_show_small_copy_len(struct device *dev, > > +    struct device_attribute *attr, char *buf) > > +{ > > + struct ena_adapter

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

On Thu, 2016-06-16 at 10:55 -0700, Benjamin Poirier wrote: > On 2016/06/13 11:46, Netanel Belgazal wrote: [...] > > +static ssize_t ena_show_small_copy_len(struct device *dev, > > +    struct device_attribute *attr, char *buf) > > +{ > > + struct ena_adapter

Re: [PATCH v2 1/3] firmware: arm_scpi: add support for device power state management

On Thu, 2016-06-16 at 11:37 +0100, Sudeep Holla wrote: > SCPI protocol supports device power state management. This deals with > power states of various peripheral devices in the system other than the > core compute subsystem. > > This patch adds support for the power state management of those >

Re: [PATCH v2 1/3] firmware: arm_scpi: add support for device power state management

On Thu, 2016-06-16 at 11:37 +0100, Sudeep Holla wrote: > SCPI protocol supports device power state management. This deals with > power states of various peripheral devices in the system other than the > core compute subsystem. > > This patch adds support for the power state management of those >

Re: [PATCH 6/8] net: gianfar: fix old-style declaration

Hello. On 06/16/2016 04:52 PM, Arnd Bergmann wrote: Modern C standards expect the '__inline__' keyword to come before the return type in a declaration, and we get a warning for this with "make W=1": drivers/net/ethernet/freescale/gianfar.c:2278:1: error: 'inline' is not at beginning of

Re: [PATCH 6/8] net: gianfar: fix old-style declaration

Hello. On 06/16/2016 04:52 PM, Arnd Bergmann wrote: Modern C standards expect the '__inline__' keyword to come before the return type in a declaration, and we get a warning for this with "make W=1": drivers/net/ethernet/freescale/gianfar.c:2278:1: error: 'inline' is not at beginning of

Re: [PATCH] sparc64: Swap registers for fault code and address in mna trap

Your patch has been whitespace corrupted by your email client. Also, the correct mailing list to submit Sparc patches to is sparcli...@vger.kernel.org

Re: [PATCH] sparc64: Swap registers for fault code and address in mna trap

Your patch has been whitespace corrupted by your email client. Also, the correct mailing list to submit Sparc patches to is sparcli...@vger.kernel.org

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

On 16/06/16 18:47, Jon Medhurst (Tixy) wrote: On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote: [...] +enum scpi_power_domain_state { + SCPI_PD_STATE_ON = 0, + SCPI_PD_STATE_OFF = 3, +}; The SCPI doc defines the meaning of these numbers (0 and 3) in the 'Juno specifics'

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

On 16/06/16 18:47, Jon Medhurst (Tixy) wrote: On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote: [...] +enum scpi_power_domain_state { + SCPI_PD_STATE_ON = 0, + SCPI_PD_STATE_OFF = 3, +}; The SCPI doc defines the meaning of these numbers (0 and 3) in the 'Juno specifics'

Re: [PATCH 08/13] x86/dumpstack: When OOPSing, rewind the stack before do_exit

On Thu, Jun 16, 2016 at 10:50 AM, Josh Poimboeuf wrote: > On Wed, Jun 15, 2016 at 05:28:30PM -0700, Andy Lutomirski wrote: >> If we call do_exit with a clean stack, we greatly reduce the risk of >> recursive oopses due to stack overflow in do_exit, and we allow >> do_exit to

Re: [PATCH] dsa: b53: fix big-endian register access

On 06/16/2016 02:00 AM, Arnd Bergmann wrote: > The b53 dsa register access confusingly uses __raw register accessors > when both the CPU and the device are big-endian, but it uses little- > endian accessors when the same device is used from a little-endian > CPU, which makes no sense. > > This

Re: [PATCH 4/5] usb: pxa27x_udc: remove unused function argument

Arnd Bergmann writes: > We get a warning for this when building with W=1 because the > argument gets assigned to something else but never read: > > drivers/usb/gadget/udc/pxa27x_udc.c: In function 'stop_activity': > drivers/usb/gadget/udc/pxa27x_udc.c:1828:74: error: parameter

Re: [PATCH 4/5] usb: pxa27x_udc: remove unused function argument

Arnd Bergmann writes: > We get a warning for this when building with W=1 because the > argument gets assigned to something else but never read: > > drivers/usb/gadget/udc/pxa27x_udc.c: In function 'stop_activity': > drivers/usb/gadget/udc/pxa27x_udc.c:1828:74: error: parameter 'driver' set >

Re: [PATCH 08/13] x86/dumpstack: When OOPSing, rewind the stack before do_exit

On Thu, Jun 16, 2016 at 10:50 AM, Josh Poimboeuf wrote: > On Wed, Jun 15, 2016 at 05:28:30PM -0700, Andy Lutomirski wrote: >> If we call do_exit with a clean stack, we greatly reduce the risk of >> recursive oopses due to stack overflow in do_exit, and we allow >> do_exit to work even if we OOPS

Re: [PATCH] dsa: b53: fix big-endian register access

On 06/16/2016 02:00 AM, Arnd Bergmann wrote: > The b53 dsa register access confusingly uses __raw register accessors > when both the CPU and the device are big-endian, but it uses little- > endian accessors when the same device is used from a little-endian > CPU, which makes no sense. > > This

[PATCH net-next v5 6/7] vmxnet3: introduce command to register memory region

In vmxnet3 version 3, the emulation added support for the vmxnet3 driver to communicate information about the memory regions the driver will use for rx/tx buffers. The driver can also indicate which rx/tx queue the memory region is applicable for. If this information is communicated to the

[PATCH net-next v5 3/7] vmxnet3: allow variable length transmit data ring buffer

vmxnet3 driver supports transmit data ring viz. a set of fixed size buffers used by the driver to copy packet headers. Small packets that fit these buffers are copied into these buffers entirely. Currently this buffer size of fixed at 128 bytes. This patch extends transmit data ring

[PATCH net-next v5 6/7] vmxnet3: introduce command to register memory region

In vmxnet3 version 3, the emulation added support for the vmxnet3 driver to communicate information about the memory regions the driver will use for rx/tx buffers. The driver can also indicate which rx/tx queue the memory region is applicable for. If this information is communicated to the

[PATCH net-next v5 3/7] vmxnet3: allow variable length transmit data ring buffer

vmxnet3 driver supports transmit data ring viz. a set of fixed size buffers used by the driver to copy packet headers. Small packets that fit these buffers are copied into these buffers entirely. Currently this buffer size of fixed at 128 bytes. This patch extends transmit data ring

[PATCH net-next v5 0/7] vmxnet3: upgrade to version 3

vmxnet3 emulation has recently added several new features which includes support for new commands the driver can issue to emulation, change in descriptor fields etc. This patch series extends the vmxnet3 driver to leverage these new features. Compatibility is maintained using existing vmxnet3

[PATCH net-next v5 5/7] vmxnet3: add support for get_coalesce, set_coalesce ethtool operations

The emulation supports a variety of coalescing modes viz. disabled (no coalescing), adaptive, static (number of packets to batch before raising an interrupt), rate based (number of interrupts per second). This patch implements get_coalesce and set_coalesce methods to allow querying and

[PATCH net-next v5 0/7] vmxnet3: upgrade to version 3

vmxnet3 emulation has recently added several new features which includes support for new commands the driver can issue to emulation, change in descriptor fields etc. This patch series extends the vmxnet3 driver to leverage these new features. Compatibility is maintained using existing vmxnet3

[PATCH net-next v5 5/7] vmxnet3: add support for get_coalesce, set_coalesce ethtool operations

The emulation supports a variety of coalescing modes viz. disabled (no coalescing), adaptive, static (number of packets to batch before raising an interrupt), rate based (number of interrupts per second). This patch implements get_coalesce and set_coalesce methods to allow querying and

[PATCH net-next v5 7/7] vmxnet3: update to version 3

With all vmxnet3 version 3 changes incorporated in the vmxnet3 driver, the driver can configure emulation to run at vmxnet3 version 3, provided the emulation advertises support for version 3. Signed-off-by: Shrikrishna Khare --- drivers/net/vmxnet3/vmxnet3_drv.c | 7 ++-

[PATCH net-next v5 7/7] vmxnet3: update to version 3

With all vmxnet3 version 3 changes incorporated in the vmxnet3 driver, the driver can configure emulation to run at vmxnet3 version 3, provided the emulation advertises support for version 3. Signed-off-by: Shrikrishna Khare --- drivers/net/vmxnet3/vmxnet3_drv.c | 7 ++-

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

On 2016/06/13 11:46, Netanel Belgazal wrote: [...] > + > +static int ena_set_coalesce(struct net_device *net_dev, > + struct ethtool_coalesce *coalesce) > +{ > + struct ena_adapter *adapter = netdev_priv(net_dev); > + struct ena_com_dev *ena_dev = adapter->ena_dev;

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

On 2016/06/13 11:46, Netanel Belgazal wrote: [...] > + > +static int ena_set_coalesce(struct net_device *net_dev, > + struct ethtool_coalesce *coalesce) > +{ > + struct ena_adapter *adapter = netdev_priv(net_dev); > + struct ena_com_dev *ena_dev = adapter->ena_dev;

[PATCH net-next v5 2/7] vmxnet3: introduce generalized command interface to configure the device

Shared memory is used to exchange information between the vmxnet3 driver and the emulation. In order to request emulation to perform a task, the driver first populates specific fields in this shared memory and then issues corresponding command by writing to the command register(CMD). The layout of

[PATCH net-next v5 2/7] vmxnet3: introduce generalized command interface to configure the device

Shared memory is used to exchange information between the vmxnet3 driver and the emulation. In order to request emulation to perform a task, the driver first populates specific fields in this shared memory and then issues corresponding command by writing to the command register(CMD). The layout of

[PATCH net-next v5 4/7] vmxnet3: add receive data ring support

vmxnet3 driver preallocates buffers for receiving packets and posts the buffers to the emulation. In order to deliver a received packet to the guest, the emulation must map buffer(s) and copy the packet into it. To avoid this memory mapping overhead, this patch introduces the receive data ring -

[PATCH net-next v5 4/7] vmxnet3: add receive data ring support

vmxnet3 driver preallocates buffers for receiving packets and posts the buffers to the emulation. In order to deliver a received packet to the guest, the emulation must map buffer(s) and copy the packet into it. To avoid this memory mapping overhead, this patch introduces the receive data ring -

[PATCH v3] of: fix memory leak related to safe_name()

From: Frank Rowand Fix a memory leak resulting from memory allocation in safe_name(). This patch fixes all call sites of safe_name(). Mathieu Malaterre reported the memory leak on boot: On my PowerMac device-tree would generate a duplicate name: [0.023043]

[PATCH net-next v5 1/7] vmxnet3: prepare for version 3 changes

vmxnet3 is currently at version 2, but some command definitions from previous vmxnet3 versions are missing. Add those definitions before moving to version 3. Also, introduce utility macros for vmxnet3 version comparison and update Copyright information and Maintained by. Signed-off-by:

[PATCH v3] of: fix memory leak related to safe_name()

From: Frank Rowand Fix a memory leak resulting from memory allocation in safe_name(). This patch fixes all call sites of safe_name(). Mathieu Malaterre reported the memory leak on boot: On my PowerMac device-tree would generate a duplicate name: [0.023043] device-tree: Duplicate name in

[PATCH net-next v5 1/7] vmxnet3: prepare for version 3 changes

vmxnet3 is currently at version 2, but some command definitions from previous vmxnet3 versions are missing. Add those definitions before moving to version 3. Also, introduce utility macros for vmxnet3 version comparison and update Copyright information and Maintained by. Signed-off-by:

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

On Wed, Jun 15, 2016 at 11:05 PM, Heiko Carstens wrote: > On Wed, Jun 15, 2016 at 05:28:22PM -0700, Andy Lutomirski wrote: >> Since the dawn of time, a kernel stack overflow has been a real PITA >> to debug, has caused nondeterministic crashes some time after the >>

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

On Wed, Jun 15, 2016 at 11:05 PM, Heiko Carstens wrote: > On Wed, Jun 15, 2016 at 05:28:22PM -0700, Andy Lutomirski wrote: >> Since the dawn of time, a kernel stack overflow has been a real PITA >> to debug, has caused nondeterministic crashes some time after the >> actual overflow, and has

Re: [PATCH 08/13] x86/dumpstack: When OOPSing, rewind the stack before do_exit

On Wed, Jun 15, 2016 at 05:28:30PM -0700, Andy Lutomirski wrote: > If we call do_exit with a clean stack, we greatly reduce the risk of > recursive oopses due to stack overflow in do_exit, and we allow > do_exit to work even if we OOPS from an IST stack. The latter gives > us a much better chance

Re: [PATCH 08/13] x86/dumpstack: When OOPSing, rewind the stack before do_exit

On Wed, Jun 15, 2016 at 05:28:30PM -0700, Andy Lutomirski wrote: > If we call do_exit with a clean stack, we greatly reduce the risk of > recursive oopses due to stack overflow in do_exit, and we allow > do_exit to work even if we OOPS from an IST stack. The latter gives > us a much better chance

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

On Wed, Jun 15, 2016 at 11:34:11AM -0400, Christopher Covington wrote: > From: Tomasz Nowicki > > pci_generic_ecam_ops is used by default. Since there are platforms > which have non-compliant ECAM space we need to overwrite these > accessors prior to PCI buses enumeration. In

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

On Wed, Jun 15, 2016 at 11:34:11AM -0400, Christopher Covington wrote: > From: Tomasz Nowicki > > pci_generic_ecam_ops is used by default. Since there are platforms > which have non-compliant ECAM space we need to overwrite these > accessors prior to PCI buses enumeration. In order to do that >

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote: [...] > +enum scpi_power_domain_state { > + SCPI_PD_STATE_ON = 0, > + SCPI_PD_STATE_OFF = 3, > +}; The SCPI doc defines the meaning of these numbers (0 and 3) in the 'Juno specifics' chapter. So does these values need to come from

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote: [...] > +enum scpi_power_domain_state { > + SCPI_PD_STATE_ON = 0, > + SCPI_PD_STATE_OFF = 3, > +}; The SCPI doc defines the meaning of these numbers (0 and 3) in the 'Juno specifics' chapter. So does these values need to come from

Re: [PATCH v2] of: fix memory leak related to safe_name()

On 06/16/16 00:51, Mathieu Malaterre wrote: > Sorry, symptoms not solved. According to kmemleak, I have now: > > [ 661.323100] kmemleak: 100 new suspected memory leaks (see > /sys/kernel/debug/kmemleak) > [ 1260.226120] kmemleak: 1 new suspected memory leaks (see > /sys/kernel/debug/kmemleak) >

Re: [PATCH v2] of: fix memory leak related to safe_name()

On 06/16/16 00:51, Mathieu Malaterre wrote: > Sorry, symptoms not solved. According to kmemleak, I have now: > > [ 661.323100] kmemleak: 100 new suspected memory leaks (see > /sys/kernel/debug/kmemleak) > [ 1260.226120] kmemleak: 1 new suspected memory leaks (see > /sys/kernel/debug/kmemleak) >

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

On Thu, Jun 16, 2016 at 05:04:24PM +0200, Andreas Schwab wrote: > Peter Zijlstra writes: > > > If not, do you want me to 'fix' this or just remove the comment? > > It's not broken, so nothing to fix. Its non obvious code, that's usually plenty reason to change it. Geert,

Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

On Thu, Jun 16, 2016 at 05:04:24PM +0200, Andreas Schwab wrote: > Peter Zijlstra writes: > > > If not, do you want me to 'fix' this or just remove the comment? > > It's not broken, so nothing to fix. Its non obvious code, that's usually plenty reason to change it. Geert, you maintain this

Re: [PATCH 04/13] mm: Track NR_KERNEL_STACK in pages instead of number of stacks

On Thu, Jun 16, 2016 at 8:33 AM, Josh Poimboeuf wrote: > On Wed, Jun 15, 2016 at 05:28:26PM -0700, Andy Lutomirski wrote: >> Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a >> zone. This only makes sense if each kernel stack exists entirely in >> one zone,

Re: [PATCH 04/13] mm: Track NR_KERNEL_STACK in pages instead of number of stacks

On Thu, Jun 16, 2016 at 8:33 AM, Josh Poimboeuf wrote: > On Wed, Jun 15, 2016 at 05:28:26PM -0700, Andy Lutomirski wrote: >> Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a >> zone. This only makes sense if each kernel stack exists entirely in >> one zone, and allowing vmapped

Re: [PATCH] [ACPI] Change structure initialisation to C99 style

On Tue, Jun 14, 2016 at 1:42 AM, Amitoj Kaur Chawla wrote: > Replace the in order struct initialisation style with explicit field > style. > > The Coccinelle semantic patch used to make this change is as follows: > > @decl@ > identifier i1,fld; > type T; > field list[n] fs;

Re: [PATCH] [ACPI] Change structure initialisation to C99 style

On Tue, Jun 14, 2016 at 1:42 AM, Amitoj Kaur Chawla wrote: > Replace the in order struct initialisation style with explicit field > style. > > The Coccinelle semantic patch used to make this change is as follows: > > @decl@ > identifier i1,fld; > type T; > field list[n] fs; > @@ > > struct i1 { >

Re: [PATCH 2/2] scsi: wd7000: print sector number as 64-bit

Hi, [auto build test WARNING on scsi/for-next] [also build test WARNING on v4.7-rc3 next-20160616] [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/Arnd-Bergmann/scsi-lpfc-avoid-harmless

Re: [PATCH 2/2] scsi: wd7000: print sector number as 64-bit

Hi, [auto build test WARNING on scsi/for-next] [also build test WARNING on v4.7-rc3 next-20160616] [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/Arnd-Bergmann/scsi-lpfc-avoid-harmless

Re: [PATCH 06/13] fork: Add generic vmalloced stack support

On Thu, Jun 16, 2016 at 10:25 AM, Kees Cook wrote: > On Wed, Jun 15, 2016 at 5:28 PM, Andy Lutomirski wrote: >> If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with >> vmalloc_node. >> >> Signed-off-by: Andy Lutomirski >>

Re: [PATCH 06/13] fork: Add generic vmalloced stack support

On Thu, Jun 16, 2016 at 10:25 AM, Kees Cook wrote: > On Wed, Jun 15, 2016 at 5:28 PM, Andy Lutomirski wrote: >> If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with >> vmalloc_node. >> >> Signed-off-by: Andy Lutomirski >> --- >> arch/Kconfig | 12 >> kernel/fork.c |

Re: [PATCH] sched/fair: initialize throttle_count for new task-groups lazily

Konstantin Khlebnikov writes: > On 16.06.2016 20:03, bseg...@google.com wrote: >> Konstantin Khlebnikov writes: >> >>> Cgroup created inside throttled group must inherit current throttle_count. >>> Broken throttle_count allows to nominate

Re: [PATCH] sched/fair: initialize throttle_count for new task-groups lazily

Konstantin Khlebnikov writes: > On 16.06.2016 20:03, bseg...@google.com wrote: >> Konstantin Khlebnikov writes: >> >>> Cgroup created inside throttled group must inherit current throttle_count. >>> Broken throttle_count allows to nominate throttled entries as a next buddy, >>> later this leads

Re: [PATCH 06/13] fork: Add generic vmalloced stack support

On Wed, Jun 15, 2016 at 5:28 PM, Andy Lutomirski wrote: > If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with > vmalloc_node. > > Signed-off-by: Andy Lutomirski > --- > arch/Kconfig | 12 > kernel/fork.c | 45

Re: [PATCH 06/13] fork: Add generic vmalloced stack support

On Wed, Jun 15, 2016 at 5:28 PM, Andy Lutomirski wrote: > If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with > vmalloc_node. > > Signed-off-by: Andy Lutomirski > --- > arch/Kconfig | 12 > kernel/fork.c | 45 + > 2 files

Re: [PATCH] sched/fair: initialize throttle_count for new task-groups lazily

On 16.06.2016 20:03, bseg...@google.com wrote: Konstantin Khlebnikov writes: Cgroup created inside throttled group must inherit current throttle_count. Broken throttle_count allows to nominate throttled entries as a next buddy, later this leads to null pointer

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

On Wed, Jun 15, 2016 at 5:28 PM, Andy Lutomirski wrote: > Since the dawn of time, a kernel stack overflow has been a real PITA > to debug, has caused nondeterministic crashes some time after the > actual overflow, and has generally been easy to exploit for root. > > With this

Re: Kernel 4.7rc3 - Performance drop 30-40% for SPECjbb2005 and SPECjvm2008 benchmarks against 4.6 kernel

On Thu, Jun 16, 2016 at 06:38:50PM +0200, Jirka Hladky wrote: > Hello, > > we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008 Blergh, of course I don't have those.. :/ > benchmarks starting from 4.7.0-0.rc0 kernel compared to 4.6 kernel. > > We have tested kernels 4.7.0-0.rc1 and

Re: [PATCH] sched/fair: initialize throttle_count for new task-groups lazily

On 16.06.2016 20:03, bseg...@google.com wrote: Konstantin Khlebnikov writes: Cgroup created inside throttled group must inherit current throttle_count. Broken throttle_count allows to nominate throttled entries as a next buddy, later this leads to null pointer dereference in

Re: [PATCH 00/13] Virtually mapped stacks with guard pages (x86, core)

On Wed, Jun 15, 2016 at 5:28 PM, Andy Lutomirski wrote: > Since the dawn of time, a kernel stack overflow has been a real PITA > to debug, has caused nondeterministic crashes some time after the > actual overflow, and has generally been easy to exploit for root. > > With this series, arches can

Re: Kernel 4.7rc3 - Performance drop 30-40% for SPECjbb2005 and SPECjvm2008 benchmarks against 4.6 kernel

On Thu, Jun 16, 2016 at 06:38:50PM +0200, Jirka Hladky wrote: > Hello, > > we see performance drop 30-40% for SPECjbb2005 and SPECjvm2008 Blergh, of course I don't have those.. :/ > benchmarks starting from 4.7.0-0.rc0 kernel compared to 4.6 kernel. > > We have tested kernels 4.7.0-0.rc1 and

[RFC] [PATCH 2/3] staging: media: omap1: convert to videobuf2

Created and tested on Amstrad Delta on top of Linux-4.7-rc3 with "staging: media: omap1: drop videobuf-dma-sg mode" applied. Signed-off-by: Janusz Krzysztofik --- drivers/staging/media/omap1/Kconfig| 2 +- drivers/staging/media/omap1/omap1_camera.c | 363

[RFC] [PATCH 3/3] staging: media: omap1: use dmaengine

Created and tested on Amstrad Delta on top of Linux-4.7-rc3 with "staging: media: omap1: convert to videobuf2" applied. Signed-off-by: Janusz Krzysztofik --- drivers/staging/media/omap1/Kconfig| 2 +- drivers/staging/media/omap1/omap1_camera.c | 432

[RFC] [PATCH 2/3] staging: media: omap1: convert to videobuf2

Created and tested on Amstrad Delta on top of Linux-4.7-rc3 with "staging: media: omap1: drop videobuf-dma-sg mode" applied. Signed-off-by: Janusz Krzysztofik --- drivers/staging/media/omap1/Kconfig| 2 +- drivers/staging/media/omap1/omap1_camera.c | 363 -

[RFC] [PATCH 3/3] staging: media: omap1: use dmaengine

Created and tested on Amstrad Delta on top of Linux-4.7-rc3 with "staging: media: omap1: convert to videobuf2" applied. Signed-off-by: Janusz Krzysztofik --- drivers/staging/media/omap1/Kconfig| 2 +- drivers/staging/media/omap1/omap1_camera.c | 432 + 2

Re: [RFC PATCH 2/2] KVM: x86: use __kvm_guest_exit

On 16/06/2016 19:03, David Matlack wrote: > > > If you make the else case the same as svm_handle_external_intr, can we > > > avoid requiring ack-intr-on-exit? > > > > Yes, but the sti/nop/cli would be useless if ack-intr-on-exit is > > available. It's a bit ugly, so I RFCed the bold thing

[RFC] [PATCH 1/3] staging: media: omap1: drop videobuf-dma-sg mode

For over 20 last kernel versions the driver has been able to allocate DMA buffers in videobuf-dma-contig mode without any issues. Drop the no longer needed sg mode in preparation for conversion to videobuf2. Created and tested on Amstrad Delta against Linux-4.7-rc3 with omap1_camera and ov6650

[RFC] [PATCH 1/3] staging: media: omap1: drop videobuf-dma-sg mode

For over 20 last kernel versions the driver has been able to allocate DMA buffers in videobuf-dma-contig mode without any issues. Drop the no longer needed sg mode in preparation for conversion to videobuf2. Created and tested on Amstrad Delta against Linux-4.7-rc3 with omap1_camera and ov6650

Re: [RFC PATCH 2/2] KVM: x86: use __kvm_guest_exit

On 16/06/2016 19:03, David Matlack wrote: > > > If you make the else case the same as svm_handle_external_intr, can we > > > avoid requiring ack-intr-on-exit? > > > > Yes, but the sti/nop/cli would be useless if ack-intr-on-exit is > > available. It's a bit ugly, so I RFCed the bold thing

<    3   4   5   6   7   8   9   10   11   12   >