Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig

[Masahiro Yamada]

2018-02-20 0:18 GMT+09:00 Ulf Magnusson :

>>
>> I'm not happy that we in one context can reference CONFIG variables
>> directly, but inside the $(call ...) and $(shell ...) needs the $ prefix.
>> But I could not come up with something un-ambigious where this could be 
>> avoided.
>
> I think we should be careful about allowing references to config
> symbols. It mixes up the parsing and evaluation phases, since $() is
> expanded during parsing (which I consider a feature and think is
> needed to retain sanity).
>
> Patch 06/23 removes the last existing instance of symbol references in
> strings by getting rid of 'option env'. That's an improvement to me.
> We shouldn't add it back.


This is really important design decision,
so I'd like to hear a little more from experts.


For example, x86 allows users to choose sub-arch, either 'i386' or 'x86_64'.

https://github.com/torvalds/linux/blob/v4.16-rc2/arch/x86/Kconfig#L4



If the user toggles CONFIG_64BIT,
the bi-arch compiler will work in a slightly different mode
(at least, back-end parts)

So, my question is, is there a case,

$(cc-option, -m32 -foo) is y, but
$(cc-option, -m64 -foo) is n  ?
(or vice versa)


If the answer is yes, $(cc-option -foo) would have to be re-calculated
every time CONFIG_64BIT is toggled.

This is what I'd like to avoid, though.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 0/6] DISCONTIGMEM support for PPC32

[Christophe LEROY]

Le 20/02/2018 à 17:14, Jonathan Neuschäfer a écrit :

This patchset adds support for DISCONTIGMEM on 32-bit PowerPC. This is
required to properly support the Nintendo Wii's memory layout, in which
there are two blocks of RAM and MMIO in the middle.

Previously, this memory layout was handled by code that joins the two
RAM blocks into one, reserves the MMIO hole, and permits allocations of
reserved memory in ioremap. This hack didn't work with resource-based
allocation (as used for example in the GPIO driver for Wii[1]), however.

After this patchset, users of the Wii can either select CONFIG_FLATMEM
to get the old behaviour, or CONFIG_DISCONTIGMEM to get the new
behaviour.


My question might me stupid, as I don't know PCC64 in deep, but when 
looking at page_is_ram() in arch/powerpc/mm/mem.c, I have the feeling 
the PPC64 implements ram by blocks. Isn't it what you are trying to 
achieve ? Wouldn't it be feasible to map to what's done in PPC64 for PPC32 ?


Christophe



Some parts of this patchset are probably not ideal (I'm thinking of my
implementation of pfn_to_nid here), and will require some discussion/
changes.

[1]: https://www.spinics.net/lists/devicetree/msg213956.html

Jonathan Neuschäfer (6):
   powerpc/mm/32: Use pfn_valid to check if pointer is in RAM
   powerpc: numa: Fix overshift on PPC32
   powerpc: numa: Use the right #ifdef guards around functions
   powerpc: numa: Restrict fake NUMA enulation to CONFIG_NUMA systems
   powerpc: Implement DISCONTIGMEM and allow selection on PPC32
   powerpc: wii: Don't rely on reserved memory hack if DISCONTIGMEM is
 set

  arch/powerpc/Kconfig |  5 -
  arch/powerpc/include/asm/mmzone.h| 21 +
  arch/powerpc/mm/numa.c   | 18 +++---
  arch/powerpc/mm/pgtable_32.c |  2 +-
  arch/powerpc/platforms/embedded6xx/wii.c | 10 +++---
  5 files changed, 48 insertions(+), 8 deletions(-)

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

[Balbir Singh]

On Wed, Feb 21, 2018 at 3:57 PM, Alastair D'Silva  wrote:
> From: Alastair D'Silva 
>
> Some required information is not exposed to userspace currently (eg. the
> PASID), pass this information back, along with other information which
> is currently communicated via sysfs, which saves some parsing effort in
> userspace.
>
> Signed-off-by: Alastair D'Silva 
> ---
>  drivers/misc/ocxl/file.c | 27 +++
>  include/uapi/misc/ocxl.h | 22 ++
>  2 files changed, 49 insertions(+)
>
> diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
> index d9aa407db06a..11514a8444e5 100644
> --- a/drivers/misc/ocxl/file.c
> +++ b/drivers/misc/ocxl/file.c
> @@ -102,10 +102,32 @@ static long afu_ioctl_attach(struct ocxl_context *ctx,
> return rc;
>  }
>
> +static long afu_ioctl_get_metadata(struct ocxl_context *ctx,
> +   struct ocxl_ioctl_get_metadata __user *uarg)

Why do we call this metadata? Isn't this an afu_descriptor?

> +{
> +   struct ocxl_ioctl_get_metadata arg;
> +
> +   memset(, 0, sizeof(arg));
> +
> +   arg.version = 0;

Does it make sense to have version 0? Even if does, you can afford
to skip initialization due to the memset above. I prefer that versions
start with 1

> +
> +   arg.afu_version_major = ctx->afu->config.version_major;
> +   arg.afu_version_minor = ctx->afu->config.version_minor;
> +   arg.pasid = ctx->pasid;
> +   arg.pp_mmio_size = ctx->afu->config.pp_mmio_stride;
> +   arg.global_mmio_size = ctx->afu->config.global_mmio_size;
> +
> +   if (copy_to_user(uarg, , sizeof(arg)))
> +   return -EFAULT;
> +
> +   return 0;
> +}
> +
>  #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" :  
>   \
> x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" :   \
> x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
> x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
> +   x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
> "UNKNOWN")
>
>  static long afu_ioctl(struct file *file, unsigned int cmd,
> @@ -157,6 +179,11 @@ static long afu_ioctl(struct file *file, unsigned int 
> cmd,
> irq_fd.eventfd);
> break;
>
> +   case OCXL_IOCTL_GET_METADATA:
> +   rc = afu_ioctl_get_metadata(ctx,
> +   (struct ocxl_ioctl_get_metadata __user *) 
> args);
> +   break;
> +
> default:
> rc = -EINVAL;
> }
> diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> index 4b0b0b756f3e..16e1f48ce280 100644
> --- a/include/uapi/misc/ocxl.h
> +++ b/include/uapi/misc/ocxl.h
> @@ -32,6 +32,27 @@ struct ocxl_ioctl_attach {
> __u64 reserved3;
>  };
>
> +/*
> + * Version contains the version of the struct.
> + * Versions will always be backwards compatible, that is, new versions will 
> not
> + * alter existing fields
> + */
> +struct ocxl_ioctl_get_metadata {

This sounds more like a function name, do we need it to be _get_metdata?

> +   __u16 version;
> +
> +   // Version 0 fields
> +   __u8  afu_version_major;
> +   __u8  afu_version_minor;
> +   __u32 pasid;
> +
> +   __u64 pp_mmio_size;
> +   __u64 global_mmio_size;
> +

Should we document the fields? pp_ stands for per process, but is not
very clear at first look. Why do we care to return only the size, what
about lpc size?

> +   // End version 0 fields
> +
> +   __u64 reserved[13]; // Total of 16*u64
> +};


Balbir Singh.

Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()

[Viresh Kumar]

On 21-02-18, 16:39, Michael Ellerman wrote:
> Viresh Kumar  writes:

> > AFAICT, you will get -1 here only if the freq table had no valid
> > frequencies (or the freq table is empty). Why would that happen ?
> 
> Bugs?

The cupfreq driver shouldn't have registered itself in that case (i.e.
if the cpufreq table is empty).

> Or if you ask for a target_freq that is higher than anything in the
> table.

You will still get a valid index in that case.

There is only once case where we return -1, when the cpufreq table
doesn't have any valid frequencies.

> Or the API changes, and we forget to update this call site.

I am not sure we can do much about that right now.

> If you're saying that cpufreq_table_find_index_dl() can NEVER fail,

Yes, if we have at least one valid frequency in the table, otherwise
the cpufreq driver shouldn't have registered itself.

> then
> write it so that it can never fail and change it to return unsigned int.

But what should we do when there is no frequency in the cpufreq table?
Just in case where a driver is buggy and tries to call this routine
for an invalid table.

> Having it potentially return -1, which is then used to index an array
> and not handling that is just asking for bugs to happen.

I understand what you are trying to say here, but I don't know what
can be done to prevent this here.

What we can do is change the return type to void and pass a int
pointer to the routine, but that wouldn't change anything at all. That
pointers variable can still have -1 in it.

-- 
viresh

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

[Andrew Donnellan]

On 21/02/18 15:57, Alastair D'Silva wrote:

From: Alastair D'Silva 

Some required information is not exposed to userspace currently (eg. the
PASID), pass this information back, along with other information which
is currently communicated via sysfs, which saves some parsing effort in
userspace.

Signed-off-by: Alastair D'Silva 


Seems fine.

Acked-by: Andrew Donnellan 

--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()

[Michael Ellerman]

Viresh Kumar  writes:

> On 12-02-18, 15:51, Shilpasri G Bhat wrote:
>> This patch fixes the below Coverity warning:
>> 
>> *** CID 182816:  Memory - illegal accesses  (NEGATIVE_RETURNS)
>> /drivers/cpufreq/powernv-cpufreq.c: 1008 in powernv_fast_switch()
>> 1002 unsigned int target_freq)
>> 1003 {
>> 1004 int index;
>> 1005 struct powernv_smp_call_data freq_data;
>> 1006
>> 1007 index = cpufreq_table_find_index_dl(policy, target_freq);
>> >>> CID 182816:  Memory - illegal accesses  (NEGATIVE_RETURNS)
>> >>> Using variable "index" as an index to array "powernv_freqs".
>> 1008 freq_data.pstate_id = powernv_freqs[index].driver_data;
>> 1009 freq_data.gpstate_id = powernv_freqs[index].driver_data;
>> 1010 set_pstate(_data);
>> 1011
>> 1012 return powernv_freqs[index].frequency;
>> 1013 }
>> 
>> Signed-off-by: Shilpasri G Bhat 
>> ---
>>  drivers/cpufreq/powernv-cpufreq.c | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/drivers/cpufreq/powernv-cpufreq.c 
>> b/drivers/cpufreq/powernv-cpufreq.c
>> index 29cdec1..69edfe9 100644
>> --- a/drivers/cpufreq/powernv-cpufreq.c
>> +++ b/drivers/cpufreq/powernv-cpufreq.c
>> @@ -1005,6 +1005,9 @@ static unsigned int powernv_fast_switch(struct 
>> cpufreq_policy *policy,
>>  struct powernv_smp_call_data freq_data;
>>  
>>  index = cpufreq_table_find_index_dl(policy, target_freq);
>> +if (unlikely(index < 0))
>> +index = get_nominal_index();
>> +
>
> AFAICT, you will get -1 here only if the freq table had no valid
> frequencies (or the freq table is empty). Why would that happen ?

Bugs?

Or if you ask for a target_freq that is higher than anything in the
table.

Or the API changes, and we forget to update this call site.

If you're saying that cpufreq_table_find_index_dl() can NEVER fail, then
write it so that it can never fail and change it to return unsigned int.

Having it potentially return -1, which is then used to index an array
and not handling that is just asking for bugs to happen.

cheers

Re: [RFC] powerpc/powernv/mce: Don't silently restart the machine

[Balbir Singh]

On Wed, Feb 21, 2018 at 3:54 PM, Stewart Smith
 wrote:
> Balbir Singh  writes:
>> On MCE the current code will restart the machine with
>> ppc_md.restart(). This case was extremely unlikely since
>> prior to that a skiboot call is made and that resulted in
>> a checkstop for analysis.
>>
>> With newer skiboots, on P9 we don't checkstop the box by
>> default, instead we return back to the kernel to extract
>> useful information at the time of the MCE. While we still
>> get this information, this patch converts the restart to
>> a panic(), so that if configured a dump can be taken and
>> we can track and probably debug the potential issue causing
>> the MCE.
>
> I agree with the patch, although I'd be nervous stating that skiboot is
> going to keep this behaviour. In *theory* we should only ever get a
> platform error when there's actually something that isn't the kernel's
> fault.
>
> Like any firmware promise though, it's slightly less reliable than one
> from a politician.
>
> I'd say that in this case deferring to policy on what to do in event of
> panic() is the right thing.
>

Your right, except that with NPUs and coherent device memory, things
change. It is a platform error on the device side, the large issue is
that the CPU touched this memory. Ideally we want the device and
device driver to handle this error, but its racy as the CPU now treats
it as a platform error on the system side. IOW, the definition of
platform has grown and so has the definition of platform error and it
can no longer be solely contained inside of one boxes firmware.

Balbir Singh.

[PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

[Alastair D'Silva]

From: Alastair D'Silva 

Some required information is not exposed to userspace currently (eg. the
PASID), pass this information back, along with other information which
is currently communicated via sysfs, which saves some parsing effort in
userspace.

Signed-off-by: Alastair D'Silva 
---
 drivers/misc/ocxl/file.c | 27 +++
 include/uapi/misc/ocxl.h | 22 ++
 2 files changed, 49 insertions(+)

diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index d9aa407db06a..11514a8444e5 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -102,10 +102,32 @@ static long afu_ioctl_attach(struct ocxl_context *ctx,
return rc;
 }
 
+static long afu_ioctl_get_metadata(struct ocxl_context *ctx,
+   struct ocxl_ioctl_get_metadata __user *uarg)
+{
+   struct ocxl_ioctl_get_metadata arg;
+
+   memset(, 0, sizeof(arg));
+
+   arg.version = 0;
+
+   arg.afu_version_major = ctx->afu->config.version_major;
+   arg.afu_version_minor = ctx->afu->config.version_minor;
+   arg.pasid = ctx->pasid;
+   arg.pp_mmio_size = ctx->afu->config.pp_mmio_stride;
+   arg.global_mmio_size = ctx->afu->config.global_mmio_size;
+
+   if (copy_to_user(uarg, , sizeof(arg)))
+   return -EFAULT;
+
+   return 0;
+}
+
 #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" :
\
x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" :   \
x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
+   x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
"UNKNOWN")
 
 static long afu_ioctl(struct file *file, unsigned int cmd,
@@ -157,6 +179,11 @@ static long afu_ioctl(struct file *file, unsigned int cmd,
irq_fd.eventfd);
break;
 
+   case OCXL_IOCTL_GET_METADATA:
+   rc = afu_ioctl_get_metadata(ctx,
+   (struct ocxl_ioctl_get_metadata __user *) args);
+   break;
+
default:
rc = -EINVAL;
}
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 4b0b0b756f3e..16e1f48ce280 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -32,6 +32,27 @@ struct ocxl_ioctl_attach {
__u64 reserved3;
 };
 
+/*
+ * Version contains the version of the struct.
+ * Versions will always be backwards compatible, that is, new versions will not
+ * alter existing fields
+ */
+struct ocxl_ioctl_get_metadata {
+   __u16 version;
+
+   // Version 0 fields
+   __u8  afu_version_major;
+   __u8  afu_version_minor;
+   __u32 pasid;
+
+   __u64 pp_mmio_size;
+   __u64 global_mmio_size;
+
+   // End version 0 fields
+
+   __u64 reserved[13]; // Total of 16*u64
+};
+
 struct ocxl_ioctl_irq_fd {
__u64 irq_offset;
__s32 eventfd;
@@ -45,5 +66,6 @@ struct ocxl_ioctl_irq_fd {
 #define OCXL_IOCTL_IRQ_ALLOC   _IOR(OCXL_MAGIC, 0x11, __u64)
 #define OCXL_IOCTL_IRQ_FREE_IOW(OCXL_MAGIC, 0x12, __u64)
 #define OCXL_IOCTL_IRQ_SET_FD  _IOW(OCXL_MAGIC, 0x13, struct ocxl_ioctl_irq_fd)
+#define OCXL_IOCTL_GET_METADATA _IOR(OCXL_MAGIC, 0x14, struct 
ocxl_ioctl_get_metadata)
 
 #endif /* _UAPI_MISC_OCXL_H */
-- 
2.14.3

Re: [PATCH v9 1/2] powerpc/powernv: Enable tunneled operations

[Stewart Smith]

Philippe Bergheaud  writes:
> diff --git a/arch/powerpc/include/asm/opal-api.h 
> b/arch/powerpc/include/asm/opal-api.h
> index 94bd1bf2c873..07b5e2240ecc 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -204,7 +204,9 @@
>  #define OPAL_NPU_SPA_SETUP   159
>  #define OPAL_NPU_SPA_CLEAR_CACHE 160
>  #define OPAL_NPU_TL_SET  161
> -#define OPAL_LAST161
> +#define OPAL_PCI_GET_PBCQ_TUNNEL_BAR 162
> +#define OPAL_PCI_SET_PBCQ_TUNNEL_BAR 163
> +#define OPAL_LAST163


These numbers will change as other calls have gone in with those OPAL
API ids.

Feel free to send a tiny patch to skiboot reserving some though.

I should probably encourage people to do that when they start working on
new API calls.

-- 
Stewart Smith
OPAL Architect, IBM.

Re: [RFC] powerpc/powernv/mce: Don't silently restart the machine

[Stewart Smith]

Balbir Singh  writes:
> On MCE the current code will restart the machine with
> ppc_md.restart(). This case was extremely unlikely since
> prior to that a skiboot call is made and that resulted in
> a checkstop for analysis.
>
> With newer skiboots, on P9 we don't checkstop the box by
> default, instead we return back to the kernel to extract
> useful information at the time of the MCE. While we still
> get this information, this patch converts the restart to
> a panic(), so that if configured a dump can be taken and
> we can track and probably debug the potential issue causing
> the MCE.

I agree with the patch, although I'd be nervous stating that skiboot is
going to keep this behaviour. In *theory* we should only ever get a
platform error when there's actually something that isn't the kernel's
fault.

Like any firmware promise though, it's slightly less reliable than one
from a politician.

I'd say that in this case deferring to policy on what to do in event of
panic() is the right thing.

-- 
Stewart Smith
OPAL Architect, IBM.

Re: [PATCH v2 (skiboot)] dt: add /cpus/ibm, powerpc-cpu-features device tree bindings

[Stewart Smith]

Nicholas Piggin  writes:
> This is a new CPU feature advertising interface that is fine-grained,
> extensible, aware of privilege levels, and gives control of features
> to all levels of the stack (firmware, hypervisor, and OS).
>
> The design and binding specification is described in detail in doc/.
>
> Signed-off-by: Nicholas Piggin 
> ---
> Since v1:
>
> - Fold branch-v3 into fixed-point-v3, as pointed out by Segher they
>   are all fixed point facilities.
>
> - Fixed typo (Segher)
>
>  core/Makefile.inc  |   2 +-
>  core/cpufeatures.c | 921 
> +
>  core/device.c  |   7 +
>  core/init.c|   1 +
>  .../ibm,powerpc-cpu-features/binding.txt   | 245 ++
>  .../ibm,powerpc-cpu-features/design.txt| 157 
>  include/device.h   |   1 +
>  include/skiboot.h  |   5 +
>  8 files changed, 1338 insertions(+), 1 deletion(-)
>  create mode 100644 core/cpufeatures.c
>  create mode 100644 doc/device-tree/ibm,powerpc-cpu-features/binding.txt
>  create mode 100644
>  doc/device-tree/ibm,powerpc-cpu-features/design.txt

Merged to master as of 7f4c8e8ce0b78ca046643d7f4f63d81f4fd11746 and has
made it into -rc4

-- 
Stewart Smith
OPAL Architect, IBM.

Re: [PATCH] scsi: cxlflash: Select SCSI_SCAN_ASYNC

[Matthew R. Ochs]

On Tue, Feb 20, 2018 at 07:56:35PM +1100, Michael Ellerman wrote:
> Vaibhav Jain  writes:
> 
> > The cxlflash driver uses "Asynchronous SCSI scanning" enabled by
> > CONFIG_SCSI_SCAN_ASYNC. Without this enabled the modprobe of cxlflash
> > module gets hung with following backtrace:
> >
> > Call Trace:
> >  __switch_to+0x2cc/0x470
> >  __schedule+0x288/0xab0
> >  schedule+0x40/0xc0
> >  schedule_timeout+0x254/0x4f0
> >  wait_for_common+0xdc/0x260
> >  flush_work+0x140/0x2a0
> >  work_on_cpu+0x88/0xb0
> >  pci_device_probe+0x1d0/0x220
> >  driver_probe_device+0x408/0x5b0
> >  __driver_attach+0x16c/0x1a0
> >  bus_for_each_dev+0xb8/0x110
> >  driver_attach+0x3c/0x60
> >  bus_add_driver+0x1d8/0x370
> >  driver_register+0x9c/0x180
> >  __pci_register_driver+0x74/0xa0
> >  init_cxlflash+0x158/0x1cc
> >  do_one_initcall+0x68/0x1e0
> >  do_init_module+0x90/0x254
> >  load_module+0x2f8c/0x3720
> >  SyS_finit_module+0xcc/0x140
> >  system_call+0x58/0x6c
> 
> Why does it "hang"? That's kind of bizarre, I would expect either a
> build or runtime failure if a feature the driver requires is missing.
> 

It hangs due to a bug in the driver. I briefly looked at it several
months back before getting distracted with other items. IIRC there
was an issue with the state machine.

> > diff --git a/drivers/scsi/cxlflash/Kconfig b/drivers/scsi/cxlflash/Kconfig
> > index a011c5dbf214..f054c1b0fff3 100644
> > --- a/drivers/scsi/cxlflash/Kconfig
> > +++ b/drivers/scsi/cxlflash/Kconfig
> > @@ -6,6 +6,7 @@ config CXLFLASH
> > tristate "Support for IBM CAPI Flash"
> > depends on PCI && SCSI && CXL && EEH
> > select IRQ_POLL
> > +   select SCSI_SCAN_ASYNC
> 
> It's user configurable, so it's rude to select it. It can also be
> disabled on the kernel command line, so this seems like a fragile
> solution.
>
I think Vaibhav's intention here was to avoid the hang while the bug
is still present - I believe he has encountered it several times recently.

The proper solution would be to fix the bug.

Re: [PATCH V6] cxl: Fix timebase synchronization status on P9

[Michael Ellerman]

Christophe Lombard  writes:

> The PSL Timebase register is updated by the PSL to maintain the
> timebase.
> On P9, the Timebase value is only provided by the CAPP as received
> the last time a timebase request was performed.
> The timebase requests are initiated through the adapter configuration or
> application registers.
> The specific sysfs entry "/sys/class/cxl/cardxx/psl_timebase_synced" is
> now dynamically updated according the content of the PSL Timebase
> register.
>
> Signed-off-by: Christophe Lombard 
> Reviewed-by: Vaibhav Jain 
> Acked-by: Andrew Donnellan 

Can you give me a Fixes: tag for this?

Does it need to go to stable? I can't tell from the change log how bad
the bug this fixes is.

cheers

> ---
> This patch applies on top of this patch:
>  http://patchwork.ozlabs.org/patch/873663/
>
> Changelog[v6]
>  - Rebased to latest upstream.
>  - Recompute the status only in native mode.
>
> Changelog[v5]
>  - Rebased to latest upstream.
>  - Changed the type of 'delta'
>
> Changelog[v4]
>  - Rebased to latest upstream.
>  - Added log message.
>
> Changelog[v3]
>  - Rebased to latest upstream.
>  - Dynamic update is now applied to P8.
>
> Changelog[v2]
>  - Missing Signed-off-by.
>  - Spaces required around the ':'.
> ---
>  drivers/misc/cxl/pci.c   | 17 -
>  drivers/misc/cxl/sysfs.c | 12 
>  2 files changed, 12 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
> index 66eed6a..3247eaf 100644
> --- a/drivers/misc/cxl/pci.c
> +++ b/drivers/misc/cxl/pci.c
> @@ -606,9 +606,6 @@ static u64 timebase_read_xsl(struct cxl *adapter)
>  
>  static void cxl_setup_psl_timebase(struct cxl *adapter, struct pci_dev *dev)
>  {
> - u64 psl_tb;
> - int delta;
> - unsigned int retry = 0;
>   struct device_node *np;
>  
>   adapter->psl_timebase_synced = false;
> @@ -636,20 +633,6 @@ static void cxl_setup_psl_timebase(struct cxl *adapter, 
> struct pci_dev *dev)
>   cxl_p1_write(adapter, CXL_PSL_Control, 0x);
>   cxl_p1_write(adapter, CXL_PSL_Control, CXL_PSL_Control_tb);
>  
> - /* Wait until CORE TB and PSL TB difference <= 16usecs */
> - do {
> - msleep(1);
> - if (retry++ > 5) {
> - dev_info(>dev, "PSL timebase can't synchronize\n");
> - return;
> - }
> - psl_tb = adapter->native->sl_ops->timebase_read(adapter);
> - delta = mftb() - psl_tb;
> - if (delta < 0)
> - delta = -delta;
> - } while (tb_to_ns(delta) > 16000);
> -
> - adapter->psl_timebase_synced = true;
>   return;
>  }
>  
> diff --git a/drivers/misc/cxl/sysfs.c b/drivers/misc/cxl/sysfs.c
> index a8b6d6a..95285b7 100644
> --- a/drivers/misc/cxl/sysfs.c
> +++ b/drivers/misc/cxl/sysfs.c
> @@ -62,7 +62,19 @@ static ssize_t psl_timebase_synced_show(struct device 
> *device,
>   char *buf)
>  {
>   struct cxl *adapter = to_cxl_adapter(device);
> + u64 psl_tb, delta;
>  
> + /* Recompute the status only in native mode */
> + if (cpu_has_feature(CPU_FTR_HVMODE)) {
> + psl_tb = adapter->native->sl_ops->timebase_read(adapter);
> + delta = abs(mftb() - psl_tb);
> +
> + /* CORE TB and PSL TB difference <= 16usecs ? */
> + adapter->psl_timebase_synced = (tb_to_ns(delta) < 16000) ? true 
> : false;
> + pr_devel("PSL timebase %s - delta: 0x%016llx\n",
> +  (tb_to_ns(delta) < 16000) ? "synchronized" :
> +  "not synchronized", tb_to_ns(delta));
> + }
>   return scnprintf(buf, PAGE_SIZE, "%i\n", adapter->psl_timebase_synced);
>  }
>  
> -- 
> 2.7.4

Re: [RFC] powerpc/powernv/mce: Don't silently restart the machine

[Nicholas Piggin]

On Wed, 21 Feb 2018 12:01:11 +1100
Balbir Singh  wrote:

> On MCE the current code will restart the machine with
> ppc_md.restart(). This case was extremely unlikely since
> prior to that a skiboot call is made and that resulted in
> a checkstop for analysis.
> 
> With newer skiboots, on P9 we don't checkstop the box by
> default, instead we return back to the kernel to extract
> useful information at the time of the MCE. While we still
> get this information, this patch converts the restart to
> a panic(), so that if configured a dump can be taken and
> we can track and probably debug the potential issue causing
> the MCE.
> 
> Signed-off-by: Balbir Singh 

Seems like something we should be doing.

Reviewed-by: Nicholas Piggin 

> ---
>  arch/powerpc/platforms/powernv/opal.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/opal.c 
> b/arch/powerpc/platforms/powernv/opal.c
> index 69b5263fc9e3..b510a6f41b00 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -500,9 +500,12 @@ void pnv_platform_error_reboot(struct pt_regs *regs, 
> const char *msg)
>*opal to trigger checkstop explicitly for error analysis.
>*The FSP PRD component would have already got notified
>*about this error through other channels.
> +  * 4. We are running on a newer skiboot that by default does
> +  *not cause a checkstop, drops us back to the kernel to
> +  *extract context and state at the time of the error.
>*/
>  
> - ppc_md.restart(NULL);
> + panic("PowerNV Unrecovered Machine Check");
>  }
>  
>  int opal_machine_check(struct pt_regs *regs)

Re: [PATCH 1/6] powerpc/mm/32: Use pfn_valid to check if pointer is in RAM

[christophe leroy]

Le 20/02/2018 à 17:14, Jonathan Neuschäfer a écrit :

The Nintendo Wii has a memory layout that places two chunks of RAM at
non-adjacent addresses, and MMIO between them. Currently, the allocation
of these MMIO areas is made possible by declaring the MMIO hole as
reserved memory and allowing reserved memory to be allocated (cf.
wii_memory_fixups).

This patch is the first step towards proper support for discontiguous
memory on PPC32 by using pfn_valid to check if a pointer points into
RAM, rather than open-coding the check. It should result in no
functional difference.

Signed-off-by: Jonathan Neuschäfer 
---
  arch/powerpc/mm/pgtable_32.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index d35d9ad3c1cd..b5c009893a44 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -147,7 +147,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, 
unsigned long flags,
 * Don't allow anybody to remap normal RAM that we're using.
 * mem_init() sets high_memory so only do the check after that.
 */
-   if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
+   if (slab_is_available() && pfn_valid(__phys_to_pfn(p)) &&


I'm not sure this is equivalent:

high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
#define ARCH_PFN_OFFSET ((unsigned long)(MEMORY_START >> PAGE_SHIFT))
#define pfn_valid(pfn)  ((pfn) >= ARCH_PFN_OFFSET && (pfn) < max_mapnr)
set_max_mapnr(max_pfn);

So in the current implementation it checks against max_low_pfn while 
your patch checks against max_pfn


max_low_pfn = max_pfn = memblock_end_of_DRAM() >> PAGE_SHIFT;
#ifdef CONFIG_HIGHMEM
max_low_pfn = lowmem_end_addr >> PAGE_SHIFT;
#endif

Christophe


!(__allow_ioremap_reserved && memblock_is_region_reserved(p, 
size))) {
printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
   (unsigned long long)p, __builtin_return_address(0));



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

[RFC] powerpc/powernv/mce: Don't silently restart the machine

[Balbir Singh]

On MCE the current code will restart the machine with
ppc_md.restart(). This case was extremely unlikely since
prior to that a skiboot call is made and that resulted in
a checkstop for analysis.

With newer skiboots, on P9 we don't checkstop the box by
default, instead we return back to the kernel to extract
useful information at the time of the MCE. While we still
get this information, this patch converts the restart to
a panic(), so that if configured a dump can be taken and
we can track and probably debug the potential issue causing
the MCE.

Signed-off-by: Balbir Singh 
---
 arch/powerpc/platforms/powernv/opal.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 69b5263fc9e3..b510a6f41b00 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -500,9 +500,12 @@ void pnv_platform_error_reboot(struct pt_regs *regs, const 
char *msg)
 *opal to trigger checkstop explicitly for error analysis.
 *The FSP PRD component would have already got notified
 *about this error through other channels.
+* 4. We are running on a newer skiboot that by default does
+*not cause a checkstop, drops us back to the kernel to
+*extract context and state at the time of the error.
 */
 
-   ppc_md.restart(NULL);
+   panic("PowerNV Unrecovered Machine Check");
 }
 
 int opal_machine_check(struct pt_regs *regs)
-- 
2.13.6

Re: [PATCH] bpf, powerpc: fix jit for seccomp_data access

[Daniel Borkmann]

On 02/21/2018 01:33 AM, Michael Ellerman wrote:
> Mark Lord  writes:
> 
>> I am using SECCOMP to filter syscalls on a ppc32 platform,
>> and noticed that the JIT compiler was failing on the BPF
>> even though the interpreter was working fine.
>>
>> The issue was that the compiler was missing one of the instructions
>> used by SECCOMP, so here is a patch to enable JIT for that instruction.
>>
>> Signed-Off-By:  Mark Lord 
> 
> Thanks.
> 
> What is the failure mode without this patch? I assume when you have the
> JIT enabled the seccomp filter fails to load entirely? Or do we have
> logic to fall back to the interpreter?

The logic for all JITs is that once a BPF insn cannot be JITed then it falls
back to BPF interpreter. Here, since ppc32 is cBPF the path is: cBPF insn ->
cBPF JIT -> fail -> migrate cBPF to eBPF -> run in eBPF interpreter. In the
case where interpreter is compiled out (CONFIG_BPF_JIT_ALWAYS_ON), then the
filter is rejected.

> Either way we should probably back port to stable. I assume this has
> been broken since we originally added 32-bit support, so:

Note that arm32 before it was converted to be an eBPF JIT (eBPF JITs do handle
seccomp BPF in any case) was the only cBPF JIT that had it 'JIT-able', so
currently, other cBPF ones like sparc32 or mips32 don't translate it either.
Meaning, it would be nice to have as feature; I wouldn't necessarily frame
it as a bug though (or at least a stable-urgent one, imho, but I leave that
to you, of course).

> Fixes: eb84bab0fb38 ("ppc: Kconfig: Enable BPF JIT on ppc32")
> Cc: sta...@vger.kernel.org # v4.1+
> 
> cheers
> 
> 
>> --- old/arch/powerpc/net/bpf_jit_comp.c 2018-02-16 14:07:01.0 -0500
>> +++ linux/arch/powerpc/net/bpf_jit_comp.c   2018-02-20 
>> 14:41:20.805227494 -0500
>> @@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
>> BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
>> PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff, 
>> len));
>> break;
>> +   case BPF_LDX | BPF_W | BPF_ABS: /* A = *((u32 
>> *)(seccomp_data + K)); */
>> +   PPC_LWZ_OFFS(r_A, r_skb, K);
>> +   break;
>> case BPF_LDX | BPF_W | BPF_LEN: /* X = skb->len; */
>> PPC_LWZ_OFFS(r_X, r_skb, offsetof(struct sk_buff, 
>> len));
>> break;
>> -- 
>> Mark Lord
>> Real-Time Remedies Inc.
>> ml...@pobox.com

