[RFC 15/20] net: dsa: add tree-wide FDB ops

In order to support cross-chip operations, we need to inform each switch driver when a port operation occurs in a DSA tree. Implement tree-wide FDB operations. Signed-off-by: Vivien Didelot --- drivers/net/dsa/bcm_sf2.c | 12

[RFC 04/20] net: dsa: pass dsa_port down to drivers FDB ops

Now that DSA as proper structure for DSA ports, pass it down to the port_fdb_{prepare,add,del,dump} driver functions. Signed-off-by: Vivien Didelot --- drivers/net/dsa/bcm_sf2.c | 20 +++- drivers/net/dsa/mv88e6xxx.c | 22

[RFC 02/20] net: dsa: be consistent with NETDEV_CHANGEUPPER

Once NETDEV_CHANGEUPPER is emitted, the device is already (un)bridged. If an error is returned on port_bridge_join, the bridge layer will rollback the operation and unbridge the port. Respect this by setting bridge_dev to NULL on error. Also the DSA layer shouldn't assume that the drivers know

[RFC 13/20] net: dsa: list switches in tree

List the registered dsa_switch structures in a "ds" member of the dsa_switch_tree structure. This allows the drivers to easily iterate on the DSA switch structures of their related DSA tree. Signed-off-by: Vivien Didelot --- include/net/dsa.h | 9 +

[RFC 08/20] net: dsa: bcm_sf2: use bridge device from dsa_port

Now that the DSA layer exposes the DSA port structures to drivers, use that to retrieve the port bridge membership and thus get rid of the private bridge_dev pointer. Signed-off-by: Vivien Didelot --- drivers/net/dsa/bcm_sf2.c | 30

[RFC 15/20] net: dsa: add tree-wide FDB ops

In order to support cross-chip operations, we need to inform each switch driver when a port operation occurs in a DSA tree. Implement tree-wide FDB operations. Signed-off-by: Vivien Didelot --- drivers/net/dsa/bcm_sf2.c | 12 drivers/net/dsa/mv88e6xxx.c | 12

[RFC 04/20] net: dsa: pass dsa_port down to drivers FDB ops

Now that DSA as proper structure for DSA ports, pass it down to the port_fdb_{prepare,add,del,dump} driver functions. Signed-off-by: Vivien Didelot --- drivers/net/dsa/bcm_sf2.c | 20 +++- drivers/net/dsa/mv88e6xxx.c | 22 +++--- drivers/net/dsa/mv88e6xxx.h |

[RFC 02/20] net: dsa: be consistent with NETDEV_CHANGEUPPER

Once NETDEV_CHANGEUPPER is emitted, the device is already (un)bridged. If an error is returned on port_bridge_join, the bridge layer will rollback the operation and unbridge the port. Respect this by setting bridge_dev to NULL on error. Also the DSA layer shouldn't assume that the drivers know

[RFC 13/20] net: dsa: list switches in tree

List the registered dsa_switch structures in a "ds" member of the dsa_switch_tree structure. This allows the drivers to easily iterate on the DSA switch structures of their related DSA tree. Signed-off-by: Vivien Didelot --- include/net/dsa.h | 9 + net/dsa/dsa.c | 3 +++ 2 files

[RFC 08/20] net: dsa: bcm_sf2: use bridge device from dsa_port

Now that the DSA layer exposes the DSA port structures to drivers, use that to retrieve the port bridge membership and thus get rid of the private bridge_dev pointer. Signed-off-by: Vivien Didelot --- drivers/net/dsa/bcm_sf2.c | 30 ++ drivers/net/dsa/bcm_sf2.h | 2

[RFC 20/20] net: dsa: mv88e6xxx: setup PVT on cross-chip ops

Switches with a Cross-chip Port VLAN Table are currently configured to allow cross-chip frames to egress any internal ports. This means that unbridged cross-chip ports can actually talk to each other, and this is not what we want. In order to restrict that, we need to setup the PVT entry for an

[RFC 01/20] net: dsa: introduce a dsa_port structure

Introduce a new dsa_port structure, used to store port-centric information, such as a pointer to its DSA switch and its port number. It will later contains further data, such as its bridge device. This is a first step towards implementing cross-chip port operations. Signed-off-by: Vivien Didelot

[RFC 20/20] net: dsa: mv88e6xxx: setup PVT on cross-chip ops

Switches with a Cross-chip Port VLAN Table are currently configured to allow cross-chip frames to egress any internal ports. This means that unbridged cross-chip ports can actually talk to each other, and this is not what we want. In order to restrict that, we need to setup the PVT entry for an

[RFC 01/20] net: dsa: introduce a dsa_port structure

