* Re: [PATCH 02/17] bitops: Add generic parity calculation for u64
From: Jiri Slaby @ 2025-02-27 6:38 UTC (permalink / raw)
To: Yury Norov
Cc: Kuan-Wei Chiu, tglx, mingo, bp, dave.hansen, x86, jk, joel,
eajames, andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, dmitry.torokhov, mchehab,
awalls, hverkuil, miquel.raynal, richard, vigneshr, louis.peens,
andrew+netdev, davem, edumazet, pabeni, parthiban.veerasooran,
arend.vanspriel, johannes, gregkh, akpm, hpa, alistair, linux,
Laurent.pinchart, jonas, jernej.skrabec, kuba, linux-kernel,
linux-fsi, dri-devel, linux-input, linux-media, linux-mtd,
oss-drivers, netdev, linux-wireless, brcm80211,
brcm80211-dev-list.pdl, linux-serial, bpf, jserv, Yu-Chun Lin
In-Reply-To: <Z79ebv630yuNOJKV@thinkpad>
On 26. 02. 25, 19:33, Yury Norov wrote:
>> Not in cases where macros are inevitable. I mean, do we need parityXX() for
>> XX in (8, 16, 32, 64) at all? Isn't the parity() above enough for everybody?
>
> The existing codebase has something like:
>
> int ret;
>
> ret = i3c_master_get_free_addr(m, last_addr + 1);
> ret |= parity8(ret) ? 0 : BIT(7)
>
> So if we'll switch it to a macro like one above, it will become a
> 32-bit parity. It wouldn't be an error because i3c_master_get_free_addr()
> returns an u8 or -ENOMEM, and the error code is checked explicitly.
>
> But if we decide to go with parity() only, some users will have to
> call it like parity((u8)val) explicitly. Which is not bad actually.
That cast looks ugly -- we apparently need parityXX(). (In this
particular case we could do parity8(last_addr), but I assume there are
more cases like this.) Thanks for looking up the case for this.
>> And if not, you can have all those parityXX() as inlines as you suggest, but
>> also provide a macro such as the above to call (optimized) parityXX() as per
>> datatype len.
>
> Yes, if we need fixed-type parity's, they should all be one-liners
> calling the same macro. Macros or inline functions - no preference for
> me.
--
js
suse labs
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH 02/17] bitops: Add generic parity calculation for u64
From: Jiri Slaby @ 2025-02-27 6:38 UTC (permalink / raw)
To: Yury Norov
Cc: Kuan-Wei Chiu, tglx, mingo, bp, dave.hansen, x86, jk, joel,
eajames, andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, dmitry.torokhov, mchehab,
awalls, hverkuil, miquel.raynal, richard, vigneshr, louis.peens,
andrew+netdev, davem, edumazet, pabeni, parthiban.veerasooran,
arend.vanspriel, johannes, gregkh, akpm, hpa, alistair, linux,
Laurent.pinchart, jonas, jernej.skrabec, kuba, linux-kernel,
linux-fsi, dri-devel, linux-input, linux-media, linux-mtd,
oss-drivers, netdev, linux-wireless, brcm80211,
brcm80211-dev-list.pdl, linux-serial, bpf, jserv, Yu-Chun Lin
In-Reply-To: <Z79ebv630yuNOJKV@thinkpad>
On 26. 02. 25, 19:33, Yury Norov wrote:
>> Not in cases where macros are inevitable. I mean, do we need parityXX() for
>> XX in (8, 16, 32, 64) at all? Isn't the parity() above enough for everybody?
>
> The existing codebase has something like:
>
> int ret;
>
> ret = i3c_master_get_free_addr(m, last_addr + 1);
> ret |= parity8(ret) ? 0 : BIT(7)
>
> So if we'll switch it to a macro like one above, it will become a
> 32-bit parity. It wouldn't be an error because i3c_master_get_free_addr()
> returns an u8 or -ENOMEM, and the error code is checked explicitly.
>
> But if we decide to go with parity() only, some users will have to
> call it like parity((u8)val) explicitly. Which is not bad actually.
That cast looks ugly -- we apparently need parityXX(). (In this
particular case we could do parity8(last_addr), but I assume there are
more cases like this.) Thanks for looking up the case for this.
>> And if not, you can have all those parityXX() as inlines as you suggest, but
>> also provide a macro such as the above to call (optimized) parityXX() as per
>> datatype len.
>
> Yes, if we need fixed-type parity's, they should all be one-liners
> calling the same macro. Macros or inline functions - no preference for
> me.
--
js
suse labs
^ permalink raw reply
* automount doesn't work without GPT table
From: Alexander Shiyan @ 2025-02-27 6:37 UTC (permalink / raw)
To: Barebox List
Hello All.
I found that automounting does not work without a GPT table.
In the example below, it is not possible to automatically mount a
partition from an MMC card.
However, if I add the full paths to the command manually, everything works.
barebox 2025.02.0-00690-ga6a0a0ba4f61 #12 Thu Feb 27 08:27:56 MSK 2025
Board: Mega-Milas MM-SM-SAMA5D2
AT91: Detected soc type: sama5d2
AT91: Detected soc subtype: sama5d27c_d1g
...
sdhci-at91 b0000000.sdio-host@b0000000.of: registered as mmc1
mmc1: detected SD card version 2.0
mmc1: registered mmc1
...
barebox@Mega-Milas Informer SAMA5D2:/ ls /mnt/mmc1.0
mount: Device or resource busy
running automount command 'mount mmc1.0' failed
ls: No such device
barebox@Mega-Milas Informer SAMA5D2:/ automount -l
/mnt/mmc1 mount mmc1
/mnt/mmc1.0 mount mmc1.0
/mnt/mmc1.1 mount mmc1.1
/mnt/tftp ifup -a1 && mount -t tftp $global.net.server /mnt/tftp
/mnt/nfs ifup -a1 && mount -t nfs
${global.net.server}:/home/${global.user}/nfsroot/${global.hostname}
/mnt/nfs
/mnt/ratp mount -t ratpfs none /mnt/ratp
barebox@Mega-Milas Informer SAMA5D2:/ automount /mnt/mmc1.0 "mount
/dev/mmc1.0 /mnt/mmc1.0"
barebox@Mega-Milas Informer SAMA5D2:/ ls /mnt/mmc1.0
BOOT.BIN barebox.bin barebox.env rootfs.squashfs
With the GPT table on the MMC, everything works OK out of the box:
sdhci-at91 b0000000.sdio-host@b0000000.of: registered as mmc1
mmc1: detected SD card version 2.0
WARNING: mmc1: GPT:Primary header thinks Alt. header is not at the end
of the disk.
WARNING: mmc1: GPT:395303 != 60440575
WARNING: mmc1: GPT:Alternate GPT header not at the end of the disk.
WARNING: mmc1: GPT:395303 != 60440575
WARNING: mmc1: GPT: Use parted to correct GPT errors.
mmc1: registered mmc1
...
barebox@Mega-Milas Informer SAMA5D2:/ ls /mnt/mmc1.0
mounted /dev/mmc1.0 on /mnt/mmc1.0
BOOT.BIN barebox.bin barebox.env rootfs.squashfs
^ permalink raw reply
* Re: [PATCH v2 4/6] usb: chipidea: imx: add wakeup interrupt handling
From: Xu Yang @ 2025-02-27 6:34 UTC (permalink / raw)
To: Peter Chen
Cc: gregkh, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, linux-usb, devicetree, imx, jun.li
In-Reply-To: <Z7_bInsND2BpyOdX@nchen-desktop>
On Thu, Feb 27, 2025 at 11:25:22AM +0800, Peter Chen wrote:
> On 25-02-25 13:39:53, Xu Yang wrote:
> > In previous imx platform, normal USB controller interrupt and wakeup
> > interrupt are bound to one irq line. However, it changes on latest
> > i.MX95 platform since it has a dedicated irq line for wakeup interrupt.
> > This will add wakeup interrupt handling for i.MX95 to support various
> > wakeup events.
> >
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
>
> Please fix the build error, and others are okay for me.
Sure, I'm going to fix it.
Thanks,
Xu Yang
^ permalink raw reply
* Re: [PATCH 05/11] PCI/TSM: Authenticate devices via platform TSM
From: Xu Yilun @ 2025-02-27 6:35 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Alexey Kardashevskiy, Dan Williams, linux-coco, Lukas Wunner,
Samuel Ortiz, Bjorn Helgaas, linux-pci, gregkh
In-Reply-To: <yq5a4j0gc3fp.fsf@kernel.org>
On Wed, Feb 26, 2025 at 05:40:02PM +0530, Aneesh Kumar K.V wrote:
> Xu Yilun <yilun.xu@linux.intel.com> writes:
>
> > On Fri, Feb 21, 2025 at 01:43:28PM +0530, Aneesh Kumar K.V wrote:
> >> Alexey Kardashevskiy <aik@amd.com> writes:
> >>
> >> ....
> >>
> >> >
> >> > I am trying to wrap my head around your tsm. here is what I got in my tree:
> >> > https://github.com/aik/linux/blob/tsm/include/linux/tsm.h
> >> >
> >> > Shortly:
> >> >
> >> > drivers/virt/coco/tsm.ko does sysfs (including "connect" and "bind" to
> >> > control and "certs"/"report" to attest) and implements tsm_dev/tsm_tdi,
> >> > it does not know pci_dev;
> >> >
> >> > drivers/pci/tsm-pci.ko creates/destroys tsm_dev/tsm_dev using tsm.ko;
> >> >
> >> > drivers/crypto/ccp/ccp.ko (the PSP guy) registers:
> >> > - tsm_subsys in tsm.ko (which does "connect" and "bind" and
> >> > - tsm_bus_subsys in tsm-pci.ko (which does "spdm_forward")
> >> > ccp.ko knows about pci_dev and whatever else comes in the future, and
> >> > ccp.ko's "connect" implementation calls the IDE library (I am adopting
> >> > yours now, with some tweaks).
> >> >
> >> > tsm-dev and tsm-tdi embed struct dev each and are added as children to
> >> > PCI devices: no hide/show attrs, no additional TSM pointer in struct
> >> > device or pci_dev, looks like:
> >> >
> >> > aik@sc ~> ls /sys/bus/pci/devices/0000:e1:04.0/tsm-tdi/tdi:0000:e1:04.0/
> >> > device power subsystem tsm_report tsm_report_user tsm_tdi_bind
> >> > tsm_tdi_status tsm_tdi_status_user uevent
> >> >
> >> > aik@sc ~> ls /sys/bus/pci/devices/0000:e1:04.0/tsm_dev/
> >> > device power subsystem tsm_certs tsm_cert_slot tsm_certs_user
> >> > tsm_dev_connect tsm_dev_status tsm_meas tsm_meas_user uevent
> >> >
> >> > aik@sc ~> ls /sys/class/tsm/tsm0/
> >> > device power stream0:0000:e1:00.0 subsystem uevent
> >> >
> >> > aik@sc ~> ls /sys/class/tsm-dev/
> >> > tdev:0000:c0:01.1 tdev:0000:e0:01.1 tdev:0000:e1:00.0
> >> >
> >> > aik@sc ~> ls /sys/class/tsm-tdi/
> >> > tdi:0000:c0:01.1 tdi:0000:e0:01.1 tdi:0000:e1:00.0 tdi:0000:e1:04.0
> >> > tdi:0000:e1:04.1 tdi:0000:e1:04.2 tdi:0000:e1:04.3
> >> >
> >> >
> >> > SPDM forwarding seems a bus-agnostic concept, "connect" is a PCI thing
> >> > but pci_dev is only needed for DOE/IDE.
> >> >
> >> > Or is separating struct pci_dev from struct device not worth it and most
> >> > of it should go to tsm-pci.ko? Then what is left for tsm.ko? Thanks,
> >> >
> >>
> >> For the Arm CCA DA, I have structured the flow as follows. I am
> >> currently refining my changes to prepare them for posting. I am using
> >> tsm-core in both the host and guest. There is no bind interface at the
> >> sysfs level; instead, it is managed via the KVM ioctl
> >>
> >> Host:
> >> step 1.
> >> echo ${DEVICE} > /sys/bus/pci/devices/${DEVICE}/driver/unbind
> >> echo vfio-pci > /sys/bus/pci/devices/${DEVICE}/driver_override
> >> echo ${DEVICE} > /sys/bus/pci/drivers_probe
> >>
> >> step 2.
> >> echo 1 > /sys/bus/pci/devices/$DEVICE/tsm/connect
> >>
> >> step 3.
> >> using VMM to make the new KVM_SET_DEVICE_ATTR ioctl
> >>
> >> + dev_num = vfio_devices[i].dev_hdr.dev_num;
> >> + /* kvmtool only do 0 domain, 0 bus and 0 function devices. */
> >> + guest_bdf = (0ULL << 32) | (0 << 16) | dev_num << 11 | (0 << 8);
> >> +
> >> + struct kvm_vfio_tsm_bind param = {
> >> + .guest_rid = guest_bdf,
> >> + .devfd = vfio_devices[i].fd,
> >> + };
> >> + struct kvm_device_attr attr = {
> >> + .group = KVM_DEV_VFIO_DEVICE,
> >> + .attr = KVM_DEV_VFIO_DEVICE_TDI_BIND,
> >> + .addr = (__u64)¶m,
> >> + };
> >> +
> >> + if (ioctl(kvm_vfio_device, KVM_SET_DEVICE_ATTR, &attr)) {
> >> + pr_err("Failed KVM_SET_DEVICE_ATTR for KVM_DEV_VFIO_DEVICE");
> >> + return -ENODEV;
> >> + }
> >> +
> >
> > I think bind (which brings device to a LOCKED state, no MMIO, no DMA)
> > cannot be a driver agnostic behavior. So I think it should be a VFIO
> > ioctl.
> >
>
> For the current CCA implementation bind is equivalent to VDEV_CREATE
> which doesn't mark the device LOCKED. Marking the device LOCKED is
> driven by the guest as shown in the steps below.
Could you elaborate why vdev create & LOCK can't be done at the same
time, when guest requests "lock"? Intel TDX also requires firmware calls
like tdi_create(alloc metadata) & tdi_bind(do LOCK), but I don't see
there is need to break them out in different phases.
>
>
> >>
> >> Now in the guest we follow the below steps
> >>
> >> step 1:
> >> echo ${DEVICE} > /sys/bus/pci/devices/${DEVICE}/driver/unbind
> >>
> >> step 2: Move the device to TDISP LOCK state
> >> echo 1 > /sys/bus/pci/devices/0000:00:00.0/tsm/connect
> >> echo 3 > /sys/bus/pci/devices/0000:00:00.0/tsm/connect
> >
> > Reuse the 'connect' interface? I think it conceptually brings chaos. Is
> > it better we create a new interface?
> >
>
> I was looking at converting these numbers to strings.
> "1" -> connect
What does "connect" do in guest?
Thanks,
Yilun
> "2" -> lock
> "3" -> run
>
>
> >
> >>
> >> step 3: Moves the device to TDISP RUN state
> >> echo 4 > /sys/bus/pci/devices/0000:00:00.0/tsm/connect
> >
> > Could you elaborate what '1'/'3'/'4' stand for?
> >
>
> As mentioned above, them move the device to different TDISP state.
>
> I will reply to this patch with my early RFC chnages for tsm framework.
> I am not yet ready to share the CCA backend changes. But I assume having
> the tsm framework changes alone can be useful?
>
> -aneesh
^ permalink raw reply
* [kirkstone][meta-oe][PATCH] abseil-cpp: fix CVE-2025-0838
From: changqing.li @ 2025-02-27 6:36 UTC (permalink / raw)
To: openembedded-devel
From: Changqing Li <changqing.li@windriver.com>
Backport a patch to fix CVE-2025-0838
CVE-2025-0838:
There exists a heap buffer overflow vulnerable in Abseil-cpp. The sized
constructors, reserve(), and rehash() methods of
absl::{flat,node}hash{set,map} did not impose an upper bound on their
size argument. As a result, it was possible for a caller to pass a very
large size that would cause an integer overflow when computing the size
of the container's backing store, and a subsequent out-of-bounds memory
write. Subsequent accesses to the container might also access
out-of-bounds memory. We recommend upgrading past commit
5a0e2cb5e3958dd90bb8569a2766622cb74d90c1
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2025-0838
Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
.../abseil-cpp/abseil-cpp/CVE-2025-0838.patch | 114 ++++++++++++++++++
.../abseil-cpp/abseil-cpp_git.bb | 1 +
2 files changed, 115 insertions(+)
create mode 100644 meta-oe/recipes-devtools/abseil-cpp/abseil-cpp/CVE-2025-0838.patch
diff --git a/meta-oe/recipes-devtools/abseil-cpp/abseil-cpp/CVE-2025-0838.patch b/meta-oe/recipes-devtools/abseil-cpp/abseil-cpp/CVE-2025-0838.patch
new file mode 100644
index 0000000000..c8d5cd1f0a
--- /dev/null
+++ b/meta-oe/recipes-devtools/abseil-cpp/abseil-cpp/CVE-2025-0838.patch
@@ -0,0 +1,114 @@
+From bdbad523d92cd2308139086226bfc36fc2068267 Mon Sep 17 00:00:00 2001
+From: Changqing Li <changqing.li@windriver.com>
+Date: Thu, 27 Feb 2025 12:05:11 +0800
+Subject: [PATCH] Fix potential integer overflow in hash container
+ create/resize (#1813)
+
+The sized constructors, reserve(), and rehash() methods of
+absl::{flat,node}_hash_{set,map} did not impose an upper bound on
+their size argument. As a result, it was possible for a caller to pass
+a very large size that would cause an integer overflow when computing
+the size of the container's backing store. Subsequent accesses to the
+container might then access out-of-bounds memory.
+
+The fix is in two parts:
+
+1) Update max_size() to return the maximum number of items that can be
+stored in the container
+
+2) Validate the size arguments to the constructors, reserve(), and
+rehash() methods, and abort the program when the argument is invalid
+
+We've looked at uses of these containers in Google codebases like
+Chrome, and determined this vulnerability is likely to be difficult to
+exploit. This is primarily because container sizes are rarely
+attacker-controlled.
+
+The bug was discovered by Dmitry Vyukov <dvyukov@google.com>.
+
+CVE: CVE-2025-0838
+Upstream-Status: Backport [https://github.com/abseil/abseil-cpp/commit/caa7bb4457bfcafcd55a940204ef78c1bf1f417d]
+This patch is backported from 20230802.3
+
+Signed-off-by: Changqing Li <changqing.li@windriver.com>
+---
+ absl/container/internal/raw_hash_set.h | 15 ++++++++++++++-
+ absl/container/internal/raw_hash_set_test.cc | 8 ++++++++
+ 2 files changed, 22 insertions(+), 1 deletion(-)
+
+diff --git a/absl/container/internal/raw_hash_set.h b/absl/container/internal/raw_hash_set.h
+index 046a6939..ecea25b4 100644
+--- a/absl/container/internal/raw_hash_set.h
++++ b/absl/container/internal/raw_hash_set.h
+@@ -662,6 +662,12 @@ inline size_t NormalizeCapacity(size_t n) {
+ return n ? ~size_t{} >> countl_zero(n) : 1;
+ }
+
++template <size_t kSlotSize>
++size_t MaxValidCapacity() {
++ return NormalizeCapacity((std::numeric_limits<size_t>::max)() / 4 /
++ kSlotSize);
++}
++
+ // General notes on capacity/growth methods below:
+ // - We use 7/8th as maximum load factor. For 16-wide groups, that gives an
+ // average of two empty slots per group.
+@@ -1065,6 +1071,8 @@ class raw_hash_set {
+ : ctrl_(EmptyGroup()),
+ settings_(0, HashtablezInfoHandle(), hash, eq, alloc) {
+ if (bucket_count) {
++ ABSL_RAW_CHECK(bucket_count <= MaxValidCapacity<sizeof(slot_type)>(),
++ "Hash table size overflow");
+ capacity_ = NormalizeCapacity(bucket_count);
+ initialize_slots();
+ }
+@@ -1258,7 +1266,9 @@ class raw_hash_set {
+ bool empty() const { return !size(); }
+ size_t size() const { return size_; }
+ size_t capacity() const { return capacity_; }
+- size_t max_size() const { return (std::numeric_limits<size_t>::max)(); }
++ size_t max_size() const {
++ return CapacityToGrowth(MaxValidCapacity<sizeof(slot_type)>());
++ }
+
+ ABSL_ATTRIBUTE_REINITIALIZES void clear() {
+ // Iterating over this container is O(bucket_count()). When bucket_count()
+@@ -1595,6 +1605,8 @@ class raw_hash_set {
+ auto m = NormalizeCapacity(n | GrowthToLowerboundCapacity(size()));
+ // n == 0 unconditionally rehashes as per the standard.
+ if (n == 0 || m > capacity_) {
++ ABSL_RAW_CHECK(m <= MaxValidCapacity<sizeof(slot_type)>(),
++ "Hash table size overflow");
+ resize(m);
+
+ // This is after resize, to ensure that we have completed the allocation
+@@ -1605,6 +1617,7 @@ class raw_hash_set {
+
+ void reserve(size_t n) {
+ if (n > size() + growth_left()) {
++ ABSL_RAW_CHECK(n <= max_size(), "Hash table size overflow");
+ size_t m = GrowthToLowerboundCapacity(n);
+ resize(NormalizeCapacity(m));
+
+diff --git a/absl/container/internal/raw_hash_set_test.cc b/absl/container/internal/raw_hash_set_test.cc
+index 9cd88a28..81a5c866 100644
+--- a/absl/container/internal/raw_hash_set_test.cc
++++ b/absl/container/internal/raw_hash_set_test.cc
+@@ -2176,6 +2176,14 @@ TEST(Table, AlignOne) {
+ }
+ }
+
++TEST(Table, MaxSizeOverflow) {
++ size_t overflow = (std::numeric_limits<size_t>::max)();
++ EXPECT_DEATH_IF_SUPPORTED(IntTable t(overflow), "Hash table size overflow");
++ IntTable t;
++ EXPECT_DEATH_IF_SUPPORTED(t.reserve(overflow), "Hash table size overflow");
++ EXPECT_DEATH_IF_SUPPORTED(t.rehash(overflow), "Hash table size overflow");
++}
++
+ } // namespace
+ } // namespace container_internal
+ ABSL_NAMESPACE_END
+--
+2.34.1
+
diff --git a/meta-oe/recipes-devtools/abseil-cpp/abseil-cpp_git.bb b/meta-oe/recipes-devtools/abseil-cpp/abseil-cpp_git.bb
index 30eef75ffb..dd63aedab9 100644
--- a/meta-oe/recipes-devtools/abseil-cpp/abseil-cpp_git.bb
+++ b/meta-oe/recipes-devtools/abseil-cpp/abseil-cpp_git.bb
@@ -15,6 +15,7 @@ SRC_URI = "git://github.com/abseil/abseil-cpp;branch=${BRANCH};protocol=https \
file://0002-Remove-maes-option-from-cross-compilation.patch \
file://abseil-ppc-fixes.patch \
file://0001-absl-strings-internal-str_format-extension.h-add-mis.patch \
+ file://CVE-2025-0838.patch \
"
S = "${WORKDIR}/git"
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 3/6] usb: chipidea: imx: add HSIO Block Control wakeup setting
From: Xu Yang @ 2025-02-27 6:32 UTC (permalink / raw)
To: Peter Chen
Cc: gregkh, robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, linux-usb, devicetree, imx, jun.li
In-Reply-To: <Z7_Y3KIsyKBOqx3K@nchen-desktop>
On Thu, Feb 27, 2025 at 11:15:40AM +0800, Peter Chen wrote:
> On 25-02-25 13:39:52, Xu Yang wrote:
> > On i.MX95 platform, USB wakeup setting is controlled by HSIO Block
> > Control:
> >
> > HSIO Block Control Overview:
> > - The HSIO block control include configuration and status registers that
> > provide miscellaneous top-level controls for clocking, beat limiter
> > enables, wakeup signal enables and interrupt status for the PCIe and USB
> > interfaces.
> >
> > The wakeup function of HSIO blkctl is basically same as non-core, except
> > improvements about power lost cases. This will add the wakeup setting for
> > HSIO blkctl on i.MX95. It will firstly ioremap hsio blkctl memory, then do
> > wakeup setting as needs.
> >
> > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > Reviewed-by: Jun Li <jun.li@nxp.com>
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> >
> > ---
> > Changes in v2:
> > - add Rb tag
> > ---
> > drivers/usb/chipidea/usbmisc_imx.c | 107 +++++++++++++++++++++++++++++
> > 1 file changed, 107 insertions(+)
> >
> > diff --git a/drivers/usb/chipidea/usbmisc_imx.c b/drivers/usb/chipidea/usbmisc_imx.c
> > index 1394881fde5f..f933fc70be66 100644
> > --- a/drivers/usb/chipidea/usbmisc_imx.c
> > +++ b/drivers/usb/chipidea/usbmisc_imx.c
> > @@ -139,6 +139,22 @@
> > #define MX6_USB_OTG_WAKEUP_BITS (MX6_BM_WAKEUP_ENABLE | MX6_BM_VBUS_WAKEUP | \
> > MX6_BM_ID_WAKEUP | MX6SX_BM_DPDM_WAKEUP_EN)
> >
> > +/*
> > + * HSIO Block Control Register
> > + */
> > +
> > +#define BLKCTL_USB_WAKEUP_CTRL 0x0
> > +#define BLKCTL_OTG_WAKE_ENABLE BIT(31)
> > +#define BLKCTL_OTG_VBUS_SESSVALID BIT(4)
> > +#define BLKCTL_OTG_ID_WAKEUP_EN BIT(2)
> > +#define BLKCTL_OTG_VBUS_WAKEUP_EN BIT(1)
> > +#define BLKCTL_OTG_DPDM_WAKEUP_EN BIT(0)
> > +
> > +#define BLKCTL_WAKEUP_SOURCE (BLKCTL_OTG_WAKE_ENABLE | \
> > + BLKCTL_OTG_ID_WAKEUP_EN | \
> > + BLKCTL_OTG_VBUS_WAKEUP_EN | \
> > + BLKCTL_OTG_DPDM_WAKEUP_EN)
> > +
> > struct usbmisc_ops {
> > /* It's called once when probe a usb device */
> > int (*init)(struct imx_usbmisc_data *data);
> > @@ -159,6 +175,7 @@ struct usbmisc_ops {
> >
> > struct imx_usbmisc {
> > void __iomem *base;
> > + void __iomem *blkctl;
> > spinlock_t lock;
> > const struct usbmisc_ops *ops;
> > };
> > @@ -1016,6 +1033,76 @@ static int usbmisc_imx6sx_power_lost_check(struct imx_usbmisc_data *data)
> > return 0;
> > }
> >
> > +static u32 usbmisc_blkctl_wakeup_setting(struct imx_usbmisc_data *data)
> > +{
> > + u32 wakeup_setting = BLKCTL_WAKEUP_SOURCE;
> > +
> > + if (data->ext_id || data->available_role != USB_DR_MODE_OTG)
> > + wakeup_setting &= ~BLKCTL_OTG_ID_WAKEUP_EN;
> > +
> > + if (data->ext_vbus || data->available_role == USB_DR_MODE_HOST)
> > + wakeup_setting &= ~BLKCTL_OTG_VBUS_WAKEUP_EN;
> > +
> > + /* Select session valid as VBUS wakeup source */
> > + wakeup_setting |= BLKCTL_OTG_VBUS_SESSVALID;
> > +
> > + return wakeup_setting;
> > +}
> > +
> > +static int usbmisc_imx95_set_wakeup(struct imx_usbmisc_data *data, bool enabled)
> > +{
> > + struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
> > + unsigned long flags;
> > + u32 val;
> > +
> > + spin_lock_irqsave(&usbmisc->lock, flags);
> > + val = readl(usbmisc->blkctl + BLKCTL_USB_WAKEUP_CTRL);
> > + val &= ~BLKCTL_WAKEUP_SOURCE;
> > +
> > + if (enabled)
> > + val |= usbmisc_blkctl_wakeup_setting(data);
> > +
> > + writel(val, usbmisc->blkctl + BLKCTL_USB_WAKEUP_CTRL);
> > + spin_unlock_irqrestore(&usbmisc->lock, flags);
> > +
> > + return 0;
> > +}
> > +
> > +static int usbmisc_imx95_init(struct imx_usbmisc_data *data)
> > +{
> > + struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
> > + unsigned long flags;
> > + u32 reg;
> > +
> > + if (data->index >= 1)
> > + return -EINVAL;
> > +
> > + spin_lock_irqsave(&usbmisc->lock, flags);
> > + reg = readl(usbmisc->base);
> > +
> > + if (data->disable_oc) {
> > + reg |= MX6_BM_OVER_CUR_DIS;
> > + } else {
> > + reg &= ~MX6_BM_OVER_CUR_DIS;
> > +
> > + if (data->oc_pol_configured && data->oc_pol_active_low)
> > + reg |= MX6_BM_OVER_CUR_POLARITY;
> > + else if (data->oc_pol_configured)
> > + reg &= ~MX6_BM_OVER_CUR_POLARITY;
> > + }
> > +
> > + if (data->pwr_pol == 1)
> > + reg |= MX6_BM_PWR_POLARITY;
> > +
> > + writel(reg, usbmisc->base);
> > + spin_unlock_irqrestore(&usbmisc->lock, flags);
> > +
> > + /* use HSIO blkctl wakeup as source, disable usbmisc setting*/
> > + usbmisc_imx7d_set_wakeup(data, false);
> > +
> > + return 0;
> > +}
>
> Above code has duplicated with some imx7d and imx7ulp init code,
> Is it possible abstract some common code for all these three platforms?
Sure. Thanks for your suggestion. I'll do it.
Thanks,
Xu Yang
^ permalink raw reply
* ✗ i915.CI.BAT: failure for series starting with [i-g-t,1/2] lib/syncobj: Make running under Valgrind quiet
From: Patchwork @ 2025-02-27 6:35 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: igt-dev
In-Reply-To: <20250225124454.1976-1-tvrtko.ursulin@igalia.com>
[-- Attachment #1: Type: text/plain, Size: 4560 bytes --]
== Series Details ==
Series: series starting with [i-g-t,1/2] lib/syncobj: Make running under Valgrind quiet
URL : https://patchwork.freedesktop.org/series/145403/
State : failure
== Summary ==
CI Bug Log - changes from IGT_8249 -> IGTPW_12665
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with IGTPW_12665 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in IGTPW_12665, please notify your bug team (I915-ci-infra@lists.freedesktop.org) to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_12665/index.html
Participating hosts (44 -> 44)
------------------------------
No changes in participating hosts
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in IGTPW_12665:
### IGT changes ###
#### Possible regressions ####
* igt@i915_module_load@load:
- bat-twl-1: [PASS][1] -> [DMESG-WARN][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_8249/bat-twl-1/igt@i915_module_load@load.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_12665/bat-twl-1/igt@i915_module_load@load.html
* igt@i915_selftest@live@reset:
- bat-adlp-11: [PASS][3] -> [ABORT][4]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_8249/bat-adlp-11/igt@i915_selftest@live@reset.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_12665/bat-adlp-11/igt@i915_selftest@live@reset.html
* igt@i915_selftest@live@slpc:
- bat-twl-1: NOTRUN -> [INCOMPLETE][5]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_12665/bat-twl-1/igt@i915_selftest@live@slpc.html
Known issues
------------
Here are the changes found in IGTPW_12665 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_selftest@live:
- bat-adlp-11: [PASS][6] -> [ABORT][7] ([i915#13696])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_8249/bat-adlp-11/igt@i915_selftest@live.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_12665/bat-adlp-11/igt@i915_selftest@live.html
* igt@i915_selftest@live@reset:
- bat-twl-2: [PASS][8] -> [ABORT][9] ([i915#12919] / [i915#13503]) +1 other test abort
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_8249/bat-twl-2/igt@i915_selftest@live@reset.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_12665/bat-twl-2/igt@i915_selftest@live@reset.html
#### Possible fixes ####
* igt@i915_module_load@load:
- bat-mtlp-9: [DMESG-WARN][10] ([i915#13494]) -> [PASS][11]
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_8249/bat-mtlp-9/igt@i915_module_load@load.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_12665/bat-mtlp-9/igt@i915_module_load@load.html
* igt@i915_selftest@live@execlists:
- bat-twl-1: [INCOMPLETE][12] -> [PASS][13]
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_8249/bat-twl-1/igt@i915_selftest@live@execlists.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_12665/bat-twl-1/igt@i915_selftest@live@execlists.html
#### Warnings ####
* igt@i915_selftest@live:
- bat-twl-1: [INCOMPLETE][14] -> [INCOMPLETE][15] ([i915#13761])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_8249/bat-twl-1/igt@i915_selftest@live.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_12665/bat-twl-1/igt@i915_selftest@live.html
[i915#12919]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12919
[i915#13494]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13494
[i915#13503]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13503
[i915#13696]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13696
[i915#13761]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13761
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_8249 -> IGTPW_12665
* Linux: CI_DRM_16189 -> CI_DRM_16190
CI-20190529: 20190529
CI_DRM_16189: 1afde926204e64fbc8e4e98aef49f8c56228bf70 @ git://anongit.freedesktop.org/gfx-ci/linux
CI_DRM_16190: 8541a64154cd8b9c07977dedc1d22883f43279a0 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_12665: 12665
IGT_8249: 8cb34f260a285ff7eaa3d79cf71f0a4960e4c890 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_12665/index.html
[-- Attachment #2: Type: text/html, Size: 5385 bytes --]
^ permalink raw reply
* Re: [PATCH v2] vdpa: Fix endian bugs in shadow virtqueue
From: Michael Tokarev @ 2025-02-27 6:33 UTC (permalink / raw)
To: Konstantin Shkolnyy, eperezma
Cc: mst, sgarzare, mjrosato, qemu-devel, qemu-stable
In-Reply-To: <9cb188a8-2e13-49fe-9104-1e08b1c92964@linux.ibm.com>
25.02.2025 15:39, Konstantin Shkolnyy wrote:
> On 2/25/2025 03:30, Michael Tokarev wrote:
>> This looks like a qemu-stable material.
>> Please let me know if it is not.
>
> It won't help without my other "[PATCH v2] vdpa: Allow vDPA to work on big-endian machine". With both patches, VDPA works on a big-endian machine.
Aha. And it is not in master yet. Thank you for letting me know!
How do you think, is it worth the effort to pick these up for
older stable releases (7.2, 8.2) too?
Thanks,
/mjt
^ permalink raw reply
* Re: [resend v3 00/19] Add Cadence NAND Driver support
From: Michael Nazzareno Trimarchi @ 2025-02-27 6:33 UTC (permalink / raw)
To: dinesh.maniyam
Cc: u-boot, Marek, Simon, Tom Rini, Dario Binacchi, Johan Jonker,
Michal Simek, Arseniy Krasnov, Alexander Dahl, William Zhang,
Igor Prusov, Tingting Meng, Tien Fong, Kok Kiang, Boon Khai, Alif,
Hazim, Jit Loon Lim, Sieu Mun Tang
In-Reply-To: <20250226161833.53689-1-dinesh.maniyam@intel.com>
Hi Dinesh
On Wed, Feb 26, 2025 at 5:18 PM <dinesh.maniyam@intel.com> wrote:
>
> From: Dinesh Maniyam <dinesh.maniyam@intel.com>
>
> This patchset add Cadence NAND driver support for
> Intel Agilex5 devices.
>
> The NAND driver is leveraged from the cadence-nand-controller.c
> from Linux version 6.11.2. U-Boot will support read, write and erase
> NAND with Cadence driver. The driver further enhanced in U-Boot
> to support NAND booting from FSBL and support boot to kernel
> via UBIFS.
>
I have just applied on top of master and they are not applied clean. I
can fix these conflicts by myself this conflicts, but I would
like that when you apply patches you fix warnings like trailing space.
Applying: dt: nand: add cadence nand dt-bindings
Applying: arm: dts: agilex5: Enabled cdns-nand dts setting
Applying: drivers: mtd: nand: Add driver for Cadence Nand
Applying: drivers: mtd: nand: cadence: Add support for read status command
Applying: drivers: mtd: nand: cadence: Add support for readid command
Applying: drivers: mtd: nand: cadence: Add support for NAND_CMD_PARAM
Applying: drivers: mtd: nand: cadence: Add support for NAND_CMD_RESET
Applying: drivers: mtd: nand: cadence: Support cmd SET_FEATURES & GET_FEATURES
Applying: drivers: mtd: nand: cadence: Flush & invalidate dma descriptor
Applying: drivers: mtd: nand: cadence: Poll for desc complete status
Applying: drivers: mtd: nand: cadence: Use bounce buffer
Applying: drivers: nand: Enabled Kconfig and Makefile for cdns-nand
Applying: configs: nand2_defconfig: Enable configs for nand boot
Applying: drivers: mtd: nand: base: Add support for Hardware ECC for
check bad block
Applying: drivers: mtd: nand: spl: Add support for nand SPL load image
.git/rebase-apply/patch:19: trailing whitespace.
* Copyright (C) 2024 Intel Corporation <www.intel.com>
warning: 1 line adds whitespace errors.
Apart of that
pplying: drivers: mtd: nand: Enabled Kconfig and Makefile for SPL_NAND_FRAMEWORK
error: patch failed: drivers/mtd/nand/raw/Makefile:3
error: drivers/mtd/nand/raw/Makefile: patch does not apply
Patch failed at 0017 drivers: mtd: nand: Enabled Kconfig and Makefile
for SPL_NAND_FRAMEWORK
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
I will review the rest
Michael
> Patch status:
> Have changes: All patches expect Patch 19
>
> Detail changelog can find in commit message.
>
> v1->v2:
> --------
> Patch 1 - 18:
>
> - remove the "this patch is to" commit phrases
>
> Patch 4;
> - minor refactoring of code to match the stable version 6.11.2.
>
> Patch 14:
> - Add maintainer and "#include" mechanism for new variant
>
> Patch 16:
> - leverage the existing nand_spl_load_image
>
> v2->v3:
> --------
> Patch: arm: dts: agilex5: Enabled cdns-nand dts setting
> - Move &nand from uboot.dtsi to socdk.dts
>
> Patch: include: asm: Add support to read/write 64-bit
> - Dropped because redefinition of readsq & writesq
>
> Patch: drivers: mtd: nand: Add driver for Cadence Nand
> - Remove redundant clk_free func
>
> Patch: drivers: mtd: nand: Enabled Kconfig and Makefile for SPL_NAND_FRAMEWORK
> - New
>
> Patch: drivers: mtd: nand: Kconfig: Add SYS_NAND_PAGE_SIZE dependency
> - New
>
> Patch: configs: nand2_defconfig: Enable configs for nand boot
> - Remove CONFIG_OF_UPSTREAM in order to get correct dts for compilation
>
> Patch: drivers: mtd: nand: base: Add support for Hardware ECC for check bad block
> - Remove copyright
>
> Patch: drivers: mtd: nand: Kconfig: Remove SYS_NAND_BLOCK_SIZE dependency
> - Dropped because SPL NAND have dependency with SYS_NAND_BLOCK_SIZE
>
> History:
> --------
> [v1]: https://patchwork.ozlabs.org/project/uboot/cover/20240919035512.13854-1-dinesh.maniyam@intel.com/
> [v2]: https://patchwork.ozlabs.org/project/uboot/cover/20241205092315.25060-1-dinesh.maniyam@intel.com/
>
> Dinesh Maniyam (19):
> dt: nand: add cadence nand dt-bindings
> arm: dts: agilex5: Enabled cdns-nand dts setting
> drivers: mtd: nand: Add driver for Cadence Nand
> drivers: mtd: nand: cadence: Add support for read status command
> drivers: mtd: nand: cadence: Add support for readid command
> drivers: mtd: nand: cadence: Add support for NAND_CMD_PARAM
> drivers: mtd: nand: cadence: Add support for NAND_CMD_RESET
> drivers: mtd: nand: cadence: Support cmd SET_FEATURES & GET_FEATURES
> drivers: mtd: nand: cadence: Flush & invalidate dma descriptor
> drivers: mtd: nand: cadence: Poll for desc complete status
> drivers: mtd: nand: cadence: Use bounce buffer
> drivers: nand: Enabled Kconfig and Makefile for cdns-nand
> configs: nand2_defconfig: Enable configs for nand boot
> drivers: mtd: nand: base: Add support for Hardware ECC for check bad
> block
> drivers: mtd: nand: spl: Add support for nand SPL load image
> drivers: mtd: nand: Enabled Kconfig and Makefile for Cadence-SPL
> drivers: mtd: nand: Enabled Kconfig and Makefile for
> SPL_NAND_FRAMEWORK
> drivers: mtd: nand: Kconfig: Add SYS_NAND_PAGE_SIZE dependency
> drivers: mtd: nand: Kconfig: Enabled self-init for cdns-nand SPL
>
> arch/arm/dts/socfpga_agilex5.dtsi | 14 +
> .../arm/dts/socfpga_agilex5_socdk-u-boot.dtsi | 9 +-
> arch/arm/dts/socfpga_agilex5_socdk.dts | 19 +
> board/intel/agilex5-socdk/MAINTAINERS | 2 +
> configs/socfpga_agilex5_nand2_defconfig | 32 +
> .../mtd/cadence,nand.yaml | 98 +
> drivers/mtd/nand/raw/Kconfig | 26 +-
> drivers/mtd/nand/raw/Makefile | 12 +
> drivers/mtd/nand/raw/cadence_nand.c | 2423 +++++++++++++++++
> drivers/mtd/nand/raw/cadence_spl.c | 59 +
> drivers/mtd/nand/raw/nand_base.c | 69 +-
> include/cadence-nand.h | 529 ++++
> include/linux/mtd/rawnand.h | 12 +
> 13 files changed, 3278 insertions(+), 26 deletions(-)
> create mode 100644 configs/socfpga_agilex5_nand2_defconfig
> create mode 100644 doc/device-tree-bindings/mtd/cadence,nand.yaml
> create mode 100644 drivers/mtd/nand/raw/cadence_nand.c
> create mode 100644 drivers/mtd/nand/raw/cadence_spl.c
> create mode 100644 include/cadence-nand.h
>
> --
> 2.19.0
>
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
__________________________________
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@amarulasolutions.com
www.amarulasolutions.com
^ permalink raw reply
* Re: [PATCH] crypto: lib/Kconfig - Select and hide arch options
From: kernel test robot @ 2025-02-27 6:29 UTC (permalink / raw)
To: Herbert Xu, Arnd Bergmann
Cc: llvm, oe-kbuild-all, Will Deacon, David S . Miller,
Catalin Marinas, Thomas Bogendoerfer, Harald Freudenberger,
Holger Dengler, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Martin K. Petersen,
Ard Biesheuvel, Eric Biggers, James E . J . Bottomley,
Jarkko Sakkinen, linux-crypto, linux-arm-kernel, linux-kernel,
linux-mips, linux-s390
In-Reply-To: <Z76aUfPIbhPAsHbv@gondor.apana.org.au>
Hi Herbert,
kernel test robot noticed the following build errors:
[auto build test ERROR on herbert-cryptodev-2.6/master]
[cannot apply to soc/for-next linus/master v6.14-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Herbert-Xu/crypto-lib-Kconfig-Select-and-hide-arch-options/20250226-125220
base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
patch link: https://lore.kernel.org/r/Z76aUfPIbhPAsHbv%40gondor.apana.org.au
patch subject: [PATCH] crypto: lib/Kconfig - Select and hide arch options
config: x86_64-buildonly-randconfig-002-20250227 (https://download.01.org/0day-ci/archive/20250227/202502271449.k2LZdEgF-lkp@intel.com/config)
compiler: clang version 19.1.7 (https://github.com/llvm/llvm-project cd708029e0b2869e80abe31ddb175f7c35361f90)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250227/202502271449.k2LZdEgF-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202502271449.k2LZdEgF-lkp@intel.com/
All errors (new ones prefixed by >>, old ones prefixed by <<):
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/fpga/tests/fpga-mgr-test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/fpga/tests/fpga-bridge-test.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/fpga/tests/fpga-region-test.o
>> ERROR: modpost: "curve25519_generic" [arch/x86/crypto/curve25519-x86_64.ko] undefined!
>> ERROR: modpost: "curve25519_base_point" [arch/x86/crypto/curve25519-x86_64.ko] undefined!
>> ERROR: modpost: "curve25519_null_point" [arch/x86/crypto/curve25519-x86_64.ko] undefined!
>> ERROR: modpost: "curve25519_null_point" [lib/crypto/libcurve25519.ko] undefined!
>> ERROR: modpost: "curve25519_generic" [lib/crypto/libcurve25519.ko] undefined!
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 4/5] printk: Rename console_start to console_resume
From: Jiri Slaby @ 2025-02-27 6:30 UTC (permalink / raw)
To: Marcos Paulo de Souza, Greg Kroah-Hartman, Eric Biederman,
Rafael J. Wysocki, Len Brown, Pavel Machek, Petr Mladek,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Todd E Brandt
Cc: linux-kernel, kexec, linux-pm, linux-serial
In-Reply-To: <20250226-printk-renaming-v1-4-0b878577f2e6@suse.com>
On 26. 02. 25, 20:59, Marcos Paulo de Souza wrote:
> The intent of console_start was to resume a previosly suspended console,
> so rename it accordly.
FWIW no objections re code change. Except "previosly" here and
"accordly" in 1-4 :D. (In case you resend.)
thanks,
--
js
suse labs
^ permalink raw reply
* [PATCH v4] lib/vsprintf: Add support for generic FOURCCs by extending %p4cc
From: Aditya Garg @ 2025-02-27 6:30 UTC (permalink / raw)
To: pmladek@suse.com, Steven Rostedt,
andriy.shevchenko@linux.intel.com, Rasmus Villemoes,
senozhatsky@chromium.org, corbet@lwn.net,
akpm@linux-foundation.org, apw@canonical.com, joe@perches.com,
dwaipayanray1@gmail.com, lukas.bulwahn@gmail.com
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Hector Martin, sven@svenpeter.dev, Janne Grunau,
alyssa@rosenzweig.io, Asahi Linux Mailing List
From: Hector Martin <marcan@marcan.st>
%p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but
it's useful to be able to print generic 4-character codes formatted as
an integer. Extend it to add format specifiers for printing generic
32-bit FOURCCs with various endian semantics:
%p4ch Host-endian
%p4cl Little-endian
%p4cb Big-endian
%p4cr Reverse-endian
The endianness determines how bytes are interpreted as a u32, and the
FOURCC is then always printed MSByte-first (this is the opposite of
V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would
allow printing LSByte-first FOURCCs stored in host endian order
(other than the hex form being in character order, not the integer
value).
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Aditya Garg <gargaditya08@live.com>
---
v2 ->
- Add this patch to appletbdrm patchset
v3 ->
- Make array static
v4 ->
- Fix code error
- Fix sparse warnings
- Make this patch separate from drm
Documentation/core-api/printk-formats.rst | 32 +++++++++++++++++++
lib/test_printf.c | 39 +++++++++++++++++++----
lib/vsprintf.c | 38 ++++++++++++++++++----
scripts/checkpatch.pl | 2 +-
4 files changed, 97 insertions(+), 14 deletions(-)
diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
index ecccc0473..9982861fa 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -648,6 +648,38 @@ Examples::
%p4cc Y10 little-endian (0x20303159)
%p4cc NV12 big-endian (0xb231564e)
+Generic FourCC code
+-------------------
+
+::
+ %p4c[hrbl] gP00 (0x67503030)
+
+Print a generic FourCC code, as both ASCII characters and its numerical
+value as hexadecimal.
+
+The additional ``h``, ``r``, ``b``, and ``l`` specifiers are used to specify
+host, reversed, big or little endian order data respectively. Host endian
+order means the data is interpreted as a 32-bit integer and the most
+significant byte is printed first; that is, the character code as printed
+matches the byte order stored in memory on big-endian systems, and is reversed
+on little-endian systems.
+
+Passed by reference.
+
+Examples for a little-endian machine, given &(u32)0x67503030::
+
+ %p4ch gP00 (0x67503030)
+ %p4cr 00Pg (0x30305067)
+ %p4cb 00Pg (0x30305067)
+ %p4cl gP00 (0x67503030)
+
+Examples for a big-endian machine, given &(u32)0x67503030::
+
+ %p4ch gP00 (0x67503030)
+ %p4cr 00Pg (0x30305067)
+ %p4cb gP00 (0x67503030)
+ %p4cl 00Pg (0x30305067)
+
Rust
----
diff --git a/lib/test_printf.c b/lib/test_printf.c
index 59dbe4f9a..056929c06 100644
--- a/lib/test_printf.c
+++ b/lib/test_printf.c
@@ -776,21 +776,46 @@ static void __init fwnode_pointer(void)
software_node_unregister_node_group(group);
}
+struct fourcc_struct {
+ u32 code;
+ const char *str;
+};
+
+static void __init fourcc_pointer_test(const struct fourcc_struct *fc, size_t n,
+ const char *fmt)
+{
+ size_t i;
+
+ for (i = 0; i < n; i++)
+ test(fc[i].str, fmt, &fc[i].code);
+}
+
static void __init fourcc_pointer(void)
{
- struct {
- u32 code;
- char *str;
- } const try[] = {
+ static const struct fourcc_struct try_cc[] = {
{ 0x3231564e, "NV12 little-endian (0x3231564e)", },
{ 0xb231564e, "NV12 big-endian (0xb231564e)", },
{ 0x10111213, ".... little-endian (0x10111213)", },
{ 0x20303159, "Y10 little-endian (0x20303159)", },
};
- unsigned int i;
+ static const struct fourcc_struct try_ch = {
+ 0x41424344, "ABCD (0x41424344)",
+ };
+ static const struct fourcc_struct try_cr = {
+ 0x41424344, "DCBA (0x44434241)",
+ };
+ static const struct fourcc_struct try_cl = {
+ le32_to_cpu(0x41424344), "ABCD (0x41424344)",
+ };
+ static const struct fourcc_struct try_cb = {
+ be32_to_cpu(0x41424344), "ABCD (0x41424344)",
+ };
- for (i = 0; i < ARRAY_SIZE(try); i++)
- test(try[i].str, "%p4cc", &try[i].code);
+ fourcc_pointer_test(try_cc, ARRAY_SIZE(try_cc), "%p4cc");
+ fourcc_pointer_test(&try_ch, 1, "%p4ch");
+ fourcc_pointer_test(&try_cr, 1, "%p4cr");
+ fourcc_pointer_test(&try_cl, 1, "%p4cl");
+ fourcc_pointer_test(&try_cb, 1, "%p4cb");
}
static void __init
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 56fe96319..2ac90aba2 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1781,27 +1781,53 @@ char *fourcc_string(char *buf, char *end, const u32 *fourcc,
char output[sizeof("0123 little-endian (0x01234567)")];
char *p = output;
unsigned int i;
+ bool pixel_fmt = false;
u32 orig, val;
- if (fmt[1] != 'c' || fmt[2] != 'c')
+ if (fmt[1] != 'c')
return error_string(buf, end, "(%p4?)", spec);
if (check_pointer(&buf, end, fourcc, spec))
return buf;
orig = get_unaligned(fourcc);
- val = orig & ~BIT(31);
+ switch (fmt[2]) {
+ case 'h':
+ val = orig;
+ break;
+ case 'r':
+ orig = swab32(orig);
+ val = orig;
+ break;
+ case 'l':
+ orig = (__force u32)cpu_to_le32(orig);
+ val = orig;
+ break;
+ case 'b':
+ orig = (__force u32)cpu_to_be32(orig);
+ val = orig;
+ break;
+ case 'c':
+ /* Pixel formats are printed LSB-first */
+ val = swab32(orig & ~BIT(31));
+ pixel_fmt = true;
+ break;
+ default:
+ return error_string(buf, end, "(%p4?)", spec);
+ }
for (i = 0; i < sizeof(u32); i++) {
- unsigned char c = val >> (i * 8);
+ unsigned char c = val >> ((3 - i) * 8);
/* Print non-control ASCII characters as-is, dot otherwise */
*p++ = isascii(c) && isprint(c) ? c : '.';
}
- *p++ = ' ';
- strcpy(p, orig & BIT(31) ? "big-endian" : "little-endian");
- p += strlen(p);
+ if (pixel_fmt) {
+ *p++ = ' ';
+ strcpy(p, orig & BIT(31) ? "big-endian" : "little-endian");
+ p += strlen(p);
+ }
*p++ = ' ';
*p++ = '(';
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 7b28ad331..21516f753 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6904,7 +6904,7 @@ sub process {
($extension eq "f" &&
defined $qualifier && $qualifier !~ /^w/) ||
($extension eq "4" &&
- defined $qualifier && $qualifier !~ /^cc/)) {
+ defined $qualifier && $qualifier !~ /^c[chlbr]/)) {
$bad_specifier = $specifier;
last;
}
--
2.43.0
^ permalink raw reply related
* Re: [Patch v2 15/24] perf/x86/intel: Add SSP register support for arch-PEBS
From: Mi, Dapeng @ 2025-02-27 6:29 UTC (permalink / raw)
To: Andi Kleen, Peter Zijlstra
Cc: Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Ian Rogers,
Adrian Hunter, Alexander Shishkin, Kan Liang, Eranian Stephane,
linux-kernel, linux-perf-users, Dapeng Mi
In-Reply-To: <Z74rqf5V6bfTZxhG@tassilo>
On 2/26/2025 4:44 AM, Andi Kleen wrote:
> On Tue, Feb 25, 2025 at 12:54:50PM +0100, Peter Zijlstra wrote:
>> On Tue, Feb 18, 2025 at 03:28:09PM +0000, Dapeng Mi wrote:
>>
>>> @@ -651,6 +651,16 @@ int x86_pmu_hw_config(struct perf_event *event)
>>> return -EINVAL;
>>> }
>>>
>>> + /* sample_regs_user never support SSP register. */
>>> + if (unlikely(event->attr.sample_regs_user & BIT_ULL(PERF_REG_X86_SSP)))
>>> + return -EINVAL;
>> We can easily enough read user SSP, no?
> Not for multi record PEBS.
>
> Also technically it may not be precise.
Yes, If need to support to capture user space SSP, then PEBS has to fall
back to only capture single record.
Andi, you said "it may not be precise", could you please give more details?
I didn't get this. Thanks.
>
> -andi
>
^ permalink raw reply
* [Xenomai 3] recvmmsg is broken when using timeouts
From: Jan Kiszka @ 2025-02-27 6:29 UTC (permalink / raw)
To: Xenomai; +Cc: Philippe Gerum
Quick heads up, but I suspect only few are affected in practice:
The implementation of recvmmsg in Xenomai 3 is broken since day #1
regarding timeouts. The internal timeout handler
recvmmsg_timeout_handler races with the xnthread_suspend calls in the
actual recvmsg handlers regarding setting / clearing XNTIMEO. I don't
see a quick fix yet, will likely require some more deeper extension of
the cobalt core to support such a timeout across multiple
xnthread_suspend calls.
The issue can be easily reproduced by running smokey's y2038 test in
qemu while the host machine is overloaded. The test will eventually get
stuck in recvmmsg64.
Jan
--
Siemens AG, Foundational Technologies
Linux Expert Center
^ permalink raw reply
* Re: [PATCH v4 5/6] commands/ls: Print full paths for file args
From: Glenn Washburn @ 2025-02-27 6:28 UTC (permalink / raw)
To: Daniel Kiper; +Cc: grub-devel, Vladimir Serbinenko
In-Reply-To: <20250224171459.qublm3dahydsdehp@tomti.i.net-space.pl>
On Mon, 24 Feb 2025 18:14:59 +0100
Daniel Kiper <dkiper@net-space.pl> wrote:
> On Mon, Jan 06, 2025 at 01:02:43AM -0600, Glenn Washburn wrote:
> > For arguments that are paths to files, print the full path of the file.
> >
> > Signed-off-by: Glenn Washburn <development@efficientek.com>
> > ---
> > grub-core/commands/ls.c | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/grub-core/commands/ls.c b/grub-core/commands/ls.c
> > index e33c16158d63..384d3e3cede8 100644
> > --- a/grub-core/commands/ls.c
> > +++ b/grub-core/commands/ls.c
> > @@ -98,6 +98,7 @@ static int
> > print_file (const char *filename, const struct grub_dirhook_info *info,
> > void *data)
> > {
> > + char *pathname = NULL;
> > struct grub_ls_list_files_ctx *ctx = data;
> >
> > if ((! ctx->all) && (filename[0] == '.'))
> > @@ -117,7 +118,6 @@ print_file (const char *filename, const struct grub_dirhook_info *info,
> > if (! info->dir)
> > {
> > grub_file_t file;
> > - char *pathname;
> >
> > if (ctx->dirname[grub_strlen (ctx->dirname) - 1] == '/')
> > pathname = grub_xasprintf ("%s%s", ctx->dirname, filename);
> > @@ -143,7 +143,6 @@ print_file (const char *filename, const struct grub_dirhook_info *info,
> > else
> > grub_xputs ("????????????");
> >
> > - grub_free (pathname);
> > grub_errno = GRUB_ERR_NONE;
> > }
> > else
> > @@ -165,7 +164,10 @@ print_file (const char *filename, const struct grub_dirhook_info *info,
> > datetime.day, datetime.hour,
> > datetime.minute, datetime.second);
> > }
> > - grub_printf ("%s%s\n", filename, info->dir ? "/" : "");
> > + grub_printf ("%s%s\n", (ctx->filename) ? pathname : filename,
>
> "(pathname != NULL) ? pathname : filename" would not be more natural/correct?
I think this is equivalent. Yes, this does seem more intuitive. Do you
want me to update and send a v5?
Glenn
>
> Otherwise patches LGTM...
>
> Daniel
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
^ permalink raw reply
* Re: [PATCH] x86/crc32: use builtins to improve code generation
From: Eric Biggers @ 2025-02-27 6:28 UTC (permalink / raw)
To: Bill Wendling
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), H. Peter Anvin,
Ard Biesheuvel, Nathan Chancellor, Nick Desaulniers, Justin Stitt,
LKML, linux-crypto, clang-built-linux
In-Reply-To: <CAGG=3QVi27WRYVxmsk9+HLpJw9ZJrpfLjU8G4exuXm-vUA-KqQ@mail.gmail.com>
On Wed, Feb 26, 2025 at 10:12:47PM -0800, Bill Wendling wrote:
> For both gcc and clang, crc32 builtins generate better code than the
> inline asm. GCC improves, removing unneeded "mov" instructions. Clang
> does the same and unrolls the loops. GCC has no changes on i386, but
> Clang's code generation is vastly improved, due to Clang's "rm"
> constraint issue.
>
> The number of cycles improved by ~0.1% for GCC and ~1% for Clang, which
> is expected because of the "rm" issue. However, Clang's performance is
> better than GCC's by ~1.5%, most likely due to loop unrolling.
>
> Link: https://github.com/llvm/llvm-project/issues/20571#issuecomment-2649330009
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: x86@kernel.org
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Eric Biggers <ebiggers@kernel.org>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
> Cc: Justin Stitt <justinstitt@google.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: llvm@lists.linux.dev
> Signed-off-by: Bill Wendling <morbo@google.com>
> ---
> arch/x86/Makefile | 3 +++
> arch/x86/lib/crc32-glue.c | 8 ++++----
> 2 files changed, 7 insertions(+), 4 deletions(-)
Thanks! A couple concerns, though:
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 5b773b34768d..241436da1473 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -114,6 +114,9 @@ else
> KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
> endif
>
> +# Enables the use of CRC32 builtins.
> +KBUILD_CFLAGS += -mcrc32
Doesn't this technically allow the compiler to insert CRC32 instructions
anywhere in arch/x86/ without the needed runtime CPU feature check? Normally
when using intrinsics it's necessary to limit the scope of the feature
enablement to match the runtime CPU feature check that is done, e.g. by using
the target function attribute.
> diff --git a/arch/x86/lib/crc32-glue.c b/arch/x86/lib/crc32-glue.c
> index 2dd18a886ded..fdb94bff25f4 100644
> --- a/arch/x86/lib/crc32-glue.c
> +++ b/arch/x86/lib/crc32-glue.c
> @@ -48,9 +48,9 @@ u32 crc32_le_arch(u32 crc, const u8 *p, size_t len)
> EXPORT_SYMBOL(crc32_le_arch);
>
> #ifdef CONFIG_X86_64
> -#define CRC32_INST "crc32q %1, %q0"
> +#define CRC32_INST __builtin_ia32_crc32di
> #else
> -#define CRC32_INST "crc32l %1, %0"
> +#define CRC32_INST __builtin_ia32_crc32si
> #endif
Do both gcc and clang consider these builtins to be a stable API, or do they
only guarantee the stability of _mm_crc32_*() from immintrin.h? At least for
the rest of the SSE and AVX stuff, I thought that only the immintrin.h functions
are actually considered stable.
- Eric
^ permalink raw reply
* [meta-oe][PATCH] thin-provisioning-tools: Upgrade to 1.1.0
From: Khem Raj @ 2025-02-27 6:25 UTC (permalink / raw)
To: openembedded-devel; +Cc: Khem Raj
Specify BINDGEN_EXTRA_CLANG_ARGS to pass correct cflags to bindgen during
cross compile
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
.../thin-provisioning-tools-crates.inc | 38 ++++++++++---------
...14.bb => thin-provisioning-tools_1.1.0.bb} | 7 ++--
2 files changed, 24 insertions(+), 21 deletions(-)
rename meta-oe/dynamic-layers/clang-layer/recipes-support/thin-provisioning-tools/{thin-provisioning-tools_1.0.14.bb => thin-provisioning-tools_1.1.0.bb} (88%)
diff --git a/meta-oe/dynamic-layers/clang-layer/recipes-support/thin-provisioning-tools/thin-provisioning-tools-crates.inc b/meta-oe/dynamic-layers/clang-layer/recipes-support/thin-provisioning-tools/thin-provisioning-tools-crates.inc
index a49704fe21..65dda50739 100644
--- a/meta-oe/dynamic-layers/clang-layer/recipes-support/thin-provisioning-tools/thin-provisioning-tools-crates.inc
+++ b/meta-oe/dynamic-layers/clang-layer/recipes-support/thin-provisioning-tools/thin-provisioning-tools-crates.inc
@@ -16,15 +16,15 @@ SRC_URI += " \
crate://crates.io/bindgen/0.69.4 \
crate://crates.io/bitflags/1.3.2 \
crate://crates.io/bitflags/2.6.0 \
- crate://crates.io/bytemuck/1.16.1 \
+ crate://crates.io/bytemuck/1.16.3 \
crate://crates.io/byteorder/1.5.0 \
crate://crates.io/cassowary/0.3.0 \
crate://crates.io/cexpr/0.6.0 \
crate://crates.io/cfg-if/1.0.0 \
crate://crates.io/cfg_aliases/0.2.1 \
crate://crates.io/clang-sys/1.8.1 \
- crate://crates.io/clap/4.5.11 \
- crate://crates.io/clap_builder/4.5.11 \
+ crate://crates.io/clap/4.5.13 \
+ crate://crates.io/clap_builder/4.5.13 \
crate://crates.io/clap_lex/0.7.2 \
crate://crates.io/colorchoice/1.0.2 \
crate://crates.io/console/0.15.8 \
@@ -44,7 +44,7 @@ SRC_URI += " \
crate://crates.io/exitcode/1.1.2 \
crate://crates.io/fastrand/2.1.0 \
crate://crates.io/fixedbitset/0.4.2 \
- crate://crates.io/flate2/1.0.30 \
+ crate://crates.io/flate2/1.0.31 \
crate://crates.io/fragile/2.0.0 \
crate://crates.io/getrandom/0.2.15 \
crate://crates.io/glob/0.3.1 \
@@ -76,10 +76,10 @@ SRC_URI += " \
crate://crates.io/number_prefix/0.4.0 \
crate://crates.io/numtoa/0.1.0 \
crate://crates.io/once_cell/1.19.0 \
- crate://crates.io/os_pipe/1.2.0 \
+ crate://crates.io/os_pipe/1.2.1 \
crate://crates.io/pkg-config/0.3.30 \
crate://crates.io/portable-atomic/1.7.0 \
- crate://crates.io/ppv-lite86/0.2.19 \
+ crate://crates.io/ppv-lite86/0.2.20 \
crate://crates.io/predicates/3.1.2 \
crate://crates.io/predicates-core/1.0.8 \
crate://crates.io/predicates-tree/1.0.11 \
@@ -94,7 +94,7 @@ SRC_URI += " \
crate://crates.io/rangemap/1.5.1 \
crate://crates.io/redox_syscall/0.2.16 \
crate://crates.io/redox_termios/0.1.3 \
- crate://crates.io/regex/1.10.5 \
+ crate://crates.io/regex/1.10.6 \
crate://crates.io/regex-automata/0.4.7 \
crate://crates.io/regex-syntax/0.8.4 \
crate://crates.io/retry/2.0.0 \
@@ -106,12 +106,12 @@ SRC_URI += " \
crate://crates.io/semver/1.0.23 \
crate://crates.io/serde/1.0.204 \
crate://crates.io/serde_derive/1.0.204 \
- crate://crates.io/shared_child/1.0.0 \
+ crate://crates.io/shared_child/1.0.1 \
crate://crates.io/shlex/1.3.0 \
crate://crates.io/strsim/0.11.1 \
crate://crates.io/syn/1.0.109 \
crate://crates.io/syn/2.0.72 \
- crate://crates.io/tempfile/3.10.1 \
+ crate://crates.io/tempfile/3.11.0 \
crate://crates.io/termion/1.5.6 \
crate://crates.io/termtree/0.4.1 \
crate://crates.io/thiserror/1.0.63 \
@@ -128,6 +128,7 @@ SRC_URI += " \
crate://crates.io/winapi-i686-pc-windows-gnu/0.4.0 \
crate://crates.io/winapi-x86_64-pc-windows-gnu/0.4.0 \
crate://crates.io/windows-sys/0.52.0 \
+ crate://crates.io/windows-sys/0.59.0 \
crate://crates.io/windows-targets/0.52.6 \
crate://crates.io/windows_aarch64_gnullvm/0.52.6 \
crate://crates.io/windows_aarch64_msvc/0.52.6 \
@@ -155,15 +156,15 @@ SRC_URI[base64-0.22.1.sha256sum] = "72b3254f16251a8381aa12e40e3c4d2f0199f8c6508f
SRC_URI[bindgen-0.69.4.sha256sum] = "a00dc851838a2120612785d195287475a3ac45514741da670b735818822129a0"
SRC_URI[bitflags-1.3.2.sha256sum] = "bef38d45163c2f1dde094a7dfd33ccf595c92905c8f8f4fdc18d06fb1037718a"
SRC_URI[bitflags-2.6.0.sha256sum] = "b048fb63fd8b5923fc5aa7b340d8e156aec7ec02f0c78fa8a6ddc2613f6f71de"
-SRC_URI[bytemuck-1.16.1.sha256sum] = "b236fc92302c97ed75b38da1f4917b5cdda4984745740f153a5d3059e48d725e"
+SRC_URI[bytemuck-1.16.3.sha256sum] = "102087e286b4677862ea56cf8fc58bb2cdfa8725c40ffb80fe3a008eb7f2fc83"
SRC_URI[byteorder-1.5.0.sha256sum] = "1fd0f2584146f6f2ef48085050886acf353beff7305ebd1ae69500e27c67f64b"
SRC_URI[cassowary-0.3.0.sha256sum] = "df8670b8c7b9dae1793364eafadf7239c40d669904660c5960d74cfd80b46a53"
SRC_URI[cexpr-0.6.0.sha256sum] = "6fac387a98bb7c37292057cffc56d62ecb629900026402633ae9160df93a8766"
SRC_URI[cfg-if-1.0.0.sha256sum] = "baf1de4339761588bc0619e3cbc0120ee582ebb74b53b4efbf79117bd2da40fd"
SRC_URI[cfg_aliases-0.2.1.sha256sum] = "613afe47fcd5fac7ccf1db93babcb082c5994d996f20b8b159f2ad1658eb5724"
SRC_URI[clang-sys-1.8.1.sha256sum] = "0b023947811758c97c59bf9d1c188fd619ad4718dcaa767947df1cadb14f39f4"
-SRC_URI[clap-4.5.11.sha256sum] = "35723e6a11662c2afb578bcf0b88bf6ea8e21282a953428f240574fcc3a2b5b3"
-SRC_URI[clap_builder-4.5.11.sha256sum] = "49eb96cbfa7cfa35017b7cd548c75b14c3118c98b423041d70562665e07fb0fa"
+SRC_URI[clap-4.5.13.sha256sum] = "0fbb260a053428790f3de475e304ff84cdbc4face759ea7a3e64c1edd938a7fc"
+SRC_URI[clap_builder-4.5.13.sha256sum] = "64b17d7ea74e9f833c7dbf2cbe4fb12ff26783eda4782a8975b72f895c9b4d99"
SRC_URI[clap_lex-0.7.2.sha256sum] = "1462739cb27611015575c0c11df5df7601141071f07518d56fcc1be504cbec97"
SRC_URI[colorchoice-1.0.2.sha256sum] = "d3fd119d74b830634cea2a0f58bbd0d54540518a14397557951e79340abc28c0"
SRC_URI[console-0.15.8.sha256sum] = "0e1f83fc076bd6dd27517eacdf25fef6c4dfe5f1d7448bafaaf3a26f13b5e4eb"
@@ -183,7 +184,7 @@ SRC_URI[errno-0.3.9.sha256sum] = "534c5cf6194dfab3db3242765c03bbe257cf92f22b38f6
SRC_URI[exitcode-1.1.2.sha256sum] = "de853764b47027c2e862a995c34978ffa63c1501f2e15f987ba11bd4f9bba193"
SRC_URI[fastrand-2.1.0.sha256sum] = "9fc0510504f03c51ada170672ac806f1f105a88aa97a5281117e1ddc3368e51a"
SRC_URI[fixedbitset-0.4.2.sha256sum] = "0ce7134b9999ecaf8bcd65542e436736ef32ddca1b3e06094cb6ec5755203b80"
-SRC_URI[flate2-1.0.30.sha256sum] = "5f54427cfd1c7829e2a139fcefea601bf088ebca651d2bf53ebc600eac295dae"
+SRC_URI[flate2-1.0.31.sha256sum] = "7f211bbe8e69bbd0cfdea405084f128ae8b4aaa6b0b522fc8f2b009084797920"
SRC_URI[fragile-2.0.0.sha256sum] = "6c2141d6d6c8512188a7891b4b01590a45f6dac67afb4f255c4124dbb86d4eaa"
SRC_URI[getrandom-0.2.15.sha256sum] = "c4567c8db10ae91089c99af84c68c38da3ec2f087c3f82960bcdbf3656b6f4d7"
SRC_URI[glob-0.3.1.sha256sum] = "d2fabcfbdc87f4758337ca535fb41a6d701b65693ce38287d856d1674551ec9b"
@@ -215,10 +216,10 @@ SRC_URI[num_cpus-1.16.0.sha256sum] = "4161fcb6d602d4d2081af7c3a45852d875a03dd337
SRC_URI[number_prefix-0.4.0.sha256sum] = "830b246a0e5f20af87141b25c173cd1b609bd7779a4617d6ec582abaf90870f3"
SRC_URI[numtoa-0.1.0.sha256sum] = "b8f8bdf33df195859076e54ab11ee78a1b208382d3a26ec40d142ffc1ecc49ef"
SRC_URI[once_cell-1.19.0.sha256sum] = "3fdb12b2476b595f9358c5161aa467c2438859caa136dec86c26fdd2efe17b92"
-SRC_URI[os_pipe-1.2.0.sha256sum] = "29d73ba8daf8fac13b0501d1abeddcfe21ba7401ada61a819144b6c2a4f32209"
+SRC_URI[os_pipe-1.2.1.sha256sum] = "5ffd2b0a5634335b135d5728d84c5e0fd726954b87111f7506a61c502280d982"
SRC_URI[pkg-config-0.3.30.sha256sum] = "d231b230927b5e4ad203db57bbcbee2802f6bce620b1e4a9024a07d94e2907ec"
SRC_URI[portable-atomic-1.7.0.sha256sum] = "da544ee218f0d287a911e9c99a39a8c9bc8fcad3cb8db5959940044ecfc67265"
-SRC_URI[ppv-lite86-0.2.19.sha256sum] = "2288c0e17cc8d342c712bb43a257a80ebffce59cdb33d5000d8348f3ec02528b"
+SRC_URI[ppv-lite86-0.2.20.sha256sum] = "77957b295656769bb8ad2b6a6b09d897d94f05c41b069aede1fcdaa675eaea04"
SRC_URI[predicates-3.1.2.sha256sum] = "7e9086cc7640c29a356d1a29fd134380bee9d8f79a17410aa76e7ad295f42c97"
SRC_URI[predicates-core-1.0.8.sha256sum] = "ae8177bee8e75d6846599c6b9ff679ed51e882816914eec639944d7c9aa11931"
SRC_URI[predicates-tree-1.0.11.sha256sum] = "41b740d195ed3166cd147c8047ec98db0e22ec019eb8eeb76d343b795304fb13"
@@ -233,7 +234,7 @@ SRC_URI[rand_core-0.6.4.sha256sum] = "ec0be4795e2f6a28069bec0b5ff3e2ac9bafc99e6a
SRC_URI[rangemap-1.5.1.sha256sum] = "f60fcc7d6849342eff22c4350c8b9a989ee8ceabc4b481253e8946b9fe83d684"
SRC_URI[redox_syscall-0.2.16.sha256sum] = "fb5a58c1855b4b6819d59012155603f0b22ad30cad752600aadfcb695265519a"
SRC_URI[redox_termios-0.1.3.sha256sum] = "20145670ba436b55d91fc92d25e71160fbfbdd57831631c8d7d36377a476f1cb"
-SRC_URI[regex-1.10.5.sha256sum] = "b91213439dad192326a0d7c6ee3955910425f441d7038e0d6933b0aec5c4517f"
+SRC_URI[regex-1.10.6.sha256sum] = "4219d74c6b67a3654a9fbebc4b419e22126d13d2f3c4a07ee0cb61ff79a79619"
SRC_URI[regex-automata-0.4.7.sha256sum] = "38caf58cc5ef2fed281f89292ef23f6365465ed9a41b7a7754eb4e26496c92df"
SRC_URI[regex-syntax-0.8.4.sha256sum] = "7a66a03ae7c801facd77a29370b4faec201768915ac14a721ba36f20bc9c209b"
SRC_URI[retry-2.0.0.sha256sum] = "9166d72162de3575f950507683fac47e30f6f2c3836b71b7fbc61aa517c9c5f4"
@@ -245,12 +246,12 @@ SRC_URI[safemem-0.3.3.sha256sum] = "ef703b7cb59335eae2eb93ceb664c0eb7ea6bf567079
SRC_URI[semver-1.0.23.sha256sum] = "61697e0a1c7e512e84a621326239844a24d8207b4669b41bc18b32ea5cbf988b"
SRC_URI[serde-1.0.204.sha256sum] = "bc76f558e0cbb2a839d37354c575f1dc3fdc6546b5be373ba43d95f231bf7c12"
SRC_URI[serde_derive-1.0.204.sha256sum] = "e0cd7e117be63d3c3678776753929474f3b04a43a080c744d6b0ae2a8c28e222"
-SRC_URI[shared_child-1.0.0.sha256sum] = "b0d94659ad3c2137fef23ae75b03d5241d633f8acded53d672decfa0e6e0caef"
+SRC_URI[shared_child-1.0.1.sha256sum] = "09fa9338aed9a1df411814a5b2252f7cd206c55ae9bf2fa763f8de84603aa60c"
SRC_URI[shlex-1.3.0.sha256sum] = "0fda2ff0d084019ba4d7c6f371c95d8fd75ce3524c3cb8fb653a3023f6323e64"
SRC_URI[strsim-0.11.1.sha256sum] = "7da8b5736845d9f2fcb837ea5d9e2628564b3b043a70948a3f0b778838c5fb4f"
SRC_URI[syn-1.0.109.sha256sum] = "72b64191b275b66ffe2469e8af2c1cfe3bafa67b529ead792a6d0160888b4237"
SRC_URI[syn-2.0.72.sha256sum] = "dc4b9b9bf2add8093d3f2c0204471e951b2285580335de42f9d2534f3ae7a8af"
-SRC_URI[tempfile-3.10.1.sha256sum] = "85b77fafb263dd9d05cbeac119526425676db3784113aa9295c88498cbf8bff1"
+SRC_URI[tempfile-3.11.0.sha256sum] = "b8fcd239983515c23a32fb82099f97d0b11b8c72f654ed659363a95c3dad7a53"
SRC_URI[termion-1.5.6.sha256sum] = "077185e2eac69c3f8379a4298e1e07cd36beb962290d4a51199acf0fdc10607e"
SRC_URI[termtree-0.4.1.sha256sum] = "3369f5ac52d5eb6ab48c6b4ffdc8efbcad6b89c765749064ba298f2c68a16a76"
SRC_URI[thiserror-1.0.63.sha256sum] = "c0342370b38b6a11b6cc11d6a805569958d54cfa061a29969c3b5ce2ea405724"
@@ -267,6 +268,7 @@ SRC_URI[winapi-0.3.9.sha256sum] = "5c839a674fcd7a98952e593242ea400abe93992746761
SRC_URI[winapi-i686-pc-windows-gnu-0.4.0.sha256sum] = "ac3b87c63620426dd9b991e5ce0329eff545bccbbb34f3be09ff6fb6ab51b7b6"
SRC_URI[winapi-x86_64-pc-windows-gnu-0.4.0.sha256sum] = "712e227841d057c1ee1cd2fb22fa7e5a5461ae8e48fa2ca79ec42cfc1931183f"
SRC_URI[windows-sys-0.52.0.sha256sum] = "282be5f36a8ce781fad8c8ae18fa3f9beff57ec1b52cb3de0789201425d9a33d"
+SRC_URI[windows-sys-0.59.0.sha256sum] = "1e38bc4d79ed67fd075bcc251a1c39b32a1776bbe92e5bef1f0bf1f8c531853b"
SRC_URI[windows-targets-0.52.6.sha256sum] = "9b724f72796e036ab90c1021d4780d4d3d648aca59e491e6b98e725b84e99973"
SRC_URI[windows_aarch64_gnullvm-0.52.6.sha256sum] = "32a4622180e7a0ec044bb555404c800bc9fd9ec262ec147edd5989ccd0c02cd3"
SRC_URI[windows_aarch64_msvc-0.52.6.sha256sum] = "09ec2a7bb152e2252b53fa7803150007879548bc709c039df7627cabbd05d469"
diff --git a/meta-oe/dynamic-layers/clang-layer/recipes-support/thin-provisioning-tools/thin-provisioning-tools_1.0.14.bb b/meta-oe/dynamic-layers/clang-layer/recipes-support/thin-provisioning-tools/thin-provisioning-tools_1.1.0.bb
similarity index 88%
rename from meta-oe/dynamic-layers/clang-layer/recipes-support/thin-provisioning-tools/thin-provisioning-tools_1.0.14.bb
rename to meta-oe/dynamic-layers/clang-layer/recipes-support/thin-provisioning-tools/thin-provisioning-tools_1.1.0.bb
index e5a683aa0f..bb4b53c28b 100644
--- a/meta-oe/dynamic-layers/clang-layer/recipes-support/thin-provisioning-tools/thin-provisioning-tools_1.0.14.bb
+++ b/meta-oe/dynamic-layers/clang-layer/recipes-support/thin-provisioning-tools/thin-provisioning-tools_1.1.0.bb
@@ -11,16 +11,17 @@ SRC_URI = " \
git://github.com/jthornber/thin-provisioning-tools;branch=main;protocol=https \
"
-# v1.0.14
-SRCREV = "6be3e0937800cb947f1be7c0150825f155cfca14"
+# v1.1.0
+SRCREV = "b745ab35057bdd0a4f1406938916621dcf2b7ef6"
UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>\d+(\.\d+)+)"
inherit cargo cargo-update-recipe-crates
inherit pkgconfig
-DEPENDS += "udev clang-native"
+DEPENDS += "udev libdevmapper libdevmapper-native clang-native"
export LIBCLANG_PATH = "${WORKDIR}/recipe-sysroot-native${libdir}"
+export BINDGEN_EXTRA_CLANG_ARGS = "${BUILD_CFLAGS}"
require ${BPN}-crates.inc
require ${BPN}-git-crates.inc
^ permalink raw reply related
* RE: [PATCH] clk: davinci: Use of_get_available_child_by_name()
From: Biju Das @ 2025-02-27 6:24 UTC (permalink / raw)
To: Stephen Boyd, David Lechner, Michael Turquette
Cc: linux-clk@vger.kernel.org, Geert Uytterhoeven, biju.das.au
In-Reply-To: <76e67776d562acfc9e55500d512c4583.sboyd@kernel.org>
Hi Stephan,
> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: 26 February 2025 23:53
> Subject: Re: [PATCH] clk: davinci: Use of_get_available_child_by_name()
>
> Quoting Biju Das (2025-02-01 08:10:09)
> > Simplify of_davinci_pll_init() by using of_get_available_child_by_name().
> >
> > While at it, move of_node_put(child) inside the if block to avoid
> > additional check if of_child is NULL.
> >
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > ---
> > This patch is only compile tested and depend upon[1] [1]
> > https://lore.kernel.org/all/20250201093126.7322-1-biju.das.jz@bp.renes
> > as.com/
> > ---
>
> Please resend this when the dependency is in Linus' tree.
Sure.
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH] uio_hv_generic: Fix sysfs creation path for ring buffer
From: Naman Jain @ 2025-02-27 6:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: K . Y . Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui,
Stephen Hemminger, linux-hyperv, linux-kernel, stable,
Saurabh Sengar, Michael Kelley, Long Li
In-Reply-To: <2025022643-predict-hedge-8c77@gregkh>
On 2/26/2025 8:03 PM, Greg Kroah-Hartman wrote:
> On Wed, Feb 26, 2025 at 05:51:46PM +0530, Naman Jain wrote:
>>
>>
>> On 2/26/2025 3:33 PM, Greg Kroah-Hartman wrote:
>>> On Wed, Feb 26, 2025 at 10:43:41AM +0530, Naman Jain wrote:
>>>>
>>>>
>>>> On 2/25/2025 2:09 PM, Greg Kroah-Hartman wrote:
>>>>> On Tue, Feb 25, 2025 at 02:04:43PM +0530, Naman Jain wrote:
>>>>>>
>>>>>>
>>>>>> On 2/25/2025 11:42 AM, Greg Kroah-Hartman wrote:
>>>>>>> On Tue, Feb 25, 2025 at 10:50:01AM +0530, Naman Jain wrote:
>>>>>>>> On regular bootup, devices get registered to vmbus first, so when
>>>>>>>> uio_hv_generic driver for a particular device type is probed,
>>>>>>>> the device is already initialized and added, so sysfs creation in
>>>>>>>> uio_hv_generic probe works fine. However, when device is removed
>>>>>>>> and brought back, the channel rescinds and device again gets
>>>>>>>> registered to vmbus. However this time, the uio_hv_generic driver is
>>>>>>>> already registered to probe for that device and in this case sysfs
>>>>>>>> creation is tried before the device gets initialized completely.
>>>>>>>>
>>>>>>>> Fix this by moving the core logic of sysfs creation for ring buffer,
>>>>>>>> from uio_hv_generic to HyperV's vmbus driver, where rest of the sysfs
>>>>>>>> attributes for the channels are defined. While doing that, make use
>>>>>>>> of attribute groups and macros, instead of creating sysfs directly,
>>>>>>>> to ensure better error handling and code flow.
>>
>> <snip>
>>
>>>>>>>> +static int hv_mmap_ring_buffer_wrapper(struct file *filp, struct kobject *kobj,
>>>>>>>> + const struct bin_attribute *attr,
>>>>>>>> + struct vm_area_struct *vma)
>>>>>>>> +{
>>>>>>>> + struct vmbus_channel *channel = container_of(kobj, struct vmbus_channel, kobj);
>>>>>>>> +
>>>>>>>> + if (!channel->mmap_ring_buffer)
>>>>>>>> + return -ENODEV;
>>>>>>>> + return channel->mmap_ring_buffer(channel, vma);
>>>>>>>
>>>>>>> What is preventing mmap_ring_buffer from being set to NULL right after
>>>>>>> checking it and then calling it here? I see no locks here or where you
>>>>>>> are assigning this variable at all, so what is preventing these types of
>>>>>>> races?
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> greg k-h
>>>>>>
>>>>>> Thank you so much for reviewing.
>>>>>> I spent some time to understand if this race condition can happen and it
>>>>>> seems execution flow is pretty sequential, for a particular channel of a
>>>>>> device.
>>>>>>
>>>>>> Unless hv_uio_remove (which makes channel->mmap_ring_buffer NULL) can be
>>>>>> called in parallel to hv_uio_probe (which had set
>>>>>> channel->mmap_ring_buffer to non NULL), I doubt race can happen here.
>>>>>>
>>>>>> Code Flow: (R, W-> Read, Write to channel->mmap_ring_buffer)
>>>>>>
>>>>>> vmbus_device_register
>>>>>> device_register
>>>>>> hv_uio_probe
>>>>>> hv_create_ring_sysfs (W to non NULL)
>>>>>> sysfs_update_group
>>>>>> vmbus_chan_attr_is_visible (R)
>>>>>> vmbus_add_channel_kobj
>>>>>> sysfs_create_group
>>>>>> vmbus_chan_attr_is_visible (R)
>>>>>> hv_mmap_ring_buffer_wrapper (critical section)
>>>>>>
>>>>>> hv_uio_remove
>>>>>> hv_remove_ring_sysfs (W to NULL)
>>>>>
>>>>> Yes, and right in here someone mmaps the file.
>>>>>
>>>>> I think you can race here, no locks at all feels wrong.
>>>>>
>>>>> Messing with sysfs groups and files like this is rough, and almost never
>>>>> a good idea, why can't you just do this all at once with the default
>>>>> groups, why is this being added/removed out-of-band?
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>
>>>> The decision to avoid creating a "ring" sysfs attribute by default
>>>> likely stems from a specific use case where it wasn't needed for every
>>>> device. By creating it automatically, it keeps the uio_hv_generic
>>>> driver simpler and helps prevent potential race conditions. However, it
>>>> has an added cost of having ring buffer for all the channels, where it
>>>> is not required. I am trying to find if there are any more implications
>>>> of it.
>>>
>>> You do know about the "is_visable" attribute callback, right? Why not
>>> just use that instead of manually mucking around with the
>>> adding/removing of sysfs attributes at all? That is what it was
>>> designed for.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> Hi Greg,
>> Yes, I am utilizing that in my patch. For differentiating channels of a
>> uio_hv_generic device, and for *selectively* creating sysfs, we
>> introduced this field in channel struct "channel->mmap_ring_buffer",
>> which we were setting only in uio_hv_generic. But, by the time we set
>> this in uio_hv_generic driver, the sysfs creation has already gone
>> through and sysfs doesn't get updated dynamically. That's where there
>> was a need to call sysfs_update_group. I thought the better place to
>> keep sysfs_update_group would be in vmbus driver, where we are creating
>> the original sysfs entries, hence I had to add the wrapper functions.
>> This led us to the race condition we are trying to address now.
>>
>>
>> @@ -1838,6 +1872,10 @@ static umode_t vmbus_chan_attr_is_visible(struct
>> kobject *kobj,
>> attr == &chan_attr_monitor_id.attr))
>> return 0;
>>
>> + /* Hide ring attribute if channel's mmap_ring_buffer function is not yet
>> initialised */
>> + if (attr == &chan_attr_ring_buffer.attr && !channel->mmap_ring_buffer)
>> + return 0;
>> +
>> return attr->mode;
>
> Ok, that's good. BUT you need to change the detection of this to be
> before the device is set up in the driver. Why can't you do it in the
> device creation logic itself instead of after-the-fact when you will
> ALWAYS race with userspace?
>
> thanks,
>
> greg k-h
Sure, will check more on this. Thanks.
Regards,
Naman
^ permalink raw reply
* Re: [PATCH 0/7] Implement MPIPL for PowerNV
From: Aditya Gupta @ 2025-02-27 6:23 UTC (permalink / raw)
To: Nicholas Piggin, qemu-devel
Cc: qemu-ppc, Frédéric Barrat, Sourabh Jain,
Mahesh J Salgaonkar, Hari Bathini
In-Reply-To: <D82WY0RYB30R.3M0B68UOLV0EK@gmail.com>
Hi Nick,
On 27/02/25 09:07, Nicholas Piggin wrote:
> On Mon Feb 17, 2025 at 5:19 PM AEST, Aditya Gupta wrote:
>> Overview
>> =========
>>
>> Implemented MPIPL (Memory Preserving IPL, aka fadump) on PowerNV machine
>> in QEMU.
> Wow, that's a lot of effort.
Thanks Nick.
>> Note: It's okay if this isn't merged as there might be less users. Sending
>> for archieval purpose, as the patches can be referred for how fadump/mpipl
>> can be implemented in baremetal/PowerNV/any other arch QEMU.
> I would like to add it. It helps test a bunch of code that is in Linux
> and skiboot, so it would be quite useful. A functional test would be
> important to have.
Sure, it's not complete yet (didn't implement the CPU saving part) as I
just wanted to do a experiment I did, will improve those things by v2
then. It might take some time though.
Will look into the functional test thing also.
> I've had a glance through it, but better review might have to wait for
> until the next development cycle.
Sure, that's totally okay. Thank you for looking at it.
Thanks,
- Aditya G
> Thanks,
> Nick
^ permalink raw reply
* Re: [PATCH v5 1/6] target/i386: Update EPYC CPU model for Cache property, RAS, SVM feature bits
From: Zhao Liu @ 2025-02-27 6:42 UTC (permalink / raw)
To: Moger, Babu
Cc: John Allen, pbonzini, qemu-devel, kvm, davydov-max, Joao Martins
In-Reply-To: <7822f511-6b64-417f-830f-3ef912e572d7@amd.com>
On Wed, Feb 26, 2025 at 02:28:35PM -0600, Moger, Babu wrote:
> Date: Wed, 26 Feb 2025 14:28:35 -0600
> From: "Moger, Babu" <babu.moger@amd.com>
> Subject: Re: [PATCH v5 1/6] target/i386: Update EPYC CPU model for Cache
> property, RAS, SVM feature bits
>
> Hi John,
>
> On 2/25/25 11:01, John Allen wrote:
> > On Thu, Feb 20, 2025 at 06:59:34PM +0800, Zhao Liu wrote:
> >> And one more thing :-) ...
> >>
> >>> static const CPUCaches epyc_rome_cache_info = {
> >>> .l1d_cache = &(CPUCacheInfo) {
> >>> .type = DATA_CACHE,
> >>> @@ -5207,6 +5261,25 @@ static const X86CPUDefinition builtin_x86_defs[] = {
> >>> },
> >>> .cache_info = &epyc_v4_cache_info
> >>> },
> >>> + {
> >>> + .version = 5,
> >>> + .props = (PropValue[]) {
> >>> + { "overflow-recov", "on" },
> >>> + { "succor", "on" },
> >>
> >> When I checks the "overflow-recov" and "succor" enabling, I find these 2
> >> bits are set unconditionally.
> >>
> >> I'm not sure if all AMD platforms support both bits, do you think it's
> >> necessary to check the host support?
> >
> > Hi Zhao,
> >
> > IIRC, we intentionally set these unconditionally since there is no
> > specific support needed from the host side for guests to use these bits
> > to handle MCEs. See the original discussion and rationale in this
> > thread:
> >
> > https://lore.kernel.org/all/20230706194022.2485195-2-john.allen@amd.com/
> >
> > However, this discussion only applied to the SUCCOR feature and not the
> > OVERFLOW_RECOV feature and now that you bring it up, I'm second guessing
> > whether we can apply the same thinking to OVERFLOW_RECOV. I think we may
> > want to keep setting the SUCCOR bit unconditionally, but we may want to
> > handle OVERFLOW_RECOV normally. I'll have to track down some old
> > hardware to see how this behaves when the hardware doesn't support it.
Yes, thanks!
> Yes. We need to verify it on pre-EPYC hardware. Please let us know how it
> goes.
>
> But, this series updates only the EPYC based CPU models. It should not be
> a concern here. Right?
Yes, it doesn't block this series. :-)
Thank you both,
Zhao
^ permalink raw reply
* Re: [PATCH v1 10/11] perf python: Add evlist.config to set up record options
From: Ian Rogers @ 2025-02-27 6:21 UTC (permalink / raw)
To: Howard Chu
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa,
Adrian Hunter, Kan Liang, Yicong Yang, James Clark,
Dr. David Alan Gilbert, Levi Yun, Ze Gao, Weilin Wang, Xu Yang,
linux-perf-users, linux-kernel
In-Reply-To: <CAH0uvoj=PJMbOR_iQDFxRsGN+Q04tkkHdAceReHoZANOtv3uCA@mail.gmail.com>
On Wed, Feb 26, 2025 at 9:46 PM Howard Chu <howardchu95@gmail.com> wrote:
>
> Hello,
>
> On Wed, Jan 8, 2025 at 11:51 PM Ian Rogers <irogers@google.com> wrote:
> >
> > Add access to evlist__config that is used to configure an evlist with
> > record options.
> >
> > Signed-off-by: Ian Rogers <irogers@google.com>
> > ---
> > tools/perf/util/python.c | 33 +++++++++++++++++++++++++++++++++
> > 1 file changed, 33 insertions(+)
> >
>
> <SNIP>
>
> > + .user_interval = ULLONG_MAX,
> > + .freq = 4000,
> > + .target = {
> > + .uses_mmap = true,
> > + .default_per_cpu = true,
> > + },
> > + .nr_threads_synthesize = 1,
> > + .ctl_fd = -1,
> > + .ctl_fd_ack = -1,
> > + .no_buffering = true,
> > + .no_inherit = true,
>
> Are these indentations intentional?
Nope, not sure what happened. I'll fix it in v2.
Thanks and thanks for the tags!
Ian
>
> Thanks,
> Howard
^ permalink raw reply
* [PATCH] testsuite/smokey/y2038: Plug race between interruption signaler and waiter
From: Jan Kiszka @ 2025-02-27 6:21 UTC (permalink / raw)
To: Xenomai; +Cc: Florian Bezdeka
From: Jan Kiszka <jan.kiszka@siemens.com>
While testing pselect interruption, force signaler and waiter on the
same CPU and prioritize the latter over the former. This avoids a race
between sending the signal right after being unblocked from the
semaphore and blocking in pselect. Seen rather frequently now with
qemu-arm 4-core machines.
With the schedule-based ordering in place, we can safely drop the
nanosleep before signalling.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
testsuite/smokey/y2038/syscall-tests.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/testsuite/smokey/y2038/syscall-tests.c b/testsuite/smokey/y2038/syscall-tests.c
index 29e9c66c0a..b614d3ba07 100644
--- a/testsuite/smokey/y2038/syscall-tests.c
+++ b/testsuite/smokey/y2038/syscall-tests.c
@@ -13,6 +13,7 @@
#include <sys/timerfd.h>
#include <sys/utsname.h>
#include <mqueue.h>
+#include <sched.h>
#include <rtdm/ipc.h>
smokey_test_plugin(y2038, SMOKEY_NOARGS, "Validate correct y2038 support");
@@ -1422,9 +1423,11 @@ static void pselect64_sig_handler(int sig)
static void *pselect64_waiting_thread(void *arg)
{
struct thread_context *ctx = (struct thread_context *)arg;
+ struct sched_param schedp = {.sched_priority = 99};
struct xn_timespec64 ts;
int sock = ctx->sock;
struct sigaction sa;
+ cpu_set_t cpuset;
fd_set rfds;
int ret;
@@ -1439,6 +1442,18 @@ static void *pselect64_waiting_thread(void *arg)
if (ret)
goto out;
+ CPU_ZERO(&cpuset);
+ CPU_SET(0, &cpuset);
+ ret = sched_setaffinity(0, sizeof(cpuset), &cpuset);
+ if (!smokey_assert(ret == 0)) {
+ ret = -errno;
+ goto out;
+ }
+
+ ret = sched_setscheduler(0, SCHED_FIFO, &schedp);
+ if (!smokey_assert(ret == 0))
+ goto out;
+
/* Waiting for 1sec should be enough to get a signal */
ts.tv_sec = 1;
ts.tv_nsec = 0;
@@ -1461,9 +1476,9 @@ out:
static int test_pselect64_interruption(void)
{
- struct timespec ts = { .tv_sec = 0, .tv_nsec = 100000 };
struct thread_context ctx = { 0 };
void *w_ret = NULL;
+ cpu_set_t cpuset;
pthread_t w;
sem_t sem;
int sock;
@@ -1481,6 +1496,12 @@ static int test_pselect64_interruption(void)
if (ret)
return ret;
+ CPU_ZERO(&cpuset);
+ CPU_SET(0, &cpuset);
+ ret = sched_setaffinity(0, sizeof(cpuset), &cpuset);
+ if (!smokey_assert(ret == 0))
+ return -errno;
+
ctx.sock = sock;
ctx.sc_nr = sc_cobalt_pselect64;
ctx.sem = &sem;
@@ -1493,9 +1514,6 @@ static int test_pselect64_interruption(void)
/* Wait for the waiting thread to be ready */
sem_wait(&sem);
- /* Allow the waiting thread to enter the pselect64() syscall */
- nanosleep(&ts, NULL);
-
/* Send a signal to interrupt the syscall and trigger -EINTR */
__STD(pthread_kill(w, SIGUSR1));
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] cobalt/tracing: Fix cobalt_tick_shot trace point
From: Jan Kiszka @ 2025-02-27 6:21 UTC (permalink / raw)
To: Florian Bezdeka, xenomai
In-Reply-To: <20250226142117.4057013-1-florian.bezdeka@siemens.com>
On 26.02.25 15:21, Florian Bezdeka wrote:
> It's not allowed to call div_s64() from the TP_printk() part.
> Fix the tracepoint by moving the call to the TP_fast_assign() section.
>
> The trace buffer looked like that:
> [UNABLE TO PARSE] secs=%d nsec=%d delta=%d
>
Just ran into that yesterday again, but I only thought it would be
outdated local trace-cmd. Good catch!
> Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>
> ---
> kernel/cobalt/trace/cobalt-core.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/cobalt/trace/cobalt-core.h b/kernel/cobalt/trace/cobalt-core.h
> index 22e4adda2..645d3e3ad 100644
> --- a/kernel/cobalt/trace/cobalt-core.h
> +++ b/kernel/cobalt/trace/cobalt-core.h
> @@ -822,14 +822,14 @@ TRACE_EVENT(cobalt_tick_shot,
> ),
>
> TP_fast_assign(
> - __entry->delta = delta;
> + __entry->delta = div_s64(delta, 1000);
> __entry->secs = div_u64_rem(trace_clock_local() + delta,
> NSEC_PER_SEC, &__entry->nsecs);
> ),
>
> TP_printk("next tick at %Lu.%06u (delay: %Ld us)",
> (unsigned long long)__entry->secs,
> - __entry->nsecs / 1000, div_s64(__entry->delta, 1000))
> + __entry->nsecs / 1000, __entry->delta)
> );
>
> TRACE_EVENT(cobalt_trace,
Thanks, applied.
Jan
--
Siemens AG, Foundational Technologies
Linux Expert Center
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.