Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR)

2018-03-19 Thread John Syne
Hi Jonathan,

Thank you for all your hard work. Your feedback is really helpful. I’m 
surprised that no one from Analog Device has offered any suggestions.

Anyway, please see my comments inline below

Regards,
John





> On Mar 18, 2018, at 5:23 AM, Jonathan Cameron  wrote:
> 
> On Sat, 17 Mar 2018 23:11:45 -0700
> John Syne  wrote:
> 
>> Hi Jonathan,
> Hi John and All,
> 
> I'd love to get some additional input on this from anyone interested.
> There are a lot of weird and wonderful derived quantities in an energy
> meter and it seems we need to make some fundamental changes to support
> them - including potentially a userspace breaking change to the event
> code description.
> 
>> 
>> Here is the complete list of registers for the ADE7878 which I copied from 
>> the data sheet. I added a column “IIO Attribute” which I hope follows your 
>> IIO ABI. Please make any changes you feel are incorrect. BTW, there are 
>> several registers that cannot be generalized and are used purely for chip 
>> configuration. I think we should add a new naming convention, namely 
>> {register}_{}. Also, I see in the sys_bus_iio doc
>> in_accel_x_peak_raw
>> 
>> so shouldn’t the phase be represented as follows:
>> 
>> in_current_A_scale
> I'm still confused.  What does A represent here?  I assumed that was a wild
> card for the channel number before but clearly not.
> 
> Ah, you are labelling the 3 separate phases as A, B and C. Hmm.
> I guess they sort of look like axis, and sort of like independent channels.
> So could be indexed or done via modifiers depending on how you look at it.
In metering terminology, the three phases are commonly referred to as RED, 
GREEN, BLUE or PhaseA, PhaseB, PhaseC and Neutral. Analog Devices uses the ABCN 
nomenclature so anyone using this driver will probably have referenced the 
Analog Devices datasheet so this terminology should be familiar. 
> 
> Hmm. With neutral in there as well I guess we need to make them
> modifiers (but might change my mind later ;)
> 
> Particularly as we are using the the modifier for RMS under the previous
> plan... It appears we should treat that instead like we did for peak
> and do it as an additional info mask element.  The problem with doing that
> on a continuous measurement is that we can't treat it as a channel to
> be output through the buffered interface.
I’ve changed the layout of the spreadsheet to breakout the Direction, Type, 
Index, Modifier and Info Mask to make sure there is no miss-understanding and 
will help identify all the items we need to add.

The ADE7878 channels that will use the buffer are IAWV, VAWV, IBWV, VBWV, ICWV, 
VCWV, INWV, AVA, BVA, CVA, AWATT, BWATT, CWATT, AVAR, BVAR, and CVAR. So I 
guess we have to add an index

Address RegisterIIO Attribute   
Dir TypeIndex   ModifierInfo Mask   R/W 
Bit Bit Length  TypeDefault Description 


Length  During Comm 
Value   
0xE50C  IAWVin_current0_phaseA_instantaneousin  current 
0   phaseA  instantaneous   R   24  32 SE   
S   N/A Instantaneous value of Phase A current.
0xE50D  IBWVin_current1_phaseB_instantaneousin  current 
1   phaseB  instantaneous   R   24  32 SE   
S   N/A Instantaneous value of Phase B current.
0xE50E  ICWVin_current2_phaseC_instantaneousin  current 
2   phaseC  instantaneous   R   24  32 SE   
S   N/A Instantaneous value of Phase C current.
0xE50F  INWVin_current3_phaseN_instantaneousin  current 
3   neutral instantaneous   R   24  32 SE   
S   N/A Instantaneous value of neutral current 
(ADE7868 and ADE7878 only).
0xE510  VAWVin_voltage4_phaseA_instantaneousin  voltage 
4   phaseA  instantaneous   R   24  32 SE   
S   N/A Instantaneous value of Phase A voltage.
0xE511  VBWVin_voltage5_phaseB_instantaneousin  voltage 
5   phaseB  instantaneous   R   24  32 SE   
S   N/A Instantaneous value of Phase B voltage.
0xE512  VCWVin_voltage6_phaseC_instantaneousin  voltage 
6   phaseC  instantaneous   R   24  32 SE   
S   N/A Instantaneous value of Phase C voltage.
0xE513  AWATT   

Re: meter ABI: (was Re: [PATCH v2 1/3] staging:iio:meter: Replaces IIO_DEV_ATTR_CH_OFF by IIO_DEVICE_ATTR)

2018-03-19 Thread John Syne
Hi Jonathan,

Thank you for all your hard work. Your feedback is really helpful. I’m 
surprised that no one from Analog Device has offered any suggestions.

Anyway, please see my comments inline below

Regards,
John





> On Mar 18, 2018, at 5:23 AM, Jonathan Cameron  wrote:
> 
> On Sat, 17 Mar 2018 23:11:45 -0700
> John Syne  wrote:
> 
>> Hi Jonathan,
> Hi John and All,
> 
> I'd love to get some additional input on this from anyone interested.
> There are a lot of weird and wonderful derived quantities in an energy
> meter and it seems we need to make some fundamental changes to support
> them - including potentially a userspace breaking change to the event
> code description.
> 
>> 
>> Here is the complete list of registers for the ADE7878 which I copied from 
>> the data sheet. I added a column “IIO Attribute” which I hope follows your 
>> IIO ABI. Please make any changes you feel are incorrect. BTW, there are 
>> several registers that cannot be generalized and are used purely for chip 
>> configuration. I think we should add a new naming convention, namely 
>> {register}_{}. Also, I see in the sys_bus_iio doc
>> in_accel_x_peak_raw
>> 
>> so shouldn’t the phase be represented as follows:
>> 
>> in_current_A_scale
> I'm still confused.  What does A represent here?  I assumed that was a wild
> card for the channel number before but clearly not.
> 
> Ah, you are labelling the 3 separate phases as A, B and C. Hmm.
> I guess they sort of look like axis, and sort of like independent channels.
> So could be indexed or done via modifiers depending on how you look at it.
In metering terminology, the three phases are commonly referred to as RED, 
GREEN, BLUE or PhaseA, PhaseB, PhaseC and Neutral. Analog Devices uses the ABCN 
nomenclature so anyone using this driver will probably have referenced the 
Analog Devices datasheet so this terminology should be familiar. 
> 
> Hmm. With neutral in there as well I guess we need to make them
> modifiers (but might change my mind later ;)
> 
> Particularly as we are using the the modifier for RMS under the previous
> plan... It appears we should treat that instead like we did for peak
> and do it as an additional info mask element.  The problem with doing that
> on a continuous measurement is that we can't treat it as a channel to
> be output through the buffered interface.
I’ve changed the layout of the spreadsheet to breakout the Direction, Type, 
Index, Modifier and Info Mask to make sure there is no miss-understanding and 
will help identify all the items we need to add.

The ADE7878 channels that will use the buffer are IAWV, VAWV, IBWV, VBWV, ICWV, 
VCWV, INWV, AVA, BVA, CVA, AWATT, BWATT, CWATT, AVAR, BVAR, and CVAR. So I 
guess we have to add an index

Address RegisterIIO Attribute   
Dir TypeIndex   ModifierInfo Mask   R/W 
Bit Bit Length  TypeDefault Description 


Length  During Comm 
Value   
0xE50C  IAWVin_current0_phaseA_instantaneousin  current 
0   phaseA  instantaneous   R   24  32 SE   
S   N/A Instantaneous value of Phase A current.
0xE50D  IBWVin_current1_phaseB_instantaneousin  current 
1   phaseB  instantaneous   R   24  32 SE   
S   N/A Instantaneous value of Phase B current.
0xE50E  ICWVin_current2_phaseC_instantaneousin  current 
2   phaseC  instantaneous   R   24  32 SE   
S   N/A Instantaneous value of Phase C current.
0xE50F  INWVin_current3_phaseN_instantaneousin  current 
3   neutral instantaneous   R   24  32 SE   
S   N/A Instantaneous value of neutral current 
(ADE7868 and ADE7878 only).
0xE510  VAWVin_voltage4_phaseA_instantaneousin  voltage 
4   phaseA  instantaneous   R   24  32 SE   
S   N/A Instantaneous value of Phase A voltage.
0xE511  VBWVin_voltage5_phaseB_instantaneousin  voltage 
5   phaseB  instantaneous   R   24  32 SE   
S   N/A Instantaneous value of Phase B voltage.
0xE512  VCWVin_voltage6_phaseC_instantaneousin  voltage 
6   phaseC  instantaneous   R   24  32 SE   
S   N/A Instantaneous value of Phase C voltage.
0xE513  AWATT   in_power7_phaseA_instantaneous  

Re: [PATCH] ACPI / scan: Send the change uevent with offine environmental data

2018-03-19 Thread joeyli
Hi Rafael, 