Introduce a new dsa_port structure, used to store port-centric information, such as a pointer to its DSA switch and its port number. It will later contains further data, such as its bridge device. This is a first step towards implementing cross-chip port operations. Signed-off-by: Vivien Didelot

Re: [PATCH] xfs: idle aild if the AIL is pushed up to the target LSN

On Wed, Apr 27, 2016 at 08:31:38PM +0200, Lucas Stach wrote: > Am Dienstag, den 26.04.2016, 09:08 +1000 schrieb Dave Chinner: > [...] > > > > > > > > > > > That said, I'm not sure whether there's a notable benefit of > > > > idling > > > > for > > > > 50ms over just scheduling out when we've hit

Re: [PATCH] xfs: idle aild if the AIL is pushed up to the target LSN

On Wed, Apr 27, 2016 at 08:31:38PM +0200, Lucas Stach wrote: > Am Dienstag, den 26.04.2016, 09:08 +1000 schrieb Dave Chinner: > [...] > > > > > > > > > > > That said, I'm not sure whether there's a notable benefit of > > > > idling > > > > for > > > > 50ms over just scheduling out when we've hit

[PATCH 05/15] staging: lustre: ldlm: use accessor macros for l_flags

From: Bruce Korb Convert most of the ldlm lock's l_flags references from direct bit twiddling to using bit specific macros. A few multi-bit operations are left as an exercise for the reader. The changes are mostly in ldlm, but also in llite, osc and quota. Also add a

[PATCH 05/15] staging: lustre: ldlm: use accessor macros for l_flags

From: Bruce Korb Convert most of the ldlm lock's l_flags references from direct bit twiddling to using bit specific macros. A few multi-bit operations are left as an exercise for the reader. The changes are mostly in ldlm, but also in llite, osc and quota. Also add a multi-bit (mask) test.

[PATCH 03/15] staging: lustre: obdclass: add LCT_SERVER_SESSION for server session

From: Wang Di Add LCT_SERVER_SESSION for server session, and separate the server session flag from LCT_SESSION, so to avoid allocating session info for client stack for each server request, if client and server are on the same node. Signed-off-by: Wang Di

[PATCH 03/15] staging: lustre: obdclass: add LCT_SERVER_SESSION for server session

From: Wang Di Add LCT_SERVER_SESSION for server session, and separate the server session flag from LCT_SESSION, so to avoid allocating session info for client stack for each server request, if client and server are on the same node. Signed-off-by: Wang Di Intel-bug-id:

[PATCH 01/15] staging: lustre: llite: reset writeback index in ll_writepages

From: Jinshan Xiong Otherwise after one round the writeback index will become beyond the file size and ->writepages() turns into an empty operation. Also, a safety guard is added to limit the wait time for grant to 10 minutes(take recovery into consideration) at maximum

[PATCH 04/15] staging: lustre: lmv: kernel crash due to misconfigured MDT

From: Dmitry Eremin There are few places with access to lmv->tgts[] without check for NULL. Usually it may happens when MDT configured starting from index 1 instead of 0. For example: mkfs.lustre --reformat --mgs --mdt --index=1 /dev/sdd1 Signed-off-by: Dmitry

[PATCH 04/15] staging: lustre: lmv: kernel crash due to misconfigured MDT

From: Dmitry Eremin There are few places with access to lmv->tgts[] without check for NULL. Usually it may happens when MDT configured starting from index 1 instead of 0. For example: mkfs.lustre --reformat --mgs --mdt --index=1 /dev/sdd1 Signed-off-by: Dmitry Eremin Intel-bug-id:

[PATCH 01/15] staging: lustre: llite: reset writeback index in ll_writepages

From: Jinshan Xiong Otherwise after one round the writeback index will become beyond the file size and ->writepages() turns into an empty operation. Also, a safety guard is added to limit the wait time for grant to 10 minutes(take recovery into consideration) at maximum in the osc_enter_cache()

[PATCH 11/15] staging: lustre: mgc: fix 'error handling' issues

From: Sebastien Buisson Fix 'error handling' issues found by Coverity version 6.6.1: Unchecked return value (CHECKED_RETURN) Calling function without checking return value. Argument cannot be negative (NEGATIVE_RETURNS) Negative value used as argument to a function expecting a

mmotm 2016-04-27-15-21 uploaded

The mm-of-the-moment snapshot 2016-04-27-15-21 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

[PATCH 09/15] staging: lustre: llite: Replace printing of i_ino with ll_inode2fid()