Re: [PATCH] bpf, powerpc: fix jit for seccomp_data access

[Michael Ellerman]

Mark Lord  writes:

> I am using SECCOMP to filter syscalls on a ppc32 platform,
> and noticed that the JIT compiler was failing on the BPF
> even though the interpreter was working fine.
>
> The issue was that the compiler was missing one of the instructions
> used by SECCOMP, so here is a patch to enable JIT for that instruction.
>
> Signed-Off-By:  Mark Lord 

Thanks.

What is the failure mode without this patch? I assume when you have the
JIT enabled the seccomp filter fails to load entirely? Or do we have
logic to fall back to the interpreter?

Either way we should probably back port to stable. I assume this has
been broken since we originally added 32-bit support, so:

Fixes: eb84bab0fb38 ("ppc: Kconfig: Enable BPF JIT on ppc32")
Cc: sta...@vger.kernel.org # v4.1+

cheers


> --- old/arch/powerpc/net/bpf_jit_comp.c 2018-02-16 14:07:01.0 -0500
> +++ linux/arch/powerpc/net/bpf_jit_comp.c   2018-02-20 14:41:20.805227494 
> -0500
> @@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
> BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
> PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff, 
> len));
> break;
> +   case BPF_LDX | BPF_W | BPF_ABS: /* A = *((u32 *)(seccomp_data 
> + K)); */
> +   PPC_LWZ_OFFS(r_A, r_skb, K);
> +   break;
> case BPF_LDX | BPF_W | BPF_LEN: /* X = skb->len; */
> PPC_LWZ_OFFS(r_X, r_skb, offsetof(struct sk_buff, 
> len));
> break;
> -- 
> Mark Lord
> Real-Time Remedies Inc.
> ml...@pobox.com

[PATCH 0/6] DISCONTIGMEM support for PPC32

[Jonathan Neuschäfer]

This patchset adds support for DISCONTIGMEM on 32-bit PowerPC. This is
required to properly support the Nintendo Wii's memory layout, in which
there are two blocks of RAM and MMIO in the middle.

Previously, this memory layout was handled by code that joins the two
RAM blocks into one, reserves the MMIO hole, and permits allocations of
reserved memory in ioremap. This hack didn't work with resource-based
allocation (as used for example in the GPIO driver for Wii[1]), however.

After this patchset, users of the Wii can either select CONFIG_FLATMEM
to get the old behaviour, or CONFIG_DISCONTIGMEM to get the new
behaviour.

Some parts of this patchset are probably not ideal (I'm thinking of my
implementation of pfn_to_nid here), and will require some discussion/
changes.

[1]: https://www.spinics.net/lists/devicetree/msg213956.html

Jonathan Neuschäfer (6):
  powerpc/mm/32: Use pfn_valid to check if pointer is in RAM
  powerpc: numa: Fix overshift on PPC32
  powerpc: numa: Use the right #ifdef guards around functions
  powerpc: numa: Restrict fake NUMA enulation to CONFIG_NUMA systems
  powerpc: Implement DISCONTIGMEM and allow selection on PPC32
  powerpc: wii: Don't rely on reserved memory hack if DISCONTIGMEM is
set

 arch/powerpc/Kconfig |  5 -
 arch/powerpc/include/asm/mmzone.h| 21 +
 arch/powerpc/mm/numa.c   | 18 +++---
 arch/powerpc/mm/pgtable_32.c |  2 +-
 arch/powerpc/platforms/embedded6xx/wii.c | 10 +++---
 5 files changed, 48 insertions(+), 8 deletions(-)

-- 
2.16.1

[PATCH 1/6] powerpc/mm/32: Use pfn_valid to check if pointer is in RAM

[Jonathan Neuschäfer]

The Nintendo Wii has a memory layout that places two chunks of RAM at
non-adjacent addresses, and MMIO between them. Currently, the allocation
of these MMIO areas is made possible by declaring the MMIO hole as
reserved memory and allowing reserved memory to be allocated (cf.
wii_memory_fixups).

This patch is the first step towards proper support for discontiguous
memory on PPC32 by using pfn_valid to check if a pointer points into
RAM, rather than open-coding the check. It should result in no
functional difference.

Signed-off-by: Jonathan Neuschäfer 
---
 arch/powerpc/mm/pgtable_32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index d35d9ad3c1cd..b5c009893a44 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -147,7 +147,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, 
unsigned long flags,
 * Don't allow anybody to remap normal RAM that we're using.
 * mem_init() sets high_memory so only do the check after that.
 */
-   if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
+   if (slab_is_available() && pfn_valid(__phys_to_pfn(p)) &&
!(__allow_ioremap_reserved && memblock_is_region_reserved(p, 
size))) {
printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
   (unsigned long long)p, __builtin_return_address(0));
-- 
2.16.1

[PATCH 2/6] powerpc: numa: Fix overshift on PPC32

[Jonathan Neuschäfer]

When read_n_cells is compiled for PPC32, "result << 32" causes an
overshift, which GCC doesn't like. Fix this by using u64 instead of
unsigned long.

Signed-off-by: Jonathan Neuschäfer 
---
 arch/powerpc/mm/numa.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index edd8d0bc9364..0570bc2a0b13 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -357,9 +357,9 @@ static void __init get_n_mem_cells(int *n_addr_cells, int 
*n_size_cells)
of_node_put(memory);
 }
 
-static unsigned long read_n_cells(int n, const __be32 **buf)
+static u64 read_n_cells(int n, const __be32 **buf)
 {
-   unsigned long result = 0;
+   u64 result = 0;
 
while (n--) {
result = (result << 32) | of_read_number(*buf, 1);
-- 
2.16.1

[PATCH 3/6] powerpc: numa: Use the right #ifdef guards around functions

[Jonathan Neuschäfer]

of_node_to_nid and dump_numa_cpu_topology are declared inline in their
respective header files, if CONFIG_NUMA is not set. Thus it is only
valid to define these functions in numa.c if CONFIG_NUMA is set.
(numa.c, despite the name, isn't conditionalized on CONFIG_NUMA, but
CONFIG_NEED_MULTIPLE_NODES.)

Signed-off-by: Jonathan Neuschäfer 
---
 arch/powerpc/mm/numa.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 0570bc2a0b13..df03a65b658f 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -254,6 +254,7 @@ static int of_node_to_nid_single(struct device_node *device)
return nid;
 }
 
+#ifdef CONFIG_NUMA
 /* Walk the device tree upwards, looking for an associativity id */
 int of_node_to_nid(struct device_node *device)
 {
@@ -272,6 +273,7 @@ int of_node_to_nid(struct device_node *device)
return nid;
 }
 EXPORT_SYMBOL(of_node_to_nid);
+#endif
 
 static int __init find_min_common_depth(void)
 {
@@ -744,6 +746,7 @@ static void __init setup_nonnuma(void)
}
 }
 
+#ifdef CONFIG_NUMA
 void __init dump_numa_cpu_topology(void)
 {
unsigned int node;
@@ -778,6 +781,7 @@ void __init dump_numa_cpu_topology(void)
pr_cont("\n");
}
 }
+#endif
 
 /* Initialize NODE_DATA for a node on the local memory */
 static void __init setup_node_data(int nid, u64 start_pfn, u64 end_pfn)
-- 
2.16.1

Re: [PATCH] fix double ;;s in code

[Andrew Morton]

On Tue, 20 Feb 2018 10:03:56 +0200 Jani Nikula  
wrote:

> On Mon, 19 Feb 2018, Pavel Machek  wrote:
> > On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
> >> Yeah, pls split this into one patch per area, with a suitable patch
> >> subject prefix. Look at git log of each file to get a feeling for what's
> >> the standard in each area.
> >
> > Yeah I can spend hour spliting it, and then people will ignore it
> > anyway.
> >
> > If you care about one of the files being modified, please fix the
> > bug, ";;" is a clear bug.
> >
> > If you don't care ... well I don't care either.
> 
> Look, if this causes just one conflict down the line because it touches
> the kernel all over the place, then IMO it already wasn't worth
> it. Merge conflicts are inevitable, but there's no reason to make life
> harder just to cater for a cleanup patch. It's not that important.
> 
> Had it been split up, the drm parts would've been merged already.

I just stage patches like this behind linux-next.  So if your stuff in
in -next, you'll never notice a thing.

Re: [PATCH 5/6] powerpc: Implement DISCONTIGMEM and allow selection on PPC32

[kbuild test robot]

Hi Jonathan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.16-rc2 next-20180220]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jonathan-Neusch-fer/DISCONTIGMEM-support-for-PPC32/20180221-044840
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   In file included from include/linux/gfp.h:6:0,
from include/linux/mm.h:10,
from include/linux/mman.h:5,
from arch/powerpc/kernel/asm-offsets.c:22:
>> include/linux/mmzone.h:1239:19: error: conflicting types for 'pfn_valid'
static inline int pfn_valid(unsigned long pfn)
  ^
   In file included from include/linux/mmzone.h:912:0,
from include/linux/gfp.h:6,
from include/linux/mm.h:10,
from include/linux/mman.h:5,
from arch/powerpc/kernel/asm-offsets.c:22:
   arch/powerpc/include/asm/mmzone.h:40:19: note: previous definition of 
'pfn_valid' was here
static inline int pfn_valid(int pfn)
  ^
   make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +/pfn_valid +1239 include/linux/mmzone.h

c4e1be9e Dave Hansen2017-07-06  1237  
7b7bf499 Will Deacon2011-05-19  1238  #ifndef CONFIG_HAVE_ARCH_PFN_VALID
d41dee36 Andy Whitcroft 2005-06-23 @1239  static inline int pfn_valid(unsigned 
long pfn)
d41dee36 Andy Whitcroft 2005-06-23  1240  {
d41dee36 Andy Whitcroft 2005-06-23  1241if (pfn_to_section_nr(pfn) >= 
NR_MEM_SECTIONS)
d41dee36 Andy Whitcroft 2005-06-23  1242return 0;
29751f69 Andy Whitcroft 2005-06-23  1243return 
valid_section(__nr_to_section(pfn_to_section_nr(pfn)));
d41dee36 Andy Whitcroft 2005-06-23  1244  }
7b7bf499 Will Deacon2011-05-19  1245  #endif
d41dee36 Andy Whitcroft 2005-06-23  1246  

:: The code at line 1239 was first introduced by commit
:: d41dee369bff3b9dcb6328d4d822926c28cc2594 [PATCH] sparsemem memory model

:: TO: Andy Whitcroft <a...@shadowen.org>
:: CC: Linus Torvalds <torva...@ppc970.osdl.org>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] ocxl: Fix potential bad errno on irq allocation

[Andrew Donnellan]

On 17/02/18 00:01, Frederic Barrat wrote:

Fix some issues found by a static checker:

When allocating an AFU interrupt, if the driver cannot copy the output
parameters to userland, the errno value was not set to EFAULT

Remove a (now) useless cast.

Reported-by: Dan Carpenter 
Signed-off-by: Frederic Barrat 


Acked-by: Andrew Donnellan 