On Mon, Mar 19, 2018 at 11:02:32AM +0100, Rafael J. Wysocki wrote:
> On Friday, March 2, 2018 7:35:08 AM CET Lee, Chun-Yi wrote:
> > In current design of ACPI container offline, Kernel emits
> > KOBJ_CHANGE uevent to user space to indidate that the ejection of
> > the container was triggered by platform. (caa73ea15 patch)
> > 
> > A pure KOBJ_CHANGE uevent is not enough for user space to identify
> > the purpose. For example, a "udevadm trigger" command can also
> > be used to emit change event to all udev rules. A udev rule can not
> > identify that the event is from kernel for offline or from udevadm
> > for other purpose. Then the offline action in udev rule may also be
> > triggered by udevadm tool.
> > 
> > So, similar to the change uevent of dock, kernel sends the
> > KOBJ_CHANGE uevent with a offline environmental data to indicate
> > purpose. It's useful by udev rule for using ENV{EVENT} filter.
> > 
> > Cc: Michal Hocko  
> > Cc: "Rafael J. Wysocki"  
> > Cc: Len Brown  
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  drivers/acpi/scan.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 8e63d93..f6dca9b 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -116,6 +116,7 @@ bool acpi_scan_is_offline(struct acpi_device *adev, 
> > bool uevent)
> >  {
> > struct acpi_device_physical_node *pn;
> > bool offline = true;
> > +   static const char *envp[] = { "EVENT=offline", NULL };
> >  
> > /*
> >  * acpi_container_offline() calls this for all of the container's
> > @@ -126,7 +127,7 @@ bool acpi_scan_is_offline(struct acpi_device *adev, 
> > bool uevent)
> > list_for_each_entry(pn, >physical_node_list, node)
> > if (device_supports_offline(pn->dev) && !pn->dev->offline) {
> > if (uevent)
> > -   kobject_uevent(>dev->kobj, KOBJ_CHANGE);
> > +   kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, 
> > envp);
> >  
> > offline = false;
> > break;
> > 
> 
> This causes build issues when applied, please fix.
> 

I just sent the v2 patch. Thanks for your review!

Joey Lee 


Re: [PATCH] ACPI / scan: Send the change uevent with offine environmental data

2018-03-19 Thread joeyli
Hi Rafael, 

On Mon, Mar 19, 2018 at 11:02:32AM +0100, Rafael J. Wysocki wrote:
> On Friday, March 2, 2018 7:35:08 AM CET Lee, Chun-Yi wrote:
> > In current design of ACPI container offline, Kernel emits
> > KOBJ_CHANGE uevent to user space to indidate that the ejection of
> > the container was triggered by platform. (caa73ea15 patch)
> > 
> > A pure KOBJ_CHANGE uevent is not enough for user space to identify
> > the purpose. For example, a "udevadm trigger" command can also
> > be used to emit change event to all udev rules. A udev rule can not
> > identify that the event is from kernel for offline or from udevadm
> > for other purpose. Then the offline action in udev rule may also be
> > triggered by udevadm tool.
> > 
> > So, similar to the change uevent of dock, kernel sends the
> > KOBJ_CHANGE uevent with a offline environmental data to indicate
> > purpose. It's useful by udev rule for using ENV{EVENT} filter.
> > 
> > Cc: Michal Hocko  
> > Cc: "Rafael J. Wysocki"  
> > Cc: Len Brown  
> > Signed-off-by: "Lee, Chun-Yi" 
> > ---
> >  drivers/acpi/scan.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 8e63d93..f6dca9b 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -116,6 +116,7 @@ bool acpi_scan_is_offline(struct acpi_device *adev, 
> > bool uevent)
> >  {
> > struct acpi_device_physical_node *pn;
> > bool offline = true;
> > +   static const char *envp[] = { "EVENT=offline", NULL };
> >  
> > /*
> >  * acpi_container_offline() calls this for all of the container's
> > @@ -126,7 +127,7 @@ bool acpi_scan_is_offline(struct acpi_device *adev, 
> > bool uevent)
> > list_for_each_entry(pn, >physical_node_list, node)
> > if (device_supports_offline(pn->dev) && !pn->dev->offline) {
> > if (uevent)
> > -   kobject_uevent(>dev->kobj, KOBJ_CHANGE);
> > +   kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, 
> > envp);
> >  
> > offline = false;
> > break;
> > 
> 
> This causes build issues when applied, please fix.
> 

I just sent the v2 patch. Thanks for your review!

Joey Lee 


[PATCH v2] ACPI / scan: Send the change uevent with offine environmental data

2018-03-19 Thread Lee, Chun-Yi
In current design of ACPI container offline, Kernel emits
KOBJ_CHANGE uevent to user space to indidate that the ejection of
the container was triggered by platform. (caa73ea15 patch)

A pure KOBJ_CHANGE uevent is not enough for user space to identify
the purpose. For example, a "udevadm trigger" command can also
be used to emit change event to all udev rules. A udev rule can not
identify that the event is from kernel for offline or from udevadm
for other purpose. Then the offline action in udev rule may also be
triggered by udevadm tool.

So, similar to the change uevent of dock, kernel sends the
KOBJ_CHANGE uevent with a offline environmental data to indicate
purpose. It's useful by udev rule for using ENV{EVENT} filter.

v2:
Fix build warning for the environmental string

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Acked-by: Michal Hocko 
Tested-by: Michal Hocko 
Signed-off-by: "Lee, Chun-Yi" 
---
 drivers/acpi/scan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 8e63d93..490498e 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -116,6 +116,7 @@ bool acpi_scan_is_offline(struct acpi_device *adev, bool 
uevent)
 {
struct acpi_device_physical_node *pn;
bool offline = true;
+   char *envp[] = { "EVENT=offline", NULL };
 
/*
 * acpi_container_offline() calls this for all of the container's
@@ -126,7 +127,7 @@ bool acpi_scan_is_offline(struct acpi_device *adev, bool 
uevent)
list_for_each_entry(pn, >physical_node_list, node)
if (device_supports_offline(pn->dev) && !pn->dev->offline) {
if (uevent)
-   kobject_uevent(>dev->kobj, KOBJ_CHANGE);
+   kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, 
envp);
 
offline = false;
break;
-- 
2.10.2



[PATCH v2] ACPI / scan: Send the change uevent with offine environmental data

2018-03-19 Thread Lee, Chun-Yi
In current design of ACPI container offline, Kernel emits
KOBJ_CHANGE uevent to user space to indidate that the ejection of
the container was triggered by platform. (caa73ea15 patch)

A pure KOBJ_CHANGE uevent is not enough for user space to identify
the purpose. For example, a "udevadm trigger" command can also
be used to emit change event to all udev rules. A udev rule can not
identify that the event is from kernel for offline or from udevadm
for other purpose. Then the offline action in udev rule may also be
triggered by udevadm tool.

So, similar to the change uevent of dock, kernel sends the
KOBJ_CHANGE uevent with a offline environmental data to indicate
purpose. It's useful by udev rule for using ENV{EVENT} filter.

v2:
Fix build warning for the environmental string

Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Acked-by: Michal Hocko 
Tested-by: Michal Hocko 
Signed-off-by: "Lee, Chun-Yi" 
---
 drivers/acpi/scan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 8e63d93..490498e 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -116,6 +116,7 @@ bool acpi_scan_is_offline(struct acpi_device *adev, bool 
uevent)
 {
struct acpi_device_physical_node *pn;
bool offline = true;
+   char *envp[] = { "EVENT=offline", NULL };
 
/*
 * acpi_container_offline() calls this for all of the container's
@@ -126,7 +127,7 @@ bool acpi_scan_is_offline(struct acpi_device *adev, bool 
uevent)
list_for_each_entry(pn, >physical_node_list, node)
if (device_supports_offline(pn->dev) && !pn->dev->offline) {
if (uevent)
-   kobject_uevent(>dev->kobj, KOBJ_CHANGE);
+   kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, 
envp);
 
offline = false;
break;
-- 
2.10.2



Re: [PATCH v4 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

2018-03-19 Thread Knut Omang
On Mon, 2018-02-05 at 08:20 +0100, Knut Omang wrote:
> On Mon, 2018-02-05 at 16:03 +0900, Masahiro Yamada wrote:

Hi Masahiro,

I know these are busy times but any hope of getting forward on this?
Anything more I can do to ease the process?

Thanks for your time,
Knut

> > 2018-02-05 15:41 GMT+09:00 Knut Omang :
> > > On Fri, 2018-01-19 at 11:14 +0100, Knut Omang wrote:
> > >> Add scripts/runchecks which has generic support for running
> > >> checker tools in a convenient and user friendly way that
> > >> the author hopes can contribute to rein in issues detected
> > >> by these tools in a manageable and convenient way.
> > >>
> > >> scripts/runchecks provides the following basic functionality:
> > >>
> > >> * Makes it possible to selectively suppress output from individual
> > >>   checks on a per file or per subsystem basis.
> > >> * Unifies output and suppression input from different tools
> > >>   by providing a single unified syntax and presentation for the
> > >>   underlying tools in the style of "scripts/checkpatch.pl --show-types".
> > >> * Allows selective run of one, or more (or all) configured tools
> > >>   for each file.
> > >>
> > >> In the Makefile system, the sparse specific setup has been replaced
> > >> by setup for runchecks.
> > >
> > > Hi all,
> > >
> > > - Anything more I can/need to do to bring this forward?
> > > - Any quiet concerns?
> > >
> > > I realize it is a subsystem crossing change,
> > 
> > Is it?  Only Kbuild this is related to.
> 
> Ok, I see!
> 
> > > and a lot going on elsewhere,
> > > nevertheless I believe this is a time saver in the slightly longer run,
> > > as it allows automation of checking, even without a "perfect"
> > > code base to begin with.
> > >
> > 
> > Sorry for the delay.
> 
> I understand, no problem - just was afraid it was about to get lost 
> in between subsystems,
> 
> > I have not been able to find time to dive into the detail yet.
> > (Actually, I tried to do that for v2 or v3, where Python code was so dirty,
> > then consumed my time to figure out what the code was trying to do)
> 
> Hopefully v4 is cleaner from a Python code style point of view at least,
> but let me know if you have any particular part of the code in mind wrt 
> readability. Also hopefully the docs should be of help.
> 
> > I find my concern here:
> > https://lkml.org/lkml/2018/1/5/497
> 
> I believe I have addressed the issues there in v4.
> 
> > Anyway, I will take a look again when I find some time.
> > You do not need to take care of the detail until I request to do so.
> 
> Ok, thanks a lot for your time and the quick response now!
> 
> Best regards,
> Knut
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

2018-03-19 Thread Knut Omang
On Mon, 2018-02-05 at 08:20 +0100, Knut Omang wrote:
> On Mon, 2018-02-05 at 16:03 +0900, Masahiro Yamada wrote:

Hi Masahiro,

I know these are busy times but any hope of getting forward on this?
Anything more I can do to ease the process?

Thanks for your time,
Knut

> > 2018-02-05 15:41 GMT+09:00 Knut Omang :
> > > On Fri, 2018-01-19 at 11:14 +0100, Knut Omang wrote:
> > >> Add scripts/runchecks which has generic support for running
> > >> checker tools in a convenient and user friendly way that
> > >> the author hopes can contribute to rein in issues detected
> > >> by these tools in a manageable and convenient way.
> > >>
> > >> scripts/runchecks provides the following basic functionality:
> > >>
> > >> * Makes it possible to selectively suppress output from individual
> > >>   checks on a per file or per subsystem basis.
> > >> * Unifies output and suppression input from different tools
> > >>   by providing a single unified syntax and presentation for the
> > >>   underlying tools in the style of "scripts/checkpatch.pl --show-types".
> > >> * Allows selective run of one, or more (or all) configured tools
> > >>   for each file.
> > >>
> > >> In the Makefile system, the sparse specific setup has been replaced
> > >> by setup for runchecks.
> > >
> > > Hi all,
> > >
> > > - Anything more I can/need to do to bring this forward?
> > > - Any quiet concerns?
> > >
> > > I realize it is a subsystem crossing change,
> > 
> > Is it?  Only Kbuild this is related to.
> 
> Ok, I see!
> 
> > > and a lot going on elsewhere,
> > > nevertheless I believe this is a time saver in the slightly longer run,
> > > as it allows automation of checking, even without a "perfect"
> > > code base to begin with.
> > >
> > 
> > Sorry for the delay.
> 
> I understand, no problem - just was afraid it was about to get lost 
> in between subsystems,
> 
> > I have not been able to find time to dive into the detail yet.
> > (Actually, I tried to do that for v2 or v3, where Python code was so dirty,
> > then consumed my time to figure out what the code was trying to do)
> 
> Hopefully v4 is cleaner from a Python code style point of view at least,
> but let me know if you have any particular part of the code in mind wrt 
> readability. Also hopefully the docs should be of help.
> 
> > I find my concern here:
> > https://lkml.org/lkml/2018/1/5/497
> 
> I believe I have addressed the issues there in v4.
> 
> > Anyway, I will take a look again when I find some time.
> > You do not need to take care of the detail until I request to do so.
> 
> Ok, thanks a lot for your time and the quick response now!
> 
> Best regards,
> Knut
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCHv2 0/7] sched/fair: Migrate 'misfit' tasks on asymmetric capacity systems

2018-03-19 Thread Gaku Inami
Hi

> -Original Message-
> From: Morten Rasmussen [mailto:morten.rasmus...@arm.com]
> Sent: Thursday, March 15, 2018 11:47 PM
> To: pet...@infradead.org; mi...@redhat.com
> Cc: valentin.schnei...@arm.com; dietmar.eggem...@arm.com; 
> vincent.guit...@linaro.org; Gaku Inami
> ; linux-kernel@vger.kernel.org; Morten Rasmussen 
> 
> Subject: [PATCHv2 0/7] sched/fair: Migrate 'misfit' tasks on asymmetric 
> capacity systems
[snip]
> 
> The patches have been tested on:
>1. Arm Juno (r0): 2+4 Cortex A57/A53
>2. Hikey960: 4+4 Cortex A73/A53
> 

I have tested this on our R-Car again and it works well. In addition,
I confirmed that this patch-set also brings performance improvement to
other benchmarks(e.g. memory load latency in LMbench). You can add:

Tested-by: Gaku Inami 

The patches have been tested on:
   3. Renesas R-Car H3 : 4+4 Cortex A57/A53

Results:
Single runs with completion time of each task
R-Car H3 (tip)
total time:  0.9435s
total time:  0.9952s
total time:  1.3511s
total time:  1.6747s

R-Car H3 (misfit)
total time:  0.9387s
total time:  0.9280s
total time:  0.9616s
total time:  0.9934s

10 run summary (tracking longest running task for each run)
R-Car H3
avg max
tip 1.6737  1.6758
misfit  0.9980  1.0409

Regards,
Inami

[snip]


RE: [PATCHv2 0/7] sched/fair: Migrate 'misfit' tasks on asymmetric capacity systems

2018-03-19 Thread Gaku Inami
Hi

> -Original Message-
> From: Morten Rasmussen [mailto:morten.rasmus...@arm.com]
> Sent: Thursday, March 15, 2018 11:47 PM
> To: pet...@infradead.org; mi...@redhat.com
> Cc: valentin.schnei...@arm.com; dietmar.eggem...@arm.com; 
> vincent.guit...@linaro.org; Gaku Inami
> ; linux-kernel@vger.kernel.org; Morten Rasmussen 
> 
> Subject: [PATCHv2 0/7] sched/fair: Migrate 'misfit' tasks on asymmetric 
> capacity systems
[snip]
> 
> The patches have been tested on:
>1. Arm Juno (r0): 2+4 Cortex A57/A53
>2. Hikey960: 4+4 Cortex A73/A53
> 

I have tested this on our R-Car again and it works well. In addition,
I confirmed that this patch-set also brings performance improvement to
other benchmarks(e.g. memory load latency in LMbench). You can add:

Tested-by: Gaku Inami 

The patches have been tested on:
   3. Renesas R-Car H3 : 4+4 Cortex A57/A53

Results:
Single runs with completion time of each task
R-Car H3 (tip)
total time:  0.9435s
total time:  0.9952s
total time:  1.3511s
total time:  1.6747s

R-Car H3 (misfit)
total time:  0.9387s
total time:  0.9280s
total time:  0.9616s
total time:  0.9934s

10 run summary (tracking longest running task for each run)
R-Car H3
avg max
tip 1.6737  1.6758
misfit  0.9980  1.0409

Regards,
Inami

[snip]


RE: [PATCH] bnx2x: fix spelling mistake: "registeration" -> "registration"

2018-03-19 Thread Kalluru, Sudarsana
-Original Message-
From: Colin King [mailto:colin.k...@canonical.com] 
Sent: 19 March 2018 20:03
To: Elior, Ariel ; Dept-Eng Everest Linux L2 
; net...@vger.kernel.org
Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: [PATCH] bnx2x: fix spelling mistake: "registeration" -> "registration"

From: Colin Ian King 

Trivial fix to spelling mistake in BNX2X_ERR error message text

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 74fc9af4aadb..b8388e93520a 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13913,7 +13913,7 @@ static void bnx2x_register_phc(struct bnx2x *bp)
bp->ptp_clock = ptp_clock_register(>ptp_clock_info, >pdev->dev);
if (IS_ERR(bp->ptp_clock)) {
bp->ptp_clock = NULL;
-   BNX2X_ERR("PTP clock registeration failed\n");
+   BNX2X_ERR("PTP clock registration failed\n");
}
 }
 
-- 
2.15.1

Acked-by: Sudarsana Kalluru 


RE: [PATCH] bnx2x: fix spelling mistake: "registeration" -> "registration"

2018-03-19 Thread Kalluru, Sudarsana
-Original Message-
From: Colin King [mailto:colin.k...@canonical.com] 
Sent: 19 March 2018 20:03
To: Elior, Ariel ; Dept-Eng Everest Linux L2 
; net...@vger.kernel.org
Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: [PATCH] bnx2x: fix spelling mistake: "registeration" -> "registration"

From: Colin Ian King 

Trivial fix to spelling mistake in BNX2X_ERR error message text

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 74fc9af4aadb..b8388e93520a 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13913,7 +13913,7 @@ static void bnx2x_register_phc(struct bnx2x *bp)
bp->ptp_clock = ptp_clock_register(>ptp_clock_info, >pdev->dev);
if (IS_ERR(bp->ptp_clock)) {
bp->ptp_clock = NULL;
-   BNX2X_ERR("PTP clock registeration failed\n");
+   BNX2X_ERR("PTP clock registration failed\n");
}
 }
 
-- 
2.15.1

Acked-by: Sudarsana Kalluru 


Re: [PATCH 4.4 038/134] ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss

2018-03-19 Thread Tero Kristo

On 20/03/18 01:52, Dan Rue wrote:

On Mon, Mar 19, 2018 at 07:05:21PM +0100, Greg Kroah-Hartman wrote:

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Roger Quadros 


[ Upstream commit e2d54fe76997301b49311bde7ba8ef52b47896f9 ]

It seems that if L3_INIT clkdomain is kept in HW_AUTO while usb_otg_ss
is in use then there are random chances that the usb_otg_ss module
will fail to completely idle. i.e. IDLEST = 0x2 instead of 0x3.

Preventing L3_INIT from HW_AUTO while usb_otg_ss module is in use
fixes this issue.

We don't know yet if usb_otg_ss instances 3 and 4 are affected by this
issue or not so don't add this flag for those instances.

Cc: Tero Kristo 
Signed-off-by: Roger Quadros 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 


This fails to build for me on arm32 with default config.

#
# make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm 
multi_v7_defconfig
#
#
# make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm
#
../arch/arm/mach-omap2/omap_hwmod_7xx_data.c:2243:12: error: 
'HWMOD_CLKDM_NOAUTO' undeclared here (not in a function)
   .flags  = HWMOD_CLKDM_NOAUTO,
 ^
../scripts/Makefile.build:269: recipe for target 
'arch/arm/mach-omap2/omap_hwmod_7xx_data.o' failed
make[2]: *** [arch/arm/mach-omap2/omap_hwmod_7xx_data.o] Error 1
make[2]: Target '__build' not remade because of errors.
/home/buildslave/workspace/kernel-single-defconfig-builder/defconfig/multi_v7_defconfig/label/builder/Makefile:969:
 recipe for target 'arch/arm/mach-omap2' failed
make[1]: *** [arch/arm/mach-omap2] Error 2
make[1]: Target '_all' not remade because of errors.
Makefile:152: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
make: Target '_all' not remade because of errors.


This again has some dependencies, at least:

8ff42da41147 ("ARM: OMAP2+ hwmod: Allow modules to disable HW_AUTO")

-Tero



Dan


---
  arch/arm/mach-omap2/omap_hwmod_7xx_data.c |2 ++
  1 file changed, 2 insertions(+)

--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2240,6 +2240,7 @@ static struct omap_hwmod dra7xx_usb_otg_
.class  = _usb_otg_ss_hwmod_class,
.clkdm_name = "l3init_clkdm",
.main_clk   = "dpll_core_h13x2_ck",
+   .flags  = HWMOD_CLKDM_NOAUTO,
.prcm = {
.omap4 = {
.clkctrl_offs = 
DRA7XX_CM_L3INIT_USB_OTG_SS1_CLKCTRL_OFFSET,
@@ -2261,6 +2262,7 @@ static struct omap_hwmod dra7xx_usb_otg_
.class  = _usb_otg_ss_hwmod_class,
.clkdm_name = "l3init_clkdm",
.main_clk   = "dpll_core_h13x2_ck",
+   .flags  = HWMOD_CLKDM_NOAUTO,
.prcm = {
.omap4 = {
.clkctrl_offs = 
DRA7XX_CM_L3INIT_USB_OTG_SS2_CLKCTRL_OFFSET,




--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


Re: [PATCH 4.4 038/134] ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss

2018-03-19 Thread Tero Kristo

On 20/03/18 01:52, Dan Rue wrote:

On Mon, Mar 19, 2018 at 07:05:21PM +0100, Greg Kroah-Hartman wrote:

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Roger Quadros 


[ Upstream commit e2d54fe76997301b49311bde7ba8ef52b47896f9 ]

It seems that if L3_INIT clkdomain is kept in HW_AUTO while usb_otg_ss
is in use then there are random chances that the usb_otg_ss module
will fail to completely idle. i.e. IDLEST = 0x2 instead of 0x3.

Preventing L3_INIT from HW_AUTO while usb_otg_ss module is in use
fixes this issue.

We don't know yet if usb_otg_ss instances 3 and 4 are affected by this
issue or not so don't add this flag for those instances.

Cc: Tero Kristo 
Signed-off-by: Roger Quadros 
Signed-off-by: Tony Lindgren 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 


This fails to build for me on arm32 with default config.

#
# make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm 
multi_v7_defconfig
#
#
# make -j10 -k -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- O=build-arm
#
../arch/arm/mach-omap2/omap_hwmod_7xx_data.c:2243:12: error: 
'HWMOD_CLKDM_NOAUTO' undeclared here (not in a function)
   .flags  = HWMOD_CLKDM_NOAUTO,
 ^
../scripts/Makefile.build:269: recipe for target 
'arch/arm/mach-omap2/omap_hwmod_7xx_data.o' failed
make[2]: *** [arch/arm/mach-omap2/omap_hwmod_7xx_data.o] Error 1
make[2]: Target '__build' not remade because of errors.
/home/buildslave/workspace/kernel-single-defconfig-builder/defconfig/multi_v7_defconfig/label/builder/Makefile:969:
 recipe for target 'arch/arm/mach-omap2' failed
make[1]: *** [arch/arm/mach-omap2] Error 2
make[1]: Target '_all' not remade because of errors.
Makefile:152: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
make: Target '_all' not remade because of errors.


This again has some dependencies, at least:

8ff42da41147 ("ARM: OMAP2+ hwmod: Allow modules to disable HW_AUTO")

-Tero



Dan


---
  arch/arm/mach-omap2/omap_hwmod_7xx_data.c |2 ++
  1 file changed, 2 insertions(+)

--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2240,6 +2240,7 @@ static struct omap_hwmod dra7xx_usb_otg_
.class  = _usb_otg_ss_hwmod_class,
.clkdm_name = "l3init_clkdm",
.main_clk   = "dpll_core_h13x2_ck",
+   .flags  = HWMOD_CLKDM_NOAUTO,
.prcm = {
.omap4 = {
.clkctrl_offs = 
DRA7XX_CM_L3INIT_USB_OTG_SS1_CLKCTRL_OFFSET,
@@ -2261,6 +2262,7 @@ static struct omap_hwmod dra7xx_usb_otg_
.class  = _usb_otg_ss_hwmod_class,
.clkdm_name = "l3init_clkdm",
.main_clk   = "dpll_core_h13x2_ck",
+   .flags  = HWMOD_CLKDM_NOAUTO,
.prcm = {
.omap4 = {
.clkctrl_offs = 
DRA7XX_CM_L3INIT_USB_OTG_SS2_CLKCTRL_OFFSET,




--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


RE: linux-next: build warning after merge of the libata tree

2018-03-19 Thread Richard Zhu
Hi Stephen:
Sorry to introduce this build warning.
I'm preparing one commit to fix it.

Best Regards
Richard Zhu

-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au] 
Sent: Tuesday, March 20, 2018 12:57 PM
To: Tejun Heo 
Cc: Linux-Next Mailing List ; Linux Kernel Mailing 
List ; Richard Zhu 
Subject: linux-next: build warning after merge of the libata tree

Hi Tejun,

After merging the libata tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

drivers/ata/ahci_imx.c: In function 'imx_sata_disable':
drivers/ata/ahci_imx.c:478:2: warning: enumeration value 'AHCI_IMX53' not 
handled in switch [-Wswitch]
  switch (imxpriv->type) {
  ^~

Introduced by commit

  e5878732a521 ("ahci: imx: add the imx6qp ahci sata support")

-- 
Cheers,
Stephen Rothwell


RE: linux-next: build warning after merge of the libata tree

2018-03-19 Thread Richard Zhu
Hi Stephen:
Sorry to introduce this build warning.
I'm preparing one commit to fix it.

Best Regards
Richard Zhu

-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au] 
Sent: Tuesday, March 20, 2018 12:57 PM
To: Tejun Heo 
Cc: Linux-Next Mailing List ; Linux Kernel Mailing 
List ; Richard Zhu 
Subject: linux-next: build warning after merge of the libata tree

Hi Tejun,

After merging the libata tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

drivers/ata/ahci_imx.c: In function 'imx_sata_disable':
drivers/ata/ahci_imx.c:478:2: warning: enumeration value 'AHCI_IMX53' not 
handled in switch [-Wswitch]
  switch (imxpriv->type) {
  ^~

Introduced by commit

  e5878732a521 ("ahci: imx: add the imx6qp ahci sata support")

-- 
Cheers,
Stephen Rothwell


linux-next: build warning after merge of the libata tree

2018-03-19 Thread Stephen Rothwell
Hi Tejun,

After merging the libata tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

drivers/ata/ahci_imx.c: In function 'imx_sata_disable':
drivers/ata/ahci_imx.c:478:2: warning: enumeration value 'AHCI_IMX53' not 
handled in switch [-Wswitch]
  switch (imxpriv->type) {
  ^~

Introduced by commit

  e5878732a521 ("ahci: imx: add the imx6qp ahci sata support")

-- 
Cheers,
Stephen Rothwell


pgpPOK1l3aDhi.pgp
Description: OpenPGP digital signature


linux-next: build warning after merge of the libata tree

2018-03-19 Thread Stephen Rothwell
Hi Tejun,

After merging the libata tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

drivers/ata/ahci_imx.c: In function 'imx_sata_disable':
drivers/ata/ahci_imx.c:478:2: warning: enumeration value 'AHCI_IMX53' not 
handled in switch [-Wswitch]
  switch (imxpriv->type) {
  ^~

Introduced by commit

  e5878732a521 ("ahci: imx: add the imx6qp ahci sata support")

-- 
Cheers,
Stephen Rothwell


pgpPOK1l3aDhi.pgp
Description: OpenPGP digital signature


drivers/platform/x86/dell-smbios-smm.c:99: undefined reference to `dcdbas_smi_request'

2018-03-19 Thread kbuild test robot
Hi Mario,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1b5f3ba415fe4cf8b8b39c8d104ed44cde330658
commit: 25d47027e1003546bfd8964b4423cb39bc2d53e9 platform/x86: dell-smbios: 
Link all dell-smbios-* modules together
date:   10 days ago
config: x86_64-randconfig-s1-03201142 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 25d47027e1003546bfd8964b4423cb39bc2d53e9
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/platform/x86/dell-smbios-smm.o: In function `dell_smbios_smm_call':
>> drivers/platform/x86/dell-smbios-smm.c:99: undefined reference to 
>> `dcdbas_smi_request'

vim +99 drivers/platform/x86/dell-smbios-smm.c

549b4930 Mario Limonciello 2017-11-01   84  
549b4930 Mario Limonciello 2017-11-01   85  int dell_smbios_smm_call(struct 
calling_interface_buffer *input)
549b4930 Mario Limonciello 2017-11-01   86  {
549b4930 Mario Limonciello 2017-11-01   87  struct smi_cmd command;
549b4930 Mario Limonciello 2017-11-01   88  size_t size;
549b4930 Mario Limonciello 2017-11-01   89  
549b4930 Mario Limonciello 2017-11-01   90  size = sizeof(struct 
calling_interface_buffer);
549b4930 Mario Limonciello 2017-11-01   91  command.magic = SMI_CMD_MAGIC;
549b4930 Mario Limonciello 2017-11-01   92  command.command_address = 
da_command_address;
549b4930 Mario Limonciello 2017-11-01   93  command.command_code = 
da_command_code;
549b4930 Mario Limonciello 2017-11-01   94  command.ebx = 
virt_to_phys(buffer);
549b4930 Mario Limonciello 2017-11-01   95  command.ecx = 0x42534931;
549b4930 Mario Limonciello 2017-11-01   96  
549b4930 Mario Limonciello 2017-11-01   97  mutex_lock(_mutex);
549b4930 Mario Limonciello 2017-11-01   98  memcpy(buffer, input, size);
549b4930 Mario Limonciello 2017-11-01  @99  dcdbas_smi_request();
549b4930 Mario Limonciello 2017-11-01  100  memcpy(input, buffer, size);
549b4930 Mario Limonciello 2017-11-01  101  mutex_unlock(_mutex);
549b4930 Mario Limonciello 2017-11-01  102  return 0;
549b4930 Mario Limonciello 2017-11-01  103  }
549b4930 Mario Limonciello 2017-11-01  104  

:: The code at line 99 was first introduced by commit
:: 549b4930f057658dc50d8010e66219233119a4d8 platform/x86: dell-smbios: 
Introduce dispatcher for SMM calls

:: TO: Mario Limonciello 
:: CC: Darren Hart (VMware) 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


drivers/platform/x86/dell-smbios-smm.c:99: undefined reference to `dcdbas_smi_request'

2018-03-19 Thread kbuild test robot
Hi Mario,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1b5f3ba415fe4cf8b8b39c8d104ed44cde330658
commit: 25d47027e1003546bfd8964b4423cb39bc2d53e9 platform/x86: dell-smbios: 
Link all dell-smbios-* modules together
date:   10 days ago
config: x86_64-randconfig-s1-03201142 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 25d47027e1003546bfd8964b4423cb39bc2d53e9
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/platform/x86/dell-smbios-smm.o: In function `dell_smbios_smm_call':
>> drivers/platform/x86/dell-smbios-smm.c:99: undefined reference to 
>> `dcdbas_smi_request'

vim +99 drivers/platform/x86/dell-smbios-smm.c

549b4930 Mario Limonciello 2017-11-01   84  
549b4930 Mario Limonciello 2017-11-01   85  int dell_smbios_smm_call(struct 
calling_interface_buffer *input)
549b4930 Mario Limonciello 2017-11-01   86  {
549b4930 Mario Limonciello 2017-11-01   87  struct smi_cmd command;
549b4930 Mario Limonciello 2017-11-01   88  size_t size;
549b4930 Mario Limonciello 2017-11-01   89  
549b4930 Mario Limonciello 2017-11-01   90  size = sizeof(struct 
calling_interface_buffer);
549b4930 Mario Limonciello 2017-11-01   91  command.magic = SMI_CMD_MAGIC;
549b4930 Mario Limonciello 2017-11-01   92  command.command_address = 
da_command_address;
549b4930 Mario Limonciello 2017-11-01   93  command.command_code = 
da_command_code;
549b4930 Mario Limonciello 2017-11-01   94  command.ebx = 
virt_to_phys(buffer);
549b4930 Mario Limonciello 2017-11-01   95  command.ecx = 0x42534931;
549b4930 Mario Limonciello 2017-11-01   96  
549b4930 Mario Limonciello 2017-11-01   97  mutex_lock(_mutex);
549b4930 Mario Limonciello 2017-11-01   98  memcpy(buffer, input, size);
549b4930 Mario Limonciello 2017-11-01  @99  dcdbas_smi_request();
549b4930 Mario Limonciello 2017-11-01  100  memcpy(input, buffer, size);
549b4930 Mario Limonciello 2017-11-01  101  mutex_unlock(_mutex);
549b4930 Mario Limonciello 2017-11-01  102  return 0;
549b4930 Mario Limonciello 2017-11-01  103  }
549b4930 Mario Limonciello 2017-11-01  104  

:: The code at line 99 was first introduced by commit
:: 549b4930f057658dc50d8010e66219233119a4d8 platform/x86: dell-smbios: 
Introduce dispatcher for SMM calls

:: TO: Mario Limonciello 
:: CC: Darren Hart (VMware) 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCH 4.14 064/109] dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of desc_free

2018-03-19 Thread Vinod Koul
On Mon, Mar 19, 2018 at 12:53:41PM +0530, Vinod Koul wrote:
> On Mon, Mar 19, 2018 at 09:14:00AM +0200, Peter Ujfalusi wrote:
> > On 2018-03-19 05:08, Vinod Koul wrote:
> > > On Sun, Mar 18, 2018 at 11:44:51AM +0100, Greg Kroah-Hartman wrote:
> > >> On Sun, Mar 18, 2018 at 11:24:17AM +0100, Greg Kroah-Hartman wrote:

> > >> Let me just go drop this patch, and the two dmaengine patches that
> > >> relied on this one.  If you think these should be applied to the stable
> > >> trees, can you send me a series of working patches?
> > > 
> > > Okay let me grab your tree and cherry-pick all that is required and send
> > > you. Stay tuned...

As Peter pointed out we missed 6af149d2b142.
Here is the complete list of patches:

3ee7e42f3c9b dmaengine: k3dma: Use vchan_terminate_vdesc() instead of desc_free
397c59bce6cb dmaengine: img-mdc-dma: Use vchan_terminate_vdesc() instead of 
desc_free
47d71bc75d07 dmaengine: amba-pl08x: Use vchan_terminate_vdesc() instead of 
desc_free
f0dd52c85d61 dmaengine: dma-jz4780: Use vchan_terminate_vdesc() instead of 
desc_free
de92436ac40f dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of 
desc_free
174334bcd9f8 dmaengine: edma: Use vchan_terminate_vdesc() instead of desc_free
b1faf0f564ff dmaengine: omap-dma: Use vchan_terminate_vdesc() instead of 
desc_free
1c7f072d94e8 dmaengine: virt-dma: Support for race free transfer termination
6af149d2b142 dmaengine: virt-dma: Add helper to free/reuse a descriptor

Last time we missed 6af149d2b142.

Also I have got a 4.9 break report which is also due to missing 6af149d2b142
and 1c7f072d94e8

Thanks
-- 
~Vinod


Re: [PATCH 4.14 064/109] dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of desc_free

2018-03-19 Thread Vinod Koul
On Mon, Mar 19, 2018 at 12:53:41PM +0530, Vinod Koul wrote:
> On Mon, Mar 19, 2018 at 09:14:00AM +0200, Peter Ujfalusi wrote:
> > On 2018-03-19 05:08, Vinod Koul wrote:
> > > On Sun, Mar 18, 2018 at 11:44:51AM +0100, Greg Kroah-Hartman wrote:
> > >> On Sun, Mar 18, 2018 at 11:24:17AM +0100, Greg Kroah-Hartman wrote:

> > >> Let me just go drop this patch, and the two dmaengine patches that
> > >> relied on this one.  If you think these should be applied to the stable
> > >> trees, can you send me a series of working patches?
> > > 
> > > Okay let me grab your tree and cherry-pick all that is required and send
> > > you. Stay tuned...

As Peter pointed out we missed 6af149d2b142.
Here is the complete list of patches:

3ee7e42f3c9b dmaengine: k3dma: Use vchan_terminate_vdesc() instead of desc_free
397c59bce6cb dmaengine: img-mdc-dma: Use vchan_terminate_vdesc() instead of 
desc_free
47d71bc75d07 dmaengine: amba-pl08x: Use vchan_terminate_vdesc() instead of 
desc_free
f0dd52c85d61 dmaengine: dma-jz4780: Use vchan_terminate_vdesc() instead of 
desc_free
de92436ac40f dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of 
desc_free
174334bcd9f8 dmaengine: edma: Use vchan_terminate_vdesc() instead of desc_free
b1faf0f564ff dmaengine: omap-dma: Use vchan_terminate_vdesc() instead of 
desc_free
1c7f072d94e8 dmaengine: virt-dma: Support for race free transfer termination
6af149d2b142 dmaengine: virt-dma: Add helper to free/reuse a descriptor

Last time we missed 6af149d2b142.

Also I have got a 4.9 break report which is also due to missing 6af149d2b142
and 1c7f072d94e8

Thanks
-- 
~Vinod


Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts

2018-03-19 Thread Jonathan Helman

> On Mar 19, 2018, at 7:31 PM, Jason Wang  wrote:
> 
> 
> 
> On 2018年03月20日 06:14, Jonathan Helman wrote:
>> Export the number of successful and failed hugetlb page
>> allocations via the virtio balloon driver. These 2 counts
>> come directly from the vm_events HTLB_BUDDY_PGALLOC and
>> HTLB_BUDDY_PGALLOC_FAIL.
>> 
>> Signed-off-by: Jonathan Helman 
> 
> Reviewed-by: Jason Wang 

Thanks.

> 
>> ---
>>  drivers/virtio/virtio_balloon.c | 6 ++
>>  include/uapi/linux/virtio_balloon.h | 4 +++-
>>  2 files changed, 9 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/virtio/virtio_balloon.c 
>> b/drivers/virtio/virtio_balloon.c
>> index dfe5684..6b237e3 100644
>> --- a/drivers/virtio/virtio_balloon.c
>> +++ b/drivers/virtio/virtio_balloon.c
>> @@ -272,6 +272,12 @@ static unsigned int update_balloon_stats(struct 
>> virtio_balloon *vb)
>>  pages_to_bytes(events[PSWPOUT]));
>>  update_stat(vb, idx++, VIRTIO_BALLOON_S_MAJFLT, events[PGMAJFAULT]);
>>  update_stat(vb, idx++, VIRTIO_BALLOON_S_MINFLT, events[PGFAULT]);
>> +#ifdef CONFIG_HUGETLB_PAGE
>> +update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGALLOC,
>> +events[HTLB_BUDDY_PGALLOC]);
>> +update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGFAIL,
>> +events[HTLB_BUDDY_PGALLOC_FAIL]);
>> +#endif
>>  #endif
>>  update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMFREE,
>>  pages_to_bytes(i.freeram));
>> diff --git a/include/uapi/linux/virtio_balloon.h 
>> b/include/uapi/linux/virtio_balloon.h
>> index 4e8b830..40297a3 100644
>> --- a/include/uapi/linux/virtio_balloon.h
>> +++ b/include/uapi/linux/virtio_balloon.h
>> @@ -53,7 +53,9 @@ struct virtio_balloon_config {
>>  #define VIRTIO_BALLOON_S_MEMTOT   5   /* Total amount of memory */
>>  #define VIRTIO_BALLOON_S_AVAIL6   /* Available memory as in /proc */
>>  #define VIRTIO_BALLOON_S_CACHES   7   /* Disk caches */
>> -#define VIRTIO_BALLOON_S_NR   8
>> +#define VIRTIO_BALLOON_S_HTLB_PGALLOC  8  /* Hugetlb page allocations */
>> +#define VIRTIO_BALLOON_S_HTLB_PGFAIL   9  /* Hugetlb page allocation 
>> failures */
>> +#define VIRTIO_BALLOON_S_NR   10
>>/*
>>   * Memory statistics structure.
> 
> Not for this patch, but it looks to me that exporting such nr through uapi is 
> fragile.

Sorry, can you explain what you mean here?

Jon

> 
> Thanks



Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts

2018-03-19 Thread Jonathan Helman

> On Mar 19, 2018, at 7:31 PM, Jason Wang  wrote:
> 
> 
> 
> On 2018年03月20日 06:14, Jonathan Helman wrote:
>> Export the number of successful and failed hugetlb page
>> allocations via the virtio balloon driver. These 2 counts
>> come directly from the vm_events HTLB_BUDDY_PGALLOC and
>> HTLB_BUDDY_PGALLOC_FAIL.
>> 
>> Signed-off-by: Jonathan Helman 
> 
> Reviewed-by: Jason Wang 

Thanks.

> 
>> ---
>>  drivers/virtio/virtio_balloon.c | 6 ++
>>  include/uapi/linux/virtio_balloon.h | 4 +++-
>>  2 files changed, 9 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/virtio/virtio_balloon.c 
>> b/drivers/virtio/virtio_balloon.c
>> index dfe5684..6b237e3 100644
>> --- a/drivers/virtio/virtio_balloon.c
>> +++ b/drivers/virtio/virtio_balloon.c
>> @@ -272,6 +272,12 @@ static unsigned int update_balloon_stats(struct 
>> virtio_balloon *vb)
>>  pages_to_bytes(events[PSWPOUT]));
>>  update_stat(vb, idx++, VIRTIO_BALLOON_S_MAJFLT, events[PGMAJFAULT]);
>>  update_stat(vb, idx++, VIRTIO_BALLOON_S_MINFLT, events[PGFAULT]);
>> +#ifdef CONFIG_HUGETLB_PAGE
>> +update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGALLOC,
>> +events[HTLB_BUDDY_PGALLOC]);
>> +update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGFAIL,
>> +events[HTLB_BUDDY_PGALLOC_FAIL]);
>> +#endif
>>  #endif
>>  update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMFREE,
>>  pages_to_bytes(i.freeram));
>> diff --git a/include/uapi/linux/virtio_balloon.h 
>> b/include/uapi/linux/virtio_balloon.h
>> index 4e8b830..40297a3 100644
>> --- a/include/uapi/linux/virtio_balloon.h
>> +++ b/include/uapi/linux/virtio_balloon.h
>> @@ -53,7 +53,9 @@ struct virtio_balloon_config {
>>  #define VIRTIO_BALLOON_S_MEMTOT   5   /* Total amount of memory */
>>  #define VIRTIO_BALLOON_S_AVAIL6   /* Available memory as in /proc */
>>  #define VIRTIO_BALLOON_S_CACHES   7   /* Disk caches */
>> -#define VIRTIO_BALLOON_S_NR   8
>> +#define VIRTIO_BALLOON_S_HTLB_PGALLOC  8  /* Hugetlb page allocations */
>> +#define VIRTIO_BALLOON_S_HTLB_PGFAIL   9  /* Hugetlb page allocation 
>> failures */
>> +#define VIRTIO_BALLOON_S_NR   10
>>/*
>>   * Memory statistics structure.
> 
> Not for this patch, but it looks to me that exporting such nr through uapi is 
> fragile.

Sorry, can you explain what you mean here?

Jon

> 
> Thanks



Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

2018-03-19 Thread Mike Galbraith
On Mon, 2018-03-19 at 17:41 -0400, Waiman Long wrote:
> On 03/19/2018 04:49 PM, Mike Galbraith wrote:
> > On Mon, 2018-03-19 at 08:34 -0700, Tejun Heo wrote:
> >> Hello, Mike.
> >>
> >> On Thu, Mar 15, 2018 at 03:49:01AM +0100, Mike Galbraith wrote:
> >>> Under the hood v2 details are entirely up to you.  My input ends at
> >>> please don't leave dynamic partitioning standing at the dock when v2
> >>> sails.
> >> So, this isn't about implementation details but about what the
> >> interface achieves - ie, what's the actual function?  The only thing I
> >> can see is blocking the entity which is configuring the hierarchy from
> >> making certain configs.  While that might be useful in some specific
> >> use cases, it seems to miss the bar for becoming its own kernel
> >> feature.  After all, nothing prevents the same entity from clearing
> >> the exlusive bit and making the said changes.
> > Yes, privileged contexts can maliciously or stupidly step all over one
> > other no matter what you do (finite resource), but oxymoron creation
> > (CPUs simultaneously balanced and isolated) should be handled.  If one
> > context can allocate a set overlapping a set another context intends to
> > or already has detached from scheduler domains, both are screwed.
> >
> > -Mike
> 
> The allocations of CPUs to child cgroups should be controlled by the
> parent cgroup. It is the parent's fault if some CPUs are in both
> balanced and isolated cgroups.
> 
> How about we don't allow turning off scheduling if the CPUs aren't
> exclusive from the parent's perspective? So you can't create an isolated
> cgroup if the CPUs aren't exclusive. Will this be a good enough compromise?

Sure.  The kernel need only ensure its own sanity.  Userspace conflicts
are more or less a non-issue.  In practice, all players but one will
have been constrained or eliminated prior to any partitioning.

-Mike


Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

2018-03-19 Thread Mike Galbraith
On Mon, 2018-03-19 at 17:41 -0400, Waiman Long wrote:
> On 03/19/2018 04:49 PM, Mike Galbraith wrote:
> > On Mon, 2018-03-19 at 08:34 -0700, Tejun Heo wrote:
> >> Hello, Mike.
> >>
> >> On Thu, Mar 15, 2018 at 03:49:01AM +0100, Mike Galbraith wrote:
> >>> Under the hood v2 details are entirely up to you.  My input ends at
> >>> please don't leave dynamic partitioning standing at the dock when v2
> >>> sails.
> >> So, this isn't about implementation details but about what the
> >> interface achieves - ie, what's the actual function?  The only thing I
> >> can see is blocking the entity which is configuring the hierarchy from
> >> making certain configs.  While that might be useful in some specific
> >> use cases, it seems to miss the bar for becoming its own kernel
> >> feature.  After all, nothing prevents the same entity from clearing
> >> the exlusive bit and making the said changes.
> > Yes, privileged contexts can maliciously or stupidly step all over one
> > other no matter what you do (finite resource), but oxymoron creation
> > (CPUs simultaneously balanced and isolated) should be handled.  If one
> > context can allocate a set overlapping a set another context intends to
> > or already has detached from scheduler domains, both are screwed.
> >
> > -Mike
> 
> The allocations of CPUs to child cgroups should be controlled by the
> parent cgroup. It is the parent's fault if some CPUs are in both
> balanced and isolated cgroups.
> 
> How about we don't allow turning off scheduling if the CPUs aren't
> exclusive from the parent's perspective? So you can't create an isolated
> cgroup if the CPUs aren't exclusive. Will this be a good enough compromise?

Sure.  The kernel need only ensure its own sanity.  Userspace conflicts
are more or less a non-issue.  In practice, all players but one will
have been constrained or eliminated prior to any partitioning.

-Mike


[PATCH v2] ACPI / PM: allow deeper wakeup power states with no _SxD nor _SxW

2018-03-19 Thread Daniel Drake
acpi_dev_pm_get_state() is used to determine the range of allowable
device power states when going into S3 suspend. This is implemented
by executing the _S3D and _S3W ACPI methods.

Linux follows the ACPI spec behaviour in that when _S3D is implemented
and _S3W is not, Linux will not go into a power state deeper than the one
returned by _S3D for a wakeup-enabled device.

However, this same logic is being applied to the case when neither
_S3D nor _S3W are present, and the result is that this function
decides that the device must stay in D0 (fully on) state.

This is breaking USB wakeups on Asus V222GA and Acer XC-830. _S3D and
_S3W are not present, so the USB controller is left in the D0 running
state during S3, and hence it is unable to generate a PME# wake event.

The ACPI spec is unclear on which power states are permissable for
wakeup-enabled devices when both _S3D and _S3W are missing.
However, USB wakeups work fine on these platforms under Windows, where
device manager shows that they are using D3 device state for the USB
controller in S3.

I assume that the "max = min" clamping done by the code here is
specifically written for the _S3D but no _S3W case. By making the
code true to those conditions, avoiding them on these platforms,
the controller will be put into D3 state and USB wakeups start working.

Additionally I feel that this change makes the code more directly
mirror the wording of the ACPI spec and it's associated lack of clarity.

Thanks to Mathias Nyman for pointing us in the right direction.

Signed-off-by: Daniel Drake 
Link: 
http://lkml.kernel.org/r/CAB4CAwf_k-WsF3zL4epm9TKAOu0h=bv1xhxv_gy3bzioo_n...@mail.gmail.com

https://phabricator.endlessm.com/T21410
---

Notes:
This should be considered for Linux 4.17 to give it a decent amount
of testing time before release.

v2: fix unused variable warning

 drivers/acpi/device_pm.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index c4d0a1c912f0..3d96e4da2d98 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -543,6 +543,7 @@ static int acpi_dev_pm_get_state(struct device *dev, struct 
acpi_device *adev,
unsigned long long ret;
int d_min, d_max;
bool wakeup = false;
+   bool has_sxd = false;
acpi_status status;
 
/*
@@ -581,6 +582,10 @@ static int acpi_dev_pm_get_state(struct device *dev, 
struct acpi_device *adev,
else
return -ENODATA;
}
+
+   if (status == AE_OK)
+   has_sxd = true;
+
d_min = ret;
wakeup = device_may_wakeup(dev) && adev->wakeup.flags.valid
&& adev->wakeup.sleep_state >= target_state;
@@ -599,7 +604,11 @@ static int acpi_dev_pm_get_state(struct device *dev, 
struct acpi_device *adev,
method[3] = 'W';
status = acpi_evaluate_integer(handle, method, NULL, );
if (status == AE_NOT_FOUND) {
-   if (target_state > ACPI_STATE_S0)
+   /* No _SxW. In this case, the ACPI spec says that we
+* must not go into any power state deeper than the
+* value returned from _SxD.
+*/
+   if (has_sxd && target_state > ACPI_STATE_S0)
d_max = d_min;
} else if (ACPI_SUCCESS(status) && ret <= ACPI_STATE_D3_COLD) {
/* Fall back to D3cold if ret is not a valid state. */
-- 
2.14.1



[PATCH v2] ACPI / PM: allow deeper wakeup power states with no _SxD nor _SxW

2018-03-19 Thread Daniel Drake
acpi_dev_pm_get_state() is used to determine the range of allowable
device power states when going into S3 suspend. This is implemented
by executing the _S3D and _S3W ACPI methods.

Linux follows the ACPI spec behaviour in that when _S3D is implemented
and _S3W is not, Linux will not go into a power state deeper than the one
returned by _S3D for a wakeup-enabled device.

However, this same logic is being applied to the case when neither
_S3D nor _S3W are present, and the result is that this function
decides that the device must stay in D0 (fully on) state.

This is breaking USB wakeups on Asus V222GA and Acer XC-830. _S3D and
_S3W are not present, so the USB controller is left in the D0 running
state during S3, and hence it is unable to generate a PME# wake event.

The ACPI spec is unclear on which power states are permissable for
wakeup-enabled devices when both _S3D and _S3W are missing.
However, USB wakeups work fine on these platforms under Windows, where
device manager shows that they are using D3 device state for the USB
controller in S3.

I assume that the "max = min" clamping done by the code here is
specifically written for the _S3D but no _S3W case. By making the
code true to those conditions, avoiding them on these platforms,
the controller will be put into D3 state and USB wakeups start working.

Additionally I feel that this change makes the code more directly
mirror the wording of the ACPI spec and it's associated lack of clarity.

Thanks to Mathias Nyman for pointing us in the right direction.

Signed-off-by: Daniel Drake 
Link: 
http://lkml.kernel.org/r/CAB4CAwf_k-WsF3zL4epm9TKAOu0h=bv1xhxv_gy3bzioo_n...@mail.gmail.com

https://phabricator.endlessm.com/T21410
---

Notes:
This should be considered for Linux 4.17 to give it a decent amount
of testing time before release.

v2: fix unused variable warning

 drivers/acpi/device_pm.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index c4d0a1c912f0..3d96e4da2d98 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -543,6 +543,7 @@ static int acpi_dev_pm_get_state(struct device *dev, struct 
acpi_device *adev,
unsigned long long ret;
int d_min, d_max;
bool wakeup = false;
+   bool has_sxd = false;
acpi_status status;
 
/*
@@ -581,6 +582,10 @@ static int acpi_dev_pm_get_state(struct device *dev, 
struct acpi_device *adev,
else
return -ENODATA;
}
+
+   if (status == AE_OK)
+   has_sxd = true;
+
d_min = ret;
wakeup = device_may_wakeup(dev) && adev->wakeup.flags.valid
&& adev->wakeup.sleep_state >= target_state;
@@ -599,7 +604,11 @@ static int acpi_dev_pm_get_state(struct device *dev, 
struct acpi_device *adev,
method[3] = 'W';
status = acpi_evaluate_integer(handle, method, NULL, );
if (status == AE_NOT_FOUND) {
-   if (target_state > ACPI_STATE_S0)
+   /* No _SxW. In this case, the ACPI spec says that we
+* must not go into any power state deeper than the
+* value returned from _SxD.
+*/
+   if (has_sxd && target_state > ACPI_STATE_S0)
d_max = d_min;
} else if (ACPI_SUCCESS(status) && ret <= ACPI_STATE_D3_COLD) {
/* Fall back to D3cold if ret is not a valid state. */
-- 
2.14.1



[PATCH v3 07/13] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk04.1-c3 board file

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  | 1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts | 8 
 2 files changed, 9 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4f209fb..b71487a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -748,6 +748,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8084-mtp.dtb \
qcom-ipq4019-ap.dk01.1-c1.dtb \
qcom-ipq4019-ap.dk04.1-c1.dtb \
+   qcom-ipq4019-ap.dk04.1-c3.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
new file mode 100644
index 000..0843523
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk04.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C3";
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 07/13] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk04.1-c3 board file

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  | 1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts | 8 
 2 files changed, 9 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 4f209fb..b71487a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -748,6 +748,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8084-mtp.dtb \
qcom-ipq4019-ap.dk01.1-c1.dtb \
qcom-ipq4019-ap.dk04.1-c1.dtb \
+   qcom-ipq4019-ap.dk04.1-c3.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
new file mode 100644
index 000..0843523
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk04.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C3";
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 04/13] ARM: dts: ipq4019: Update ipq4019-dk01.1 board data

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Adds missing memory, reserved-memory nodes.

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi | 28 +++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
index e413b21e..ad0fbc9 100644
--- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
@@ -20,6 +20,34 @@
model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK01.1";
compatible = "qcom,ipq4019";
 
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256MB */
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   rsvd1@8700 {
+   /* Reserved for other subsystem */
+   reg = <0x8700 0x50>;
+   no-map;
+   };
+
+   wifi_dump@8750 {
+   reg = <0x8750 0x60>;
+   no-map;
+   };
+
+   rsvd2@87B0 {
+   /* Reserved for other subsystem */
+   reg = <0x87B0 0x50>;
+   no-map;
+   };
+   };
+
soc {
rng@22000 {
status = "ok";
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 04/13] ARM: dts: ipq4019: Update ipq4019-dk01.1 board data

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Adds missing memory, reserved-memory nodes.

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi | 28 +++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
index e413b21e..ad0fbc9 100644
--- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
@@ -20,6 +20,34 @@
model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK01.1";
compatible = "qcom,ipq4019";
 
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256MB */
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   rsvd1@8700 {
+   /* Reserved for other subsystem */
+   reg = <0x8700 0x50>;
+   no-map;
+   };
+
+   wifi_dump@8750 {
+   reg = <0x8750 0x60>;
+   no-map;
+   };
+
+   rsvd2@87B0 {
+   /* Reserved for other subsystem */
+   reg = <0x87B0 0x50>;
+   no-map;
+   };
+   };
+
soc {
rng@22000 {
status = "ok";
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 05/13] ARM: dts: ipq4019: Add ipq4019-ap.dk04.dtsi

2018-03-19 Thread Sricharan R
Add the common parts for the dk04 boards.

Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi | 129 ++
 1 file changed, 129 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi

diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi
new file mode 100644
index 000..96ce081
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1";
+   compatible = "qcom,ipq4019";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256MB */
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   rsvd1@8700 {
+   /* Reserved for other subsystem */
+   reg = <0x8700 0x50>;
+   no-map;
+   };
+
+   wifi_dump@8750 {
+   reg = <0x8750 0x60>;
+   no-map;
+   };
+
+   rsvd2@87B0 {
+   /* Reserved for other subsystem */
+   reg = <0x87B0 0x50>;
+   no-map;
+   };
+   };
+
+   soc {
+   pinctrl@100 {
+   serial_0_pins: serial0_pinmux {
+   mux {
+   pins = "gpio16", "gpio17";
+   function = "blsp_uart0";
+   bias-disable;
+   };
+   };
+
+   serial_1_pins: serial1_pinmux {
+   mux {
+   pins = "gpio8", "gpio9",
+   "gpio10", "gpio11";
+   function = "blsp_uart1";
+   bias-disable;
+   };
+   };
+
+   spi_0_pins: spi_0_pinmux {
+   pinmux {
+   function = "blsp_spi0";
+   pins = "gpio13", "gpio14", "gpio15";
+   bias-disable;
+   };
+   pinmux_cs {
+   function = "gpio";
+   pins = "gpio12";
+   bias-disable;
+   output-high;
+   };
+   };
+
+   i2c_0_pins: i2c_0_pinmux {
+   mux {
+   pins = "gpio20", "gpio21";
+   function = "blsp_i2c0";
+   bias-disable;
+   };
+   };
+
+   nand_pins: nand_pins {
+   mux {
+   pins = "gpio53", "gpio55", "gpio56",
+   "gpio57", "gpio58", "gpio59",
+   "gpio60", "gpio62", "gpio63",
+   "gpio64", "gpio65", "gpio66",
+   "gpio67", "gpio68", "gpio69";
+   function = "qpic";
+   };
+   };
+   };
+
+   serial@78af000 {
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   serial@78b {
+   pinctrl-0 = <_1_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   blsp_dma: dma@7884000 {
+   status = "ok";
+   };
+
+   spi_0: spi@78b5000 { /* BLSP1 QUP1 */
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   cs-gpios = < 12 0>;
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0>;
+   compatible = 

[PATCH v3 05/13] ARM: dts: ipq4019: Add ipq4019-ap.dk04.dtsi

2018-03-19 Thread Sricharan R
Add the common parts for the dk04 boards.

Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi | 129 ++
 1 file changed, 129 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi

diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi
new file mode 100644
index 000..96ce081
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1";
+   compatible = "qcom,ipq4019";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256MB */
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   rsvd1@8700 {
+   /* Reserved for other subsystem */
+   reg = <0x8700 0x50>;
+   no-map;
+   };
+
+   wifi_dump@8750 {
+   reg = <0x8750 0x60>;
+   no-map;
+   };
+
+   rsvd2@87B0 {
+   /* Reserved for other subsystem */
+   reg = <0x87B0 0x50>;
+   no-map;
+   };
+   };
+
+   soc {
+   pinctrl@100 {
+   serial_0_pins: serial0_pinmux {
+   mux {
+   pins = "gpio16", "gpio17";
+   function = "blsp_uart0";
+   bias-disable;
+   };
+   };
+
+   serial_1_pins: serial1_pinmux {
+   mux {
+   pins = "gpio8", "gpio9",
+   "gpio10", "gpio11";
+   function = "blsp_uart1";
+   bias-disable;
+   };
+   };
+
+   spi_0_pins: spi_0_pinmux {
+   pinmux {
+   function = "blsp_spi0";
+   pins = "gpio13", "gpio14", "gpio15";
+   bias-disable;
+   };
+   pinmux_cs {
+   function = "gpio";
+   pins = "gpio12";
+   bias-disable;
+   output-high;
+   };
+   };
+
+   i2c_0_pins: i2c_0_pinmux {
+   mux {
+   pins = "gpio20", "gpio21";
+   function = "blsp_i2c0";
+   bias-disable;
+   };
+   };
+
+   nand_pins: nand_pins {
+   mux {
+   pins = "gpio53", "gpio55", "gpio56",
+   "gpio57", "gpio58", "gpio59",
+   "gpio60", "gpio62", "gpio63",
+   "gpio64", "gpio65", "gpio66",
+   "gpio67", "gpio68", "gpio69";
+   function = "qpic";
+   };
+   };
+   };
+
+   serial@78af000 {
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   serial@78b {
+   pinctrl-0 = <_1_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   blsp_dma: dma@7884000 {
+   status = "ok";
+   };
+
+   spi_0: spi@78b5000 { /* BLSP1 QUP1 */
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   cs-gpios = < 12 0>;
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0>;
+   compatible = "n25q128a11";
+   

[PATCH v3 09/13] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c1 board file

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts | 65 +
 2 files changed, 66 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b71487a..8c93fd0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -749,6 +749,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk01.1-c1.dtb \
qcom-ipq4019-ap.dk04.1-c1.dtb \
qcom-ipq4019-ap.dk04.1-c3.dtb \
+   qcom-ipq4019-ap.dk07.1-c1.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts
new file mode 100644
index 000..e4fddc1
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk07.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK07.1-C1";
+
+   soc {
+   pcie0: pci@4000 {
+   status = "ok";
+   perst-gpio = < 38 0x1>;
+   };
+
+   spi_1: spi@78b6000 { /* BLSP1 QUP2 */
+   status = "ok";
+   };
+
+   pinctrl@100 {
+   serial_1_pins: serial1_pinmux {
+   mux {
+   pins = "gpio8", "gpio9",
+   "gpio10", "gpio11";
+   function = "blsp_uart1";
+   bias-disable;
+   };
+   };
+
+   spi_0_pins: spi_0_pinmux {
+   pinmux {
+   function = "blsp_spi0";
+   pins = "gpio13", "gpio14", "gpio15";
+   bias-disable;
+   };
+   pinmux_cs {
+   function = "gpio";
+   pins = "gpio12";
+   bias-disable;
+   output-high;
+   };
+   };
+   };
+
+   serial@78b {
+   pinctrl-0 = <_1_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   spi_0: spi@78b5000 { /* BLSP1 QUP1 */
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   cs-gpios = < 12 0>;
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0>;
+   compatible = "n25q128a11";
+   spi-max-frequency = <2400>;
+   };
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 09/13] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c1 board file

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts | 65 +
 2 files changed, 66 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b71487a..8c93fd0 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -749,6 +749,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk01.1-c1.dtb \
qcom-ipq4019-ap.dk04.1-c1.dtb \
qcom-ipq4019-ap.dk04.1-c3.dtb \
+   qcom-ipq4019-ap.dk07.1-c1.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts
new file mode 100644
index 000..e4fddc1
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk07.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK07.1-C1";
+
+   soc {
+   pcie0: pci@4000 {
+   status = "ok";
+   perst-gpio = < 38 0x1>;
+   };
+
+   spi_1: spi@78b6000 { /* BLSP1 QUP2 */
+   status = "ok";
+   };
+
+   pinctrl@100 {
+   serial_1_pins: serial1_pinmux {
+   mux {
+   pins = "gpio8", "gpio9",
+   "gpio10", "gpio11";
+   function = "blsp_uart1";
+   bias-disable;
+   };
+   };
+
+   spi_0_pins: spi_0_pinmux {
+   pinmux {
+   function = "blsp_spi0";
+   pins = "gpio13", "gpio14", "gpio15";
+   bias-disable;
+   };
+   pinmux_cs {
+   function = "gpio";
+   pins = "gpio12";
+   bias-disable;
+   output-high;
+   };
+   };
+   };
+
+   serial@78b {
+   pinctrl-0 = <_1_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   spi_0: spi@78b5000 { /* BLSP1 QUP1 */
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   cs-gpios = < 12 0>;
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0>;
+   compatible = "n25q128a11";
+   spi-max-frequency = <2400>;
+   };
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 10/13] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c2 board file

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts | 26 +
 2 files changed, 27 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8c93fd0..0844087 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -750,6 +750,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk04.1-c1.dtb \
qcom-ipq4019-ap.dk04.1-c3.dtb \
qcom-ipq4019-ap.dk07.1-c1.dtb \
+   qcom-ipq4019-ap.dk07.1-c2.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts
new file mode 100644
index 000..c1e909c
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk07.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK07.1-C2";
+
+   soc {
+   pinctrl@100 {
+   serial_1_pins: serial1_pinmux {
+   mux {
+   pins = "gpio8", "gpio9";
+   function = "blsp_uart1";
+   bias-disable;
+   };
+   };
+   };
+
+   serial@78b {
+   pinctrl-0 = <_1_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH] MIPS: ralink: fix booting on mt7621

2018-03-19 Thread NeilBrown

Since commit 3af5a67c86a3 ("MIPS: Fix early CM probing") the MT7621
has not been able to boot.

This patched caused mips_cm_probe() to be called before
mt7621.c::proc_soc_init().

prom_soc_init() has a comment explaining that mips_cm_probe()
"wipes out the bootloader config" and means that configuration
registers are no longer available.  It has some code to re-enable
this config.

Before this re-enable code is run, the sysc register cannot be
read, so when SYSC_REG_CHIP_NAME0 is read, a garbage value
is returned and panic() is called.

If we move the config-repair code to the top of prom_soc_init(),
the registers can be read and boot can proceed.

Fixes: 3af5a67c86a3 ("MIPS: Fix early CM probing")
Signed-off-by: NeilBrown 
---
 arch/mips/ralink/mt7621.c | 41 +
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/arch/mips/ralink/mt7621.c b/arch/mips/ralink/mt7621.c
index 1b274742077d..5a1b19bebd5b 100644
--- a/arch/mips/ralink/mt7621.c
+++ b/arch/mips/ralink/mt7621.c
@@ -170,6 +170,27 @@ void prom_soc_init(struct ralink_soc_info *soc_info)
u32 n1;
u32 rev;
 
+   /* Early detection of CMP support */
+   mips_cm_probe();
+   mips_cpc_probe();
+
+   if (mips_cps_numiocu(0)) {
+   /*
+* mips_cm_probe() wipes out bootloader
+* config for CM regions and we have to configure them
+* again. This SoC cannot talk to pamlbus devices
+* witout proper iocu region set up.
+*
+* FIXME: it would be better to do this with values
+* from DT, but we need this very early because
+* without this we cannot talk to pretty much anything
+* including serial.
+*/
+   write_gcr_reg0_base(MT7621_PALMBUS_BASE);
+   write_gcr_reg0_mask(~MT7621_PALMBUS_SIZE |
+   CM_GCR_REGn_MASK_CMTGT_IOCU0);
+   }
+
n0 = __raw_readl(sysc + SYSC_REG_CHIP_NAME0);
n1 = __raw_readl(sysc + SYSC_REG_CHIP_NAME1);
 
@@ -194,26 +215,6 @@ void prom_soc_init(struct ralink_soc_info *soc_info)
 
rt2880_pinmux_data = mt7621_pinmux_data;
 
-   /* Early detection of CMP support */
-   mips_cm_probe();
-   mips_cpc_probe();
-
-   if (mips_cps_numiocu(0)) {
-   /*
-* mips_cm_probe() wipes out bootloader
-* config for CM regions and we have to configure them
-* again. This SoC cannot talk to pamlbus devices
-* witout proper iocu region set up.
-*
-* FIXME: it would be better to do this with values
-* from DT, but we need this very early because
-* without this we cannot talk to pretty much anything
-* including serial.
-*/
-   write_gcr_reg0_base(MT7621_PALMBUS_BASE);
-   write_gcr_reg0_mask(~MT7621_PALMBUS_SIZE |
-   CM_GCR_REGn_MASK_CMTGT_IOCU0);
-   }
 
if (!register_cps_smp_ops())
return;
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature


[PATCH v3 10/13] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c2 board file

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts | 26 +
 2 files changed, 27 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8c93fd0..0844087 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -750,6 +750,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk04.1-c1.dtb \
qcom-ipq4019-ap.dk04.1-c3.dtb \
qcom-ipq4019-ap.dk07.1-c1.dtb \
+   qcom-ipq4019-ap.dk07.1-c2.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts
new file mode 100644
index 000..c1e909c
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk07.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK07.1-C2";
+
+   soc {
+   pinctrl@100 {
+   serial_1_pins: serial1_pinmux {
+   mux {
+   pins = "gpio8", "gpio9";
+   function = "blsp_uart1";
+   bias-disable;
+   };
+   };
+   };
+
+   serial@78b {
+   pinctrl-0 = <_1_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH] MIPS: ralink: fix booting on mt7621

2018-03-19 Thread NeilBrown

Since commit 3af5a67c86a3 ("MIPS: Fix early CM probing") the MT7621
has not been able to boot.

This patched caused mips_cm_probe() to be called before
mt7621.c::proc_soc_init().

prom_soc_init() has a comment explaining that mips_cm_probe()
"wipes out the bootloader config" and means that configuration
registers are no longer available.  It has some code to re-enable
this config.

Before this re-enable code is run, the sysc register cannot be
read, so when SYSC_REG_CHIP_NAME0 is read, a garbage value
is returned and panic() is called.

If we move the config-repair code to the top of prom_soc_init(),
the registers can be read and boot can proceed.

Fixes: 3af5a67c86a3 ("MIPS: Fix early CM probing")
Signed-off-by: NeilBrown 
---
 arch/mips/ralink/mt7621.c | 41 +
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/arch/mips/ralink/mt7621.c b/arch/mips/ralink/mt7621.c
index 1b274742077d..5a1b19bebd5b 100644
--- a/arch/mips/ralink/mt7621.c
+++ b/arch/mips/ralink/mt7621.c
@@ -170,6 +170,27 @@ void prom_soc_init(struct ralink_soc_info *soc_info)
u32 n1;
u32 rev;
 
+   /* Early detection of CMP support */
+   mips_cm_probe();
+   mips_cpc_probe();
+
+   if (mips_cps_numiocu(0)) {
+   /*
+* mips_cm_probe() wipes out bootloader
+* config for CM regions and we have to configure them
+* again. This SoC cannot talk to pamlbus devices
+* witout proper iocu region set up.
+*
+* FIXME: it would be better to do this with values
+* from DT, but we need this very early because
+* without this we cannot talk to pretty much anything
+* including serial.
+*/
+   write_gcr_reg0_base(MT7621_PALMBUS_BASE);
+   write_gcr_reg0_mask(~MT7621_PALMBUS_SIZE |
+   CM_GCR_REGn_MASK_CMTGT_IOCU0);
+   }
+
n0 = __raw_readl(sysc + SYSC_REG_CHIP_NAME0);
n1 = __raw_readl(sysc + SYSC_REG_CHIP_NAME1);
 
@@ -194,26 +215,6 @@ void prom_soc_init(struct ralink_soc_info *soc_info)
 
rt2880_pinmux_data = mt7621_pinmux_data;
 
-   /* Early detection of CMP support */
-   mips_cm_probe();
-   mips_cpc_probe();
-
-   if (mips_cps_numiocu(0)) {
-   /*
-* mips_cm_probe() wipes out bootloader
-* config for CM regions and we have to configure them
-* again. This SoC cannot talk to pamlbus devices
-* witout proper iocu region set up.
-*
-* FIXME: it would be better to do this with values
-* from DT, but we need this very early because
-* without this we cannot talk to pretty much anything
-* including serial.
-*/
-   write_gcr_reg0_base(MT7621_PALMBUS_BASE);
-   write_gcr_reg0_mask(~MT7621_PALMBUS_SIZE |
-   CM_GCR_REGn_MASK_CMTGT_IOCU0);
-   }
 
if (!register_cps_smp_ops())
return;
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature


[PATCH v3 13/13] ARM: dts: ipq8074: Enable few peripherals for hk01 board

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm64/boot/dts/qcom/ipq8074-hk01.dts | 103 ++
 1 file changed, 103 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts 
b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
index 6a838b5..8efc8f9e 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
+++ b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
@@ -21,6 +21,7 @@
 
aliases {
serial0 = _uart5;
+   serial1 = _blsp2;
};
 
chosen {
@@ -41,6 +42,47 @@
bias-disable;
};
};
+
+i2c_0_pins: i2c_0_pinmux {
+ mux {
+  pins = "gpio42", "gpio43";
+  function = "blsp1_i2c";
+  drive-strength = <8>;
+  bias-disable;
+ };
+};
+
+spi_0_pins: spi_0_pins {
+ mux {
+  pins = "gpio38", "gpio39", "gpio40", 
"gpio41";
+  function = "blsp0_spi";
+  drive-strength = <8>;
+  bias-disable;
+ };
+};
+
+hsuart_pins: hsuart_pins {
+ mux {
+  pins = "gpio46", "gpio47", "gpio48", 
"gpio49";
+  function = "blsp2_uart";
+  drive-strength = <8>;
+  bias-disable;
+ };
+};
+
+qpic_pins: qpic_pins {
+   mux {
+  pins = "gpio1", "gpio3", "gpio4",
+ "gpio5", "gpio6", "gpio7",
+ "gpio8", "gpio10", "gpio11",
+ "gpio12", "gpio13", "gpio14",
+ "gpio15", "gpio16", "gpio17";
+  function = "qpic";
+  drive-strength = <8>;
+  bias-disable;
+ };
+   };
+
};
 
serial@78b3000 {
@@ -48,5 +90,66 @@
pinctrl-names = "default";
status = "ok";
};
+
+   spi@78b5000 {
+pinctrl-0 = <_0_pins>;
+pinctrl-names = "default";
+status = "ok";
+
+m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q128a11", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+};
+   };
+
+   serial@78b1000 {
+pinctrl-0 = <_pins>;
+pinctrl-names = "default";
+status = "ok";
+   };
+
+   i2c_0@78b6000 {
+pinctrl-0 = <_0_pins>;
+pinctrl-names = "default";
+status = "ok";
+   };
+
+   dma@7984000 {
+status = "ok";
+   };
+
+   nand@79b {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+
+   nand@0 {
+   reg = <0>;
+   nand-ecc-strength = <4>;
+   nand-ecc-step-size = <512>;
+   nand-bus-width = <8>;
+   };
+   };
+
+   phy@86000 {
+   status = "ok";
+   };
+
+   phy@8e000 {
+   status = "ok";
+   };
+
+   pci@2000 {
+   status = "ok";
+   perst-gpio = < 58 0x1>;
+   };
+
+   pci@1000 {
+   status = "ok";
+   perst-gpio = < 61 0x1>;
+   };
};
 };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, 

[PATCH v3 13/13] ARM: dts: ipq8074: Enable few peripherals for hk01 board

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm64/boot/dts/qcom/ipq8074-hk01.dts | 103 ++
 1 file changed, 103 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts 
b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
index 6a838b5..8efc8f9e 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
+++ b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
@@ -21,6 +21,7 @@
 
aliases {
serial0 = _uart5;
+   serial1 = _blsp2;
};
 
chosen {
@@ -41,6 +42,47 @@
bias-disable;
};
};
+
+i2c_0_pins: i2c_0_pinmux {
+ mux {
+  pins = "gpio42", "gpio43";
+  function = "blsp1_i2c";
+  drive-strength = <8>;
+  bias-disable;
+ };
+};
+
+spi_0_pins: spi_0_pins {
+ mux {
+  pins = "gpio38", "gpio39", "gpio40", 
"gpio41";
+  function = "blsp0_spi";
+  drive-strength = <8>;
+  bias-disable;
+ };
+};
+
+hsuart_pins: hsuart_pins {
+ mux {
+  pins = "gpio46", "gpio47", "gpio48", 
"gpio49";
+  function = "blsp2_uart";
+  drive-strength = <8>;
+  bias-disable;
+ };
+};
+
+qpic_pins: qpic_pins {
+   mux {
+  pins = "gpio1", "gpio3", "gpio4",
+ "gpio5", "gpio6", "gpio7",
+ "gpio8", "gpio10", "gpio11",
+ "gpio12", "gpio13", "gpio14",
+ "gpio15", "gpio16", "gpio17";
+  function = "qpic";
+  drive-strength = <8>;
+  bias-disable;
+ };
+   };
+
};
 
serial@78b3000 {
@@ -48,5 +90,66 @@
pinctrl-names = "default";
status = "ok";
};
+
+   spi@78b5000 {
+pinctrl-0 = <_0_pins>;
+pinctrl-names = "default";
+status = "ok";
+
+m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q128a11", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+};
+   };
+
+   serial@78b1000 {
+pinctrl-0 = <_pins>;
+pinctrl-names = "default";
+status = "ok";
+   };
+
+   i2c_0@78b6000 {
+pinctrl-0 = <_0_pins>;
+pinctrl-names = "default";
+status = "ok";
+   };
+
+   dma@7984000 {
+status = "ok";
+   };
+
+   nand@79b {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+
+   nand@0 {
+   reg = <0>;
+   nand-ecc-strength = <4>;
+   nand-ecc-step-size = <512>;
+   nand-bus-width = <8>;
+   };
+   };
+
+   phy@86000 {
+   status = "ok";
+   };
+
+   phy@8e000 {
+   status = "ok";
+   };
+
+   pci@2000 {
+   status = "ok";
+   perst-gpio = < 58 0x1>;
+   };
+
+   pci@1000 {
+   status = "ok";
+   perst-gpio = < 61 0x1>;
+   };
};
 };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 12/13] ARM: dts: ipq8074: Add pcie nodes

2018-03-19 Thread Sricharan R
The driver/phy support for ipq8074 is available now.
So enabling the nodes in DT.

Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 157 +-
 1 file changed, 156 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi 
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index a8dbbf0..caf3485 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -24,7 +24,7 @@
ranges = <0 0 0 0x>;
compatible = "simple-bus";
 
-   pinctrl@100 {
+   tlmm: pinctrl@100 {
compatible = "qcom,ipq8074-pinctrl";
reg = <0x100 0x30>;
interrupts = ;
@@ -229,6 +229,161 @@
dma-names = "tx", "rx", "cmd";
status = "disabled";
};
+
+   pcie_phy0: phy@86000 {
+   compatible = "qcom,ipq8074-qmp-pcie-phy";
+   reg = <0x86000 0x1000>;
+   #phy-cells = <0>;
+   clocks = < GCC_PCIE0_PIPE_CLK>;
+   clock-names = "pipe_clk";
+   clock-output-names = "pcie20_phy0_pipe_clk";
+
+   resets = < GCC_PCIE0_PHY_BCR>,
+   < GCC_PCIE0PHY_PHY_BCR>;
+   reset-names = "phy",
+ "common";
+   status = "disabled";
+   };
+
+   pcie0: pci@2000 {
+   compatible = "qcom,pcie-ipq8074";
+   reg =  <0x2000 0xf1d
+   0x2f20 0xa8
+   0x8 0x2000
+   0x2010 0x1000>;
+   reg-names = "dbi", "elbi", "parf", "config";
+   device_type = "pci";
+   linux,pci-domain = <0>;
+   bus-range = <0x00 0xff>;
+   num-lanes = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+
+   phys = <_phy0>;
+   phy-names = "pciephy";
+
+   ranges = <0x8100 0 0x2020 0x2020
+ 0 0x10   /* downstream I/O */
+ 0x8200 0 0x2030 0x2030
+ 0 0xd0>; /* non-prefetchable memory */
+
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1  0 75
+IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+   <0 0 0 2  0 78
+IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+   <0 0 0 3  0 79
+IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+   <0 0 0 4  0 83
+IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+   clocks = < GCC_SYS_NOC_PCIE0_AXI_CLK>,
+< GCC_PCIE0_AXI_M_CLK>,
+< GCC_PCIE0_AXI_S_CLK>,
+< GCC_PCIE0_AHB_CLK>,
+< GCC_PCIE0_AUX_CLK>;
+
+   clock-names = "iface",
+ "axi_m",
+ "axi_s",
+ "ahb",
+ "aux";
+   resets = < GCC_PCIE0_PIPE_ARES>,
+< GCC_PCIE0_SLEEP_ARES>,
+< GCC_PCIE0_CORE_STICKY_ARES>,
+< GCC_PCIE0_AXI_MASTER_ARES>,
+< GCC_PCIE0_AXI_SLAVE_ARES>,
+< GCC_PCIE0_AHB_ARES>,
+< GCC_PCIE0_AXI_MASTER_STICKY_ARES>;
+   reset-names = "pipe",
+ "sleep",
+ "sticky",
+ "axi_m",
+ "axi_s",
+ "ahb",
+ "axi_m_sticky";
+   status = "disabled";
+   };
+
+   pcie_phy1: phy@8e000 {
+   compatible = "qcom,ipq8074-qmp-pcie-phy";
+   reg = <0x8e000 0x1000>;
+   #phy-cells = <0>;
+   clocks = < GCC_PCIE1_PIPE_CLK>;
+   

[PATCH v3 12/13] ARM: dts: ipq8074: Add pcie nodes

2018-03-19 Thread Sricharan R
The driver/phy support for ipq8074 is available now.
So enabling the nodes in DT.

Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 157 +-
 1 file changed, 156 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi 
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index a8dbbf0..caf3485 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -24,7 +24,7 @@
ranges = <0 0 0 0x>;
compatible = "simple-bus";
 
-   pinctrl@100 {
+   tlmm: pinctrl@100 {
compatible = "qcom,ipq8074-pinctrl";
reg = <0x100 0x30>;
interrupts = ;
@@ -229,6 +229,161 @@
dma-names = "tx", "rx", "cmd";
status = "disabled";
};
+
+   pcie_phy0: phy@86000 {
+   compatible = "qcom,ipq8074-qmp-pcie-phy";
+   reg = <0x86000 0x1000>;
+   #phy-cells = <0>;
+   clocks = < GCC_PCIE0_PIPE_CLK>;
+   clock-names = "pipe_clk";
+   clock-output-names = "pcie20_phy0_pipe_clk";
+
+   resets = < GCC_PCIE0_PHY_BCR>,
+   < GCC_PCIE0PHY_PHY_BCR>;
+   reset-names = "phy",
+ "common";
+   status = "disabled";
+   };
+
+   pcie0: pci@2000 {
+   compatible = "qcom,pcie-ipq8074";
+   reg =  <0x2000 0xf1d
+   0x2f20 0xa8
+   0x8 0x2000
+   0x2010 0x1000>;
+   reg-names = "dbi", "elbi", "parf", "config";
+   device_type = "pci";
+   linux,pci-domain = <0>;
+   bus-range = <0x00 0xff>;
+   num-lanes = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+
+   phys = <_phy0>;
+   phy-names = "pciephy";
+
+   ranges = <0x8100 0 0x2020 0x2020
+ 0 0x10   /* downstream I/O */
+ 0x8200 0 0x2030 0x2030
+ 0 0xd0>; /* non-prefetchable memory */
+
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1  0 75
+IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+   <0 0 0 2  0 78
+IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+   <0 0 0 3  0 79
+IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+   <0 0 0 4  0 83
+IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+   clocks = < GCC_SYS_NOC_PCIE0_AXI_CLK>,
+< GCC_PCIE0_AXI_M_CLK>,
+< GCC_PCIE0_AXI_S_CLK>,
+< GCC_PCIE0_AHB_CLK>,
+< GCC_PCIE0_AUX_CLK>;
+
+   clock-names = "iface",
+ "axi_m",
+ "axi_s",
+ "ahb",
+ "aux";
+   resets = < GCC_PCIE0_PIPE_ARES>,
+< GCC_PCIE0_SLEEP_ARES>,
+< GCC_PCIE0_CORE_STICKY_ARES>,
+< GCC_PCIE0_AXI_MASTER_ARES>,
+< GCC_PCIE0_AXI_SLAVE_ARES>,
+< GCC_PCIE0_AHB_ARES>,
+< GCC_PCIE0_AXI_MASTER_STICKY_ARES>;
+   reset-names = "pipe",
+ "sleep",
+ "sticky",
+ "axi_m",
+ "axi_s",
+ "ahb",
+ "axi_m_sticky";
+   status = "disabled";
+   };
+
+   pcie_phy1: phy@8e000 {
+   compatible = "qcom,ipq8074-qmp-pcie-phy";
+   reg = <0x8e000 0x1000>;
+   #phy-cells = <0>;
+   clocks = < GCC_PCIE1_PIPE_CLK>;
+   clock-names = "pipe_clk";
+  

[PATCH v3 08/13] ARM: dts: ipq4019: Add ipq4019-ap.dk07.1 common data

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Add the common data for all dk07 based boards.

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi | 83 +++
 1 file changed, 83 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi

diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi
new file mode 100644
index 000..37a2ea8
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK07.1";
+   compatible = "qcom,ipq4019";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x2000>; /* 512MB */
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   rsvd1@8700 {
+   /* Reserved for other subsystem */
+   reg = <0x8700 0x50>;
+   no-map;
+   };
+
+   wifi_dump@8750 {
+   reg = <0x8750 0x60>;
+   no-map;
+   };
+
+   rsvd2@87B0 {
+   /* Reserved for other subsystem */
+   reg = <0x87B0 0x50>;
+   no-map;
+   };
+   };
+
+   soc {
+   pinctrl@100 {
+   serial_0_pins: serial0_pinmux {
+   mux {
+   pins = "gpio16", "gpio17";
+   function = "blsp_uart0";
+   bias-disable;
+   };
+   };
+
+   i2c_0_pins: i2c_0_pinmux {
+   mux {
+   pins = "gpio20", "gpio21";
+   function = "blsp_i2c0";
+   bias-disable;
+   };
+   };
+   };
+
+   serial@78af000 {
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   blsp_dma: dma@7884000 {
+   status = "ok";
+   };
+
+   i2c_0: i2c@78b7000 { /* BLSP1 QUP2 */
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   qpic_bam: dma@7984000 {
+   status = "ok";
+   };
+
+   nand: qpic-nand@79b {
+   status = "ok";
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 08/13] ARM: dts: ipq4019: Add ipq4019-ap.dk07.1 common data

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Add the common data for all dk07 based boards.

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi | 83 +++
 1 file changed, 83 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi

diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi
new file mode 100644
index 000..37a2ea8
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK07.1";
+   compatible = "qcom,ipq4019";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x2000>; /* 512MB */
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   rsvd1@8700 {
+   /* Reserved for other subsystem */
+   reg = <0x8700 0x50>;
+   no-map;
+   };
+
+   wifi_dump@8750 {
+   reg = <0x8750 0x60>;
+   no-map;
+   };
+
+   rsvd2@87B0 {
+   /* Reserved for other subsystem */
+   reg = <0x87B0 0x50>;
+   no-map;
+   };
+   };
+
+   soc {
+   pinctrl@100 {
+   serial_0_pins: serial0_pinmux {
+   mux {
+   pins = "gpio16", "gpio17";
+   function = "blsp_uart0";
+   bias-disable;
+   };
+   };
+
+   i2c_0_pins: i2c_0_pinmux {
+   mux {
+   pins = "gpio20", "gpio21";
+   function = "blsp_i2c0";
+   bias-disable;
+   };
+   };
+   };
+
+   serial@78af000 {
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   blsp_dma: dma@7884000 {
+   status = "ok";
+   };
+
+   i2c_0: i2c@78b7000 { /* BLSP1 QUP2 */
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   qpic_bam: dma@7984000 {
+   status = "ok";
+   };
+
+   nand: qpic-nand@79b {
+   status = "ok";
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 11/13] ARM: dts: ipq8074: Add peripheral nodes

2018-03-19 Thread Sricharan R
Add serial, i2c, bam, spi, qpic peripheral nodes.

Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 105 ++
 1 file changed, 105 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi 
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index 2bc5dec..a8dbbf0 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -124,6 +124,111 @@
clock-names = "core", "iface";
status = "disabled";
};
+
+   blsp_dma: dma@7884000 {
+   compatible = "qcom,bam-v1.7.0";
+   reg = <0x7884000 0x2b000>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>;
+   clock-names = "bam_clk";
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+   };
+
+   serial_blsp0: serial@78af000 {
+   compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+   reg = <0x78af000 0x200>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_UART1_APPS_CLK>,
+< GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   status = "disabled";
+   };
+
+   serial_blsp2: serial@78b1000 {
+   compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+   reg = <0x78b1000 0x200>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_UART3_APPS_CLK>,
+   < GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   dmas = <_dma 4>,
+   <_dma 5>;
+   dma-names = "tx", "rx";
+   status = "disabled";
+   };
+
+   spi_0: spi@78b5000 {
+   compatible = "qcom,spi-qup-v2.2.1";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x78b5000 0x600>;
+   interrupts = ;
+   spi-max-frequency = <5000>;
+   clocks = < GCC_BLSP1_QUP1_SPI_APPS_CLK>,
+   < GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   dmas = <_dma 12>, <_dma 13>;
+   dma-names = "tx", "rx";
+   status = "disabled";
+   };
+
+   i2c_0: i2c@78b6000 {
+   compatible = "qcom,i2c-qup-v2.2.1";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x78b6000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+   < GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   clock-frequency = <40>;
+   dmas = <_dma 15>, <_dma 14>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   i2c_1: i2c@78b7000 {
+   compatible = "qcom,i2c-qup-v2.2.1";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x78b7000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+   < GCC_BLSP1_QUP3_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   clock-frequency = <10>;
+   dmas = <_dma 17>, <_dma 16>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   qpic_bam: dma@7984000 {
+   compatible = "qcom,bam-v1.7.0";
+   reg = <0x7984000 0x1a000>;
+   interrupts = ;
+   clocks = < GCC_QPIC_AHB_CLK>;
+   clock-names = "bam_clk";
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+   status = "disabled";
+   };
+
+   qpic_nand: nand@79b {
+   compatible = "qcom,ipq8074-nand";
+   reg = <0x79b 0x1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < GCC_QPIC_CLK>,
+< GCC_QPIC_AHB_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <_bam 0>,
+  <_bam 1>,
+   

[PATCH v3 11/13] ARM: dts: ipq8074: Add peripheral nodes

2018-03-19 Thread Sricharan R
Add serial, i2c, bam, spi, qpic peripheral nodes.

Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 105 ++
 1 file changed, 105 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi 
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index 2bc5dec..a8dbbf0 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -124,6 +124,111 @@
clock-names = "core", "iface";
status = "disabled";
};
+
+   blsp_dma: dma@7884000 {
+   compatible = "qcom,bam-v1.7.0";
+   reg = <0x7884000 0x2b000>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>;
+   clock-names = "bam_clk";
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+   };
+
+   serial_blsp0: serial@78af000 {
+   compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+   reg = <0x78af000 0x200>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_UART1_APPS_CLK>,
+< GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   status = "disabled";
+   };
+
+   serial_blsp2: serial@78b1000 {
+   compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+   reg = <0x78b1000 0x200>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_UART3_APPS_CLK>,
+   < GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   dmas = <_dma 4>,
+   <_dma 5>;
+   dma-names = "tx", "rx";
+   status = "disabled";
+   };
+
+   spi_0: spi@78b5000 {
+   compatible = "qcom,spi-qup-v2.2.1";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x78b5000 0x600>;
+   interrupts = ;
+   spi-max-frequency = <5000>;
+   clocks = < GCC_BLSP1_QUP1_SPI_APPS_CLK>,
+   < GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   dmas = <_dma 12>, <_dma 13>;
+   dma-names = "tx", "rx";
+   status = "disabled";
+   };
+
+   i2c_0: i2c@78b6000 {
+   compatible = "qcom,i2c-qup-v2.2.1";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x78b6000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+   < GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   clock-frequency = <40>;
+   dmas = <_dma 15>, <_dma 14>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   i2c_1: i2c@78b7000 {
+   compatible = "qcom,i2c-qup-v2.2.1";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x78b7000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+   < GCC_BLSP1_QUP3_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   clock-frequency = <10>;
+   dmas = <_dma 17>, <_dma 16>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   qpic_bam: dma@7984000 {
+   compatible = "qcom,bam-v1.7.0";
+   reg = <0x7984000 0x1a000>;
+   interrupts = ;
+   clocks = < GCC_QPIC_AHB_CLK>;
+   clock-names = "bam_clk";
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+   status = "disabled";
+   };
+
+   qpic_nand: nand@79b {
+   compatible = "qcom,ipq8074-nand";
+   reg = <0x79b 0x1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < GCC_QPIC_CLK>,
+< GCC_QPIC_AHB_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <_bam 0>,
+  <_bam 1>,
+  <_bam 2>;
+   

[PATCH v3 06/13] ARM: dts: ipq4019: Add ipq4019-ap.dk04.1-c1 board file

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts | 20 
 2 files changed, 21 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b59e99b..4f209fb 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -747,6 +747,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8084-ifc6540.dtb \
qcom-apq8084-mtp.dtb \
qcom-ipq4019-ap.dk01.1-c1.dtb \
+   qcom-ipq4019-ap.dk04.1-c1.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
new file mode 100644
index 000..871ac3f
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk04.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C1";
+
+   soc {
+   qpic_bam: dma@7984000 {
+   status = "ok";
+   };
+
+   nand: qpic-nand@79b {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 06/13] ARM: dts: ipq4019: Add ipq4019-ap.dk04.1-c1 board file

2018-03-19 Thread Sricharan R
Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts | 20 
 2 files changed, 21 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b59e99b..4f209fb 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -747,6 +747,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8084-ifc6540.dtb \
qcom-apq8084-mtp.dtb \
qcom-ipq4019-ap.dk01.1-c1.dtb \
+   qcom-ipq4019-ap.dk04.1-c1.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
new file mode 100644
index 000..871ac3f
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk04.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C1";
+
+   soc {
+   qpic_bam: dma@7984000 {
+   status = "ok";
+   };
+
+   nand: qpic-nand@79b {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 01/13] firmware: qcom: scm: Add ipq4019 soc compatible

2018-03-19 Thread Sricharan R
Add the compatible for ipq4019.
This does not need clocks to do scm calls.

Reviewed-by: Rob Herring 
Signed-off-by: Sricharan R 
---
 Documentation/devicetree/bindings/firmware/qcom,scm.txt | 3 ++-
 drivers/firmware/qcom_scm.c | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt 
b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index 7b40054..fcf6979 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -11,9 +11,10 @@ Required properties:
  * "qcom,scm-msm8660" for MSM8660 platforms
  * "qcom,scm-msm8690" for MSM8690 platforms
  * "qcom,scm-msm8996" for MSM8996 platforms
+ * "qcom,scm-ipq4019" for IPQ4019 platforms
  * "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
 - clocks: One to three clocks may be required based on compatible.
- * No clock required for "qcom,scm-msm8996"
+ * No clock required for "qcom,scm-msm8996", "qcom,scm-ipq4019"
  * Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and 
"qcom,scm-msm8960"
  * Core, iface, and bus clocks required for "qcom,scm"
 - clock-names: Must contain "core" for the core clock, "iface" for the 
interface
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 5a7d6930..e778af7 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -603,6 +603,9 @@ static void qcom_scm_shutdown(struct platform_device *pdev)
{ .compatible = "qcom,scm-msm8996",
  .data = NULL, /* no clocks */
},
+   { .compatible = "qcom,scm-ipq4019",
+ .data = NULL, /* no clocks */
+   },
{ .compatible = "qcom,scm",
  .data = (void *)(SCM_HAS_CORE_CLK
   | SCM_HAS_IFACE_CLK
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 01/13] firmware: qcom: scm: Add ipq4019 soc compatible

2018-03-19 Thread Sricharan R
Add the compatible for ipq4019.
This does not need clocks to do scm calls.

Reviewed-by: Rob Herring 
Signed-off-by: Sricharan R 
---
 Documentation/devicetree/bindings/firmware/qcom,scm.txt | 3 ++-
 drivers/firmware/qcom_scm.c | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt 
b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index 7b40054..fcf6979 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -11,9 +11,10 @@ Required properties:
  * "qcom,scm-msm8660" for MSM8660 platforms
  * "qcom,scm-msm8690" for MSM8690 platforms
  * "qcom,scm-msm8996" for MSM8996 platforms
+ * "qcom,scm-ipq4019" for IPQ4019 platforms
  * "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
 - clocks: One to three clocks may be required based on compatible.
- * No clock required for "qcom,scm-msm8996"
+ * No clock required for "qcom,scm-msm8996", "qcom,scm-ipq4019"
  * Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and 
"qcom,scm-msm8960"
  * Core, iface, and bus clocks required for "qcom,scm"
 - clock-names: Must contain "core" for the core clock, "iface" for the 
interface
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 5a7d6930..e778af7 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -603,6 +603,9 @@ static void qcom_scm_shutdown(struct platform_device *pdev)
{ .compatible = "qcom,scm-msm8996",
  .data = NULL, /* no clocks */
},
+   { .compatible = "qcom,scm-ipq4019",
+ .data = NULL, /* no clocks */
+   },
{ .compatible = "qcom,scm",
  .data = (void *)(SCM_HAS_CORE_CLK
   | SCM_HAS_IFACE_CLK
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 00/13] ARM: dts: ipq: updates to enable a few peripherals

2018-03-19 Thread Sricharan R
[v3]
* Fixed minor comments from v2,
  https://www.spinics.net/lists/arm-kernel/msg641480.html

* Added Abhishek's review tags

[v2]
* Addressed all comments from Abhishek
* Removed dk01-c2 and dk04-c5 spinand based boards
  as support for spinand is not complete
* Based all patches on top of Andy's for-next branch

[V1]
* https://www.spinics.net/lists/arm-kernel/msg631318.html

Sricharan R (13):
  firmware: qcom: scm: Add ipq4019 soc compatible
  ARM: dts: ipq4019: Add a few peripheral nodes
  ARM: dts: ipq4019: Change the max opp frequency
  ARM: dts: ipq4019: Update ipq4019-dk01.1 board data
  ARM: dts: ipq4019: Add ipq4019-ap.dk04.dtsi
  ARM: dts: ipq4019: Add ipq4019-ap.dk04.1-c1 board file
  ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk04.1-c3 board file
  ARM: dts: ipq4019: Add ipq4019-ap.dk07.1 common data
  ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c1 board file
  ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c2 board file
  ARM: dts: ipq8074: Add peripheral nodes
  ARM: dts: ipq8074: Add pcie nodes
  ARM: dts: ipq8074: Enable few peripherals for hk01 board

 .../devicetree/bindings/firmware/qcom,scm.txt  |   3 +-
 arch/arm/boot/dts/Makefile |   4 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi  |  32 ++-
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts|  20 ++
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts|   8 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi  | 135 +++
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts|  65 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts|  26 ++
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi  |  83 +++
 arch/arm/boot/dts/qcom-ipq4019.dtsi| 136 ++-
 arch/arm64/boot/dts/qcom/ipq8074-hk01.dts  | 103 
 arch/arm64/boot/dts/qcom/ipq8074.dtsi  | 262 -
 drivers/firmware/qcom_scm.c|   3 +
 13 files changed, 875 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 02/13] ARM: dts: ipq4019: Add a few peripheral nodes

2018-03-19 Thread Sricharan R
Now with the driver updates for some peripherals being there,
add i2c, spi, pcie, bam, qpic-nand, scm nodes to enhance the available
peripheral support.

Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019.dtsi | 134 
 1 file changed, 134 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019.dtsi
index 10d112a..3a7127c 100644
--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -25,7 +25,9 @@
 
aliases {
spi0 = _0;
+   spi1 = _1;
i2c0 = _0;
+   i2c1 = _1;
};
 
cpus {
@@ -104,6 +106,12 @@
};
};
 
+   firmware {
+   scm {
+   compatible = "qcom,scm-ipq4019";
+   };
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <1 2 0xf08>,
@@ -172,6 +180,22 @@
clock-names = "core", "iface";
#address-cells = <1>;
#size-cells = <0>;
+   dmas = <_dma 5>, <_dma 4>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   spi_1: spi@78b6000 { /* BLSP1 QUP2 */
+   compatible = "qcom,spi-qup-v2.2.1";
+   reg = <0x78b6000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_QUP2_SPI_APPS_CLK>,
+   < GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   dmas = <_dma 7>, <_dma 6>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
@@ -184,9 +208,24 @@
clock-names = "iface", "core";
#address-cells = <1>;
#size-cells = <0>;
+   dmas = <_dma 9>, <_dma 8>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
+   i2c_1: i2c@78b8000 { /* BLSP1 QUP4 */
+   compatible = "qcom,i2c-qup-v2.2.1";
+   reg = <0x78b8000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+< GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   dmas = <_dma 11>, <_dma 10>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
 
cryptobam: dma@8e04000 {
compatible = "qcom,bam-v1.7.0";
@@ -293,6 +332,101 @@
reg = <0x4ab000 0x4>;
};
 
+   pcie0: pci@4000 {
+   compatible = "qcom,pcie-ipq4019", "snps,dw-pcie";
+   reg =  <0x4000 0xf1d
+   0x4f20 0xa8
+   0x8 0x2000
+   0x4010 0x1000>;
+   reg-names = "dbi", "elbi", "parf", "config";
+   device_type = "pci";
+   linux,pci-domain = <0>;
+   bus-range = <0x00 0xff>;
+   num-lanes = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+
+   ranges = <0x8100 0 0x4020 0x4020 0 
0x0010
+ 0x8200 0 0x4800 0x4800 0 
0x1000>;
+
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1  0 142 
IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+   <0 0 0 2  0 143 
IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+   <0 0 0 3  0 144 
IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+   <0 0 0 4  0 145 
IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+   clocks = < GCC_PCIE_AHB_CLK>,
+< GCC_PCIE_AXI_M_CLK>,
+< GCC_PCIE_AXI_S_CLK>;
+   clock-names = "aux",
+ "master_bus",
+ "slave_bus";
+
+   resets = < PCIE_AXI_M_ARES>,
+< PCIE_AXI_S_ARES>,
+< 

[PATCH v3 00/13] ARM: dts: ipq: updates to enable a few peripherals

2018-03-19 Thread Sricharan R
[v3]
* Fixed minor comments from v2,
  https://www.spinics.net/lists/arm-kernel/msg641480.html

* Added Abhishek's review tags

[v2]
* Addressed all comments from Abhishek
* Removed dk01-c2 and dk04-c5 spinand based boards
  as support for spinand is not complete
* Based all patches on top of Andy's for-next branch

[V1]
* https://www.spinics.net/lists/arm-kernel/msg631318.html

Sricharan R (13):
  firmware: qcom: scm: Add ipq4019 soc compatible
  ARM: dts: ipq4019: Add a few peripheral nodes
  ARM: dts: ipq4019: Change the max opp frequency
  ARM: dts: ipq4019: Update ipq4019-dk01.1 board data
  ARM: dts: ipq4019: Add ipq4019-ap.dk04.dtsi
  ARM: dts: ipq4019: Add ipq4019-ap.dk04.1-c1 board file
  ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk04.1-c3 board file
  ARM: dts: ipq4019: Add ipq4019-ap.dk07.1 common data
  ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c1 board file
  ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c2 board file
  ARM: dts: ipq8074: Add peripheral nodes
  ARM: dts: ipq8074: Add pcie nodes
  ARM: dts: ipq8074: Enable few peripherals for hk01 board

 .../devicetree/bindings/firmware/qcom,scm.txt  |   3 +-
 arch/arm/boot/dts/Makefile |   4 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi  |  32 ++-
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts|  20 ++
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts|   8 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi  | 135 +++
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts|  65 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts|  26 ++
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi  |  83 +++
 arch/arm/boot/dts/qcom-ipq4019.dtsi| 136 ++-
 arch/arm64/boot/dts/qcom/ipq8074-hk01.dts  | 103 
 arch/arm64/boot/dts/qcom/ipq8074.dtsi  | 262 -
 drivers/firmware/qcom_scm.c|   3 +
 13 files changed, 875 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 02/13] ARM: dts: ipq4019: Add a few peripheral nodes

2018-03-19 Thread Sricharan R
Now with the driver updates for some peripherals being there,
add i2c, spi, pcie, bam, qpic-nand, scm nodes to enhance the available
peripheral support.

Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019.dtsi | 134 
 1 file changed, 134 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019.dtsi
index 10d112a..3a7127c 100644
--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -25,7 +25,9 @@
 
aliases {
spi0 = _0;
+   spi1 = _1;
i2c0 = _0;
+   i2c1 = _1;
};
 
cpus {
@@ -104,6 +106,12 @@
};
};
 
+   firmware {
+   scm {
+   compatible = "qcom,scm-ipq4019";
+   };
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <1 2 0xf08>,
@@ -172,6 +180,22 @@
clock-names = "core", "iface";
#address-cells = <1>;
#size-cells = <0>;
+   dmas = <_dma 5>, <_dma 4>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   spi_1: spi@78b6000 { /* BLSP1 QUP2 */
+   compatible = "qcom,spi-qup-v2.2.1";
+   reg = <0x78b6000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_QUP2_SPI_APPS_CLK>,
+   < GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   dmas = <_dma 7>, <_dma 6>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
@@ -184,9 +208,24 @@
clock-names = "iface", "core";
#address-cells = <1>;
#size-cells = <0>;
+   dmas = <_dma 9>, <_dma 8>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
+   i2c_1: i2c@78b8000 { /* BLSP1 QUP4 */
+   compatible = "qcom,i2c-qup-v2.2.1";
+   reg = <0x78b8000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+< GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   dmas = <_dma 11>, <_dma 10>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
 
cryptobam: dma@8e04000 {
compatible = "qcom,bam-v1.7.0";
@@ -293,6 +332,101 @@
reg = <0x4ab000 0x4>;
};
 
+   pcie0: pci@4000 {
+   compatible = "qcom,pcie-ipq4019", "snps,dw-pcie";
+   reg =  <0x4000 0xf1d
+   0x4f20 0xa8
+   0x8 0x2000
+   0x4010 0x1000>;
+   reg-names = "dbi", "elbi", "parf", "config";
+   device_type = "pci";
+   linux,pci-domain = <0>;
+   bus-range = <0x00 0xff>;
+   num-lanes = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+
+   ranges = <0x8100 0 0x4020 0x4020 0 
0x0010
+ 0x8200 0 0x4800 0x4800 0 
0x1000>;
+
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1  0 142 
IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+   <0 0 0 2  0 143 
IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+   <0 0 0 3  0 144 
IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+   <0 0 0 4  0 145 
IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+   clocks = < GCC_PCIE_AHB_CLK>,
+< GCC_PCIE_AXI_M_CLK>,
+< GCC_PCIE_AXI_S_CLK>;
+   clock-names = "aux",
+ "master_bus",
+ "slave_bus";
+
+   resets = < PCIE_AXI_M_ARES>,
+< PCIE_AXI_S_ARES>,
+< PCIE_PIPE_ARES>,
+< 

[PATCH v3 03/13] ARM: dts: ipq4019: Change the max opp frequency

2018-03-19 Thread Sricharan R
The max opp frequency is 716MHZ. So update that.

Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019.dtsi
index 3a7127c..e87e825 100644
--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -47,7 +47,7 @@
48000   110
20  110
50  110
-   666000  110
+   716000  110
>;
clock-latency = <256000>;
};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



[PATCH v3 03/13] ARM: dts: ipq4019: Change the max opp frequency

2018-03-19 Thread Sricharan R
The max opp frequency is 716MHZ. So update that.

Reviewed-by: Abhishek Sahu 
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019.dtsi
index 3a7127c..e87e825 100644
--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -47,7 +47,7 @@
48000   110
20  110
50  110
-   666000  110
+   716000  110
>;
clock-latency = <256000>;
};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation



Re: [PATCH v4 1/2] kconfig: warn unmet direct dependency of tristate symbols selected by y

2018-03-19 Thread Masahiro Yamada
2018-03-19 7:17 GMT+09:00 Eugeniu Rosca :
> Hi Masahiro,
>
> On Tue, Mar 13, 2018 at 06:56:07PM +0900, Masahiro Yamada wrote:
>> Commit 246cf9c26bf1 ("kbuild: Warn on selecting symbols with unmet
>> direct dependencies") forcibly promoted ->dir_dep.tri to yes from mod.
>> So, the unmet direct dependencies of tristate symbols are not reported.
>>
>> [Test Case]
>>
>>   config MODULES
>>   def_bool y
>>   option modules
>>
>>   config A
>>   def_bool y
>>   select B
>>
>>   config B
>>   tristate "B"
>>   depends on m
>>
>> This causes unmet dependency because 'B' is forced 'y' ignoring
>> 'depends on m'.  This should be warned.
>>
>> On the other hand, the following case ('B' is bool) should not be
>> warned, so 'depends on m' for bool symbols should be naturally treated
>> as 'depends on y'.
>>
>> [Test Case2 (not unmet dependency)]
>>
>>   config MODULES
>>   def_bool y
>>   option modules
>>
>>   config A
>>   def_bool y
>>   select B
>>
>>   config B
>>   bool "B"
>>   depends on m
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Changes in v4:
>>   - newly added
>>
>>
>>  scripts/kconfig/symbol.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
>> index 0f7eba7..def860b 100644
>> --- a/scripts/kconfig/symbol.c
>> +++ b/scripts/kconfig/symbol.c
>> @@ -243,7 +243,7 @@ static void sym_calc_visibility(struct symbol *sym)
>>   tri = yes;
>>   if (sym->dir_dep.expr)
>>   tri = expr_calc_value(sym->dir_dep.expr);
>> - if (tri == mod)
>> + if (sym->type == S_BOOLEAN && tri == mod)
>
> This seems to be very close to one of the issues fixed in the old
> v2.6.5 commit 5a87d187fce1 ("[PATCH] config: choice fix") accessible at
> https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?h=5a87d187fce1
>
> IMHO you could probably use (not tested!):
> +   if (tri == mod && sym_get_type(sym) == S_BOOLEAN)
>
> instead of
> +   if (sym->type == S_BOOLEAN && tri == mod)
>
> to be consistent with the rest of sym_calc_visibility().


I tested it, and probably OK.

I will squash the diff.

Thanks.




> Also, since after this commit there will be a great amount of symmetry
> between how dirdep/revdep/weak-revdep are calculated inside
> sym_calc_visibility(), somebody could probably unify the implementations
> in future (not subject of this patch).
>
>>   tri = yes;
>>   if (sym->dir_dep.tri != tri) {
>>   sym->dir_dep.tri = tri;
>> @@ -414,7 +414,7 @@ void sym_calc_value(struct symbol *sym)
>>   }
>>   }
>>   calc_newval:
>> - if (sym->dir_dep.tri == no && sym->rev_dep.tri != no) {
>> + if (sym->dir_dep.tri < sym->rev_dep.tri) {
>
> Looks good.
>
>>   struct expr *e;
>>   e = expr_simplify_unmet_dep(sym->rev_dep.expr,
>>   sym->dir_dep.expr);
>> --
>> 2.7.4
>>
>
> Best regards,
> Eugeniu.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada


Re: [PATCH v4 1/2] kconfig: warn unmet direct dependency of tristate symbols selected by y

2018-03-19 Thread Masahiro Yamada
2018-03-19 7:17 GMT+09:00 Eugeniu Rosca :
> Hi Masahiro,
>
> On Tue, Mar 13, 2018 at 06:56:07PM +0900, Masahiro Yamada wrote:
>> Commit 246cf9c26bf1 ("kbuild: Warn on selecting symbols with unmet
>> direct dependencies") forcibly promoted ->dir_dep.tri to yes from mod.
>> So, the unmet direct dependencies of tristate symbols are not reported.
>>
>> [Test Case]
>>
>>   config MODULES
>>   def_bool y
>>   option modules
>>
>>   config A
>>   def_bool y
>>   select B
>>
>>   config B
>>   tristate "B"
>>   depends on m
>>
>> This causes unmet dependency because 'B' is forced 'y' ignoring
>> 'depends on m'.  This should be warned.
>>
>> On the other hand, the following case ('B' is bool) should not be
>> warned, so 'depends on m' for bool symbols should be naturally treated
>> as 'depends on y'.
>>
>> [Test Case2 (not unmet dependency)]
>>
>>   config MODULES
>>   def_bool y
>>   option modules
>>
>>   config A
>>   def_bool y
>>   select B
>>
>>   config B
>>   bool "B"
>>   depends on m
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Changes in v4:
>>   - newly added
>>
>>
>>  scripts/kconfig/symbol.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
>> index 0f7eba7..def860b 100644
>> --- a/scripts/kconfig/symbol.c
>> +++ b/scripts/kconfig/symbol.c
>> @@ -243,7 +243,7 @@ static void sym_calc_visibility(struct symbol *sym)
>>   tri = yes;
>>   if (sym->dir_dep.expr)
>>   tri = expr_calc_value(sym->dir_dep.expr);
>> - if (tri == mod)
>> + if (sym->type == S_BOOLEAN && tri == mod)
>
> This seems to be very close to one of the issues fixed in the old
> v2.6.5 commit 5a87d187fce1 ("[PATCH] config: choice fix") accessible at
> https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?h=5a87d187fce1
>
> IMHO you could probably use (not tested!):
> +   if (tri == mod && sym_get_type(sym) == S_BOOLEAN)
>
> instead of
> +   if (sym->type == S_BOOLEAN && tri == mod)
>
> to be consistent with the rest of sym_calc_visibility().


I tested it, and probably OK.

I will squash the diff.

Thanks.




> Also, since after this commit there will be a great amount of symmetry
> between how dirdep/revdep/weak-revdep are calculated inside
> sym_calc_visibility(), somebody could probably unify the implementations
> in future (not subject of this patch).
>
>>   tri = yes;
>>   if (sym->dir_dep.tri != tri) {
>>   sym->dir_dep.tri = tri;
>> @@ -414,7 +414,7 @@ void sym_calc_value(struct symbol *sym)
>>   }
>>   }
>>   calc_newval:
>> - if (sym->dir_dep.tri == no && sym->rev_dep.tri != no) {
>> + if (sym->dir_dep.tri < sym->rev_dep.tri) {
>
> Looks good.
>
>>   struct expr *e;
>>   e = expr_simplify_unmet_dep(sym->rev_dep.expr,
>>   sym->dir_dep.expr);
>> --
>> 2.7.4
>>
>
> Best regards,
> Eugeniu.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada


Re: [PATCH v8 01/13] resource: add walk_system_ram_res_rev()

2018-03-19 Thread Baoquan He
On 03/20/18 at 12:12pm, AKASHI Takahiro wrote:
> Baoquan,
> 
> On Tue, Mar 20, 2018 at 09:43:18AM +0800, Baoquan He wrote:
> > On 02/23/18 at 04:36pm, Dave Young wrote:
> > > Hi AKASHI,
> > > 
> > > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote:
> > > > This function, being a variant of walk_system_ram_res() introduced in
> > > > commit 8c86e70acead ("resource: provide new functions to walk through
> > > > resources"), walks through a list of all the resources of System RAM
> > > > in reversed order, i.e., from higher to lower.
> > > > 
> > > > It will be used in kexec_file implementation on arm64.
> > > 
> > > I remember there was an old discussion about this, it should be added
> > > in patch log why this is needed.
> > 
> > It's used to load kernel/initrd at the top of system RAM, and this is
> > consistent with user space kexec behaviour.
> > 
> > In x86 64, Vivek didn't do like this since there's no reverse iomem
> > resource iterating function, he just chose a match RAM region bottom up,
> > then put kernel/initrd top down in the found RAM region. This is
> > different than kexec_tools utility. I am considering to change resource
> > sibling as double list, seems AKASHI's way is easier to be accepted by
> > people. So I will use this one to change x86 64 code.
> > 
> > Hi AKASHI,
> > 
> > About arm64 kexec_file patches, will you post recently? Or any other
> > plan?
> 
> A short answer is yes, but my new version won't include this specific patch.
> So please feel free to add it to your own patch set if you want.
> 
> The reason that I'm going to remove it is that we will make a modification
> on /proc/iomem due to a bug fixing and then we will have to have our own 
> "walking" routine.

I see. Saw your post about the /proc/iomem issue and discussions.

Then I will add this patch in and post a patchset.

Thanks
Baoquan

> 
> 
> > Thanks
> > Baoquan
> > 
> > > 
> > > > 
> > > > Signed-off-by: AKASHI Takahiro 
> > > > Cc: Vivek Goyal 
> > > > Cc: Andrew Morton 
> > > > Cc: Linus Torvalds 
> > > > ---
> > > >  include/linux/ioport.h |  3 +++
> > > >  kernel/resource.c  | 57 
> > > > ++
> > > >  2 files changed, 60 insertions(+)
> > > > 
> > > > diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> > > > index da0ebaec25f0..f12d95fe038b 100644
> > > > --- a/include/linux/ioport.h
> > > > +++ b/include/linux/ioport.h
> > > > @@ -277,6 +277,9 @@ extern int
> > > >  walk_system_ram_res(u64 start, u64 end, void *arg,
> > > > int (*func)(struct resource *, void *));
> > > >  extern int
> > > > +walk_system_ram_res_rev(u64 start, u64 end, void *arg,
> > > > +   int (*func)(struct resource *, void *));
> > > > +extern int
> > > >  walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 
> > > > start, u64 end,
> > > > void *arg, int (*func)(struct resource *, void *));
> > > >  
> > > > diff --git a/kernel/resource.c b/kernel/resource.c
> > > > index e270b5048988..bdaa93407f4c 100644
> > > > --- a/kernel/resource.c
> > > > +++ b/kernel/resource.c
> > > > @@ -23,6 +23,8 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > > +#include 
> > > >  #include 
> > > >  
> > > >  
> > > > @@ -486,6 +488,61 @@ int walk_mem_res(u64 start, u64 end, void *arg,
> > > >  arg, func);
> > > >  }
> > > >  
> > > > +int walk_system_ram_res_rev(u64 start, u64 end, void *arg,
> > > > +   int (*func)(struct resource *, void *))
> > > > +{
> > > > +   struct resource res, *rams;
> > > > +   int rams_size = 16, i;
> > > > +   int ret = -1;
> > > > +
> > > > +   /* create a list */
> > > > +   rams = vmalloc(sizeof(struct resource) * rams_size);
> > > > +   if (!rams)
> > > > +   return ret;
> > > > +
> > > > +   res.start = start;
> > > > +   res.end = end;
> > > > +   res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> > > > +   i = 0;
> > > > +   while ((res.start < res.end) &&
> > > > +   (!find_next_iomem_res(, IORES_DESC_NONE, true))) {
> > > > +   if (i >= rams_size) {
> > > > +   /* re-alloc */
> > > > +   struct resource *rams_new;
> > > > +   int rams_new_size;
> > > > +
> > > > +   rams_new_size = rams_size + 16;
> > > > +   rams_new = vmalloc(sizeof(struct resource)
> > > > +   * 
> > > > rams_new_size);
> > > > +   if (!rams_new)
> > > > +   goto out;
> > > > +
> > > > +   memcpy(rams_new, rams,
> > > > +   sizeof(struct resource) * 
> > > > rams_size);
> > > > +

RE: [PATCH] media: cxd2880-spi: avoid out-of-bounds access warning

2018-03-19 Thread Yasunari.Takiguchi
Hi.

We check the patch. 

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, March 13, 2018 9:09 PM
> To: Takiguchi, Yasunari (SSS); Mauro Carvalho Chehab
> Cc: Arnd Bergmann; Martin Sebor; Matsumoto, Toshihiko (SSS); Yonezawa,
> Kota (SSS); Watanabe, Satoshi (SSS); Yamamoto, Masayuki (SSS);
> linux-me...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] media: cxd2880-spi: avoid out-of-bounds access warning
> 
> The -Warray-bounds warning in gcc-8 triggers for a newly added file:
> 
> drivers/media/spi/cxd2880-spi.c: In function 'cxd2880_write_reg':
> drivers/media/spi/cxd2880-spi.c:111:3: error: 'memcpy' forming offset
> [133, 258] is out of the bounds [0, 132] of object 'send_data' with type
> 'u8[132]' {aka 'unsigned char[132]'} [-Werror=array-bounds]
> 
> The problem appears to be that we have two range checks in this function,
> first comparing against BURST_WRITE_MAX (128) and then comparing against
> a literal '255'. The logic checking the buffer size looks at the second
> one and decides that this might be the actual maximum data length.
> 
> This is understandable behavior from the compiler, but the code is
> actually safe. Since the first check is already shorter, we can remove
> the loop and only leave that. To be on the safe side in case BURST_WRITE_MAX
> might be increased, I'm leaving the check against U8_MAX.
> 
> Fixes: bd24fcddf6b8 ("media: cxd2880-spi: Add support for CXD2880 SPI
> interface")
> Cc: Martin Sebor 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/media/spi/cxd2880-spi.c | 24 +++-
>  1 file changed, 7 insertions(+), 17 deletions(-)

Reviewed-by: Yasunari Takiguchi 




Re: [PATCH v8 01/13] resource: add walk_system_ram_res_rev()

2018-03-19 Thread Baoquan He
On 03/20/18 at 12:12pm, AKASHI Takahiro wrote:
> Baoquan,
> 
> On Tue, Mar 20, 2018 at 09:43:18AM +0800, Baoquan He wrote:
> > On 02/23/18 at 04:36pm, Dave Young wrote:
> > > Hi AKASHI,
> > > 
> > > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote:
> > > > This function, being a variant of walk_system_ram_res() introduced in
> > > > commit 8c86e70acead ("resource: provide new functions to walk through
> > > > resources"), walks through a list of all the resources of System RAM
> > > > in reversed order, i.e., from higher to lower.
> > > > 
> > > > It will be used in kexec_file implementation on arm64.
> > > 
> > > I remember there was an old discussion about this, it should be added
> > > in patch log why this is needed.
> > 
> > It's used to load kernel/initrd at the top of system RAM, and this is
> > consistent with user space kexec behaviour.
> > 
> > In x86 64, Vivek didn't do like this since there's no reverse iomem
> > resource iterating function, he just chose a match RAM region bottom up,
> > then put kernel/initrd top down in the found RAM region. This is
> > different than kexec_tools utility. I am considering to change resource
> > sibling as double list, seems AKASHI's way is easier to be accepted by
> > people. So I will use this one to change x86 64 code.
> > 
> > Hi AKASHI,
> > 
> > About arm64 kexec_file patches, will you post recently? Or any other
> > plan?
> 
> A short answer is yes, but my new version won't include this specific patch.
> So please feel free to add it to your own patch set if you want.
> 
> The reason that I'm going to remove it is that we will make a modification
> on /proc/iomem due to a bug fixing and then we will have to have our own 
> "walking" routine.

I see. Saw your post about the /proc/iomem issue and discussions.

Then I will add this patch in and post a patchset.

Thanks
Baoquan

> 
> 
> > Thanks
> > Baoquan
> > 
> > > 
> > > > 
> > > > Signed-off-by: AKASHI Takahiro 
> > > > Cc: Vivek Goyal 
> > > > Cc: Andrew Morton 
> > > > Cc: Linus Torvalds 
> > > > ---
> > > >  include/linux/ioport.h |  3 +++
> > > >  kernel/resource.c  | 57 
> > > > ++
> > > >  2 files changed, 60 insertions(+)
> > > > 
> > > > diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> > > > index da0ebaec25f0..f12d95fe038b 100644
> > > > --- a/include/linux/ioport.h
> > > > +++ b/include/linux/ioport.h
> > > > @@ -277,6 +277,9 @@ extern int
> > > >  walk_system_ram_res(u64 start, u64 end, void *arg,
> > > > int (*func)(struct resource *, void *));
> > > >  extern int
> > > > +walk_system_ram_res_rev(u64 start, u64 end, void *arg,
> > > > +   int (*func)(struct resource *, void *));
> > > > +extern int
> > > >  walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 
> > > > start, u64 end,
> > > > void *arg, int (*func)(struct resource *, void *));
> > > >  
> > > > diff --git a/kernel/resource.c b/kernel/resource.c
> > > > index e270b5048988..bdaa93407f4c 100644
> > > > --- a/kernel/resource.c
> > > > +++ b/kernel/resource.c
> > > > @@ -23,6 +23,8 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > > +#include 
> > > >  #include 
> > > >  
> > > >  
> > > > @@ -486,6 +488,61 @@ int walk_mem_res(u64 start, u64 end, void *arg,
> > > >  arg, func);
> > > >  }
> > > >  
> > > > +int walk_system_ram_res_rev(u64 start, u64 end, void *arg,
> > > > +   int (*func)(struct resource *, void *))
> > > > +{
> > > > +   struct resource res, *rams;
> > > > +   int rams_size = 16, i;
> > > > +   int ret = -1;
> > > > +
> > > > +   /* create a list */
> > > > +   rams = vmalloc(sizeof(struct resource) * rams_size);
> > > > +   if (!rams)
> > > > +   return ret;
> > > > +
> > > > +   res.start = start;
> > > > +   res.end = end;
> > > > +   res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> > > > +   i = 0;
> > > > +   while ((res.start < res.end) &&
> > > > +   (!find_next_iomem_res(, IORES_DESC_NONE, true))) {
> > > > +   if (i >= rams_size) {
> > > > +   /* re-alloc */
> > > > +   struct resource *rams_new;
> > > > +   int rams_new_size;
> > > > +
> > > > +   rams_new_size = rams_size + 16;
> > > > +   rams_new = vmalloc(sizeof(struct resource)
> > > > +   * 
> > > > rams_new_size);
> > > > +   if (!rams_new)
> > > > +   goto out;
> > > > +
> > > > +   memcpy(rams_new, rams,
> > > > +   sizeof(struct resource) * 
> > > > rams_size);
> > > > +   vfree(rams);
> > > > +   rams = rams_new;
> > > > +   

RE: [PATCH] media: cxd2880-spi: avoid out-of-bounds access warning

2018-03-19 Thread Yasunari.Takiguchi
Hi.

We check the patch. 

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, March 13, 2018 9:09 PM
> To: Takiguchi, Yasunari (SSS); Mauro Carvalho Chehab
> Cc: Arnd Bergmann; Martin Sebor; Matsumoto, Toshihiko (SSS); Yonezawa,
> Kota (SSS); Watanabe, Satoshi (SSS); Yamamoto, Masayuki (SSS);
> linux-me...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] media: cxd2880-spi: avoid out-of-bounds access warning
> 
> The -Warray-bounds warning in gcc-8 triggers for a newly added file:
> 
> drivers/media/spi/cxd2880-spi.c: In function 'cxd2880_write_reg':
> drivers/media/spi/cxd2880-spi.c:111:3: error: 'memcpy' forming offset
> [133, 258] is out of the bounds [0, 132] of object 'send_data' with type
> 'u8[132]' {aka 'unsigned char[132]'} [-Werror=array-bounds]
> 
> The problem appears to be that we have two range checks in this function,
> first comparing against BURST_WRITE_MAX (128) and then comparing against
> a literal '255'. The logic checking the buffer size looks at the second
> one and decides that this might be the actual maximum data length.
> 
> This is understandable behavior from the compiler, but the code is
> actually safe. Since the first check is already shorter, we can remove
> the loop and only leave that. To be on the safe side in case BURST_WRITE_MAX
> might be increased, I'm leaving the check against U8_MAX.
> 
> Fixes: bd24fcddf6b8 ("media: cxd2880-spi: Add support for CXD2880 SPI
> interface")
> Cc: Martin Sebor 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/media/spi/cxd2880-spi.c | 24 +++-
>  1 file changed, 7 insertions(+), 17 deletions(-)

Reviewed-by: Yasunari Takiguchi 




Re: [PATCH v2 1/3] dt-bindings: pinctrl: Add a reserved-gpio-ranges property

2018-03-19 Thread Timur Tabi

On 3/19/18 10:36 PM, Linus Walleij wrote:

This looks fine except Andy's note to rename this ranges
to gpio-reserved-ranges for namespacing.

Are you reposting this series as v3 with this fixed or does someone
else need to pick it up?


I will pick this up if Stephen wants me to.

--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.


Re: [PATCH v2 1/3] dt-bindings: pinctrl: Add a reserved-gpio-ranges property

2018-03-19 Thread Timur Tabi

On 3/19/18 10:36 PM, Linus Walleij wrote:

This looks fine except Andy's note to rename this ranges
to gpio-reserved-ranges for namespacing.

Are you reposting this series as v3 with this fixed or does someone
else need to pick it up?


I will pick this up if Stephen wants me to.

--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.


Re: [PATCH] x86/vsyscall/64: Use proper accessor to update p4d entry

2018-03-19 Thread Andy Lutomirski
On Mon, Mar 19, 2018 at 2:31 PM, Boris Ostrovsky
 wrote:
> Writing to it directly does not work for Xen PV guests.

Whoops, my bad.

Acked-by: Andy Lutomirski 

>
> Signed-off-by: Boris Ostrovsky 
> ---
>  arch/x86/entry/vsyscall/vsyscall_64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c 
> b/arch/x86/entry/vsyscall/vsyscall_64.c
> index 8560ef68a9d6..317be365bce3 100644
> --- a/arch/x86/entry/vsyscall/vsyscall_64.c
> +++ b/arch/x86/entry/vsyscall/vsyscall_64.c
> @@ -347,7 +347,7 @@ void __init set_vsyscall_pgtable_user_bits(pgd_t *root)
> set_pgd(pgd, __pgd(pgd_val(*pgd) | _PAGE_USER));
> p4d = p4d_offset(pgd, VSYSCALL_ADDR);
>  #if CONFIG_PGTABLE_LEVELS >= 5
> -   p4d->p4d |= _PAGE_USER;
> +   set_p4d(p4d, __p4d(p4d_val(*p4d) | _PAGE_USER));
>  #endif
> pud = pud_offset(p4d, VSYSCALL_ADDR);
> set_pud(pud, __pud(pud_val(*pud) | _PAGE_USER));
> --
> 2.14.3
>


Re: [PATCH] x86/vsyscall/64: Use proper accessor to update p4d entry

2018-03-19 Thread Andy Lutomirski
On Mon, Mar 19, 2018 at 2:31 PM, Boris Ostrovsky
 wrote:
> Writing to it directly does not work for Xen PV guests.

Whoops, my bad.

Acked-by: Andy Lutomirski 

>
> Signed-off-by: Boris Ostrovsky 
> ---
>  arch/x86/entry/vsyscall/vsyscall_64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c 
> b/arch/x86/entry/vsyscall/vsyscall_64.c
> index 8560ef68a9d6..317be365bce3 100644
> --- a/arch/x86/entry/vsyscall/vsyscall_64.c
> +++ b/arch/x86/entry/vsyscall/vsyscall_64.c
> @@ -347,7 +347,7 @@ void __init set_vsyscall_pgtable_user_bits(pgd_t *root)
> set_pgd(pgd, __pgd(pgd_val(*pgd) | _PAGE_USER));
> p4d = p4d_offset(pgd, VSYSCALL_ADDR);
>  #if CONFIG_PGTABLE_LEVELS >= 5
> -   p4d->p4d |= _PAGE_USER;
> +   set_p4d(p4d, __p4d(p4d_val(*p4d) | _PAGE_USER));
>  #endif
> pud = pud_offset(p4d, VSYSCALL_ADDR);
> set_pud(pud, __pud(pud_val(*pud) | _PAGE_USER));
> --
> 2.14.3
>


Re: [PATCH 14/19] csky: Misc headers

2018-03-19 Thread Guo Ren
Hi Arnd,

On Tue, Mar 20, 2018 at 12:11:24AM +0800, Arnd Bergmann wrote:
> On Mon, Mar 19, 2018 at 3:51 AM, Guo Ren  wrote:
> > +++ b/arch/csky/include/uapi/asm/fcntl.h
> > @@ -0,0 +1,13 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +#ifndef __ASM_CSKY_FCNTL_H
> > +#define __ASM_CSKY_FCNTL_H
> > +
> > +#define O_DIRECTORY04
> > +#define O_NOFOLLOW 010
> > +#define O_DIRECT   020
> > +#define O_LARGEFILE040
> > +
> > +#include 
> 
> This should just use the generic file without overrides: Please don't diverge
> from the generic syscall ABI.
>

It's a stupid copy from arm/include/uapi/asm/fcntl.h and the csky/bits/fcntl.h
in uclibc-ng and glibc are also defined with:

#define __O_DIRECTORY04 /* Must be a directory.  */
#define __O_NOFOLLOW010 /* Do not follow links.  */
#define __O_DIRECT  020 /* Direct disk access.  */
#define __O_LARGEFILE   040

So may I keep it for a while?
(I will let glibc uclibc-ng csky/bits/fcntl.h include the linux/uapi/asm/fcntl.h
first.)


> > +struct __old_kernel_stat {
> > +   unsigned short st_dev;
> 
> Same here: no need for __old_kernel_stat  or the headers on new architectures.
>
OK

Best Regards
  Guo Ren


Re: [PATCH v2 1/3] dt-bindings: pinctrl: Add a reserved-gpio-ranges property

2018-03-19 Thread Linus Walleij
Hi Stephen,

thanks for the patch and hope you have a good time at your new
workplace!

On Fri, Jan 26, 2018 at 2:13 AM, Stephen Boyd  wrote:

> Some qcom platforms make some GPIOs or pins unavailable for use
> by non-secure operating systems, and thus reading or writing the
> registers for those pins will cause access control issues.
> Introduce a DT property to describe the set of GPIOs that are
> available for use so that higher level OSes are able to know what
> pins to avoid reading/writing.
>
> Cc: Grant Likely 
> Cc: 
> Signed-off-by: Stephen Boyd 

This looks fine except Andy's note to rename this ranges
to gpio-reserved-ranges for namespacing.

Are you reposting this series as v3 with this fixed or does someone
else need to pick it up?

Yours,
Linus Walleij


Re: [PATCH 14/19] csky: Misc headers

2018-03-19 Thread Guo Ren
Hi Arnd,

On Tue, Mar 20, 2018 at 12:11:24AM +0800, Arnd Bergmann wrote:
> On Mon, Mar 19, 2018 at 3:51 AM, Guo Ren  wrote:
> > +++ b/arch/csky/include/uapi/asm/fcntl.h
> > @@ -0,0 +1,13 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> > +#ifndef __ASM_CSKY_FCNTL_H
> > +#define __ASM_CSKY_FCNTL_H
> > +
> > +#define O_DIRECTORY04
> > +#define O_NOFOLLOW 010
> > +#define O_DIRECT   020
> > +#define O_LARGEFILE040
> > +
> > +#include 
> 
> This should just use the generic file without overrides: Please don't diverge
> from the generic syscall ABI.
>

It's a stupid copy from arm/include/uapi/asm/fcntl.h and the csky/bits/fcntl.h
in uclibc-ng and glibc are also defined with:

#define __O_DIRECTORY04 /* Must be a directory.  */
#define __O_NOFOLLOW010 /* Do not follow links.  */
#define __O_DIRECT  020 /* Direct disk access.  */
#define __O_LARGEFILE   040

So may I keep it for a while?
(I will let glibc uclibc-ng csky/bits/fcntl.h include the linux/uapi/asm/fcntl.h
first.)


> > +struct __old_kernel_stat {
> > +   unsigned short st_dev;
> 
> Same here: no need for __old_kernel_stat  or the headers on new architectures.
>
OK

Best Regards
  Guo Ren


Re: [PATCH v2 1/3] dt-bindings: pinctrl: Add a reserved-gpio-ranges property

2018-03-19 Thread Linus Walleij
Hi Stephen,

thanks for the patch and hope you have a good time at your new
workplace!

On Fri, Jan 26, 2018 at 2:13 AM, Stephen Boyd  wrote:

> Some qcom platforms make some GPIOs or pins unavailable for use
> by non-secure operating systems, and thus reading or writing the
> registers for those pins will cause access control issues.
> Introduce a DT property to describe the set of GPIOs that are
> available for use so that higher level OSes are able to know what
> pins to avoid reading/writing.
>
> Cc: Grant Likely 
> Cc: 
> Signed-off-by: Stephen Boyd 

This looks fine except Andy's note to rename this ranges
to gpio-reserved-ranges for namespacing.

Are you reposting this series as v3 with this fixed or does someone
else need to pick it up?

Yours,
Linus Walleij


Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

2018-03-19 Thread Alexey Roslyakov
Arend,
I use RK3288-firefly, bcm4339 (ap6335).

Regards,
  Alex

On 20 March 2018 at 06:16, Arend van Spriel
 wrote:
> + Uffe
>
> On 3/19/2018 6:55 PM, Florian Fainelli wrote:
>>
>> On 03/19/2018 07:10 AM, Alexey Roslyakov wrote:
>>>
>>> Hi Arend,
>>> I appreciate your response. In my opinion, it has nothing to do with
>>> SDIO host, because it defines "quirks" in the driver itself.
>>
>>
>> It is not clear to me from your patch series whether the problem is that:
>>
>> - the SDIO device has a specific alignment requirements, which would be
>> either a SDIO device driver limitation/issue or maybe the underlying
>> hardware device/firmware requiring that
>>
>> - the SDIO host controller used is not capable of coping nicely with
>> these said limitations
>>
>> It seems to me like what you are doing here is a) applicable to possibly
>> more SDIO devices and host combinations, and b) should likely be done at
>> the layer between the host and device, such that it is available to more
>> combinations.
>
>
> Indeed. That was my thought exactly and I can not imagine Uffe would push
> back on that reasoning.
>
>>> If I get it right, you mean something like this:
>>>
>>> mmc3: mmc@1c12000 {
>>> ...
>>>  broken-sg-support;
>>>  sd-head-align = 4;
>>>  sd-sgentry-align = 512;
>>>
>>>  brcmf: wifi@1 {
>>>  ...
>>>  };
>>> };
>>>
>>> Where dt: bindings documentation for these entries should reside?
>>> In generic MMC bindings? Well, this is the very special case and
>>> mmc-linux maintainer will unlikely to accept these changes.
>>> Also, extra kernel code modification might be required. It could make
>>> quite trivial change much more complex.
>>
>>
>> If the MMC maintainers are not copied on this patch series, it will
>> likely be hard for them to identify this patch series and chime in...
>
>
> The main question is whether this is indeed a "very special case" as Alexey
> claims it to be or that it is likely to be applicable to other device and
> host combinations as you are suggesting.
>
> If these properties are imposed by the host or host controller it would make
> sense to have these in the mmc bindings.
>
>>>
 Also I am not sure if the broken-sg-support is still needed. We added
 that for omap_hsmmc, but that has since changed to scatter-gather emulation
 so it might not be needed anymore.
>>>
>>>
>>> I've experienced the problem with rk3288 (dw-mmc host) and sdio
>>> settings like above solved it.
>>> Frankly, I haven't investigated any deeper which one of the settings
>>> helped in my case yet...
>>> I will try to get rid of broken-sg-support first and let you know if
>>> it does make any difference.
>
>
> Are you using some chromebook. I have some lying around here so I could also
> look into it. What broadcom chipset do you have?
>
> Regards,
> Arend
>
>
>>> All the best,
>>>Alex.
>>>
>>> On 19 March 2018 at 16:31, Arend van Spriel
>>>  wrote:

 On 3/19/2018 2:40 AM, Alexey Roslyakov wrote:
>
>
> In case if the host has higher align requirements for SG items, allow
> setting device-specific aligns for scatterlist items.
>
> Signed-off-by: Alexey Roslyakov 
> ---
>Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> | 5
> +
>1 file changed, 5 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> index 86602f264dce..187b8c1b52a7 100644
> ---
> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> +++
> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> @@ -17,6 +17,11 @@ Optional properties:
>  When not specified the device will use in-band SDIO
> interrupts.
> - interrupt-names : name of the out-of-band interrupt, which must
> be
> set
>  to "host-wake".
> + - brcm,broken-sg-support : boolean flag to indicate that the SDIO
> host
> +   controller has higher align requirement than 32 bytes for each
> +   scatterlist item.
> + - brcm,sd-head-align : alignment requirement for start of data
> buffer.
> + - brcm,sd-sgentry-align : length alignment requirement for each sg
> entry.



 Hi Alexey,

 Thanks for the patch. However, the problem with these is that they are
 characterizing the host controller and not the wireless device. So from
 device tree perspective , which is to describe the hardware, these
 properties should be SDIO host controller properties. Also I am not sure
 if
 the broken-sg-support is still needed. We added that for omap_hsmmc, but
 that has since changed to scatter-gather emulation so it might not be
 needed
 

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

2018-03-19 Thread Alexey Roslyakov
Arend,
I use RK3288-firefly, bcm4339 (ap6335).

Regards,
  Alex

On 20 March 2018 at 06:16, Arend van Spriel
 wrote:
> + Uffe
>
> On 3/19/2018 6:55 PM, Florian Fainelli wrote:
>>
>> On 03/19/2018 07:10 AM, Alexey Roslyakov wrote:
>>>
>>> Hi Arend,
>>> I appreciate your response. In my opinion, it has nothing to do with
>>> SDIO host, because it defines "quirks" in the driver itself.
>>
>>
>> It is not clear to me from your patch series whether the problem is that:
>>
>> - the SDIO device has a specific alignment requirements, which would be
>> either a SDIO device driver limitation/issue or maybe the underlying
>> hardware device/firmware requiring that
>>
>> - the SDIO host controller used is not capable of coping nicely with
>> these said limitations
>>
>> It seems to me like what you are doing here is a) applicable to possibly
>> more SDIO devices and host combinations, and b) should likely be done at
>> the layer between the host and device, such that it is available to more
>> combinations.
>
>
> Indeed. That was my thought exactly and I can not imagine Uffe would push
> back on that reasoning.
>
>>> If I get it right, you mean something like this:
>>>
>>> mmc3: mmc@1c12000 {
>>> ...
>>>  broken-sg-support;
>>>  sd-head-align = 4;
>>>  sd-sgentry-align = 512;
>>>
>>>  brcmf: wifi@1 {
>>>  ...
>>>  };
>>> };
>>>
>>> Where dt: bindings documentation for these entries should reside?
>>> In generic MMC bindings? Well, this is the very special case and
>>> mmc-linux maintainer will unlikely to accept these changes.
>>> Also, extra kernel code modification might be required. It could make
>>> quite trivial change much more complex.
>>
>>
>> If the MMC maintainers are not copied on this patch series, it will
>> likely be hard for them to identify this patch series and chime in...
>
>
> The main question is whether this is indeed a "very special case" as Alexey
> claims it to be or that it is likely to be applicable to other device and
> host combinations as you are suggesting.
>
> If these properties are imposed by the host or host controller it would make
> sense to have these in the mmc bindings.
>
>>>
 Also I am not sure if the broken-sg-support is still needed. We added
 that for omap_hsmmc, but that has since changed to scatter-gather emulation
 so it might not be needed anymore.
>>>
>>>
>>> I've experienced the problem with rk3288 (dw-mmc host) and sdio
>>> settings like above solved it.
>>> Frankly, I haven't investigated any deeper which one of the settings
>>> helped in my case yet...
>>> I will try to get rid of broken-sg-support first and let you know if
>>> it does make any difference.
>
>
> Are you using some chromebook. I have some lying around here so I could also
> look into it. What broadcom chipset do you have?
>
> Regards,
> Arend
>
>
>>> All the best,
>>>Alex.
>>>
>>> On 19 March 2018 at 16:31, Arend van Spriel
>>>  wrote:

 On 3/19/2018 2:40 AM, Alexey Roslyakov wrote:
>
>
> In case if the host has higher align requirements for SG items, allow
> setting device-specific aligns for scatterlist items.
>
> Signed-off-by: Alexey Roslyakov 
> ---
>Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> | 5
> +
>1 file changed, 5 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> index 86602f264dce..187b8c1b52a7 100644
> ---
> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> +++
> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> @@ -17,6 +17,11 @@ Optional properties:
>  When not specified the device will use in-band SDIO
> interrupts.
> - interrupt-names : name of the out-of-band interrupt, which must
> be
> set
>  to "host-wake".
> + - brcm,broken-sg-support : boolean flag to indicate that the SDIO
> host
> +   controller has higher align requirement than 32 bytes for each
> +   scatterlist item.
> + - brcm,sd-head-align : alignment requirement for start of data
> buffer.
> + - brcm,sd-sgentry-align : length alignment requirement for each sg
> entry.



 Hi Alexey,

 Thanks for the patch. However, the problem with these is that they are
 characterizing the host controller and not the wireless device. So from
 device tree perspective , which is to describe the hardware, these
 properties should be SDIO host controller properties. Also I am not sure
 if
 the broken-sg-support is still needed. We added that for omap_hsmmc, but
 that has since changed to scatter-gather emulation so it might not be
 needed
 anymore.

 Regards,
 Arend
>>>
>>>
>>>
>>>
>>
>>
>



-- 
With best regards,
  

Re: [PATCH 13/36] fs: introduce new ->get_poll_head and ->poll_mask methods

2018-03-19 Thread Darrick J. Wong
On Mon, Mar 05, 2018 at 01:27:20PM -0800, Christoph Hellwig wrote:
> ->get_poll_head returns the waitqueue that the poll operation is going
> to sleep on.  Note that this means we can only use a single waitqueue
> for the poll, unlike some current drivers that use two waitqueues for
> different events.  But now that we have keyed wakeups and heavily use
> those for poll there aren't that many good reason left to keep the
> multiple waitqueues, and if there are any ->poll is still around, the
> driver just won't support aio poll.
> 
> Signed-off-by: Christoph Hellwig 

I've been wondering, how does a regular filesystem connect with this?
Also, does anything implement get_poll_head?  It looks to me like an aio
poll provider has to provide both...

--D

> ---
>  Documentation/filesystems/Locking |  7 ++-
>  Documentation/filesystems/vfs.txt | 13 +
>  fs/select.c   | 28 
>  include/linux/fs.h|  2 ++
>  include/linux/poll.h  | 27 +++
>  5 files changed, 72 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/filesystems/Locking 
> b/Documentation/filesystems/Locking
> index 220bba28f72b..6d227f9d7bd9 100644
> --- a/Documentation/filesystems/Locking
> +++ b/Documentation/filesystems/Locking
> @@ -440,6 +440,8 @@ prototypes:
>   ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
>   int (*iterate) (struct file *, struct dir_context *);
>   __poll_t (*poll) (struct file *, struct poll_table_struct *);
> + struct wait_queue_head * (*get_poll_head)(struct file *, __poll_t);
> + __poll_t (*poll_mask) (struct file *, __poll_t);
>   long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
>   long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
>   int (*mmap) (struct file *, struct vm_area_struct *);
> @@ -470,7 +472,7 @@ prototypes:
>  };
>  
>  locking rules:
> - All may block.
> + All except for ->poll_mask may block.
>  
>  ->llseek() locking has moved from llseek to the individual llseek
>  implementations.  If your fs is not using generic_file_llseek, you
> @@ -498,6 +500,9 @@ in sys_read() and friends.
>  the lease within the individual filesystem to record the result of the
>  operation
>  
> +->poll_mask can be called with or without the waitqueue lock for the 
> waitqueue
> +returned from ->get_poll_head.
> +
>  --- dquot_operations ---
>  prototypes:
>   int (*write_dquot) (struct dquot *);
> diff --git a/Documentation/filesystems/vfs.txt 
> b/Documentation/filesystems/vfs.txt
> index f608180ad59d..50ee13563271 100644
> --- a/Documentation/filesystems/vfs.txt
> +++ b/Documentation/filesystems/vfs.txt
> @@ -857,6 +857,8 @@ struct file_operations {
>   ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
>   int (*iterate) (struct file *, struct dir_context *);
>   __poll_t (*poll) (struct file *, struct poll_table_struct *);
> + struct wait_queue_head * (*get_poll_head)(struct file *, __poll_t);
> + __poll_t (*poll_mask) (struct file *, __poll_t);
>   long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
>   long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
>   int (*mmap) (struct file *, struct vm_area_struct *);
> @@ -901,6 +903,17 @@ otherwise noted.
>   activity on this file and (optionally) go to sleep until there
>   is activity. Called by the select(2) and poll(2) system calls
>  
> +  get_poll_head: Returns the struct wait_queue_head that poll, select,
> +  epoll or aio poll should wait on in case this instance only has single
> +  waitqueue.  Can return NULL to indicate polling is not supported,
> +  or a POLL* value using the POLL_TO_PTR helper in case a grave error
> +  occured and ->poll_mask shall not be called.
> +
> +  poll_mask: return the mask of POLL* values describing the file descriptor
> +  state.  Called either before going to sleep on the waitqueue returned by
> +  get_poll_head, or after it has been woken.  If ->get_poll_head and
> +  ->poll_mask are implemented ->poll does not need to be implement.
> +
>unlocked_ioctl: called by the ioctl(2) system call.
>  
>compat_ioctl: called by the ioctl(2) system call when 32 bit system calls
> diff --git a/fs/select.c b/fs/select.c
> index ba91103707ea..cc270d7f6192 100644
> --- a/fs/select.c
> +++ b/fs/select.c
> @@ -34,6 +34,34 @@
>  
>  #include 
>  
> +__poll_t vfs_poll(struct file *file, struct poll_table_struct *pt)
> +{
> + unsigned int events = poll_requested_events(pt);
> + struct wait_queue_head *head;
> +
> + if (unlikely(!file_can_poll(file)))
> + return DEFAULT_POLLMASK;
> +
> + if (file->f_op->poll)
> + return file->f_op->poll(file, pt);
> +
> + /*
> +  * Only get the poll head and do the first mask check if we are actually
> +  * 

Re: [PATCH 13/36] fs: introduce new ->get_poll_head and ->poll_mask methods

2018-03-19 Thread Darrick J. Wong
On Mon, Mar 05, 2018 at 01:27:20PM -0800, Christoph Hellwig wrote:
> ->get_poll_head returns the waitqueue that the poll operation is going
> to sleep on.  Note that this means we can only use a single waitqueue
> for the poll, unlike some current drivers that use two waitqueues for
> different events.  But now that we have keyed wakeups and heavily use
> those for poll there aren't that many good reason left to keep the
> multiple waitqueues, and if there are any ->poll is still around, the
> driver just won't support aio poll.
> 
> Signed-off-by: Christoph Hellwig 

I've been wondering, how does a regular filesystem connect with this?
Also, does anything implement get_poll_head?  It looks to me like an aio
poll provider has to provide both...

--D

> ---
>  Documentation/filesystems/Locking |  7 ++-
>  Documentation/filesystems/vfs.txt | 13 +
>  fs/select.c   | 28 
>  include/linux/fs.h|  2 ++
>  include/linux/poll.h  | 27 +++
>  5 files changed, 72 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/filesystems/Locking 
> b/Documentation/filesystems/Locking
> index 220bba28f72b..6d227f9d7bd9 100644
> --- a/Documentation/filesystems/Locking
> +++ b/Documentation/filesystems/Locking
> @@ -440,6 +440,8 @@ prototypes:
>   ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
>   int (*iterate) (struct file *, struct dir_context *);
>   __poll_t (*poll) (struct file *, struct poll_table_struct *);
> + struct wait_queue_head * (*get_poll_head)(struct file *, __poll_t);
> + __poll_t (*poll_mask) (struct file *, __poll_t);
>   long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
>   long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
>   int (*mmap) (struct file *, struct vm_area_struct *);
> @@ -470,7 +472,7 @@ prototypes:
>  };
>  
>  locking rules:
> - All may block.
> + All except for ->poll_mask may block.
>  
>  ->llseek() locking has moved from llseek to the individual llseek
>  implementations.  If your fs is not using generic_file_llseek, you
> @@ -498,6 +500,9 @@ in sys_read() and friends.
>  the lease within the individual filesystem to record the result of the
>  operation
>  
> +->poll_mask can be called with or without the waitqueue lock for the 
> waitqueue
> +returned from ->get_poll_head.
> +
>  --- dquot_operations ---
>  prototypes:
>   int (*write_dquot) (struct dquot *);
> diff --git a/Documentation/filesystems/vfs.txt 
> b/Documentation/filesystems/vfs.txt
> index f608180ad59d..50ee13563271 100644
> --- a/Documentation/filesystems/vfs.txt
> +++ b/Documentation/filesystems/vfs.txt
> @@ -857,6 +857,8 @@ struct file_operations {
>   ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
>   int (*iterate) (struct file *, struct dir_context *);
>   __poll_t (*poll) (struct file *, struct poll_table_struct *);
> + struct wait_queue_head * (*get_poll_head)(struct file *, __poll_t);
> + __poll_t (*poll_mask) (struct file *, __poll_t);
>   long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
>   long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
>   int (*mmap) (struct file *, struct vm_area_struct *);
> @@ -901,6 +903,17 @@ otherwise noted.
>   activity on this file and (optionally) go to sleep until there
>   is activity. Called by the select(2) and poll(2) system calls
>  
> +  get_poll_head: Returns the struct wait_queue_head that poll, select,
> +  epoll or aio poll should wait on in case this instance only has single
> +  waitqueue.  Can return NULL to indicate polling is not supported,
> +  or a POLL* value using the POLL_TO_PTR helper in case a grave error
> +  occured and ->poll_mask shall not be called.
> +
> +  poll_mask: return the mask of POLL* values describing the file descriptor
> +  state.  Called either before going to sleep on the waitqueue returned by
> +  get_poll_head, or after it has been woken.  If ->get_poll_head and
> +  ->poll_mask are implemented ->poll does not need to be implement.
> +
>unlocked_ioctl: called by the ioctl(2) system call.
>  
>compat_ioctl: called by the ioctl(2) system call when 32 bit system calls
> diff --git a/fs/select.c b/fs/select.c
> index ba91103707ea..cc270d7f6192 100644
> --- a/fs/select.c
> +++ b/fs/select.c
> @@ -34,6 +34,34 @@
>  
>  #include 
>  
> +__poll_t vfs_poll(struct file *file, struct poll_table_struct *pt)
> +{
> + unsigned int events = poll_requested_events(pt);
> + struct wait_queue_head *head;
> +
> + if (unlikely(!file_can_poll(file)))
> + return DEFAULT_POLLMASK;
> +
> + if (file->f_op->poll)
> + return file->f_op->poll(file, pt);
> +
> + /*
> +  * Only get the poll head and do the first mask check if we are actually
> +  * going to 

Re: [PATCH] scsi: iscsi_tcp: set BDI_CAP_STABLE_WRITES when data digest enabled

2018-03-19 Thread Martin K. Petersen

Jianchao,

> iscsi tcp will first send out data, then calculate and send data
> digest. If we don't have BDI_CAP_STABLE_WRITES, the page cache will
> be written in spite of the on going writeback. Consequently, wrong
> digest will be got and sent to target.
>
> To fix this, set BDI_CAP_STABLE_WRITES when data digest is enabled
> in iscsi_tcp .slave_configure callback.

Applied to 4.16/scsi-fixes. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] scsi: iscsi_tcp: set BDI_CAP_STABLE_WRITES when data digest enabled

2018-03-19 Thread Martin K. Petersen

Jianchao,

> iscsi tcp will first send out data, then calculate and send data
> digest. If we don't have BDI_CAP_STABLE_WRITES, the page cache will
> be written in spite of the on going writeback. Consequently, wrong
> digest will be got and sent to target.
>
> To fix this, set BDI_CAP_STABLE_WRITES when data digest is enabled
> in iscsi_tcp .slave_configure callback.

Applied to 4.16/scsi-fixes. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


[PATCH v5 3/3] Bluetooth: hci_qca: Add serdev support

2018-03-19 Thread Thierry Escande
Add support for Qualcomm serial slave devices. Probe the serial device,
retrieve its maximum speed and register a new hci uart device.

Signed-off-by: Thierry Escande 
---

v5:
- Use gpio new name 'enable'

v4:
- Rename divclk4 as susclk (its name in the bt chip)
- Use gpiod_set_value_cansleep()
- Replace #include  with 
- Restore dependency on BT_HCIUART

v3:
- Remove redundant call to gpiod_set_value() after devm_gpiod_get()
- Check returned values for clk_set_rate() and clk_prepare_enable()
- Use clk_disable_unprepare()

v2:
- Fix author email

 drivers/bluetooth/Kconfig   |   1 +
 drivers/bluetooth/hci_qca.c | 109 +++-
 2 files changed, 108 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 07e55cd8f8c8..e0f1a6609b68 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -196,6 +196,7 @@ config BT_HCIUART_BCM
 config BT_HCIUART_QCA
bool "Qualcomm Atheros protocol support"
depends on BT_HCIUART
+   depends on BT_HCIUART_SERDEV
select BT_HCIUART_H4
select BT_QCA
help
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 05ec530b8a3a..6e6042f77784 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -29,7 +29,11 @@
  */
 
 #include 
+#include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -50,6 +54,9 @@
 #define IBS_TX_IDLE_TIMEOUT_MS 2000
 #define BAUDRATE_SETTLE_TIMEOUT_MS 300
 
+/* susclk rate */
+#define SUSCLK_RATE_32KHZ  32768
+
 /* HCI_IBS transmit side sleep protocol states */
 enum tx_ibs_states {
HCI_IBS_TX_ASLEEP,
@@ -111,6 +118,12 @@ struct qca_data {
u64 votes_off;
 };
 
+struct qca_serdev {
+   struct hci_uart  serdev_hu;
+   struct gpio_desc *bt_en;
+   struct clk   *susclk;
+};
+
 static void __serial_clock_on(struct tty_struct *tty)
 {
/* TODO: Some chipset requires to enable UART clock on client
@@ -386,6 +399,7 @@ static void hci_ibs_wake_retrans_timeout(struct timer_list 
*t)
 /* Initialize protocol */
 static int qca_open(struct hci_uart *hu)
 {
+   struct qca_serdev *qcadev;
struct qca_data *qca;
 
BT_DBG("hu %p qca_open", hu);
@@ -444,6 +458,13 @@ static int qca_open(struct hci_uart *hu)
timer_setup(>tx_idle_timer, hci_ibs_tx_idle_timeout, 0);
qca->tx_idle_delay = IBS_TX_IDLE_TIMEOUT_MS;
 
+   if (hu->serdev) {
+   serdev_device_open(hu->serdev);
+
+   qcadev = serdev_device_get_drvdata(hu->serdev);
+   gpiod_set_value_cansleep(qcadev->bt_en, 1);
+   }
+
BT_DBG("HCI_UART_QCA open, tx_idle_delay=%u, wake_retrans=%u",
   qca->tx_idle_delay, qca->wake_retrans);
 
@@ -512,6 +533,7 @@ static int qca_flush(struct hci_uart *hu)
 /* Close protocol */
 static int qca_close(struct hci_uart *hu)
 {
+   struct qca_serdev *qcadev;
struct qca_data *qca = hu->priv;
 
BT_DBG("hu %p qca close", hu);
@@ -525,6 +547,13 @@ static int qca_close(struct hci_uart *hu)
destroy_workqueue(qca->workqueue);
qca->hu = NULL;
 
+   if (hu->serdev) {
+   serdev_device_close(hu->serdev);
+
+   qcadev = serdev_device_get_drvdata(hu->serdev);
+   gpiod_set_value_cansleep(qcadev->bt_en, 0);
+   }
+
kfree_skb(qca->rx_skb);
 
hu->priv = NULL;
@@ -885,6 +914,14 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t 
baudrate)
return 0;
 }
 
+static inline void host_set_baudrate(struct hci_uart *hu, unsigned int speed)
+{
+   if (hu->serdev)
+   serdev_device_set_baudrate(hu->serdev, speed);
+   else
+   hci_uart_set_baudrate(hu, speed);
+}
+
 static int qca_setup(struct hci_uart *hu)
 {
struct hci_dev *hdev = hu->hdev;
@@ -905,7 +942,7 @@ static int qca_setup(struct hci_uart *hu)
speed = hu->proto->init_speed;
 
if (speed)
-   hci_uart_set_baudrate(hu, speed);
+   host_set_baudrate(hu, speed);
 
/* Setup user speed if needed */
speed = 0;
@@ -924,7 +961,7 @@ static int qca_setup(struct hci_uart *hu)
   ret);
return ret;
}
-   hci_uart_set_baudrate(hu, speed);
+   host_set_baudrate(hu, speed);
}
 
/* Setup patch / NVM configurations */
@@ -958,12 +995,80 @@ static struct hci_uart_proto qca_proto = {
.dequeue= qca_dequeue,
 };
 
+static int qca_serdev_probe(struct serdev_device *serdev)
+{
+   struct qca_serdev *qcadev;
+   int err;
+
+   qcadev = devm_kzalloc(>dev, sizeof(*qcadev), GFP_KERNEL);
+   if (!qcadev)
+   return -ENOMEM;
+
+   qcadev->serdev_hu.serdev = serdev;
+   serdev_device_set_drvdata(serdev, qcadev);
+
+   qcadev->bt_en = 

[PATCH v5 3/3] Bluetooth: hci_qca: Add serdev support

2018-03-19 Thread Thierry Escande
Add support for Qualcomm serial slave devices. Probe the serial device,
retrieve its maximum speed and register a new hci uart device.

Signed-off-by: Thierry Escande 
---

v5:
- Use gpio new name 'enable'

v4:
- Rename divclk4 as susclk (its name in the bt chip)
- Use gpiod_set_value_cansleep()
- Replace #include  with 
- Restore dependency on BT_HCIUART

v3:
- Remove redundant call to gpiod_set_value() after devm_gpiod_get()
- Check returned values for clk_set_rate() and clk_prepare_enable()
- Use clk_disable_unprepare()

v2:
- Fix author email

 drivers/bluetooth/Kconfig   |   1 +
 drivers/bluetooth/hci_qca.c | 109 +++-
 2 files changed, 108 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 07e55cd8f8c8..e0f1a6609b68 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -196,6 +196,7 @@ config BT_HCIUART_BCM
 config BT_HCIUART_QCA
bool "Qualcomm Atheros protocol support"
depends on BT_HCIUART
+   depends on BT_HCIUART_SERDEV
select BT_HCIUART_H4
select BT_QCA
help
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 05ec530b8a3a..6e6042f77784 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -29,7 +29,11 @@
  */
 
 #include 
+#include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -50,6 +54,9 @@
 #define IBS_TX_IDLE_TIMEOUT_MS 2000
 #define BAUDRATE_SETTLE_TIMEOUT_MS 300
 
+/* susclk rate */
+#define SUSCLK_RATE_32KHZ  32768
+
 /* HCI_IBS transmit side sleep protocol states */
 enum tx_ibs_states {
HCI_IBS_TX_ASLEEP,
@@ -111,6 +118,12 @@ struct qca_data {
u64 votes_off;
 };
 
+struct qca_serdev {
+   struct hci_uart  serdev_hu;
+   struct gpio_desc *bt_en;
+   struct clk   *susclk;
+};
+
 static void __serial_clock_on(struct tty_struct *tty)
 {
/* TODO: Some chipset requires to enable UART clock on client
@@ -386,6 +399,7 @@ static void hci_ibs_wake_retrans_timeout(struct timer_list 
*t)
 /* Initialize protocol */
 static int qca_open(struct hci_uart *hu)
 {
+   struct qca_serdev *qcadev;
struct qca_data *qca;
 
BT_DBG("hu %p qca_open", hu);
@@ -444,6 +458,13 @@ static int qca_open(struct hci_uart *hu)
timer_setup(>tx_idle_timer, hci_ibs_tx_idle_timeout, 0);
qca->tx_idle_delay = IBS_TX_IDLE_TIMEOUT_MS;
 
+   if (hu->serdev) {
+   serdev_device_open(hu->serdev);
+
+   qcadev = serdev_device_get_drvdata(hu->serdev);
+   gpiod_set_value_cansleep(qcadev->bt_en, 1);
+   }
+
BT_DBG("HCI_UART_QCA open, tx_idle_delay=%u, wake_retrans=%u",
   qca->tx_idle_delay, qca->wake_retrans);
 
@@ -512,6 +533,7 @@ static int qca_flush(struct hci_uart *hu)
 /* Close protocol */
 static int qca_close(struct hci_uart *hu)
 {
+   struct qca_serdev *qcadev;
struct qca_data *qca = hu->priv;
 
BT_DBG("hu %p qca close", hu);
@@ -525,6 +547,13 @@ static int qca_close(struct hci_uart *hu)
destroy_workqueue(qca->workqueue);
qca->hu = NULL;
 
+   if (hu->serdev) {
+   serdev_device_close(hu->serdev);
+
+   qcadev = serdev_device_get_drvdata(hu->serdev);
+   gpiod_set_value_cansleep(qcadev->bt_en, 0);
+   }
+
kfree_skb(qca->rx_skb);
 
hu->priv = NULL;
@@ -885,6 +914,14 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t 
baudrate)
return 0;
 }
 
+static inline void host_set_baudrate(struct hci_uart *hu, unsigned int speed)
+{
+   if (hu->serdev)
+   serdev_device_set_baudrate(hu->serdev, speed);
+   else
+   hci_uart_set_baudrate(hu, speed);
+}
+
 static int qca_setup(struct hci_uart *hu)
 {
struct hci_dev *hdev = hu->hdev;
@@ -905,7 +942,7 @@ static int qca_setup(struct hci_uart *hu)
speed = hu->proto->init_speed;
 
if (speed)
-   hci_uart_set_baudrate(hu, speed);
+   host_set_baudrate(hu, speed);
 
/* Setup user speed if needed */
speed = 0;
@@ -924,7 +961,7 @@ static int qca_setup(struct hci_uart *hu)
   ret);
return ret;
}
-   hci_uart_set_baudrate(hu, speed);
+   host_set_baudrate(hu, speed);
}
 
/* Setup patch / NVM configurations */
@@ -958,12 +995,80 @@ static struct hci_uart_proto qca_proto = {
.dequeue= qca_dequeue,
 };
 
+static int qca_serdev_probe(struct serdev_device *serdev)
+{
+   struct qca_serdev *qcadev;
+   int err;
+
+   qcadev = devm_kzalloc(>dev, sizeof(*qcadev), GFP_KERNEL);
+   if (!qcadev)
+   return -ENOMEM;
+
+   qcadev->serdev_hu.serdev = serdev;
+   serdev_device_set_drvdata(serdev, qcadev);
+
+   qcadev->bt_en = devm_gpiod_get(>dev, "enable",

[PATCH v5 2/3] dt-bindings: net: bluetooth: Add qualcomm-bluetooth

2018-03-19 Thread Thierry Escande
Add binding document for serial bluetooth chips using Qualcomm protocol.

Signed-off-by: Thierry Escande 
---

v5:
- Rename 'bt-disable-n' gpio as 'enable'

v4:
- Move bt-disable-n-gpios to required properties section
- Add clocks and pinctrl-0 as required properties

v3: no change
v2: no change

 .../devicetree/bindings/net/qualcomm-bluetooth.txt | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt

diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt 
b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
new file mode 100644
index ..bbc2973634b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
@@ -0,0 +1,34 @@
+Qualcomm Bluetooth Chips
+-
+
+This documents the binding structure and common properties for serial
+attached Qualcomm devices.
+
+Serial attached Qualcomm devices shall be a child node of the host UART
+device the slave device is attached to.
+
+Required properties:
+ - compatible: should contain one of the following:
+   * "qcom,qca6174-bt"
+ - enable-gpios: gpio specifier used to enable chip
+ - pinctrl-0: pin phandle for bt_en gpio
+ - clocks: clock phandle for SUSCLK_32KHZ
+
+Example:
+
+serial@757 {
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_uart1_default>;
+   pinctrl-1 = <_uart1_sleep>;
+
+   bluetooth {
+   compatible = "qcom,qca6174-bt";
+
+   enable-gpios = <_gpios 19 GPIO_ACTIVE_HIGH>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_en_pin_a>;
+
+   clocks = <>;
+   };
+};
-- 
2.14.1



[PATCH v5 0/3] Bluetooth: hci_qca: Add serdev support

2018-03-19 Thread Thierry Escande
Hi,

This patchset enables the Qualcomm BT controller QCA6174 node in the
device tree of the db820c board. This allows the bluetooth chipset to
be probed and registered against the hci layer by using the serdev
framework.

This patchset also contains the documentation for the compatible
string "qcom,qca6174-bt" related to this chipset.

v5:
- Rename 'bt-disable-n' gpio as 'enable'

v4:
- Fix dt binding documentation
- Address some other issues in patch #3

v3:
- Address comments for patch #3 (details in patch)

v2:
- Fix author email

Thierry Escande (3):
  arm64: dts: apq8096-db820c: enable bluetooth node
  dt-bindings: net: bluetooth: Add qualcomm-bluetooth
  Bluetooth: hci_qca: Add serdev support

 .../devicetree/bindings/net/qualcomm-bluetooth.txt |  34 +++
 arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi  |  14 +++
 .../boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi|  17 
 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi   |  33 +++
 arch/arm64/boot/dts/qcom/msm8996.dtsi  |  10 ++
 drivers/bluetooth/Kconfig  |   1 +
 drivers/bluetooth/hci_qca.c| 109 -
 7 files changed, 216 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt

-- 
2.14.1



[PATCH v5 1/3] arm64: dts: apq8096-db820c: enable bluetooth node

2018-03-19 Thread Thierry Escande
Add a new serial node for the Qualcomm BT controller QCA6174. This
allows automatic probing and hci registration through the serdev
framework instead of relying on the userspace helpers.

Signed-off-by: Thierry Escande 
---

v5:
- Rename 'bt-disable-n' gpio as 'enable'

v4: no change
v3: no change

v2:
- Fix author email

 arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi  | 14 +
 .../boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi| 17 +++
 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi   | 33 ++
 arch/arm64/boot/dts/qcom/msm8996.dtsi  | 10 +++
 4 files changed, 74 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi 
b/arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi
index 24552f19b3fa..172165d84669 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi
@@ -36,4 +36,18 @@
drive-strength = <2>;   /* 2 MA */
};
};
+
+   blsp1_uart1_default: blsp1_uart1_default {
+   function = "blsp_uart2";
+   pins = "gpio41", "gpio42", "gpio43", "gpio44";
+   drive-strength = <16>;
+   bias-disable;
+   };
+
+   blsp1_uart1_sleep: blsp1_uart1_sleep {
+   function = "gpio";
+   pins = "gpio41", "gpio42", "gpio43", "gpio44";
+   drive-strength = <2>;
+   bias-disable;
+   };
 };
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi 
b/arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi
index 59b29ddfb6e9..f8d2a3b10b1f 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi
@@ -26,6 +26,23 @@
};
};
 
+   divclk4_pin_a: divclk4 {
+   pins = "gpio18";
+   function = "func2";
+
+   bias-disable;
+   power-source = ;
+   };
+
+   bt_en_pin_a: bt-en-active {
+   pins = "gpio19";
+   function = "normal";
+
+   output-low;
+   power-source = ;
+   qcom,drive-strength = ;
+   };
+
usb3_vbus_det_gpio: pm8996_gpio22 {
pinconf {
pins = "gpio22";
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi 
b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index 1c8f1b86472d..8b3bcdf0d718 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -23,6 +23,7 @@
aliases {
serial0 = _uart1;
serial1 = _uart2;
+   serial2 = _uart1;
i2c0= _i2c2;
i2c1= _i2c1;
i2c2= _i2c0;
@@ -34,7 +35,39 @@
stdout-path = "serial0:115200n8";
};
 
+   clocks {
+   divclk4: divclk4 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "divclk4";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin_a>;
+   };
+   };
+
soc {
+   serial@757 {
+   label = "BT-UART";
+   status = "okay";
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_uart1_default>;
+   pinctrl-1 = <_uart1_sleep>;
+
+   bluetooth {
+   compatible = "qcom,qca6174-bt";
+
+   /* bt_disable_n gpio */
+   enable-gpios = <_gpios 19 
GPIO_ACTIVE_HIGH>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_en_pin_a>;
+
+   clocks = <>;
+   };
+   };
+
serial@75b {
label = "LS-UART1";
status = "okay";
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 0a6f7952bbb1..2d54a86a027f 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -408,6 +408,16 @@
#clock-cells = <1>;
};
 
+   blsp1_uart1: serial@757 {
+   compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+   reg = <0x0757 0x1000>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_UART2_APPS_CLK>,
+< GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   status = "disabled";
+   };
+
blsp1_spi0: spi@7575000 {
  

[PATCH v5 0/3] Bluetooth: hci_qca: Add serdev support

2018-03-19 Thread Thierry Escande
Hi,

This patchset enables the Qualcomm BT controller QCA6174 node in the
device tree of the db820c board. This allows the bluetooth chipset to
be probed and registered against the hci layer by using the serdev
framework.

This patchset also contains the documentation for the compatible
string "qcom,qca6174-bt" related to this chipset.

v5:
- Rename 'bt-disable-n' gpio as 'enable'

v4:
- Fix dt binding documentation
- Address some other issues in patch #3

v3:
- Address comments for patch #3 (details in patch)

v2:
- Fix author email

Thierry Escande (3):
  arm64: dts: apq8096-db820c: enable bluetooth node
  dt-bindings: net: bluetooth: Add qualcomm-bluetooth
  Bluetooth: hci_qca: Add serdev support

 .../devicetree/bindings/net/qualcomm-bluetooth.txt |  34 +++
 arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi  |  14 +++
 .../boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi|  17 
 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi   |  33 +++
 arch/arm64/boot/dts/qcom/msm8996.dtsi  |  10 ++
 drivers/bluetooth/Kconfig  |   1 +
 drivers/bluetooth/hci_qca.c| 109 -
 7 files changed, 216 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt

-- 
2.14.1



[PATCH v5 1/3] arm64: dts: apq8096-db820c: enable bluetooth node

2018-03-19 Thread Thierry Escande
Add a new serial node for the Qualcomm BT controller QCA6174. This
allows automatic probing and hci registration through the serdev
framework instead of relying on the userspace helpers.

Signed-off-by: Thierry Escande 
---

v5:
- Rename 'bt-disable-n' gpio as 'enable'

v4: no change
v3: no change

v2:
- Fix author email

 arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi  | 14 +
 .../boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi| 17 +++
 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi   | 33 ++
 arch/arm64/boot/dts/qcom/msm8996.dtsi  | 10 +++
 4 files changed, 74 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi 
b/arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi
index 24552f19b3fa..172165d84669 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c-pins.dtsi
@@ -36,4 +36,18 @@
drive-strength = <2>;   /* 2 MA */
};
};
+
+   blsp1_uart1_default: blsp1_uart1_default {
+   function = "blsp_uart2";
+   pins = "gpio41", "gpio42", "gpio43", "gpio44";
+   drive-strength = <16>;
+   bias-disable;
+   };
+
+   blsp1_uart1_sleep: blsp1_uart1_sleep {
+   function = "gpio";
+   pins = "gpio41", "gpio42", "gpio43", "gpio44";
+   drive-strength = <2>;
+   bias-disable;
+   };
 };
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi 
b/arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi
index 59b29ddfb6e9..f8d2a3b10b1f 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c-pmic-pins.dtsi
@@ -26,6 +26,23 @@
};
};
 
+   divclk4_pin_a: divclk4 {
+   pins = "gpio18";
+   function = "func2";
+
+   bias-disable;
+   power-source = ;
+   };
+
+   bt_en_pin_a: bt-en-active {
+   pins = "gpio19";
+   function = "normal";
+
+   output-low;
+   power-source = ;
+   qcom,drive-strength = ;
+   };
+
usb3_vbus_det_gpio: pm8996_gpio22 {
pinconf {
pins = "gpio22";
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi 
b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index 1c8f1b86472d..8b3bcdf0d718 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -23,6 +23,7 @@
aliases {
serial0 = _uart1;
serial1 = _uart2;
+   serial2 = _uart1;
i2c0= _i2c2;
i2c1= _i2c1;
i2c2= _i2c0;
@@ -34,7 +35,39 @@
stdout-path = "serial0:115200n8";
};
 
+   clocks {
+   divclk4: divclk4 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "divclk4";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin_a>;
+   };
+   };
+
soc {
+   serial@757 {
+   label = "BT-UART";
+   status = "okay";
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_uart1_default>;
+   pinctrl-1 = <_uart1_sleep>;
+
+   bluetooth {
+   compatible = "qcom,qca6174-bt";
+
+   /* bt_disable_n gpio */
+   enable-gpios = <_gpios 19 
GPIO_ACTIVE_HIGH>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_en_pin_a>;
+
+   clocks = <>;
+   };
+   };
+
serial@75b {
label = "LS-UART1";
status = "okay";
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 0a6f7952bbb1..2d54a86a027f 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -408,6 +408,16 @@
#clock-cells = <1>;
};
 
+   blsp1_uart1: serial@757 {
+   compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+   reg = <0x0757 0x1000>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_UART2_APPS_CLK>,
+< GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   status = "disabled";
+   };
+
blsp1_spi0: spi@7575000 {
compatible = 

[PATCH v5 2/3] dt-bindings: net: bluetooth: Add qualcomm-bluetooth

2018-03-19 Thread Thierry Escande
Add binding document for serial bluetooth chips using Qualcomm protocol.

Signed-off-by: Thierry Escande 
---

v5:
- Rename 'bt-disable-n' gpio as 'enable'

v4:
- Move bt-disable-n-gpios to required properties section
- Add clocks and pinctrl-0 as required properties

v3: no change
v2: no change

 .../devicetree/bindings/net/qualcomm-bluetooth.txt | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt

diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt 
b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
new file mode 100644
index ..bbc2973634b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt
@@ -0,0 +1,34 @@
+Qualcomm Bluetooth Chips
+-
+
+This documents the binding structure and common properties for serial
+attached Qualcomm devices.
+
+Serial attached Qualcomm devices shall be a child node of the host UART
+device the slave device is attached to.
+
+Required properties:
+ - compatible: should contain one of the following:
+   * "qcom,qca6174-bt"
+ - enable-gpios: gpio specifier used to enable chip
+ - pinctrl-0: pin phandle for bt_en gpio
+ - clocks: clock phandle for SUSCLK_32KHZ
+
+Example:
+
+serial@757 {
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_uart1_default>;
+   pinctrl-1 = <_uart1_sleep>;
+
+   bluetooth {
+   compatible = "qcom,qca6174-bt";
+
+   enable-gpios = <_gpios 19 GPIO_ACTIVE_HIGH>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_en_pin_a>;
+
+   clocks = <>;
+   };
+};
-- 
2.14.1



RE: [RFC PATCH 1/2] clk: add new APIs to operate on all available clocks

2018-03-19 Thread A.s. Dong
> -Original Message-
> From: Stephen Boyd [mailto:sb...@kernel.org]
> Sent: Tuesday, March 20, 2018 12:22 AM
> To: A.s. Dong ; linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; dl-
> linux-imx ; aisheng.d...@codeaurora.org; linux-
> fb...@vger.kernel.org; yamada.masah...@socionext.com;
> sb...@codeaurora.org; hdego...@redhat.com;
> b.zolnier...@samsung.com; A.s. Dong 
> Subject: Re: [RFC PATCH 1/2] clk: add new APIs to operate on all available
> clocks
> 
> Quoting Dong Aisheng (2018-01-23 04:50:40)
> > This patch introduces of_clk_bulk_get_all and clk_bulk_x_all APIs to
> > users who just want to handle all available clocks from device tree
> > without need to know the detailed clock information likes clock
> > numbers and names. This is useful in writing some generic drivers to
> > handle clock part.
> >
> > Cc: Stephen Boyd 
> > Cc: Masahiro Yamada 
> > Signed-off-by: Dong Aisheng 
> >
> > ---
> > A few question may need discuss:
> > 1)  This patch is written based on of_clk_bulk_get.
> > [V4,1/1] clk: bulk: add of_clk_bulk_get()
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.kernel.org%2Fpatch%2F9971527%2F=02%7C01%7Caisheng.don
> g%40n
> >
> xp.com%7C449209dd3e19491afb9908d58db5966d%7C686ea1d3bc2b4c6fa92c
> d99c5c
> >
> 301635%7C0%7C0%7C636570733411754127=4m5emXOR%2Bui3Mqw
> MbAJQDQxJcE
> > %2BxLcB51hEi2q3V2O8%3D=0 Stepen once said we may not
> need it,
> > but i guess as we already have clk_bulk_get, there may be guys who
> > want of_clk_bulk_get as well if they need specify the clock count
> > information, becaues of_clk_bulk_get_all will not check the count.
> > And of_clk_bulk_get is also helpful when implementing
> > of_clk_bulk_get_all.
> 
> Hmm ok. It's ok to implement it on top of of_clk_bulk_get I suppose, but
> maybe that API can be kept private until someone can prove they need it
> because they don't have a struct device pointer. Can you pick that patch from
> the list and resend in the series?
> 

Of course. I will do that.

> >
> > 2) It only implements the DT type clk_get_all as i see Stephen said we
> > probably may not need to implement non-dt type as there're still no
> > users.
> 
> Good.
> 
> >
> > If we do want to implement non-dt type as well, we could revise the
> > patch to add it too.
> > ---
> >  drivers/clk/clk-bulk.c | 64
> ++
> >  include/linux/clk.h| 61
> ++-
> >  2 files changed, 124 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/clk-bulk.c b/drivers/clk/clk-bulk.c index
> > 1c1a79d..bac2aae 100644
> > --- a/drivers/clk/clk-bulk.c
> > +++ b/drivers/clk/clk-bulk.c
> > @@ -17,9 +17,11 @@
> >   */
> >
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)  int
> > __must_check of_clk_bulk_get(struct device_node *np, int num_clks, @@
> > -50,6 +52,45 @@ int __must_check of_clk_bulk_get(struct device_node
> *np, int num_clks,
> > return ret;
> >  }
> >  EXPORT_SYMBOL(of_clk_bulk_get);
> > +
> > +struct clk_bulk __must_check *of_clk_bulk_get_all(struct device_node
> > +*np) {
> > +   struct clk_bulk *clk_bulk;
> > +   int num_clks;
> > +   int ret;
> > +
> > +   num_clks = of_clk_get_parent_count(np);
> > +   if (!num_clks)
> > +   return NULL;
> > +
> > +   clk_bulk = kzalloc(sizeof(*clk_bulk) +
> > +  num_clks * sizeof(struct clk_bulk_data),
> > +  GFP_KERNEL);
> > +   if (!clk_bulk)
> > +   return ERR_PTR(-ENOMEM);
> > +
> > +   clk_bulk->num_clks = num_clks;
> > +   ret = of_clk_bulk_get(np, clk_bulk->num_clks, clk_bulk->clks);
> > +   if (ret) {
> > +   kfree(clk_bulk);
> > +   return ERR_PTR(ret);
> > +   }
> 
> Has this been tested? clk_bulk->clks probably points to junk?
> 

You're right. Will fix in a formal patch.

> > +
> > +   return clk_bulk;
> > +}
> > +EXPORT_SYMBOL(of_clk_bulk_get_all);
> > +
> > +void of_clk_bulk_put_all(struct clk_bulk *clk_bulk) {
> > +   if (IS_ERR_OR_NULL(clk_bulk))
> > +   return;
> > +
> > +   clk_bulk_put(clk_bulk->num_clks, clk_bulk->clks);
> > +
> > +   kfree(clk_bulk->clks);
> > +   kfree(clk_bulk);
> > +}
> > +EXPORT_SYMBOL(of_clk_bulk_put_all);
> >  #endif
> 
> My goal was to make device drivers pass in their struct device to
> clk_bulk_get_all() and then have that call into a private DT helper function
> like of_clk_bulk_get_all(). With your patch 2 that could still be done so 
> let's
> go that direction?
> 

Sounds good to me.

> >
> >  void clk_bulk_put(int num_clks, struct clk_bulk_data *clks) @@ -107,6
> > 

RE: [RFC PATCH 1/2] clk: add new APIs to operate on all available clocks

2018-03-19 Thread A.s. Dong
> -Original Message-
> From: Stephen Boyd [mailto:sb...@kernel.org]
> Sent: Tuesday, March 20, 2018 12:22 AM
> To: A.s. Dong ; linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; dl-
> linux-imx ; aisheng.d...@codeaurora.org; linux-
> fb...@vger.kernel.org; yamada.masah...@socionext.com;
> sb...@codeaurora.org; hdego...@redhat.com;
> b.zolnier...@samsung.com; A.s. Dong 
> Subject: Re: [RFC PATCH 1/2] clk: add new APIs to operate on all available
> clocks
> 
> Quoting Dong Aisheng (2018-01-23 04:50:40)
> > This patch introduces of_clk_bulk_get_all and clk_bulk_x_all APIs to
> > users who just want to handle all available clocks from device tree
> > without need to know the detailed clock information likes clock
> > numbers and names. This is useful in writing some generic drivers to
> > handle clock part.
> >
> > Cc: Stephen Boyd 
> > Cc: Masahiro Yamada 
> > Signed-off-by: Dong Aisheng 
> >
> > ---
> > A few question may need discuss:
> > 1)  This patch is written based on of_clk_bulk_get.
> > [V4,1/1] clk: bulk: add of_clk_bulk_get()
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.kernel.org%2Fpatch%2F9971527%2F=02%7C01%7Caisheng.don
> g%40n
> >
> xp.com%7C449209dd3e19491afb9908d58db5966d%7C686ea1d3bc2b4c6fa92c
> d99c5c
> >
> 301635%7C0%7C0%7C636570733411754127=4m5emXOR%2Bui3Mqw
> MbAJQDQxJcE
> > %2BxLcB51hEi2q3V2O8%3D=0 Stepen once said we may not
> need it,
> > but i guess as we already have clk_bulk_get, there may be guys who
> > want of_clk_bulk_get as well if they need specify the clock count
> > information, becaues of_clk_bulk_get_all will not check the count.
> > And of_clk_bulk_get is also helpful when implementing
> > of_clk_bulk_get_all.
> 
> Hmm ok. It's ok to implement it on top of of_clk_bulk_get I suppose, but
> maybe that API can be kept private until someone can prove they need it
> because they don't have a struct device pointer. Can you pick that patch from
> the list and resend in the series?
> 

Of course. I will do that.

> >
> > 2) It only implements the DT type clk_get_all as i see Stephen said we
> > probably may not need to implement non-dt type as there're still no
> > users.
> 
> Good.
> 
> >
> > If we do want to implement non-dt type as well, we could revise the
> > patch to add it too.
> > ---
> >  drivers/clk/clk-bulk.c | 64
> ++
> >  include/linux/clk.h| 61
> ++-
> >  2 files changed, 124 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/clk-bulk.c b/drivers/clk/clk-bulk.c index
> > 1c1a79d..bac2aae 100644
> > --- a/drivers/clk/clk-bulk.c
> > +++ b/drivers/clk/clk-bulk.c
> > @@ -17,9 +17,11 @@
> >   */
> >
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)  int
> > __must_check of_clk_bulk_get(struct device_node *np, int num_clks, @@
> > -50,6 +52,45 @@ int __must_check of_clk_bulk_get(struct device_node
> *np, int num_clks,
> > return ret;
> >  }
> >  EXPORT_SYMBOL(of_clk_bulk_get);
> > +
> > +struct clk_bulk __must_check *of_clk_bulk_get_all(struct device_node
> > +*np) {
> > +   struct clk_bulk *clk_bulk;
> > +   int num_clks;
> > +   int ret;
> > +
> > +   num_clks = of_clk_get_parent_count(np);
> > +   if (!num_clks)
> > +   return NULL;
> > +
> > +   clk_bulk = kzalloc(sizeof(*clk_bulk) +
> > +  num_clks * sizeof(struct clk_bulk_data),
> > +  GFP_KERNEL);
> > +   if (!clk_bulk)
> > +   return ERR_PTR(-ENOMEM);
> > +
> > +   clk_bulk->num_clks = num_clks;
> > +   ret = of_clk_bulk_get(np, clk_bulk->num_clks, clk_bulk->clks);
> > +   if (ret) {
> > +   kfree(clk_bulk);
> > +   return ERR_PTR(ret);
> > +   }
> 
> Has this been tested? clk_bulk->clks probably points to junk?
> 

You're right. Will fix in a formal patch.

> > +
> > +   return clk_bulk;
> > +}
> > +EXPORT_SYMBOL(of_clk_bulk_get_all);
> > +
> > +void of_clk_bulk_put_all(struct clk_bulk *clk_bulk) {
> > +   if (IS_ERR_OR_NULL(clk_bulk))
> > +   return;
> > +
> > +   clk_bulk_put(clk_bulk->num_clks, clk_bulk->clks);
> > +
> > +   kfree(clk_bulk->clks);
> > +   kfree(clk_bulk);
> > +}
> > +EXPORT_SYMBOL(of_clk_bulk_put_all);
> >  #endif
> 
> My goal was to make device drivers pass in their struct device to
> clk_bulk_get_all() and then have that call into a private DT helper function
> like of_clk_bulk_get_all(). With your patch 2 that could still be done so 
> let's
> go that direction?
> 

Sounds good to me.

> >
> >  void clk_bulk_put(int num_clks, struct clk_bulk_data *clks) @@ -107,6
> > +148,12 @@ void clk_bulk_unprepare(int num_clks, const struct
> > clk_bulk_data *clks)  }  EXPORT_SYMBOL_GPL(clk_bulk_unprepare);
> >
> > 

Re: [PATCH 07/36] aio: add delayed cancel support

2018-03-19 Thread Darrick J. Wong
On Mon, Mar 05, 2018 at 01:27:14PM -0800, Christoph Hellwig wrote:
> The upcoming aio poll support would like to be able to complete the
> iocb inline from the cancellation context, but that would cause
> a lock order reversal.  Add support for optionally moving the cancelation
> outside the context lock to avoid this reversal.

I started to wonder which lock order reversal the commit message refers
to?

I think the reason for adding delayed cancellations is that we want to
be able to call io_cancel -> kiocb_cancel -> aio_poll_cancel ->
aio_complete without double locking ctx_lock?

--D

> Signed-off-by: Christoph Hellwig 
> Acked-by: Jeff Moyer 
> ---
>  fs/aio.c | 49 ++---
>  1 file changed, 38 insertions(+), 11 deletions(-)
> 
> diff --git a/fs/aio.c b/fs/aio.c
> index 0b6394b4e528..9d7d6e4cde87 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -170,6 +170,10 @@ struct aio_kiocb {
>   struct list_headki_list;/* the aio core uses this
>* for cancellation */
>  
> + unsigned intflags;  /* protected by ctx->ctx_lock */
> +#define AIO_IOCB_DELAYED_CANCEL  (1 << 0)
> +#define AIO_IOCB_CANCELLED   (1 << 1)
> +
>   /*
>* If the aio_resfd field of the userspace iocb is not zero,
>* this is the underlying eventfd context to deliver events to.
> @@ -536,9 +540,9 @@ static int aio_setup_ring(struct kioctx *ctx, unsigned 
> int nr_events)
>  #define AIO_EVENTS_FIRST_PAGE((PAGE_SIZE - sizeof(struct aio_ring)) 
> / sizeof(struct io_event))
>  #define AIO_EVENTS_OFFSET(AIO_EVENTS_PER_PAGE - AIO_EVENTS_FIRST_PAGE)
>  
> -void kiocb_set_cancel_fn(struct kiocb *iocb, kiocb_cancel_fn *cancel)
> +static void __kiocb_set_cancel_fn(struct aio_kiocb *req,
> + kiocb_cancel_fn *cancel, unsigned int iocb_flags)
>  {
> - struct aio_kiocb *req = container_of(iocb, struct aio_kiocb, rw);
>   struct kioctx *ctx = req->ki_ctx;
>   unsigned long flags;
>  
> @@ -548,8 +552,15 @@ void kiocb_set_cancel_fn(struct kiocb *iocb, 
> kiocb_cancel_fn *cancel)
>   spin_lock_irqsave(>ctx_lock, flags);
>   list_add_tail(>ki_list, >active_reqs);
>   req->ki_cancel = cancel;
> + req->flags |= iocb_flags;
>   spin_unlock_irqrestore(>ctx_lock, flags);
>  }
> +
> +void kiocb_set_cancel_fn(struct kiocb *iocb, kiocb_cancel_fn *cancel)
> +{
> + return __kiocb_set_cancel_fn(container_of(iocb, struct aio_kiocb, rw),
> + cancel, 0);
> +}
>  EXPORT_SYMBOL(kiocb_set_cancel_fn);
>  
>  /*
> @@ -603,17 +614,27 @@ static void free_ioctx_users(struct percpu_ref *ref)
>  {
>   struct kioctx *ctx = container_of(ref, struct kioctx, users);
>   struct aio_kiocb *req;
> + LIST_HEAD(list);
>  
>   spin_lock_irq(>ctx_lock);
> -
>   while (!list_empty(>active_reqs)) {
>   req = list_first_entry(>active_reqs,
>  struct aio_kiocb, ki_list);
> - kiocb_cancel(req);
> - }
>  
> + if (req->flags & AIO_IOCB_DELAYED_CANCEL) {
> + req->flags |= AIO_IOCB_CANCELLED;
> + list_move_tail(>ki_list, );
> + } else {
> + kiocb_cancel(req);
> + }
> + }
>   spin_unlock_irq(>ctx_lock);
>  
> + while (!list_empty()) {
> + req = list_first_entry(, struct aio_kiocb, ki_list);
> + kiocb_cancel(req);
> + }
> +
>   percpu_ref_kill(>reqs);
>   percpu_ref_put(>reqs);
>  }
> @@ -1785,15 +1806,22 @@ SYSCALL_DEFINE3(io_cancel, aio_context_t, ctx_id, 
> struct iocb __user *, iocb,
>   if (unlikely(!ctx))
>   return -EINVAL;
>  
> - spin_lock_irq(>ctx_lock);
> + ret = -EINVAL;
>  
> + spin_lock_irq(>ctx_lock);
>   kiocb = lookup_kiocb(ctx, iocb, key);
> + if (kiocb) {
> + if (kiocb->flags & AIO_IOCB_DELAYED_CANCEL) {
> + kiocb->flags |= AIO_IOCB_CANCELLED;
> + } else {
> + ret = kiocb_cancel(kiocb);
> + kiocb = NULL;
> + }
> + }
> + spin_unlock_irq(>ctx_lock);
> +
>   if (kiocb)
>   ret = kiocb_cancel(kiocb);
> - else
> - ret = -EINVAL;
> -
> - spin_unlock_irq(>ctx_lock);
>  
>   if (!ret) {
>   /*
> @@ -1805,7 +1833,6 @@ SYSCALL_DEFINE3(io_cancel, aio_context_t, ctx_id, 
> struct iocb __user *, iocb,
>   }
>  
>   percpu_ref_put(>users);
> -
>   return ret;
>  }
>  
> -- 
> 2.14.2
> 


Re: [PATCH 07/36] aio: add delayed cancel support

2018-03-19 Thread Darrick J. Wong
On Mon, Mar 05, 2018 at 01:27:14PM -0800, Christoph Hellwig wrote:
> The upcoming aio poll support would like to be able to complete the
> iocb inline from the cancellation context, but that would cause
> a lock order reversal.  Add support for optionally moving the cancelation
> outside the context lock to avoid this reversal.

I started to wonder which lock order reversal the commit message refers
to?

I think the reason for adding delayed cancellations is that we want to
be able to call io_cancel -> kiocb_cancel -> aio_poll_cancel ->
aio_complete without double locking ctx_lock?

--D

> Signed-off-by: Christoph Hellwig 
> Acked-by: Jeff Moyer 
> ---
>  fs/aio.c | 49 ++---
>  1 file changed, 38 insertions(+), 11 deletions(-)
> 
> diff --git a/fs/aio.c b/fs/aio.c
> index 0b6394b4e528..9d7d6e4cde87 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -170,6 +170,10 @@ struct aio_kiocb {
>   struct list_headki_list;/* the aio core uses this
>* for cancellation */
>  
> + unsigned intflags;  /* protected by ctx->ctx_lock */
> +#define AIO_IOCB_DELAYED_CANCEL  (1 << 0)
> +#define AIO_IOCB_CANCELLED   (1 << 1)
> +
>   /*
>* If the aio_resfd field of the userspace iocb is not zero,
>* this is the underlying eventfd context to deliver events to.
> @@ -536,9 +540,9 @@ static int aio_setup_ring(struct kioctx *ctx, unsigned 
> int nr_events)
>  #define AIO_EVENTS_FIRST_PAGE((PAGE_SIZE - sizeof(struct aio_ring)) 
> / sizeof(struct io_event))
>  #define AIO_EVENTS_OFFSET(AIO_EVENTS_PER_PAGE - AIO_EVENTS_FIRST_PAGE)
>  
> -void kiocb_set_cancel_fn(struct kiocb *iocb, kiocb_cancel_fn *cancel)
> +static void __kiocb_set_cancel_fn(struct aio_kiocb *req,
> + kiocb_cancel_fn *cancel, unsigned int iocb_flags)
>  {
> - struct aio_kiocb *req = container_of(iocb, struct aio_kiocb, rw);
>   struct kioctx *ctx = req->ki_ctx;
>   unsigned long flags;
>  
> @@ -548,8 +552,15 @@ void kiocb_set_cancel_fn(struct kiocb *iocb, 
> kiocb_cancel_fn *cancel)
>   spin_lock_irqsave(>ctx_lock, flags);
>   list_add_tail(>ki_list, >active_reqs);
>   req->ki_cancel = cancel;
> + req->flags |= iocb_flags;
>   spin_unlock_irqrestore(>ctx_lock, flags);
>  }
> +
> +void kiocb_set_cancel_fn(struct kiocb *iocb, kiocb_cancel_fn *cancel)
> +{
> + return __kiocb_set_cancel_fn(container_of(iocb, struct aio_kiocb, rw),
> + cancel, 0);
> +}
>  EXPORT_SYMBOL(kiocb_set_cancel_fn);
>  
>  /*
> @@ -603,17 +614,27 @@ static void free_ioctx_users(struct percpu_ref *ref)
>  {
>   struct kioctx *ctx = container_of(ref, struct kioctx, users);
>   struct aio_kiocb *req;
> + LIST_HEAD(list);
>  
>   spin_lock_irq(>ctx_lock);
> -
>   while (!list_empty(>active_reqs)) {
>   req = list_first_entry(>active_reqs,
>  struct aio_kiocb, ki_list);
> - kiocb_cancel(req);
> - }
>  
> + if (req->flags & AIO_IOCB_DELAYED_CANCEL) {
> + req->flags |= AIO_IOCB_CANCELLED;
> + list_move_tail(>ki_list, );
> + } else {
> + kiocb_cancel(req);
> + }
> + }
>   spin_unlock_irq(>ctx_lock);
>  
> + while (!list_empty()) {
> + req = list_first_entry(, struct aio_kiocb, ki_list);
> + kiocb_cancel(req);
> + }
> +
>   percpu_ref_kill(>reqs);
>   percpu_ref_put(>reqs);
>  }
> @@ -1785,15 +1806,22 @@ SYSCALL_DEFINE3(io_cancel, aio_context_t, ctx_id, 
> struct iocb __user *, iocb,
>   if (unlikely(!ctx))
>   return -EINVAL;
>  
> - spin_lock_irq(>ctx_lock);
> + ret = -EINVAL;
>  
> + spin_lock_irq(>ctx_lock);
>   kiocb = lookup_kiocb(ctx, iocb, key);
> + if (kiocb) {
> + if (kiocb->flags & AIO_IOCB_DELAYED_CANCEL) {
> + kiocb->flags |= AIO_IOCB_CANCELLED;
> + } else {
> + ret = kiocb_cancel(kiocb);
> + kiocb = NULL;
> + }
> + }
> + spin_unlock_irq(>ctx_lock);
> +
>   if (kiocb)
>   ret = kiocb_cancel(kiocb);
> - else
> - ret = -EINVAL;
> -
> - spin_unlock_irq(>ctx_lock);
>  
>   if (!ret) {
>   /*
> @@ -1805,7 +1833,6 @@ SYSCALL_DEFINE3(io_cancel, aio_context_t, ctx_id, 
> struct iocb __user *, iocb,
>   }
>  
>   percpu_ref_put(>users);
> -
>   return ret;
>  }
>  
> -- 
> 2.14.2
> 


Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs

2018-03-19 Thread Zhang Rui
On 二, 2018-03-20 at 09:38 +0800, Viresh Kumar wrote:
> On 14-03-18, 13:44, Viresh Kumar wrote:
> > 
> > I got those warnings as well, and I quietly ignored them :)
> > 
> > I ignored the renaming part for the sake of consistency. The other
> > existing
> > routines for similar purpose are named as:
> > 
> > thermal_cooling_device_type_show
> > thermal_cooling_device_max_state_show
> > thermal_cooling_device_cur_state_show
> > thermal_cooling_device_cur_state_store
> > 
> > for me it made more sense to follow that naming convention. And I
> > didn't use the
> > _RO and _WO variants for the same reason.
> > 
> > Now here is what I propose now:
> > 
> > - You apply this patch as-is and ignore the warning.
> > 
> > - I will send few patches on top of that to do:
> >   - renaming of all such routines to shorter versions.
> >   - Use the _RO or _WO variants of the macro everywhere.
> > 
> > What do you say ?
> @Zhang: Can you please share the way you want this to get merged ?
> And if the
> above is fine with you ?
> 
yes, it works for me.
I will apply the patch later today.

thanks,
rui


Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs

2018-03-19 Thread Zhang Rui
On 二, 2018-03-20 at 09:38 +0800, Viresh Kumar wrote:
> On 14-03-18, 13:44, Viresh Kumar wrote:
> > 
> > I got those warnings as well, and I quietly ignored them :)
> > 
> > I ignored the renaming part for the sake of consistency. The other
> > existing
> > routines for similar purpose are named as:
> > 
> > thermal_cooling_device_type_show
> > thermal_cooling_device_max_state_show
> > thermal_cooling_device_cur_state_show
> > thermal_cooling_device_cur_state_store
> > 
> > for me it made more sense to follow that naming convention. And I
> > didn't use the
> > _RO and _WO variants for the same reason.
> > 
> > Now here is what I propose now:
> > 
> > - You apply this patch as-is and ignore the warning.
> > 
> > - I will send few patches on top of that to do:
> >   - renaming of all such routines to shorter versions.
> >   - Use the _RO or _WO variants of the macro everywhere.
> > 
> > What do you say ?
> @Zhang: Can you please share the way you want this to get merged ?
> And if the
> above is fine with you ?
> 
yes, it works for me.
I will apply the patch later today.

thanks,
rui


[PATCH 3/4] signal/x86: Move nosig handling at the end of exit_to_usermode_loop.

2018-03-19 Thread NIIBE Yutaka
Handling of restarting a system call for nosig should be done after
all possible calls of do_signal, to see if it's actually delivering
signal(s) or not.

Before this change, restarting a system call for nosig may be followed
by a call of handle_signal which would try to change the system call
returning -EINTR instead, but it is too late to do so.

Signed-off-by: NIIBE Yutaka 
---
 arch/x86/entry/common.c   | 6 +-
 arch/x86/include/asm/signal.h | 2 +-
 arch/x86/kernel/signal.c  | 6 +++---
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index 74f6eee15179..38e0939c0aeb 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -137,6 +137,8 @@ static long syscall_trace_enter(struct pt_regs *regs)
 
 static void exit_to_usermode_loop(struct pt_regs *regs, u32 cached_flags)
 {
+   int nosig = 0;
+
/*
 * In order to return to user mode, we need to have IRQs off with
 * none of EXIT_TO_USERMODE_LOOP_FLAGS set.  Several of these flags
@@ -159,7 +161,7 @@ static void exit_to_usermode_loop(struct pt_regs *regs, u32 
cached_flags)
 
/* deal with pending signal delivery */
if (cached_flags & _TIF_SIGPENDING)
-   do_signal(regs);
+   nosig |= do_signal(regs);
 
if (cached_flags & _TIF_NOTIFY_RESUME) {
clear_thread_flag(TIF_NOTIFY_RESUME);
@@ -177,6 +179,8 @@ static void exit_to_usermode_loop(struct pt_regs *regs, u32 
cached_flags)
if (!(cached_flags & EXIT_TO_USERMODE_LOOP_FLAGS))
break;
}
+   if (nosig)
+   nosig_restart_syscall(regs);
 }
 
 /* Called with IRQs disabled. */
diff --git a/arch/x86/include/asm/signal.h b/arch/x86/include/asm/signal.h
index 6517df6d9938..31e68266c2f6 100644
--- a/arch/x86/include/asm/signal.h
+++ b/arch/x86/include/asm/signal.h
@@ -35,7 +35,7 @@ typedef sigset_t compat_sigset_t;
 #endif /* __ASSEMBLY__ */
 #include 
 #ifndef __ASSEMBLY__
-extern void do_signal(struct pt_regs *regs);
+extern int do_signal(struct pt_regs *regs);
 extern void nosig_restart_syscall(struct pt_regs *regs);
 
 #define __ARCH_HAS_SA_RESTORER
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index e709b54a01b8..57576988a01f 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -803,17 +803,17 @@ static inline unsigned long get_nr_restart_syscall(const 
struct pt_regs *regs)
  * want to handle. Thus you cannot kill init even with a SIGKILL even by
  * mistake.
  */
-void do_signal(struct pt_regs *regs)
+int do_signal(struct pt_regs *regs)
 {
struct ksignal ksig;
 
if (get_signal()) {
/* Whee! Actually deliver the signal.  */
handle_signal(, regs);
-   return;
+   return 0;
}
 
-   nosig_restart_syscall(regs);
+   return 1;
 }
 
 void nosig_restart_syscall(struct pt_regs *regs)
-- 
2.11.0



[PATCH 3/4] signal/x86: Move nosig handling at the end of exit_to_usermode_loop.

2018-03-19 Thread NIIBE Yutaka
Handling of restarting a system call for nosig should be done after
all possible calls of do_signal, to see if it's actually delivering
signal(s) or not.

Before this change, restarting a system call for nosig may be followed
by a call of handle_signal which would try to change the system call
returning -EINTR instead, but it is too late to do so.

Signed-off-by: NIIBE Yutaka 
---
 arch/x86/entry/common.c   | 6 +-
 arch/x86/include/asm/signal.h | 2 +-
 arch/x86/kernel/signal.c  | 6 +++---
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index 74f6eee15179..38e0939c0aeb 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -137,6 +137,8 @@ static long syscall_trace_enter(struct pt_regs *regs)
 
 static void exit_to_usermode_loop(struct pt_regs *regs, u32 cached_flags)
 {
+   int nosig = 0;
+
/*
 * In order to return to user mode, we need to have IRQs off with
 * none of EXIT_TO_USERMODE_LOOP_FLAGS set.  Several of these flags
@@ -159,7 +161,7 @@ static void exit_to_usermode_loop(struct pt_regs *regs, u32 
cached_flags)
 
/* deal with pending signal delivery */
if (cached_flags & _TIF_SIGPENDING)
-   do_signal(regs);
+   nosig |= do_signal(regs);
 
if (cached_flags & _TIF_NOTIFY_RESUME) {
clear_thread_flag(TIF_NOTIFY_RESUME);
@@ -177,6 +179,8 @@ static void exit_to_usermode_loop(struct pt_regs *regs, u32 
cached_flags)
if (!(cached_flags & EXIT_TO_USERMODE_LOOP_FLAGS))
break;
}
+   if (nosig)
+   nosig_restart_syscall(regs);
 }
 
 /* Called with IRQs disabled. */
diff --git a/arch/x86/include/asm/signal.h b/arch/x86/include/asm/signal.h
index 6517df6d9938..31e68266c2f6 100644
--- a/arch/x86/include/asm/signal.h
+++ b/arch/x86/include/asm/signal.h
@@ -35,7 +35,7 @@ typedef sigset_t compat_sigset_t;
 #endif /* __ASSEMBLY__ */
 #include 
 #ifndef __ASSEMBLY__
-extern void do_signal(struct pt_regs *regs);
+extern int do_signal(struct pt_regs *regs);
 extern void nosig_restart_syscall(struct pt_regs *regs);
 
 #define __ARCH_HAS_SA_RESTORER
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index e709b54a01b8..57576988a01f 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -803,17 +803,17 @@ static inline unsigned long get_nr_restart_syscall(const 
struct pt_regs *regs)
  * want to handle. Thus you cannot kill init even with a SIGKILL even by
  * mistake.
  */
-void do_signal(struct pt_regs *regs)
+int do_signal(struct pt_regs *regs)
 {
struct ksignal ksig;
 
if (get_signal()) {
/* Whee! Actually deliver the signal.  */
handle_signal(, regs);
-   return;
+   return 0;
}
 
-   nosig_restart_syscall(regs);
+   return 1;
 }
 
 void nosig_restart_syscall(struct pt_regs *regs)
-- 
2.11.0



[PATCH 1/2] clk: mediatek: add devm_of_platform_populate() for MT7622 audsys

2018-03-19 Thread Ryder Lee
Add devm_of_platform_populate() to populate devices which are children
of the root node.

Signed-off-by: Ryder Lee 
---
 drivers/clk/mediatek/clk-mt7622-aud.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c 
b/drivers/clk/mediatek/clk-mt7622-aud.c
index 13f752d..4f3d47b 100644
--- a/drivers/clk/mediatek/clk-mt7622-aud.c
+++ b/drivers/clk/mediatek/clk-mt7622-aud.c
@@ -150,11 +150,23 @@ static int clk_mt7622_audiosys_init(struct 
platform_device *pdev)
   clk_data);
 
r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
-   if (r)
+   if (r) {
dev_err(>dev,
"could not register clock provider: %s: %d\n",
pdev->name, r);
 
+   goto err_clk_provider;
+   }
+
+   r = devm_of_platform_populate(>dev);
+   if (r)
+   goto err_plat_populate;
+
+   return 0;
+
+err_plat_populate:
+   of_clk_del_provider(node);
+err_clk_provider:
return r;
 }
 
-- 
1.9.1



[PATCH 2/4] signal/x86: do_signal: syscall restart should be done only once.

2018-03-19 Thread NIIBE Yutaka
do_signal may be called multiple times from exit_to_usermode_loop.  In
those multiple calls, only the one should handle restarting the system
call.

When actually delivering a signal, make sure the register will not be
examined again as syscall errno by another call of do_signal.

Signed-off-by: NIIBE Yutaka 
---
 arch/x86/kernel/signal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index cdfb82031243..e709b54a01b8 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -729,6 +729,7 @@ handle_signal(struct ksignal *ksig, struct pt_regs *regs)
regs->ip -= 2;
break;
}
+   regs->orig_ax = -1;
}
 
/*
-- 
2.11.0



[PATCH 1/2] clk: mediatek: add devm_of_platform_populate() for MT7622 audsys

2018-03-19 Thread Ryder Lee
Add devm_of_platform_populate() to populate devices which are children
of the root node.

Signed-off-by: Ryder Lee 
---
 drivers/clk/mediatek/clk-mt7622-aud.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c 
b/drivers/clk/mediatek/clk-mt7622-aud.c
index 13f752d..4f3d47b 100644
--- a/drivers/clk/mediatek/clk-mt7622-aud.c
+++ b/drivers/clk/mediatek/clk-mt7622-aud.c
@@ -150,11 +150,23 @@ static int clk_mt7622_audiosys_init(struct 
platform_device *pdev)
   clk_data);
 
r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
-   if (r)
+   if (r) {
dev_err(>dev,
"could not register clock provider: %s: %d\n",
pdev->name, r);
 
+   goto err_clk_provider;
+   }
+
+   r = devm_of_platform_populate(>dev);
+   if (r)
+   goto err_plat_populate;
+
+   return 0;
+
+err_plat_populate:
+   of_clk_del_provider(node);
+err_clk_provider:
return r;
 }
 
-- 
1.9.1



[PATCH 2/4] signal/x86: do_signal: syscall restart should be done only once.

2018-03-19 Thread NIIBE Yutaka
do_signal may be called multiple times from exit_to_usermode_loop.  In
those multiple calls, only the one should handle restarting the system
call.

When actually delivering a signal, make sure the register will not be
examined again as syscall errno by another call of do_signal.

Signed-off-by: NIIBE Yutaka 
---
 arch/x86/kernel/signal.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index cdfb82031243..e709b54a01b8 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -729,6 +729,7 @@ handle_signal(struct ksignal *ksig, struct pt_regs *regs)
regs->ip -= 2;
break;
}
+   regs->orig_ax = -1;
}
 
/*
-- 
2.11.0



[PATCH 0/4] Unblocked by fake_signal_wake_up then real signal

2018-03-19 Thread NIIBE Yutaka
Hello,

Background:
I tried to fix my own problem in suspend-to-ram with USB devices (some
device doesn't work well after suspend/resume).  I know it's common
problems.  Well, while I identified some problems of USB devices and
drivers, I did try my best.  I fixed a USB device implementation of
mine.  Then, I also located and fixed bugs in a USB user space driver
which I maintain.

Now, I think I found a kernel problem.  After suspend/resume, in my
USB user space driver, a task sends a signal to another task, then,
pselect is unblocked by the signal.  In this situation, a signal
handler is called correctly, but it seems that the pselect is
restarted.  Expected behavior is unblocked pselect returning -EINTR.

Looking the code, my theory is: 
It is a fake signal by suspend which unblocks pselect to be frozen,
and after resume, real signal is sent.  When both of signals are
handled in a single call of exit_to_usermode_loop, by two calls of
do_signal, firstly for fake signal and secondly for real signal, the
system call is restarted wrongly, where it should return -EINTR.

Here is a patch series of mine for x86.  I'd suggest architecture
maintainers to do similar if an architecture supports suspend/resume.

NIIBE Yutaka (4):
  signal/x86: Factor out nosig handling.
  signal/x86: do_signal: syscall restart should be done only once.
  signal/x86: Move nosig handling at the end of exit_to_usermode_loop.
  signal/x86: Move restore_saved_sigmask().

 arch/x86/entry/common.c   |  6 +-
 arch/x86/include/asm/signal.h |  3 ++-
 arch/x86/kernel/signal.c  | 22 ++
 3 files changed, 21 insertions(+), 10 deletions(-)

-- 
2.11.0



[PATCH 1/4] signal/x86: Factor out nosig handling.

2018-03-19 Thread NIIBE Yutaka
Make a function for swing at the ball and miss.

Signed-off-by: NIIBE Yutaka 
---
 arch/x86/include/asm/signal.h | 1 +
 arch/x86/kernel/signal.c  | 5 +
 2 files changed, 6 insertions(+)

diff --git a/arch/x86/include/asm/signal.h b/arch/x86/include/asm/signal.h
index 5f9012ff52ed..6517df6d9938 100644
--- a/arch/x86/include/asm/signal.h
+++ b/arch/x86/include/asm/signal.h
@@ -36,6 +36,7 @@ typedef sigset_t compat_sigset_t;
 #include 
 #ifndef __ASSEMBLY__
 extern void do_signal(struct pt_regs *regs);
+extern void nosig_restart_syscall(struct pt_regs *regs);
 
 #define __ARCH_HAS_SA_RESTORER
 
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 4cdc0b27ec82..cdfb82031243 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -812,6 +812,11 @@ void do_signal(struct pt_regs *regs)
return;
}
 
+   nosig_restart_syscall(regs);
+}
+
+void nosig_restart_syscall(struct pt_regs *regs)
+{
/* Did we come from a system call? */
if (syscall_get_nr(current, regs) >= 0) {
/* Restart the system call - no handlers present */
-- 
2.11.0



  1   2   3   4   5   6   7   8   9   10   >