* [GIT PULL 2/2] arm64 dts: exynos: Last round for v4.12
From: Krzysztof Kozlowski @ 2017-04-27 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1HA6cio=hboc7=BYwJn-i6RzCP1uzcCVvcQwt4wtB3Tw@mail.gmail.com>
On Thu, Apr 27, 2017 at 09:46:03PM +0200, Arnd Bergmann wrote:
> On Fri, Apr 21, 2017 at 6:40 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > The following changes since commit e3c07546747cdec07ff15c984bc6cebc9c9f788c:
> >
> > arm64: dts: exynos: Add the burst and esc clock frequency properties to DSI node (2017-03-08 08:55:39 +0200)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.12-2
> >
> > for you to fetch changes up to 5dccc9873c4af60f4478b3ef54267353f25cc301:
> >
> > arm64: dts: exynos: Use - instead of @ for DT OPP entries (2017-04-20 18:10:05 +0200)
> >
> > ----------------------------------------------------------------
> > Second update of Samsung DeviceTree ARM64 for v4.12:
> > - Fix DTC warnings in Exynos ARM64 Device Tree sources.
> > - Add panel node to TM2E board.
> >
> > ----------------------------------------------------------------
> > Hoegeun Kwon (1):
> > arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board
> >
> > Viresh Kumar (1):
> > arm64: dts: exynos: Use - instead of @ for DT OPP entries
> >
> > arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++++++-------------
> > arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 ++++++
> > arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 +++++++++++++-------------
> > 3 files changed, 60 insertions(+), 49 deletions(-)
>
> I pulled the updated version into next/dt64, thanks,
Thanks! Do not forget also about next/dt (this wasn't updated so just
tags/samsung-dt-4.12-2).
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] of_coresight: Use devm_kcalloc() in of_coresight_alloc_memory()
From: SF Markus Elfring @ 2017-04-27 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52619d05-65c4-149d-f355-cf9c037a0c9b@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 27 Apr 2017 21:29:12 +0200
Multiplications for the size determination of memory allocations
indicated that array data structures should be processed.
Thus use the corresponding function "devm_kcalloc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/hwtracing/coresight/of_coresight.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
index 09142e99e915..1e622912cd0f 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -78,21 +78,21 @@ static int of_coresight_alloc_memory(struct device *dev,
struct coresight_platform_data *pdata)
{
/* List of output port on this component */
- pdata->outports = devm_kzalloc(dev, pdata->nr_outport *
+ pdata->outports = devm_kcalloc(dev, pdata->nr_outport,
sizeof(*pdata->outports),
GFP_KERNEL);
if (!pdata->outports)
return -ENOMEM;
/* Children connected to this component via @outports */
- pdata->child_names = devm_kzalloc(dev, pdata->nr_outport *
+ pdata->child_names = devm_kcalloc(dev, pdata->nr_outport,
sizeof(*pdata->child_names),
GFP_KERNEL);
if (!pdata->child_names)
return -ENOMEM;
/* Port number on the child this component is connected to */
- pdata->child_ports = devm_kzalloc(dev, pdata->nr_outport *
+ pdata->child_ports = devm_kcalloc(dev, pdata->nr_outport,
sizeof(*pdata->child_ports),
GFP_KERNEL);
if (!pdata->child_ports)
--
2.12.2
^ permalink raw reply related
* [PATCH 1/2] coresight-stm: Use devm_kcalloc() in stm_probe()
From: SF Markus Elfring @ 2017-04-27 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52619d05-65c4-149d-f355-cf9c037a0c9b@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 27 Apr 2017 21:18:57 +0200
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "devm_kcalloc".
This issue was detected by using the Coccinelle software.
* Delete the local variable "bitmap_size" which became unnecessary
with this refactoring.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/hwtracing/coresight/coresight-stm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
index 93fc26f01bab..bbb5275bf0d2 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -799,7 +799,7 @@ static int stm_probe(struct amba_device *adev, const struct amba_id *id)
struct stm_drvdata *drvdata;
struct resource *res = &adev->res;
struct resource ch_res;
- size_t res_size, bitmap_size;
+ size_t res_size;
struct coresight_desc desc = { 0 };
struct device_node *np = adev->dev.of_node;
@@ -848,9 +848,9 @@ static int stm_probe(struct amba_device *adev, const struct amba_id *id)
res_size = min((resource_size_t)(drvdata->numsp *
BYTES_PER_CHANNEL), resource_size(res));
}
- bitmap_size = BITS_TO_LONGS(drvdata->numsp) * sizeof(long);
- guaranteed = devm_kzalloc(dev, bitmap_size, GFP_KERNEL);
+ guaranteed = devm_kcalloc(dev, BITS_TO_LONGS(drvdata->numsp),
+ sizeof(long), GFP_KERNEL);
if (!guaranteed)
return -ENOMEM;
drvdata->chs.guaranteed = guaranteed;
--
2.12.2
^ permalink raw reply related
* [GIT PULL 2/2] arm64 dts: exynos: Last round for v4.12
From: Arnd Bergmann @ 2017-04-27 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421164050.7404-2-krzk@kernel.org>
On Fri, Apr 21, 2017 at 6:40 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> The following changes since commit e3c07546747cdec07ff15c984bc6cebc9c9f788c:
>
> arm64: dts: exynos: Add the burst and esc clock frequency properties to DSI node (2017-03-08 08:55:39 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.12-2
>
> for you to fetch changes up to 5dccc9873c4af60f4478b3ef54267353f25cc301:
>
> arm64: dts: exynos: Use - instead of @ for DT OPP entries (2017-04-20 18:10:05 +0200)
>
> ----------------------------------------------------------------
> Second update of Samsung DeviceTree ARM64 for v4.12:
> - Fix DTC warnings in Exynos ARM64 Device Tree sources.
> - Add panel node to TM2E board.
>
> ----------------------------------------------------------------
> Hoegeun Kwon (1):
> arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board
>
> Viresh Kumar (1):
> arm64: dts: exynos: Use - instead of @ for DT OPP entries
>
> arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++++++-------------
> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 ++++++
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 +++++++++++++-------------
> 3 files changed, 60 insertions(+), 49 deletions(-)
I pulled the updated version into next/dt64, thanks,
Arnd
^ permalink raw reply
* [PATCH 0/2] hwtracing-coresight: Fine-tuning for two function implementations
From: SF Markus Elfring @ 2017-04-27 19:45 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 27 Apr 2017 21:34:32 +0200
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Use devm_kcalloc() in stm_probe()
Use devm_kcalloc() in of_coresight_alloc_memory()
drivers/hwtracing/coresight/coresight-stm.c | 6 +++---
drivers/hwtracing/coresight/of_coresight.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
--
2.12.2
^ permalink raw reply
* [GIT PULL] arm64: dts: juno: fixes for v4.12
From: Arnd Bergmann @ 2017-04-27 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <42ac5309-62aa-1c5e-3cbb-cb40d68e8b9b@arm.com>
On Thu, Apr 20, 2017 at 6:30 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Hi ARM SoC team,
>
> Sorry for the late pull request, but this contains only fixes
> that were found when I tested linux-next.
>
> Please pull!
Pulled into next/dt64, thanks,
Arnd
^ permalink raw reply
* [GIT PULL] ARM: dts: vexpress: fix for v4.12
From: Arnd Bergmann @ 2017-04-27 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3457b9e7-f720-b142-fa82-2855b2c2e2b1@arm.com>
On Thu, Apr 20, 2017 at 6:30 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Hi ARM SoC team,
>
> Sorry for the late pull request, but this just contain fix to remove DT
> build warnings that are showing up in linux-next
>
> Please pull!
Pulled into next/dt, thanks,
Arnd
^ permalink raw reply
* [PATCH] [stable v3.18.y] ARM: 8383/1: nommu: avoid deprecated source register on mov
From: Arnd Bergmann @ 2017-04-27 19:32 UTC (permalink / raw)
To: linux-arm-kernel
From: Stefan Agner <stefan@agner.ch>
Commit 970d96f9a81b0dd83ddd8bce0e5e1ba31881c5f5 upstream.
In Thumb2 mode, the stack register r13 is deprecated if the
destination register is the program counter (r15). Similar to
head.S, head-nommu.S uses r13 to store the return address used
after configuring the CPU's CP15 register. However, since we do
not enable a MMU, there will be no address switch and it is
possible to use branch with link instruction to call
__after_proc_init.
Avoid using r13 completely by using bl to call __after_proc_init
and get rid of __secondary_switched.
Beside removing unnecessary complexity, this also fixes a
compiler warning when compiling a !MMU kernel:
Warning: Use of r13 as a source register is deprecated when r15
is the destination register.
Tested-?by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
----
I've backported this build fix to 3.18.y as the original
patch did not apply cleanly. I rebased it one patch at a time,
and each step was fairly straightforward, but I did not test
it on hardware, so it would still be nice to have someone else
look over the patch to see if I did something wrong.
---
arch/arm/kernel/head-nommu.S | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index cc176b67c134..c6c66dd4be89 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -77,13 +77,12 @@ ENTRY(stext)
orr r6, r6, #(1 << MPU_RSR_EN) @ Set region enabled bit
bl __setup_mpu
#endif
- ldr r13, =__mmap_switched @ address to jump to after
- @ initialising sctlr
adr lr, BSYM(1f) @ return (PIC) address
ARM( add pc, r10, #PROCINFO_INITFUNC )
THUMB( add r12, r10, #PROCINFO_INITFUNC )
THUMB( ret r12 )
- 1: b __after_proc_init
+1: bl __after_proc_init
+ b __mmap_switched
ENDPROC(stext)
#ifdef CONFIG_SMP
@@ -106,8 +105,7 @@ ENTRY(secondary_startup)
movs r10, r5 @ invalid processor?
beq __error_p @ yes, error 'p'
- adr r4, __secondary_data
- ldmia r4, {r7, r12}
+ ldr r7, __secondary_data
#ifdef CONFIG_ARM_MPU
/* Use MPU region info supplied by __cpu_up */
@@ -115,23 +113,19 @@ ENTRY(secondary_startup)
bl __setup_mpu @ Initialize the MPU
#endif
- adr lr, BSYM(__after_proc_init) @ return address
- mov r13, r12 @ __secondary_switched address
+ adr lr, BSYM(1f) @ return (PIC) address
ARM( add pc, r10, #PROCINFO_INITFUNC )
THUMB( add r12, r10, #PROCINFO_INITFUNC )
THUMB( ret r12 )
-ENDPROC(secondary_startup)
-
-ENTRY(__secondary_switched)
+1: bl __after_proc_init
ldr sp, [r7, #8] @ set up the stack pointer
mov fp, #0
b secondary_start_kernel
-ENDPROC(__secondary_switched)
+ENDPROC(secondary_startup)
.type __secondary_data, %object
__secondary_data:
.long secondary_data
- .long __secondary_switched
#endif /* CONFIG_SMP */
/*
@@ -164,7 +158,7 @@ __after_proc_init:
#endif
mcr p15, 0, r0, c1, c0, 0 @ write control reg
#endif /* CONFIG_CPU_CP15 */
- ret r13
+ ret lr
ENDPROC(__after_proc_init)
.ltorg
--
2.9.0
^ permalink raw reply related
* [PATCH v5 01/22] KVM: arm/arm64: Add ITS save/restore API documentation
From: Auger Eric @ 2017-04-27 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170427175453.GA56889@lvm>
On 27/04/2017 19:54, Christoffer Dall wrote:
> On Thu, Apr 27, 2017 at 07:27:22PM +0200, Auger Eric wrote:
>> Hi Christoffer,
>>
>> On 27/04/2017 18:38, Christoffer Dall wrote:
>>> On Thu, Apr 27, 2017 at 05:29:35PM +0200, Auger Eric wrote:
>>>>
>>>>
>>>> On 27/04/2017 16:45, Christoffer Dall wrote:
>>>>> Hi Eric,
>>>>>
>>>>> On Thu, Apr 27, 2017 at 02:51:00PM +0200, Auger Eric wrote:
>>>>>> On 27/04/2017 13:02, Christoffer Dall wrote:
>>>>>>> On Thu, Apr 27, 2017 at 11:33:39AM +0200, Auger Eric wrote:
>>>>>>>> On 27/04/2017 10:57, Christoffer Dall wrote:
>>>>>>>>> On Wed, Apr 26, 2017 at 05:48:32PM +0200, Auger Eric wrote:
>>>>>>>>>> On 26/04/2017 14:31, Christoffer Dall wrote:
>>>>>>>>>>> On Fri, Apr 14, 2017 at 12:15:13PM +0200, Eric Auger wrote:
>>>>>>>>>>>> Add description for how to access ITS registers and how to save/restore
>>>>>>>>>>>> ITS tables into/from memory.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>> v4 -> v5:
>>>>>>>>>>>> - take into account Christoffer's comments
>>>>>>>>>>>> - pending table save on GICV3 side now
>>>>>>>>>>>>
>>>>>>>>>>>> v3 -> v4:
>>>>>>>>>>>> - take into account Peter's comments:
>>>>>>>>>>>> - typos
>>>>>>>>>>>> - KVM_DEV_ARM_VGIC_GRP_ITS_TABLES kvm_device_attr = 0
>>>>>>>>>>>> - add a validity bit in DTE
>>>>>>>>>>>> - document all fields in CTE and ITE
>>>>>>>>>>>> - document ABI revision
>>>>>>>>>>>> - take into account Andre's comments:
>>>>>>>>>>>> - document restrictions about GITS_CREADR writing and GITS_IIDR
>>>>>>>>>>>> - document -EBUSY error if one or more VCPUS are runnning
>>>>>>>>>>>> - document 64b registers only can be accessed with 64b access
>>>>>>>>>>>> - itt_addr field matches bits [51:8] of the itt_addr
>>>>>>>>>>>>
>>>>>>>>>>>> v1 -> v2:
>>>>>>>>>>>> - DTE and ITE now are 8 bytes
>>>>>>>>>>>> - DTE and ITE now indexed by deviceid/eventid
>>>>>>>>>>>> - use ITE name instead of ITTE
>>>>>>>>>>>> - mentions ITT_addr matches bits [51:8] of the actual address
>>>>>>>>>>>> - mentions LE layout
>>>>>>>>>>>> ---
>>>>>>>>>>>> Documentation/virtual/kvm/devices/arm-vgic-its.txt | 99 ++++++++++++++++++++++
>>>>>>>>>>>> 1 file changed, 99 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/Documentation/virtual/kvm/devices/arm-vgic-its.txt b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
>>>>>>>>>>>> index 6081a5b..b5f010d 100644
>>>>>>>>>>>> --- a/Documentation/virtual/kvm/devices/arm-vgic-its.txt
>>>>>>>>>>>> +++ b/Documentation/virtual/kvm/devices/arm-vgic-its.txt
>>>>>>>>>>>> @@ -32,7 +32,106 @@ Groups:
>>>>>>>>>>>> KVM_DEV_ARM_VGIC_CTRL_INIT
>>>>>>>>>>>> request the initialization of the ITS, no additional parameter in
>>>>>>>>>>>> kvm_device_attr.addr.
>>>>>>>>>>>> +
>>>>>>>>>>>> + KVM_DEV_ARM_ITS_SAVE_TABLES
>>>>>>>>>>>> + save the ITS table data into guest RAM, at the location provisioned
>>>>>>>>>>>> + by the guest in corresponding registers/table entries.
>>>>>>>>>>>> +
>>>>>>>>>>>> + The layout of the tables in guest memory defines an ABI. The entries
>>>>>>>>>>>> + are laid out in little endian format as described in the last paragraph.
>>>>>>>>>>>> +
>>>>>>>>>>>> + KVM_DEV_ARM_ITS_RESTORE_TABLES
>>>>>>>>>>>> + restore the ITS tables from guest RAM to ITS internal structures.
>>>>>>>>>>>> +
>>>>>>>>>>>> + The GICV3 must be restored before the ITS and all ITS registers but
>>>>>>>>>>>> + the GITS_CTLR must be restored before restoring the ITS tables.
>>>>>>>>>>>> +
>>>>>>>>>>>> + The GITS_IIDR read-only register must also be restored before
>>>>>>>>>>>> + the table restore as the IIDR revision field encodes the ABI revision.
>>>>>>>>>>>> +
>>>>>>>>>>>
>>>>>>>>>>> what is the expected sequence of operations. For example, to restore
>>>>>>>>>>> the ITS, do I call KVM_DEV_ARM_VGIC_CTRL_INIT first, then restore all
>>>>>>>>>>> the memory and registers, and finally call KVM_DEV_ARM_ITS_RESTORE_TABLES?
>>>>>>>>>> Yes KVM_DEV_ARM_VGIC_CTRL_INIT comes first, then restore all registers
>>>>>>>>>> except GITS_CTLR, then table restore, then GITS_CTLR
>>>>>>>>>>>
>>>>>>>>>>> Is there any interaction between when you call KVM_DEV_ARM_ITS_RESTORE_TABLES
>>>>>>>>>>> and restore GITS_CTLR (which enables the ITS)?
>>>>>>>>>>
>>>>>>>>>> Yep, when GITS_CTLR is set, LPIs may be enabled and this on that event
>>>>>>>>>> that the pending table is read. But the whole pending table is not read
>>>>>>>>>> as we only iterate on registered LPIs. So the ITT must have been
>>>>>>>>>> restored previously.
>>>>>>>>>>
>>>>>>>>>> I became aware that the pending table sync is done twice, once in the
>>>>>>>>>> pending table restore, and once in the GITS_CTLR restore. So if we
>>>>>>>>>> leave this order specification, I should be able to remove the sync on
>>>>>>>>>> table restore. This was the original reason why GITS_CTLR restore has
>>>>>>>>>> been done at the very end.
>>>>>>>>>
>>>>>>>>> I'm sorry, I'm a bit confused. Do we not need
>>>>>>>>> KVM_DEV_ARM_ITS_RESTORE_TABLES at all then?
>>>>>>>>
>>>>>>>> Yes you do. I was talking about the RDIST pending table sync. The save
>>>>>>>> is explicit using GICV3 device KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES.
>>>>>>>> However the sync is implicit on GITS_CTLR restore if LPIs are enabled.
>>>>>>>> and today I do it also on ITS device KVM_DEV_ARM_ITS_RESTORE_TABLES
>>>>>>>> which is not requested I think since GITS_CTLR restore does it already.
>>>>>>>
>>>>>>> Shouldn't restoring the pending tables happen when restoring some
>>>>>>> redeistributor state and not anything related to the ITS?
>>>>>>
>>>>>> Marc wrote:
>>>>>> "
>>>>>> I don't think you necessarily need a coarse map. When restoring the ITS
>>>>>> tables, you can always read the pending bit when creating the LPI
>>>>>> structure (it has been written to RAM at save time). Note that we
>>>>>> already do something like this in vgic_enable_lpis().
>>>>>> "
>>>>>>
>>>>>> This is currently what is implemented I think. the pending tables are
>>>>>> currently sync'ed on GITS_CTLR set (if LPI are enabled) + erroneously
>>>>>> also on on ITS table restore
>>>>>>
>>>>>> The problematic is: Either you know in advance which LPI INTIDare used
>>>>>> or you need to parse the whole pending table (possibly using the 1st kB
>>>>>> as coarse mapping).
>>>>>>
>>>>>> If you don't know the LPI INTIDs in advance it is only possible to
>>>>>> restore the pending bit of pending LPIs. At that time you would
>>>>>> re-allocate those pending LPI (vgic_add_lpi) and when you restore the
>>>>>> ITS ITT you would do the same for those which were not pending. Looks
>>>>>> really heavy to me: coarse mapping + dual vgic_add_lpi path.
>>>>>>
>>>>>> Otherwise we would need to add another dependency between RDIST pending
>>>>>> table restore and ITS table restore but this looks even more weird, no?
>>>>>>
>>>>>>
>>>>> So I just sat down with Andre and Marc and we tried to work through this
>>>>> and came up with the best scheme. I apologize in advance for the
>>>>> one-way nature of this e-mail, and I am of course open to discussing the
>>>>> following proposal again if you do not agree.
>>>>>
>>>>> What I think this document should say, is that the following ordering
>>>>> must be followed when restoring the GIC and the ITS:
>>>>>
>>>>> First, restore all guest memory
>>>>>
>>>>> Second, restore ALL redistributors
>>>>>
>>>>> Third, restore the ITS, in the following order:
>>>>> 1. Initialize the ITS (KVM_DEV_ARM_VGIC_CTRL_INIT)
>>>>> 2. Restore GITS_CBASER
>>>>> 3. Restore all other GITS_ registers, except GITS_CTLR!
>>>>> 4. Load the ITS table data (KVM_DEV_ARM_ITS_RESTORE_TABLES)
>>>>> 5. Restore GITS_CTLR
>>>>>
>>>>> The rationale is that we really want the redistributor and the ITS
>>>>> restore to be independent and follow the architecture. This means that
>>>>> our ABI for the redistributor should still work without restoring an ITS
>>>>> (if we ever decide to support LPIs for KVM without the ITS).
>>>>
>>>> OK. Note I already mentioned that GICv3 must be restored before the ITS.
>>>> To me this comprised the RDIST.
>>>
>>> Possibly, but I think it's good to write out the whole thing so we
>>> clearly understand the flow. That could better be achieved by
>>> correcting my proposed text above to say something like "Second, restore
>>> ALL redistributors to ensure the pending and configuration tables can be
>>> read."
>>>
>>>>
>>>> I understand the above description of the ordering comes in addition to
>>>> the existing text, right?
>>>
>>> Yes
>>>
>>>> in other words I keep the GITS_READR,
>>>> GITS_IIDR specific text as well as KVM_DEV_ARM_ITS_SAVE/RESTORE_TABLES
>>>> section.
>>>>
>>>
>>> Yes. But you don't need to do any reading of the pending table on any
>>> of the restore operations.
>> well you told me to do it on vgic_add_lpi(). This is obviously called on
>> ITS table restore. /me confused.
>
> Sorry, I meant you do not need to scan the entire table independently
> from restoring other state that requires building the data structures.
>
>> Obviously this is implicit and should
>> not be documented. Is that what you meant? btw this is not documented
>> atm I think.
>
> What I care about is that the ABI is clear and represents what the
> architecture does. So in terms of documentation in the ABI, we don't
> need to mention anything about when this is done, but we also do not
> need to specify any interaction between the pending tables and the ITS,
> beyond that the redestributors and memory must be restored before the
> ITS.
>
> Hope this clarifies.
yes it does
Thanks
Eric
>
> Thanks,
> -Christoffer
>
^ permalink raw reply
* [PATCH v5 16/22] KVM: arm64: vgic-its: Add infrastructure for table lookup
From: Auger Eric @ 2017-04-27 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170427180641.GT50776@lvm>
Hi,
On 27/04/2017 20:06, Christoffer Dall wrote:
> On Fri, Apr 14, 2017 at 12:15:28PM +0200, Eric Auger wrote:
>> Add a generic lookup_table() helper whose role consists in
>> scanning a contiguous table located in guest RAM and applying
>> a callback on each entry. Entries can be handled as linked lists
>> since the callback may return an offset to the next entry and
>> also tell that an entry is the last one.
>>
>> Helper functions also are added to compute the device/event ID
>> offset to the next DTE/ITE.
>>
>> compute_next_devid_offset, compute_next_eventid_offset and
>> lookup_table will become static in subsequent patches
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>> v4 -> v5:
>> - use kvm_read_guest
>>
>> v3 -> v4:
>> - remove static to avoid compilation warning
>> - correct size computation in looup_table()
>> - defines now encode the number of bits used for devid and eventid offsets
>> - use BIT() - 1 to encode the max offets
>> ---
>> virt/kvm/arm/vgic/vgic-its.c | 93 ++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 93 insertions(+)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
>> index 56c5123..c22b35d 100644
>> --- a/virt/kvm/arm/vgic/vgic-its.c
>> +++ b/virt/kvm/arm/vgic/vgic-its.c
>> @@ -195,6 +195,8 @@ static struct its_ite *find_ite(struct vgic_its *its, u32 device_id,
>>
>> #define VITS_TYPER_IDBITS 16
>> #define VITS_TYPER_DEVBITS 16
>> +#define VITS_DTE_MAX_DEVID_OFFSET (BIT(14) - 1)
>> +#define VITS_ITE_MAX_EVENTID_OFFSET (BIT(16) - 1)
>>
>> /*
>> * Finds and returns a collection in the ITS collection table.
>> @@ -1674,6 +1676,97 @@ int vgic_its_attr_regs_access(struct kvm_device *dev,
>> return ret;
>> }
>>
>> +u32 compute_next_devid_offset(struct list_head *h, struct its_device *dev)
>> +{
>> + struct list_head *e = &dev->dev_list;
>> + struct its_device *next;
>> + u32 next_offset;
>> +
>> + if (e->next == h)
>> + return 0;
>> + next = list_entry(e->next, struct its_device, dev_list);
>> + next_offset = next->device_id - dev->device_id;
>> +
>> + return min_t(u32, next_offset, VITS_DTE_MAX_DEVID_OFFSET);
>> +}
>> +
>> +u32 compute_next_eventid_offset(struct list_head *h, struct its_ite *ite)
>> +{
>> + struct list_head *e = &ite->ite_list;
>> + struct its_ite *next;
>> + u32 next_offset;
>> +
>> + if (e->next == h)
>> + return 0;
>> + next = list_entry(e->next, struct its_ite, ite_list);
>> + next_offset = next->event_id - ite->event_id;
>> +
>> + return min_t(u32, next_offset, VITS_ITE_MAX_EVENTID_OFFSET);
>> +}
>> +
>> +/**
>> + * entry_fn_t - Callback called on a table entry restore path
>> + * @its: its handle
>> + * @id: id of the entry
>> + * @entry: pointer to the entry
>> + * @opaque: pointer to an opaque data
>> + * @next_offset: minimal ID offset to the next entry. 0 if this
>> + * entry is the last one, 1 if the entry is invalid, >= 1 if an
>> + * entry's next_offset field was truly decoded
>> + *
>> + * Return: < 0 on error, 0 otherwise
>> + */
>> +typedef int (*entry_fn_t)(struct vgic_its *its, u32 id, void *entry,
>> + void *opaque, u32 *next_offset);
>> +
>> +/**
>> + * lookup_table - scan a contiguous table in guest RAM and applies a function
>> + * to each entry
>> + *
>> + * @its: its handle
>> + * @base: base gpa of the table
>> + * @size: size of the table in bytes
>> + * @esz: entry size in bytes
>> + * @start_id: first entry's ID
>
> I'm a little confused. Why is this not 0?
Because this is meant to be called on a second-level table as well
(device table). In that case the start ID != 0.
>
>> + * @fn: function to apply on each entry
>> + *
>> + * Return: < 0 on error, 1 if last element identified, 0 otherwise
>
> How can you scan the entire table and not find the last element?
This happens on 2d level tables. The last element might be in another 2d
level table.
>
>> + */
>> +int lookup_table(struct vgic_its *its, gpa_t base, int size, int esz,
>> + int start_id, entry_fn_t fn, void *opaque)
>
> Is this really a lookup? I think this should be called
> 'scan_its_table'.
ok no strong opinion here.
>
>> +{
>> + void *entry = kzalloc(esz, GFP_KERNEL);
>> + struct kvm *kvm = its->dev->kvm;
>> + unsigned long len = size;
>> + u32 id = start_id;
>
> why are ids u32 and not just an unsigned long?
will change that.
>
>> + gpa_t gpa = base;
>> + int ret;
>> +
>> + while (len > 0) {
>> + u32 next_offset;
>> + size_t byte_offset;
>> +
>> + ret = kvm_read_guest(kvm, gpa, entry, esz);
>> + if (ret)
>> + goto out;
>> +
>> + ret = fn(its, id, entry, opaque, &next_offset);
>> + if (ret < 0 || (!ret && !next_offset))
>> + goto out;
>> +
>> + byte_offset = next_offset * esz;
>> + id += next_offset;
>> + gpa += byte_offset;
>> + len -= byte_offset;
>> + }
>> + kfree(entry);
>> + return 0;
>> +
>
> here you can just set 'ret = 0;'
>
>> +out:
>> + kfree(entry);
>> + return (ret < 0 ? ret : 1);
>
> and then here you can do 'return (ret <= 0 ? ret : 1)'
> but I actually think it's nicer to just write:
>
> if (ret <= 0)
> return ret;
> return 1;
OK
thanks
Eric
>
>> +}
>> +
>> /**
>> * vgic_its_save_device_tables - Save the device table and all ITT
>> * into guest RAM
>> --
>> 2.5.5
>>
>
> Thanks,
> -Christoffer
>
^ permalink raw reply
* [PATCH] [media] pxa_camera: fix module remove codepath for v4l2 clock
From: Robert Jarzmik @ 2017-04-27 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4391b498-0a75-ff42-6a7e-65aef0fada07@tul.cz>
Petr Cvek <petr.cvek@tul.cz> writes:
> The conversion from soc_camera omitted a correct handling of the clock
> gating for a sensor. When the pxa_camera driver module was removed it
> tried to unregister clk, but this caused a similar warning:
>
> WARNING: CPU: 0 PID: 6740 at drivers/media/v4l2-core/v4l2-clk.c:278
> v4l2_clk_unregister(): Refusing to unregister ref-counted 0-0030 clock!
>
> The clock was at time still refcounted by the sensor driver. Before
> the removing of the pxa_camera the clock must be dropped by the sensor
> driver. This should be triggered by v4l2_async_notifier_unregister() call
> which removes sensor driver module too, calls unbind() function and then
> tries to probe sensor driver again. Inside unbind() we can safely
> unregister the v4l2 clock as the sensor driver got removed. The original
> v4l2_clk_unregister() should be put inside test as the clock can be
> already unregistered from unbind(). If there was not any bound sensor
> the clock is still present.
>
> The codepath is practically a copy from the old soc_camera. The bug was
> tested with a pxa_camera+ov9640 combination during the conversion
> of the ov9640 from the soc_camera.
>
> Signed-off-by: Petr Cvek <petr.cvek@tul.cz>
Yeah, it's way better with this patch, especially the insmod/rmmod/insmod/rmmod
test.
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Cheers.
--
Robert
^ permalink raw reply
* [PATCH v5 12/22] KVM: arm64: vgic-its: Interpret MAPD ITT_addr field
From: Auger Eric @ 2017-04-27 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170427180911.GU50776@lvm>
Hi,
On 27/04/2017 20:09, Christoffer Dall wrote:
> On Thu, Apr 27, 2017 at 07:44:25PM +0200, Auger Eric wrote:
>> Hi,
>>
>> On 27/04/2017 18:43, Christoffer Dall wrote:
>>> On Fri, Apr 14, 2017 at 12:15:24PM +0200, Eric Auger wrote:
>>>> Up to now the MAPD ITT_addr had been ignored. We will need it
>>>> for save/restore. Let's record it in the its_device struct.
>>>>
>>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>>>
>>>> ---
>>>> v4 -> v5:
>>>> - its_cmd_get_ittaddr macro now returns the actual ITT GPA
>>>>
>>>> v3 -> v4:
>>>> - in vgic_its_cmd_handle_mapd, itt_addr directly is shifted
>>>> - correct ittaddr bitmask to support 48bit GPA
>>>> ---
>>>> virt/kvm/arm/vgic/vgic-its.c | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
>>>> index 0f3c8f3..757598d 100644
>>>> --- a/virt/kvm/arm/vgic/vgic-its.c
>>>> +++ b/virt/kvm/arm/vgic/vgic-its.c
>>>> @@ -106,6 +106,7 @@ struct its_device {
>>>> /* the head for the list of ITTEs */
>>>> struct list_head itt_head;
>>>> u32 nb_eventid_bits;
>>>> + gpa_t itt_addr;
>>>> u32 device_id;
>>>> };
>>>>
>>>> @@ -569,6 +570,7 @@ static u64 its_cmd_mask_field(u64 *its_cmd, int word, int shift, int size)
>>>> #define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1, 0, 32)
>>>> #define its_cmd_get_physical_id(cmd) its_cmd_mask_field(cmd, 1, 32, 32)
>>>> #define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2, 0, 16)
>>>> +#define its_cmd_get_ittaddr(cmd) (its_cmd_mask_field(cmd, 2, 8, 47) << 8)
>>>
>>> Why 47? The ITT_addr field is bits [51:8] unless I'm looking at
>>> something wrong?
>>
>> Initially I limited to 48 bits since I found in the code:
>>
>> /*
>> * We only implement 48 bits of PA at the moment, although the ITS
>> * supports more. Let's be restrictive here.
>> */
>> #define BASER_ADDRESS(x) ((x) & GENMASK_ULL(47, 16))
>> #define CBASER_ADDRESS(x) ((x) & GENMASK_ULL(47, 12))
>>
>> But practically as I encode the ITT addr field on 52 bits now in the DTE
>> there is no reason anymore.
>
> Well, regardless, shouldn't you be bassing 44 to its_cmd_mask_field(),
> because you're shifting left 8 bits afterwards?
Hum yes that's correct. Andre already warned me against that mistake :-(
Thanks
Eric
>
> Thanks,
> -Christoffer
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [SPAM]Re: [PATCH 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
From: Arnd Bergmann @ 2017-04-27 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493194205.27023.80.camel@mtkswgap22>
On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> Hi
>
> On Tue, 2017-04-25 at 14:18 +0200, Arnd Bergmann wrote:
>> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
>> > Add documentation for PCIe host driver available in MT7623
>> > series SoCs.
>> >
>> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
>> > ---
>> > .../bindings/pci/mediatek,mt7623-pcie.txt | 153 +++++++++++++++++++++
>> > 1 file changed, 153 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
>> > new file mode 100644
>> > index 0000000..ee93ba2
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
>> > @@ -0,0 +1,153 @@
>> > +Mediatek MT7623 PCIe controller
>> > +
>> > +Required properties:
>> > +- compatible: Should contain "mediatek,mt7623-pcie".
>>
>> Did mediatek license the IP block from someone else or was it
>> developed in-house? Is there a name and/or version identifier
>> for the block itself other than identifying it as the one in mt7623?
>
> Originally, it license from synopsys. Our designer add a wrapper to hide
> the DBI detail so that we cannot use them directly. Perhaps I can call
> it "mediatek,gen2v1-pcie", because we have a plan to upstream a in-house
> Gen2 IP in the future.
Ok, so this is the same hardware that drivers/pci/dwc/ handles, but
it needs a separate driver because the wrapper that was added uses
a completely different register layout, right?
Are any of the registers the same at all, e.g. for MSI handling?
>> > +Required properties:
>> > +- device_type: Must be "pci"
>> > +- assigned-addresses: Address and size of the port configuration registers
>> > +- reg: Only the first four bytes are used to refer to the correct bus number
>> > + and device number.
>> > +- #address-cells: Must be 3
>> > +- #size-cells: Must be 2
>> > +- ranges: Sub-ranges distributed from the PCIe controller node. An empty
>> > + property is sufficient.
>> > +- clocks: Must contain an entry for each entry in clock-names.
>> > + See ../clocks/clock-bindings.txt for details.
>> > +- clock-names: Must include the following entries:
>> > + - sys_ck
>> > +- resets: Must contain an entry for each entry in reset-names.
>> > + See ../reset/reset.txt for details.
>>
>> This seems odd: you have a device that is simply identified as "pci"
>> without any more specific ID, but you require additional properties
>> (clocks, reset, ...) that are not part of the standard PCI binding.
>>
>> Can you clarify how the port devices related to the root device in
>> this hardware design?
>
> I will write clarify like this:
>
> PCIe subsys includes one Host/PCI bridge and 3 PCIe MAC port. There
> are 3 bus master for data access and 1 slave for configuration and
> status register access. Each port has PIPE interface to PHY and
If I understand this right, then each of the ports in your hardware
is what we normally drive using the drivers/pci/dwc/ driver framework,
but your implementation actually made it more PCI standard compliant
by implementing the normal PCIe host bridge registers for all ports
combined, something that most others don't.
>> Have you considered moving the nonstandard properties into the host
>> bridge node and having that device deal with setting up the links
>> to the other drivers? That way we could use the regular pcie
>> port driver for the children.
>>
>
> OK, but I still want to use port->reset to catch reset properties in
> driver.
Do you mean in drivers/pci/pcie/portdrv_pci.c? I see that it
has a function called pcie_portdrv_slot_reset(), but I don't see
how that relates to your reset line at the moment. Is this
something you have submitted in a different series?
Or do you mean in this host driver? The problem I see with
that approach is that the port device is owned by portdrv_pci,
so the host bridge driver should not look at the properties of
the port.
>> > +- reset-names: Must include the following entries:
>> > + - pcie-reset
>> > +- num-lanes: Number of lanes to use for this port.
>> > +- phys: Must contain an entry for each entry in phy-names.
>> > +- phy-names: Must include an entry for each sub node. Entries are of the form
>> > + "pcie-phyN": where N ranges from 0 to the value specified for port number.
>> > + See ../phy/phy-mt7623-pcie.txt for details.
>>
>> I think the name should not include the number of the port but rather
>> be always the same here.
>>
>
> Hmm, I think it's better to keep the name here. It's more readable for
> user to understand the relationship between port0 and phy0.
No, I would argue that it's confusing for the reader because it
is different from how most other DT bindings work: In each device
node, you tend to have a set of properties with well-known names
that are documented. When your reference is called "pcie-phy1"
in one node and "pcie-phy2", I would interpret that as both ports
having two phys each, but only one of them being used.
Arnd
^ permalink raw reply
* [PATCH net-next 1/4] ixgbe: sparc: rename the ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER
From: Casey Leedom @ 2017-04-27 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170427171938.GA10705@bhelgaas-glaptop.roam.corp.google.com>
Thanks for adding me to the Cc list Bjorn. Hopefully my message will make
it out to the netdev and linux-pci lists -- I'm not currently subscribed to
them. I've explicitly marked this message to be sent in plain text but
modern email agents suck with respect to this. (sigh) I have officially
become a curmudgeon.
So, officially, Relaxed Ordering should be a Semantic Noop as far as PCIe
transfers are concerned, as long as you don't care what order the PCIe
Transaction Layer Packets are processed in by the target PCIe Fabric End
Point.
Basically, if you have some number of back-to-back PCIe TLPs between two
Fabric End Points {A} -> {B} which have the Relaxed Ordering Attribute set,
the End Point {B} receiving these RO TLPs may process them in any order it
likes. When a TLP without Relaxed Ordering is sent {A} -> {B}, all
preceding TLPs with Relaxed Ordering set must be processed by {B} prior to
processing the TLP without Relaxed Ordering set. In this sense, a TLP
without Relaxed Ordering set is something akin to a "memory barrier".
All of this is covered in Section 2.4.1 of the PCIe 3.0 Specification (PCI
Express(r) Base Specification Revision 3.0 November 10, 2010).
The advantage of using Relaxed Ordering (which is heavily used when
sending data to Graphics Cards as I understand it), is that the PCIe
Endpoint can potentially optimize the processing order of RO TLPs with
things like a local multi-channel Memory Controller in order to achieve the
highest transfer bandwidth possible.
However, we have discovered at least two PCIe 3.0 Root Complex
implementations which have problems with TLPs directed at them with the
Relaxed Ordering Attribute set and I'm in the process of working up a Linux
Kernel PCI "Quirk" to allow those PCIe End Points to be marked as "not being
advisable to send RO TLPs to". These problems range from "mere" Performance
Problems to outright Data Corruption. I'm working with the vendors of these
... "problematic" Root Complex implementations and hope to have this patch
submitted to the linux-pci list by tomorrow.
By the way, it's important to note that just because, say, a Root Complex
has problems with RO TLPs directed at it, that doesn't mean that you want to
avoid all use of Relaxed Ordering within the PCIe Fabric. For instance,
with the vendor whose Root Complex has a Performance Problem with RO TLPs
directed at it, it's perfectly reasonable -- and desired -- to use Relaxed
Ordering in Peer-to-Peer traffic. Say for instance, with an NVMe <->
Ethernet application.
Casey
^ permalink raw reply
* [PATCH 1/2] PCI: mediatek: Add Mediatek PCIe host controller support
From: Arnd Bergmann @ 2017-04-27 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493194200.27023.79.camel@mtkswgap22>
On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
> On Tue, 2017-04-25 at 14:38 +0200, Arnd Bergmann wrote:
>> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee@mediatek.com> wrote:
>> > +static int mtk_pcie_enable_ports(struct mtk_pcie *pcie)
>> > +{
>> > + struct device *dev = pcie->dev;
>> > + struct mtk_pcie_port *port, *tmp;
>> > + int err, linkup = 0;
>> > +
>> > + list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
>> > + err = clk_prepare_enable(port->sys_ck);
>> > + if (err) {
>> > + dev_err(dev, "failed to enable port%d clock\n",
>> > + port->index);
>> > + continue;
>> > + }
>> > +
>> > + /* assert RC */
>> > + reset_control_assert(port->reset);
>> > + /* de-assert RC */
>> > + reset_control_deassert(port->reset);
>> > +
>> > + /* power on PHY */
>> > + err = phy_power_on(port->phy);
>> > + if (err) {
>> > + dev_err(dev, "failed to power on port%d phy\n",
>> > + port->index);
>> > + goto err_phy_on;
>> > + }
>> > +
>> > + mtk_pcie_assert_ports(port);
>> > +
>>
>> Similar to the comment I had for the binding, I wonder if it would be
>> better to keep all the information about the ports in one place and
>> then just deal with it at the root level.
>>
>> Alternatively, we could decide to standardize on the properties
>> you have added to the pcie port node, but then I would handle
>> them in the pcieport driver rather than in the host bridge driver.
>
> Sorry, I'm not sure what you want me to do here.
>
> I could move all clock operation in root level. But we need to keep the
> reset and PHY operation sequence in the loop, In addition, we could
> easily free resources if ports link fail.
>
> How about moving this function to mtk_pcie_parse_and_add_res()?
That could work, please try it out and see if the code gets better or
worse. This may depend on what we end up doing with the DT
properties.
>> > +/*
>> > + * This IP lacks interrupt status register to check or map INTx from
>> > + * different devices at the same time.
>> > + */
>> > +static int __init mtk_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
>> > +{
>> > + struct mtk_pcie *pcie = dev->bus->sysdata;
>> > + struct mtk_pcie_port *port;
>> > +
>> > + list_for_each_entry(port, &pcie->ports, list)
>> > + if (port->index == slot)
>> > + return port->irq;
>> > +
>> > + return -1;
>> > +}
>>
>> This looks odd, what is it needed for specifically? It looks like
>> it's broken for devices behind bridges, and the interrupt mapping
>> should normally come from the interrupt-map property, without
>> the need for a driver specific map_irq override.
>
> Our hardware just has a GIC for each port and lacks interrupt status for
> host driver to distinguish INTx. So I return port IRQ here.
You should still be able to express this with standard interrupt-map
DT property, without having to resort to your own map_irq
callback handler.
In the interrupt-map-mask, you can ignore the interrupt line
only list the devfn of the root ports for each entry.
>> > +static int mtk_pcie_register_ports(struct mtk_pcie *pcie)
>> > +{
>> > + struct pci_bus *bus, *child;
>> > +
>> > + bus = pci_scan_root_bus(pcie->dev, 0, &mtk_pcie_ops, pcie,
>> > + &pcie->resources);
>>
>> Can you use the new pci_register_host_bridge() method instead of
>> pci_scan_root_bus() here?
>
> May I know what's difference between pci_scan_root_bus() and using
> pci_register_host_bridge() directly? What situation should we use it?
> It seems that just tegra use this new method currently.
We introduced the new function for tegra for now, in the long run
I would hope we can convert all other drivers to it as well, to make it
easier to add further parameters.
The new function also has a cleaner way of dealing with the memory
allocations, similar to how other subsystems work.
Arnd
^ permalink raw reply
* [PATCH 0/3 v3] ARM/ARM64: silence large module first time allocation
From: Florian Fainelli @ 2017-04-27 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <56EE35F5-97F9-4EA4-894B-581E7AE09A78@linaro.org>
On 04/27/2017 11:24 AM, Ard Biesheuvel wrote:
>
>> On 27 Apr 2017, at 19:18, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation
>> done from module space will fail, produce a general OOM allocation and also a
>> vmap warning. The second allocation from vmalloc space may or may not be
>> successful, but is actually the one we are interested about in these cases.
>>
>> This patch series passed __GFP_NOWARN to silence such allocations from the
>> ARM/ARM64 module loader's first time allocation when the MODULES_PLT option is
>> enabled, and also makes alloc_vmap_area() react to the caller setting
>> __GFP_NOWARN to silence "vmap allocation for size..." messages.
>>
>>
>> Changes in v3:
>> - check for __GFP_NOWARN not set where the check for printk_ratelimited()
>> is done, add Michal's Acked-by
>>
>> - use C conditionals and not CPP conditionals for IS_ENABLED(), add Ard's
>> Reviewed-by tag
>>
>
> Ok these look fine now. But are you sure that omitting the single pr_warn() gets rid of all of that?
> Or do we need more patches on top?
Since the caller now set __GFP_NOWARN, this propagates correctly to all
functions called from alloc_vmap_area() like kmalloc_node(). With the
patches applied, I only get the stuff that I would expect:
# echo 8 7 4 1 > /proc/sys/kernel/printk
# insmod huge.ko
[ 59.285547] huge: loading out-of-tree module taints kernel.
[ 59.328553] big_init: I am a big module using 3932160 bytes of data!
#
>
>
>> Changes in v2:
>>
>> - check __GFP_NOWARN out of the printk_ratelimited() check (Michal)
>>
>> Here is an example of what we would get without these two patches, pretty
>> scary huh?
>>
>> # insmod /mnt/nfs/huge.ko
>> [ 22.114143] random: nonblocking pool is initialized
>> [ 22.183575] vmap allocation for size 15736832 failed: use vmalloc=<size> to increase size.
>> [ 22.191873] vmalloc: allocation failure: 15729534 bytes
>> [ 22.197112] insmod: page allocation failure: order:0, mode:0xd0
>> [ 22.203048] CPU: 2 PID: 1506 Comm: insmod Tainted: G O 4.1.20-1.9pre-01082-gbbbff07bc3ce #9
>> [ 22.212536] Hardware name: Broadcom STB (Flattened Device Tree)
>> [ 22.218480] [<c0017eec>] (unwind_backtrace) from [<c00135c8>] (show_stack+0x10/0x14)
>> [ 22.226238] [<c00135c8>] (show_stack) from [<c0638684>] (dump_stack+0x90/0xa4)
>> [ 22.233473] [<c0638684>] (dump_stack) from [<c00aae1c>] (warn_alloc_failed+0x104/0x144)
>> [ 22.241490] [<c00aae1c>] (warn_alloc_failed) from [<c00d72e0>] (__vmalloc_node_range+0x170/0x218)
>> [ 22.250375] [<c00d72e0>] (__vmalloc_node_range) from [<c00147d0>] (module_alloc+0x50/0xac)
>> [ 22.258651] [<c00147d0>] (module_alloc) from [<c008ae2c>] (module_alloc_update_bounds+0xc/0x6c)
>> [ 22.267360] [<c008ae2c>] (module_alloc_update_bounds) from [<c008b778>] (load_module+0x8ec/0x2058)
>> [ 22.276329] [<c008b778>] (load_module) from [<c008cfd4>] (SyS_init_module+0xf0/0x174)
>> [ 22.284170] [<c008cfd4>] (SyS_init_module) from [<c0010140>] (ret_fast_syscall+0x0/0x3c)
>> [ 22.292277] Mem-Info:
>> [ 22.294567] active_anon:5236 inactive_anon:1773 isolated_anon:0
>> [ 22.294567] active_file:1 inactive_file:3822 isolated_file:0
>> [ 22.294567] unevictable:0 dirty:0 writeback:0 unstable:0
>> [ 22.294567] slab_reclaimable:238 slab_unreclaimable:1594
>> [ 22.294567] mapped:855 shmem:2950 pagetables:36 bounce:0
>> [ 22.294567] free:39031 free_pcp:198 free_cma:3928
>> [ 22.327196] DMA free:156124kB min:1880kB low:2348kB high:2820kB active_anon:20944kB inactive_anon:7092kB active_file:4kB inactive_file:15288kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:262144kB managed:227676kB mlocked:0kB dirty:0kB writeback:0kB mapped:3420kB shmem:11800kB slab_reclaimable:952kB slab_unreclaimable:6376kB kernel_stack:560kB pagetables:144kB unstable:0kB bounce:0kB free_pcp:792kB local_pcp:68kB free_cma:15712kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
>> [ 22.371631] lowmem_reserve[]: 0 0 0 0
>> [ 22.375372] HighMem free:0kB min:128kB low:128kB high:128kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2883584kB managed:0kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
>> [ 22.416249] lowmem_reserve[]: 0 0 0 0
>> [ 22.419986] DMA: 3*4kB (UEM) 4*8kB (UE) 1*16kB (M) 4*32kB (UEMC) 3*64kB (EMC) 1*128kB (E) 4*256kB (UEMC) 2*512kB (UE) 2*1024kB (MC) 4*2048kB (UEMC) 35*4096kB (MRC) = 156156kB
>> [ 22.435922] HighMem: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
>> [ 22.446130] 6789 total pagecache pages
>> [ 22.449889] 0 pages in swap cache
>> [ 22.453212] Swap cache stats: add 0, delete 0, find 0/0
>> [ 22.458447] Free swap = 0kB
>> [ 22.461334] Total swap = 0kB
>> [ 22.464222] 786432 pages RAM
>> [ 22.467110] 720896 pages HighMem/MovableOnly
>> [ 22.471388] 725417 pages reserved
>> [ 22.474711] 4096 pages cma reserved
>> [ 22.511310] big_init: I am a big module using 3932160 bytes of data!
>>
>> Florian Fainelli (3):
>> mm: Silence vmap() allocation failures based on caller gfp_flags
>> ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y
>> arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y
>>
>> arch/arm/kernel/module.c | 11 +++++++++--
>> arch/arm64/kernel/module.c | 7 ++++++-
>> mm/vmalloc.c | 2 +-
>> 3 files changed, 16 insertions(+), 4 deletions(-)
>>
>> --
>> 2.9.3
>>
--
Florian
^ permalink raw reply
* [PATCH 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors
From: Markus Mayer @ 2017-04-27 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGt4E5susQWWNZPbNh8AoWtK-4yu50VL=GqOw+_2w_FA+2V68Q@mail.gmail.com>
On 25 April 2017 at 12:29, Markus Mayer <markus.mayer@broadcom.com> wrote:
> Hi Rob,
>
> On 18 April 2017 at 13:17, Markus Mayer <code@mmayer.net> wrote:
>> From: Markus Mayer <mmayer@broadcom.com>
>>
>> Provide bindings for the Broadcom STB DDR PHY Front End (DPFE).
>
> Would you be able to have a look at this binding? The driver won't be
> upstreamed as hwmon driver (as per Guenter's comments). I am currently
> converting the driver to a "soc" driver instead, but the proposed
> binding remains unchanged.
>
> If you have comments or suggestions, I would like to incorporate them
> with the new series I will be sending out.
To explain a bit more what we are looking for: we had a internal
discussions how to structure this binding and are looking for some
guidance.
Should we create three different nodes for the three different memory
areas (dpfe-cpu at ..., dpfe-dmem at ..., dpfe-imem at ...), each with a single
"reg" property (which is the proposal below) or should this be one
single property with 3 "reg" cells, i.e. something like this:
dpfe-cpu at f1132000 {
...
reg = <0xf1132000 0x180 /* register space */
0xf1134000 0x1000 /* data memory */
0xf1138000 0x4000>; /* instruction memory */
...
};
Regards,
-Markus
>> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>> ---
>> .../devicetree/bindings/hwmon/brcmstb-dpfe.txt | 68 ++++++++++++++++++++++
>> 1 file changed, 68 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt b/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
>> new file mode 100644
>> index 0000000..3519197
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/brcmstb-dpfe.txt
>> @@ -0,0 +1,68 @@
>> +DDR PHY Front End (DPFE) for Broadcom STB
>> +=========================================
>> +
>> +DPFE and the DPFE firmware provide an interface for the host CPU to
>> +communicate with the DCPU, which resides inside the DDR PHY.
>> +
>> +There are three memory regions for interacting with the DCPU.
>> +
>> +The DCPU Register Space
>> +-----------------------
>> +
>> +Required properties:
>> + - compatible: must be one of brcm,bcm7271-dpfe-cpu, brcm,dpfe-cpu-v12.0.0.0
>> + or brcm,dpfe-cpu
>> + - reg: must reference the start address and length of the DCPU register
>> + space
>> +
>> +Optional properties:
>> + - cell-index: the index of the DPFE instance; will default to 0 if not set
>> +
>> +Example:
>> + dpfe_cpu0: dpfe-cpu at f1132000 {
>> + compatible = "brcm,bcm7271-dpfe-cpu",
>> + "brcm,dpfe-cpu-v12.0.0.0",
>> + "brcm,dpfe-cpu";
>> + reg = <0xf1132000 0x180>;
>> + cell-index = <0>;
>> + };
>> +
>> +The DCPU Data Memory Space
>> +--------------------------
>> +
>> +Required properties:
>> + - compatible: must be one of brcm,bcm7271-dpfe-dmem, brcm,dpfe-dmem-v12.0.0.0
>> + or brcm,dpfe-dmem
>> + - reg: must reference the start address and length of the DCPU DMEM space
>> +
>> +Optional properties:
>> + - cell-index: the index of the DPFE instance; will default to 0 if not set
>> +
>> +Example:
>> + dpfe_dmem0: dpfe-dmem at f1134000 {
>> + compatible = "brcm,bcm7271-dpfe-dmem",
>> + "brcm,dpfe-dmem-v12.0.0.0",
>> + "brcm,dpfe-dmem";
>> + reg = <0xf1134000 0x1000>;
>> + cell-index = <0>;
>> + };
>> +
>> +The DCPU Instruction Memory Space
>> +---------------------------------
>> +
>> +Required properties:
>> + - compatible: must be one of brcm,bcm7271-dpfe-imem, brcm,dpfe-imem-v12.0.0.0
>> + or brcm,dpfe-imem
>> + - reg: must reference the start address and length of the DCPU IMEM space
>> +
>> +Optional properties:
>> + - cell-index: the index of the DPFE instance; will default to 0 if not set
>> +
>> +Example:
>> + dpfe_imem0: dpfe-imem at f1138000 {
>> + compatible = "brcm,bcm7271-dpfe-imem",
>> + "brcm,dpfe-imem-v12.0.0.0",
>> + "brcm,dpfe-imem";
>> + reg = <0xf1138000 0x4000>;
>> + cell-index = <0>;
>> + };
>> --
>> 2.7.4
>>
^ permalink raw reply
* [PATCH 0/3 v3] ARM/ARM64: silence large module first time allocation
From: Ard Biesheuvel @ 2017-04-27 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170427181902.28829-1-f.fainelli@gmail.com>
> On 27 Apr 2017, at 19:18, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation
> done from module space will fail, produce a general OOM allocation and also a
> vmap warning. The second allocation from vmalloc space may or may not be
> successful, but is actually the one we are interested about in these cases.
>
> This patch series passed __GFP_NOWARN to silence such allocations from the
> ARM/ARM64 module loader's first time allocation when the MODULES_PLT option is
> enabled, and also makes alloc_vmap_area() react to the caller setting
> __GFP_NOWARN to silence "vmap allocation for size..." messages.
>
>
> Changes in v3:
> - check for __GFP_NOWARN not set where the check for printk_ratelimited()
> is done, add Michal's Acked-by
>
> - use C conditionals and not CPP conditionals for IS_ENABLED(), add Ard's
> Reviewed-by tag
>
Ok these look fine now. But are you sure that omitting the single pr_warn() gets rid of all of that?
Or do we need more patches on top?
> Changes in v2:
>
> - check __GFP_NOWARN out of the printk_ratelimited() check (Michal)
>
> Here is an example of what we would get without these two patches, pretty
> scary huh?
>
> # insmod /mnt/nfs/huge.ko
> [ 22.114143] random: nonblocking pool is initialized
> [ 22.183575] vmap allocation for size 15736832 failed: use vmalloc=<size> to increase size.
> [ 22.191873] vmalloc: allocation failure: 15729534 bytes
> [ 22.197112] insmod: page allocation failure: order:0, mode:0xd0
> [ 22.203048] CPU: 2 PID: 1506 Comm: insmod Tainted: G O 4.1.20-1.9pre-01082-gbbbff07bc3ce #9
> [ 22.212536] Hardware name: Broadcom STB (Flattened Device Tree)
> [ 22.218480] [<c0017eec>] (unwind_backtrace) from [<c00135c8>] (show_stack+0x10/0x14)
> [ 22.226238] [<c00135c8>] (show_stack) from [<c0638684>] (dump_stack+0x90/0xa4)
> [ 22.233473] [<c0638684>] (dump_stack) from [<c00aae1c>] (warn_alloc_failed+0x104/0x144)
> [ 22.241490] [<c00aae1c>] (warn_alloc_failed) from [<c00d72e0>] (__vmalloc_node_range+0x170/0x218)
> [ 22.250375] [<c00d72e0>] (__vmalloc_node_range) from [<c00147d0>] (module_alloc+0x50/0xac)
> [ 22.258651] [<c00147d0>] (module_alloc) from [<c008ae2c>] (module_alloc_update_bounds+0xc/0x6c)
> [ 22.267360] [<c008ae2c>] (module_alloc_update_bounds) from [<c008b778>] (load_module+0x8ec/0x2058)
> [ 22.276329] [<c008b778>] (load_module) from [<c008cfd4>] (SyS_init_module+0xf0/0x174)
> [ 22.284170] [<c008cfd4>] (SyS_init_module) from [<c0010140>] (ret_fast_syscall+0x0/0x3c)
> [ 22.292277] Mem-Info:
> [ 22.294567] active_anon:5236 inactive_anon:1773 isolated_anon:0
> [ 22.294567] active_file:1 inactive_file:3822 isolated_file:0
> [ 22.294567] unevictable:0 dirty:0 writeback:0 unstable:0
> [ 22.294567] slab_reclaimable:238 slab_unreclaimable:1594
> [ 22.294567] mapped:855 shmem:2950 pagetables:36 bounce:0
> [ 22.294567] free:39031 free_pcp:198 free_cma:3928
> [ 22.327196] DMA free:156124kB min:1880kB low:2348kB high:2820kB active_anon:20944kB inactive_anon:7092kB active_file:4kB inactive_file:15288kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:262144kB managed:227676kB mlocked:0kB dirty:0kB writeback:0kB mapped:3420kB shmem:11800kB slab_reclaimable:952kB slab_unreclaimable:6376kB kernel_stack:560kB pagetables:144kB unstable:0kB bounce:0kB free_pcp:792kB local_pcp:68kB free_cma:15712kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> [ 22.371631] lowmem_reserve[]: 0 0 0 0
> [ 22.375372] HighMem free:0kB min:128kB low:128kB high:128kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2883584kB managed:0kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
> [ 22.416249] lowmem_reserve[]: 0 0 0 0
> [ 22.419986] DMA: 3*4kB (UEM) 4*8kB (UE) 1*16kB (M) 4*32kB (UEMC) 3*64kB (EMC) 1*128kB (E) 4*256kB (UEMC) 2*512kB (UE) 2*1024kB (MC) 4*2048kB (UEMC) 35*4096kB (MRC) = 156156kB
> [ 22.435922] HighMem: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> [ 22.446130] 6789 total pagecache pages
> [ 22.449889] 0 pages in swap cache
> [ 22.453212] Swap cache stats: add 0, delete 0, find 0/0
> [ 22.458447] Free swap = 0kB
> [ 22.461334] Total swap = 0kB
> [ 22.464222] 786432 pages RAM
> [ 22.467110] 720896 pages HighMem/MovableOnly
> [ 22.471388] 725417 pages reserved
> [ 22.474711] 4096 pages cma reserved
> [ 22.511310] big_init: I am a big module using 3932160 bytes of data!
>
> Florian Fainelli (3):
> mm: Silence vmap() allocation failures based on caller gfp_flags
> ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y
> arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y
>
> arch/arm/kernel/module.c | 11 +++++++++--
> arch/arm64/kernel/module.c | 7 ++++++-
> mm/vmalloc.c | 2 +-
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v2 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags
From: Florian Fainelli @ 2017-04-27 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170427182018.GC30672@dhcp22.suse.cz>
On 04/27/2017 11:20 AM, Michal Hocko wrote:
>>> would be shorter and you wouldn't need the goto and a label.
>>
>> Do you want me to resubmit with that change included?
>
> Up to you. As I've said this is a nit at best.
I just sent a v3 based on feedback from Ard, thanks!
--
Florian
^ permalink raw reply
* [PATCH v2 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags
From: Michal Hocko @ 2017-04-27 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <416a788c-6160-1ce8-fccc-839f719b2a88@gmail.com>
On Thu 27-04-17 11:03:31, Florian Fainelli wrote:
> On 04/27/2017 10:56 AM, Michal Hocko wrote:
> > On Thu 27-04-17 10:38:58, Florian Fainelli wrote:
> >> If the caller has set __GFP_NOWARN don't print the following message:
> >> vmap allocation for size 15736832 failed: use vmalloc=<size> to increase
> >> size.
> >>
> >> This can happen with the ARM/Linux or ARM64/Linux module loader built
> >> with CONFIG_ARM{,64}_MODULE_PLTS=y which does a first attempt at loading
> >> a large module from module space, then falls back to vmalloc space.
> >>
> >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >
> > Acked-by: Michal Hocko <mhocko@suse.com>
> >
> > just a nit
> >
> >> ---
> >> mm/vmalloc.c | 4 ++++
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> >> index 0b057628a7ba..d8a851634674 100644
> >> --- a/mm/vmalloc.c
> >> +++ b/mm/vmalloc.c
> >> @@ -521,9 +521,13 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
> >> }
> >> }
> >>
> >> + if (gfp_mask & __GFP_NOWARN)
> >> + goto out;
> >> +
> >> if (printk_ratelimit())
> >
> > if (!(gfp_mask & __GFP_NOWARN) && printk_ratelimit())
> >> pr_warn("vmap allocation for size %lu failed: use vmalloc=<size> to increase size\n",
> >> size);
> >
> > would be shorter and you wouldn't need the goto and a label.
>
> Do you want me to resubmit with that change included?
Up to you. As I've said this is a nit at best.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v3 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y
From: Florian Fainelli @ 2017-04-27 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170427181902.28829-1-f.fainelli@gmail.com>
When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
module space fails, because the module is too big, and then the module
allocation is attempted from vmalloc space. Silence the first allocation
failure in that case by setting __GFP_NOWARN.
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm64/kernel/module.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 7f316982ce00..093c13541efb 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -32,11 +32,16 @@
void *module_alloc(unsigned long size)
{
+ gfp_t gfp_mask = GFP_KERNEL;
void *p;
+ /* Silence the initial allocation */
+ if (IS_ENABLED(CONFIG_ARM64_MODULE_PLTS))
+ gfp_mask |= __GFP_NOWARN;
+
p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
module_alloc_base + MODULES_VSIZE,
- GFP_KERNEL, PAGE_KERNEL_EXEC, 0,
+ gfp_mask, PAGE_KERNEL_EXEC, 0,
NUMA_NO_NODE, __builtin_return_address(0));
if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
--
2.9.3
^ permalink raw reply related
* [PATCH v3 2/3] ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y
From: Florian Fainelli @ 2017-04-27 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170427181902.28829-1-f.fainelli@gmail.com>
When CONFIG_ARM_MODULE_PLTS is enabled, the first allocation using the
module space fails, because the module is too big, and then the module
allocation is attempted from vmalloc space. Silence the first allocation
failure in that case by setting __GFP_NOWARN.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/kernel/module.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index 80254b47dc34..3ff571c2c71c 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -40,8 +40,15 @@
#ifdef CONFIG_MMU
void *module_alloc(unsigned long size)
{
- void *p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
- GFP_KERNEL, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
+ gfp_t gfp_mask = GFP_KERNEL;
+ void *p;
+
+ /* Silence the initial allocation */
+ if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS))
+ gfp_mask |= __GFP_NOWARN;
+
+ p = __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END,
+ gfp_mask, PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
__builtin_return_address(0));
if (!IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || p)
return p;
--
2.9.3
^ permalink raw reply related
* [PATCH v3 1/3] mm: Silence vmap() allocation failures based on caller gfp_flags
From: Florian Fainelli @ 2017-04-27 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170427181902.28829-1-f.fainelli@gmail.com>
If the caller has set __GFP_NOWARN don't print the following message:
vmap allocation for size 15736832 failed: use vmalloc=<size> to increase
size.
This can happen with the ARM/Linux or ARM64/Linux module loader built
with CONFIG_ARM{,64}_MODULE_PLTS=y which does a first attempt at loading
a large module from module space, then falls back to vmalloc space.
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
mm/vmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 0b057628a7ba..b74f1d01ef76 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -521,7 +521,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
}
}
- if (printk_ratelimit())
+ if (!(gfp_mask & __GFP_NOWARN) && printk_ratelimit())
pr_warn("vmap allocation for size %lu failed: use vmalloc=<size> to increase size\n",
size);
kfree(va);
--
2.9.3
^ permalink raw reply related
* [PATCH 0/3 v3] ARM/ARM64: silence large module first time allocation
From: Florian Fainelli @ 2017-04-27 18:18 UTC (permalink / raw)
To: linux-arm-kernel
With kernels built with CONFIG_ARM{,64}_MODULES_PLTS=y, the first allocation
done from module space will fail, produce a general OOM allocation and also a
vmap warning. The second allocation from vmalloc space may or may not be
successful, but is actually the one we are interested about in these cases.
This patch series passed __GFP_NOWARN to silence such allocations from the
ARM/ARM64 module loader's first time allocation when the MODULES_PLT option is
enabled, and also makes alloc_vmap_area() react to the caller setting
__GFP_NOWARN to silence "vmap allocation for size..." messages.
Changes in v3:
- check for __GFP_NOWARN not set where the check for printk_ratelimited()
is done, add Michal's Acked-by
- use C conditionals and not CPP conditionals for IS_ENABLED(), add Ard's
Reviewed-by tag
Changes in v2:
- check __GFP_NOWARN out of the printk_ratelimited() check (Michal)
Here is an example of what we would get without these two patches, pretty
scary huh?
# insmod /mnt/nfs/huge.ko
[ 22.114143] random: nonblocking pool is initialized
[ 22.183575] vmap allocation for size 15736832 failed: use vmalloc=<size> to increase size.
[ 22.191873] vmalloc: allocation failure: 15729534 bytes
[ 22.197112] insmod: page allocation failure: order:0, mode:0xd0
[ 22.203048] CPU: 2 PID: 1506 Comm: insmod Tainted: G O 4.1.20-1.9pre-01082-gbbbff07bc3ce #9
[ 22.212536] Hardware name: Broadcom STB (Flattened Device Tree)
[ 22.218480] [<c0017eec>] (unwind_backtrace) from [<c00135c8>] (show_stack+0x10/0x14)
[ 22.226238] [<c00135c8>] (show_stack) from [<c0638684>] (dump_stack+0x90/0xa4)
[ 22.233473] [<c0638684>] (dump_stack) from [<c00aae1c>] (warn_alloc_failed+0x104/0x144)
[ 22.241490] [<c00aae1c>] (warn_alloc_failed) from [<c00d72e0>] (__vmalloc_node_range+0x170/0x218)
[ 22.250375] [<c00d72e0>] (__vmalloc_node_range) from [<c00147d0>] (module_alloc+0x50/0xac)
[ 22.258651] [<c00147d0>] (module_alloc) from [<c008ae2c>] (module_alloc_update_bounds+0xc/0x6c)
[ 22.267360] [<c008ae2c>] (module_alloc_update_bounds) from [<c008b778>] (load_module+0x8ec/0x2058)
[ 22.276329] [<c008b778>] (load_module) from [<c008cfd4>] (SyS_init_module+0xf0/0x174)
[ 22.284170] [<c008cfd4>] (SyS_init_module) from [<c0010140>] (ret_fast_syscall+0x0/0x3c)
[ 22.292277] Mem-Info:
[ 22.294567] active_anon:5236 inactive_anon:1773 isolated_anon:0
[ 22.294567] active_file:1 inactive_file:3822 isolated_file:0
[ 22.294567] unevictable:0 dirty:0 writeback:0 unstable:0
[ 22.294567] slab_reclaimable:238 slab_unreclaimable:1594
[ 22.294567] mapped:855 shmem:2950 pagetables:36 bounce:0
[ 22.294567] free:39031 free_pcp:198 free_cma:3928
[ 22.327196] DMA free:156124kB min:1880kB low:2348kB high:2820kB active_anon:20944kB inactive_anon:7092kB active_file:4kB inactive_file:15288kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:262144kB managed:227676kB mlocked:0kB dirty:0kB writeback:0kB mapped:3420kB shmem:11800kB slab_reclaimable:952kB slab_unreclaimable:6376kB kernel_stack:560kB pagetables:144kB unstable:0kB bounce:0kB free_pcp:792kB local_pcp:68kB free_cma:15712kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 22.371631] lowmem_reserve[]: 0 0 0 0
[ 22.375372] HighMem free:0kB min:128kB low:128kB high:128kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2883584kB managed:0kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[ 22.416249] lowmem_reserve[]: 0 0 0 0
[ 22.419986] DMA: 3*4kB (UEM) 4*8kB (UE) 1*16kB (M) 4*32kB (UEMC) 3*64kB (EMC) 1*128kB (E) 4*256kB (UEMC) 2*512kB (UE) 2*1024kB (MC) 4*2048kB (UEMC) 35*4096kB (MRC) = 156156kB
[ 22.435922] HighMem: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
[ 22.446130] 6789 total pagecache pages
[ 22.449889] 0 pages in swap cache
[ 22.453212] Swap cache stats: add 0, delete 0, find 0/0
[ 22.458447] Free swap = 0kB
[ 22.461334] Total swap = 0kB
[ 22.464222] 786432 pages RAM
[ 22.467110] 720896 pages HighMem/MovableOnly
[ 22.471388] 725417 pages reserved
[ 22.474711] 4096 pages cma reserved
[ 22.511310] big_init: I am a big module using 3932160 bytes of data!
Florian Fainelli (3):
mm: Silence vmap() allocation failures based on caller gfp_flags
ARM: Silence first allocation with CONFIG_ARM_MODULE_PLTS=y
arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y
arch/arm/kernel/module.c | 11 +++++++++--
arch/arm64/kernel/module.c | 7 ++++++-
mm/vmalloc.c | 2 +-
3 files changed, 16 insertions(+), 4 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v5 01/10] arm64: allwinner: a64: enable RSB on A64
From: icenowy at aosc.io @ 2017-04-27 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170427132805.izv6xfktlhfc4yty@lukather>
? 2017-04-27 21:28?Maxime Ripard ???
> On Wed, Apr 26, 2017 at 11:20:14PM +0800, Icenowy Zheng wrote:
>> Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
>>
>> Add it and its pinmux.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> Acked-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>> Changes in v2:
>> - Removed bonus properties in pio node.
>> - Added Chen-Yu's ACK.
>>
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 19
>> +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index c7f669f5884f..05ec9fc5e81f 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -422,6 +422,25 @@
>> #gpio-cells = <3>;
>> interrupt-controller;
>> #interrupt-cells = <3>;
>> +
>> + r_rsb_pins: rsb at 0 {
>> + pins = "PL0", "PL1";
>> + function = "s_rsb";
>> + };
>> + };
>> +
>> + r_rsb: rsb at 1f03400 {
>> + compatible = "allwinner,sun8i-a23-rsb";
>> + reg = <0x01f03400 0x400>;
>> + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&r_ccu 6>;
>
> Please use the defines here..
Linux-4.12 doesn't yet enter rc1, and the defines are still not in
Linus's tree.
Please note that I have already mentioned that this patch is necessary
to be merged into 4.12, otherwise poweroff won't work properly at 4.12 .
So I think it shouldn't still use defines.
I will fix here after 4.12-rc1 is out, along with other r_ccu
usages.
>
>> + clock-frequency = <3000000>;
>> + resets = <&r_ccu 2>;
>
> And here.
>
> Thanks!
> Maxime
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox