* Re: [PATCH 1/4] mm: introduce debug_pagealloc_map_pages() helper
From: David Hildenbrand @ 2020-10-26 11:55 UTC (permalink / raw)
To: Mike Rapoport
Cc: Peter Zijlstra, Dave Hansen, linux-mm, Paul Mackerras,
Pavel Machek, H. Peter Anvin, sparclinux, Christoph Lameter,
Will Deacon, linux-riscv, linux-s390, x86, Mike Rapoport,
Christian Borntraeger, Ingo Molnar, Catalin Marinas, Len Brown,
Albert Ou, Vasily Gorbik, linux-pm, Heiko Carstens,
David Rientjes, Borislav Petkov, Andy Lutomirski, Paul Walmsley,
Kirill A. Shutemov, Thomas Gleixner, Joonsoo Kim,
linux-arm-kernel, Rafael J. Wysocki, linux-kernel, Pekka Enberg,
Palmer Dabbelt, Andrew Morton, Edgecombe, Rick P, linuxppc-dev,
David S. Miller
In-Reply-To: <20201026115443.GF1154158@kernel.org>
On 26.10.20 12:54, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 12:05:13PM +0100, David Hildenbrand wrote:
>> On 25.10.20 11:15, Mike Rapoport wrote:
>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>
>>> When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the
>>> kernel direct mapping after free_pages(). The pages than need to be
>>> mapped back before they could be used. Theese mapping operations use
>>> __kernel_map_pages() guarded with with debug_pagealloc_enabled().
>>>
>>> The only place that calls __kernel_map_pages() without checking
>>> whether DEBUG_PAGEALLOC is enabled is the hibernation code that
>>> presumes availability of this function when ARCH_HAS_SET_DIRECT_MAP
>>> is set. Still, on arm64, __kernel_map_pages() will bail out when
>>> DEBUG_PAGEALLOC is not enabled but set_direct_map_invalid_noflush()
>>> may render some pages not present in the direct map and hibernation
>>> code won't be able to save such pages.
>>>
>>> To make page allocation debugging and hibernation interaction more
>>> robust, the dependency on DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP
>>> has to be made more explicit.
>>>
>>> Start with combining the guard condition and the call to
>>> __kernel_map_pages() into a single debug_pagealloc_map_pages()
>>> function to emphasize that __kernel_map_pages() should not be called
>>> without DEBUG_PAGEALLOC and use this new function to map/unmap pages
>>> when page allocation debug is enabled.
>>>
>>> As the only remaining user of kernel_map_pages() is the hibernation
>>> code, mode that function into kernel/power/snapshot.c closer to a
>>> caller.
>>
>> s/mode/move/
>>
>>>
>>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> ---
>>> include/linux/mm.h | 16 +++++++--------- kernel/power/snapshot.c
>>> | 11 +++++++++++ mm/memory_hotplug.c | 3 +-- mm/page_alloc.c
>>> | 6 ++---- mm/slab.c | 8 +++----- 5 files changed, 24
>>> insertions(+), 20 deletions(-)
>>>
>>> diff --git a/include/linux/mm.h b/include/linux/mm.h index
>>> ef360fe70aaf..14e397f3752c 100644 --- a/include/linux/mm.h +++
>>> b/include/linux/mm.h @@ -2927,21 +2927,19 @@ static inline bool
>>> debug_pagealloc_enabled_static(void) #if
>>> defined(CONFIG_DEBUG_PAGEALLOC) ||
>>> defined(CONFIG_ARCH_HAS_SET_DIRECT_MAP) extern void
>>> __kernel_map_pages(struct page *page, int numpages, int enable);
>>>
>>> -/* - * When called in DEBUG_PAGEALLOC context, the call should most
>>> likely be - * guarded by debug_pagealloc_enabled() or
>>> debug_pagealloc_enabled_static() - */ -static inline void
>>> -kernel_map_pages(struct page *page, int numpages, int enable)
>>> +static inline void debug_pagealloc_map_pages(struct page *page, +
>>> int numpages, int enable) { - __kernel_map_pages(page, numpages,
>>> enable); + if (debug_pagealloc_enabled_static()) +
>>> __kernel_map_pages(page, numpages, enable); } + #ifdef
>>> CONFIG_HIBERNATION extern bool kernel_page_present(struct page
>>> *page); #endif /* CONFIG_HIBERNATION */ #else /*
>>> CONFIG_DEBUG_PAGEALLOC || CONFIG_ARCH_HAS_SET_DIRECT_MAP */ -static
>>> inline void -kernel_map_pages(struct page *page, int numpages, int
>>> enable) {} +static inline void debug_pagealloc_map_pages(struct page
>>> *page, + int numpages, int enable) {} #ifdef
>>> CONFIG_HIBERNATION static inline bool kernel_page_present(struct page
>>> *page) { return true; } #endif /* CONFIG_HIBERNATION */ diff --git
>>> a/kernel/power/snapshot.c b/kernel/power/snapshot.c index
>>> 46b1804c1ddf..fa499466f645 100644 --- a/kernel/power/snapshot.c +++
>>> b/kernel/power/snapshot.c @@ -76,6 +76,17 @@ static inline void
>>> hibernate_restore_protect_page(void *page_address) {} static inline
>>> void hibernate_restore_unprotect_page(void *page_address) {} #endif
>>> /* CONFIG_STRICT_KERNEL_RWX && CONFIG_ARCH_HAS_SET_MEMORY */
>>>
>>> +#if defined(CONFIG_DEBUG_PAGEALLOC) ||
>>> defined(CONFIG_ARCH_HAS_SET_DIRECT_MAP) +static inline void
>>> +kernel_map_pages(struct page *page, int numpages, int enable) +{ +
>>> __kernel_map_pages(page, numpages, enable); +} +#else +static inline
>>> void +kernel_map_pages(struct page *page, int numpages, int enable)
>>> {} +#endif +
>>
>> That change should go into a separate patch.
>
> Hmm, I beleive you refer to moving kernel_map_pages() to snapshot.c,
> right?
Sorry, yes!
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: fsl_aud2htx: Add aud2htx module driver
From: Mark Brown @ 2020-10-26 13:30 UTC (permalink / raw)
To: Shengjiu Wang
Cc: devicetree, alsa-devel, timur, Xiubo.Lee, lgirdwood, linuxppc-dev,
tiwai, perex, nicoleotsuka, robh+dt, festevam, linux-kernel
In-Reply-To: <1603708855-2663-2-git-send-email-shengjiu.wang@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]
On Mon, Oct 26, 2020 at 06:40:55PM +0800, Shengjiu Wang wrote:
> +static int fsl_aud2htx_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params,
> + struct snd_soc_dai *cpu_dai)
> +{
> + struct fsl_aud2htx *aud2htx = snd_soc_dai_get_drvdata(cpu_dai);
> +
> + /* DMA request when number of entries < WTMK_LOW */
> + regmap_update_bits(aud2htx->regmap, AUD2HTX_CTRL_EXT,
> + AUD2HTX_CTRE_DT_MASK, 0);
> +
> + /* Disable interrupts*/
> + regmap_update_bits(aud2htx->regmap, AUD2HTX_IRQ_MASK,
> + AUD2HTX_WM_HIGH_IRQ_MASK |
> + AUD2HTX_WM_LOW_IRQ_MASK |
> + AUD2HTX_OVF_MASK,
> + AUD2HTX_WM_HIGH_IRQ_MASK |
> + AUD2HTX_WM_LOW_IRQ_MASK |
> + AUD2HTX_OVF_MASK);
> +
> + /* Configur watermark */
> + regmap_update_bits(aud2htx->regmap, AUD2HTX_CTRL_EXT,
> + AUD2HTX_CTRE_WL_MASK,
> + AUD2HTX_WTMK_LOW << AUD2HTX_CTRE_WL_SHIFT);
> + regmap_update_bits(aud2htx->regmap, AUD2HTX_CTRL_EXT,
> + AUD2HTX_CTRE_WH_MASK,
> + AUD2HTX_WTMK_HIGH << AUD2HTX_CTRE_WH_SHIFT);
> + return 0;
> +}
This doesn't look like a hw_params operation - it doesn't appear to
reference the params at all, or even containt any conditional
statements. Shouldn't this be configured just once at driver load?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [Bug 209869] New: Kernel 5.10-rc1 fails to boot on a PowerMac G4 3, 6 at an early stage
From: bugzilla-daemon @ 2020-10-26 13:40 UTC (permalink / raw)
To: linuxppc-dev
https://bugzilla.kernel.org/show_bug.cgi?id=209869
Bug ID: 209869
Summary: Kernel 5.10-rc1 fails to boot on a PowerMac G4 3,6 at
an early stage
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.10-rc1
Hardware: PPC-32
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: PPC-32
Assignee: platform_ppc-32@kernel-bugs.osdl.org
Reporter: erhard_f@mailbox.org
Regression: Yes
Created attachment 293201
--> https://bugzilla.kernel.org/attachment.cgi?id=293201&action=edit
kernel .config (5.10-rc1, PowerMac G4 DP)
With current 5.10-rc1 my PowerMac G4 DP fails to boot. The kernel gets
decompressed but shortly afterwards the machine freezes, displaying in black
letters on a white screen:
done
found display : /pci@f0000000/ATY,AlteracParent@10/ATY,Alterac_B@1,
opening...
Kernel 5.9.1 works well on this machine, the kernel .config was carried over
from 5.9.1 with make oldconfig.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH v3 01/16] dt-bindings: usb: usb-hcd: Convert generic USB properties to DT schema
From: Serge Semin @ 2020-10-26 16:46 UTC (permalink / raw)
To: Chunfeng Yun, Rob Herring, Greg Kroah-Hartman, Rob Herring
Cc: Neil Armstrong, linux-kernel, Pavel Parkhomenko, Kevin Hilman,
Krzysztof Kozlowski, Andy Gross, linux-snps-arc, devicetree,
Mathias Nyman, Martin Blumenstingl, Lad Prabhakar, Alexey Malahov,
Bjorn Andersson, linux-arm-kernel, Roger Quadros, Felipe Balbi,
Yoshihiro Shimoda, linux-usb, linux-mips, Serge Semin,
Manu Gautam, linuxppc-dev
In-Reply-To: <20201021154621.a3vtoa4lriwkpnfo@mobilestation>
Folks, any comment on my previous message below?
On Wed, Oct 21, 2020 at 06:46:21PM +0300, Serge Semin wrote:
> On Wed, Oct 21, 2020 at 11:00:36AM +0800, Chunfeng Yun wrote:
> > On Tue, 2020-10-20 at 14:20 +0300, Serge Semin wrote:
> > > The generic USB HCD properties have been described in the legacy bindings
> > > text file: Documentation/devicetree/bindings/usb/generic.txt . Let's
> > > convert it' content into the USB HCD DT schema properties so all USB DT
> > ^ its?
> > > nodes would be validated to have them properly utilized.
> > >
> > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > > Reviewed-by: Rob Herring <robh@kernel.org>
> > >
> > > ---
> > >
> > > Changelog v2:
> > > - Discard '|' in all the new properties, since we don't need to preserve
> > > the text formatting.
> > > - Convert abbreviated form of the "maximum-speed" enum restriction into
> > > the multi-lined version of the list.
> > > - Drop quotes from around the string constants.
> > > ---
> > > .../devicetree/bindings/usb/generic.txt | 57 ------------
> > > .../devicetree/bindings/usb/usb-hcd.yaml | 88 +++++++++++++++++++
>
> > Do we need change the file name or modify it's title?
> > the title is "Generic USB Host Controller Device Tree Bindings", but
> > some generic properties, such as, dr_mode, usb-role-switch, otg related
> > ones, are usually used by DRD controller, this may cause some confusion.
>
> Hm, good question. A problem of the naming and the properties inclusion do
> exist here. I haven't thought that through when moved all the generic
> properties into the usb-hcd.yaml bindings file. But I don't think it's a good
> idea to rename the file. Most likely the best solution would be to split the
> functionality up as follows:
>
> 1) usb.yaml - common USB controller with generic properties for all USB modes (host, peripheral, otg):
> + $nodename
> + phys
> + phy-names
> + usb-phy
> + maximum-speed
> + phy_type
> 2) usb-hcd.yaml - DT schema for USB host controllers (EHCI/OHCI/UHCI):
> + allOf: [usb.yaml#]
> + companion
> 3) usb-xhci.yaml - DT schema for USB host controllers (xHCI):
> + allOf: [usb-hcd.yaml#]
> + usb2-lpm-disable
> + usb3-lpm-capable
> + quirk-broken-port-ped
> + imod-interval-ns
> 4) usb-drd.yaml - DT schema for USB OTG controllers:
> + otg-rev
> + hnp-disable
> + srp-disable
> + adp-disable
> + usb-role-switch
> + role-switch-default-mode
> + tpl-support
> + dr_mode: [host, peripheral, otg]
>
> So in case if an USB controller is DRD with EHCI host, then it will need
> to pass evaluation of allOf: [usb-hcd.yaml#, usb-drd.yaml#]. If an USB
> controller is DRD with xHCI host, then the next schema can be applied:
> [usb-xhci.yaml#, usb-drd.yaml#]. A conditional schema is also applicable
> here, like this:
> allOf:
> - $ref: usb-drd.yaml#
> - if:
> properties:
> dr_mode:
> const: host
> then:
> $ref: usb-hcd.yaml# (or usb-xhci.yaml#)
> else:
> #ref: usb.yaml#
>
> What do you think? @Rob, @Greg, we need your opinion here.
>
> -Sergey
>
> >
> > > 2 files changed, 88 insertions(+), 57 deletions(-)
> > > delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > deleted file mode 100644
> > > index ba472e7aefc9..000000000000
> > > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > +++ /dev/null
> > > @@ -1,57 +0,0 @@
> > > -Generic USB Properties
> > > -
> > > -Optional properties:
> > > - - maximum-speed: tells USB controllers we want to work up to a certain
> > > - speed. Valid arguments are "super-speed-plus",
> > > - "super-speed", "high-speed", "full-speed" and
> > > - "low-speed". In case this isn't passed via DT, USB
> > > - controllers should default to their maximum HW
> > > - capability.
> > > - - dr_mode: tells Dual-Role USB controllers that we want to work on a
> > > - particular mode. Valid arguments are "host",
> > > - "peripheral" and "otg". In case this attribute isn't
> > > - passed via DT, USB DRD controllers should default to
> > > - OTG.
> > > - - phy_type: tells USB controllers that we want to configure the core to support
> > > - a UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is
> > > - selected. Valid arguments are "utmi" and "utmi_wide".
> > > - In case this isn't passed via DT, USB controllers should
> > > - default to HW capability.
> > > - - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > - with which the device and its descriptors are compliant,
> > > - in binary-coded decimal (i.e. 2.0 is 0200H). This
> > > - property is used if any real OTG features(HNP/SRP/ADP)
> > > - is enabled, if ADP is required, otg-rev should be
> > > - 0x0200 or above.
> > > - - companion: phandle of a companion
> > > - - hnp-disable: tells OTG controllers we want to disable OTG HNP, normally HNP
> > > - is the basic function of real OTG except you want it
> > > - to be a srp-capable only B device.
> > > - - srp-disable: tells OTG controllers we want to disable OTG SRP, SRP is
> > > - optional for OTG device.
> > > - - adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
> > > - optional for OTG device.
> > > - - usb-role-switch: boolean, indicates that the device is capable of assigning
> > > - the USB data role (USB host or USB device) for a given
> > > - USB connector, such as Type-C, Type-B(micro).
> > > - see connector/usb-connector.yaml.
> > > - - role-switch-default-mode: indicating if usb-role-switch is enabled, the
> > > - device default operation mode of controller while usb
> > > - role is USB_ROLE_NONE. Valid arguments are "host" and
> > > - "peripheral". Defaults to "peripheral" if not
> > > - specified.
> > > -
> > > -
> > > -This is an attribute to a USB controller such as:
> > > -
> > > -dwc3@4a030000 {
> > > - compatible = "synopsys,dwc3";
> > > - reg = <0x4a030000 0xcfff>;
> > > - interrupts = <0 92 4>
> > > - usb-phy = <&usb2_phy>, <&usb3,phy>;
> > > - maximum-speed = "super-speed";
> > > - dr_mode = "otg";
> > > - phy_type = "utmi_wide";
> > > - otg-rev = <0x0200>;
> > > - adp-disable;
> > > -};
> > > diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > > index 7263b7f2b510..ee7ea205c71d 100644
> > > --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > > +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > > @@ -22,9 +22,97 @@ properties:
> > > description:
> > > Name specifier for the USB PHY
> > >
> > > + maximum-speed:
> > > + description:
> > > + Tells USB controllers we want to work up to a certain speed. In case this
> > > + isn't passed via DT, USB controllers should default to their maximum HW
> > > + capability.
> > > + $ref: /schemas/types.yaml#/definitions/string
> > > + enum:
> > > + - low-speed
> > > + - full-speed
> > > + - high-speed
> > > + - super-speed
> > > + - super-speed-plus
> > > +
> > > + dr_mode:
> > > + description:
> > > + Tells Dual-Role USB controllers that we want to work on a particular
> > > + mode. In case this attribute isn't passed via DT, USB DRD controllers
> > > + should default to OTG.
> > > + $ref: /schemas/types.yaml#/definitions/string
> > > + enum: [host, peripheral, otg]
> > > +
> > > + phy_type:
> > > + description:
> > > + Tells USB controllers that we want to configure the core to support a
> > > + UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is selected. In case
> > > + this isn't passed via DT, USB controllers should default to HW
> > > + capability.
> > > + $ref: /schemas/types.yaml#/definitions/string
> > > + enum: [utmi, utmi_wide]
> > > +
> > > + otg-rev:
> > > + description:
> > > + Tells usb driver the release number of the OTG and EH supplement with
> > > + which the device and its descriptors are compliant, in binary-coded
> > > + decimal (i.e. 2.0 is 0200H). This property is used if any real OTG
> > > + features (HNP/SRP/ADP) is enabled. If ADP is required, otg-rev should be
> > > + 0x0200 or above.
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > +
> > > + companion:
> > > + description: Phandle of a companion device
> > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > +
> > > + hnp-disable:
> > > + description:
> > > + Tells OTG controllers we want to disable OTG HNP. Normally HNP is the
> > > + basic function of real OTG except you want it to be a srp-capable only B
> > > + device.
> > > + type: boolean
> > > +
> > > + srp-disable:
> > > + description:
> > > + Tells OTG controllers we want to disable OTG SRP. SRP is optional for OTG
> > > + device.
> > > + type: boolean
> > > +
> > > + adp-disable:
> > > + description:
> > > + Tells OTG controllers we want to disable OTG ADP. ADP is optional for OTG
> > > + device.
> > > + type: boolean
> > > +
> > > + usb-role-switch:
> > > + description:
> > > + Indicates that the device is capable of assigning the USB data role
> > > + (USB host or USB device) for a given USB connector, such as Type-C,
> > > + Type-B(micro). See connector/usb-connector.yaml.
> > > +
> > > + role-switch-default-mode:
> > > + description:
> > > + Indicates if usb-role-switch is enabled, the device default operation
> > > + mode of controller while usb role is USB_ROLE_NONE.
> > > + $ref: /schemas/types.yaml#/definitions/string
> > > + enum: [host, peripheral]
> > > + default: peripheral
> > > +
> > > examples:
> > > - |
> > > usb {
> > > phys = <&usb2_phy1>, <&usb3_phy1>;
> > > phy-names = "usb";
> > > };
> > > + - |
> > > + usb@4a030000 {
> > > + compatible = "snps,dwc3";
> > > + reg = <0x4a030000 0xcfff>;
> > > + interrupts = <0 92 4>;
> > > + usb-phy = <&usb2_phy>, <&usb3_phy>;
> > > + maximum-speed = "super-speed";
> > > + dr_mode = "otg";
> > > + phy_type = "utmi_wide";
> > > + otg-rev = <0x0200>;
> > > + adp-disable;
> > > + };
> >
^ permalink raw reply
* Re: [PATCH 0/4] arch, mm: improve robustness of direct map manipulation
From: Edgecombe, Rick P @ 2020-10-26 18:05 UTC (permalink / raw)
To: rppt@kernel.org
Cc: david@redhat.com, peterz@infradead.org, catalin.marinas@arm.com,
dave.hansen@linux.intel.com, linux-mm@kvack.org, paulus@samba.org,
pavel@ucw.cz, hpa@zytor.com, sparclinux@vger.kernel.org,
cl@linux.com, will@kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, x86@kernel.org, rppt@linux.ibm.com,
borntraeger@de.ibm.com, mingo@redhat.com, rientjes@google.com,
Brown, Len, aou@eecs.berkeley.edu, gor@linux.ibm.com,
linux-pm@vger.kernel.org, hca@linux.ibm.com, bp@alien8.de,
luto@kernel.org, paul.walmsley@sifive.com, kirill@shutemov.name,
tglx@linutronix.de, iamjoonsoo.kim@lge.com,
linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org, penberg@kernel.org,
palmer@dabbelt.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20201026090526.GA1154158@kernel.org>
On Mon, 2020-10-26 at 11:05 +0200, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 01:13:52AM +0000, Edgecombe, Rick P wrote:
> > On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> > > Indeed, for architectures that define
> > > CONFIG_ARCH_HAS_SET_DIRECT_MAP
> > > it is
> > > possible that __kernel_map_pages() would fail, but since this
> > > function is
> > > void, the failure will go unnoticed.
> >
> > Could you elaborate on how this could happen? Do you mean during
> > runtime today or if something new was introduced?
>
> A failure in__kernel_map_pages() may happen today. For instance, on
> x86
> if the kernel is built with DEBUG_PAGEALLOC.
>
> __kernel_map_pages(page, 1, 0);
>
> will need to split, say, 2M page and during the split an allocation
> of
> page table could fail.
On x86 at least, DEBUG_PAGEALLOC expects to never have to break a page
on the direct map and even disables locking in cpa because it assumes
this. If this is happening somehow anyway then we should probably fix
that. Even if it's a debug feature, it will not be as useful if it is
causing its own crashes.
I'm still wondering if there is something I'm missing here. It seems
like you are saying there is a bug in some arch's, so let's add a WARN
in cross-arch code to log it as it crashes. A warn and making things
clearer seem like good ideas, but if there is a bug we should fix it.
The code around the callers still functionally assume re-mapping can't
fail.
> Currently, the only user of __kernel_map_pages() outside
> DEBUG_PAGEALLOC
> is hibernation, but I think it would be safer to entirely prevent
> usage
> of __kernel_map_pages() when DEBUG_PAGEALLOC=n.
I totally agree it's error prone FWIW. On x86, my mental model of how
it is supposed to work is: If a page is 4k and NP it cannot fail to be
remapped. set_direct_map_invalid_noflush() should result in 4k NP
pages, and DEBUG_PAGEALLOC should result in all 4k pages on the direct
map. Are you seeing this violated or do I have wrong assumptions?
Beyond whatever you are seeing, for the latter case of new things
getting introduced to an interface with hidden dependencies... Another
edge case could be a new caller to set_memory_np() could result in
large NP pages. None of the callers today should cause this AFAICT, but
it's not great to rely on the callers to know these details.
^ permalink raw reply
* Re: [PATCH] ibmveth: Fix use of ibmveth in a bridge.
From: Jakub Kicinski @ 2020-10-26 18:52 UTC (permalink / raw)
To: Michal Suchanek
Cc: Cristobal Forno, netdev, linux-kernel, Thomas Bogendoerfer,
Paul Mackerras, linuxppc-dev, David S. Miller, Cris Forno
In-Reply-To: <20201026104221.26570-1-msuchanek@suse.de>
On Mon, 26 Oct 2020 11:42:21 +0100 Michal Suchanek wrote:
> From: Thomas Bogendoerfer <tbogendoerfer@suse.de>
>
> The check for src mac address in ibmveth_is_packet_unsupported is wrong.
> Commit 6f2275433a2f wanted to shut down messages for loopback packets,
> but now suppresses bridged frames, which are accepted by the hypervisor
> otherwise bridging won't work at all.
>
> Fixes: 6f2275433a2f ("ibmveth: Detect unsupported packets before sending to the hypervisor")
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Since the From: line says Thomas we need a signoff from him.
^ permalink raw reply
* Re: [PATCH 2/4] PM: hibernate: improve robustness of mapping pages in the direct map
From: Edgecombe, Rick P @ 2020-10-26 18:57 UTC (permalink / raw)
To: rppt@kernel.org
Cc: david@redhat.com, peterz@infradead.org, catalin.marinas@arm.com,
dave.hansen@linux.intel.com, linux-mm@kvack.org, paulus@samba.org,
pavel@ucw.cz, hpa@zytor.com, sparclinux@vger.kernel.org,
cl@linux.com, will@kernel.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, x86@kernel.org, rppt@linux.ibm.com,
borntraeger@de.ibm.com, mingo@redhat.com, rientjes@google.com,
Brown, Len, aou@eecs.berkeley.edu, gor@linux.ibm.com,
linux-pm@vger.kernel.org, hca@linux.ibm.com, bp@alien8.de,
luto@kernel.org, paul.walmsley@sifive.com, kirill@shutemov.name,
tglx@linutronix.de, iamjoonsoo.kim@lge.com,
linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org, penberg@kernel.org,
palmer@dabbelt.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
In-Reply-To: <20201026091554.GB1154158@kernel.org>
On Mon, 2020-10-26 at 11:15 +0200, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 12:38:32AM +0000, Edgecombe, Rick P wrote:
> > On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote:
> > > From: Mike Rapoport <rppt@linux.ibm.com>
> > >
> > > When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page
> > > may
> > > be
> > > not present in the direct map and has to be explicitly mapped
> > > before
> > > it
> > > could be copied.
> > >
> > > On arm64 it is possible that a page would be removed from the
> > > direct
> > > map
> > > using set_direct_map_invalid_noflush() but __kernel_map_pages()
> > > will
> > > refuse
> > > to map this page back if DEBUG_PAGEALLOC is disabled.
> >
> > It looks to me that arm64 __kernel_map_pages() will still attempt
> > to
> > map it if rodata_full is true, how does this happen?
>
> Unless I misread the code, arm64 requires both rodata_full and
> debug_pagealloc_enabled() to be true for __kernel_map_pages() to do
> anything.
> But rodata_full condition applies to set_direct_map_*_noflush() as
> well,
> so with !rodata_full the linear map won't be ever changed.
Hmm, looks to me that __kernel_map_pages() will only skip it if both
debug pagealloc and rodata_full are false.
But now I'm wondering if maybe we could simplify things by just moving
the hibernate unmapped page logic off of the direct map. On x86,
text_poke() used to use this reserved fixmap pte thing that it could
rely on to remap memory with. If hibernate had some separate pte for
remapping like that, then we could not have any direct map restrictions
caused by it/kernel_map_pages(), and it wouldn't have to worry about
relying on anything else.
^ permalink raw reply
* Re: [PATCH] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Guenter Roeck @ 2020-10-26 19:36 UTC (permalink / raw)
To: Joe Perches
Cc: Miguel Ojeda, Linus Torvalds, Nick Desaulniers, linux-kernel,
clang-built-linux, linuxppc-dev
In-Reply-To: <fe8abcc88cff676ead8ee48db1e993e63b0611c7.1603327264.git.joe@perches.com>
On Wed, Oct 21, 2020 at 07:36:07PM -0700, Joe Perches wrote:
> Use a more generic form for __section that requires quotes to avoid
> complications with clang and gcc differences.
>
> Remove the quote operator # from compiler_attributes.h __section macro.
>
> Convert all unquoted __section(foo) uses to quoted __section("foo").
> Also convert __attribute__((section("foo"))) uses to __section("foo")
> even if the __attribute__ has multiple list entry forms.
>
> Conversion done using a script:
>
> Link: https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/2-convert_section.pl
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Reviewed-by: Nick Desaulniers <ndesaulniers@gooogle.com>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
s390 (all builds):
Error log:
error: section .boot.preserved.data differs between vmlinux and arch/s390/boot/compressed/vmlinux
make[2]: *** [arch/s390/boot/section_cmp.boot.preserved.data] Error 1
make[2]: *** Waiting for unfinished jobs....
error: section .boot.data differs between vmlinux and arch/s390/boot/compressed/vmlinux
make[2]: *** [arch/s390/boot/section_cmp.boot.data] Error 1
make[1]: *** [bzImage] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [__sub-make] Error 2
Reverting this patch fixes the problem.
Guenter
^ permalink raw reply
* Re: [PATCH] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Guenter Roeck @ 2020-10-26 19:41 UTC (permalink / raw)
To: Joe Perches
Cc: Miguel Ojeda, Linus Torvalds, Nick Desaulniers, linux-kernel,
clang-built-linux, linuxppc-dev
In-Reply-To: <fe8abcc88cff676ead8ee48db1e993e63b0611c7.1603327264.git.joe@perches.com>
On Wed, Oct 21, 2020 at 07:36:07PM -0700, Joe Perches wrote:
> Use a more generic form for __section that requires quotes to avoid
> complications with clang and gcc differences.
>
> Remove the quote operator # from compiler_attributes.h __section macro.
>
> Convert all unquoted __section(foo) uses to quoted __section("foo").
> Also convert __attribute__((section("foo"))) uses to __section("foo")
> even if the __attribute__ has multiple list entry forms.
>
> Conversion done using a script:
>
> Link: https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/2-convert_section.pl
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Reviewed-by: Nick Desaulniers <ndesaulniers@gooogle.com>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> ---
>
make ARCH=um SUBARCH=x86_64 defconfig:
Building um:defconfig ... failed
--------------
Error log:
arch/um/kernel/skas/clone.c:24:16: error: expected declaration specifiers or '...' before string constant
24 | void __section(".__syscall_stub")
| ^~~~~~~~~~~~~~~~~
make[3]: *** [arch/um/kernel/skas/clone.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [arch/um/kernel/skas] Error 2
make[2]: *** Waiting for unfinished jobs....
arch/um/os-Linux/signal.c: In function 'sig_handler_common':
arch/um/os-Linux/signal.c:51:1: warning: the frame size of 2960 bytes is larger than 1024 bytes [-Wframe-larger-than=]
51 | }
| ^
arch/um/os-Linux/signal.c: In function 'timer_real_alarm_handler':
arch/um/os-Linux/signal.c:95:1: warning: the frame size of 2960 bytes is larger than 1024 bytes [-Wframe-larger-than=]
95 | }
| ^
make[1]: *** [arch/um/kernel] Error 2
make[1]: *** Waiting for unfinished jobs....
arch/x86/um/stub_segv.c:11:16: error: expected declaration specifiers or '...' before string constant
11 | void __section(".__syscall_stub")
| ^~~~~~~~~~~~~~~~~
make[2]: *** [arch/x86/um/stub_segv.o] Error 1
make[1]: *** [arch/x86/um] Error 2
make: *** [__sub-make] Error 2
As with s390, reverting this patch fixes the problem.
Guenter
^ permalink raw reply
* Re: [PATCH] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Nathan Chancellor @ 2020-10-26 19:44 UTC (permalink / raw)
To: Guenter Roeck
Cc: Miguel Ojeda, linuxppc-dev, Nick Desaulniers, linux-kernel,
clang-built-linux, Joe Perches, Linus Torvalds
In-Reply-To: <20201026193652.GA77796@roeck-us.net>
On Mon, Oct 26, 2020 at 12:36:52PM -0700, Guenter Roeck wrote:
> On Wed, Oct 21, 2020 at 07:36:07PM -0700, Joe Perches wrote:
> > Use a more generic form for __section that requires quotes to avoid
> > complications with clang and gcc differences.
> >
> > Remove the quote operator # from compiler_attributes.h __section macro.
> >
> > Convert all unquoted __section(foo) uses to quoted __section("foo").
> > Also convert __attribute__((section("foo"))) uses to __section("foo")
> > even if the __attribute__ has multiple list entry forms.
> >
> > Conversion done using a script:
> >
> > Link: https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/2-convert_section.pl
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
> > Reviewed-by: Nick Desaulniers <ndesaulniers@gooogle.com>
> > Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
>
> s390 (all builds):
>
> Error log:
> error: section .boot.preserved.data differs between vmlinux and arch/s390/boot/compressed/vmlinux
> make[2]: *** [arch/s390/boot/section_cmp.boot.preserved.data] Error 1
> make[2]: *** Waiting for unfinished jobs....
> error: section .boot.data differs between vmlinux and arch/s390/boot/compressed/vmlinux
> make[2]: *** [arch/s390/boot/section_cmp.boot.data] Error 1
> make[1]: *** [bzImage] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make: *** [__sub-make] Error 2
>
> Reverting this patch fixes the problem.
>
> Guenter
>
Seems like this should be fixed by commit 8e90b4b1305a ("s390: correct
__bootdata / __bootdata_preserved macros").
Cheers,
Nathan
^ permalink raw reply
* Re: Build regressions/improvements in v5.10-rc1
From: Nathan Lynch @ 2020-10-26 20:17 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Scott Cheloha, linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <CAMuHMdXbsJPnsXg6bA_e32zJkBG1Zzqj-ja5WzHDKL0d9OcfPg@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Mon, Oct 26, 2020 at 10:46 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> Below is the list of build error/warning regressions/improvements in
>> v5.10-rc1[1] compared to v5.9[2].
>>
>> Summarized:
>> - build errors: +3/-7
>> - build warnings: +26/-28
>>
>> Happy fixing! ;-)
>>
>> Thanks to the linux-next team for providing the build service.
>>
>> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3650b228f83adda7e5ee532e2b90429c03f7b9ec/ (all 192 configs)
>> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/bbf5c979011a099af5dc76498918ed7df445635b/ (all 192 configs)
>>
>>
>> *** ERRORS ***
>>
>> 3 error regressions:
>> + /kisskb/src/arch/um/kernel/skas/clone.c: error: expected declaration specifiers or '...' before string constant: => 24:16
>
> um-all{mod,yes}config
>
>> + error: hotplug-memory.c: undefined reference to `of_drconf_to_nid_single': => .text+0x5e0)
>
> powerpc-gcc5/pseries_le_defconfig+NO_NUMA
Probably introduced by:
commit 72cdd117c449896c707fc6cfe5b90978160697d0
Author: Scott Cheloha <cheloha@linux.ibm.com>
Date: Wed Sep 16 09:51:22 2020 -0500
pseries/hotplug-memory: hot-add: skip redundant LMB lookup
Scott?
^ permalink raw reply
* Re: [PATCH] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Linus Torvalds @ 2020-10-26 20:33 UTC (permalink / raw)
To: Guenter Roeck
Cc: Miguel Ojeda, Nick Desaulniers, Linux Kernel Mailing List,
clang-built-linux, Joe Perches, linuxppc-dev
In-Reply-To: <20201026194127.GA106214@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
On Mon, Oct 26, 2020 at 12:41 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> make ARCH=um SUBARCH=x86_64 defconfig:
>
> Building um:defconfig ... failed
> --------------
> Error log:
> arch/um/kernel/skas/clone.c:24:16: error: expected declaration specifiers or '...' before string constant
> arch/x86/um/stub_segv.c:11:16: error: expected declaration specifiers or '...' before string constant
Weird. Is __section() not defined somehow for those files?
It does look like they have very minimal headers, so undoing that
patch just for those two files is likely the right thing to do.
> As with s390, reverting this patch fixes the problem.
s390 should be fixed already.
Is the attached minimal patch sufficient for um to get back to working
order, or is there something else hiding there too?
Linus
[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 935 bytes --]
arch/um/kernel/skas/clone.c | 2 +-
arch/x86/um/stub_segv.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git b/arch/um/kernel/skas/clone.c a/arch/um/kernel/skas/clone.c
index 95c355181dcd..bfb70c456b30 100644
--- b/arch/um/kernel/skas/clone.c
+++ a/arch/um/kernel/skas/clone.c
@@ -21,7 +21,7 @@
* on some systems.
*/
-void __section(".__syscall_stub")
+void __attribute__ ((__section__ (".__syscall_stub")))
stub_clone_handler(void)
{
struct stub_data *data = (struct stub_data *) STUB_DATA;
diff --git b/arch/x86/um/stub_segv.c a/arch/x86/um/stub_segv.c
index fdcd58af707a..27361cbb7ca9 100644
--- b/arch/x86/um/stub_segv.c
+++ a/arch/x86/um/stub_segv.c
@@ -8,7 +8,7 @@
#include <sysdep/mcontext.h>
#include <sys/ucontext.h>
-void __section(".__syscall_stub")
+void __attribute__ ((__section__ (".__syscall_stub")))
stub_segv_handler(int sig, siginfo_t *info, void *p)
{
ucontext_t *uc = p;
^ permalink raw reply related
* Re: [PATCH] ibmveth: Fix use of ibmveth in a bridge.
From: Thomas Bogendoerfer @ 2020-10-26 19:04 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Cristobal Forno, netdev, linux-kernel, Paul Mackerras,
Michal Suchanek, linuxppc-dev, David S. Miller, Cris Forno
In-Reply-To: <20201026115237.21b114fe@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
On Mon, 26 Oct 2020 11:52:37 -0700
Jakub Kicinski <kuba@kernel.org> wrote:
> On Mon, 26 Oct 2020 11:42:21 +0100 Michal Suchanek wrote:
> > From: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> >
> > The check for src mac address in ibmveth_is_packet_unsupported is wrong.
> > Commit 6f2275433a2f wanted to shut down messages for loopback packets,
> > but now suppresses bridged frames, which are accepted by the hypervisor
> > otherwise bridging won't work at all.
> >
> > Fixes: 6f2275433a2f ("ibmveth: Detect unsupported packets before sending to the hypervisor")
> > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
>
> Since the From: line says Thomas we need a signoff from him.
you can add
Signed-off-by: tbogendoerfer@suse.de
Thomas.
--
SUSE Software Solutions Germany GmbH
HRB 36809 (AG Nürnberg)
Geschäftsführer: Felix Imendörffer
^ permalink raw reply
* Re: [PATCH] treewide: Convert macro and uses of __section(foo) to __section("foo")
From: Guenter Roeck @ 2020-10-26 21:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Miguel Ojeda, Nick Desaulniers, Linux Kernel Mailing List,
clang-built-linux, Joe Perches, linuxppc-dev
In-Reply-To: <CAHk-=whjhHuwANGerJLJyn7jXCfMQMiaBAW+o2r_T+n=Ki+New@mail.gmail.com>
On Mon, Oct 26, 2020 at 01:33:48PM -0700, Linus Torvalds wrote:
> On Mon, Oct 26, 2020 at 12:41 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > make ARCH=um SUBARCH=x86_64 defconfig:
> >
> > Building um:defconfig ... failed
> > --------------
> > Error log:
> > arch/um/kernel/skas/clone.c:24:16: error: expected declaration specifiers or '...' before string constant
> > arch/x86/um/stub_segv.c:11:16: error: expected declaration specifiers or '...' before string constant
>
> Weird. Is __section() not defined somehow for those files?
>
> It does look like they have very minimal headers, so undoing that
> patch just for those two files is likely the right thing to do.
>
> > As with s390, reverting this patch fixes the problem.
>
> s390 should be fixed already.
>
> Is the attached minimal patch sufficient for um to get back to working
> order, or is there something else hiding there too?
>
That works for me.
Tested-by: Guenter Roeck <linux@roeck-us.net>
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH] ibmvscsi: fix race potential race after loss of transport
From: Martin K. Petersen @ 2020-10-26 22:17 UTC (permalink / raw)
To: Tyrel Datwyler
Cc: martin.petersen, linux-scsi, linux-kernel, james.bottomley,
brking, linuxppc-dev
In-Reply-To: <20201025001355.4527-1-tyreld@linux.ibm.com>
Tyrel,
> After a loss of tranport due to an adatper migration or
> crash/disconnect from the host partner there is a tiny window where we
> can race adjusting the request_limit of the adapter.
Applied to 5.10/scsi-fixes, thanks!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH v2] ASoC: fsl_spdif: Add support for higher sample rates
From: Mark Brown @ 2020-10-26 23:45 UTC (permalink / raw)
To: Xiubo.Lee, timur, Shengjiu Wang, perex, tiwai, festevam,
alsa-devel, nicoleotsuka
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1602557360-18795-1-git-send-email-shengjiu.wang@nxp.com>
On Tue, 13 Oct 2020 10:49:20 +0800, Shengjiu Wang wrote:
> Add 88200Hz and 176400Hz sample rates support for TX.
> Add 88200Hz, 176400Hz, 192000Hz sample rates support for RX.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl_spdif: Add support for higher sample rates
commit: 1bfa3eaa4511256ab14555ab2573e6e75194b1fa
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [REGRESSION] mm: process_vm_readv testcase no longer works after compat_prcoess_vm_readv removed
From: Kyle Huey @ 2020-10-26 22:55 UTC (permalink / raw)
To: open list, Christoph Hellwig
Cc: linux-aio, David Howells, linux-mm, keyrings, sparclinux,
Robert O'Callahan, linux-arch, linux-s390, linux-scsi,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Linus Torvalds,
Arnd Bergmann, linux-block, Alexander Viro, io-uring,
moderated list:ARM PORT, Jens Axboe, linux-parisc, netdev,
linux-mips, linux-security-module,
open list:FILESYSTEMS (VFS and infrastructure), Andrew Morton,
linuxppc-dev
A test program from the rr[0] test suite, vm_readv_writev[1], no
longer works on 5.10-rc1 when compiled as a 32 bit binary and executed
on a 64 bit kernel. The first process_vm_readv call (on line 35) now
fails with EFAULT. I have bisected this to
c3973b401ef2b0b8005f8074a10e96e3ea093823.
It should be fairly straightforward to extract the test case from our
repository into a standalone program.
- Kyle
[0] https://rr-project.org/
[1] https://github.com/mozilla/rr/blob/master/src/test/vm_readv_writev.c
^ permalink raw reply
* Re: [PATCH v4 0/2] DAI driver for new XCVR IP
From: Mark Brown @ 2020-10-26 23:45 UTC (permalink / raw)
To: linuxppc-dev, Liam Girdwood, Timur Tabi, Nicolin Chen,
Viorel Suman, Philipp Zabel, Shengjiu Wang,
Cosmin-Gabriel Samoila, linux-kernel, Fabio Estevam, Rob Herring,
Xiubo Li, Matthias Schiffer, Jaroslav Kysela, devicetree,
Takashi Iwai, Viorel Suman (OSS), alsa-devel
In-Reply-To: <20201013121733.83684-1-viorel.suman@oss.nxp.com>
On Tue, 13 Oct 2020 15:17:31 +0300, Viorel Suman (OSS) wrote:
> DAI driver for new XCVR IP found in i.MX8MP.
>
> Viorel Suman (2):
> ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
> ASoC: dt-bindings: fsl_xcvr: Add document for XCVR
>
> Changes since v1:
> - improved 6- and 12-ch layout comment
> - used regmap polling function, improved
> clocks handling in runtime_resume
> - added FW size check in FW load function,
> improved IRQ handler, removed dummy IRQ handlers
> - fixed yaml file
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
commit: 28564486866fa889b78264360022c94836fa8072
[2/2] ASoC: dt-bindings: fsl_xcvr: Add document for XCVR
commit: 0afb88d5a602488f877380ad1ec37cc20c927c68
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: dt-bindings: fsl_spdif: Add new compatible string for i.MX8QM
From: Mark Brown @ 2020-10-26 23:46 UTC (permalink / raw)
To: Xiubo.Lee, timur, lgirdwood, Shengjiu Wang, perex, devicetree,
tiwai, festevam, robh+dt, alsa-devel, nicoleotsuka
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1602739728-4433-1-git-send-email-shengjiu.wang@nxp.com>
On Thu, 15 Oct 2020 13:28:47 +0800, Shengjiu Wang wrote:
> Add new compatible string "fsl,imx8qm-spdif" for supporting spdif
> module on i.MX8QM.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: dt-bindings: fsl_spdif: Add new compatible string for i.MX8QM
commit: 87b2fc1139a13cf81d0a95fb2cbaba7daeee8908
[2/2] ASoC: fsl_spdif: Add support for i.MX8QM platform
commit: 516232e3609f485be04445b03723fbaed64a5321
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* [PATCH AUTOSEL 5.9 001/147] powerpc/vmemmap: Fix memory leak with vmemmap list allocation failures.
From: Sasha Levin @ 2020-10-26 23:46 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, Aneesh Kumar K.V, linuxppc-dev
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
[ Upstream commit ccaea15296f9773abd43aaa17ee4b88848e4a505 ]
If we fail to allocate vmemmap list, we don't keep track of allocated
vmemmap block buf. Hence on section deactivate we skip vmemmap block
buf free. This results in memory leak.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200731113500.248306-1-aneesh.kumar@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/mm/init_64.c | 35 ++++++++++++++++++++++++++++-------
1 file changed, 28 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index 8459056cce671..2ae42c2a5cf04 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -162,16 +162,16 @@ static __meminit struct vmemmap_backing * vmemmap_list_alloc(int node)
return next++;
}
-static __meminit void vmemmap_list_populate(unsigned long phys,
- unsigned long start,
- int node)
+static __meminit int vmemmap_list_populate(unsigned long phys,
+ unsigned long start,
+ int node)
{
struct vmemmap_backing *vmem_back;
vmem_back = vmemmap_list_alloc(node);
if (unlikely(!vmem_back)) {
- WARN_ON(1);
- return;
+ pr_debug("vmemap list allocation failed\n");
+ return -ENOMEM;
}
vmem_back->phys = phys;
@@ -179,6 +179,7 @@ static __meminit void vmemmap_list_populate(unsigned long phys,
vmem_back->list = vmemmap_list;
vmemmap_list = vmem_back;
+ return 0;
}
static bool altmap_cross_boundary(struct vmem_altmap *altmap, unsigned long start,
@@ -199,6 +200,7 @@ static bool altmap_cross_boundary(struct vmem_altmap *altmap, unsigned long star
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
struct vmem_altmap *altmap)
{
+ bool altmap_alloc;
unsigned long page_size = 1 << mmu_psize_defs[mmu_vmemmap_psize].shift;
/* Align to the page size of the linear mapping. */
@@ -228,13 +230,32 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
p = vmemmap_alloc_block_buf(page_size, node, altmap);
if (!p)
pr_debug("altmap block allocation failed, falling back to system memory");
+ else
+ altmap_alloc = true;
}
- if (!p)
+ if (!p) {
p = vmemmap_alloc_block_buf(page_size, node, NULL);
+ altmap_alloc = false;
+ }
if (!p)
return -ENOMEM;
- vmemmap_list_populate(__pa(p), start, node);
+ if (vmemmap_list_populate(__pa(p), start, node)) {
+ /*
+ * If we don't populate vmemap list, we don't have
+ * the ability to free the allocated vmemmap
+ * pages in section_deactivate. Hence free them
+ * here.
+ */
+ int nr_pfns = page_size >> PAGE_SHIFT;
+ unsigned long page_order = get_order(page_size);
+
+ if (altmap_alloc)
+ vmem_altmap_free(altmap, nr_pfns);
+ else
+ free_pages((unsigned long)p, page_order);
+ return -ENOMEM;
+ }
pr_debug(" * %016lx..%016lx allocated at %p\n",
start, start + page_size, p);
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.9 002/147] powerpc/powernv/smp: Fix spurious DBG() warning
From: Sasha Levin @ 2020-10-26 23:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linuxppc-dev, Oliver O'Halloran, Joel Stanley
In-Reply-To: <20201026234905.1022767-1-sashal@kernel.org>
From: Oliver O'Halloran <oohall@gmail.com>
[ Upstream commit f6bac19cf65c5be21d14a0c9684c8f560f2096dd ]
When building with W=1 we get the following warning:
arch/powerpc/platforms/powernv/smp.c: In function ‘pnv_smp_cpu_kill_self’:
arch/powerpc/platforms/powernv/smp.c:276:16: error: suggest braces around
empty body in an ‘if’ statement [-Werror=empty-body]
276 | cpu, srr1);
| ^
cc1: all warnings being treated as errors
The full context is this block:
if (srr1 && !generic_check_cpu_restart(cpu))
DBG("CPU%d Unexpected exit while offline srr1=%lx!\n",
cpu, srr1);
When building with DEBUG undefined DBG() expands to nothing and GCC emits
the warning due to the lack of braces around an empty statement.
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200804005410.146094-2-oohall@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/powernv/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
index b2ba3e95bda73..bbf361f23ae86 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -43,7 +43,7 @@
#include <asm/udbg.h>
#define DBG(fmt...) udbg_printf(fmt)
#else
-#define DBG(fmt...)
+#define DBG(fmt...) do { } while (0)
#endif
static void pnv_smp_setup_cpu(int cpu)
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.9 005/147] powerpc/watchpoint/ptrace: Fix SETHWDEBUG when CONFIG_HAVE_HW_BREAKPOINT=N
From: Sasha Levin @ 2020-10-26 23:46 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Ravi Bangoria, Pedro Miraglia Franco de Carvalho,
linuxppc-dev
In-Reply-To: <20201026234905.1022767-1-sashal@kernel.org>
From: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
[ Upstream commit 9b6b7c680cc20971444d9f836e49fc98848bcd0a ]
When kernel is compiled with CONFIG_HAVE_HW_BREAKPOINT=N, user can
still create watchpoint using PPC_PTRACE_SETHWDEBUG, with limited
functionalities. But, such watchpoints are never firing because of
the missing privilege settings. Fix that.
It's safe to set HW_BRK_TYPE_PRIV_ALL because we don't really leak
any kernel address in signal info. Setting HW_BRK_TYPE_PRIV_ALL will
also help to find scenarios when kernel accesses user memory.
Reported-by: Pedro Miraglia Franco de Carvalho <pedromfc@linux.ibm.com>
Suggested-by: Pedro Miraglia Franco de Carvalho <pedromfc@linux.ibm.com>
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200902042945.129369-4-ravi.bangoria@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/ptrace/ptrace-noadv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index 697c7e4b5877f..57a0ab822334f 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -217,7 +217,7 @@ long ppc_set_hwdebug(struct task_struct *child, struct ppc_hw_breakpoint *bp_inf
return -EIO;
brk.address = ALIGN_DOWN(bp_info->addr, HW_BREAKPOINT_SIZE);
- brk.type = HW_BRK_TYPE_TRANSLATE;
+ brk.type = HW_BRK_TYPE_TRANSLATE | HW_BRK_TYPE_PRIV_ALL;
brk.len = DABR_MAX_LEN;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ)
brk.type |= HW_BRK_TYPE_READ;
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.9 007/147] powerpc: select ARCH_WANT_IRQS_OFF_ACTIVATE_MM
From: Sasha Levin @ 2020-10-26 23:46 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev, Nicholas Piggin
In-Reply-To: <20201026234905.1022767-1-sashal@kernel.org>
From: Nicholas Piggin <npiggin@gmail.com>
[ Upstream commit 66acd46080bd9e5ad2be4b0eb1d498d5145d058e ]
powerpc uses IPIs in some situations to switch a kernel thread away
from a lazy tlb mm, which is subject to the TLB flushing race
described in the changelog introducing ARCH_WANT_IRQS_OFF_ACTIVATE_MM.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200914045219.3736466-3-npiggin@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/mmu_context.h | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 787e829b6f25c..8250c0fd85285 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -148,6 +148,7 @@ config PPC
select ARCH_USE_QUEUED_RWLOCKS if PPC_QUEUED_SPINLOCKS
select ARCH_USE_QUEUED_SPINLOCKS if PPC_QUEUED_SPINLOCKS
select ARCH_WANT_IPC_PARSE_VERSION
+ select ARCH_WANT_IRQS_OFF_ACTIVATE_MM
select ARCH_WEAK_RELEASE_ACQUIRE
select BINFMT_ELF
select BUILDTIME_TABLE_SORT
diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
index 7f3658a973846..e02aa793420b8 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -244,7 +244,7 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
*/
static inline void activate_mm(struct mm_struct *prev, struct mm_struct *next)
{
- switch_mm(prev, next, current);
+ switch_mm_irqs_off(prev, next, current);
}
/* We don't currently use enter_lazy_tlb() for anything */
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.9 020/147] powerpc/64s: handle ISA v3.1 local copy-paste context switches
From: Sasha Levin @ 2020-10-26 23:46 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, kvm-ppc, Nicholas Piggin, linuxppc-dev
In-Reply-To: <20201026234905.1022767-1-sashal@kernel.org>
From: Nicholas Piggin <npiggin@gmail.com>
[ Upstream commit dc462267d2d7aacffc3c1d99b02d7a7c59db7c66 ]
The ISA v3.1 the copy-paste facility has a new memory move functionality
which allows the copy buffer to be pasted to domestic memory (RAM) as
opposed to foreign memory (accelerator).
This means the POWER9 trick of avoiding the cp_abort on context switch if
the process had not mapped foreign memory does not work on POWER10. Do the
cp_abort unconditionally there.
KVM must also cp_abort on guest exit to prevent copy buffer state leaking
between contexts.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200825075535.224536-1-npiggin@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/process.c | 16 +++++++++-------
arch/powerpc/kvm/book3s_hv.c | 7 +++++++
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 8 ++++++++
3 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 73a57043ee662..3f2dc0675ea7a 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1256,15 +1256,17 @@ struct task_struct *__switch_to(struct task_struct *prev,
restore_math(current->thread.regs);
/*
- * The copy-paste buffer can only store into foreign real
- * addresses, so unprivileged processes can not see the
- * data or use it in any way unless they have foreign real
- * mappings. If the new process has the foreign real address
- * mappings, we must issue a cp_abort to clear any state and
- * prevent snooping, corruption or a covert channel.
+ * On POWER9 the copy-paste buffer can only paste into
+ * foreign real addresses, so unprivileged processes can not
+ * see the data or use it in any way unless they have
+ * foreign real mappings. If the new process has the foreign
+ * real address mappings, we must issue a cp_abort to clear
+ * any state and prevent snooping, corruption or a covert
+ * channel. ISA v3.1 supports paste into local memory.
*/
if (current->mm &&
- atomic_read(¤t->mm->context.vas_windows))
+ (cpu_has_feature(CPU_FTR_ARCH_31) ||
+ atomic_read(¤t->mm->context.vas_windows)))
asm volatile(PPC_CP_ABORT);
}
#endif /* CONFIG_PPC_BOOK3S_64 */
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 4ba06a2a306cf..3bd3118c76330 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -3530,6 +3530,13 @@ static int kvmhv_load_hv_regs_and_go(struct kvm_vcpu *vcpu, u64 time_limit,
*/
asm volatile("eieio; tlbsync; ptesync");
+ /*
+ * cp_abort is required if the processor supports local copy-paste
+ * to clear the copy buffer that was under control of the guest.
+ */
+ if (cpu_has_feature(CPU_FTR_ARCH_31))
+ asm volatile(PPC_CP_ABORT);
+
mtspr(SPRN_LPID, vcpu->kvm->arch.host_lpid); /* restore host LPID */
isync();
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 799d6d0f4eade..cd9995ee84419 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -1830,6 +1830,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_P9_RADIX_PREFETCH_BUG)
2:
#endif /* CONFIG_PPC_RADIX_MMU */
+ /*
+ * cp_abort is required if the processor supports local copy-paste
+ * to clear the copy buffer that was under control of the guest.
+ */
+BEGIN_FTR_SECTION
+ PPC_CP_ABORT
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_31)
+
/*
* POWER7/POWER8 guest -> host partition switch code.
* We don't have to lock against tlbies but we do
--
2.25.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.9 058/147] selftests/powerpc: Make using_hash_mmu() work on Cell & PowerMac
From: Sasha Levin @ 2020-10-26 23:47 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev, linux-kselftest
In-Reply-To: <20201026234905.1022767-1-sashal@kernel.org>
From: Michael Ellerman <mpe@ellerman.id.au>
[ Upstream commit 34c103342be3f9397e656da7c5cc86e97b91f514 ]
These platforms don't show the MMU in /proc/cpuinfo, but they always
use hash, so teach using_hash_mmu() that.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200819015727.1977134-1-mpe@ellerman.id.au
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/powerpc/utils.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/utils.c b/tools/testing/selftests/powerpc/utils.c
index 18b6a773d5c73..638ffacc90aa1 100644
--- a/tools/testing/selftests/powerpc/utils.c
+++ b/tools/testing/selftests/powerpc/utils.c
@@ -318,7 +318,9 @@ int using_hash_mmu(bool *using_hash)
rc = 0;
while (fgets(line, sizeof(line), f) != NULL) {
- if (strcmp(line, "MMU : Hash\n") == 0) {
+ if (!strcmp(line, "MMU : Hash\n") ||
+ !strcmp(line, "platform : Cell\n") ||
+ !strcmp(line, "platform : PowerMac\n")) {
*using_hash = true;
goto out;
}
--
2.25.1
^ permalink raw reply related
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