Re: [PATCH 2/4] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE

2018-11-26 Thread Mark Brown
On Mon, Nov 26, 2018 at 09:27:02AM +0100, Juri Lelli wrote: > is highly debatable). I also seem to remember that there might also be > cases where DT values cannot be changed at all for a (new?) platform > that happens to be using DTs shipped with an old revision; something > along these lines was

Re: [PATCH 2/4] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE

2018-11-26 Thread Daniel Lezcano
Hi Juri, On 26/11/2018 09:27, Juri Lelli wrote: > Hi, > > On 23/11/18 17:54, Daniel Lezcano wrote: >> On 23/11/2018 17:20, Sudeep Holla wrote: >>> On Fri, Nov 23, 2018 at 05:04:18PM +0100, Daniel Lezcano wrote: On 23/11/2018 14:58, Sudeep Holla wrote: > On Mon, Oct 29, 2018 at 05:23:18PM

Re: [PATCH 2/4] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE

2018-11-26 Thread Juri Lelli
Hi, On 23/11/18 17:54, Daniel Lezcano wrote: > On 23/11/2018 17:20, Sudeep Holla wrote: > > On Fri, Nov 23, 2018 at 05:04:18PM +0100, Daniel Lezcano wrote: > >> On 23/11/2018 14:58, Sudeep Holla wrote: > >>> On Mon, Oct 29, 2018 at 05:23:18PM +0100, Daniel Lezcano wrote: > The mutex protects

Re: [PATCH 2/4] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE

2018-11-23 Thread Daniel Lezcano
On 23/11/2018 17:20, Sudeep Holla wrote: > On Fri, Nov 23, 2018 at 05:04:18PM +0100, Daniel Lezcano wrote: >> On 23/11/2018 14:58, Sudeep Holla wrote: >>> On Mon, Oct 29, 2018 at 05:23:18PM +0100, Daniel Lezcano wrote: The mutex protects a per_cpu variable access. The potential race can h

Re: [PATCH 2/4] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE

2018-11-23 Thread Sudeep Holla
On Fri, Nov 23, 2018 at 05:04:18PM +0100, Daniel Lezcano wrote: > On 23/11/2018 14:58, Sudeep Holla wrote: > > On Mon, Oct 29, 2018 at 05:23:18PM +0100, Daniel Lezcano wrote: > >> The mutex protects a per_cpu variable access. The potential race can > >> happen only when the cpufreq governor module

Re: [PATCH 2/4] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE

2018-11-23 Thread Daniel Lezcano
On 23/11/2018 14:58, Sudeep Holla wrote: > On Mon, Oct 29, 2018 at 05:23:18PM +0100, Daniel Lezcano wrote: >> The mutex protects a per_cpu variable access. The potential race can >> happen only when the cpufreq governor module is loaded and at the same >> time the cpu capacity is changed in the sys

Re: [PATCH 2/4] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE

2018-11-23 Thread Sudeep Holla
On Mon, Oct 29, 2018 at 05:23:18PM +0100, Daniel Lezcano wrote: > The mutex protects a per_cpu variable access. The potential race can > happen only when the cpufreq governor module is loaded and at the same > time the cpu capacity is changed in the sysfs. > I wonder if we really need that sysfs e

Re: [PATCH 2/4] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE

2018-10-29 Thread Viresh Kumar
On Mon, Oct 29, 2018 at 9:54 PM Daniel Lezcano wrote: > > The mutex protects a per_cpu variable access. The potential race can > happen only when the cpufreq governor module is loaded and at the same > time the cpu capacity is changed in the sysfs. > > There is no real interest of using a mutex to

[PATCH 2/4] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE

2018-10-29 Thread Daniel Lezcano
The mutex protects a per_cpu variable access. The potential race can happen only when the cpufreq governor module is loaded and at the same time the cpu capacity is changed in the sysfs. There is no real interest of using a mutex to protect a variable assignation when there is no situation where a