[PATCH] irqchip/gicv3-its: skip irq affinity setting when target cpu is the same as current setting

[Majun]

From: MaJun <majun...@huawei.com>

Just skip the irq affinity setting when the target cpu is the same as
current setting.
This is a small optimization for irq affinity setting logic.

Signed-off-by: MaJun <majun...@huawei.com>
---
 drivers/irqchip/irq-gic-v3-its.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 45ea1933..b335280 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -644,9 +644,12 @@ static int its_set_affinity(struct irq_data *d, const 
struct cpumask *mask_val,
if (cpu >= nr_cpu_ids)
return -EINVAL;
 
-   target_col = _dev->its->collections[cpu];
-   its_send_movi(its_dev, target_col, id);
-   its_dev->event_map.col_map[id] = cpu;
+   /* don't set the affinity when the target cpu is same as current one */
+   if (cpu != its_dev->event_map.col_map[id]) {
+   target_col = _dev->its->collections[cpu];
+   its_send_movi(its_dev, target_col, id);
+   its_dev->event_map.col_map[id] = cpu;
+   }
 
return IRQ_SET_MASK_OK_DONE;
 }
-- 
1.7.12.4

[PATCH] irqchip/gicv3-its: skip irq affinity setting when target cpu is the same as current setting

[Majun]

From: MaJun 

Just skip the irq affinity setting when the target cpu is the same as
current setting.
This is a small optimization for irq affinity setting logic.

Signed-off-by: MaJun 
---
 drivers/irqchip/irq-gic-v3-its.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 45ea1933..b335280 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -644,9 +644,12 @@ static int its_set_affinity(struct irq_data *d, const 
struct cpumask *mask_val,
if (cpu >= nr_cpu_ids)
return -EINVAL;
 
-   target_col = _dev->its->collections[cpu];
-   its_send_movi(its_dev, target_col, id);
-   its_dev->event_map.col_map[id] = cpu;
+   /* don't set the affinity when the target cpu is same as current one */
+   if (cpu != its_dev->event_map.col_map[id]) {
+   target_col = _dev->its->collections[cpu];
+   its_send_movi(its_dev, target_col, id);
+   its_dev->event_map.col_map[id] = cpu;
+   }
 
return IRQ_SET_MASK_OK_DONE;
 }
-- 
1.7.12.4

[tip:irq/urgent] irqchip/mbigen: Fix the clear register offset calculation

[tip-bot for MaJun]

Commit-ID:  9459a04b6a5a09967eec94a1b66f0a74312819d9
Gitweb: http://git.kernel.org/tip/9459a04b6a5a09967eec94a1b66f0a74312819d9
Author: MaJun <majun...@huawei.com>
AuthorDate: Fri, 12 May 2017 11:55:28 +0800
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Fri, 12 May 2017 10:25:38 +0200

irqchip/mbigen: Fix the clear register offset calculation

The register array offset for clearing an interrupt is calculated by:

offset = (hwirq - RESERVED_IRQ_PER_MBIGEN_CHIP) / 32;

This is wrong because the clear register array includes the reserved
interrupts. So the clear operation ends up in the wrong register.

This went unnoticed so far, because the hardware clears the real bit
through a timeout mechanism when the hardware is configured in debug
mode. That debug mode was enabled on early generations of the hardware, so
the problem was papered over.

On newer hardware with updated firmware the debug mode was disabled, so the
bits did not get cleared which causes the system to malfunction.

Remove the subtraction of RESERVED_IRQ_PER_MBIGEN_CHIP, so the correct
register is accessed.

[ tglx: Rewrote changelog ]

