Re: [RFC v4 PATCH 2/5] powerpc/crash hp: introduce a new config option CRASH_HOTPLUG
On 21/04/22 20:59, Eric DeVolder wrote: On 4/21/22 06:34, Michael Ellerman wrote: Sourabh Jain writes: The option CRASH_HOTPLUG enables, in kernel update to kexec segments on hotplug events. All the updates needed on the capture kernel load path in the kernel for both kexec_load and kexec_file_load system will be kept under this config. Signed-off-by: Sourabh Jain Reviewed-by: Eric DeVolder --- arch/powerpc/Kconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index b779603978e1..777db33f75b5 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -623,6 +623,17 @@ config FA_DUMP If unsure, say "y". Only special kernels like petitboot may need to say "N" here. +config CRASH_HOTPLUG + bool "kernel updates of crash kexec segments" + depends on CRASH_DUMP && (HOTPLUG_CPU) && KEXEC_FILE + help + An efficient way to keep the capture kernel up-to-date with CPU + hotplug events. On CPU hotplug event the kexec segments of capture + kernel becomes stale and need to be updated with latest CPU data. + In this method the kernel performs minimal update to only relevant + kexec segments on CPU hotplug event, instead of triggering full + capture kernel reload from userspace using udev rule. Why would a user ever want to turn this off? Seems to me we should just make it always behave this way, and not have a CONFIG option at all. Sourabh, Borislav Petkov also requested I remove the config option, which will be the case in upcoming v8. Where I was using CONFIG_CRASH_HOTPLUG, I've replaced it with the CONFIG_HOTPLUG_CPU || CONFIG_MEMORY_HOTPLUG. Yes good idea. Even Michael suggested there is no need for new CONFIG option. I will also remove CRASH_HOTPLUG config in the next version. Thanks, Sourabh Jain
Re: [RFC v4 PATCH 2/5] powerpc/crash hp: introduce a new config option CRASH_HOTPLUG
On 21/04/22 17:04, Michael Ellerman wrote: Sourabh Jain writes: The option CRASH_HOTPLUG enables, in kernel update to kexec segments on hotplug events. All the updates needed on the capture kernel load path in the kernel for both kexec_load and kexec_file_load system will be kept under this config. Signed-off-by: Sourabh Jain Reviewed-by: Eric DeVolder --- arch/powerpc/Kconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index b779603978e1..777db33f75b5 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -623,6 +623,17 @@ config FA_DUMP If unsure, say "y". Only special kernels like petitboot may need to say "N" here. +config CRASH_HOTPLUG + bool "kernel updates of crash kexec segments" + depends on CRASH_DUMP && (HOTPLUG_CPU) && KEXEC_FILE + help + An efficient way to keep the capture kernel up-to-date with CPU + hotplug events. On CPU hotplug event the kexec segments of capture + kernel becomes stale and need to be updated with latest CPU data. + In this method the kernel performs minimal update to only relevant + kexec segments on CPU hotplug event, instead of triggering full + capture kernel reload from userspace using udev rule. Why would a user ever want to turn this off? Seems to me we should just make it always behave this way, and not have a CONFIG option at all. Yes, we don't need a new CONFIG option. Thanks for the suggestion. Thanks, Sourabh Jain
Re: [PATCH v5] PCI hotplug: rpaphp: Error out on busy status from get-sensor-state
Nathan Lynch writes: > Mahesh Salgaonkar writes: >> When certain PHB HW failure causes phyp to recover PHB, it marks the PE >> state as temporarily unavailable until recovery is complete. This also >> triggers an EEH handler in Linux which needs to notify drivers, and perform >> recovery. But before notifying the driver about the pci error it uses PCI >> get_adapter_state()->get-sesnor-state() operation of the hotplug_slot to ^ typo >> determine if the slot contains a device or not. if the slot is empty, the >> recovery is skipped entirely. >> >> However on certain PHB failures, the rtas call get-sesnor-state() returns ^ typo >> extended busy error (9902) until PHB is recovered by phyp. Once PHB is >> recovered, the get-sensor-state() returns success with correct presence >> status. The rtas call interface rtas_get_sensor() loops over the rtas call RTAS >> on extended delay return code (9902) until the return value is either >> success (0) or error (-1). This causes the EEH handler to get stuck for ~6 >> seconds before it could notify that the pci error has been detected and >> stop any active operations. Hence with running I/O traffic, during this 6 >> seconds, the network driver continues its operation and hits a timeout >> (netdev watchdog). On timeouts, network driver go into ffdc capture mode >> and reset path assuming the PCI device is in fatal condition. This >> sometimes causes EEH recovery to fail. This impacts the ssh connection and >> leads to the system being inaccessible. >> >> >> [52732.244731] DEBUG: ibm_read_slot_reset_state2() >> [52732.244762] DEBUG: ret = 0, rets[0]=5, rets[1]=1, rets[2]=4000, rets[3]=> >> [52732.244798] DEBUG: in eeh_slot_presence_check >> [52732.244804] DEBUG: error state check >> [52732.244807] DEBUG: Is slot hotpluggable >> [52732.244810] DEBUG: hotpluggable ops ? >> [52732.244953] DEBUG: Calling ops->get_adapter_status >> [52732.244958] DEBUG: calling rpaphp_get_sensor_state >> [52736.564262] [ cut here ] >> [52736.564299] NETDEV WATCHDOG: enP64p1s0f3 (tg3): transmit queue 0 timed o> >> [52736.564324] WARNING: CPU: 1442 PID: 0 at net/sched/sch_generic.c:478 dev> >> [...] >> [52736.564505] NIP [c0c32368] dev_watchdog+0x438/0x440 >> [52736.564513] LR [c0c32364] dev_watchdog+0x434/0x440 >> >> >> To avoid this issue, fix the pci hotplug driver (rpaphp) to return an error >> if the slot presence state can not be detected immediately while pe is in PE >> EEH recovery state. Current implementation uses rtas_get_sensor() API which >> blocks the slot check state until rtas call returns success. Change >> rpaphp_get_sensor_state() to invoke rtas_call(get-sensor-state) directly >> only if the respective pe is in EEH recovery state, and take actions based >> on rtas return status. >> >> In normal cases (non-EEH case) rpaphp_get_sensor_state() will continue to >> invoke rtas_get_sensor() as it was earlier with no change in existing >> behavior. >> >> Signed-off-by: Mahesh Salgaonkar >> >> --- >> Change in v5: >> - Fixup #define macros with parentheses around the values. >> >> Change in V4: >> - Error out on sensor busy only if pe is going through EEH recovery instead >> of always error out. >> >> Change in V3: >> - Invoke rtas_call(get-sensor-state) directly from >> rpaphp_get_sensor_state() directly and do special handling. >> - See v2 at >> https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/237336.html >> >> Change in V2: >> - Alternate approach to fix the EEH issue instead of delaying slot presence >> check proposed at >> https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/236956.html >> >> Also refer: >> https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/237027.html > > Sorry for the long delay. I think it looks OK now. Does this need to go > to the PCI list/maintainer? Yes it needs to be Cc'ed to the PCI list/maintainer, even if we end up merging it via the powerpc tree. cheers
Re: [PATCH v5] PCI hotplug: rpaphp: Error out on busy status from get-sensor-state
Mahesh Salgaonkar writes: > When certain PHB HW failure causes phyp to recover PHB, it marks the PE > state as temporarily unavailable until recovery is complete. This also > triggers an EEH handler in Linux which needs to notify drivers, and perform > recovery. But before notifying the driver about the pci error it uses > get_adapter_state()->get-sesnor-state() operation of the hotplug_slot to > determine if the slot contains a device or not. if the slot is empty, the > recovery is skipped entirely. > > However on certain PHB failures, the rtas call get-sesnor-state() returns > extended busy error (9902) until PHB is recovered by phyp. Once PHB is > recovered, the get-sensor-state() returns success with correct presence > status. The rtas call interface rtas_get_sensor() loops over the rtas call > on extended delay return code (9902) until the return value is either > success (0) or error (-1). This causes the EEH handler to get stuck for ~6 > seconds before it could notify that the pci error has been detected and > stop any active operations. Hence with running I/O traffic, during this 6 > seconds, the network driver continues its operation and hits a timeout > (netdev watchdog). On timeouts, network driver go into ffdc capture mode > and reset path assuming the PCI device is in fatal condition. This > sometimes causes EEH recovery to fail. This impacts the ssh connection and > leads to the system being inaccessible. > > > [52732.244731] DEBUG: ibm_read_slot_reset_state2() > [52732.244762] DEBUG: ret = 0, rets[0]=5, rets[1]=1, rets[2]=4000, rets[3]=> > [52732.244798] DEBUG: in eeh_slot_presence_check > [52732.244804] DEBUG: error state check > [52732.244807] DEBUG: Is slot hotpluggable > [52732.244810] DEBUG: hotpluggable ops ? > [52732.244953] DEBUG: Calling ops->get_adapter_status > [52732.244958] DEBUG: calling rpaphp_get_sensor_state > [52736.564262] [ cut here ] > [52736.564299] NETDEV WATCHDOG: enP64p1s0f3 (tg3): transmit queue 0 timed o> > [52736.564324] WARNING: CPU: 1442 PID: 0 at net/sched/sch_generic.c:478 dev> > [...] > [52736.564505] NIP [c0c32368] dev_watchdog+0x438/0x440 > [52736.564513] LR [c0c32364] dev_watchdog+0x434/0x440 > > > To avoid this issue, fix the pci hotplug driver (rpaphp) to return an error > if the slot presence state can not be detected immediately while pe is in > EEH recovery state. Current implementation uses rtas_get_sensor() API which > blocks the slot check state until rtas call returns success. Change > rpaphp_get_sensor_state() to invoke rtas_call(get-sensor-state) directly > only if the respective pe is in EEH recovery state, and take actions based > on rtas return status. > > In normal cases (non-EEH case) rpaphp_get_sensor_state() will continue to > invoke rtas_get_sensor() as it was earlier with no change in existing > behavior. > > Signed-off-by: Mahesh Salgaonkar > > --- > Change in v5: > - Fixup #define macros with parentheses around the values. > > Change in V4: > - Error out on sensor busy only if pe is going through EEH recovery instead > of always error out. > > Change in V3: > - Invoke rtas_call(get-sensor-state) directly from > rpaphp_get_sensor_state() directly and do special handling. > - See v2 at > https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/237336.html > > Change in V2: > - Alternate approach to fix the EEH issue instead of delaying slot presence > check proposed at > https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/236956.html > > Also refer: > https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/237027.html Sorry for the long delay. I think it looks OK now. Does this need to go to the PCI list/maintainer? Reviewed-by: Nathan Lynch
Re: [PATCH v4 2/2] PCI/PM: Fix pci_pm_suspend_noirq() to disable PTM
On Sat, 2022-04-23 at 10:01 -0500, Bjorn Helgaas wrote:
> On Sat, Apr 23, 2022 at 12:43:14AM +, Jingar, Rajvi wrote:
> > > -Original Message-
> > > From: Bjorn Helgaas
> > > On Thu, Apr 14, 2022 at 07:54:02PM +0200, Rafael J. Wysocki wrote:
> > > > On 3/25/2022 8:50 PM, Rajvi Jingar wrote:
> > > > > For the PCIe devices (like nvme) that do not go into D3 state still
> > > > > need to
> > > > > disable PTM on PCIe root ports to allow the port to enter a lower-
> > > > > power PM
> > > > > state and the SoC to reach a lower-power idle state as a whole. Move
> > > > > the
> > > > > pci_disable_ptm() out of pci_prepare_to_sleep() as this code path is
> > > > > not
> > > > > followed for devices that do not go into D3. This patch fixes the
> > > > > issue
> > > > > seen on Dell XPS 9300 with Ice Lake CPU and Dell Precision 5530 with
> > > > > Coffee
> > > > > Lake CPU platforms to get improved residency in low power idle states.
> > > > >
> > > > > Fixes: a697f072f5da ("PCI: Disable PTM during suspend to save power")
> > > > > Signed-off-by: Rajvi Jingar
> > > > > Suggested-by: David E. Box
> > > > > ---
> > > > > drivers/pci/pci-driver.c | 10 ++
> > > > > drivers/pci/pci.c| 10 --
> > > > > 2 files changed, 10 insertions(+), 10 deletions(-)
> > > > >
> > > > > diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> > > > > index 8b55a90126a2..ab733374a260 100644
> > > > > --- a/drivers/pci/pci-driver.c
> > > > > +++ b/drivers/pci/pci-driver.c
> > > > > @@ -847,6 +847,16 @@ static int pci_pm_suspend_noirq(struct device
> > > > > *dev)
> > > > > if (!pci_dev->state_saved) {
> > > > > pci_save_state(pci_dev);
> > > > > + /*
> > > > > + * There are systems (for example, Intel mobile chips
> > > > > since
> > > Coffee
> > > > > + * Lake) where the power drawn while suspended can be
> > > significantly
> > > > > + * reduced by disabling PTM on PCIe root ports as this
> > > > > allows the
> > > > > + * port to enter a lower-power PM state and the SoC to
> > > > > reach a
> > > > > + * lower-power idle state as a whole.
> > > > > + */
> > > > > + if (pci_pcie_type(pci_dev) == PCI_EXP_TYPE_ROOT_PORT)
> > > > > + pci_disable_ptm(pci_dev);
> > >
> > > Why is disabling PTM dependent on pci_dev->state_saved? The point of
> > > this is to change the behavior of the device, and it seems like we
> > > want to do that regardless of whether the driver has used
> > > pci_save_state().
> >
> > Because we use the saved state to restore PTM on the root port.
> > And it's under this condition that the root port state gets saved.
>
> Yes, I understand that pci_restore_ptm_state() depends on a previous
> call to pci_save_ptm_state().
>
> The point I'm trying to make is that pci_disable_ptm() changes the
> state of the device, and that state change should not depend on
> whether the driver has used pci_save_state().
We do it here because D3 depends on whether the device state was saved by the
driver.
if (!pci_dev->state_saved) {
pci_save_state(pci_dev);
/* disable PTM here */
if (pci_power_manageable(pci_dev))
pci_prepare_to_sleep(pci_dev);
}
If we disable PTM before the check, we will have saved "PTM disabled" as the
restore state. And we can't do it after the check as the device will be in D3.
As to disabling PTM on all devices, I see no problem with this, but the
reasoning is different. We disabled the root port PTM for power savings.
David
>
> When we're putting a device into a low-power state, I think we want to
> disable PTM *always*, no matter what the driver did. And I think we
> want to do it for all devices, not just Root Ports.
>
> Bjorn
Re: [PATCH v2 1/2] dt-bindings: interrupt-controller: fsl, ls-extirq: convert to YAML
Am 2022-04-25 20:36, schrieb Krzysztof Kozlowski: On 25/04/2022 16:02, Michael Walle wrote: Convert the fsl,ls-extirq binding to the new YAML format. (...) diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml new file mode 100644 index ..39d120ad7549 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/fsl,ls-extirq.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Layerscape External Interrupt Controller + +maintainers: + - Shawn Guo + - Li Yang + +description: | + Some Layerscape SOCs (LS1021A, LS1043A, LS1046A LS1088A, LS208xA, + LX216xA) support inverting the polarity of certain external interrupt + lines. + +allOf: + - $ref: /schemas/interrupt-controller.yaml# I have doubts whether this is here applicable. See also Rob's comment: https://lore.kernel.org/all/yjjjpxlwj%2fyoe...@robh.at.kernel.org/ This device does not have children, so the interrupt-controller schema should be probably skipped. ok. + +properties: + compatible: +oneOf: + - enum: + - fsl,ls1021a-extirq + - fsl,ls1043a-extirq + - fsl,ls1088a-extirq + - items: + - enum: + - fsl,ls1046a-extirq + - const: fsl,ls1043a-extirq + - items: + - enum: + - fsl,ls2080a-extirq + - fsl,lx2160a-extirq + - const: fsl,ls1088a-extirq + + '#interrupt-cells': +const: 2 + + '#address-cells': +const: 0 + + interrupt-controller: true + + reg: +maxItems: 1 +description: + Specifies the Interrupt Polarity Control Register (INTPCR) in the + SCFG or the External Interrupt Control Register (IRQCR) in the ISC. + + interrupt-map: btw. minItems: 12 maxItems: 12 Isn't working here, is that expected? The validator seem to get the count of the elements of one tuple wrong. I.e. arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dtb: interrupt-controller@14: interrupt-map: [[0, 0, 1, 0, 0, 4, 1, 0], [1, 0, 1, 4, 2, 0, 1, 0], [2, 4, 3, 0, 1, 0, 3, 4], [4, 0, 1, 0, 4, 4, 5, 0], [1, 0, 5, 4, 6, 0, 1, 0], [6, 4, 7, 0, 1, 0, 7, 4], [8, 0, 1, 0, 8, 4, 9, 0], [1, 0, 9, 4, 10, 0, 1, 0], [10, 4, 11, 0, 1, 0, 11, 4]] is too short +description: Specifies the mapping from external interrupts to GIC interrupts. + + interrupt-map-mask: +items: + - const: 0x This looks highly permissive mask and should be instead defined per variant, for example (quickly looking at DTS): 0x7 for ls1021 0xf for ls1043a and ls1088a Just that I understand it correctly, the result of the AND with that mask is then looked up in the interrupt-map (the first entry there)? You might need to correct the DTS. Some confirmation from someone with datasheet would be good. According to their datasheets they have the following number of external IRQs: - ls1021a has 6, - ls1043a has 12, - ls1046a has 12, - ls1088a has 12, - ls2080a has 12, - lx2160a has 12. That is what I need to confirm, right? Is there a better way than the following snippet: properties: interrupt-map-mask: true allOf: - if: properties: compatible: contains: enum: - fsl,ls1021a-extirq then: properties: interrupt-map-mask: items: - const: 0x7 - const: 0 - if: properties: compatible: contains: enum: - fsl,ls1043a-extirq - fsl,ls1046a-extirq - fsl,ls1088a-extirq - fsl,ls2080a-extirq - fsl,lx2160a-extirq then: properties: interrupt-map-mask: items: - const: 0xf - const: 0 -michael
Re: [PATCH 0/7] Remove unused SLOW_DOWN_IO
On Fri, Apr 22, 2022 at 10:48:28AM -0700, Jakub Kicinski wrote:
> On Fri, 15 Apr 2022 14:08:10 -0500 Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
> >
> > Only alpha, ia64, powerpc, and sh define SLOW_DOWN_IO, and there are no
> > actual uses of it. The few references to it are in situations that are
> > themselves unused. Remove them all.
> >
> > It should be safe to apply these independently and in any order. The only
> > place SLOW_DOWN_IO is used at all is the lmc_var.h definition of DELAY,
> > which is itself never used.
>
> Hi Bojrn! Would you mind reposting just patches 1 and 3 for networking?
> LMC got removed in net-next (commit a5b116a0fa90 ("net: wan: remove the
> lanmedia (lmc) driver")) so the entire series fails to apply and therefore
> defeats all of our patch handling scripts :S
Sure, coming up, with reduced cc: list.
Re: [PATCH] powerpc/pci: Remove useless null check before call of_node_put()
On 4/23/22 07:32, Michael Ellerman wrote:
> Tyrel Datwyler writes:
>> On 4/20/22 19:52, Haowen Bai wrote:
>>> No need to add null check before call of_node_put(), since the
>>> implementation of of_node_put() has done it.
>>>
>>> Signed-off-by: Haowen Bai
>>> ---
>>> arch/powerpc/kernel/pci_dn.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kernel/pci_dn.c b/arch/powerpc/kernel/pci_dn.c
>>> index 61571ae23953..ba3bbc9bec2d 100644
>>> --- a/arch/powerpc/kernel/pci_dn.c
>>> +++ b/arch/powerpc/kernel/pci_dn.c
>>> @@ -357,8 +357,8 @@ void pci_remove_device_node_info(struct device_node *dn)
>>>
>>> /* Drop the parent pci_dn's ref to our backing dt node */
>>> parent = of_get_parent(dn);
>>> - if (parent)
>>> - of_node_put(parent);
>>> +
>>> + of_node_put(parent);
>>
>> This whole block of code looks useless, or suspect. Examining the rest of the
>> code for this function this is the only place that parent is referenced. The
>> of_get_parent() call returns the parent with its refcount incremented, and
>> then
>> we turn around and call of_node_put() which drops that reference we just
>> took.
>> The comment doesn't do what it says it does. If we really need to drop a
>> previous reference to the parent device node this code block would need to
>> call
>> of_node_put() twice on parent to accomplish that.
>
> Yeah good analysis.
>
> It used to use pdn->parent, which didn't grab an extra reference, see
> commit 14db3d52d3a2 ("powerpc/eeh: Reduce use of pci_dn::node").
>
> The old code was:
>
> if (pdn->parent)
> of_node_put(pdn->parent->node);
>
>> A closer examination is required to determine if what the comment says we
>> need
>> to do is required. If it is then the code as it exists today is leaking that
>> reference AFAICS.
>
> Yeah. This function is only called from pnv_php.c, ie. powernv PCI
> hotplug, which I think gets less testing than pseries hotplug. So
> possibly we are leaking references and haven't noticed, or maybe the
> comment is out of date.
Looks like we leak it. From pci_add_device_node_info() we clearly take a
reference we don't free:
/* Attach to parent node */
INIT_LIST_HEAD(>child_list);
INIT_LIST_HEAD(>list);
parent = of_get_parent(dn);
pdn->parent = parent ? PCI_DN(parent) : NULL;
if (pdn->parent)
list_add_tail(>list, >parent->child_list);
return pdn;
The question becomes whats the right fix. Doing a double put in the remove path
seems wrong, and looks gross. We no longer store a reference to the parent
device node in pci_dn::parent but instead a reference to the an actual pci_dn
struct. Seems to suggest we can drop the reference taken in
pci_add_device_node_info().
-Tyrel
>
> cheers
Re: [PATCH 1/3] perf symbol: Pass is_kallsyms to symbols__fixup_end()
Hi Ian, On Sat, Apr 16, 2022 at 7:59 AM Ian Rogers wrote: > > On Fri, Apr 15, 2022 at 8:40 PM Namhyung Kim wrote: > > > > The symbol fixup is necessary for symbols in kallsyms since they don't > > have size info. So we use the next symbol's address to calculate the > > size. Now it's also used for user binaries because sometimes they > > miss size for hand-written asm functions. > > > > There's a arch-specific function to handle kallsyms differently but > > currently it cannot distinguish kallsyms from others. Pass this > > information explicitly to handle it properly. Note that those arch > > functions will be moved to the generic function so I didn't added it > > to the arch-functions. > > Thanks Namhyung, in: > https://lore.kernel.org/linux-perf-users/20220412154817.2728324-3-irog...@google.com/ > I used "dso->kernel != DSO_SPACE__USER" in symbol-elf to make this > more than just kallsyms as presumably kernel code is the issue. Do we > know elf kernel code has correctly sized symbols? Yeah, IIUC the whole point of the symbol end fixup is because the kallsyms doesn't have the symbol size info. Every ELF binaries should have the size except for some hand-written asm functions which missed adding it manually. I guess that's the reason it was added to other DSO loading paths. Also considering "[" (and "]") in the symbol name is specific to kallsyms which has both kernel and module symbols together. Thanks, Namhyung
Re: [PATCH v4 2/2] PCI/PM: Fix pci_pm_suspend_noirq() to disable PTM
On Mon, Apr 25, 2022 at 8:33 PM David E. Box
wrote:
>
> On Sat, 2022-04-23 at 10:01 -0500, Bjorn Helgaas wrote:
> > On Sat, Apr 23, 2022 at 12:43:14AM +, Jingar, Rajvi wrote:
> > > > -Original Message-
> > > > From: Bjorn Helgaas
> > > > On Thu, Apr 14, 2022 at 07:54:02PM +0200, Rafael J. Wysocki wrote:
> > > > > On 3/25/2022 8:50 PM, Rajvi Jingar wrote:
> > > > > > For the PCIe devices (like nvme) that do not go into D3 state still
> > > > > > need to
> > > > > > disable PTM on PCIe root ports to allow the port to enter a lower-
> > > > > > power PM
> > > > > > state and the SoC to reach a lower-power idle state as a whole. Move
> > > > > > the
> > > > > > pci_disable_ptm() out of pci_prepare_to_sleep() as this code path is
> > > > > > not
> > > > > > followed for devices that do not go into D3. This patch fixes the
> > > > > > issue
> > > > > > seen on Dell XPS 9300 with Ice Lake CPU and Dell Precision 5530 with
> > > > > > Coffee
> > > > > > Lake CPU platforms to get improved residency in low power idle
> > > > > > states.
> > > > > >
> > > > > > Fixes: a697f072f5da ("PCI: Disable PTM during suspend to save
> > > > > > power")
> > > > > > Signed-off-by: Rajvi Jingar
> > > > > > Suggested-by: David E. Box
> > > > > > ---
> > > > > > drivers/pci/pci-driver.c | 10 ++
> > > > > > drivers/pci/pci.c| 10 --
> > > > > > 2 files changed, 10 insertions(+), 10 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> > > > > > index 8b55a90126a2..ab733374a260 100644
> > > > > > --- a/drivers/pci/pci-driver.c
> > > > > > +++ b/drivers/pci/pci-driver.c
> > > > > > @@ -847,6 +847,16 @@ static int pci_pm_suspend_noirq(struct device
> > > > > > *dev)
> > > > > > if (!pci_dev->state_saved) {
> > > > > > pci_save_state(pci_dev);
> > > > > > + /*
> > > > > > + * There are systems (for example, Intel mobile chips
> > > > > > since
> > > > Coffee
> > > > > > + * Lake) where the power drawn while suspended can be
> > > > significantly
> > > > > > + * reduced by disabling PTM on PCIe root ports as this
> > > > > > allows the
> > > > > > + * port to enter a lower-power PM state and the SoC to
> > > > > > reach a
> > > > > > + * lower-power idle state as a whole.
> > > > > > + */
> > > > > > + if (pci_pcie_type(pci_dev) == PCI_EXP_TYPE_ROOT_PORT)
> > > > > > + pci_disable_ptm(pci_dev);
> > > >
> > > > Why is disabling PTM dependent on pci_dev->state_saved? The point of
> > > > this is to change the behavior of the device, and it seems like we
> > > > want to do that regardless of whether the driver has used
> > > > pci_save_state().
> > >
> > > Because we use the saved state to restore PTM on the root port.
> > > And it's under this condition that the root port state gets saved.
> >
> > Yes, I understand that pci_restore_ptm_state() depends on a previous
> > call to pci_save_ptm_state().
> >
> > The point I'm trying to make is that pci_disable_ptm() changes the
> > state of the device, and that state change should not depend on
> > whether the driver has used pci_save_state().
>
> We do it here because D3 depends on whether the device state was saved by the
> driver.
>
> if (!pci_dev->state_saved) {
> pci_save_state(pci_dev);
>
> /* disable PTM here */
>
> if (pci_power_manageable(pci_dev))
> pci_prepare_to_sleep(pci_dev);
> }
>
>
> If we disable PTM before the check, we will have saved "PTM disabled" as the
> restore state. And we can't do it after the check as the device will be in D3.
>
> As to disabling PTM on all devices, I see no problem with this, but the
> reasoning is different. We disabled the root port PTM for power savings.
Right. As per the comment explaining why it is disabled.
> >
> > When we're putting a device into a low-power state, I think we want to
> > disable PTM *always*, no matter what the driver did. And I think we
> > want to do it for all devices, not just Root Ports.
> >
> > Bjorn
>
Re: [PATCH v2 1/2] dt-bindings: interrupt-controller: fsl, ls-extirq: convert to YAML
On 25/04/2022 16:02, Michael Walle wrote: > Convert the fsl,ls-extirq binding to the new YAML format. > (...) > diff --git > a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml > b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml > new file mode 100644 > index ..39d120ad7549 > --- /dev/null > +++ > b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml > @@ -0,0 +1,88 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/interrupt-controller/fsl,ls-extirq.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Freescale Layerscape External Interrupt Controller > + > +maintainers: > + - Shawn Guo > + - Li Yang > + > +description: | > + Some Layerscape SOCs (LS1021A, LS1043A, LS1046A LS1088A, LS208xA, > + LX216xA) support inverting the polarity of certain external interrupt > + lines. > + > +allOf: > + - $ref: /schemas/interrupt-controller.yaml# I have doubts whether this is here applicable. See also Rob's comment: https://lore.kernel.org/all/yjjjpxlwj%2fyoe...@robh.at.kernel.org/ This device does not have children, so the interrupt-controller schema should be probably skipped. > + > +properties: > + compatible: > +oneOf: > + - enum: > + - fsl,ls1021a-extirq > + - fsl,ls1043a-extirq > + - fsl,ls1088a-extirq > + - items: > + - enum: > + - fsl,ls1046a-extirq > + - const: fsl,ls1043a-extirq > + - items: > + - enum: > + - fsl,ls2080a-extirq > + - fsl,lx2160a-extirq > + - const: fsl,ls1088a-extirq > + > + '#interrupt-cells': > +const: 2 > + > + '#address-cells': > +const: 0 > + > + interrupt-controller: true > + > + reg: > +maxItems: 1 > +description: > + Specifies the Interrupt Polarity Control Register (INTPCR) in the > + SCFG or the External Interrupt Control Register (IRQCR) in the ISC. > + > + interrupt-map: > +description: Specifies the mapping from external interrupts to GIC > interrupts. > + > + interrupt-map-mask: > +items: > + - const: 0x This looks highly permissive mask and should be instead defined per variant, for example (quickly looking at DTS): 0x7 for ls1021 0xf for ls1043a and ls1088a You might need to correct the DTS. Some confirmation from someone with datasheet would be good. Best regards, Krzysztof
L2 SRAM on PowerPC e500 and Caching-inhibited bit
Hello! I started playing with PowerPC e500 architecture, it is something really new for me and I suspect that I found a bug in U-Boot code which configures L2 cache as initial SRAM (L2 with locked lines). U-Boot code for the first half of L2 cache sets Caching-inhibited (MAS2_I) in TLB and for second half of L2 cache it unsets this bit. And I think that this is a bug as it seems strange if one half of L2 should be mapped differently than second half. I wrote about it email to U-Boot mailing list: https://lore.kernel.org/u-boot/20220413092633.gmz4rqpiha4rwecb@pali/ I discussed about it on U-Boot IRC channel and developers suggested me to write on Linux PowerPC mailing list as there could be more skilled people. Michael, or anybody else, could you help me with this? Do you know if L2 SRAM entry in TLB for e500v2 / BookE architecture should have MAS2_I bit set or not?
Re: [PATCH v2 2/2] dt-bindings: fsl: convert fsl,layerscape-scfg to YAML
On 25/04/2022 16:02, Michael Walle wrote: > Convert the fsl,layerscape-scfg binding to the new YAML format. > > In the device trees, the device node always have a "syscon" > compatible, which wasn't mentioned in the previous binding. > > Also added, compared to the original binding, is the > interrupt-controller subnode as used in arch/arm/boot/dts/ls1021a.dtsi > as well as the litte-endian and big-endian properties. > > Signed-off-by: Michael Walle > --- > changes since v1: > - moved to soc/fsl/fsl,layerscape-scfg.yaml > - generic name for node in example > - mention added "syscon" compatible in commit message > - reference specific interrupt controller Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
[PATCH] kexec_file: Drop pr_err in weak implementations of arch_kexec_apply_relocations[_add]
kexec_load_purgatory() can fail for many reasons - there is no need to
print an error when encountering unsupported relocations.
This solves a build issue on powerpc with binutils v2.36 and newer [1].
Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
symbols") [2], binutils started dropping section symbols that it thought
were unused. This isn't an issue in general, but with kexec_file.c, gcc
is placing kexec_arch_apply_relocations[_add] into a separate
.text.unlikely section and the section symbol ".text.unlikely" is being
dropped. Due to this, recordmcount is unable to find a non-weak symbol
in .text.unlikely to generate a relocation record against. Dropping
pr_err() calls results in these functions being left in .text section,
enabling recordmcount to emit a proper relocation record.
[1] https://github.com/linuxppc/issues/issues/388
[2] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d1bcae833b32f1
Signed-off-by: Naveen N. Rao
---
kernel/kexec_file.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 8347fc158d2b96..55d144c58b5278 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -121,7 +121,6 @@ int __weak
arch_kexec_apply_relocations_add(struct purgatory_info *pi, Elf_Shdr *section,
const Elf_Shdr *relsec, const Elf_Shdr *symtab)
{
- pr_err("RELA relocation unsupported.\n");
return -ENOEXEC;
}
@@ -138,7 +137,6 @@ int __weak
arch_kexec_apply_relocations(struct purgatory_info *pi, Elf_Shdr *section,
const Elf_Shdr *relsec, const Elf_Shdr *symtab)
{
- pr_err("REL relocation unsupported.\n");
return -ENOEXEC;
}
base-commit: 83d8a0d166119de813cad27ae7d61f54f9aea707
--
2.35.1
Re: [PATCH] ASoC: imx-hdmi: remove useless null check before call of_node_put()
On Thu, 21 Apr 2022 10:45:20 +0800, Haowen Bai wrote: > No need to add null check before call of_node_put(), since the > implementation of of_node_put() has done it. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: imx-hdmi: remove useless null check before call of_node_put() commit: 666b0cad75dc9517100295aed590aef2ff9a73d1 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
Re: [PATCH] ASoC: fsl_asrc: using pm_runtime_resume_and_get to simplify the code
On Wed, 20 Apr 2022 03:04:02 +, cgel@gmail.com wrote: > From: Minghao Chi > > Using pm_runtime_resume_and_get() to replace pm_runtime_get_sync and > pm_runtime_put_noidle. This change is just to simplify the code, no > actual functional changes. > > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: fsl_asrc: using pm_runtime_resume_and_get to simplify the code commit: d05040741afef6eb5d4366de7d5b62f700958787 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
Re: [PATCH] macintosh: macio_asic: fix resource_size.cocci warnings
Hello Michael,
On Fri, Apr 22, 2022 at 04:44:24PM +1000, Michael Ellerman wrote:
> Yihao Han writes:
> > - if (index == 0 && (res->end - res->start) > 0xfff)
> > + if (index == 0 && (resource_size(res)) > 0xfff)
> > res->end = res->start + 0xfff;
> > - if (index == 1 && (res->end - res->start) > 0xff)
> > + if (index == 1 && (resource_size(res)) > 0xff)
>
> Are you sure the conversion is correct? It's not exactly equivalent:
>
> static inline resource_size_t resource_size(const struct resource *res)
> {
> return res->end - res->start + 1;
> }
Indeed. I pointed out this issue in the v2 that already hit my inbox.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Re: [PATCH v2] macintosh: macio_asic: fix resource_size.cocci warnings
On Thu, Apr 21, 2022 at 07:18:07AM -0700, Yihao Han wrote:
> drivers/macintosh/macio_asic.c:219:26-29: WARNING:Suspicious code.
> resource_size is maybe missing with res
> drivers/macintosh/macio_asic.c:221:26-29: WARNING:Suspicious code.
> resource_size is maybe missing with res
>
> Use resource_size function on resource object instead of
> explicit computation.
>
> Generated by: scripts/coccinelle/api/resource_size.cocci
>
> Signed-off-by: Yihao Han
> ---
> v2: drop parenthesis around resource_size(res) and edit commit message
> ---
> drivers/macintosh/macio_asic.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
> index 1943a007e2d5..260fccb3863e 100644
> --- a/drivers/macintosh/macio_asic.c
> +++ b/drivers/macintosh/macio_asic.c
> @@ -216,9 +216,9 @@ static int macio_resource_quirks(struct device_node *np,
> struct resource *res,
> /* Some older IDE resources have bogus sizes */
> if (of_node_name_eq(np, "IDE") || of_node_name_eq(np, "ATA") ||
> of_node_is_type(np, "ide") || of_node_is_type(np, "ata")) {
> - if (index == 0 && (res->end - res->start) > 0xfff)
> + if (index == 0 && resource_size(res) > 0xfff)
Michael Ellerman noted in the v1 thread, that this is wrong as
resource_size evaluates to end - start + 1. So this has to be
if (index == 0 && resource_size(res) > 0x1000)
to be equivalent.
> res->end = res->start + 0xfff;
> - if (index == 1 && (res->end - res->start) > 0xff)
> + if (index == 1 && resource_size(res) > 0xff)
Similar here.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
[PATCH v4 09/13] serial: General support for multipoint addresses
Add generic support for serial multipoint addressing. Two new ioctls are added. TIOCSADDR is used to indicate the destination/receive address. TIOCGADDR returns the current address in use. The driver should implement set_addr and get_addr to support addressing mode. Adjust ADDRB clearing to happen only if driver does not provide set_addr (=the driver doesn't support address mode). This change is necessary for supporting devices with RS485 multipoint addressing [*]. A following patch in the patch series adds support for Synopsys Designware UART capable for 9th bit addressing mode. In this mode, 9th bit is used to indicate an address (byte) within the communication line. The 9th bit addressing mode is selected using ADDRB introduced by the previous patch. Transmit addresses / receiver filter are specified by setting the flags SER_ADDR_DEST and/or SER_ADDR_RECV. When the user supplies the transmit address, in the 9bit addressing mode it is sent out immediately with the 9th bit set to 1. After that, the subsequent normal data bytes are sent with 9th bit as 0 and they are intended to the device with the given address. It is up to receiver to enforce the filter using SER_ADDR_RECV. When userspace has supplied the receive address, the driver is expected to handle the matching of the address and only data with that address is forwarded to the user. Both SER_ADDR_DEST and SER_ADDR_RECV can be given at the same time in a single call if the addresses are the same. The user can clear the receive filter with SER_ADDR_RECV_CLEAR. [*] Technically, RS485 is just an electronic spec and does not itself specify the 9th bit addressing mode but 9th bit seems at least "semi-standard" way to do addressing with RS485. Cc: linux-...@vger.kernel.org Cc: Ivan Kokshaysky Cc: Matt Turner Cc: linux-al...@vger.kernel.org Cc: Thomas Bogendoerfer Cc: linux-m...@vger.kernel.org Cc: "James E.J. Bottomley" Cc: Helge Deller Cc: linux-par...@vger.kernel.org Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-dev@lists.ozlabs.org Cc: Yoshinori Sato Cc: Rich Felker Cc: linux...@vger.kernel.org Cc: "David S. Miller" Cc: sparcli...@vger.kernel.org Cc: Chris Zankel Cc: Max Filippov Cc: linux-xte...@linux-xtensa.org Cc: Arnd Bergmann Cc: linux-a...@vger.kernel.org Cc: linux-...@vger.kernel.org Signed-off-by: Ilpo Järvinen --- .../driver-api/serial/serial-rs485.rst| 23 ++- arch/alpha/include/uapi/asm/ioctls.h | 3 + arch/mips/include/uapi/asm/ioctls.h | 3 + arch/parisc/include/uapi/asm/ioctls.h | 3 + arch/powerpc/include/uapi/asm/ioctls.h| 3 + arch/sh/include/uapi/asm/ioctls.h | 3 + arch/sparc/include/uapi/asm/ioctls.h | 3 + arch/xtensa/include/uapi/asm/ioctls.h | 3 + drivers/tty/serial/8250/8250_core.c | 2 + drivers/tty/serial/serial_core.c | 62 ++- drivers/tty/tty_io.c | 2 + include/linux/serial_core.h | 6 ++ include/uapi/asm-generic/ioctls.h | 3 + include/uapi/linux/serial.h | 8 +++ 14 files changed, 125 insertions(+), 2 deletions(-) diff --git a/Documentation/driver-api/serial/serial-rs485.rst b/Documentation/driver-api/serial/serial-rs485.rst index 6bc824f948f9..2f45f007fa5b 100644 --- a/Documentation/driver-api/serial/serial-rs485.rst +++ b/Documentation/driver-api/serial/serial-rs485.rst @@ -95,7 +95,28 @@ RS485 Serial Communications /* Error handling. See errno. */ } -5. References +5. Multipoint Addressing + + + The Linux kernel provides serial_addr structure to handle addressing within + multipoint serial communications line such as RS485. 9th bit addressiong mode + is enabled by adding ADDRB flag in termios c_cflag. + + Serial core calls device specific set/get_addr in response to TIOCSADDR and + TIOCGADDR ioctls with a pointer to serial_addr. Destination and receive + address can be specified using serial_addr flags field. Receive address may + also be cleared using flags. Once an address is set, the communication + can occur only with the particular device and other peers are filtered out. + It is left up to the receiver side to enforce the filtering. + + Address flags: + - SER_ADDR_RECV: Receive (filter) address. + - SER_ADDR_RECV_CLEAR: Clear receive filter (only for TIOCSADDR). + - SER_ADDR_DEST: Destination address. + + Note: not all devices supporting RS485 support multipoint addressing. + +6. References = [1] include/uapi/linux/serial.h diff --git a/arch/alpha/include/uapi/asm/ioctls.h b/arch/alpha/include/uapi/asm/ioctls.h index 971311605288..500cab3e1d6b 100644 --- a/arch/alpha/include/uapi/asm/ioctls.h +++ b/arch/alpha/include/uapi/asm/ioctls.h @@ -125,4 +125,7 @@ #define TIOCMIWAIT 0x545C /* wait for a change on serial input line(s) */ #define
[PATCH v4 08/13] serial: termbits: ADDRB to indicate 9th bit addressing mode
Add ADDRB to termbits to indicate 9th bit addressing mode. This change
is necessary for supporting devices with RS485 multipoint addressing
[*]. A later patch in the patch series adds support for Synopsys
Designware UART capable for 9th bit addressing mode. In this mode, 9th
bit is used to indicate an address (byte) within the communication
line. The 9th bit addressing mode is selected using ADDRB introduced by
an earlier patch.
[*] Technically, RS485 is just an electronic spec and does not itself
specify the 9th bit addressing mode but 9th bit seems at least
"semi-standard" way to do addressing with RS485.
Cc: linux-...@vger.kernel.org
Cc: Ivan Kokshaysky
Cc: Matt Turner
Cc: linux-al...@vger.kernel.org
Cc: Thomas Bogendoerfer
Cc: linux-m...@vger.kernel.org
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: linux-par...@vger.kernel.org
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
Cc: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Cc: Arnd Bergmann
Cc: linux-a...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Ilpo Järvinen
---
arch/alpha/include/uapi/asm/termbits.h | 1 +
arch/mips/include/uapi/asm/termbits.h| 1 +
arch/parisc/include/uapi/asm/termbits.h | 1 +
arch/powerpc/include/uapi/asm/termbits.h | 1 +
arch/sparc/include/uapi/asm/termbits.h | 1 +
drivers/char/pcmcia/synclink_cs.c| 2 ++
drivers/ipack/devices/ipoctal.c | 2 ++
drivers/mmc/core/sdio_uart.c | 2 ++
drivers/net/usb/hso.c| 3 ++-
drivers/s390/char/tty3270.c | 3 +++
drivers/staging/greybus/uart.c | 2 ++
drivers/tty/amiserial.c | 6 +-
drivers/tty/moxa.c | 1 +
drivers/tty/mxser.c | 1 +
drivers/tty/serial/serial_core.c | 2 ++
drivers/tty/synclink_gt.c| 2 ++
drivers/tty/tty_ioctl.c | 2 ++
drivers/usb/class/cdc-acm.c | 2 ++
drivers/usb/serial/usb-serial.c | 6 --
include/uapi/asm-generic/termbits.h | 1 +
net/bluetooth/rfcomm/tty.c | 2 ++
21 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/arch/alpha/include/uapi/asm/termbits.h
b/arch/alpha/include/uapi/asm/termbits.h
index 4575ba34a0ea..0c123e715486 100644
--- a/arch/alpha/include/uapi/asm/termbits.h
+++ b/arch/alpha/include/uapi/asm/termbits.h
@@ -180,6 +180,7 @@ struct ktermios {
#define HUPCL 0004
#define CLOCAL 0010
+#define ADDRB 0040/* address bit */
#define CMSPAR 0100 /* mark or space (stick) parity */
#define CRTSCTS 0200 /* flow control */
diff --git a/arch/mips/include/uapi/asm/termbits.h
b/arch/mips/include/uapi/asm/termbits.h
index dfeffba729b7..4732d31b0e4e 100644
--- a/arch/mips/include/uapi/asm/termbits.h
+++ b/arch/mips/include/uapi/asm/termbits.h
@@ -182,6 +182,7 @@ struct ktermios {
#define B350 0010016
#define B400 0010017
#define CIBAUD 00200360 /* input baud rate */
+#define ADDRB0040 /* address bit */
#define CMSPAR 0100 /* mark or space (stick) parity */
#define CRTSCTS 0200 /* flow control */
diff --git a/arch/parisc/include/uapi/asm/termbits.h
b/arch/parisc/include/uapi/asm/termbits.h
index 40e920f8d683..d6bbd10d92ba 100644
--- a/arch/parisc/include/uapi/asm/termbits.h
+++ b/arch/parisc/include/uapi/asm/termbits.h
@@ -159,6 +159,7 @@ struct ktermios {
#define B350 0010016
#define B400 0010017
#define CIBAUD00200360 /* input baud rate */
+#define ADDRB0040 /* address bit */
#define CMSPAR0100 /* mark or space (stick) parity */
#define CRTSCTS 0200 /* flow control */
diff --git a/arch/powerpc/include/uapi/asm/termbits.h
b/arch/powerpc/include/uapi/asm/termbits.h
index ed18bc61f63d..c6a033732f39 100644
--- a/arch/powerpc/include/uapi/asm/termbits.h
+++ b/arch/powerpc/include/uapi/asm/termbits.h
@@ -171,6 +171,7 @@ struct ktermios {
#define HUPCL 0004
#define CLOCAL 0010
+#define ADDRB 0040/* address bit */
#define CMSPAR 0100 /* mark or space (stick) parity */
#define CRTSCTS 0200 /* flow control */
diff --git a/arch/sparc/include/uapi/asm/termbits.h
b/arch/sparc/include/uapi/asm/termbits.h
index ce5ad5d0f105..5eb1d547b5c4 100644
--- a/arch/sparc/include/uapi/asm/termbits.h
+++ b/arch/sparc/include/uapi/asm/termbits.h
@@ -201,6 +201,7 @@ struct ktermios {
#define B350 0x1012
#define B400 0x1013 */
#define CIBAUD 0x100f /* input baud rate (not used) */
+#define ADDRB0x2000 /* address bit */
#define CMSPAR 0x4000 /* mark or space (stick) parity */
#define CRTSCTS 0x8000 /* flow control */
diff --git a/drivers/char/pcmcia/synclink_cs.c
[PATCH] KVM: PPC: Book3S HV: Initialize AMOR in nested entry
The hypervisor always sets AMOR to ~0, but let's ensure we're not
passing stale values around.
Signed-off-by: Fabiano Rosas
---
arch/powerpc/kvm/book3s_hv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 6fa518f6501d..b5f504576765 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -3967,6 +3967,7 @@ static int kvmhv_vcpu_entry_p9_nested(struct kvm_vcpu
*vcpu, u64 time_limit, uns
kvmhv_save_hv_regs(vcpu, );
hvregs.lpcr = lpcr;
+ hvregs.amor = ~0;
vcpu->arch.regs.msr = vcpu->arch.shregs.msr;
hvregs.version = HV_GUEST_STATE_VERSION;
if (vcpu->arch.nested) {
--
2.35.1
[PATCH v2 2/2] dt-bindings: fsl: convert fsl,layerscape-scfg to YAML
Convert the fsl,layerscape-scfg binding to the new YAML format.
In the device trees, the device node always have a "syscon"
compatible, which wasn't mentioned in the previous binding.
Also added, compared to the original binding, is the
interrupt-controller subnode as used in arch/arm/boot/dts/ls1021a.dtsi
as well as the litte-endian and big-endian properties.
Signed-off-by: Michael Walle
---
changes since v1:
- moved to soc/fsl/fsl,layerscape-scfg.yaml
- generic name for node in example
- mention added "syscon" compatible in commit message
- reference specific interrupt controller
.../arm/freescale/fsl,layerscape-scfg.txt | 19 --
.../bindings/soc/fsl/fsl,layerscape-scfg.yaml | 58 +++
2 files changed, 58 insertions(+), 19 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt
create mode 100644
Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml
diff --git
a/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt
deleted file mode 100644
index 0ab67b0b216d..
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Freescale SCFG
-
-SCFG is the supplemental configuration unit, that provides SoC specific
-configuration and status registers for the chip. Such as getting PEX port
-status.
-
-Required properties:
- - compatible: Should contain a chip-specific compatible string,
- Chip-specific strings are of the form "fsl,-scfg",
- The following s are known to be supported:
- ls1012a, ls1021a, ls1043a, ls1046a, ls2080a.
-
- - reg: should contain base address and length of SCFG memory-mapped registers
-
-Example:
- scfg: scfg@157 {
- compatible = "fsl,ls1021a-scfg";
- reg = <0x0 0x157 0x0 0x1>;
- };
diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml
b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml
new file mode 100644
index ..8d088b5fe823
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-scfg.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/fsl/fsl,layerscape-scfg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Layerscape Supplemental Configuration Unit
+
+maintainers:
+ - Shawn Guo
+ - Li Yang
+
+description: |
+ SCFG is the supplemental configuration unit, that provides SoC specific
+ configuration and status registers for the chip. Such as getting PEX port
+ status.
+
+properties:
+ compatible:
+items:
+ - enum:
+ - fsl,ls1012a-scfg
+ - fsl,ls1021a-scfg
+ - fsl,ls1028a-scfg
+ - fsl,ls1043a-scfg
+ - fsl,ls1046a-scfg
+ - const: syscon
+
+ reg:
+maxItems: 1
+
+ little-endian: true
+ big-endian: true
+
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 1
+
+ ranges: true
+
+patternProperties:
+ "^interrupt-controller@[a-z0-9]+$":
+$ref: /schemas/interrupt-controller/fsl,ls-extirq.yaml#
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+syscon@157 {
+compatible = "fsl,ls1021a-scfg", "syscon";
+reg = <0x157 0x1>;
+};
--
2.30.2
[PATCH v2 1/2] dt-bindings: interrupt-controller: fsl, ls-extirq: convert to YAML
Convert the fsl,ls-extirq binding to the new YAML format.
In contrast to the original binding documentation, there are three
compatibles which are used in their corresponding device trees which
have a specific compatible and the (already documented) fallback
compatible:
- "fsl,ls1046a-extirq", "fsl,ls1043a-extirq"
- "fsl,ls2080a-extirq", "fsl,ls1088a-extirq"
- "fsl,lx2160a-extirq", "fsl,ls1088a-extirq"
Signed-off-by: Michael Walle
---
changes since v1:
- new patch, because it's reference in patch 2/2
.../interrupt-controller/fsl,ls-extirq.txt| 53 ---
.../interrupt-controller/fsl,ls-extirq.yaml | 88 +++
2 files changed, 88 insertions(+), 53 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
deleted file mode 100644
index 4d47df1a5c91..
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-* Freescale Layerscape external IRQs
-
-Some Layerscape SOCs (LS1021A, LS1043A, LS1046A
-LS1088A, LS208xA, LX216xA) support inverting
-the polarity of certain external interrupt lines.
-
-The device node must be a child of the node representing the
-Supplemental Configuration Unit (SCFG).
-
-Required properties:
-- compatible: should be "fsl,-extirq", e.g. "fsl,ls1021a-extirq".
- "fsl,ls1043a-extirq": for LS1043A, LS1046A.
- "fsl,ls1088a-extirq": for LS1088A, LS208xA, LX216xA.
-- #interrupt-cells: Must be 2. The first element is the index of the
- external interrupt line. The second element is the trigger type.
-- #address-cells: Must be 0.
-- interrupt-controller: Identifies the node as an interrupt controller
-- reg: Specifies the Interrupt Polarity Control Register (INTPCR) in
- the SCFG or the External Interrupt Control Register (IRQCR) in
- the ISC.
-- interrupt-map: Specifies the mapping from external interrupts to GIC
- interrupts.
-- interrupt-map-mask: Must be <0x 0>.
-
-Example:
- scfg: scfg@157 {
- compatible = "fsl,ls1021a-scfg", "syscon";
- reg = <0x0 0x157 0x0 0x1>;
- big-endian;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x0 0x157 0x1>;
-
- extirq: interrupt-controller@1ac {
- compatible = "fsl,ls1021a-extirq";
- #interrupt-cells = <2>;
- #address-cells = <0>;
- interrupt-controller;
- reg = <0x1ac 4>;
- interrupt-map =
- <0 0 GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
- <1 0 GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
- <2 0 GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
- <3 0 GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
- <4 0 GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
- <5 0 GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-map-mask = <0x 0x0>;
- };
- };
-
-
- interrupts-extended = < GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>,
- < 1 IRQ_TYPE_LEVEL_LOW>;
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml
b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml
new file mode 100644
index ..39d120ad7549
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-extirq.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/fsl,ls-extirq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Layerscape External Interrupt Controller
+
+maintainers:
+ - Shawn Guo
+ - Li Yang
+
+description: |
+ Some Layerscape SOCs (LS1021A, LS1043A, LS1046A LS1088A, LS208xA,
+ LX216xA) support inverting the polarity of certain external interrupt
+ lines.
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+properties:
+ compatible:
+oneOf:
+ - enum:
+ - fsl,ls1021a-extirq
+ - fsl,ls1043a-extirq
+ - fsl,ls1088a-extirq
+ - items:
+ - enum:
+ - fsl,ls1046a-extirq
+ - const: fsl,ls1043a-extirq
+ - items:
+ - enum:
+ - fsl,ls2080a-extirq
+ - fsl,lx2160a-extirq
+ - const: fsl,ls1088a-extirq
+
+ '#interrupt-cells':
+const: 2
+
+ '#address-cells':
+const: 0
+
+ interrupt-controller: true
+
+ reg:
+maxItems: 1
+description:
+ Specifies the Interrupt Polarity
