* Re: [PATCH v2 3/9] soc: samsung: Add Exynos Adaptive Supply Voltage driver
From: Robin Murphy @ 2019-08-08 12:48 UTC (permalink / raw)
To: Krzysztof Kozlowski, Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc@vger.kernel.org,
Bartłomiej Żołnierkiewicz, pankaj.dubey, linux-pm,
linux-kernel@vger.kernel.org, robh+dt, kgene, vireshk,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <CAJKOXPc8iFo=2JAGEZSC46N3sZae4+JcZYBCjpKysb6PFPzyaQ@mail.gmail.com>
On 08/08/2019 13:31, Krzysztof Kozlowski wrote:
> On Thu, 8 Aug 2019 at 14:07, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>>>> +static unsigned int exynos5422_asv_parse_table(struct exynos_asv *asv,
>>>> + unsigned int pkg_id)
>>>> +{
>>>> + return (pkg_id >> EXYNOS5422_TABLE_OFFSET) & EXYNOS5422_TABLE_MASK;
>>>> +}
>>>> +
>>>> +static bool exynos5422_asv_parse_bin2(struct exynos_asv *asv,
>>>> + unsigned int pkg_id)
>>>> +{
>>>> + return (pkg_id >> EXYNOS5422_BIN2_OFFSET) & EXYNOS5422_BIN2_MASK;
>>>
>>> return !!() for converting to boolean.
>>
>> I'm not convinced it is needed, the return type of the function is bool
>> and value of the expression will be implicitly converted to that type.
>> Is there any compiler warning related to that?
>
> Yeah, but bool is int so there will be no implicit conversion... I
> guess it is a convention. In theory !! is the proper conversion to
> bool but if bool==int then it's essentially conversion to 1. I am not
> sure what's the benefit, maybe for some wrong code which would do
> comparisons on result like if (exynos5422_asv_parse_bin2() == TRUE)...
Not so - since we use "-std=gnu89", we have C99-like _Bool, which our
bool is a typedef of. Conversions, either implicit or explicit, are
well-defined:
"6.3.1.2 Boolean type
When any scalar value is converted to _Bool, the result is 0 if the
value compares equal
to 0; otherwise, the result is 1."
This is even called out in Documentation/process/coding-style.rst:
"When using bool types the !! construction is not needed, which
eliminates a class of bugs."
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/6] tty: serial: Add linflexuart driver for S32V234
From: Stefan-gabriel Mirea @ 2019-08-08 12:47 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, corbet@lwn.net,
gregkh@linuxfoundation.org, jslaby@suse.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
Cosmin Stefan Stoica, robh+dt@kernel.org,
linux-serial@vger.kernel.org, catalin.marinas@arm.com,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org,
Larisa Ileana Grigore
In-Reply-To: <20190808080832.nleult5bknmzr3ze@willie-the-truck>
Hello Will,
On 8/8/2019 11:08 AM, Will Deacon wrote:
> On Fri, Aug 02, 2019 at 07:47:23PM +0000, Stefan-gabriel Mirea wrote:
>> + linflex,<addr>
>> + Use early console provided by Freescale LinFlex UART
>> + serial driver for NXP S32V234 SoCs. A valid base
>> + address must be provided, and the serial port must
>> + already be setup and configured.
>
> Why isn't earlycon= sufficient for this?
"earlycon=" is not actually supported. I will fix this in the next
version by adding a /chosen/stdout-path to the dts. The compatible
string provided to OF_EARLYCON_DECLARE will also be changed from
"fsl,s32v234-linflexuart" to "fsl,s32-linflexuart" to match the one in
the device tree nodes. I missed this after importing a rename from our
codebase.
Should I remove this addition from kernel-parameters.txt after that?
Regards,
Stefan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] mmc: sdhci-of-at91: add quirk for broken HS200
From: Ludovic Desroches @ 2019-08-08 12:42 UTC (permalink / raw)
To: Eugen Hristev - M18282
Cc: devicetree@vger.kernel.org, alexandre.belloni@bootlin.com,
linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
adrian.hunter@intel.com, ulf.hansson@linaro.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1565252928-28994-1-git-send-email-eugen.hristev@microchip.com>
On Thu, Aug 08, 2019 at 10:35:40AM +0200, Eugen Hristev - M18282 wrote:
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> HS200 is not implemented in the driver, but the controller claims it
> through caps.
> Remove it via quirk.
> Without this quirk, the mmc core will try to enable hs200, which will fail,
> and the eMMC initialization will fail.
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Thanks
Ludovic
> ---
> drivers/mmc/host/sdhci-of-at91.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c
> index 57fe3b2..3a8c6d8 100644
> --- a/drivers/mmc/host/sdhci-of-at91.c
> +++ b/drivers/mmc/host/sdhci-of-at91.c
> @@ -370,6 +370,9 @@ static int sdhci_at91_probe(struct platform_device *pdev)
> pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
> pm_runtime_use_autosuspend(&pdev->dev);
>
> + /* HS200 is broken at this moment */
> + host->quirks2 = SDHCI_QUIRK2_BROKEN_HS200;
> +
> ret = sdhci_add_host(host);
> if (ret)
> goto pm_runtime_disable;
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: at91: sama5d27_som1_ek: add mmc capabilities for SDMMC0
From: Ludovic Desroches @ 2019-08-08 12:42 UTC (permalink / raw)
To: Eugen Hristev - M18282
Cc: devicetree@vger.kernel.org, alexandre.belloni@bootlin.com,
linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
adrian.hunter@intel.com, ulf.hansson@linaro.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1565252928-28994-2-git-send-email-eugen.hristev@microchip.com>
On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote:
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> Add mmc capabilities for SDMMC0 for this board.
> With this enabled, eMMC connected card is detected as:
>
> mmc0: new DDR MMC card at address 0001
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
I am interested to have the some insights about the use of sd-uhs-*
properties.
Our IP can't deal with 1V8 by itself. It has a 1V8SEL signal which can
be used as the logic control input of a mux. So even if the IP claims
to support UHS modes, it depends on the board.
Are the sd-uhs-* properties a way to deal with this? I tend to think no
as sdhci_setup_host() will set the caps depending on the content of the
capabilities register. Do we have to use the SDHCI_QUIRK_MISSING_CAPS
quirk or sdhci-caps/sdhci-caps-mask?
Regards
Ludovic
> ---
> arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
> index 149e539..194b3a3 100644
> --- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
> +++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
> @@ -54,6 +54,7 @@
>
> sdmmc0: sdio-host@a0000000 {
> bus-width = <8>;
> + mmc-ddr-3_3v;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_sdmmc0_default>;
> status = "okay";
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: Clarify when cpu_enable() is called
From: Mark Brown @ 2019-08-08 12:36 UTC (permalink / raw)
To: Suzuki K Poulose; +Cc: catalin.marinas, will, linux-arm-kernel
In-Reply-To: <460ad751-9b15-03c8-2279-d90837e94219@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 979 bytes --]
On Thu, Aug 08, 2019 at 10:20:12AM +0100, Suzuki K Poulose wrote:
> On 07/08/2019 17:01, Will Deacon wrote:
> > On Tue, Aug 06, 2019 at 06:00:43PM +0100, Mark Brown wrote:
> > > + * Take the appropriate actions to configure this capability for this
> > > + * CPU. This will be called on all CPUs in the system if the
> > > + * capability is detected anywhere in the system.
> > That's not quite right though either, is it? We need to take into account
> > the scope of the capability/erratum as well,
> Exactly. Each capability is detected based on the "SCOPE" of the capability.
> So, the above statement is clearly misleading (i.e, mentioning the case for the
> LOCAL_CPU scope capabilities) and is wrong for SYSTEM scope. For that matter,
> one should not talk about the "where" it is detected, as long as he understands
> the "scope" of the capability.
My goal with using "anywhere" was to cover all scopes, including the
system scope and also all more local scopes.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/9] soc: samsung: Add Exynos Adaptive Supply Voltage driver
From: Krzysztof Kozlowski @ 2019-08-08 12:31 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc@vger.kernel.org, linux-pm,
pankaj.dubey, Bartłomiej Żołnierkiewicz,
linux-kernel@vger.kernel.org, robh+dt, kgene, vireshk,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <a56fe2d8-1f26-b462-1564-f23902f7dbb5@samsung.com>
On Thu, 8 Aug 2019 at 14:07, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
> >> +static unsigned int exynos5422_asv_parse_table(struct exynos_asv *asv,
> >> + unsigned int pkg_id)
> >> +{
> >> + return (pkg_id >> EXYNOS5422_TABLE_OFFSET) & EXYNOS5422_TABLE_MASK;
> >> +}
> >> +
> >> +static bool exynos5422_asv_parse_bin2(struct exynos_asv *asv,
> >> + unsigned int pkg_id)
> >> +{
> >> + return (pkg_id >> EXYNOS5422_BIN2_OFFSET) & EXYNOS5422_BIN2_MASK;
> >
> > return !!() for converting to boolean.
>
> I'm not convinced it is needed, the return type of the function is bool
> and value of the expression will be implicitly converted to that type.
> Is there any compiler warning related to that?
Yeah, but bool is int so there will be no implicit conversion... I
guess it is a convention. In theory !! is the proper conversion to
bool but if bool==int then it's essentially conversion to 1. I am not
sure what's the benefit, maybe for some wrong code which would do
comparisons on result like if (exynos5422_asv_parse_bin2() == TRUE)...
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] dma: qcom: hidma_mgmt: Add of_node_put() before goto
From: Vinod Koul @ 2019-08-08 12:27 UTC (permalink / raw)
To: Sinan Kaya
Cc: linux-arm-msm, agross, Nishka Dasgupta, dmaengine, dan.j.williams,
linux-arm-kernel
In-Reply-To: <eab2555a-07ad-9e48-14d4-e34417d52fbb@kernel.org>
On 24-07-19, 13:25, Sinan Kaya wrote:
> On 7/24/2019 4:16 AM, Nishka Dasgupta wrote:
> > Each iteration of for_each_available_child_of_node puts the previous
> > node, but in the case of a goto from the middle of the loop, there is
> > no put, thus causing a memory leak.
> > Hence add an of_node_put under the label that the gotos point to.
> > In order to avoid decrementing an already-decremented refcount, copy the
> > original contents of the label (including the return statement) to just
> > above the label, so that the code under the label is executed only when
> > a goto exit from the loop occurs.
> > Additionally, remove an unnecessary get/put pair from the loop, as the
> > loop itself already keeps track of refcount.
> > Issue found with Coccinelle.
> >
> > Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
>
> nit: please post v3 with dmaengine:qcom:hidma_mgmt:....
>
> Vinod doesn't like commit subjectss in this directory to have dma name
> on it. You can keep my acked-by.
That's right but I am okay to hand edit while applying for drive by
contributors :) so applied with you ack
> Acked-by: Sinan Kaya <okaya@kernel.org>
>
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 04/24] dmaengine: qcom_hidma: Remove call to memset after dmam_alloc_coherent
From: Vinod Koul @ 2019-08-08 12:22 UTC (permalink / raw)
To: Fuqian Huang
Cc: linux-arm-msm, Sinan Kaya, linux-kernel, David Brown, Andy Gross,
dmaengine, linux-arm-kernel
In-Reply-To: <20190715031723.6375-1-huangfq.daxian@gmail.com>
On 15-07-19, 11:17, Fuqian Huang wrote:
> In commit 518a2f1925c3
> ("dma-mapping: zero memory returned from dma_alloc_*"),
> dma_alloc_coherent has already zeroed the memory.
> So memset is not needed.
Applied, thanks
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 03/24] dmaengine: imx-sdma: Remove call to memset after dma_alloc_coherent
From: Vinod Koul @ 2019-08-08 12:22 UTC (permalink / raw)
To: Fuqian Huang
Cc: dmaengine, Sascha Hauer, Shawn Guo, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190715031716.6328-1-huangfq.daxian@gmail.com>
On 15-07-19, 11:17, Fuqian Huang wrote:
> In commit 518a2f1925c3
> ("dma-mapping: zero memory returned from dma_alloc_*"),
> dma_alloc_coherent has already zeroed the memory.
> So memset is not needed.
Applied, thanks
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: fsl: add support for Hummingboard Pulse
From: Baruch Siach @ 2019-08-08 12:22 UTC (permalink / raw)
To: Fabio Estevam
Cc: Sascha Hauer, Jon Nettleton, NXP Linux Team,
Pengutronix Kernel Team, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAOMZO5C9zBPZgc4CfR_h6hDg5vEXTzokCh9rbzNknZ4eE06qLw@mail.gmail.com>
Hi Fabio,
Thanks for your review. I'll send an updated patch shortly.
One comment below.
On Thu, Aug 08 2019, Fabio Estevam wrote:
> On Wed, Aug 7, 2019 at 11:32 AM Baruch Siach <baruch@tkos.co.il> wrote:
>>
>> From: Jon Nettleton <jon@solid-run.com>
>>
>> The SolidRun Hummingboard Pulse carrier board carries the SolidRun
>> i.MX8MQ based SOM.
>>
>> Notably missing is PCIe support that depends on analog PLLOUT clock.
>> Current imx clk driver does not support this clock.
>>
>> Signed-off-by: Jon Nettleton <jon@solid-run.com>
>> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[...]
>> +&i2c2 {
>> + clock-frequency = <100000>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_i2c2>;
>> + status = "okay";
>> +
>> + typec_ptn5100: ptn5110@50 {
>> + compatible = "usb,tcpci";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_typec>;
>> + reg = <0x50>;
>> + interrupt-parent = <&gpio1>;
>> + interrupts = <6 8>;
>> + ss-sel-gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
>> + src-pdos = <0x380190c8>;
>
> This property and others do not exist in mainline
>
> Please see Documentation/devicetree/bindings/usb/typec-tcpci.txt and
> arch/arm64/boot/dts/freescale/imx8mm-evk.dts for a reference.
Thanks for the reference. I assume your refer to imx8mm-evk.dts in
Shawn's imx/dt64 branch, since it's not in the mainline tree.
One problem I had with this example is that 'port' node is not under the
'connector' node. The kernel doesn't like that:
[ 1.502227] OF: graph: no port node found in /soc@0/bus@30800000/i2c@30a30000/usb-typec@50/connector
Do you see something similar?
I moved 'port' under 'connector' to avoid this warning. The TypeC
connector works either way, though.
Do you have any idea whether there is a 'ss-sel-gpios' property
equivalent in current kernel code?
Thanks again,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: Clarify when cpu_enable() is called
From: Mark Brown @ 2019-08-08 12:19 UTC (permalink / raw)
To: Suzuki K Poulose; +Cc: catalin.marinas, will, linux-arm-kernel
In-Reply-To: <0508fc5a-ab61-f507-507f-3002e49f2d27@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 2126 bytes --]
On Thu, Aug 08, 2019 at 12:05:02PM +0100, Suzuki K Poulose wrote:
> On 07/08/2019 17:51, Mark Brown wrote:
> > On Wed, Aug 07, 2019 at 05:01:08PM +0100, Will Deacon wrote:
> > > On Tue, Aug 06, 2019 at 06:00:43PM +0100, Mark Brown wrote:
> > I guess you're thinking of the ARM64_CPUCAP_SYSTEM_FEATURE case where we
> > match the feature on all CPUs so we could see the feature on some CPUs
> > but not detect it as we're requiring a match on all?
> We don't run the "match" check (i.e, detect) on all CPUs for SYSTEM scoped
> features. Instead, we use sanitised feature set to detect the system features.
Right, but the sanitised feature set involves merging the capabilities
of all the CPUs.
> > If this is called for any CPU in the system then it will be
> > called for all of them.
> > might cover it?
> * current CPU. If this capability is detected by the kernel, this will
> * called on all the CPUs in the system, including the hotplugged
> * CPUs.
> */
How about adding ", regardless of if the capability was detected on that
specific CPU" at the end? The above is *accurate* but it's still easy to
insert an "on that CPU" in there when reading especially with the
awkward phrasing. Or possibly just drop the first comma. The reason I
said "If this is called" rather than "if this is detected" is to make it
as clear as possible that the calls don't depend on detection without
being overly verbose.
If this capability is detected by the kernel
this will called on all the CPUs in the system, including
the hotplugged CPUs, regardless of if the capability was
detected on that specific CPU.
> > I don't see where we limit where cpu_enable() is called after we start
> > calling it. When we're looping through in cpu_enable_non_boot_scope()
> > we skip SCOPE_BOOT_CPU but those get cpu_enable() called in
> > enable_cpu_capabilites() or verify_local_cpu_capabilities() depending on
> > if it's the boot CPU or not. It's possible I'm missing something
> > though.
...
> Does this help ?
I think you just confirmed that when I said we don't limit where we call
cpu_enable() that's accurate?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 0/3] Add basic support for RTC on Allwinner H6 SoC
From: Ondřej Jirman @ 2019-08-08 12:12 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Mark Rutland, Alessandro Zummo, devicetree, Maxime Ripard,
linux-sunxi, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel, linux-rtc
In-Reply-To: <20190807105502.GK3600@piout.net>
On Wed, Aug 07, 2019 at 12:55:02PM +0200, Alexandre Belloni wrote:
> Hi,
>
> On 06/08/2019 20:30:45+0200, Ondřej Jirman wrote:
> > Maybe whether XO or DCXO is used also matters if you want to do some fine
> > tunning of DCXO (control register has pletny of options), but that's probably
> > better done in u-boot. And there's still no need to read HOSC source from DT.
> > The driver can just check compatible, and if it is H6 and OSC_CLK_SRC_SEL is 1,
> > it can do it's DCXO tunning, or whatever. But neither OS nor bootloader will
> > be using this info to gate/disable the osciallator.
> >
>
> It is actually useful to be able to tweak the crystal tuning at
> runtime to be able to reduce clock drift and compare with a reliable
> source (e.g. NTP).
I don't think there's a Linux kernel API that you can use to achieve that, so
that's a rather theoretical concern at the moment.
Also there are multiple clocks, that can drive the RTC, and you usually don't
drive it from 24MHz DCXO oscillator. The reason is that you'd have to deal with
the fact that the clock for RTC then becomes 24000000/750 (750 is fixed
divider), which is 32000.
So if you want to get 32768Hz for RTC by tuning the DCXO, it would have to have
24 576 000 Hz. And even if you could achieve that (doubtful), it would throw off
timings in the rest of the system (say UART, USB, CPU, display ctl) in a major way.
I guess you can try tuning 24MHz oscillator so that it's closer to the
real-world 24MHz via NTP reference for other reasons. But it would be
complicated, and require precise interaction with other components, like using
HW timers sourced from 24MHz HOSC clock, because you can't use CPU's timers,
because of inaccuracies introduced during DVFS, for example.
regards,
o.
> I'm curious, what kind of options does this RTC have?
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/9] soc: samsung: Add Exynos Adaptive Supply Voltage driver
From: Sylwester Nawrocki @ 2019-08-08 12:07 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-samsung-soc@vger.kernel.org, linux-pm,
pankaj.dubey, Bartłomiej Żołnierkiewicz,
linux-kernel, robh+dt, kgene, vireshk, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <CAJKOXPeOfDHjqSotxVwVuy+6r9X3Q8ZXLit1_=gGd7bOwkHupA@mail.gmail.com>
On 7/23/19 15:38, Krzysztof Kozlowski wrote:
> On Thu, 18 Jul 2019 at 16:31, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>>
>> The Adaptive Supply Voltage (ASV) driver adjusts CPU cluster operating
>> points depending on exact revision of an SoC retrieved from the CHIPID
>> block or the OTP memory. This allows for some power saving as for some
>> CPU clock frequencies we can lower CPU cluster supply voltage comparing
>> to safe values common to the all chip revisions.
>>
>> This patch adds support for Exynos5422/5800 SoC, it is partially based
>> on code from https://github.com/hardkernel/linux repository,
>> branch odroidxu4-4.14.y, files: arch/arm/mach-exynos/exynos5422-asv.[ch].
>>
>> Tested on Odroid XU3, XU4, XU3 Lite.
>>
>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> ---
>> Changes since v1 (RFC):
>> - removed code for parsing the ASV OPP tables from DT, the ASV OPP tables
>> moved to the driver;
>> - converted to use the regmap API;
>> - converted to normal platform driver.
>> ---
>> drivers/soc/samsung/Kconfig | 11 +
>> drivers/soc/samsung/Makefile | 3 +
>> drivers/soc/samsung/exynos-asv.c | 185 ++++++++++
>> drivers/soc/samsung/exynos-asv.h | 82 +++++
>> drivers/soc/samsung/exynos5422-asv.c | 499 +++++++++++++++++++++++++++
>> drivers/soc/samsung/exynos5422-asv.h | 25 ++
>> 6 files changed, 805 insertions(+)
>> create mode 100644 drivers/soc/samsung/exynos-asv.c
>> create mode 100644 drivers/soc/samsung/exynos-asv.h
>> create mode 100644 drivers/soc/samsung/exynos5422-asv.c
>> create mode 100644 drivers/soc/samsung/exynos5422-asv.h
>>
>> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
>> index 2905f5262197..539cd95dd176 100644
>> --- a/drivers/soc/samsung/Kconfig
>> +++ b/drivers/soc/samsung/Kconfig
>> @@ -7,6 +7,17 @@ menuconfig SOC_SAMSUNG
>>
>> if SOC_SAMSUNG
>>
>> +config EXYNOS_ASV
>> + bool "Exynos Adaptive Supply Voltage support" if COMPILE_TEST
>> + depends on ARCH_EXYNOS || COMPILE_TEST
>> + depends on EXYNOS_CHIPID
>
> (ARCH_EXYNOS && EXYNOS_CHIPID) || COMPILE_TEST
OK
>> + select EXYNOS_ASV_ARM if ARM && ARCH_EXYNOS
>> +
>> +# There is no need to enable these drivers for ARMv8
>> +config EXYNOS_ASV_ARM
>> + bool "Exynos ASV ARMv7-specific driver extensions" if COMPILE_TEST
>> + depends on EXYNOS_ASV
>> diff --git a/drivers/soc/samsung/exynos-asv.c b/drivers/soc/samsung/exynos-asv.c
>> new file mode 100644
>> index 000000000000..b1a7e0ba8870
>> --- /dev/null
>> +++ b/drivers/soc/samsung/exynos-asv.c
>> @@ -0,0 +1,185 @@
>> +static int exynos_asv_probe(struct platform_device *pdev)
>> +{
>> + int (*probe_func)(struct exynos_asv *asv);
>> + struct exynos_asv *asv;
>> + struct device *cpu_dev;
>> + u32 product_id = 0;
>> + int ret, i;
>> +
>> + cpu_dev = get_cpu_device(0);
>> + ret = dev_pm_opp_get_opp_count(cpu_dev);
>> + if (ret < 0)
>> + return -EPROBE_DEFER;
>> +
>> + asv = kcalloc(1, sizeof(*asv), GFP_KERNEL);
>> + if (!asv)
>> + return -ENOMEM;
>> +
>> + asv->chipid_regmap = syscon_node_to_regmap(pdev->dev.of_node);
>> + if (IS_ERR(asv->chipid_regmap)) {
>> + dev_err(&pdev->dev, "Could not find syscon regmap\n");
>
> Here and in following error-paths - kfree().
Thanks, I will fix that.
>> + return PTR_ERR(asv->chipid_regmap);
>> + }
>> +
>> + regmap_read(asv->chipid_regmap, EXYNOS_CHIPID_REG_PRO_ID, &product_id);
>> +module_platform_driver(exynos_asv_driver);
>> diff --git a/drivers/soc/samsung/exynos-asv.h b/drivers/soc/samsung/exynos-asv.h
>> new file mode 100644
>> index 000000000000..d0a5d603093d
>> --- /dev/null
>> +++ b/drivers/soc/samsung/exynos-asv.h
>> @@ -0,0 +1,82 @@
>> +#ifndef _EXYNOS_ASV_H
>> +#define _EXYNOS_ASV_H
>
> Here and in other header use prefix:
> __LINUX_SOC_
> (just like the existing exynos-pmu.h)
OK, I will change that.
>> +struct exynos_asv_subsys {
>> + struct exynos_asv *asv;
>> + char *cpu_dt_compat;
>
> const char *
OK
>> + int id;
>> +#endif /* _EXYNOS_ASV_H */
>> diff --git a/drivers/soc/samsung/exynos5422-asv.c b/drivers/soc/samsung/exynos5422-asv.c
>> new file mode 100644
>> index 000000000000..5fd673a6a733
>> --- /dev/null
>> +++ b/drivers/soc/samsung/exynos5422-asv.c
>> @@ -0,0 +1,499 @@
>> +#include <linux/bitrev.h>
>> +#include <linux/device.h>
>> +#include <linux/errno.h>
>> +#include <linux/init.h>
>
> Looks unused.
Indeed, I will drop it.
>> +static unsigned int exynos5422_asv_parse_table(struct exynos_asv *asv,
>> + unsigned int pkg_id)
>> +{
>> + return (pkg_id >> EXYNOS5422_TABLE_OFFSET) & EXYNOS5422_TABLE_MASK;
>> +}
>> +
>> +static bool exynos5422_asv_parse_bin2(struct exynos_asv *asv,
>> + unsigned int pkg_id)
>> +{
>> + return (pkg_id >> EXYNOS5422_BIN2_OFFSET) & EXYNOS5422_BIN2_MASK;
>
> return !!() for converting to boolean.
I'm not convinced it is needed, the return type of the function is bool
and value of the expression will be implicitly converted to that type.
Is there any compiler warning related to that?
>> +}
>> +
>> +static bool exynos5422_asv_parse_sg(struct exynos_asv *asv,
>> + unsigned int pkg_id)
>> +{
>> + return ((pkg_id >> EXYNOS5422_USESG_OFFSET) & EXYNOS5422_USESG_MASK);
>
> Unneeded () over entire statement.
Will drop it.
--
Regards,
Sylwester
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/9] soc: samsung: Convert exynos-chipid driver to use the regmap API
From: Sylwester Nawrocki @ 2019-08-08 12:07 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-samsung-soc@vger.kernel.org, linux-pm,
pankaj.dubey, Bartłomiej Żołnierkiewicz,
linux-kernel, robh+dt, kgene, vireshk, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <CAJKOXPfLPjmjgX01UAyu_=7etUO1G7osMQDmyHVBNxF2Sdh=yA@mail.gmail.com>
On 7/23/19 15:01, Krzysztof Kozlowski wrote:
> On Thu, 18 Jul 2019 at 16:31, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>>
>> Convert the driver to use regmap API in order to allow other
>> drivers, like ASV, to access the CHIPID registers.
>>
>> This patch adds definition of selected CHIPID register offsets
>> and register bit fields for Exynos5422 SoC.
>>
>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
>> index 78b123ee60c0..594b00488013 100644
>> --- a/drivers/soc/samsung/exynos-chipid.c
>> +++ b/drivers/soc/samsung/exynos-chipid.c
>> @@ -9,18 +9,16 @@
>> */
>> @@ -53,29 +51,24 @@ static const char * __init product_id_to_soc_id(unsigned int product_id)
>> int __init exynos_chipid_early_init(void)
>> {
>> + regmap = syscon_regmap_lookup_by_compatible("samsung,exynos4210-chipid");
>> + if (IS_ERR(regmap)) {
>> + pr_err("%s: failed to get regmap\n", __func__);
>
> Other places do not use __func__ prefix so make it consistent. Add it
> in patch #1?
I would rather drop the function name prefix here, there should be
no problem in finding those error messages with grep. I'll just make
the above log a bit more specific.
>> + return PTR_ERR(regmap);
>> }
>> diff --git a/include/linux/soc/samsung/exynos-chipid.h b/include/linux/soc/samsung/exynos-chipid.h
>> new file mode 100644
>> index 000000000000..25359d70d617
>> --- /dev/null
>> +++ b/include/linux/soc/samsung/exynos-chipid.h
>> @@ -0,0 +1,48 @@
>> +#define EXYNOS_CHIPID_REG_PRO_ID 0x00
>> + #define EXYNOS_SUBREV_MASK (0xf << 4)
>
> " #define" is unusual syntax. I think not used anywhere else. Stick to
> regular one.
Indeed it's almost not used anywhere, I will drop those leading spaces.
git grep "^\ #define" *.[ch] | wc -l
--
Regards,
Sylwester
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/9] soc: samsung: Add exynos chipid driver support
From: Sylwester Nawrocki @ 2019-08-08 12:07 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-samsung-soc@vger.kernel.org, linux-pm,
pankaj.dubey, Bartłomiej Żołnierkiewicz,
linux-kernel, robh+dt, kgene, vireshk, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <CAJKOXPfLBif-=09B9jZ3qN1kWdTAcrBQZGvZ+A-MUifXK4si9Q@mail.gmail.com>
On 7/23/19 14:57, Krzysztof Kozlowski wrote:
>> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
>> --- /dev/null
>> +++ b/drivers/soc/samsung/exynos-chipid.c
>> @@ -0,0 +1,111 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +#include <linux/io.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/platform_device.h>
>
> Any changes here from my previous comments?
Oops, I tried hard to not miss any of the comments but probably not hard enough.
The two above platform header files will be removed in v3.
--
Regards,
Sylwester
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4.4 V2 24/43] arm64: Add skeleton to harden the branch predictor against aliasing attacks
From: Viresh Kumar @ 2019-08-08 12:06 UTC (permalink / raw)
To: Mark Rutland
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <20190806121816.GD475@lakrids.cambridge.arm.com>
On 06-08-19, 13:18, Mark Rutland wrote:
> Upstream and in v4.9, the meltdown patches came before the spectre
> patches, and doing this in the opposite order causes context problems
> like the above.
>
> Given that, I think it would be less surprising to do the meltdown
> backport first, though I apprecaite that's more work to get these
> patches in. :/
I attempted meltdown backport in the last two days and the amount of
extra patches to be backported is enormous. And I am not sure if
everything is alright as well now, and things will greatly rely on
reviews from you for it.
For this series, what about just backporting for now to account for
CSV3 ? And attempting meltdown backport separately later ?
179a56f6f9fb arm64: Take into account ID_AA64PFR0_EL1.CSV3
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] drm: add cache support for arm64
From: Daniel Vetter @ 2019-08-08 11:58 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Rob Clark, Maxime Ripard, Catalin Marinas, David Airlie,
Maarten Lankhorst, LKML, dri-devel, Sean Paul, Rob Clark,
Linux ARM, Daniel Vetter, Greg Kroah-Hartman, Thomas Gleixner,
Will Deacon, Allison Randal
In-Reply-To: <20190808095506.GA32621@lst.de>
On Thu, Aug 08, 2019 at 11:55:06AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 07, 2019 at 10:48:56AM +0200, Daniel Vetter wrote:
> > > other drm drivers how do they guarantee addressability without an
> > > iommu?)
> >
> > We use shmem to get at swappable pages. We generally just assume that
> > the gpu can get at those pages, but things fall apart in fun ways:
> > - some setups somehow inject bounce buffers. Some drivers just give
> > up, others try to allocate a pool of pages with dma_alloc_coherent.
> > - some devices are misdesigned and can't access as much as the cpu. We
> > allocate using GFP_DMA32 to fix that.
>
> Well, for shmem you can't really call allocators directly, right?
We can pass gfp flags to shmem_read_mapping_page_gfp, which is just about
enough for the 2 cases on intel platforms where the gpu can only access
4G, but the cpu has way more.
> One thing I have in my pipeline is a dma_alloc_pages API that allocates
> pages that are guaranteed to be addressably by the device or otherwise
> fail. But that doesn't really help with the shmem fs.
Yeah, the other drivers where the shmem gfp trick doesn't work copy
back&forth between the dma-able pages and the shmem swappable pages as
needed in their shrinker/allocation code. I guess ideal would be if we
could fuse the custom allocator somehow directly into shmem.
Otoh once you start thrashing beyond system memory for gfx workloads it's
pretty hopeless anyway, and speed doesn't really matter anymore.
> > Also modern gpu apis pretty much assume you can malloc() and then use
> > that directly with the gpu.
>
> Which is fine as long as the GPU itself supports full 64-bit addressing
> (or always sits behind an iommu), and the platform doesn't impose
> addressing limit, which unfortunately some that are shipped right now
> still do :(
Yes, the userspace api people in khronos are occasionally a bit optimistic
:-)
> But userspace malloc really means dma_map_* anyway, so not really
> relevant for memory allocations.
It does tie in, since we'll want a dma_map which fails if a direct mapping
isn't possible. It also helps the driver code a lot if we could use the
same low-level flushing functions between our own memory (whatever that
is) and anon pages from malloc. And in all the cases if it's not possible,
we want a failure, not elaborate attempts at hiding the differences
between all possible architectures out there.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/2] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-08 11:41 UTC (permalink / raw)
To: robh+dt
Cc: devicetree, Neil Armstrong, martin.blumenstingl, netdev,
linux-kernel, linux-amlogic, Rob Herring, linux-arm-kernel
In-Reply-To: <20190808114101.29982-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Synopsys DWMAC Glue for Amlogic SoCs over to a YAML schemas.
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++++++++++++++++++
.../devicetree/bindings/net/meson-dwmac.txt | 71 -----------
.../devicetree/bindings/net/snps,dwmac.yaml | 5 +
3 files changed, 118 insertions(+), 71 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
new file mode 100644
index 000000000000..ae91aa9d8616
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson DWMAC Ethernet controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+# We need a select here so we don't match all nodes with 'snps,dwmac'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ required:
+ - compatible
+
+allOf:
+ - $ref: "snps,dwmac.yaml#"
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: GMAC main clock
+ - description: First parent clock of the internal mux
+ - description: Second parent clock of the internal mux
+
+ clock-names:
+ minItems: 3
+ maxItems: 3
+ items:
+ - const: stmmaceth
+ - const: clkin0
+ - const: clkin1
+
+ amlogic,tx-delay-ns:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description:
+ The internal RGMII TX clock delay (provided by this driver) in
+ nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns.
+ When phy-mode is set to "rgmii" then the TX delay should be
+ explicitly configured. When not configured a fallback of 2ns is
+ used. When the phy-mode is set to either "rgmii-id" or "rgmii-txid"
+ the TX clock delay is already provided by the PHY. In that case
+ this property should be set to 0ns (which disables the TX clock
+ delay in the MAC to prevent the clock from going off because both
+ PHY and MAC are adding a delay).
+ Any configuration is ignored when the phy-mode is set to "rmii".
+
+properties:
+ compatible:
+ additionalItems: true
+ maxItems: 3
+ items:
+ - enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ contains:
+ enum:
+ - snps,dwmac-3.70a
+ - snps,dwmac
+
+ reg:
+ items:
+ - description:
+ The first register range should be the one of the DWMAC controller
+ - description:
+ The second range is is for the Amlogic specific configuration
+ (for example the PRG_ETHERNET register range on Meson8b and newer)
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - phy-mode
+
+examples:
+ - |
+ ethmac: ethernet@c9410000 {
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0xc9410000 0x10000>, <0xc8834540 0x8>;
+ interrupts = <8>;
+ interrupt-names = "macirq";
+ clocks = <&clk_eth>, <&clkc_fclk_div2>, <&clk_mpll2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+ phy-mode = "rgmii";
+ };
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
deleted file mode 100644
index 1321bb194ed9..000000000000
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Amlogic Meson DWMAC Ethernet controller
-
-The device inherits all the properties of the dwmac/stmmac devices
-described in the file stmmac.txt in the current directory with the
-following changes.
-
-Required properties on all platforms:
-
-- compatible: Depending on the platform this should be one of:
- - "amlogic,meson6-dwmac"
- - "amlogic,meson8b-dwmac"
- - "amlogic,meson8m2-dwmac"
- - "amlogic,meson-gxbb-dwmac"
- - "amlogic,meson-axg-dwmac"
- Additionally "snps,dwmac" and any applicable more
- detailed version number described in net/stmmac.txt
- should be used.
-
-- reg: The first register range should be the one of the DWMAC
- controller. The second range is is for the Amlogic specific
- configuration (for example the PRG_ETHERNET register range
- on Meson8b and newer)
-
-Required properties on Meson8b, Meson8m2, GXBB and newer:
-- clock-names: Should contain the following:
- - "stmmaceth" - see stmmac.txt
- - "clkin0" - first parent clock of the internal mux
- - "clkin1" - second parent clock of the internal mux
-
-Optional properties on Meson8b, Meson8m2, GXBB and newer:
-- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
- by this driver) in nanoseconds. Allowed values
- are: 0ns, 2ns, 4ns, 6ns.
- When phy-mode is set to "rgmii" then the TX
- delay should be explicitly configured. When
- not configured a fallback of 2ns is used.
- When the phy-mode is set to either "rgmii-id"
- or "rgmii-txid" the TX clock delay is already
- provided by the PHY. In that case this
- property should be set to 0ns (which disables
- the TX clock delay in the MAC to prevent the
- clock from going off because both PHY and MAC
- are adding a delay).
- Any configuration is ignored when the phy-mode
- is set to "rmii".
-
-Example for Meson6:
-
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson6-dwmac", "snps,dwmac";
- reg = <0xc9410000 0x10000
- 0xc1108108 0x4>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clk81>;
- clock-names = "stmmaceth";
- }
-
-Example for GXBB:
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
- reg = <0x0 0xc9410000 0x0 0x10000>,
- <0x0 0xc8834540 0x0 0x8>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clkc CLKID_ETH>,
- <&clkc CLKID_FCLK_DIV2>,
- <&clkc CLKID_MPLL2>;
- clock-names = "stmmaceth", "clkin0", "clkin1";
- phy-mode = "rgmii";
- };
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 4377f511a51d..c78be15704b9 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -50,6 +50,11 @@ properties:
- allwinner,sun8i-r40-emac
- allwinner,sun8i-v3s-emac
- allwinner,sun50i-a64-emac
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
- snps,dwmac
- snps,dwmac-3.50a
- snps,dwmac-3.610
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: net: snps, dwmac: update reg minItems maxItems
From: Neil Armstrong @ 2019-08-08 11:41 UTC (permalink / raw)
To: robh+dt
Cc: devicetree, Neil Armstrong, martin.blumenstingl, netdev,
linux-kernel, Maxime Ripard, linux-amlogic, Rob Herring,
linux-arm-kernel
In-Reply-To: <20190808114101.29982-1-narmstrong@baylibre.com>
The Amlogic Meson DWMAC glue bindings needs a second reg cells for the
glue registers, thus update the reg minItems/maxItems to allow more
than a single reg cell.
Also update the allwinner,sun7i-a20-gmac.yaml derivative schema to specify
maxItems to 1.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
.../devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml | 3 +++
Documentation/devicetree/bindings/net/snps,dwmac.yaml | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
index 06b1cc8bea14..ef446ae166f3 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
@@ -17,6 +17,9 @@ properties:
compatible:
const: allwinner,sun7i-a20-gmac
+ reg:
+ maxItems: 1
+
interrupts:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 76fea2be66ac..4377f511a51d 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -61,7 +61,8 @@ properties:
- snps,dwxgmac-2.10
reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
interrupts:
minItems: 1
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 0/2] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-08 11:40 UTC (permalink / raw)
To: robh+dt
Cc: devicetree, Neil Armstrong, martin.blumenstingl, netdev,
linux-kernel, linux-amlogic, linux-arm-kernel
This patchsets converts the Amlogic Meson DWMAC glue bindings over to
YAML schemas using the already converted dwmac bindings.
The first patch is needed because the Amlogic glue needs a supplementary
reg cell to access the DWMAC glue registers.
Changes since v2:
- Added review tags
- Updated allwinner,sun7i-a20-gmac.yaml reg maxItems
Neil Armstrong (2):
dt-bindings: net: snps,dwmac: update reg minItems maxItems
dt-bindings: net: meson-dwmac: convert to yaml
.../net/allwinner,sun7i-a20-gmac.yaml | 3 +
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++++++++++++++++++
.../devicetree/bindings/net/meson-dwmac.txt | 71 -----------
.../devicetree/bindings/net/snps,dwmac.yaml | 8 +-
4 files changed, 123 insertions(+), 72 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Detecting AArch32 support from a AArch64 process in user space
From: Dave Martin @ 2019-08-08 11:31 UTC (permalink / raw)
To: Stefan Agner
Cc: Marc Zyngier, ynorov, will.deacon, linux-arm-kernel,
suzuki.poulose
In-Reply-To: <2adcb1ed626fb7829481b2b8d0ff54d1@agner.ch>
On Thu, Aug 08, 2019 at 12:17:26PM +0200, Stefan Agner wrote:
> On 2019-08-08 11:04, Marc Zyngier wrote:
[...]
> > Hey, you could create a VM, a vcpu and dump the ID registers by issuing
> > a set of KVM_GET_ONE_REG ioctls. Not necessarily recommended... ;-)
>
> I see, no no, I think I leave that exercise for somebody else to try :)
I think KVM guest AArch32 support can exist even when compat is
configured out though. So just because it works in a guest doesn't mean
that the host kernel supports it for userspace, IIUC.
Otherwise, this would be a fun hack ;)
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Detecting AArch32 support from a AArch64 process in user space
From: Dave Martin @ 2019-08-08 11:28 UTC (permalink / raw)
To: Stefan Agner
Cc: Marc Zyngier, ynorov, will.deacon, linux-arm-kernel,
suzuki.poulose
In-Reply-To: <09a5d28f865ef0bd034ba9acbe1b5334@agner.ch>
On Thu, Aug 08, 2019 at 12:30:03PM +0200, Stefan Agner wrote:
> On 2019-08-08 11:35, Dave Martin wrote:
> > On Thu, Aug 08, 2019 at 09:36:42AM +0200, Stefan Agner wrote:
> >> [resend this time with the correct mailing list address]
> >>
> >> Hello,
> >>
> >> I am trying to detect whether an ARMv8 system running in AArch64 state
> >> supports AArch32 state from a user space process. The arm64_features[]
> >> in
> >
> > Why? Is this just for diagnostic purposes, or some programmatic reason?
>
> The use case I currently have in mind is to decide whether to show
> 32-bit ARM Docker images in a UI (or arm32v7 images how it is nowadays
> called in Docker land).
>
> >
> > In the latter case, just try to do what ever it is you want to do that
> > depends on AArch32: if it fails, you don't have AArch32.
>
>
> Yeah one option I considered was just fetching a minimalistic arm32v7
> container, but still seems a bit excessive.
Ah, right.
So, I guess trying to set the personality or trying to exec a trivial
32-bit binary would answer that.
You could ship a trivial static binary with docker for that: trying
to run a whole container is probably overkill.
If trying to set the personality is more convenient though, that seems
an equally good approach in practice.
[...]
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [xlnx:xlnx_rebase_v4.19 1452/1504] drivers/staging/xroeframer/xroe_framer.o:(.bss+0x0): multiple definition of `lp'
From: kbuild test robot @ 2019-08-08 11:12 UTC (permalink / raw)
To: Bharat Kumar Gogada; +Cc: Michal Simek, kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
tree: https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.19
head: f0be99aa3709d7b1813796fc828053c4099c6b44
commit: 7d67b5fe62ec7a2b6c8fea1c4303a4e60a2989f5 [1452/1504] pci: xdma: pl: Remove of_pci_get_host_bridge_resources
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 7d67b5fe62ec7a2b6c8fea1c4303a4e60a2989f5
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/staging/xroeframer/xroe_framer.o:(.bss+0x0): multiple definition of `lp'
drivers/net/ethernet/xilinx/xilinx_tsn_switch.o:(.bss+0x0): first defined here
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 61001 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: Clarify when cpu_enable() is called
From: Suzuki K Poulose @ 2019-08-08 11:05 UTC (permalink / raw)
To: broonie, will; +Cc: catalin.marinas, linux-arm-kernel
In-Reply-To: <20190807165143.GI4048@sirena.co.uk>
On 07/08/2019 17:51, Mark Brown wrote:
> On Wed, Aug 07, 2019 at 05:01:08PM +0100, Will Deacon wrote:
>> On Tue, Aug 06, 2019 at 06:00:43PM +0100, Mark Brown wrote:
>
>>> - * Take the appropriate actions to enable this capability for this CPU.
>>> - * For each successfully booted CPU, this method is called for each
>>> - * globally detected capability.
>>> + * Take the appropriate actions to configure this capability for this
>>> + * CPU. This will be called on all CPUs in the system if the
>>> + * capability is detected anywhere in the system.
>
>> That's not quite right though either, is it? We need to take into account
>> the scope of the capability/erratum as well, since we don't /always/ call
>> this function for everybody.
>
> I guess you're thinking of the ARM64_CPUCAP_SYSTEM_FEATURE case where we
> match the feature on all CPUs so we could see the feature on some CPUs
> but not detect it as we're requiring a match on all?
We don't run the "match" check (i.e, detect) on all CPUs for SYSTEM scoped
features. Instead, we use sanitised feature set to detect the system features.
> Possibly the above
> should be "detected and enabled" rather than just "detected"? I can see
> how that might not be 100% clear, I was thinking of detection as passing
> all the match requirements including cross-CPU requirements but that
> could be more explicit. Perhaps something like:
>
> If this is called for any CPU in the system then it will be
> called for all of them.
>
> might cover it?
* Take the appropriate actions to configure this capability for the
* current CPU. If this capability is detected by the kernel, this will
* called on all the CPUs in the system, including the hotplugged
* CPUs.
*/
>
>> Suzuki, are there any cases where ->cpu_enable() may be called on a CPU
>> without the feature outside of ARM64_CPUCAP_LOCAL_CPU_ERRATUM or
>> ARM64_CPUCAP_BOOT_RESTRICTED_CPU_LOCAL_FEATURE?
>
> There's at least ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE, that was what
> caused me to notice what was happening (and get confused about why
> cpu_enable() was being called on non-matching CPUs).
Well, this is true for the ERRATUM too. In a nutshell, any LOCAL_CPU scoped
capability can trigger this on the CPUs.
>
> I don't see where we limit where cpu_enable() is called after we start
> calling it. When we're looping through in cpu_enable_non_boot_scope()
> we skip SCOPE_BOOT_CPU but those get cpu_enable() called in
> enable_cpu_capabilites() or verify_local_cpu_capabilities() depending on
> if it's the boot CPU or not. It's possible I'm missing something
> though.
There are two phases for any capability:
1) Detection - The kernel runs the matches() for the capability and marks
the cap available when it returns true. Depending on the scope of the
capability this could be done :
a) BOOT_CPU scope - Only on boot CPU. This must be only used for
features that are enabled very early in the kernel and get used
right away by the boot CPU. The checks use the raw CPU registers.
e.g, VHE - kernel runs in EL2, GIC NMI via Priority masking.
b) LOCAL_SCOPE - On boot CPU and all the secondary CPUs booted by the
kernel during smp bring up (before smp_cpus_done()) and before the
userspace gets control. The checks use the raw CPU registers.
e.g, CPU erratums
c) SYSTEM_SCOPE - After all the smp CPUs are booted by the kernel,
(i.e, from smp_cpus_done()). The checks are usually run with
sanitised feature register set, and gives you the system wide
state of the features.
The kernel finalizes the capabilities at this point and cannot be changed.
Thus, the hotplugged CPUs cannot affect the feature state and must comply
to the now advertised set of capabilities/features.
2) Enabling a capability - Once the kernel has detected the capability and has
been advertised (via cpu_hwcaps), each capability can take some action using
the cpu_enable() callback. This could include changing system/control register
configurations (e.g, trapping access to registers). The cpu_enable() is called
on all online CPUs in the system. Depending on the SCOPE of the capabilities,
the "cpu_enable" operation is triggered. For all CPUs that are brought online
after the capability was enabled (e.g hotplugged CPUs), this gets called via
check_local_cpu_capabilities()->verify_local_cpu_capabilities().
a) BOOT_CPU - The BOOT scope capabilities are enabled after the
boot CPU detects the features.
i.e, from setup_boot_cpu_capabilities() and is applied directly
on the boot CPU (because there are no other online CPUs). Thus, all
other CPUs (including the secondaries brought up by the kernel) trigger
the cpu_enable() for BOOT scope CPUs via check_local_cpu_capabilities().
b) All the other capabilities trigger the "cpu_enable" on all the online CPUs
after the system establishes the feature set in setup_system_capabilities().
And the cpu_enable() operations are batched via stop_machine() with
cpu_enable_non_boot_scope_capabilities() [ The boot CPU scope capabilities
are already enabled by now on all online CPUs].
Any new CPU that the kernel brings up must be triggered by the userspace and
they trigger the cpu_enable() operation as they are brought up individually
via check_local_cpu_capabilities()->verify_local_cpu_capabilities().
Does this help ?
Cheers
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: usb zero copy dma handling
From: Robin Murphy @ 2019-08-08 10:43 UTC (permalink / raw)
To: Greg KH; +Cc: yvahkhfo.1df7f8c2, linux-usb, security, linux-arm-kernel
In-Reply-To: <20190808100726.GB23844@kroah.com>
On 2019-08-08 11:07 am, Greg KH wrote:
> On Thu, Aug 08, 2019 at 10:46:24AM +0100, Robin Murphy wrote:
>> On 2019-08-08 9:58 am, Greg KH wrote:
>>> On Thu, Aug 08, 2019 at 10:46:36AM +0200, yvahkhfo.1df7f8c2@hashmail.org wrote:
>>>> Hello linux-usb and linux-arm.
>>>>
>>>> Ccing security@ because "the kernel dma code is mapping randomish
>>>> kernel/user mem to a user process" seems to have security implications
>>>> even though i didnt research that aspect past "its a 100% reliable way
>>>> to crash a raspi from userspace".
>>>>
>>>> tried submitting this through linux-arm-kernel ~2 weeks ago but
>>>> the only "response" i got was phishing-spam.
>>>> tried to follow up through raspi-internals chat, they suggested
>>>> i try linux-usb instead, but otoh the original reporter was
>>>> deflected from -usb to "try some other mls, they might care".
>>>> https://www.spinics.net/lists/linux-usb/msg173277.html
>>>>
>>>> if i am not following some arcane ritual or indenting convention required
>>>> by regular users of these lists i apologize in advance, but i am not a
>>>> kernel developer, i am just here as a user with a bug and a patch.
>>>> (and the vger FAQ link 404s...)
>>>
>>> The "arcane ritual" should be really well documented by now, it's in
>>> Documentation/SubmittingPatches in your kernel tree, and you can read it
>>> online at:
>>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>>>
>>>
>>>> i rediffed against HEAD even though the two weeks old patch still applied
>>>> cleanly with +2 offset.
>>>>
>>>> # stepping off soap box # actual technical content starts here #
>>>>
>>>> this is a followup to that thread from 2018-11:
>>>> https://www.spinics.net/lists/arm-kernel/msg685598.html
>>>>
>>>> the issue was discussed in more detail than i can claim
>>>> to fully understand back then, but no fix ever merged.
>>>> but i would really like to use rtl_433 on a raspi without
>>>> having to build a custom-patched kernel first.
>>>>
>>>> the attached patch is my stripdown/cleanup of a devel-diff
>>>> provided to me by the original reporter Steve Markgraf.
>>>> credits to him for the good parts, blame to me for the bad parts.
>>>>
>>>> this does not cover the additional case of "PIO-based usb controllers"
>>>> mainly because i dont understand what that means (or how to handle it)
>>>> and if its broken right now (as the thread indicates) it might
>>>> as well stay broken until someone who understands cares enough.
>>>>
>>>> could you please get this on track for merging?
>>>
>>>
>>>>
>>>> regards,
>>>> x23
>>>>
>>>>
>>>>
>>>
>>>> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
>>>> index b265ab5405f9..69594c2169ea 100644
>>>> --- a/drivers/usb/core/devio.c
>>>> +++ b/drivers/usb/core/devio.c
>>>> @@ -238,9 +238,14 @@ static int usbdev_mmap(struct file *file, struct vm_area_struct *vma)
>>>> usbm->vma_use_count = 1;
>>>> INIT_LIST_HEAD(&usbm->memlist);
>>>> +#ifdef CONFIG_X86
>>>> if (remap_pfn_range(vma, vma->vm_start,
>>>> virt_to_phys(usbm->mem) >> PAGE_SHIFT,
>>>> size, vma->vm_page_prot) < 0) {
>>>> +#else /* !CONFIG_X86 */
>>>> + if (dma_mmap_coherent(ps->dev->bus->sysdev,
>>>> + vma, mem, dma_handle, size) < 0) {
>>>> +#endif /* !CONFIG_X86 */
>>>> dec_usb_memory_use_count(usbm, &usbm->vma_use_count);
>>>> return -EAGAIN;
>>>> }
>>>
>>> First off, we need this in a format we could apply it in (hint, read the
>>> above links).
>>>
>>> But the main issue here is what exactly is this "fixing"? What is wrong
>>> with the existing code that non-x86 systems have such a problem with?
>>> Shouldn't all of these dma issues be handled by the platform with the
>>> remap_pfn_range() call itself?
>>
>> If usbm->mem is (or ever can be) a CPU address returned by
>> dma_alloc_coherent(), then doing virt_to_phys() on it is bogus and may yield
>> a nonsense 'PFN' to begin with. However, it it can can ever come from a
>> regular page allocation/kmalloc/vmalloc then unconditionally passing it to
>> dma_mmap_coherent wouldn't be right either.
>
> usbm->mem comes from a call to usb_alloc_coherent() which calls
> hcd_buffer_alloc() which tries to allocate memory in the best possible
> way for that specific host controller. If the host controller has a
> pool of memory, it uses that, if the host controller has PIO it uses
> kmalloc(), if there are some "pools" of host controller memory it uses
> dma_pool_alloc() and as a total last resort, calls dma_alloc_coherent().
>
> So yes, this could happen.
>
> So how to fix this properly? What host controller driver is being used
> here that ends up defaulting to dma_alloc_coherent()? Shouldn't that be
> fixed up no matter what?
>
> And then, if what you say is correct then a real fix for devio.c could
> be made, but that is NOT going to just depend on the arch the system is
> running on, as all of this depends on the host controller being accessed
> at that moment for that device.
Right, in that case we'd probably want some kind of usb_mmap_coherent()
helper to encapsulate equivalent logic to usb_{alloc,free}_coherent() to
figure out which remap operation is appropriate. It's absolutely not an
arch-specific thing.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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