---
  drivers/misc/ocxl/file.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index 2dd2db9bc1c9..337462e1569f 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -133,8 +133,10 @@ static long afu_ioctl(struct file *file, unsigned int cmd,
if (!rc) {
rc = copy_to_user((u64 __user *) args, _offset,
sizeof(irq_offset));
-   if (rc)
+   if (rc) {
ocxl_afu_irq_free(ctx, irq_offset);
+   return -EFAULT;
+   }
}
break;

@@ -329,7 +331,7 @@ static ssize_t afu_read(struct file *file, char __user 
*buf, size_t count,

used += sizeof(header);

-   rc = (ssize_t) used;
+   rc = used;
return rc;
  }



--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

Re: [PATCH] fix double ;;s in code

[Joe Perches]

On Tue, 2018-02-20 at 17:19 +1100, Michael Ellerman wrote:
> Daniel Vetter  writes:
> > On Sun, Feb 18, 2018 at 11:00:56AM +0100, Christophe LEROY wrote:
> > > Le 17/02/2018 à 22:19, Pavel Machek a écrit :
> > > > 
> > > > Fix double ;;'s in code.
> > > > 
> > > > Signed-off-by: Pavel Machek 
> > > 
> > > A summary of the files modified on top of the patch would help understand
> > > the impact.
> > > 
> > > A maybe there should be one patch by area, eg one for each arch specific
> > > modif and one for drivers/ and one for block/ ?
> > 
> > Yeah, pls split this into one patch per area, with a suitable patch
> > subject prefix. Look at git log of each file to get a feeling for what's
> > the standard in each area.
> 
> This part is actually pretty annoying.
> 
> I hacked up a script (below) which seems to do a reasonable job in most
> cases.

Here was another suggestion from awhile ago
https://lkml.org/lkml/2010/11/16/245

Re: [PATCH] fix double ;;s in code

[Alex Deucher]

On Tue, Feb 20, 2018 at 3:03 AM, Jani Nikula
 wrote:
> On Mon, 19 Feb 2018, Pavel Machek  wrote:
>> On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
>>> Yeah, pls split this into one patch per area, with a suitable patch
>>> subject prefix. Look at git log of each file to get a feeling for what's
>>> the standard in each area.
>>
>> Yeah I can spend hour spliting it, and then people will ignore it
>> anyway.
>>
>> If you care about one of the files being modified, please fix the
>> bug, ";;" is a clear bug.
>>
>> If you don't care ... well I don't care either.
>
> Look, if this causes just one conflict down the line because it touches
> the kernel all over the place, then IMO it already wasn't worth
> it. Merge conflicts are inevitable, but there's no reason to make life
> harder just to cater for a cleanup patch. It's not that important.
>
> Had it been split up, the drm parts would've been merged already.

FWIW, the amdgpu and scheduler changes have already been fixed for -next.

Alex

>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] bpf, powerpc: fix jit for seccomp_data access

[Mark Lord]

I am using SECCOMP to filter syscalls on a ppc32 platform,
and noticed that the JIT compiler was failing on the BPF
even though the interpreter was working fine.

The issue was that the compiler was missing one of the instructions
used by SECCOMP, so here is a patch to enable JIT for that instruction.

Signed-Off-By:  Mark Lord 

--- old/arch/powerpc/net/bpf_jit_comp.c 2018-02-16 14:07:01.0 -0500
+++ linux/arch/powerpc/net/bpf_jit_comp.c   2018-02-20 14:41:20.805227494 
-0500
@@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff, len));
break;
+   case BPF_LDX | BPF_W | BPF_ABS: /* A = *((u32 *)(seccomp_data + 
K)); */
+   PPC_LWZ_OFFS(r_A, r_skb, K);
+   break;
case BPF_LDX | BPF_W | BPF_LEN: /* X = skb->len; */
PPC_LWZ_OFFS(r_X, r_skb, offsetof(struct sk_buff, len));
break;
-- 
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com

[PATCH 5/6] powerpc: Implement DISCONTIGMEM and allow selection on PPC32

[Jonathan Neuschäfer]

The implementation of pfn_to_nid and pfn_valid in mmzone.h is based on
arch/metag's implementation.

Signed-off-by: Jonathan Neuschäfer 
---

NOTE: Checking NODE_DATA(nid) in pfn_to_nid appears to be uncommon.
Running up to MAX_NUMNODES instead of checking NODE_DATA(nid) would
require the node_data array to be filled with valid pointers.
---
 arch/powerpc/Kconfig  |  5 -
 arch/powerpc/include/asm/mmzone.h | 21 +
 arch/powerpc/mm/numa.c|  7 +++
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 73ce5dd07642..c2633b7b8ed9 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -639,7 +639,6 @@ config HAVE_MEMORYLESS_NODES
 
 config ARCH_SELECT_MEMORY_MODEL
def_bool y
-   depends on PPC64
 
 config ARCH_FLATMEM_ENABLE
def_bool y
@@ -654,6 +653,10 @@ config ARCH_SPARSEMEM_DEFAULT
def_bool y
depends on PPC_BOOK3S_64
 
+config ARCH_DISCONTIGMEM_ENABLE
+   def_bool y
+   depends on PPC32
+
 config SYS_SUPPORTS_HUGETLBFS
bool
 
diff --git a/arch/powerpc/include/asm/mmzone.h 
b/arch/powerpc/include/asm/mmzone.h
index 91c69ff53a8a..1684a5c98d23 100644
--- a/arch/powerpc/include/asm/mmzone.h
+++ b/arch/powerpc/include/asm/mmzone.h
@@ -26,6 +26,27 @@ extern struct pglist_data *node_data[];
  */
 #define NODE_DATA(nid) (node_data[nid])
 
+static inline int pfn_to_nid(unsigned long pfn)
+{
+   int nid;
+
+   for (nid = 0; nid < MAX_NUMNODES && NODE_DATA(nid); nid++)
+   if (pfn >= node_start_pfn(nid) && pfn <= node_end_pfn(nid))
+   return nid;
+
+   return -1;
+}
+
+static inline int pfn_valid(int pfn)
+{
+   int nid = pfn_to_nid(pfn);
+
+   if (nid >= 0)
+   return pfn < node_end_pfn(nid);
+
+   return 0;
+}
+
 /*
  * Following are specific to this numa platform.
  */
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index dfe279529463..ec47f1081509 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -744,6 +744,13 @@ static void __init setup_nonnuma(void)
  PFN_PHYS(end_pfn - start_pfn),
  , nid);
node_set_online(nid);
+
+   /*
+* On DISCONTIGMEM systems, place different memory blocks into
+* different nodes.
+*/
+   if (IS_ENABLED(CONFIG_DISCONTIGMEM) && nid < MAX_NUMNODES - 1)
+   nid++;
}
 }
 
-- 
2.16.1

Re: [PATCH v2] watchdog: add SPDX identifiers for watchdog subsystem

[Marcus Folkesson]

On Tue, Feb 20, 2018 at 07:13:43AM -0800, Guenter Roeck wrote:
> On 02/20/2018 05:21 AM, Marcus Folkesson wrote:
> > Hello William,
> > 
> > On Tue, Feb 20, 2018 at 07:49:55AM -0500, William Breathitt Gray wrote:
> > > On Tue, Feb 20, 2018 at 11:45:31AM +0100, Marcus Folkesson wrote:
> > > > - Add SPDX identifier
> > > > - Remove boiler plate license text
> > > > - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
> > > >   license
> > > > 
> > > > Signed-off-by: Marcus Folkesson 
> > > > Acked-by: Adam Thomson 
> > > > Acked-by: Charles Keepax 
> > > > Acked-by: Nicolas Ferre 
> > > > Acked-by: Michal Simek 
> > > > ---
> > > > 
> > > > Notes:
> > > > v2:
> > > > - Put back removed copyright texts for meson_gxbb_wdt and 
> > > > coh901327_wdt
> > > > - Change to BSD-3-Clause for meson_gxbb_wdt
> > > > v1: Please have an extra look at meson_gxbb_wdt.c
> > > 
> > > [...]
> > > 
> > > > diff --git a/drivers/watchdog/ebc-c384_wdt.c 
> > > > b/drivers/watchdog/ebc-c384_wdt.c
> > > > index 2170b275ea01..c173b6f5c866 100644
> > > > --- a/drivers/watchdog/ebc-c384_wdt.c
> > > > +++ b/drivers/watchdog/ebc-c384_wdt.c
> > > > @@ -1,15 +1,8 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > /*
> > > >   * Watchdog timer driver for the WinSystems EBC-C384
> > > >   * Copyright (C) 2016 William Breathitt Gray
> > > >   *

The copyright is untouched?

> > > > - * This program is free software; you can redistribute it and/or modify
> > > > - * it under the terms of the GNU General Public License, version 2, as
> > > > - * published by the Free Software Foundation.
> > > > - *
> > > > - * This program is distributed in the hope that it will be useful, but
> > > > - * WITHOUT ANY WARRANTY; without even the implied warranty of
> > > > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > > > - * General Public License for more details.
> > > >   */
> > > > #include 
> > > > #include 
> > 
> > Thank you for your feedback!
> > > 
> > > I have no problem with adding a SPDX line to the top of this file, but
> > > use "SPDX-License-Identifier: GPL-2.0-only" as I was very intentional
> > > with the selection of GPL version 2 only when I published this code.
> > 
> > SPDX-License-Identifier: GPL-2.0
> > Is GPL-2.0 only [1], so it respects your choice of license.
> > 
> > > 
> > > Furthermore, please do not remove the existing copyright text; although
> > 
> 
> It is not a matter if you CAN keep a copyright. You MUST NOT remove a 
> copyright.
> As long as you do, the series is
> 
> Nacked-by: Guenter Roeck 
> 
> Guenter

I'm sorry, I do not see where the copyright is removed unless you count
the license text as part of the copyright.

Can you please point it out?

> 
> > The copyright text:
> > 
> >   Copyright (C) 2016 William Breathitt Gray
> > 
> > Is still in the file.

^^^

> > 
> > 
> > > it's just boilerplate for some, I was careful with the selection of
> > > these words, and I worry the SPDX line only -- despite its useful
> > > conciseness -- may lead to misunderstandings about my intentioned
> > > license for this code.
> > 
> > I'm not sure I understand your concerns here, the SPDX identifier is
> > a shorthand for the GPL 2.0 only license. See [1] - Linux kernel licensing 
> > rules.
> > 
> > One of the biggest benefits with SPDX identifier is that it is hard to 
> > verify
> > boiler plate licenses due to formatting, types, different formulations and 
> > so on.
> > 
> > If still worrying, I think we could keep the license text as
> > well.
> > 
> > > 
> > > For the time being, I can't Ack this patch with the changes it makes
> > > currently:
> > > 
> > >  Nacked-by: William Breathitt Gray 
> > > 
> > > William Breathitt Gray
> > 
> > Please let me know if I got you wrong at some point.
> > 
> > [1] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst
> > 
> > Best regards
> > Marcus Folkesson
> > 
> 

Best regards
Marcus Folkesson


signature.asc
Description: PGP signature

Re: [PATCH v2] watchdog: add SPDX identifiers for watchdog subsystem

[William Breathitt Gray]

On Tue, Feb 20, 2018 at 04:33:26PM +0100, Marcus Folkesson wrote:
>On Tue, Feb 20, 2018 at 07:13:43AM -0800, Guenter Roeck wrote:
>> On 02/20/2018 05:21 AM, Marcus Folkesson wrote:
>> > Hello William,
>> > 
>> > On Tue, Feb 20, 2018 at 07:49:55AM -0500, William Breathitt Gray wrote:
>> > > On Tue, Feb 20, 2018 at 11:45:31AM +0100, Marcus Folkesson wrote:
>> > > > - Add SPDX identifier
>> > > > - Remove boiler plate license text
>> > > > - If MODULE_LICENSE and boiler plate does not match, go for boiler 
>> > > > plate
>> > > >   license
>> > > > 
>> > > > Signed-off-by: Marcus Folkesson 
>> > > > Acked-by: Adam Thomson 
>> > > > Acked-by: Charles Keepax 
>> > > > Acked-by: Nicolas Ferre 
>> > > > Acked-by: Michal Simek 
>> > > > ---
>> > > > 
>> > > > Notes:
>> > > > v2:
>> > > >- Put back removed copyright texts for meson_gxbb_wdt and 
>> > > > coh901327_wdt
>> > > >- Change to BSD-3-Clause for meson_gxbb_wdt
>> > > > v1: Please have an extra look at meson_gxbb_wdt.c
>> > > 
>> > > [...]
>> > > 
>> > > > diff --git a/drivers/watchdog/ebc-c384_wdt.c 
>> > > > b/drivers/watchdog/ebc-c384_wdt.c
>> > > > index 2170b275ea01..c173b6f5c866 100644
>> > > > --- a/drivers/watchdog/ebc-c384_wdt.c
>> > > > +++ b/drivers/watchdog/ebc-c384_wdt.c
>> > > > @@ -1,15 +1,8 @@
>> > > > +// SPDX-License-Identifier: GPL-2.0
>> > > > /*
>> > > >   * Watchdog timer driver for the WinSystems EBC-C384
>> > > >   * Copyright (C) 2016 William Breathitt Gray
>> > > >   *
>
>The copyright is untouched?
>
>> > > > - * This program is free software; you can redistribute it and/or 
>> > > > modify
>> > > > - * it under the terms of the GNU General Public License, version 2, as
>> > > > - * published by the Free Software Foundation.
>> > > > - *
>> > > > - * This program is distributed in the hope that it will be useful, but
>> > > > - * WITHOUT ANY WARRANTY; without even the implied warranty of
>> > > > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> > > > - * General Public License for more details.
>> > > >   */
>> > > > #include 
>> > > > #include 
>> > 
>> > Thank you for your feedback!
>> > > 
>> > > I have no problem with adding a SPDX line to the top of this file, but
>> > > use "SPDX-License-Identifier: GPL-2.0-only" as I was very intentional
>> > > with the selection of GPL version 2 only when I published this code.
>> > 
>> > SPDX-License-Identifier: GPL-2.0
>> > Is GPL-2.0 only [1], so it respects your choice of license.

Ah, this should be fine then. :)

>> > 
>> > > 
>> > > Furthermore, please do not remove the existing copyright text; although
>> > 
>> 
>> It is not a matter if you CAN keep a copyright. You MUST NOT remove a 
>> copyright.
>> As long as you do, the series is
>> 
>> Nacked-by: Guenter Roeck 
>> 
>> Guenter
>
>I'm sorry, I do not see where the copyright is removed unless you count
>the license text as part of the copyright.
>
>Can you please point it out?
>
>> 
>> > The copyright text:
>> > 
>> >   Copyright (C) 2016 William Breathitt Gray
>> > 
>> > Is still in the file.
>
>^^^
>
>> > 
>> > 
>> > > it's just boilerplate for some, I was careful with the selection of
>> > > these words, and I worry the SPDX line only -- despite its useful
>> > > conciseness -- may lead to misunderstandings about my intentioned
>> > > license for this code.
>> > 
>> > I'm not sure I understand your concerns here, the SPDX identifier is
>> > a shorthand for the GPL 2.0 only license. See [1] - Linux kernel licensing 
>> > rules.
>> > 
>> > One of the biggest benefits with SPDX identifier is that it is hard to 
>> > verify
>> > boiler plate licenses due to formatting, types, different formulations and 
>> > so on.
>> > 
>> > If still worrying, I think we could keep the license text as
>> > well.

I'm sorry for the confusion, I should have wrote "license text" rather
than "copyright text" in my previous message. I agree with the benefits
of utilizing the SPDX identifier, and I see the addition of the SPDX
line as useful, but I would prefer the original license text remain as
well.

William Breathitt Gray

>> > 
>> > > 
>> > > For the time being, I can't Ack this patch with the changes it makes
>> > > currently:
>> > > 
>> > >  Nacked-by: William Breathitt Gray 
>> > > 
>> > > William Breathitt Gray
>> > 
>> > Please let me know if I got you wrong at some point.
>> > 
>> > [1] 
>> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst
>> > 
>> > Best regards
>> > Marcus Folkesson
>> > 
>> 
>
>Best regards
>Marcus Folkesson

[PATCH 0/9] powerpc cpu feature and kernel build stuff

[Nicholas Piggin]

These are various things that came up after taking a look
at dt_cpu_ftrs again. Just a bunch of small cleanups and
fixes.

Nicholas Piggin (9):
  powerpc/64s: cputable add all POWER9 features to CPU_FTRS_ALWAYS
  powerpc/64s: fix CPU_FTRS_POSSIBLE vector features
  powerpc/64s: kbuild set assembler machine type to POWER4
  powerpc/64s: dt_cpu_ftrs fix POWER9 DD2.2 and above
  powerpc: remove unused CPU_FTR_ARCH_201
  powerpc/64s: remove POWER4 support
  powerpc/64/le: add GENERIC_CPU support
  powerpc/64s/le: refine feature sets for little endian builds
  powerpc/64s: add POWER9 CPU type selection

 arch/powerpc/Makefile  |  12 +-
 arch/powerpc/include/asm/cputable.h|  33 +-
 arch/powerpc/include/asm/mmu.h |   6 +-
 arch/powerpc/include/asm/ppc_asm.h |  11 +-
 arch/powerpc/kernel/cputable.c |  36 +-
 arch/powerpc/kernel/dt_cpu_ftrs.c  |   4 +-
 arch/powerpc/kernel/entry_64.S |   2 +-
 arch/powerpc/kernel/exceptions-64s.S   |  10 +-
 arch/powerpc/kernel/prom_init.c|  10 +-
 arch/powerpc/kvm/emulate.c |   6 -
 arch/powerpc/lib/copypage_power7.S |   3 -
 arch/powerpc/lib/copyuser_power7.S |   3 -
 arch/powerpc/lib/memcpy_power7.S   |   3 -
 arch/powerpc/mm/hash_utils_64.c|   9 +-
 arch/powerpc/perf/Makefile |   2 +-
 arch/powerpc/perf/power4-pmu.c | 622 -
 arch/powerpc/platforms/Kconfig.cputype |  17 +-
 17 files changed, 63 insertions(+), 726 deletions(-)
 delete mode 100644 arch/powerpc/perf/power4-pmu.c

-- 
2.16.1

[PATCH 4/9] powerpc/64s: dt_cpu_ftrs fix POWER9 DD2.2 and above

[Nicholas Piggin]

The CPU_FTR_POWER9_DD2_1 flag is intended to be set for DD2.1 and
above (which is what the cputable setup does). Fix dt_cpu_ftrs setup
to match.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/kernel/dt_cpu_ftrs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c 
b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 945e2c29ad2d..cb6ae7b3cdd6 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -707,7 +707,9 @@ static __init void cpufeatures_cpu_quirks(void)
 */
if ((version & 0xff00) == 0x004e0100)
cur_cpu_spec->cpu_features |= CPU_FTR_POWER9_DD1;
-   else if ((version & 0xefff) == 0x004e0201)
+   else if ((version & 0xefff) == 0x004e0200)
+   ; /* DD2.0 has no feature flag */
+   else /* DD2.1 and up have DD2_1 */
cur_cpu_spec->cpu_features |= CPU_FTR_POWER9_DD2_1;
 }
 
-- 
2.16.1

[PATCH 2/9] powerpc/64s: fix CPU_FTRS_POSSIBLE vector features

[Nicholas Piggin]

ALTIVEC and VSX features are not default in the POWER CPU feature
sets because they are intended to be enabled by firmware. They
should be added individually to the CPU_FTRS_POSSIBLE set. It
already contains CPU_FTR_VSX, so add ALTIVEC. This becomes
important with a reduced set of supported CPUs.

The _COMP features should be used because they won't be present
if compiled out.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/include/asm/cputable.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 1fb9b1ea4662..27bb8e96ce7a 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -488,8 +488,8 @@ static inline void cpu_feature_keys_init(void) { }
(CPU_FTRS_POWER4 | CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | \
 CPU_FTRS_POWER6 | CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | \
 CPU_FTRS_POWER8 | CPU_FTRS_POWER8_DD1 | CPU_FTRS_CELL | \
-CPU_FTRS_PA6T | CPU_FTR_VSX | CPU_FTRS_POWER9 | \
-CPU_FTRS_POWER9_DD1 | CPU_FTRS_POWER9_DD2_1)
+CPU_FTRS_PA6T | CPU_FTR_ALTIVEC_COMP | CPU_FTR_VSX_COMP | \
+CPU_FTRS_POWER9 | CPU_FTRS_POWER9_DD1 | CPU_FTRS_POWER9_DD2_1)
 #endif
 #else
 enum {
-- 
2.16.1

Re: [PATCH v2] watchdog: add SPDX identifiers for watchdog subsystem

[Guenter Roeck]

On 02/20/2018 05:21 AM, Marcus Folkesson wrote:

Hello William,

On Tue, Feb 20, 2018 at 07:49:55AM -0500, William Breathitt Gray wrote:

On Tue, Feb 20, 2018 at 11:45:31AM +0100, Marcus Folkesson wrote:

- Add SPDX identifier
- Remove boiler plate license text
- If MODULE_LICENSE and boiler plate does not match, go for boiler plate
  license

Signed-off-by: Marcus Folkesson 
Acked-by: Adam Thomson 
Acked-by: Charles Keepax 
Acked-by: Nicolas Ferre 
Acked-by: Michal Simek 
---

Notes:
v2:
- Put back removed copyright texts for meson_gxbb_wdt and coh901327_wdt
- Change to BSD-3-Clause for meson_gxbb_wdt
v1: Please have an extra look at meson_gxbb_wdt.c


[...]


diff --git a/drivers/watchdog/ebc-c384_wdt.c b/drivers/watchdog/ebc-c384_wdt.c
index 2170b275ea01..c173b6f5c866 100644
--- a/drivers/watchdog/ebc-c384_wdt.c
+++ b/drivers/watchdog/ebc-c384_wdt.c
@@ -1,15 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
/*
  * Watchdog timer driver for the WinSystems EBC-C384
  * Copyright (C) 2016 William Breathitt Gray
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License, version 2, as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
  */
#include 
#include 


Thank you for your feedback!


I have no problem with adding a SPDX line to the top of this file, but
use "SPDX-License-Identifier: GPL-2.0-only" as I was very intentional
with the selection of GPL version 2 only when I published this code.


SPDX-License-Identifier: GPL-2.0
Is GPL-2.0 only [1], so it respects your choice of license.



Furthermore, please do not remove the existing copyright text; although




It is not a matter if you CAN keep a copyright. You MUST NOT remove a copyright.
As long as you do, the series is

Nacked-by: Guenter Roeck 

Guenter


The copyright text:

  Copyright (C) 2016 William Breathitt Gray

Is still in the file.



it's just boilerplate for some, I was careful with the selection of
these words, and I worry the SPDX line only -- despite its useful
conciseness -- may lead to misunderstandings about my intentioned
license for this code.


I'm not sure I understand your concerns here, the SPDX identifier is
a shorthand for the GPL 2.0 only license. See [1] - Linux kernel licensing 
rules.

One of the biggest benefits with SPDX identifier is that it is hard to verify
boiler plate licenses due to formatting, types, different formulations and so 
on.

If still worrying, I think we could keep the license text as
well.



For the time being, I can't Ack this patch with the changes it makes
currently:

 Nacked-by: William Breathitt Gray 

William Breathitt Gray


Please let me know if I got you wrong at some point.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst

Best regards
Marcus Folkesson

[PATCH 6/9] powerpc/64s: remove POWER4 support

[Nicholas Piggin]

POWER4 has been broken since at least the change 49d09bf2a6
("powerpc/64s: Optimise MSR handling in exception handling"), which
requires mtmsrd L=1 support. This was introduced in ISA v2.01, and
POWER4 supports ISA v2.00.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/Makefile  |   5 +-
 arch/powerpc/include/asm/cputable.h|   8 +-
 arch/powerpc/include/asm/mmu.h |   6 +-
 arch/powerpc/kernel/cputable.c |  36 +-
 arch/powerpc/kernel/prom_init.c|  10 +-
 arch/powerpc/kvm/emulate.c |   6 -
 arch/powerpc/mm/hash_utils_64.c|   9 +-
 arch/powerpc/perf/Makefile |   2 +-
 arch/powerpc/perf/power4-pmu.c | 622 -
 arch/powerpc/platforms/Kconfig.cputype |   6 +-
 10 files changed, 18 insertions(+), 692 deletions(-)
 delete mode 100644 arch/powerpc/perf/power4-pmu.c

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index cb6de0815a28..2265d53023f4 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -144,8 +144,8 @@ CFLAGS-$(CONFIG_PPC64)  += $(call 
cc-option,-mno-pointers-to-nested-functions)
 CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 $(MULTIPLEWORD)
 
 ifeq ($(CONFIG_PPC_BOOK3S_64),y)
-CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power7,-mtune=power4)
-CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power4
+CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power7,$(call 
cc-option,-mtune=power5))
+CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mcpu=power5,-mcpu=power4)
 else
 CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=powerpc64
 endif
