Re: [PATCH 2/3] PCI/AER: Decode Requester ID when no error info found
On Tue, Jan 02, 2024 at 11:22:53AM -0800, Kuppuswamy Sathyanarayanan wrote:
> On 12/6/2023 2:42 PM, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
> >
> > When a device with AER detects an error, it logs error information in its
> > own AER Error Status registers. It may send an Error Message to the Root
> > Port (RCEC in the case of an RCiEP), which logs the fact that an Error
> > Message was received (Root Error Status) and the Requester ID of the
> > message source (Error Source Identification).
> >
> > aer_print_port_info() prints the Requester ID from the Root Port Error
> > Source in the usual Linux "bb:dd.f" format, but when find_source_device()
> > finds no error details in the hierarchy below the Root Port, it printed the
> > raw Requester ID without decoding it.
> >
> > Decode the Requester ID in the usual Linux format so it matches other
> > messages.
> >
> > Sample message changes:
> >
> > - pcieport :00:1c.5: AER: Correctable error received: :00:1c.5
> > - pcieport :00:1c.5: AER: can't find device of ID00e5
> > + pcieport :00:1c.5: AER: Correctable error message received from
> > :00:1c.5
> > + pcieport :00:1c.5: AER: found no error details for :00:1c.5
> >
> > Signed-off-by: Bjorn Helgaas
>
> Except for the suggestion given below, it looks good to me.
>
> Reviewed-by: Kuppuswamy Sathyanarayanan
>
Thanks for taking a look!
> > @@ -740,7 +740,7 @@ static void aer_print_port_info(struct pci_dev *dev,
> > struct aer_err_info *info)
> > u8 bus = info->id >> 8;
> > u8 devfn = info->id & 0xff;
> >
> > - pci_info(dev, "%s%s error received: %04x:%02x:%02x.%d\n",
> > + pci_info(dev, "%s%s error message received from %04x:%02x:%02x.%d\n",
> > info->multi_error_valid ? "Multiple " : "",
> > aer_error_severity_string[info->severity],
> > pci_domain_nr(dev->bus), bus, PCI_SLOT(devfn),
> > @@ -929,7 +929,12 @@ static bool find_source_device(struct pci_dev *parent,
> > pci_walk_bus(parent->subordinate, find_device_iter, e_info);
> >
> > if (!e_info->error_dev_num) {
> > - pci_info(parent, "can't find device of ID%04x\n", e_info->id);
> > + u8 bus = e_info->id >> 8;
> > + u8 devfn = e_info->id & 0xff;
>
> You can use PCI_BUS_NUM(e_info->id) for getting bus number. Since
> you are extracting this info in more than one place, maybe you can
> also define a macro PCI_DEVFN(id) (following PCI_BUS_NUM()).
Thanks, both good ideas.
We already have a PCI_DEVFN() that *combines* slot + func into devfn,
so we'd have to come up with a different name.
I'll add a patch to use PCI_BUS_NUM() in the two places here and in
pme.c.
I think I'll wait with these until after the v6.7 release.
> > + pci_info(parent, "found no error details for
> > %04x:%02x:%02x.%d\n",
> > +pci_domain_nr(parent->bus), bus, PCI_SLOT(devfn),
> > +PCI_FUNC(devfn));
> > return false;
> > }
> > return true;
>
> --
> Sathyanarayanan Kuppuswamy
> Linux Kernel Developer
[PATCH] crypto:vmx: Move ppc vmx diirectory to arch/powerpc/crypto.
Relocate all crypto files in vmx driver to arch/powerpc/crypto directory
and remove vmx directory.
drivers/crypto/vmx/aes.c rename to arch/powerpc/crypto/aes.c
drivers/crypto/vmx/aes_cbc.c rename to arch/powerpc/crypto/aes_cbc.c
drivers/crypto/vmx/aes_ctr.c rename to arch/powerpc/crypto/aes_ctr.c
drivers/crypto/vmx/aes_xts.c rename to arch/powerpc/crypto/aes_xts.c
drivers/crypto/vmx/aesp8-ppc.h rename to arch/powerpc/crypto/aesp8-ppc.h
drivers/crypto/vmx/aesp8-ppc.pl rename to arch/powerpc/crypto/aesp8-ppc.pl
drivers/crypto/vmx/ghash.c rename to arch/powerpc/crypto/ghash.c
drivers/crypto/vmx/ghashp8-ppc.pl rename to arch/powerpc/crypto/ghashp8-ppc.pl
drivers/crypto/vmx/vmx.c rename to arch/powerpc/crypto/vmx.c
deleted files:
drivers/crypto/vmx/Makefile
drivers/crypto/vmx/Kconfig
drivers/crypto/vmx/ppc-xlate.pl
This patch has been tested has passed the selftest. The patch is also tested
with
CONFIG_CRYPTO_MANAGER_EXTRA_TESTS enabled.
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/Kconfig | 20 ++
arch/powerpc/crypto/Makefile | 20 +-
.../crypto/vmx => arch/powerpc/crypto}/aes.c | 0
.../vmx => arch/powerpc/crypto}/aes_cbc.c | 0
.../vmx => arch/powerpc/crypto}/aes_ctr.c | 0
.../vmx => arch/powerpc/crypto}/aes_xts.c | 0
.../vmx => arch/powerpc/crypto}/aesp8-ppc.h | 0
.../vmx => arch/powerpc/crypto}/aesp8-ppc.pl | 0
.../vmx => arch/powerpc/crypto}/ghash.c | 0
.../powerpc/crypto}/ghashp8-ppc.pl| 0
.../crypto/vmx => arch/powerpc/crypto}/vmx.c | 0
drivers/crypto/Kconfig| 14 +-
drivers/crypto/Makefile | 2 +-
drivers/crypto/vmx/.gitignore | 3 -
drivers/crypto/vmx/Kconfig| 14 --
drivers/crypto/vmx/Makefile | 23 --
drivers/crypto/vmx/ppc-xlate.pl | 231 --
17 files changed, 46 insertions(+), 281 deletions(-)
rename {drivers/crypto/vmx => arch/powerpc/crypto}/aes.c (100%)
rename {drivers/crypto/vmx => arch/powerpc/crypto}/aes_cbc.c (100%)
rename {drivers/crypto/vmx => arch/powerpc/crypto}/aes_ctr.c (100%)
rename {drivers/crypto/vmx => arch/powerpc/crypto}/aes_xts.c (100%)
rename {drivers/crypto/vmx => arch/powerpc/crypto}/aesp8-ppc.h (100%)
rename {drivers/crypto/vmx => arch/powerpc/crypto}/aesp8-ppc.pl (100%)
rename {drivers/crypto/vmx => arch/powerpc/crypto}/ghash.c (100%)
rename {drivers/crypto/vmx => arch/powerpc/crypto}/ghashp8-ppc.pl (100%)
rename {drivers/crypto/vmx => arch/powerpc/crypto}/vmx.c (100%)
delete mode 100644 drivers/crypto/vmx/.gitignore
delete mode 100644 drivers/crypto/vmx/Kconfig
delete mode 100644 drivers/crypto/vmx/Makefile
delete mode 100644 drivers/crypto/vmx/ppc-xlate.pl
diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig
index 6fc2248ca561..1e201b7ae2fc 100644
--- a/arch/powerpc/crypto/Kconfig
+++ b/arch/powerpc/crypto/Kconfig
@@ -137,4 +137,24 @@ config CRYPTO_POLY1305_P10
- Power10 or later
- Little-endian
+config CRYPTO_DEV_VMX
+bool "Support for VMX cryptographic acceleration instructions"
+depends on PPC64 && VSX
+help
+ Support for VMX cryptographic acceleration instructions.
+
+config CRYPTO_DEV_VMX_ENCRYPT
+ tristate "Encryption acceleration support on P8 CPU"
+ depends on CRYPTO_DEV_VMX
+ select CRYPTO_AES
+ select CRYPTO_CBC
+ select CRYPTO_CTR
+ select CRYPTO_GHASH
+ select CRYPTO_XTS
+ default m
+ help
+ Support for VMX cryptographic acceleration instructions on Power8 CPU.
+ This module supports acceleration for AES and GHASH in hardware. If
you
+ choose 'M' here, this module will be called vmx-crypto.
+
endmenu
diff --git a/arch/powerpc/crypto/Makefile b/arch/powerpc/crypto/Makefile
index ebdac1b9eb9a..fca0e9739869 100644
--- a/arch/powerpc/crypto/Makefile
+++ b/arch/powerpc/crypto/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_CRYPTO_VPMSUM_TESTER) += crc-vpmsum_test.o
obj-$(CONFIG_CRYPTO_AES_GCM_P10) += aes-gcm-p10-crypto.o
obj-$(CONFIG_CRYPTO_CHACHA20_P10) += chacha-p10-crypto.o
obj-$(CONFIG_CRYPTO_POLY1305_P10) += poly1305-p10-crypto.o
+obj-$(CONFIG_CRYPTO_DEV_VMX_ENCRYPT) += vmx-crypto.o
aes-ppc-spe-y := aes-spe-core.o aes-spe-keys.o aes-tab-4k.o aes-spe-modes.o
aes-spe-glue.o
md5-ppc-y := md5-asm.o md5-glue.o
@@ -27,14 +28,29 @@ crct10dif-vpmsum-y := crct10dif-vpmsum_asm.o
crct10dif-vpmsum_glue.o
aes-gcm-p10-crypto-y := aes-gcm-p10-glue.o aes-gcm-p10.o ghashp10-ppc.o
aesp10-ppc.o
chacha-p10-crypto-y := chacha-p10-glue.o chacha-p10le-8x.o
poly1305-p10-crypto-y := poly1305-p10-glue.o poly1305-p10le_64.o
+vmx-crypto-objs := vmx.o aesp8-ppc.o ghashp8-ppc.o aes.o aes_cbc.o aes_ctr.o
aes_xts.o ghash.o
+
+ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
+override flavour := linux-ppc64le
+else
+ifdef CONFIG_PPC64_ELF_ABI_V2
+override flavour := linux-ppc64-elfv2
+else
Re: [PATCH 1/3] PCI/AER: Use 'Correctable' and 'Uncorrectable' spec terms for errors
On 12/6/2023 2:42 PM, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> The PCIe spec classifies errors as either "Correctable" or "Uncorrectable".
> Previously we printed these as "Corrected" or "Uncorrected". To avoid
> confusion, use the same terms as the spec.
>
> One confusing situation is when one agent detects an error, but another
> agent is responsible for recovery, e.g., by re-attempting the operation.
> The first agent may log a "correctable" error but it has not yet been
> corrected. The recovery agent must report an uncorrectable error if it is
> unable to recover. If we print the first agent's error as "Corrected", it
> gives the false impression that it has already been resolved.
>
> Sample message change:
>
> - pcieport :00:1c.5: AER: Corrected error received: :00:1c.5
> + pcieport :00:1c.5: AER: Correctable error received: :00:1c.5
>
> Signed-off-by: Bjorn Helgaas
> ---
Looks good to me.
Reviewed-by: Kuppuswamy Sathyanarayanan
> drivers/pci/pcie/aer.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index 42a3bd35a3e1..20db80018b5d 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -436,9 +436,9 @@ void pci_aer_exit(struct pci_dev *dev)
> * AER error strings
> */
> static const char *aer_error_severity_string[] = {
> - "Uncorrected (Non-Fatal)",
> - "Uncorrected (Fatal)",
> - "Corrected"
> + "Uncorrectable (Non-Fatal)",
> + "Uncorrectable (Fatal)",
> + "Correctable"
> };
>
> static const char *aer_error_layer[] = {
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
Re: [PATCH 2/3] PCI/AER: Decode Requester ID when no error info found
On 12/6/2023 2:42 PM, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> When a device with AER detects an error, it logs error information in its
> own AER Error Status registers. It may send an Error Message to the Root
> Port (RCEC in the case of an RCiEP), which logs the fact that an Error
> Message was received (Root Error Status) and the Requester ID of the
> message source (Error Source Identification).
>
> aer_print_port_info() prints the Requester ID from the Root Port Error
> Source in the usual Linux "bb:dd.f" format, but when find_source_device()
> finds no error details in the hierarchy below the Root Port, it printed the
> raw Requester ID without decoding it.
>
> Decode the Requester ID in the usual Linux format so it matches other
> messages.
>
> Sample message changes:
>
> - pcieport :00:1c.5: AER: Correctable error received: :00:1c.5
> - pcieport :00:1c.5: AER: can't find device of ID00e5
> + pcieport :00:1c.5: AER: Correctable error message received from
> :00:1c.5
> + pcieport :00:1c.5: AER: found no error details for :00:1c.5
>
> Signed-off-by: Bjorn Helgaas
Except for the suggestion given below, it looks good to me.
Reviewed-by: Kuppuswamy Sathyanarayanan
> ---
> drivers/pci/pcie/aer.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index 20db80018b5d..2ff6bac9979f 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -740,7 +740,7 @@ static void aer_print_port_info(struct pci_dev *dev,
> struct aer_err_info *info)
> u8 bus = info->id >> 8;
> u8 devfn = info->id & 0xff;
>
> - pci_info(dev, "%s%s error received: %04x:%02x:%02x.%d\n",
> + pci_info(dev, "%s%s error message received from %04x:%02x:%02x.%d\n",
>info->multi_error_valid ? "Multiple " : "",
>aer_error_severity_string[info->severity],
>pci_domain_nr(dev->bus), bus, PCI_SLOT(devfn),
> @@ -929,7 +929,12 @@ static bool find_source_device(struct pci_dev *parent,
> pci_walk_bus(parent->subordinate, find_device_iter, e_info);
>
> if (!e_info->error_dev_num) {
> - pci_info(parent, "can't find device of ID%04x\n", e_info->id);
> + u8 bus = e_info->id >> 8;
> + u8 devfn = e_info->id & 0xff;
You can use PCI_BUS_NUM(e_info->id) for getting bus number. Since you are
extracting this info in more than one place, maybe you can also define a
macro PCI_DEVFN(id) (following PCI_BUS_NUM()).
> +
> + pci_info(parent, "found no error details for
> %04x:%02x:%02x.%d\n",
> + pci_domain_nr(parent->bus), bus, PCI_SLOT(devfn),
> + PCI_FUNC(devfn));
> return false;
> }
> return true;
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
Re: [PATCH v4] powerpc/pseries/vas: Use usleep_range() to support HCALL delay
"Aneesh Kumar K.V" writes:
> Haren Myneni writes:
>
>> diff --git a/arch/powerpc/platforms/pseries/vas.c
>> b/arch/powerpc/platforms/pseries/vas.c
>> index 71d52a670d95..5cf81c564d4b 100644
>> --- a/arch/powerpc/platforms/pseries/vas.c
>> +++ b/arch/powerpc/platforms/pseries/vas.c
>> @@ -38,7 +38,30 @@ static long hcall_return_busy_check(long rc)
>> {
>> /* Check if we are stalled for some time */
>> if (H_IS_LONG_BUSY(rc)) {
>> -msleep(get_longbusy_msecs(rc));
>> +unsigned int ms;
>> +/*
>> + * Allocate, Modify and Deallocate HCALLs returns
>> + * H_LONG_BUSY_ORDER_1_MSEC or H_LONG_BUSY_ORDER_10_MSEC
>> + * for the long delay. So the sleep time should always
>> + * be either 1 or 10msecs, but in case if the HCALL
>> + * returns the long delay > 10 msecs, clamp the sleep
>> + * time to 10msecs.
>> + */
>> +ms = clamp(get_longbusy_msecs(rc), 1, 10);
>> +
>> +/*
>> + * msleep() will often sleep at least 20 msecs even
>> + * though the hypervisor suggests that the OS reissue
>> + * HCALLs after 1 or 10msecs. Also the delay hint from
>> + * the HCALL is just a suggestion. So OK to pause for
>> + * less time than the hinted delay. Use usleep_range()
>> + * to ensure we don't sleep much longer than actually
>> + * needed.
>> + *
>> + * See Documentation/timers/timers-howto.rst for
>> + * explanation of the range used here.
>> + */
>> +usleep_range(ms * 100, ms * 1000);
>>
>
> Is there more details on this range? (ms *100, ms * 1000)
The preceding comment ("see Documentation/timers/timers-howto...")
should be removed, that document does not really explain this range
directly.
What timers-howto does say is that the larger a range you provide, the
less likely you are to trigger an interrupt to wake up. Since we know
that retrying "too soon" is harmless, providing a lower bound an order
of magnitude less than the suggested delay (which forms the upper bound)
seems reasonable.
>
> can we use USEC_PER_MSEC instead of 1000.
agreed
>> rc = H_BUSY;
>> } else if (rc == H_BUSY) {
>> cond_resched();
>
>
> It would be good to convert this to a helper and switch rtas_busy_delay
> to use this new helper.
I have reservations about that suggestion.
The logic for handling the 990x extended delay constants conceivably
could be shared. But any helper that handles the "retry immediately"
statuses has to know whether it's handling a status from an RTAS call or
an hcall: RTAS_BUSY and H_BUSY have the same semantics but different
values.
Also I don't really want kernel/rtas.c to gain more dependencies on
pseries-specific code as long as there are non-pseries platforms that
use it (chrp, maple, cell).
Tolerating a little duplication here should be OK IMO.
> One question though is w.r.t the clamp values.
> Does that need to be specific to each hcall? Can we make it generic?
>
> rtas_busy_delay() expliclity check for 20msec. Any reason to do that?
> timers-howto.rst suggest > 10msec to use msleep.
I understand it to suggest (roughly) 20ms for the threshold:
SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms):
* Use usleep_range
[...]
msleep(1~20) may not do what the caller intends, and
will often sleep longer (~20 ms actual sleep for any
value given in the 1~20ms range).
20ms is also the threshold used by fsleep().
Re: [Mainline/linux-next-netdev/net-next/scsi]Dlpar remove, drmgr phb and pci remove operations are failing
Hi, Tasmiya Nalatwad writes: > [Mainline/linux-next-netdev/net-next/scsi] What does this mean? Are you reporting this issue against four separate trees? > Dlpar remove, drmgr phb and > pci remove operations are failing > > command ---> chhwres -r io --rsubtype slot -m "managed system name" -o r > --id 6 -l 21030014 > > output ---> > > HSCL2929 The dynamic removal of I/O resources failed: The I/O slot > dynamic partitioning operation failed. Here are the I/O slot IDs that > failed and the reasons for failure: > > Jan 02 02:20:22 caDlparCommand:execv to drmgr > Validating PHB DLPAR capability...yes. > Could not find drc index 0x2014 to add to phb list > There are no DR capable slots on this system > Could not find PHB PHB 20 > > The OS return code is 3. This isn't really a useful report to send to kernel mailing lists. This is a mixture of output from the HMC (Hardware Management Console) and output from drmgr, a powerpc-specific utility that the HMC invokes remotely on the host. There's no indication of a kernel problem. This is just a guess, but please ensure your powerpc-utils package (which contains drmgr) is reasonably recent. Versions up until something like 3-4 years ago don't understand the ibm,drc-info properties in the device tree and may experience failures like this. If that doesn't help, there is likely some other issue (kernel or not) to investigate here. Your best route to a resolution is probably to file an internal bug and make the test environment available to a developer who can look into it.
Re: [PATCHv3 RESEND 10/10] ASoC: dt-bindings: fsl-asoc-card: add compatible for generic codec
Hello, On Wednesday, 20 December, 2023 23:25:50, Rob Herring wrote: > On Mon, Dec 18, 2023 at 01:40:58PM +0100, Elinor Montmasson wrote: > > +Optional, relevant only with the "fsl,imx-audio-generic" compatible: > > + > > + - cpu-slot-width : Indicates a specific TDM slot width in bits. > > + - cpu-slot-num : Indicates a specific number of TDM slots per frame. > > Pretty sure I've seen other bindings with TDM slot properties. A sign we > need something common if we don't already have something. That's right, "tdm-slot.txt" already defines TDM bindings, I will use them with the utility function snd_soc_of_parse_tdm_slot(). > > + - cpu-sysclk-freq-rx : Frequency of the CPU DAI sys clock for Rx. > > + - cpu-sysclk-freq-tx : Frequency of the CPU DAI sys clock for Tx. > > + > > + - cpu-sysclk-dir-rx-out : Boolean property. Specifies sys clock direction > > + as 'out' on initialization for Rx. > > + If not set, default direction is 'in'. > > + - cpu-sysclk-dir-tx-out : Boolean property. Specifies sys clock direction > > + as 'out' on initialization for Tx. > > + If not set, default direction is 'in'. > > Looks like clock stuff. Use the clock binding. simple-card defines similar properties at the dai level: "system-clock-frequency" and "system-clock-direction-out". The first is used if no "clocks" binding is specified for the dai node. Maybe I could use a similar logic with fsl-asoc-card ? * adding a "clock-cpu" phandle property which should be the cpu clock. It will be used to retreive the frequency for both RX and TX. * keeping "cpu-sysclk-freq-rx"/"cpu-sysclk-freq-tx", which are used if no clock is provided, like "system-clock-frequency" in simple-card. * keep using "cpu-sysclk-dir-rx-out"/"cpu-sysclk-dir-tx-out", like "system-clock-direction-out" in simple card. Also, maybe I could rename my new properties: cpu-system-clock-frequency-tx, cpu-system-clock-direction-out-rx, ... It would better match those in simple-card as they do the same thing. Best regards, Elinor Montmasson
[Mainline/linux-next-netdev/net-next/scsi]Dlpar remove, drmgr phb and pci remove operations are failing
Greetings, [Mainline/linux-next-netdev/net-next/scsi]Dlpar remove, drmgr phb and pci remove operations are failing command ---> chhwres -r io --rsubtype slot -m "managed system name" -o r --id 6 -l 21030014 output ---> HSCL2929 The dynamic removal of I/O resources failed: The I/O slot dynamic partitioning operation failed. Here are the I/O slot IDs that failed and the reasons for failure: Jan 02 02:20:22 caDlparCommand:execv to drmgr Validating PHB DLPAR capability...yes. Could not find drc index 0x2014 to add to phb list There are no DR capable slots on this system Could not find PHB PHB 20 The OS return code is 3. -- Regards, Tasmiya Nalatwad IBM Linux Technology Center
