from:"Santosh Shilimkar"

On 11/12/20 2:22 PM, Nishanth Menon wrote:

On 13:59-20201112, santosh.shilim...@oracle.com wrote:

On 11/12/20 1:56 PM, Nishanth Menon wrote:

On 14:08-20201026, Nishanth Menon wrote:

On 23:30-20201026, Lokesh Vutla wrote:
[..]

➜ linux git:(master) git grep -in ARCH_K3_AM6_SOC
arch/arm64/configs/defconfig:961:CONFIG_ARCH_K3_AM6_SOC=y
drivers/soc/ti/Kconfig:7:config ARCH_K3_AM6_SOC
➜ linux git:(master) git grep -in ARCH_K3_J721E_SOC
arch/arm64/configs/defconfig:962:CONFIG_ARCH_K3_J721E_SOC=y
drivers/gpu/drm/bridge/cadence/Kconfig:16: depends on ARCH_K3_J721E_SOC ||
COMPILE_TEST
drivers/soc/ti/Kconfig:12:config ARCH_K3_J721E_SOC

I see drm bridge Kconfig is cleaned[0]. Please clean the defconfig as well.

[0]
https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201026165441.22894-1...@ti.com/__;!!GqivPVa7Brio!KWOx2aLl7hlHQrN--kiz1N5WaPWgeZzFZ12ptg8NzJE2BSnxxrWmsoqn5vjMvpfO1bSGYQ$

Yes, the defconfig patches have to be queued up in a different queue,
Lets see where the two patches fall and will post the defconfig
updates as well.

Santosh,

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201026165441.22894-1...@ti.com/__;!!GqivPVa7Brio!KWOx2aLl7hlHQrN--kiz1N5WaPWgeZzFZ12ptg8NzJE2BSnxxrWmsoqn5vjMvpfO1bSGYQ$
looks available in next now.

Can we queue this patch[1] up for 5.11 window?

Depending on your preference, I can carry the defconfig patch[2] (to
prevent merge dependencies, might be good to get an immutable tag) OR
you can pick the defconfig patch up that cleans after removing the
symbol.

I can apply SOC kconfig patch [1] to my soc branch. That branch with
some additional patches am going to send up, so it should
work. Let me know.

OK, sounds fine to me, If you can give me a tag, I can add queue up
defconfig on top to prevent bisect issues.

I won't be adding tag till all the commits are lineup but branch will
be immutable.

Regards.
Santosh

Re: [PATCH] soc: ti: Kconfig: Drop ARM64 SoC specific configs


On 11/12/20 1:56 PM, Nishanth Menon wrote:

On 14:08-20201026, Nishanth Menon wrote:

On 23:30-20201026, Lokesh Vutla wrote:
[..]

➜  linux git:(master) git grep -in ARCH_K3_AM6_SOC
arch/arm64/configs/defconfig:961:CONFIG_ARCH_K3_AM6_SOC=y
drivers/soc/ti/Kconfig:7:config ARCH_K3_AM6_SOC
➜  linux git:(master) git grep -in ARCH_K3_J721E_SOC
arch/arm64/configs/defconfig:962:CONFIG_ARCH_K3_J721E_SOC=y
drivers/gpu/drm/bridge/cadence/Kconfig:16:  depends on ARCH_K3_J721E_SOC ||
COMPILE_TEST
drivers/soc/ti/Kconfig:12:config ARCH_K3_J721E_SOC


I see drm bridge Kconfig is cleaned[0]. Please clean the defconfig as well.

[0]
https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201026165441.22894-1...@ti.com/__;!!GqivPVa7Brio!KWOx2aLl7hlHQrN--kiz1N5WaPWgeZzFZ12ptg8NzJE2BSnxxrWmsoqn5vjMvpfO1bSGYQ$



Yes, the defconfig patches have to be queued up in a different queue,
Lets see where the two patches fall and will post the defconfig
updates as well.



Santosh,

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-arm-kernel/patch/20201026165441.22894-1...@ti.com/__;!!GqivPVa7Brio!KWOx2aLl7hlHQrN--kiz1N5WaPWgeZzFZ12ptg8NzJE2BSnxxrWmsoqn5vjMvpfO1bSGYQ$
looks available in next now.

Can we queue this patch[1] up for 5.11 window?

Depending on your preference, I can carry the defconfig patch[2] (to
prevent merge dependencies, might be good to get an immutable tag) OR
you can pick the defconfig patch up that cleans after removing the
symbol.



I can apply SOC kconfig patch [1] to my soc branch. That branch with
some additional patches am going to send up, so it should
work. Let me know.

Regards,
Santosh

Re: [PATCH 06/25] soc: ti: knav_qmss_queue: Remove set but unchecked variable 'ret'


On 11/12/20 11:02 AM, Lee Jones wrote:

On Thu, 12 Nov 2020, santosh.shilim...@oracle.com wrote:


On 11/12/20 5:21 AM, Lee Jones wrote:

On Thu, 12 Nov 2020, Tero Kristo wrote:


On 12/11/2020 12:31, Lee Jones wrote:

Cc:ing a few people I know.

On Tue, 03 Nov 2020, Lee Jones wrote:


Fixes the following W=1 kernel build warning(s):

drivers/soc/ti/knav_qmss_queue.c: In function ‘knav_setup_queue_pools’:
drivers/soc/ti/knav_qmss_queue.c:1310:6: warning: variable ‘ret’ set but 
not used [-Wunused-but-set-variable]

Cc: Santosh Shilimkar 
Cc: Sandeep Nair 
Cc: Cyril Chemparathy 
Signed-off-by: Lee Jones 
---
drivers/soc/ti/knav_qmss_queue.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)


Any idea who will take these TI patches?

https://urldefense.com/v3/__https://lore.kernel.org/linux-arm-kernel/2020052540.gh173...@builder.lan/__;!!GqivPVa7Brio!KEeMCT-GwmLNnDFCOqxnunXXiCrCpj3ZFXpiMzj55VmlOJ-FVhKmom-O7sq-CkL8s0sjAg$



(Dropped a few inactive emails from delivery.)

Santosh is the maintainer for the subsystem, so my vote would go for him.


Thanks for your prompt reply Tero.

It looks as though Santosh has been on Cc since the start.  He must
just be busy.  I'll give him a little while longer before submitting a
[RESEND].


Go ahead and re-post. These seems to be trivial so will pick
it up.


If you are in receipt of the first iteration, there shouldn't be any
requirement for a [RESEND].  Unless you deleted them from your inbox?


I haven't deleted anything. I thought you are going to repost based
on "I'll give him a little while longer before submitting a [RESEND]"
:-)

Regards,
Santosh


Regards,
Santosh

Re: [PATCH 06/25] soc: ti: knav_qmss_queue: Remove set but unchecked variable 'ret'


On 11/12/20 5:21 AM, Lee Jones wrote:

On Thu, 12 Nov 2020, Tero Kristo wrote:


On 12/11/2020 12:31, Lee Jones wrote:

Cc:ing a few people I know.

On Tue, 03 Nov 2020, Lee Jones wrote:


Fixes the following W=1 kernel build warning(s):

   drivers/soc/ti/knav_qmss_queue.c: In function ‘knav_setup_queue_pools’:
   drivers/soc/ti/knav_qmss_queue.c:1310:6: warning: variable ‘ret’ set but not 
used [-Wunused-but-set-variable]

Cc: Santosh Shilimkar 
Cc: Sandeep Nair 
Cc: Cyril Chemparathy 
Signed-off-by: Lee Jones 
---
   drivers/soc/ti/knav_qmss_queue.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)


Any idea who will take these TI patches?

https://urldefense.com/v3/__https://lore.kernel.org/linux-arm-kernel/2020052540.gh173...@builder.lan/__;!!GqivPVa7Brio!KEeMCT-GwmLNnDFCOqxnunXXiCrCpj3ZFXpiMzj55VmlOJ-FVhKmom-O7sq-CkL8s0sjAg$



(Dropped a few inactive emails from delivery.)

Santosh is the maintainer for the subsystem, so my vote would go for him.


Thanks for your prompt reply Tero.

It looks as though Santosh has been on Cc since the start.  He must
just be busy.  I'll give him a little while longer before submitting a
[RESEND].


Go ahead and re-post. These seems to be trivial so will pick
it up.

Regards,
Santosh

Re: [RESEND PATCH] soc: ti: ti_sci_pm_domains: check for proper args count in xlate

2020-10-29 Thread santosh . shilimkar


Hi Arnd, olof,

On 10/29/20 2:33 AM, Tero Kristo wrote:

K2G devices still only use single parameter for power-domains property,
so check for this properly in the driver. Without this, every peripheral
fails to probe resulting in boot failure.