@@ -166,7 +166,6 @@ ifdef CONFIG_MPROFILE_KERNEL
 endif
 
 CFLAGS-$(CONFIG_CELL_CPU) += $(call cc-option,-mcpu=cell)
-CFLAGS-$(CONFIG_POWER4_CPU) += $(call cc-option,-mcpu=power4)
 CFLAGS-$(CONFIG_POWER5_CPU) += $(call cc-option,-mcpu=power5)
 CFLAGS-$(CONFIG_POWER6_CPU) += $(call cc-option,-mcpu=power6)
 CFLAGS-$(CONFIG_POWER7_CPU) += $(call cc-option,-mcpu=power7)
diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 1c684aa7e0de..8907f44df708 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -411,10 +411,6 @@ static inline void cpu_feature_keys_init(void) { }
 #define CPU_FTRS_GENERIC_32(CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN)
 
 /* 64-bit CPUs */
-#define CPU_FTRS_POWER4(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
-   CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
-   CPU_FTR_MMCRA | CPU_FTR_CP_USE_DCBTZ | \
-   CPU_FTR_STCX_CHECKS_ADDRESS)
 #define CPU_FTRS_PPC970(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA | \
@@ -484,7 +480,7 @@ static inline void cpu_feature_keys_init(void) { }
 #define CPU_FTRS_POSSIBLE  (CPU_FTRS_E6500 | CPU_FTRS_E5500)
 #else
 #define CPU_FTRS_POSSIBLE  \
-   (CPU_FTRS_POWER4 | CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | \
+   (CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | \
 CPU_FTRS_POWER6 | CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | \
 CPU_FTRS_POWER8 | CPU_FTRS_POWER8_DD1 | CPU_FTRS_CELL | \
 CPU_FTRS_PA6T | CPU_FTR_ALTIVEC_COMP | CPU_FTR_VSX_COMP | \
@@ -536,7 +532,7 @@ enum {
 #define CPU_FTRS_ALWAYS(CPU_FTRS_E6500 & CPU_FTRS_E5500)
 #else
 #define CPU_FTRS_ALWAYS\
-   (CPU_FTRS_POWER4 & CPU_FTRS_PPC970 & CPU_FTRS_POWER5 & \
+   (CPU_FTRS_PPC970 & CPU_FTRS_POWER5 & \
 CPU_FTRS_POWER6 & CPU_FTRS_POWER7 & CPU_FTRS_CELL & \
 CPU_FTRS_PA6T & CPU_FTRS_POWER8 & CPU_FTRS_POWER8E & \
 CPU_FTRS_POWER8_DD1 & ~CPU_FTR_HVMODE & CPU_FTRS_POSSIBLE & \
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index bb38312cff28..61d15ce92278 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -111,9 +111,9 @@
 /* MMU feature bit sets for various CPUs */
 #define MMU_FTRS_DEFAULT_HPTE_ARCH_V2  \
MMU_FTR_HPTE_TABLE | MMU_FTR_PPCAS_ARCH_V2
-#define MMU_FTRS_POWER4MMU_FTRS_DEFAULT_HPTE_ARCH_V2
-#define MMU_FTRS_PPC970MMU_FTRS_POWER4 | MMU_FTR_TLBIE_CROP_VA
-#define MMU_FTRS_POWER5MMU_FTRS_POWER4 | MMU_FTR_LOCKLESS_TLBIE
+#define MMU_FTRS_POWER MMU_FTRS_DEFAULT_HPTE_ARCH_V2
+#define MMU_FTRS_PPC970MMU_FTRS_POWER | MMU_FTR_TLBIE_CROP_VA
+#define MMU_FTRS_POWER5MMU_FTRS_POWER | MMU_FTR_LOCKLESS_TLBIE
 #define MMU_FTRS_POWER6MMU_FTRS_POWER5 | MMU_FTR_KERNEL_RO | 
MMU_FTR_68_BIT_VA
 #define MMU_FTRS_POWER7MMU_FTRS_POWER6
 #define MMU_FTRS_POWER8MMU_FTRS_POWER6
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index c40a9fc1e5d1..40aea5e48279 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -133,36 +133,6 @@ extern void 

Re: [PATCH 2/3] rfi-flush: Make it possible to call setup_rfi_flush() again

[Michal Suchánek]

On Tue, 20 Feb 2018 20:59:18 +1100
Michael Ellerman  wrote:

> Mauricio Faria de Oliveira  writes:
> 
> > Hi Michal and Michael,
> >
> > On 02/15/2018 05:13 AM, Michal Suchánek wrote:  
> >>> From: Michael Ellerman
> >>>
> >>> For PowerVM migration we want to be able to call setup_rfi_flush()
> >>> again after we've migrated the partition.
> >>>
> >>> To support that we need to check that we're not trying to
> >>> allocate the fallback flush area after memblock has gone away. If
> >>> so we just fail, we don't support migrating from a patched to an
> >>> unpatched machine. Or we do support it, but there will be no RFI
> >>> flush enabled on the destination.
> >>>  
> >> This sounds bad to me. Either we support RFI flush or we don't.
> >> 
> >> If we do the fallback area should be allocated at boot so it is
> >> always available. [snip]  
> >
> > I think the problem with this is the size of the fallback area might
> > have to be different between the origin and destination systems,
> > say, a larger L1 data cache at the destination.
> >
> > In that case, the original size might not be enough to fully flush
> > the L1 data cache.
> >
> > Michael, is that the reason it is done that way?  I thought of that,
> > but don't know for sure.  
> 
> No, supporting different cache sizes is a good idea though :)
> 
> I did it the way I did because otherwise we waste memory on every
> system on earth just to support a use case that we don't actually
> intend for anyone to ever use - ie. migrating from a patched machine
> to an unpatched machine.

If you have multiple hosts running some LPMs and want to update them
without shutting down the whole thing I suppose it might easily happen
that a machine (re)started on a patched host is migrated to unpatched
host.

> 
> In fact without further checks we'd be allocating the fallback area on
> powernv machines which don't even support LPM.

They support suspend to disk which basically amounts to the same thing.
Downgrading the firmware while in sleep does not sound like a good
idea, though.

> 
> So that just seemed a bit gross.
> 
> I think I'm inclined to leave it the way it is, unless you feel
> strongly about it Michal?

I think it would be more user friendly to either support the fallback
method 100% or remove it and require patched firmware. 

Thanks

Michal

[PATCH 1/9] powerpc/64s: cputable add all POWER9 features to CPU_FTRS_ALWAYS

[Nicholas Piggin]

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/include/asm/cputable.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index a2c5c95882cf..1fb9b1ea4662 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -541,7 +541,7 @@ enum {
 CPU_FTRS_POWER6 & CPU_FTRS_POWER7 & CPU_FTRS_CELL & \
 CPU_FTRS_PA6T & CPU_FTRS_POWER8 & CPU_FTRS_POWER8E & \
 CPU_FTRS_POWER8_DD1 & ~CPU_FTR_HVMODE & CPU_FTRS_POSSIBLE & \
-CPU_FTRS_POWER9)
+CPU_FTRS_POWER9 & CPU_FTRS_POWER9_DD1 & CPU_FTRS_POWER9_DD2_1)
 #endif
 #else
 enum {
-- 
2.16.1

[PATCH 9/9] powerpc/64s: add POWER9 CPU type selection

[Nicholas Piggin]

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/Makefile  | 3 ++-
 arch/powerpc/platforms/Kconfig.cputype | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 973b1a1b98d2..f46b6cf364d7 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -146,7 +146,7 @@ CFLAGS-$(CONFIG_PPC32)  := -ffixed-r2 $(MULTIPLEWORD)
 ifeq ($(CONFIG_PPC_BOOK3S_64),y)
 ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
 CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power8
-CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power8)
+CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power9,-mtune=power8)
 else
 CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power7,$(call 
cc-option,-mtune=power5))
 CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mcpu=power5,-mcpu=power4)
@@ -175,6 +175,7 @@ CFLAGS-$(CONFIG_POWER5_CPU) += $(call 
cc-option,-mcpu=power5)
 CFLAGS-$(CONFIG_POWER6_CPU) += $(call cc-option,-mcpu=power6)
 CFLAGS-$(CONFIG_POWER7_CPU) += $(call cc-option,-mcpu=power7)
 CFLAGS-$(CONFIG_POWER8_CPU) += $(call cc-option,-mcpu=power8)
+CFLAGS-$(CONFIG_POWER9_CPU) += $(call cc-option,-mcpu=power9)
 
 # Altivec option not allowed with e500mc64 in GCC.
 ifeq ($(CONFIG_ALTIVEC),y)
diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index ad878990c896..69be65450c0c 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -121,6 +121,11 @@ config POWER8_CPU
depends on PPC_BOOK3S_64
select ARCH_HAS_FAST_MULTIPLIER
 
+config POWER9_CPU
+   bool "POWER9"
+   depends on PPC_BOOK3S_64
+   select ARCH_HAS_FAST_MULTIPLIER
+
 config E5500_CPU
bool "Freescale e5500"
depends on E500
-- 
2.16.1

[PATCH 5/9] powerpc: remove unused CPU_FTR_ARCH_201

[Nicholas Piggin]

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/include/asm/cputable.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 27bb8e96ce7a..1c684aa7e0de 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -175,7 +175,6 @@ static inline void cpu_feature_keys_init(void) { }
 #endif
 
 #define CPU_FTR_HVMODE LONG_ASM_CONST(0x0001)
-#define CPU_FTR_ARCH_201   LONG_ASM_CONST(0x0002)
 #define CPU_FTR_ARCH_206   LONG_ASM_CONST(0x0004)
 #define CPU_FTR_ARCH_207S  LONG_ASM_CONST(0x0008)
 #define CPU_FTR_ARCH_300   LONG_ASM_CONST(0x0010)
@@ -417,7 +416,7 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_MMCRA | CPU_FTR_CP_USE_DCBTZ | \
CPU_FTR_STCX_CHECKS_ADDRESS)
 #define CPU_FTRS_PPC970(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
-   CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_201 | \
+   CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA | \
CPU_FTR_CP_USE_DCBTZ | CPU_FTR_STCX_CHECKS_ADDRESS | \
CPU_FTR_HVMODE | CPU_FTR_DABRX)
-- 
2.16.1

[PATCH 3/9] powerpc/64s: kbuild set assembler machine type to POWER4

[Nicholas Piggin]

Rather than override the machine type in .S code (which can hide
wrong or ambiguous code generation for the target), set the type
to power4 for all assembly.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/Makefile|  1 +
 arch/powerpc/include/asm/ppc_asm.h   | 11 ---
 arch/powerpc/kernel/entry_64.S   |  2 +-
 arch/powerpc/kernel/exceptions-64s.S | 10 ++
 arch/powerpc/lib/copypage_power7.S   |  3 ---
 arch/powerpc/lib/copyuser_power7.S   |  3 ---
 arch/powerpc/lib/memcpy_power7.S |  3 ---
 7 files changed, 8 insertions(+), 25 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index ccd2556bdb53..cb6de0815a28 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -243,6 +243,7 @@ endif
 cpu-as-$(CONFIG_4xx)   += -Wa,-m405
 cpu-as-$(CONFIG_ALTIVEC)   += $(call as-option,-Wa$(comma)-maltivec)
 cpu-as-$(CONFIG_E200)  += -Wa,-me200
+cpu-as-$(CONFIG_PPC_BOOK3S_64) += -Wa,-mpower4
 
 KBUILD_AFLAGS += $(cpu-as-y)
 KBUILD_CFLAGS += $(cpu-as-y)
diff --git a/arch/powerpc/include/asm/ppc_asm.h 
b/arch/powerpc/include/asm/ppc_asm.h
index ae94b3626b6c..13f7f4c0e1ea 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -439,14 +439,11 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
 
 /* The following stops all load and store data streams associated with stream
  * ID (ie. streams created explicitly).  The embedded and server mnemonics for
- * dcbt are different so we use machine "power4" here explicitly.
+ * dcbt are different so this must only be used for server.
  */
-#define DCBT_STOP_ALL_STREAM_IDS(scratch)  \
-.machine push ;\
-.machine "power4" ;\
-   lis scratch,0x6000@h;   \
-   dcbt0,scratch,0b01010;  \
-.machine pop
+#define DCBT_BOOK3S_STOP_ALL_STREAM_IDS(scratch)   \
+   lis scratch,0x6000@h;   \
+   dcbt0,scratch,0b01010
 
 /*
  * toreal/fromreal/tophys/tovirt macros. 32-bit BookE makes them
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 2cb5109a7ea3..51695608c68b 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -545,7 +545,7 @@ _GLOBAL(_switch)
 /* Cancel all explict user streams as they will have no use after context
  * switch and will stop the HW from creating streams itself
  */
-   DCBT_STOP_ALL_STREAM_IDS(r6)
+   DCBT_BOOK3S_STOP_ALL_STREAM_IDS(r6)
 #endif
 
addir6,r4,-THREAD   /* Convert THREAD to 'current' */
diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index 3ac87e53b3da..19a021eae769 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -629,14 +629,11 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_TYPE_RADIX)
 
bne cr4,1f  /* returning to kernel */
 
-.machine   push
-.machine   "power4"
mtcrf   0x80,r9
mtcrf   0x08,r9 /* MSR[PR] indication is in cr4 */
mtcrf   0x04,r9 /* MSR[RI] indication is in cr5 */
mtcrf   0x02,r9 /* I/D indication is in cr6 */
mtcrf   0x01,r9 /* slb_allocate uses cr0 and cr7 */
-.machine   pop
 
RESTORE_CTR(r9, PACA_EXSLB)
RESTORE_PPR_PACA(PACA_EXSLB, r9)
@@ -649,14 +646,11 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_TYPE_RADIX)
RFI_TO_USER
b   .   /* prevent speculative execution */
 1:
-.machine   push
-.machine   "power4"
mtcrf   0x80,r9
mtcrf   0x08,r9 /* MSR[PR] indication is in cr4 */
mtcrf   0x04,r9 /* MSR[RI] indication is in cr5 */
mtcrf   0x02,r9 /* I/D indication is in cr6 */
mtcrf   0x01,r9 /* slb_allocate uses cr0 and cr7 */
-.machine   pop
 
RESTORE_CTR(r9, PACA_EXSLB)
RESTORE_PPR_PACA(PACA_EXSLB, r9)
@@ -1466,7 +1460,7 @@ TRAMP_REAL_BEGIN(rfi_flush_fallback)
ld  r11,PACA_L1D_FLUSH_SIZE(r13)
srdir11,r11,(7 + 3) /* 128 byte lines, unrolled 8x */
mtctr   r11
-   DCBT_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
+   DCBT_BOOK3S_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
 
/* order ld/st prior to dcbt stop all streams with flushing */
sync
@@ -1506,7 +1500,7 @@ TRAMP_REAL_BEGIN(hrfi_flush_fallback)
ld  r11,PACA_L1D_FLUSH_SIZE(r13)
srdir11,r11,(7 + 3) /* 128 byte lines, unrolled 8x */
mtctr   r11
-   DCBT_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
+   DCBT_BOOK3S_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
 
/* order ld/st prior to dcbt stop all streams with flushing */
sync
diff --git a/arch/powerpc/lib/copypage_power7.S 
b/arch/powerpc/lib/copypage_power7.S
index ca5fc8fa7efc..8fa73b7ab20e 100644
--- 

[PATCH 8/9] powerpc/64s/le: refine feature sets for little endian builds

[Nicholas Piggin]

This reduces vmlinux text size by 1kB and data by 1.5kB with
a small build!

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/include/asm/cputable.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 8907f44df708..cb423f2a5696 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -479,6 +479,13 @@ static inline void cpu_feature_keys_init(void) { }
 #ifdef CONFIG_PPC_BOOK3E
 #define CPU_FTRS_POSSIBLE  (CPU_FTRS_E6500 | CPU_FTRS_E5500)
 #else
+#ifdef CONFIG_CPU_LITTLE_ENDIAN
+#define CPU_FTRS_POSSIBLE  \
+   (CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | \
+CPU_FTRS_POWER8 | CPU_FTRS_POWER8_DD1 | \
+CPU_FTR_ALTIVEC_COMP | CPU_FTR_VSX_COMP | \
+CPU_FTRS_POWER9 | CPU_FTRS_POWER9_DD1 | CPU_FTRS_POWER9_DD2_1)
+#else
 #define CPU_FTRS_POSSIBLE  \
(CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | \
 CPU_FTRS_POWER6 | CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | \
@@ -486,6 +493,7 @@ static inline void cpu_feature_keys_init(void) { }
 CPU_FTRS_PA6T | CPU_FTR_ALTIVEC_COMP | CPU_FTR_VSX_COMP | \
 CPU_FTRS_POWER9 | CPU_FTRS_POWER9_DD1 | CPU_FTRS_POWER9_DD2_1)
 #endif