Fixes: a6c2f87b8820 ("irqchip/mbigen: Implement the mbigen irq chip operation 
functions")
Signed-off-by: MaJun <majun...@huawei.com>
Signed-off-by: Hanjun Guo <hanjun@linaro.org>
Acked-by: Marc Zyngier <marc.zyng...@arm.com>
Cc: Kefeng Wang <wangkefeng.w...@huawei.com>
Cc: linux...@huawei.com
Cc: Wei Yongjun <weiyongj...@huawei.com>
Link: 
http://lkml.kernel.org/r/1494561328-39514-4-git-send-email-guohan...@huawei.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>

---
 drivers/irqchip/irq-mbigen.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 2fa1e45..31d6b5a 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -106,10 +106,7 @@ static inline void get_mbigen_type_reg(irq_hw_number_t 
hwirq,
 static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
u32 *mask, u32 *addr)
 {
-   unsigned int ofst;
-
-   hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
-   ofst = hwirq / 32 * 4;
+   unsigned int ofst = (hwirq / 32) * 4;
 
*mask = 1 << (hwirq % 32);
*addr = ofst + REG_MBIGEN_CLEAR_OFFSET;

[tip:irq/urgent] irqchip/mbigen: Fix the clear register offset calculation

[tip-bot for MaJun]

Commit-ID:  9459a04b6a5a09967eec94a1b66f0a74312819d9
Gitweb: http://git.kernel.org/tip/9459a04b6a5a09967eec94a1b66f0a74312819d9
Author: MaJun 
AuthorDate: Fri, 12 May 2017 11:55:28 +0800
Committer:  Thomas Gleixner 
CommitDate: Fri, 12 May 2017 10:25:38 +0200

irqchip/mbigen: Fix the clear register offset calculation

The register array offset for clearing an interrupt is calculated by:

offset = (hwirq - RESERVED_IRQ_PER_MBIGEN_CHIP) / 32;

This is wrong because the clear register array includes the reserved
interrupts. So the clear operation ends up in the wrong register.

This went unnoticed so far, because the hardware clears the real bit
through a timeout mechanism when the hardware is configured in debug
mode. That debug mode was enabled on early generations of the hardware, so
the problem was papered over.

On newer hardware with updated firmware the debug mode was disabled, so the
bits did not get cleared which causes the system to malfunction.

Remove the subtraction of RESERVED_IRQ_PER_MBIGEN_CHIP, so the correct
register is accessed.

[ tglx: Rewrote changelog ]

Fixes: a6c2f87b8820 ("irqchip/mbigen: Implement the mbigen irq chip operation 
functions")
Signed-off-by: MaJun 
Signed-off-by: Hanjun Guo 
Acked-by: Marc Zyngier 
Cc: Kefeng Wang 
Cc: linux...@huawei.com
Cc: Wei Yongjun 
Link: 
http://lkml.kernel.org/r/1494561328-39514-4-git-send-email-guohan...@huawei.com
Signed-off-by: Thomas Gleixner 

---
 drivers/irqchip/irq-mbigen.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 2fa1e45..31d6b5a 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -106,10 +106,7 @@ static inline void get_mbigen_type_reg(irq_hw_number_t 
hwirq,
 static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
u32 *mask, u32 *addr)
 {
-   unsigned int ofst;
-
-   hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
-   ofst = hwirq / 32 * 4;
+   unsigned int ofst = (hwirq / 32) * 4;
 
*mask = 1 << (hwirq % 32);
*addr = ofst + REG_MBIGEN_CLEAR_OFFSET;

Re: [PATCH v2 0/3] irqchip/mbigen: bugfixs

[majun (Euler7)]

Hi Hanjun,
This patchset is fine to me and make my
D05 machine work again.So,

Tested-by: MaJun <majun...@huawei.com>

Thanks
Majun

在 2017/5/12 11:55, Hanjun Guo 写道:
> From: Hanjun Guo <hanjun@linaro.org>
> 
> Here are 3 bugfixes for mbigen:
> 
> Patch 1 is a critical bugfix which to fix the mbigen probe failure,
> commit 216646e4d82e ("irqchip/mbigen: Fix return value check in
> mbigen_device_probe()") introduced this breakage;
> 
> Patch 2 fixes a potential NULL dereferencing;
> 
> Patch 3 fixes a wrong clear register offset;
> 
> v1 -> v2:
>  - Rebase on top of lastest Linus tree (09d79d1 Merge tag
>'docs-4.12-2' of git://git.lwn.net/linux);
> 
>  - Fix a checkpatch error.
> 
> Thanks
> Hanjun
> 
> Hanjun Guo (2):
>   irqchip/mbigen: Fix memory mapping code
>   irqchip/mbigen: Fix potential NULL dereferencing
> 
> MaJun (1):
>   irqchip/mbigen: Fix the clear register offset
> 
>  drivers/irqchip/irq-mbigen.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 

Re: [PATCH v2 0/3] irqchip/mbigen: bugfixs

[majun (Euler7)]

Hi Hanjun,
This patchset is fine to me and make my
D05 machine work again.So,

Tested-by: MaJun 

Thanks
Majun

在 2017/5/12 11:55, Hanjun Guo 写道:
> From: Hanjun Guo 
> 
> Here are 3 bugfixes for mbigen:
> 
> Patch 1 is a critical bugfix which to fix the mbigen probe failure,
> commit 216646e4d82e ("irqchip/mbigen: Fix return value check in
> mbigen_device_probe()") introduced this breakage;
> 
> Patch 2 fixes a potential NULL dereferencing;
> 
> Patch 3 fixes a wrong clear register offset;
> 
> v1 -> v2:
>  - Rebase on top of lastest Linus tree (09d79d1 Merge tag
>'docs-4.12-2' of git://git.lwn.net/linux);
> 
>  - Fix a checkpatch error.
> 
> Thanks
> Hanjun
> 
> Hanjun Guo (2):
>   irqchip/mbigen: Fix memory mapping code
>   irqchip/mbigen: Fix potential NULL dereferencing
> 
> MaJun (1):
>   irqchip/mbigen: Fix the clear register offset
> 
>  drivers/irqchip/irq-mbigen.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 

Re: [PATCH] irqchip/mbigen: Fix the clear register offset

[majun (Euler7)]

Hi Marc:

在 2017/4/26 16:01, Marc Zyngier 写道:
> On 26/04/17 04:10, Hanjun Guo wrote:
>> Hi Majun,
>>
>> On 2017/4/25 10:16, Majun wrote:
>>> From: MaJun <majun...@huawei.com>
>>>
>>> Don't minus reserved interrupts (64) when get the clear register 
>>> offset,because
>>> the clear register space includes the space of these 64 interrupts.
>>
>> Could you mention the background that there is a timeout mechanism
>> to clear the register in the mbigen to make the code work even we clear
>> the wrong (and noneffective) register? that will help for review I
>> think.
> 
> A timeout? So if you don't clear the interrupt in a timely manner, it
> will still bypass the masking? That feels very wrong. How is this
> timeout configured? Can it be entirely disabled?

You are right. The timeout should be turn off usually, it's just a debug or
testing function in our chip. Because of configuration mistake in BIOS, this 
function
is turned on now and covered the bug in clear offset calculate.
Now, it's time to fix this.

Thanks
MaJun

> 
>>
>>>
>>> Signed-off-by: MaJun <majun...@huawei.com>
>>> ---
>>>  drivers/irqchip/irq-mbigen.c | 1 -
>>>  1 file changed, 1 deletion(-)
>>>
>>> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
>>> index 061cdb8..75818a5 100644
>>> --- a/drivers/irqchip/irq-mbigen.c
>>> +++ b/drivers/irqchip/irq-mbigen.c
>>> @@ -108,7 +108,6 @@ static inline void get_mbigen_clear_reg(irq_hw_number_t 
>>> hwirq,
>>>  {
>>> unsigned int ofst;
>>>
>>> -   hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
>>> ofst = hwirq / 32 * 4;
>>>
>>> *mask = 1 << (hwirq % 32);
>>
>> How about following to save more lines of code:
>>
>> --- a/drivers/irqchip/irq-mbigen.c
>> +++ b/drivers/irqchip/irq-mbigen.c
>> @@ -106,10 +106,7 @@ static inline void 
>> get_mbigen_type_reg(irq_hw_number_t hwirq,
>>   static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
>>  u32 *mask, u32 *addr)
>>   {
>> -   unsigned int ofst;
>> -
>> -   hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
>> -   ofst = hwirq / 32 * 4;
>> +   unsigned int ofst = hwirq / 32 * 4;
>>
>>  *mask = 1 << (hwirq % 32);
>>  *addr = ofst + REG_MBIGEN_CLEAR_OFFSET;
> 
> Well, this is not a code deletion contest... ;-)
> 
>   M.
> 

Re: [PATCH] irqchip/mbigen: Fix the clear register offset

[majun (Euler7)]

Hi Marc:

在 2017/4/26 16:01, Marc Zyngier 写道:
> On 26/04/17 04:10, Hanjun Guo wrote:
>> Hi Majun,
>>
>> On 2017/4/25 10:16, Majun wrote:
>>> From: MaJun 
>>>
>>> Don't minus reserved interrupts (64) when get the clear register 
>>> offset,because
>>> the clear register space includes the space of these 64 interrupts.
>>
>> Could you mention the background that there is a timeout mechanism
>> to clear the register in the mbigen to make the code work even we clear
>> the wrong (and noneffective) register? that will help for review I
>> think.
> 
> A timeout? So if you don't clear the interrupt in a timely manner, it
> will still bypass the masking? That feels very wrong. How is this
> timeout configured? Can it be entirely disabled?

You are right. The timeout should be turn off usually, it's just a debug or
testing function in our chip. Because of configuration mistake in BIOS, this 
function
is turned on now and covered the bug in clear offset calculate.
Now, it's time to fix this.

Thanks
MaJun

> 
>>
>>>
>>> Signed-off-by: MaJun 
>>> ---
>>>  drivers/irqchip/irq-mbigen.c | 1 -
>>>  1 file changed, 1 deletion(-)
>>>
>>> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
>>> index 061cdb8..75818a5 100644
>>> --- a/drivers/irqchip/irq-mbigen.c
>>> +++ b/drivers/irqchip/irq-mbigen.c
>>> @@ -108,7 +108,6 @@ static inline void get_mbigen_clear_reg(irq_hw_number_t 
>>> hwirq,
>>>  {
>>> unsigned int ofst;
>>>
>>> -   hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
>>> ofst = hwirq / 32 * 4;
>>>
>>> *mask = 1 << (hwirq % 32);
>>
>> How about following to save more lines of code:
>>
>> --- a/drivers/irqchip/irq-mbigen.c
>> +++ b/drivers/irqchip/irq-mbigen.c
>> @@ -106,10 +106,7 @@ static inline void 
>> get_mbigen_type_reg(irq_hw_number_t hwirq,
>>   static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
>>  u32 *mask, u32 *addr)
>>   {
>> -   unsigned int ofst;
>> -
>> -   hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
>> -   ofst = hwirq / 32 * 4;
>> +   unsigned int ofst = hwirq / 32 * 4;
>>
>>  *mask = 1 << (hwirq % 32);
>>  *addr = ofst + REG_MBIGEN_CLEAR_OFFSET;
> 
> Well, this is not a code deletion contest... ;-)
> 
>   M.
> 

[PATCH] irqchip/mbigen: Fix the clear register offset

[Majun]

From: MaJun <majun...@huawei.com>

Don't minus reserved interrupts (64) when get the clear register offset,because
the clear register space includes the space of these 64 interrupts.

Signed-off-by: MaJun <majun...@huawei.com>
---
 drivers/irqchip/irq-mbigen.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 061cdb8..75818a5 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -108,7 +108,6 @@ static inline void get_mbigen_clear_reg(irq_hw_number_t 
hwirq,
 {
unsigned int ofst;
 
-   hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
ofst = hwirq / 32 * 4;
 
*mask = 1 << (hwirq % 32);
-- 
1.7.12.4

[PATCH] irqchip/mbigen: Fix the clear register offset

[Majun]

From: MaJun 

Don't minus reserved interrupts (64) when get the clear register offset,because
the clear register space includes the space of these 64 interrupts.

Signed-off-by: MaJun 
---
 drivers/irqchip/irq-mbigen.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 061cdb8..75818a5 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -108,7 +108,6 @@ static inline void get_mbigen_clear_reg(irq_hw_number_t 
hwirq,
 {
unsigned int ofst;
 
-   hwirq -= RESERVED_IRQ_PER_MBIGEN_CHIP;
ofst = hwirq / 32 * 4;
 
*mask = 1 << (hwirq % 32);
-- 
1.7.12.4

Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT

[majun (Euler7)]

Hi Lorenzo:

在 2017/3/31 0:54, Lorenzo Pieralisi 写道:
> On Thu, Mar 30, 2017 at 05:14:34PM +0100, John Garry wrote:
>>
>>>>>>>
>>>>>>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
>>>>>>> this patch and post the resulting branch for everyone to have a final
>>>>>>> test.
[...]
>>>>
>>>> Thanks to all of you!
>>>> Tested on D05 board with this branch, the SAS disks and XGE port are 
>>>> working fine.
>>>
>>> Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull
>>> request to Catalin tomorrow, please carry out last few checks before
>>> I send it:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git 
>>> tags/acpi-arm64-for-v4.12
>>>
>>> You should try to merge it with Marc's branch:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git 
>>> irq/irqchip-4.12
>>>
>>> and test the resulting branch, that's how they will go upstream.
>>>
>>> Please let me know, thank you for your help !
>>>
>>
>> Hi Lorenzo,
>>
>> xuwei is away now, and it is night time with majun, so I tested.
>> majun can retest tomorrow again to triple-check. I did not touch the
>> ITS patch Marc made which had the weak version of
>> iort_pmis_get_dev_id(), but it should not affect anything in my
>> test.
>>
>> After merging your tag to Marc's branch, here is the git log:
>> git log --oneline
>> 8b6f3f8 Merge tag 'acpi-arm64-for-v4.12' into irq/irqchip-4.12
>> d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device
>> ae7c183 ACPI: platform-msi: retrieve devid from IORT
>> e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support
>> 8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
>> 697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic
>> d11349c irqchip: mbigen: Add ACPI support
>> aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain()
>> 964bac1 irqchip: mbigen: drop module owner
>> b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware
>> d264edb irqchip: gicv3-its: platform-msi: scan MADT to create
>> platform msi domain
>> baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init()
>> to prepare for ACPI
>> fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
>> cc9eb0d irqchip: gic-v3-its: keep the include header files in
>> alphabetic order
>> ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type
>> ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number
>> 3382357 dt-bindings: mediatek: multiple bases support for sysirq
>> 4015616 irqchip: replace moxa with ftintc010
>> 532278c irqchip: faraday: fix the trigger types
>> 923fa67 irqchip: refactor Gemini driver to reflect Faraday origin
>> 44d64ce irqchip: augment Gemini bindings to reflect Faraday origin
>> c02ed2e Linux 4.11-rc4
>>
>> And some testing:
>>
[...]
>>
>> Disk /dev/sdf: 186.3 GiB, 200049647616 bytes, 390721968 sectors
>> Units: sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 131072 bytes
>>
>> root@(none)$
>>
>> Looks ok
> 
> Great, thanks !
> 
>> @majun, please test as well.
> 
> Yes, final test, PR is ready to be sent, I reviewed Hanjun patches
> but I just want to avoid breaking them given that we had to carry
> out changes for the split PR.
> 
I tested these patches again as you suggested, all of the related devices，
xge/sas/usb/uart, are working fine on my hisilicon board just like before.

The git log is:
565fdf3 Merge tag 'acpi-arm64-for-v4.12' into marc-irq-4.12
d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device
ae7c183 ACPI: platform-msi: retrieve devid from IORT
e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support
8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic
d11349c irqchip: mbigen: Add ACPI support
aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain()
964bac1 irqchip: mbigen: drop module owner
b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware
d264edb irqchip: gicv3-its: platform-msi: scan MADT to create platform msi 
domain
baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare 
for ACPI
fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare(

Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT

[majun (Euler7)]

Hi Lorenzo:

在 2017/3/31 0:54, Lorenzo Pieralisi 写道:
> On Thu, Mar 30, 2017 at 05:14:34PM +0100, John Garry wrote:
>>
>>>>>>>
>>>>>>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
>>>>>>> this patch and post the resulting branch for everyone to have a final
>>>>>>> test.
[...]
>>>>
>>>> Thanks to all of you!
>>>> Tested on D05 board with this branch, the SAS disks and XGE port are 
>>>> working fine.
>>>
>>> Ma Jun and Wei Xu, I pushed out a signed tag in preparation for a pull
>>> request to Catalin tomorrow, please carry out last few checks before
>>> I send it:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git 
>>> tags/acpi-arm64-for-v4.12
>>>
>>> You should try to merge it with Marc's branch:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git 
>>> irq/irqchip-4.12
>>>
>>> and test the resulting branch, that's how they will go upstream.
>>>
>>> Please let me know, thank you for your help !
>>>
>>
>> Hi Lorenzo,
>>
>> xuwei is away now, and it is night time with majun, so I tested.
>> majun can retest tomorrow again to triple-check. I did not touch the
>> ITS patch Marc made which had the weak version of
>> iort_pmis_get_dev_id(), but it should not affect anything in my
>> test.
>>
>> After merging your tag to Marc's branch, here is the git log:
>> git log --oneline
>> 8b6f3f8 Merge tag 'acpi-arm64-for-v4.12' into irq/irqchip-4.12
>> d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device
>> ae7c183 ACPI: platform-msi: retrieve devid from IORT
>> e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support
>> 8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
>> 697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic
>> d11349c irqchip: mbigen: Add ACPI support
>> aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain()
>> 964bac1 irqchip: mbigen: drop module owner
>> b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware
>> d264edb irqchip: gicv3-its: platform-msi: scan MADT to create
>> platform msi domain
>> baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init()
>> to prepare for ACPI
>> fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
>> cc9eb0d irqchip: gic-v3-its: keep the include header files in
>> alphabetic order
>> ff3eeb4 irqchip: mtk-sysirq: prevent unnecessary visibility when set_type
>> ea04362 irqchip: mtk-sysirq: extend intpol base to arbitrary number
>> 3382357 dt-bindings: mediatek: multiple bases support for sysirq
>> 4015616 irqchip: replace moxa with ftintc010
>> 532278c irqchip: faraday: fix the trigger types
>> 923fa67 irqchip: refactor Gemini driver to reflect Faraday origin
>> 44d64ce irqchip: augment Gemini bindings to reflect Faraday origin
>> c02ed2e Linux 4.11-rc4
>>
>> And some testing:
>>
[...]
>>
>> Disk /dev/sdf: 186.3 GiB, 200049647616 bytes, 390721968 sectors
>> Units: sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 131072 bytes
>>
>> root@(none)$
>>
>> Looks ok
> 
> Great, thanks !
> 
>> @majun, please test as well.
> 
> Yes, final test, PR is ready to be sent, I reviewed Hanjun patches
> but I just want to avoid breaking them given that we had to carry
> out changes for the split PR.
> 
I tested these patches again as you suggested, all of the related devices，
xge/sas/usb/uart, are working fine on my hisilicon board just like before.

The git log is:
565fdf3 Merge tag 'acpi-arm64-for-v4.12' into marc-irq-4.12
d4f54a1 ACPI: platform: setup MSI domain for ACPI based platform device
ae7c183 ACPI: platform-msi: retrieve devid from IORT
e6db07d irqchip/gic-v3-its: Add IORT hook for platform MSI support
8ca4f1d ACPI/IORT: Introduce iort_node_map_platform_id() to retrieve dev id
697f609 ACPI/IORT: Rename iort_node_map_rid() to make it generic
d11349c irqchip: mbigen: Add ACPI support
aa15f11 irqchip: mbigen: introduce mbigen_of_create_domain()
964bac1 irqchip: mbigen: drop module owner
b8302fe msi: platform: make platform_msi_create_device_domain() ACPI aware
d264edb irqchip: gicv3-its: platform-msi: scan MADT to create platform msi 
domain
baf1168 irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare 
for ACPI
fbdda90 irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare(

Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT

[majun (Euler7)]

Hi all:

在 2017/3/30 11:07, Hanjun Guo 写道:
> On 03/30/2017 01:32 AM, Lorenzo Pieralisi wrote:
>> On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote:
>>> On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote:
>>>> On 29/03/17 14:00, Hanjun Guo wrote:
>>>>> On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:
>>>>>> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:
>>>>>>> Hi Lorenzo,
>>>>>>>
>>>>>>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:
>>>>>>>> Hi Hanjun, Marc,
>>>>>>>>
>>>>>>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
> [...]
>>>>>>>>>drivers/acpi/arm64/iort.c | 24 
>>>>>>>>> 
>>>>>>>>>drivers/irqchip/irq-gic-v3-its-platform-msi.c |  3 ++-
[...]
>>>>
>>>> Thoughts?
>>>
>>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
>>> this patch and post the resulting branch for everyone to have a final
>>> test.
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git 
>> acpi/arm64-acpi-4.12
>>
>> Please have a look and let me know if that's ok, I planned to send
>> a PR to Catalin by the end of the week (first 7 patches up to
>> 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform
>> device")).
> 
> Perfect for me too, Lorenzo, Marc, Thank you very much.
> 
> I'm currently in paternity leave and can't reach the machine,
> I had a detail review with the patches, they looks good to me,
> Ma Jun and Wei Xu will test on Hisilicon machines and give the
> feedback.

The sas/xge/uart are working fine on my hisilicon board with
Lorenzo's branch (arm64-acpi-4.12)

Thanks
Majun

> 
> Thanks
> Hanjun
> 
> .
> 

Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT

[majun (Euler7)]

Hi all:

在 2017/3/30 11:07, Hanjun Guo 写道:
> On 03/30/2017 01:32 AM, Lorenzo Pieralisi wrote:
>> On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote:
>>> On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote:
>>>> On 29/03/17 14:00, Hanjun Guo wrote:
>>>>> On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote:
>>>>>> On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote:
>>>>>>> Hi Lorenzo,
>>>>>>>
>>>>>>> On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote:
>>>>>>>> Hi Hanjun, Marc,
>>>>>>>>
>>>>>>>> On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote:
> [...]
>>>>>>>>>drivers/acpi/arm64/iort.c | 24 
>>>>>>>>> 
>>>>>>>>>drivers/irqchip/irq-gic-v3-its-platform-msi.c |  3 ++-
[...]
>>>>
>>>> Thoughts?
>>>
>>> Perfect for me. Hanjun, I can cherry pick Marc's patch above, rework
>>> this patch and post the resulting branch for everyone to have a final
>>> test.
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git 
>> acpi/arm64-acpi-4.12
>>
>> Please have a look and let me know if that's ok, I planned to send
>> a PR to Catalin by the end of the week (first 7 patches up to
>> 7fc3061df075 ("ACPI: platform: setup MSI domain for ACPI based platform
>> device")).
> 
> Perfect for me too, Lorenzo, Marc, Thank you very much.
> 
> I'm currently in paternity leave and can't reach the machine,
> I had a detail review with the patches, they looks good to me,
> Ma Jun and Wei Xu will test on Hisilicon machines and give the
> feedback.

The sas/xge/uart are working fine on my hisilicon board with
Lorenzo's branch (arm64-acpi-4.12)

Thanks
Majun

> 
> Thanks
> Hanjun
> 
> .
> 

Re: [Update][PATCH v9.1 15/15] irqchip: mbigen: Add ACPI support

[majun (Euler7)]

Hi hanjun:
This patch works fine on my D05 board.

Tested-by: MaJun <majun...@huawei.com>

Best Regards
Majun

在 2017/3/28 20:21, Hanjun Guo 写道:
> With the preparation of platform msi support and interrupt producer
> in commit d44fa3d46079 ("ACPI: Add support for ResourceSource/IRQ
> domain mapping"), we can add mbigen ACPI support now.
> 
> Now that the major framework changes are ready, we just need to add
> the ACPI probe code which creates the irqdomain for devices connecting
> to it.
> 
> In order to create the irqdomain, we need to know the number of hw
> irqs as input which is provided by mbigen. In DT case, we are using
> "num-pins" property to describe it, and we will take advantage of
> that too using _DSD in ACPI as there is no standard way of describe
> it in ACPI way, also according to the _DSD rule described in
> Documentation/acpi/DSD-properties-rules.txt, it doesn't break
> the rules.
> 
> The DSDT is represented as below:
> 
> For mbigen,
>   Device(MBI0) {
>   Name(_HID, "HISI0152")
>   Name(_UID, Zero)
>   Name(_CRS, ResourceTemplate() {
>   Memory32Fixed(ReadWrite, 0xa008, 0x1)
>   })
> 
>  Name(_DSD, Package () {
>  ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>  Package () {
>  Package () {"num-pins", 378}
>  }
> })
>  }
> 
> For devices,
>  Device(SAS0) {
>  Name(_HID, "HISI")
>  Name(_UID, Zero)
>  Name(_CRS, ResourceTemplate() {
>  Memory32Fixed(ReadWrite, 0xb003, 0x1)
>Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12, ...}
>  })
>  }
> 
> So for the devices connected to the mbigen, as we clearly say that
> it refers to a specific interrupt controller (mbigen), we can get
> the virq from mbigen's irqdomain once it's created successfully.
> 
> Signed-off-by: Hanjun Guo <hanjun@linaro.org>
> Signed-off-by: MaJun <majun...@huawei.com>
> Cc: Al Stone <a...@redhat.com>
> Cc: Darren Hart <dvh...@infradead.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieral...@arm.com>
> Cc: Marc Zyngier <marc.zyng...@arm.com>
> ---
>  drivers/irqchip/irq-mbigen.c | 75 
> ++--
>  1 file changed, 72 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index 3756408..061cdb8 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -16,6 +16,7 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
>   unsigned long *hwirq,
>   unsigned int *type)
>  {
> - if (is_of_node(fwspec->fwnode)) {
> + if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) {
>   if (fwspec->param_count != 2)
>   return -EINVAL;
>  
> @@ -271,6 +272,58 @@ static int mbigen_of_create_domain(struct 
> platform_device *pdev,
>   return 0;
>  }
>  
> +#ifdef CONFIG_ACPI
> +static int mbigen_acpi_create_domain(struct platform_device *pdev,
> +  struct mbigen_device *mgn_chip)
> +{
> + struct irq_domain *domain;
> + u32 num_pins = 0;
> + int ret;
> +
> + /*
> +  * "num-pins" is the total number of interrupt pins implemented in
> +  * this mbigen instance, and mbigen is an interrupt controller
> +  * connected to ITS  converting wired interrupts into MSI, so we
> +  * use "num-pins" to alloc MSI vectors which are needed by client
> +  * devices connected to it.
> +  *
> +  * Here is the DSDT device node used for mbigen in firmware:
> +  *  Device(MBI0) {
> +  *  Name(_HID, "HISI0152")
> +  *  Name(_UID, Zero)
> +  *  Name(_CRS, ResourceTemplate() {
> +  *  Memory32Fixed(ReadWrite, 0xa008, 0x1)
> +  *  })
> +  *
> +  *  Name(_DSD, Package () {
> +  *  ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> +  *  Package () {
> +  *  Package () {"num-pins", 378}
> +  *  }
> +  *  })
>

Re: [Update][PATCH v9.1 15/15] irqchip: mbigen: Add ACPI support

[majun (Euler7)]

Hi hanjun:
This patch works fine on my D05 board.

Tested-by: MaJun 

Best Regards
Majun

在 2017/3/28 20:21, Hanjun Guo 写道:
> With the preparation of platform msi support and interrupt producer
> in commit d44fa3d46079 ("ACPI: Add support for ResourceSource/IRQ
> domain mapping"), we can add mbigen ACPI support now.
> 
> Now that the major framework changes are ready, we just need to add
> the ACPI probe code which creates the irqdomain for devices connecting
> to it.
> 
> In order to create the irqdomain, we need to know the number of hw
> irqs as input which is provided by mbigen. In DT case, we are using
> "num-pins" property to describe it, and we will take advantage of
> that too using _DSD in ACPI as there is no standard way of describe
> it in ACPI way, also according to the _DSD rule described in
> Documentation/acpi/DSD-properties-rules.txt, it doesn't break
> the rules.
> 
> The DSDT is represented as below:
> 
> For mbigen,
>   Device(MBI0) {
>   Name(_HID, "HISI0152")
>   Name(_UID, Zero)
>   Name(_CRS, ResourceTemplate() {
>   Memory32Fixed(ReadWrite, 0xa008, 0x1)
>   })
> 
>  Name(_DSD, Package () {
>  ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>  Package () {
>  Package () {"num-pins", 378}
>  }
> })
>  }
> 
> For devices,
>  Device(SAS0) {
>  Name(_HID, "HISI")
>  Name(_UID, Zero)
>  Name(_CRS, ResourceTemplate() {
>  Memory32Fixed(ReadWrite, 0xb003, 0x1)
>Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12, ...}
>  })
>  }
> 
> So for the devices connected to the mbigen, as we clearly say that
> it refers to a specific interrupt controller (mbigen), we can get
> the virq from mbigen's irqdomain once it's created successfully.
> 
> Signed-off-by: Hanjun Guo 
> Signed-off-by: MaJun 
> Cc: Al Stone 
> Cc: Darren Hart 
> Cc: Lorenzo Pieralisi 
> Cc: Marc Zyngier 
> ---
>  drivers/irqchip/irq-mbigen.c | 75 
> ++--
>  1 file changed, 72 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index 3756408..061cdb8 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -16,6 +16,7 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
>   unsigned long *hwirq,
>   unsigned int *type)
>  {
> - if (is_of_node(fwspec->fwnode)) {
> + if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) {
>   if (fwspec->param_count != 2)
>   return -EINVAL;
>  
> @@ -271,6 +272,58 @@ static int mbigen_of_create_domain(struct 
> platform_device *pdev,
>   return 0;
>  }
>  
> +#ifdef CONFIG_ACPI
> +static int mbigen_acpi_create_domain(struct platform_device *pdev,
> +  struct mbigen_device *mgn_chip)
> +{
> + struct irq_domain *domain;
> + u32 num_pins = 0;
> + int ret;
> +
> + /*
> +  * "num-pins" is the total number of interrupt pins implemented in
> +  * this mbigen instance, and mbigen is an interrupt controller
> +  * connected to ITS  converting wired interrupts into MSI, so we
> +  * use "num-pins" to alloc MSI vectors which are needed by client
> +  * devices connected to it.
> +  *
> +  * Here is the DSDT device node used for mbigen in firmware:
> +  *  Device(MBI0) {
> +  *  Name(_HID, "HISI0152")
> +  *  Name(_UID, Zero)
> +  *  Name(_CRS, ResourceTemplate() {
> +  *  Memory32Fixed(ReadWrite, 0xa008, 0x1)
> +  *  })
> +  *
> +  *  Name(_DSD, Package () {
> +  *  ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> +  *  Package () {
> +  *  Package () {"num-pins", 378}
> +  *  }
> +  *  })
> +  *  }
> +  */
> + ret = device_property_read_u32(>dev, "num-pins", _pins);
> + if (ret || num_pins == 0)
> + return -EINVAL

Re: [PATCH v5 00/14] ACPI platform MSI support and its example mbigen

[majun (Euler7)]

Hi:

在 2016/12/26 16:57, majun (Euler7) 写道:
> Hi Hanjun:
>   This patch set works fine on my Hisilicon D05 board.
> Feel free to add

Based on the Patch 1/3, 2/3 of [PATCH V9 0/3] irqchip: qcom: Add IRQ combiner 
driver
from Agustin Vega-Frias

https://lwn.net/Articles/709222/

>   Tested-by: Majun <majun...@huawei.com>
> 
> 在 2016/12/22 13:35, Hanjun Guo 写道:
>> From: Hanjun Guo <hanjun@linaro.org>
>>
>> v4 -> v5:
>>  - Add mbigen support back with tested on with Agustin's patchset,
>>and it's a good example of how ACPI platform MSI works
>>  - rebased on top of lastest Linus tree (commit 52bce91 splice: 
>> reinstate SIGPIPE/EPIPE handling)
>>
>> v3 -> v4:
>> - Drop mbi-gen patches to just submit platform msi support because
>>   will rebase mbi-gen patches on top of Agustin's patchset, and 
>> discusion
>>   is going there.
>> - Add a patch to support device topology such as NC(named componant, 
>> paltform device)
>>   ->SMMU->ITS which suggested by Lorenzo;
>> - rebased on top of Lorenzo's v9 of ACPI IORT ARM SMMU support;
>> - rebased on top of 4.9-rc7
>>
>> v2 -> v3:
>> - Drop RFC tag
>> - Rebase against v4.9-rc2 and Lorenzo's v6 of ACPI IORT ARM SMMU 
>> support [1]
>> - Add 3 cleanup patches (patch 1, 2, 3)
>> - Drop arch_init call patch from last version
>> - Introduce a callback for platform device to set msi domain
>> - Introduce a new API to get paltform device's domain instead of
>>   reusing the PCI one in previous version
>> - Add a patch to rework iort_node_get_id()
>>
>> [1]: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1251993.html
>>
>> v1 -> v2:
>> - Fix the bug of if multi Interrupt() resoures in single _PRS,
>>   we need to calculate all the irq numbers (I missed it in previous
>>   version);
>> - Rebased on Marc's irq/irqchip-4.9 branch and Lorenzo's v5
>>   SMMU patches (also Robin's SMMu patches)
>> - Add patch irqchip: mbigen: promote mbigen init.
>>
>> With platform msi support landed in the kernel, and the introduction
>> of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi
>> is ready, this patch set add few patches to enable the ACPI platform
>> msi support.
>>
>> For platform device connecting to ITS on arm platform, we have IORT
>> table with the named componant node to describe the mappings of paltform
>> device and ITS, so we can retrieve the dev id and find its parent
>> irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
>>
>> The fisrt 3 patches are cleanups;
>>
>> Patch 4,5 are refactoring its_pmsi_prepare() for both DT and ACPI
>> then retrieve the dev id from iort;
>>
>> Patch 6,7 to create platform msi domain to ACPI case which scanned
>> the MADT table;
>>
>> Patch 8,9,10,11 to setup the msi domain for platform device based
>> on IORT table.
>>
>> Patch 12,13,14 convert dt based mbigen driver to support ACPI.
>>
>> Teasted on Hisilicon D03/D05.
>>
>> Happy holidays!
>>
>> Thanks
>> Hanjun
>>
>> Hanjun Guo (12):
>>   ACPI: ARM64: IORT: minor cleanup for iort_match_node_callback()
>>   irqchip: gic-v3-its: keep the head file include in alphabetic order
>>   ACPI: ARM64: IORT: add missing comment for iort_dev_find_its_id()
>>   irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
>>   ACPI: platform-msi: retrieve dev id from IORT
>>   irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare
>> for ACPI
>>   irqchip: gicv3-its: platform-msi: scan MADT to create platform msi
>> domain
>>   ACPI: ARM64: IORT: rework iort_node_get_id()
>>   ACPI: platform: setup MSI domain for ACPI based platform device
>>   ACPI: ARM64: IORT: rework iort_node_get_id() for NC->SMMU->ITS case
>>   msi: platform: make platform_msi_create_device_domain() ACPI aware
>>   irqchip: mbigen: Add ACPI support
>>
>> Kefeng Wang (2):
>>   irqchip: mbigen: drop module owner
>>   irqchip: mbigen: introduce mbigen_of_create_domain()
>>
>>  drivers/acpi/acpi_platform.c  |  11 ++
>>  drivers/acpi/arm64/iort.c | 138 
>> --
>>  drivers/base/platform-msi.c   |   3 +-
>>  drivers/base/platform.c   |   3 +
>>  drivers/irqchip/irq-gic-v3-its-platform-msi.c | 106 +++-
>>  drivers/irqchip/irq-gic-v3-its.c  |   3 +-
>>  drivers/irqchip/irq-mbigen.c  | 109 
>>  include/linux/acpi_iort.h |  11 ++
>>  include/linux/platform_device.h   |   3 +
>>  9 files changed, 309 insertions(+), 78 deletions(-)
>>
> 
> 
> .
> 

Re: [PATCH v5 00/14] ACPI platform MSI support and its example mbigen

[majun (Euler7)]

Hi:

在 2016/12/26 16:57, majun (Euler7) 写道:
> Hi Hanjun:
>   This patch set works fine on my Hisilicon D05 board.
> Feel free to add

Based on the Patch 1/3, 2/3 of [PATCH V9 0/3] irqchip: qcom: Add IRQ combiner 
driver
from Agustin Vega-Frias

https://lwn.net/Articles/709222/

>   Tested-by: Majun 
> 
> 在 2016/12/22 13:35, Hanjun Guo 写道:
>> From: Hanjun Guo 
>>
>> v4 -> v5:
>>  - Add mbigen support back with tested on with Agustin's patchset,
>>and it's a good example of how ACPI platform MSI works
>>  - rebased on top of lastest Linus tree (commit 52bce91 splice: 
>> reinstate SIGPIPE/EPIPE handling)
>>
>> v3 -> v4:
>> - Drop mbi-gen patches to just submit platform msi support because
>>   will rebase mbi-gen patches on top of Agustin's patchset, and 
>> discusion
>>   is going there.
>> - Add a patch to support device topology such as NC(named componant, 
>> paltform device)
>>   ->SMMU->ITS which suggested by Lorenzo;
>> - rebased on top of Lorenzo's v9 of ACPI IORT ARM SMMU support;
>> - rebased on top of 4.9-rc7
>>
>> v2 -> v3:
>> - Drop RFC tag
>> - Rebase against v4.9-rc2 and Lorenzo's v6 of ACPI IORT ARM SMMU 
>> support [1]
>> - Add 3 cleanup patches (patch 1, 2, 3)
>> - Drop arch_init call patch from last version
>> - Introduce a callback for platform device to set msi domain
>> - Introduce a new API to get paltform device's domain instead of
>>   reusing the PCI one in previous version
>> - Add a patch to rework iort_node_get_id()
>>
>> [1]: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1251993.html
>>
>> v1 -> v2:
>> - Fix the bug of if multi Interrupt() resoures in single _PRS,
>>   we need to calculate all the irq numbers (I missed it in previous
>>   version);
>> - Rebased on Marc's irq/irqchip-4.9 branch and Lorenzo's v5
>>   SMMU patches (also Robin's SMMu patches)
>> - Add patch irqchip: mbigen: promote mbigen init.
>>
>> With platform msi support landed in the kernel, and the introduction
>> of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi
>> is ready, this patch set add few patches to enable the ACPI platform
>> msi support.
>>
>> For platform device connecting to ITS on arm platform, we have IORT
>> table with the named componant node to describe the mappings of paltform
>> device and ITS, so we can retrieve the dev id and find its parent
>> irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
>>
>> The fisrt 3 patches are cleanups;
>>
>> Patch 4,5 are refactoring its_pmsi_prepare() for both DT and ACPI
>> then retrieve the dev id from iort;
>>
>> Patch 6,7 to create platform msi domain to ACPI case which scanned
>> the MADT table;
>>
>> Patch 8,9,10,11 to setup the msi domain for platform device based
>> on IORT table.
>>
>> Patch 12,13,14 convert dt based mbigen driver to support ACPI.
>>
>> Teasted on Hisilicon D03/D05.
>>
>> Happy holidays!
>>
>> Thanks
>> Hanjun
>>
>> Hanjun Guo (12):
>>   ACPI: ARM64: IORT: minor cleanup for iort_match_node_callback()
>>   irqchip: gic-v3-its: keep the head file include in alphabetic order
>>   ACPI: ARM64: IORT: add missing comment for iort_dev_find_its_id()
>>   irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
>>   ACPI: platform-msi: retrieve dev id from IORT
>>   irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare
>> for ACPI
>>   irqchip: gicv3-its: platform-msi: scan MADT to create platform msi
>> domain
>>   ACPI: ARM64: IORT: rework iort_node_get_id()
>>   ACPI: platform: setup MSI domain for ACPI based platform device
>>   ACPI: ARM64: IORT: rework iort_node_get_id() for NC->SMMU->ITS case
>>   msi: platform: make platform_msi_create_device_domain() ACPI aware
>>   irqchip: mbigen: Add ACPI support
>>
>> Kefeng Wang (2):
>>   irqchip: mbigen: drop module owner
>>   irqchip: mbigen: introduce mbigen_of_create_domain()
>>
>>  drivers/acpi/acpi_platform.c  |  11 ++
>>  drivers/acpi/arm64/iort.c | 138 
>> --
>>  drivers/base/platform-msi.c   |   3 +-
>>  drivers/base/platform.c   |   3 +
>>  drivers/irqchip/irq-gic-v3-its-platform-msi.c | 106 +++-
>>  drivers/irqchip/irq-gic-v3-its.c  |   3 +-
>>  drivers/irqchip/irq-mbigen.c  | 109 
>>  include/linux/acpi_iort.h |  11 ++
>>  include/linux/platform_device.h   |   3 +
>>  9 files changed, 309 insertions(+), 78 deletions(-)
>>
> 
> 
> .
> 

Re: [PATCH v5 14/14] irqchip: mbigen: Add ACPI support

[majun (Euler7)]

Hi hanjun：

在 2016/12/22 13:35, Hanjun Guo 写道:
> From: Hanjun Guo <hanjun@linaro.org>
> 
> With the preparation of platform msi support and interrupt producer
> in DSDT, we can add mbigen ACPI support now.
> 
> We are using _PRS methd to indicate number of irq pins instead
> of num_pins in DT to avoid _DSD usage in this case.
> 
> For mbi-gen,
> Device(MBI0) {
>   Name(_HID, "HISI0152")
>   Name(_UID, Zero)
>   Name(_CRS, ResourceTemplate() {
>   Memory32Fixed(ReadWrite, 0xa008, 0x1)
>   })
> 
>   Name (_PRS, ResourceTemplate() {
> Interrupt(ResourceProducer,...) {12,14,}
>   })
> }
> 
> For devices,
> 
>Device(COM0) {
>   Name(_HID, "ACPIIDxx")
>   Name(_UID, Zero)
>   Name(_CRS, ResourceTemplate() {
>  Memory32Fixed(ReadWrite, 0xb003, 0x1)
>Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
>   })
> }
> 
> With the helpe of platform msi and interrupt producer, then devices
> will get the virq from mbi-gen's irqdomain.
> 
> Signed-off-by: Hanjun Guo <hanjun@linaro.org>
> Cc: Marc Zyngier <marc.zyng...@arm.com>
> Cc: Thomas Gleixner <t...@linutronix.de>
> Cc: Ma Jun <majun...@huawei.com>
> ---
>  drivers/irqchip/irq-mbigen.c | 70 
> ++--
>  1 file changed, 67 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index 4e11da5..17d35fa 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -16,6 +16,7 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
>   unsigned long *hwirq,
>   unsigned int *type)
>  {
> - if (is_of_node(fwspec->fwnode)) {
> + if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) {
>   if (fwspec->param_count != 2)
>   return -EINVAL;
>  
> @@ -271,6 +272,54 @@ static int mbigen_of_create_domain(struct 
> platform_device *pdev,
>   return 0;
>  }
>  
> +#ifdef CONFIG_ACPI
> +static acpi_status mbigen_acpi_process_resource(struct acpi_resource *ares,
> +  void *context)
> +{
> + struct acpi_resource_extended_irq *ext_irq;
> + u32 *num_irqs = context;
> +
> + switch (ares->type) {
> + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> + ext_irq = >data.extended_irq;
> + *num_irqs += ext_irq->interrupt_count;
> + break;
> + default:
> + break;
> + }
> +
> + return AE_OK;
> +}
> +
> +static int mbigen_acpi_create_domain(struct platform_device *pdev,
> +  struct mbigen_device *mgn_chip)
> +{
> + struct irq_domain *domain;
> + u32 num_msis = 0;
> + acpi_status status;
> +
> + status = acpi_walk_resources(ACPI_HANDLE(>dev), METHOD_NAME__PRS,
> +  mbigen_acpi_process_resource, _msis);
> +if (ACPI_FAILURE(status) || num_msis == 0)
> + return -EINVAL;
> +
> + domain = platform_msi_create_device_domain(>dev, num_msis,
> +mbigen_write_msg,
> +_domain_ops,
> +mgn_chip);
> + if (!domain)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +#else
> +static int mbigen_acpi_create_domain(struct platform_device *pdev,
> +  struct mbigen_device *mgn_chip)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
>  static int mbigen_device_probe(struct platform_device *pdev)
>  {
>   struct mbigen_device *mgn_chip;
> @@ -288,9 +337,17 @@ static int mbigen_device_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(mgn_chip->base))
>   return PTR_ERR(mgn_chip->base);
>  
> - err = mbigen_of_create_domain(pdev, mgn_chip);
> - if (err)
> + if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
> + err = mbigen_of_create_domain(pdev, mgn_chip);
> + else if (ACPI_COMPANION(>dev))
> + err = mbigen_acpi_create_domain(pdev, mgn_chip);
> + else
> +

Re: [PATCH v5 14/14] irqchip: mbigen: Add ACPI support

[majun (Euler7)]

 
> mgn_chip->base);
>   return err;
> + }
>  
>   platform_set_drvdata(pdev, mgn_chip);
>   return 0;
> @@ -302,10 +359,17 @@ static int mbigen_device_probe(struct platform_device 
> *pdev)
>  };
>  MODULE_DEVICE_TABLE(of, mbigen_of_match);
>  
> +static const struct acpi_device_id mbigen_acpi_match[] = {
> +{ "HISI0152", 0 },
> + {}
> +};
> +MODULE_DEVICE_TABLE(acpi, mbigen_acpi_match);
> +
>  static struct platform_driver mbigen_platform_driver = {
>   .driver = {
>   .name   = "Hisilicon MBIGEN-V2",
>   .of_match_table = mbigen_of_match,
> + .acpi_match_table = ACPI_PTR(mbigen_acpi_match),
>   },
>   .probe  = mbigen_device_probe,
>  };
> 
Reviewed-by: MaJun 

Re: [PATCH v5 13/14] irqchip: mbigen: introduce mbigen_of_create_domain()

[majun (Euler7)]

Hi hanjun：

在 2016/12/22 13:35, Hanjun Guo 写道:
> From: Kefeng Wang <wangkefeng.w...@huawei.com>
> 
> Introduce mbigen_of_create_domain() to consolidate OF related
> code and prepare for ACPI later, no funtional change.
> 
> Signed-off-by: Kefeng Wang <wangkefeng.w...@huawei.com>
> Signed-off-by: Hanjun Guo <hanjun@linaro.org>
> Cc: Marc Zyngier <marc.zyng...@arm.com>
> Cc: Thomas Gleixner <t...@linutronix.de>
> Cc: Ma Jun <majun...@huawei.com>
> ---
>  drivers/irqchip/irq-mbigen.c | 42 +++---
>  1 file changed, 27 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index c01ab41..4e11da5 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -236,27 +236,15 @@ static int mbigen_irq_domain_alloc(struct irq_domain 
> *domain,
>   .free   = irq_domain_free_irqs_common,
>  };
>  
> -static int mbigen_device_probe(struct platform_device *pdev)
> +static int mbigen_of_create_domain(struct platform_device *pdev,
> +struct mbigen_device *mgn_chip)
>  {
> - struct mbigen_device *mgn_chip;
> + struct device *parent;
>   struct platform_device *child;
>   struct irq_domain *domain;
>   struct device_node *np;
> - struct device *parent;
> - struct resource *res;
>   u32 num_pins;
>  
> - mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
> - if (!mgn_chip)
> - return -ENOMEM;
> -
> - mgn_chip->pdev = pdev;
> -
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - mgn_chip->base = devm_ioremap_resource(>dev, res);
> - if (IS_ERR(mgn_chip->base))
> - return PTR_ERR(mgn_chip->base);
> -
>   for_each_child_of_node(pdev->dev.of_node, np) {
>   if (!of_property_read_bool(np, "interrupt-controller"))
>   continue;
> @@ -280,6 +268,30 @@ static int mbigen_device_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>   }
>  
> + return 0;
> +}
> +
> +static int mbigen_device_probe(struct platform_device *pdev)
> +{
> + struct mbigen_device *mgn_chip;
> + struct resource *res;
> + int err;
> +
> + mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
> + if (!mgn_chip)
> + return -ENOMEM;
> +
> + mgn_chip->pdev = pdev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + mgn_chip->base = devm_ioremap(>dev, res->start, 
> resource_size(res));
> + if (IS_ERR(mgn_chip->base))
> + return PTR_ERR(mgn_chip->base);
> +
> + err = mbigen_of_create_domain(pdev, mgn_chip);
> + if (err)
> + return err;
> +
>   platform_set_drvdata(pdev, mgn_chip);
>   return 0;
>  }
> 
Reviewed-by: MaJun <majun...@huawei.com>

Re: [PATCH v5 12/14] irqchip: mbigen: drop module owner

[majun (Euler7)]

Hi hanjun：

在 2016/12/22 13:35, Hanjun Guo 写道:
> From: Kefeng Wang <wangkefeng.w...@huawei.com>
> 
> Module owner will be set by driver core, so drop it.
> 
> Signed-off-by: Kefeng Wang <wangkefeng.w...@huawei.com>
> Signed-off-by: Hanjun Guo <hanjun@linaro.org>
> Cc: Marc Zyngier <marc.zyng...@arm.com>
> Cc: Thomas Gleixner <t...@linutronix.de>
> Cc: Ma Jun <majun...@huawei.com>
> ---
>  drivers/irqchip/irq-mbigen.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index 03b79b0..c01ab41 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -293,7 +293,6 @@ static int mbigen_device_probe(struct platform_device 
> *pdev)
>  static struct platform_driver mbigen_platform_driver = {
>   .driver = {
>   .name   = "Hisilicon MBIGEN-V2",
> - .owner  = THIS_MODULE,
>   .of_match_table = mbigen_of_match,
>   },
>   .probe  = mbigen_device_probe,
> 

Reviewed-by: MaJun <majun...@huawei.com>

Re: [PATCH v5 13/14] irqchip: mbigen: introduce mbigen_of_create_domain()

[majun (Euler7)]

Hi hanjun：

在 2016/12/22 13:35, Hanjun Guo 写道:
> From: Kefeng Wang 
> 
> Introduce mbigen_of_create_domain() to consolidate OF related
> code and prepare for ACPI later, no funtional change.
> 
> Signed-off-by: Kefeng Wang 
> Signed-off-by: Hanjun Guo 
> Cc: Marc Zyngier 
> Cc: Thomas Gleixner 
> Cc: Ma Jun 
> ---
>  drivers/irqchip/irq-mbigen.c | 42 +++---
>  1 file changed, 27 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index c01ab41..4e11da5 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -236,27 +236,15 @@ static int mbigen_irq_domain_alloc(struct irq_domain 
> *domain,
>   .free   = irq_domain_free_irqs_common,
>  };
>  
> -static int mbigen_device_probe(struct platform_device *pdev)
> +static int mbigen_of_create_domain(struct platform_device *pdev,
> +struct mbigen_device *mgn_chip)
>  {
> - struct mbigen_device *mgn_chip;
> + struct device *parent;
>   struct platform_device *child;
>   struct irq_domain *domain;
>   struct device_node *np;
> - struct device *parent;
> - struct resource *res;
>   u32 num_pins;
>  
> - mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
> - if (!mgn_chip)
> - return -ENOMEM;
> -
> - mgn_chip->pdev = pdev;
> -
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - mgn_chip->base = devm_ioremap_resource(>dev, res);
> - if (IS_ERR(mgn_chip->base))
> - return PTR_ERR(mgn_chip->base);
> -
>   for_each_child_of_node(pdev->dev.of_node, np) {
>   if (!of_property_read_bool(np, "interrupt-controller"))
>   continue;
> @@ -280,6 +268,30 @@ static int mbigen_device_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>   }
>  
> + return 0;
> +}
> +
> +static int mbigen_device_probe(struct platform_device *pdev)
> +{
> + struct mbigen_device *mgn_chip;
> + struct resource *res;
> + int err;
> +
> + mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
> + if (!mgn_chip)
> + return -ENOMEM;
> +
> + mgn_chip->pdev = pdev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + mgn_chip->base = devm_ioremap(>dev, res->start, 
> resource_size(res));
> + if (IS_ERR(mgn_chip->base))
> + return PTR_ERR(mgn_chip->base);
> +
> + err = mbigen_of_create_domain(pdev, mgn_chip);
> + if (err)
> + return err;
> +
>   platform_set_drvdata(pdev, mgn_chip);
>   return 0;
>  }
> 
Reviewed-by: MaJun 

Re: [PATCH v5 12/14] irqchip: mbigen: drop module owner

[majun (Euler7)]

Hi hanjun：

在 2016/12/22 13:35, Hanjun Guo 写道:
> From: Kefeng Wang 
> 
> Module owner will be set by driver core, so drop it.
> 
> Signed-off-by: Kefeng Wang 
> Signed-off-by: Hanjun Guo 
> Cc: Marc Zyngier 
> Cc: Thomas Gleixner 
> Cc: Ma Jun 
> ---
>  drivers/irqchip/irq-mbigen.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index 03b79b0..c01ab41 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -293,7 +293,6 @@ static int mbigen_device_probe(struct platform_device 
> *pdev)
>  static struct platform_driver mbigen_platform_driver = {
>   .driver = {
>   .name   = "Hisilicon MBIGEN-V2",
> - .owner  = THIS_MODULE,
>   .of_match_table = mbigen_of_match,
>   },
>   .probe  = mbigen_device_probe,
> 

Reviewed-by: MaJun 

Re: [PATCH v5 00/14] ACPI platform MSI support and its example mbigen

[majun (Euler7)]

Hi Hanjun:
This patch set works fine on my Hisilicon D05 board.
Feel free to add
Tested-by: Majun <majun...@huawei.com>

在 2016/12/22 13:35, Hanjun Guo 写道:
> From: Hanjun Guo <hanjun@linaro.org>
> 
> v4 -> v5:
>   - Add mbigen support back with tested on with Agustin's patchset,
> and it's a good example of how ACPI platform MSI works
>   - rebased on top of lastest Linus tree (commit 52bce91 splice: 
> reinstate SIGPIPE/EPIPE handling)
> 
> v3 -> v4:
> - Drop mbi-gen patches to just submit platform msi support because
>   will rebase mbi-gen patches on top of Agustin's patchset, and 
> discusion
>   is going there.
> - Add a patch to support device topology such as NC(named componant, 
> paltform device)
>   ->SMMU->ITS which suggested by Lorenzo;
> - rebased on top of Lorenzo's v9 of ACPI IORT ARM SMMU support;
> - rebased on top of 4.9-rc7
> 
> v2 -> v3:
> - Drop RFC tag
> - Rebase against v4.9-rc2 and Lorenzo's v6 of ACPI IORT ARM SMMU 
> support [1]
> - Add 3 cleanup patches (patch 1, 2, 3)
> - Drop arch_init call patch from last version
> - Introduce a callback for platform device to set msi domain
> - Introduce a new API to get paltform device's domain instead of
>   reusing the PCI one in previous version
> - Add a patch to rework iort_node_get_id()
> 
> [1]: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1251993.html
> 
> v1 -> v2:
> - Fix the bug of if multi Interrupt() resoures in single _PRS,
>   we need to calculate all the irq numbers (I missed it in previous
>   version);
> - Rebased on Marc's irq/irqchip-4.9 branch and Lorenzo's v5
>   SMMU patches (also Robin's SMMu patches)
> - Add patch irqchip: mbigen: promote mbigen init.
> 
> With platform msi support landed in the kernel, and the introduction
> of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi
> is ready, this patch set add few patches to enable the ACPI platform
> msi support.
> 
> For platform device connecting to ITS on arm platform, we have IORT
> table with the named componant node to describe the mappings of paltform
> device and ITS, so we can retrieve the dev id and find its parent
> irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
> 
> The fisrt 3 patches are cleanups;
> 
> Patch 4,5 are refactoring its_pmsi_prepare() for both DT and ACPI
> then retrieve the dev id from iort;
> 
> Patch 6,7 to create platform msi domain to ACPI case which scanned
> the MADT table;
> 
> Patch 8,9,10,11 to setup the msi domain for platform device based
> on IORT table.
> 
> Patch 12,13,14 convert dt based mbigen driver to support ACPI.
> 
> Teasted on Hisilicon D03/D05.
> 
> Happy holidays!
> 
> Thanks
> Hanjun
> 
> Hanjun Guo (12):
>   ACPI: ARM64: IORT: minor cleanup for iort_match_node_callback()
>   irqchip: gic-v3-its: keep the head file include in alphabetic order
>   ACPI: ARM64: IORT: add missing comment for iort_dev_find_its_id()
>   irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
>   ACPI: platform-msi: retrieve dev id from IORT
>   irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare
> for ACPI
>   irqchip: gicv3-its: platform-msi: scan MADT to create platform msi
> domain
>   ACPI: ARM64: IORT: rework iort_node_get_id()
>   ACPI: platform: setup MSI domain for ACPI based platform device
>   ACPI: ARM64: IORT: rework iort_node_get_id() for NC->SMMU->ITS case
>   msi: platform: make platform_msi_create_device_domain() ACPI aware
>   irqchip: mbigen: Add ACPI support
> 
> Kefeng Wang (2):
>   irqchip: mbigen: drop module owner
>   irqchip: mbigen: introduce mbigen_of_create_domain()
> 
>  drivers/acpi/acpi_platform.c  |  11 ++
>  drivers/acpi/arm64/iort.c | 138 
> --
>  drivers/base/platform-msi.c   |   3 +-
>  drivers/base/platform.c   |   3 +
>  drivers/irqchip/irq-gic-v3-its-platform-msi.c | 106 +++-
>  drivers/irqchip/irq-gic-v3-its.c  |   3 +-
>  drivers/irqchip/irq-mbigen.c  | 109 
>  include/linux/acpi_iort.h |  11 ++
>  include/linux/platform_device.h   |   3 +
>  9 files changed, 309 insertions(+), 78 deletions(-)
> 

Re: [PATCH v5 00/14] ACPI platform MSI support and its example mbigen

[majun (Euler7)]

Hi Hanjun:
This patch set works fine on my Hisilicon D05 board.
Feel free to add
Tested-by: Majun 

在 2016/12/22 13:35, Hanjun Guo 写道:
> From: Hanjun Guo 
> 
> v4 -> v5:
>   - Add mbigen support back with tested on with Agustin's patchset,
> and it's a good example of how ACPI platform MSI works
>   - rebased on top of lastest Linus tree (commit 52bce91 splice: 
> reinstate SIGPIPE/EPIPE handling)
> 
> v3 -> v4:
> - Drop mbi-gen patches to just submit platform msi support because
>   will rebase mbi-gen patches on top of Agustin's patchset, and 
> discusion
>   is going there.
> - Add a patch to support device topology such as NC(named componant, 
> paltform device)
>   ->SMMU->ITS which suggested by Lorenzo;
> - rebased on top of Lorenzo's v9 of ACPI IORT ARM SMMU support;
> - rebased on top of 4.9-rc7
> 
> v2 -> v3:
> - Drop RFC tag
> - Rebase against v4.9-rc2 and Lorenzo's v6 of ACPI IORT ARM SMMU 
> support [1]
> - Add 3 cleanup patches (patch 1, 2, 3)
> - Drop arch_init call patch from last version
> - Introduce a callback for platform device to set msi domain
> - Introduce a new API to get paltform device's domain instead of
>   reusing the PCI one in previous version
> - Add a patch to rework iort_node_get_id()
> 
> [1]: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1251993.html
> 
> v1 -> v2:
> - Fix the bug of if multi Interrupt() resoures in single _PRS,
>   we need to calculate all the irq numbers (I missed it in previous
>   version);
> - Rebased on Marc's irq/irqchip-4.9 branch and Lorenzo's v5
>   SMMU patches (also Robin's SMMu patches)
> - Add patch irqchip: mbigen: promote mbigen init.
> 
> With platform msi support landed in the kernel, and the introduction
> of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi
> is ready, this patch set add few patches to enable the ACPI platform
> msi support.
> 
> For platform device connecting to ITS on arm platform, we have IORT
> table with the named componant node to describe the mappings of paltform
> device and ITS, so we can retrieve the dev id and find its parent
> irqdomain (ITS) from IORT table (simlar with the ACPI ITS support).
> 
> The fisrt 3 patches are cleanups;
> 
> Patch 4,5 are refactoring its_pmsi_prepare() for both DT and ACPI
> then retrieve the dev id from iort;
> 
> Patch 6,7 to create platform msi domain to ACPI case which scanned
> the MADT table;
> 
> Patch 8,9,10,11 to setup the msi domain for platform device based
> on IORT table.
> 
> Patch 12,13,14 convert dt based mbigen driver to support ACPI.
> 
> Teasted on Hisilicon D03/D05.
> 
> Happy holidays!
> 
> Thanks
> Hanjun
> 
> Hanjun Guo (12):
>   ACPI: ARM64: IORT: minor cleanup for iort_match_node_callback()
>   irqchip: gic-v3-its: keep the head file include in alphabetic order
>   ACPI: ARM64: IORT: add missing comment for iort_dev_find_its_id()
>   irqchip: gicv3-its: platform-msi: refactor its_pmsi_prepare()
>   ACPI: platform-msi: retrieve dev id from IORT
>   irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare
> for ACPI
>   irqchip: gicv3-its: platform-msi: scan MADT to create platform msi
> domain
>   ACPI: ARM64: IORT: rework iort_node_get_id()
>   ACPI: platform: setup MSI domain for ACPI based platform device
>   ACPI: ARM64: IORT: rework iort_node_get_id() for NC->SMMU->ITS case
>   msi: platform: make platform_msi_create_device_domain() ACPI aware
>   irqchip: mbigen: Add ACPI support
> 
> Kefeng Wang (2):
>   irqchip: mbigen: drop module owner
>   irqchip: mbigen: introduce mbigen_of_create_domain()
> 
>  drivers/acpi/acpi_platform.c  |  11 ++
>  drivers/acpi/arm64/iort.c | 138 
> --
>  drivers/base/platform-msi.c   |   3 +-
>  drivers/base/platform.c   |   3 +
>  drivers/irqchip/irq-gic-v3-its-platform-msi.c | 106 +++-
>  drivers/irqchip/irq-gic-v3-its.c  |   3 +-
>  drivers/irqchip/irq-mbigen.c  | 109 
>  include/linux/acpi_iort.h |  11 ++
>  include/linux/platform_device.h   |   3 +
>  9 files changed, 309 insertions(+), 78 deletions(-)
> 

Re: [RFC PATCH 0/3] Add a new flag for ITS device to control indirect route

[majun (Euler7)]

Hi Marc:

在 2016/12/2 17:35, Marc Zyngier 写道:
> On 02/12/16 09:29, majun (Euler7) wrote:
>>
>>
>> 在 2016/12/1 17:07, Marc Zyngier 写道:
>>> On 01/12/16 07:45, Majun wrote:
>>>> From: MaJun <majun...@huawei.com>
>>>>
>>>> For current ITS driver, two level table (indirect route) is enabled when 
>>>> the memory used
>>>> for LPI route table over the limit(64KB * 2) size. But this function 
>>>> impact the 
>>>> performance of LPI interrupt actually because need more time to look up 
>>>> the table.
>>>
>>> Are you implying that your ITS doesn't have a cache to lookup the most
>>> active devices, hence performing a full lookup on each interrupt?
>>
>> Our ITS chip has the cache with depth 64. But this seems not enough for some
>> scenario,espeically on virtulization platform.
> 
> Then I don't see how switching to to flat tables is going to improve
> things. Can you share actual performance numbers?
> 
Sorry, I run this code on EMU and have no actual performance numbers now.

Suppose there are 66 devices in system.
As far as our chip concerned, there are always 2 devices can't benefit from
cache fully when they report the interrupt.

If i'm wrong, please correct me.

Thanks
Majun

>>> Anyway, doing this as a DT quirk doesn't feel right. Please use the ITS
>>> quirk infrastructure.
>>
>> If there is no other better solutions, I will do this.
> 
> Thanks,
> 
>   M.
> 

Re: [RFC PATCH 0/3] Add a new flag for ITS device to control indirect route

[majun (Euler7)]

Hi Marc:

在 2016/12/2 17:35, Marc Zyngier 写道:
> On 02/12/16 09:29, majun (Euler7) wrote:
>>
>>
>> 在 2016/12/1 17:07, Marc Zyngier 写道:
>>> On 01/12/16 07:45, Majun wrote:
>>>> From: MaJun 
>>>>
>>>> For current ITS driver, two level table (indirect route) is enabled when 
>>>> the memory used
>>>> for LPI route table over the limit(64KB * 2) size. But this function 
>>>> impact the 
>>>> performance of LPI interrupt actually because need more time to look up 
>>>> the table.
>>>
>>> Are you implying that your ITS doesn't have a cache to lookup the most
>>> active devices, hence performing a full lookup on each interrupt?
>>
>> Our ITS chip has the cache with depth 64. But this seems not enough for some
>> scenario,espeically on virtulization platform.
> 
> Then I don't see how switching to to flat tables is going to improve
> things. Can you share actual performance numbers?
> 
Sorry, I run this code on EMU and have no actual performance numbers now.

Suppose there are 66 devices in system.
As far as our chip concerned, there are always 2 devices can't benefit from
cache fully when they report the interrupt.

If i'm wrong, please correct me.

Thanks
Majun

>>> Anyway, doing this as a DT quirk doesn't feel right. Please use the ITS
>>> quirk infrastructure.
>>
>> If there is no other better solutions, I will do this.
> 
> Thanks,
> 
>   M.
> 

Re: [RFC PATCH 0/3] Add a new flag for ITS device to control indirect route

[majun (Euler7)]

在 2016/12/1 17:07, Marc Zyngier 写道:
> On 01/12/16 07:45, Majun wrote:
>> From: MaJun <majun...@huawei.com>
>>
>> For current ITS driver, two level table (indirect route) is enabled when the 
>> memory used
>> for LPI route table over the limit(64KB * 2) size. But this function impact 
>> the 
>> performance of LPI interrupt actually because need more time to look up the 
>> table.
> 
> Are you implying that your ITS doesn't have a cache to lookup the most
> active devices, hence performing a full lookup on each interrupt?

Our ITS chip has the cache with depth 64. But this seems not enough for some
scenario,espeically on virtulization platform.
> 
> Anyway, doing this as a DT quirk doesn't feel right. Please use the ITS
> quirk infrastructure.

If there is no other better solutions, I will do this.

Thanks!
Majun



> 
> Thanks,
> 
>   M.
> 

Re: [RFC PATCH 0/3] Add a new flag for ITS device to control indirect route

[majun (Euler7)]

在 2016/12/1 17:07, Marc Zyngier 写道:
> On 01/12/16 07:45, Majun wrote:
>> From: MaJun 
>>
>> For current ITS driver, two level table (indirect route) is enabled when the 
>> memory used
>> for LPI route table over the limit(64KB * 2) size. But this function impact 
>> the 
>> performance of LPI interrupt actually because need more time to look up the 
>> table.
> 
> Are you implying that your ITS doesn't have a cache to lookup the most
> active devices, hence performing a full lookup on each interrupt?

Our ITS chip has the cache with depth 64. But this seems not enough for some
scenario,espeically on virtulization platform.
> 
> Anyway, doing this as a DT quirk doesn't feel right. Please use the ITS
> quirk infrastructure.

If there is no other better solutions, I will do this.

Thanks!
Majun



> 
> Thanks,
> 
>   M.
> 

[RFC PATCH 1/3]Binding: Add a new property string in ITS node to control the two-level route function

[Majun]

From: MaJun <majun...@huawei.com>

Add the two-level-route property in ITS node.
When this property string defined, two-level route(indirect) function
will be enabled in ITS driver, otherwise disable it.

Signed-off-by: MaJun <majun...@huawei.com>
---
 Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt 
b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
index 4c29cda..e9f4a9c 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
@@ -74,6 +74,8 @@ These nodes must have the following properties:
   which will generate the MSI.
 - reg: Specifies the base physical address and size of the ITS
   registers.
+- two-level-route: This is an optional property which means enable the two 
level
+  route property when look up route table.
 
 The main GIC node must contain the appropriate #address-cells,
 #size-cells and ranges properties for the reg property of all ITS
@@ -97,6 +99,7 @@ Examples:
 
gic-its@2c20 {
compatible = "arm,gic-v3-its";
+   two-level-route;
msi-controller;
#msi-cells = <1>;
reg = <0x0 0x2c20 0 0x20>;
-- 
1.7.12.4

[RFC PATCH 3/3]irqchip/gicv3-its: Add a new flag to control indirect route in ACPI mode.

[Majun]

From: MaJun <majun...@huawei.com>

Add a new flag to control indirect route function for ACPI mode.
To carry the user defined flags information, we used the reserved byte
in ITS MADT table

Signed-off-by: MaJun <majun...@huawei.com>
---
 drivers/irqchip/irq-gic-v3-its.c | 5 -
 include/acpi/actbl1.h| 3 ++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index ee54133..4420283 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1848,6 +1848,7 @@ static int __init gic_acpi_parse_madt_its(struct 
acpi_subtable_header *header,
struct fwnode_handle *dom_handle;
struct resource res;
int err;
+   u8 flags = 0;
 
its_entry = (struct acpi_madt_generic_translator *)header;
memset(, 0, sizeof(res));
@@ -1855,6 +1856,8 @@ static int __init gic_acpi_parse_madt_its(struct 
acpi_subtable_header *header,
res.end = its_entry->base_address + ACPI_GICV3_ITS_MEM_SIZE - 1;
res.flags = IORESOURCE_MEM;
 
+   flags = its_entry->flags;
+
dom_handle = irq_domain_alloc_fwnode((void *)its_entry->base_address);
if (!dom_handle) {
pr_err("ITS@%pa: Unable to allocate GICv3 ITS domain token\n",
@@ -1869,7 +1872,7 @@ static int __init gic_acpi_parse_madt_its(struct 
acpi_subtable_header *header,
goto dom_err;
}
 
-   err = its_probe_one(, dom_handle, NUMA_NO_NODE, 0);
+   err = its_probe_one(, dom_handle, NUMA_NO_NODE, flags);
if (!err)
return 0;
 
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 796d6ba..42a08ae 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -930,7 +930,8 @@ struct acpi_madt_generic_translator {
u16 reserved;   /* reserved - must be zero */
u32 translation_id;
u64 base_address;
-   u32 reserved2;
+   u8 flags;
+   u8 reserved2[3];
 };
 
 /*
-- 
1.7.12.4

[RFC PATCH 1/3]Binding: Add a new property string in ITS node to control the two-level route function

[Majun]

From: MaJun 

Add the two-level-route property in ITS node.
When this property string defined, two-level route(indirect) function
will be enabled in ITS driver, otherwise disable it.

Signed-off-by: MaJun 
---
 Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt 
b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
index 4c29cda..e9f4a9c 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
@@ -74,6 +74,8 @@ These nodes must have the following properties:
   which will generate the MSI.
 - reg: Specifies the base physical address and size of the ITS
   registers.
+- two-level-route: This is an optional property which means enable the two 
level
+  route property when look up route table.
 
 The main GIC node must contain the appropriate #address-cells,
 #size-cells and ranges properties for the reg property of all ITS
@@ -97,6 +99,7 @@ Examples:
 
gic-its@2c20 {
compatible = "arm,gic-v3-its";
+   two-level-route;
msi-controller;
#msi-cells = <1>;
reg = <0x0 0x2c20 0 0x20>;
-- 
1.7.12.4

[RFC PATCH 3/3]irqchip/gicv3-its: Add a new flag to control indirect route in ACPI mode.

[Majun]

From: MaJun 

Add a new flag to control indirect route function for ACPI mode.
To carry the user defined flags information, we used the reserved byte
in ITS MADT table

Signed-off-by: MaJun 
---
 drivers/irqchip/irq-gic-v3-its.c | 5 -
 include/acpi/actbl1.h| 3 ++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index ee54133..4420283 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1848,6 +1848,7 @@ static int __init gic_acpi_parse_madt_its(struct 
acpi_subtable_header *header,
struct fwnode_handle *dom_handle;
struct resource res;
int err;
+   u8 flags = 0;
 
its_entry = (struct acpi_madt_generic_translator *)header;
memset(, 0, sizeof(res));
@@ -1855,6 +1856,8 @@ static int __init gic_acpi_parse_madt_its(struct 
acpi_subtable_header *header,
res.end = its_entry->base_address + ACPI_GICV3_ITS_MEM_SIZE - 1;
res.flags = IORESOURCE_MEM;
 
+   flags = its_entry->flags;
+
dom_handle = irq_domain_alloc_fwnode((void *)its_entry->base_address);
if (!dom_handle) {
pr_err("ITS@%pa: Unable to allocate GICv3 ITS domain token\n",
@@ -1869,7 +1872,7 @@ static int __init gic_acpi_parse_madt_its(struct 
acpi_subtable_header *header,
goto dom_err;
}
 
-   err = its_probe_one(, dom_handle, NUMA_NO_NODE, 0);
+   err = its_probe_one(, dom_handle, NUMA_NO_NODE, flags);
if (!err)
return 0;
 
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 796d6ba..42a08ae 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -930,7 +930,8 @@ struct acpi_madt_generic_translator {
u16 reserved;   /* reserved - must be zero */
u32 translation_id;
u64 base_address;
-   u32 reserved2;
+   u8 flags;
+   u8 reserved2[3];
 };
 
 /*
-- 
1.7.12.4

[RFC PATCH 0/3] Add a new flag for ITS device to control indirect route

[Majun]

From: MaJun <majun...@huawei.com>

For current ITS driver, two level table (indirect route) is enabled when the 
memory used
for LPI route table over the limit(64KB * 2) size. But this function impact the 
performance of LPI interrupt actually because need more time to look up the 
table.

Although this function can save the memory needed, we'd better let the user
to decide enable or disable this function.

MaJun (3):
  Binding: Add a new property string in ITS node to control the two-level route 
function
  irqchip/gicv3-its:irqchip/gicv3-its: add a new flag to control indirect route 
in DT mode
  irqchip/gicv3-its:irqchip/gicv3-its: Add a new flag to control indirect route 
function in ACPI mode.

 .../bindings/interrupt-controller/arm,gic-v3.txt  |  3 +++
 drivers/irqchip/irq-gic-v3-its.c  | 19 ++-
 include/acpi/actbl1.h |  3 ++-
 3 files changed, 19 insertions(+), 6 deletions(-)

-- 
1.7.12.4

[RFC PATCH 0/3] Add a new flag for ITS device to control indirect route

[Majun]

From: MaJun 

For current ITS driver, two level table (indirect route) is enabled when the 
memory used
for LPI route table over the limit(64KB * 2) size. But this function impact the 
performance of LPI interrupt actually because need more time to look up the 
table.

Although this function can save the memory needed, we'd better let the user
to decide enable or disable this function.

MaJun (3):
  Binding: Add a new property string in ITS node to control the two-level route 
function
  irqchip/gicv3-its:irqchip/gicv3-its: add a new flag to control indirect route 
in DT mode
  irqchip/gicv3-its:irqchip/gicv3-its: Add a new flag to control indirect route 
function in ACPI mode.

 .../bindings/interrupt-controller/arm,gic-v3.txt  |  3 +++
 drivers/irqchip/irq-gic-v3-its.c  | 19 ++-
 include/acpi/actbl1.h |  3 ++-
 3 files changed, 19 insertions(+), 6 deletions(-)

-- 
1.7.12.4

[RFC PATCH 2/3] irqchip/gicv3-its: add a new flag to control indirect route in DT mode

[Majun]

From: MaJun <majun...@huawei.com>

Add a new flag for ITS node in DT mode so we can disable/enable the
indirect route function.

Signed-off-by: MaJun <majun...@huawei.com>
---
 drivers/irqchip/irq-gic-v3-its.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index d278425..ee54133 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -46,6 +46,7 @@
 #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING  (1ULL << 0)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_22375  (1ULL << 1)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_23144  (1ULL << 2)
+#define ITS_FLAGS_INDIRECT_ROUTE   (1ULL << 3)
 
 #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
 
@@ -967,7 +968,7 @@ static bool its_parse_baser_device(struct its_node *its, 
struct its_baser *baser
bool indirect = false;
 
/* No need to enable Indirection if memory requirement < (psz*2)bytes */
-   if ((esz << ids) > (psz * 2)) {
+   if ((its->flags & ITS_FLAGS_INDIRECT_ROUTE) && ((esz << ids) > (psz * 
2))) {
/*
 * Find out whether hw supports a single or two-level table by
 * table by reading bit at offset '62' after writing '1' to it.
@@ -1673,8 +1674,8 @@ static int its_init_domain(struct fwnode_handle *handle, 
struct its_node *its)
return 0;
 }
 
-static int __init its_probe_one(struct resource *res,
-   struct fwnode_handle *handle, int numa_node)
+static int __init its_probe_one(struct resource *res, struct fwnode_handle 
*handle,
+   int numa_node, u8 flags)
 {
struct its_node *its;
void __iomem *its_base;
@@ -1716,6 +1717,7 @@ static int __init its_probe_one(struct resource *res,
its->phys_base = res->start;
its->ite_size = ((readl_relaxed(its_base + GITS_TYPER) >> 4) & 0xf) + 1;
its->numa_node = numa_node;
+   its->flags |= flags;
 
its->cmd_base = kzalloc(ITS_CMD_QUEUE_SZ, GFP_KERNEL);
if (!its->cmd_base) {
@@ -1812,6 +1814,7 @@ static int __init its_of_probe(struct device_node *node)
 {
struct device_node *np;
struct resource res;
+   u8 flags = 0;
 
for (np = of_find_matching_node(node, its_device_id); np;
 np = of_find_matching_node(np, its_device_id)) {
@@ -1826,7 +1829,10 @@ static int __init its_of_probe(struct device_node *node)
continue;
}
 
-   its_probe_one(, >fwnode, of_node_to_nid(np));
+   if (of_property_read_bool(np, "two-level-route"))
+   flags |= ITS_FLAGS_INDIRECT_ROUTE;
+
+   its_probe_one(, >fwnode, of_node_to_nid(np), flags);
}
return 0;
 }
@@ -1863,7 +1869,7 @@ static int __init gic_acpi_parse_madt_its(struct 
acpi_subtable_header *header,
goto dom_err;
}
 
-   err = its_probe_one(, dom_handle, NUMA_NO_NODE);
+   err = its_probe_one(, dom_handle, NUMA_NO_NODE, 0);
if (!err)
return 0;
 
-- 
1.7.12.4

[RFC PATCH 2/3] irqchip/gicv3-its: add a new flag to control indirect route in DT mode

[Majun]

From: MaJun 

Add a new flag for ITS node in DT mode so we can disable/enable the
indirect route function.

Signed-off-by: MaJun 
---
 drivers/irqchip/irq-gic-v3-its.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index d278425..ee54133 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -46,6 +46,7 @@
 #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING  (1ULL << 0)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_22375  (1ULL << 1)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_23144  (1ULL << 2)
+#define ITS_FLAGS_INDIRECT_ROUTE   (1ULL << 3)
 
 #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
 
@@ -967,7 +968,7 @@ static bool its_parse_baser_device(struct its_node *its, 
struct its_baser *baser
bool indirect = false;
 
/* No need to enable Indirection if memory requirement < (psz*2)bytes */
-   if ((esz << ids) > (psz * 2)) {
+   if ((its->flags & ITS_FLAGS_INDIRECT_ROUTE) && ((esz << ids) > (psz * 
2))) {
/*
 * Find out whether hw supports a single or two-level table by
 * table by reading bit at offset '62' after writing '1' to it.
@@ -1673,8 +1674,8 @@ static int its_init_domain(struct fwnode_handle *handle, 
struct its_node *its)
return 0;
 }
 
-static int __init its_probe_one(struct resource *res,
-   struct fwnode_handle *handle, int numa_node)
+static int __init its_probe_one(struct resource *res, struct fwnode_handle 
*handle,
+   int numa_node, u8 flags)
 {
struct its_node *its;
void __iomem *its_base;
@@ -1716,6 +1717,7 @@ static int __init its_probe_one(struct resource *res,
its->phys_base = res->start;
its->ite_size = ((readl_relaxed(its_base + GITS_TYPER) >> 4) & 0xf) + 1;
its->numa_node = numa_node;
+   its->flags |= flags;
 
its->cmd_base = kzalloc(ITS_CMD_QUEUE_SZ, GFP_KERNEL);
if (!its->cmd_base) {
@@ -1812,6 +1814,7 @@ static int __init its_of_probe(struct device_node *node)
 {
struct device_node *np;
struct resource res;
+   u8 flags = 0;
 
for (np = of_find_matching_node(node, its_device_id); np;
 np = of_find_matching_node(np, its_device_id)) {
@@ -1826,7 +1829,10 @@ static int __init its_of_probe(struct device_node *node)
continue;
}
 
-   its_probe_one(, >fwnode, of_node_to_nid(np));
+   if (of_property_read_bool(np, "two-level-route"))
+   flags |= ITS_FLAGS_INDIRECT_ROUTE;
+
+   its_probe_one(, >fwnode, of_node_to_nid(np), flags);
}
return 0;
 }
@@ -1863,7 +1869,7 @@ static int __init gic_acpi_parse_madt_its(struct 
acpi_subtable_header *header,
goto dom_err;
}
 
-   err = its_probe_one(, dom_handle, NUMA_NO_NODE);
+   err = its_probe_one(, dom_handle, NUMA_NO_NODE, 0);
if (!err)
return 0;
 
-- 
1.7.12.4

Re: [PATCH] ACPI: fix the process flow for 0 which return from acpi_register_gsi

[majun (Euler7)]

sorry, ignore this one..


在 2016/12/1 15:41, Majun 写道:
> From: MaJun <majun...@huawei.com>
> 
> The return value 0 from acpi_register_gsi() means irq mapping failed.
> So, we should process this case in else branch.
> 
> Signed-off-by: MaJun <majun...@huawei.com>
> ---
>  drivers/acpi/resource.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 56241eb..9918326 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -416,7 +416,7 @@ static void acpi_dev_get_irqresource(struct resource 
> *res, u32 gsi,
>  
>   res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
>   irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
> - if (irq >= 0) {
> + if (irq > 0) {
>   res->start = irq;
>   res->end = irq;
>   } else {
> 

Re: [PATCH] ACPI: fix the process flow for 0 which return from acpi_register_gsi

[majun (Euler7)]

sorry, ignore this one..


在 2016/12/1 15:41, Majun 写道:
> From: MaJun 
> 
> The return value 0 from acpi_register_gsi() means irq mapping failed.
> So, we should process this case in else branch.
> 
> Signed-off-by: MaJun 
> ---
>  drivers/acpi/resource.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 56241eb..9918326 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -416,7 +416,7 @@ static void acpi_dev_get_irqresource(struct resource 
> *res, u32 gsi,
>  
>   res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
>   irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
> - if (irq >= 0) {
> + if (irq > 0) {
>   res->start = irq;
>   res->end = irq;
>   } else {
> 

[PATCH] ACPI: fix the process flow for 0 which return from acpi_register_gsi

[Majun]

From: MaJun <majun...@huawei.com>

The return value 0 from acpi_register_gsi() means irq mapping failed.
So, we should process this case in else branch.

Signed-off-by: MaJun <majun...@huawei.com>
---
 drivers/acpi/resource.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 56241eb..9918326 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -416,7 +416,7 @@ static void acpi_dev_get_irqresource(struct resource *res, 
u32 gsi,
 
res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
-   if (irq >= 0) {
+   if (irq > 0) {
res->start = irq;
res->end = irq;
} else {
-- 
1.7.12.4

[PATCH] ACPI: fix the process flow for 0 which return from acpi_register_gsi

[Majun]

From: MaJun 

The return value 0 from acpi_register_gsi() means irq mapping failed.
So, we should process this case in else branch.

Signed-off-by: MaJun 
---
 drivers/acpi/resource.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 56241eb..9918326 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -416,7 +416,7 @@ static void acpi_dev_get_irqresource(struct resource *res, 
u32 gsi,
 
res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
-   if (irq >= 0) {
+   if (irq > 0) {
res->start = irq;
res->end = irq;
} else {
-- 
1.7.12.4

Re: [PATCH V7 1/3] ACPI: Retry IRQ conversion if it failed previously

[majun (Euler7)]

This patch works fine on my D05 board.

Tested-by: Majun <majun...@huawei.com>

在 2016/11/14 5:59, Agustin Vega-Frias 写道:
> This allows probe deferral to work properly when a dependent device
> fails to get a valid IRQ because the IRQ domain was not registered
> at the time the resources were added to the platform_device.
> 
> Signed-off-by: Agustin Vega-Frias <agust...@codeaurora.org>
> ---
>  drivers/acpi/resource.c | 59 
> +
>  drivers/base/platform.c |  9 +++-
>  include/linux/acpi.h|  7 ++
>  3 files changed, 74 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 56241eb..4beda15 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -664,3 +664,62 @@ int acpi_dev_filter_resource_type(struct acpi_resource 
> *ares,
>   return (type & types) ? 0 : 1;
>  }
>  EXPORT_SYMBOL_GPL(acpi_dev_filter_resource_type);
> +
> +struct acpi_irq_get_ctx {
> + unsigned int index;
> + struct resource *res;
> +};
> +
> +static acpi_status acpi_irq_get_cb(struct acpi_resource *ares, void *context)
> +{
> + struct acpi_irq_get_ctx *ctx = context;
> + struct acpi_resource_irq *irq;
> + struct acpi_resource_extended_irq *ext_irq;
> +
> + switch (ares->type) {
> + case ACPI_RESOURCE_TYPE_IRQ:
> + irq = >data.irq;
> + if (ctx->index < irq->interrupt_count) {
> + acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
> + return AE_CTRL_TERMINATE;
> + }
> + ctx->index -= irq->interrupt_count;
> + break;
> + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> + ext_irq = >data.extended_irq;
> + if (ctx->index < ext_irq->interrupt_count) {
> + acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
> + return AE_CTRL_TERMINATE;
> + }
> + ctx->index -= ext_irq->interrupt_count;
> + break;
> + }
> +
> + return AE_OK;
> +}
> +
> +/**
> + * acpi_irq_get - Look for the ACPI IRQ resource with the given index and
> + *use it to initialize the given Linux IRQ resource.
> + * @handle ACPI device handle
> + * @index  ACPI IRQ resource index to lookup
> + * @resLinux IRQ resource to initialize
> + *
> + * Return: 0 on success
> + * -EINVAL if an error occurs
> + * -EPROBE_DEFER if the IRQ lookup/conversion failed
> + */
> +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource 
> *res)
> +{
> + struct acpi_irq_get_ctx ctx = { index, res };
> + acpi_status status;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> +  acpi_irq_get_cb, );
> + if (ACPI_FAILURE(status))
> + return -EINVAL;
> + if (res->flags & IORESOURCE_DISABLED)
> + return -EPROBE_DEFER;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_get);
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index c4af003..61423d2 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -102,6 +102,14 @@ int platform_get_irq(struct platform_device *dev, 
> unsigned int num)
>   }
>  
>   r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> + if (r && r->flags & IORESOURCE_DISABLED && ACPI_COMPANION(>dev)) {
> + int ret;
> +
> + ret = acpi_irq_get(ACPI_HANDLE(>dev), num, r);
> + if (ret)
> + return ret;
> + }
> +
>   /*
>* The resources may pass trigger flags to the irqs that need
>* to be set up. It so happens that the trigger flags for
> @@ -1450,4 +1458,3 @@ void __init early_platform_cleanup(void)
>   memset(>dev.devres_head, 0, sizeof(pd->dev.devres_head));
>   }
>  }
> -
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 689a8b9..325bdb9 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -406,6 +406,7 @@ bool acpi_dev_resource_ext_address_space(struct 
> acpi_resource *ares,
>  unsigned int acpi_dev_get_irq_type(int triggering, int polarity);
>  bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
>struct resource *res);
> +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource 
> *res);
>  
>  void acpi_dev_free_resource_list(struct list_head *list);
>  int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
> @@ -763,6 +764,12 @@ static inline int 
> acpi_reconfig_notifier_unregister(struct notifier_block *nb)
>   return -EINVAL;
>  }
>  
> +static inline int acpi_irq_get(acpi_handle handle, unsigned int index,
> +struct resource *res)
> +{
> + return -EINVAL;
> +}
> +
>  #endif   /* !CONFIG_ACPI */
>  
>  #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
> 

Re: [PATCH V7 1/3] ACPI: Retry IRQ conversion if it failed previously

[majun (Euler7)]

This patch works fine on my D05 board.

Tested-by: Majun 

在 2016/11/14 5:59, Agustin Vega-Frias 写道:
> This allows probe deferral to work properly when a dependent device
> fails to get a valid IRQ because the IRQ domain was not registered
> at the time the resources were added to the platform_device.
> 
> Signed-off-by: Agustin Vega-Frias 
> ---
>  drivers/acpi/resource.c | 59 
> +
>  drivers/base/platform.c |  9 +++-
>  include/linux/acpi.h|  7 ++
>  3 files changed, 74 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 56241eb..4beda15 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -664,3 +664,62 @@ int acpi_dev_filter_resource_type(struct acpi_resource 
> *ares,
>   return (type & types) ? 0 : 1;
>  }
>  EXPORT_SYMBOL_GPL(acpi_dev_filter_resource_type);
> +
> +struct acpi_irq_get_ctx {
> + unsigned int index;
> + struct resource *res;
> +};
> +
> +static acpi_status acpi_irq_get_cb(struct acpi_resource *ares, void *context)
> +{
> + struct acpi_irq_get_ctx *ctx = context;
> + struct acpi_resource_irq *irq;
> + struct acpi_resource_extended_irq *ext_irq;
> +
> + switch (ares->type) {
> + case ACPI_RESOURCE_TYPE_IRQ:
> + irq = >data.irq;
> + if (ctx->index < irq->interrupt_count) {
> + acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
> + return AE_CTRL_TERMINATE;
> + }
> + ctx->index -= irq->interrupt_count;
> + break;
> + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> + ext_irq = >data.extended_irq;
> + if (ctx->index < ext_irq->interrupt_count) {
> + acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
> + return AE_CTRL_TERMINATE;
> + }
> + ctx->index -= ext_irq->interrupt_count;
> + break;
> + }
> +
> + return AE_OK;
> +}
> +
> +/**
> + * acpi_irq_get - Look for the ACPI IRQ resource with the given index and
> + *use it to initialize the given Linux IRQ resource.
> + * @handle ACPI device handle
> + * @index  ACPI IRQ resource index to lookup
> + * @resLinux IRQ resource to initialize
> + *
> + * Return: 0 on success
> + * -EINVAL if an error occurs
> + * -EPROBE_DEFER if the IRQ lookup/conversion failed
> + */
> +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource 
> *res)
> +{
> + struct acpi_irq_get_ctx ctx = { index, res };
> + acpi_status status;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> +  acpi_irq_get_cb, );
> + if (ACPI_FAILURE(status))
> + return -EINVAL;
> + if (res->flags & IORESOURCE_DISABLED)
> + return -EPROBE_DEFER;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_get);
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index c4af003..61423d2 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -102,6 +102,14 @@ int platform_get_irq(struct platform_device *dev, 
> unsigned int num)
>   }
>  
>   r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> + if (r && r->flags & IORESOURCE_DISABLED && ACPI_COMPANION(>dev)) {
> + int ret;
> +
> + ret = acpi_irq_get(ACPI_HANDLE(>dev), num, r);
> + if (ret)
> + return ret;
> + }
> +
>   /*
>* The resources may pass trigger flags to the irqs that need
>* to be set up. It so happens that the trigger flags for
> @@ -1450,4 +1458,3 @@ void __init early_platform_cleanup(void)
>   memset(>dev.devres_head, 0, sizeof(pd->dev.devres_head));
>   }
>  }
> -
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 689a8b9..325bdb9 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -406,6 +406,7 @@ bool acpi_dev_resource_ext_address_space(struct 
> acpi_resource *ares,
>  unsigned int acpi_dev_get_irq_type(int triggering, int polarity);
>  bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
>struct resource *res);
> +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource 
> *res);
>  
>  void acpi_dev_free_resource_list(struct list_head *list);
>  int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
> @@ -763,6 +764,12 @@ static inline int 
> acpi_reconfig_notifier_unregister(struct notifier_block *nb)
>   return -EINVAL;
>  }
>  
> +static inline int acpi_irq_get(acpi_handle handle, unsigned int index,
> +struct resource *res)
> +{
> + return -EINVAL;
> +}
> +
>  #endif   /* !CONFIG_ACPI */
>  
>  #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
> 

[PATCH] ACPI: fix the process flow for 0 which return from acpi_register_gsi

[MaJun]

The return value 0 from acpi_register_gsi() means irq mapping failed.
So, we should process this case in else branch.

Signed-off-by: MaJun <majun...@huawei.com>
---
 drivers/acpi/resource.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 56241eb..9918326 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -416,7 +416,7 @@ static void acpi_dev_get_irqresource(struct resource *res, 
u32 gsi,
 
res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
-   if (irq >= 0) {
+   if (irq > 0) {
res->start = irq;
res->end = irq;
} else {
-- 
1.7.12.4

[PATCH] ACPI: fix the process flow for 0 which return from acpi_register_gsi

[MaJun]

The return value 0 from acpi_register_gsi() means irq mapping failed.
So, we should process this case in else branch.

Signed-off-by: MaJun 
---
 drivers/acpi/resource.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 56241eb..9918326 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -416,7 +416,7 @@ static void acpi_dev_get_irqresource(struct resource *res, 
u32 gsi,
 
res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
-   if (irq >= 0) {
+   if (irq > 0) {
res->start = irq;
res->end = irq;
} else {
-- 
1.7.12.4

Re: [PATCH] generic: Add the exception case checking routine for ppi interrupt

[majun (F)]

在 2016/8/31 16:35, Marc Zyngier 写道:
> On 31/08/16 07:35, majun (F) wrote:
[...]
>>>
>>
>> I just checked the status of irq 30 during capture kernel booting.
>>
>> The irq 30 status is: mask, pending after arch_timer_starting_cpu() called.
>> Because irq 30 triggered only 1 time during capture kernel booting,
>> I think this problem maybe happened in the case like:
>> 1:irq 30 triggered, but not acked by cpu yet.
>> 2:local_irq_disable() called
>> 3:system reboot -->capture kernel booting
>> 4:local_irq_enable()
>> 5:irq 30 acked by CPU.
>>
>> Is this case possible?
> 
> I can't see how, because you've missed:
> 
> 3b: All PPIs are disabled as each CPU comes up
> 
> So for (5) to occur, I can only see two possibilities:
> (a) either something else is enabling the timer PPI

I checked the whole process, the irq 30 alway keeping disabled.

> (b) your GIC doesn't correctly retire a pending PPI that is being disabled

According to our hardware guy said, GIC in our system has problem in this case.
Usually, when we mask irq 30, the interrupt which in pending status but not 
acked by cpu
should be released/cleared by hardware, but actually, we did't do like this in 
our system.

So, this conclusion just same as you assumption.

Do you have any suggestion or workaround for this problem?

Thanks!
Majun

> 
> I'm discounting (b) because I can't see how the system would work
> otherwise, so (a) must be happening somehow.
> 


> Thanks,
> 
>   M.
> 

Re: [PATCH] generic: Add the exception case checking routine for ppi interrupt

[majun (F)]

在 2016/8/31 16:35, Marc Zyngier 写道:
> On 31/08/16 07:35, majun (F) wrote:
[...]
>>>
>>
>> I just checked the status of irq 30 during capture kernel booting.
>>
>> The irq 30 status is: mask, pending after arch_timer_starting_cpu() called.
>> Because irq 30 triggered only 1 time during capture kernel booting,
>> I think this problem maybe happened in the case like:
>> 1:irq 30 triggered, but not acked by cpu yet.
>> 2:local_irq_disable() called
>> 3:system reboot -->capture kernel booting
>> 4:local_irq_enable()
>> 5:irq 30 acked by CPU.
>>
>> Is this case possible?
> 
> I can't see how, because you've missed:
> 
> 3b: All PPIs are disabled as each CPU comes up
> 
> So for (5) to occur, I can only see two possibilities:
> (a) either something else is enabling the timer PPI

I checked the whole process, the irq 30 alway keeping disabled.

> (b) your GIC doesn't correctly retire a pending PPI that is being disabled

According to our hardware guy said, GIC in our system has problem in this case.
Usually, when we mask irq 30, the interrupt which in pending status but not 
acked by cpu
should be released/cleared by hardware, but actually, we did't do like this in 
our system.

So, this conclusion just same as you assumption.

Do you have any suggestion or workaround for this problem?

Thanks!
Majun

> 
> I'm discounting (b) because I can't see how the system would work
> otherwise, so (a) must be happening somehow.
> 


> Thanks,
> 
>   M.
> 

Re: [PATCH] generic: Add the exception case checking routine for ppi interrupt

[majun (F)]

Hi Marc & Mark:

在 2016/8/30 19:21, Mark Rutland 写道:
> On Tue, Aug 30, 2016 at 12:07:36PM +0100, Marc Zyngier wrote:
>> +Mark
>> On 30/08/16 11:35, majun (F) wrote:
>>> 在 2016/8/30 16:50, Marc Zyngier 写道:
>>>> On 30/08/16 05:17, MaJun wrote:
>>>>> From: Ma Jun <majun...@huawei.com>
>>>>>
>>>>> During system booting, if the interrupt which has no action registered
>>>>> is triggered, it would cause system panic when try to access the
>>>>> action member.
>>>>
>>>> And why would that interrupt be enabled? If you enable a PPI before
>>>> registering a handler, you're doing something wrong.
>>>
>>> Actually,the problem described above happened during the capture
>>> kernel booting.
>>>
>>> In my system, sometimes there is a pending physical timer
>>> interrupt(30) when the first kernel panic and the status is kept
>>> until the capture kernel booting.
>>
>> And that's perfectly fine. The interrupt can be pending forever, as it
>> shouldn't get enabled.
>>
>>> So, this interrupt will be handled during capture kernel booting.
>>
>> Why? Who enables it?
>>
>>> Becasue we use virt timer interrupt but not physical timer interrupt
>>> in capture kernel, the interrupt 30 has no action handler.
>>
>> Again: who enables this interrupt? Whichever driver enables it should be
>> fixed.
> 
> I'm also at a loss.
> 
> In this case, arch_timer_uses_ppi must be VIRT_PPI. So in
> arch_timer_register(), we'll only request_percpu_irq the virt PPI.
> arch_timer_has_nonsecure_ppi() will be false, given arch_timer_uses_ppi
> is VIRT_PPI, so in arch_timer_starting_cpu() we'll only
> enable_percpu_irq() the virt PPI.
> 
> We don't fiddle with arch_timer_uses_ppi after calling
> arch_timer_register(). So I can't see how we could enable another IRQ in
> this case.
> 
> Looking at the driver in virt/kvm/arm/arch_timer.c, we only enable what
> we've succesfully requested, so it doesnt' seem like there's an issue
> there.
> 
>>From a quick look at teh GIC driver, it looks like we reset PPIs
> correctly, so it doesn't look like we have a "latent enable".
> 

I just checked the status of irq 30 during capture kernel booting.

The irq 30 status is: mask, pending after arch_timer_starting_cpu() called.
Because irq 30 triggered only 1 time during capture kernel booting,
I think this problem maybe happened in the case like:
1:irq 30 triggered, but not acked by cpu yet.
2:local_irq_disable() called
3:system reboot -->capture kernel booting
4:local_irq_enable()
5:irq 30 acked by CPU.

Is this case possible?

Thanks
MaJun

> Thanks,
> Mark.
> 
> .
> 

Re: [PATCH] generic: Add the exception case checking routine for ppi interrupt

[majun (F)]

Hi Marc & Mark:

在 2016/8/30 19:21, Mark Rutland 写道:
> On Tue, Aug 30, 2016 at 12:07:36PM +0100, Marc Zyngier wrote:
>> +Mark
>> On 30/08/16 11:35, majun (F) wrote:
>>> 在 2016/8/30 16:50, Marc Zyngier 写道:
>>>> On 30/08/16 05:17, MaJun wrote:
>>>>> From: Ma Jun 
>>>>>
>>>>> During system booting, if the interrupt which has no action registered
>>>>> is triggered, it would cause system panic when try to access the
>>>>> action member.
>>>>
>>>> And why would that interrupt be enabled? If you enable a PPI before
>>>> registering a handler, you're doing something wrong.
>>>
>>> Actually,the problem described above happened during the capture
>>> kernel booting.
>>>
>>> In my system, sometimes there is a pending physical timer
>>> interrupt(30) when the first kernel panic and the status is kept
>>> until the capture kernel booting.
>>
>> And that's perfectly fine. The interrupt can be pending forever, as it
>> shouldn't get enabled.
>>
>>> So, this interrupt will be handled during capture kernel booting.
>>
>> Why? Who enables it?
>>
>>> Becasue we use virt timer interrupt but not physical timer interrupt
>>> in capture kernel, the interrupt 30 has no action handler.
>>
>> Again: who enables this interrupt? Whichever driver enables it should be
>> fixed.
> 
> I'm also at a loss.
> 
> In this case, arch_timer_uses_ppi must be VIRT_PPI. So in
> arch_timer_register(), we'll only request_percpu_irq the virt PPI.
> arch_timer_has_nonsecure_ppi() will be false, given arch_timer_uses_ppi
> is VIRT_PPI, so in arch_timer_starting_cpu() we'll only
> enable_percpu_irq() the virt PPI.
> 
> We don't fiddle with arch_timer_uses_ppi after calling
> arch_timer_register(). So I can't see how we could enable another IRQ in
> this case.
> 
> Looking at the driver in virt/kvm/arm/arch_timer.c, we only enable what
> we've succesfully requested, so it doesnt' seem like there's an issue
> there.
> 
>>From a quick look at teh GIC driver, it looks like we reset PPIs
> correctly, so it doesn't look like we have a "latent enable".
> 

I just checked the status of irq 30 during capture kernel booting.

The irq 30 status is: mask, pending after arch_timer_starting_cpu() called.
Because irq 30 triggered only 1 time during capture kernel booting,
I think this problem maybe happened in the case like:
1:irq 30 triggered, but not acked by cpu yet.
2:local_irq_disable() called
3:system reboot -->capture kernel booting
4:local_irq_enable()
5:irq 30 acked by CPU.

Is this case possible?

Thanks
MaJun

> Thanks,
> Mark.
> 
> .
> 

Re: [PATCH] generic: Add the exception case checking routine for ppi interrupt

[majun (F)]

在 2016/8/30 16:50, Marc Zyngier 写道:
> On 30/08/16 05:17, MaJun wrote:
>> From: Ma Jun <majun...@huawei.com>
>>
>> During system booting, if the interrupt which has no action registered
>> is triggered, it would cause system panic when try to access the
>> action member.
> 
> And why would that interrupt be enabled? If you enable a PPI before
> registering a handler, you're doing something wrong.
> 

Actually,the problem described above happened during the capture kernel booting.

In my system, sometimes there is a pending physical timer interrupt(30)
when the first kernel panic and the status is kept until the capture kernel 
booting.

So, this interrupt will be handled during capture kernel booting.

Becasue we use virt timer interrupt but not physical timer interrupt in capture 
kernel,
the interrupt 30 has no action handler.

Besides, I think we need to do exception check in this function just
like "handle_fasteoi_irq" does.

Thanks
MaJun

> Thanks,
> 
>   M.
> 

Re: [PATCH] generic: Add the exception case checking routine for ppi interrupt

[majun (F)]

在 2016/8/30 16:50, Marc Zyngier 写道:
> On 30/08/16 05:17, MaJun wrote:
>> From: Ma Jun 
>>
>> During system booting, if the interrupt which has no action registered
>> is triggered, it would cause system panic when try to access the
>> action member.
> 
> And why would that interrupt be enabled? If you enable a PPI before
> registering a handler, you're doing something wrong.
> 

Actually,the problem described above happened during the capture kernel booting.

In my system, sometimes there is a pending physical timer interrupt(30)
when the first kernel panic and the status is kept until the capture kernel 
booting.

So, this interrupt will be handled during capture kernel booting.

Becasue we use virt timer interrupt but not physical timer interrupt in capture 
kernel,
the interrupt 30 has no action handler.

Besides, I think we need to do exception check in this function just
like "handle_fasteoi_irq" does.

Thanks
MaJun

> Thanks,
> 
>   M.
> 

[PATCH] generic: Add the exception case checking routine for ppi interrupt

[MaJun]

From: Ma Jun <majun...@huawei.com>

During system booting, if the interrupt which has no action registered
is triggered, it would cause system panic when try to access the
action member.

Signed-off-by: Ma Jun <majun...@huawei.com>
---
 kernel/irq/chip.c |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 8114d06..9a0e872 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -766,11 +766,23 @@ handle_percpu_irq(unsigned int irq, struct irq_desc *desc)
  */
 void handle_percpu_devid_irq(unsigned int irq, struct irq_desc *desc)
 {
-   struct irq_chip *chip = irq_desc_get_chip(desc);
-   struct irqaction *action = desc->action;
-   void *dev_id = raw_cpu_ptr(action->percpu_dev_id);
+   struct irq_chip *chip = NULL;
+   struct irqaction *action;
+   void *dev_id;
irqreturn_t res;
 
+   action = desc->action;
+
+   /* Unexpected interrupt in some execption case
+* we just send eoi to end this interrupt
+*/
+   if (unlikely(!action)) {
+   mask_irq(desc);
+   goto out;
+   }
+   dev_id = raw_cpu_ptr(action->percpu_dev_id);
+
+   chip = irq_desc_get_chip(desc);
kstat_incr_irqs_this_cpu(irq, desc);
 
if (chip->irq_ack)
@@ -779,7 +791,7 @@ void handle_percpu_devid_irq(unsigned int irq, struct 
irq_desc *desc)
trace_irq_handler_entry(irq, action);
res = action->handler(irq, dev_id);
trace_irq_handler_exit(irq, action, res);
-
+out:
if (chip->irq_eoi)
chip->irq_eoi(>irq_data);
 }
-- 
1.7.1

[PATCH] generic: Add the exception case checking routine for ppi interrupt

[MaJun]

From: Ma Jun 

During system booting, if the interrupt which has no action registered
is triggered, it would cause system panic when try to access the
action member.

Signed-off-by: Ma Jun 
---
 kernel/irq/chip.c |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 8114d06..9a0e872 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -766,11 +766,23 @@ handle_percpu_irq(unsigned int irq, struct irq_desc *desc)
  */
 void handle_percpu_devid_irq(unsigned int irq, struct irq_desc *desc)
 {
-   struct irq_chip *chip = irq_desc_get_chip(desc);
-   struct irqaction *action = desc->action;
-   void *dev_id = raw_cpu_ptr(action->percpu_dev_id);
+   struct irq_chip *chip = NULL;
+   struct irqaction *action;
+   void *dev_id;
irqreturn_t res;
 
+   action = desc->action;
+
+   /* Unexpected interrupt in some execption case
+* we just send eoi to end this interrupt
+*/
+   if (unlikely(!action)) {
+   mask_irq(desc);
+   goto out;
+   }
+   dev_id = raw_cpu_ptr(action->percpu_dev_id);
+
+   chip = irq_desc_get_chip(desc);
kstat_incr_irqs_this_cpu(irq, desc);
 
if (chip->irq_ack)
@@ -779,7 +791,7 @@ void handle_percpu_devid_irq(unsigned int irq, struct 
irq_desc *desc)
trace_irq_handler_entry(irq, action);
res = action->handler(irq, dev_id);
trace_irq_handler_exit(irq, action, res);
-
+out:
if (chip->irq_eoi)
chip->irq_eoi(>irq_data);
 }
-- 
1.7.1

Re: [PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver.

[majun (F)]

Hi Marc:

在 2016/5/6 15:32, Marc Zyngier 写道:
> On 06/05/16 02:12, majun (F) wrote:
>> Hi Marc:
>>
>> 在 2016/5/5 22:49, Marc Zyngier 写道:
>>> On 22/03/16 03:10, majun (F) wrote:
>>>>
>>>>
>>>> 在 2016/3/21 18:29, Thomas Gleixner 写道:
>>>>> On Thu, 17 Mar 2016, MaJun wrote:
>>>>>> This patch set is used to fix the problem of remap a set of registers
>>>>>> repeatedly in current mbigen driver.
>>>>>>
>>>>>>   irqchip/mbigen:Change the mbigen node definition in dt binding file
>>>>>>   irqchip/mbigen:Change the mbigen driver based on the new mbigen node 
>>>>>> definition
>>>>>
>>>>> These subject lines are still horrible as they tell nothing about the 
>>>>> nature
>>>>> of the change. I fixed them up along with the changelogs and applied them 
>>>>> to
>>>>> irq/urgent. Can you spot the difference?
>>>>
>>>> Yes, after you changing, the subject and change log clearly show why we 
>>>> need to
>>>> do this change.
>>>> I have learned a lot from you :)
>>>>
>>>>>
>>>>> While at it. The config switch for this driver is horrible. It's just in 
>>>>> the
>>>>> middle of the device driver configs. Why is this configurable by the user 
>>>>> at
>>>>> all? It simply should be selected by arm64 or some subarch configuration
>>>>> there. Please clean that up.
>>>>>
>>>> will do.
>>>
>>> So what's the status of this? Do you still plan to respin it?
>>>
>>
>> This patch set had been ACK by Thomas.
> 
> Interesting. Somehow, the ARM email server has decided not to deliver
> the tip-bot messages, so I didn't see it was already in.
> 
> Sorry for the noise.

Not at all. Thank you for your attention.
MaJun
Thanks!
> 
>   M.
> 

Re: [PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver.

[majun (F)]

Hi Marc:

在 2016/5/6 15:32, Marc Zyngier 写道:
> On 06/05/16 02:12, majun (F) wrote:
>> Hi Marc:
>>
>> 在 2016/5/5 22:49, Marc Zyngier 写道:
>>> On 22/03/16 03:10, majun (F) wrote:
>>>>
>>>>
>>>> 在 2016/3/21 18:29, Thomas Gleixner 写道:
>>>>> On Thu, 17 Mar 2016, MaJun wrote:
>>>>>> This patch set is used to fix the problem of remap a set of registers
>>>>>> repeatedly in current mbigen driver.
>>>>>>
>>>>>>   irqchip/mbigen:Change the mbigen node definition in dt binding file
>>>>>>   irqchip/mbigen:Change the mbigen driver based on the new mbigen node 
>>>>>> definition
>>>>>
>>>>> These subject lines are still horrible as they tell nothing about the 
>>>>> nature
>>>>> of the change. I fixed them up along with the changelogs and applied them 
>>>>> to
>>>>> irq/urgent. Can you spot the difference?
>>>>
>>>> Yes, after you changing, the subject and change log clearly show why we 
>>>> need to
>>>> do this change.
>>>> I have learned a lot from you :)
>>>>
>>>>>
>>>>> While at it. The config switch for this driver is horrible. It's just in 
>>>>> the
>>>>> middle of the device driver configs. Why is this configurable by the user 
>>>>> at
>>>>> all? It simply should be selected by arm64 or some subarch configuration
>>>>> there. Please clean that up.
>>>>>
>>>> will do.
>>>
>>> So what's the status of this? Do you still plan to respin it?
>>>
>>
>> This patch set had been ACK by Thomas.
> 
> Interesting. Somehow, the ARM email server has decided not to deliver
> the tip-bot messages, so I didn't see it was already in.
> 
> Sorry for the noise.

Not at all. Thank you for your attention.
MaJun
Thanks!
> 
>   M.
> 

Re: [PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver.

[majun (F)]

Hi Marc:

在 2016/5/5 22:49, Marc Zyngier 写道:
> On 22/03/16 03:10, majun (F) wrote:
>>
>>
>> 在 2016/3/21 18:29, Thomas Gleixner 写道:
>>> On Thu, 17 Mar 2016, MaJun wrote:
>>>> This patch set is used to fix the problem of remap a set of registers
>>>> repeatedly in current mbigen driver.
>>>>
>>>>   irqchip/mbigen:Change the mbigen node definition in dt binding file
>>>>   irqchip/mbigen:Change the mbigen driver based on the new mbigen node 
>>>> definition
>>>
>>> These subject lines are still horrible as they tell nothing about the nature
>>> of the change. I fixed them up along with the changelogs and applied them to
>>> irq/urgent. Can you spot the difference?
>>
>> Yes, after you changing, the subject and change log clearly show why we need 
>> to
>> do this change.
>> I have learned a lot from you :)
>>
>>>
>>> While at it. The config switch for this driver is horrible. It's just in the
>>> middle of the device driver configs. Why is this configurable by the user at
>>> all? It simply should be selected by arm64 or some subarch configuration
>>> there. Please clean that up.
>>>
>> will do.
> 
> So what's the status of this? Do you still plan to respin it?
> 

This patch set had been ACK by Thomas.
If you mean the mbigen driver config switch problem, the patch for this problem 
also
had been ACK by thomas.
please see the link:
https://lkml.org/lkml/2016/3/23/76

Thanks
Ma Jun

> Thanks,
> 
>   M.
> 

Re: [PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver.

[majun (F)]

Hi Marc:

在 2016/5/5 22:49, Marc Zyngier 写道:
> On 22/03/16 03:10, majun (F) wrote:
>>
>>
>> 在 2016/3/21 18:29, Thomas Gleixner 写道:
>>> On Thu, 17 Mar 2016, MaJun wrote:
>>>> This patch set is used to fix the problem of remap a set of registers
>>>> repeatedly in current mbigen driver.
>>>>
>>>>   irqchip/mbigen:Change the mbigen node definition in dt binding file
>>>>   irqchip/mbigen:Change the mbigen driver based on the new mbigen node 
>>>> definition
>>>
>>> These subject lines are still horrible as they tell nothing about the nature
>>> of the change. I fixed them up along with the changelogs and applied them to
>>> irq/urgent. Can you spot the difference?
>>
>> Yes, after you changing, the subject and change log clearly show why we need 
>> to
>> do this change.
>> I have learned a lot from you :)
>>
>>>
>>> While at it. The config switch for this driver is horrible. It's just in the
>>> middle of the device driver configs. Why is this configurable by the user at
>>> all? It simply should be selected by arm64 or some subarch configuration
>>> there. Please clean that up.
>>>
>> will do.
> 
> So what's the status of this? Do you still plan to respin it?
> 

This patch set had been ACK by Thomas.
If you mean the mbigen driver config switch problem, the patch for this problem 
also
had been ACK by thomas.
please see the link:
https://lkml.org/lkml/2016/3/23/76

Thanks
Ma Jun

> Thanks,
> 
>   M.
> 

[RFC PATCH] genirq: Change the non-balanced irq to balance irq when the cpu of the irq bounded off line

[MaJun]

From: Ma Jun <majun...@huawei.com>

When the CPU of a non-balanced irq bounded is off line, the irq will be 
migrated to other CPUs,
usually the first cpu on-line.

We can suppose the situation if a system has more than one non-balanced irq.
At extreme case, these irqs will be migrated to the same CPU and will cause the 
CPU run with high irq pressure, even make the system die.

So, I think maybe we need to change the non-balanced irq to a irq can be
balanced to avoid the problem descried above.

Maybe this is not a good solution for this problem, please offer me some
suggestion if you have a better one.

Signed-off-by: Ma Jun <majun...@huawei.com>
---
 kernel/irq/cpuhotplug.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/kernel/irq/cpuhotplug.c b/kernel/irq/cpuhotplug.c
index 011f8c4..80d54a5 100644
--- a/kernel/irq/cpuhotplug.c
+++ b/kernel/irq/cpuhotplug.c
@@ -30,6 +30,8 @@ static bool migrate_one_irq(struct irq_desc *desc)
return false;
 
if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
+   if (irq_settings_has_no_balance_set(desc))
+   irqd_clear(d, IRQD_NO_BALANCING);
affinity = cpu_online_mask;
ret = true;
}
-- 
1.7.1

[RFC PATCH] genirq: Change the non-balanced irq to balance irq when the cpu of the irq bounded off line

[MaJun]

From: Ma Jun 

When the CPU of a non-balanced irq bounded is off line, the irq will be 
migrated to other CPUs,
usually the first cpu on-line.

We can suppose the situation if a system has more than one non-balanced irq.
At extreme case, these irqs will be migrated to the same CPU and will cause the 
CPU run with high irq pressure, even make the system die.

So, I think maybe we need to change the non-balanced irq to a irq can be
balanced to avoid the problem descried above.

Maybe this is not a good solution for this problem, please offer me some
suggestion if you have a better one.

Signed-off-by: Ma Jun 
---
 kernel/irq/cpuhotplug.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/kernel/irq/cpuhotplug.c b/kernel/irq/cpuhotplug.c
index 011f8c4..80d54a5 100644
--- a/kernel/irq/cpuhotplug.c
+++ b/kernel/irq/cpuhotplug.c
@@ -30,6 +30,8 @@ static bool migrate_one_irq(struct irq_desc *desc)
return false;
 
if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
+   if (irq_settings_has_no_balance_set(desc))
+   irqd_clear(d, IRQD_NO_BALANCING);
affinity = cpu_online_mask;
ret = true;
}
-- 
1.7.1

[tip:irq/urgent] irqchip/mbigen: Make CONFIG_HISILICON_IRQ_MBIGEN a hidden option

[tip-bot for MaJun]

Commit-ID:  9a7c4abd41c0d553f4fb9845bdd4328155426ac7
Gitweb: http://git.kernel.org/tip/9a7c4abd41c0d553f4fb9845bdd4328155426ac7
Author: MaJun <majun...@huawei.com>
AuthorDate: Wed, 23 Mar 2016 17:06:33 +0800
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Wed, 23 Mar 2016 12:02:29 +0100

irqchip/mbigen: Make CONFIG_HISILICON_IRQ_MBIGEN a hidden option

This config is selected by CONFIG_ARCH_HISI, so there is no point to have it
user configurable.

While at it move the config option to the proper place in the alphabetically
sorted option list.

Requested-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Ma Jun <majun...@huawei.com>
Cc: mark.rutl...@arm.com
Cc: ja...@lakedaemon.net
Cc: marc.zyng...@arm.com
Cc: catalin.mari...@arm.com
Cc: guohan...@huawei.com
Cc: will.dea...@arm.com
Cc: huxin...@huawei.com
Cc: lize...@huawei.com
Cc: dingtianh...@huawei.com
Cc: zhaojun...@hisilicon.com
Cc: liguo...@hisilicon.com
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1458723993-21044-3-git-send-email-majun...@huawei.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>

---
 drivers/irqchip/Kconfig | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 7e8c441..3e12479 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -32,14 +32,6 @@ config ARM_GIC_V3_ITS
bool
select PCI_MSI_IRQ_DOMAIN
 
-config HISILICON_IRQ_MBIGEN
-   bool "Support mbigen interrupt controller"
-   default n
-   depends on ARM_GIC_V3 && ARM_GIC_V3_ITS && GENERIC_MSI_IRQ_DOMAIN
-   help
-Enable the mbigen interrupt controller used on
-Hisilicon platform.
-
 config ARM_NVIC
bool
select IRQ_DOMAIN
@@ -114,6 +106,12 @@ config DW_APB_ICTL
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
 
+config HISILICON_IRQ_MBIGEN
+   bool
+   select ARM_GIC_V3
+   select ARM_GIC_V3_ITS
+   select GENERIC_MSI_IRQ_DOMAIN
+
 config IMGPDC_IRQ
bool
select GENERIC_IRQ_CHIP

[tip:irq/urgent] irqchip/mbigen: Make CONFIG_HISILICON_IRQ_MBIGEN a hidden option

[tip-bot for MaJun]

Commit-ID:  9a7c4abd41c0d553f4fb9845bdd4328155426ac7
Gitweb: http://git.kernel.org/tip/9a7c4abd41c0d553f4fb9845bdd4328155426ac7
Author: MaJun 
AuthorDate: Wed, 23 Mar 2016 17:06:33 +0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 23 Mar 2016 12:02:29 +0100

irqchip/mbigen: Make CONFIG_HISILICON_IRQ_MBIGEN a hidden option

This config is selected by CONFIG_ARCH_HISI, so there is no point to have it
user configurable.

While at it move the config option to the proper place in the alphabetically
sorted option list.

Requested-by: Thomas Gleixner 
Signed-off-by: Ma Jun 
Cc: mark.rutl...@arm.com
Cc: ja...@lakedaemon.net
Cc: marc.zyng...@arm.com
Cc: catalin.mari...@arm.com
Cc: guohan...@huawei.com
Cc: will.dea...@arm.com
Cc: huxin...@huawei.com
Cc: lize...@huawei.com
Cc: dingtianh...@huawei.com
Cc: zhaojun...@hisilicon.com
Cc: liguo...@hisilicon.com
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1458723993-21044-3-git-send-email-majun...@huawei.com
Signed-off-by: Thomas Gleixner 

---
 drivers/irqchip/Kconfig | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 7e8c441..3e12479 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -32,14 +32,6 @@ config ARM_GIC_V3_ITS
bool
select PCI_MSI_IRQ_DOMAIN
 
-config HISILICON_IRQ_MBIGEN
-   bool "Support mbigen interrupt controller"
-   default n
-   depends on ARM_GIC_V3 && ARM_GIC_V3_ITS && GENERIC_MSI_IRQ_DOMAIN
-   help
-Enable the mbigen interrupt controller used on
-Hisilicon platform.
-
 config ARM_NVIC
bool
select IRQ_DOMAIN
@@ -114,6 +106,12 @@ config DW_APB_ICTL
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
 
+config HISILICON_IRQ_MBIGEN
+   bool
+   select ARM_GIC_V3
+   select ARM_GIC_V3_ITS
+   select GENERIC_MSI_IRQ_DOMAIN
+
 config IMGPDC_IRQ
bool
select GENERIC_IRQ_CHIP

[tip:irq/urgent] ARM64: Kconfig: Select mbigen interrupt controller on Hisilicon platform

[tip-bot for MaJun]

Commit-ID:  dd17a3c40d46adea7215cad3f8fa0afb7c616290
Gitweb: http://git.kernel.org/tip/dd17a3c40d46adea7215cad3f8fa0afb7c616290
Author: MaJun <majun...@huawei.com>
AuthorDate: Wed, 23 Mar 2016 17:06:32 +0800
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Wed, 23 Mar 2016 12:02:29 +0100

ARM64: Kconfig: Select mbigen interrupt controller on Hisilicon platform

As a interrupt controller used on some of hisilicon SOCs(660,1610 etc.),
mbigen driver should be enabled when CONFIG_ARCH_HISI is enabled.

Signed-off-by: Ma Jun <majun...@huawei.com>
Cc: mark.rutl...@arm.com
Cc: ja...@lakedaemon.net
Cc: marc.zyng...@arm.com
Cc: catalin.mari...@arm.com
Cc: guohan...@huawei.com
Cc: will.dea...@arm.com
Cc: huxin...@huawei.com
Cc: lize...@huawei.com
Cc: dingtianh...@huawei.com
Cc: zhaojun...@hisilicon.com
Cc: liguo...@hisilicon.com
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1458723993-21044-2-git-send-email-majun...@huawei.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>

---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f6..fdfd526 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -37,6 +37,7 @@ config ARCH_LAYERSCAPE
 
 config ARCH_HISI
bool "Hisilicon SoC Family"
+   select HISILICON_IRQ_MBIGEN
help
  This enables support for Hisilicon ARMv8 SoC family
 

[tip:irq/urgent] ARM64: Kconfig: Select mbigen interrupt controller on Hisilicon platform

[tip-bot for MaJun]

Commit-ID:  dd17a3c40d46adea7215cad3f8fa0afb7c616290
Gitweb: http://git.kernel.org/tip/dd17a3c40d46adea7215cad3f8fa0afb7c616290
Author: MaJun 
AuthorDate: Wed, 23 Mar 2016 17:06:32 +0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 23 Mar 2016 12:02:29 +0100

ARM64: Kconfig: Select mbigen interrupt controller on Hisilicon platform

As a interrupt controller used on some of hisilicon SOCs(660,1610 etc.),
mbigen driver should be enabled when CONFIG_ARCH_HISI is enabled.

Signed-off-by: Ma Jun 
Cc: mark.rutl...@arm.com
Cc: ja...@lakedaemon.net
Cc: marc.zyng...@arm.com
Cc: catalin.mari...@arm.com
Cc: guohan...@huawei.com
Cc: will.dea...@arm.com
Cc: huxin...@huawei.com
Cc: lize...@huawei.com
Cc: dingtianh...@huawei.com
Cc: zhaojun...@hisilicon.com
Cc: liguo...@hisilicon.com
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1458723993-21044-2-git-send-email-majun...@huawei.com
Signed-off-by: Thomas Gleixner 

---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f6..fdfd526 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -37,6 +37,7 @@ config ARCH_LAYERSCAPE
 
 config ARCH_HISI
bool "Hisilicon SoC Family"
+   select HISILICON_IRQ_MBIGEN
help
  This enables support for Hisilicon ARMv8 SoC family
 

[PATCH 1/2]ARM64: Enable mbigen interrupt controller on Hisilicon platform

[MaJun]

From: Ma Jun <majun...@huawei.com>

As a interrupt controller used on some of hisilicon SOCs(660,1610 etc.),
mbigen driver should be enabled when CONFIG_ARCH_HISI is enabled.
Signed-off-by: Ma Jun <majun...@huawei.com>
---
 arch/arm64/Kconfig.platforms |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f6..fdfd526 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -37,6 +37,7 @@ config ARCH_LAYERSCAPE
 
 config ARCH_HISI
bool "Hisilicon SoC Family"
+   select HISILICON_IRQ_MBIGEN
help
  This enables support for Hisilicon ARMv8 SoC family
 
-- 
1.7.1

[PATCH 1/2]ARM64: Enable mbigen interrupt controller on Hisilicon platform

[MaJun]

From: Ma Jun 

As a interrupt controller used on some of hisilicon SOCs(660,1610 etc.),
mbigen driver should be enabled when CONFIG_ARCH_HISI is enabled.
Signed-off-by: Ma Jun 
---
 arch/arm64/Kconfig.platforms |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f6..fdfd526 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -37,6 +37,7 @@ config ARCH_LAYERSCAPE
 
 config ARCH_HISI
bool "Hisilicon SoC Family"
+   select HISILICON_IRQ_MBIGEN
help
  This enables support for Hisilicon ARMv8 SoC family
 
-- 
1.7.1

[PATCH 2/2] irqchip/mbigen:Change the config option of mbigen driver to non-configurable

[MaJun]

From: Ma Jun <majun...@huawei.com>

This config is selected by CONFIG_ARCH_HISI, So we change
this config to non-configurable.

I also adjust the mbigen config position try to sort the configs
in alphabetical order.

Signed-off-by: Ma Jun <majun...@huawei.com>
---
 drivers/irqchip/Kconfig |   14 ++
 1 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 7e8c441..3e12479 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -32,14 +32,6 @@ config ARM_GIC_V3_ITS
bool
select PCI_MSI_IRQ_DOMAIN
 
-config HISILICON_IRQ_MBIGEN
-   bool "Support mbigen interrupt controller"
-   default n
-   depends on ARM_GIC_V3 && ARM_GIC_V3_ITS && GENERIC_MSI_IRQ_DOMAIN
-   help
-Enable the mbigen interrupt controller used on
-Hisilicon platform.
-
 config ARM_NVIC
bool
select IRQ_DOMAIN
@@ -114,6 +106,12 @@ config DW_APB_ICTL
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
 
+config HISILICON_IRQ_MBIGEN
+   bool
+   select ARM_GIC_V3
+   select ARM_GIC_V3_ITS
+   select GENERIC_MSI_IRQ_DOMAIN
+
 config IMGPDC_IRQ
bool
select GENERIC_IRQ_CHIP
-- 
1.7.1

[PATCH 0/2] Change the the config option of mbigen driver.

[MaJun]

From: Ma Jun <majun...@huawei.com>

In current driver, the config of mbigen driver is a configurable option and
have nothing to do with CONFIG_ARCH_HISI.

As a module of Hisilicon SOC, the config of mbigen driver should be selected
by CONFIG_ARCH_HISI on Hisilicon platform, but not a configurable option.

This patch set is applied to fix this problem.

Ma Jun (2):
  ARM64: Enable mbigen interrupt controller on Hisilicon platform
  irqchip/mbigen:Change the config option of mbigen driver to non-configurable

 arch/arm64/Kconfig.platforms |1 +
 drivers/irqchip/Kconfig  |   14 ++
 2 files changed, 7 insertions(+), 8 deletions(-)

[PATCH 2/2] irqchip/mbigen:Change the config option of mbigen driver to non-configurable

[MaJun]

From: Ma Jun 

This config is selected by CONFIG_ARCH_HISI, So we change
this config to non-configurable.

I also adjust the mbigen config position try to sort the configs
in alphabetical order.

Signed-off-by: Ma Jun 
---
 drivers/irqchip/Kconfig |   14 ++
 1 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 7e8c441..3e12479 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -32,14 +32,6 @@ config ARM_GIC_V3_ITS
bool
select PCI_MSI_IRQ_DOMAIN
 
-config HISILICON_IRQ_MBIGEN
-   bool "Support mbigen interrupt controller"
-   default n
-   depends on ARM_GIC_V3 && ARM_GIC_V3_ITS && GENERIC_MSI_IRQ_DOMAIN
-   help
-Enable the mbigen interrupt controller used on
-Hisilicon platform.
-
 config ARM_NVIC
bool
select IRQ_DOMAIN
@@ -114,6 +106,12 @@ config DW_APB_ICTL
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
 
+config HISILICON_IRQ_MBIGEN
+   bool
+   select ARM_GIC_V3
+   select ARM_GIC_V3_ITS
+   select GENERIC_MSI_IRQ_DOMAIN
+
 config IMGPDC_IRQ
bool
select GENERIC_IRQ_CHIP
-- 
1.7.1

[PATCH 0/2] Change the the config option of mbigen driver.

[MaJun]

From: Ma Jun 

In current driver, the config of mbigen driver is a configurable option and
have nothing to do with CONFIG_ARCH_HISI.

As a module of Hisilicon SOC, the config of mbigen driver should be selected
by CONFIG_ARCH_HISI on Hisilicon platform, but not a configurable option.

This patch set is applied to fix this problem.

Ma Jun (2):
  ARM64: Enable mbigen interrupt controller on Hisilicon platform
  irqchip/mbigen:Change the config option of mbigen driver to non-configurable

 arch/arm64/Kconfig.platforms |1 +
 drivers/irqchip/Kconfig  |   14 ++
 2 files changed, 7 insertions(+), 8 deletions(-)

Re: [PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver.

[majun (F)]

在 2016/3/21 18:29, Thomas Gleixner 写道:
> On Thu, 17 Mar 2016, MaJun wrote:
>> This patch set is used to fix the problem of remap a set of registers
>> repeatedly in current mbigen driver.
>>
>>   irqchip/mbigen:Change the mbigen node definition in dt binding file
>>   irqchip/mbigen:Change the mbigen driver based on the new mbigen node 
>> definition
> 
> These subject lines are still horrible as they tell nothing about the nature
> of the change. I fixed them up along with the changelogs and applied them to
> irq/urgent. Can you spot the difference?

Yes, after you changing, the subject and change log clearly show why we need to
do this change.
I have learned a lot from you :)

> 
> While at it. The config switch for this driver is horrible. It's just in the
> middle of the device driver configs. Why is this configurable by the user at
> all? It simply should be selected by arm64 or some subarch configuration
> there. Please clean that up.
> 
will do.

Thanks!
MaJun

> Thanks,
> 
>   tglx
> 
> .
> 

Re: [PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver.

[majun (F)]

在 2016/3/21 18:29, Thomas Gleixner 写道:
> On Thu, 17 Mar 2016, MaJun wrote:
>> This patch set is used to fix the problem of remap a set of registers
>> repeatedly in current mbigen driver.
>>
>>   irqchip/mbigen:Change the mbigen node definition in dt binding file
>>   irqchip/mbigen:Change the mbigen driver based on the new mbigen node 
>> definition
> 
> These subject lines are still horrible as they tell nothing about the nature
> of the change. I fixed them up along with the changelogs and applied them to
> irq/urgent. Can you spot the difference?

Yes, after you changing, the subject and change log clearly show why we need to
do this change.
I have learned a lot from you :)

> 
> While at it. The config switch for this driver is horrible. It's just in the
> middle of the device driver configs. Why is this configurable by the user at
> all? It simply should be selected by arm64 or some subarch configuration
> there. Please clean that up.
> 
will do.

Thanks!
MaJun

> Thanks,
> 
>   tglx
> 
> .
> 

[tip:irq/urgent] irqchip/mbigen: Adjust DT bindings to handle multiple devices in a module

[tip-bot for MaJun]

Commit-ID:  d0e286415dc1f4fea2971d6186b0775c7062575b
Gitweb: http://git.kernel.org/tip/d0e286415dc1f4fea2971d6186b0775c7062575b
Author: MaJun <majun...@huawei.com>
AuthorDate: Thu, 17 Mar 2016 16:34:00 +0800
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Mon, 21 Mar 2016 11:24:10 +0100

irqchip/mbigen: Adjust DT bindings to handle multiple devices in a module

A mbigen hardware module can contain more than one device node. These device
nodes contain the same register definition.

mbigen_dev1:intc_dev1 {
...
reg = <0x0 0xc008 0x0 0x1>;
...
};

mbigen_dev2:intc_dev2 {
...
reg = <0x0 0xc008 0x0 0x1>;
...
};

In this case both devices try to request the same resource resulting in a
resource conflict.

To address this problem the devices need to be subnodes of the mbigen hardware
module, which then contains the unique register space.

[ tglx: Massaged changelog ]

Suggested-by: Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: Ma Jun <majun...@huawei.com>
Cc: ja...@lakedaemon.net
Cc: marc.zyng...@arm.com
Cc: catalin.mari...@arm.com
Cc: guohan...@huawei.com
Cc: will.dea...@arm.com
Cc: huxin...@huawei.com
Cc: lize...@huawei.com
Cc: dingtianh...@huawei.com
Cc: zhaojun...@hisilicon.com
Cc: liguo...@hisilicon.com
Cc: linux-arm-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/20160203111602.GA1234@leverpostej
Link: 
http://lkml.kernel.org/r/1458203641-17172-2-git-send-email-majun...@huawei.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>

---
 .../interrupt-controller/hisilicon,mbigen-v2.txt   | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
index 720f7c9..3b2f4c4 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
@@ -21,6 +21,8 @@ Mbigen main node required properties:
 - reg: Specifies the base physical address and size of the Mbigen
   registers.
 
+Mbigen sub node required properties:
+--
 - interrupt controller: Identifies the node as an interrupt controller
 
 - msi-parent: Specifies the MSI controller this mbigen use.
@@ -45,13 +47,23 @@ Mbigen main node required properties:
 
 Examples:
 
-   mbigen_device_gmac:intc {
+   mbigen_chip_dsa {
compatible = "hisilicon,mbigen-v2";
reg = <0x0 0xc008 0x0 0x1>;
-   interrupt-controller;
-   msi-parent = <_dsa 0x40b1c>;
-   num-pins = <9>;
-   #interrupt-cells = <2>;
+
+   mbigen_gmac:intc_gmac {
+   interrupt-controller;
+   msi-parent = <_dsa 0x40b1c>;
+   num-pins = <9>;
+   #interrupt-cells = <2>;
+   };
+
+   mbigen_i2c:intc_i2c {
+   interrupt-controller;
+   msi-parent = <_dsa 0x40b0e>;
+   num-pins = <2>;
+   #interrupt-cells = <2>;
+   };
};
 
 Devices connect to mbigen required properties:

[tip:irq/urgent] irqchip/mbigen: Adjust DT bindings to handle multiple devices in a module

[tip-bot for MaJun]

Commit-ID:  d0e286415dc1f4fea2971d6186b0775c7062575b
Gitweb: http://git.kernel.org/tip/d0e286415dc1f4fea2971d6186b0775c7062575b
Author: MaJun 
AuthorDate: Thu, 17 Mar 2016 16:34:00 +0800
Committer:  Thomas Gleixner 
CommitDate: Mon, 21 Mar 2016 11:24:10 +0100

irqchip/mbigen: Adjust DT bindings to handle multiple devices in a module

A mbigen hardware module can contain more than one device node. These device
nodes contain the same register definition.

mbigen_dev1:intc_dev1 {
...
reg = <0x0 0xc008 0x0 0x1>;
...
};

mbigen_dev2:intc_dev2 {
...
reg = <0x0 0xc008 0x0 0x1>;
...
};

In this case both devices try to request the same resource resulting in a
resource conflict.

To address this problem the devices need to be subnodes of the mbigen hardware
module, which then contains the unique register space.

[ tglx: Massaged changelog ]

Suggested-by: Mark Rutland 
Signed-off-by: Ma Jun 
Cc: ja...@lakedaemon.net
Cc: marc.zyng...@arm.com
Cc: catalin.mari...@arm.com
Cc: guohan...@huawei.com
Cc: will.dea...@arm.com
Cc: huxin...@huawei.com
Cc: lize...@huawei.com
Cc: dingtianh...@huawei.com
Cc: zhaojun...@hisilicon.com
Cc: liguo...@hisilicon.com
Cc: linux-arm-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/20160203111602.GA1234@leverpostej
Link: 
http://lkml.kernel.org/r/1458203641-17172-2-git-send-email-majun...@huawei.com
Signed-off-by: Thomas Gleixner 

---
 .../interrupt-controller/hisilicon,mbigen-v2.txt   | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
index 720f7c9..3b2f4c4 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
@@ -21,6 +21,8 @@ Mbigen main node required properties:
 - reg: Specifies the base physical address and size of the Mbigen
   registers.
 
+Mbigen sub node required properties:
+--
 - interrupt controller: Identifies the node as an interrupt controller
 
 - msi-parent: Specifies the MSI controller this mbigen use.
@@ -45,13 +47,23 @@ Mbigen main node required properties:
 
 Examples:
 
-   mbigen_device_gmac:intc {
+   mbigen_chip_dsa {
compatible = "hisilicon,mbigen-v2";
reg = <0x0 0xc008 0x0 0x1>;
-   interrupt-controller;
-   msi-parent = <_dsa 0x40b1c>;
-   num-pins = <9>;
-   #interrupt-cells = <2>;
+
+   mbigen_gmac:intc_gmac {
+   interrupt-controller;
+   msi-parent = <_dsa 0x40b1c>;
+   num-pins = <9>;
+   #interrupt-cells = <2>;
+   };
+
+   mbigen_i2c:intc_i2c {
+   interrupt-controller;
+   msi-parent = <_dsa 0x40b0e>;
+   num-pins = <2>;
+   #interrupt-cells = <2>;
+   };
};
 
 Devices connect to mbigen required properties:

[tip:irq/urgent] irqchip/mbigen: Handle multiple device nodes in a mbigen module

[tip-bot for MaJun]

Commit-ID:  ed2a1002d25ccdb6606c8ccb608524118bd30614
Gitweb: http://git.kernel.org/tip/ed2a1002d25ccdb6606c8ccb608524118bd30614
Author: MaJun <majun...@huawei.com>
AuthorDate: Thu, 17 Mar 2016 16:34:01 +0800
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Mon, 21 Mar 2016 11:24:11 +0100

irqchip/mbigen: Handle multiple device nodes in a mbigen module

Each mbigen device is represented as a independent platform device. If the
devices belong to the same mbigen hardware module, then the register space for
these devices is the same. That leads to a resource conflict.

The solution for this is to represent the mbigen module as a platform device
and make the mbigen devices subdevices of that. The register space is
associated to the mbigen module and therefor the resource conflict is avoided.

[ tglx: Massaged changelog, cleaned up the code and removed the silly printk ]

Signed-off-by: Ma Jun <majun...@huawei.com>
Cc: mark.rutl...@arm.com
Cc: ja...@lakedaemon.net
Cc: marc.zyng...@arm.com
Cc: catalin.mari...@arm.com
Cc: guohan...@huawei.com
Cc: will.dea...@arm.com
Cc: huxin...@huawei.com
Cc: lize...@huawei.com
Cc: dingtianh...@huawei.com
Cc: zhaojun...@hisilicon.com
Cc: liguo...@hisilicon.com
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1458203641-17172-3-git-send-email-majun...@huawei.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
---
 drivers/irqchip/irq-mbigen.c | 38 --
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4dd3eb8..d67baa2 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -239,8 +239,11 @@ static struct irq_domain_ops mbigen_domain_ops = {
 static int mbigen_device_probe(struct platform_device *pdev)
 {
struct mbigen_device *mgn_chip;
-   struct resource *res;
+   struct platform_device *child;
struct irq_domain *domain;
+   struct device_node *np;
+   struct device *parent;
+   struct resource *res;
u32 num_pins;
 
mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
@@ -254,23 +257,30 @@ static int mbigen_device_probe(struct platform_device 
*pdev)
if (IS_ERR(mgn_chip->base))
return PTR_ERR(mgn_chip->base);
 
-   if (of_property_read_u32(pdev->dev.of_node, "num-pins", _pins) < 0) 
{
-   dev_err(>dev, "No num-pins property\n");
-   return -EINVAL;
-   }
+   for_each_child_of_node(pdev->dev.of_node, np) {
+   if (!of_property_read_bool(np, "interrupt-controller"))
+   continue;
 
-   domain = platform_msi_create_device_domain(>dev, num_pins,
-   mbigen_write_msg,
-   _domain_ops,
-   mgn_chip);
+   parent = platform_bus_type.dev_root;
+   child = of_platform_device_create(np, NULL, parent);
+   if (IS_ERR(child))
+   return PTR_ERR(child);
 
-   if (!domain)
-   return -ENOMEM;
+   if (of_property_read_u32(child->dev.of_node, "num-pins",
+_pins) < 0) {
+   dev_err(>dev, "No num-pins property\n");
+   return -EINVAL;
+   }
+
+   domain = platform_msi_create_device_domain(>dev, 
num_pins,
+  mbigen_write_msg,
+  _domain_ops,
+  mgn_chip);
+   if (!domain)
+   return -ENOMEM;
+   }
 
platform_set_drvdata(pdev, mgn_chip);
-
-   dev_info(>dev, "Allocated %d MSIs\n", num_pins);
-
return 0;
 }
 

[tip:irq/urgent] irqchip/mbigen: Handle multiple device nodes in a mbigen module

[tip-bot for MaJun]

Commit-ID:  ed2a1002d25ccdb6606c8ccb608524118bd30614
Gitweb: http://git.kernel.org/tip/ed2a1002d25ccdb6606c8ccb608524118bd30614
Author: MaJun 
AuthorDate: Thu, 17 Mar 2016 16:34:01 +0800
Committer:  Thomas Gleixner 
CommitDate: Mon, 21 Mar 2016 11:24:11 +0100

irqchip/mbigen: Handle multiple device nodes in a mbigen module

Each mbigen device is represented as a independent platform device. If the
devices belong to the same mbigen hardware module, then the register space for
these devices is the same. That leads to a resource conflict.

The solution for this is to represent the mbigen module as a platform device
and make the mbigen devices subdevices of that. The register space is
associated to the mbigen module and therefor the resource conflict is avoided.

[ tglx: Massaged changelog, cleaned up the code and removed the silly printk ]

Signed-off-by: Ma Jun 
Cc: mark.rutl...@arm.com
Cc: ja...@lakedaemon.net
Cc: marc.zyng...@arm.com
Cc: catalin.mari...@arm.com
Cc: guohan...@huawei.com
Cc: will.dea...@arm.com
Cc: huxin...@huawei.com
Cc: lize...@huawei.com
Cc: dingtianh...@huawei.com
Cc: zhaojun...@hisilicon.com
Cc: liguo...@hisilicon.com
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1458203641-17172-3-git-send-email-majun...@huawei.com
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/irq-mbigen.c | 38 --
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4dd3eb8..d67baa2 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -239,8 +239,11 @@ static struct irq_domain_ops mbigen_domain_ops = {
 static int mbigen_device_probe(struct platform_device *pdev)
 {
struct mbigen_device *mgn_chip;
-   struct resource *res;
+   struct platform_device *child;
struct irq_domain *domain;
+   struct device_node *np;
+   struct device *parent;
+   struct resource *res;
u32 num_pins;
 
mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
@@ -254,23 +257,30 @@ static int mbigen_device_probe(struct platform_device 
*pdev)
if (IS_ERR(mgn_chip->base))
return PTR_ERR(mgn_chip->base);
 
-   if (of_property_read_u32(pdev->dev.of_node, "num-pins", _pins) < 0) 
{
-   dev_err(>dev, "No num-pins property\n");
-   return -EINVAL;
-   }
+   for_each_child_of_node(pdev->dev.of_node, np) {
+   if (!of_property_read_bool(np, "interrupt-controller"))
+   continue;
 
-   domain = platform_msi_create_device_domain(>dev, num_pins,
-   mbigen_write_msg,
-   _domain_ops,
-   mgn_chip);
+   parent = platform_bus_type.dev_root;
+   child = of_platform_device_create(np, NULL, parent);
+   if (IS_ERR(child))
+   return PTR_ERR(child);
 
-   if (!domain)
-   return -ENOMEM;
+   if (of_property_read_u32(child->dev.of_node, "num-pins",
+_pins) < 0) {
+   dev_err(>dev, "No num-pins property\n");
+   return -EINVAL;
+   }
+
+   domain = platform_msi_create_device_domain(>dev, 
num_pins,
+  mbigen_write_msg,
+  _domain_ops,
+  mgn_chip);
+   if (!domain)
+   return -ENOMEM;
+   }
 
platform_set_drvdata(pdev, mgn_chip);
-
-   dev_info(>dev, "Allocated %d MSIs\n", num_pins);
-
return 0;
 }
 

[PATCH v3 1/2] irqchip/mbigen:Change the mbigen node definition in dt binding file

[MaJun]

From: Ma Jun <majun...@huawei.com>

For mbigen module, there is a special case that more than one mbigen
device nodes use the same reg definition in DTS when these devices
exist in the same mbigen hardware module.

In current mbigen driver, these mbigen devices definition as below:
mbigen_dev1:intc_dev1 {
...
reg = <0x0 0xc008 0x0 0x1>;
...
};

mbigen_dev2:intc_dev2 {
...
reg = <0x0 0xc008 0x0 0x1>;
...
};

On this case, devm_ioremap_resource() returns fail with info
"can't request region for resource" because of memory region check.

To fix this problem, the mbigen node definition and
structure are changed as Mark Rutland suggested in v1 patch[1].

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/403691.html

Signed-off-by: Ma Jun <majun...@huawei.com>
---
 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   22 +++
 1 files changed, 17 insertions(+), 5 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
index 720f7c9..3b2f4c4 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
@@ -21,6 +21,8 @@ Mbigen main node required properties:
 - reg: Specifies the base physical address and size of the Mbigen
   registers.
 
+Mbigen sub node required properties:
+--
 - interrupt controller: Identifies the node as an interrupt controller
 
 - msi-parent: Specifies the MSI controller this mbigen use.
@@ -45,13 +47,23 @@ Mbigen main node required properties:
 
 Examples:
 
-   mbigen_device_gmac:intc {
+   mbigen_chip_dsa {
compatible = "hisilicon,mbigen-v2";
reg = <0x0 0xc008 0x0 0x1>;
-   interrupt-controller;
-   msi-parent = <_dsa 0x40b1c>;
-   num-pins = <9>;
-   #interrupt-cells = <2>;
+
+   mbigen_gmac:intc_gmac {
+   interrupt-controller;
+   msi-parent = <_dsa 0x40b1c>;
+   num-pins = <9>;
+   #interrupt-cells = <2>;
+   };
+
+   mbigen_i2c:intc_i2c {
+   interrupt-controller;
+   msi-parent = <_dsa 0x40b0e>;
+   num-pins = <2>;
+   #interrupt-cells = <2>;
+   };
};
 
 Devices connect to mbigen required properties:
-- 
1.7.1

[PATCH v3 1/2] irqchip/mbigen:Change the mbigen node definition in dt binding file

[MaJun]

From: Ma Jun 

For mbigen module, there is a special case that more than one mbigen
device nodes use the same reg definition in DTS when these devices
exist in the same mbigen hardware module.

In current mbigen driver, these mbigen devices definition as below:
mbigen_dev1:intc_dev1 {
...
reg = <0x0 0xc008 0x0 0x1>;
...
};

mbigen_dev2:intc_dev2 {
...
reg = <0x0 0xc008 0x0 0x1>;
...
};

On this case, devm_ioremap_resource() returns fail with info
"can't request region for resource" because of memory region check.

To fix this problem, the mbigen node definition and
structure are changed as Mark Rutland suggested in v1 patch[1].

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/403691.html

Signed-off-by: Ma Jun 
---
 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   22 +++
 1 files changed, 17 insertions(+), 5 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
index 720f7c9..3b2f4c4 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
@@ -21,6 +21,8 @@ Mbigen main node required properties:
 - reg: Specifies the base physical address and size of the Mbigen
   registers.
 
+Mbigen sub node required properties:
+--
 - interrupt controller: Identifies the node as an interrupt controller
 
 - msi-parent: Specifies the MSI controller this mbigen use.
@@ -45,13 +47,23 @@ Mbigen main node required properties:
 
 Examples:
 
-   mbigen_device_gmac:intc {
+   mbigen_chip_dsa {
compatible = "hisilicon,mbigen-v2";
reg = <0x0 0xc008 0x0 0x1>;
-   interrupt-controller;
-   msi-parent = <_dsa 0x40b1c>;
-   num-pins = <9>;
-   #interrupt-cells = <2>;
+
+   mbigen_gmac:intc_gmac {
+   interrupt-controller;
+   msi-parent = <_dsa 0x40b1c>;
+   num-pins = <9>;
+   #interrupt-cells = <2>;
+   };
+
+   mbigen_i2c:intc_i2c {
+   interrupt-controller;
+   msi-parent = <_dsa 0x40b0e>;
+   num-pins = <2>;
+   #interrupt-cells = <2>;
+   };
};
 
 Devices connect to mbigen required properties:
-- 
1.7.1

[PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver.

[MaJun]

From: Ma Jun <majun...@huawei.com>

This patch set is used to fix the problem of remap a set of registers
repeatedly in current mbigen driver.

Changes in v3:
--- Change the log to make more detail description about
the IO remap problem.

Changes in v2:
--- Change the mbigen device node definition as Mark suggested.
--- Change the mbigen driver based on the new mbigen dts structure.

Ma Jun (2):
  irqchip/mbigen:Change the mbigen node definition in dt binding file
  irqchip/mbigen:Change the mbigen driver based on the new mbigen node 
definition

 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   22 +++---
 drivers/irqchip/irq-mbigen.c   |   30 ++--
 2 files changed, 38 insertions(+), 14 deletions(-)

[PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver.

[MaJun]

From: Ma Jun 

This patch set is used to fix the problem of remap a set of registers
repeatedly in current mbigen driver.

Changes in v3:
--- Change the log to make more detail description about
the IO remap problem.

Changes in v2:
--- Change the mbigen device node definition as Mark suggested.
--- Change the mbigen driver based on the new mbigen dts structure.

Ma Jun (2):
  irqchip/mbigen:Change the mbigen node definition in dt binding file
  irqchip/mbigen:Change the mbigen driver based on the new mbigen node 
definition

 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   22 +++---
 drivers/irqchip/irq-mbigen.c   |   30 ++--
 2 files changed, 38 insertions(+), 14 deletions(-)

[PATCH v3 2/2] irqchip/mbigen:Change the mbigen driver based on the new mbigen node definition.

[MaJun]

From: Ma Jun <majun...@huawei.com>

In current mbigen driver, each mbigen device is initialized as a platform 
device.
When these devices belong to same mbigen hardware module(chip), they use the
same register definition in their device node and caused the problem of 
registers
remapped repeatedly.

Now, I try to initialize the mbigen module(chip) as a platform device and remap
the register once to fix this problem.

Signed-off-by: Ma Jun <majun...@huawei.com>
---
 drivers/irqchip/irq-mbigen.c |   30 +-
 1 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4dd3eb8..4d413bc 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -242,6 +242,8 @@ static int mbigen_device_probe(struct platform_device *pdev)
struct resource *res;
struct irq_domain *domain;
u32 num_pins;
+   struct platform_device *child_pdev;
+   struct device_node *np;
 
mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
if (!mgn_chip)
@@ -251,25 +253,35 @@ static int mbigen_device_probe(struct platform_device 
*pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
mgn_chip->base = devm_ioremap_resource(>dev, res);
+
if (IS_ERR(mgn_chip->base))
return PTR_ERR(mgn_chip->base);
 
-   if (of_property_read_u32(pdev->dev.of_node, "num-pins", _pins) < 0) 
{
-   dev_err(>dev, "No num-pins property\n");
-   return -EINVAL;
-   }
+   for_each_child_of_node(pdev->dev.of_node, np) {
+   if (!of_property_read_bool(np, "interrupt-controller"))
+   continue;
+
+   child_pdev = of_platform_device_create(np, NULL, 
platform_bus_type.dev_root);
+   if (IS_ERR(child_pdev))
+   return PTR_ERR(child_pdev);
+
+   if (of_property_read_u32(child_pdev->dev.of_node, "num-pins", 
_pins) < 0) {
+   dev_err(>dev, "No num-pins property\n");
+   return -EINVAL;
+   }
 
-   domain = platform_msi_create_device_domain(>dev, num_pins,
+   domain = platform_msi_create_device_domain(_pdev->dev, 
num_pins,
mbigen_write_msg,
_domain_ops,
mgn_chip);
 
-   if (!domain)
-   return -ENOMEM;
+   if (!domain)
+   return -ENOMEM;
 
-   platform_set_drvdata(pdev, mgn_chip);
+   dev_info(_pdev->dev, "Allocated %d MSIs\n", num_pins);
+   }
 
-   dev_info(>dev, "Allocated %d MSIs\n", num_pins);
+   platform_set_drvdata(pdev, mgn_chip);
 
return 0;
 }
-- 
1.7.1

[PATCH v3 2/2] irqchip/mbigen:Change the mbigen driver based on the new mbigen node definition.

[MaJun]

From: Ma Jun 

In current mbigen driver, each mbigen device is initialized as a platform 
device.
When these devices belong to same mbigen hardware module(chip), they use the
same register definition in their device node and caused the problem of 
registers
remapped repeatedly.

Now, I try to initialize the mbigen module(chip) as a platform device and remap
the register once to fix this problem.

Signed-off-by: Ma Jun 
---
 drivers/irqchip/irq-mbigen.c |   30 +-
 1 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4dd3eb8..4d413bc 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -242,6 +242,8 @@ static int mbigen_device_probe(struct platform_device *pdev)
struct resource *res;
struct irq_domain *domain;
u32 num_pins;
+   struct platform_device *child_pdev;
+   struct device_node *np;
 
mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
if (!mgn_chip)
@@ -251,25 +253,35 @@ static int mbigen_device_probe(struct platform_device 
*pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
mgn_chip->base = devm_ioremap_resource(>dev, res);
+
if (IS_ERR(mgn_chip->base))
return PTR_ERR(mgn_chip->base);
 
-   if (of_property_read_u32(pdev->dev.of_node, "num-pins", _pins) < 0) 
{
-   dev_err(>dev, "No num-pins property\n");
-   return -EINVAL;
-   }
+   for_each_child_of_node(pdev->dev.of_node, np) {
+   if (!of_property_read_bool(np, "interrupt-controller"))
+   continue;
+
+   child_pdev = of_platform_device_create(np, NULL, 
platform_bus_type.dev_root);
+   if (IS_ERR(child_pdev))
+   return PTR_ERR(child_pdev);
+
+   if (of_property_read_u32(child_pdev->dev.of_node, "num-pins", 
_pins) < 0) {
+   dev_err(>dev, "No num-pins property\n");
+   return -EINVAL;
+   }
 
-   domain = platform_msi_create_device_domain(>dev, num_pins,
+   domain = platform_msi_create_device_domain(_pdev->dev, 
num_pins,
mbigen_write_msg,
_domain_ops,
mgn_chip);
 
-   if (!domain)
-   return -ENOMEM;
+   if (!domain)
+   return -ENOMEM;
 
-   platform_set_drvdata(pdev, mgn_chip);
+   dev_info(_pdev->dev, "Allocated %d MSIs\n", num_pins);
+   }
 
-   dev_info(>dev, "Allocated %d MSIs\n", num_pins);
+   platform_set_drvdata(pdev, mgn_chip);
 
return 0;
 }
-- 
1.7.1

Re: [PATCH v2 1/2] Irq/mbigen:Change the mbigen node definition in dt binding file

[majun (F)]

Hi Thomas:
Thanks for pointing out the problems.
I'll make detail description about this problem and resend this patch set.


在 2016/3/14 15:49, Thomas Gleixner 写道:
> Majun,
> 
> On Mon, 14 Mar 2016, MaJun wrote:
> 
> First of all the prefix for irq chip drivers is not "Irq/".
> 
> Hint: git log drivers/irqchip 
> 
>> From: Ma Jun <majun...@huawei.com>
>>
>> For mbigen module, there is a special case that more than one mbigen
>> device nodes use the same reg definition in DTS when these devices
>> exist in the same mbigen hardware module.
> 
> There is a special case, so what?
>  

In current driver, the registers would be remapped repeatedly
and caused error when use the function "devm_ioremap_resource".

That's the problem I tried to fix.

>> To fix the mbigen IO remap problem, the mbigen node definition and
> 
> Which problem?
> 
>> structure are changed based on Mark Rutland's suggestion.
> 
> That's really uselss. Nobody has any idea what Mark suggested and in which way
> it fixes that unspecified problem you are talking about.
> 

Actually, I discussed this problem with Mark in v1.
He raised some questions and suggestions
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/403691.html

Thanks!
MaJun

> Thanks,
> 
>   tglx
> 
> .
> 

Re: [PATCH v2 1/2] Irq/mbigen:Change the mbigen node definition in dt binding file

[majun (F)]

Hi Thomas:
Thanks for pointing out the problems.
I'll make detail description about this problem and resend this patch set.


在 2016/3/14 15:49, Thomas Gleixner 写道:
> Majun,
> 
> On Mon, 14 Mar 2016, MaJun wrote:
> 
> First of all the prefix for irq chip drivers is not "Irq/".
> 
> Hint: git log drivers/irqchip 
> 
>> From: Ma Jun 
>>
>> For mbigen module, there is a special case that more than one mbigen
>> device nodes use the same reg definition in DTS when these devices
>> exist in the same mbigen hardware module.
> 
> There is a special case, so what?
>  

In current driver, the registers would be remapped repeatedly
and caused error when use the function "devm_ioremap_resource".

That's the problem I tried to fix.

>> To fix the mbigen IO remap problem, the mbigen node definition and
> 
> Which problem?
> 
>> structure are changed based on Mark Rutland's suggestion.
> 
> That's really uselss. Nobody has any idea what Mark suggested and in which way
> it fixes that unspecified problem you are talking about.
> 

Actually, I discussed this problem with Mark in v1.
He raised some questions and suggestions
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/403691.html

Thanks!
MaJun

> Thanks,
> 
>   tglx
> 
> .
> 

[PATCH v2 2/2] Irq/mbigen:Change the mbigen driver based on the new mbigen node definition.

[MaJun]

From: Ma Jun <majun...@huawei.com>

To fix the IO remap problem, change the mbigen driver based on the
new mbigen node definition.

Signed-off-by: Ma Jun <majun...@huawei.com>
---
 drivers/irqchip/irq-mbigen.c |   30 +-
 1 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4dd3eb8..4d413bc 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -242,6 +242,8 @@ static int mbigen_device_probe(struct platform_device *pdev)
struct resource *res;
struct irq_domain *domain;
u32 num_pins;
+   struct platform_device *child_pdev;
+   struct device_node *np;
 
mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
if (!mgn_chip)
@@ -251,25 +253,35 @@ static int mbigen_device_probe(struct platform_device 
*pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
mgn_chip->base = devm_ioremap_resource(>dev, res);
+
if (IS_ERR(mgn_chip->base))
return PTR_ERR(mgn_chip->base);
 
-   if (of_property_read_u32(pdev->dev.of_node, "num-pins", _pins) < 0) 
{
-   dev_err(>dev, "No num-pins property\n");
-   return -EINVAL;
-   }
+   for_each_child_of_node(pdev->dev.of_node, np) {
+   if (!of_property_read_bool(np, "interrupt-controller"))
+   continue;
+
+   child_pdev = of_platform_device_create(np, NULL, 
platform_bus_type.dev_root);
+   if (IS_ERR(child_pdev))
+   return PTR_ERR(child_pdev);
+
+   if (of_property_read_u32(child_pdev->dev.of_node, "num-pins", 
_pins) < 0) {
+   dev_err(>dev, "No num-pins property\n");
+   return -EINVAL;
+   }
 
-   domain = platform_msi_create_device_domain(>dev, num_pins,
+   domain = platform_msi_create_device_domain(_pdev->dev, 
num_pins,
mbigen_write_msg,
_domain_ops,
mgn_chip);
 
-   if (!domain)
-   return -ENOMEM;
+   if (!domain)
+   return -ENOMEM;
 
-   platform_set_drvdata(pdev, mgn_chip);
+   dev_info(_pdev->dev, "Allocated %d MSIs\n", num_pins);
+   }
 
-   dev_info(>dev, "Allocated %d MSIs\n", num_pins);
+   platform_set_drvdata(pdev, mgn_chip);
 
return 0;
 }
-- 
1.7.1

[PATCH v2 1/2] Irq/mbigen:Change the mbigen node definition in dt binding file

[MaJun]

From: Ma Jun <majun...@huawei.com>

For mbigen module, there is a special case that more than one mbigen
device nodes use the same reg definition in DTS when these devices
exist in the same mbigen hardware module.

To fix the mbigen IO remap problem, the mbigen node definition and
structure are changed based on Mark Rutland's suggestion.

Signed-off-by: Ma Jun <majun...@huawei.com>
---
 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   22 +++
 1 files changed, 17 insertions(+), 5 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
index 720f7c9..3b2f4c4 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
@@ -21,6 +21,8 @@ Mbigen main node required properties:
 - reg: Specifies the base physical address and size of the Mbigen
   registers.
 
+Mbigen sub node required properties:
+--
 - interrupt controller: Identifies the node as an interrupt controller
 
 - msi-parent: Specifies the MSI controller this mbigen use.
@@ -45,13 +47,23 @@ Mbigen main node required properties:
 
 Examples:
 
-   mbigen_device_gmac:intc {
+   mbigen_chip_dsa {
compatible = "hisilicon,mbigen-v2";
reg = <0x0 0xc008 0x0 0x1>;
-   interrupt-controller;
-   msi-parent = <_dsa 0x40b1c>;
-   num-pins = <9>;
-   #interrupt-cells = <2>;
+
+   mbigen_gmac:intc_gmac {
+   interrupt-controller;
+   msi-parent = <_dsa 0x40b1c>;
+   num-pins = <9>;
+   #interrupt-cells = <2>;
+   };
+
+   mbigen_i2c:intc_i2c {
+   interrupt-controller;
+   msi-parent = <_dsa 0x40b0e>;
+   num-pins = <2>;
+   #interrupt-cells = <2>;
+   };
};
 
 Devices connect to mbigen required properties:
-- 
1.7.1

[PATCH v2 1/2] Irq/mbigen:Change the mbigen node definition in dt binding file

[MaJun]

From: Ma Jun 

For mbigen module, there is a special case that more than one mbigen
device nodes use the same reg definition in DTS when these devices
exist in the same mbigen hardware module.

To fix the mbigen IO remap problem, the mbigen node definition and
structure are changed based on Mark Rutland's suggestion.

Signed-off-by: Ma Jun 
---
 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   22 +++
 1 files changed, 17 insertions(+), 5 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
index 720f7c9..3b2f4c4 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
@@ -21,6 +21,8 @@ Mbigen main node required properties:
 - reg: Specifies the base physical address and size of the Mbigen
   registers.
 
+Mbigen sub node required properties:
+--
 - interrupt controller: Identifies the node as an interrupt controller
 
 - msi-parent: Specifies the MSI controller this mbigen use.
@@ -45,13 +47,23 @@ Mbigen main node required properties:
 
 Examples:
 
-   mbigen_device_gmac:intc {
+   mbigen_chip_dsa {
compatible = "hisilicon,mbigen-v2";
reg = <0x0 0xc008 0x0 0x1>;
-   interrupt-controller;
-   msi-parent = <_dsa 0x40b1c>;
-   num-pins = <9>;
-   #interrupt-cells = <2>;
+
+   mbigen_gmac:intc_gmac {
+   interrupt-controller;
+   msi-parent = <_dsa 0x40b1c>;
+   num-pins = <9>;
+   #interrupt-cells = <2>;
+   };
+
+   mbigen_i2c:intc_i2c {
+   interrupt-controller;
+   msi-parent = <_dsa 0x40b0e>;
+   num-pins = <2>;
+   #interrupt-cells = <2>;
+   };
};
 
 Devices connect to mbigen required properties:
-- 
1.7.1

[PATCH v2 2/2] Irq/mbigen:Change the mbigen driver based on the new mbigen node definition.

[MaJun]

From: Ma Jun 

To fix the IO remap problem, change the mbigen driver based on the
new mbigen node definition.

Signed-off-by: Ma Jun 
---
 drivers/irqchip/irq-mbigen.c |   30 +-
 1 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4dd3eb8..4d413bc 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -242,6 +242,8 @@ static int mbigen_device_probe(struct platform_device *pdev)
struct resource *res;
struct irq_domain *domain;
u32 num_pins;
+   struct platform_device *child_pdev;
+   struct device_node *np;
 
mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
if (!mgn_chip)
@@ -251,25 +253,35 @@ static int mbigen_device_probe(struct platform_device 
*pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
mgn_chip->base = devm_ioremap_resource(>dev, res);
+
if (IS_ERR(mgn_chip->base))
return PTR_ERR(mgn_chip->base);
 
-   if (of_property_read_u32(pdev->dev.of_node, "num-pins", _pins) < 0) 
{
-   dev_err(>dev, "No num-pins property\n");
-   return -EINVAL;
-   }
+   for_each_child_of_node(pdev->dev.of_node, np) {
+   if (!of_property_read_bool(np, "interrupt-controller"))
+   continue;
+
+   child_pdev = of_platform_device_create(np, NULL, 
platform_bus_type.dev_root);
+   if (IS_ERR(child_pdev))
+   return PTR_ERR(child_pdev);
+
+   if (of_property_read_u32(child_pdev->dev.of_node, "num-pins", 
_pins) < 0) {
+   dev_err(>dev, "No num-pins property\n");
+   return -EINVAL;
+   }
 
-   domain = platform_msi_create_device_domain(>dev, num_pins,
+   domain = platform_msi_create_device_domain(_pdev->dev, 
num_pins,
mbigen_write_msg,
_domain_ops,
mgn_chip);
 
-   if (!domain)
-   return -ENOMEM;
+   if (!domain)
+   return -ENOMEM;
 
-   platform_set_drvdata(pdev, mgn_chip);
+   dev_info(_pdev->dev, "Allocated %d MSIs\n", num_pins);
+   }
 
-   dev_info(>dev, "Allocated %d MSIs\n", num_pins);
+   platform_set_drvdata(pdev, mgn_chip);
 
return 0;
 }
-- 
1.7.1

[PATCH v2 0/2] Irq/Mbigen: fix the IO remap problem in mbigen driver.

[MaJun]

From: Ma Jun <majun...@huawei.com>

This patch set is used to fix the problem of remap a set of registers
repeatedly.

Changes in v2:
--- Change the mbigen device node definition
--- Change the mbigen driver based on the new mbigen dts structure.

Ma Jun (2):
  Irq/mbigen:Change the mbigen node definition in dt binding file
  Irq/mbigen:Change the mbigen driver based on the new mbigen node definition

 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   22 +++---
 drivers/irqchip/irq-mbigen.c   |   30 ++--
 2 files changed, 38 insertions(+), 14 deletions(-)

[PATCH v2 0/2] Irq/Mbigen: fix the IO remap problem in mbigen driver.

[MaJun]

From: Ma Jun 

This patch set is used to fix the problem of remap a set of registers
repeatedly.

Changes in v2:
--- Change the mbigen device node definition
--- Change the mbigen driver based on the new mbigen dts structure.

Ma Jun (2):
  Irq/mbigen:Change the mbigen node definition in dt binding file
  Irq/mbigen:Change the mbigen driver based on the new mbigen node definition

 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   22 +++---
 drivers/irqchip/irq-mbigen.c   |   30 ++--
 2 files changed, 38 insertions(+), 14 deletions(-)

Re: [PATCH] Change the spin_lock/unlock_irq interface in proc_alloc_inum() function

[majun (F)]

在 2016/3/2 11:09, Al Viro 写道:
> On Wed, Mar 02, 2016 at 10:47:59AM +0800, MaJun wrote:
>> From: Ma Jun <majun...@huawei.com>
>>
>> The spin_lock/unlock_irq interface is not safe when this function is called
>> at some case which need irq disabled.
> 
>> For example:
>>  spin_lock_irqsave()
>>  |
>>  request_irq() --> proc_alloc_inum()
>>  |
>>  spin_unlock_irqrestore()
> 
> Do you even read your own patch?
> 
>>  if (!ida_pre_get(_inum_ida, GFP_KERNEL))
>^^
>This.
> 
> It can block.  You *can't* call that under spin_lock_irqsave().  At all.
> You also can't do request_irq() under a spinlock, no matter whether you
> disable irqs or not - it also blocks.  So does proc_mkdir(), for that
> matter, and not only in proc_alloc_inum().
> 
> NAKed.  Don't do it.  request_irq() is not to be called under spinlocks,
> with or without irqs disabled.
> 

Sorry,I made a wrong example for this problem.
I want to say this interface may change the irq status after this function
be called.

Thanks!
MaJun

> .
> 

Re: [PATCH] Change the spin_lock/unlock_irq interface in proc_alloc_inum() function

[majun (F)]

在 2016/3/2 11:09, Al Viro 写道:
> On Wed, Mar 02, 2016 at 10:47:59AM +0800, MaJun wrote:
>> From: Ma Jun 
>>
>> The spin_lock/unlock_irq interface is not safe when this function is called
>> at some case which need irq disabled.
> 
>> For example:
>>  spin_lock_irqsave()
>>  |
>>  request_irq() --> proc_alloc_inum()
>>  |
>>  spin_unlock_irqrestore()
> 
> Do you even read your own patch?
> 
>>  if (!ida_pre_get(_inum_ida, GFP_KERNEL))
>^^
>This.
> 
> It can block.  You *can't* call that under spin_lock_irqsave().  At all.
> You also can't do request_irq() under a spinlock, no matter whether you
> disable irqs or not - it also blocks.  So does proc_mkdir(), for that
> matter, and not only in proc_alloc_inum().
> 
> NAKed.  Don't do it.  request_irq() is not to be called under spinlocks,
> with or without irqs disabled.
> 

Sorry,I made a wrong example for this problem.
I want to say this interface may change the irq status after this function
be called.

Thanks!
MaJun

> .
> 

[PATCH] Change the spin_lock/unlock_irq interface in proc_alloc_inum() function

[MaJun]

From: Ma Jun <majun...@huawei.com>

The spin_lock/unlock_irq interface is not safe when this function is called
at some case which need irq disabled.

For example:
spin_lock_irqsave()
|
request_irq() --> proc_alloc_inum()
|
spin_unlock_irqrestore()

Reported-by: Fan Jinke <fanjin...@huawei.com>
Signed-off-by: Ma Jun <majun...@huawei.com>
---
 fs/proc/generic.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index ff3ffc7..4fc1502 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -191,23 +191,24 @@ int proc_alloc_inum(unsigned int *inum)
 {
unsigned int i;
int error;
+   unsigned long flags;
 
 retry:
if (!ida_pre_get(_inum_ida, GFP_KERNEL))
return -ENOMEM;
 
-   spin_lock_irq(_inum_lock);
+   spin_lock_irqsave(_inum_lock, flags);
error = ida_get_new(_inum_ida, );
-   spin_unlock_irq(_inum_lock);
+   spin_unlock_irqrestore(_inum_lock, flags);
if (error == -EAGAIN)
goto retry;
else if (error)
return error;
 
if (i > UINT_MAX - PROC_DYNAMIC_FIRST) {
-   spin_lock_irq(_inum_lock);
+   spin_lock_irqsave(_inum_lock, flags);
ida_remove(_inum_ida, i);
-   spin_unlock_irq(_inum_lock);
+   spin_unlock_irqrestore(_inum_lock, flags);
return -ENOSPC;
}
*inum = PROC_DYNAMIC_FIRST + i;
-- 
1.7.1

[PATCH] Change the spin_lock/unlock_irq interface in proc_alloc_inum() function

[MaJun]

From: Ma Jun 

The spin_lock/unlock_irq interface is not safe when this function is called
at some case which need irq disabled.

For example:
spin_lock_irqsave()
|
request_irq() --> proc_alloc_inum()
|
spin_unlock_irqrestore()

Reported-by: Fan Jinke 
Signed-off-by: Ma Jun 
---
 fs/proc/generic.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index ff3ffc7..4fc1502 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -191,23 +191,24 @@ int proc_alloc_inum(unsigned int *inum)
 {
unsigned int i;
int error;
+   unsigned long flags;
 
 retry:
if (!ida_pre_get(_inum_ida, GFP_KERNEL))
return -ENOMEM;
 
-   spin_lock_irq(_inum_lock);
+   spin_lock_irqsave(_inum_lock, flags);
error = ida_get_new(_inum_ida, );
-   spin_unlock_irq(_inum_lock);
+   spin_unlock_irqrestore(_inum_lock, flags);
if (error == -EAGAIN)
goto retry;
else if (error)
return error;
 
if (i > UINT_MAX - PROC_DYNAMIC_FIRST) {
-   spin_lock_irq(_inum_lock);
+   spin_lock_irqsave(_inum_lock, flags);
ida_remove(_inum_ida, i);
-   spin_unlock_irq(_inum_lock);
+   spin_unlock_irqrestore(_inum_lock, flags);
return -ENOSPC;
}
*inum = PROC_DYNAMIC_FIRST + i;
-- 
1.7.1

[PATCH] Irq/mbigen:Promote the mbigen driver register timing

[MaJun]

From: Ma Jun <majun...@huawei.com>

Using module_platform_driver() to register mbigen driver is
too late for some driver to apply irq, because the mbigen irq
domain is not created yet. 

Signed-off-by: Ma Jun <majun...@huawei.com>
---
 drivers/irqchip/irq-mbigen.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4dd3eb8..4df359c 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -289,7 +289,14 @@ static struct platform_driver mbigen_platform_driver = {
.probe  = mbigen_device_probe,
 };
 
-module_platform_driver(mbigen_platform_driver);
+static __init int mbigen_init(void)
+
+{
+   return platform_driver_register(_platform_driver);
+
+}
+
+arch_initcall(mbigen_init);
 
 MODULE_AUTHOR("Jun Ma <majun...@huawei.com>");
 MODULE_AUTHOR("Yun Wu <wuyun...@huawei.com>");
-- 
1.7.1

[PATCH] Irq/mbigen:Promote the mbigen driver register timing

[MaJun]

From: Ma Jun 

Using module_platform_driver() to register mbigen driver is
too late for some driver to apply irq, because the mbigen irq
domain is not created yet. 

Signed-off-by: Ma Jun 
---
 drivers/irqchip/irq-mbigen.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4dd3eb8..4df359c 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -289,7 +289,14 @@ static struct platform_driver mbigen_platform_driver = {
.probe  = mbigen_device_probe,
 };
 
-module_platform_driver(mbigen_platform_driver);
+static __init int mbigen_init(void)
+
+{
+   return platform_driver_register(_platform_driver);
+
+}
+
+arch_initcall(mbigen_init);
 
 MODULE_AUTHOR("Jun Ma ");
 MODULE_AUTHOR("Yun Wu ");
-- 
1.7.1

Re: [PATCH v2 4/5] irqchip:create irq domain for each mbigen device

[majun (F)]

在 2016/2/16 16:50, Marc Zyngier 写道:
> On Tue, 16 Feb 2016 14:37:27 +0800
> MaJun <majun...@huawei.com> wrote:
> 
>> From: Ma Jun <majun...@huawei.com>
[...]
>> +unsigned int nid;
>> +
>> +nid = get_mbigen_nid(hwirq);
>> +
>> +if (nid < 4)
>> +return (nid * 4) + REG_MBIGEN_VEC_OFFSET;
>> +else
>> +return (nid - 4) * 4 + REG_MBIGEN_EXT_VEC_OFFSET;
>> +}
>> +
>> +static struct irq_chip mbigen_irq_chip = {
>> +.name = "mbigen-v1",
>> +};
>> +
>> +static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
>> +{
>> +/* The address of doorbell is encoded in mbigen register by default
>> + * So,we don't need to program the doorbell address at here
>> + * Besides, the event ID is decided by the hardware pin number,
>> + * we can't change it in software.So, we don't need to encode the
>> + * event ID in mbigen register.
>> + */
> 
> Really? What if tomorrow I decide to change the EventID allocation
> policy in the ITS driver? Have your HW engineers really baked the
> behaviour of the Linux driver into the device?
> 

Yes.
If we really need to support this chip,is there
any possible solution for this problem?

Thanks!
MaJun

> I'm puzzled.
> 
>   M.
> 

Re: [PATCH v2 4/5] irqchip:create irq domain for each mbigen device

[majun (F)]

在 2016/2/16 16:50, Marc Zyngier 写道:
> On Tue, 16 Feb 2016 14:37:27 +0800
> MaJun  wrote:
> 
>> From: Ma Jun 
[...]
>> +unsigned int nid;
>> +
>> +nid = get_mbigen_nid(hwirq);
>> +
>> +if (nid < 4)
>> +return (nid * 4) + REG_MBIGEN_VEC_OFFSET;
>> +else
>> +return (nid - 4) * 4 + REG_MBIGEN_EXT_VEC_OFFSET;
>> +}
>> +
>> +static struct irq_chip mbigen_irq_chip = {
>> +.name = "mbigen-v1",
>> +};
>> +
>> +static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
>> +{
>> +/* The address of doorbell is encoded in mbigen register by default
>> + * So,we don't need to program the doorbell address at here
>> + * Besides, the event ID is decided by the hardware pin number,
>> + * we can't change it in software.So, we don't need to encode the
>> + * event ID in mbigen register.
>> + */
> 
> Really? What if tomorrow I decide to change the EventID allocation
> policy in the ITS driver? Have your HW engineers really baked the
> behaviour of the Linux driver into the device?
> 

Yes.
If we really need to support this chip,is there
any possible solution for this problem?

Thanks!
MaJun

> I'm puzzled.
> 
>   M.
> 

[PATCH v2 3/5] irqchip: add platform device driver for mbigen device

[MaJun]

From: Ma Jun <majun...@huawei.com>

Add the platform device driver for mbigen chip v1.
This patch just same as mbigen v2.

Signed-off-by: Ma Jun <majun...@huawei.com>
---
 drivers/irqchip/Makefile|2 +-
 drivers/irqchip/irq-mbigen-v1.c |   76 +++
 2 files changed, 77 insertions(+), 1 deletions(-)
 create mode 100644 drivers/irqchip/irq-mbigen-v1.c

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index d91d99d..d4b9c7f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -25,7 +25,7 @@ obj-$(CONFIG_REALVIEW_DT) += irq-gic-realview.o
 obj-$(CONFIG_ARM_GIC_V2M)  += irq-gic-v2m.o
 obj-$(CONFIG_ARM_GIC_V3)   += irq-gic-v3.o irq-gic-common.o
 obj-$(CONFIG_ARM_GIC_V3_ITS)   += irq-gic-v3-its.o 
irq-gic-v3-its-pci-msi.o irq-gic-v3-its-platform-msi.o
-obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o
+obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o irq-mbigen-v1.o
 obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
 obj-$(CONFIG_ARM_VIC)  += irq-vic.o
 obj-$(CONFIG_ATMEL_AIC_IRQ)+= irq-atmel-aic-common.o 
irq-atmel-aic.o
diff --git a/drivers/irqchip/irq-mbigen-v1.c b/drivers/irqchip/irq-mbigen-v1.c
new file mode 100644
index 000..9445658
--- /dev/null
+++ b/drivers/irqchip/irq-mbigen-v1.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright (C) 2015 Hisilicon Limited, All Rights Reserved.
+ * Author: Jun Ma <majun...@huawei.com>
+ * Author: Yun Wu <wuyun...@huawei.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct mbigen_device - holds the information of mbigen device.
+ *
+ * @pdev:  pointer to the platform device structure of mbigen chip.
+ * @base:  mapped address of this mbigen chip.
+ */
+struct mbigen_device {
+   struct platform_device  *pdev;
+   void __iomem*base;
+};
+
+static int mbigen_device_probe(struct platform_device *pdev)
+{
+   struct mbigen_device *mgn_chip;
+   struct resource *res;
+
+   mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
+   if (!mgn_chip)
+   return -ENOMEM;
+
+   mgn_chip->pdev = pdev;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   mgn_chip->base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(mgn_chip->base))
+   return PTR_ERR(mgn_chip->base);
+
+   platform_set_drvdata(pdev, mgn_chip);
+
+   return 0;
+}
+
+static const struct of_device_id mbigen_of_match[] = {
+   { .compatible = "hisilicon,mbigen-v1" },
+   { /* END */ }
+};
+MODULE_DEVICE_TABLE(of, mbigen_of_match);
+
+static struct platform_driver mbigen_platform_driver = {
+   .driver = {
+   .name   = "Hisilicon MBIGEN-V1",
+   .owner  = THIS_MODULE,
+   .of_match_table = mbigen_of_match,
+   },
+   .probe  = mbigen_device_probe,
+};
+
+module_platform_driver(mbigen_platform_driver);
+
+MODULE_AUTHOR("Jun Ma <majun...@huawei.com>");
+MODULE_AUTHOR("Yun Wu <wuyun...@huawei.com>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Hisilicon MBI Generator driver");
-- 
1.7.1

[PATCH v2 3/5] irqchip: add platform device driver for mbigen device

[MaJun]

From: Ma Jun 

Add the platform device driver for mbigen chip v1.
This patch just same as mbigen v2.

Signed-off-by: Ma Jun 
---
 drivers/irqchip/Makefile|2 +-
 drivers/irqchip/irq-mbigen-v1.c |   76 +++
 2 files changed, 77 insertions(+), 1 deletions(-)
 create mode 100644 drivers/irqchip/irq-mbigen-v1.c

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index d91d99d..d4b9c7f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -25,7 +25,7 @@ obj-$(CONFIG_REALVIEW_DT) += irq-gic-realview.o
 obj-$(CONFIG_ARM_GIC_V2M)  += irq-gic-v2m.o
 obj-$(CONFIG_ARM_GIC_V3)   += irq-gic-v3.o irq-gic-common.o
 obj-$(CONFIG_ARM_GIC_V3_ITS)   += irq-gic-v3-its.o 
irq-gic-v3-its-pci-msi.o irq-gic-v3-its-platform-msi.o
-obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o
+obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o irq-mbigen-v1.o
 obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
 obj-$(CONFIG_ARM_VIC)  += irq-vic.o
 obj-$(CONFIG_ATMEL_AIC_IRQ)+= irq-atmel-aic-common.o 
irq-atmel-aic.o
diff --git a/drivers/irqchip/irq-mbigen-v1.c b/drivers/irqchip/irq-mbigen-v1.c
new file mode 100644
index 000..9445658
--- /dev/null
+++ b/drivers/irqchip/irq-mbigen-v1.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright (C) 2015 Hisilicon Limited, All Rights Reserved.
+ * Author: Jun Ma 
+ * Author: Yun Wu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct mbigen_device - holds the information of mbigen device.
+ *
+ * @pdev:  pointer to the platform device structure of mbigen chip.
+ * @base:  mapped address of this mbigen chip.
+ */
+struct mbigen_device {
+   struct platform_device  *pdev;
+   void __iomem*base;
+};
+
+static int mbigen_device_probe(struct platform_device *pdev)
+{
+   struct mbigen_device *mgn_chip;
+   struct resource *res;
+
+   mgn_chip = devm_kzalloc(>dev, sizeof(*mgn_chip), GFP_KERNEL);
+   if (!mgn_chip)
+   return -ENOMEM;
+
+   mgn_chip->pdev = pdev;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   mgn_chip->base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(mgn_chip->base))
+   return PTR_ERR(mgn_chip->base);
+
+   platform_set_drvdata(pdev, mgn_chip);
+
+   return 0;
+}
+
+static const struct of_device_id mbigen_of_match[] = {
+   { .compatible = "hisilicon,mbigen-v1" },
+   { /* END */ }
+};
+MODULE_DEVICE_TABLE(of, mbigen_of_match);
+
+static struct platform_driver mbigen_platform_driver = {
+   .driver = {
+   .name   = "Hisilicon MBIGEN-V1",
+   .owner  = THIS_MODULE,
+   .of_match_table = mbigen_of_match,
+   },
+   .probe  = mbigen_device_probe,
+};
+
+module_platform_driver(mbigen_platform_driver);
+
+MODULE_AUTHOR("Jun Ma ");
+MODULE_AUTHOR("Yun Wu ");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Hisilicon MBI Generator driver");
-- 
1.7.1