On Wed, 2025-03-05 at 13:13 +0100, Niklas Schnelle wrote:
> On Wed, 2025-03-05 at 10:53 +0100, Maximilian Immanuel Brandtner wrote:
> > On Mon, 2025-03-03 at 12:54 +0100, Amit Shah wrote:
> > > On Tue, 2025-02-25 at 10:21 +0100, Maximilian Immanuel Brandtner
> > > wrot
implemented resize for multiport (because in the
> virtio spec I was only able to find references to resizing as a control
> message which requires multiport. In your email you claimed that config
> space resizing exists as well. I was only able to find references to
> resizing as a cont
On 16 January 2025 17:12:27 CET, Manivannan Sadhasivam
wrote:
>On Thu, Jan 16, 2025 at 04:36:07PM +0100, Niklas Cassel wrote:
>> On Thu, Jan 16, 2025 at 07:21:02PM +0530, Manivannan Sadhasivam wrote:
>> > Hi,
>> >
>> > This series carries forward the effo
t->msixnum > 2048)
> - goto usage;
> - continue;
> - case 'i':
> - test->irqtype = atoi(optarg);
> - if (test->irqtype < 0 || test->irqtype > 2)
> - goto usage;
> - test->set_irqtype = true;
> - continue;
> - case 'I':
> - test->get_irqtype = true;
> - continue;
> - case 'r':
> - test->read = true;
> - continue;
> - case 'w':
> - test->write = true;
> - continue;
> - case 'c':
> - test->copy = true;
> - continue;
> - case 'e':
> - test->clear_irq = true;
> - continue;
> - case 's':
> - test->size = strtoul(optarg, NULL, 0);
> - continue;
> - case 'd':
> - test->use_dma = true;
> - continue;
> - case 'h':
> - default:
> -usage:
> - fprintf(stderr,
> - "usage: %s [options]\n"
> - "Options:\n"
> - "\t-D PCI endpoint test device
> {default: /dev/pci-endpoint-test.0}\n"
> - "\t-b BAR test (bar number between
> 0..5)\n"
> - "\t-C Consecutive BAR test\n"
> - "\t-m MSI test (msi number between
> 1..32)\n"
> - "\t-x \tMSI-X test (msix number
> between 1..2048)\n"
> - "\t-i \tSet IRQ type (0 - Legacy, 1 -
> MSI, 2 - MSI-X)\n"
> - "\t-e Clear IRQ\n"
> - "\t-I Get current IRQ type
> configured\n"
> - "\t-d Use DMA\n"
> - "\t-l Legacy IRQ test\n"
> - "\t-r Read buffer test\n"
> - "\t-w Write buffer test\n"
> - "\t-c Copy buffer test\n"
> - "\t-s Size of buffer {default:
> 100KB}\n"
> - "\t-h Print this help message\n",
> - argv[0]);
> - return -EINVAL;
> - }
> -
> - return run_test(test);
> -}
> diff --git a/tools/testing/selftests/pci_endpoint/pcitest.sh
> b/tools/testing/selftests/pci_endpoint/pcitest.sh
> deleted file mode 100644
> index 770f4d6df34b..
> --- a/tools/testing/selftests/pci_endpoint/pcitest.sh
> +++ /dev/null
> @@ -1,73 +0,0 @@
> -#!/bin/sh
> -# SPDX-License-Identifier: GPL-2.0
> -
> -echo "BAR tests"
> -echo
> -
> -bar=0
> -
> -while [ $bar -lt 6 ]
> -do
> - pcitest -b $bar
> - bar=`expr $bar + 1`
> -done
> -pcitest -C
> -echo
> -
> -echo "Interrupt tests"
> -echo
> -
> -pcitest -i 0
> -pcitest -l
> -
> -pcitest -i 1
> -msi=1
> -
> -while [ $msi -lt 33 ]
> -do
> -pcitest -m $msi
> -msi=`expr $msi + 1`
> -done
> -echo
> -
> -pcitest -i 2
> -msix=1
> -
> -while [ $msix -lt 2049 ]
> -do
> -pcitest -x $msix
> -msix=`expr $msix + 1`
> -done
> -echo
> -
> -echo "Read Tests"
> -echo
> -
> -pcitest -i 1
> -
> -pcitest -r -s 1
> -pcitest -r -s 1024
> -pcitest -r -s 1025
> -pcitest -r -s 1024000
> -pcitest -r -s 1024001
> -echo
> -
> -echo "Write Tests"
> -echo
> -
> -pcitest -w -s 1
> -pcitest -w -s 1024
> -pcitest -w -s 1025
> -pcitest -w -s 1024000
> -pcitest -w -s 1024001
> -echo
> -
> -echo "Copy Tests"
> -echo
> -
> -pcitest -c -s 1
> -pcitest -c -s 1024
> -pcitest -c -s 1025
> -pcitest -c -s 1024000
> -pcitest -c -s 1024001
> -echo
> --
> 2.25.1
>
Reviewed-by: Niklas Cassel
+$(info ${CURDIR})
> prepare: $(OUTPUT)include/linux/
>
> PCITEST_IN := $(OUTPUT)pcitest-in.o
> diff --git a/tools/pci/pcitest.c
> b/tools/testing/selftests/pci_endpoint/pcitest.c
> similarity index 100%
> rename from tools/pci/pcitest.c
> rename to tools/testing/selftests/pci_endpoint/pcitest.c
> diff --git a/tools/pci/pcitest.sh
> b/tools/testing/selftests/pci_endpoint/pcitest.sh
> similarity index 100%
> rename from tools/pci/pcitest.sh
> rename to tools/testing/selftests/pci_endpoint/pcitest.sh
> --
> 2.25.1
>
Reviewed-by: Niklas Cassel
0221007053934.5188-1-aman1.gu...@samsung.com
> [2]
> https://lore.kernel.org/linux-pci/b2a5db97-dc59-33ab-71cd-f591e0b1b...@linuxfoundation.org
>
> Changes in v5:
>
> * Incorporated comments from Niklas
> * Added a patch to fix the DMA MEMCPY check in pci-epf-test driver
>
d the DMA
> controller can support both DMA_PRIVATE and DMA_MEMCPY.
>
> So fix the check and also reword the error message.
>
> Reported-by: Niklas Cassel
> Closes: https://lore.kernel.org/linux-pci/Z3QtEihbiKIGogWA@ryzen
> Fixes: 8353813c88ef ("PCI: endpoint: Enab
On Thu, Jan 16, 2025 at 10:17:25AM +0530, Manivannan Sadhasivam wrote:
> On Thu, Jan 02, 2025 at 03:23:14PM +0100, Niklas Cassel wrote:
> > Hello Mani, Vinod,
> >
> > On Thu, Jan 02, 2025 at 12:34:04PM +0530, Manivannan Sadhasivam wrote:
> > > On Tue, Dec 31, 20
Hello Mani, Vinod,
On Thu, Jan 02, 2025 at 12:34:04PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Dec 31, 2024 at 08:33:57PM +0100, Niklas Cassel wrote:
> >
> > I have some patches that adds DMA_MEMCPY to dw-edma, but I'm not sure if
> > the DWC eDMA hardware suppor
On 31 December 2024 20:18:12 CET, Manivannan Sadhasivam
wrote:
>On Tue, Dec 31, 2024 at 06:42:42PM +0100, Niklas Cassel wrote:
>> On Tue, Dec 31, 2024 at 06:43:41PM +0530, Manivannan Sadhasivam wrote:
>>
>> (...)
>>
>> > + # RUN
est -f pci_ep_basic -T BAR_TEST -v
(...)
> +
> +TEST_F(pci_ep_data_transfer, COPY_TEST)
> +{
> + struct pci_endpoint_test_xfer_param param = {0};
This (also other places in this file) can be written as:
struct pci_endpoint_test_xfer_param param = {};
Kind regards,
Niklas
make sense IMO.
Kind regards,
Niklas
> ---
> Documentation/PCI/endpoint/pci-test-howto.rst | 9 +
> MAINTAINERS| 2 +-
> tools/testing/selftests/pci_endpoint/.gitignore| 3 +++
> tools/{pci => test
lse;
> + return -ETIMEDOUT;
>
> - return pci_irq_vector(pdev, msi_num - 1) == test->last_irq;
> + if (!(pci_irq_vector(pdev, msi_num - 1) == test->last_irq))
if (pci_irq_vector(pdev, msi_num - 1) != test->last_irq) ?
Or perhaps even:
ret = pci_irq_vector();
if (ret < 0)
return ret;
if (ret != test->last_irq)
return -EIO;
Otherwise, this looks good to me:
Reviewed-by: Niklas Cassel
it a bit more.
Ok, thanks!
I really hope that the kselftest conversion will have time to land this
cycle as well.
Feel free to CC me on the next revision and I will make sure to send a
Tested-by and/or Reviewed-by.
Kind regards,
Niklas
you could see earlier in this same thread:
https://lore.kernel.org/linux-pci/20241219000112.GE1444967@rocinante/T/#m7bb0e624a4bf88f5cc13dc3804972c4fa9a79bcd
Mani suggested that my patch (which conflicts with this),
should be picked up first.
Is there a reason for the sudden chance of plans?
Please advice on how to proceed.
Kind regards,
Niklas
On Mon, Dec 16, 2024 at 11:33:37AM +0530, Manivannan Sadhasivam wrote:
> On Thu, Dec 12, 2024 at 10:25:53AM +0100, Niklas Cassel wrote:
> >
> > If you need to respin this series, I strongly suggest that you send the
> > Qcom fix separately. It is totally independent, and
picked up first,
so this series could also add a kselftest testcase for the above.
Kind regards,
Niklas
On Fri, Nov 29, 2024 at 10:22:56PM +0530, Manivannan Sadhasivam wrote:
> On Fri, Nov 29, 2024 at 05:42:26PM +0100, Niklas Cassel wrote:
> > On Fri, Nov 29, 2024 at 10:05:55PM +0530, Manivannan Sadhasivam wrote:
> > > On Fri, Nov 29, 2024 at 02:51:26PM +0100, Niklas Cassel wrote:
On Fri, Nov 29, 2024 at 10:05:55PM +0530, Manivannan Sadhasivam wrote:
> On Fri, Nov 29, 2024 at 02:51:26PM +0100, Niklas Cassel wrote:
> > Hello Mani,
> >
> > On Fri, Nov 29, 2024 at 02:54:15PM +0530, Manivannan Sadhasivam wrote:
> > > Migrate the PCI endpoint te
and select CONFIG_DW_EDMA=y)),
pci_epf_test_copy() will fail with:
[ 93.779444] pci_epf_test pci_epf_test.0: Cannot transfer data using DMA
See:
https://github.com/torvalds/linux/blob/v6.12/drivers/pci/endpoint/functions/pci-epf-test.c#L363-L368
Kind regards,
Niklas
From: Niklas Carlsson
The ALSA control readback functionality only works for non-volatile
controls, i.e. control values that does not change on their own without
driver interaction.
This doesn't work for readbacks since the DSP firmware updates the
control value. Disable the cache mechani
Hey,
I forgot to give you a bug tracker in case you want one.
Here: https://bugzilla.kernel.org/show_bug.cgi?id=212691
Thanks,
David
Hello,
I have tested and found this bug to occur on the specified bisected
commit through Linux Kernel version 5.11.12.
I am running Devuan (Debian) Linux with a hand created kernel config. I'm
attaching it.
I've bisected the kernel and found the broken commit. Here's how I got
there in case you'r
Instead of relying on the fallback in asm-generic/io.h which sets
PCI_IOBASE 0 if it is not defined set it explicitly.
Link:
https://lore.kernel.org/lkml/CAK8P3a3PK9zyeP4ymELtc2ZYnymECoACiigw9Za+pvSJpCk5=g...@mail.gmail.com/
Signed-off-by: Niklas Schnelle
---
arch/sparc/include/asm/io.h | 4
Make things explicit and silence the warning by letting inb() and
friends fail with WARN_ONCE() and a 0xff... return in case PCI_IOBASE is
not defined.
Signed-off-by: Niklas Schnelle
---
v1 -> v2:
- Instead of working around the warning with a uintptr_t PCI_IOBASE make inb()
and friends ex
-generic/io.h.
Thanks,
Niklas
Changes since v1:
- Added patch to explicitly set PCI_IOBASE to 0 on sparc as suggested by Arnd
Bergmann
- Instead of working around the warning with a uintptr_t PCI_IOBASE make inb()
and friends explicitly WARN_ONCE() and return 0xff... (Arnd)
Niklas Schnelle (2
On Wed, 2021-04-14 at 15:17 -0500, Bjorn Helgaas wrote:
> On Mon, Apr 12, 2021 at 03:59:05PM +0200, Niklas Schnelle wrote:
> > On s390 each PCI device has a user-defined ID (UID) exposed under
> > /sys/bus/pci/devices//uid. This ID was designed to serve as the PCI
> > device&#
On Wed, 2021-04-14 at 13:50 +, David Laight wrote:
> From: Niklas Schnelle
> > Sent: 14 April 2021 13:35
> >
> > On Tue, 2021-04-13 at 14:12 +, David Laight wrote:
> > > From: Arnd Bergmann
> > > > Sent: 13 April 2021 14:40
> > > >
On Tue, 2021-04-13 at 14:12 +, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 13 April 2021 14:40
> >
> > On Tue, Apr 13, 2021 at 3:06 PM David Laight
> > wrote:
> > > From: Arnd Bergmann
> > > > Sent: 13 April 2021 13:58
> > > ...
> > > > The remaining ones (csky, m68k, sparc32) need t
t; devices using the
MAX96712 as a video source there are a lot of features missing. Most
notably the ability to operate the GMSL bus.
Signed-off-by: Niklas Söderlund
---
MAINTAINERS | 6 +
drivers/staging/media/Kconfig | 2 +
drivers/staging/medi
On Tue, 2021-04-13 at 14:26 +0200, Arnd Bergmann wrote:
> On Tue, Apr 13, 2021 at 1:54 PM Niklas Schnelle
> wrote:
> > When PCI_IOBASE is not defined, it is set to 0 such that it is ignored
> > in calls to the readX/writeX primitives. While mathematically obvious
> > this
s in drivers. Instead use "uintptr_t" for PCI_IOBASE
0 and explicitly cast to "void __iomem *" when calling readX/writeX.
Signed-off-by: Niklas Schnelle
---
include/asm-generic/io.h | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/includ
On Tue, 2021-04-13 at 10:32 +0300, Leon Romanovsky wrote:
> On Tue, Apr 13, 2021 at 08:57:19AM +0200, Niklas Schnelle wrote:
> > On Tue, 2021-04-13 at 08:39 +0300, Leon Romanovsky wrote:
> > > On Mon, Apr 12, 2021 at 03:59:04PM +0200, Niklas Schnelle wrote:
> >
On Tue, 2021-04-13 at 08:39 +0300, Leon Romanovsky wrote:
> On Mon, Apr 12, 2021 at 03:59:04PM +0200, Niklas Schnelle wrote:
> > Hi Narendra, Hi All,
> >
> > According to Documentation/ABI/testing/sysfs-bus-pci you are responsible
> > for the index device attribute
space infrastructure.
Thanks,
Niklas Schnelle
Niklas Schnelle (1):
s390/pci: expose a PCI device's UID as its index
Documentation/ABI/testing/sysfs-bus-pci | 11 +---
arch/s390/pci/pci_sysfs.c | 35 +
2 files changed, 42 insertions(+), 4 deletions(-)
--
2.25.1
systemd's
interface naming support for free.
Signed-off-by: Niklas Schnelle
Acked-by: Viktor Mihajlovski
---
Documentation/ABI/testing/sysfs-bus-pci | 11 +---
arch/s390/pci/pci_sysfs.c | 35 +
2 files changed, 42 insertions(+), 4 deletions(-)
diff
There is a single trailing whitespace in core.c.
Since this is just a single whitespace, the chances of this affecting
backports to stable should be quite low, so let's just remove it.
Signed-off-by: Niklas Cassel
---
drivers/nvme/host/core.c | 2 +-
1 file changed, 1 insertion(+), 1 del
There is a single trailing whitespace in multipath.c.
Since this is just a single whitespace, the chances of this affecting
backports to stable should be quite low, so let's just remove it.
Signed-off-by: Niklas Cassel
---
drivers/nvme/host/multipath.c | 2 +-
1 file changed, 1 insertion(
Hello nvme peeps,
This series removes all the trailing whitespace I could find using:
git grep '[[:blank:]]$' drivers/nvme
So this should remove all the existing trailing whitespace in
drivers/nvme/*
Kind regards,
Niklas
Niklas Cassel (3):
nvme-pci: remove single trailing whitesp
There is a single trailing whitespace in pci.c.
Since this is just a single whitespace, the chances of this affecting
backports to stable should be quite low, so let's just remove it.
Signed-off-by: Niklas Cassel
---
drivers/nvme/host/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 del
From: Niklas Cassel
According to the module parameter description for sgl_threshold,
a value of 0 means that SGLs are disabled.
If SGLs are disabled, we should respect that, even for the case
where the request is made up of a single physical segment.
Fixes: 297910571f08 ("nvme-pci: opt
The following commit has been merged into the timers/core branch of tip:
Commit-ID: c4d814416fe3f5eb27438209a83582d7508ba80a
Gitweb:
https://git.kernel.org/tip/c4d814416fe3f5eb27438209a83582d7508ba80a
Author:Niklas Söderlund
AuthorDate:Thu, 11 Feb 2021 15:31:02 +01:00
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 446e1a943554e07a4e6431fff6dd06c0f130895a
Gitweb:
https://git.kernel.org/tip/446e1a943554e07a4e6431fff6dd06c0f130895a
Author:Niklas Söderlund
AuthorDate:Thu, 11 Feb 2021 15:33:44 +01:00
Hello,
(There are so many maintainers for kfd_iommu.c I feel like I'm spamming.)
When compiling for Linux version 5.11.12 using the AMDGPU GPU driver
with HSA_AMD enabled, I get the below set of errors. To work around this,
I need to change AMD_IOMMU_V2 from M to Y. This bug doesn't affect linux
k
On Thu, 2021-04-01 at 20:46 +0800, Bixuan Cui wrote:
> The ioremap/iounmap is implemented in arch/s390/pci/pci.c.
> While CONFIG_PCI is disabled,the compilation error is reported:
> s390x-linux-gnu-ld: drivers/pcmcia/cistpl.o: in function `set_cis_map':
> cistpl.c:(.text+0x32a): undefined r
From: Niklas Cassel
When a passthru command targets a specific namespace, the ns parameter to
nvme_user_cmd()/nvme_user_cmd64() is set. However, there is currently no
validation that the nsid specified in the passthru command targets the
namespace/nsid represented by the block device that the
On Tue, Mar 30, 2021 at 08:30:22PM +0200, jav...@javigon.com wrote:
> On 26.03.2021 20:59, Niklas Cassel wrote:
> > From: Niklas Cassel
> >
> > Currently when doing NVME_IOCTL_IO_CMD on the controller character device,
> > the command is rejected if there is mor
The following commit has been merged into the timers/core branch of tip:
Commit-ID: d4c7c28806616809e3baa0b7cd8c665516b2726d
Gitweb:
https://git.kernel.org/tip/d4c7c28806616809e3baa0b7cd8c665516b2726d
Author:Niklas Söderlund
AuthorDate:Thu, 11 Feb 2021 14:43:18 +01:00
From: Niklas Cassel
Currently when doing NVME_IOCTL_IO_CMD on the controller character device,
the command is rejected if there is more than one namespace in the
ctrl->namespaces list.
There is not really any reason for this restriction.
Instead, check the nsid value specified in the passt
On Fri, Mar 26, 2021 at 12:19:42AM +0900, Keith Busch wrote:
> On Thu, Mar 25, 2021 at 09:48:37AM +0000, Niklas Cassel wrote:
> > From: Niklas Cassel
> >
> > When a passthru command targets a specific namespace, the ns parameter to
> > nvme_user_cmd()/nvme_user_cmd64(
From: Niklas Cassel
When a passthru command targets a specific namespace, the ns parameter to
nvme_user_cmd()/nvme_user_cmd64() is set. However, there is currently no
validation that the nsid specified in the passthru command targets the
namespace/nsid represented by the block device that the
On Thu, Mar 25, 2021 at 09:48:37AM +, Niklas Cassel wrote:
> From: Niklas Cassel
>
> When a passthru command targets a specific namespace, the ns parameter to
> nvme_user_cmd()/nvme_user_cmd64() is set. However, there is currently no
> validation that the nsid specified
From: Niklas Cassel
When a passthru command targets a specific namespace, the ns parameter to
nvme_user_cmd()/nvme_user_cmd64() is set. However, there is currently no
validation that the nsid specified in the passthru command targets the
namespace/nsid represented by the block device that the
On 21/03/2021 16:51, Zhiqiang Liu wrote:
In disable_slot(), if we obtain desired PCI device
successfully by calling pci_get_slot(), we should
call pci_dev_put() to release its reference.
Thanks for the patch! This should however be fixed independently by
commit 0b13525c20fe ("s390/pci: fix
Hello,
I'm asking how to report a bug in the physical HW here because I can't
think of anywhere else to ask where there might be people who have done
this before.
The HW in question is an AMD 3900X and ASRock Taichi B550 MB. I have
turned both CPU and MB in for warranty and the defect remains.
W
#x27;s interface
naming support for free.
Signed-off-by: Niklas Schnelle
Acked-by: Viktor Mihajlovski
---
Changes from RFC patch:
- Use sysfs_emit() instead of sprintf() (Thanks Krzysztof Wilczyński!)
Documentation/ABI/testing/sysfs-bus-pci | 11 +---
arch/s390/pci/pci_sysfs.c
ng hotplug testing, I overlooked several missing pci_dev_put() calls
for way too long. So let's add a debug print in pci_release_dev() making
it much easier to spot when the PCI device structure is not released
when it is supposed to.
Signed-off-by: Niklas Schnelle
---
drivers/pci/probe.c | 1 +
Hi Wolfram,
Thanks for your patch.
On 2021-03-11 10:09:18 +0100, Wolfram Sang wrote:
> Signed-off-by: Wolfram Sang
Reviewed-by: Niklas Söderlund
> ---
>
> Changes since V1:
> * none, but additional testing was done which revealed that this CMT
> in deed behaves the same
On Mon, Mar 08, 2021 at 10:02:05PM +0530, Kanchan Joshi wrote:
> On Mon, Mar 8, 2021 at 4:21 PM Niklas Cassel wrote:
> >
> > From: Niklas Cassel
> >
> > This reverts commit 73d90386b559d6f4c3c5db5e6bb1b68aae8fd3e7.
> >
> > Commit 73d90386b559 ("n
Hi Wolfram,
Thanks for your patch.
On 2021-03-05 14:28:59 +0100, Wolfram Sang wrote:
> CMTOUT_IE is only supported for older SoCs. Newer SoCs shall not set
> this bit. So, add a version check.
>
> Reported-by: Phong Hoang
> Signed-off-by: Wolfram Sang
Reviewed-by: N
From: Niklas Cassel
This reverts commit 73d90386b559d6f4c3c5db5e6bb1b68aae8fd3e7.
Commit 73d90386b559 ("nvme: cleanup zone information initialization")
introduced the following warning at boot:
WARNING: CPU: 0 PID: 7 at block/blk-settings.c:252
blk_queue_max_zone_append_sectors+0x7d
On 3/7/21 9:46 PM, Krzysztof Wilczyński wrote:
> Hi Niklas,
>
> [...]
>> +static ssize_t index_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> +struct zpci_dev *zdev = to_zpci(to_pci_dev(dev));
>&g
Hi Wolfram,
Thanks for your work.
On 2021-03-05 15:23:59 +0100, Wolfram Sang wrote:
> Signed-off-by: Wolfram Sang
Reviewed-by: Niklas Söderlund
> ---
>
> This is the correct one. TMU passed the testsuite, CMT needs a second
> look.
>
> Documentation/devicetree/b
irectly. Thank you Greg for making me
realize that we were looking too much at just exposing platform details
instead of looking how existing interfaces could suit our purpose.
Thanks,
Niklas Schnelle
Niklas Schnelle (1):
s390/pci: expose a PCI device's UID as its index
Documentation/ABI/
#x27;s interface
naming support for free.
Signed-off-by: Niklas Schnelle
Acked-by: Viktor Mihajlovski
---
Documentation/ABI/testing/sysfs-bus-pci | 11 +---
arch/s390/pci/pci_sysfs.c | 36 +
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a
a2c5e6 ("clocksource: add enable() and disable() callbacks")
Signed-off-by: Niklas Söderlund
---
kernel/time/timekeeping.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 6ae
On 2/4/21 2:38 PM, Greg Kroah-Hartman wrote:
> On Thu, Feb 04, 2021 at 01:02:51PM +0100, Niklas Schnelle wrote:
>>
>>
>> On 2/4/21 11:40 AM, Greg Kroah-Hartman wrote:
>>> On Thu, Feb 04, 2021 at 10:43:53AM +0100, Niklas Schnelle wrote:
>>>> The globa
On 2/4/21 11:40 AM, Greg Kroah-Hartman wrote:
> On Thu, Feb 04, 2021 at 10:43:53AM +0100, Niklas Schnelle wrote:
>> The global UID uniqueness attribute exposes whether the platform
>> guarantees that the user-defined per-device UID attribute values
>> (/sys/bus/pci/device
/unique_uids
Signed-off-by: Niklas Schnelle
---
Documentation/ABI/testing/sysfs-bus-pci | 9 +
drivers/pci/pci-sysfs.c | 21 +
2 files changed, 30 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-pci
b/Documentation/ABI/testing/sysfs-bus
n see this strictly requires the use of raw kobject handling and loses us
the direct relation with PCI so I wanted to give this just one more shot and
get your opinion on it.
Thanks,
Niklas
Niklas Schnelle (1):
PCI: Add s390 specific UID uniqueness attribute
Documentation/ABI/testing/sysfs-bu
On 1/21/21 6:28 PM, Greg Kroah-Hartman wrote:
> On Thu, Jan 21, 2021 at 06:04:52PM +0100, Niklas Schnelle wrote:
>>
>>
>> On 1/21/21 4:54 PM, Bjorn Helgaas wrote:
>>> [Greg may be able to help compare/contrast this s390 UID with udev
>>> persistent names
On 1/21/21 4:54 PM, Bjorn Helgaas wrote:
> [Greg may be able to help compare/contrast this s390 UID with udev
> persistent names]
>
> On Thu, Jan 21, 2021 at 04:31:55PM +0100, Niklas Schnelle wrote:
>> On 1/15/21 4:29 PM, Bjorn Helgaas wrote:
>>> On Fri, Jan 1
On 1/15/21 4:29 PM, Bjorn Helgaas wrote:
> On Fri, Jan 15, 2021 at 12:20:59PM +0100, Niklas Schnelle wrote:
>> On 1/14/21 5:14 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jan 14, 2021 at 04:51:17PM +0100, Niklas Schnelle wrote:
>>>> On 1/14/21 4:17 PM, Greg Kroah-Ha
On 1/19/21 9:02 PM, Matthew Rosato wrote:
> Some s390 PCI devices (e.g. ISM) perform I/O operations that have very
> specific requirements in terms of alignment as well as the patterns in
> which the data is read/written. Allowing these to proceed through the
> typical vfio_pci_bar_rw path will
On 1/20/21 6:10 PM, Matthew Rosato wrote:
> On 1/20/21 8:21 AM, Niklas Schnelle wrote:
>>
>>
>> On 1/19/21 9:02 PM, Matthew Rosato wrote:
>>> Some s390 PCI devices (e.g. ISM) perform I/O operations that have very
>> .. snip ...
>>> +
>>> +st
On 1/19/21 9:02 PM, Matthew Rosato wrote:
> Some s390 PCI devices (e.g. ISM) perform I/O operations that have very
.. snip ...
> +
> +static size_t vfio_pci_zdev_io_rw(struct vfio_pci_device *vdev,
> + char __user *buf, size_t count,
> +
hile at it, use pm_runtime_put() instead of pm_runtime_put_sync(), as
> there is no reason to do a synchronous power down.
>
> Fixes: 7fa2955ff70ce453 ("sh_eth: Fix sleeping function called from invalid
> context")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Niklas Söderlund
On 1/15/21 4:29 PM, Bjorn Helgaas wrote:
> On Fri, Jan 15, 2021 at 12:20:59PM +0100, Niklas Schnelle wrote:
>> On 1/14/21 5:14 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jan 14, 2021 at 04:51:17PM +0100, Niklas Schnelle wrote:
>>>> On 1/14/21 4:17 PM, Greg Kroah-Ha
On 1/14/21 5:14 PM, Greg Kroah-Hartman wrote:
> On Thu, Jan 14, 2021 at 04:51:17PM +0100, Niklas Schnelle wrote:
>>
>>
>> On 1/14/21 4:17 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jan 14, 2021 at 04:06:11PM +0100, Niklas Schnelle wrote:
>>>>
>&g
On 1/14/21 4:17 PM, Greg Kroah-Hartman wrote:
> On Thu, Jan 14, 2021 at 04:06:11PM +0100, Niklas Schnelle wrote:
>>
>>
>> On 1/14/21 2:58 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jan 14, 2021 at 02:44:53PM +0100, Christian Brauner wrote:
>>>> On Thu
On 1/14/21 2:58 PM, Greg Kroah-Hartman wrote:
> On Thu, Jan 14, 2021 at 02:44:53PM +0100, Christian Brauner wrote:
>> On Thu, Jan 14, 2021 at 02:20:10PM +0100, Niklas Schnelle wrote:
>>>
>>>
>>> On 1/13/21 7:55 PM, Bjorn Helgaas wrote:
>>>>
On 1/13/21 7:55 PM, Bjorn Helgaas wrote:
> On Wed, Jan 13, 2021 at 08:47:58AM +0100, Niklas Schnelle wrote:
>> On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
>>> On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
>>>> We use the UID of a zPCI adapter, or t
On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
> On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
>> We use the UID of a zPCI adapter, or the UID of the function zero if
>> there are multiple functions in an adapter, as PCI domain if and only if
>> UID
ctive would be a great choice but I realize that there
currently are no platform specific attributes directly under
"/sys/bus/pci" so this clearly requires some discussion. What's your
thought on this and do you know of any other platform specific global
PCI attributes as I
domain
will be stable, yet currently there is no way to access this information
from userspace.
So let's solve this by showing the state of UID checking as a sysfs
attribute in /sys/bus/pci/uid_checking
Signed-off-by: Niklas Schnelle
---
Documentation/ABI/testing/sysfs-bus-pci | 11
dependency on implicit reset and/or
> boot loader state, and by enabling the clock supply explicitly for all
> channels used instead. This requires postponing the clk_disable() call,
> else the timer's registers cannot be accessed in sh_cmt_setup_channel().
>
> Signed-off-by: Geert
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 8ae954caf49ac403c177d117fb8e05cbc866aa3c
Gitweb:
https://git.kernel.org/tip/8ae954caf49ac403c177d117fb8e05cbc866aa3c
Author:Niklas Söderlund
AuthorDate:Sat, 05 Dec 2020 03:19:20 +01:00
st regards,
Niklas Schnelle
On 12/10/20 3:26 PM, Greg Kroah-Hartman wrote:
> From: Alexander Gordeev
>
> commit a2bd4097b3ec242f4de4924db463a9c94530e03a upstream.
>
> The directed MSIs are delivered to CPUs whose address is
> written to the MSI message address. The current code
w()
region which uses the common code _Kernel_ ioread()/iowrite() API. This Kernel
ioread()/iowrite() API uses PCI MIO Load/Stores by default on machines that
support them (z15 currently). The ISM driver, knowing that its device does not
support MIO, goes around this API and directly calls zpci_stor
by: Daniel Lezcano
Reviewed-by: Niklas Söderlund
> ---
> drivers/thermal/rcar_thermal.c | 19 ---
> 1 file changed, 19 deletions(-)
>
> diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
> index 6ae757d66f46..b49f04daaf47 100644
&g
154
[ 47.682308] smpboot_thread_fn+0x244/0x270
[ 47.690560] kthread+0x154/0x160
[ 47.697927] ret_from_fork+0x10/0x20
[ 47.708447] clocksource: Switched to clocksource e60f.timer
Signed-off-by: Niklas Söderlund
---
drivers/clocksource/sh_cmt.c | 18 ++
1 file c
anosleep CLOCK_REALTIME_ALARM[UNSUPPORTED]
Nanosleep CLOCK_BOOTTIME_ALARM[UNSUPPORTED]
Nanosleep CLOCK_TAI [OK]
# Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
# Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
Niklas Söderlund (2):
clocksource
a2c5e6 ("clocksource: add enable() and disable() callbacks")
Signed-off-by: Niklas Söderlund
---
kernel/time/timekeeping.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 685
urned. Fix this.
>
> Addresses-Coverity: ("Unused value")
> Fixes: b9ad52aafe38 ("media: rcar-vin: Rework parallel firmware parsing")
> Signed-off-by: Colin Ian King
Reviewed-by: Niklas Söderlund
> ---
> drivers/media/platform/rcar-vin/rcar-core.c | 2 +-
>
On 12/3/20 12:19 PM, Dan Carpenter wrote:
> On Thu, Dec 03, 2020 at 11:52:48AM +0100, Niklas Schnelle wrote:
>>
>>
>> On 12/3/20 11:27 AM, Dan Carpenter wrote:
>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/l
1ff3ff1a0b Sebastian Ott 2015-06-16 93 break;
> 7fc611ff3ff1a0b Sebastian Ott 2015-06-16 94 }
> fcf2f402937a669 Sebastian Ott 2013-12-18 95 zdev->fh =
> ccdf->fh;
> f606b3ef47c9f87 Pierre Morel2020-03-25 96
On 11/30/20 9:55 AM, Halil Pasic wrote:
> On Mon, 30 Nov 2020 09:30:33 +0100
> Niklas Schnelle wrote:
>
>> I'm not really familiar, with it but I think this is closely related
>> to what I asked Bernd Nerz. I fear that if CPUs go away we might already
>> be in
On 11/27/20 4:39 PM, Halil Pasic wrote:
> On Fri, 27 Nov 2020 11:08:10 +0100
> Niklas Schnelle wrote:
>
>>
>>
>> On 11/27/20 9:56 AM, Halil Pasic wrote:
>>> On Thu, 26 Nov 2020 18:00:37 +0100
>>> Alexander Gordeev wrote:
>>>
>>
On 11/27/20 9:56 AM, Halil Pasic wrote:
> On Thu, 26 Nov 2020 18:00:37 +0100
> Alexander Gordeev wrote:
>
>> The directed MSIs are delivered to CPUs whose address is
>> written to the MSI message data. The current code assumes
>> that a CPU logical number (as it is seen by the kernel)
>> is al
On 11/13/20 5:25 PM, Christoph Hellwig wrote:
> On Fri, Nov 13, 2020 at 02:15:59PM +0100, Niklas Schnelle wrote:
>>
>>
>> On 11/12/20 6:36 PM, Keith Busch wrote:
>>> On Thu, Nov 12, 2020 at 04:45:35PM +0100, Niklas Schnelle wrote:
>>>> You got to get
1 - 100 of 1021 matches
Mail list logo
