* Re: [PATCH 06/32] pwm: tegra: convert to devm_platform_ioremap_resource
From: Uwe Kleine-König @ 2020-05-23 17:23 UTC (permalink / raw)
To: Yangtao Li
Cc: alexandre.belloni, heiko, linux-kernel, linux-tegra,
thierry.reding, linux-riscv, festevam, f.fainelli, shc_work,
khilman, wens, jonathanh, linux-rockchip, ludovic.desroches,
bcm-kernel-feedback-list, linux-imx, slemieux.tyco, linux-pwm,
rjui, s.hauer, mripard, vz, linux-mediatek, linux-rpi-kernel,
paul.walmsley, matthias.bgg, linux-amlogic, linux-arm-kernel,
sbranden, linux, palmer, kernel, shawnguo, claudiu.beznea,
nsaenzjulienne
In-Reply-To: <20191229080610.7597-6-tiny.windzz@gmail.com>
Hello,
On Sun, Dec 29, 2019 at 08:05:44AM +0000, Yangtao Li wrote:
> Use devm_platform_ioremap_resource() to simplify code.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
_______________________________________________
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 05/32] pwm: ep93xx: convert to devm_platform_ioremap_resource
From: Uwe Kleine-König @ 2020-05-23 17:24 UTC (permalink / raw)
To: Yangtao Li
Cc: alexandre.belloni, heiko, linux-kernel, linux-tegra,
thierry.reding, linux-riscv, festevam, f.fainelli, shc_work,
khilman, wens, jonathanh, linux-rockchip, ludovic.desroches,
bcm-kernel-feedback-list, linux-imx, slemieux.tyco, linux-pwm,
rjui, s.hauer, mripard, vz, linux-mediatek, linux-rpi-kernel,
paul.walmsley, matthias.bgg, linux-amlogic, linux-arm-kernel,
sbranden, linux, palmer, kernel, shawnguo, claudiu.beznea,
nsaenzjulienne
In-Reply-To: <20191229080610.7597-5-tiny.windzz@gmail.com>
Hello,
On Sun, Dec 29, 2019 at 08:05:43AM +0000, Yangtao Li wrote:
> Use devm_platform_ioremap_resource() to simplify code.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
_______________________________________________
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 03/32] pwm: rcar: convert to devm_platform_ioremap_resource
From: Uwe Kleine-König @ 2020-05-23 17:24 UTC (permalink / raw)
To: Yangtao Li
Cc: alexandre.belloni, heiko, linux-kernel, linux-tegra,
thierry.reding, linux-riscv, festevam, f.fainelli, shc_work,
khilman, wens, jonathanh, linux-rockchip, ludovic.desroches,
bcm-kernel-feedback-list, linux-imx, slemieux.tyco, linux-pwm,
rjui, s.hauer, mripard, vz, linux-mediatek, linux-rpi-kernel,
paul.walmsley, matthias.bgg, linux-amlogic, linux-arm-kernel,
sbranden, linux, palmer, kernel, shawnguo, claudiu.beznea,
nsaenzjulienne
In-Reply-To: <20191229080610.7597-3-tiny.windzz@gmail.com>
Hello,
On Sun, Dec 29, 2019 at 08:05:41AM +0000, Yangtao Li wrote:
> Use devm_platform_ioremap_resource() to simplify code.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
_______________________________________________
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 02/32] pwm: fsl-ftm: convert to devm_platform_ioremap_resource
From: Uwe Kleine-König @ 2020-05-23 17:24 UTC (permalink / raw)
To: Yangtao Li
Cc: alexandre.belloni, heiko, linux-kernel, linux-tegra,
thierry.reding, linux-riscv, festevam, f.fainelli, shc_work,
khilman, wens, jonathanh, linux-rockchip, ludovic.desroches,
bcm-kernel-feedback-list, linux-imx, slemieux.tyco, linux-pwm,
rjui, s.hauer, mripard, vz, linux-mediatek, linux-rpi-kernel,
paul.walmsley, matthias.bgg, linux-amlogic, linux-arm-kernel,
sbranden, linux, palmer, kernel, shawnguo, claudiu.beznea,
nsaenzjulienne
In-Reply-To: <20191229080610.7597-2-tiny.windzz@gmail.com>
Hello,
On Sun, Dec 29, 2019 at 08:05:40AM +0000, Yangtao Li wrote:
> Use devm_platform_ioremap_resource() to simplify code.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
_______________________________________________
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 15/32] pwm: rockchip: convert to devm_platform_ioremap_resource
From: Uwe Kleine-König @ 2020-05-23 17:25 UTC (permalink / raw)
To: Yangtao Li
Cc: alexandre.belloni, heiko, linux-kernel, linux-tegra,
thierry.reding, linux-riscv, festevam, f.fainelli, shc_work,
khilman, wens, jonathanh, linux-rockchip, ludovic.desroches,
bcm-kernel-feedback-list, linux-imx, slemieux.tyco, linux-pwm,
rjui, s.hauer, mripard, vz, linux-mediatek, linux-rpi-kernel,
paul.walmsley, matthias.bgg, linux-amlogic, linux-arm-kernel,
sbranden, linux, palmer, kernel, shawnguo, claudiu.beznea,
nsaenzjulienne
In-Reply-To: <20191229080610.7597-15-tiny.windzz@gmail.com>
Hello,
On Sun, Dec 29, 2019 at 08:05:53AM +0000, Yangtao Li wrote:
> Use devm_platform_ioremap_resource() to simplify code.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
_______________________________________________
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 14/32] pwm: meson: convert to devm_platform_ioremap_resource
From: Uwe Kleine-König @ 2020-05-23 17:25 UTC (permalink / raw)
To: Yangtao Li
Cc: alexandre.belloni, heiko, linux-kernel, linux-tegra,
thierry.reding, linux-riscv, festevam, f.fainelli, shc_work,
khilman, wens, jonathanh, linux-rockchip, ludovic.desroches,
bcm-kernel-feedback-list, linux-imx, slemieux.tyco, linux-pwm,
rjui, s.hauer, mripard, vz, linux-mediatek, linux-rpi-kernel,
paul.walmsley, matthias.bgg, linux-amlogic, linux-arm-kernel,
sbranden, linux, palmer, kernel, shawnguo, claudiu.beznea,
nsaenzjulienne
In-Reply-To: <20191229080610.7597-14-tiny.windzz@gmail.com>
Hello,
On Sun, Dec 29, 2019 at 08:05:52AM +0000, Yangtao Li wrote:
> Use devm_platform_ioremap_resource() to simplify code.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
_______________________________________________
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 32/32] pwm: atmel: convert to devm_platform_ioremap_resource
From: Uwe Kleine-König @ 2020-05-23 17:25 UTC (permalink / raw)
To: Yangtao Li
Cc: alexandre.belloni, heiko, linux-kernel, linux-tegra,
thierry.reding, linux-riscv, festevam, f.fainelli, shc_work,
khilman, wens, jonathanh, linux-rockchip, ludovic.desroches,
bcm-kernel-feedback-list, linux-imx, slemieux.tyco, linux-pwm,
rjui, s.hauer, mripard, vz, linux-mediatek, linux-rpi-kernel,
paul.walmsley, matthias.bgg, linux-amlogic, linux-arm-kernel,
sbranden, linux, palmer, kernel, shawnguo, claudiu.beznea,
nsaenzjulienne
In-Reply-To: <20191229080610.7597-32-tiny.windzz@gmail.com>
Hello,
On Sun, Dec 29, 2019 at 08:06:10AM +0000, Yangtao Li wrote:
> Use devm_platform_ioremap_resource() to simplify code.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
_______________________________________________
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 25/32] pwm: brcmstb: convert to devm_platform_ioremap_resource
From: Uwe Kleine-König @ 2020-05-23 17:25 UTC (permalink / raw)
To: Yangtao Li
Cc: alexandre.belloni, heiko, linux-kernel, linux-tegra,
thierry.reding, linux-riscv, festevam, f.fainelli, shc_work,
khilman, wens, jonathanh, linux-rockchip, ludovic.desroches,
bcm-kernel-feedback-list, linux-imx, slemieux.tyco, linux-pwm,
rjui, s.hauer, mripard, vz, linux-mediatek, linux-rpi-kernel,
paul.walmsley, matthias.bgg, linux-amlogic, linux-arm-kernel,
sbranden, linux, palmer, kernel, shawnguo, claudiu.beznea,
nsaenzjulienne
In-Reply-To: <20191229080610.7597-25-tiny.windzz@gmail.com>
Hello,
On Sun, Dec 29, 2019 at 08:06:03AM +0000, Yangtao Li wrote:
> Use devm_platform_ioremap_resource() to simplify code.
>
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
_______________________________________________
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] firmware: smccc: Add ARCH_SOC_ID support
From: Sudeep Holla @ 2020-05-23 17:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Francois Ozog, Lorenzo Pieralisi, Jose.Marinho,
Greg Kroah-Hartman, linux-kernel@vger.kernel.org, harb,
Sudeep Holla, Will Deacon, Linux ARM
In-Reply-To: <CAK8P3a33_5q1bNRrt+4sQ55QKrN12rOkuzmPH0BDujbug1RTyA@mail.gmail.com>
On Fri, May 22, 2020 at 08:41:59PM +0200, Arnd Bergmann wrote:
> On Fri, May 22, 2020 at 6:54 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
[...]
> >
> > Not sure if I understand your concerns completely here.
> >
> > Anyways I wanted to clarify that the jep106 encoding is applicable only
> > for manufacturer's id and not for SoC ID or revision. Not sure if that
> > changes anything about your concerns.
>
> The problem I see is that by looking at just the existing attributes,
> you have no way of telling what namespace the strings are in,
> and a script that tries pattern matching could confuse two
> hexadecimal numbers from a different namespace, such as
> pci vendor/device or usb vendor/device IDs that are similar
> in spirit to the jep106 codes.
>
Ah OK, understood.
> > > - I think we should have something unique in "family" just because
> > > existing scripts can use that as the primary indentifier
>
> This is part of the same issue: If we put just "jep106 identified SoC"
> as the "family", it would be something a driver could match against.
>
I understand that and that's the reason I was introducing new field as
manufacture but I now see there is no point in adding that.
[...]
> > But this just indicates manufacturer id and nothing related to SoC family.
> > If it is jep106:043b, all it indicates is Arm Ltd and assigning it to
> > family doesn't sound right to me.
> >
> > I had requests for both of the above during the design of interface but
> > I was told vendors were happy with the interface. I will let the authors
> > speak about that.
>
> In most cases, the existing drivers put a hardcoded string into the
> family, such as
>
> "Samsung Exynos"
> "Freescale i.MX"
> "Amlogic Meson"
>
> or slightly more specific
>
> "R-Car Gen2"
>
Hmmm....
> Having a numeric identifier for the SoC manufacturer here is a
> bit more coarse than that, but would be similar in spirit.
>
Agreed.
[..]
> >
> > OK, I agree on ease part. But for me, we don't have any property in the
> > list to indicate the vendor/manufacturer's name. I don't see issue adding
> > one, name can be fixed as jep106_identification_code is too specific.
> >
> > How about manufacturer with the value in the format "jep106:1234" if
> > it is not normal string but jep106 encoding.
>
> I don't think we need a real name like "Arm" or "Samsung" here,
> but just a number is not enough, it should at least be something
> that can be assumed to never conflict with the name of a chip
> by another scheme.
>
Fair enough.
> jep106:5678 (the IMP_DEF_SOC_ID field in my example) would
> probably be sufficient to not conflict with a another soc_device
> driver, but is quite likely to clash with an ID used by another
> manufacturer.
>
IIUC, you are fine with "jep106:1234:5678" where 1234 is jep106 manufacture
id code and 5678 is soc_id as it may avoid all the conflicts across
the manufacture namespaces.
> jep106:1234 (the manufacturer ID) in turn seems too broad from
> the soc_id field, as that would include every chip made by one
> company.
>
I understand, and IIUC you prefer this to be embedded with soc_id
especially to avoid namespace conflicts which makes sense.
Thanks for all the discussion and valuable inputs. I am now bit nervous
to add SoC info from SMCCC ARCH_SOC_ID to sysfs yet as we need more info
especially "machine" and "serial_number" for elsewhere(OEM firmware mostly
from DT or ACPI).
TBH, the mix might be bit of a mess as there are soc drivers that rely
on DT completely today. Anyways, this SOC_ID can be added as library that
can be used by a *generic* soc driver once we define a standard way to
fetch other information("machine" and "serial_number"). I am happy to
get suggestions on that front especially from you and Francois as you
have got some context already.
--
Regards,
Sudeep
_______________________________________________
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 30/32] pwm: hibvt: do some cleanup
From: Uwe Kleine-König @ 2020-05-23 17:44 UTC (permalink / raw)
To: Yangtao Li, thierry.reding
Cc: alexandre.belloni, heiko, linux-kernel, linux-tegra, linux-riscv,
festevam, f.fainelli, shc_work, khilman, wens, jonathanh,
linux-rockchip, ludovic.desroches, bcm-kernel-feedback-list,
linux-imx, slemieux.tyco, linux-pwm, rjui, s.hauer, mripard, vz,
linux-mediatek, linux-rpi-kernel, paul.walmsley, matthias.bgg,
linux-amlogic, linux-arm-kernel, sbranden, linux, palmer, kernel,
shawnguo, claudiu.beznea, nsaenzjulienne
In-Reply-To: <20200220204152.p6rublsssifvvnvk@pengutronix.de>
On Thu, Feb 20, 2020 at 09:41:52PM +0100, Uwe Kleine-König wrote:
> On Sun, Dec 29, 2019 at 08:06:08AM +0000, Yangtao Li wrote:
> > Use devm_platform_ioremap_resource() to simplify code.
> > 'i' and 'ret' are variables of the same type and there is no
> > need to use two lines.
>
> I think I wouldn't have merged these two lines, but I don't feel strong
> here. The other 31 patches are clean replacements.
>
> But I also don't think respining just for this minor thing is worth the
> effort, so:
>
> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> for the whole series. (Not sure it is sensible to ack each patch
> individually, @Thierry, tell me if this simplifies things for you.)
I took a deeper look now and added Reviewed-by for all other patches to
ease application. So doing the same here:
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
FTR: I'd do the following now:
for patch in 1216003 1216065 1216063 1216005 1216062 1216061 1216059 1216057 1216054 1216056 1216051 1216050 1216048 1216010 1216044 1216046 1216042 1216041 1216036 1216037 1216034 1216032 1216030 1216013 1216029 1216025 1216026 1216024 1216015 1216021 1216017 1216019; do
pwclient git-am -m -s $patch && pwclient update -s "Accepted" -c "$(git rev-parse HEAD)" $patch || break
done
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
_______________________________________________
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/2] hwrng: iproc-rng200 - Set the quality value
From: Stephan Müller @ 2020-05-23 18:46 UTC (permalink / raw)
To: Stefan Wahren, Lukasz Stelmach
Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger,
Greg Kroah-Hartman, Matt Mackall, linux-kernel,
Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz,
Kukjin Kim, Arnd Bergmann, linux-crypto, Ray Jui,
bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel
In-Reply-To: <dleftjftbtyubp.fsf%l.stelmach@samsung.com>
Am Donnerstag, 21. Mai 2020, 21:14:02 CEST schrieb Lukasz Stelmach:
Hi Lukasz,
> It was <2020-05-21 czw 13:00>, when Stefan Wahren wrote:
> > Hi Lukasz,
> >
> > Am 19.05.20 um 23:25 schrieb Łukasz Stelmach:
> >> The value was estimaded with ea_iid[1] using on 10485760 bytes read from
> >> the RNG via /dev/hwrng. The min-entropy value calculated using the most
> >> common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464.
> >
> > could you please mention in the commit the used hardware
> > implementation(s) of iproc-rng200 to get this quality?
> >
> > AFAIK there is still no public register description at least for the
> > bcm2711. So is it safe to assume that the suggested quality applies to
> > all possible configurations?
>
> I've learnt that there is a post-processing unit in RNG200 that tests
> the output of the noise generator and fills FIFO only with data that
> passes FIPS tests. Unlike simmilar unit in Exynos, it cannot be disabled
> or bypassed. Therefore, after Stephan Mueller's thorough explanations I
> am considering dropping this patch in v3.
If you would be more clear what that FIPS test is all about, we may be able to
identify whether it affects the entropy behavior or not. E.g. if it is the
SP800-90B health test following SP880-90B section 4.4, this does not affect
entropy and you could apply your calculation.
>
> However, I stil am still not 100% convinced that it is impossible to
> assign the quality a reasonable non-zero value in such case.
>
> > Thanks
> > Stefan
> >
> >> [1]
> >> https://protect2.fireeye.com/url?k=da4735b2-87d99b28-da46befd-0cc47a336f
> >> ae-e1c21080bc6ab1e4&q=1&u=https%3A%2F%2Fgithub.com%2Fusnistgov%2FSP800-90
> >> B_EntropyAssessment [2]
> >> https://csrc.nist.gov/publications/detail/sp/800-90b/final
> >>
> >> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
> >> ---
> >>
> >> drivers/char/hw_random/iproc-rng200.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/char/hw_random/iproc-rng200.c
> >> b/drivers/char/hw_random/iproc-rng200.c index 32d9fe61a225..95669ece050f
> >> 100644
> >> --- a/drivers/char/hw_random/iproc-rng200.c
> >> +++ b/drivers/char/hw_random/iproc-rng200.c
> >> @@ -199,6 +199,7 @@ static int iproc_rng200_probe(struct platform_device
> >> *pdev)>>
> >> priv->rng.read = iproc_rng200_read,
> >> priv->rng.init = iproc_rng200_init,
> >> priv->rng.cleanup = iproc_rng200_cleanup,
> >>
> >> + priv->rng.quality = 1000,
> >>
> >> /* Register driver */
> >> ret = devm_hwrng_register(dev, &priv->rng);
Ciao
Stephan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr
From: Stephan Müller @ 2020-05-23 18:52 UTC (permalink / raw)
To: Gilad Ben-Yossef, Ard Biesheuvel
Cc: Eric Biggers, Linux Crypto Mailing List, Linux ARM
In-Reply-To: <CAMj1kXFJJcg-YeSw+_FDfyOvjQTJ6w1YyKqWaxCWSjDhRLEDoA@mail.gmail.com>
Am Donnerstag, 21. Mai 2020, 15:23:41 CEST schrieb Ard Biesheuvel:
Hi Ard,
> On Thu, 21 May 2020 at 15:01, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> > Hi Ard,
> >
> > Thank you for looping me in.
> >
> > On Wed, May 20, 2020 at 10:09 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > On Wed, 20 May 2020 at 09:01, Stephan Mueller <smueller@chronox.de>
wrote:
> > > > Am Mittwoch, 20. Mai 2020, 08:54:10 CEST schrieb Ard Biesheuvel:
> > > >
> > > > Hi Ard,
> > > >
> > > > > On Wed, 20 May 2020 at 08:47, Stephan Mueller <smueller@chronox.de>
wrote:
> > > ...
> > >
> > > > > > The state of all block chaining modes we currently have is defined
> > > > > > with
> > > > > > the
> > > > > > IV. That is the reason why I mentioned it can be implemented
> > > > > > stateless
> > > > > > when I am able to get the IV output from the previous operation.
> > > > >
> > > > > But it is simply the same as the penultimate block of ciphertext. So
> > > > > you can simply capture it after encrypt, or before decrypt. There is
> > > > > really no need to rely on the CTS transformation to pass it back to
> > > > > you via the buffer that is only specified to provide an input to the
> > > > > CTS transform.
> > > >
> > > > Let me recheck that as I am not fully sure on that one. But if it can
> > > > be
> > > > handled that way, it would make life easier.
> > >
> > > Please refer to patch 2. The .iv_out test vectors were all simply
> > > copied from the appropriate offset into the associated .ctext member.
> >
> > Not surprisingly since to the best of my understanding this behaviour
> > is not strictly specified, ccree currently fails the IV output check
> > with the 2nd version of the patch.
>
> That is what I suspected, hence the cc:
> > If I understand you correctly, the expected output IV is simply the
> > next to last block of the ciphertext?
>
> Yes. But this happens to work for the generic case because the CTS
> driver itself requires the encapsulated CBC mode to return the output
> IV, which is simply passed through back to the caller. CTS mode itself
> does not specify any kind of output IV, so we should not rely on this
> behavior.
Note, the update to the spec based on your suggestion is already in a merge
request:
https://github.com/usnistgov/ACVP/issues/860
Thanks for your input.
Ciao
Stephan
_______________________________________________
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] arm64: dts: mediatek: add cpufreq and cci devfreq nodes for mt8183
From: Matthias Brugger @ 2020-05-23 19:04 UTC (permalink / raw)
To: Andrew-sh.Cheng, Rob Herring, Mark Rutland, devicetree
Cc: srv_heupstream, linux-mediatek, linux-kernel, linux-arm-kernel
In-Reply-To: <1576826785-3867-1-git-send-email-andrew-sh.cheng@mediatek.com>
On 20/12/2019 08:26, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng" <andrew-sh.cheng@mediatek.com>
>
> add cpufreq and cci devfreq nodes for mt8183
>
> Depend on regulator node patch:
> https://patchwork.kernel.org/patch/11284617/
>
> Signed-off-by: Andrew-sh.Cheng <andrew-sh.cheng@mediatek.com>
> ---
> arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 36 ++++
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 245 ++++++++++++++++++++++++++++
> 2 files changed, 281 insertions(+)
>
[...]
> +
> + cci: cci {
> + compatible = "mediatek,mt8183-cci";
I wasn't able to find anyprovider for this compatible.
I'll drop this patch from my queue.
Regards,
Matthias
_______________________________________________
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] firmware: smccc: Add ARCH_SOC_ID support
From: Arnd Bergmann @ 2020-05-23 19:40 UTC (permalink / raw)
To: Sudeep Holla
Cc: Mark Rutland, Francois Ozog, Lorenzo Pieralisi, Jose.Marinho,
Greg Kroah-Hartman, linux-kernel@vger.kernel.org, harb,
Will Deacon, Linux ARM
In-Reply-To: <20200523172721.GC18810@bogus>
On Sat, May 23, 2020 at 7:27 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
> On Fri, May 22, 2020 at 08:41:59PM +0200, Arnd Bergmann wrote:
> > On Fri, May 22, 2020 at 6:54 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> > jep106:5678 (the IMP_DEF_SOC_ID field in my example) would
> > probably be sufficient to not conflict with a another soc_device
> > driver, but is quite likely to clash with an ID used by another
> > manufacturer.
> >
>
> IIUC, you are fine with "jep106:1234:5678" where 1234 is jep106 manufacture
> id code and 5678 is soc_id as it may avoid all the conflicts across
> the manufacture namespaces.
I think either jep106:5678 or jep106:1234:5678 (or some variation with
different field separators if you prefer) would be fine here.
> > jep106:1234 (the manufacturer ID) in turn seems too broad from
> > the soc_id field, as that would include every chip made by one
> > company.
> >
>
> I understand, and IIUC you prefer this to be embedded with soc_id
> especially to avoid namespace conflicts which makes sense.
>
> Thanks for all the discussion and valuable inputs. I am now bit nervous
> to add SoC info from SMCCC ARCH_SOC_ID to sysfs yet as we need more info
> especially "machine" and "serial_number" for elsewhere(OEM firmware mostly
> from DT or ACPI).
I probably wouldn't mix those in with the same driver. If machine and
serial_number have no smccc interface, then they should be left out,
but there could be a separate soc_device that gets that information
by other means, usually using one of the existing hardware id register
drivers.
> TBH, the mix might be bit of a mess as there are soc drivers that rely
> on DT completely today. Anyways, this SOC_ID can be added as library that
> can be used by a *generic* soc driver once we define a standard way to
> fetch other information("machine" and "serial_number"). I am happy to
> get suggestions on that front especially from you and Francois as you
> have got some context already.
Well, I suppose we could have the entire data from the smccc interface
in a central place somewhere, such as (to stay with my example)
"1234:5678:9abcdef0" in an attribute of any soc_device driver that
adds a call to a library function for the jep106 ID, or possibly in
/sys/firmware or even a field added to /proc/cpuinfo.
Arnd
_______________________________________________
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] pwm: rockchip: simplify rockchip_pwm_get_state()
From: Uwe Kleine-König @ 2020-05-23 20:01 UTC (permalink / raw)
To: David Wu
Cc: linux-pwm, Heiko Stuebner, Rasmus Villemoes, linux-kernel,
linux-rockchip, Thierry Reding, linux-arm-kernel
In-Reply-To: <20190919111115.5oraof2bdl4627xv@pengutronix.de>
Hello David,
On Thu, Sep 19, 2019 at 01:11:15PM +0200, oUwe Kleine-König wrote:
> On Thu, Sep 19, 2019 at 11:17:27AM +0200, Rasmus Villemoes wrote:
> > The way state->enabled is computed is rather convoluted and hard to
> > read - both branches of the if() actually do the exact same thing. So
> > remove the if(), and further simplify "<boolean condition> ? true :
> > false" to "<boolean condition>".
> >
> > Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> > ---
> > I stumbled on this while trying to understand how the pwm subsystem
> > works. This patch is a semantic no-op, but it's also possible that,
> > say, the first branch simply contains a "double negative" so either
> > the != should be == or the "false : true" should be "true : false".
>
> The change looks obviously right, it's a noop.
>
> I share your doubts however. The construct was introduced in commit
> 831b2790507b ("pwm: rockchip: Use same PWM ops for each IP") by David
> Wu.
>
> Before there were rockchip_pwm_get_state_v1 for the supports_polarity =
> false case and rockchip_pwm_get_state_v2 for supports_polarity = true.
>
> In both state->enabled was assigned true if ((val & enable_conf) ==
> enable_conf). So I assume everything is fine.
>
> A confirmation by David would be great though.
This is still open. Can you please have a look at
https://patchwork.ozlabs.org/project/linux-pwm/patch/20190919091728.24756-1-linux@rasmusvillemoes.dk/
and verify it's correct?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] dt-bindings: dma: uart: mtk: fix example
From: matthias.bgg @ 2020-05-23 20:15 UTC (permalink / raw)
To: sean.wang, vkoul, robh+dt
Cc: devicetree, Matthias Brugger, linux-kernel, dmaengine,
linux-mediatek, matthias.bgg, linux-arm-kernel
From: Matthias Brugger <mbrugger@suse.com>
The binding example is missing the fallback compatible.
This is needed as the driver only matches against mt6577.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
---
Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt b/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt
index 5d6f98c43e3d..2117db0ce4f2 100644
--- a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt
+++ b/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt
@@ -21,7 +21,8 @@ Required properties:
Examples:
apdma: dma-controller@11000400 {
- compatible = "mediatek,mt2712-uart-dma";
+ compatible = "mediatek,mt2712-uart-dma",
+ "mediatek,mt6577-uart-dma";
reg = <0 0x11000400 0 0x80>,
<0 0x11000480 0 0x80>,
<0 0x11000500 0 0x80>,
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [GIT PULL] arm64: DT updates for v5.8 (2nd round)
From: Matthias Brugger @ 2020-05-23 21:03 UTC (permalink / raw)
To: arm-soc, SoC Team
Cc: Jjian Zhou, Biao Huang, Long Cheng,
moderated list:ARM/Mediatek SoC support,
linux-arm-kernel@lists.infradead.org, matthias.bgg@kernel.org,
Enric Balletbo i Serra, Hsin-Hsiung Wang
Hi Olof and Arnd,
This is the second round of DTS updates for arm64 based SoCs from MediaTek.
It's based on the first pull request I send on 16th of May [1].
Please have a look and apply :)
Regards,
Matthias
[1]
https://lore.kernel.org/linux-mediatek/2794a8db-c14f-ac34-9e28-9f3700db6c4c@gmail.com/
---
The following changes since commit f0e5405b9ebf084c34c41f5d38a0013bee166f4d:
arm64: dts: mt8173: Add capacity-dmips-mhz attributes (2020-05-16 18:36:40 +0200)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v5.7-next-dts64.2
for you to fetch changes up to 21eb9ec7c3e6f5c6ddae2e19768fd7eab2cd3b63:
arm: dts: mt2712: add uart APDMA to device tree (2020-05-23 21:03:13 +0200)
----------------------------------------------------------------
mt8183:
- add PMIC mt6358
- add MMC node
mt2712:
- enable APDMA for the uart node
- add ethernet gmac node
mmsys:
- change node name to syscon as mmsys no longer represents only clocks
but also the DRM subsystem
----------------------------------------------------------------
Biao Huang (1):
arm64: dts: mt2712: add ethernet device node
Enric Balletbo i Serra (1):
arm64: dts: mt8173: Fix mmsys node name
Hsin-Hsiung Wang (1):
arm64: dts: mt6358: add PMIC MT6358 related nodes
Long Cheng (1):
arm: dts: mt2712: add uart APDMA to device tree
Matthias Brugger (1):
arm64: dts: mt6797: Fix mmsys node name
jjian zhou (1):
arm64: dts: mt8183: add mmc node
arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 74 ++++++
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 116 +++++++++
arch/arm64/boot/dts/mediatek/mt6358.dtsi | 358 ++++++++++++++++++++++++++++
arch/arm64/boot/dts/mediatek/mt6797.dtsi | 2 +-
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 +-
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 147 ++++++++++++
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 24 ++
7 files changed, 721 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6358.dtsi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] drivers: soc: mediatek: updates for v5.8 (2nd round)
From: Matthias Brugger @ 2020-05-23 21:09 UTC (permalink / raw)
To: arm-soc, SoC Team
Cc: Enric Balletbo i Serra, moderated list:ARM/Mediatek SoC support,
linux-arm-kernel@lists.infradead.org, matthias.bgg@kernel.org
Hi Arnd,
Hi Olof,
Please have a look on the following patches for the SoC drivers from MediaTek.
Basically it's the conversion of the missing drivers to the new mmsys approach I
mentioned in the first pull request [1]. This request is based on this first
pull request. With this new patches we finish the transition of all clock
drivers to be probed via the mmsys SoC driver. This will allow us to enable DRM
support on them (e.g. for mt7623 aka BananaPi-R2 there are some patches which
need to be rebased).
Please have a look and pull :)
Regards,
Matthias
[1]
https://lore.kernel.org/linux-mediatek/2cf27d33-59c6-023b-9993-57a2639824ea@gmail.com/
---
The following changes since commit 154910f886762a2817ddddad7fc6fed8c23b4ad1:
ARM: mediatek: Replace <linux/clk-provider.h> by <linux/of_clk.h> (2020-05-15
17:19:41 +0200)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
tags/v5.7-next-soc.2
for you to fetch changes up to 32956dda97577f0960eb3d9d9aff7338d0cf4cc4:
clk/soc: mediatek: mt6779: Bind clock driver from platform device (2020-05-20
12:49:35 +0200)
----------------------------------------------------------------
- make mmsys kconfig entry to depend on ARCH_MEDIATEK instead of a specific SoC
- move clock driver to bind against the new mmsys driver
(mt2712, mt2701, mt8183, mt6797 and mt6779)
----------------------------------------------------------------
Enric Balletbo i Serra (3):
soc: mediatek: Enable mmsys driver by default if Mediatek arch is selected
clk / soc: mediatek: Bind clock and gpu driver for mt2712
clk / soc: mediatek: Bind clock and gpu driver for mt2701
Matthias Brugger (3):
clk/soc: mediatek: mt8183: Bind clock driver from platform device
clk/soc: mediatek: mt6797: Bind clock driver from platform device
clk/soc: mediatek: mt6779: Bind clock driver from platform device
drivers/clk/mediatek/clk-mt2701-mm.c | 9 ++------
drivers/clk/mediatek/clk-mt2712-mm.c | 9 ++------
drivers/clk/mediatek/clk-mt6779-mm.c | 9 ++------
drivers/clk/mediatek/clk-mt6797-mm.c | 9 ++------
drivers/clk/mediatek/clk-mt8183-mm.c | 9 ++------
drivers/soc/mediatek/Kconfig | 3 +--
drivers/soc/mediatek/mtk-mmsys.c | 40 ++++++++++++++++++++++++++++++++++++
7 files changed, 51 insertions(+), 37 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v3 1/2] thermal: core: Let thermal zone device's mode be stored in its struct
From: Daniel Lezcano @ 2020-05-23 21:24 UTC (permalink / raw)
To: Andrzej Pietrasiewicz, linux-pm
Cc: Rafael J . Wysocki, platform-driver-x86, Shawn Guo, kernel,
Fabio Estevam, Amit Kucheria, linux-acpi, NXP Linux Team,
Darren Hart, Zhang Rui, Gayatri Kammela, Len Brown,
Barlomiej Zolnierkiewicz, Sascha Hauer, Ido Schimmel, Jiri Pirko,
Thomas Gleixner, Allison Randal, linux-arm-kernel,
Support Opensource, netdev, Peter Kaestle,
Pengutronix Kernel Team, Enrico Weigelt, David S . Miller,
Andy Shevchenko
In-Reply-To: <20200417162020.19980-2-andrzej.p@collabora.com>
Hi Andrzej,
On 17/04/2020 18:20, Andrzej Pietrasiewicz wrote:
> Thermal zone devices' mode is stored in individual drivers. This patch
> changes it so that mode is stored in struct thermal_zone_device instead.
>
> As a result all driver-specific variables storing the mode are not needed
> and are removed. Consequently, the get_mode() implementations have nothing
> to operate on and need to be removed, too.
>
> Some thermal framework specific functions are introduced:
>
> thermal_zone_device_get_mode()
> thermal_zone_device_set_mode()
> thermal_zone_device_enable()
> thermal_zone_device_disable()
>
> thermal_zone_device_get_mode() and its "set" counterpart take tzd's lock
> and the "set" calls driver's set_mode() if provided, so the latter must
> not take this lock again. At the end of the "set"
> thermal_zone_device_update() is called so drivers don't need to repeat this
> invocation in their specific set_mode() implementations.
>
> The scope of the above 4 functions is purposedly limited to the thermal
> framework and drivers are not supposed to call them. This encapsulation
> does not fully work at the moment for some drivers, though:
>
> - platform/x86/acerhdf.c
> - drivers/thermal/imx_thermal.c
> - drivers/thermal/intel/intel_quark_dts_thermal.c
> - drivers/thermal/of-thermal.c
>
> and they manipulate struct thermal_zone_device's members directly.
>
> struct thermal_zone_params gains a new member called initial_mode, which
> is used to set tzd's mode at registration time.
>
> The sysfs "mode" attribute is always exposed from now on, because all
> thermal zone devices now have their get_mode() implemented at the generic
> level and it is always available. Exposing "mode" doesn't hurt the drivers
> which don't provide their own set_mode(), because writing to "mode" will
> result in -EPERM, as expected.
The result is great, that is a nice cleanup of the thermal framework.
After review it appears there are still problems IMO, especially with
the suspend / resume path. The patch is big, it is a bit complex to
comment. I suggest to re-org the changes as following:
- patch 1 : Add the four functions:
* thermal_zone_device_set_mode()
* thermal_zone_device_enable()
* thermal_zone_device_disable()
* thermal_zone_device_is_enabled()
*but* do not export thermal_zone_device_set_mode(), it must stay private
to the thermal framework ATM.
- patch 2 : Add the mode THERMAL_DEVICE_SUSPENDED
In the thermal_pm_notify() in the:
- PM_SUSPEND_PREPARE case, set the mode to THERMAL_DEVICE_SUSPENDED if
the mode is THERMAL_DEVICE_ENABLED
- PM_POST_SUSPEND case, set the mode to THERMAL_DEVICE_ENABLED, if the
mode is THERMAL_DEVICE_SUSPENDED
- patch 3 : Change the monitor function
Change monitor_thermal_zone() function to set the polling to zero if the
mode is THERMAL_DEVICE_DISABLED
- patch 4 : Do the changes to remove get_mode() ops
Make sure there is no access to tz->mode from the drivers anymore but
use of the functions of patch 1. IMO, this is the tricky part because a
part of the drivers are not calling the update after setting the mode
while the function thermal_zone_device_enable()/disable() call update
via the thermal_zone_device_set_mode(), so we must be sure to not break
anything.
- patch 5 : Do the changes to remove set_mode() ops users
As the patch 3 sets the polling to zero, the routine in the driver
setting the polling to zero is no longer needed (eg. in the mellanox
driver). I expect int300 to be the last user of this ops, hopefully we
can find a way to get rid of the specific call done inside and then
remove the ops.
The initial_mode approach looks hackish, I suggest to make the default
the thermal zone disabled after creating and then explicitly enable it.
Note that is what do a lot of drivers already.
Hopefully, these changes are git-bisect safe.
Does it make sense ?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr
From: Ard Biesheuvel @ 2020-05-23 22:40 UTC (permalink / raw)
To: Stephan Müller
Cc: Eric Biggers, Gilad Ben-Yossef, Linux Crypto Mailing List,
Linux ARM
In-Reply-To: <9730423.nUPlyArG6x@positron.chronox.de>
On Sat, 23 May 2020 at 20:52, Stephan Müller <smueller@chronox.de> wrote:
>
> Am Donnerstag, 21. Mai 2020, 15:23:41 CEST schrieb Ard Biesheuvel:
>
> Hi Ard,
>
> > On Thu, 21 May 2020 at 15:01, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> > > Hi Ard,
> > >
> > > Thank you for looping me in.
> > >
> > > On Wed, May 20, 2020 at 10:09 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > On Wed, 20 May 2020 at 09:01, Stephan Mueller <smueller@chronox.de>
> wrote:
> > > > > Am Mittwoch, 20. Mai 2020, 08:54:10 CEST schrieb Ard Biesheuvel:
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > > On Wed, 20 May 2020 at 08:47, Stephan Mueller <smueller@chronox.de>
> wrote:
> > > > ...
> > > >
> > > > > > > The state of all block chaining modes we currently have is defined
> > > > > > > with
> > > > > > > the
> > > > > > > IV. That is the reason why I mentioned it can be implemented
> > > > > > > stateless
> > > > > > > when I am able to get the IV output from the previous operation.
> > > > > >
> > > > > > But it is simply the same as the penultimate block of ciphertext. So
> > > > > > you can simply capture it after encrypt, or before decrypt. There is
> > > > > > really no need to rely on the CTS transformation to pass it back to
> > > > > > you via the buffer that is only specified to provide an input to the
> > > > > > CTS transform.
> > > > >
> > > > > Let me recheck that as I am not fully sure on that one. But if it can
> > > > > be
> > > > > handled that way, it would make life easier.
> > > >
> > > > Please refer to patch 2. The .iv_out test vectors were all simply
> > > > copied from the appropriate offset into the associated .ctext member.
> > >
> > > Not surprisingly since to the best of my understanding this behaviour
> > > is not strictly specified, ccree currently fails the IV output check
> > > with the 2nd version of the patch.
> >
> > That is what I suspected, hence the cc:
> > > If I understand you correctly, the expected output IV is simply the
> > > next to last block of the ciphertext?
> >
> > Yes. But this happens to work for the generic case because the CTS
> > driver itself requires the encapsulated CBC mode to return the output
> > IV, which is simply passed through back to the caller. CTS mode itself
> > does not specify any kind of output IV, so we should not rely on this
> > behavior.
>
> Note, the update to the spec based on your suggestion is already in a merge
> request:
>
> https://github.com/usnistgov/ACVP/issues/860
>
> Thanks for your input.
>
Thanks for the head's up. I've left a comment there, as the proposed
change is not equivalent to the unspecified current behavior.
_______________________________________________
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 0/5] net: provide a devres variant of register_netdev()
From: David Miller @ 2020-05-23 23:56 UTC (permalink / raw)
To: brgl
Cc: edwin.peer, devicetree, bgolaszewski, stephane.leprovost, arnd,
corbet, netdev, sean.wang, linux-kernel, fparent, pedro.tsai,
linux-mediatek, andrew.perepech, john, matthias.bgg, kuba,
Mark-MC.Lee, linux-arm-kernel, hkallweit1
In-Reply-To: <20200523132711.30617-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Sat, 23 May 2020 15:27:06 +0200
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Using devres helpers allows to shrink the probing code, avoid memory leaks in
> error paths make sure the order in which resources are freed is the exact
> opposite of their allocation. This series proposes to add a devres variant
> of register_netdev() that will only work with net_device structures whose
> memory is also managed.
>
> First we add the missing documentation entry for the only other networking
> devres helper: devm_alloc_etherdev().
>
> Next we move devm_alloc_etherdev() into a separate source file.
>
> We then use a proxy structure in devm_alloc_etherdev() to improve readability.
>
> Last: we implement devm_register_netdev() and use it in mtk-eth-mac driver.
>
> v1 -> v2:
> - rebase on top of net-next after driver rename, no functional changes
Series applied, thank you.
_______________________________________________
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] thermal: imx8mm: Add get_trend ops
From: Anson Huang @ 2020-05-24 0:50 UTC (permalink / raw)
To: Daniel Lezcano, rui.zhang@intel.com, amit.kucheria@verdurent.com,
shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <6a4d31e4-8a24-2e9f-aa49-bec8258ead4c@linaro.org>
Hi, Daniel
> Subject: Re: [PATCH] thermal: imx8mm: Add get_trend ops
>
> On 23/05/2020 02:35, Anson Huang wrote:
> > Hi, Daniel
> >
> >
> >> Subject: Re: [PATCH] thermal: imx8mm: Add get_trend ops
> >>
> >> On 13/05/2020 04:58, Anson Huang wrote:
> >>> Add get_trend ops for i.MX8MM thermal to apply fast cooling
> >>> mechanism, when temperature exceeds passive trip point, the highest
> >>> cooling action will be applied, and when temperature drops to lower
> >>> than the margin below passive trip point, the lowest cooling action
> >>> will be applied.
> >>
> >> You are not describing what is the goal of this change.
> >
> > The goal of this change is to make sure whenever temperature exceeds
> > passive trip point, the highest cooling action will be applied
> > immediately, e.g., if there are many cpufreq OPP, the default cooling
> > will be step by step, it will take some more rounds to make cpufreq drop to
> lowest OPP, while on i.MX, we expect the cpufreq drop to lowest OPP
> immediately.
>
> Whatever the slope of the temperature increase?
Yes.
>
> >> IIUC, the resulting change will be an on/off action. The thermal zone
> >> is mitigated with the highest cooling effect, so the lowest OPP, then
> >> the temperature trend is stable until it goes below the trip - margin
> >> where the mitigation is stopped.
> >
> > Yes, your understanding is correctly, once the temperature exceeds
> > passive trip point, the highest cooling action will be applied
> > immediately and then it will be stable there until temperature drop to
> > trip - margin, then the cooling action will be cancelled, the margin is to avoid
> the back and forth near the passive trip point.
> >
> >>
> >> Except, I'm missing something, setting a trip point with a 10000
> >> hysteresis and a cooling map min/max set to the highest opp will result on
> the same.
> >
> > Yes setting cooling map min/max cooling state to highest OPP will make
> > the highest cooling action applied immediately, and to have the
> > function of cooling action being cancelled when temperature drops to
> > trip - margin, I have to define another trip point, say passive trip
> > point is 85000, and cooling map min/max set to highest OPP in passive
> > trip point then add another trip point named "active" with 75000, and
> without any cooling map in it, right?
>
> May be I misunderstood but only the change as below is needed. No need to
> add a trip point, especially an 'active' trip which is a for an active cooling
> device like a fan.
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> index cc7152ecedd9..bea263bd06b4 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> @@ -231,10 +231,10 @@ cooling-maps {
> map0 {
> trip = <&cpu_alert0>;
> cooling-device =
> - <&A53_0 THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> - <&A53_1 THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> - <&A53_2 THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>,
> - <&A53_3 THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + <&A53_0 2 2>,
> + <&A53_1 2 2>,
> + <&A53_2 2 2>,
> + <&A53_3 2 2>
> };
> };
> };
>
>
Thanks, I will have a try to see if it meets our expectation.
Anson
_______________________________________________
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 15/17] arm64/cpufeature: Add remaining feature bits in ID_AA64DFR0 register
From: Anshuman Khandual @ 2020-05-24 1:08 UTC (permalink / raw)
To: Suzuki K Poulose, linux-arm-kernel
Cc: mark.rutland, catalin.marinas, will, linux-kernel, maz
In-Reply-To: <5bad1e13-e498-b33e-5305-336d855c2c8b@arm.com>
On 05/20/2020 07:27 PM, Suzuki K Poulose wrote:
> On 05/19/2020 10:40 AM, Anshuman Khandual wrote:
>> Enable MTPMU and TRACEFILT features bits in ID_AA64DFR0 register as per ARM
>> DDI 0487F.a specification.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>>
>> Suggested-by: Will Deacon <will@kernel.org>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> arch/arm64/include/asm/sysreg.h | 2 ++
>> arch/arm64/kernel/cpufeature.c | 2 ++
>> 2 files changed, 4 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
>> index a572069ccf6e..4bcd21cc2d68 100644
>> --- a/arch/arm64/include/asm/sysreg.h
>> +++ b/arch/arm64/include/asm/sysreg.h
>> @@ -766,6 +766,8 @@
>> #define ID_AA64MMFR2_CNP_SHIFT 0
>> /* id_aa64dfr0 */
>> +#define ID_AA64DFR0_MTPMU_SHIFT 48
>> +#define ID_AA64DFR0_TRACEFILT_SHIFT 40
>> #define ID_AA64DFR0_PMSVER_SHIFT 32
>> #define ID_AA64DFR0_CTX_CMPS_SHIFT 28
>> #define ID_AA64DFR0_WRPS_SHIFT 20
>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>> index 6338151f263c..986974be0178 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -366,6 +366,8 @@ static const struct arm64_ftr_bits ftr_id_mmfr0[] = {
>> };
>> static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
>> + S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_MTPMU_SHIFT, 4, 0),
>> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_TRACEFILT_SHIFT, 4, 0),
>
> We maske both the fields for KVM in AArch32 ID registers. We should do the same here.
MTPMU is defined for AArch32 ID register ID_DFR1_EL1, even though the
entire register is hidden from KVM with ID_HIDDEN().
static const struct arm64_ftr_bits ftr_id_dfr1[] = {
S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_DFR1_MTPMU_SHIFT, 4, 0),
ARM64_FTR_END,
};
Should the ID_AA64DFR0_EL1 be hidden from KVM as well. But it has many
other existing features apart from MTPMU and TRACEFILT which are being
added here.
_______________________________________________
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 13/17] arm64/cpufeature: Add remaining feature bits in ID_AA64MMFR1 register
From: Anshuman Khandual @ 2020-05-24 1:09 UTC (permalink / raw)
To: Suzuki K Poulose, linux-arm-kernel
Cc: mark.rutland, catalin.marinas, will, linux-kernel, maz
In-Reply-To: <6ad2dde0-455f-90a6-7b76-eda4fe8d6efe@arm.com>
On 05/19/2020 07:14 PM, Suzuki K Poulose wrote:
> On 05/19/2020 10:40 AM, Anshuman Khandual wrote:
>> Enable ETS, TWED, XNX and SPECSEI features bits in ID_AA64MMFR1 register as
>> per ARM DDI 0487F.a specification.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>>
>> Suggested-by: Will Deacon <will@kernel.org>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> arch/arm64/include/asm/sysreg.h | 4 ++++
>> arch/arm64/kernel/cpufeature.c | 4 ++++
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
>> index 95fdfc5e9bd0..f9dd2c5ab074 100644
>> --- a/arch/arm64/include/asm/sysreg.h
>> +++ b/arch/arm64/include/asm/sysreg.h
>> @@ -734,6 +734,10 @@
>> #endif
>> /* id_aa64mmfr1 */
>> +#define ID_AA64MMFR1_ETS_SHIFT 36
>> +#define ID_AA64MMFR1_TWED_SHIFT 32
>> +#define ID_AA64MMFR1_XNX_SHIFT 28
>> +#define ID_AA64MMFR1_SPECSEI_SHIFT 24
>> #define ID_AA64MMFR1_PAN_SHIFT 20
>> #define ID_AA64MMFR1_LOR_SHIFT 16
>> #define ID_AA64MMFR1_HPD_SHIFT 12
>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>> index 7ce19f97ba73..1f10ff7df705 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -299,6 +299,10 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
>> };
>> static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
>> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_ETS_SHIFT, 4, 0),
>> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_TWED_SHIFT, 4, 0),
>> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_XNX_SHIFT, 4, 0),
>> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_SPECSEI_SHIFT, 4, 0),
>
> SpecSEI must be HIGHER_SAFE, like we did for MMFR4 ?
Sure, will change.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v12 09/11] ptp: extend input argument for getcrosstimestamp API
From: Richard Cochran @ 2020-05-24 1:42 UTC (permalink / raw)
To: Jianyong Wu
Cc: Mark.Rutland, maz, justin.he, Wei.Chen, kvm, suzuki.poulose,
netdev, Steve.Capper, linux-kernel, sean.j.christopherson,
steven.price, Kaly.Xin, john.stultz, yangbo.lu, pbonzini, tglx,
nd, will, kvmarm, linux-arm-kernel
In-Reply-To: <20200522083724.38182-10-jianyong.wu@arm.com>
On Fri, May 22, 2020 at 04:37:22PM +0800, Jianyong Wu wrote:
> sometimes we may need tell getcrosstimestamp call back how to perform
> itself. Extending input arguments for getcrosstimestamp API to offer more
> exquisite control for the operation.
This text does not offer any justification for the change in API.
> diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
> index c602670bbffb..ba765647e54b 100644
> --- a/include/linux/ptp_clock_kernel.h
> +++ b/include/linux/ptp_clock_kernel.h
> @@ -133,7 +133,8 @@ struct ptp_clock_info {
> int (*gettimex64)(struct ptp_clock_info *ptp, struct timespec64 *ts,
> struct ptp_system_timestamp *sts);
> int (*getcrosststamp)(struct ptp_clock_info *ptp,
> - struct system_device_crosststamp *cts);
> + struct system_device_crosststamp *cts,
> + long *flag);
Well, you ignored the kernel doc completely. But in any case, I must
NAK this completely opaque and mysterious change. You want to add a
random pointer to some flag? I don't think so.
Thanks,
Richard
_______________________________________________
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