+#endif
 #else
 enum {
CPU_FTRS_POSSIBLE =
@@ -531,6 +539,13 @@ enum {
 #ifdef CONFIG_PPC_BOOK3E
 #define CPU_FTRS_ALWAYS(CPU_FTRS_E6500 & CPU_FTRS_E5500)
 #else
+#ifdef CONFIG_CPU_LITTLE_ENDIAN
+#define CPU_FTRS_ALWAYS \
+   (CPU_FTRS_POWER7 & CPU_FTRS_POWER8E & \
+CPU_FTRS_POWER8 & CPU_FTRS_POWER8_DD1 & \
+CPU_FTRS_POWER9 & CPU_FTRS_POWER9_DD1 & CPU_FTRS_POWER9_DD2_1 & \
+CPU_FTRS_POSSIBLE & ~CPU_FTR_HVMODE)
+#else
 #define CPU_FTRS_ALWAYS\
(CPU_FTRS_PPC970 & CPU_FTRS_POWER5 & \
 CPU_FTRS_POWER6 & CPU_FTRS_POWER7 & CPU_FTRS_CELL & \
@@ -538,6 +553,7 @@ enum {
 CPU_FTRS_POWER8_DD1 & ~CPU_FTR_HVMODE & CPU_FTRS_POSSIBLE & \
 CPU_FTRS_POWER9 & CPU_FTRS_POWER9_DD1 & CPU_FTRS_POWER9_DD2_1)
 #endif
+#endif
 #else
 enum {
CPU_FTRS_ALWAYS =
-- 
2.16.1

[PATCH 7/9] powerpc/64/le: add GENERIC_CPU support

[Nicholas Piggin]

Add GENERIC_CPU support for little-endian rather than using POWER8
specific selection for POWER9 and above.

Restrict GENERIC_CPU to POWER8 and above on little endian.

Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/Makefile  | 5 +
 arch/powerpc/platforms/Kconfig.cputype | 6 +++---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 2265d53023f4..973b1a1b98d2 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -144,8 +144,13 @@ CFLAGS-$(CONFIG_PPC64) += $(call 
cc-option,-mno-pointers-to-nested-functions)
 CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 $(MULTIPLEWORD)
 
 ifeq ($(CONFIG_PPC_BOOK3S_64),y)
+ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
+CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power8
+CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power8)
+else
 CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power7,$(call 
cc-option,-mtune=power5))
 CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mcpu=power5,-mcpu=power4)
+endif
 else
 CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=powerpc64
 endif
diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index 560466cc5170..ad878990c896 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -87,7 +87,6 @@ endchoice
 choice
prompt "CPU selection"
depends on PPC64
-   default POWER8_CPU if CPU_LITTLE_ENDIAN
default GENERIC_CPU
help
  This will create a kernel which is optimised for a particular CPU.
@@ -96,8 +95,9 @@ choice
  If unsure, select Generic.
 
 config GENERIC_CPU
-   bool "Generic"
-   depends on !CPU_LITTLE_ENDIAN
+   bool "Generic" if !CPU_LITTLE_ENDIAN
+   bool "Generic (POWER8 and above)" if CPU_LITTLE_ENDIAN
+   select ARCH_HAS_FAST_MULTIPLIER if CPU_LITTLE_ENDIAN
 
 config CELL_CPU
bool "Cell Broadband Engine"
-- 
2.16.1

Re: [PATCH v2] watchdog: add SPDX identifiers for watchdog subsystem

[Matthias Brugger]

On 02/20/2018 11:45 AM, Marcus Folkesson wrote:
> - Add SPDX identifier
> - Remove boiler plate license text
> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
>   license
> 
> Signed-off-by: Marcus Folkesson 
> Acked-by: Adam Thomson 
> Acked-by: Charles Keepax 
> Acked-by: Nicolas Ferre 
> Acked-by: Michal Simek 
> ---
> 
> Notes:
> v2:
>   - Put back removed copyright texts for meson_gxbb_wdt and coh901327_wdt
>   - Change to BSD-3-Clause for meson_gxbb_wdt
> v1: Please have an extra look at meson_gxbb_wdt.c
> 
>  drivers/watchdog/acquirewdt.c  |  6 +---

[...]

>  drivers/watchdog/mpc8xxx_wdt.c |  6 +---
>  drivers/watchdog/mt7621_wdt.c  |  5 +---
>  drivers/watchdog/mtk_wdt.c | 11 +---
>  drivers/watchdog/mtx-1_wdt.c   | 11 +---
>  drivers/watchdog/mv64x60_wdt.c |  6 ++--

[...]

> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index 7ed417a765c7..498e7d4e1b66 100644
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Mediatek Watchdog Driver
>   *
> @@ -5,16 +6,6 @@
>   *
>   * Matthias Brugger 
>   *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
>   * Based on sunxi_wdt.c
>   */
>  

Acked-by: Matthias Brugger 

[PATCH v9 1/2] powerpc/powernv: Enable tunneled operations

[Philippe Bergheaud]

P9 supports PCI tunneled operations (atomics and as_notify). This
patch adds support for tunneled operations on powernv, with a new
API, to be called by device drivers:

pnv_pci_enable_tunnel()
   Enable tunnel operations, tell driver the 16-bit ASN indication
   used by kernel.

pnv_pci_disable_tunnel()
   Disable tunnel operations.

pnv_pci_set_tunnel_bar()
   Tell kernel the Tunnel BAR Response address used by driver.
   This function uses two new OPAL calls, as the PBCQ Tunnel BAR
   register is configured by skiboot.

pnv_pci_get_as_notify_info()
   Return the ASN info of the thread to be woken up.

Signed-off-by: Philippe Bergheaud 
---
Changelog:

v2: Do not set the ASN indication. Get it from the device tree.

v3: Make pnv_pci_get_phb_node() available when compiling without cxl.

v4: Add pnv_pci_get_as_notify_info().
Rebase opal call numbers on skiboot 5.9.6.

v5: pnv_pci_get_tunnel_ind():
  - fix node reference count
pnv_pci_get_as_notify_info():
  - fail if task == NULL
  - read pid from mm->context.id
  - explain that thread.tidr require CONFIG_PPC64

v6: pnv_pci_get_tunnel_ind():
  - check if radix is enabled, or else return an error
pnv_pci_get_as_notify_info():
  - remove a capi-specific comment, irrelevant for pci

v7: pnv_pci_set_tunnel_bar():
  - setting the tunnel bar more than once with the same value
is not an error

v8: No change

v9: Rename pnv_pci_get_tunnel_ind() into pnv_pci_enable_tunnel():
  - Increase real window size to accept as_notify messages.
New api pnv_pci_disable_tunnel():
  - Restore real window size to its default value.
Adjust opal call numbers.

This patch depends on the following skiboot patches:
  https://patchwork.ozlabs.org/patch/874415/
  https://patchwork.ozlabs.org/patch/874416/
---
 arch/powerpc/include/asm/opal-api.h|   4 +-
 arch/powerpc/include/asm/opal.h|   2 +
 arch/powerpc/include/asm/pnv-pci.h |   6 ++
 arch/powerpc/platforms/powernv/opal-wrappers.S |   2 +
 arch/powerpc/platforms/powernv/pci-cxl.c   |   8 --
 arch/powerpc/platforms/powernv/pci.c   | 135 +
 6 files changed, 148 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 94bd1bf2c873..07b5e2240ecc 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -204,7 +204,9 @@
 #define OPAL_NPU_SPA_SETUP 159
 #define OPAL_NPU_SPA_CLEAR_CACHE   160
 #define OPAL_NPU_TL_SET161
-#define OPAL_LAST  161
+#define OPAL_PCI_GET_PBCQ_TUNNEL_BAR   162
+#define OPAL_PCI_SET_PBCQ_TUNNEL_BAR   163
+#define OPAL_LAST  163
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 12e70fb58700..dde60089d0d4 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -204,6 +204,8 @@ int64_t opal_unregister_dump_region(uint32_t id);
 int64_t opal_slw_set_reg(uint64_t cpu_pir, uint64_t sprn, uint64_t val);
 int64_t opal_config_cpu_idle_state(uint64_t state, uint64_t flag);
 int64_t opal_pci_set_phb_cxl_mode(uint64_t phb_id, uint64_t mode, uint64_t 
pe_number);
+int64_t opal_pci_get_pbcq_tunnel_bar(uint64_t phb_id, uint64_t *addr);
+int64_t opal_pci_set_pbcq_tunnel_bar(uint64_t phb_id, uint64_t addr);
 int64_t opal_ipmi_send(uint64_t interface, struct opal_ipmi_msg *msg,
uint64_t msg_len);
 int64_t opal_ipmi_recv(uint64_t interface, struct opal_ipmi_msg *msg,
diff --git a/arch/powerpc/include/asm/pnv-pci.h 
b/arch/powerpc/include/asm/pnv-pci.h
index 3e5cf251ad9a..d2d8c28db336 100644
--- a/arch/powerpc/include/asm/pnv-pci.h
+++ b/arch/powerpc/include/asm/pnv-pci.h
@@ -29,6 +29,12 @@ extern int pnv_pci_set_power_state(uint64_t id, uint8_t 
state,
 extern int pnv_pci_set_p2p(struct pci_dev *initiator, struct pci_dev *target,
   u64 desc);
 
+extern int pnv_pci_enable_tunnel(struct pci_dev *dev, uint64_t *asnind);
+extern int pnv_pci_disable_tunnel(struct pci_dev *dev);
+extern int pnv_pci_set_tunnel_bar(struct pci_dev *dev, uint64_t addr,
+ int enable);
+extern int pnv_pci_get_as_notify_info(struct task_struct *task, u32 *lpid,
+ u32 *pid, u32 *tid);
 int pnv_phb_to_cxl_mode(struct pci_dev *dev, uint64_t mode);
 int pnv_cxl_ioda_msi_setup(struct pci_dev *dev, unsigned int hwirq,
   unsigned int virq);
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S 
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 1b2936ba6040..3da30c2f26b4 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -323,3 +323,5 @@ OPAL_CALL(opal_sensor_group_clear,   

Re: [PATCH] powerpc/npu-dma.c: Fix deadlock in mmio_invalidate

[Mark Hairgrove]

On Mon, 19 Feb 2018, Balbir Singh wrote:

> Good point, although I think the acquire_* function itself may be called
> from a higher layer with the mmap_sem always held. I wonder if we need
> barriers around get and put mmio_atsd_reg.

I agree with the need for memory barriers. FWIW, page tables can be
invalidated without mmap_sem being held, for example by
unmap_mapping_range.

Re: [PATCH v2] watchdog: add SPDX identifiers for watchdog subsystem

[Marcus Folkesson]

On Tue, Feb 20, 2018 at 01:14:27PM -0500, William Breathitt Gray wrote:
> On Tue, Feb 20, 2018 at 04:33:26PM +0100, Marcus Folkesson wrote:
> >On Tue, Feb 20, 2018 at 07:13:43AM -0800, Guenter Roeck wrote:
> >> On 02/20/2018 05:21 AM, Marcus Folkesson wrote:
> >> > Hello William,
> >> > 
> >> > On Tue, Feb 20, 2018 at 07:49:55AM -0500, William Breathitt Gray wrote:
> >> > > On Tue, Feb 20, 2018 at 11:45:31AM +0100, Marcus Folkesson wrote:
> >> > > > - Add SPDX identifier
> >> > > > - Remove boiler plate license text
> >> > > > - If MODULE_LICENSE and boiler plate does not match, go for boiler 
> >> > > > plate
> >> > > >   license
> >> > > > 
> >> > > > Signed-off-by: Marcus Folkesson 
> >> > > > Acked-by: Adam Thomson 
> >> > > > Acked-by: Charles Keepax 
> >> > > > Acked-by: Nicolas Ferre 
> >> > > > Acked-by: Michal Simek 
> >> > > > ---
> >> > > > 
> >> > > > Notes:
> >> > > > v2:
> >> > > >  - Put back removed copyright texts for meson_gxbb_wdt and 
> >> > > > coh901327_wdt
> >> > > >  - Change to BSD-3-Clause for meson_gxbb_wdt
> >> > > > v1: Please have an extra look at meson_gxbb_wdt.c
> >> > > 
> >> > > [...]
> >> > > 
> >> > > > diff --git a/drivers/watchdog/ebc-c384_wdt.c 
> >> > > > b/drivers/watchdog/ebc-c384_wdt.c
> >> > > > index 2170b275ea01..c173b6f5c866 100644
> >> > > > --- a/drivers/watchdog/ebc-c384_wdt.c
> >> > > > +++ b/drivers/watchdog/ebc-c384_wdt.c
> >> > > > @@ -1,15 +1,8 @@
> >> > > > +// SPDX-License-Identifier: GPL-2.0
> >> > > > /*
> >> > > >   * Watchdog timer driver for the WinSystems EBC-C384
> >> > > >   * Copyright (C) 2016 William Breathitt Gray
> >> > > >   *
> >
> >The copyright is untouched?
> >
> >> > > > - * This program is free software; you can redistribute it and/or 
> >> > > > modify
> >> > > > - * it under the terms of the GNU General Public License, version 2, 
> >> > > > as
> >> > > > - * published by the Free Software Foundation.
> >> > > > - *
> >> > > > - * This program is distributed in the hope that it will be useful, 
> >> > > > but
> >> > > > - * WITHOUT ANY WARRANTY; without even the implied warranty of
> >> > > > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> >> > > > - * General Public License for more details.
> >> > > >   */
> >> > > > #include 
> >> > > > #include 
> >> > 
> >> > Thank you for your feedback!
> >> > > 
> >> > > I have no problem with adding a SPDX line to the top of this file, but
> >> > > use "SPDX-License-Identifier: GPL-2.0-only" as I was very intentional
> >> > > with the selection of GPL version 2 only when I published this code.
> >> > 
> >> > SPDX-License-Identifier: GPL-2.0
> >> > Is GPL-2.0 only [1], so it respects your choice of license.
> 
> Ah, this should be fine then. :)
> 

Good!

> >> > 
> >> > > 
> >> > > Furthermore, please do not remove the existing copyright text; although
> >> > 
> >> 
> >> It is not a matter if you CAN keep a copyright. You MUST NOT remove a 
> >> copyright.
> >> As long as you do, the series is
> >> 
> >> Nacked-by: Guenter Roeck 
> >> 
> >> Guenter
> >
> >I'm sorry, I do not see where the copyright is removed unless you count
> >the license text as part of the copyright.
> >
> >Can you please point it out?
> >
> >> 
> >> > The copyright text:
> >> > 
> >> >   Copyright (C) 2016 William Breathitt Gray
> >> > 
> >> > Is still in the file.
> >
> >^^^
> >
> >> > 
> >> > 
> >> > > it's just boilerplate for some, I was careful with the selection of
> >> > > these words, and I worry the SPDX line only -- despite its useful
> >> > > conciseness -- may lead to misunderstandings about my intentioned
> >> > > license for this code.
> >> > 
> >> > I'm not sure I understand your concerns here, the SPDX identifier is
> >> > a shorthand for the GPL 2.0 only license. See [1] - Linux kernel 
> >> > licensing rules.
> >> > 
> >> > One of the biggest benefits with SPDX identifier is that it is hard to 
> >> > verify
> >> > boiler plate licenses due to formatting, types, different formulations 
> >> > and so on.
> >> > 
> >> > If still worrying, I think we could keep the license text as
> >> > well.
> 
> I'm sorry for the confusion, I should have wrote "license text" rather
> than "copyright text" in my previous message. I agree with the benefits

No problem at all.

> of utilizing the SPDX identifier, and I see the addition of the SPDX
> line as useful, but I would prefer the original license text remain as
> well.

Of course, I will keep the the original license intact for v3.
> 
> William Breathitt Gray
> 

Best regards
Marcus Folkesson


signature.asc
Description: PGP signature

Re: [RFC][PATCH bpf v2 1/2] bpf: allow 64-bit offsets for bpf function calls

[Naveen N. Rao]

Michael Ellerman wrote:

"Naveen N. Rao"  writes:

Daniel Borkmann wrote:

On 02/15/2018 05:25 PM, Daniel Borkmann wrote:

On 02/13/2018 05:05 AM, Sandipan Das wrote:

The imm field of a bpf_insn is a signed 32-bit integer. For
JIT-ed bpf-to-bpf function calls, it stores the offset from
__bpf_call_base to the start of the callee function.

For some architectures, such as powerpc64, it was found that
this offset may be as large as 64 bits because of which this
cannot be accomodated in the imm field without truncation.

To resolve this, we additionally make aux->func within each
bpf_prog associated with the functions to point to the list
of all function addresses determined by the verifier.

We keep the value assigned to the off field of the bpf_insn
as a way to index into aux->func and also set aux->func_cnt
so that this can be used for performing basic upper bound
checks for the off field.

Signed-off-by: Sandipan Das 
---
v2: Make aux->func point to the list of functions determined
by the verifier rather than allocating a separate callee
list for each function.


Approach looks good to me; do you know whether s390x JIT would
have similar requirement? I think one limitation that would still
need to be addressed later with such approach would be regarding the
xlated prog dump in bpftool, see 'BPF calls via JIT' in 7105e828c087
("bpf: allow for correlation of maps and helpers in dump"). Any
ideas for this (potentially if we could use off + imm for calls,
we'd get to 48 bits, but that seems still not be enough as you say)?


All good points. I'm not really sure how s390x works, so I can't comment 
on that, but I'm copying Michael Holzheu for his consideration.


With the existing scheme, 48 bits won't be enough, so we rejected that 
approach. I can also see how this will be a problem with bpftool, but I 
haven't looked into it in detail. I wonder if we can annotate the output 
to indicate the function being referred to?




One other random thought, although I'm not sure how feasible this
is for ppc64 JIT to realize ... but idea would be to have something
like the below:

diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 29ca920..daa7258 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -512,6 +512,11 @@ int bpf_get_kallsym(unsigned int symnum, unsigned long 
*value, char *type,
return ret;
 }

+void * __weak bpf_jit_image_alloc(unsigned long size)
+{
+   return module_alloc(size);
+}
+
 struct bpf_binary_header *
 bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
 unsigned int alignment,
@@ -525,7 +530,7 @@ bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
 * random section of illegal instructions.
 */
size = round_up(proglen + sizeof(*hdr) + 128, PAGE_SIZE);
-   hdr = module_alloc(size);
+   hdr = bpf_jit_image_alloc(size);
if (hdr == NULL)
return NULL;

And ppc64 JIT could override bpf_jit_image_alloc() in a similar way
like some archs would override the module_alloc() helper through a
custom implementation, usually via __vmalloc_node_range(), so we
could perhaps fit the range for BPF JITed images in a way that they
could use the 32bit imm in the end? There are not that many progs
loaded typically, so the range could be a bit narrower in such case
anyway. (Not sure if this would work out though, but I thought to
bring it up.)


That'd be a good option to consider. I don't think we want to allocate 
anything from the linear memory range since users could load 
unprivileged BPF programs and consume a lot of memory that way. I doubt 
if we can map vmalloc'ed memory into the 0xc0 address range, but I'm not 
entirely sure.


Michael,
Is the above possible? The question is if we can have BPF programs be 
allocated within 4GB of __bpf_call_base (which is a kernel symbol), so 
that calls to those programs can be encoded in a 32-bit immediate field 
in a BPF instruction.


Hmmm.

It's not technically impossible, but I don't think it's really a good
option.

The 0xc range is a linear mapping of RAM, and the kernel tends to be
near the start of RAM for reasons. That means there generally isn't a
hole in the 0xc range within 4GB for you to map BPF programs.

You could create a hole by making the 0xc mapping non linear, ie.
mapping some RAM near the kernel elsewhere in the 0xc range, to make a
hole that you can then remap BPF programs into. But I think that would
cause a lot of bugs, it's a pretty fundamental assumption that the
linear mapping is 1:1.

As an extension, we may be able to extend it to 
48-bits by combining with another BPF instruction field (offset). In 
either case, the vmalloc'ed address range won't work.


48-bits could possibly work, we don't have systems with that much RAM
*yet*. So you could remap the BPF programs at the end of the 0xc range,
or somewhere we have a gap in RAM.

That would probably still 

[PATCH 4/6] powerpc: numa: Restrict fake NUMA enulation to CONFIG_NUMA systems

[Jonathan Neuschäfer]

Signed-off-by: Jonathan Neuschäfer 
---
 arch/powerpc/mm/numa.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index df03a65b658f..dfe279529463 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -738,7 +738,8 @@ static void __init setup_nonnuma(void)
start_pfn = memblock_region_memory_base_pfn(reg);
end_pfn = memblock_region_memory_end_pfn(reg);
 
-   fake_numa_create_new_node(end_pfn, );
+   if (IS_ENABLED(CONFIG_NUMA))
+   fake_numa_create_new_node(end_pfn, );
memblock_set_node(PFN_PHYS(start_pfn),
  PFN_PHYS(end_pfn - start_pfn),
  , nid);
-- 
2.16.1

[PATCH v9 2/2] cxl: read PHB indications from the device tree

[Philippe Bergheaud]

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 
---
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.

v5: get_phb_indications():
  - make static variables local to function.
  - return static variable values by arguments.

v6: get_phb_indications():
  - acquire a mutex before setting the phb indications.

v7: get_phb_indications():
cxl_get_xsl9_dsnctl():
  - return -ENODEV instead of -1.

v8: get_phb_indications():
  - stay on the safe side: acquire the mutex unconditionally

v9: No change.

This patch depends on the following skiboot patch:
  https://patchwork.ozlabs.org/patch/874415/
---
 drivers/misc/cxl/cxl.h|  2 +-
 drivers/misc/cxl/cxllib.c |  2 +-
 drivers/misc/cxl/pci.c| 48 ++-
 3 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
index 4f015da78f28..a7689944b351 100644
--- a/drivers/misc/cxl/cxl.h
+++ b/drivers/misc/cxl/cxl.h
@@ -1065,7 +1065,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 30ccba436b3b..bea1eb004b49 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, >dsnctl);
+   rc = cxl_get_xsl9_dsnctl(dev, capp_unit_id, >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 758842f65a1b..8d179e64a296 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -407,21 +407,59 @@ 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 DEFINE_MUTEX(indications_mutex);
+
+static int get_phb_indications(struct pci_dev *dev, u64 *capiind, u64 *asnind,
+  u64 *nbwind)
+{
+   static u64 nbw, asn, capi = 0;
+   struct device_node *np;
+   const __be32 *prop;
+
+   mutex_lock(_mutex);
+   if (!capi) {
+   if (!(np = pnv_pci_get_phb_node(dev))) {
+   mutex_unlock(_mutex);
+   return -ENODEV;
+   }
+
+   prop = of_get_property(np, "ibm,phb-indications", NULL);
+   if (!prop) {
+   nbw = 0x0300UL; /* legacy values */
+   asn = 0x0400UL;
+   capi = 0x0200UL;
+   } else {
+   nbw = (u64)be32_to_cpu(prop[2]);
+   asn = (u64)be32_to_cpu(prop[1]);
+   capi = (u64)be32_to_cpu(prop[0]);
+   }
+   of_node_put(np);
+   }
+   *capiind = capi;
+   *asnind = asn;
+   *nbwind = nbw;
+   mutex_unlock(_mutex);
+   return 0;
+}
+
+int cxl_get_xsl9_dsnctl(struct pci_dev *dev, u64 capp_unit_id, u64 *reg)
 {
u64 xsl_dsnctl;
+   u64 capiind, asnind, nbwind;
 
/*
 * CAPI Identifier bits [0:7]
 * bit 61:60 MSI bits --> 0
 * bit 59 TVT selector --> 0
 */
+   if (get_phb_indications(dev, , , ))
+   return -ENODEV;
 
/*
 * 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 */
+   xsl_dsnctl = (capiind << (63-15)); /* Bit 57 */
xsl_dsnctl |= (capp_unit_id << (63-15));
 
/* nMMU_ID Defaults to: b’01001’*/
@@ -435,14 +473,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));
+

[PATCH 6/6] powerpc: wii: Don't rely on reserved memory hack if DISCONTIGMEM is set

[Jonathan Neuschäfer]

Signed-off-by: Jonathan Neuschäfer 
---
 arch/powerpc/platforms/embedded6xx/wii.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/platforms/embedded6xx/wii.c 
b/arch/powerpc/platforms/embedded6xx/wii.c
index 4682327f76a9..589ac87a3ce0 100644
--- a/arch/powerpc/platforms/embedded6xx/wii.c
+++ b/arch/powerpc/platforms/embedded6xx/wii.c
@@ -81,13 +81,16 @@ void __init wii_memory_fixups(void)
BUG_ON(memblock.memory.cnt != 2);
BUG_ON(!page_aligned(p[0].base) || !page_aligned(p[1].base));
 
+   /* determine hole */
+   wii_hole_start = ALIGN(p[0].base + p[0].size, PAGE_SIZE);
+   wii_hole_size = p[1].base - wii_hole_start;
+
+#ifndef CONFIG_DISCONTIGMEM
/* trim unaligned tail */
memblock_remove(ALIGN(p[1].base + p[1].size, PAGE_SIZE),
(phys_addr_t)ULLONG_MAX);
 
-   /* determine hole, add & reserve them */
-   wii_hole_start = ALIGN(p[0].base + p[0].size, PAGE_SIZE);
-   wii_hole_size = p[1].base - wii_hole_start;
+   /* add & reserve hole */
memblock_add(wii_hole_start, wii_hole_size);
memblock_reserve(wii_hole_start, wii_hole_size);
 
@@ -96,6 +99,7 @@ void __init wii_memory_fixups(void)
 
/* allow ioremapping the address space in the hole */
__allow_ioremap_reserved = 1;
+#endif
 }
 
 unsigned long __init wii_mmu_mapin_mem2(unsigned long top)
-- 
2.16.1

[PATCH V6] cxl: Fix timebase synchronization status on P9

[Christophe Lombard]

The PSL Timebase register is updated by the PSL to maintain the
timebase.
On P9, the Timebase value is only provided by the CAPP as received
the last time a timebase request was performed.
The timebase requests are initiated through the adapter configuration or
application registers.
The specific sysfs entry "/sys/class/cxl/cardxx/psl_timebase_synced" is
now dynamically updated according the content of the PSL Timebase
register.

Signed-off-by: Christophe Lombard 
Reviewed-by: Vaibhav Jain 
Acked-by: Andrew Donnellan 

---
This patch applies on top of this patch:
 http://patchwork.ozlabs.org/patch/873663/

Changelog[v6]
 - Rebased to latest upstream.
 - Recompute the status only in native mode.

Changelog[v5]
 - Rebased to latest upstream.
 - Changed the type of 'delta'

Changelog[v4]
 - Rebased to latest upstream.
 - Added log message.

Changelog[v3]
 - Rebased to latest upstream.
 - Dynamic update is now applied to P8.

Changelog[v2]
 - Missing Signed-off-by.
 - Spaces required around the ':'.
---
 drivers/misc/cxl/pci.c   | 17 -
 drivers/misc/cxl/sysfs.c | 12 
 2 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 66eed6a..3247eaf 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -606,9 +606,6 @@ static u64 timebase_read_xsl(struct cxl *adapter)
 
 static void cxl_setup_psl_timebase(struct cxl *adapter, struct pci_dev *dev)
 {
-   u64 psl_tb;
-   int delta;
-   unsigned int retry = 0;
struct device_node *np;
 
adapter->psl_timebase_synced = false;
@@ -636,20 +633,6 @@ static void cxl_setup_psl_timebase(struct cxl *adapter, 
struct pci_dev *dev)
cxl_p1_write(adapter, CXL_PSL_Control, 0x);
cxl_p1_write(adapter, CXL_PSL_Control, CXL_PSL_Control_tb);
 
-   /* Wait until CORE TB and PSL TB difference <= 16usecs */
-   do {
-   msleep(1);
-   if (retry++ > 5) {
-   dev_info(>dev, "PSL timebase can't synchronize\n");
-   return;
-   }
-   psl_tb = adapter->native->sl_ops->timebase_read(adapter);
-   delta = mftb() - psl_tb;
-   if (delta < 0)
-   delta = -delta;
-   } while (tb_to_ns(delta) > 16000);
-
-   adapter->psl_timebase_synced = true;
return;
 }
 
diff --git a/drivers/misc/cxl/sysfs.c b/drivers/misc/cxl/sysfs.c
index a8b6d6a..95285b7 100644
--- a/drivers/misc/cxl/sysfs.c
+++ b/drivers/misc/cxl/sysfs.c
@@ -62,7 +62,19 @@ static ssize_t psl_timebase_synced_show(struct device 
*device,
char *buf)
 {
struct cxl *adapter = to_cxl_adapter(device);
+   u64 psl_tb, delta;
 
+   /* Recompute the status only in native mode */
+   if (cpu_has_feature(CPU_FTR_HVMODE)) {
+   psl_tb = adapter->native->sl_ops->timebase_read(adapter);
+   delta = abs(mftb() - psl_tb);
+
+   /* CORE TB and PSL TB difference <= 16usecs ? */
+   adapter->psl_timebase_synced = (tb_to_ns(delta) < 16000) ? true 
: false;
+   pr_devel("PSL timebase %s - delta: 0x%016llx\n",
+(tb_to_ns(delta) < 16000) ? "synchronized" :
+"not synchronized", tb_to_ns(delta));
+   }
return scnprintf(buf, PAGE_SIZE, "%i\n", adapter->psl_timebase_synced);
 }
 
-- 
2.7.4

Re: [PATCH v2] watchdog: add SPDX identifiers for watchdog subsystem

[William Breathitt Gray]

On Tue, Feb 20, 2018 at 11:45:31AM +0100, Marcus Folkesson wrote:
>- Add SPDX identifier
>- Remove boiler plate license text
>- If MODULE_LICENSE and boiler plate does not match, go for boiler plate
>  license
>
>Signed-off-by: Marcus Folkesson 
>Acked-by: Adam Thomson 
>Acked-by: Charles Keepax 
>Acked-by: Nicolas Ferre 
>Acked-by: Michal Simek 
>---
>
>Notes:
>v2:
>   - Put back removed copyright texts for meson_gxbb_wdt and coh901327_wdt
>   - Change to BSD-3-Clause for meson_gxbb_wdt
>v1: Please have an extra look at meson_gxbb_wdt.c

[...]

>diff --git a/drivers/watchdog/ebc-c384_wdt.c b/drivers/watchdog/ebc-c384_wdt.c
>index 2170b275ea01..c173b6f5c866 100644
>--- a/drivers/watchdog/ebc-c384_wdt.c
>+++ b/drivers/watchdog/ebc-c384_wdt.c
>@@ -1,15 +1,8 @@
>+// SPDX-License-Identifier: GPL-2.0
> /*
>  * Watchdog timer driver for the WinSystems EBC-C384
>  * Copyright (C) 2016 William Breathitt Gray
>  *
>- * This program is free software; you can redistribute it and/or modify
>- * it under the terms of the GNU General Public License, version 2, as
>- * published by the Free Software Foundation.
>- *
>- * This program is distributed in the hope that it will be useful, but
>- * WITHOUT ANY WARRANTY; without even the implied warranty of
>- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>- * General Public License for more details.
>  */
> #include 
> #include 

I have no problem with adding a SPDX line to the top of this file, but
use "SPDX-License-Identifier: GPL-2.0-only" as I was very intentional
with the selection of GPL version 2 only when I published this code.

Furthermore, please do not remove the existing copyright text; although
it's just boilerplate for some, I was careful with the selection of
these words, and I worry the SPDX line only -- despite its useful
conciseness -- may lead to misunderstandings about my intentioned
license for this code.

For the time being, I can't Ack this patch with the changes it makes
currently:

Nacked-by: William Breathitt Gray 

William Breathitt Gray

Re: [PATCH v2] watchdog: add SPDX identifiers for watchdog subsystem

[Marcus Folkesson]

Hello William,

On Tue, Feb 20, 2018 at 07:49:55AM -0500, William Breathitt Gray wrote:
> On Tue, Feb 20, 2018 at 11:45:31AM +0100, Marcus Folkesson wrote:
> >- Add SPDX identifier
> >- Remove boiler plate license text
> >- If MODULE_LICENSE and boiler plate does not match, go for boiler plate
> >  license
> >
> >Signed-off-by: Marcus Folkesson 
> >Acked-by: Adam Thomson 
> >Acked-by: Charles Keepax 
> >Acked-by: Nicolas Ferre 
> >Acked-by: Michal Simek 
> >---
> >
> >Notes:
> >v2:
> > - Put back removed copyright texts for meson_gxbb_wdt and coh901327_wdt
> > - Change to BSD-3-Clause for meson_gxbb_wdt
> >v1: Please have an extra look at meson_gxbb_wdt.c
> 
> [...]
> 
> >diff --git a/drivers/watchdog/ebc-c384_wdt.c 
> >b/drivers/watchdog/ebc-c384_wdt.c
> >index 2170b275ea01..c173b6f5c866 100644
> >--- a/drivers/watchdog/ebc-c384_wdt.c
> >+++ b/drivers/watchdog/ebc-c384_wdt.c
> >@@ -1,15 +1,8 @@
> >+// SPDX-License-Identifier: GPL-2.0
> > /*
> >  * Watchdog timer driver for the WinSystems EBC-C384
> >  * Copyright (C) 2016 William Breathitt Gray
> >  *
> >- * This program is free software; you can redistribute it and/or modify
> >- * it under the terms of the GNU General Public License, version 2, as
> >- * published by the Free Software Foundation.
> >- *
> >- * This program is distributed in the hope that it will be useful, but
> >- * WITHOUT ANY WARRANTY; without even the implied warranty of
> >- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> >- * General Public License for more details.
> >  */
> > #include 
> > #include 

Thank you for your feedback!
> 
> I have no problem with adding a SPDX line to the top of this file, but
> use "SPDX-License-Identifier: GPL-2.0-only" as I was very intentional
> with the selection of GPL version 2 only when I published this code.

SPDX-License-Identifier: GPL-2.0
Is GPL-2.0 only [1], so it respects your choice of license.

> 
> Furthermore, please do not remove the existing copyright text; although

The copyright text:

 Copyright (C) 2016 William Breathitt Gray

Is still in the file.


> it's just boilerplate for some, I was careful with the selection of
> these words, and I worry the SPDX line only -- despite its useful
> conciseness -- may lead to misunderstandings about my intentioned
> license for this code.

I'm not sure I understand your concerns here, the SPDX identifier is
a shorthand for the GPL 2.0 only license. See [1] - Linux kernel licensing 
rules.

One of the biggest benefits with SPDX identifier is that it is hard to verify
boiler plate licenses due to formatting, types, different formulations and so 
on.

If still worrying, I think we could keep the license text as
well.

> 
> For the time being, I can't Ack this patch with the changes it makes
> currently:
> 
> Nacked-by: William Breathitt Gray 
> 
> William Breathitt Gray

Please let me know if I got you wrong at some point.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst

Best regards
Marcus Folkesson


signature.asc
Description: PGP signature

Re: [PATCH v2] watchdog: add SPDX identifiers for watchdog subsystem

[Neil Armstrong]

On 20/02/2018 11:45, Marcus Folkesson wrote:
> - Add SPDX identifier
> - Remove boiler plate license text
> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
>   license
> 
> Signed-off-by: Marcus Folkesson 
> Acked-by: Adam Thomson 
> Acked-by: Charles Keepax 
> Acked-by: Nicolas Ferre 
> Acked-by: Michal Simek 
> ---
> 
> Notes:
> v2:
>   - Put back removed copyright texts for meson_gxbb_wdt and coh901327_wdt
>   - Change to BSD-3-Clause for meson_gxbb_wdt
> v1: Please have an extra look at meson_gxbb_wdt.c
> 
>  drivers/watchdog/acquirewdt.c  |  6 +---
>  drivers/watchdog/advantechwdt.c|  6 +---
>  drivers/watchdog/alim1535_wdt.c|  6 +---
>  drivers/watchdog/alim7101_wdt.c|  1 +
>  drivers/watchdog/ar7_wdt.c | 14 +-
>  drivers/watchdog/asm9260_wdt.c |  2 +-
>  drivers/watchdog/aspeed_wdt.c  |  5 +---
>  drivers/watchdog/at91rm9200_wdt.c  |  5 +---
>  drivers/watchdog/at91sam9_wdt.c|  5 +---
>  drivers/watchdog/at91sam9_wdt.h|  5 +---
>  drivers/watchdog/ath79_wdt.c   |  4 +--
>  drivers/watchdog/atlas7_wdt.c  |  2 +-
>  drivers/watchdog/bcm2835_wdt.c |  5 +---
>  drivers/watchdog/bcm47xx_wdt.c |  5 +---
>  drivers/watchdog/bcm63xx_wdt.c |  5 +---
>  drivers/watchdog/bcm7038_wdt.c | 12 ++--
>  drivers/watchdog/bcm_kona_wdt.c|  9 +-
>  drivers/watchdog/bfin_wdt.c|  2 +-
>  drivers/watchdog/booke_wdt.c   |  5 +---
>  drivers/watchdog/cadence_wdt.c |  5 +---
>  drivers/watchdog/coh901327_wdt.c   |  4 +--
>  drivers/watchdog/cpu5wdt.c | 15 +-
>  drivers/watchdog/cpwd.c|  1 +
>  drivers/watchdog/da9052_wdt.c  |  6 +---
>  drivers/watchdog/da9055_wdt.c  |  6 +---
>  drivers/watchdog/da9062_wdt.c  | 10 +--
>  drivers/watchdog/da9063_wdt.c  |  5 +---
>  drivers/watchdog/davinci_wdt.c |  7 ++---
>  drivers/watchdog/diag288_wdt.c |  1 +
>  drivers/watchdog/digicolor_wdt.c   |  5 +---
>  drivers/watchdog/dw_wdt.c  |  6 +---
>  drivers/watchdog/ebc-c384_wdt.c|  9 +-
>  drivers/watchdog/ep93xx_wdt.c  |  7 ++---
>  drivers/watchdog/eurotechwdt.c |  6 +---
>  drivers/watchdog/f71808e_wdt.c | 16 +--
>  drivers/watchdog/ftwdt010_wdt.c|  6 ++--
>  drivers/watchdog/gef_wdt.c |  6 +---
>  drivers/watchdog/geodewdt.c|  5 +---
>  drivers/watchdog/gpio_wdt.c|  5 +---
>  drivers/watchdog/hpwdt.c   |  7 ++---
>  drivers/watchdog/i6300esb.c|  6 +---
>  drivers/watchdog/iTCO_vendor_support.c |  9 +-
>  drivers/watchdog/iTCO_wdt.c| 10 +--
>  drivers/watchdog/ib700wdt.c|  6 +---
>  drivers/watchdog/ibmasr.c  |  3 +-
>  drivers/watchdog/ie6xx_wdt.c   | 18 ++--
>  drivers/watchdog/imgpdc_wdt.c  |  5 +---
>  drivers/watchdog/imx2_wdt.c|  5 +---
>  drivers/watchdog/indydog.c |  6 +---
>  drivers/watchdog/intel-mid_wdt.c   |  6 ++--
>  drivers/watchdog/intel_scu_watchdog.c  | 18 ++--
>  drivers/watchdog/intel_scu_watchdog.h  | 16 +--
>  drivers/watchdog/iop_wdt.c | 16 ++-
>  drivers/watchdog/it8712f_wdt.c | 10 +--
>  drivers/watchdog/it87_wdt.c| 10 +--
>  drivers/watchdog/ixp4xx_wdt.c  |  6 ++--
>  drivers/watchdog/jz4740_wdt.c  | 10 +--
>  drivers/watchdog/kempld_wdt.c  | 12 ++--
>  drivers/watchdog/ks8695_wdt.c  |  6 ++--
>  drivers/watchdog/lantiq_wdt.c  |  7 ++---
>  drivers/watchdog/loongson1_wdt.c   |  5 +---
>  drivers/watchdog/lpc18xx_wdt.c |  5 +---
>  drivers/watchdog/m54xx_wdt.c   |  6 ++--
>  drivers/watchdog/machzwd.c | 11 +---
>  drivers/watchdog/max63xx_wdt.c |  5 +---
>  drivers/watchdog/max77620_wdt.c|  5 +---
>  drivers/watchdog/mei_wdt.c | 12 ++--
>  drivers/watchdog/mena21_wdt.c  |  4 +--
>  drivers/watchdog/menf21bmc_wdt.c   |  8 ++
>  drivers/watchdog/meson_gxbb_wdt.c  | 50 
> +-
>  drivers/watchdog/meson_wdt.c   |  6 +---
>  drivers/watchdog/mixcomwd.c|  6 +---
>  drivers/watchdog/moxart_wdt.c  |  7 ++---
>  drivers/watchdog/mpc8xxx_wdt.c |  6 +---
>  drivers/watchdog/mt7621_wdt.c  |  5 +---
>  drivers/watchdog/mtk_wdt.c | 11 +---
>  drivers/watchdog/mtx-1_wdt.c   | 11 +---
>  drivers/watchdog/mv64x60_wdt.c |  6 ++--
>  drivers/watchdog/ni903x_wdt.c  | 11 +---
>  drivers/watchdog/nic7018_wdt.c | 11 +---
>  

Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests

[Horia Geantă]

On 2/20/2018 12:34 PM, Herbert Xu wrote:
> On Mon, Feb 19, 2018 at 01:16:30PM +, Horia Geantă wrote:
>>
>>> And what about ALGIF path from user space ?
>>> What if the user never calls the last sendmsg() which will call 
>>> hash_finup() ?
>>>
>> User is expected to follow the rules of the crypto API.
>> Of course, kernel won't (or at least shouldn't) crash in case of misuse.
>> However, in these cases some resources might not be freed - it's unavoidable.
> 
> the crypto API does not require the presence of a finalisation.
> It is entirely optional.  So leaving resources pinned down until
> final/finup occurs is unacceptable, both from user-space and the
> kernel.
> 
If final/finup is optional, how is the final hash supposed to be retrieved?

According to documentation, these are the accepted flows (with the option to
export/import a partial hash b/w update and final/finup):

.init() -> .update() -> .final()
^| |
'' '---> HASH

.init() -> .update() -> .finup()
^| |
'' '---> HASH

   .digest()
   |
   '---> HASH

Note that digest() is not an issue in the case we are discussing, since resource
allocation happens only in init().

Thanks,
Horia

Re: [PATCH v2] watchdog: add SPDX identifiers for watchdog subsystem

[Thierry Reding]

On Tue, Feb 20, 2018 at 11:45:31AM +0100, Marcus Folkesson wrote:
[...]
>  drivers/watchdog/tegra_wdt.c   | 10 +--
[...]

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH v2] watchdog: add SPDX identifiers for watchdog subsystem