From: James Nunez The printing of i_ino/i_generation in llite messages is not nearly so useful as printing the full inode FID, since i_ino is a "compressed" version of the FID and there may be duplicate values for i_ino in some cases (especially if running on a 32-bit

[PATCH 11/15] staging: lustre: mgc: fix 'error handling' issues

From: Sebastien Buisson Fix 'error handling' issues found by Coverity version 6.6.1: Unchecked return value (CHECKED_RETURN) Calling function without checking return value. Argument cannot be negative (NEGATIVE_RETURNS) Negative value used as argument to a function expecting a positive value.

mmotm 2016-04-27-15-21 uploaded

The mm-of-the-moment snapshot 2016-04-27-15-21 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

[PATCH 09/15] staging: lustre: llite: Replace printing of i_ino with ll_inode2fid()

From: James Nunez The printing of i_ino/i_generation in llite messages is not nearly so useful as printing the full inode FID, since i_ino is a "compressed" version of the FID and there may be duplicate values for i_ino in some cases (especially if running on a 32-bit client). All instances of

[PATCH 07/15] staging: lustre: ldlm: remove code wireshark handling

From: Bruce Korb Wireshark output moved to userland file "lustre_dlm_flags_wshark.c" and only bits that can actually appear "on the wire" are emitted. The user land "packet-lustre.c" code that references these bits now gets emitted into that file. e.g. the "local_only" bit

[PATCH 07/15] staging: lustre: ldlm: remove code wireshark handling

From: Bruce Korb Wireshark output moved to userland file "lustre_dlm_flags_wshark.c" and only bits that can actually appear "on the wire" are emitted. The user land "packet-lustre.c" code that references these bits now gets emitted into that file. e.g. the "local_only" bit is never put on the

[PATCH 13/15] staging: lustre: osc: Track number of "unstable" pages per osc

From: Prakash Surya This change adds simple accounting hooks for "unstable" pages on a per OSC basis. Now, in addition to the per filesystem tracking, each OSC will maintain a running total of its unstable pages. These counters are exported through the proc interface, and can be

[PATCH 15/15] staging: lustre: ptlrpc: quiet warning for 2.1/2.5 connections

From: Andreas Dilger The Lustre 2.5.4 client will print a warning about connections with 2.1.3 servers, yet they are still supposed to be interoperable. Increase the window of warning to be up to Lustre 2.5.50, since we do not intend to allow interoperability between

[PATCH 10/15] staging: lustre: clio: add debug message in osc_completion()

From: Niu Yawei Replace LASSERT with LASSERTF in osc_completion, thus we can get more info when the LASSERT is triggered. Signed-off-by: Niu Yawei Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3843 Reviewed-on: http://review.whamcloud.com/7494

[PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

When booting with efifb, we get a frame buffer address passed into the system. This address can be backed by any device, including PCI devices. PCI devices can have their BARs mapped to various places inside the PCI window though. Linux makes use of that on early boot and usually maps PCI BARs

[PATCH 10/15] staging: lustre: clio: add debug message in osc_completion()

From: Niu Yawei Replace LASSERT with LASSERTF in osc_completion, thus we can get more info when the LASSERT is triggered. Signed-off-by: Niu Yawei Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3843 Reviewed-on: http://review.whamcloud.com/7494 Reviewed-by: Bobi Jam Reviewed-by: Jinshan

[PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

When booting with efifb, we get a frame buffer address passed into the system. This address can be backed by any device, including PCI devices. PCI devices can have their BARs mapped to various places inside the PCI window though. Linux makes use of that on early boot and usually maps PCI BARs

[PATCH 13/15] staging: lustre: osc: Track number of "unstable" pages per osc

From: Prakash Surya This change adds simple accounting hooks for "unstable" pages on a per OSC basis. Now, in addition to the per filesystem tracking, each OSC will maintain a running total of its unstable pages. These counters are exported through the proc interface, and can be read using the

[PATCH 15/15] staging: lustre: ptlrpc: quiet warning for 2.1/2.5 connections

From: Andreas Dilger The Lustre 2.5.4 client will print a warning about connections with 2.1.3 servers, yet they are still supposed to be interoperable. Increase the window of warning to be up to Lustre 2.5.50, since we do not intend to allow interoperability between 2.1 and 2.6 systems. This

[PATCH 14/15] staging: lustre: osc: Use SOFT_SYNC to urge server commit

From: Prakash Surya This change adds a BRW page flag, OBD_BRW_SOFT_SYNC. This flag is intended to urge a server to commit a client's unstable pages to stable storage. A client will add this flag to any BRW requests while it is in a state where it has "many" unstable pages pinned

[PATCH 14/15] staging: lustre: osc: Use SOFT_SYNC to urge server commit

From: Prakash Surya This change adds a BRW page flag, OBD_BRW_SOFT_SYNC. This flag is intended to urge a server to commit a client's unstable pages to stable storage. A client will add this flag to any BRW requests while it is in a state where it has "many" unstable pages pinned in its cache.

[PATCH 12/15] staging: lustre: osc: Track and limit "unstable" pages

From: Prakash Surya This change adds a global counter to track the number of "unstable" pages held by a given client, along with per file system counters. An "unstable" page is defined as a page which has been sent to the server as part of a bulk request, but is uncommitted to

[PATCH 12/15] staging: lustre: osc: Track and limit "unstable" pages

From: Prakash Surya This change adds a global counter to track the number of "unstable" pages held by a given client, along with per file system counters. An "unstable" page is defined as a page which has been sent to the server as part of a bulk request, but is uncommitted to stable storage.

[PATCH 08/15] staging: lustre: ldlm: update comments about ldlm l_flags

From: Bruce Korb Add and update documentation about some of the ldlm l_flags. Signed-off-by: Bruce Korb Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2906 Reviewed-by: Keith Mannthey Reviewed-on:

[PATCH 08/15] staging: lustre: ldlm: update comments about ldlm l_flags

From: Bruce Korb Add and update documentation about some of the ldlm l_flags. Signed-off-by: Bruce Korb Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2906 Reviewed-by: Keith Mannthey Reviewed-on: http://review.whamcloud.com/7963 Reviewed-by: Doug Oucharek Reviewed-by: Andreas Dilger

[PATCH 02/15] staging: lustre: llite: NFS reexport issue

From: Dmitry Eremin Suppress erroneous/confusing messages when NFS is out of sync and requests old data. Signed-off-by: Dmitry Eremin Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4050 Reviewed-on: http://review.whamcloud.com/7850

[PATCH 02/15] staging: lustre: llite: NFS reexport issue

From: Dmitry Eremin Suppress erroneous/confusing messages when NFS is out of sync and requests old data. Signed-off-by: Dmitry Eremin Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4050 Reviewed-on: http://review.whamcloud.com/7850 Reviewed-by: Andreas Dilger Reviewed-by: Bob Glossman

[PATCH 06/15] staging: lustre: ldlm: clean up l_flags

From: Bruce Korb Remove the now obsolete LDLM_AST_FLAGS and LDLM_INHERIT_FLAGS defines. Remove the obsolete LDLM_FL_HIDE_LOCK_MASK define. Rename "local_only" mask to "off_wire" since it is confusingly similar to a flag that (I think) means, "do not copy this lock over the

[PATCH 00/15] patches missing from lustre 2.5.51

This is the collection of bug fixes and code cleanup that are missing from the upstream client that exist with lustre version 2.5.51. Andreas Dilger (1): staging: lustre: ptlrpc: quiet warning for 2.1/2.5 connections Bruce Korb (4): staging: lustre: ldlm: use accessor macros for l_flags

[PATCH 06/15] staging: lustre: ldlm: clean up l_flags

From: Bruce Korb Remove the now obsolete LDLM_AST_FLAGS and LDLM_INHERIT_FLAGS defines. Remove the obsolete LDLM_FL_HIDE_LOCK_MASK define. Rename "local_only" mask to "off_wire" since it is confusingly similar to a flag that (I think) means, "do not copy this lock over the wire." Signed-off-by:

[PATCH 00/15] patches missing from lustre 2.5.51

This is the collection of bug fixes and code cleanup that are missing from the upstream client that exist with lustre version 2.5.51. Andreas Dilger (1): staging: lustre: ptlrpc: quiet warning for 2.1/2.5 connections Bruce Korb (4): staging: lustre: ldlm: use accessor macros for l_flags

Re: [PATCH, RFT] byteswap: try to avoid __builtin_constant_p gcc bug

On Thu, Apr 28, 2016 at 12:00:36AM +0200, Arnd Bergmann wrote: > This is another attempt to avoid a regression in wwn_to_u64() > after that started using get_unaligned_be64(), which in turn > ran into a bug on gcc-4.9 through 6.1. > > As part of the problem is how __builtin_constant_p gets

Re: [PATCH, RFT] byteswap: try to avoid __builtin_constant_p gcc bug

On Thu, Apr 28, 2016 at 12:00:36AM +0200, Arnd Bergmann wrote: > This is another attempt to avoid a regression in wwn_to_u64() > after that started using get_unaligned_be64(), which in turn > ran into a bug on gcc-4.9 through 6.1. > > As part of the problem is how __builtin_constant_p gets

[PATCH, RFT] byteswap: try to avoid __builtin_constant_p gcc bug

This is another attempt to avoid a regression in wwn_to_u64() after that started using get_unaligned_be64(), which in turn ran into a bug on gcc-4.9 through 6.1. As part of the problem is how __builtin_constant_p gets evaluated on an argument passed by reference into an inline function, this

[PATCH, RFT] byteswap: try to avoid __builtin_constant_p gcc bug

This is another attempt to avoid a regression in wwn_to_u64() after that started using get_unaligned_be64(), which in turn ran into a bug on gcc-4.9 through 6.1. As part of the problem is how __builtin_constant_p gets evaluated on an argument passed by reference into an inline function, this

Re: [PATCH] media: fix media_ioctl use-after-free when driver unbinds

On 04/27/2016 10:43 AM, Lars-Peter Clausen wrote: > Looks mostly good, a few comments. > > On 04/27/2016 05:08 AM, Shuah Khan wrote: > [...] >> @@ -428,7 +428,7 @@ static long media_device_ioctl(struct file *filp, >> unsigned int cmd, >> unsigned long arg) >> { >>

Re: [PATCH] media: fix media_ioctl use-after-free when driver unbinds

On 04/27/2016 10:43 AM, Lars-Peter Clausen wrote: > Looks mostly good, a few comments. > > On 04/27/2016 05:08 AM, Shuah Khan wrote: > [...] >> @@ -428,7 +428,7 @@ static long media_device_ioctl(struct file *filp, >> unsigned int cmd, >> unsigned long arg) >> { >>

Re: [PATCH v4 1/7] regulator: rk808: Add rk808_reg_ops_ranges for LDO3

Am Dienstag, 26. April 2016, 16:54:04 schrieb Wadim Egorov: > LDO_REG3 descriptor is using linear_ranges. > Add and use proper ops for LDO_REG3. > > Signed-off-by: Wadim Egorov I'm to late to the party judging by Mark's "Aplied" message, but just to confirm, this patch

Re: [PATCH v4 1/7] regulator: rk808: Add rk808_reg_ops_ranges for LDO3

Am Dienstag, 26. April 2016, 16:54:04 schrieb Wadim Egorov: > LDO_REG3 descriptor is using linear_ranges. > Add and use proper ops for LDO_REG3. > > Signed-off-by: Wadim Egorov I'm to late to the party judging by Mark's "Aplied" message, but just to confirm, this patch sucessfully fixes the

Re: [PATCH 4/4] thermal: bang-bang governor: act on lower trip boundary

On Mon, Apr 25, 2016 at 11:02:47AM +0800, Caesar Wang wrote: > From: Sascha Hauer > > With interrupt driven thermal zones we pass the lower and upper > temperature on which shall be acted, so in the governor we have to act on > the exact lower temperature to be

Re: [PATCH 4/4] thermal: bang-bang governor: act on lower trip boundary

On Mon, Apr 25, 2016 at 11:02:47AM +0800, Caesar Wang wrote: > From: Sascha Hauer > > With interrupt driven thermal zones we pass the lower and upper > temperature on which shall be acted, so in the governor we have to act on > the exact lower temperature to be consistent. Otherwise an interrupt

Re: [PATCH 2/4] thermal: of: implement .set_trips for device tree thermal zones

On Mon, Apr 25, 2016 at 11:02:45AM +0800, Caesar Wang wrote: > From: Sascha Hauer > > Signed-off-by: Sascha Hauer > Signed-off-by: Caesar Wang > Cc: Zhang Rui > Cc: Eduardo Valentin

Re: [PATCH 2/4] thermal: of: implement .set_trips for device tree thermal zones

On Mon, Apr 25, 2016 at 11:02:45AM +0800, Caesar Wang wrote: > From: Sascha Hauer > > Signed-off-by: Sascha Hauer > Signed-off-by: Caesar Wang > Cc: Zhang Rui > Cc: Eduardo Valentin > Cc: linux...@vger.kernel.org > --- > > drivers/thermal/of-thermal.c | 12 >

Re: [PATCH 7/9] thermal: of: Add support for hardware-tracked trip points

On Fri, Apr 22, 2016 at 06:17:54PM +0800, Caesar Wang wrote: > Hi Sascha, > These are still the newest patches. I won't have any resources in the > near future for continuing the work on them, so feel free to pick them > up. There hasn't been much discussion around these patches which

Re: [PATCH 7/9] thermal: of: Add support for hardware-tracked trip points

On Fri, Apr 22, 2016 at 06:17:54PM +0800, Caesar Wang wrote: > Hi Sascha, > These are still the newest patches. I won't have any resources in the > near future for continuing the work on them, so feel free to pick them > up. There hasn't been much discussion around these patches which

Re: [PATCH 1/4] thermal: Add support for hardware-tracked trip points

A couple of comments as follows, On Mon, Apr 25, 2016 at 11:02:44AM +0800, Caesar Wang wrote: > From: Sascha Hauer > > This adds support for hardware-tracked trip points to the device tree > thermal sensor framework. > > The framework supports an arbitrary number of

Re: [PATCH 1/4] thermal: Add support for hardware-tracked trip points

A couple of comments as follows, On Mon, Apr 25, 2016 at 11:02:44AM +0800, Caesar Wang wrote: > From: Sascha Hauer > > This adds support for hardware-tracked trip points to the device tree > thermal sensor framework. > > The framework supports an arbitrary number of trip points. Whenever > the

Re: [RFC 1/4] perf kvm: Enable 'record' on powerpc

Em Wed, Apr 27, 2016 at 06:02:21PM +0530, Ravi Bangoria escreveu: > Hi Arnaldo, > > I've worked on your patch. I'm sending this patch(diff) to check if this > is the same idea you want to progress with. I cleanup your patch, > removed arch specific compile time directives and changed code to >

Re: [RFC 1/4] perf kvm: Enable 'record' on powerpc

Em Wed, Apr 27, 2016 at 06:02:21PM +0530, Ravi Bangoria escreveu: > Hi Arnaldo, > > I've worked on your patch. I'm sending this patch(diff) to check if this > is the same idea you want to progress with. I cleanup your patch, > removed arch specific compile time directives and changed code to >

Re: [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

On Wed, Apr 27, 2016 at 8:09 AM, Karel Zak wrote: > On Tue, Apr 26, 2016 at 02:51:01PM -0700, Gwendal Grignou wrote: >> Julius and I were looking at the code when we spotted the issue. >> >> As Julius said, "just pass a boot param", is not easy on certain >> machines, like phone.

Re: [PATCH] block: partitions: efi: Always check for alternative GPT at end of drive

On Wed, Apr 27, 2016 at 8:09 AM, Karel Zak wrote: > On Tue, Apr 26, 2016 at 02:51:01PM -0700, Gwendal Grignou wrote: >> Julius and I were looking at the code when we spotted the issue. >> >> As Julius said, "just pass a boot param", is not easy on certain >> machines, like phone. It is not user

Re: [PATCH] i2c-mux-pca9541: fix setup_timer.cocci warnings

On 2016-04-27 21:06, Julia Lawall wrote: > Use setup_timer function instead of initializing timer with the function > and data fields > > Generated by: scripts/coccinelle/api/setup_timer.cocci > > Signed-off-by: Fengguang Wu > Signed-off-by: Julia Lawall

Re: [PATCH] i2c-mux-pca9541: fix setup_timer.cocci warnings

On 2016-04-27 21:06, Julia Lawall wrote: > Use setup_timer function instead of initializing timer with the function > and data fields > > Generated by: scripts/coccinelle/api/setup_timer.cocci > > Signed-off-by: Fengguang Wu > Signed-off-by: Julia Lawall > Acked-by: Peter Rosin Cheers, Peter

Re: [PATCH v6 0/7] perf tools: Use SIGUSR2 control data dumpping

Em Wed, Apr 20, 2016 at 06:59:47PM +, Wang Nan escreveu: > v5 -> v6: Improve trigger class: rename (Suggested by Namhyung Kim) > toggle -> hit; don't generate functions for each trigger, > use generic functions instead. > > Patch cleanup: switch auxtrace_snapshot to

Re: [PATCH v6 0/7] perf tools: Use SIGUSR2 control data dumpping

Em Wed, Apr 20, 2016 at 06:59:47PM +, Wang Nan escreveu: > v5 -> v6: Improve trigger class: rename (Suggested by Namhyung Kim) > toggle -> hit; don't generate functions for each trigger, > use generic functions instead. > > Patch cleanup: switch auxtrace_snapshot to

Re: [PATCH] scsi: fc: force inlining of wwn conversion functions

On Wednesday 27 April 2016 13:05:03 Martin Jambor wrote: > On Tue, Apr 26, 2016 at 05:58:20PM +0200, Arnd Bergmann wrote: > > On Tuesday 26 April 2016 09:06:54 Martin K. Petersen wrote: > > > > "Arnd" == Arnd Bergmann writes: > > > > > > Arnd> I don't think we can

Re: [PATCH] scsi: fc: force inlining of wwn conversion functions

On Wednesday 27 April 2016 13:05:03 Martin Jambor wrote: > On Tue, Apr 26, 2016 at 05:58:20PM +0200, Arnd Bergmann wrote: > > On Tuesday 26 April 2016 09:06:54 Martin K. Petersen wrote: > > > > "Arnd" == Arnd Bergmann writes: > > > > > > Arnd> I don't think we can realistically blacklist

Re: [PATCH v6 3/7] perf record: Split output into multiple files via '--switch-output'

Em Wed, Apr 20, 2016 at 06:59:50PM +, Wang Nan escreveu: > Allow 'perf record' to split its output into multiple files. > > For example: I squashed: -> 360 T 04/20 Wang Nan(1.7K) ├─>[PATCH v6 6/7] perf record: Re-synthesize tracking events after output switching Into this patch,

Re: [PATCH V2] cpuidle: Change ktime_get() with local_clock()

On Friday, April 22, 2016 08:42:40 AM Peter Zijlstra wrote: > On Thu, Apr 21, 2016 at 09:41:14PM +0200, Rafael J. Wysocki wrote: > > On Thu, Apr 21, 2016 at 10:56 AM, Daniel Lezcano > > wrote: > > > The ktime_get() can have a non negligeable overhead, use local_clock()

Re: [PATCH v6 3/7] perf record: Split output into multiple files via '--switch-output'

Em Wed, Apr 20, 2016 at 06:59:50PM +, Wang Nan escreveu: > Allow 'perf record' to split its output into multiple files. > > For example: I squashed: -> 360 T 04/20 Wang Nan(1.7K) ├─>[PATCH v6 6/7] perf record: Re-synthesize tracking events after output switching Into this patch,

Re: [PATCH V2] cpuidle: Change ktime_get() with local_clock()

On Friday, April 22, 2016 08:42:40 AM Peter Zijlstra wrote: > On Thu, Apr 21, 2016 at 09:41:14PM +0200, Rafael J. Wysocki wrote: > > On Thu, Apr 21, 2016 at 10:56 AM, Daniel Lezcano > > wrote: > > > The ktime_get() can have a non negligeable overhead, use local_clock() > > > instead. > > > > > >

Re: [PATCH] PM / clk: ensure we don't allocate a -ve size of count clks

On Saturday, April 16, 2016 01:50:03 PM Colin King wrote: > From: Colin Ian King > > It is entirely possible for of_count_phandle_wit_args to > return a -ve error return value so we need to check for this > otherwise we end up allocating a negative number of clk

Re: [PATCH] PM / clk: ensure we don't allocate a -ve size of count clks

On Saturday, April 16, 2016 01:50:03 PM Colin King wrote: > From: Colin Ian King > > It is entirely possible for of_count_phandle_wit_args to > return a -ve error return value so we need to check for this > otherwise we end up allocating a negative number of clk objects. > > Signed-off-by:

Re: [PATCH] powercap/intel_rapl: Add support for Kabylake

On Monday, April 25, 2016 08:36:47 AM Jacob Pan wrote: > On Mon, 25 Apr 2016 16:20:17 +0200 > "Rafael J. Wysocki" wrote: > > > How urgent is this? > > > > Can we live without it in 4.6 in particular? > not urgent. OK Queued up for 4.7, thanks!

Re: [PATCH v4 4/4] ARM64: dts: rockchip: add dts file for RK3399 evaluation board

Am Mittwoch, 27. April 2016, 15:54:53 schrieb Jianqun Xu: > This patch add rk3399-evb.dts for RK3399 evaluation board. > Tested on RK3399 evb. > > Signed-off-by: Jianqun Xu applied to my dts64-branch for 4.7 Thanks Heiko

Re: [PATCH] powercap/intel_rapl: Add support for Kabylake

On Monday, April 25, 2016 08:36:47 AM Jacob Pan wrote: > On Mon, 25 Apr 2016 16:20:17 +0200 > "Rafael J. Wysocki" wrote: > > > How urgent is this? > > > > Can we live without it in 4.6 in particular? > not urgent. OK Queued up for 4.7, thanks!

Re: [PATCH v4 4/4] ARM64: dts: rockchip: add dts file for RK3399 evaluation board

Am Mittwoch, 27. April 2016, 15:54:53 schrieb Jianqun Xu: > This patch add rk3399-evb.dts for RK3399 evaluation board. > Tested on RK3399 evb. > > Signed-off-by: Jianqun Xu applied to my dts64-branch for 4.7 Thanks Heiko

Re: [PATCH v2 3/3] ARM: dts: exynos: Lower SD card interface voltage to 2.8v on Odroid X/X2/U3

Hello On 04/27/2016 10:00 AM, Krzysztof Kozlowski wrote: > Odroid X/X2/U3 schematics say that SD card vmmc regulator > (LDO21/TFLASH) operates on 2.8 V. Mainline U-Boot uses that value as > well. 2.8 V is common on Exynos-based boards. Additionally use some > descriptive name for this regulator.

Re: [PATCH v2 3/3] ARM: dts: exynos: Lower SD card interface voltage to 2.8v on Odroid X/X2/U3

Hello On 04/27/2016 10:00 AM, Krzysztof Kozlowski wrote: > Odroid X/X2/U3 schematics say that SD card vmmc regulator > (LDO21/TFLASH) operates on 2.8 V. Mainline U-Boot uses that value as > well. 2.8 V is common on Exynos-based boards. Additionally use some > descriptive name for this regulator.

Re: [PATCH v4 3/4] Documentation: devicetree: rockchip: Document rk3399-evb

Am Mittwoch, 27. April 2016, 15:54:52 schrieb Jianqun Xu: > Use "rockchip,rk3399-evb" compatible string for Rockchip RK3399 > evaluation board. > > Acked-by: Rob Herring > Signed-off-by: Jianqun Xu applied to my dts64-branch for 4.7 Thanks Heiko

Re: [PATCH v4 3/4] Documentation: devicetree: rockchip: Document rk3399-evb

Am Mittwoch, 27. April 2016, 15:54:52 schrieb Jianqun Xu: > Use "rockchip,rk3399-evb" compatible string for Rockchip RK3399 > evaluation board. > > Acked-by: Rob Herring > Signed-off-by: Jianqun Xu applied to my dts64-branch for 4.7 Thanks Heiko

Re: [PATCH v4 1/4] Documentation: rockchip-dw-mshc: add description for rk3399

Am Mittwoch, 27. April 2016, 15:54:50 schrieb Jianqun Xu: > From: Shawn Lin > > Add "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc" for > dwmmc on rk3399 platform. > > Acked-by: Rob Herring > Signed-off-by: Shawn Lin >

Re: [PATCH v4 2/4] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

Am Mittwoch, 27. April 2016, 15:54:51 schrieb Jianqun Xu: > This patch adds core dtsi file for Rockchip RK3399 SoCs. > > The RK3399 has big/little architecture, which needs a separate > node for the PMU of each microarchitecture, for now it missing > the pmu node since the old one could not work

Re: [PATCH v4 1/4] Documentation: rockchip-dw-mshc: add description for rk3399

Am Mittwoch, 27. April 2016, 15:54:50 schrieb Jianqun Xu: > From: Shawn Lin > > Add "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc" for > dwmmc on rk3399 platform. > > Acked-by: Rob Herring > Signed-off-by: Shawn Lin > Signed-off-by: Jianqun Xu applied to my dts64-branch for 4.7

Re: [PATCH v4 2/4] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

Am Mittwoch, 27. April 2016, 15:54:51 schrieb Jianqun Xu: > This patch adds core dtsi file for Rockchip RK3399 SoCs. > > The RK3399 has big/little architecture, which needs a separate > node for the PMU of each microarchitecture, for now it missing > the pmu node since the old one could not work

Re: [PATCH] ASoC: atmel_ssc_dai: note buggy I2S support when the codec masters LRCLK

On 2016-04-27 18:23, Mark Brown wrote: > On Wed, Apr 27, 2016 at 11:06:33AM +0200, Peter Rosin wrote: > >> While the start condition is correct for the left channel word in the I2S >> case, it is not correct that the right channel word follows immediately >> after the left channel word. The start

Re: [PATCH] ASoC: atmel_ssc_dai: note buggy I2S support when the codec masters LRCLK

On 2016-04-27 18:23, Mark Brown wrote: > On Wed, Apr 27, 2016 at 11:06:33AM +0200, Peter Rosin wrote: > >> While the start condition is correct for the left channel word in the I2S >> case, it is not correct that the right channel word follows immediately >> after the left channel word. The start

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

Hi, On Wed, Apr 27, 2016 at 02:13:56PM -0500, Bin Liu wrote: > Hi, > > On Wed, Apr 27, 2016 at 09:26:10PM +0300, Maxim Uvarov wrote: > > 2016-04-27 18:46 GMT+03:00 Bin Liu : > > > Hi, > > > > > > On Wed, Apr 27, 2016 at 09:51:58AM +0300, Max Uvarov wrote: > > >> Fix soft lockup

Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error

Hi, On Wed, Apr 27, 2016 at 02:13:56PM -0500, Bin Liu wrote: > Hi, > > On Wed, Apr 27, 2016 at 09:26:10PM +0300, Maxim Uvarov wrote: > > 2016-04-27 18:46 GMT+03:00 Bin Liu : > > > Hi, > > > > > > On Wed, Apr 27, 2016 at 09:51:58AM +0300, Max Uvarov wrote: > > >> Fix soft lockup when resetting

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