* Re: [PATCH 6/6] powerpc/rtas: constrain user region allocation to RMA
From: Nathan Lynch @ 2021-01-21 0:26 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: aik, tyreld, brking, ajd, aneesh.kumar
In-Reply-To: <87czxzrel3.fsf@mpe.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Nathan Lynch <nathanl@linux.ibm.com> writes:
>> Michael Ellerman <mpe@ellerman.id.au> writes:
>>> Nathan Lynch <nathanl@linux.ibm.com> writes:
>>>> Memory locations passed as arguments from the OS to RTAS usually need
>>>> to be addressable in 32-bit mode and must reside in the Real Mode
>>>> Area. On PAPR guests, the RMA starts at logical address 0 and is the
>>>> first logical memory block reported in the LPAR’s device tree.
>>>>
>>>> On powerpc targets with RTAS, Linux makes available to user space a
>>>> region of memory suitable for arguments to be passed to RTAS via
>>>> sys_rtas(). This region (rtas_rmo_buf) is allocated via the memblock
>>>> API during boot in order to ensure that it satisfies the requirements
>>>> described above.
>>>>
>>>> With radix MMU, the upper limit supplied to the memblock allocation
>>>> can exceed the bounds of the first logical memory block, since
>>>> ppc64_rma_size is ULONG_MAX and RTAS_INSTANTIATE_MAX is 1GB.
>>>
>>> Why does the size of the first memory block matter for radix?
>>
>> Here is my understanding: in the platform architecture, the size of the
>> first memory block equals the RMA, regardless of the MMU mode. It just
>> so happens that when using radix, Linux can pass ibm,configure-connector
>> a work area address outside of the RMA because the allocation
>> constraints for the work area are computed differently. It would be
>> wrong of the OS to pass RTAS arguments outside of this region with hash
>> MMU as well.
>
> If that's the requirement then shouldn't we be adjusting ppc64_rma_size?
> Otherwise aren't other uses of ppc64_rma_size going to run into similar
> problems.
Not all allocations limited by ppc64_rma_size set up memory that is
passed to RTAS though, do they? e.g. emergency_stack_init and
init_fallback_flush? Those shouldn't be confined to the first LMB
unnecessarily.
That's why I'm thinking what I've written here should be generalized a
bit and placed in an early allocator function that can be used to set up
the user region and the per-cpu reentrant RTAS argument buffers
(see allocate_paca_ptrs/new_rtas_args). So far those two sites are the
only ones I'm convinced need attention.
^ permalink raw reply
* Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()
From: Saravana Kannan @ 2021-01-20 23:58 UTC (permalink / raw)
To: Michael Walle
Cc: Rob Herring, Lorenzo Pieralisi, Roy Zang, PCI, LKML,
Minghuan Lian, Mingkai Hu, Greg Kroah-Hartman, Bjorn Helgaas,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <f706c0e4b684e07635396fcf02f4c9a6@walle.cc>
On Wed, Jan 20, 2021 at 3:53 PM Michael Walle <michael@walle.cc> wrote:
>
> Am 2021-01-20 20:47, schrieb Saravana Kannan:
> > On Wed, Jan 20, 2021 at 11:28 AM Michael Walle <michael@walle.cc>
> > wrote:
> >>
> >> [RESEND, fat-fingered the buttons of my mail client and converted
> >> all CCs to BCCs :(]
> >>
> >> Am 2021-01-20 20:02, schrieb Saravana Kannan:
> >> > On Wed, Jan 20, 2021 at 6:24 AM Rob Herring <robh@kernel.org> wrote:
> >> >>
> >> >> On Wed, Jan 20, 2021 at 4:53 AM Michael Walle <michael@walle.cc>
> >> >> wrote:
> >> >> >
> >> >> > fw_devlink will defer the probe until all suppliers are ready. We can't
> >> >> > use builtin_platform_driver_probe() because it doesn't retry after probe
> >> >> > deferral. Convert it to builtin_platform_driver().
> >> >>
> >> >> If builtin_platform_driver_probe() doesn't work with fw_devlink, then
> >> >> shouldn't it be fixed or removed?
> >> >
> >> > I was actually thinking about this too. The problem with fixing
> >> > builtin_platform_driver_probe() to behave like
> >> > builtin_platform_driver() is that these probe functions could be
> >> > marked with __init. But there are also only 20 instances of
> >> > builtin_platform_driver_probe() in the kernel:
> >> > $ git grep ^builtin_platform_driver_probe | wc -l
> >> > 20
> >> >
> >> > So it might be easier to just fix them to not use
> >> > builtin_platform_driver_probe().
> >> >
> >> > Michael,
> >> >
> >> > Any chance you'd be willing to help me by converting all these to
> >> > builtin_platform_driver() and delete builtin_platform_driver_probe()?
> >>
> >> If it just moving the probe function to the _driver struct and
> >> remove the __init annotations. I could look into that.
> >
> > Yup. That's pretty much it AFAICT.
> >
> > builtin_platform_driver_probe() also makes sure the driver doesn't ask
> > for async probe, etc. But I doubt anyone is actually setting async
> > flags and still using builtin_platform_driver_probe().
>
> Hasn't module_platform_driver_probe() the same problem? And there
> are ~80 drivers which uses that.
Yeah. The biggest problem with all of these is the __init markers.
Maybe some familiar with coccinelle can help?
-Saravana
^ permalink raw reply
* Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()
From: Michael Walle @ 2021-01-20 23:53 UTC (permalink / raw)
To: Saravana Kannan
Cc: Rob Herring, Lorenzo Pieralisi, Roy Zang, PCI, LKML,
Minghuan Lian, Mingkai Hu, Greg Kroah-Hartman, Bjorn Helgaas,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <CAGETcx8eZRd1fJ3yuO_t2UXBFHObeNdv-c8oFH3mXw6zi=zOkQ@mail.gmail.com>
Am 2021-01-20 20:47, schrieb Saravana Kannan:
> On Wed, Jan 20, 2021 at 11:28 AM Michael Walle <michael@walle.cc>
> wrote:
>>
>> [RESEND, fat-fingered the buttons of my mail client and converted
>> all CCs to BCCs :(]
>>
>> Am 2021-01-20 20:02, schrieb Saravana Kannan:
>> > On Wed, Jan 20, 2021 at 6:24 AM Rob Herring <robh@kernel.org> wrote:
>> >>
>> >> On Wed, Jan 20, 2021 at 4:53 AM Michael Walle <michael@walle.cc>
>> >> wrote:
>> >> >
>> >> > fw_devlink will defer the probe until all suppliers are ready. We can't
>> >> > use builtin_platform_driver_probe() because it doesn't retry after probe
>> >> > deferral. Convert it to builtin_platform_driver().
>> >>
>> >> If builtin_platform_driver_probe() doesn't work with fw_devlink, then
>> >> shouldn't it be fixed or removed?
>> >
>> > I was actually thinking about this too. The problem with fixing
>> > builtin_platform_driver_probe() to behave like
>> > builtin_platform_driver() is that these probe functions could be
>> > marked with __init. But there are also only 20 instances of
>> > builtin_platform_driver_probe() in the kernel:
>> > $ git grep ^builtin_platform_driver_probe | wc -l
>> > 20
>> >
>> > So it might be easier to just fix them to not use
>> > builtin_platform_driver_probe().
>> >
>> > Michael,
>> >
>> > Any chance you'd be willing to help me by converting all these to
>> > builtin_platform_driver() and delete builtin_platform_driver_probe()?
>>
>> If it just moving the probe function to the _driver struct and
>> remove the __init annotations. I could look into that.
>
> Yup. That's pretty much it AFAICT.
>
> builtin_platform_driver_probe() also makes sure the driver doesn't ask
> for async probe, etc. But I doubt anyone is actually setting async
> flags and still using builtin_platform_driver_probe().
Hasn't module_platform_driver_probe() the same problem? And there
are ~80 drivers which uses that.
-michael
^ permalink raw reply
* Re: [PATCH 1/2] crypto: talitos - Work around SEC6 ERRATA (AES-CTR mode data size error)
From: Ard Biesheuvel @ 2021-01-20 22:23 UTC (permalink / raw)
To: Christophe Leroy
Cc: Linux Crypto Mailing List, Linux Kernel Mailing List,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Herbert Xu,
David S. Miller
In-Reply-To: <4b7a870573f485b9fea496b13c9b02d86dd97314.1611169001.git.christophe.leroy@csgroup.eu>
On Wed, 20 Jan 2021 at 19:59, Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
> Talitos Security Engine AESU considers any input
> data size that is not a multiple of 16 bytes to be an error.
> This is not a problem in general, except for Counter mode
> that is a stream cipher and can have an input of any size.
>
> Test Manager for ctr(aes) fails on 4th test vector which has
> a length of 499 while all previous vectors which have a 16 bytes
> multiple length succeed.
>
> As suggested by Freescale, round up the input data length to the
> nearest 16 bytes.
>
> Fixes: 5e75ae1b3cef ("crypto: talitos - add new crypto modes")
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Doesn't this cause the hardware to write outside the given buffer?
> ---
> drivers/crypto/talitos.c | 28 ++++++++++++++++------------
> drivers/crypto/talitos.h | 1 +
> 2 files changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
> index 4fd85f31630a..b656983c1ef4 100644
> --- a/drivers/crypto/talitos.c
> +++ b/drivers/crypto/talitos.c
> @@ -1093,11 +1093,12 @@ static void ipsec_esp_decrypt_hwauth_done(struct device *dev,
> */
> static int sg_to_link_tbl_offset(struct scatterlist *sg, int sg_count,
> unsigned int offset, int datalen, int elen,
> - struct talitos_ptr *link_tbl_ptr)
> + struct talitos_ptr *link_tbl_ptr, int align)
> {
> int n_sg = elen ? sg_count + 1 : sg_count;
> int count = 0;
> int cryptlen = datalen + elen;
> + int padding = ALIGN(cryptlen, align) - cryptlen;
>
> while (cryptlen && sg && n_sg--) {
> unsigned int len = sg_dma_len(sg);
> @@ -1121,7 +1122,7 @@ static int sg_to_link_tbl_offset(struct scatterlist *sg, int sg_count,
> offset += datalen;
> }
> to_talitos_ptr(link_tbl_ptr + count,
> - sg_dma_address(sg) + offset, len, 0);
> + sg_dma_address(sg) + offset, sg_next(sg) ? len : len + padding, 0);
> to_talitos_ptr_ext_set(link_tbl_ptr + count, 0, 0);
> count++;
> cryptlen -= len;
> @@ -1144,10 +1145,11 @@ static int talitos_sg_map_ext(struct device *dev, struct scatterlist *src,
> unsigned int len, struct talitos_edesc *edesc,
> struct talitos_ptr *ptr, int sg_count,
> unsigned int offset, int tbl_off, int elen,
> - bool force)
> + bool force, int align)
> {
> struct talitos_private *priv = dev_get_drvdata(dev);
> bool is_sec1 = has_ftr_sec1(priv);
> + int aligned_len = ALIGN(len, align);
>
> if (!src) {
> to_talitos_ptr(ptr, 0, 0, is_sec1);
> @@ -1155,22 +1157,22 @@ static int talitos_sg_map_ext(struct device *dev, struct scatterlist *src,
> }
> to_talitos_ptr_ext_set(ptr, elen, is_sec1);
> if (sg_count == 1 && !force) {
> - to_talitos_ptr(ptr, sg_dma_address(src) + offset, len, is_sec1);
> + to_talitos_ptr(ptr, sg_dma_address(src) + offset, aligned_len, is_sec1);
> return sg_count;
> }
> if (is_sec1) {
> - to_talitos_ptr(ptr, edesc->dma_link_tbl + offset, len, is_sec1);
> + to_talitos_ptr(ptr, edesc->dma_link_tbl + offset, aligned_len, is_sec1);
> return sg_count;
> }
> sg_count = sg_to_link_tbl_offset(src, sg_count, offset, len, elen,
> - &edesc->link_tbl[tbl_off]);
> + &edesc->link_tbl[tbl_off], align);
> if (sg_count == 1 && !force) {
> /* Only one segment now, so no link tbl needed*/
> copy_talitos_ptr(ptr, &edesc->link_tbl[tbl_off], is_sec1);
> return sg_count;
> }
> to_talitos_ptr(ptr, edesc->dma_link_tbl +
> - tbl_off * sizeof(struct talitos_ptr), len, is_sec1);
> + tbl_off * sizeof(struct talitos_ptr), aligned_len, is_sec1);
> to_talitos_ptr_ext_or(ptr, DESC_PTR_LNKTBL_JUMP, is_sec1);
>
> return sg_count;
> @@ -1182,7 +1184,7 @@ static int talitos_sg_map(struct device *dev, struct scatterlist *src,
> unsigned int offset, int tbl_off)
> {
> return talitos_sg_map_ext(dev, src, len, edesc, ptr, sg_count, offset,
> - tbl_off, 0, false);
> + tbl_off, 0, false, 1);
> }
>
> /*
> @@ -1251,7 +1253,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq,
>
> ret = talitos_sg_map_ext(dev, areq->src, cryptlen, edesc, &desc->ptr[4],
> sg_count, areq->assoclen, tbl_off, elen,
> - false);
> + false, 1);
>
> if (ret > 1) {
> tbl_off += ret;
> @@ -1271,7 +1273,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq,
> elen = 0;
> ret = talitos_sg_map_ext(dev, areq->dst, cryptlen, edesc, &desc->ptr[5],
> sg_count, areq->assoclen, tbl_off, elen,
> - is_ipsec_esp && !encrypt);
> + is_ipsec_esp && !encrypt, 1);
> tbl_off += ret;
>
> if (!encrypt && is_ipsec_esp) {
> @@ -1577,6 +1579,8 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
> bool sync_needed = false;
> struct talitos_private *priv = dev_get_drvdata(dev);
> bool is_sec1 = has_ftr_sec1(priv);
> + bool is_ctr = (desc->hdr & DESC_HDR_SEL0_MASK) == DESC_HDR_SEL0_AESU &&
> + (desc->hdr & DESC_HDR_MODE0_AESU_MASK) == DESC_HDR_MODE0_AESU_CTR;
>
> /* first DWORD empty */
>
> @@ -1597,8 +1601,8 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
> /*
> * cipher in
> */
> - sg_count = talitos_sg_map(dev, areq->src, cryptlen, edesc,
> - &desc->ptr[3], sg_count, 0, 0);
> + sg_count = talitos_sg_map_ext(dev, areq->src, cryptlen, edesc, &desc->ptr[3],
> + sg_count, 0, 0, 0, false, is_ctr ? 16 : 1);
> if (sg_count > 1)
> sync_needed = true;
>
> diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
> index 1469b956948a..32825119e880 100644
> --- a/drivers/crypto/talitos.h
> +++ b/drivers/crypto/talitos.h
> @@ -344,6 +344,7 @@ static inline bool has_ftr_sec1(struct talitos_private *priv)
>
> /* primary execution unit mode (MODE0) and derivatives */
> #define DESC_HDR_MODE0_ENCRYPT cpu_to_be32(0x00100000)
> +#define DESC_HDR_MODE0_AESU_MASK cpu_to_be32(0x00600000)
> #define DESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x00200000)
> #define DESC_HDR_MODE0_AESU_CTR cpu_to_be32(0x00600000)
> #define DESC_HDR_MODE0_DEU_CBC cpu_to_be32(0x00400000)
> --
> 2.25.0
>
^ permalink raw reply
* Re: [RFC PATCH v3 5/6] dt-bindings: of: Add restricted DMA pool
From: Rob Herring @ 2021-01-20 21:31 UTC (permalink / raw)
To: Robin Murphy
Cc: Heikki Krogerus, Peter Zijlstra, Grant Likely, Paul Mackerras,
Frank Rowand, Ingo Molnar, Marek Szyprowski, Stefano Stabellini,
Saravana Kannan, Heinrich Schuchardt, Joerg Roedel,
Wysocki, Rafael J, Christoph Hellwig, Bartosz Golaszewski,
xen-devel, Thierry Reding, devicetree, Will Deacon,
Konrad Rzeszutek Wilk, Dan Williams, Nicolas Boichat,
Claire Chang, Boris Ostrovsky, Andy Shevchenko, Juergen Gross,
Greg Kroah-Hartman, Randy Dunlap, linux-kernel@vger.kernel.org,
Tomasz Figa, Linux IOMMU, linuxppc-dev, Thiago Jung Bauermann
In-Reply-To: <313f8052-a591-75de-c4c2-ee9ea8f02e7f@arm.com>
On Wed, Jan 20, 2021 at 11:30 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2021-01-20 16:53, Rob Herring wrote:
> > On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> >> Introduce the new compatible string, restricted-dma-pool, for restricted
> >> DMA. One can specify the address and length of the restricted DMA memory
> >> region by restricted-dma-pool in the device tree.
> >
> > If this goes into DT, I think we should be able to use dma-ranges for
> > this purpose instead. Normally, 'dma-ranges' is for physical bus
> > restrictions, but there's no reason it can't be used for policy or to
> > express restrictions the firmware has enabled.
>
> There would still need to be some way to tell SWIOTLB to pick up the
> corresponding chunk of memory and to prevent the kernel from using it
> for anything else, though.
Don't we already have that problem if dma-ranges had a very small
range? We just get lucky because the restriction is generally much
more RAM than needed.
In any case, wouldn't finding all the dma-ranges do this? We're
already walking the tree to find the max DMA address now.
> >> Signed-off-by: Claire Chang <tientzu@chromium.org>
> >> ---
> >> .../reserved-memory/reserved-memory.txt | 24 +++++++++++++++++++
> >> 1 file changed, 24 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> >> index e8d3096d922c..44975e2a1fd2 100644
> >> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> >> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> >> @@ -51,6 +51,20 @@ compatible (optional) - standard definition
> >> used as a shared pool of DMA buffers for a set of devices. It can
> >> be used by an operating system to instantiate the necessary pool
> >> management subsystem if necessary.
> >> + - restricted-dma-pool: This indicates a region of memory meant to be
> >> + used as a pool of restricted DMA buffers for a set of devices. The
> >> + memory region would be the only region accessible to those devices.
> >> + When using this, the no-map and reusable properties must not be set,
> >> + so the operating system can create a virtual mapping that will be used
> >> + for synchronization. The main purpose for restricted DMA is to
> >> + mitigate the lack of DMA access control on systems without an IOMMU,
> >> + which could result in the DMA accessing the system memory at
> >> + unexpected times and/or unexpected addresses, possibly leading to data
> >> + leakage or corruption. The feature on its own provides a basic level
> >> + of protection against the DMA overwriting buffer contents at
> >> + unexpected times. However, to protect against general data leakage and
> >> + system memory corruption, the system needs to provide way to restrict
> >> + the DMA to a predefined memory region.
> >> - vendor specific string in the form <vendor>,[<device>-]<usage>
> >> no-map (optional) - empty property
> >> - Indicates the operating system must not create a virtual mapping
> >> @@ -120,6 +134,11 @@ one for multimedia processing (named multimedia-memory@77000000, 64MiB).
> >> compatible = "acme,multimedia-memory";
> >> reg = <0x77000000 0x4000000>;
> >> };
> >> +
> >> + restricted_dma_mem_reserved: restricted_dma_mem_reserved {
> >> + compatible = "restricted-dma-pool";
> >> + reg = <0x50000000 0x400000>;
> >> + };
> >> };
> >>
> >> /* ... */
> >> @@ -138,4 +157,9 @@ one for multimedia processing (named multimedia-memory@77000000, 64MiB).
> >> memory-region = <&multimedia_reserved>;
> >> /* ... */
> >> };
> >> +
> >> + pcie_device: pcie_device@0,0 {
> >> + memory-region = <&restricted_dma_mem_reserved>;
> >
> > PCI hosts often have inbound window configurations that limit the
> > address range and translate PCI to bus addresses. Those windows happen
> > to be configured by dma-ranges. In any case, wouldn't you want to put
> > the configuration in the PCI host node? Is there a usecase of
> > restricting one PCIe device and not another?
>
> The general design seems to accommodate devices having their own pools
> such that they can't even snoop on each others' transient DMA data. If
> the interconnect had a way of wiring up, say, PCI RIDs to AMBA NSAIDs,
> then in principle you could certainly apply that to PCI endpoints too
> (presumably you'd also disallow them from peer-to-peer transactions at
> the PCI level too).
At least for PCI, I think we can handle this. We have the BDF in the
3rd address cell in dma-ranges. The Openfirmware spec says those are 0
in the case of ranges. It doesn't talk about dma-ranges though. But I
think we could extend it to allow for BDF. Though typically with PCIe
every device is behind its own bridge and each bridge node can have a
dma-ranges.
Rob
^ permalink raw reply
* linux-next: build failure on power pc
From: Yury Norov @ 2021-01-20 21:29 UTC (permalink / raw)
To: linuxppc-dev, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
Hi all,
I found the power pc build broken on today's
linux-next (647060f3b592).
My compiler is:
yury:linux$ powerpc-linux-gnu-gcc --version
powerpc-linux-gnu-gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The config and error log are attached.
Thanks,
Yury
[-- Attachment #2: ppc.tar.gz --]
[-- Type: application/gzip, Size: 69105 bytes --]
^ permalink raw reply
* Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()
From: Saravana Kannan @ 2021-01-20 19:47 UTC (permalink / raw)
To: Michael Walle
Cc: Rob Herring, Lorenzo Pieralisi, Roy Zang, PCI, LKML,
Minghuan Lian, Mingkai Hu, Greg Kroah-Hartman, Bjorn Helgaas,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <CAGETcx8eZRd1fJ3yuO_t2UXBFHObeNdv-c8oFH3mXw6zi=zOkQ@mail.gmail.com>
On Wed, Jan 20, 2021 at 11:47 AM Saravana Kannan <saravanak@google.com> wrote:
>
> On Wed, Jan 20, 2021 at 11:28 AM Michael Walle <michael@walle.cc> wrote:
> >
> > [RESEND, fat-fingered the buttons of my mail client and converted
> > all CCs to BCCs :(]
> >
> > Am 2021-01-20 20:02, schrieb Saravana Kannan:
> > > On Wed, Jan 20, 2021 at 6:24 AM Rob Herring <robh@kernel.org> wrote:
> > >>
> > >> On Wed, Jan 20, 2021 at 4:53 AM Michael Walle <michael@walle.cc>
> > >> wrote:
> > >> >
> > >> > fw_devlink will defer the probe until all suppliers are ready. We can't
> > >> > use builtin_platform_driver_probe() because it doesn't retry after probe
> > >> > deferral. Convert it to builtin_platform_driver().
> > >>
> > >> If builtin_platform_driver_probe() doesn't work with fw_devlink, then
> > >> shouldn't it be fixed or removed?
> > >
> > > I was actually thinking about this too. The problem with fixing
> > > builtin_platform_driver_probe() to behave like
> > > builtin_platform_driver() is that these probe functions could be
> > > marked with __init. But there are also only 20 instances of
> > > builtin_platform_driver_probe() in the kernel:
> > > $ git grep ^builtin_platform_driver_probe | wc -l
> > > 20
> > >
> > > So it might be easier to just fix them to not use
> > > builtin_platform_driver_probe().
> > >
> > > Michael,
> > >
> > > Any chance you'd be willing to help me by converting all these to
> > > builtin_platform_driver() and delete builtin_platform_driver_probe()?
> >
> > If it just moving the probe function to the _driver struct and
> > remove the __init annotations. I could look into that.
>
> Yup. That's pretty much it AFAICT.
>
> builtin_platform_driver_probe() also makes sure the driver doesn't ask
> for async probe, etc. But I doubt anyone is actually setting async
> flags and still using builtin_platform_driver_probe().
>
And thanks for agreeing to help!
-Saravana
^ permalink raw reply
* Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()
From: Saravana Kannan @ 2021-01-20 19:47 UTC (permalink / raw)
To: Michael Walle
Cc: Rob Herring, Lorenzo Pieralisi, Roy Zang, PCI, LKML,
Minghuan Lian, Mingkai Hu, Greg Kroah-Hartman, Bjorn Helgaas,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <c3e35b90e173b15870a859fd7001a712@walle.cc>
On Wed, Jan 20, 2021 at 11:28 AM Michael Walle <michael@walle.cc> wrote:
>
> [RESEND, fat-fingered the buttons of my mail client and converted
> all CCs to BCCs :(]
>
> Am 2021-01-20 20:02, schrieb Saravana Kannan:
> > On Wed, Jan 20, 2021 at 6:24 AM Rob Herring <robh@kernel.org> wrote:
> >>
> >> On Wed, Jan 20, 2021 at 4:53 AM Michael Walle <michael@walle.cc>
> >> wrote:
> >> >
> >> > fw_devlink will defer the probe until all suppliers are ready. We can't
> >> > use builtin_platform_driver_probe() because it doesn't retry after probe
> >> > deferral. Convert it to builtin_platform_driver().
> >>
> >> If builtin_platform_driver_probe() doesn't work with fw_devlink, then
> >> shouldn't it be fixed or removed?
> >
> > I was actually thinking about this too. The problem with fixing
> > builtin_platform_driver_probe() to behave like
> > builtin_platform_driver() is that these probe functions could be
> > marked with __init. But there are also only 20 instances of
> > builtin_platform_driver_probe() in the kernel:
> > $ git grep ^builtin_platform_driver_probe | wc -l
> > 20
> >
> > So it might be easier to just fix them to not use
> > builtin_platform_driver_probe().
> >
> > Michael,
> >
> > Any chance you'd be willing to help me by converting all these to
> > builtin_platform_driver() and delete builtin_platform_driver_probe()?
>
> If it just moving the probe function to the _driver struct and
> remove the __init annotations. I could look into that.
Yup. That's pretty much it AFAICT.
builtin_platform_driver_probe() also makes sure the driver doesn't ask
for async probe, etc. But I doubt anyone is actually setting async
flags and still using builtin_platform_driver_probe().
-Saravana
^ permalink raw reply
* Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()
From: Michael Walle @ 2021-01-20 19:25 UTC (permalink / raw)
In-Reply-To: <CAGETcx86HMo=gaDdXFyJ4QQ-pGXWzw2G0J=SjC-eq4K7B1zQHg@mail.gmail.com>
Am 2021-01-20 20:02, schrieb Saravana Kannan:
> On Wed, Jan 20, 2021 at 6:24 AM Rob Herring <robh@kernel.org> wrote:
>>
>> On Wed, Jan 20, 2021 at 4:53 AM Michael Walle <michael@walle.cc>
>> wrote:
>> >
>> > fw_devlink will defer the probe until all suppliers are ready. We can't
>> > use builtin_platform_driver_probe() because it doesn't retry after probe
>> > deferral. Convert it to builtin_platform_driver().
>>
>> If builtin_platform_driver_probe() doesn't work with fw_devlink, then
>> shouldn't it be fixed or removed?
>
> I was actually thinking about this too. The problem with fixing
> builtin_platform_driver_probe() to behave like
> builtin_platform_driver() is that these probe functions could be
> marked with __init. But there are also only 20 instances of
> builtin_platform_driver_probe() in the kernel:
> $ git grep ^builtin_platform_driver_probe | wc -l
> 20
>
> So it might be easier to just fix them to not use
> builtin_platform_driver_probe().
>
> Michael,
>
> Any chance you'd be willing to help me by converting all these to
> builtin_platform_driver() and delete builtin_platform_driver_probe()?
If it just moving the probe function to the _driver struct and
remove the __init annotations. I could look into that.
-michael
^ permalink raw reply
* Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()
From: Saravana Kannan @ 2021-01-20 19:02 UTC (permalink / raw)
To: Rob Herring
Cc: Roy Zang, Lorenzo Pieralisi, PCI, linux-kernel@vger.kernel.org,
Minghuan Lian, Michael Walle, Mingkai Hu, Greg Kroah-Hartman,
Bjorn Helgaas, linuxppc-dev, linux-arm-kernel
In-Reply-To: <CAL_JsqLSJCLtgPyAdKSqsy=JoHSLYef_0s-stTbiJ+VCq2qaSA@mail.gmail.com>
On Wed, Jan 20, 2021 at 6:24 AM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, Jan 20, 2021 at 4:53 AM Michael Walle <michael@walle.cc> wrote:
> >
> > fw_devlink will defer the probe until all suppliers are ready. We can't
> > use builtin_platform_driver_probe() because it doesn't retry after probe
> > deferral. Convert it to builtin_platform_driver().
>
> If builtin_platform_driver_probe() doesn't work with fw_devlink, then
> shouldn't it be fixed or removed?
I was actually thinking about this too. The problem with fixing
builtin_platform_driver_probe() to behave like
builtin_platform_driver() is that these probe functions could be
marked with __init. But there are also only 20 instances of
builtin_platform_driver_probe() in the kernel:
$ git grep ^builtin_platform_driver_probe | wc -l
20
So it might be easier to just fix them to not use
builtin_platform_driver_probe().
Michael,
Any chance you'd be willing to help me by converting all these to
builtin_platform_driver() and delete builtin_platform_driver_probe()?
-Saravana
> Then we're not fixing drivers later
> when folks start caring about deferred probe and devlink.
>
> I'd really prefer if we convert this to a module instead. (And all the
> other PCI host drivers.)
>
> > Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
>
> This happened!?
>
> > Signed-off-by: Michael Walle <michael@walle.cc>
> > ---
> > drivers/pci/controller/dwc/pci-layerscape.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
> > index 44ad34cdc3bc..5b9c625df7b8 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> > @@ -232,7 +232,7 @@ static const struct of_device_id ls_pcie_of_match[] = {
> > { },
> > };
> >
> > -static int __init ls_pcie_probe(struct platform_device *pdev)
> > +static int ls_pcie_probe(struct platform_device *pdev)
> > {
> > struct device *dev = &pdev->dev;
> > struct dw_pcie *pci;
> > @@ -271,10 +271,11 @@ static int __init ls_pcie_probe(struct platform_device *pdev)
> > }
> >
> > static struct platform_driver ls_pcie_driver = {
> > + .probe = ls_pcie_probe,
> > .driver = {
> > .name = "layerscape-pcie",
> > .of_match_table = ls_pcie_of_match,
> > .suppress_bind_attrs = true,
> > },
> > };
> > -builtin_platform_driver_probe(ls_pcie_driver, ls_pcie_probe);
> > +builtin_platform_driver(ls_pcie_driver);
> > --
> > 2.20.1
> >
^ permalink raw reply
* Re: [PATCH] powerpc/64: prevent replayed interrupt handlers from running softirqs
From: Athira Rajeev @ 2021-01-20 18:12 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20210120075005.1678565-1-npiggin@gmail.com>
[-- Attachment #1: Type: text/html, Size: 6264 bytes --]
^ permalink raw reply
* [PATCH] arch: powerpc: mm: book3s64: Fixed spelling architectue -> architecture in line number 1061
From: Bhaskar Chowdhury @ 2021-01-20 14:20 UTC (permalink / raw)
To: mpe, benh, paulus, akpm, rppt, linuxppc-dev, linux-kernel
Cc: rdunlap, Bhaskar Chowdhury
s/architectue/architecture/
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
---
arch/powerpc/mm/book3s64/radix_pgtable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
index 98f0b243c1ab..8b8f1451e944 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -1058,7 +1058,7 @@ void radix__ptep_set_access_flags(struct vm_area_struct *vma, pte_t *ptep,
* Book3S does not require a TLB flush when relaxing access
* restrictions when the address space is not attached to a
* NMMU, because the core MMU will reload the pte after taking
- * an access fault, which is defined by the architectue.
+ * an access fault, which is defined by the architecture.
*/
}
/* See ptesync comment in radix__set_pte_at */
--
2.30.0
^ permalink raw reply related
* Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()
From: Michael Walle @ 2021-01-20 19:28 UTC (permalink / raw)
To: Saravana Kannan
Cc: Rob Herring, Lorenzo Pieralisi, Roy Zang, PCI, linux-kernel,
Minghuan Lian, Mingkai Hu, Greg Kroah-Hartman, Bjorn Helgaas,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <CAGETcx86HMo=gaDdXFyJ4QQ-pGXWzw2G0J=SjC-eq4K7B1zQHg@mail.gmail.com>
[RESEND, fat-fingered the buttons of my mail client and converted
all CCs to BCCs :(]
Am 2021-01-20 20:02, schrieb Saravana Kannan:
> On Wed, Jan 20, 2021 at 6:24 AM Rob Herring <robh@kernel.org> wrote:
>>
>> On Wed, Jan 20, 2021 at 4:53 AM Michael Walle <michael@walle.cc>
>> wrote:
>> >
>> > fw_devlink will defer the probe until all suppliers are ready. We can't
>> > use builtin_platform_driver_probe() because it doesn't retry after probe
>> > deferral. Convert it to builtin_platform_driver().
>>
>> If builtin_platform_driver_probe() doesn't work with fw_devlink, then
>> shouldn't it be fixed or removed?
>
> I was actually thinking about this too. The problem with fixing
> builtin_platform_driver_probe() to behave like
> builtin_platform_driver() is that these probe functions could be
> marked with __init. But there are also only 20 instances of
> builtin_platform_driver_probe() in the kernel:
> $ git grep ^builtin_platform_driver_probe | wc -l
> 20
>
> So it might be easier to just fix them to not use
> builtin_platform_driver_probe().
>
> Michael,
>
> Any chance you'd be willing to help me by converting all these to
> builtin_platform_driver() and delete builtin_platform_driver_probe()?
If it just moving the probe function to the _driver struct and
remove the __init annotations. I could look into that.
-michael
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 034dfbf2e25530e4ee252464b397f30a5f55fbb7
From: kernel test robot @ 2021-01-20 19:00 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 034dfbf2e25530e4ee252464b397f30a5f55fbb7 Automatic merge of 'fixes' into merge (2021-01-20 15:45)
elapsed time: 817m
configs tested: 142
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
sh polaris_defconfig
powerpc pasemi_defconfig
sparc64 defconfig
arc tb10x_defconfig
m68k m5272c3_defconfig
c6x evmc6474_defconfig
powerpc mgcoge_defconfig
powerpc mpc8313_rdb_defconfig
riscv alldefconfig
arm cm_x300_defconfig
powerpc xes_mpc85xx_defconfig
arm s3c6400_defconfig
powerpc ep8248e_defconfig
powerpc mpc834x_mds_defconfig
arm sunxi_defconfig
mips malta_kvm_guest_defconfig
m68k amcore_defconfig
mips decstation_64_defconfig
ia64 zx1_defconfig
sh ul2_defconfig
sh se7721_defconfig
mips gcw0_defconfig
xtensa virt_defconfig
sh apsh4a3a_defconfig
m68k m5249evb_defconfig
mips loongson3_defconfig
powerpc sbc8548_defconfig
c6x evmc6472_defconfig
powerpc mpc837x_mds_defconfig
mips cobalt_defconfig
arm corgi_defconfig
m68k m5407c3_defconfig
m68k amiga_defconfig
powerpc cm5200_defconfig
arm omap2plus_defconfig
powerpc pq2fads_defconfig
powerpc eiger_defconfig
arc alldefconfig
powerpc redwood_defconfig
arm at91_dt_defconfig
powerpc rainier_defconfig
mips bcm63xx_defconfig
arm alldefconfig
mips loongson1b_defconfig
mips jazz_defconfig
mips omega2p_defconfig
powerpc canyonlands_defconfig
nds32 alldefconfig
xtensa xip_kc705_defconfig
sh se7724_defconfig
arm pcm027_defconfig
sh secureedge5410_defconfig
mips lemote2f_defconfig
riscv nommu_k210_defconfig
parisc generic-32bit_defconfig
arm ezx_defconfig
arm pxa168_defconfig
riscv rv32_defconfig
powerpc mpc837x_rdb_defconfig
arm spear6xx_defconfig
openrisc defconfig
powerpc skiroot_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210120
i386 randconfig-a002-20210120
i386 randconfig-a004-20210120
i386 randconfig-a006-20210120
i386 randconfig-a005-20210120
i386 randconfig-a003-20210120
x86_64 randconfig-a012-20210120
x86_64 randconfig-a015-20210120
x86_64 randconfig-a016-20210120
x86_64 randconfig-a011-20210120
x86_64 randconfig-a013-20210120
x86_64 randconfig-a014-20210120
i386 randconfig-a013-20210120
i386 randconfig-a011-20210120
i386 randconfig-a012-20210120
i386 randconfig-a014-20210120
i386 randconfig-a015-20210120
i386 randconfig-a016-20210120
i386 randconfig-a011-20210119
i386 randconfig-a012-20210119
i386 randconfig-a016-20210119
i386 randconfig-a015-20210119
i386 randconfig-a013-20210119
i386 randconfig-a014-20210119
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a002-20210120
x86_64 randconfig-a003-20210120
x86_64 randconfig-a001-20210120
x86_64 randconfig-a005-20210120
x86_64 randconfig-a006-20210120
x86_64 randconfig-a004-20210120
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 04483fc005f81d678e4fe63e36eab4fb39c5277b
From: kernel test robot @ 2021-01-20 19:01 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 04483fc005f81d678e4fe63e36eab4fb39c5277b powerpc: Always enable queued spinlocks for 64s, disable for others
elapsed time: 815m
configs tested: 142
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
sh polaris_defconfig
powerpc pasemi_defconfig
sparc64 defconfig
arc tb10x_defconfig
m68k m5272c3_defconfig
c6x evmc6474_defconfig
powerpc mgcoge_defconfig
powerpc mpc8313_rdb_defconfig
riscv alldefconfig
xtensa generic_kc705_defconfig
arm qcom_defconfig
arm cm_x300_defconfig
powerpc xes_mpc85xx_defconfig
arm s3c6400_defconfig
powerpc ep8248e_defconfig
powerpc mpc834x_mds_defconfig
arm sunxi_defconfig
mips malta_kvm_guest_defconfig
m68k amcore_defconfig
mips decstation_64_defconfig
ia64 zx1_defconfig
sh ul2_defconfig
sh se7721_defconfig
mips gcw0_defconfig
xtensa virt_defconfig
sh apsh4a3a_defconfig
m68k m5249evb_defconfig
mips loongson3_defconfig
powerpc sbc8548_defconfig
c6x evmc6472_defconfig
powerpc mpc837x_mds_defconfig
mips cobalt_defconfig
arm corgi_defconfig
m68k m5407c3_defconfig
m68k amiga_defconfig
powerpc cm5200_defconfig
arm omap2plus_defconfig
powerpc pq2fads_defconfig
powerpc eiger_defconfig
arc alldefconfig
mips tb0287_defconfig
arm aspeed_g4_defconfig
powerpc maple_defconfig
parisc generic-64bit_defconfig
arm hisi_defconfig
mips loongson1b_defconfig
mips jazz_defconfig
mips omega2p_defconfig
powerpc canyonlands_defconfig
powerpc tqm8xx_defconfig
arm lart_defconfig
mips cu1000-neo_defconfig
arm cns3420vb_defconfig
um i386_defconfig
xtensa alldefconfig
arm stm32_defconfig
sh se7780_defconfig
arm spear6xx_defconfig
openrisc defconfig
powerpc skiroot_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210120
i386 randconfig-a002-20210120
i386 randconfig-a004-20210120
i386 randconfig-a006-20210120
i386 randconfig-a005-20210120
i386 randconfig-a003-20210120
x86_64 randconfig-a012-20210120
x86_64 randconfig-a015-20210120
x86_64 randconfig-a016-20210120
x86_64 randconfig-a011-20210120
x86_64 randconfig-a013-20210120
x86_64 randconfig-a014-20210120
i386 randconfig-a011-20210119
i386 randconfig-a012-20210119
i386 randconfig-a016-20210119
i386 randconfig-a015-20210119
i386 randconfig-a013-20210119
i386 randconfig-a014-20210119
i386 randconfig-a013-20210120
i386 randconfig-a011-20210120
i386 randconfig-a012-20210120
i386 randconfig-a014-20210120
i386 randconfig-a015-20210120
i386 randconfig-a016-20210120
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a002-20210120
x86_64 randconfig-a003-20210120
x86_64 randconfig-a001-20210120
x86_64 randconfig-a005-20210120
x86_64 randconfig-a006-20210120
x86_64 randconfig-a004-20210120
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS dd3a44c06f7b4f14e90065bf05d62c255b20005f
From: kernel test robot @ 2021-01-20 19:00 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: dd3a44c06f7b4f14e90065bf05d62c255b20005f selftests/powerpc: Only test lwm/stmw on big endian
elapsed time: 820m
configs tested: 162
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
s390 debug_defconfig
mips cu1830-neo_defconfig
arm moxart_defconfig
xtensa smp_lx200_defconfig
powerpc stx_gp3_defconfig
sh polaris_defconfig
powerpc pasemi_defconfig
sparc64 defconfig
arc tb10x_defconfig
m68k m5272c3_defconfig
c6x evmc6474_defconfig
sh rsk7269_defconfig
arm h3600_defconfig
um i386_defconfig
sh rsk7201_defconfig
sh magicpanelr2_defconfig
powerpc mgcoge_defconfig
powerpc mpc8313_rdb_defconfig
riscv alldefconfig
arm cm_x300_defconfig
powerpc xes_mpc85xx_defconfig
arm s3c6400_defconfig
powerpc ep8248e_defconfig
powerpc mpc834x_mds_defconfig
arm sunxi_defconfig
mips gcw0_defconfig
xtensa virt_defconfig
sh apsh4a3a_defconfig
m68k m5249evb_defconfig
mips loongson3_defconfig
arm colibri_pxa300_defconfig
powerpc lite5200b_defconfig
mips malta_defconfig
m68k mvme147_defconfig
xtensa iss_defconfig
mips e55_defconfig
powerpc sbc8548_defconfig
c6x evmc6472_defconfig
powerpc mpc837x_mds_defconfig
mips cobalt_defconfig
sh se7206_defconfig
powerpc mpc8540_ads_defconfig
arc vdk_hs38_smp_defconfig
mips maltaup_defconfig
powerpc ppc64_defconfig
powerpc cell_defconfig
arm corgi_defconfig
m68k m5407c3_defconfig
m68k amiga_defconfig
powerpc cm5200_defconfig
arm omap2plus_defconfig
powerpc pq2fads_defconfig
powerpc eiger_defconfig
arc alldefconfig
powerpc redwood_defconfig
arm at91_dt_defconfig
powerpc rainier_defconfig
m68k amcore_defconfig
mips bcm63xx_defconfig
arm alldefconfig
mips tb0287_defconfig
arm aspeed_g4_defconfig
powerpc maple_defconfig
parisc generic-64bit_defconfig
arm hisi_defconfig
mips loongson1b_defconfig
mips jazz_defconfig
mips omega2p_defconfig
powerpc canyonlands_defconfig
nds32 alldefconfig
xtensa xip_kc705_defconfig
sh se7724_defconfig
arm pcm027_defconfig
sh secureedge5410_defconfig
mips lemote2f_defconfig
ia64 generic_defconfig
powerpc mpc83xx_defconfig
arm spear6xx_defconfig
openrisc defconfig
powerpc skiroot_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210120
i386 randconfig-a002-20210120
i386 randconfig-a004-20210120
i386 randconfig-a006-20210120
i386 randconfig-a005-20210120
i386 randconfig-a003-20210120
x86_64 randconfig-a012-20210120
x86_64 randconfig-a015-20210120
x86_64 randconfig-a016-20210120
x86_64 randconfig-a011-20210120
x86_64 randconfig-a013-20210120
x86_64 randconfig-a014-20210120
i386 randconfig-a011-20210119
i386 randconfig-a012-20210119
i386 randconfig-a016-20210119
i386 randconfig-a015-20210119
i386 randconfig-a013-20210119
i386 randconfig-a014-20210119
i386 randconfig-a013-20210120
i386 randconfig-a011-20210120
i386 randconfig-a012-20210120
i386 randconfig-a014-20210120
i386 randconfig-a015-20210120
i386 randconfig-a016-20210120
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a002-20210120
x86_64 randconfig-a003-20210120
x86_64 randconfig-a001-20210120
x86_64 randconfig-a005-20210120
x86_64 randconfig-a006-20210120
x86_64 randconfig-a004-20210120
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH 1/2] crypto: talitos - Work around SEC6 ERRATA (AES-CTR mode data size error)
From: Christophe Leroy @ 2021-01-20 18:57 UTC (permalink / raw)
To: Herbert Xu, David S. Miller; +Cc: linuxppc-dev, linux-crypto, linux-kernel
Talitos Security Engine AESU considers any input
data size that is not a multiple of 16 bytes to be an error.
This is not a problem in general, except for Counter mode
that is a stream cipher and can have an input of any size.
Test Manager for ctr(aes) fails on 4th test vector which has
a length of 499 while all previous vectors which have a 16 bytes
multiple length succeed.
As suggested by Freescale, round up the input data length to the
nearest 16 bytes.
Fixes: 5e75ae1b3cef ("crypto: talitos - add new crypto modes")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
drivers/crypto/talitos.c | 28 ++++++++++++++++------------
drivers/crypto/talitos.h | 1 +
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 4fd85f31630a..b656983c1ef4 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1093,11 +1093,12 @@ static void ipsec_esp_decrypt_hwauth_done(struct device *dev,
*/
static int sg_to_link_tbl_offset(struct scatterlist *sg, int sg_count,
unsigned int offset, int datalen, int elen,
- struct talitos_ptr *link_tbl_ptr)
+ struct talitos_ptr *link_tbl_ptr, int align)
{
int n_sg = elen ? sg_count + 1 : sg_count;
int count = 0;
int cryptlen = datalen + elen;
+ int padding = ALIGN(cryptlen, align) - cryptlen;
while (cryptlen && sg && n_sg--) {
unsigned int len = sg_dma_len(sg);
@@ -1121,7 +1122,7 @@ static int sg_to_link_tbl_offset(struct scatterlist *sg, int sg_count,
offset += datalen;
}
to_talitos_ptr(link_tbl_ptr + count,
- sg_dma_address(sg) + offset, len, 0);
+ sg_dma_address(sg) + offset, sg_next(sg) ? len : len + padding, 0);
to_talitos_ptr_ext_set(link_tbl_ptr + count, 0, 0);
count++;
cryptlen -= len;
@@ -1144,10 +1145,11 @@ static int talitos_sg_map_ext(struct device *dev, struct scatterlist *src,
unsigned int len, struct talitos_edesc *edesc,
struct talitos_ptr *ptr, int sg_count,
unsigned int offset, int tbl_off, int elen,
- bool force)
+ bool force, int align)
{
struct talitos_private *priv = dev_get_drvdata(dev);
bool is_sec1 = has_ftr_sec1(priv);
+ int aligned_len = ALIGN(len, align);
if (!src) {
to_talitos_ptr(ptr, 0, 0, is_sec1);
@@ -1155,22 +1157,22 @@ static int talitos_sg_map_ext(struct device *dev, struct scatterlist *src,
}
to_talitos_ptr_ext_set(ptr, elen, is_sec1);
if (sg_count == 1 && !force) {
- to_talitos_ptr(ptr, sg_dma_address(src) + offset, len, is_sec1);
+ to_talitos_ptr(ptr, sg_dma_address(src) + offset, aligned_len, is_sec1);
return sg_count;
}
if (is_sec1) {
- to_talitos_ptr(ptr, edesc->dma_link_tbl + offset, len, is_sec1);
+ to_talitos_ptr(ptr, edesc->dma_link_tbl + offset, aligned_len, is_sec1);
return sg_count;
}
sg_count = sg_to_link_tbl_offset(src, sg_count, offset, len, elen,
- &edesc->link_tbl[tbl_off]);
+ &edesc->link_tbl[tbl_off], align);
if (sg_count == 1 && !force) {
/* Only one segment now, so no link tbl needed*/
copy_talitos_ptr(ptr, &edesc->link_tbl[tbl_off], is_sec1);
return sg_count;
}
to_talitos_ptr(ptr, edesc->dma_link_tbl +
- tbl_off * sizeof(struct talitos_ptr), len, is_sec1);
+ tbl_off * sizeof(struct talitos_ptr), aligned_len, is_sec1);
to_talitos_ptr_ext_or(ptr, DESC_PTR_LNKTBL_JUMP, is_sec1);
return sg_count;
@@ -1182,7 +1184,7 @@ static int talitos_sg_map(struct device *dev, struct scatterlist *src,
unsigned int offset, int tbl_off)
{
return talitos_sg_map_ext(dev, src, len, edesc, ptr, sg_count, offset,
- tbl_off, 0, false);
+ tbl_off, 0, false, 1);
}
/*
@@ -1251,7 +1253,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq,
ret = talitos_sg_map_ext(dev, areq->src, cryptlen, edesc, &desc->ptr[4],
sg_count, areq->assoclen, tbl_off, elen,
- false);
+ false, 1);
if (ret > 1) {
tbl_off += ret;
@@ -1271,7 +1273,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct aead_request *areq,
elen = 0;
ret = talitos_sg_map_ext(dev, areq->dst, cryptlen, edesc, &desc->ptr[5],
sg_count, areq->assoclen, tbl_off, elen,
- is_ipsec_esp && !encrypt);
+ is_ipsec_esp && !encrypt, 1);
tbl_off += ret;
if (!encrypt && is_ipsec_esp) {
@@ -1577,6 +1579,8 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
bool sync_needed = false;
struct talitos_private *priv = dev_get_drvdata(dev);
bool is_sec1 = has_ftr_sec1(priv);
+ bool is_ctr = (desc->hdr & DESC_HDR_SEL0_MASK) == DESC_HDR_SEL0_AESU &&
+ (desc->hdr & DESC_HDR_MODE0_AESU_MASK) == DESC_HDR_MODE0_AESU_CTR;
/* first DWORD empty */
@@ -1597,8 +1601,8 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
/*
* cipher in
*/
- sg_count = talitos_sg_map(dev, areq->src, cryptlen, edesc,
- &desc->ptr[3], sg_count, 0, 0);
+ sg_count = talitos_sg_map_ext(dev, areq->src, cryptlen, edesc, &desc->ptr[3],
+ sg_count, 0, 0, 0, false, is_ctr ? 16 : 1);
if (sg_count > 1)
sync_needed = true;
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index 1469b956948a..32825119e880 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -344,6 +344,7 @@ static inline bool has_ftr_sec1(struct talitos_private *priv)
/* primary execution unit mode (MODE0) and derivatives */
#define DESC_HDR_MODE0_ENCRYPT cpu_to_be32(0x00100000)
+#define DESC_HDR_MODE0_AESU_MASK cpu_to_be32(0x00600000)
#define DESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x00200000)
#define DESC_HDR_MODE0_AESU_CTR cpu_to_be32(0x00600000)
#define DESC_HDR_MODE0_DEU_CBC cpu_to_be32(0x00400000)
--
2.25.0
^ permalink raw reply related
* [PATCH 2/2] crypto: talitos - Fix ctr(aes) on SEC1
From: Christophe Leroy @ 2021-01-20 18:57 UTC (permalink / raw)
To: Herbert Xu, David S. Miller; +Cc: linuxppc-dev, linux-crypto, linux-kernel
In-Reply-To: <4b7a870573f485b9fea496b13c9b02d86dd97314.1611169001.git.christophe.leroy@csgroup.eu>
While ctr(aes) requires the use of a special descriptor on SEC2 (see
commit 70d355ccea89 ("crypto: talitos - fix ctr-aes-talitos")), that
special descriptor doesn't work on SEC1, see commit e738c5f15562
("powerpc/8xx: Add DT node for using the SEC engine of the MPC885").
However, the common nonsnoop descriptor works properly on SEC1 for
ctr(aes).
Add a second template for ctr(aes) that will be registered
only on SEC1.
Fixes: 70d355ccea89 ("crypto: talitos - fix ctr-aes-talitos")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
drivers/crypto/talitos.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index b656983c1ef4..25c9f825b8b5 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -2765,6 +2765,22 @@ static struct talitos_alg_template driver_algs[] = {
DESC_HDR_SEL0_AESU |
DESC_HDR_MODE0_AESU_CTR,
},
+ { .type = CRYPTO_ALG_TYPE_SKCIPHER,
+ .alg.skcipher = {
+ .base.cra_name = "ctr(aes)",
+ .base.cra_driver_name = "ctr-aes-talitos",
+ .base.cra_blocksize = 1,
+ .base.cra_flags = CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_ALLOCATES_MEMORY,
+ .min_keysize = AES_MIN_KEY_SIZE,
+ .max_keysize = AES_MAX_KEY_SIZE,
+ .ivsize = AES_BLOCK_SIZE,
+ .setkey = skcipher_aes_setkey,
+ },
+ .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
+ DESC_HDR_SEL0_AESU |
+ DESC_HDR_MODE0_AESU_CTR,
+ },
{ .type = CRYPTO_ALG_TYPE_SKCIPHER,
.alg.skcipher = {
.base.cra_name = "ecb(des)",
@@ -3182,6 +3198,12 @@ static struct talitos_crypto_alg *talitos_alg_alloc(struct device *dev,
t_alg->algt.alg.skcipher.setkey ?: skcipher_setkey;
t_alg->algt.alg.skcipher.encrypt = skcipher_encrypt;
t_alg->algt.alg.skcipher.decrypt = skcipher_decrypt;
+ if (!strcmp(alg->cra_name, "ctr(aes)") && !has_ftr_sec1(priv) &&
+ DESC_TYPE(t_alg->algt.desc_hdr_template) !=
+ DESC_TYPE(DESC_HDR_TYPE_AESU_CTR_NONSNOOP)) {
+ devm_kfree(dev, t_alg);
+ return ERR_PTR(-ENOTSUPP);
+ }
break;
case CRYPTO_ALG_TYPE_AEAD:
alg = &t_alg->algt.alg.aead.base;
--
2.25.0
^ permalink raw reply related
* [PATCH] powerpc: Fix debug print in smp_setup_cpu_maps
From: Fabiano Rosas @ 2021-01-20 18:18 UTC (permalink / raw)
To: linuxppc-dev
When figuring out the number of threads, the debug message prints "1
thread" for the first iteration of the loop, instead of the actual
number of threads calculated from the length of the
"ibm,ppc-interrupt-server#s" property.
* /cpus/PowerPC,POWER8@20...
ibm,ppc-interrupt-server#s -> 1 threads <--- WRONG
thread 0 -> cpu 0 (hard id 32)
thread 1 -> cpu 1 (hard id 33)
thread 2 -> cpu 2 (hard id 34)
thread 3 -> cpu 3 (hard id 35)
thread 4 -> cpu 4 (hard id 36)
thread 5 -> cpu 5 (hard id 37)
thread 6 -> cpu 6 (hard id 38)
thread 7 -> cpu 7 (hard id 39)
* /cpus/PowerPC,POWER8@28...
ibm,ppc-interrupt-server#s -> 8 threads
thread 0 -> cpu 8 (hard id 40)
thread 1 -> cpu 9 (hard id 41)
thread 2 -> cpu 10 (hard id 42)
thread 3 -> cpu 11 (hard id 43)
thread 4 -> cpu 12 (hard id 44)
thread 5 -> cpu 13 (hard id 45)
thread 6 -> cpu 14 (hard id 46)
thread 7 -> cpu 15 (hard id 47)
(...)
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
---
arch/powerpc/kernel/setup-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 71f38e9248be..46481ea96c88 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -462,8 +462,8 @@ void __init smp_setup_cpu_maps(void)
intserv = of_get_property(dn, "ibm,ppc-interrupt-server#s",
&len);
if (intserv) {
- DBG(" ibm,ppc-interrupt-server#s -> %d threads\n",
- nthreads);
+ DBG(" ibm,ppc-interrupt-server#s -> %lu threads\n",
+ (len / sizeof(int)));
} else {
DBG(" no ibm,ppc-interrupt-server#s -> 1 thread\n");
intserv = of_get_property(dn, "reg", &len);
--
2.29.2
^ permalink raw reply related
* Re: [PATCH] arch: powerpc: mm: book3s64: Fixed spelling architectue -> architecture in line number 1061
From: Randy Dunlap @ 2021-01-20 17:51 UTC (permalink / raw)
To: Bhaskar Chowdhury, mpe, benh, paulus, akpm, rppt, linuxppc-dev,
linux-kernel
In-Reply-To: <20210120142020.2623355-1-unixbhaskar@gmail.com>
On 1/20/21 6:20 AM, Bhaskar Chowdhury wrote:
> s/architectue/architecture/
>
> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
Line number in $Subject is just too much.
> ---
> arch/powerpc/mm/book3s64/radix_pgtable.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
> index 98f0b243c1ab..8b8f1451e944 100644
> --- a/arch/powerpc/mm/book3s64/radix_pgtable.c
> +++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
> @@ -1058,7 +1058,7 @@ void radix__ptep_set_access_flags(struct vm_area_struct *vma, pte_t *ptep,
> * Book3S does not require a TLB flush when relaxing access
> * restrictions when the address space is not attached to a
> * NMMU, because the core MMU will reload the pte after taking
> - * an access fault, which is defined by the architectue.
> + * an access fault, which is defined by the architecture.
> */
> }
> /* See ptesync comment in radix__set_pte_at */
> --
> 2.30.0
>
--
~Randy
"He closes his eyes and drops the goggles. You can't get hurt
by looking at a bitmap. Or can you?"
(Neal Stephenson: Snow Crash)
^ permalink raw reply
* Re: [RFC PATCH v3 5/6] dt-bindings: of: Add restricted DMA pool
From: Robin Murphy @ 2021-01-20 17:30 UTC (permalink / raw)
To: Rob Herring, Claire Chang
Cc: heikki.krogerus, peterz, linux-kernel, grant.likely, paulus, will,
mingo, m.szyprowski, sstabellini, saravanak, joro,
rafael.j.wysocki, hch, bgolaszewski, xen-devel, treding,
devicetree, konrad.wilk, dan.j.williams, drinkcat,
boris.ostrovsky, andriy.shevchenko, jgross, gregkh, rdunlap,
frowand.list, tfiga, iommu, xypron.glpk, linuxppc-dev, bauerman
In-Reply-To: <20210120165348.GA220770@robh.at.kernel.org>
On 2021-01-20 16:53, Rob Herring wrote:
> On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
>> Introduce the new compatible string, restricted-dma-pool, for restricted
>> DMA. One can specify the address and length of the restricted DMA memory
>> region by restricted-dma-pool in the device tree.
>
> If this goes into DT, I think we should be able to use dma-ranges for
> this purpose instead. Normally, 'dma-ranges' is for physical bus
> restrictions, but there's no reason it can't be used for policy or to
> express restrictions the firmware has enabled.
There would still need to be some way to tell SWIOTLB to pick up the
corresponding chunk of memory and to prevent the kernel from using it
for anything else, though.
>> Signed-off-by: Claire Chang <tientzu@chromium.org>
>> ---
>> .../reserved-memory/reserved-memory.txt | 24 +++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>> index e8d3096d922c..44975e2a1fd2 100644
>> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>> @@ -51,6 +51,20 @@ compatible (optional) - standard definition
>> used as a shared pool of DMA buffers for a set of devices. It can
>> be used by an operating system to instantiate the necessary pool
>> management subsystem if necessary.
>> + - restricted-dma-pool: This indicates a region of memory meant to be
>> + used as a pool of restricted DMA buffers for a set of devices. The
>> + memory region would be the only region accessible to those devices.
>> + When using this, the no-map and reusable properties must not be set,
>> + so the operating system can create a virtual mapping that will be used
>> + for synchronization. The main purpose for restricted DMA is to
>> + mitigate the lack of DMA access control on systems without an IOMMU,
>> + which could result in the DMA accessing the system memory at
>> + unexpected times and/or unexpected addresses, possibly leading to data
>> + leakage or corruption. The feature on its own provides a basic level
>> + of protection against the DMA overwriting buffer contents at
>> + unexpected times. However, to protect against general data leakage and
>> + system memory corruption, the system needs to provide way to restrict
>> + the DMA to a predefined memory region.
>> - vendor specific string in the form <vendor>,[<device>-]<usage>
>> no-map (optional) - empty property
>> - Indicates the operating system must not create a virtual mapping
>> @@ -120,6 +134,11 @@ one for multimedia processing (named multimedia-memory@77000000, 64MiB).
>> compatible = "acme,multimedia-memory";
>> reg = <0x77000000 0x4000000>;
>> };
>> +
>> + restricted_dma_mem_reserved: restricted_dma_mem_reserved {
>> + compatible = "restricted-dma-pool";
>> + reg = <0x50000000 0x400000>;
>> + };
>> };
>>
>> /* ... */
>> @@ -138,4 +157,9 @@ one for multimedia processing (named multimedia-memory@77000000, 64MiB).
>> memory-region = <&multimedia_reserved>;
>> /* ... */
>> };
>> +
>> + pcie_device: pcie_device@0,0 {
>> + memory-region = <&restricted_dma_mem_reserved>;
>
> PCI hosts often have inbound window configurations that limit the
> address range and translate PCI to bus addresses. Those windows happen
> to be configured by dma-ranges. In any case, wouldn't you want to put
> the configuration in the PCI host node? Is there a usecase of
> restricting one PCIe device and not another?
The general design seems to accommodate devices having their own pools
such that they can't even snoop on each others' transient DMA data. If
the interconnect had a way of wiring up, say, PCI RIDs to AMBA NSAIDs,
then in principle you could certainly apply that to PCI endpoints too
(presumably you'd also disallow them from peer-to-peer transactions at
the PCI level too).
Robin.
^ permalink raw reply
* Re: [PATCH 1/3] tty: hvcs: Drop unnecessary if block
From: Tyrel Datwyler @ 2021-01-20 17:16 UTC (permalink / raw)
To: Uwe Kleine-König, Greg Kroah-Hartman, Jiri Slaby
Cc: sparclinux, linuxppc-dev, David S . Miller, linux-kernel
In-Reply-To: <20210114175718.137483-2-u.kleine-koenig@pengutronix.de>
On 1/14/21 9:57 AM, Uwe Kleine-König wrote:
> If hvcs_probe() succeeded dev_set_drvdata() is called with a non-NULL
> value, and if hvcs_probe() failed hvcs_remove() isn't called.
>
> So there is no way dev_get_drvdata() can return NULL in hvcs_remove() and
> the check can just go away.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
> ---
> drivers/tty/hvc/hvcs.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
> index 509d1042825a..3e0461285c34 100644
> --- a/drivers/tty/hvc/hvcs.c
> +++ b/drivers/tty/hvc/hvcs.c
> @@ -825,9 +825,6 @@ static int hvcs_remove(struct vio_dev *dev)
> unsigned long flags;
> struct tty_struct *tty;
>
> - if (!hvcsd)
> - return -ENODEV;
> -
> /* By this time the vty-server won't be getting any more interrupts */
>
> spin_lock_irqsave(&hvcsd->lock, flags);
>
^ permalink raw reply
* Re: [RFC PATCH v3 5/6] dt-bindings: of: Add restricted DMA pool
From: Rob Herring @ 2021-01-20 16:53 UTC (permalink / raw)
To: Claire Chang
Cc: heikki.krogerus, peterz, linux-kernel, grant.likely, paulus, will,
mingo, m.szyprowski, sstabellini, saravanak, joro,
rafael.j.wysocki, hch, bgolaszewski, xen-devel, treding,
devicetree, konrad.wilk, dan.j.williams, linuxppc-dev, drinkcat,
boris.ostrovsky, andriy.shevchenko, jgross, gregkh, rdunlap,
frowand.list, tfiga, iommu, xypron.glpk, robin.murphy, bauerman
In-Reply-To: <20210106034124.30560-6-tientzu@chromium.org>
On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> Introduce the new compatible string, restricted-dma-pool, for restricted
> DMA. One can specify the address and length of the restricted DMA memory
> region by restricted-dma-pool in the device tree.
If this goes into DT, I think we should be able to use dma-ranges for
this purpose instead. Normally, 'dma-ranges' is for physical bus
restrictions, but there's no reason it can't be used for policy or to
express restrictions the firmware has enabled.
> Signed-off-by: Claire Chang <tientzu@chromium.org>
> ---
> .../reserved-memory/reserved-memory.txt | 24 +++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> index e8d3096d922c..44975e2a1fd2 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> @@ -51,6 +51,20 @@ compatible (optional) - standard definition
> used as a shared pool of DMA buffers for a set of devices. It can
> be used by an operating system to instantiate the necessary pool
> management subsystem if necessary.
> + - restricted-dma-pool: This indicates a region of memory meant to be
> + used as a pool of restricted DMA buffers for a set of devices. The
> + memory region would be the only region accessible to those devices.
> + When using this, the no-map and reusable properties must not be set,
> + so the operating system can create a virtual mapping that will be used
> + for synchronization. The main purpose for restricted DMA is to
> + mitigate the lack of DMA access control on systems without an IOMMU,
> + which could result in the DMA accessing the system memory at
> + unexpected times and/or unexpected addresses, possibly leading to data
> + leakage or corruption. The feature on its own provides a basic level
> + of protection against the DMA overwriting buffer contents at
> + unexpected times. However, to protect against general data leakage and
> + system memory corruption, the system needs to provide way to restrict
> + the DMA to a predefined memory region.
> - vendor specific string in the form <vendor>,[<device>-]<usage>
> no-map (optional) - empty property
> - Indicates the operating system must not create a virtual mapping
> @@ -120,6 +134,11 @@ one for multimedia processing (named multimedia-memory@77000000, 64MiB).
> compatible = "acme,multimedia-memory";
> reg = <0x77000000 0x4000000>;
> };
> +
> + restricted_dma_mem_reserved: restricted_dma_mem_reserved {
> + compatible = "restricted-dma-pool";
> + reg = <0x50000000 0x400000>;
> + };
> };
>
> /* ... */
> @@ -138,4 +157,9 @@ one for multimedia processing (named multimedia-memory@77000000, 64MiB).
> memory-region = <&multimedia_reserved>;
> /* ... */
> };
> +
> + pcie_device: pcie_device@0,0 {
> + memory-region = <&restricted_dma_mem_reserved>;
PCI hosts often have inbound window configurations that limit the
address range and translate PCI to bus addresses. Those windows happen
to be configured by dma-ranges. In any case, wouldn't you want to put
the configuration in the PCI host node? Is there a usecase of
restricting one PCIe device and not another?
Rob
^ permalink raw reply
* Re: [PATCH v3] [PATCH] powerpc/sstep: Check ISA 3.0 instruction validity before emulation
From: Michal Suchánek @ 2021-01-20 16:09 UTC (permalink / raw)
To: Ananth N Mavinakayanahalli; +Cc: naveen.n.rao, ravi.bangoria, linuxppc-dev, dja
In-Reply-To: <161114113785.214433.12934683302522893921.stgit@thinktux.local>
On Wed, Jan 20, 2021 at 04:43:14PM +0530, Ananth N Mavinakayanahalli wrote:
> We currently unconditionally try to emulate newer instructions on older
> Power versions that could cause issues. Gate it.
Fixes: 350779a29f11 ("powerpc: Handle most loads and stores in instruction emulation code")
There are more that would apply but most of the checks land in code
added by the above.
Thanks
Michal
>
> Signed-off-by: Ananth N Mavinakayanahalli <ananth@linux.ibm.com>
> ---
>
> [v3] Addressed Naveen's comments on scv and addpcis
> [v2] Fixed description
>
> arch/powerpc/lib/sstep.c | 46 ++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
> index bf7a7d62ae8b..5a425a4a1d88 100644
> --- a/arch/powerpc/lib/sstep.c
> +++ b/arch/powerpc/lib/sstep.c
> @@ -1304,9 +1304,11 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> if ((word & 0xfe2) == 2)
> op->type = SYSCALL;
> else if (IS_ENABLED(CONFIG_PPC_BOOK3S_64) &&
> - (word & 0xfe3) == 1)
> + (word & 0xfe3) == 1) { /* scv */
> op->type = SYSCALL_VECTORED_0;
> - else
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> + } else
> op->type = UNKNOWN;
> return 0;
> #endif
> @@ -1530,6 +1532,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> case 19:
> if (((word >> 1) & 0x1f) == 2) {
> /* addpcis */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> imm = (short) (word & 0xffc1); /* d0 + d2 fields */
> imm |= (word >> 15) & 0x3e; /* d1 field */
> op->val = regs->nip + (imm << 16) + 4;
> @@ -2439,6 +2443,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> break;
>
> case 268: /* lxvx */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd | ((word & 1) << 5);
> op->type = MKOP(LOAD_VSX, 0, 16);
> op->element_size = 16;
> @@ -2448,6 +2454,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> case 269: /* lxvl */
> case 301: { /* lxvll */
> int nb;
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd | ((word & 1) << 5);
> op->ea = ra ? regs->gpr[ra] : 0;
> nb = regs->gpr[rb] & 0xff;
> @@ -2475,6 +2483,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> break;
>
> case 364: /* lxvwsx */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd | ((word & 1) << 5);
> op->type = MKOP(LOAD_VSX, 0, 4);
> op->element_size = 4;
> @@ -2482,6 +2492,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> break;
>
> case 396: /* stxvx */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd | ((word & 1) << 5);
> op->type = MKOP(STORE_VSX, 0, 16);
> op->element_size = 16;
> @@ -2491,6 +2503,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> case 397: /* stxvl */
> case 429: { /* stxvll */
> int nb;
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd | ((word & 1) << 5);
> op->ea = ra ? regs->gpr[ra] : 0;
> nb = regs->gpr[rb] & 0xff;
> @@ -2542,6 +2556,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> break;
>
> case 781: /* lxsibzx */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd | ((word & 1) << 5);
> op->type = MKOP(LOAD_VSX, 0, 1);
> op->element_size = 8;
> @@ -2549,6 +2565,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> break;
>
> case 812: /* lxvh8x */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd | ((word & 1) << 5);
> op->type = MKOP(LOAD_VSX, 0, 16);
> op->element_size = 2;
> @@ -2556,6 +2574,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> break;
>
> case 813: /* lxsihzx */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd | ((word & 1) << 5);
> op->type = MKOP(LOAD_VSX, 0, 2);
> op->element_size = 8;
> @@ -2569,6 +2589,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> break;
>
> case 876: /* lxvb16x */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd | ((word & 1) << 5);
> op->type = MKOP(LOAD_VSX, 0, 16);
> op->element_size = 1;
> @@ -2582,6 +2604,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> break;
>
> case 909: /* stxsibx */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd | ((word & 1) << 5);
> op->type = MKOP(STORE_VSX, 0, 1);
> op->element_size = 8;
> @@ -2589,6 +2613,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> break;
>
> case 940: /* stxvh8x */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd | ((word & 1) << 5);
> op->type = MKOP(STORE_VSX, 0, 16);
> op->element_size = 2;
> @@ -2596,6 +2622,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> break;
>
> case 941: /* stxsihx */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd | ((word & 1) << 5);
> op->type = MKOP(STORE_VSX, 0, 2);
> op->element_size = 8;
> @@ -2609,6 +2637,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> break;
>
> case 1004: /* stxvb16x */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd | ((word & 1) << 5);
> op->type = MKOP(STORE_VSX, 0, 16);
> op->element_size = 1;
> @@ -2717,12 +2747,16 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> op->type = MKOP(LOAD_FP, 0, 16);
> break;
> case 2: /* lxsd */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd + 32;
> op->type = MKOP(LOAD_VSX, 0, 8);
> op->element_size = 8;
> op->vsx_flags = VSX_CHECK_VEC;
> break;
> case 3: /* lxssp */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->reg = rd + 32;
> op->type = MKOP(LOAD_VSX, 0, 4);
> op->element_size = 8;
> @@ -2775,6 +2809,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> break;
>
> case 1: /* lxv */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->ea = dqform_ea(word, regs);
> if (word & 8)
> op->reg = rd + 32;
> @@ -2785,6 +2821,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
>
> case 2: /* stxsd with LSB of DS field = 0 */
> case 6: /* stxsd with LSB of DS field = 1 */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->ea = dsform_ea(word, regs);
> op->reg = rd + 32;
> op->type = MKOP(STORE_VSX, 0, 8);
> @@ -2794,6 +2832,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
>
> case 3: /* stxssp with LSB of DS field = 0 */
> case 7: /* stxssp with LSB of DS field = 1 */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->ea = dsform_ea(word, regs);
> op->reg = rd + 32;
> op->type = MKOP(STORE_VSX, 0, 4);
> @@ -2802,6 +2842,8 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
> break;
>
> case 5: /* stxv */
> + if (!cpu_has_feature(CPU_FTR_ARCH_300))
> + return -1;
> op->ea = dqform_ea(word, regs);
> if (word & 8)
> op->reg = rd + 32;
>
>
^ permalink raw reply
* Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()
From: Greg Kroah-Hartman @ 2021-01-20 15:50 UTC (permalink / raw)
To: Rob Herring
Cc: Roy Zang, Lorenzo Pieralisi, Saravana Kannan, PCI,
linux-kernel@vger.kernel.org, Minghuan Lian, Michael Walle,
Mingkai Hu, Bjorn Helgaas, linuxppc-dev, linux-arm-kernel
In-Reply-To: <CAL_JsqLSJCLtgPyAdKSqsy=JoHSLYef_0s-stTbiJ+VCq2qaSA@mail.gmail.com>
On Wed, Jan 20, 2021 at 08:23:59AM -0600, Rob Herring wrote:
> On Wed, Jan 20, 2021 at 4:53 AM Michael Walle <michael@walle.cc> wrote:
> >
> > fw_devlink will defer the probe until all suppliers are ready. We can't
> > use builtin_platform_driver_probe() because it doesn't retry after probe
> > deferral. Convert it to builtin_platform_driver().
>
> If builtin_platform_driver_probe() doesn't work with fw_devlink, then
> shouldn't it be fixed or removed? Then we're not fixing drivers later
> when folks start caring about deferred probe and devlink.
>
> I'd really prefer if we convert this to a module instead. (And all the
> other PCI host drivers.)
>
> > Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
>
> This happened!?
It's in linux-next in my tree, but is looking like it might be reverted
soon. But finding these issues is good.
thanks,
greg k-h
^ 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