Re: [PATCH v2 01/25] mtd: nand: qcom: fix config error for BCH

On 2017-08-04 00:17, Boris Brezillon wrote: On Thu, 03 Aug 2017 23:22:37 +0530 Abhishek Sahu wrote: On 2017-08-03 21:26, Boris Brezillon wrote: > On Wed, 19 Jul 2017 17:17:49 +0530 > Abhishek Sahu wrote: > >> The configuration for BCH is not

Re: [PATCH v2 01/25] mtd: nand: qcom: fix config error for BCH

On 2017-08-04 00:17, Boris Brezillon wrote: On Thu, 03 Aug 2017 23:22:37 +0530 Abhishek Sahu wrote: On 2017-08-03 21:26, Boris Brezillon wrote: > On Wed, 19 Jul 2017 17:17:49 +0530 > Abhishek Sahu wrote: > >> The configuration for BCH is not correct in the current driver. >> The

Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from EP

On Thu, Aug 03, 2017 at 01:50:29PM +0530, Oza Oza wrote: > On Thu, Aug 3, 2017 at 2:34 AM, Bjorn Helgaas wrote: > > On Thu, Jul 06, 2017 at 08:39:41AM +0530, Oza Pawandeep wrote: > >> For Configuration Requests only, following reset it is possible for a > >> device to

Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from EP

On Thu, Aug 03, 2017 at 01:50:29PM +0530, Oza Oza wrote: > On Thu, Aug 3, 2017 at 2:34 AM, Bjorn Helgaas wrote: > > On Thu, Jul 06, 2017 at 08:39:41AM +0530, Oza Pawandeep wrote: > >> For Configuration Requests only, following reset it is possible for a > >> device to terminate the request but

Re: [PATCH v2 1/4] dt-bindings: phy-hisi-inno-usb2: add support for hisi-inno-usb2 phy

On Wed, Jul 26, 2017 at 02:06:00PM +0800, Jiancheng Xue wrote: > Add support for hisi-inno-usb2 phy. > > Signed-off-by: Jiancheng Xue > --- > .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 31 > ++ > 1 file changed, 31 insertions(+) >

Re: [PATCH v2 1/4] dt-bindings: phy-hisi-inno-usb2: add support for hisi-inno-usb2 phy

On Wed, Jul 26, 2017 at 02:06:00PM +0800, Jiancheng Xue wrote: > Add support for hisi-inno-usb2 phy. > > Signed-off-by: Jiancheng Xue > --- > .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 31 > ++ > 1 file changed, 31 insertions(+) > create mode 100644 >

Re: [PATCH v6 2/3]: perf/core: use context tstamp_data for skipped events on mux interrupt