[Måns Rullgård]

Marcus Folkesson  writes:

> - Add SPDX identifier
> - Remove boiler plate license text
> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
>   license
>
> Signed-off-by: Marcus Folkesson 
> Acked-by: Adam Thomson 
> Acked-by: Charles Keepax 
> Acked-by: Nicolas Ferre 
> Acked-by: Michal Simek 
> ---
>
> Notes:
> v2:
>   - Put back removed copyright texts for meson_gxbb_wdt and coh901327_wdt
>   - Change to BSD-3-Clause for meson_gxbb_wdt
> v1: Please have an extra look at meson_gxbb_wdt.c

[...]

>  drivers/watchdog/tangox_wdt.c  |  6 +---

For tangox_wdt:
Acked-by: Mans Rullgard 

-- 
Måns Rullgård

Re: [PATCH] watchdog: add SPDX identifiers for watchdog subsystem

[Charles Keepax]

On Tue, Feb 20, 2018 at 10:31:08AM +0100, Marcus Folkesson wrote:
> - Add SPDX identifier
> - Remove boiler plate license text
> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
>   license
> 
> Signed-off-by: Marcus Folkesson 
> ---
>  drivers/watchdog/wm831x_wdt.c  |  5 +---
>  drivers/watchdog/wm8350_wdt.c  |  5 +---

For the Wolfson parts:

Acked-by: Charles Keepax 

Thanks,
Charles

[PATCH v2] watchdog: add SPDX identifiers for watchdog subsystem

[Marcus Folkesson]

- Add SPDX identifier
- Remove boiler plate license text
- If MODULE_LICENSE and boiler plate does not match, go for boiler plate
  license

Signed-off-by: Marcus Folkesson 
Acked-by: Adam Thomson 
Acked-by: Charles Keepax 
Acked-by: Nicolas Ferre 
Acked-by: Michal Simek 
---

Notes:
v2:
- Put back removed copyright texts for meson_gxbb_wdt and coh901327_wdt
- Change to BSD-3-Clause for meson_gxbb_wdt
v1: Please have an extra look at meson_gxbb_wdt.c

 drivers/watchdog/acquirewdt.c  |  6 +---
 drivers/watchdog/advantechwdt.c|  6 +---
 drivers/watchdog/alim1535_wdt.c|  6 +---
 drivers/watchdog/alim7101_wdt.c|  1 +
 drivers/watchdog/ar7_wdt.c | 14 +-
 drivers/watchdog/asm9260_wdt.c |  2 +-
 drivers/watchdog/aspeed_wdt.c  |  5 +---
 drivers/watchdog/at91rm9200_wdt.c  |  5 +---
 drivers/watchdog/at91sam9_wdt.c|  5 +---
 drivers/watchdog/at91sam9_wdt.h|  5 +---
 drivers/watchdog/ath79_wdt.c   |  4 +--
 drivers/watchdog/atlas7_wdt.c  |  2 +-
 drivers/watchdog/bcm2835_wdt.c |  5 +---
 drivers/watchdog/bcm47xx_wdt.c |  5 +---
 drivers/watchdog/bcm63xx_wdt.c |  5 +---
 drivers/watchdog/bcm7038_wdt.c | 12 ++--
 drivers/watchdog/bcm_kona_wdt.c|  9 +-
 drivers/watchdog/bfin_wdt.c|  2 +-
 drivers/watchdog/booke_wdt.c   |  5 +---
 drivers/watchdog/cadence_wdt.c |  5 +---
 drivers/watchdog/coh901327_wdt.c   |  4 +--
 drivers/watchdog/cpu5wdt.c | 15 +-
 drivers/watchdog/cpwd.c|  1 +
 drivers/watchdog/da9052_wdt.c  |  6 +---
 drivers/watchdog/da9055_wdt.c  |  6 +---
 drivers/watchdog/da9062_wdt.c  | 10 +--
 drivers/watchdog/da9063_wdt.c  |  5 +---
 drivers/watchdog/davinci_wdt.c |  7 ++---
 drivers/watchdog/diag288_wdt.c |  1 +
 drivers/watchdog/digicolor_wdt.c   |  5 +---
 drivers/watchdog/dw_wdt.c  |  6 +---
 drivers/watchdog/ebc-c384_wdt.c|  9 +-
 drivers/watchdog/ep93xx_wdt.c  |  7 ++---
 drivers/watchdog/eurotechwdt.c |  6 +---
 drivers/watchdog/f71808e_wdt.c | 16 +--
 drivers/watchdog/ftwdt010_wdt.c|  6 ++--
 drivers/watchdog/gef_wdt.c |  6 +---
 drivers/watchdog/geodewdt.c|  5 +---
 drivers/watchdog/gpio_wdt.c|  5 +---
 drivers/watchdog/hpwdt.c   |  7 ++---
 drivers/watchdog/i6300esb.c|  6 +---
 drivers/watchdog/iTCO_vendor_support.c |  9 +-
 drivers/watchdog/iTCO_wdt.c| 10 +--
 drivers/watchdog/ib700wdt.c|  6 +---
 drivers/watchdog/ibmasr.c  |  3 +-
 drivers/watchdog/ie6xx_wdt.c   | 18 ++--
 drivers/watchdog/imgpdc_wdt.c  |  5 +---
 drivers/watchdog/imx2_wdt.c|  5 +---
 drivers/watchdog/indydog.c |  6 +---
 drivers/watchdog/intel-mid_wdt.c   |  6 ++--
 drivers/watchdog/intel_scu_watchdog.c  | 18 ++--
 drivers/watchdog/intel_scu_watchdog.h  | 16 +--
 drivers/watchdog/iop_wdt.c | 16 ++-
 drivers/watchdog/it8712f_wdt.c | 10 +--
 drivers/watchdog/it87_wdt.c| 10 +--
 drivers/watchdog/ixp4xx_wdt.c  |  6 ++--
 drivers/watchdog/jz4740_wdt.c  | 10 +--
 drivers/watchdog/kempld_wdt.c  | 12 ++--
 drivers/watchdog/ks8695_wdt.c  |  6 ++--
 drivers/watchdog/lantiq_wdt.c  |  7 ++---
 drivers/watchdog/loongson1_wdt.c   |  5 +---
 drivers/watchdog/lpc18xx_wdt.c |  5 +---
 drivers/watchdog/m54xx_wdt.c   |  6 ++--
 drivers/watchdog/machzwd.c | 11 +---
 drivers/watchdog/max63xx_wdt.c |  5 +---
 drivers/watchdog/max77620_wdt.c|  5 +---
 drivers/watchdog/mei_wdt.c | 12 ++--
 drivers/watchdog/mena21_wdt.c  |  4 +--
 drivers/watchdog/menf21bmc_wdt.c   |  8 ++
 drivers/watchdog/meson_gxbb_wdt.c  | 50 +-
 drivers/watchdog/meson_wdt.c   |  6 +---
 drivers/watchdog/mixcomwd.c|  6 +---
 drivers/watchdog/moxart_wdt.c  |  7 ++---
 drivers/watchdog/mpc8xxx_wdt.c |  6 +---
 drivers/watchdog/mt7621_wdt.c  |  5 +---
 drivers/watchdog/mtk_wdt.c | 11 +---
 drivers/watchdog/mtx-1_wdt.c   | 11 +---
 drivers/watchdog/mv64x60_wdt.c |  6 ++--
 drivers/watchdog/ni903x_wdt.c  | 11 +---
 drivers/watchdog/nic7018_wdt.c | 11 +---
 drivers/watchdog/nuc900_wdt.c  |  7 ++---
 drivers/watchdog/nv_tco.c  |  6 +---
 drivers/watchdog/nv_tco.h  | 10 +--
 drivers/watchdog/octeon-wdt-main.c | 11 +---
 drivers/watchdog/octeon-wdt-nmi.S  | 

