Re: stmmac still supporting spear600 ?

On 09-03-17, 10:09, Giuseppe CAVALLARO wrote: > Hello > > We do not test stmmac on this spear board since many years > and I guess you have to provide parameters from the platform. > In fact, stmmac is recently tested with DT. > IIRC, the mac on spear600 could not have the HW cap register > so it

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

On 26 September 2015 at 22:31, Jiri Slaby wrote: > But this has to crash whenever the file is read as val's storage is gone at > that moment already, right? Yeah, its fixed now in the new version. This was a *really* bad idea :( -- To unsubscribe from this list: send the

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

On 25 September 2015 at 15:19, Rafael J. Wysocki wrote: > So if you allow something like debugfs to update your structure, how > do you make sure there is the proper locking? Not really sure at all.. Isn't there some debugfs locking that will jump in, to avoid updation of

[PATCH V5 2/2] debugfs: Pass bool pointer to debugfs_create_bool()

updates to all user sites as well, in the same commit updating the API. regmap core was also using debugfs_{read|write}_file_bool(), directly and variable types were updated for that to be bool as well. Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org> Acked-by: Mark Brown <broo...@k

[PATCH V5 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

' to u32. Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org> --- BCC'd a lot of people (rather than cc'ing them) to make sure - the series reaches them - mailing lists do not block the patchset due to long cc list - and we don't spam the BCC'd people for every reply V4->V5: - Sw

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

On 25-09-15, 22:58, Rafael J. Wysocki wrote: > Say you have three adjacent fields in a structure, x, y, z, each one byte > long. > Initially, all of them are equal to 0. > > CPU A writes 1 to x and CPU B writes 2 to y at the same time. > > What's the result? But then two CPUs can update the

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

On 25 September 2015 at 13:33, Rafael J. Wysocki wrote: > You're going to change that into bool in the next patch, right? Yeah. > So what if bool is a byte and the field is not word-aligned Its between two 'unsigned long' variables today, and the struct isn't packed. So, it

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

On 25-09-15, 20:49, Johannes Berg wrote: > Ok, then, but that means Rafael is completely wrong ... > debugfs_create_bool() takes a *pointer* and it needs to be long-lived, > it can't be on the stack. You also don't get a call when it changes. Ahh, ofcourse. My bad as well... I think we can

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

On 25-09-15, 19:42, Johannes Berg wrote: > On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote: > > > Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org> > > --- > > V3->V4: > > - Create a local variable instead of changing type of global_lock > >

[PATCH V4 2/2] debugfs: Pass bool pointer to debugfs_create_bool()

). That required updates to all user sites as well, in the same commit updating the API. regmap core was also using debugfs_{read|write}_file_bool(), directly and variable types were updated for that to be bool as well. Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org> Acked-by: Mark Brown

[PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

to debugfs_create_bool() and assigning its value to global_lock later. Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org> --- V3->V4: - Create a local variable instead of changing type of global_lock (Rafael) - Drop the stable tag - BCC'd a lot of people (rather than cc'ing them) to

[PATCH V1 Resend 05/10] drivers: net: Drop unlikely before IS_ERR(_OR_NULL)

IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there is no need to do that again from its callers. Drop it. Acked-by: Murali Karicheri m-kariche...@ti.com Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- drivers/net/ethernet/ti/netcp_core.c | 4 ++-- 1 file changed, 2

[PATCH V1 Resend 10/10] net: Drop unlikely before IS_ERR(_OR_NULL)

IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there is no need to do that again from its callers. Drop it. Acked-by: Neil Horman nhor...@tuxdriver.com Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- net/openvswitch/datapath.c | 2 +- net/sctp/socket.c | 2

[PATCH V1 Resend 06/11] drivers: net: Drop unlikely before IS_ERR(_OR_NULL)

IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there is no need to do that again from its callers. Drop it. Acked-by: Murali Karicheri m-kariche...@ti.com Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- drivers/net/ethernet/ti/netcp_core.c | 4 ++-- 1 file changed, 2

[PATCH V1 Resend 11/11] net: Drop unlikely before IS_ERR(_OR_NULL)

IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there is no need to do that again from its callers. Drop it. Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- net/openvswitch/datapath.c | 2 +- net/sctp/socket.c | 2 +- net/socket.c | 6 +++--- 3

Re: [PATCH 08/15] drivers: net: Drop unlikely before IS_ERR(_OR_NULL)

On 31-07-15, 11:04, Murali Karicheri wrote: On 07/31/2015 04:38 AM, Viresh Kumar wrote: IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there is no need to do that again from its callers. Drop it. IS_ERR_OR_NULL() is defined as static inline bool __must_check

[PATCH 15/15] net: Drop unlikely before IS_ERR(_OR_NULL)

IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there is no need to do that again from its callers. Drop it. Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- net/openvswitch/datapath.c | 2 +- net/sctp/socket.c | 2 +- net/socket.c | 6 +++--- 3

[PATCH 08/15] drivers: net: Drop unlikely before IS_ERR(_OR_NULL)

IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there is no need to do that again from its callers. Drop it. Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- drivers/net/ethernet/ti/netcp_core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH] bus: subsys: update return type of -remove_dev() to void

On 30-07-15, 12:59, Borislav Petkov wrote: On Thu, Jul 30, 2015 at 03:04:01PM +0530, Viresh Kumar wrote: Its return value is not used by the subsys core and nothing meaningful can be done with it, even if we want to use it. The subsys device is anyway getting removed. I'm assuming sysfs

[PATCH] bus: subsys: update return type of -remove_dev() to void

Its return value is not used by the subsys core and nothing meaningful can be done with it, even if we want to use it. The subsys device is anyway getting removed. Update prototype of -remove_dev() to make its return type as void. Fix all usage sites as well. Signed-off-by: Viresh Kumar