On 03.08.2017 18:00, Peter Zijlstra wrote: > On Wed, Aug 02, 2017 at 11:15:39AM +0300, Alexey Budankov wrote: >> @@ -772,6 +780,10 @@ struct perf_event_context { >> */ >> u64 time; >> u64 timestamp; >> +/* >> + *

Re: [PATCH v6 2/3]: perf/core: use context tstamp_data for skipped events on mux interrupt

On 03.08.2017 18:00, Peter Zijlstra wrote: > On Wed, Aug 02, 2017 at 11:15:39AM +0300, Alexey Budankov wrote: >> @@ -772,6 +780,10 @@ struct perf_event_context { >> */ >> u64 time; >> u64 timestamp; >> +/* >> + *

Re: [PATCH v2 01/25] mtd: nand: qcom: fix config error for BCH

On Thu, 03 Aug 2017 23:22:37 +0530 Abhishek Sahu wrote: > On 2017-08-03 21:26, Boris Brezillon wrote: > > On Wed, 19 Jul 2017 17:17:49 +0530 > > Abhishek Sahu wrote: > > > >> The configuration for BCH is not correct in the current driver. > >>

Re: [PATCH v2 01/25] mtd: nand: qcom: fix config error for BCH

On Thu, 03 Aug 2017 23:22:37 +0530 Abhishek Sahu wrote: > On 2017-08-03 21:26, Boris Brezillon wrote: > > On Wed, 19 Jul 2017 17:17:49 +0530 > > Abhishek Sahu wrote: > > > >> The configuration for BCH is not correct in the current driver. > >> The ECC_CFG_ECC_DISABLE bit defines whether to

[PATCH 1/2] ipc/sem: drop sem_checkid helper

... 'tis not used. Signed-off-by: Davidlohr Bueso --- ipc/sem.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/ipc/sem.c b/ipc/sem.c index 9e70cd7a17da..e9980cba07fd 100644 --- a/ipc/sem.c +++ b/ipc/sem.c @@ -130,8 +130,6 @@ struct sem_undo_list { #define sem_ids(ns)

[PATCH 1/2] ipc/sem: drop sem_checkid helper

... 'tis not used. Signed-off-by: Davidlohr Bueso --- ipc/sem.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/ipc/sem.c b/ipc/sem.c index 9e70cd7a17da..e9980cba07fd 100644 --- a/ipc/sem.c +++ b/ipc/sem.c @@ -130,8 +130,6 @@ struct sem_undo_list { #define sem_ids(ns)

[PATCH 2/2] ipc/sem: play nicer with large nsops allocations

Replacing semop()'s kmalloc for kvmalloc was originally proposed by Manfred on the premise that it can be called for large (than order-1) sizes. For example, while Oracle recommends setting SEMOPM to a _minimum_ of 100, some distros[1] encourage the setting to be a factor of the amount of db tasks

[PATCH 2/2] ipc/sem: play nicer with large nsops allocations

Replacing semop()'s kmalloc for kvmalloc was originally proposed by Manfred on the premise that it can be called for large (than order-1) sizes. For example, while Oracle recommends setting SEMOPM to a _minimum_ of 100, some distros[1] encourage the setting to be a factor of the amount of db tasks

Re: [PATCH] clk: uniphier: remove sLD3 SoC support

On Wed, Jul 26, 2017 at 12:34:35PM +0900, Masahiro Yamada wrote: > This SoC is too old. It is difficult to maintain any longer. > > Signed-off-by: Masahiro Yamada > --- > > .../devicetree/bindings/clock/uniphier-clock.txt | 5 --- >

Re: [PATCH] clk: uniphier: remove sLD3 SoC support

On Wed, Jul 26, 2017 at 12:34:35PM +0900, Masahiro Yamada wrote: > This SoC is too old. It is difficult to maintain any longer. > > Signed-off-by: Masahiro Yamada > --- > > .../devicetree/bindings/clock/uniphier-clock.txt | 5 --- > drivers/clk/uniphier/clk-uniphier-core.c | 16

[PATCH v6 1/7] drm/tilcdc: ensure nonatomic iowrite64 is not used

Add a check to ensure iowrite64 is only used if it is atomic. It was decided in [1] that the tilcdc driver should not be using an atomic operation (so it was left out of this patchset). However, it turns out that through the drm code, a nonatomic header is actually included:

[PATCH v6 1/7] drm/tilcdc: ensure nonatomic iowrite64 is not used

Add a check to ensure iowrite64 is only used if it is atomic. It was decided in [1] that the tilcdc driver should not be using an atomic operation (so it was left out of this patchset). However, it turns out that through the drm code, a nonatomic header is actually included:

[PATCH v6 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Acked-by: Dave Jiang Acked-by: Allen Hubbe

[PATCH v6 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Acked-by: Dave Jiang Acked-by: Allen Hubbe Acked-by: Jon Mason --- drivers/ntb/hw/intel/ntb_hw_intel.c | 30

[PATCH v6 0/7] make io{read|write}64 globally usable

Changes since v5: - Added a fix to the tilcdc driver to ensure it doesn't use the non-atomic operation. (This includes adding io{read|write}64[be]_is_nonatomic defines). Changes since v4: - Add functions so the powerpc implementation of iomap.c compiles. (As noticed by Horia) Changes since

[PATCH v6 0/7] make io{read|write}64 globally usable

Changes since v5: - Added a fix to the tilcdc driver to ensure it doesn't use the non-atomic operation. (This includes adding io{read|write}64[be]_is_nonatomic defines). Changes since v4: - Add functions so the powerpc implementation of iomap.c compiles. (As noticed by Horia) Changes since

[PATCH v6 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

[PATCH v6 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

[PATCH v6 4/7] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq

[PATCH v6 4/7] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq

[PATCH v6 2/7] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

Subsequent patches in this series makes use of the readq and writeq defines in iomap.h. However, as is, they get missed on the powerpc platform seeing the include comes before the define. This patch moves the include down to fix this. Signed-off-by: Logan Gunthorpe Acked-By:

[PATCH v6 2/7] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

Subsequent patches in this series makes use of the readq and writeq defines in iomap.h. However, as is, they get missed on the powerpc platform seeing the include comes before the define. This patch moves the include down to fix this. Signed-off-by: Logan Gunthorpe Acked-By: Michael Ellerman

[PATCH v6 3/7] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

These functions will be introduced into the generic iomap.c so they can deal with PIO accesses in hi-lo/lo-hi variants. Thus, the powerpc version of iomap.c will need to provide the same functions even though, in this arch, they are identical to the regular io{read|write}64 functions.

[PATCH v6 3/7] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

These functions will be introduced into the generic iomap.c so they can deal with PIO accesses in hi-lo/lo-hi variants. Thus, the powerpc version of iomap.c will need to provide the same functions even though, in this arch, they are identical to the regular io{read|write}64 functions.

[PATCH v6 7/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

From: Horia Geantă We can now make use of the io-64-nonatomic-lo-hi header to always provide 64 bit IO operations. So this patch cleans up the extra CONFIG_64BIT ifdefs. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device

[PATCH v6 7/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

From: Horia Geantă We can now make use of the io-64-nonatomic-lo-hi header to always provide 64 bit IO operations. So this patch cleans up the extra CONFIG_64BIT ifdefs. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device endianness, the lower address

[PATCH v4 05/15] NTB: Ensure ntb_mw_get_align() is only called when the link is up

With Switchtec hardware it's impossible to get the alignment parameters for a peer's memory window until the peer's driver has configured its windows. Strictly speaking, the link doesn't have to be up for this, but the link being up is the only way the client can tell that the other side has been

[PATCH v4 05/15] NTB: Ensure ntb_mw_get_align() is only called when the link is up

With Switchtec hardware it's impossible to get the alignment parameters for a peer's memory window until the peer's driver has configured its windows. Strictly speaking, the link doesn't have to be up for this, but the link being up is the only way the client can tell that the other side has been

[PATCH v4 03/15] NTB: switchtec: Add NTB hardware register definitions

There are two additional regions: ctrl and dbmsg. The first is for generic NTB control and memory windows. The second is for doorbells and message registers. This patch also adds a number of related constants for using these registers. Signed-off-by: Logan Gunthorpe

[PATCH v4 03/15] NTB: switchtec: Add NTB hardware register definitions

There are two additional regions: ctrl and dbmsg. The first is for generic NTB control and memory windows. The second is for doorbells and message registers. This patch also adds a number of related constants for using these registers. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates

[PATCH v4 06/15] NTB: Add check and comment for link up to mw_count() and mw_get_align()

Adds a comment and a check to ntb_mw_get_align() so that it always fails if the function is called before the link is up. Also adds a comment to ntb_mw_count() to note that it may return 0 if it is called before the link is up. This is to prevent accidental mis-use in clients that are testing on

[PATCH v4 06/15] NTB: Add check and comment for link up to mw_count() and mw_get_align()

Adds a comment and a check to ntb_mw_get_align() so that it always fails if the function is called before the link is up. Also adds a comment to ntb_mw_count() to note that it may return 0 if it is called before the link is up. This is to prevent accidental mis-use in clients that are testing on

[PATCH v4 09/15] NTB: switchtec_ntb: Initialize hardware for doorbells and messages

Set up some hardware registers and creates interrupt service routines for the doorbells and messages. There are 64 doorbells in the switch that are shared between all partitions. The upper 4 doorbells are also shared with the messages and are therefore not used. Thus, this provides 28 doorbells

[PATCH v4 09/15] NTB: switchtec_ntb: Initialize hardware for doorbells and messages

Set up some hardware registers and creates interrupt service routines for the doorbells and messages. There are 64 doorbells in the switch that are shared between all partitions. The upper 4 doorbells are also shared with the messages and are therefore not used. Thus, this provides 28 doorbells

[PATCH v4 01/15] NTB: switchtec: Move structure definitions into a common header

Create the switchtec.h header in include/linux with hardware defines and the switchtec_dev structure. Both moved directly from switchtec.c. This is a prep patch for creating an NTB driver for Switchtec. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates

[PATCH v4 04/15] NTB: switchtec: Add link event notifier callback

In order for the Switchtec NTB code to handle link change events we create a notifier callback in the switchtec code which gets called whenever an appropriate event interrupt occurs. In order to preserve userspace's ability to follow these events, we compare the event count with a stored copy

[PATCH v4 01/15] NTB: switchtec: Move structure definitions into a common header

Create the switchtec.h header in include/linux with hardware defines and the switchtec_dev structure. Both moved directly from switchtec.c. This is a prep patch for creating an NTB driver for Switchtec. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates Reviewed-by: Kurt Schwemmer

[PATCH v4 04/15] NTB: switchtec: Add link event notifier callback

In order for the Switchtec NTB code to handle link change events we create a notifier callback in the switchtec code which gets called whenever an appropriate event interrupt occurs. In order to preserve userspace's ability to follow these events, we compare the event count with a stored copy

[PATCH v4 15/15] NTB: switchtec_ntb: Update switchtec documentation with notes for NTB

The switchtec_ntb driver has a couple requirements on the switchec's hardware configuration so we add these notes to the documentation. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates Reviewed-by: Kurt Schwemmer

[PATCH v4 15/15] NTB: switchtec_ntb: Update switchtec documentation with notes for NTB

The switchtec_ntb driver has a couple requirements on the switchec's hardware configuration so we add these notes to the documentation. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates Reviewed-by: Kurt Schwemmer Acked-by: Allen Hubbe --- Documentation/switchtec.txt | 12

[PATCH v4 10/15] NTB: switchtec_ntb: Add skeleton NTB driver

Add a skeleton NTB driver which will be filled out in subsequent patches. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates Reviewed-by: Kurt Schwemmer Acked-by: Allen Hubbe ---

[PATCH v4 02/15] NTB: switchtec: Export class symbol for use in upper layer driver

We export the class pointer symbol and add an extern define in the Switchtec header file. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates Reviewed-by: Kurt Schwemmer Acked-by: Bjorn Helgaas

[PATCH v4 10/15] NTB: switchtec_ntb: Add skeleton NTB driver

Add a skeleton NTB driver which will be filled out in subsequent patches. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates Reviewed-by: Kurt Schwemmer Acked-by: Allen Hubbe --- drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 148 - include/linux/ntb.h

[PATCH v4 02/15] NTB: switchtec: Export class symbol for use in upper layer driver

We export the class pointer symbol and add an extern define in the Switchtec header file. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates Reviewed-by: Kurt Schwemmer Acked-by: Bjorn Helgaas --- drivers/pci/switch/switchtec.c | 4 +++- include/linux/switchtec.h | 2 ++ 2 files

[PATCH v4 00/15] Switchtec NTB Support

Changes since v3: - Rebased onto the Jon's ntb branch that contains one of the patches that was in v3 - Various spelling and commit log mistakes noticed by Bjorn - Renamed switchtec_ntb to ntb_hw_switchtec per Dave's suggestion - Fixed a number of code nits pointed out by Jon -- Changes since

[PATCH v4 00/15] Switchtec NTB Support

Changes since v3: - Rebased onto the Jon's ntb branch that contains one of the patches that was in v3 - Various spelling and commit log mistakes noticed by Bjorn - Renamed switchtec_ntb to ntb_hw_switchtec per Dave's suggestion - Fixed a number of code nits pointed out by Jon -- Changes since

[PATCH v4 08/15] NTB: switchtec_ntb: Initialize hardware for memory windows

Add the code to initialize the memory windows in the hardware. This includes setting up the requester ID table, and figuring out which BAR corresponds to which memory window. (Seeing the switch can be configured with any number of BARs.) Also, seeing the device doesn't have hardware for

[PATCH v4 08/15] NTB: switchtec_ntb: Initialize hardware for memory windows

Add the code to initialize the memory windows in the hardware. This includes setting up the requester ID table, and figuring out which BAR corresponds to which memory window. (Seeing the switch can be configured with any number of BARs.) Also, seeing the device doesn't have hardware for

[PATCH v4 07/15] NTB: switchtec_ntb: Introduce initial NTB driver

Seeing the Switchtec NTB hardware shares the same endpoint as the management endpoint we utilize the class_interface API to register an NTB driver for every Switchtec device in the system that has the NTB class code. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates

[PATCH v4 07/15] NTB: switchtec_ntb: Introduce initial NTB driver

Seeing the Switchtec NTB hardware shares the same endpoint as the management endpoint we utilize the class_interface API to register an NTB driver for every Switchtec device in the system that has the NTB class code. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates Reviewed-by: Kurt

[PATCH v4 12/15] NTB: switchtec_ntb: Implement doorbell registers

Pretty straightforward implementation of doorbell registers. The shift and mask were setup in an earlier patch and this just hooks up the appropriate portion of the IDB register as the local doorbells and the opposite portion of ODB as the peer doorbells. The DB mask is protected by a spinlock to

[PATCH v4 12/15] NTB: switchtec_ntb: Implement doorbell registers

Pretty straightforward implementation of doorbell registers. The shift and mask were setup in an earlier patch and this just hooks up the appropriate portion of the IDB register as the local doorbells and the opposite portion of ODB as the peer doorbells. The DB mask is protected by a spinlock to

[PATCH v4 14/15] NTB: switchtec_ntb: Add memory window support

The Switchtec hardware has two types of memory windows: LUTs and Direct. The first area in each BAR is for LUT windows and the remaining area is for the direct region. The total number of LUT entries is set by a configuration setting in hardware and they all must be the same size. (This is fixed

[PATCH v4 14/15] NTB: switchtec_ntb: Add memory window support

The Switchtec hardware has two types of memory windows: LUTs and Direct. The first area in each BAR is for LUT windows and the remaining area is for the direct region. The total number of LUT entries is set by a configuration setting in hardware and they all must be the same size. (This is fixed

[PATCH v4 13/15] NTB: switchtec_ntb: Implement scratchpad registers

Seeing there is no dedicated hardware for this, we simply add these as entries in the shared memory window. Thus, we could support any number of them but 128 seems like enough, for now. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates

[PATCH v4 13/15] NTB: switchtec_ntb: Implement scratchpad registers

Seeing there is no dedicated hardware for this, we simply add these as entries in the shared memory window. Thus, we could support any number of them but 128 seems like enough, for now. Signed-off-by: Logan Gunthorpe Reviewed-by: Stephen Bates Reviewed-by: Kurt Schwemmer Acked-by: Allen Hubbe

[PATCH v4 11/15] NTB: switchtec_ntb: Add link management

switchtec_ntb checks for a link by looking at the shared memory window. If the magic number is correct and the other side indicates their link is enabled then we take the link to be up. Whenever we change our local link status we send a msg to the other side to check whether it's up and change

[PATCH v4 11/15] NTB: switchtec_ntb: Add link management

switchtec_ntb checks for a link by looking at the shared memory window. If the magic number is correct and the other side indicates their link is enabled then we take the link to be up. Whenever we change our local link status we send a msg to the other side to check whether it's up and change

Re: suspicious __GFP_NOMEMALLOC in selinux

On Thu, Aug 3, 2017 at 7:05 AM, Michal Hocko wrote: > On Thu 03-08-17 19:44:46, Tetsuo Handa wrote: >> Michal Hocko wrote: >> > On Thu 03-08-17 19:02:57, Tetsuo Handa wrote: >> > > On 2017/08/03 17:11, Michal Hocko wrote: >> > > > [CC Mel] >> > > > >> > > > On Wed 02-08-17

Re: suspicious __GFP_NOMEMALLOC in selinux

On Thu, Aug 3, 2017 at 7:05 AM, Michal Hocko wrote: > On Thu 03-08-17 19:44:46, Tetsuo Handa wrote: >> Michal Hocko wrote: >> > On Thu 03-08-17 19:02:57, Tetsuo Handa wrote: >> > > On 2017/08/03 17:11, Michal Hocko wrote: >> > > > [CC Mel] >> > > > >> > > > On Wed 02-08-17 17:45:56, Paul Moore

Re: [PATCH net-next] net: dsa: Add support for 64-bit statistics

On Thu, Aug 03, 2017 at 10:30:56AM -0700, Florian Fainelli wrote: > On 08/02/2017 04:49 PM, David Miller wrote: > > From: Florian Fainelli > > Date: Tue, 1 Aug 2017 15:00:36 -0700 > > > >> DSA slave network devices maintain a pair of bytes and packets counters > >> for

Re: [PATCH net-next] net: dsa: Add support for 64-bit statistics

On Thu, Aug 03, 2017 at 10:30:56AM -0700, Florian Fainelli wrote: > On 08/02/2017 04:49 PM, David Miller wrote: > > From: Florian Fainelli > > Date: Tue, 1 Aug 2017 15:00:36 -0700 > > > >> DSA slave network devices maintain a pair of bytes and packets counters > >> for each directions, but

Re: [PATCH v3 net-next 1/5] net: dsa: lan9303: Change lan9303_xxx_packet_processing() port param.

On 08/03/2017 02:45 AM, Egil Hjelmeland wrote: > lan9303_enable_packet_processing, lan9303_disable_packet_processing() > Pass port number (0,1,2) as parameter instead of port offset. > Because other functions in the module pass port numbers. > And to enable simplifications in following patch. > >

Re: [PATCH v3 net-next 1/5] net: dsa: lan9303: Change lan9303_xxx_packet_processing() port param.

On 08/03/2017 02:45 AM, Egil Hjelmeland wrote: > lan9303_enable_packet_processing, lan9303_disable_packet_processing() > Pass port number (0,1,2) as parameter instead of port offset. > Because other functions in the module pass port numbers. > And to enable simplifications in following patch. > >

Re: [PATCH v3 net-next 4/5] net: dsa: lan9303: Rename lan9303_xxx_packet_processing()

On 08/03/2017 02:45 AM, Egil Hjelmeland wrote: > The lan9303_enable_packet_processing, lan9303_disable_packet_processing > functions operate on port, so the names should reflect that. > And to align with lan9303_disable_processing(), rename: > > lan9303_enable_packet_processing ->

Re: [PATCH v3 net-next 4/5] net: dsa: lan9303: Rename lan9303_xxx_packet_processing()

On 08/03/2017 02:45 AM, Egil Hjelmeland wrote: > The lan9303_enable_packet_processing, lan9303_disable_packet_processing > functions operate on port, so the names should reflect that. > And to align with lan9303_disable_processing(), rename: > > lan9303_enable_packet_processing ->

Re: [patch] perf wrong enabled time after attach/enable/enable

On Wed, 2 Aug 2017, Peter Zijlstra wrote: > Playing with that test it really is the IOC_DISABLE while STOP'ed that > messes things up. > > Ah.. magic.. the below seems to fix things, hopefully it doesn't break > anything else. yes, I've tested this and it seems to fix things. With both this

Re: [patch] perf wrong enabled time after attach/enable/enable

On Wed, 2 Aug 2017, Peter Zijlstra wrote: > Playing with that test it really is the IOC_DISABLE while STOP'ed that > messes things up. > > Ah.. magic.. the below seems to fix things, hopefully it doesn't break > anything else. yes, I've tested this and it seems to fix things. With both this

Re: [PATCH v3 net-next 3/5] net: dsa: lan9303: Simplify lan9303_xxx_packet_processing() usage

On 08/03/2017 02:45 AM, Egil Hjelmeland wrote: > Simplify usage of lan9303_enable_packet_processing, > lan9303_disable_packet_processing() > > Signed-off-by: Egil Hjelmeland Reviewed-by: Florian Fainelli took a little while to figure out that

Re: [PATCH v3 net-next 3/5] net: dsa: lan9303: Simplify lan9303_xxx_packet_processing() usage

On 08/03/2017 02:45 AM, Egil Hjelmeland wrote: > Simplify usage of lan9303_enable_packet_processing, > lan9303_disable_packet_processing() > > Signed-off-by: Egil Hjelmeland Reviewed-by: Florian Fainelli took a little while to figure out that we are utilizing fall through of the switch/case

Re: [PATCH v3 net-next 5/5] net: dsa: lan9303: refactor lan9303_get_ethtool_stats

On 08/03/2017 02:45 AM, Egil Hjelmeland wrote: > In lan9303_get_ethtool_stats: Get rid of 0x400 constant magic > by using new lan9303_read_switch_reg() inside loop. > Reduced scope of two variables. > > Signed-off-by: Egil Hjelmeland > --- >

Re: [PATCH v3 net-next 5/5] net: dsa: lan9303: refactor lan9303_get_ethtool_stats

On 08/03/2017 02:45 AM, Egil Hjelmeland wrote: > In lan9303_get_ethtool_stats: Get rid of 0x400 constant magic > by using new lan9303_read_switch_reg() inside loop. > Reduced scope of two variables. > > Signed-off-by: Egil Hjelmeland > --- > drivers/net/dsa/lan9303-core.c | 26

[PATCH v2] arm64: avoid overflow in VA_START and PAGE_OFFSET

The bitmask used to define these values produces overflow, as seen by this compiler warning: arch/arm64/kernel/head.S:47:8: warning: integer overflow in preprocessor expression #elif (PAGE_OFFSET & 0x1f) != 0 ^~~ arch/arm64/include/asm/memory.h:52:46: note:

Re: perf: bug in rdpmc/mmap accounting after exec

On Wed, 2 Aug 2017, Peter Zijlstra wrote: > On Wed, Jul 26, 2017 at 03:39:01PM -0400, Vince Weaver wrote: > > In fact, current->mm->context.perf_rdpmc_allowed goes negative which seems > > like it shouldn't happen? > > Good find that... > > The below seems to fix that for me. yes, I can

[PATCH v2] arm64: avoid overflow in VA_START and PAGE_OFFSET

The bitmask used to define these values produces overflow, as seen by this compiler warning: arch/arm64/kernel/head.S:47:8: warning: integer overflow in preprocessor expression #elif (PAGE_OFFSET & 0x1f) != 0 ^~~ arch/arm64/include/asm/memory.h:52:46: note:

Re: perf: bug in rdpmc/mmap accounting after exec

On Wed, 2 Aug 2017, Peter Zijlstra wrote: > On Wed, Jul 26, 2017 at 03:39:01PM -0400, Vince Weaver wrote: > > In fact, current->mm->context.perf_rdpmc_allowed goes negative which seems > > like it shouldn't happen? > > Good find that... > > The below seems to fix that for me. yes, I can

Re: [PATCH v3 net-next 2/5] net: dsa: lan9303: define LAN9303_NUM_PORTS 3

On 08/03/2017 02:45 AM, Egil Hjelmeland wrote: > Will be used instead of '3' in upcomming patches. > > Signed-off-by: Egil Hjelmeland Reviewed-by: Florian Fainelli -- Florian

Re: [PATCH v3 net-next 2/5] net: dsa: lan9303: define LAN9303_NUM_PORTS 3

On 08/03/2017 02:45 AM, Egil Hjelmeland wrote: > Will be used instead of '3' in upcomming patches. > > Signed-off-by: Egil Hjelmeland Reviewed-by: Florian Fainelli -- Florian

Re: [PATCH v2 02/25] mtd: nand: qcom: program NAND_DEV_CMD_VLD register

On 2017-08-03 21:17, Boris Brezillon wrote: On Wed, 19 Jul 2017 17:17:50 +0530 Abhishek Sahu wrote: The current driver is failing without complete bootchain since NAND_DEV_CMD_VLD value is not valid. Signed-off-by: Abhishek Sahu ---

Re: [PATCH v2 02/25] mtd: nand: qcom: program NAND_DEV_CMD_VLD register

On 2017-08-03 21:17, Boris Brezillon wrote: On Wed, 19 Jul 2017 17:17:50 +0530 Abhishek Sahu wrote: The current driver is failing without complete bootchain since NAND_DEV_CMD_VLD value is not valid. Signed-off-by: Abhishek Sahu --- drivers/mtd/nand/qcom_nandc.c | 4 1 file changed, 4

Re: [PATCH v2 1/2] kernel/events: Add option to notify through signals on wakeup

On Tue, 1 Aug 2017, Naveen N. Rao wrote: > Add a new option 'signal_on_wakeup' to request for a signal to be > delivered on ring buffer wakeup controlled through watermark and > {wakeup_events, wakeup_watermark}. HUP is signaled on exit. > > Setting signal_on_wakeup disables use of IOC_REFRESH

Re: [PATCH v2 1/2] kernel/events: Add option to notify through signals on wakeup

On Tue, 1 Aug 2017, Naveen N. Rao wrote: > Add a new option 'signal_on_wakeup' to request for a signal to be > delivered on ring buffer wakeup controlled through watermark and > {wakeup_events, wakeup_watermark}. HUP is signaled on exit. > > Setting signal_on_wakeup disables use of IOC_REFRESH

Re: [PATCH 01/11] arm64: docs: describe ELF hwcaps

On Wed, Jul 19, 2017 at 9:01 AM, Mark Rutland wrote: > We don't document our ELF hwcaps, leaving developers to interpret them > according to hearsay, guesswork, or (in exceptional cases) inspection of > the current kernel code. > > This is less than optimal, and it would be

Re: [PATCH 01/11] arm64: docs: describe ELF hwcaps

On Wed, Jul 19, 2017 at 9:01 AM, Mark Rutland wrote: > We don't document our ELF hwcaps, leaving developers to interpret them > according to hearsay, guesswork, or (in exceptional cases) inspection of > the current kernel code. > > This is less than optimal, and it would be far better if we had

Re: [PATCH v2 02/25] mtd: nand: qcom: program NAND_DEV_CMD_VLD register

On 2017-08-03 21:18, Boris Brezillon wrote: On Wed, 19 Jul 2017 17:17:50 +0530 Abhishek Sahu wrote: The current driver is failing without complete bootchain since NAND_DEV_CMD_VLD value is not valid. Signed-off-by: Abhishek Sahu BTW, do you

Re: [PATCH v2 02/25] mtd: nand: qcom: program NAND_DEV_CMD_VLD register

On 2017-08-03 21:18, Boris Brezillon wrote: On Wed, 19 Jul 2017 17:17:50 +0530 Abhishek Sahu wrote: The current driver is failing without complete bootchain since NAND_DEV_CMD_VLD value is not valid. Signed-off-by: Abhishek Sahu BTW, do you want to backport this fix? Maybe you add Fixes

Re: [PATCH] arm64: avoid overflow in VA_START and PAGE_OFFSET

> Would > > #define VA_START (UL(0x) - (1 << VA_BITS) + 1) > > also work? I think you'd have to wrap the 1 in a UL(), ex: #define VA_START (UL(0x) - (UL(1) << VA_BITS) + 1) Otherwise IIUC a integral literal (`1`) is treated as an int, which on arm64 is LP64

Re: [PATCH] arm64: avoid overflow in VA_START and PAGE_OFFSET

> Would > > #define VA_START (UL(0x) - (1 << VA_BITS) + 1) > > also work? I think you'd have to wrap the 1 in a UL(), ex: #define VA_START (UL(0x) - (UL(1) << VA_BITS) + 1) Otherwise IIUC a integral literal (`1`) is treated as an int, which on arm64 is LP64

Re: [PATCH v2 01/25] mtd: nand: qcom: fix config error for BCH

On 2017-08-03 21:26, Boris Brezillon wrote: On Wed, 19 Jul 2017 17:17:49 +0530 Abhishek Sahu wrote: The configuration for BCH is not correct in the current driver. The ECC_CFG_ECC_DISABLE bit defines whether to enable or disable the BCH ECC in which 0x1 :

Re: [PATCH v2 01/25] mtd: nand: qcom: fix config error for BCH

On 2017-08-03 21:26, Boris Brezillon wrote: On Wed, 19 Jul 2017 17:17:49 +0530 Abhishek Sahu wrote: The configuration for BCH is not correct in the current driver. The ECC_CFG_ECC_DISABLE bit defines whether to enable or disable the BCH ECC in which 0x1 : BCH_DISABLED 0x0 :

[PATCH] ASoC: Intel: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/intel/atom/sst/sst_pci.c | 2 +- 1 file changed,

[PATCH] ASoC: Intel: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/intel/atom/sst/sst_pci.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [patch v1 0/2] JTAG driver introduction

> Hi Andrew > > Thanks a lot for review. > > We used user space tool for that, which is an adaptation of some > Lattice tools, which allows programming of SVF files. We are using > it for Lattice CPLD burning, since we have for such devices on our > system, but this tool could be used for

Re: [patch v1 0/2] JTAG driver introduction

> Hi Andrew > > Thanks a lot for review. > > We used user space tool for that, which is an adaptation of some > Lattice tools, which allows programming of SVF files. We are using > it for Lattice CPLD burning, since we have for such devices on our > system, but this tool could be used for

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