* Re: [PATCH] On ppc64le we HAVE_RELIABLE_STACKTRACE
From: Michael Ellerman @ 2017-12-21 12:10 UTC (permalink / raw)
To: Josh Poimboeuf, Torsten Duwe
Cc: Jiri Kosina, linuxppc-dev, linux-kernel, Nicholas Piggin,
live-patching
In-Reply-To: <20171219214652.u7qeb7fxov62ttke@treble>
Josh Poimboeuf <jpoimboe@redhat.com> writes:
> On Tue, Dec 19, 2017 at 12:28:33PM +0100, Torsten Duwe wrote:
>> On Mon, Dec 18, 2017 at 12:56:22PM -0600, Josh Poimboeuf wrote:
>> > On Mon, Dec 18, 2017 at 03:33:34PM +1000, Nicholas Piggin wrote:
>> > > On Sun, 17 Dec 2017 20:58:54 -0600
>> > > Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>> > >
>> > > > On Fri, Dec 15, 2017 at 07:40:09PM +1000, Nicholas Piggin wrote:
>> > > > > On Tue, 12 Dec 2017 08:05:01 -0600
>> > > > > Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>> > > > >
>> > > > > > What about leaf functions? If a leaf function doesn't establish a stack
>> > > > > > frame, and it has inline asm which contains a blr to another function,
>> > > > > > this ABI is broken.
>> > > >
>> > > > Oops, I meant to say "bl" instead of "blr".
>>
>> You need to save LR, one way or the other. If gcc thinks it's a leaf function and
>> does not do it, nor does your asm code, you'll return in an endless loop => bug.
>
> Ah, so the function's return path would be corrupted, and an unreliable
> stack trace would be the least of our problems.
That's mostly true.
It is possible to save LR somewhere other than the correct stack slot,
in which case you can return correctly but still confuse the unwinder. A
function can hide its caller that way.
It's stupid and we should never do it, but it's not impossible.
...
> So with your proposal, I think I'm convinced that we don't need objtool
> for ppc64le. Does anyone disagree?
I don't disagree, but I'd be happier if we did have objtool support.
Just because it would give us a lot more certainty that we're doing the
right thing everywhere, including in hand-coded asm and inline asm.
It's easy to write powerpc asm such that stack traces are reliable, but
it is *possible* to break them.
> There are still a few more things that need to be looked at:
>
> 1) With function graph tracing enabled, is the unwinder smart enough to
> get the original function return address, e.g. by calling
> ftrace_graph_ret_addr()?
No I don't think so.
> 2) Similar question for kretprobes.
>
> 3) Any other issues with generated code (e.g., bpf, ftrace trampolines),
> runtime patching (e.g., CPU feature alternatives), kprobes, paravirt,
> etc, that might confuse the unwinder?
We'll have to look, I can't be sure off the top of my head.
> 4) As a sanity check, it *might* be a good idea for
> save_stack_trace_tsk_reliable() to ensure that it always reaches the
> end of the stack. There are several ways to do that:
>
> - If the syscall entry stack frame is always the same size, then the
> "end" would simply mean that the stack pointer is at a certain
> offset from the end of the task stack page. However this might not
> work for kthreads and idle tasks, unless their stacks also start at
> the same offset. (On x86 we actually standardized the end of stack
> location for all tasks, both user and kernel.)
Yeah it differs between user and kernel.
> - If the unwinder can get to the syscall frame, it can presumably
> examine regs->msr to check the PR bit to ensure it got all the way
> to syscall entry. But again this might only work for user tasks,
> depending on how kernel task stacks are set up.
That sounds like a good idea. We could possibly mark the last frame of
kernel tasks somehow.
> - Or a different approach would be to do error checking along the
> way, and reporting an error for any unexpected conditions.
>
> However, given that backlink/LR corruption doesn't seem possible with
> this architecture, maybe #4 would be overkill. Personally I would
> feel more comfortable with an "end" check and a WARN() if it doesn't
> reach the end.
Yeah I agree.
cheers
^ permalink raw reply
* Re: [PATCH] cxl: Check if vphb exists before iterating over AFU devices
From: Greg KH @ 2017-12-21 8:03 UTC (permalink / raw)
To: Vaibhav Jain
Cc: stable, Andrew Donnellan, Frederic Barrat, Michael Ellerman,
linuxppc-dev
In-Reply-To: <20171221040619.25270-1-vaibhav@linux.vnet.ibm.com>
On Thu, Dec 21, 2017 at 09:36:19AM +0530, Vaibhav Jain wrote:
> commit 12841f87b7a8ceb3d54f171660f72a86941bfcb3 upstream, for 4.3.
Thanks, now applied to 4.4.
greg k-h
^ permalink raw reply
* Re: [PATCH] powerpc/powernv : Add support to enable sensor groups
From: Shilpasri G Bhat @ 2017-12-21 5:03 UTC (permalink / raw)
To: Stewart Smith, Michael Ellerman, linuxppc-dev
Cc: linux-kernel, ego, akshay.adiga, svaidy,
linux@roeck-us.net >> Guenter Roeck
In-Reply-To: <87609nxfym.fsf@linux.vnet.ibm.com>
Hi,
On 12/04/2017 10:11 AM, Stewart Smith wrote:
> Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> writes:
>> On 11/28/2017 05:07 PM, Michael Ellerman wrote:
>>> Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> writes:
>>>
>>>> Adds support to enable/disable a sensor group. This can be used to
>>>> select the sensor groups that needs to be copied to main memory by
>>>> OCC. Sensor groups like power, temperature, current, voltage,
>>>> frequency, utilization can be enabled/disabled at runtime.
>>>>
>>>> Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
>>>> ---
>>>> The skiboot patch for the opal call is posted below:
>>>> https://lists.ozlabs.org/pipermail/skiboot/2017-November/009713.html
>>>
>>> Can you remind me why we're doing this with a completely bespoke sysfs
>>> API, rather than using some generic sensors API?
>>>
>>
>> Disabling/Enabling sensor groups is not supported in the current generic sensors
>> API. And also we dont export all type of sensors in HWMON as not all of them are
>> environment sensors (like performance).
>
> Are there barriers to adding such concepts to the generic sensors API?
>
Yes.
HWMON does not support attributes for a sensor-group. If we are to extend HWMON
to add new per-sensor attributes to disable/enable, then we need to do either of
the below:
1) If any one of the sensor is disabled then all the sensors belonging to that
group will be disabled. OR
2) To disable a sensor group we need to disable all the sensors belonging to
that group.
Another problem is hwmon categorizes the sensor-groups based on the type of
sensors like power, temp. If OCC allows multiple groups of the same type then
this approach adds some more complexity to the user to identify the sensors
belonging to correct group.
And lastly HWMON does not allow platform specific non-standard sensor groups
like CSM, job-scheduler, profiler.
Thanks and Regards,
Shilpa
^ permalink raw reply
* [PATCH] cxl: Check if vphb exists before iterating over AFU devices
From: Vaibhav Jain @ 2017-12-21 4:06 UTC (permalink / raw)
To: stable
Cc: Vaibhav Jain, Andrew Donnellan, Frederic Barrat, Michael Ellerman,
linuxppc-dev
commit 12841f87b7a8ceb3d54f171660f72a86941bfcb3 upstream, for 4.3.
During an eeh a kernel-oops is reported if no vPHB is allocated to the
AFU. This happens as during AFU init, an error in creation of vPHB is
a non-fatal error. Hence afu->phb should always be checked for NULL
before iterating over it for the virtual AFU pci devices.
This patch fixes the kenel-oops by adding a NULL pointer check for
afu->phb before it is dereferenced.
Fixes: 9e8df8a21963 ("cxl: EEH support")
Cc: stable@vger.kernel.org # v4.3+
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
Changelog:
- Rebased the patch on 4.3 stable tree
---
drivers/misc/cxl/pci.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 85761d7eb333..b982329f3837 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -1328,6 +1328,9 @@ static pci_ers_result_t cxl_vphb_error_detected(struct cxl_afu *afu,
/* There should only be one entry, but go through the list
* anyway
*/
+ if (afu->phb == NULL)
+ return result;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
if (!afu_dev->driver)
continue;
@@ -1368,6 +1371,10 @@ static pci_ers_result_t cxl_pci_error_detected(struct pci_dev *pdev,
*/
for (i = 0; i < adapter->slices; i++) {
afu = adapter->afu[i];
+ /*
+ * Tell the AFU drivers; but we don't care what they
+ * say, we're going away.
+ */
cxl_vphb_error_detected(afu, state);
}
return PCI_ERS_RESULT_DISCONNECT;
@@ -1491,6 +1498,9 @@ static pci_ers_result_t cxl_pci_slot_reset(struct pci_dev *pdev)
if (cxl_afu_select_best_mode(afu))
goto err;
+ if (afu->phb == NULL)
+ continue;
+
cxl_pci_vphb_reconfigure(afu);
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
@@ -1555,6 +1565,9 @@ static void cxl_pci_resume(struct pci_dev *pdev)
for (i = 0; i < adapter->slices; i++) {
afu = adapter->afu[i];
+ if (afu->phb == NULL)
+ continue;
+
list_for_each_entry(afu_dev, &afu->phb->bus->devices, bus_list) {
if (afu_dev->driver && afu_dev->driver->err_handler &&
afu_dev->driver->err_handler->resume)
--
2.14.3
^ permalink raw reply related
* Re: [PATCH] cxl: Check if vphb exists before iterating over AFU devices
From: Vaibhav Jain @ 2017-12-21 4:05 UTC (permalink / raw)
To: Greg KH
Cc: stable, Andrew Donnellan, Frederic Barrat, linuxppc-dev,
Michael Ellerman
In-Reply-To: <20171220170307.GA31793@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Wed, Dec 20, 2017 at 03:07:06PM +0530, Vaibhav Jain wrote:
>> commit 12841f87b7a8ceb3d54f171660f72a86941bfcb3 upstream, for 4.9.
>
> Thanks, do we also need this for 4.4? If so, can you provide a
> backport?
>
Thanks Greg for applying this patch on 4.9 stable tree. I have done a
back-port for 4.3+ and will send the back-ported-patch across.
Cheers,
--
Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Linux Technology Center, IBM India Pvt. Ltd.
^ permalink raw reply
* Re: [PATCH v1 7/7] pseries/setup: Add Initialization of VF Bars
From: Juan Alvarez @ 2017-12-21 3:04 UTC (permalink / raw)
To: Alexey Kardashevskiy, Bryant G. Ly, benh, paulus, mpe
Cc: seroyer, alex.williamson, helgaas, ruscur, linux-pci,
linuxppc-dev, bodong, eli, saeedm
In-Reply-To: <fd876ee1-4c12-587b-a8a0-56233fea3401@ozlabs.ru>
On 12/19/17 12:38 AM, Alexey Kardashevskiy wrote:
> On 19/12/17 06:29, Juan Alvarez wrote:
>> This is PF only path. Yes either we have a root returned otherwise
>> will fall back to iomem_resource.
> You have removed context from my response, do not do that please.
My apologies. I will not do that.
>
> When will you have root and when you won't? imho it should always be either
> one or another.
>
Yes you are correct. The resource is carved out of a different mmio
space and will never be passed in the assigned-addresses property in
the device node of PF.
We will remove that function call, conditional check and set root accordingly.
>> On 12/18/17 1:21 AM, Alexey Kardashevskiy wrote:
>>> @dev here is a VF, right? I am not familiar with powervn much but from what
>>> I see - the devices are sitting on a root bus of their own PHB and they all
>>> either have a root returned from pci_find_parent_resource() or none of them
>>> has a root and will fall back to &iomem_resource, or both cases are possible?
>
- Juan
^ permalink raw reply
* Re: [PATCH v2 2/7] powerpc/kernel: Add uevents in EEH error/resume
From: Juan Alvarez @ 2017-12-21 3:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Bjorn Helgaas, Bryant G. Ly
Cc: paulus, mpe, seroyer, alex.williamson, aik, ruscur, linux-pci,
linuxppc-dev, bodong, eli, saeedm, Keith Busch, Gabriele Paoloni,
Dongdong Liu
In-Reply-To: <1513664878.2743.8.camel@kernel.crashing.org>
On 12/19/17 12:27 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2017-12-18 at 22:50 -0600, Bjorn Helgaas wrote:
>> [+cc Keith, Gabriele, Dongdong]
>>
>> On Mon, Dec 18, 2017 at 04:38:03PM -0600, Bryant G. Ly wrote:
>>> Devices can go offline when EEH is reported. This patch adds
>>> a change to the kernel object and lets udev know of error.
>>> When device resumes a change is also set reporting device as
>>> online. Therefore, EEH events are better propagated to user
>>> space for devices in powerpc arch.
>> I'm on vacation and can't review this in detail, but I wonder if you
>> can compare this with the uevents we emit for DPC, AER, and hotplug
>> events (if any). I hope we don't end up with userspace having to be
>> aware of the differences between EEH, DPC, AER, etc.
>>
>>> From a very quick look, I only see a few uevents even mentioned in
>> drivers/pci: KOBJ_ADD in __pci_hp_register() and KOBJ_CHANGE in the
>> SR-IOV code. I'm worried that we're missing some important uevents in
>> the PCI core. That's not an argument against what you're doing here;
>> it just would be nice to fill in any missing pieces in the core also,
>> and hopefully make them consistent with these EEH events.
> We also need to be careful about what specific EEH activity we are
> talking about, and if we bring into the picture things like DPDK, it
> gets even more murky...
>
> The basic way EEH is supposed to work for recovery (minus all sort of
> implementation nasties which hopefully Russell and Sam are trying to
> cleanup and fix) is that either:
>
> - The driver of the device has recovery callbacks, in which
> case the driver participates in the recovery process, the device
> doesn't "go away" (though it shouldn't be accessed during that process
> by other entities, userspace originated config space could be a problem
> and needs to be blocked...). The recovery typically involves a reset of
> the device but in sync with the driver.
>
> - The driver doesn't have the callbacks. In this case, we
> simulate an unplug, reset the device, and replug.
>
> So it makes sense for the second case to emit the same uevents as a
> normal PCI(e) hotplug.
>
> For the former case I'm less sure.... Do we really need userspace to be
> notified ? If yes, what for precisely ?
In pSeries SR-IOV environment the management console might need to apply
certain configuration changes to the PF driver after it has been recovered
and before the VF drivers are allowed to resume their recovery path.
I could not think of another way to notify user space of these events.
I made this assumption because I saw there were no uevents added when
the device goes offline and come back online in EEH code. It was my
intention to make the event as generic as possible in EEH component,
therefore, making this change independent of pSeries SR-IOV.
- Juan
^ permalink raw reply
* Re: [PATCH v2 2/7] powerpc/kernel: Add uevents in EEH error/resume
From: Juan Alvarez @ 2017-12-21 3:04 UTC (permalink / raw)
To: Russell Currey, Bjorn Helgaas, Bryant G. Ly
Cc: benh, paulus, mpe, seroyer, alex.williamson, aik, linux-pci,
linuxppc-dev, bodong, eli, saeedm, Keith Busch, Gabriele Paoloni,
Dongdong Liu
In-Reply-To: <1513659576.2151.6.camel@russell.cc>
On 12/18/17 10:59 PM, Russell Currey wrote:
> On Mon, 2017-12-18 at 22:50 -0600, Bjorn Helgaas wrote:
>> [+cc Keith, Gabriele, Dongdong]
>>
>> On Mon, Dec 18, 2017 at 04:38:03PM -0600, Bryant G. Ly wrote:
>>> Devices can go offline when EEH is reported. This patch adds
>>> a change to the kernel object and lets udev know of error.
>>> When device resumes a change is also set reporting device as
>>> online. Therefore, EEH events are better propagated to user
>>> space for devices in powerpc arch.
>> I'm on vacation and can't review this in detail, but I wonder if you
>> can compare this with the uevents we emit for DPC, AER, and hotplug
>> events (if any). I hope we don't end up with userspace having to be
>> aware of the differences between EEH, DPC, AER, etc.
>>
>> From a very quick look, I only see a few uevents even mentioned in
>> drivers/pci: KOBJ_ADD in __pci_hp_register() and KOBJ_CHANGE in the
>> SR-IOV code. I'm worried that we're missing some important uevents
>> in
>> the PCI core.
The only place where I see the KOBJ_REMOVE being used is when the device is
removed in pci_destroy_dev -> device_del whic will be called implicitly
in permanent failure path of EEH code
>> That's not an argument against what you're doing here;
>> it just would be nice to fill in any missing pieces in the core also,
>> and hopefully make them consistent with these EEH events.
> I don't think this needs to be particularly complex, could we get away
> with events for when devices do the following?
>
> - begin recovery
> - successfully recover
> - fail recovery
If there are no objections in the on going review of this patch
I can change them to these names:
- BEGIN_RECOVERY
- SUCCESSFUL_RECOVERY
- FAILED_RECOVERY
>
> It might be worthwhile sorting out some consistent, non-EEH-specific
> naming, and then other device error recovery systems can do the same
> later.
>
Do you have a more consistent naming in mind for these events?
- Juan
^ permalink raw reply
* RE: [PATCH v3 0/3] create sysfs representation of ACPI HMAT
From: Elliott, Robert (Persistent Memory) @ 2017-12-21 1:41 UTC (permalink / raw)
To: Ross Zwisler, Matthew Wilcox
Cc: Michal Hocko, Box, David E, Dave Hansen, Zheng, Lv,
linux-nvdimm@lists.01.org, Rafael J. Wysocki, Anaczkowski, Lukasz,
Moore, Robert, linux-acpi@vger.kernel.org, Odzioba, Lukasz,
Schmauss, Erik, Len Brown, John Hubbard,
linuxppc-dev@lists.ozlabs.org, Jerome Glisse, devel@acpica.org,
Kogut, Jaroslaw, linux-mm@kvack.org, Koss, Marcin,
linux-api@vger.kernel.org, Brice Goglin, Nachimuthu, Murugasamy,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Koziej, Artur,
Lahtinen, Joonas, Andrew Morton, Tim Chen
In-Reply-To: <20171220211350.GA2688@linux.intel.com>
> -----Original Message-----
> From: Linux-nvdimm [mailto:linux-nvdimm-bounces@lists.01.org] On Behalf O=
f
> Ross Zwisler
...
>=20
> On Wed, Dec 20, 2017 at 10:19:37AM -0800, Matthew Wilcox wrote:
...
> > initiator is a CPU? I'd have expected you to expose a memory controlle=
r
> > abstraction rather than re-use storage terminology.
>=20
> Yea, I agree that at first blush it seems weird. It turns out that
> looking at it in sort of a storage initiator/target way is beneficial,
> though, because it allows us to cut down on the number of data values
> we need to represent.
>=20
> For example the SLIT, which doesn't differentiate between initiator and
> target proximity domains (and thus nodes) always represents a system
> with N proximity domains using a NxN distance table. This makes sense
> if every node contains both CPUs and memory.
>=20
> With the introduction of the HMAT, though, we can have memory-only
> initiator nodes and we can explicitly associate them with their local=20
> CPU. This is necessary so that we can separate memory with different
> performance characteristics (HBM vs normal memory vs persistent memory,
> for example) that are all attached to the same CPU.
>=20
> So, say we now have a system with 4 CPUs, and each of those CPUs has 3
> different types of memory attached to it. We now have 16 total proximity
> domains, 4 CPU and 12 memory.
The CPU cores that make up a node can have performance restrictions of
their own; for example, they might max out at 10 GB/s even though the
memory controller supports 120 GB/s (meaning you need to use 12 cores
on the node to fully exercise memory). It'd be helpful to report this,
so software can decide how many cores to use for bandwidth-intensive work.
> If we represent this with the SLIT we end up with a 16 X 16 distance tabl=
e
> (256 entries), most of which don't matter because they are memory-to-
> memory distances which don't make sense.
>=20
> In the HMAT, though, we separate out the initiators and the targets and
> put them into separate lists. (See 5.2.27.4 System Locality Latency and
> Bandwidth Information Structure in ACPI 6.2 for details.) So, this same
> config in the HMAT only has 4*12=3D48 performance values of each type, al=
l
> of which convey meaningful information.
>=20
> The HMAT indeed even uses the storage "initiator" and "target"
> terminology. :)
Centralized DMA engines (e.g., as used by the "DMA based blk-mq pmem
driver") have performance differences too. A CPU might include
CPU cores that reach 10 GB/s, DMA engines that reach 60 GB/s, and
memory controllers that reach 120 GB/s. I guess these would be
represented as extra initiators on the node?
---
Robert Elliott, HPE Persistent Memory
^ permalink raw reply
* Re: [-next PATCH 4/4] treewide: Use DEVICE_ATTR_WO
From: Zhang Rui @ 2017-12-21 0:50 UTC (permalink / raw)
To: Joe Perches, Borislav Petkov, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Thomas Falcon, John Allen,
Inaky Perez-Gonzalez, linux-wimax, James Smart, Dick Kennedy,
Eduardo Valentin
Cc: Martin Schwidefsky, Heiko Carstens, Thomas Gleixner,
H. Peter Anvin, x86, Dmitry Torokhov, James E.J. Bottomley,
Martin K. Petersen, linux-s390, linux-kernel, linux-input, netdev,
linuxppc-dev, linux-scsi, linux-pm
In-Reply-To: <fa30f1ad73f76dafff816df40cacffe613aa2f48.1513706702.git.joe@perches.com>
On Tue, 2017-12-19 at 10:15 -0800, Joe Perches wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_WO where possible.
>
> Done with perl script:
>
> $ git grep -w --name-only DEVICE_ATTR | \
> xargs perl -i -e 'local $/; while (<>) {
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IWUSR\s*|\s*0200\s*)\)?
> \s*,\s*NULL\s*,\s*\s_store\s*\)/DEVICE_ATTR_WO(\1)/g; print;}'
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> arch/s390/kernel/smp.c | 2 +-
> arch/x86/kernel/cpu/microcode/core.c | 2 +-
> drivers/input/touchscreen/elants_i2c.c | 2 +-
> drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
> drivers/net/wimax/i2400m/sysfs.c | 3 +--
> drivers/scsi/lpfc/lpfc_attr.c | 3 +--
> drivers/thermal/thermal_sysfs.c | 2 +-
For the thermal part,
Acked-by: Zhang Rui <rui.zhang@intel.com>
thanks,
rui
> 7 files changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
> index b8c1a85bcf2d..a919b2f0141d 100644
> --- a/arch/s390/kernel/smp.c
> +++ b/arch/s390/kernel/smp.c
> @@ -1151,7 +1151,7 @@ static ssize_t __ref rescan_store(struct device
> *dev,
> rc = smp_rescan_cpus();
> return rc ? rc : count;
> }
> -static DEVICE_ATTR(rescan, 0200, NULL, rescan_store);
> +static DEVICE_ATTR_WO(rescan);
> #endif /* CONFIG_HOTPLUG_CPU */
>
> static int __init s390_smp_init(void)
> diff --git a/arch/x86/kernel/cpu/microcode/core.c
> b/arch/x86/kernel/cpu/microcode/core.c
> index c4fa4a85d4cb..09c74b0560dd 100644
> --- a/arch/x86/kernel/cpu/microcode/core.c
> +++ b/arch/x86/kernel/cpu/microcode/core.c
> @@ -560,7 +560,7 @@ static ssize_t pf_show(struct device *dev,
> return sprintf(buf, "0x%x\n", uci->cpu_sig.pf);
> }
>
> -static DEVICE_ATTR(reload, 0200, NULL, reload_store);
> +static DEVICE_ATTR_WO(reload);
> static DEVICE_ATTR(version, 0400, version_show, NULL);
> static DEVICE_ATTR(processor_flags, 0400, pf_show, NULL);
>
> diff --git a/drivers/input/touchscreen/elants_i2c.c
> b/drivers/input/touchscreen/elants_i2c.c
> index a458e5ec9e41..819213e88f32 100644
> --- a/drivers/input/touchscreen/elants_i2c.c
> +++ b/drivers/input/touchscreen/elants_i2c.c
> @@ -1000,7 +1000,7 @@ static ssize_t show_iap_mode(struct device
> *dev,
> "Normal" : "Recovery");
> }
>
> -static DEVICE_ATTR(calibrate, S_IWUSR, NULL, calibrate_store);
> +static DEVICE_ATTR_WO(calibrate);
> static DEVICE_ATTR(iap_mode, S_IRUGO, show_iap_mode, NULL);
> static DEVICE_ATTR(update_fw, S_IWUSR, NULL, write_update_fw);
>
> diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
> b/drivers/net/ethernet/ibm/ibmvnic.c
> index 1dc4aef37d3a..42b96e1a1b13 100644
> --- a/drivers/net/ethernet/ibm/ibmvnic.c
> +++ b/drivers/net/ethernet/ibm/ibmvnic.c
> @@ -4411,7 +4411,7 @@ static ssize_t failover_store(struct device
> *dev, struct device_attribute *attr,
> return count;
> }
>
> -static DEVICE_ATTR(failover, 0200, NULL, failover_store);
> +static DEVICE_ATTR_WO(failover);
>
> static unsigned long ibmvnic_get_desired_dma(struct vio_dev *vdev)
> {
> diff --git a/drivers/net/wimax/i2400m/sysfs.c
> b/drivers/net/wimax/i2400m/sysfs.c
> index 1237109f251a..8c67df11105c 100644
> --- a/drivers/net/wimax/i2400m/sysfs.c
> +++ b/drivers/net/wimax/i2400m/sysfs.c
> @@ -65,8 +65,7 @@ ssize_t i2400m_idle_timeout_store(struct device
> *dev,
> }
>
> static
> -DEVICE_ATTR(i2400m_idle_timeout, S_IWUSR,
> - NULL, i2400m_idle_timeout_store);
> +DEVICE_ATTR_WO(i2400m_idle_timeout);
>
> static
> struct attribute *i2400m_dev_attrs[] = {
> diff --git a/drivers/scsi/lpfc/lpfc_attr.c
> b/drivers/scsi/lpfc/lpfc_attr.c
> index 517ff203cfde..6ddaf51a23f6 100644
> --- a/drivers/scsi/lpfc/lpfc_attr.c
> +++ b/drivers/scsi/lpfc/lpfc_attr.c
> @@ -2418,8 +2418,7 @@ lpfc_soft_wwn_enable_store(struct device *dev,
> struct device_attribute *attr,
>
> return count;
> }
> -static DEVICE_ATTR(lpfc_soft_wwn_enable, S_IWUSR, NULL,
> - lpfc_soft_wwn_enable_store);
> +static DEVICE_ATTR_WO(lpfc_soft_wwn_enable);
>
> /**
> * lpfc_soft_wwpn_show - Return the cfg soft ww port name of the
> adapter
> diff --git a/drivers/thermal/thermal_sysfs.c
> b/drivers/thermal/thermal_sysfs.c
> index 2bc964392924..ba81c9080f6e 100644
> --- a/drivers/thermal/thermal_sysfs.c
> +++ b/drivers/thermal/thermal_sysfs.c
> @@ -317,7 +317,7 @@ emul_temp_store(struct device *dev, struct
> device_attribute *attr,
>
> return ret ? ret : count;
> }
> -static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);
> +static DEVICE_ATTR_WO(emul_temp);
> #endif
>
> static ssize_t
^ permalink raw reply
* Re: [PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface
From: Benjamin Herrenschmidt @ 2017-12-20 22:49 UTC (permalink / raw)
To: Ram Pai
Cc: Dave Hansen, mpe, mingo, akpm, corbet, arnd, linuxppc-dev,
linux-mm, x86, linux-arch, linux-doc, linux-kselftest,
linux-kernel, paulus, khandual, aneesh.kumar, bsingharora, hbabu,
mhocko, bauerman, ebiederm
In-Reply-To: <20171220175022.GB5619@ram.oc3035372033.ibm.com>
On Wed, 2017-12-20 at 09:50 -0800, Ram Pai wrote:
> The argument against this patch is -- it should not be baked into
> the ABI as yet, since we do not have clarity on what applications need.
>
> As it stands today the only way to figure out the information from
> userspace is by probing the kernel through calls to sys_pkey_alloc().
>
> AT_HWCAP can be used, but that will certainly not be capable of
> providing all the information that userspace might expect.
>
> Your thoughts?
Well, there's one well known application wanting that whole keys
business, so why not ask them what works for them ?
In the meantime, that shouldn't block the rest of the patches.
Cheers,
Ben.
^ permalink raw reply
* Re: ps3: Improve a size determination in five functions
From: Geoff Levand @ 2017-12-21 0:05 UTC (permalink / raw)
To: SF Markus Elfring, linuxppc-dev
Cc: Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras, LKML,
kernel-janitors
In-Reply-To: <2003adbe-1849-b689-40bf-00e02ae4e01e@users.sourceforge.net>
On 12/20/2017 01:20 PM, SF Markus Elfring wrote:
>> o Your patch fixes no bug nor replaces any depreciated feature.
>
> How do you think about information from the section “14) Allocating memory”
> in the document “coding-style.rst” for the shown source code transformation?
In terms of importance, I would put maintenance and user support as more
important than coding style.
Regarding Section 14 of coding-style.rst specifically, as I mentioned the
PS3 support is over 10 years old. I don't expect a change to the type of
any structures. If there are type changes, then we can update the
allocation size parameters at that time.
-Geoff
^ permalink raw reply
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name"
From: Rasmus Villemoes @ 2017-12-20 23:37 UTC (permalink / raw)
To: Michael Ellerman
Cc: Johannes Berg, netdev@vger.kernel.org, Jouni Malinen,
Johannes Berg, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <87vah29a1m.fsf@concordia.ellerman.id.au>
On Tue, Dec 19 2017, Michael Ellerman <michael@concordia.ellerman.id.au> wrote:
> Hi Johannes,
>
>> From: Johannes Berg <johannes.berg@intel.com>
>>
>> This reverts commit d6f295e9def0; some userspace (in the case
>
> This revert seems to have broken networking on one of my powerpc
> machines, according to git bisect.
>
> The symptom is DHCP fails and I don't get a link, I didn't dig any
> further than that. I can if it's helpful.
>
> I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name
> is now the same as dev_alloc_name_ns") only makes sense while
> d6f295e9def0 remains in the tree.
I'm sorry about all of this, I really didn't think there would be such
consequences of changing an errno return. Indeed, d6f29 was preparation
for unifying the two functions that do the exact same thing (and how we
ever got into that situation is somewhat unclear), except for
their behaviour in the case the requested name already exists. So one of
the two interfaces had to change its return value, and as I wrote, I
thought EEXIST was the saner choice when an explicit name (no %d) had
been requested.
> ie. before the entire series, dev_get_valid_name() would return EEXIST,
> and that was retained when 87c320e51519 was merged, but now that
> d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE.
>
> I can get the network up again if I also revert 87c320e51519 ("net:
> core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with
> the gross patch below.
I don't think changing -ENFILE to -EEXIST would be right either, since
dev_get_valid_name() used to be able to return both (-EEXIST in the case
where there's no %d, -ENFILE in the case where we end up calling
dev_alloc_name_ns()). If anything, we could do the check for the old
-EEXIST condition first, and then call dev_alloc_name_ns(). But I'm also
fine with reverting.
Again, sorry :(
Rasmus
^ permalink raw reply
* Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT
From: Ross Zwisler @ 2017-12-20 22:41 UTC (permalink / raw)
To: Dan Williams
Cc: Ross Zwisler, Matthew Wilcox, Dave Hansen, Michal Hocko,
linux-kernel@vger.kernel.org, Anaczkowski, Lukasz, Box, David E,
Kogut, Jaroslaw, Koss, Marcin, Koziej, Artur, Lahtinen, Joonas,
Moore, Robert, Nachimuthu, Murugasamy, Odzioba, Lukasz,
Rafael J. Wysocki, Rafael J. Wysocki, Schmauss, Erik,
Verma, Vishal L, Zheng, Lv, Andrew Morton, Balbir Singh,
Brice Goglin, Jerome Glisse, John Hubbard, Len Brown, Tim Chen,
devel, Linux ACPI, Linux MM, linux-nvdimm@lists.01.org, Linux API,
linuxppc-dev
In-Reply-To: <CAPcyv4gTknp=0yQnVrrB5Ui+mJE_x-wdkV86UD4hsYnx3CAjfA@mail.gmail.com>
On Wed, Dec 20, 2017 at 02:29:56PM -0800, Dan Williams wrote:
> On Wed, Dec 20, 2017 at 1:24 PM, Ross Zwisler
> <ross.zwisler@linux.intel.com> wrote:
> > On Wed, Dec 20, 2017 at 01:16:49PM -0800, Matthew Wilcox wrote:
> >> On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote:
> >> > On 12/20/2017 10:19 AM, Matthew Wilcox wrote:
> >> > > I don't know what the right interface is, but my laptop has a set of
> >> > > /sys/devices/system/memory/memoryN/ directories. Perhaps this is the
> >> > > right place to expose write_bw (etc).
> >> >
> >> > Those directories are already too redundant and wasteful. I think we'd
> >> > really rather not add to them. In addition, it's technically possible
> >> > to have a memory section span NUMA nodes and have different performance
> >> > properties, which make it impossible to represent there.
> >> >
> >> > In any case, ACPI PXM's (Proximity Domains) are guaranteed to have
> >> > uniform performance properties in the HMAT, and we just so happen to
> >> > always create one NUMA node per PXM. So, NUMA nodes really are a good fit.
> >>
> >> I think you're missing my larger point which is that I don't think this
> >> should be exposed to userspace as an ACPI feature. Because if you do,
> >> then it'll also be exposed to userspace as an openfirmware feature.
> >> And sooner or later a devicetree feature. And then writing a portable
> >> program becomes an exercise in suffering.
> >>
> >> So, what's the right place in sysfs that isn't tied to ACPI? A new
> >> directory or set of directories under /sys/devices/system/memory/ ?
> >
> > Oh, the current location isn't at all tied to acpi except that it happens to
> > be named 'hmat'. When it was all named 'hmem' it was just:
> >
> > /sys/devices/system/hmem
> >
> > Which has no ACPI-isms at all. I'm happy to move it under
> > /sys/devices/system/memory/hmat if that's helpful, but I think we still have
> > the issue that the data represented therein is still pulled right from the
> > HMAT, and I don't know how to abstract it into something more platform
> > agnostic until I know what data is provided by those other platforms.
> >
> > For example, the HMAT provides latency information and bandwidth information
> > for both reads and writes. Will the devicetree/openfirmware/etc version have
> > this same info, or will it be just different enough that it won't translate
> > into whatever I choose to stick in sysfs?
>
> For the initial implementation do we need to have a representation of
> all the performance data? Given that
> /sys/devices/system/node/nodeX/distance is the only generic
> performance attribute published by the kernel today it is already the
> case that applications that need to target specific memories need to
> go parse information that is not provided by the kernel by default.
> The question is can those specialized applications stay special and go
> parse the platform specific data sources, like raw HMAT, directly, or
> do we expect general purpose applications to make use of this data? I
> think a firmware-id to numa-node translation facility
> (/sys/devices/system/node/nodeX/fwid) is a simple start that we can
> build on with more information as specific use cases arise.
We don't represent all the performance data, we only represent the data for
local initiator/target pairs. I do think that this is useful to have in sysfs
because it provides a way to easily answer the most commonly asked questions
(or at least what I'm guessing will be the most commmonly asked queststions),
i.e. "given a CPU, what are the speeds of the various types of memory attached
to it", and "given a chunk of memory, how fast is it and to which CPU is it
local"? By providing this base level of information I'm hoping to prevent
most applications from having to parse the HMAT directly.
The question of whether or not to include this local performance information
was one of the main questions of the initial RFC patch series, and I did get
feedback (albiet off-list) that the local performance information was
valuable to at least some users. I did intentionally structure my (now very
short) set so that the performance information was added as a separate patch,
so we can get to the place you're talking about where we only provide firmware
id <=> proximity domain mappings by just leaving off the last patch in the
series.
I'm personally still of the opinion though that this last patch does add
value.
^ permalink raw reply
* Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT
From: Dan Williams @ 2017-12-20 22:29 UTC (permalink / raw)
To: Ross Zwisler
Cc: Matthew Wilcox, Dave Hansen, Michal Hocko,
linux-kernel@vger.kernel.org, Anaczkowski, Lukasz, Box, David E,
Kogut, Jaroslaw, Koss, Marcin, Koziej, Artur, Lahtinen, Joonas,
Moore, Robert, Nachimuthu, Murugasamy, Odzioba, Lukasz,
Rafael J. Wysocki, Rafael J. Wysocki, Schmauss, Erik,
Verma, Vishal L, Zheng, Lv, Andrew Morton, Balbir Singh,
Brice Goglin, Jerome Glisse, John Hubbard, Len Brown, Tim Chen,
devel, Linux ACPI, Linux MM, linux-nvdimm@lists.01.org, Linux API,
linuxppc-dev
In-Reply-To: <20171220212408.GA8308@linux.intel.com>
On Wed, Dec 20, 2017 at 1:24 PM, Ross Zwisler
<ross.zwisler@linux.intel.com> wrote:
> On Wed, Dec 20, 2017 at 01:16:49PM -0800, Matthew Wilcox wrote:
>> On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote:
>> > On 12/20/2017 10:19 AM, Matthew Wilcox wrote:
>> > > I don't know what the right interface is, but my laptop has a set of
>> > > /sys/devices/system/memory/memoryN/ directories. Perhaps this is the
>> > > right place to expose write_bw (etc).
>> >
>> > Those directories are already too redundant and wasteful. I think we'd
>> > really rather not add to them. In addition, it's technically possible
>> > to have a memory section span NUMA nodes and have different performance
>> > properties, which make it impossible to represent there.
>> >
>> > In any case, ACPI PXM's (Proximity Domains) are guaranteed to have
>> > uniform performance properties in the HMAT, and we just so happen to
>> > always create one NUMA node per PXM. So, NUMA nodes really are a good fit.
>>
>> I think you're missing my larger point which is that I don't think this
>> should be exposed to userspace as an ACPI feature. Because if you do,
>> then it'll also be exposed to userspace as an openfirmware feature.
>> And sooner or later a devicetree feature. And then writing a portable
>> program becomes an exercise in suffering.
>>
>> So, what's the right place in sysfs that isn't tied to ACPI? A new
>> directory or set of directories under /sys/devices/system/memory/ ?
>
> Oh, the current location isn't at all tied to acpi except that it happens to
> be named 'hmat'. When it was all named 'hmem' it was just:
>
> /sys/devices/system/hmem
>
> Which has no ACPI-isms at all. I'm happy to move it under
> /sys/devices/system/memory/hmat if that's helpful, but I think we still have
> the issue that the data represented therein is still pulled right from the
> HMAT, and I don't know how to abstract it into something more platform
> agnostic until I know what data is provided by those other platforms.
>
> For example, the HMAT provides latency information and bandwidth information
> for both reads and writes. Will the devicetree/openfirmware/etc version have
> this same info, or will it be just different enough that it won't translate
> into whatever I choose to stick in sysfs?
For the initial implementation do we need to have a representation of
all the performance data? Given that
/sys/devices/system/node/nodeX/distance is the only generic
performance attribute published by the kernel today it is already the
case that applications that need to target specific memories need to
go parse information that is not provided by the kernel by default.
The question is can those specialized applications stay special and go
parse the platform specific data sources, like raw HMAT, directly, or
do we expect general purpose applications to make use of this data? I
think a firmware-id to numa-node translation facility
(/sys/devices/system/node/nodeX/fwid) is a simple start that we can
build on with more information as specific use cases arise.
^ permalink raw reply
* Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT
From: Ross Zwisler @ 2017-12-20 21:24 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Dave Hansen, Ross Zwisler, Michal Hocko, linux-kernel,
Anaczkowski, Lukasz, Box, David E, Kogut, Jaroslaw, Koss, Marcin,
Koziej, Artur, Lahtinen, Joonas, Moore, Robert,
Nachimuthu, Murugasamy, Odzioba, Lukasz, Rafael J. Wysocki,
Rafael J. Wysocki, Schmauss, Erik, Verma, Vishal L, Zheng, Lv,
Andrew Morton, Balbir Singh, Brice Goglin, Dan Williams,
Jerome Glisse, John Hubbard, Len Brown, Tim Chen, devel,
linux-acpi, linux-mm, linux-nvdimm, linux-api, linuxppc-dev
In-Reply-To: <20171220211649.GA32200@bombadil.infradead.org>
On Wed, Dec 20, 2017 at 01:16:49PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote:
> > On 12/20/2017 10:19 AM, Matthew Wilcox wrote:
> > > I don't know what the right interface is, but my laptop has a set of
> > > /sys/devices/system/memory/memoryN/ directories. Perhaps this is the
> > > right place to expose write_bw (etc).
> >
> > Those directories are already too redundant and wasteful. I think we'd
> > really rather not add to them. In addition, it's technically possible
> > to have a memory section span NUMA nodes and have different performance
> > properties, which make it impossible to represent there.
> >
> > In any case, ACPI PXM's (Proximity Domains) are guaranteed to have
> > uniform performance properties in the HMAT, and we just so happen to
> > always create one NUMA node per PXM. So, NUMA nodes really are a good fit.
>
> I think you're missing my larger point which is that I don't think this
> should be exposed to userspace as an ACPI feature. Because if you do,
> then it'll also be exposed to userspace as an openfirmware feature.
> And sooner or later a devicetree feature. And then writing a portable
> program becomes an exercise in suffering.
>
> So, what's the right place in sysfs that isn't tied to ACPI? A new
> directory or set of directories under /sys/devices/system/memory/ ?
Oh, the current location isn't at all tied to acpi except that it happens to
be named 'hmat'. When it was all named 'hmem' it was just:
/sys/devices/system/hmem
Which has no ACPI-isms at all. I'm happy to move it under
/sys/devices/system/memory/hmat if that's helpful, but I think we still have
the issue that the data represented therein is still pulled right from the
HMAT, and I don't know how to abstract it into something more platform
agnostic until I know what data is provided by those other platforms.
For example, the HMAT provides latency information and bandwidth information
for both reads and writes. Will the devicetree/openfirmware/etc version have
this same info, or will it be just different enough that it won't translate
into whatever I choose to stick in sysfs?
^ permalink raw reply
* Re: ps3: Improve a size determination in five functions
From: SF Markus Elfring @ 2017-12-20 21:20 UTC (permalink / raw)
To: Geoff Levand, linuxppc-dev
Cc: Benjamin Herrenschmidt, Michael Ellerman, Paul Mackerras, LKML,
kernel-janitors
In-Reply-To: <cd0c8519-85d0-0ce5-14a1-54a573234a98@infradead.org>
> Some observations:
>
> o Your patch fixes no bug nor replaces any depreciated feature.
How do you think about information from the section “14) Allocating memory”
in the document “coding-style.rst” for the shown source code transformation?
> o There will be no functional change; …
Yes. - The suggested adjustment should work in this way generally.
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT
From: Matthew Wilcox @ 2017-12-20 21:16 UTC (permalink / raw)
To: Dave Hansen
Cc: Ross Zwisler, Michal Hocko, linux-kernel, Anaczkowski, Lukasz,
Box, David E, Kogut, Jaroslaw, Koss, Marcin, Koziej, Artur,
Lahtinen, Joonas, Moore, Robert, Nachimuthu, Murugasamy,
Odzioba, Lukasz, Rafael J. Wysocki, Rafael J. Wysocki,
Schmauss, Erik, Verma, Vishal L, Zheng, Lv, Andrew Morton,
Balbir Singh, Brice Goglin, Dan Williams, Jerome Glisse,
John Hubbard, Len Brown, Tim Chen, devel, linux-acpi, linux-mm,
linux-nvdimm, linux-api, linuxppc-dev
In-Reply-To: <2da89d31-27a3-34ab-2dbb-92403c8215ec@intel.com>
On Wed, Dec 20, 2017 at 12:22:21PM -0800, Dave Hansen wrote:
> On 12/20/2017 10:19 AM, Matthew Wilcox wrote:
> > I don't know what the right interface is, but my laptop has a set of
> > /sys/devices/system/memory/memoryN/ directories. Perhaps this is the
> > right place to expose write_bw (etc).
>
> Those directories are already too redundant and wasteful. I think we'd
> really rather not add to them. In addition, it's technically possible
> to have a memory section span NUMA nodes and have different performance
> properties, which make it impossible to represent there.
>
> In any case, ACPI PXM's (Proximity Domains) are guaranteed to have
> uniform performance properties in the HMAT, and we just so happen to
> always create one NUMA node per PXM. So, NUMA nodes really are a good fit.
I think you're missing my larger point which is that I don't think this
should be exposed to userspace as an ACPI feature. Because if you do,
then it'll also be exposed to userspace as an openfirmware feature.
And sooner or later a devicetree feature. And then writing a portable
program becomes an exercise in suffering.
So, what's the right place in sysfs that isn't tied to ACPI? A new
directory or set of directories under /sys/devices/system/memory/ ?
^ permalink raw reply
* Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT
From: Ross Zwisler @ 2017-12-20 21:13 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ross Zwisler, Michal Hocko, linux-kernel, Anaczkowski, Lukasz,
Box, David E, Kogut, Jaroslaw, Koss, Marcin, Koziej, Artur,
Lahtinen, Joonas, Moore, Robert, Nachimuthu, Murugasamy,
Odzioba, Lukasz, Rafael J. Wysocki, Rafael J. Wysocki,
Schmauss, Erik, Verma, Vishal L, Zheng, Lv, Andrew Morton,
Balbir Singh, Brice Goglin, Dan Williams, Dave Hansen,
Jerome Glisse, John Hubbard, Len Brown, Tim Chen, devel,
linux-acpi, linux-mm, linux-nvdimm, linux-api, linuxppc-dev
In-Reply-To: <20171220181937.GB12236@bombadil.infradead.org>
On Wed, Dec 20, 2017 at 10:19:37AM -0800, Matthew Wilcox wrote:
> On Mon, Dec 18, 2017 at 01:35:47PM -0700, Ross Zwisler wrote:
> > What I'm hoping to do with this series is to just provide a sysfs
> > representation of the HMAT so that applications can know which NUMA nodes to
> > select with existing utilities like numactl. This series does not currently
> > alter any kernel behavior, it only provides a sysfs interface.
> >
> > Say for example you had a system with some high bandwidth memory (HBM), and
> > you wanted to use it for a specific application. You could use the sysfs
> > representation of the HMAT to figure out which memory target held your HBM.
> > You could do this by looking at the local bandwidth values for the various
> > memory targets, so:
> >
> > # grep . /sys/devices/system/hmat/mem_tgt*/local_init/write_bw_MBps
> > /sys/devices/system/hmat/mem_tgt2/local_init/write_bw_MBps:81920
> > /sys/devices/system/hmat/mem_tgt3/local_init/write_bw_MBps:40960
> > /sys/devices/system/hmat/mem_tgt4/local_init/write_bw_MBps:40960
> > /sys/devices/system/hmat/mem_tgt5/local_init/write_bw_MBps:40960
> >
> > and look for the one that corresponds to your HBM speed. (These numbers are
> > made up, but you get the idea.)
>
> Presumably ACPI-based platforms will not be the only ones who have the
> ability to expose different bandwidth memories in the future. I think
> we need a platform-agnostic way ... right, PowerPC people?
Hey Matthew,
Yep, this is where I started as well. My plan with my initial implementation
was to try and make the sysfs representation as platform agnostic as possible,
and just have the ACPI HMAT as one of the many places to gather the data
needed to populate sysfs.
However, as I began coding the implementation became very specific to the
HMAT, probably because I don't know of way that this type of info is
represented on another platform. John Hubbard noticed the same thing and
asked me to s/HMEM/HMAT/ everywhere and just make it HMAT specific, and to
prevent it from being confused with the HMM work:
https://lkml.org/lkml/2017/7/7/33
https://lkml.org/lkml/2017/7/7/442
I'm open to making it more platform agnostic if I can get my hands on a
parallel effort in another platform and tease out the commonality, but trying
to do that without a second example hasn't worked out. If we don't have a
good second example right now I think maybe we should put this in and then
merge it with the second example when it comes along.
> I don't know what the right interface is, but my laptop has a set of
> /sys/devices/system/memory/memoryN/ directories. Perhaps this is the
> right place to expose write_bw (etc).
>
> > Once you know the NUMA node of your HBM, you can figure out the NUMA node of
> > it's local initiator:
> >
> > # ls -d /sys/devices/system/hmat/mem_tgt2/local_init/mem_init*
> > /sys/devices/system/hmat/mem_tgt2/local_init/mem_init0
> >
> > So, in our made-up example our HBM is located in numa node 2, and the local
> > CPU for that HBM is at numa node 0.
>
> initiator is a CPU? I'd have expected you to expose a memory controller
> abstraction rather than re-use storage terminology.
Yea, I agree that at first blush it seems weird. It turns out that looking at
it in sort of a storage initiator/target way is beneficial, though, because it
allows us to cut down on the number of data values we need to represent.
For example the SLIT, which doesn't differentiate between initiator and target
proximity domains (and thus nodes) always represents a system with N proximity
domains using a NxN distance table. This makes sense if every node contains
both CPUs and memory.
With the introduction of the HMAT, though, we can have memory-only initiator
nodes and we can explicitly associate them with their local CPU. This is
necessary so that we can separate memory with different performance
characteristics (HBM vs normal memory vs persistent memory, for example) that
are all attached to the same CPU.
So, say we now have a system with 4 CPUs, and each of those CPUs has 3
different types of memory attached to it. We now have 16 total proximity
domains, 4 CPU and 12 memory.
If we represent this with the SLIT we end up with a 16 X 16 distance table
(256 entries), most of which don't matter because they are memory-to-memory
distances which don't make sense.
In the HMAT, though, we separate out the initiators and the targets and put
them into separate lists. (See 5.2.27.4 System Locality Latency and Bandwidth
Information Structure in ACPI 6.2 for details.) So, this same config in the
HMAT only has 4*12=48 performance values of each type, all of which convey
meaningful information.
The HMAT indeed even uses the storage "initiator" and "target" terminology. :)
^ permalink raw reply
* Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT
From: Dave Hansen @ 2017-12-20 20:22 UTC (permalink / raw)
To: Matthew Wilcox, Ross Zwisler
Cc: Michal Hocko, linux-kernel, Anaczkowski, Lukasz, Box, David E,
Kogut, Jaroslaw, Koss, Marcin, Koziej, Artur, Lahtinen, Joonas,
Moore, Robert, Nachimuthu, Murugasamy, Odzioba, Lukasz,
Rafael J. Wysocki, Rafael J. Wysocki, Schmauss, Erik,
Verma, Vishal L, Zheng, Lv, Andrew Morton, Balbir Singh,
Brice Goglin, Dan Williams, Jerome Glisse, John Hubbard,
Len Brown, Tim Chen, devel, linux-acpi, linux-mm, linux-nvdimm,
linux-api, linuxppc-dev
In-Reply-To: <20171220181937.GB12236@bombadil.infradead.org>
On 12/20/2017 10:19 AM, Matthew Wilcox wrote:
> I don't know what the right interface is, but my laptop has a set of
> /sys/devices/system/memory/memoryN/ directories. Perhaps this is the
> right place to expose write_bw (etc).
Those directories are already too redundant and wasteful. I think we'd
really rather not add to them. In addition, it's technically possible
to have a memory section span NUMA nodes and have different performance
properties, which make it impossible to represent there.
In any case, ACPI PXM's (Proximity Domains) are guaranteed to have
uniform performance properties in the HMAT, and we just so happen to
always create one NUMA node per PXM. So, NUMA nodes really are a good fit.
^ permalink raw reply
* Re: [PATCH 2/2] ps3: Improve a size determination in five functions
From: Geoff Levand @ 2017-12-20 19:58 UTC (permalink / raw)
To: SF Markus Elfring, linuxppc-dev, Benjamin Herrenschmidt,
Michael Ellerman, Paul Mackerras
Cc: LKML, kernel-janitors
In-Reply-To: <7aed1208-aa55-edb6-54be-f47fb1498bfd@users.sourceforge.net>
Hi,
On 12/16/2017 05:54 AM, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 16 Dec 2017 14:21:04 +0100
>
> Replace the specification of data structures by variable references
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
After some thought, I've decided to reject this patch and others like
it because I feel it will make long term maintenance of the PS3 code
more difficult.
Some observations:
o Your patch fixes no bug nor replaces any depreciated feature.
o There will be no functional change; the generated binary
will be nearly identical.
o The PS3 kernel support is now over 10 years old.
o I need to continue support for a few old kernel versions,
specifically linux-3.15 and linux-2.6.30. That includes
keeping them working with new toolchain versions. I need
to back port fixes to these old kernels.
o When problems arise I sometimes need to use git bisect
back to old kernel versions. When I do the bisect I often
have fixes and local debug patches that I apply to the
bisected tree before building.
o Source code changes between versions causes patch conflicts
that need to be manually resolved. This can be error prone
and very time consuming on a long bisect session.
My decision to reject this patch and others like it is in
attempt to minimize the code maintenance effort. If you have
patches that fix bugs, upgrade depreciated features, or
generally improve functionality please submit them for
review.
-Geoff
^ permalink raw reply
* Re: [PATCH V5] cxl: Add support for ASB_Notify on POWER9
From: Frederic Barrat @ 2017-12-20 19:05 UTC (permalink / raw)
To: Christophe Lombard, linuxppc-dev, vaibhav, andrew.donnellan
In-Reply-To: <1513790844-27779-1-git-send-email-clombard@linux.vnet.ibm.com>
> --- a/drivers/misc/cxl/file.c
> +++ b/drivers/misc/cxl/file.c
> @@ -173,7 +173,7 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,
> * flags are set it's invalid
> */
> if (work.reserved1 || work.reserved2 || work.reserved3 ||
> - work.reserved4 || work.reserved5 || work.reserved6 ||
> + work.reserved4 || work.reserved5 ||
> (work.flags & ~CXL_START_WORK_ALL)) {
> rc = -EINVAL;
> goto out;
> @@ -248,7 +248,19 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,
> */
> smp_mb();
>
> - trace_cxl_attach(ctx, work.work_element_descriptor, work.num_interrupts, amr);
> + /* Assign a unique TIDR (thread id) for the current thread */
> + if (work.flags & CXL_START_WORK_TID) {
> + rc = cxl_context_thread_tidr(ctx);
> + if (rc)
We're already pretty deep and have allocated quite a few resources, we
we'd need to unwind (see error path below when the attach fails).
However, we cannot clear the thread TIDR register, so we need to be
careful that a user process cannot exhaust our limited pool of TIDs by
calling the attach ioctl with bogus arguments. Which should be easy to
do: attach the max number of contexts, and keep calling attach!
So we're going to need to figure out something to prevent that (define a
max allocation per context? with a value of 1 for now?)
> diff --git a/include/uapi/misc/cxl.h b/include/uapi/misc/cxl.h
> index 49e8fd0..3ea2d4b4 100644
> --- a/include/uapi/misc/cxl.h
> +++ b/include/uapi/misc/cxl.h
> @@ -20,20 +20,22 @@ struct cxl_ioctl_start_work {
> __u64 work_element_descriptor;
> __u64 amr;
> __s16 num_interrupts;
> - __s16 reserved1;
> - __s32 reserved2;
> + __s16 tid;
Should probably be unsigned.
Fred
> + __s32 reserved1;
> + __u64 reserved2;
> __u64 reserved3;
> __u64 reserved4;
> __u64 reserved5;
> - __u64 reserved6;
> };
>
> #define CXL_START_WORK_AMR 0x0000000000000001ULL
> #define CXL_START_WORK_NUM_IRQS 0x0000000000000002ULL
> #define CXL_START_WORK_ERR_FF 0x0000000000000004ULL
> +#define CXL_START_WORK_TID 0x0000000000000008ULL
> #define CXL_START_WORK_ALL (CXL_START_WORK_AMR |\
> CXL_START_WORK_NUM_IRQS |\
> - CXL_START_WORK_ERR_FF)
> + CXL_START_WORK_ERR_FF |\
> + CXL_START_WORK_TID)
>
>
> /* Possible modes that an afu can be in */
>
^ permalink raw reply
* Re: [PATCH v3 0/3] create sysfs representation of ACPI HMAT
From: Matthew Wilcox @ 2017-12-20 18:19 UTC (permalink / raw)
To: Ross Zwisler
Cc: Michal Hocko, linux-kernel, Anaczkowski, Lukasz, Box, David E,
Kogut, Jaroslaw, Koss, Marcin, Koziej, Artur, Lahtinen, Joonas,
Moore, Robert, Nachimuthu, Murugasamy, Odzioba, Lukasz,
Rafael J. Wysocki, Rafael J. Wysocki, Schmauss, Erik,
Verma, Vishal L, Zheng, Lv, Andrew Morton, Balbir Singh,
Brice Goglin, Dan Williams, Dave Hansen, Jerome Glisse,
John Hubbard, Len Brown, Tim Chen, devel, linux-acpi, linux-mm,
linux-nvdimm, linux-api, linuxppc-dev
In-Reply-To: <20171218203547.GA2366@linux.intel.com>
On Mon, Dec 18, 2017 at 01:35:47PM -0700, Ross Zwisler wrote:
> What I'm hoping to do with this series is to just provide a sysfs
> representation of the HMAT so that applications can know which NUMA nodes to
> select with existing utilities like numactl. This series does not currently
> alter any kernel behavior, it only provides a sysfs interface.
>
> Say for example you had a system with some high bandwidth memory (HBM), and
> you wanted to use it for a specific application. You could use the sysfs
> representation of the HMAT to figure out which memory target held your HBM.
> You could do this by looking at the local bandwidth values for the various
> memory targets, so:
>
> # grep . /sys/devices/system/hmat/mem_tgt*/local_init/write_bw_MBps
> /sys/devices/system/hmat/mem_tgt2/local_init/write_bw_MBps:81920
> /sys/devices/system/hmat/mem_tgt3/local_init/write_bw_MBps:40960
> /sys/devices/system/hmat/mem_tgt4/local_init/write_bw_MBps:40960
> /sys/devices/system/hmat/mem_tgt5/local_init/write_bw_MBps:40960
>
> and look for the one that corresponds to your HBM speed. (These numbers are
> made up, but you get the idea.)
Presumably ACPI-based platforms will not be the only ones who have the
ability to expose different bandwidth memories in the future. I think
we need a platform-agnostic way ... right, PowerPC people?
I don't know what the right interface is, but my laptop has a set of
/sys/devices/system/memory/memoryN/ directories. Perhaps this is the
right place to expose write_bw (etc).
> Once you know the NUMA node of your HBM, you can figure out the NUMA node of
> it's local initiator:
>
> # ls -d /sys/devices/system/hmat/mem_tgt2/local_init/mem_init*
> /sys/devices/system/hmat/mem_tgt2/local_init/mem_init0
>
> So, in our made-up example our HBM is located in numa node 2, and the local
> CPU for that HBM is at numa node 0.
initiator is a CPU? I'd have expected you to expose a memory controller
abstraction rather than re-use storage terminology.
^ permalink raw reply
* Re: [RFC PATCH 3/8] powerpc/64s: put the per-cpu data_offset in r14
From: Gabriel Paubert @ 2017-12-20 17:53 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20171220145206.12234-4-npiggin@gmail.com>
On Thu, Dec 21, 2017 at 12:52:01AM +1000, Nicholas Piggin wrote:
> Shifted left by 16 bits, so the low 16 bits of r14 remain available.
> This allows per-cpu pointers to be dereferenced with a single extra
> shift whereas previously it was a load and add.
> ---
> arch/powerpc/include/asm/paca.h | 5 +++++
> arch/powerpc/include/asm/percpu.h | 2 +-
> arch/powerpc/kernel/entry_64.S | 5 -----
> arch/powerpc/kernel/head_64.S | 5 +----
> arch/powerpc/kernel/setup_64.c | 11 +++++++++--
> 5 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index cd6a9a010895..4dd4ac69e84f 100644
> --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -35,6 +35,11 @@
>
> register struct paca_struct *local_paca asm("r13");
> #ifdef CONFIG_PPC_BOOK3S
> +/*
> + * The top 32-bits of r14 is used as the per-cpu offset, shifted by PAGE_SHIFT.
Top 32, really? It's 48 in later comments.
Gabriel
> + * The per-cpu could be moved completely to vmalloc space if we had large
> + * vmalloc page mapping? (no, must access it in real mode).
> + */
> register u64 local_r14 asm("r14");
> #endif
>
> diff --git a/arch/powerpc/include/asm/percpu.h b/arch/powerpc/include/asm/percpu.h
> index dce863a7635c..1e0d79d30eac 100644
> --- a/arch/powerpc/include/asm/percpu.h
> +++ b/arch/powerpc/include/asm/percpu.h
> @@ -12,7 +12,7 @@
>
> #include <asm/paca.h>
>
> -#define __my_cpu_offset local_paca->data_offset
> +#define __my_cpu_offset (local_r14 >> 16)
>
> #endif /* CONFIG_SMP */
> #endif /* __powerpc64__ */
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index 592e4b36065f..6b0e3ac311e8 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -262,11 +262,6 @@ system_call_exit:
> BEGIN_FTR_SECTION
> stdcx. r0,0,r1 /* to clear the reservation */
> END_FTR_SECTION_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
> - LOAD_REG_IMMEDIATE(r10, 0xdeadbeefULL << 32)
> - mfspr r11,SPRN_PIR
> - or r10,r10,r11
> - tdne r10,r14
> -
> andi. r6,r8,MSR_PR
> ld r4,_LINK(r1)
>
> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> index 5a9ec06eab14..cdb710f43681 100644
> --- a/arch/powerpc/kernel/head_64.S
> +++ b/arch/powerpc/kernel/head_64.S
> @@ -413,10 +413,7 @@ generic_secondary_common_init:
> b kexec_wait /* next kernel might do better */
>
> 2: SET_PACA(r13)
> - LOAD_REG_IMMEDIATE(r14, 0xdeadbeef << 32)
> - mfspr r3,SPRN_PIR
> - or r14,r14,r3
> - std r14,PACA_R14(r13)
> + ld r14,PACA_R14(r13)
>
> #ifdef CONFIG_PPC_BOOK3E
> addi r12,r13,PACA_EXTLB /* and TLB exc frame in another */
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 9a4c5bf35d92..f4a96ebb523a 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -192,8 +192,8 @@ static void __init fixup_boot_paca(void)
> get_paca()->data_offset = 0;
> /* Mark interrupts disabled in PACA */
> irq_soft_mask_set(IRQ_SOFT_MASK_STD);
> - /* Set r14 and paca_r14 to debug value */
> - get_paca()->r14 = (0xdeadbeefULL << 32) | mfspr(SPRN_PIR);
> + /* Set r14 and paca_r14 to zero */
> + get_paca()->r14 = 0;
> local_r14 = get_paca()->r14;
> }
>
> @@ -761,7 +761,14 @@ void __init setup_per_cpu_areas(void)
> for_each_possible_cpu(cpu) {
> __per_cpu_offset[cpu] = delta + pcpu_unit_offsets[cpu];
> paca[cpu].data_offset = __per_cpu_offset[cpu];
> +
> + BUG_ON(paca[cpu].data_offset & (PAGE_SIZE-1));
> + BUG_ON(paca[cpu].data_offset >= (1UL << (64 - 16)));
> +
> + /* The top 48 bits are used for per-cpu data */
> + paca[cpu].r14 |= paca[cpu].data_offset << 16;
> }
> + local_r14 = paca[smp_processor_id()].r14;
> }
> #endif
>
> --
> 2.15.0
^ permalink raw reply
* Re: [PATCH v4 2/2] cxl: read PHB indications from the device tree
From: Frederic Barrat @ 2017-12-20 18:02 UTC (permalink / raw)
To: Philippe Bergheaud, linuxppc-dev; +Cc: clombard, benh
In-Reply-To: <20171215134818.23864-2-felix@linux.vnet.ibm.com>
Le 15/12/2017 à 14:48, Philippe Bergheaud a écrit :
> Configure the P9 XSL_DSNCTL register with PHB indications found
> in the device tree, or else use legacy hard-coded values.
>
> Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
> ---
> Changelog:
>
> v2: New patch. Use the new device tree property "ibm,phb-indications".
>
> v3: No change.
>
> v4: No functional change.
> Drop cosmetic fix in comment.
>
> This patch depends on the following skiboot prerequisite:
>
> https://patchwork.ozlabs.org/patch/849162/
> ---
> drivers/misc/cxl/cxl.h | 2 +-
> drivers/misc/cxl/cxllib.c | 2 +-
> drivers/misc/cxl/pci.c | 40 +++++++++++++++++++++++++++++++++++-----
> 3 files changed, 37 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
> index e46a4062904a..5a6e9a921c2b 100644
> --- a/drivers/misc/cxl/cxl.h
> +++ b/drivers/misc/cxl/cxl.h
> @@ -1062,7 +1062,7 @@ int cxl_psl_purge(struct cxl_afu *afu);
> int cxl_calc_capp_routing(struct pci_dev *dev, u64 *chipid,
> u32 *phb_index, u64 *capp_unit_id);
> int cxl_slot_is_switched(struct pci_dev *dev);
> -int cxl_get_xsl9_dsnctl(u64 capp_unit_id, u64 *reg);
> +int cxl_get_xsl9_dsnctl(struct pci_dev *dev, u64 capp_unit_id, u64 *reg);
> u64 cxl_calculate_sr(bool master, bool kernel, bool real_mode, bool p9);
>
> void cxl_native_irq_dump_regs_psl9(struct cxl_context *ctx);
> diff --git a/drivers/misc/cxl/cxllib.c b/drivers/misc/cxl/cxllib.c
> index dc9bc1807fdf..61f80d586279 100644
> --- a/drivers/misc/cxl/cxllib.c
> +++ b/drivers/misc/cxl/cxllib.c
> @@ -99,7 +99,7 @@ int cxllib_get_xsl_config(struct pci_dev *dev, struct cxllib_xsl_config *cfg)
> if (rc)
> return rc;
>
> - rc = cxl_get_xsl9_dsnctl(capp_unit_id, &cfg->dsnctl);
> + rc = cxl_get_xsl9_dsnctl(dev, capp_unit_id, &cfg->dsnctl);
> if (rc)
> return rc;
> if (cpu_has_feature(CPU_FTR_POWER9_DD1)) {
> diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
> index 19969ee86d6f..c58fb28685af 100644
> --- a/drivers/misc/cxl/pci.c
> +++ b/drivers/misc/cxl/pci.c
> @@ -409,7 +409,36 @@ int cxl_calc_capp_routing(struct pci_dev *dev, u64 *chipid,
> return 0;
> }
>
> -int cxl_get_xsl9_dsnctl(u64 capp_unit_id, u64 *reg)
> +static u64 nbwind = 0;
> +static u64 asnind = 0;
> +static u64 capiind = 0;
Could we avoid the globals and keep the static within
get_phb_indications() and have the function return them as out
parameters? It would seem cleaner to me.
Fred
> +static int get_phb_indications(struct pci_dev *dev)
> +{
> + struct device_node *np;
> + const __be32 *prop;
> +
> + if (capiind)
> + return 0;
> +
> + if (!(np = pnv_pci_get_phb_node(dev)))
> + return -1;
> +
> + prop = of_get_property(np, "ibm,phb-indications", NULL);
> + if (!prop) {
> + nbwind = 0x0300UL; /* legacy values */
> + asnind = 0x0400UL;
> + capiind = 0x0200UL;
> + } else {
> + nbwind = (u64)be32_to_cpu(prop[2]);
> + asnind = (u64)be32_to_cpu(prop[1]);
> + capiind = (u64)be32_to_cpu(prop[0]);
> + }
> + of_node_put(np);
> + return 0;
> +}
> +
> +int cxl_get_xsl9_dsnctl(struct pci_dev *dev, u64 capp_unit_id, u64 *reg)
> {
> u64 xsl_dsnctl;
>
> @@ -423,7 +452,8 @@ int cxl_get_xsl9_dsnctl(u64 capp_unit_id, u64 *reg)
> * Tell XSL where to route data to.
> * The field chipid should match the PHB CAPI_CMPM register
> */
> - xsl_dsnctl = ((u64)0x2 << (63-7)); /* Bit 57 */
> + get_phb_indications(dev);
> + xsl_dsnctl = (capiind << (63-15)); /* Bit 57 */
> xsl_dsnctl |= (capp_unit_id << (63-15));
>
> /* nMMU_ID Defaults to: b’000001001’*/
> @@ -437,14 +467,14 @@ int cxl_get_xsl9_dsnctl(u64 capp_unit_id, u64 *reg)
> * nbwind=0x03, bits [57:58], must include capi indicator.
> * Not supported on P9 DD1.
> */
> - xsl_dsnctl |= ((u64)0x03 << (63-47));
> + xsl_dsnctl |= (nbwind << (63-55));
>
> /*
> * Upper 16b address bits of ASB_Notify messages sent to the
> * system. Need to match the PHB’s ASN Compare/Mask Register.
> * Not supported on P9 DD1.
> */
> - xsl_dsnctl |= ((u64)0x04 << (63-55));
> + xsl_dsnctl |= asnind;
> }
>
> *reg = xsl_dsnctl;
> @@ -464,7 +494,7 @@ static int init_implementation_adapter_regs_psl9(struct cxl *adapter,
> if (rc)
> return rc;
>
> - rc = cxl_get_xsl9_dsnctl(capp_unit_id, &xsl_dsnctl);
> + rc = cxl_get_xsl9_dsnctl(dev, capp_unit_id, &xsl_dsnctl);
> if (rc)
> return rc;
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox