Hi Vincent,
Thanks for all your help.
On 2018-04-26 12:31:33 +0200, Vincent Guittot wrote:
> Hi Niklas,
>
> Le Thursday 26 Apr 2018 à 00:56:03 (+0200), Niklas Söderlund a écrit :
> > Hi Vincent,
> >
> > Here are the result, sorry for the delay.
> >
> >
Hi Vincent,
On 2018-04-26 17:27:24 +0200, Vincent Guittot wrote:
> Hi Niklas,
>
> >> Thanks for the trace, I have been able to catch a problem with it.
> >> Could you test the patch below to confirm that the problem is solved ?
> >> The patch apply on-top
On Thu, Apr 26, 2018 at 11:01:30AM -0700, Bjorn Andersson wrote:
> On Thu 26 Apr 04:55 PDT 2018, Niklas Cassel wrote:
>
> > qcom_scm_call_atomic1() can crash with a NULL pointer dereference at
> > qcom_scm_call_atomic1+0x30/0x48.
> >
>
> Hi Niklas,
>
> The
Update pattern for qcom_scm, so that get_maintainer.pl will show the
correct maintainers + lists, not only for qcom_scm.c, but also for
the files: qcom_scm-32.c, qcom_scm-64.c, qcom_scm.h.
Signed-off-by: Niklas Cassel
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
ard switches SW-53 and SW-54 with CVBS input selected
> by the default switches configuration.
You are missing your SoB line :-)
Reviewed-by: Niklas Söderlund
> ---
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 36
> ++
> 1 file changed, 36 insert
ave a policy about describing hardware which can't be
used without flipping switches. I have no opinion on if we should do
that or not I leave that to others, but for the change itself.
Reviewed-by: Niklas Söderlund
I think it's good we describe it as it's part of the Draak b
Hi there,
>
> While running static analysis on linux-next today a null pointer
> dereference issue was detected by CoverityScan. The following commit
> introduced the issue:
>
> commit 3bb4c3bc85bf77a76c921671800bde2e1bf82a88
> Author: Niklas Söderlund
> Date:
according to the AAPCS.
Add r12 to the clobber list so that the compiler knows that the
callee potentially overwrites the value in r12.
Clobber descriptions may not in any way overlap with an input or
output operand.
Reviewed-by: Bjorn Andersson
Reviewed-by: Stephen Boyd
Signed-off-by: Niklas
originally introduced in commit d96db25d2025
("ath10k: add initial SDIO support").
Fixes: d96db25d2025 ("ath10k: add initial SDIO support")
Signed-off-by: Niklas Cassel
---
drivers/net/wireless/ath/ath10k/sdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On Wed, Feb 27, 2019 at 05:32:14PM -0600, Rob Herring wrote:
> On Tue, Feb 26, 2019 at 8:18 PM Niklas Cassel
> wrote:
> >
> > Hello Rob,
> >
> > Your patch e01afc325025 ("PM / Domains: Stop deferring probe
> > at the end of initcall") breaks defer
ers/thermal/rcar_gen3_thermal.c | 41 +++--
> 1 file changed, 9 insertions(+), 32 deletions(-)
>
> --
> 2.19.2
>
--
Regards,
Niklas Söderlund
ter(virt_dev);
> if (ret) {
> @@ -2533,7 +2535,7 @@ struct device *genpd_dev_pm_attach_by_id(struct device
> *dev,
> }
>
> /* Try to attach the device to the PM domain at the specified index. */
> - ret = __genpd_dev_pm_attach(virt_dev, dev->of_node, index, false);
> + ret = __genpd_dev_pm_attach(virt_dev, index, false);
> if (ret < 1) {
> device_unregister(virt_dev);
> return ret ? ERR_PTR(ret) : NULL;
> --
> 2.17.1
>
Acked-by: Niklas Cassel
> return ERR_PTR(ret);
> }
>
> --
> 2.17.1
>
Acked-by: Niklas Cassel
"#power-domain-cells");
> - if (num_domains < 2 || index >= num_domains)
> + if (index >= num_domains)
> return NULL;
>
> /* Allocate and register device on the genpd bus. */
> --
> 2.17.1
>
Acked-by: Niklas Cassel
Increase s3 max voltage in accordance to QCS404 CPR Fusing Guide Rev 6.0
Signed-off-by: Niklas Cassel
---
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
b/arch/arm64/boot/dts/qcom/qcs404
The commit description should be: arm64: dts: qcom: qcs404-evb:
(The s3 regulator node moved during upstreaming.)
Andy/Bjorn, could you please fix this before applying?
Kind regards,
Niklas
On Thu, Apr 25, 2019 at 01:34:29PM +0200, Niklas Cassel wrote:
> Increase s3 max voltage in accorda
is a multiple of the
regulator step size.
There was actually a patch sent that did this:
https://patchwork.kernel.org/patch/10819313/
However, the commit 331ab98f8c4a ("arm64: dts: qcom: qcs404:
Fix voltages l3") that was applied is not identical to that patch.
Signed-off-by: Nik
target requested by cpufreq core) and we skip updating the performance
> state in this case.
>
> Fix this by also updating the performance state when the old_freq ==
> freq.
>
> Fixes: ca1b5d77b1c6 ("OPP: Configure all required OPPs")
> Cc: v5.0 # v5.0
le for H3ES1.*, according
> to Hardware manual values 1 are "setting prohibited" for Gen3.
>
> Signed-off-by: Hoan Nguyen An
Reviewed-by: Niklas Söderlund
> ---
> drivers/thermal/rcar_gen3_thermal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
it's done in other drivers:
$ grep SYSFS .config
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_SYSFS_SYSCALL=y
# CONFIG_DMI_SYSFS is not set
# CONFIG_FW_CFG_SYSFS is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_GPIO_SYSFS is not set
# CONFIG_WATCHDOG_SYSFS is not set
CONFIG_EDAC_LEGACY_SYSFS=y
schedule_delayed_work(&deferred_probe_timeout_work,
deferred_probe_timeout * HZ);
Kind regards,
Niklas
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
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
/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
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
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
Hi Geert,
Thanks for your work.
On 2020-05-19 10:11:01 +0200, Geert Uytterhoeven wrote:
> Document Device Tree bindings for the Renesas EMMA Mobile System Timer.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Niklas Söderlund
> ---
> .../bindings/timer/renesas,em-sti.y
Hello,
I downloaded the kernel sources from kernel.org using curl, then
opera, and finally lynx (to rule out an html parsing bug). I did the same
with the sign and I keep getting:
% gpg2 --verify linux-5.8.tar.sign linux-5.8.tar.xz
gpg: Signature made Mon Aug 3 00:19:13 2020 EDT
gpg:
On Wed, 5 Aug 2020 18:36:08 -0700
Randy Dunlap wrote:
> On 8/5/20 5:59 PM, David Niklas wrote:
> > Hello,
> > I downloaded the kernel sources from kernel.org using curl, then
> > opera, and finally lynx (to rule out an html parsing bug). I did the
> > same with
ngle child node 'endpoint@0', #address-cells/#size-cells are not
> > > necessary
> > >
> > > (same for vin5-7 below)
> > >
> > Referring to commit 5e53dbf4edb4d ("arm64: dts: renesas: r8a77990: Fix
> > VIN endpoint numbering") we def
Hi Geert and Lad,
On 2020-08-07 13:36:46 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Fri, Aug 7, 2020 at 1:27 PM Niklas Söderlund
> wrote:
> > On 2020-08-06 13:47:58 +0200, Geert Uytterhoeven wrote:
> > > On Thu, Aug 6, 2020 at 1:17 PM Lad, Prabhakar
> >
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
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
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
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
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
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/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/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/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 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
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
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
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
#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
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/
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
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
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 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
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
-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
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
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
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
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
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
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
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:
> >
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 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
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: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
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 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 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 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
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
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
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 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(
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
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
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
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/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
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 +-
>
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
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
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 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
#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
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,
> +
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
> 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
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
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 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
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
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
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
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
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/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/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/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 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
301 - 400 of 1082 matches
Mail list logo