Re: [PATCH] powerpc/eeh: Add conditional check on notify_resume

[Michael Neuling]

On Thu, 2018-02-15 at 12:49 -0600, Bryant G. Ly wrote:
> From: "Juan J. Alvarez" 
> 
> EEH structure is not populated with function
> notify resume when running on systems that do not support
> it, i.e: BMC. Hence adding a conditional check for NULL for
> systems that don't add function notify_resume.
> 
> Signed-off-by: Juan J. Alvarez 
> Reviewed-by: Bryant G. Ly 
> Tested-by: Carol L. Soto 

Acked-by: Michael Neuling 

> ---
>  arch/powerpc/kernel/eeh_driver.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/eeh_driver.c
> b/arch/powerpc/kernel/eeh_driver.c
> index beea218..0c0b66f 100644
> --- a/arch/powerpc/kernel/eeh_driver.c
> +++ b/arch/powerpc/kernel/eeh_driver.c
> @@ -384,7 +384,8 @@ static void *eeh_report_resume(void *data, void *userdata)
>   eeh_pcid_put(dev);
>   pci_uevent_ers(dev, PCI_ERS_RESULT_RECOVERED);
>  #ifdef CONFIG_PCI_IOV
> - eeh_ops->notify_resume(eeh_dev_to_pdn(edev));
> + if (eeh_ops->notify_resume && eeh_dev_to_pdn(edev))
> + eeh_ops->notify_resume(eeh_dev_to_pdn(edev));
>  #endif
>   return NULL;
>  }

Re: [PATCH] watchdog: add SPDX identifiers for watchdog subsystem

[Neil Armstrong]

Hi Marcus,

On 20/02/2018 10:59, Marcus Folkesson wrote:
> On Tue, Feb 20, 2018 at 10:47:03AM +0100, Neil Armstrong wrote:
>> Hi Marcus,
>>
>> On 20/02/2018 10:31, Marcus Folkesson wrote:
>>> - Add SPDX identifier
>>> - Remove boiler plate license text
>>> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
>>>   license
>>>
>>> Signed-off-by: Marcus Folkesson 
>>> ---
>>>
>>> Notes:
>>> v1: Please have an extra look at meson_gxbb_wdt.c
>>>
>>>  drivers/watchdog/acquirewdt.c  |  6 +---
>>>  drivers/watchdog/advantechwdt.c|  6 +---
>>>  drivers/watchdog/alim1535_wdt.c|  6 +---
>>>  drivers/watchdog/alim7101_wdt.c|  1 +
>>>  drivers/watchdog/ar7_wdt.c | 14 +
>>>  drivers/watchdog/asm9260_wdt.c |  2 +-
>>>  drivers/watchdog/aspeed_wdt.c  |  5 +---
>>>  drivers/watchdog/at91rm9200_wdt.c  |  5 +---
>>>  drivers/watchdog/at91sam9_wdt.c|  5 +---
>>>  drivers/watchdog/at91sam9_wdt.h|  5 +---
>>>  drivers/watchdog/ath79_wdt.c   |  4 +--
>>>  drivers/watchdog/atlas7_wdt.c  |  2 +-
>>>  drivers/watchdog/bcm2835_wdt.c |  5 +---
>>>  drivers/watchdog/bcm47xx_wdt.c |  5 +---
>>>  drivers/watchdog/bcm63xx_wdt.c |  5 +---
>>>  drivers/watchdog/bcm7038_wdt.c | 12 ++--
>>>  drivers/watchdog/bcm_kona_wdt.c|  9 +-
>>>  drivers/watchdog/bfin_wdt.c|  2 +-
>>>  drivers/watchdog/booke_wdt.c   |  5 +---
>>>  drivers/watchdog/cadence_wdt.c |  5 +---
>>>  drivers/watchdog/coh901327_wdt.c   |  7 ++---
>>>  drivers/watchdog/cpu5wdt.c | 15 +-
>>>  drivers/watchdog/cpwd.c|  1 +
>>>  drivers/watchdog/da9052_wdt.c  |  6 +---
>>>  drivers/watchdog/da9055_wdt.c  |  6 +---
>>>  drivers/watchdog/da9062_wdt.c  | 10 +--
>>>  drivers/watchdog/da9063_wdt.c  |  5 +---
>>>  drivers/watchdog/davinci_wdt.c |  7 ++---
>>>  drivers/watchdog/diag288_wdt.c |  1 +
>>>  drivers/watchdog/digicolor_wdt.c   |  5 +---
>>>  drivers/watchdog/dw_wdt.c  |  6 +---
>>>  drivers/watchdog/ebc-c384_wdt.c|  9 +-
>>>  drivers/watchdog/ep93xx_wdt.c  |  7 ++---
>>>  drivers/watchdog/eurotechwdt.c |  6 +---
>>>  drivers/watchdog/f71808e_wdt.c | 16 +-
>>>  drivers/watchdog/ftwdt010_wdt.c|  6 ++--
>>>  drivers/watchdog/gef_wdt.c |  6 +---
>>>  drivers/watchdog/geodewdt.c|  5 +---
>>>  drivers/watchdog/gpio_wdt.c|  5 +---
>>>  drivers/watchdog/hpwdt.c   |  7 ++---
>>>  drivers/watchdog/i6300esb.c|  6 +---
>>>  drivers/watchdog/iTCO_vendor_support.c |  9 +-
>>>  drivers/watchdog/iTCO_wdt.c| 10 +--
>>>  drivers/watchdog/ib700wdt.c|  6 +---
>>>  drivers/watchdog/ibmasr.c  |  3 +-
>>>  drivers/watchdog/ie6xx_wdt.c   | 18 ++-
>>>  drivers/watchdog/imgpdc_wdt.c  |  5 +---
>>>  drivers/watchdog/imx2_wdt.c|  5 +---
>>>  drivers/watchdog/indydog.c |  6 +---
>>>  drivers/watchdog/intel-mid_wdt.c   |  6 ++--
>>>  drivers/watchdog/intel_scu_watchdog.c  | 18 ++-
>>>  drivers/watchdog/intel_scu_watchdog.h  | 16 +-
>>>  drivers/watchdog/iop_wdt.c | 16 ++
>>>  drivers/watchdog/it8712f_wdt.c | 10 +--
>>>  drivers/watchdog/it87_wdt.c| 10 +--
>>>  drivers/watchdog/ixp4xx_wdt.c  |  6 ++--
>>>  drivers/watchdog/jz4740_wdt.c  | 10 +--
>>>  drivers/watchdog/kempld_wdt.c  | 12 ++--
>>>  drivers/watchdog/ks8695_wdt.c  |  6 ++--
>>>  drivers/watchdog/lantiq_wdt.c  |  7 ++---
>>>  drivers/watchdog/loongson1_wdt.c   |  5 +---
>>>  drivers/watchdog/lpc18xx_wdt.c |  5 +---
>>>  drivers/watchdog/m54xx_wdt.c   |  6 ++--
>>>  drivers/watchdog/machzwd.c | 11 +--
>>>  drivers/watchdog/max63xx_wdt.c |  5 +---
>>>  drivers/watchdog/max77620_wdt.c|  5 +---
>>>  drivers/watchdog/mei_wdt.c | 12 ++--
>>>  drivers/watchdog/mena21_wdt.c  |  4 +--
>>>  drivers/watchdog/menf21bmc_wdt.c   |  8 ++---
>>>  drivers/watchdog/meson_gxbb_wdt.c  | 55 
>>> +-
>>>  drivers/watchdog/meson_wdt.c   |  6 +---
>>>  drivers/watchdog/mixcomwd.c|  6 +---
>>>  drivers/watchdog/moxart_wdt.c  |  7 ++---
>>>  drivers/watchdog/mpc8xxx_wdt.c |  6 +---
>>>  drivers/watchdog/mt7621_wdt.c  |  5 +---
>>>  drivers/watchdog/mtk_wdt.c | 11 +--
>>>  drivers/watchdog/mtx-1_wdt.c   | 11 +--
>>>  drivers/watchdog/mv64x60_wdt.c |  6 ++--
>>>  drivers/watchdog/ni903x_wdt.c  | 11 +--
>>>  drivers/watchdog/nic7018_wdt.c | 11 +--
>>>  drivers/watchdog/nuc900_wdt.c  |  7 ++---
>>>  

Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests

[Herbert Xu]

On Mon, Feb 19, 2018 at 01:16:30PM +, Horia Geantă wrote:
>
> > And what about ALGIF path from user space ?
> > What if the user never calls the last sendmsg() which will call 
> > hash_finup() ?
> > 
> User is expected to follow the rules of the crypto API.
> Of course, kernel won't (or at least shouldn't) crash in case of misuse.
> However, in these cases some resources might not be freed - it's unavoidable.

the crypto API does not require the presence of a finalisation.
It is entirely optional.  So leaving resources pinned down until
final/finup occurs is unacceptable, both from user-space and the
kernel.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

RE: [PATCH] watchdog: add SPDX identifiers for watchdog subsystem

[Adam Thomson]

On 20 February 2018 09:31, Marcus Folkesson wrote:

> - Add SPDX identifier
> - Remove boiler plate license text
> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
>   license
> 
> Signed-off-by: Marcus Folkesson 
> ---

[...]

> diff --git a/drivers/watchdog/da9052_wdt.c b/drivers/watchdog/da9052_wdt.c
> index d6d5006efa71..e263bad99574 100644
> --- a/drivers/watchdog/da9052_wdt.c
> +++ b/drivers/watchdog/da9052_wdt.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0+
>  /*
>   * System monitoring driver for DA9052 PMICs.
>   *
> @@ -5,11 +6,6 @@
>   *
>   * Author: Anthony Olech 
>   *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
>   */
> 
>  #include 
> diff --git a/drivers/watchdog/da9055_wdt.c b/drivers/watchdog/da9055_wdt.c
> index 50bdd1022186..26a5b2984094 100644
> --- a/drivers/watchdog/da9055_wdt.c
> +++ b/drivers/watchdog/da9055_wdt.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0+
>  /*
>   * System monitoring driver for DA9055 PMICs.
>   *
> @@ -5,11 +6,6 @@
>   *
>   * Author: David Dajun Chen 
>   *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
>   */
> 
>  #include 
> diff --git a/drivers/watchdog/da9062_wdt.c b/drivers/watchdog/da9062_wdt.c
> index 814dff6045a4..a001782bbfdb 100644
> --- a/drivers/watchdog/da9062_wdt.c
> +++ b/drivers/watchdog/da9062_wdt.c
> @@ -1,16 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Watchdog device driver for DA9062 and DA9061 PMICs
>   * Copyright (C) 2015  Dialog Semiconductor Ltd.
>   *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License
> - * as published by the Free Software Foundation; either version 2
> - * of the License, or (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
>   */
> 
>  #include 
> diff --git a/drivers/watchdog/da9063_wdt.c b/drivers/watchdog/da9063_wdt.c
> index 2a20fc163ed0..b17ac1bb1f28 100644
> --- a/drivers/watchdog/da9063_wdt.c
> +++ b/drivers/watchdog/da9063_wdt.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Watchdog driver for DA9063 PMICs.
>   *
> @@ -5,10 +6,6 @@
>   *
>   * Author: Mariusz Wojtasik 
>   *
> - * This program is free software; you can redistribute  it and/or modify it
> - * under  the terms of  the GNU General  Public License as published by the
> - * Free Software Foundation;  either version 2 of the  License, or (at your
> - * option) any later version.
>   */

For Dialog drivers,

Acked-by: Adam Thomson 

Re: [PATCH] watchdog: add SPDX identifiers for watchdog subsystem

[Michal Simek]

On 20.2.2018 10:31, Marcus Folkesson wrote:
> - Add SPDX identifier
> - Remove boiler plate license text
> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
>   license
> 
> Signed-off-by: Marcus Folkesson 
> ---
> 
> Notes:
> v1: Please have an extra look at meson_gxbb_wdt.c
> 
>  drivers/watchdog/cadence_wdt.c |  5 +---
>  drivers/watchdog/of_xilinx_wdt.c   |  8 ++---


Acked-by: Michal Simek  (For cadence_wdt and
of_xilinx_wdt)

Thanks,
Michal

Re: [PATCH] watchdog: add SPDX identifiers for watchdog subsystem

[Nicolas Ferre]

On 20/02/2018 at 10:31, Marcus Folkesson wrote:

- Add SPDX identifier
- Remove boiler plate license text
- If MODULE_LICENSE and boiler plate does not match, go for boiler plate
   license

Signed-off-by: Marcus Folkesson 
---

Notes:
 v1: Please have an extra look at meson_gxbb_wdt.c

  drivers/watchdog/acquirewdt.c  |  6 +---


[..]


  drivers/watchdog/at91rm9200_wdt.c  |  5 +---
  drivers/watchdog/at91sam9_wdt.c|  5 +---
  drivers/watchdog/at91sam9_wdt.h|  5 +---


For these 3

[..]


  drivers/watchdog/sama5d4_wdt.c |  3 +-


And this one:
Acked-by: Nicolas Ferre 

Thanks, best regards,
--
Nicolas Ferre

Re: [PATCH] watchdog: add SPDX identifiers for watchdog subsystem

[Marcus Folkesson]

On Tue, Feb 20, 2018 at 10:47:03AM +0100, Neil Armstrong wrote:
> Hi Marcus,
> 
> On 20/02/2018 10:31, Marcus Folkesson wrote:
> > - Add SPDX identifier
> > - Remove boiler plate license text
> > - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
> >   license
> > 
> > Signed-off-by: Marcus Folkesson 
> > ---
> > 
> > Notes:
> > v1: Please have an extra look at meson_gxbb_wdt.c
> > 
> >  drivers/watchdog/acquirewdt.c  |  6 +---
> >  drivers/watchdog/advantechwdt.c|  6 +---
> >  drivers/watchdog/alim1535_wdt.c|  6 +---
> >  drivers/watchdog/alim7101_wdt.c|  1 +
> >  drivers/watchdog/ar7_wdt.c | 14 +
> >  drivers/watchdog/asm9260_wdt.c |  2 +-
> >  drivers/watchdog/aspeed_wdt.c  |  5 +---
> >  drivers/watchdog/at91rm9200_wdt.c  |  5 +---
> >  drivers/watchdog/at91sam9_wdt.c|  5 +---
> >  drivers/watchdog/at91sam9_wdt.h|  5 +---
> >  drivers/watchdog/ath79_wdt.c   |  4 +--
> >  drivers/watchdog/atlas7_wdt.c  |  2 +-
> >  drivers/watchdog/bcm2835_wdt.c |  5 +---
> >  drivers/watchdog/bcm47xx_wdt.c |  5 +---
> >  drivers/watchdog/bcm63xx_wdt.c |  5 +---
> >  drivers/watchdog/bcm7038_wdt.c | 12 ++--
> >  drivers/watchdog/bcm_kona_wdt.c|  9 +-
> >  drivers/watchdog/bfin_wdt.c|  2 +-
> >  drivers/watchdog/booke_wdt.c   |  5 +---
> >  drivers/watchdog/cadence_wdt.c |  5 +---
> >  drivers/watchdog/coh901327_wdt.c   |  7 ++---
> >  drivers/watchdog/cpu5wdt.c | 15 +-
> >  drivers/watchdog/cpwd.c|  1 +
> >  drivers/watchdog/da9052_wdt.c  |  6 +---
> >  drivers/watchdog/da9055_wdt.c  |  6 +---
> >  drivers/watchdog/da9062_wdt.c  | 10 +--
> >  drivers/watchdog/da9063_wdt.c  |  5 +---
> >  drivers/watchdog/davinci_wdt.c |  7 ++---
> >  drivers/watchdog/diag288_wdt.c |  1 +
> >  drivers/watchdog/digicolor_wdt.c   |  5 +---
> >  drivers/watchdog/dw_wdt.c  |  6 +---
> >  drivers/watchdog/ebc-c384_wdt.c|  9 +-
> >  drivers/watchdog/ep93xx_wdt.c  |  7 ++---
> >  drivers/watchdog/eurotechwdt.c |  6 +---
> >  drivers/watchdog/f71808e_wdt.c | 16 +-
> >  drivers/watchdog/ftwdt010_wdt.c|  6 ++--
> >  drivers/watchdog/gef_wdt.c |  6 +---
> >  drivers/watchdog/geodewdt.c|  5 +---
> >  drivers/watchdog/gpio_wdt.c|  5 +---
> >  drivers/watchdog/hpwdt.c   |  7 ++---
> >  drivers/watchdog/i6300esb.c|  6 +---
> >  drivers/watchdog/iTCO_vendor_support.c |  9 +-
> >  drivers/watchdog/iTCO_wdt.c| 10 +--
> >  drivers/watchdog/ib700wdt.c|  6 +---
> >  drivers/watchdog/ibmasr.c  |  3 +-
> >  drivers/watchdog/ie6xx_wdt.c   | 18 ++-
> >  drivers/watchdog/imgpdc_wdt.c  |  5 +---
> >  drivers/watchdog/imx2_wdt.c|  5 +---
> >  drivers/watchdog/indydog.c |  6 +---
> >  drivers/watchdog/intel-mid_wdt.c   |  6 ++--
> >  drivers/watchdog/intel_scu_watchdog.c  | 18 ++-
> >  drivers/watchdog/intel_scu_watchdog.h  | 16 +-
> >  drivers/watchdog/iop_wdt.c | 16 ++
> >  drivers/watchdog/it8712f_wdt.c | 10 +--
> >  drivers/watchdog/it87_wdt.c| 10 +--
> >  drivers/watchdog/ixp4xx_wdt.c  |  6 ++--
> >  drivers/watchdog/jz4740_wdt.c  | 10 +--
> >  drivers/watchdog/kempld_wdt.c  | 12 ++--
> >  drivers/watchdog/ks8695_wdt.c  |  6 ++--
> >  drivers/watchdog/lantiq_wdt.c  |  7 ++---
> >  drivers/watchdog/loongson1_wdt.c   |  5 +---
> >  drivers/watchdog/lpc18xx_wdt.c |  5 +---
> >  drivers/watchdog/m54xx_wdt.c   |  6 ++--
> >  drivers/watchdog/machzwd.c | 11 +--
> >  drivers/watchdog/max63xx_wdt.c |  5 +---
> >  drivers/watchdog/max77620_wdt.c|  5 +---
> >  drivers/watchdog/mei_wdt.c | 12 ++--
> >  drivers/watchdog/mena21_wdt.c  |  4 +--
> >  drivers/watchdog/menf21bmc_wdt.c   |  8 ++---
> >  drivers/watchdog/meson_gxbb_wdt.c  | 55 
> > +-
> >  drivers/watchdog/meson_wdt.c   |  6 +---
> >  drivers/watchdog/mixcomwd.c|  6 +---
> >  drivers/watchdog/moxart_wdt.c  |  7 ++---
> >  drivers/watchdog/mpc8xxx_wdt.c |  6 +---
> >  drivers/watchdog/mt7621_wdt.c  |  5 +---
> >  drivers/watchdog/mtk_wdt.c | 11 +--
> >  drivers/watchdog/mtx-1_wdt.c   | 11 +--
> >  drivers/watchdog/mv64x60_wdt.c |  6 ++--
> >  drivers/watchdog/ni903x_wdt.c  | 11 +--
> >  drivers/watchdog/nic7018_wdt.c | 11 +--
> >  drivers/watchdog/nuc900_wdt.c  |  7 ++---
> >  drivers/watchdog/nv_tco.c  |  6 +---
> >  

Re: [PATCH] watchdog: add SPDX identifiers for watchdog subsystem

[Neil Armstrong]

Hi Marcus,

On 20/02/2018 10:31, Marcus Folkesson wrote:
> - Add SPDX identifier
> - Remove boiler plate license text
> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
>   license
> 
> Signed-off-by: Marcus Folkesson 
> ---
> 
> Notes:
> v1: Please have an extra look at meson_gxbb_wdt.c
> 
>  drivers/watchdog/acquirewdt.c  |  6 +---
>  drivers/watchdog/advantechwdt.c|  6 +---
>  drivers/watchdog/alim1535_wdt.c|  6 +---
>  drivers/watchdog/alim7101_wdt.c|  1 +
>  drivers/watchdog/ar7_wdt.c | 14 +
>  drivers/watchdog/asm9260_wdt.c |  2 +-
>  drivers/watchdog/aspeed_wdt.c  |  5 +---
>  drivers/watchdog/at91rm9200_wdt.c  |  5 +---
>  drivers/watchdog/at91sam9_wdt.c|  5 +---
>  drivers/watchdog/at91sam9_wdt.h|  5 +---
>  drivers/watchdog/ath79_wdt.c   |  4 +--
>  drivers/watchdog/atlas7_wdt.c  |  2 +-
>  drivers/watchdog/bcm2835_wdt.c |  5 +---
>  drivers/watchdog/bcm47xx_wdt.c |  5 +---
>  drivers/watchdog/bcm63xx_wdt.c |  5 +---
>  drivers/watchdog/bcm7038_wdt.c | 12 ++--
>  drivers/watchdog/bcm_kona_wdt.c|  9 +-
>  drivers/watchdog/bfin_wdt.c|  2 +-
>  drivers/watchdog/booke_wdt.c   |  5 +---
>  drivers/watchdog/cadence_wdt.c |  5 +---
>  drivers/watchdog/coh901327_wdt.c   |  7 ++---
>  drivers/watchdog/cpu5wdt.c | 15 +-
>  drivers/watchdog/cpwd.c|  1 +
>  drivers/watchdog/da9052_wdt.c  |  6 +---
>  drivers/watchdog/da9055_wdt.c  |  6 +---
>  drivers/watchdog/da9062_wdt.c  | 10 +--
>  drivers/watchdog/da9063_wdt.c  |  5 +---
>  drivers/watchdog/davinci_wdt.c |  7 ++---
>  drivers/watchdog/diag288_wdt.c |  1 +
>  drivers/watchdog/digicolor_wdt.c   |  5 +---
>  drivers/watchdog/dw_wdt.c  |  6 +---
>  drivers/watchdog/ebc-c384_wdt.c|  9 +-
>  drivers/watchdog/ep93xx_wdt.c  |  7 ++---
>  drivers/watchdog/eurotechwdt.c |  6 +---
>  drivers/watchdog/f71808e_wdt.c | 16 +-
>  drivers/watchdog/ftwdt010_wdt.c|  6 ++--
>  drivers/watchdog/gef_wdt.c |  6 +---
>  drivers/watchdog/geodewdt.c|  5 +---
>  drivers/watchdog/gpio_wdt.c|  5 +---
>  drivers/watchdog/hpwdt.c   |  7 ++---
>  drivers/watchdog/i6300esb.c|  6 +---
>  drivers/watchdog/iTCO_vendor_support.c |  9 +-
>  drivers/watchdog/iTCO_wdt.c| 10 +--
>  drivers/watchdog/ib700wdt.c|  6 +---
>  drivers/watchdog/ibmasr.c  |  3 +-
>  drivers/watchdog/ie6xx_wdt.c   | 18 ++-
>  drivers/watchdog/imgpdc_wdt.c  |  5 +---
>  drivers/watchdog/imx2_wdt.c|  5 +---
>  drivers/watchdog/indydog.c |  6 +---
>  drivers/watchdog/intel-mid_wdt.c   |  6 ++--
>  drivers/watchdog/intel_scu_watchdog.c  | 18 ++-
>  drivers/watchdog/intel_scu_watchdog.h  | 16 +-
>  drivers/watchdog/iop_wdt.c | 16 ++
>  drivers/watchdog/it8712f_wdt.c | 10 +--
>  drivers/watchdog/it87_wdt.c| 10 +--
>  drivers/watchdog/ixp4xx_wdt.c  |  6 ++--
>  drivers/watchdog/jz4740_wdt.c  | 10 +--
>  drivers/watchdog/kempld_wdt.c  | 12 ++--
>  drivers/watchdog/ks8695_wdt.c  |  6 ++--
>  drivers/watchdog/lantiq_wdt.c  |  7 ++---
>  drivers/watchdog/loongson1_wdt.c   |  5 +---
>  drivers/watchdog/lpc18xx_wdt.c |  5 +---
>  drivers/watchdog/m54xx_wdt.c   |  6 ++--
>  drivers/watchdog/machzwd.c | 11 +--
>  drivers/watchdog/max63xx_wdt.c |  5 +---
>  drivers/watchdog/max77620_wdt.c|  5 +---
>  drivers/watchdog/mei_wdt.c | 12 ++--
>  drivers/watchdog/mena21_wdt.c  |  4 +--
>  drivers/watchdog/menf21bmc_wdt.c   |  8 ++---
>  drivers/watchdog/meson_gxbb_wdt.c  | 55 
> +-
>  drivers/watchdog/meson_wdt.c   |  6 +---
>  drivers/watchdog/mixcomwd.c|  6 +---
>  drivers/watchdog/moxart_wdt.c  |  7 ++---
>  drivers/watchdog/mpc8xxx_wdt.c |  6 +---
>  drivers/watchdog/mt7621_wdt.c  |  5 +---
>  drivers/watchdog/mtk_wdt.c | 11 +--
>  drivers/watchdog/mtx-1_wdt.c   | 11 +--
>  drivers/watchdog/mv64x60_wdt.c |  6 ++--
>  drivers/watchdog/ni903x_wdt.c  | 11 +--
>  drivers/watchdog/nic7018_wdt.c | 11 +--
>  drivers/watchdog/nuc900_wdt.c  |  7 ++---
>  drivers/watchdog/nv_tco.c  |  6 +---
>  drivers/watchdog/nv_tco.h  | 10 +--
>  drivers/watchdog/octeon-wdt-main.c | 11 +--
>  drivers/watchdog/octeon-wdt-nmi.S  |  5 +---
>  drivers/watchdog/of_xilinx_wdt.c   |  8 ++---
>  drivers/watchdog/omap_wdt.c|  1 +
>  

[PATCH] watchdog: add SPDX identifiers for watchdog subsystem

[Marcus Folkesson]

- Add SPDX identifier
- Remove boiler plate license text
- If MODULE_LICENSE and boiler plate does not match, go for boiler plate
  license

Signed-off-by: Marcus Folkesson 
---

Notes:
v1: Please have an extra look at meson_gxbb_wdt.c

 drivers/watchdog/acquirewdt.c  |  6 +---
 drivers/watchdog/advantechwdt.c|  6 +---
 drivers/watchdog/alim1535_wdt.c|  6 +---
 drivers/watchdog/alim7101_wdt.c|  1 +
 drivers/watchdog/ar7_wdt.c | 14 +
 drivers/watchdog/asm9260_wdt.c |  2 +-
 drivers/watchdog/aspeed_wdt.c  |  5 +---
 drivers/watchdog/at91rm9200_wdt.c  |  5 +---
 drivers/watchdog/at91sam9_wdt.c|  5 +---
 drivers/watchdog/at91sam9_wdt.h|  5 +---
 drivers/watchdog/ath79_wdt.c   |  4 +--
 drivers/watchdog/atlas7_wdt.c  |  2 +-
 drivers/watchdog/bcm2835_wdt.c |  5 +---
 drivers/watchdog/bcm47xx_wdt.c |  5 +---
 drivers/watchdog/bcm63xx_wdt.c |  5 +---
 drivers/watchdog/bcm7038_wdt.c | 12 ++--
 drivers/watchdog/bcm_kona_wdt.c|  9 +-
 drivers/watchdog/bfin_wdt.c|  2 +-
 drivers/watchdog/booke_wdt.c   |  5 +---
 drivers/watchdog/cadence_wdt.c |  5 +---
 drivers/watchdog/coh901327_wdt.c   |  7 ++---
 drivers/watchdog/cpu5wdt.c | 15 +-
 drivers/watchdog/cpwd.c|  1 +
 drivers/watchdog/da9052_wdt.c  |  6 +---
 drivers/watchdog/da9055_wdt.c  |  6 +---
 drivers/watchdog/da9062_wdt.c  | 10 +--
 drivers/watchdog/da9063_wdt.c  |  5 +---
 drivers/watchdog/davinci_wdt.c |  7 ++---
 drivers/watchdog/diag288_wdt.c |  1 +
 drivers/watchdog/digicolor_wdt.c   |  5 +---
 drivers/watchdog/dw_wdt.c  |  6 +---
 drivers/watchdog/ebc-c384_wdt.c|  9 +-
 drivers/watchdog/ep93xx_wdt.c  |  7 ++---
 drivers/watchdog/eurotechwdt.c |  6 +---
 drivers/watchdog/f71808e_wdt.c | 16 +-
 drivers/watchdog/ftwdt010_wdt.c|  6 ++--
 drivers/watchdog/gef_wdt.c |  6 +---
 drivers/watchdog/geodewdt.c|  5 +---
 drivers/watchdog/gpio_wdt.c|  5 +---
 drivers/watchdog/hpwdt.c   |  7 ++---
 drivers/watchdog/i6300esb.c|  6 +---
 drivers/watchdog/iTCO_vendor_support.c |  9 +-
 drivers/watchdog/iTCO_wdt.c| 10 +--
 drivers/watchdog/ib700wdt.c|  6 +---
 drivers/watchdog/ibmasr.c  |  3 +-
 drivers/watchdog/ie6xx_wdt.c   | 18 ++-
 drivers/watchdog/imgpdc_wdt.c  |  5 +---
 drivers/watchdog/imx2_wdt.c|  5 +---
 drivers/watchdog/indydog.c |  6 +---
 drivers/watchdog/intel-mid_wdt.c   |  6 ++--
 drivers/watchdog/intel_scu_watchdog.c  | 18 ++-
 drivers/watchdog/intel_scu_watchdog.h  | 16 +-
 drivers/watchdog/iop_wdt.c | 16 ++
 drivers/watchdog/it8712f_wdt.c | 10 +--
 drivers/watchdog/it87_wdt.c| 10 +--
 drivers/watchdog/ixp4xx_wdt.c  |  6 ++--
 drivers/watchdog/jz4740_wdt.c  | 10 +--
 drivers/watchdog/kempld_wdt.c  | 12 ++--
 drivers/watchdog/ks8695_wdt.c  |  6 ++--
 drivers/watchdog/lantiq_wdt.c  |  7 ++---
 drivers/watchdog/loongson1_wdt.c   |  5 +---
 drivers/watchdog/lpc18xx_wdt.c |  5 +---
 drivers/watchdog/m54xx_wdt.c   |  6 ++--
 drivers/watchdog/machzwd.c | 11 +--
 drivers/watchdog/max63xx_wdt.c |  5 +---
 drivers/watchdog/max77620_wdt.c|  5 +---
 drivers/watchdog/mei_wdt.c | 12 ++--
 drivers/watchdog/mena21_wdt.c  |  4 +--
 drivers/watchdog/menf21bmc_wdt.c   |  8 ++---
 drivers/watchdog/meson_gxbb_wdt.c  | 55 +-
 drivers/watchdog/meson_wdt.c   |  6 +---
 drivers/watchdog/mixcomwd.c|  6 +---
 drivers/watchdog/moxart_wdt.c  |  7 ++---
 drivers/watchdog/mpc8xxx_wdt.c |  6 +---
 drivers/watchdog/mt7621_wdt.c  |  5 +---
 drivers/watchdog/mtk_wdt.c | 11 +--
 drivers/watchdog/mtx-1_wdt.c   | 11 +--
 drivers/watchdog/mv64x60_wdt.c |  6 ++--
 drivers/watchdog/ni903x_wdt.c  | 11 +--
 drivers/watchdog/nic7018_wdt.c | 11 +--
 drivers/watchdog/nuc900_wdt.c  |  7 ++---
 drivers/watchdog/nv_tco.c  |  6 +---
 drivers/watchdog/nv_tco.h  | 10 +--
 drivers/watchdog/octeon-wdt-main.c | 11 +--
 drivers/watchdog/octeon-wdt-nmi.S  |  5 +---
 drivers/watchdog/of_xilinx_wdt.c   |  8 ++---
 drivers/watchdog/omap_wdt.c|  1 +
 drivers/watchdog/omap_wdt.h| 21 +
 drivers/watchdog/orion_wdt.c   |  5 +---
 drivers/watchdog/pc87413_wdt.c | 10 +--
 drivers/watchdog/pcwd.c|  1 +
 drivers/watchdog/pcwd_pci.c| 10 +--
 

Re: [PATCH] fix double ;;s in code

[Jani Nikula]

On Mon, 19 Feb 2018, Pavel Machek  wrote:
> On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
>> Yeah, pls split this into one patch per area, with a suitable patch
>> subject prefix. Look at git log of each file to get a feeling for what's
>> the standard in each area.
>
> Yeah I can spend hour spliting it, and then people will ignore it
> anyway.
>
> If you care about one of the files being modified, please fix the
> bug, ";;" is a clear bug.
>
> If you don't care ... well I don't care either.

Look, if this causes just one conflict down the line because it touches
the kernel all over the place, then IMO it already wasn't worth
it. Merge conflicts are inevitable, but there's no reason to make life
harder just to cater for a cleanup patch. It's not that important.

Had it been split up, the drm parts would've been merged already.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 2/3] rfi-flush: Make it possible to call setup_rfi_flush() again

[Michael Ellerman]

Mauricio Faria de Oliveira  writes:

> Hi Michal and Michael,
>
> On 02/15/2018 05:13 AM, Michal Suchánek wrote:
>>> From: Michael Ellerman
>>>
>>> For PowerVM migration we want to be able to call setup_rfi_flush()
>>> again after we've migrated the partition.
>>>
>>> To support that we need to check that we're not trying to allocate the
>>> fallback flush area after memblock has gone away. If so we just fail,
>>> we don't support migrating from a patched to an unpatched machine. Or
>>> we do support it, but there will be no RFI flush enabled on the
>>> destination.
>>>
>> This sounds bad to me. Either we support RFI flush or we don't.
>> 
>> If we do the fallback area should be allocated at boot so it is always
>> available. [snip]
>
> I think the problem with this is the size of the fallback area might
> have to be different between the origin and destination systems, say,
> a larger L1 data cache at the destination.
>
> In that case, the original size might not be enough to fully flush
> the L1 data cache.
>
> Michael, is that the reason it is done that way?  I thought of that,
> but don't know for sure.

No, supporting different cache sizes is a good idea though :)