Fixes: efa5c01cd7ee ("soc: ti: ti_sci_pm_domains: switch to use multiple genpds 
instead of one")
Reported-by: Nishanth Menon 
Signed-off-by: Tero Kristo 
Acked-by: Nishanth Menon 
Acked-by: Santosh Shilimkar 
---

Can you please add this to your fixes queue ?
This fixes boot failures on K2Gdevices ?


  drivers/soc/ti/ti_sci_pm_domains.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/ti/ti_sci_pm_domains.c 
b/drivers/soc/ti/ti_sci_pm_domains.c
index af2126d2b2ff..8afb3f45d263 100644
--- a/drivers/soc/ti/ti_sci_pm_domains.c
+++ b/drivers/soc/ti/ti_sci_pm_domains.c
@@ -91,7 +91,7 @@ static struct generic_pm_domain *ti_sci_pd_xlate(
struct genpd_onecell_data *genpd_data = data;
unsigned int idx = genpdspec->args[0];
  
-	if (genpdspec->args_count < 2)

+   if (genpdspec->args_count != 1 && genpdspec->args_count != 2)
return ERR_PTR(-EINVAL);
  
  	if (idx >= genpd_data->num_domains) {

Re: [PATCH] soc: ti: ti_sci_pm_domains: check for proper args count in xlate

2020-10-28 Thread santosh . shilimkar


On 10/28/20 2:43 PM, Nishanth Menon wrote:

On 16:17-20201028, Tero Kristo wrote:

K2G devices still only use single parameter for power-domains property,
so check for this properly in the driver. Without this, every peripheral
fails to probe resulting in boot failure.

Fixes: efa5c01cd7ee ("soc: ti: ti_sci_pm_domains: switch to use multiple genpds 
instead of one")
Reported-by: Nishanth Menon 
Signed-off-by: Tero Kristo 
---
  drivers/soc/ti/ti_sci_pm_domains.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/ti/ti_sci_pm_domains.c 
b/drivers/soc/ti/ti_sci_pm_domains.c
index af2126d2b2ff..8afb3f45d263 100644
--- a/drivers/soc/ti/ti_sci_pm_domains.c
+++ b/drivers/soc/ti/ti_sci_pm_domains.c
@@ -91,7 +91,7 @@ static struct generic_pm_domain *ti_sci_pd_xlate(
struct genpd_onecell_data *genpd_data = data;
unsigned int idx = genpdspec->args[0];
  
-	if (genpdspec->args_count < 2)

+   if (genpdspec->args_count != 1 && genpdspec->args_count != 2)
return ERR_PTR(-EINVAL);
  
  	if (idx >= genpd_data->num_domains) {



Thanks Tero.

Acked-by: Nishanth Menon 

Santosh: can we queue this one for 5.10? - I am trying to track and get
all platforms booting and functional in 5.10


Sure. Can you re-post with my ack to s...@kernel.org and copy me ?
Will try to get this one applied.

Regards,
Santosh

Re: [PATCH v2 00/11] firmware/soc: ti_sci, ringacc/inta: Preparation for AM64 DMA support

2020-10-08 Thread santosh . shilimkar


On 10/8/20 4:52 AM, Peter Ujfalusi wrote:

Santosh: if you plan to take this series for 5.11, then can you create an
immutable branch which I can refer to Vinod for the DMA patches I'm going to
send soon.


I will set it up right after the 5.10-rc1 is tagged.

regards,
Santosh

Re: [PATCH v2 00/11] firmware/soc: ti_sci, ringacc/inta: Preparation for AM64 DMA support

2020-10-08 Thread santosh . shilimkar


On 10/8/20 4:52 AM, Peter Ujfalusi wrote:

Santosh: if you plan to take this series for 5.11, then can you create an
immutable branch which I can refer to Vinod for the DMA patches I'm going to
send soon.


I will set it up right after the 5.10-rc1 is tagged.

regards,
Santosh

[GIT PULL] ARM: soc: TI driver updates for v5.10

2020-09-20 Thread Santosh Shilimkar

The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:

  Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git 
tags/drivers_soc_for_5.10

for you to fetch changes up to dcca7a97c6bfff2a7a18b928a0b9bf215cc8f4f5:

  Add missing '#' to fix schema errors: (2020-09-20 19:36:37 -0700)


ARM: soc: TI driver updates for v5.10

Consist of:
 - Add Ring accelerator support for AM65x
 - Add TI PRUSS platform driver and enable it on available platforms
 - Extend PRUSS driver for CORECLK_MUX/IEPCLK_MUX support
 - UDMA rx ring pair fix
 - Add socinfo entry for J7200


Grygorii Strashko (2):
  soc: ti: k3: ringacc: add am65x sr2.0 support
  bindings: soc: ti: soc: ringacc: remove ti,dma-ring-reset-quirk

Grzegorz Jaszczyk (3):
  dt-bindings: soc: ti: Add TI PRUSS bindings
  dt-bindings: soc: ti: Update TI PRUSS bindings regarding clock-muxes
  soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUX

Krzysztof Kozlowski (1):
  Add missing '#' to fix schema errors:

Peter Ujfalusi (2):
  soc: ti: k3-socinfo: Add entry for J7200
  dmaengine: ti: k3-udma-glue: Fix parameters for rx ring pair request

Qinglang Miao (1):
  soc: ti: Convert to DEFINE_SHOW_ATTRIBUTE

Suman Anna (6):
  soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs
  soc: ti: pruss: Add support for PRU-ICSSs on AM437x SoCs
  soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs
  soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC
  soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM65x SoCs
  soc: ti: pruss: Enable support for ICSSG subsystems on K3 J721E SoCs

Tero Kristo (2):
  soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of one
  firmware: ti_sci: allow frequency change for disabled clocks by default

 .../devicetree/bindings/soc/ti/k3-ringacc.yaml |   6 -
 .../devicetree/bindings/soc/ti/ti,pruss.yaml   | 439 +
 drivers/dma/ti/k3-udma-glue.c  |   2 +-
 drivers/firmware/ti_sci.c  |   6 +-
 drivers/soc/ti/Kconfig |  11 +
 drivers/soc/ti/Makefile|   1 +
 drivers/soc/ti/k3-ringacc.c|  33 +-
 drivers/soc/ti/k3-socinfo.c|   1 +
 drivers/soc/ti/knav_dma.c  |  16 +-
 drivers/soc/ti/knav_qmss_queue.c   |  14 +-
 drivers/soc/ti/pruss.c | 354 +
 drivers/soc/ti/ti_sci_pm_domains.c | 251 ++--
 include/linux/pruss_driver.h   |  54 +++
 13 files changed, 1021 insertions(+), 167 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
 create mode 100644 drivers/soc/ti/pruss.c
 create mode 100644 include/linux/pruss_driver.h

Re: [PATCH] dt-bindings: soc: ti: ti,pruss: fix schema ID

2020-09-17 Thread santosh . shilimkar


On 9/17/20 1:35 AM, Krzysztof Kozlowski wrote:

On Thu, 17 Sep 2020 at 10:32, Grzegorz Jaszczyk
 wrote:


On Thu, 17 Sep 2020 at 09:05, Krzysztof Kozlowski  wrote:


Add missing '#' to fix schema errors:

   $id: 
'https://urldefense.com/v3/__http://devicetree.org/schemas/soc/ti/ti,pruss.yaml__;!!GqivPVa7Brio!NF67-KbyQr0smc7iM86dsdgoOaQrQRN4F2aNdLndleTjLn6BhqrmDBL4ekWiVIG6IBFwLA$
 ' does not match 
'https://urldefense.com/v3/__http://devicetree.org/schemas/.**A5C*5C.yaml*__;KiUlIw!!GqivPVa7Brio!NF67-KbyQr0smc7iM86dsdgoOaQrQRN4F2aNdLndleTjLn6BhqrmDBL4ekWiVIGpNPP7ig$
 '
   $schema: 
'https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml__;!!GqivPVa7Brio!NF67-KbyQr0smc7iM86dsdgoOaQrQRN4F2aNdLndleTjLn6BhqrmDBL4ekWiVIEdWH0Bzw$
 ' is not one of 
['https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!GqivPVa7Brio!NF67-KbyQr0smc7iM86dsdgoOaQrQRN4F2aNdLndleTjLn6BhqrmDBL4ekWiVIHcNI2bOQ$
 ', 
'https://urldefense.com/v3/__http://devicetree.org/meta-schemas/base.yaml*__;Iw!!GqivPVa7Brio!NF67-KbyQr0smc7iM86dsdgoOaQrQRN4F2aNdLndleTjLn6BhqrmDBL4ekWiVIFH0HvA-g$
 ']
   Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml: ignoring, error in 
schema: $id

Signed-off-by: Krzysztof Kozlowski 
---
  Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml 
b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
index cf7dc83f724f..037c51b2f972 100644
--- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
@@ -1,8 +1,8 @@
  # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
  %YAML 1.2
  ---
-$id: 
https://urldefense.com/v3/__http://devicetree.org/schemas/soc/ti/ti,pruss.yaml__;!!GqivPVa7Brio!NF67-KbyQr0smc7iM86dsdgoOaQrQRN4F2aNdLndleTjLn6BhqrmDBL4ekWiVIG6IBFwLA$
-$schema: 
https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml__;!!GqivPVa7Brio!NF67-KbyQr0smc7iM86dsdgoOaQrQRN4F2aNdLndleTjLn6BhqrmDBL4ekWiVIEdWH0Bzw$
+$id: 
https://urldefense.com/v3/__http://devicetree.org/schemas/soc/ti/ti,pruss.yaml*__;Iw!!GqivPVa7Brio!NF67-KbyQr0smc7iM86dsdgoOaQrQRN4F2aNdLndleTjLn6BhqrmDBL4ekWiVIHAb7bLvA$
+$schema: 
https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!GqivPVa7Brio!NF67-KbyQr0smc7iM86dsdgoOaQrQRN4F2aNdLndleTjLn6BhqrmDBL4ekWiVIHcNI2bOQ$


I've double checked and "#" was present in the original patch sent and
ack for upstream: 
https://urldefense.com/v3/__https://patchwork.kernel.org/patch/11729649/__;!!GqivPVa7Brio!NF67-KbyQr0smc7iM86dsdgoOaQrQRN4F2aNdLndleTjLn6BhqrmDBL4ekWiVIEaRPpx1g$
It seems like something got wrong on linux-next but this is the only
diff between original patch and one found in linux-next. Thank you for
taking care of it.


Indeed that's weird. It must get lost when applying...


These URLs get mangled sometimes and I needed to fix them. Will fix the
original commit. Thanks for reporting.

Re: [PATCH 2/3] ARM/keystone: move the DMA offset handling under ifdef CONFIG_ARM_LPAE

2020-09-11 Thread santosh . shilimkar


On 9/11/20 4:15 AM, Russell King - ARM Linux admin wrote:

On Thu, Sep 10, 2020 at 07:40:37AM +0200, Christoph Hellwig wrote:

The DMA offset notifier can only be used if PHYS_OFFSET is at least
KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit
phys_addr_t.  Currently the code compiles fine despite that, a pending
change to the DMA offset handling would create a compiler warning for
this case.  Add an ifdef to not compile the code except for LPAE
configs.


However, to have use of the high physical offset, LPAE needs to be
enabled, which ensures that phys_addr_t is 64-bit.

I believe that DMA is non-coherent on this platform unless the high
physical address is used. Or something like that.


Exactly. Higher address ranges needs to be used for DMA coherency.

Regards,
Santosh

Re: [PATCH 0/3] clk: keystone: some minor fixes

2020-09-10 Thread santosh . shilimkar





On 9/10/20 2:29 PM, Stephen Boyd wrote:

Quoting santosh.shilim...@oracle.com (2020-09-08 10:19:32)



On 9/7/20 1:57 AM, Tero Kristo wrote:

Hi Santosh,

This series contains a few fixes for the TI SCI clock driver.
- Patch #1 is a clear bug fix, where we missed to parse assigned-clock
data properly to detect which clocks are in use on the SoC.
- Patch #2 is a performance improvement patch which avoids some
unnecessary round trips to firmware side while setting clock
frequency.
- Patch #3 fixes some issues with set_rate passed to firmware, where the
parameters are too strict; namely, firmware fails to handle some cases
properly if min,tgt,max values for a clock rate are exactly the same
value. Yeah, the firmware is quite weird here but nothing much else we
can do from kernel side other than this


Looks fine to me Tero.

Acked-by: Santosh Shilimkar 


Hi Stephen, Mike,
Can you please pick these fixes via clk tree ?


Sure. I assume this is -next material and not critical fixes.


Yep.

Re: [PATCH next v2 0/3] soc: ti: k3: ringacc: add am65x sr2.0 support

2020-09-09 Thread santosh . shilimkar


On 9/2/20 7:08 AM, Nishanth Menon wrote:

On 11:34-20200831, santosh.shilim...@oracle.com wrote:

On 8/29/20 11:41 AM, Grygorii Strashko wrote:

Hi Santosh,

I've rebased on top of  linux-next and identified merge conflict of patch 3
with commit 6da45875fa17 ("arm64: dts: k3-am65: Update the RM resource types")
in -next.

---
This series adds support for the TI AM65x SR2.0 SoC Ringacc which has fixed
errata i2023 "RINGACC, UDMA: RINGACC and UDMA Ring State Interoperability
Issue after Channel Teardown". This errata also fixed for J271E SoC.
The SOC bus chipinfo data is used to identify the SoC and configure
i2023 errata W/A.

This changes made "ti,dma-ring-reset-quirk" DT property obsolete, so it's 
removed.

Changes in v2:
   - no functional changes
   - rebased on top of linux-next
   - added ask from Rob Herring


Thanks. Can you please followup DT acks for PRUSS series so that I can
apply PRUSS + $subject series.



Santosh, in this series, may i suggest that the dtsi changes[1] be hosted
on my tree? else we are going to create a mix of rc1 and rc3 branches
which is going to be irritating, to say the least.

I will pick [1] the day after I see the patches 1 and 2 in linux-next tag.


Sure !!

Re: [PATCH next v2 0/3] soc: ti: k3: ringacc: add am65x sr2.0 support

2020-09-08 Thread santosh . shilimkar





On 9/8/20 3:09 PM, Suman Anna wrote:

Hi Santosh,

On 8/31/20 1:34 PM, santosh.shilim...@oracle.com wrote:

On 8/29/20 11:41 AM, Grygorii Strashko wrote:

Hi Santosh,

I've rebased on top of  linux-next and identified merge conflict of patch 3
with commit 6da45875fa17 ("arm64: dts: k3-am65: Update the RM resource types")
in -next.

---
This series adds support for the TI AM65x SR2.0 SoC Ringacc which has fixed
errata i2023 "RINGACC, UDMA: RINGACC and UDMA Ring State Interoperability
Issue after Channel Teardown". This errata also fixed for J271E SoC.
The SOC bus chipinfo data is used to identify the SoC and configure
i2023 errata W/A.

This changes made "ti,dma-ring-reset-quirk" DT property obsolete, so it's
removed.

Changes in v2:
   - no functional changes
   - rebased on top of linux-next
   - added ask from Rob Herring


Thanks. Can you please followup DT acks for PRUSS series so that I can
apply PRUSS + $subject series.


PRUSS dt binding is acked now, so can you pick up the PRUSS v2 series for 5.10
merge window.


Yes, I saw ack from Rob. Will try to get to this over coming weekend.

Regards,
Santosh

Re: [PATCH 0/3] clk: keystone: some minor fixes

2020-09-08 Thread santosh . shilimkar





On 9/7/20 1:57 AM, Tero Kristo wrote:

Hi Santosh,

This series contains a few fixes for the TI SCI clock driver.
- Patch #1 is a clear bug fix, where we missed to parse assigned-clock
   data properly to detect which clocks are in use on the SoC.
- Patch #2 is a performance improvement patch which avoids some
   unnecessary round trips to firmware side while setting clock
   frequency.
- Patch #3 fixes some issues with set_rate passed to firmware, where the
   parameters are too strict; namely, firmware fails to handle some cases
   properly if min,tgt,max values for a clock rate are exactly the same
   value. Yeah, the firmware is quite weird here but nothing much else we
   can do from kernel side other than this


Looks fine to me Tero.

Acked-by: Santosh Shilimkar 


Hi Stephen, Mike,
Can you please pick these fixes via clk tree ?

Re: [PATCH next v2 0/3] soc: ti: k3: ringacc: add am65x sr2.0 support

2020-08-31 Thread santosh . shilimkar


On 8/29/20 11:41 AM, Grygorii Strashko wrote:

Hi Santosh,

I've rebased on top of  linux-next and identified merge conflict of patch 3
with commit 6da45875fa17 ("arm64: dts: k3-am65: Update the RM resource types")
in -next.

---
This series adds support for the TI AM65x SR2.0 SoC Ringacc which has fixed
errata i2023 "RINGACC, UDMA: RINGACC and UDMA Ring State Interoperability
Issue after Channel Teardown". This errata also fixed for J271E SoC.
The SOC bus chipinfo data is used to identify the SoC and configure
i2023 errata W/A.

This changes made "ti,dma-ring-reset-quirk" DT property obsolete, so it's 
removed.

Changes in v2:
  - no functional changes
  - rebased on top of linux-next
  - added ask from Rob Herring


Thanks. Can you please followup DT acks for PRUSS series so that I can
apply PRUSS + $subject series.


v1: 
https://urldefense.com/v3/__https://lore.kernel.org/patchwork/cover/1284233/__;!!GqivPVa7Brio!PCmZ-nZZ6YQak-0T43bPZYI0gHsYL9k6N7S2gZEFbIr8BRKtv2BK01VejQzlBPBBgcfvCQ$
 
Grygorii Strashko (3):

   soc: ti: k3: ringacc: add am65x sr2.0 support
   bindings: soc: ti: soc: ringacc: remove ti,dma-ring-reset-quirk
   arm64: dts: ti: k3-am65: ringacc: drop ti,dma-ring-reset-quirk

  .../bindings/soc/ti/k3-ringacc.yaml   |  6 
  arch/arm64/boot/dts/ti/k3-am65-main.dtsi  |  1 -
  arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi   |  1 -
  drivers/soc/ti/k3-ringacc.c   | 33 +--
  4 files changed, 30 insertions(+), 11 deletions(-)

Re: [PATCH] memory: emif: Remove bogus debugfs error handling

2020-08-26 Thread santosh . shilimkar


On 8/26/20 4:37 AM, Dan Carpenter wrote:

Callers are generally not supposed to check the return values from
debugfs functions.  Debugfs functions never return NULL so this error
handling will never trigger.  (Historically debugfs functions used to
return a mix of NULL and error pointers but it was eventually deemed too
complicated for something which wasn't intended to be used in normal
situations).

Delete all the error handling.

Signed-off-by: Dan Carpenter 
---

Looks good to me !!

Acked-by: Santosh Shilimkar

Re: [PATCH 0/6] Add TI PRUSS platform driver

2020-08-20 Thread santosh . shilimkar


On 8/20/20 7:43 AM, Suman Anna wrote:

Hi Santosh, Tony,

On 7/29/20 6:02 AM, Grzegorz Jaszczyk wrote:

Hi,

The Programmable Real-Time Unit and Industrial Communication Subsystem
(PRU-ICSS) is present on various TI SoCs. The IP is present on multiple TI SoC
architecture families including the OMAP architecture SoCs such as AM33xx,
AM437x and AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is also
present on the Davinci based OMAPL138 SoCs and K3 architecture based AM65x and
J721E SoCs as well.

A PRUSS consists of dual 32-bit RISC cores (Programmable Real-Time Units, or
PRUs), shared RAM, data and instruction RAMs, some internal peripheral modules
to facilitate industrial communication, and an interrupt controller.

The programmable nature of the PRUs provide flexibility to implement custom
peripheral interfaces, fast real-time responses, or specialized data handling.
The common peripheral modules include the following,
   - an Ethernet MII_RT module with two MII ports
   - an MDIO port to control external Ethernet PHYs
   - an Industrial Ethernet Peripheral (IEP) to manage/generate Industrial
 Ethernet functions
   - an Enhanced Capture Module (eCAP)
   - an Industrial Ethernet Timer with 7/9 capture and 16 compare events
   - a 16550-compatible UART to support PROFIBUS
   - Enhanced GPIO with async capture and serial support


A typical usage scenario would be to load the application firmware into one or
more of the PRU cores, initialize one or more of the peripherals and perform I/O
through shared RAM from either a kernel driver or directly from userspace.

This series contains the PRUSS platform driver. This is the parent driver for
the entire PRUSS and is used for managing the subsystem level resources like
various memories and the CFG module.  It is responsible for the creation and
deletion of the platform devices for the child PRU devices and other child
devices (like Interrupt Controller, MDIO node and some syscon nodes) so that
they can be managed by specific platform drivers.

Grzegorz Jaszczyk (1):
   dt-bindings: soc: ti: Add TI PRUSS bindings

Suman Anna (5):
   soc: ti: pruss: Add a platform driver for PRUSS in TI SoCs
   soc: ti: pruss: Add support for PRU-ICSSs on AM437x SoCs
   soc: ti: pruss: Add support for PRU-ICSS subsystems on AM57xx SoCs
   soc: ti: pruss: Add support for PRU-ICSS subsystems on 66AK2G SoC
   soc: ti: pruss: enable support for ICSSG subsystems on K3 AM65x SoCs


Do you have any comments on the driver portions of this series before Greg posts
a v2 addressing the binding comments. This is one of the foundation series
towards enabling PRUSS, and is a dependency for the PRU remoteproc driver.


No just post V2 addressing Rob's comment. I will line it up once
rob acks it.

Regards,
Santosh

Re: [PATCH 0/3] Simplify PM for am3/4, drop RTC pdata for am3/4/dra7

2020-08-19 Thread santosh . shilimkar





On 8/18/20 1:29 AM, Tony Lindgren wrote:

Hi Santosh,

* Tony Lindgren  [200703 19:08]:

Hi all,

Here are patches to simplify the RTC+DDR PM code for am3 and am4. We want
to do this to drop the RTC related legacy platform data for am3 and am4.
We also drop RTC legacy platform data for dra7.

Please test the RTC+DDR suspend on am437x-gp-evm if possible. I've tested
this series on am437x-sk-evm, but at least currently cannot do RTC+DDR
suspend and is limited to testing retention suspend only.

These patches depend on v5.8-rc3 for earlier suspend and resume related
fixes.

Additionally, for testing the LCD for suspend, the following patch is
needed for the missing omapdrm PM ops:

drm/omap: force runtime PM suspend on system suspend


Here's another series that was getting too late for v5.9 that I'd like to
queue for v5.10. Care to take a look and ack if it looks OK?


Just finished going through the patches. If the suspend continue to work
with this update then its good to go.

FWIW,
Acked-by: Santosh Shilimkar

Re: [PATCHv4 0/6] Add initial genpd support for omap PRM driver

2020-08-17 Thread santosh . shilimkar


On 8/16/20 11:53 PM, Tony Lindgren wrote:

Hi Santosh,

* Tony Lindgren  [200702 18:46]:

Hi all,

Here's v4 set of patches to add genpd support to the PRM (Power and Reset
Module) driver.

Initially we just add one hardware accelerator power domain for sgx,
and one interconnect instance for l4_abe. The rest of the SoC specific
domain data is probably best added one SoC at a time based on generated
data.


Care to ack some of these patches? I'd like to get this into Linux next
for v5.10 :)


Sure,
Acked-by: Santosh Shilimkar

Re: [PATCH] dmaengine: ti: k3-udma-glue: Fix parameters for rx ring pair request

2020-08-06 Thread santosh . shilimkar


On 8/5/20 6:17 AM, Grygorii Strashko wrote:



On 05/08/2020 14:32, Vinod Koul wrote:

On 05-08-20, 14:27, Peter Ujfalusi wrote:

The original commit mixed up the forward and completion ring IDs for the
rx flow configuration.


Acked-By: Vinod Koul 



Fixes: 4927b1ab2047 ("dmaengine: ti: k3-udma: Switch to 
k3_ringacc_request_rings_pair")

Signed-off-by: Peter Ujfalusi 
---
Hi Santosh, Vinod,

the offending patch was queued via ti SoC tree.
Santosh, can you pick up this fix also?


Thank you Peter for catching this - it's valid issue.
but I'd like to note that issue was discovered with private code and
nothing is broken in Master.

Reviewed-by: Grygorii Strashko 


Will queue this up for next merge window.

regards,
Santosh

Re: [PATCH] soc: ti: k3-socinfo: Add entry for J7200

2020-08-04 Thread santosh . shilimkar


On 8/4/20 2:39 PM, Grygorii Strashko wrote:

Hi Santosh,

On 03/08/2020 17:41, Lokesh Vutla wrote:



On 03/08/20 4:23 pm, Peter Ujfalusi wrote:

Update K3 chipinfo driver to support new TI J7200 SoC.
It's JTAG PARTNO is 0xBB6D.

Signed-off-by: Peter Ujfalusi 


Reviewed-by: Lokesh Vutla 



Reviewed-by: Grygorii Strashko 


Thanks for reviews. Will add it to the queue.

[GIT PULL] SOC: TI Keystone driver update for v5.9

2020-07-25 Thread Santosh Shilimkar

The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:

  Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git 
tags/drivers_soc_for_5.9

for you to fetch changes up to 09241e61103d89abf9134849b9d0dc46ac4f9cb3:

  soc: TI knav_qmss: make symbol 'knav_acc_range_ops' static (2020-07-24 
14:47:10 -0700)


SOC: TI Keystone driver update for v5.9

 - TI K3 Ring Accelerator updates
 - Few non critical warining fixes


Alexander A. Klimov (1):
  firmware: ti_sci: Replace HTTP links with HTTPS ones

Grygorii Strashko (5):
  dt-bindings: soc: ti: k3-ringacc: convert bindings to json-schema
  soc: ti: k3-ringacc: add ring's flags to dump
  soc: ti: k3-ringacc: add request pair of rings api.
  soc: ti: k3-ringacc: separate soc specific initialization
  soc: ti: k3-ringacc: fix: warn: variable dereferenced before check 'ring'

Peter Ujfalusi (2):
  soc: ti: k3-ringacc: Move state tracking variables under a struct
  dmaengine: ti: k3-udma: Switch to k3_ringacc_request_rings_pair

Randy Dunlap (1):
  soc: ti/ti_sci_protocol.h: drop a duplicated word + clarify

Wei Yongjun (1):
  soc: TI knav_qmss: make symbol 'knav_acc_range_ops' static

kernel test robot (1):
  soc: ti: k3: fix semicolon.cocci warnings

 .../bindings/interrupt-controller/ti,sci-intr.txt  |   2 +-
 .../devicetree/bindings/soc/ti/k3-ringacc.txt  |  59 --
 .../devicetree/bindings/soc/ti/k3-ringacc.yaml | 102 +++
 drivers/dma/ti/k3-udma-glue.c  |  42 ++---
 drivers/dma/ti/k3-udma.c   |  34 ++--
 drivers/firmware/ti_sci.c  |   2 +-
 drivers/firmware/ti_sci.h  |   2 +-
 drivers/irqchip/irq-ti-sci-inta.c  |   2 +-
 drivers/irqchip/irq-ti-sci-intr.c  |   2 +-
 drivers/reset/reset-ti-sci.c   |   2 +-
 drivers/soc/ti/k3-ringacc.c| 200 ++---
 drivers/soc/ti/knav_qmss_acc.c |   2 +-
 include/linux/soc/ti/k3-ringacc.h  |   4 +
 include/linux/soc/ti/ti_sci_inta_msi.h |   2 +-
 include/linux/soc/ti/ti_sci_protocol.h |   6 +-
 15 files changed, 276 insertions(+), 187 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/soc/ti/k3-ringacc.txt
 create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml

Re: [PATCH next v2 0/6] soc: ti: k3-ringacc: updates

2020-07-17 Thread santosh . shilimkar


On 7/17/20 6:20 AM, Grygorii Strashko wrote:

Hi Santosh,

This series is a set of non critical  updates for The TI K3 AM654x/J721E
Ring Accelerator driver.


Thanks. Will have a look and if all looks good, add it to next.


Patch 1 - convert bindings to json-schema
Patches 2,3,5 - code reworking
Patch 4 - adds new API to request pair of rings k3_ringacc_request_rings_pair()
Patch 6 - updates K3 UDMA to use new API

Changes in v2:
- fixed build warning with patch 6
- added "Reviewed-by:" and "Acked-by:" tags.

v1: https://lore.kernel.org/patchwork/cover/1266231/

Grygorii Strashko (4):
   dt-bindings: soc: ti: k3-ringacc: convert bindings to json-schema
   soc: ti: k3-ringacc: add ring's flags to dump
   soc: ti: k3-ringacc: add request pair of rings api.
   soc: ti: k3-ringacc: separate soc specific initialization

Peter Ujfalusi (2):
   soc: ti: k3-ringacc: Move state tracking variables under a struct
   dmaengine: ti: k3-udma: Switch to k3_ringacc_request_rings_pair

  .../devicetree/bindings/soc/ti/k3-ringacc.txt |  59 --
  .../bindings/soc/ti/k3-ringacc.yaml   | 102 +
  drivers/dma/ti/k3-udma-glue.c |  42 ++--
  drivers/dma/ti/k3-udma.c  |  34 +--
  drivers/soc/ti/k3-ringacc.c   | 194 --
  include/linux/soc/ti/k3-ringacc.h |   4 +
  6 files changed, 261 insertions(+), 174 deletions(-)
  delete mode 100644 Documentation/devicetree/bindings/soc/ti/k3-ringacc.txt
  create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-ringacc.yaml

Re: [GIT PULL] ARM: Keystone DTS updates for 5.7

2020-06-02 Thread santosh . shilimkar


On 6/2/20 1:00 PM, Arnd Bergmann wrote:

On Tue, Jun 2, 2020 at 5:14 PM  wrote:


Hi Arnd, Olof,

On 3/7/20 9:56 AM, Santosh Shilimkar wrote:

The following changes since commit bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9:

Linux 5.6-rc1 (2020-02-09 16:08:48 -0800)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git 
tags/keystone_dts_for_5.7

for you to fetch changes up to 7856488bd83b0182548a84d05c07326321ae6138:

ARM: dts: keystone-k2g-evm: add HDMI video support (2020-03-07 09:47:24 
-0800)


ARM: Keystone DTS updates for 5.7

Add display support for K2G EVM Board


Jyri Sarha (2):
ARM: dts: keystone-k2g: Add DSS node
ARM: dts: keystone-k2g-evm: add HDMI video support

   arch/arm/boot/dts/keystone-k2g-evm.dts | 101 
+
   arch/arm/boot/dts/keystone-k2g.dtsi|  22 +++
   2 files changed, 123 insertions(+)


Looks like this pull request wasn't picked. Can you please check
in case am missing something.


I pulled it now, thanks for double-checking!

The problem here was that the s...@kernel.org address was not on Cc, so
the pull request did not end up in patchwork. I try to also look for other
pull requests sent to the a...@kernel.org address, but it's much less reliable.


Thanks Arnd. I started copying s...@kernel.org as well for pull request
after Olof's suggestion. This one was sent before that.

Regards,
Santosh

Re: [GIT PULL] ARM: Keystone DTS updates for 5.7

2020-06-02 Thread santosh . shilimkar


Hi Arnd, Olof,

On 3/7/20 9:56 AM, Santosh Shilimkar wrote:

The following changes since commit bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9:

   Linux 5.6-rc1 (2020-02-09 16:08:48 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git 
tags/keystone_dts_for_5.7

for you to fetch changes up to 7856488bd83b0182548a84d05c07326321ae6138:

   ARM: dts: keystone-k2g-evm: add HDMI video support (2020-03-07 09:47:24 
-0800)


ARM: Keystone DTS updates for 5.7

Add display support for K2G EVM Board


Jyri Sarha (2):
   ARM: dts: keystone-k2g: Add DSS node
   ARM: dts: keystone-k2g-evm: add HDMI video support

  arch/arm/boot/dts/keystone-k2g-evm.dts | 101 +
  arch/arm/boot/dts/keystone-k2g.dtsi|  22 +++
  2 files changed, 123 insertions(+)


Looks like this pull request wasn't picked. Can you please check
in case am missing something.

Regards,
Santosh

Re: [PATCH v4 0/2] soc: ti: add k3 platforms chipid module driver

2020-05-29 Thread santosh . shilimkar


On 5/29/20 11:34 AM, Arnd Bergmann wrote:

On Fri, May 29, 2020 at 8:22 PM Grygorii Strashko
 wrote:

On 12/05/2020 15:34, Grygorii Strashko wrote:



   .../bindings/soc/ti/k3-socinfo.yaml   |  40 +
   drivers/soc/ti/Kconfig|  10 ++
   drivers/soc/ti/Makefile   |   1 +
   drivers/soc/ti/k3-socinfo.c   | 152 ++
   4 files changed, 203 insertions(+)
   create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
   create mode 100644 drivers/soc/ti/k3-socinfo.c



Any chances you can pick this up?


I merged a version of this driver from Santosh's pull request into the
arm/drviers tree yesterday.

Is there something missing?


Nope. I was going to reply on the thread but missed it.

Regards,
Santosh

Re: [PATCH] ARM: omap2: drop broken broadcast timer hack

2020-05-28 Thread santosh . shilimkar


On 5/28/20 8:57 AM, Tony Lindgren wrote:

* Tony Lindgren  [200528 13:51]:

* Tony Lindgren  [200528 13:47]:

* Arnd Bergmann  [200528 09:20]:

The OMAP4 timer code had a special hack for using the broadcast timer
without SMP. Since the dmtimer is now gone, this also needs to be dropped
to avoid a link failure for non-SMP AM43xx configurations:

kernel/time/tick-broadcast.o: in function `tick_device_uses_broadcast':
tick-broadcast.c:(.text+0x130): undefined reference to `tick_broadcast'


Hmm this sounds like a regression though. Isn't this needed for using
the ARM local timers on non-SMP SoC, so a separate timer from dmtimer?

I've probably removed something accidentally to cause this.


Sounds like arch/arm/mach-omap2/Makefile change needs to be removed
to always still build in timer.o. And probably timer.c needs back
the ifdef for CONFIG_SOC_HAS_REALTIME_COUNTER.

I'll take a look today.


I've sent a patch along those lines as:

[PATCH] ARM: OMAP2+: Fix regression for using local timer on non-SMP SoCs

A link for the patch at [0] below.


CPU local timers not being in always ON power domain use to be the
reason on early version of the SOCs but later SOC moved the CPU local
timer also in always on domain. Probably AM43xx does loose local timer
on CPU PD in low power so yes broadcast would be needed with dmtimer
help.



[0] 
https://lore.kernel.org/linux-omap/20200528155453.8585-1-t...@atomide.com/T/#u


This should restore it.

Regards,
Santosh

[GIT PULL 1/2] soc: TI drivers updates for v5.8

2020-05-27 Thread Santosh Shilimkar

The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:

  Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git 
tags/drivers_soc_for_5.8

for you to fetch changes up to b8b38a8e3cae100f292d756e32c78ab288db8a7d:

  drivers: soc: ti: knav_qmss_queue: Make knav_gp_range_ops static (2020-05-27 
20:39:14 -0700)


soc: ARM TI update for v5.8

 - Platform chipid driver support and associated dts doc update
 - Sparse warning fix in Navigator driver


Grygorii Strashko (2):
  dt-bindings: soc: ti: add binding for k3 platforms chipid module
  soc: ti: add k3 platforms chipid module driver

Samuel Zou (1):
  drivers: soc: ti: knav_qmss_queue: Make knav_gp_range_ops static

 .../devicetree/bindings/soc/ti/k3-socinfo.yaml |  40 ++
 drivers/soc/ti/Kconfig |  10 ++
 drivers/soc/ti/Makefile|   1 +
 drivers/soc/ti/k3-socinfo.c| 152 +
 drivers/soc/ti/knav_qmss_queue.c   |   2 +-
 5 files changed, 204 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
 create mode 100644 drivers/soc/ti/k3-socinfo.c

[GIT PULL 2/2] ARM: DTS: Keystone update for v5.8

2020-05-27 Thread Santosh Shilimkar

The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:

  Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git 
tags/keystone_dts_for_5.8

for you to fetch changes up to 644c5a582261ecdf1df41b11d05d10a10a66:

  ARM: dts: keystone: Rename "msmram" node to "sram" (2020-05-27 20:36:32 -0700)


ARM: dts: Keystone update for v5.8

 - Rename "msmram" node to "sram"


Krzysztof Kozlowski (1):
  ARM: dts: keystone: Rename "msmram" node to "sram"

 arch/arm/boot/dts/keystone-k2e.dtsi  | 4 ++--
 arch/arm/boot/dts/keystone-k2g.dtsi  | 4 ++--
 arch/arm/boot/dts/keystone-k2hk.dtsi | 4 ++--
 arch/arm/boot/dts/keystone-k2l.dtsi  | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

Re: [PATCH] rds: fix crash in rds_info_getsockopt()

2020-05-20 Thread santosh . shilimkar


On 5/20/20 12:41 PM, John Hubbard wrote:

The conversion to pin_user_pages() had a bug: it overlooked
the case of allocation of pages failing. Fix that by restoring
an equivalent check.

Reported-by: syzbot+118ac0af4ac7f785a...@syzkaller.appspotmail.com
Fixes: dbfe7d74376e ("rds: convert get_user_pages() --> pin_user_pages()")

Cc: David S. Miller 
Cc: Jakub Kicinski 
Cc: net...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc: rds-de...@oss.oracle.com
Signed-off-by: John Hubbard 
---

Thanks John !!

Acked-by: Santosh Shilimkar

Re: [PATCH 1/1] soc: ti: omap-prm: use atomic iopoll instead of sleeping one

2020-05-19 Thread santosh . shilimkar


On 5/19/20 10:45 AM, Tony Lindgren wrote:

* Tero Kristo  [200514 00:38]:

The reset handling APIs for omap-prm can be invoked PM runtime which
runs in atomic context. For this to work properly, switch to atomic
iopoll version instead of the current which can sleep. Otherwise,
this throws a "BUG: scheduling while atomic" warning. Issue is seen
rather easily when CONFIG_PREEMPT is enabled.

Signed-off-by: Tero Kristo 


Santosh do you want me to pick this for fixes?


Sure Tony. Thanks !!

Acked-by: Santosh Shilimkar

Re: [PATCH v2 0/2] soc: ti: add k3 platforms chipid module driver

2020-05-05 Thread santosh . shilimkar





On 5/5/20 12:34 PM, Grygorii Strashko wrote:

Hi All,

This series introduces TI K3 Multicore SoC platforms chipid module driver
which provides identification support of the TI K3 SoCs (family, revision)
and register this information with the SoC bus. It is available under
/sys/devices/soc0/ for user space, and can be checked, where needed,
in Kernel using soc_device_match().
It is also required for introducing support for new revisions of
K3 AM65x/J721E SoCs.

Example J721E:
   # cat /sys/devices/soc0/{machine,family,revision}
   Texas Instruments K3 J721E SoC
   J721E
   SR1.0

Example AM65x:
   # cat /sys/devices/soc0/{machine,family,revision}
   Texas Instruments AM654 Base Board
   AM65X
   SR1.0

Changes in v2:
  - pr_debug() replaced with pr_info() to show SoC info on init
  - minor format change
  - split series on driver and platform changes
  - add Reviewed-by: Lokesh Vutla 

v1: https://lwn.net/Articles/818577/

Grygorii Strashko (2):
   dt-bindings: soc: ti: add binding for k3 platforms chipid module
   soc: ti: add k3 platforms chipid module driver


Need ack from DT maintainers on bindings.

Regards,
Santosh

Re: [PATCH 0/5] soc: ti: add k3 platforms chipid module driver

2020-05-01 Thread santosh . shilimkar


On 5/1/20 1:55 PM, Grygorii Strashko wrote:

Hi Santosh, Tero

On 23/04/2020 21:05, Grygorii Strashko wrote:

Hi All,

This series introduces TI K3 Multicore SoC platforms chipid module driver
which provides identification support of the TI K3 SoCs (family, 
revision)

and register this information with the SoC bus. It is available under
/sys/devices/soc0/ for user space, and can be checked, where needed,
in Kernel using soc_device_match().
It is also required for introducing support for new revisions of
K3 AM65x/J721E SoCs.

Example J721E:
   # cat /sys/devices/soc0/{machine,family,revision}
   Texas Instruments K3 J721E SoC
   J721E
   SR1.0

Example AM65x:
   # cat /sys/devices/soc0/{machine,family,revision}
   Texas Instruments AM654 Base Board
   AM65X
   SR1.0

Grygorii Strashko (5):
   dt-bindings: soc: ti: add binding for k3 platforms chipid module
   soc: ti: add k3 platforms chipid module driver
   arm64: arch_k3: enable chipid driver
   arm64: dts: ti: k3-am65-wakeup: add k3 platforms chipid module node
   arm64: dts: ti: k3-j721e-mcu-wakeup: add k3 platforms chipid module
 node

  .../bindings/soc/ti/k3-socinfo.yaml   |  40 ++
  arch/arm64/Kconfig.platforms  |   1 +
  arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi    |   5 +
  .../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi  |   5 +
  drivers/soc/ti/Kconfig    |  10 ++
  drivers/soc/ti/Makefile   |   1 +
  drivers/soc/ti/k3-socinfo.c   | 135 ++
  7 files changed, 197 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml

  create mode 100644 drivers/soc/ti/k3-socinfo.c



Any more comments? I'm going resend it.

If you have acks from DT maintainers, then I suggest you to split this 
series and post platform and drivers patches separately.


Regards,
Santosh

Re: [PATCH 24/37] docs: networking: convert rds.txt to ReST

2020-04-30 Thread santosh . shilimkar


On 4/30/20 9:04 AM, Mauro Carvalho Chehab wrote:

- add SPDX header;
- add a document title;
- mark code blocks and literals as such;
- mark tables as such;
- mark lists as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.

Signed-off-by: Mauro Carvalho Chehab 
---

Acked-by: Santosh Shilimkar

Re: [PATCH v3 00/14] dmaengine/soc: Add Texas Instruments UDMA support

2019-10-04 Thread santosh . shilimkar


On 9/30/19 11:16 PM, Peter Ujfalusi wrote:

Hi,

Changes since v2
)https://patchwork.kernel.org/project/linux-dmaengine/list/?series=152609=*)
- Based on 5.4-rc1
- Support for Flow only data transfer for the glue layer





Grygorii Strashko (3):
   bindings: soc: ti: add documentation for k3 ringacc
   soc: ti: k3: add navss ringacc driver
   dmaengine: ti: k3-udma: Add glue layer for non DMAengine users

Peter Ujfalusi (11):
   dmaengine: doc: Add sections for per descriptor metadata support
   dmaengine: Add metadata_ops for dma_async_tx_descriptor
   dmaengine: Add support for reporting DMA cached data amount
   dmaengine: ti: Add cppi5 header for UDMA
   dt-bindings: dma: ti: Add document for K3 UDMA
   dmaengine: ti: New driver for K3 UDMA - split#1: defines, structs, io
 func
   dmaengine: ti: New driver for K3 UDMA - split#2: probe/remove, xlate
 and filter_fn
   dmaengine: ti: New driver for K3 UDMA - split#3: alloc/free
 chan_resources
   dmaengine: ti: New driver for K3 UDMA - split#4: dma_device callbacks
 1
   dmaengine: ti: New driver for K3 UDMA - split#5: dma_device callbacks
 2
   dmaengine: ti: New driver for K3 UDMA - split#6: Kconfig and Makefile

  .../devicetree/bindings/dma/ti/k3-udma.txt|  185 +
  .../devicetree/bindings/soc/ti/k3-ringacc.txt |   59 +
  Documentation/driver-api/dmaengine/client.rst |   75 +
  .../driver-api/dmaengine/provider.rst |   46 +
  drivers/dma/dmaengine.c   |   73 +
  drivers/dma/dmaengine.h   |8 +
  drivers/dma/ti/Kconfig|   22 +
  drivers/dma/ti/Makefile   |2 +
  drivers/dma/ti/k3-udma-glue.c | 1225 ++
  drivers/dma/ti/k3-udma-private.c  |  141 +
  drivers/dma/ti/k3-udma.c  | 3525 +
  drivers/dma/ti/k3-udma.h  |  161 +
  drivers/soc/ti/Kconfig|   12 +
  drivers/soc/ti/Makefile   |1 +
  drivers/soc/ti/k3-ringacc.c   | 1165 ++
  include/dt-bindings/dma/k3-udma.h |   10 +
  include/linux/dma/k3-udma-glue.h  |  134 +
  include/linux/dma/ti-cppi5.h  | 1049 +
  include/linux/dmaengine.h |  110 +
  include/linux/soc/ti/k3-ringacc.h |  245 ++
  20 files changed, 8248 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-udma.txt
  create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-ringacc.txt
  create mode 100644 drivers/dma/ti/k3-udma-glue.c
  create mode 100644 drivers/dma/ti/k3-udma-private.c
  create mode 100644 drivers/dma/ti/k3-udma.c
  create mode 100644 drivers/dma/ti/k3-udma.h
  create mode 100644 drivers/soc/ti/k3-ringacc.c
  create mode 100644 include/dt-bindings/dma/k3-udma.h
  create mode 100644 include/linux/dma/k3-udma-glue.h
  create mode 100644 include/linux/dma/ti-cppi5.h
  create mode 100644 include/linux/soc/ti/k3-ringacc.h


Can you please split this series and post drivers/soc/* bits
separately ?  If its ready, I can apply k3-ringacc.c changes.

Regards,
Santosh

Re: [PATCH 2/2] soc: ti: move 2 driver config options into the TI SOC drivers menu

2019-09-22 Thread santosh . shilimkar





On 9/21/19 1:46 PM, Randy Dunlap wrote:

Hi Santosh,

Would you also pick up patch 2/2, which I didn't Cc: you on?:(

Do I need to resend it?


Yes please. I don't have your 2/2

Re: [PATCH 1/2] soc: ti: big cleanup of Kconfig file

2019-09-19 Thread santosh . shilimkar


On 9/19/19 3:33 PM, Randy Dunlap wrote:

From: Randy Dunlap 

Cleanup drivers/soc/ti/Kconfig:
- delete duplicate words
- end sentences with '.'
- fix typos/spellos
- Subsystem is one word
- capitalize acronyms
- reflow lines to be <= 80 columns

Fixes: 41f93af900a2 ("soc: ti: add Keystone Navigator QMSS driver")
Fixes: 88139ed03058 ("soc: ti: add Keystone Navigator DMA support")
Fixes: afe761f8d3e9 ("soc: ti: Add pm33xx driver for basic suspend support")
Fixes: 5a99ae0092fe ("soc: ti: pm33xx: AM437X: Add rtc_only with ddr in self-refresh 
support")
Fixes: a869b7b30dac ("soc: ti: Add Support for AM654 SoC config option")
Fixes: cff377f7897a ("soc: ti: Add Support for J721E SoC config option")
Signed-off-by: Randy Dunlap 
Cc: Olof Johansson 
Cc: Santosh Shilimkar 
Cc: Sandeep Nair 
Cc: Dave Gerlach 
Cc: Keerthy 
Cc: Tony Lindgren 
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
@Santosh: MAINTAINERS says that you maintain drivers/soc/ti/*,
but there is more that Keystone-related code in that subdirectory
now... just in case you want to update that info.


Yes am aware there more drivers and so far I have been taking
care of everything in drivers/soc/ti/*


  drivers/soc/ti/Kconfig |   20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)


Patch looks fine to me. Do you want me to pick this up ?

Re: BUG: unable to handle kernel NULL pointer dereference in rds_bind

2019-09-16 Thread santosh . shilimkar


On 9/16/19 9:49 AM, Cong Wang wrote:

On Mon, Sep 16, 2019 at 6:29 AM syzbot
 wrote:


Hello,

syzbot found the following crash on:

HEAD commit:f4b752a6 mlx4: fix spelling mistake "veify" -> "verify"
git tree:   net
console output: https://syzkaller.appspot.com/x/log.txt?x=16cbebe660
kernel config:  https://syzkaller.appspot.com/x/.config?x=b89bb446a3faaba4
dashboard link: https://syzkaller.appspot.com/bug?extid=fae39afd2101a17ec624
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=10753bc160
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=111dfc1160

The bug was bisected to:

commit b9a1e627405d68d475a3c1f35e685ccfb5bbe668
Author: Cong Wang 
Date:   Thu Jul 4 00:21:13 2019 +

  hsr: implement dellink to clean up resources



The crash has nothing to do with this commit. It is probably caused
by the lack of ->laddr_check in rds_loop_transport.


Will have a look.

regards,
Santosh

Re: [RESEND PATCH next v2 0/6] ARM: keystone: update dt and enable cpts support

2019-09-05 Thread santosh . shilimkar


On 9/5/19 12:33 PM, Grygorii Strashko wrote:

Hi Santosh,

On 06/07/2019 02:48, santosh.shilim...@oracle.com wrote:

On 7/5/19 8:12 AM, Grygorii Strashko wrote:

Hi Santosh,

This series is set of platform changes required to enable NETCP CPTS 
reference
clock selection and final patch to enable CPTS for Keystone 
66AK2E/L/HK SoCs.


Those patches were posted already [1] together with driver's changes, 
so this
is re-send of DT/platform specific changes only, as driver's changes 
have

been merged already.

Patches 1-5: CPTS DT nodes update for TI Keystone 2 66AK2HK/E/L SoCs.
Patch 6: enables CPTS for TI Keystone 2 66AK2HK/E/L SoCs.

[1] https://patchwork.kernel.org/cover/10980037/

Grygorii Strashko (6):
   ARM: dts: keystone-clocks: add input fixed clocks
   ARM: dts: k2e-clocks: add input ext. fixed clocks tsipclka/b
   ARM: dts: k2e-netcp: add cpts refclk_mux node
   ARM: dts: k2hk-netcp: add cpts refclk_mux node
   ARM: dts: k2l-netcp: add cpts refclk_mux node
   ARM: configs: keystone: enable cpts


Will add these for 5.4 queue. Thanks !!


Sry, that I'm disturbing you, but I do not see those patches applied?


Sorry I missed this one. Will queue this up for next merge window.
Will push this out to next early once rc1 is out. If you don't
see it, please ping me.


Regards,
Santosh

Re: [GIT PULL] SOC: TI soc updates for 5.4

2019-09-04 Thread santosh . shilimkar


On 9/4/19 6:13 AM, Arnd Bergmann wrote:

On Tue, Aug 27, 2019 at 5:12 AM Santosh Shilimkar
 wrote:



soc: TI soc updates for 5.4

  -  Update firmware to support PM domain shared and exclusive support
  -  Update driver and dt binding docs for the same.



Lokesh Vutla (3):
   firmware: ti_sci: Allow for device shared and exclusive requests
   dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared
 access
   soc: ti: ti_sci_pm_domains: Add support for exclusive and shared
 access


Hi Santosh,

I noticed that your branch is based on top of v5.3-rc2, while my
arm/drivers branch started out from -rc1.

Do you have any dependencies on -rc2 in your changes? If not,
could you please resubmit after rebasing? I can also just
cherry-pick those three commits if that's easier.


No dependencies. Can you please cherry pick them this time ?
Will use rc1 for future pull request(s). Thanks !!

Regards,
Santosh

[GIT PULL] SOC: TI soc updates for 5.4

2019-08-26 Thread Santosh Shilimkar

The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b:

  Linux 5.3-rc2 (2019-07-28 12:47:02 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git 
tags/drivers_soc_for_5.4

for you to fetch changes up to 23013399a2252e9f592c2c52a62b213d3ef09217:

  soc: ti: ti_sci_pm_domains: Add support for exclusive and shared access 
(2019-08-26 20:00:41 -0700)


soc: TI soc updates for 5.4

 -  Update firmware to support PM domain shared and exclusive support
 -  Update driver and dt binding docs for the same.



Lokesh Vutla (3):
  firmware: ti_sci: Allow for device shared and exclusive requests
  dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared
access
  soc: ti: ti_sci_pm_domains: Add support for exclusive and shared
access

 .../devicetree/bindings/soc/ti/sci-pm-domain.txt   | 11 +-
 MAINTAINERS|  1 +
 drivers/firmware/ti_sci.c  | 45 +-
 drivers/soc/ti/ti_sci_pm_domains.c | 23 ++-
 include/dt-bindings/soc/ti,sci_pm_domain.h |  9 +
 include/linux/soc/ti/ti_sci_protocol.h |  3 ++
 6 files changed, 86 insertions(+), 6 deletions(-)
 create mode 100644 include/dt-bindings/soc/ti,sci_pm_domain.h

-- 
1.9.1

Re: [PATCH] net: rds: Fix possible null-pointer dereferences in rds_rdma_cm_event_handler_cmn()

2019-07-26 Thread santosh . shilimkar


On 7/26/19 7:17 AM, Jia-Ju Bai wrote:

In rds_rdma_cm_event_handler_cmn(), there are some if statements to
check whether conn is NULL, such as on lines 65, 96 and 112.
But conn is not checked before being used on line 108:
 trans->cm_connect_complete(conn, event);
and on lines 140-143:
 rdsdebug("DISCONNECT event - dropping connection "
 "%pI6c->%pI6c\n", >c_laddr,
 >c_faddr);
 rds_conn_drop(conn);

Thus, possible null-pointer dereferences may occur.

To fix these bugs, conn is checked before being used.

These bugs are found by a static analysis tool STCheck written by us.

Signed-off-by: Jia-Ju Bai 
---

That's possible. Looks good.

Acked-by: Santosh Shilimkar

Re: memory leak in rds_send_probe

2019-07-23 Thread santosh . shilimkar





On 7/23/19 9:19 AM, Dmitry Vyukov wrote:

On Tue, Jul 23, 2019 at 6:18 PM syzbot
 wrote:


Hello,

syzbot found the following crash on:

HEAD commit:c6dd78fc Merge branch 'x86-urgent-for-linus' of git://git...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14be98c860
kernel config:  https://syzkaller.appspot.com/x/.config?x=8de7d700ea5ac607
dashboard link: https://syzkaller.appspot.com/bug?extid=5134cdf021c4ed5aaa5f
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=145df0c860
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=170001f460


+net/rds/message.c maintainers


IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+5134cdf021c4ed5aa...@syzkaller.appspotmail.com

BUG: memory leak
unreferenced object 0x8881234e9c00 (size 512):


Thanks for reporting. We will look into it.


comm "kworker/u4:2", pid 286, jiffies 4294948041 (age 7.750s)
hex dump (first 32 bytes):
  01 00 00 00 00 00 00 00 08 9c 4e 23 81 88 ff ff  ..N#
  08 9c 4e 23 81 88 ff ff 18 9c 4e 23 81 88 ff ff  ..N#..N#
backtrace:
  [<32e378fa>] kmemleak_alloc_recursive
/./include/linux/kmemleak.h:43 [inline]
  [<32e378fa>] slab_post_alloc_hook /mm/slab.h:522 [inline]
  [<32e378fa>] slab_alloc /mm/slab.c:3319 [inline]
  [<32e378fa>] __do_kmalloc /mm/slab.c:3653 [inline]
  [<32e378fa>] __kmalloc+0x16d/0x2d0 /mm/slab.c:3664
  [<15bc9536>] kmalloc /./include/linux/slab.h:557 [inline]
  [<15bc9536>] kzalloc /./include/linux/slab.h:748 [inline]
  [<15bc9536>] rds_message_alloc+0x3e/0xc0 /net/rds/message.c:291
  [] rds_send_probe.constprop.0+0x42/0x2f0
/net/rds/send.c:1419
  [<794a00cc>] rds_send_pong+0x1e/0x23 /net/rds/send.c:1482
  [] rds_recv_incoming+0x27e/0x460 /net/rds/recv.c:343
  [] rds_loop_xmit+0x86/0x100 /net/rds/loop.c:96
  [] rds_send_xmit+0x524/0x9a0 /net/rds/send.c:355
  [<557b0101>] rds_send_worker+0x3c/0xd0 /net/rds/threads.c:200
  [<4ba94868>] process_one_work+0x23f/0x490
/kernel/workqueue.c:2269
  [] worker_thread+0x195/0x580 /kernel/workqueue.c:2415
  [<3ee8c1a1>] kthread+0x13e/0x160 /kernel/kthread.c:255
  [<4cd53c81>] ret_from_fork+0x1f/0x30
/arch/x86/entry/entry_64.S:352



---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

--
You received this message because you are subscribed to the Google Groups 
"syzkaller-bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to syzkaller-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/syzkaller-bugs/ad1dfe058e5b89ab%40google.com.

Re: [RESEND PATCH next v2 0/6] ARM: keystone: update dt and enable cpts support

2019-07-05 Thread santosh . shilimkar


On 7/5/19 8:12 AM, Grygorii Strashko wrote:

Hi Santosh,

This series is set of platform changes required to enable NETCP CPTS reference
clock selection and final patch to enable CPTS for Keystone 66AK2E/L/HK SoCs.

Those patches were posted already [1] together with driver's changes, so this
is re-send of DT/platform specific changes only, as driver's changes have
been merged already.

Patches 1-5: CPTS DT nodes update for TI Keystone 2 66AK2HK/E/L SoCs.
Patch 6: enables CPTS for TI Keystone 2 66AK2HK/E/L SoCs.

[1] https://patchwork.kernel.org/cover/10980037/

Grygorii Strashko (6):
   ARM: dts: keystone-clocks: add input fixed clocks
   ARM: dts: k2e-clocks: add input ext. fixed clocks tsipclka/b
   ARM: dts: k2e-netcp: add cpts refclk_mux node
   ARM: dts: k2hk-netcp: add cpts refclk_mux node
   ARM: dts: k2l-netcp: add cpts refclk_mux node
   ARM: configs: keystone: enable cpts


Will add these for 5.4 queue. Thanks !!

Regards,
Santosh

Re: [PATCH] soc: ti: fix irq-ti-sci link error

2019-07-01 Thread santosh . shilimkar


On 7/1/19 3:24 PM, Olof Johansson wrote:

On Mon, Jul 1, 2019 at 10:36 AM  wrote:


On 6/17/19 6:01 AM, Arnd Bergmann wrote:

The irqchip driver depends on the SoC specific driver, but we want
to be able to compile-test it elsewhere:

WARNING: unmet direct dependencies detected for TI_SCI_INTA_MSI_DOMAIN
Depends on [n]: SOC_TI [=n]
Selected by [y]:
- TI_SCI_INTA_IRQCHIP [=y] && TI_SCI_PROTOCOL [=y]

drivers/irqchip/irq-ti-sci-inta.o: In function `ti_sci_inta_irq_domain_probe':
irq-ti-sci-inta.c:(.text+0x204): undefined reference to 
`ti_sci_inta_msi_create_irq_domain'

Rearrange the Kconfig and Makefile so we build the soc driver whenever
its users are there, regardless of the SOC_TI option.

Fixes: 49b323157bf1 ("soc: ti: Add MSI domain bus support for Interrupt 
Aggregator")
Fixes: f011df6179bd ("irqchip/ti-sci-inta: Add msi domain support")
Signed-off-by: Arnd Bergmann 
---

Thanks Arnd. Will you be able to add it to your fixes queue.

FWIW, Acked-by: Santosh Shilimkar 


Cc:ing to a...@kernel.org is the best way to make sure it surfaces.

Also, please do Acked-by on separate line so the tools catch it next

Will do..


time (also, check for typos. :)


:- )


Applying to fixes.

Thanks for picking it up.

Re: [PATCH] soc: ti: fix irq-ti-sci link error

2019-07-01 Thread santosh . shilimkar


On 6/17/19 6:01 AM, Arnd Bergmann wrote:

The irqchip driver depends on the SoC specific driver, but we want
to be able to compile-test it elsewhere:

WARNING: unmet direct dependencies detected for TI_SCI_INTA_MSI_DOMAIN
   Depends on [n]: SOC_TI [=n]
   Selected by [y]:
   - TI_SCI_INTA_IRQCHIP [=y] && TI_SCI_PROTOCOL [=y]

drivers/irqchip/irq-ti-sci-inta.o: In function `ti_sci_inta_irq_domain_probe':
irq-ti-sci-inta.c:(.text+0x204): undefined reference to 
`ti_sci_inta_msi_create_irq_domain'

Rearrange the Kconfig and Makefile so we build the soc driver whenever
its users are there, regardless of the SOC_TI option.

Fixes: 49b323157bf1 ("soc: ti: Add MSI domain bus support for Interrupt 
Aggregator")
Fixes: f011df6179bd ("irqchip/ti-sci-inta: Add msi domain support")
Signed-off-by: Arnd Bergmann 
---

Thanks Arnd. Will you be able to add it to your fixes queue.

FWIW, Acked-by: Santosh Shilimkar

[GIT PULL] ARM: TI SOC updates for v5.3

2019-06-18 Thread Santosh Shilimkar

The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07:

  Linux 5.2-rc2 (2019-05-26 16:49:19 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git 
tags/drivers_soc_for_5.3

for you to fetch changes up to 4c960505df44b94001178575a505dd8315086edc:

  firmware: ti_sci: Fix gcc unused-but-set-variable warning (2019-06-18 
21:32:25 -0700)


SOC: TI SCI updates for v5.3

- Couple of fixes to handle resource ranges and
  requesting response always from firmware;
- Add processor control
- Add support APIs for DMA
- Fix the SPDX license plate
- Unused varible warning fix


Andrew F. Davis (1):
  firmware: ti_sci: Always request response from firmware

Nishad Kamdar (1):
  firmware: ti_sci: Use the correct style for SPDX License Identifier

Peter Ujfalusi (2):
  firmware: ti_sci: Add resource management APIs for ringacc, psi-l and udma
  firmware: ti_sci: Parse all resource ranges even if some is not available

Suman Anna (1):
  firmware: ti_sci: Add support for processor control

YueHaibing (1):
  firmware: ti_sci: Fix gcc unused-but-set-variable warning

 drivers/firmware/ti_sci.c  | 1143 +++-
 drivers/firmware/ti_sci.h  |  812 ++-
 include/linux/soc/ti/ti_sci_protocol.h |  246 +++
 3 files changed, 2051 insertions(+), 150 deletions(-)

Re: [PATCH] linux-next: DOC: RDS: Fix a typo in rds.txt

2019-06-12 Thread santosh . shilimkar


On 6/12/19 5:29 AM, Masanari Iida wrote:

This patch fixes a spelling typo in rds.txt

Signed-off-by: Masanari Iida 
---
  Documentation/networking/rds.txt | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/networking/rds.txt b/Documentation/networking/rds.txt
index 0235ae69af2a..f2a0147c933d 100644
--- a/Documentation/networking/rds.txt
+++ b/Documentation/networking/rds.txt
@@ -389,7 +389,7 @@ Multipath RDS (mprds)
a common (to all paths) part, and a per-path struct rds_conn_path. All
I/O workqs and reconnect threads are driven from the rds_conn_path.
Transports such as TCP that are multipath capable may then set up a
-  TPC socket per rds_conn_path, and this is managed by the transport via
+  TCP socket per rds_conn_path, and this is managed by the transport via
the transport privatee cp_transport_data pointer.
  
Transports announce themselves as multipath capable by setting the



Thanks !!

Acked-by: Santosh Shilimkar

Re: [PATCH] knav_qmss_queue: fix a missing-check bug in knav_pool_create()

2019-06-11 Thread santosh . shilimkar





On 6/11/19 3:08 AM, Gen Zhang wrote:

On Tue, Jun 11, 2019 at 10:54:15AM +0100, Marc Zyngier wrote:

Hi Gen,

No idea why I'm being cc'd on this but hey... ;-)

I copied email address ftom thid commit:-)
https://github.com/torvalds/linux/commit/832ad0e3da4510fd17f98804abe512ea9a747035#diff-f2a24befc247191f4b81af93e9336785


On 11/06/2019 10:37, Gen Zhang wrote:

On Thu, May 30, 2019 at 11:39:49AM +0800, Gen Zhang wrote:

In knav_pool_create(), 'pool->name' is allocated by kstrndup(). It
returns NULL when fails. So 'pool->name' should be checked. And free
'pool' when error.

Signed-off-by: Gen Zhang 
---
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 8b41837..0f8cb28 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -814,6 +814,12 @@ void *knav_pool_create(const char *name,
}
  
  	pool->name = kstrndup(name, KNAV_NAME_SIZE - 1, GFP_KERNEL);

+   if (!pool->name) {
+   dev_err(kdev->dev, "failed to duplicate for pool(%s)\n",
+   name);


There is no need to output anything, the kernel will be loud enough if
you run out of memory.

Thanks for your comments.



+   ret = -ENOMEM;
+   goto err_name;
+   }
pool->kdev = kdev;
pool->dev = kdev->dev;
  
@@ -864,6 +870,7 @@ void *knav_pool_create(const char *name,

mutex_unlock(_dev_lock);
  err:
kfree(pool->name);
+err_name:


kfree(NULL) is perfectly valid, there is no need to create a second
label. Just branch to the existing error label.

Sure, better not to add redundant codes.



devm_kfree(kdev->dev, pool);
return ERR_PTR(ret);
  }

Can anyone look into this patch?

Thanks
Gen



The real question is whether this is actually an error at all.
pool->name doesn't seem to be used for anything but debug information,
and the printing code can perfectly accommodate a NULL pointer.

That sounds reasonable. This patch just fixes a *theoretical* bug.


Not even theoretical bug.

Re: [PATCH] firmware: ti_sci: Add support for processor control

2019-06-10 Thread santosh . shilimkar





On 6/10/19 5:19 AM, Tero Kristo wrote:

On 08/06/2019 00:35, santosh.shilim...@oracle.com wrote:

On 6/5/19 3:33 PM, Suman Anna wrote:

Texas Instrument's System Control Interface (TI-SCI) Message Protocol
is used in Texas Instrument's System on Chip (SoC) such as those
in K3 family AM654 SoC to communicate between various compute
processors with a central system controller entity.

The system controller provides various services including the control
of other compute processors within the SoC. Extend the TI-SCI protocol
support to add various TI-SCI commands to invoke services associated
with power and reset control, and boot vector management of the
various compute processors from the Linux kernel.

Signed-off-by: Suman Anna 
---
Hi Santosh, Nishanth, Tero,

Appreciate it if this patch can be picked up for the 5.3 merge window.
This is a dependency patch for my various remoteproc drivers on TI K3
SoCs. Patch is on top of v5.2-rc1.


I will pick this up for 5.3.


Santosh,

There is a pile of drivers/firmware changes for ti-sci, which have cross 
dependencies, and will cause merge conflicts also as they touch same file.


Do you mind if I setup a pull-request for these all and send it to you? 
They are going to be on top of the keystone clock pull-request I just 
sent today though, otherwise it won't compile (the 32bit clock support 
has dependency towards the clock driver.)



That will be great Tero.

Regards,
Santosh

Re: [PATCH] firmware: ti_sci: Add support for processor control

2019-06-07 Thread santosh . shilimkar


On 6/5/19 3:33 PM, Suman Anna wrote:

Texas Instrument's System Control Interface (TI-SCI) Message Protocol
is used in Texas Instrument's System on Chip (SoC) such as those
in K3 family AM654 SoC to communicate between various compute
processors with a central system controller entity.

The system controller provides various services including the control
of other compute processors within the SoC. Extend the TI-SCI protocol
support to add various TI-SCI commands to invoke services associated
with power and reset control, and boot vector management of the
various compute processors from the Linux kernel.

Signed-off-by: Suman Anna 
---
Hi Santosh, Nishanth, Tero,

Appreciate it if this patch can be picked up for the 5.3 merge window.
This is a dependency patch for my various remoteproc drivers on TI K3
SoCs. Patch is on top of v5.2-rc1.


I will pick this up for 5.3.

Regards,
Santosh

[GIT PULL] soc: ti: couple of non critical fixes for v5.1

2019-02-01 Thread Santosh Shilimkar

The following changes since commit 1c7fc5cbc33980acd13d668f1c8f0313d6ae9fd8:

  Linux 5.0-rc2 (2019-01-14 10:41:12 +1200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git 
tags/drivers_soc_for_5.1

for you to fetch changes up to 2b13ef1f4261688c2dc5d67dbee69ed2fdddf53e:

  soc: ti: knav_dma: Use proper enum in pktdma_init_chan (2019-01-30 10:22:17 
-0800)


soc: ti: couple of non critical fixes for v5.1

 - Fix the Clang warning for enum in Navigator dma
 - Simplify code in ti_sci with DEFINE_SHOW_ATTRIBUTE macro


Nathan Chancellor (1):
  soc: ti: knav_dma: Use proper enum in pktdma_init_chan

Yangtao Li (1):
  firmware: ti_sci: Change to use DEFINE_SHOW_ATTRIBUTE macro

 drivers/firmware/ti_sci.c | 21 ++---
 drivers/soc/ti/knav_dma.c |  2 +-
 2 files changed, 3 insertions(+), 20 deletions(-)

Re: [PATCH] soc: ti: knav_dma: Use proper enum in pktdma_init_chan

2019-01-29 Thread Santosh Shilimkar


On 1/26/2019 11:11 AM, Nathan Chancellor wrote:

On Mon, Dec 10, 2018 at 05:41:14PM -0700, Nathan Chancellor wrote:

Clang warns when one enumerated type is implicitly converted to another:

drivers/soc/ti/knav_dma.c:601:20: warning: implicit conversion from
enumeration type 'enum dma_data_direction' to different enumeration type
'enum dma_transfer_direction' [-Wenum-conversion]
 chan->direction = DMA_NONE;
 ~ ^~~~
1 warning generated.

While DMA_NONE and DMA_TRANS_NONE have different values, there is no
functional change because direction is never checked against DMA_NONE,
only against DMA_MEM_TO_DEV and DMA_DEV_TO_MEM.

Signed-off-by: Nathan Chancellor 
---
  drivers/soc/ti/knav_dma.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
index e05ab16d9a9e..6285cd8efb21 100644
--- a/drivers/soc/ti/knav_dma.c
+++ b/drivers/soc/ti/knav_dma.c
@@ -598,7 +598,7 @@ static int pktdma_init_chan(struct knav_dma_device *dma,
  
  	INIT_LIST_HEAD(>list);

chan->dma= dma;
-   chan->direction  = DMA_NONE;
+   chan->direction  = DMA_TRANS_NONE;
atomic_set(>ref_count, 0);
spin_lock_init(>lock);
  
--

2.20.0



Ping?
I have marked this to picked up. Thanks !!

Re: [PATCH 1/4] ARM: omap2: avoid section mismatch warning

2018-12-10 Thread Santosh Shilimkar


On 12/10/2018 1:58 PM, Arnd Bergmann wrote:

WARNING: vmlinux.o(.text+0x27530): Section mismatch in reference from the 
function am43xx_suspend_init() to the function .init.text:am43xx_map_scu()
The function am43xx_suspend_init() references
the function __init am43xx_map_scu().
This is often because am43xx_suspend_init lacks a __init
annotation or the annotation of am43xx_map_scu is wrong.

Signed-off-by: Arnd Bergmann 
---

Acked-by: Santosh Shilimkar

Re: [PATCH] firmware: ti_sci: Change to use DEFINE_SHOW_ATTRIBUTE macro

2018-12-08 Thread Santosh Shilimkar


On 12/8/2018 8:04 AM, Nishanth Menon wrote:

On 09:05-20181122, Yangtao Li wrote:

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

Signed-off-by: Yangtao Li 


Thanks for the same and sorry for responding so late.

[...]

Santosh,
could you pick this up? maybe for next rev or so?

Reviewed-by: Nishanth Menon 


Sure !!

Re: omap5 fixing palmas IRQ_TYPE_NONE warning leads to gpadc timeouts

2018-11-26 Thread Santosh Shilimkar


On 11/26/2018 11:14 AM, Tony Lindgren wrote:

* Thierry Reding  [181126 10:14]:

On Mon, Nov 19, 2018 at 09:14:06AM -0800, Tony Lindgren wrote:

Well so commit 7e9d474954f4 ("ARM: tegra: Correct polarity for
Tegra114 PMIC interrupt") states that tegra114 inverts the
polarity of the PMIC interrupt. So adding Jon and Thierry to Cc.

So it seems that commit df545d1cd01a ("mfd: palmas: Provide
irq flags through DT/platform data") wrongly sets the
PALMAS_POLARITY_CTRL_INT_POLARITY on IRQ_TYPE_LEVEL_HIGH
while it should set it on IRQ_TYPE_LEVEL_LOW.


Oops, sorry, you seem to have come to pretty much the same conclusion as
I did. I think what we need to do is find a copy of the TRM and see what
exactly the right behaviour is. Or we need to find someone that can take
measurements of the PMIC interrupt pin.


Yeah so either tegra inverts the PMIC interrupt twice now,
or we have also omap5 wkupgen also inverting the PMIC interrupt
once.. Santosh, do you remember if omap5 wkupgen might be
inverting the palmas interrupt?


From the memory, omap5 wakeupgen doesn't invert the irqlines and
not anything specific to PMIC specially either.

Re: omap5 fixing palmas IRQ_TYPE_NONE warning leads to gpadc timeouts

2018-11-26 Thread Santosh Shilimkar


On 11/26/2018 11:14 AM, Tony Lindgren wrote:

* Thierry Reding  [181126 10:14]:

On Mon, Nov 19, 2018 at 09:14:06AM -0800, Tony Lindgren wrote:

Well so commit 7e9d474954f4 ("ARM: tegra: Correct polarity for
Tegra114 PMIC interrupt") states that tegra114 inverts the
polarity of the PMIC interrupt. So adding Jon and Thierry to Cc.

So it seems that commit df545d1cd01a ("mfd: palmas: Provide
irq flags through DT/platform data") wrongly sets the
PALMAS_POLARITY_CTRL_INT_POLARITY on IRQ_TYPE_LEVEL_HIGH
while it should set it on IRQ_TYPE_LEVEL_LOW.


Oops, sorry, you seem to have come to pretty much the same conclusion as
I did. I think what we need to do is find a copy of the TRM and see what
exactly the right behaviour is. Or we need to find someone that can take
measurements of the PMIC interrupt pin.


Yeah so either tegra inverts the PMIC interrupt twice now,
or we have also omap5 wkupgen also inverting the PMIC interrupt
once.. Santosh, do you remember if omap5 wkupgen might be
inverting the palmas interrupt?


From the memory, omap5 wakeupgen doesn't invert the irqlines and
not anything specific to PMIC specially either.

Re: [PATCH] soc: ti: wkup_m3: Add PRCM int16 as the wake up source

2018-11-13 Thread Santosh Shilimkar


On 11/11/2018 9:17 PM, Keerthy wrote:

Add PRCM int16 as the wake up source.

Signed-off-by: Keerthy 
---

Looks good.

Tony, Would you able to pick this up ?

Re: [PATCH] soc: ti: wkup_m3: Add PRCM int16 as the wake up source

2018-11-13 Thread Santosh Shilimkar


On 11/11/2018 9:17 PM, Keerthy wrote:

Add PRCM int16 as the wake up source.

Signed-off-by: Keerthy 
---

Looks good.

Tony, Would you able to pick this up ?

Re: [PATCH v2 09/10] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver


On 10/31/2018 11:42 AM, Marc Zyngier wrote:

On 31/10/18 18:38, Santosh Shilimkar wrote:

On 10/31/2018 11:21 AM, Marc Zyngier wrote:

Hi Grygorii,



[...]



Well, I'm convinced that we do not want a networking driver to be tied
to an interrupt architecture, and that the two should be completely
independent. But that's my own opinion. I can only see two solutions
moving forward:

1) You make the IA a real interrupt controller that exposes real
interrupts (one per event), and write your networking driver
independently of the underlying interrupt architecture.

2) you make the IA an integral part of your network driver, not exposing
anything outside of it, and limiting the interactions with the IR
*through the standard IRQ API*. You duplicate this knowledge throughout
the other client drivers.

I believe that (2) would be a massive design mistake as it locks the
driver to a single of the HW (and potentially a single revision of the
firmware) while (1) gives you the required level of flexibility by
hiding the whole event "concept" at a single location.

Yes, (1) makes you rewrite your existing, out of tree drivers. Oh well...


My preference is also not tie the network driver with IA. BTW, this is
very standard functionality with other network drivers too. And this
is handled using MSI-X.

So strong NO for 1) from me as well.


Err. Are you opposing to (1) or (2)? From the above, I cannot really
tell... ;-)


I mixed it up, sorry. I meant NO for (2), i.e No for making IA part of
the network driver.

Regards,
Santosh

Re: [PATCH v2 09/10] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver


On 10/31/2018 11:42 AM, Marc Zyngier wrote:

On 31/10/18 18:38, Santosh Shilimkar wrote:

On 10/31/2018 11:21 AM, Marc Zyngier wrote:

Hi Grygorii,



[...]



Well, I'm convinced that we do not want a networking driver to be tied
to an interrupt architecture, and that the two should be completely
independent. But that's my own opinion. I can only see two solutions
moving forward:

1) You make the IA a real interrupt controller that exposes real
interrupts (one per event), and write your networking driver
independently of the underlying interrupt architecture.

2) you make the IA an integral part of your network driver, not exposing
anything outside of it, and limiting the interactions with the IR
*through the standard IRQ API*. You duplicate this knowledge throughout
the other client drivers.

I believe that (2) would be a massive design mistake as it locks the
driver to a single of the HW (and potentially a single revision of the
firmware) while (1) gives you the required level of flexibility by
hiding the whole event "concept" at a single location.

Yes, (1) makes you rewrite your existing, out of tree drivers. Oh well...


My preference is also not tie the network driver with IA. BTW, this is
very standard functionality with other network drivers too. And this
is handled using MSI-X.

So strong NO for 1) from me as well.


Err. Are you opposing to (1) or (2)? From the above, I cannot really
tell... ;-)


I mixed it up, sorry. I meant NO for (2), i.e No for making IA part of
the network driver.

Regards,
Santosh

Re: [PATCH v2 09/10] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver


On 10/31/2018 11:21 AM, Marc Zyngier wrote:

Hi Grygorii,



[...]



Well, I'm convinced that we do not want a networking driver to be tied
to an interrupt architecture, and that the two should be completely
independent. But that's my own opinion. I can only see two solutions
moving forward:

1) You make the IA a real interrupt controller that exposes real
interrupts (one per event), and write your networking driver
independently of the underlying interrupt architecture.

2) you make the IA an integral part of your network driver, not exposing
anything outside of it, and limiting the interactions with the IR
*through the standard IRQ API*. You duplicate this knowledge throughout
the other client drivers.

I believe that (2) would be a massive design mistake as it locks the
driver to a single of the HW (and potentially a single revision of the
firmware) while (1) gives you the required level of flexibility by
hiding the whole event "concept" at a single location.

Yes, (1) makes you rewrite your existing, out of tree drivers. Oh well...


My preference is also not tie the network driver with IA. BTW, this is
very standard functionality with other network drivers too. And this
is handled using MSI-X.

So strong NO for 1) from me as well.

regards,
Santosh

Re: [PATCH v2 09/10] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver


On 10/31/2018 11:21 AM, Marc Zyngier wrote:

Hi Grygorii,



[...]



Well, I'm convinced that we do not want a networking driver to be tied
to an interrupt architecture, and that the two should be completely
independent. But that's my own opinion. I can only see two solutions
moving forward:

1) You make the IA a real interrupt controller that exposes real
interrupts (one per event), and write your networking driver
independently of the underlying interrupt architecture.

2) you make the IA an integral part of your network driver, not exposing
anything outside of it, and limiting the interactions with the IR
*through the standard IRQ API*. You duplicate this knowledge throughout
the other client drivers.

I believe that (2) would be a massive design mistake as it locks the
driver to a single of the HW (and potentially a single revision of the
firmware) while (1) gives you the required level of flexibility by
hiding the whole event "concept" at a single location.

Yes, (1) makes you rewrite your existing, out of tree drivers. Oh well...


My preference is also not tie the network driver with IA. BTW, this is
very standard functionality with other network drivers too. And this
is handled using MSI-X.

So strong NO for 1) from me as well.

regards,
Santosh

Re: [PATCH] soc: ti: QMSS: Fix usage of irq_set_affinity_hint


Hi Greg,

On 10/30/2018 4:11 AM, Marc Zyngier wrote:

The Keystone QMSS driver is pretty damaged, in the sense that it
does things like this:

irq_set_affinity_hint(irq, to_cpumask(_map));

where cpu_map is a local variable. As we leave the function, this
will point to nowhere-land, and things will end-up badly.

Instead, let's use a proper cpumask that gets allocated, giving
the driver a chance to actually work with things like irqbalance
as well as have a hypothetical 64bit future.

Signed-off-by: Marc Zyngier 
---
I found this one by inspection after finding a similar bug in an
unrelated driver. It is only compile-tested. It would probably
a Cc stable, but that's Santosh's decision.


Would be able to apply this fix from Marc for stable or it needs
to be re-posted with CC to stable ?



  drivers/soc/ti/knav_qmss.h   |  4 ++--
  drivers/soc/ti/knav_qmss_acc.c   | 10 +-
  drivers/soc/ti/knav_qmss_queue.c | 22 +++---
  3 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index 3efc47e82973..bd040c29c4bf 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -329,8 +329,8 @@ struct knav_range_ops {
  };
  
  struct knav_irq_info {

-   int irq;
-   u32 cpu_map;
+   int irq;
+   struct cpumask  *cpu_mask;
  };
  
  struct knav_range_info {

diff --git a/drivers/soc/ti/knav_qmss_acc.c b/drivers/soc/ti/knav_qmss_acc.c
index 316e82e46f6c..2f7fb2dcc1d6 100644
--- a/drivers/soc/ti/knav_qmss_acc.c
+++ b/drivers/soc/ti/knav_qmss_acc.c
@@ -205,18 +205,18 @@ static int knav_range_setup_acc_irq(struct 
knav_range_info *range,
  {
struct knav_device *kdev = range->kdev;
struct knav_acc_channel *acc;
-   unsigned long cpu_map;
+   struct cpumask *cpu_mask;
int ret = 0, irq;
u32 old, new;
  
  	if (range->flags & RANGE_MULTI_QUEUE) {

acc = range->acc;
irq = range->irqs[0].irq;
-   cpu_map = range->irqs[0].cpu_map;
+   cpu_mask = range->irqs[0].cpu_mask;
} else {
acc = range->acc + queue;
irq = range->irqs[queue].irq;
-   cpu_map = range->irqs[queue].cpu_map;
+   cpu_mask = range->irqs[queue].cpu_mask;
}
  
  	old = acc->open_mask;

@@ -239,8 +239,8 @@ static int knav_range_setup_acc_irq(struct knav_range_info 
*range,
acc->name, acc->name);
ret = request_irq(irq, knav_acc_int_handler, 0, acc->name,
  range);
-   if (!ret && cpu_map) {
-   ret = irq_set_affinity_hint(irq, to_cpumask(_map));
+   if (!ret && cpu_mask) {
+   ret = irq_set_affinity_hint(irq, cpu_mask);
if (ret) {
dev_warn(range->kdev->dev,
 "Failed to set IRQ affinity\n");
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index b5d5673c255c..8b418379272d 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -118,19 +118,17 @@ static int knav_queue_setup_irq(struct knav_range_info 
*range,
  struct knav_queue_inst *inst)
  {
unsigned queue = inst->id - range->queue_base;
-   unsigned long cpu_map;
int ret = 0, irq;
  
  	if (range->flags & RANGE_HAS_IRQ) {

irq = range->irqs[queue].irq;
-   cpu_map = range->irqs[queue].cpu_map;
ret = request_irq(irq, knav_queue_int_handler, 0,
inst->irq_name, inst);
if (ret)
return ret;
disable_irq(irq);
-   if (cpu_map) {
-   ret = irq_set_affinity_hint(irq, to_cpumask(_map));
+   if (range->irqs[queue].cpu_mask) {
+   ret = irq_set_affinity_hint(irq, 
range->irqs[queue].cpu_mask);
if (ret) {
dev_warn(range->kdev->dev,
 "Failed to set IRQ affinity\n");
@@ -1262,9 +1260,19 @@ static int knav_setup_queue_range(struct knav_device 
*kdev,
  
  		range->num_irqs++;
  
-		if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3)

-   range->irqs[i].cpu_map =
-   (oirq.args[2] & 0xff00) >> 8;
+   if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3) {
+   unsigned long mask;
+   int bit;
+
+   range->irqs[i].cpu_mask = devm_kzalloc(dev,
+  cpumask_size(), 
GFP_KERNEL);
+   if (!range->irqs[i].cpu_mask)
+   return -ENOMEM;
+
+   mask =

Re: [PATCH] soc: ti: QMSS: Fix usage of irq_set_affinity_hint


Hi Greg,

On 10/30/2018 4:11 AM, Marc Zyngier wrote:

The Keystone QMSS driver is pretty damaged, in the sense that it
does things like this:

irq_set_affinity_hint(irq, to_cpumask(_map));

where cpu_map is a local variable. As we leave the function, this
will point to nowhere-land, and things will end-up badly.

Instead, let's use a proper cpumask that gets allocated, giving
the driver a chance to actually work with things like irqbalance
as well as have a hypothetical 64bit future.

Signed-off-by: Marc Zyngier 
---
I found this one by inspection after finding a similar bug in an
unrelated driver. It is only compile-tested. It would probably
a Cc stable, but that's Santosh's decision.


Would be able to apply this fix from Marc for stable or it needs
to be re-posted with CC to stable ?



  drivers/soc/ti/knav_qmss.h   |  4 ++--
  drivers/soc/ti/knav_qmss_acc.c   | 10 +-
  drivers/soc/ti/knav_qmss_queue.c | 22 +++---
  3 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index 3efc47e82973..bd040c29c4bf 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -329,8 +329,8 @@ struct knav_range_ops {
  };
  
  struct knav_irq_info {

-   int irq;
-   u32 cpu_map;
+   int irq;
+   struct cpumask  *cpu_mask;
  };
  
  struct knav_range_info {

diff --git a/drivers/soc/ti/knav_qmss_acc.c b/drivers/soc/ti/knav_qmss_acc.c
index 316e82e46f6c..2f7fb2dcc1d6 100644
--- a/drivers/soc/ti/knav_qmss_acc.c
+++ b/drivers/soc/ti/knav_qmss_acc.c
@@ -205,18 +205,18 @@ static int knav_range_setup_acc_irq(struct 
knav_range_info *range,
  {
struct knav_device *kdev = range->kdev;
struct knav_acc_channel *acc;
-   unsigned long cpu_map;
+   struct cpumask *cpu_mask;
int ret = 0, irq;
u32 old, new;
  
  	if (range->flags & RANGE_MULTI_QUEUE) {

acc = range->acc;
irq = range->irqs[0].irq;
-   cpu_map = range->irqs[0].cpu_map;
+   cpu_mask = range->irqs[0].cpu_mask;
} else {
acc = range->acc + queue;
irq = range->irqs[queue].irq;
-   cpu_map = range->irqs[queue].cpu_map;
+   cpu_mask = range->irqs[queue].cpu_mask;
}
  
  	old = acc->open_mask;

@@ -239,8 +239,8 @@ static int knav_range_setup_acc_irq(struct knav_range_info 
*range,
acc->name, acc->name);
ret = request_irq(irq, knav_acc_int_handler, 0, acc->name,
  range);
-   if (!ret && cpu_map) {
-   ret = irq_set_affinity_hint(irq, to_cpumask(_map));
+   if (!ret && cpu_mask) {
+   ret = irq_set_affinity_hint(irq, cpu_mask);
if (ret) {
dev_warn(range->kdev->dev,
 "Failed to set IRQ affinity\n");
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index b5d5673c255c..8b418379272d 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -118,19 +118,17 @@ static int knav_queue_setup_irq(struct knav_range_info 
*range,
  struct knav_queue_inst *inst)
  {
unsigned queue = inst->id - range->queue_base;
-   unsigned long cpu_map;
int ret = 0, irq;
  
  	if (range->flags & RANGE_HAS_IRQ) {

irq = range->irqs[queue].irq;
-   cpu_map = range->irqs[queue].cpu_map;
ret = request_irq(irq, knav_queue_int_handler, 0,
inst->irq_name, inst);
if (ret)
return ret;
disable_irq(irq);
-   if (cpu_map) {
-   ret = irq_set_affinity_hint(irq, to_cpumask(_map));
+   if (range->irqs[queue].cpu_mask) {
+   ret = irq_set_affinity_hint(irq, 
range->irqs[queue].cpu_mask);
if (ret) {
dev_warn(range->kdev->dev,
 "Failed to set IRQ affinity\n");
@@ -1262,9 +1260,19 @@ static int knav_setup_queue_range(struct knav_device 
*kdev,
  
  		range->num_irqs++;
  
-		if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3)

-   range->irqs[i].cpu_map =
-   (oirq.args[2] & 0xff00) >> 8;
+   if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3) {
+   unsigned long mask;
+   int bit;
+
+   range->irqs[i].cpu_mask = devm_kzalloc(dev,
+  cpumask_size(), 
GFP_KERNEL);
+   if (!range->irqs[i].cpu_mask)
+   return -ENOMEM;
+
+   mask =

Re: [PATCH] soc: ti: QMSS: Fix usage of irq_set_affinity_hint


Hi Arnd, Olof,

On 10/30/2018 4:11 AM, Marc Zyngier wrote:

The Keystone QMSS driver is pretty damaged, in the sense that it
does things like this:

irq_set_affinity_hint(irq, to_cpumask(_map));

where cpu_map is a local variable. As we leave the function, this
will point to nowhere-land, and things will end-up badly.

Instead, let's use a proper cpumask that gets allocated, giving
the driver a chance to actually work with things like irqbalance
as well as have a hypothetical 64bit future.

Signed-off-by: Marc Zyngier 
---

Could you please add this patch to your fixes branch ?

FWIW,
Acked-by: Santosh Shilimkar

Re: [PATCH] soc: ti: QMSS: Fix usage of irq_set_affinity_hint


Hi Arnd, Olof,

On 10/30/2018 4:11 AM, Marc Zyngier wrote:

The Keystone QMSS driver is pretty damaged, in the sense that it
does things like this:

irq_set_affinity_hint(irq, to_cpumask(_map));

where cpu_map is a local variable. As we leave the function, this
will point to nowhere-land, and things will end-up badly.

Instead, let's use a proper cpumask that gets allocated, giving
the driver a chance to actually work with things like irqbalance
as well as have a hypothetical 64bit future.

Signed-off-by: Marc Zyngier 
---

Could you please add this patch to your fixes branch ?

FWIW,
Acked-by: Santosh Shilimkar

Re: [PATCH] soc: ti: QMSS: Fix usage of irq_set_affinity_hint


10/30/2018 4:11 AM, Marc Zyngier wrote:

The Keystone QMSS driver is pretty damaged, in the sense that it
does things like this:

irq_set_affinity_hint(irq, to_cpumask(_map));

where cpu_map is a local variable. As we leave the function, this
will point to nowhere-land, and things will end-up badly.

Instead, let's use a proper cpumask that gets allocated, giving
the driver a chance to actually work with things like irqbalance
as well as have a hypothetical 64bit future.

Signed-off-by: Marc Zyngier 
---

Thanks Marc for the fix. Will send note to arm-soc folks
to pick this up for fixes and also stable.

Regards,
Santosh

Re: [PATCH] soc: ti: QMSS: Fix usage of irq_set_affinity_hint