* [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Martin Blumenstingl @ 2016-11-24 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480002964.17538.131.camel@baylibre.com>
On Thu, Nov 24, 2016 at 4:56 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Thu, 2016-11-24 at 15:34 +0100, Martin Blumenstingl wrote:
>> Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
>> cycle TX clock delay. This seems to work fine for many boards (for
>> example Odroid-C2 or Amlogic's reference boards) but there are some
>> others where TX traffic is simply broken.
>> There are probably multiple reasons why it's working on some boards
>> while it's broken on others:
>> - some of Amlogic's reference boards are using a Micrel PHY
>> - hardware circuit design
>> - maybe more...
>>
>> This raises a question though:
>> Which device is supposed to enable the TX delay when both MAC and PHY
>> support it? And should we implement it for each PHY / MAC separately
>> or should we think about a more generic solution (currently it's not
>> possible to disable the TX delay generated by the RTL8211F PHY via
>> devicetree when using phy-mode "rgmii")?
>
> Actually you can skip the part which activate the Tx-delay on the phy
> by setting "phy-mode = "rgmii-id" instead of "rgmii"
>
> phy->interface will no longer be PHY_INTERFACE_MODE_RGMII
> but PHY_INTERFACE_MODE_RGMII_ID.
unfortunately this is not true for RTL8211F (I did my previous tests
with the same expectation in mind)!
the code seems to suggest that TX-delay is disabled whenever mode !=
PHY_INTERFACE_MODE_RGMII.
BUT: on my device RTL8211F_TX_DELAY is set even before
"phy_write(phydev, 0x11, reg);"!
Based on what I found it seems that rgmii-id, rgmii-txid and
rgmii-rxid are supposed to be handled by the PHY.
That would mean that we have two problems here:
1) drivers/net/phy/realtek.c:rtl8211f_config_init should check for
PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID and
enable the TX-delay in that case - otherwise explicitly disable it
2) dwmac-meson8b.c should only use the configured TX-delay for
PHY_INTERFACE_MODE_RGMII
@Florian: could you please share your thoughts on this (who handles
the TX delay in which case)?
Regards,
Martin
^ permalink raw reply
* [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue
From: Martin Blumenstingl @ 2016-11-24 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480003306.17538.137.camel@baylibre.com>
On Thu, Nov 24, 2016 at 5:01 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Thu, 2016-11-24 at 15:40 +0100, Martin Blumenstingl wrote:
>> Hi Jerome,
>>
>> On Mon, Nov 21, 2016 at 4:35 PM, Jerome Brunet <jbrunet@baylibre.com>
>> wrote:
>> >
>> > This patchset fixes an issue with the OdroidC2 board (DWMAC +
>> > RTL8211F).
>> > Initially reported as a low Tx throughput issue at gigabit speed,
>> > the
>> > platform enters LPI too often. This eventually break the link (both
>> > Tx
>> > and Rx), and require to bring the interface down and up again to
>> > get the
>> > Rx path working again.
>> >
>> > The root cause of this issue is not fully understood yet but
>> > disabling EEE
>> > advertisement on the PHY prevent this feature to be negotiated.
>> > With this change, the link is stable and reliable, with the
>> > expected
>> > throughput performance.
>> I have just sent a series which allows configuring the TX delay on
>> the
>> MAC (dwmac-meson8b glue) side: [0]
>> Disabling the TX delay generated by the MAC fixes TX throughput for
>> me, even when leaving EEE enabled in the RTL8211F PHY driver!
>>
>> Unfortunately the RTL8211F PHY is a black-box for the community
>> because there is no public datasheeet available.
>> *maybe* (pure speculation!) they're enabling the TX delay based on
>> some internal magic only when EEE is enabled.
>
> Hi already tried acting on the register setting the TX_delay. I also
> tried on the PHY. I never been able to improve situation on the
> Odroic2. Only disabling EEE improved the situation.
OK, thanks for clarifying this!
> To make sure, i tried again with your patch but the result remains
> unchanged. With Tx_delay disabled (either the mac or the phy), the
> situation is even worse, it seems that nothing gets through
This is interesting, because in your case you should have a 4ns TX
delay (2ns from the MAC and presumably 2ns from the PHY).
Maybe that is also the reason why the TX delay is configurable in 2ns
steps in PRG_ETHERNET0 on Amlogic SoCs.
out of curiosity: have you tried setting a 4ns (half clock-cycle) TX
delay for the MAC and disabling it in the PHY?
Regards,
Martin
^ permalink raw reply
* [PATCH 0/3] arm64: dts: r8a7796: Add CAN/CAN FD support
From: Chris Paterson @ 2016-11-24 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXO=uFuJCXPjkdYB_CeyfPMqy6cMrOW=s1DZzcJ9Gp33A@mail.gmail.com>
Hello Geert,
From: geert.uytterhoeven@gmail.com
Sent: 24 November 2016 16:42
> Hi Chris,
>
> On Thu, Nov 24, 2016 at 3:25 PM, Chris Paterson
> <Chris.Paterson2@renesas.com> wrote:
> > From: Simon Horman [mailto:horms at verge.net.au]
> > Sent: 24 November 2016 10:18
> >> On Thu, Nov 24, 2016 at 10:05:08AM +0000, Chris Paterson wrote:
> >> > From: Simon Horman [mailto:horms at verge.net.au]
> >> > > Regarding the arch/arm64/boot/dts/renesas/ portion, I would like
> >> > > some consideration given to what effect enabling memory above 4Gb
> >> > > (64bit
> >> > > addressing) would have.
> >> >
> >> > Can you give me some guidance here? I'm not sure what you're
> >> > referring to. As far as I know the DT reg definition here is
> >> > 64-bit, or are you referring to DMA usage? If the later, neither CAN
> driver uses DMA.
> >>
> >> Sorry for not being clearer.
> >>
> >> What I would like to know is if there are any problems in the CAN
> >> driver or hardware that would prevent it from functioning with memory
> >> that requires 64bit addressing present.
> >>
> >> If the CAN hardware cannot use DMA then DMA doesn't need to be
> taken
> >> into account. But if it DMA could be enabled in future for CAN, for
> >> example after some driver enhancements, then it would be good to know
> >> if 64bit memory can be supported - if not it would imply DMA cannot be
> enabled.
> >
> > Thank you for the clarification.
> >
> > The CAN interface for r8a7795/6 does not support DMA.
> >
> > With CAN FD there is currently a H/W issue that means DMA is unusable.
>
> Is that issue present on R-Car M3-W, or only on R-Car H3 ES1.x?
Both
>
> > Potentially this issue could be fixed in the future and DMA support
> > could be added to the driver. If this happens I can see no reason why
> > the CAN FD IP wouldn't be able to handle DMA transfers when using 64bit
> addressing.
>
> Yep, AFAIK it uses SYS-DMAC, which supports 64-bit addressing.
Yep
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-
> m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* [PATCH v28 9/9] Documentation: dt: chosen properties for arm64 kdump
From: Catalin Marinas @ 2016-11-24 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124095944.7167-1-takahiro.akashi@linaro.org>
On Thu, Nov 24, 2016 at 06:59:44PM +0900, AKASHI Takahiro wrote:
> From: James Morse <james.morse@arm.com>
>
> Add documentation for
> linux,crashkernel-base and crashkernel-size,
> linux,usable-memory-range
> linux,elfcorehdr
> used by arm64 kdump to decribe the kdump reserved area, and
> the elfcorehdr's location within it.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> [takahiro.akashi at linaro.org: added "linux,crashkernel-base" and "-size" ]
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: devicetree at vger.kernel.org
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
Rob, Mark, are you ok with this patch?
--
Catalin
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Afzal Mohammed @ 2016-11-24 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123191621.GD14217@n2100.armlinux.org.uk>
Hi,
On Wed, Nov 23, 2016 at 07:16:21PM +0000, Russell King - ARM Linux wrote:
> Well, !MMU and multiplatform _are_ exclusive in reality. One of the
> things we work around in multiplatform is the different physical
> address space layouts of the platforms, particularly with where RAM
> is located. That's not possible in !MMU configurations. A kernel
> built to support every platform in multiplatform will not boot on
> most of them.
>
> So efforts to make !MMU work with multiplatform are IMHO rather
> misguided.
>
> !MMU makes sense with classifications of systems (like the Cortex-M*
> based systems) but not everything.
Okay, seems you were referring to AUTO_ZRELADDR or if you had
something else in mind, please let me know.
The plan was to use Image instead of zImage. Here there are 2
platforms, Freescale's, oh no, NXP's, oh no no, Qualcomm's Vybrid
(vf610) and TI's Sitara siblings (am335x beagle & am437x). It was
thought that though changes might have to be made b/n them, at least
it might be easier using same defconfig, thus went by multi_v7.
Though have been able to build for !MMU, have not yet been successful
in seeing any activity on the console, probably will have to put
printascii() into service.
Regards
afzal
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Afzal Mohammed @ 2016-11-24 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5835BEBA.8050905@arm.com>
Hi,
On Wed, Nov 23, 2016 at 04:07:22PM +0000, Vladimir Murzin wrote:
> I think this one is fixed by
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 8e7496c..c3349b9 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -2019,7 +2019,7 @@ config XIP_PHYS_ADDR
> config KEXEC
> bool "Kexec system call (EXPERIMENTAL)"
> depends on (!SMP || PM_SLEEP_SMP)
> - depends on !CPU_V7M
> + depends on MMU
> These we fixed in 9001214 ("ARM: imx: no need to select SMP_ON_UP explicitly")
> Thanks for trying it. Just a gentle remainder not to forget to set DRAM_BASE
> and DRAM_SIZE ;)
Thanks for the info.
Based on your feedback, have been able to build multi_v7 w/ MMU & SMP
disabled.
Trying to get something in the console on Cortex A platform.
Regards
afzal
^ permalink raw reply
* [PATCH 4/4] crypto: arm/crct10dif - port x86 SSE implementation to ARM
From: Ard Biesheuvel @ 2016-11-24 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480002201-1427-5-git-send-email-ard.biesheuvel@linaro.org>
On 24 November 2016 at 15:43, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> This is a straight transliteration of the Intel algorithm implemented
> using SSE and PCLMULQDQ instructions that resides under in the file
> arch/x86/crypto/crct10dif-pcl-asm_64.S.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm/crypto/Kconfig | 5 +
> arch/arm/crypto/Makefile | 2 +
> arch/{arm64 => arm}/crypto/crct10dif-ce-core.S | 457 +++++++++++---------
> arch/{arm64 => arm}/crypto/crct10dif-ce-glue.c | 23 +-
> 4 files changed, 277 insertions(+), 210 deletions(-)
>
This patch needs the following hunk folded in to avoid breaking the
Thumb2 build:
"""
diff --git a/arch/arm/crypto/crct10dif-ce-core.S
b/arch/arm/crypto/crct10dif-ce-core.S
index 30168b0f8581..4fdbca94dd0c 100644
--- a/arch/arm/crypto/crct10dif-ce-core.S
+++ b/arch/arm/crypto/crct10dif-ce-core.S
@@ -152,7 +152,8 @@ CPU_LE( vrev64.8 q7, q7 )
// XOR the initial_crc value
veor.8 q0, q0, q10
- adrl ip, rk3
+ARM( adrl ip, rk3 )
+THUMB( adr ip, rk3 )
vld1.64 {q10}, [ip] // xmm10 has rk3 and rk4
// type of pmull instruction
// will determine which constant to use
"""
Updated patch(es) can be found here
https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git/log/?h=arm-crct10dif
^ permalink raw reply related
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Vladimir Murzin @ 2016-11-24 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124172826.GB3524@afzalpc>
On 24/11/16 17:28, Afzal Mohammed wrote:
> Hi,
>
> On Wed, Nov 23, 2016 at 04:07:22PM +0000, Vladimir Murzin wrote:
>
>> I think this one is fixed by
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 8e7496c..c3349b9 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -2019,7 +2019,7 @@ config XIP_PHYS_ADDR
>> config KEXEC
>> bool "Kexec system call (EXPERIMENTAL)"
>> depends on (!SMP || PM_SLEEP_SMP)
>> - depends on !CPU_V7M
>> + depends on MMU
>
>> These we fixed in 9001214 ("ARM: imx: no need to select SMP_ON_UP explicitly")
>
>> Thanks for trying it. Just a gentle remainder not to forget to set DRAM_BASE
>> and DRAM_SIZE ;)
>
> Thanks for the info.
>
> Based on your feedback, have been able to build multi_v7 w/ MMU & SMP
> disabled.
>
> Trying to get something in the console on Cortex A platform.
Make sure you have ARM_MPU disabled, otherwise it will die early (I keep
proper patch for that here).
Cheers
Vladimir
>
> Regards
> afzal
>
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Russell King - ARM Linux @ 2016-11-24 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124172535.GA3524@afzalpc>
On Thu, Nov 24, 2016 at 10:55:35PM +0530, Afzal Mohammed wrote:
> Hi,
>
> On Wed, Nov 23, 2016 at 07:16:21PM +0000, Russell King - ARM Linux wrote:
>
> > Well, !MMU and multiplatform _are_ exclusive in reality. One of the
> > things we work around in multiplatform is the different physical
> > address space layouts of the platforms, particularly with where RAM
> > is located. That's not possible in !MMU configurations. A kernel
> > built to support every platform in multiplatform will not boot on
> > most of them.
> >
> > So efforts to make !MMU work with multiplatform are IMHO rather
> > misguided.
> >
> > !MMU makes sense with classifications of systems (like the Cortex-M*
> > based systems) but not everything.
>
> Okay, seems you were referring to AUTO_ZRELADDR or if you had
> something else in mind, please let me know.
No, I'm talking about the kernel proper itself.
> The plan was to use Image instead of zImage. Here there are 2
> platforms, Freescale's, oh no, NXP's, oh no no, Qualcomm's Vybrid
> (vf610) and TI's Sitara siblings (am335x beagle & am437x).
Right, so Freescale's iMX6, RAM starts at 0x10000000, so when building
for noMMU, you need to specify DRAM_START as 0x10000000 and DRAM_SIZE
to be the appropriate size of RAM.
You'll be able to run the same "Image" kernel on the other platforms
_if_ and _only_ _if_ they have RAM covering the same region.
That's my point - the kernel image will be linked to place its
read-write data at a certain location in the address space, and if
you have the MMU disabled (or in 1:1 translation mode) you _must_
have RAM at that location.
The reason multiplatform works is because we use the MMU to abstract
away the differences in the location of RAM on the platform (amongst
other things.)
Also note that Cortex-A class CPUs don't perform well with the MMU
off, because you can't enable the data cache - and you must have the
data cache enabled for SMP to be functional, and it's also required
for exclusives to work.
There's also some cases where "Device, non-shared" must be used to
access some devices, which can only be done with the MMU enabled.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [RFC PATCH 09/11] ARM: NOMMU: define SECTION_xxx macros
From: Vladimir Murzin @ 2016-11-24 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58347A61.306@arm.com>
On 22/11/16 17:03, Vladimir Murzin wrote:
> On 22/11/16 11:54, Russell King - ARM Linux wrote:
>> On Tue, Nov 22, 2016 at 11:50:57AM +0000, Vladimir Murzin wrote:
>>> On 22/11/16 10:07, Russell King - ARM Linux wrote:
>>>> On Tue, Nov 22, 2016 at 09:26:06AM +0000, Vladimir Murzin wrote:
>>>>> Pickup defines from pgtable-2level.h to make NOMMU build happy.
>>>>
>>>> This needs more detail.
>>>>
>>>
>>> It comes from
>>>
>>> CC arch/arm/kernel/setup.o
>>> arch/arm/kernel/setup.c: In function 'reserve_crashkernel':
>>> arch/arm/kernel/setup.c:1001:25: error: 'SECTION_SIZE' undeclared (first use in this function)
>>> crash_size, SECTION_SIZE);
>>> ^
>>> arch/arm/kernel/setup.c:1001:25: note: each undeclared identifier is reported only once for each function it appears in
>>> make[1]: *** [arch/arm/kernel/setup.o] Error 1
>>> make: *** [arch/arm/kernel] Error 2
>>
>> Hmm, I decided not to use CRASH_ALIGN there because I didn't want to
>> break anyone's existing setup unnecessarily, however arguably it
>> should be CRASH_ALIGN to ensure that the new kernel is properly
>> positioned.
>>
>> I wonder if we can get away with changing that, rather than
>> unnecessarily introducing these otherwise meaningless definitions
>> for R-class.
>>
>
> CRASH_ALIGN works fine but it seems not only user of SECTION_SIZE
>
> In file included from ./include/linux/cache.h:4:0,
> from ./include/linux/printk.h:8,
> from ./include/linux/kernel.h:13,
> from arch/arm/mach-omap2/omap-secure.c:15:
> arch/arm/mach-omap2/omap-secure.c: In function 'omap_secure_ram_reserve_memblock':
> arch/arm/mach-omap2/omap-secure.c:65:21: error: 'SECTION_SIZE' undeclared (first use in this function)
> size = ALIGN(size, SECTION_SIZE);
> ^
> ./include/uapi/linux/kernel.h:10:47: note: in definition of macro '__ALIGN_KERNEL_MASK'
> #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
> ^
> ./include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
> #define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
> ^
> arch/arm/mach-omap2/omap-secure.c:65:9: note: in expansion of macro 'ALIGN'
> size = ALIGN(size, SECTION_SIZE);
> ^
> arch/arm/mach-omap2/omap-secure.c:65:21: note: each undeclared identifier is reported only once for each function it appears in
> size = ALIGN(size, SECTION_SIZE);
> ^
> ./include/uapi/linux/kernel.h:10:47: note: in definition of macro '__ALIGN_KERNEL_MASK'
> #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask))
> ^
> ./include/linux/kernel.h:48:22: note: in expansion of macro '__ALIGN_KERNEL'
> #define ALIGN(x, a) __ALIGN_KERNEL((x), (a))
> ^
> arch/arm/mach-omap2/omap-secure.c:65:9: note: in expansion of macro 'ALIGN'
> size = ALIGN(size, SECTION_SIZE);
> ^
> make[1]: *** [arch/arm/mach-omap2/omap-secure.o] Error 1
Russell, do you have further comment on this? I would try to address them in
the next version.
Thanks!
Vladimir
>
> Cheers
> Vladimir
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [RFC PATCH 06/11] ARM: tlbflush: drop dependency on CONFIG_SMP
From: Vladimir Murzin @ 2016-11-24 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <583449F9.6060804@arm.com>
On 22/11/16 13:36, Vladimir Murzin wrote:
> On 22/11/16 10:03, Russell King - ARM Linux wrote:
>> On Tue, Nov 22, 2016 at 09:26:03AM +0000, Vladimir Murzin wrote:
>>> It can be referenced in UP case as well.
>>
>> What's missing is an explanation of why you want this change.
>> Exposing the local_* stuff doesn't make sense for UP.
>
> It comes from:
>
> arch/arm/mach-mvebu/pmsu.c: In function 'armada_370_xp_pmsu_idle_enter':
> arch/arm/mach-mvebu/pmsu.c:291:2: error: implicit declaration of function 'local_flush_tlb_all' [-Werror=implicit-function-declaration]
> local_flush_tlb_all();
> ^
>
> make[1]: *** [arch/arm/mach-mvebu/pmsu.o] Error 1
>
> and
>
> arch/arm/mach-imx/pm-imx5.c: In function 'mx5_suspend_enter':
> arch/arm/mach-imx/pm-imx5.c:227:3: error: implicit declaration of function 'local_flush_tlb_all' [-Werror=implicit-function-declaration]
>
> local_flush_tlb_all();
> ^
> cc1: some warnings being treated as errors
> make[1]: *** [arch/arm/mach-imx/pm-imx5.o] Error 1
>
> Maybe there are other users, please, let me know if you want me to count them
> all.
Russell, is it a good argument to expose the local_* stuff or it should be
addressed differently?
Thanks
Vladimir
>
> Cheers
> Vladimir
>
>>
>>> Cc: Russell King <linux@armlinux.org.uk>
>>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>>> ---
>>> arch/arm/include/asm/tlbflush.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
>>> index def9e57..d9a6e2e 100644
>>> --- a/arch/arm/include/asm/tlbflush.h
>>> +++ b/arch/arm/include/asm/tlbflush.h
>>> @@ -641,7 +641,7 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
>>>
>>> #endif
>>>
>>> -#elif defined(CONFIG_SMP) /* !CONFIG_MMU */
>>> +#else /* !CONFIG_MMU */
>>>
>>> #ifndef __ASSEMBLY__
>>>
>>> --
>>> 1.7.9.5
>>>
>>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Afzal Mohammed @ 2016-11-24 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124173532.GH14217@n2100.armlinux.org.uk>
Hi,
On Thu, Nov 24, 2016 at 05:35:32PM +0000, Russell King - ARM Linux wrote:
> Right, so Freescale's iMX6, RAM starts at 0x10000000, so when building
> for noMMU, you need to specify DRAM_START as 0x10000000 and DRAM_SIZE
> to be the appropriate size of RAM.
Hmm.., i had thought that Vybrid's memory mappings starts from
0x80000000 (same TI Sitara's), just rechecked the older boot logs of
Vybrid & Data manual, it seems it is @0x80000000, probably iMX6 has a
different map.
> Also note that Cortex-A class CPUs don't perform well with the MMU
> off, because you can't enable the data cache - and you must have the
> data cache enabled for SMP to be functional, and it's also required
> for exclusives to work.
Yes, was aware of the performance degradation due to disabled dcache.
Here the platforms at my disposal are all single core - vf610, am335x
& am437x (though strictly speaking 2 of them are ARM SMP
configurations, but with number of cores as 1). Seems at least from
SMP pov, not expecting issues as they are single core (SMP disabled
kernel with MMU enabled works on those)
> There's also some cases where "Device, non-shared" must be used to
> access some devices, which can only be done with the MMU enabled.
Thanks for your valuable feedbacks.
Regards
afzal
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Afzal Mohammed @ 2016-11-24 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5837246D.5080106@arm.com>
Hi,
On Thu, Nov 24, 2016 at 05:33:33PM +0000, Vladimir Murzin wrote:
> Make sure you have ARM_MPU disabled, otherwise it will die early (I keep
> proper patch for that here).
Hmm.., thanks, that is enabled here, will disable it & proceed.
Regards
afzal
^ permalink raw reply
* [PATCH 9/9] arm64: Documentation - Expose CPU feature registers
From: Catalin Marinas @ 2016-11-24 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479994809-9081-10-git-send-email-suzuki.poulose@arm.com>
Hi Suzuki,
On Thu, Nov 24, 2016 at 01:40:09PM +0000, Suzuki K. Poulose wrote:
> --- /dev/null
> +++ b/Documentation/arm64/cpu-feature-registers.txt
> @@ -0,0 +1,198 @@
> + ARM64 CPU Feature Registers
> + ===========================
> +
> +Author: Suzuki K Poulose <suzuki.poulose@arm.com>
> +
> +
> +This file describes the API for exporting the AArch64 CPU ID/feature
> +registers to userspace. The availability of this API is advertised
> +via the HWCAP_CPUID in HWCAPs.
s/API/ABI/ maybe?
> +
> +1. Motivation
> +---------------
> +
> +The ARM architecture defines a set of feature registers, which describe
> +the capabilities of the CPU/system. Access to these system registers is
> +restricted from EL0 and there is no reliable way for an application to
> +extract this information to make better decisions at runtime. There is
> +limited information available to the application via HWCAPs, however
> +there are some issues with their usage.
> +
> + a) Any change to the HWCAPs requires an update to userspace (e.g libc)
> + to detect the new changes, which can take a long time to appear in
> + distributions. Exposing the registers allows applications to get the
> + information without requiring updates to the toolchains.
> +
> + b) Access to HWCAPs is sometimes limited (e.g prior to libc, or
> + when ld is initialised at startup time).
> +
> + c) HWCAPs cannot represent non-boolean information effectively. The
> + architecture defines a canonical format for representing features
> + in the ID registers; this is well defined and is capable of
> + representing all valid architecture variations. Exposing the ID
> + registers avoids having to come up with HWCAP representations and
> + parsing code.
For point (c) above, we don't (yet?) have an actual case on AArch64
where HWCAP needs more than a boolean value.
And just to clarify my position: I consider that we should continue to
expose HWCAP for new features (e.g. SVE) in parallel with the CPUID
access emulation. There are different use-cases for them (i.e. dynamic
loader uses HWCAP for the ifunc resolver).
> +3. Implementation
> +--------------------
> +
> +The infrastructure is built on the emulation of the 'MRS' instruction.
> +Accessing a restricted system register from an application generates an
> +exception and ends up in SIGILL being delivered to the process.
> +The infrastructure hooks into the exception handler and emulates the
> +operation if the source belongs to the supported system register space.
> +
> +The infrastructure emulates only the following system register space:
> + Op0=3, Op1=0, CRn=0
> +
> +(See Table C5-6 'System instruction encodings for non-Debug System
> +register accesses' in ARMv8 ARM DDI 0487A.h, for the list of
> +registers).
> +
> +
> +The following rules are applied to the value returned by the
> +infrastructure:
> +
> + a) The value of an 'IMPLEMENTATION DEFINED' field is set to 0.
> + b) The value of a reserved field is populated with the reserved
> + value as defined by the architecture.
> + c) The value of a field marked as not 'visible', is set to indicate
> + the feature is missing (as defined by the architecture).
I don't understand point (c) above. If it is marked as not 'visible', it
is always reported to user as 0. The above could be misinterpreted as
reporting missing architecture features.
[...]
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 94c188f..fb331de 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -81,6 +81,10 @@ static bool __maybe_unused
> cpufeature_pan_not_uao(const struct arm64_cpu_capabilities *entry, int __unused);
>
>
> +/*
> + * NOTE: Any changes to the visibility of features should be kept in
> + * sync with the documentation of the CPU feature register API.
s/API/ABI/
--
Catalin
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Russell King - ARM Linux @ 2016-11-24 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124180751.GA5258@afzalpc>
On Thu, Nov 24, 2016 at 11:37:51PM +0530, Afzal Mohammed wrote:
> Hi,
>
> On Thu, Nov 24, 2016 at 05:35:32PM +0000, Russell King - ARM Linux wrote:
>
> > Right, so Freescale's iMX6, RAM starts at 0x10000000, so when building
> > for noMMU, you need to specify DRAM_START as 0x10000000 and DRAM_SIZE
> > to be the appropriate size of RAM.
>
> Hmm.., i had thought that Vybrid's memory mappings starts from
> 0x80000000 (same TI Sitara's), just rechecked the older boot logs of
> Vybrid & Data manual, it seems it is @0x80000000, probably iMX6 has a
> different map.
Right, so if you build a multiplatform kernel which covers TI Sitara
and iMX6, then you have a choice:
- Set DRAM_START to 0x10000000, and have a kernel which will boot on
iMX6 but fail on TI Sitara.
- Set DRAM_START to 0x80000000, and have a kernel which will boot on
TI Sitara, but fail on iMX6 with less than 2GiB of memory (0x70000000
bytes to be exact.)
This is why multiplatform doesn't make sense for noMMU - you can't
actually build a multiplatform kernel that will work across all
these platforms.
You'd have to re-link it (at the very least) to place the data section
elsewhere in physical memory to make it work.
It's this reason that I don't like removing the "depends on MMU" from
multiplatform - it gives the incorrect impression that we _can_ support
a wide range of systems, but what it will lead to is a kernel that will
work on some platforms but not others. The result will be more "bug"
reports because the kernel fails to boot...
In any case, I think kernelci and similar would first need to be updated
to avoid trying to boot noMMU kernels on hardware which it just can't
boot on - we _really_ do not want to be randomly scribbling into physical
memory, potentially hitting devices, especially with devices that contain
OTP fuses that set options as security features.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Florian Fainelli @ 2016-11-24 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCB7sXjXor++W+PW0-j_VxATRzhexjqHgXj2jD10tBpZFg@mail.gmail.com>
Le 24/11/2016 ? 09:05, Martin Blumenstingl a ?crit :
> On Thu, Nov 24, 2016 at 4:56 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
>> On Thu, 2016-11-24 at 15:34 +0100, Martin Blumenstingl wrote:
>>> Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
>>> cycle TX clock delay. This seems to work fine for many boards (for
>>> example Odroid-C2 or Amlogic's reference boards) but there are some
>>> others where TX traffic is simply broken.
>>> There are probably multiple reasons why it's working on some boards
>>> while it's broken on others:
>>> - some of Amlogic's reference boards are using a Micrel PHY
>>> - hardware circuit design
>>> - maybe more...
>>>
>>> This raises a question though:
>>> Which device is supposed to enable the TX delay when both MAC and PHY
>>> support it? And should we implement it for each PHY / MAC separately
>>> or should we think about a more generic solution (currently it's not
>>> possible to disable the TX delay generated by the RTL8211F PHY via
>>> devicetree when using phy-mode "rgmii")?
>>
>> Actually you can skip the part which activate the Tx-delay on the phy
>> by setting "phy-mode = "rgmii-id" instead of "rgmii"
>>
>> phy->interface will no longer be PHY_INTERFACE_MODE_RGMII
>> but PHY_INTERFACE_MODE_RGMII_ID.
> unfortunately this is not true for RTL8211F (I did my previous tests
> with the same expectation in mind)!
> the code seems to suggest that TX-delay is disabled whenever mode !=
> PHY_INTERFACE_MODE_RGMII.
> BUT: on my device RTL8211F_TX_DELAY is set even before
> "phy_write(phydev, 0x11, reg);"!
(Adding Sebastian (and Mans, and Andrew) since he raised the same
question a while ago. I think I now understand a bit better what
Sebastian was after a couple of weeks ago)
>
> Based on what I found it seems that rgmii-id, rgmii-txid and
> rgmii-rxid are supposed to be handled by the PHY.
Correct, the meaning of PHY_INTERFACE_MODE should be from the
perspective of the PHY device:
- PHY_INTERFACE_MODE_RGMII_TXID means that the PHY is responsible for
adding a delay when the MAC transmits (TX MAC -> PHY (delay) -> wire)
- PHY_INTERFACE_MODE_RGMII_RXID means that the PHY is responsible for
adding a delay when the MAC receives (RX MAC <- (delay) PHY) <- wire)
> That would mean that we have two problems here:
> 1) drivers/net/phy/realtek.c:rtl8211f_config_init should check for
> PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID and
> enable the TX-delay in that case - otherwise explicitly disable it
Agreed.
> 2) dwmac-meson8b.c should only use the configured TX-delay for
> PHY_INTERFACE_MODE_RGMII
> @Florian: could you please share your thoughts on this (who handles
> the TX delay in which case)?
This also seems reasonable to do, provided that the PHY is also properly
configured not to add delays in both directions, and therefore assumes
that the MAC does it.
We have a fairly large problem with how RGMII delays are done in PHYLIB
and Ethernet MAC drivers (or just in general), where we can't really
intersect properly what a PHY is supporting (in terms of internal
delays), and what the MAC supports either. One possible approach could
be to update PHY drivers a list of PHY_INTERFACE_MODE_* that they
support (ideally, even with normalized nanosecond delay values), and
then intersect that with the requested phy_interface_t during
phy_{attach,connect} time, and feed this back to the MAC with a special
error code/callback, so we could gracefully try to choose another
PHY_INTERFACE_MODE_* value that the MAC supports....
A larger problem is that a number of drivers have been deployed, and
Device Trees, possibly with the meaning of "phy-mode" and
"phy-connection-type" being from the MAC perspective, and not the PHY
perspective *sigh*, good luck auditing those.
So from there, here is possibly what we could do
- submit a series of patches that update the PHYLIB documentation (there
are other things missing here) and make it clear from which entity (PHY
or MAC) does the delay apply to, document the "intersection" problem here
- have you document the configured behavior for dwmac-meson8b that we
just discussed here in v2 of this patch series
Sorry for the long post, here is a virtual potato: 0
--
Florian
^ permalink raw reply
* [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible
From: Florian Fainelli @ 2016-11-24 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8760ncly5s.fsf@free-electrons.com>
Le 24/11/2016 ? 07:01, Gregory CLEMENT a ?crit :
> Hi Arnd,
>
> On jeu., nov. 24 2016, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Thursday, November 24, 2016 4:37:36 PM CET Jisheng Zhang wrote:
>>> solB (a SW shadow cookie) perhaps gives a better performance: in hot path,
>>> such as mvneta_rx(), the driver accesses buf_cookie and buf_phys_addr of
>>> rx_desc which is allocated by dma_alloc_coherent, it's noncacheable if the
>>> device isn't cache-coherent. I didn't measure the performance difference,
>>> because in fact we take solA as well internally. From your experience,
>>> can the performance gain deserve the complex code?
>>
>> Yes, a read from uncached memory is fairly slow, so if you have a chance
>> to avoid that it will probably help. When adding complexity to the code,
>> it probably makes sense to take a runtime profile anyway quantify how
>> much it gains.
>>
>> On machines that have cache-coherent DMA, accessing the descriptor
>> should be fine, as you already have to load the entire cache line
>> to read the status field.
>>
>> Looking at this snippet:
>>
>> rx_status = rx_desc->status;
>> rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE);
>> data = (unsigned char *)rx_desc->buf_cookie;
>> phys_addr = rx_desc->buf_phys_addr;
>> pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc);
>> bm_pool = &pp->bm_priv->bm_pools[pool_id];
>>
>> if (!mvneta_rxq_desc_is_first_last(rx_status) ||
>> (rx_status & MVNETA_RXD_ERR_SUMMARY)) {
>> err_drop_frame_ret_pool:
>> /* Return the buffer to the pool */
>> mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool,
>> rx_desc->buf_phys_addr);
>> err_drop_frame:
>>
>>
>> I think there is more room for optimizing if you start: you read
>> the status field twice (the second one in MVNETA_RX_GET_BM_POOL_ID)
>> and you can cache the buf_phys_addr along with the virtual address
>> once you add that.
>
> I agree we can optimize this code but it is not related to the 64 bits
> conversion. Indeed this part is running when we use the HW buffer
> management, however currently this part is not ready at all for 64
> bits. The virtual address is directly handled by the hardware but it has
> only 32 bits to store it in the cookie.So if we want to use the HWBM in
> 64 bits we need to redesign the code, (maybe by storing the virtual
> address in a array and pass the index in the cookie).
Can't you make sure that skb->data is aligned to a value big enough that
you can still cover the <N> bit physical address space of the adapter
within a 32-bit quantity if you drop the low bits that would be all zeroes?
That way, even though you only have 32-bits of storage/cookie, these
don't have to be the actual 32-bits of your original address, but could
be addr >> 8 for instance?
As you indicate using an index stored in the cookie might be a better
scheme though, since you could attach a lot more metadata to an index in
an local array (which could be in cached memory) as opposed to just an
address.
--
Florian
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Robin Murphy @ 2016-11-24 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <004401d2466d$5b8b2170$12a16450$@codeaurora.org>
On 24/11/16 16:10, Sricharan wrote:
> Hi Robin,
>
> <snip..>
>
>>
>>>>>>> iommu_group_get_for_dev which gets called in the add_device
>>>>>>> callback, increases the reference count of the iommu_group,
>>>>>>> so we do an iommu_group_put after that. iommu_group_get_for_dev
>>>>>>> inturn calls device_group callback and in the case of arm-smmu
>>>>>>> we call generic_device_group/pci_device_group which takes
>>>>>>> care of increasing the group's reference. But when we return
>>>>>>> an already existing group(when multiple devices have same group)
>>>>>>> the reference is not incremented, resulting in issues when the
>>>>>>> remove_device callback for the devices is invoked.
>>>>>>> Fixing the same here.
>>>>>>
>>>>>> Bah, yes, this does look like my fault - after flip-flopping between
>>>>>> about 3 different ways to keep refcounts for the S2CR entries, none of
>>>>>> which would quite work, I ripped it all out but apparently still got
>>>>>> things wrong, oh well. Thanks for figuring it out.
>>>>>>
>>>>>> On the probe-deferral angle, whilst it's useful to have uncovered this
>>>>>> bug, I don't think we should actually be calling remove_device() from
>>>>>> DMA teardown. I think it's preferable from a user perspective if group
>>>>>> numbering remains stable, rather than changing depending on the order in
>>>>>> which they unbind/rebind VFIO drivers. I'm really keen to try and get
>>>>>> this in shape for 4.10, so I've taken the liberty of hacking up my own
>>>>>> branch (iommu/defer) based on v3 - would you mind taking a look at the
>>>>>> two "iommu/of:" commits to see what you think? (Ignore the PCI changes
>>>>>> to your later patches - that was an experiment which didn't really work out)
>>>>>
>>>>> Ok, will take a look at this now and respond more on this.
>>>>>
>>>> Sorry for the delayed response on this. I was OOO for the last few days.
>>>> So i tested this branch and it worked fine. I tested it with a pci device
>>>> for both normal and deferred probe cases. The of/iommu patches
>>>> are the cleanup/preparation patches and it looks fine. One thing is without
>>>> calling the remove_device callback, the resources like (smes for exmaple)
>>>> and the group association of the device all remain allocated. That does not
>>>> feel correct, given that the associated device does not exist. So to
>>>> understand that, what happens with VFIO in this case which makes the
>>>> group renumbering/rebinding a problem ?
>>>>
>>>
>>> Would it be ok if i post a V4 based on your branch above ?
>>
>> Sure, as long as none of the hacks slip through :) - I've just pushed
>> out a mild rework based on Lorenzo's v9, which I hope shouldn't break
>> anything for you.
>>
>
> Ok sure, i will test and just the post out the stuff from your branch then
> mostly by tomorrow.
Cool. We're rather hoping that the ACPI stuff is good to go for 4.10
now, so it's probably worth pulling the rest of that in (beyond the one
patch I picked) to make sure the of_dma_configure/acpi_dma_configure
paths don't inadvertently diverge.
>> Having thought a bit more about the add/remove thing, I'm inclined to
>> agree that the group numbering itself may not be that big an issue in
>> practice - sure, it could break my little script, but it looks like QEMU
>> and such work with the device ID rather than the group number directly,
>> so might not even notice. However, the fact remains that the callbacks
>> are intended to handle a device being added to/removed from its bus, and
>> will continue to do so on other platforms, so I don't like the idea of
>> introducing needlessly different behaviour. If you unbind a driver, the
>> stream IDs and everything don't stop existing at the hardware level; the
>> struct device to which the in-kernel data belongs still exists and
>> doesn't stop being associated with its bus. There's no good reason for
>> freeing SMEs that we'll only reallocate again (inadequately-specced
>> hardware with not enough SMRs/contexts is not a *good* reason), and
>
> ok, so SMRs/contexts was the reason i was adding the remove_dev
> callback, but if thats not good enough then there was no other
> intention.
>
>> there are also some strong arguments against letting any stream IDs the
>> kernel knows about go back to bypass after a driver has been bound - by
>
> ok, but not sure why is this so ?
Any device the kernel is in control of, having bound a driver to it,
definitely should not be doing DMA after that driver is unbound...
>> keeping groups around as expected that's something we can implement
>> quite easily without having to completely lock down bypass for stream
>> IDs the kernel *doesn't* know about.
>>
>
> So do you mean in this case to keep the unbound device's group/context bank
> to bypass rather than resetting the streamids ?
...which we can easily enforce by keeping the device attached to its
default domain, in which nothing should be mapped by that point (we
could even have a group notifier switch its S2CRs to faulting entries
for extreme paranoia). Freeing the SMRs means those stream IDs would
instead fall back to the default "unmatched" behaviour, which in general
is going to be bypass, and thus allow DMA attacks.
It's harder to disable unmatched bypass in general, because we may have
devices which physically master through the SMMU but want low latency
more than they want translation (at the moment the best we can do is
leave the kernel unaware of those stream IDs), or there could be unknown
devices under control of the firmware or other agents which we would
disrupt by hitting a system-wide switch.
Robin.
>
> Regards,
> Sricharan
>
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Robert Richter @ 2016-11-24 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124150918.GF2213@rric.localdomain>
Ard,
> > >> On 24 November 2016 at 13:51, Robert Richter <robert.richter@cavium.com> wrote:
> > >> > On 24.11.16 13:44:31, Ard Biesheuvel wrote:
> > >> Regions containing firmware tables are owned by the firmware, and it
> > >> is the firmware that tells us which memory attributes we are allowed
> > >> to use. If those attributes include WB, it is perfectly legal to use a
> > >> cacheable mapping. That does *not* mean they should be covered by the
> > >> linear mapping. The linear mapping is read-write-non-exec, for
> > >> instance, and we may prefer to use a read-only mapping and/or
> > >> executable mapping.
> > >
> > > Ok, I am going to fix try_ram_remap().
I revisited the code and it is working well already since:
e7cd190385d1 arm64: mark reserved memblock regions explicitly in iomem
Now, try_ram_remap() is only called if the region to be mapped is
entirely in IORESOURCE_SYSTEM_RAM. This is only true for normal mem
ranges and not NOMAP mem. region_intersects() then returns
REGION_INTERSECTS and calls try_ram_remap(). For the NOMAP memory case
REGION_DISJOINT would be returned and thus arch_memremap_wb() being
called directly. Before the e7cd190385d1 change try_ram_remap() was
called also for nomap regions.
So we can leave memremap() as it is and just apply this patch
unmodified. What do you think? Please ack.
I am going to prepare the pfn_is_ram() change in addition to this
patch, but that should not be required for this fix to work correcly.
Thanks,
-Robert
^ permalink raw reply
* [PATCH 5/7] efi: Get the secure boot status [ver #3]
From: James Bottomley @ 2016-11-24 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147990565051.7576.9673287945782426886.stgit@warthog.procyon.org.uk>
On Wed, 2016-11-23 at 12:54 +0000, David Howells wrote:
> Get the firmware's secure-boot status in the kernel boot wrapper and
> stash it somewhere that the main kernel image can find.
>
> The efi_get_secureboot() function is extracted from the arm stub and
> (a) generalised so that it can be called from x86 and (b) made to use
> efi_call_runtime() so that it can be run in mixed-mode.
>
> Suggested-by: Lukas Wunner <lukas@wunner.de>
> Signed-off-by: David Howells <dhowells@redhat.com>
Since you seem to be using this to mean "is the platform locked down?",
this looks to be no longer complete in the UEFI 2.6 world. If
DeployedMode == 0, even if SecureBoot == 1 and SetupMode == 0, you can
remove the platform key by writing 1 to AuditMode and gain control of
the secure variables. The lock down state becomes DeployedMode == 1,
SecureBoot == 1 and SetupMode == 0
See the diagram on page 1817
http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf
James
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Ard Biesheuvel @ 2016-11-24 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124192659.GH2213@rric.localdomain>
On 24 November 2016 at 19:26, Robert Richter <robert.richter@cavium.com> wrote:
> Ard,
>
>> > >> On 24 November 2016 at 13:51, Robert Richter <robert.richter@cavium.com> wrote:
>> > >> > On 24.11.16 13:44:31, Ard Biesheuvel wrote:
>
>> > >> Regions containing firmware tables are owned by the firmware, and it
>> > >> is the firmware that tells us which memory attributes we are allowed
>> > >> to use. If those attributes include WB, it is perfectly legal to use a
>> > >> cacheable mapping. That does *not* mean they should be covered by the
>> > >> linear mapping. The linear mapping is read-write-non-exec, for
>> > >> instance, and we may prefer to use a read-only mapping and/or
>> > >> executable mapping.
>> > >
>> > > Ok, I am going to fix try_ram_remap().
>
> I revisited the code and it is working well already since:
>
> e7cd190385d1 arm64: mark reserved memblock regions explicitly in iomem
>
> Now, try_ram_remap() is only called if the region to be mapped is
> entirely in IORESOURCE_SYSTEM_RAM. This is only true for normal mem
> ranges and not NOMAP mem. region_intersects() then returns
> REGION_INTERSECTS and calls try_ram_remap(). For the NOMAP memory case
> REGION_DISJOINT would be returned and thus arch_memremap_wb() being
> called directly. Before the e7cd190385d1 change try_ram_remap() was
> called also for nomap regions.
>
> So we can leave memremap() as it is and just apply this patch
> unmodified. What do you think?
I agree. The pfn_valid() check in try_ram_remap() is still appropriate
simply because the PageHighmem check requires a valid struct page. But
if we don't enter that code path anymore for NOMAP regions, I think
we're ok.
> Please ack.
>
I still don't fully understand how it is guaranteed that *all* memory
(i.e., all regions for which memblock_is_memory() returns true) is
covered by a struct page, but marked as reserved. Are we relying on
the fact that NOMAP memory is also memblock_reserve()'d?
> I am going to prepare the pfn_is_ram() change in addition to this
> patch, but that should not be required for this fix to work correcly.
>
I don't think you need to bother with page_is_ram() then. The only
place we use it is in devmem_is_allowed(), and there it makes sense to
allow NOMAP regions to be accessed (provided that you think /dev/mem
is a good idea in the first place).
^ permalink raw reply
* [RFC PATCH 2/2] arm64: dts: enable the MUSB controller of Pine64 in host-only mode
From: Maxime Ripard @ 2016-11-24 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122165902.62543-2-icenowy@aosc.xyz>
On Wed, Nov 23, 2016 at 12:59:02AM +0800, Icenowy Zheng wrote:
> A64 has a MUSB controller wired to the USB PHY 0, which is connected
> to the upper USB Type-A port of Pine64.
>
> As the port is a Type-A female port, enable it in host-only mode in the
> device tree, which makes devices with USB Type-A male port can work on
> this port (which is originally designed by Pine64 team).
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied both, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/7504c3f1/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Maxime Ripard @ 2016-11-24 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122170616.29557-1-manu@bidouilliste.com>
On Tue, Nov 22, 2016 at 06:06:16PM +0100, Emmanuel Vadot wrote:
> The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
> others three only have 1.
> Add the num-cs property to each node.
>
> Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
I don't think we have any code that uses it at the moment. What is the
rationale behind this patch?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/e1729b42/attachment.sig>
^ permalink raw reply
* [PATCH 0/2] ARM: dts: sun6i: Disable display pipeline by default
From: Maxime Ripard @ 2016-11-24 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124064339.12615-1-wens@csie.org>
On Thu, Nov 24, 2016 at 02:43:37PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> While we now support the internal display pipeline found on sun6i, it
> is possible that we are unable to enable the display for some boards,
> due to a lack of drivers for the panels or bridges found on them. If
> the display pipeline is enabled, the driver will try to enable, and
> possibly screw up the simple framebuffer U-boot had configured.
>
> This series disables the display pipeline by default, and re-enables
> it for the A31 Hummingbird, which already had its display pipeline
> enabled.
>
> The series can go in after 4.10-rc1, as a fix, but should not be delayed
> till the next release.
Applied both, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/fc6a71f2/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sun6i: hummingbird: Enable USB OTG
From: Maxime Ripard @ 2016-11-24 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124112908.4796-1-wens@csie.org>
On Thu, Nov 24, 2016 at 07:29:08PM +0800, Chen-Yu Tsai wrote:
> The A31 Hummingbird has a mini USB OTG port, and uses GPIO pins from the
> SoC for ID pin and VBUS detection and VBUS control. The PMIC can also do
> VBUS detection and control.
>
> Here we prefer to use the PMIC's DRIVEVBUS function to control VBUS for
> USB OTG, as that is the hardware default.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/fb996ac4/attachment.sig>
^ 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