I did it the way I did because otherwise we waste memory on every system
on earth just to support a use case that we don't actually intend for
anyone to ever use - ie. migrating from a patched machine to an
unpatched machine.

In fact without further checks we'd be allocating the fallback area on
powernv machines which don't even support LPM.

So that just seemed a bit gross.

I think I'm inclined to leave it the way it is, unless you feel strongly
about it Michal?

cheers

Re: [RFC][PATCH bpf v2 1/2] bpf: allow 64-bit offsets for bpf function calls

[Michael Ellerman]

"Naveen N. Rao"  writes:
> Daniel Borkmann wrote:
>> On 02/15/2018 05:25 PM, Daniel Borkmann wrote:
>>> On 02/13/2018 05:05 AM, Sandipan Das wrote:
 The imm field of a bpf_insn is a signed 32-bit integer. For
 JIT-ed bpf-to-bpf function calls, it stores the offset from
 __bpf_call_base to the start of the callee function.

 For some architectures, such as powerpc64, it was found that
 this offset may be as large as 64 bits because of which this
 cannot be accomodated in the imm field without truncation.

 To resolve this, we additionally make aux->func within each
 bpf_prog associated with the functions to point to the list
 of all function addresses determined by the verifier.

 We keep the value assigned to the off field of the bpf_insn
 as a way to index into aux->func and also set aux->func_cnt
 so that this can be used for performing basic upper bound
 checks for the off field.

 Signed-off-by: Sandipan Das 
 ---
 v2: Make aux->func point to the list of functions determined
 by the verifier rather than allocating a separate callee
 list for each function.
>>> 
>>> Approach looks good to me; do you know whether s390x JIT would
>>> have similar requirement? I think one limitation that would still
>>> need to be addressed later with such approach would be regarding the
>>> xlated prog dump in bpftool, see 'BPF calls via JIT' in 7105e828c087
>>> ("bpf: allow for correlation of maps and helpers in dump"). Any
>>> ideas for this (potentially if we could use off + imm for calls,
>>> we'd get to 48 bits, but that seems still not be enough as you say)?
>
> All good points. I'm not really sure how s390x works, so I can't comment 
> on that, but I'm copying Michael Holzheu for his consideration.
>
> With the existing scheme, 48 bits won't be enough, so we rejected that 
> approach. I can also see how this will be a problem with bpftool, but I 
> haven't looked into it in detail. I wonder if we can annotate the output 
> to indicate the function being referred to?
>
>> 
>> One other random thought, although I'm not sure how feasible this
>> is for ppc64 JIT to realize ... but idea would be to have something
>> like the below:
>> 
>> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
>> index 29ca920..daa7258 100644
>> --- a/kernel/bpf/core.c
>> +++ b/kernel/bpf/core.c
>> @@ -512,6 +512,11 @@ int bpf_get_kallsym(unsigned int symnum, unsigned long 
>> *value, char *type,
>>  return ret;
>>  }
>> 
>> +void * __weak bpf_jit_image_alloc(unsigned long size)
>> +{
>> +return module_alloc(size);
>> +}
>> +
>>  struct bpf_binary_header *
>>  bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
>>   unsigned int alignment,
>> @@ -525,7 +530,7 @@ bpf_jit_binary_alloc(unsigned int proglen, u8 
>> **image_ptr,
>>   * random section of illegal instructions.
>>   */
>>  size = round_up(proglen + sizeof(*hdr) + 128, PAGE_SIZE);
>> -hdr = module_alloc(size);
>> +hdr = bpf_jit_image_alloc(size);
>>  if (hdr == NULL)
>>  return NULL;
>> 
>> And ppc64 JIT could override bpf_jit_image_alloc() in a similar way
>> like some archs would override the module_alloc() helper through a
>> custom implementation, usually via __vmalloc_node_range(), so we
>> could perhaps fit the range for BPF JITed images in a way that they
>> could use the 32bit imm in the end? There are not that many progs
>> loaded typically, so the range could be a bit narrower in such case
>> anyway. (Not sure if this would work out though, but I thought to
>> bring it up.)
>
> That'd be a good option to consider. I don't think we want to allocate 
> anything from the linear memory range since users could load 
> unprivileged BPF programs and consume a lot of memory that way. I doubt 
> if we can map vmalloc'ed memory into the 0xc0 address range, but I'm not 
> entirely sure.
>
> Michael,
> Is the above possible? The question is if we can have BPF programs be 
> allocated within 4GB of __bpf_call_base (which is a kernel symbol), so 
> that calls to those programs can be encoded in a 32-bit immediate field 
> in a BPF instruction.

Hmmm.

It's not technically impossible, but I don't think it's really a good
option.

The 0xc range is a linear mapping of RAM, and the kernel tends to be
near the start of RAM for reasons. That means there generally isn't a
hole in the 0xc range within 4GB for you to map BPF programs.

You could create a hole by making the 0xc mapping non linear, ie.
mapping some RAM near the kernel elsewhere in the 0xc range, to make a
hole that you can then remap BPF programs into. But I think that would
cause a lot of bugs, it's a pretty fundamental assumption that the
linear mapping is 1:1.

> As an extension, we may be able to extend it to 
> 48-bits by combining with another BPF instruction field (offset). In 
> either case, the 

Re: [PATCH V5] cxl: Fix timebase synchronization status on P9

[Frederic Barrat]

Le 19/02/2018 à 15:28, Christophe Lombard a écrit :

The PSL Timebase register is updated by the PSL to maintain the
timebase.
On P9, the Timebase value is only provided by the CAPP as received
the last time a timebase request was performed.
The timebase requests are initiated through the adapter configuration or
application registers.
The specific sysfs entry "/sys/class/cxl/cardxx/psl_timebase_synced" is
now dynamically updated according the content of the PSL Timebase
register.

Signed-off-by: Christophe Lombard 

---
This patch applies on top of this patch:
  http://patchwork.ozlabs.org/patch/873663/

Changelog[v5]
  - Rebased to latest upstream.
  - Changed the type of 'delta'

Changelog[v4]
  - Rebased to latest upstream.
  - Added log message.

Changelog[v3]
  - Rebased to latest upstream.
  - Dynamic update is now applied to P8.

Changelog[v2]
  - Missing Signed-off-by.
  - Spaces required around the ':'.
---
  drivers/misc/cxl/pci.c   | 17 -
  drivers/misc/cxl/sysfs.c | 10 ++
  2 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 66eed6a..3247eaf 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -606,9 +606,6 @@ static u64 timebase_read_xsl(struct cxl *adapter)

  static void cxl_setup_psl_timebase(struct cxl *adapter, struct pci_dev *dev)
  {
-   u64 psl_tb;
-   int delta;
-   unsigned int retry = 0;
struct device_node *np;

adapter->psl_timebase_synced = false;
@@ -636,20 +633,6 @@ static void cxl_setup_psl_timebase(struct cxl *adapter, 
struct pci_dev *dev)
cxl_p1_write(adapter, CXL_PSL_Control, 0x);
cxl_p1_write(adapter, CXL_PSL_Control, CXL_PSL_Control_tb);

-   /* Wait until CORE TB and PSL TB difference <= 16usecs */
-   do {
-   msleep(1);
-   if (retry++ > 5) {
-   dev_info(>dev, "PSL timebase can't synchronize\n");
-   return;
-   }
-   psl_tb = adapter->native->sl_ops->timebase_read(adapter);
-   delta = mftb() - psl_tb;
-   if (delta < 0)
-   delta = -delta;
-   } while (tb_to_ns(delta) > 16000);
-
-   adapter->psl_timebase_synced = true;
return;
  }

diff --git a/drivers/misc/cxl/sysfs.c b/drivers/misc/cxl/sysfs.c
index a8b6d6a..a20bf8e 100644
--- a/drivers/misc/cxl/sysfs.c
+++ b/drivers/misc/cxl/sysfs.c
@@ -62,6 +62,16 @@ static ssize_t psl_timebase_synced_show(struct device 
*device,
char *buf)
  {
struct cxl *adapter = to_cxl_adapter(device);
+   u64 psl_tb, delta;
+
+   psl_tb = adapter->native->sl_ops->timebase_read(adapter);


It would dump core in a lpar.
pHyp is supposed to have it initialized, though we have no way to know 
for sure. On p8, we're also only supporting a card which doesn't have 
timebase problem on powerVM and it doesn't apply to p9. So I think we 
just need to recompute the status on bare-metal only.


  Fred



+   delta = abs(mftb() - psl_tb);
+
+   /* CORE TB and PSL TB difference <= 16usecs ? */
+   adapter->psl_timebase_synced = (tb_to_ns(delta) < 16000) ? true : false;
+   pr_devel("PSL timebase %s - delta: 0x%016llx\n",
+(tb_to_ns(delta) < 16000) ? "synchronized" :
+"not synchronized", tb_to_ns(delta));

return scnprintf(buf, PAGE_SIZE, "%i\n", adapter->psl_timebase_synced);
  }

Re: [PATCH] scsi: cxlflash: Select SCSI_SCAN_ASYNC

[Michael Ellerman]

Vaibhav Jain  writes:

> The cxlflash driver uses "Asynchronous SCSI scanning" enabled by
> CONFIG_SCSI_SCAN_ASYNC. Without this enabled the modprobe of cxlflash
> module gets hung with following backtrace:
>
> Call Trace:
>  __switch_to+0x2cc/0x470
>  __schedule+0x288/0xab0
>  schedule+0x40/0xc0
>  schedule_timeout+0x254/0x4f0
>  wait_for_common+0xdc/0x260
>  flush_work+0x140/0x2a0
>  work_on_cpu+0x88/0xb0
>  pci_device_probe+0x1d0/0x220
>  driver_probe_device+0x408/0x5b0
>  __driver_attach+0x16c/0x1a0
>  bus_for_each_dev+0xb8/0x110
>  driver_attach+0x3c/0x60
>  bus_add_driver+0x1d8/0x370
>  driver_register+0x9c/0x180
>  __pci_register_driver+0x74/0xa0
>  init_cxlflash+0x158/0x1cc
>  do_one_initcall+0x68/0x1e0
>  do_init_module+0x90/0x254
>  load_module+0x2f8c/0x3720
>  SyS_finit_module+0xcc/0x140
>  system_call+0x58/0x6c

Why does it "hang"? That's kind of bizarre, I would expect either a
build or runtime failure if a feature the driver requires is missing.

> diff --git a/drivers/scsi/cxlflash/Kconfig b/drivers/scsi/cxlflash/Kconfig
> index a011c5dbf214..f054c1b0fff3 100644
> --- a/drivers/scsi/cxlflash/Kconfig
> +++ b/drivers/scsi/cxlflash/Kconfig
> @@ -6,6 +6,7 @@ config CXLFLASH
>   tristate "Support for IBM CAPI Flash"
>   depends on PCI && SCSI && CXL && EEH
>   select IRQ_POLL
> + select SCSI_SCAN_ASYNC

It's user configurable, so it's rude to select it. It can also be
disabled on the kernel command line, so this seems like a fragile
solution.

cheers