linux-next: Tree for Aug 2

2019-08-01 Thread Stephen Rothwell
Hi all,

Changes since 20190801:

My fixes tree is empty again

The jc_docs tree gained a conflict against the cifs tree.

The drm-misc tree lost its build failure.

The tip tree lost its build failure.

Non-merge commits (relative to Linus' tree): 3729
 4234 files changed, 221424 insertions(+), 101481 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 304 trees (counting Linus' and 74 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1e78030e5e5b Merge tag 'mmc-v5.3-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc)
Merging fixes/master (609488bc979f Linux 5.3-rc2)
Merging kbuild-current/fixes (e8de12fb7cde kbuild: Check for unknown options 
with cc-option usage in Kconfig and clang)
Merging arc-current/for-curr (4431af2bc1c6 ARC: fix typo in setup_dma_ops log 
message)
Merging arm-current/fixes (c5d0e49e8d8f ARM: 8867/1: vdso: pass --be8 to linker 
if necessary)
Merging arm-soc-fixes/arm/fixes (7bd9d465140a Merge tag 'imx-fixes-5.3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes)
Merging arm64-fixes/for-next/fixes (749d1a348860 arm64: Make debug exception 
handlers visible from RCU)
Merging m68k-current/for-linus (f28a1f16135c m68k: Don't select 
ARCH_HAS_DMA_PREP_COHERENT for nommu or coldfire)
Merging powerpc-fixes/fixes (d7e23b887f67 powerpc/kasan: fix early boot failure 
on PPC32)
Merging s390-fixes/fixes (8480657280ee vfio-ccw: make vfio_ccw_async_region_ops 
static)
Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (18601078957b Merge branch 
'net-Manufacturer-names-and-spelling-fixes')
Merging bpf/master (f1fc7249dddc selftests/bpf: tests for jmp to 1st insn)
Merging ipsec/master (22d6552f827e xfrm interface: fix management of phydev)
Merging netfilter/master (4d97972b45f0 net: stmmac: Use netif_tx_napi_add() for 
TX polling function)
Merging ipvs/master (58e8b37069ff Merge branch 'net-phy-dp83867-add-some-fixes')
Merging wireless-drivers/master (1f6607250331 iwlwifi: dbg_ini: fix compile 
time assert build errors)
Merging mac80211/master (d8a1de3d5bb8 isdn: hfcsusb: Fix mISDN driver crash 
caused by transfer buffer on the stack)
Merging rdma-fixes/for-rc (708637e65abd Do not dereference 'siw_crypto_shash' 
before checking)
Merging sound-current/for-linus (5d78e1c2b7f4 ALSA: usb-audio: Fix gpf in 
snd_usb_pipe_sanity_check)
Merging sound-asoc-fixes/for-linus (130fe519da23 Merge branch 'asoc-5.3' into 
asoc-linus)
Merging regmap-fixes/for-linus (609488bc979f Linux 5.3-rc2)
Merging regulator-fixes/for-linus (407561586cdf Merge branch 'regulator-5.3' 
into regulator-linus)
Merging spi-fixes/for-linus (5573a4c95617 Merge branch 'spi-5.3' into spi-linus)
Merging pci-current/for-linus (5f9e832c1370 Linus 5.3-rc1)
Merging driver-core.current/driver-core-linus (ac43432cb1f5 driver core: Fix 
use-after-free and double free on glue directory)
Merging tty.current/tty-linus (81eaadcae81b kgdboc: disable the console lock 
when in kgdb)
Merging usb.current/usb-linus (a29d56c2ed24 usb: typec: ucsi: ccg: Fix 
uninitilized symbol error)
Merging usb-gadget-fixes/fixes (42de8afc40c9 usb: dwc2: Use generic PHY width 
in params setup)
Merging usb-se

Re: [PATCH] ALSA: hda: Add support of Zhaoxin controller

2019-08-01 Thread Takashi Iwai
On Fri, 02 Aug 2019 05:04:08 +0200,
Tony W Wang-oc wrote:
> 
> Add the new PCI ID 0x1d17 0x3288 Zhaoxin controller support
> 
> Signed-off-by: Tony W Wang-oc 

Applied, thanks.


Takashi


Re: [PATCH] ALSA: isa/wavefront: remove redundant assignment to pointer bptr

2019-08-01 Thread Takashi Iwai
On Thu, 01 Aug 2019 18:28:24 +0200,
Colin King wrote:
> 
> From: Colin Ian King 
> 
> The pointer bptr is being assigned a value that is never read
> and it is being updated in the next statement with a new value.
> The initialization is redundant and can be removed.
> 
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King 

Applied, thanks.


Takashi


[PATCH V3 2/2] cpufreq: intel_pstate: Implement ->resolve_freq()

2019-08-01 Thread Viresh Kumar
Intel pstate driver exposes min_perf_pct and max_perf_pct sysfs files,
which can be used to force a limit on the min/max P state of the driver.
Though these files eventually control the min/max frequencies that the
CPUs will run at, they don't make a change to policy->min/max values.

When the values of these files are changed (in passive mode of the
driver), it leads to calling ->limits() callback of the cpufreq
governors, like schedutil. On a call to it the governors shall
forcefully update the frequency to come within the limits. For getting
the value within limits, the schedutil governor calls
cpufreq_driver_resolve_freq(), which eventually tries to call
->resolve_freq() callback for this driver. Since the callback isn't
present, the schedutil governor fails to get the target freq within
limit and sometimes aborts the update believing that the frequency is
already set to the target value.

This patch implements the resolve_freq() callback, so the correct target
frequency can be returned by the driver and the schedutil governor gets
the frequency within limits immediately.

Fixes: ecd288429126 ("cpufreq: schedutil: Don't set next_freq to UINT_MAX")
Cc: v4.18+  # v4.18+
Reported-by: Doug Smythies 
Signed-off-by: Viresh Kumar 
---
V3:
- This was earlier posted as a diff to an email reply and is getting
  sent for the first time only as a proper patch.

 drivers/cpufreq/intel_pstate.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index cc27d4c59dca..2d84361fbebc 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2314,6 +2314,18 @@ static int intel_cpufreq_target(struct cpufreq_policy 
*policy,
return 0;
 }
 
+static unsigned int intel_cpufreq_resolve_freq(struct cpufreq_policy *policy,
+  unsigned int target_freq)
+{
+   struct cpudata *cpu = all_cpu_data[policy->cpu];
+   int target_pstate;
+
+   target_pstate = DIV_ROUND_UP(target_freq, cpu->pstate.scaling);
+   target_pstate = intel_pstate_prepare_request(cpu, target_pstate);
+
+   return target_pstate * cpu->pstate.scaling;
+}
+
 static unsigned int intel_cpufreq_fast_switch(struct cpufreq_policy *policy,
  unsigned int target_freq)
 {
@@ -2350,6 +2362,7 @@ static struct cpufreq_driver intel_cpufreq = {
.verify = intel_cpufreq_verify_policy,
.target = intel_cpufreq_target,
.fast_switch= intel_cpufreq_fast_switch,
+   .resolve_freq   = intel_cpufreq_resolve_freq,
.init   = intel_cpufreq_cpu_init,
.exit   = intel_pstate_cpu_exit,
.stop_cpu   = intel_cpufreq_stop_cpu,
-- 
2.21.0.rc0.269.g1a574e7a288b



[PATCH V3 1/2] cpufreq: schedutil: Don't skip freq update when limits change

2019-08-01 Thread Viresh Kumar
To avoid reducing the frequency of a CPU prematurely, we skip reducing
the frequency if the CPU had been busy recently.

This should not be done when the limits of the policy are changed, for
example due to thermal throttling. We should always get the frequency
within the new limits as soon as possible.

Trying to fix this by using only one flag, i.e. need_freq_update, can
lead to a race condition where the flag gets cleared without forcing us
to change the frequency at least once. And so this patch introduces
another flag to avoid that race condition.

Fixes: ecd288429126 ("cpufreq: schedutil: Don't set next_freq to UINT_MAX")
Cc: v4.18+  # v4.18+
Reported-by: Doug Smythies 
Signed-off-by: Viresh Kumar 
---
V2->V3:
- Updated commit log.

V1->V2:
- Fixed the race condition using a different flag.

@Doug: I haven't changed the code since you last tested these. Your
Tested-by tag can be useful while applying the patches. Thanks.

 kernel/sched/cpufreq_schedutil.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 636ca6f88c8e..2f382b0959e5 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -40,6 +40,7 @@ struct sugov_policy {
struct task_struct  *thread;
boolwork_in_progress;
 
+   boollimits_changed;
boolneed_freq_update;
 };
 
@@ -89,8 +90,11 @@ static bool sugov_should_update_freq(struct sugov_policy 
*sg_policy, u64 time)
!cpufreq_this_cpu_can_update(sg_policy->policy))
return false;
 
-   if (unlikely(sg_policy->need_freq_update))
+   if (unlikely(sg_policy->limits_changed)) {
+   sg_policy->limits_changed = false;
+   sg_policy->need_freq_update = true;
return true;
+   }
 
delta_ns = time - sg_policy->last_freq_update_time;
 
@@ -437,7 +441,7 @@ static inline bool sugov_cpu_is_busy(struct sugov_cpu 
*sg_cpu) { return false; }
 static inline void ignore_dl_rate_limit(struct sugov_cpu *sg_cpu, struct 
sugov_policy *sg_policy)
 {
if (cpu_bw_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->bw_dl)
-   sg_policy->need_freq_update = true;
+   sg_policy->limits_changed = true;
 }
 
 static void sugov_update_single(struct update_util_data *hook, u64 time,
@@ -447,7 +451,7 @@ static void sugov_update_single(struct update_util_data 
*hook, u64 time,
struct sugov_policy *sg_policy = sg_cpu->sg_policy;
unsigned long util, max;
unsigned int next_f;
-   bool busy;
+   bool busy = false;
 
sugov_iowait_boost(sg_cpu, time, flags);
sg_cpu->last_update = time;
@@ -457,7 +461,9 @@ static void sugov_update_single(struct update_util_data 
*hook, u64 time,
if (!sugov_should_update_freq(sg_policy, time))
return;
 
-   busy = sugov_cpu_is_busy(sg_cpu);
+   /* Limits may have changed, don't skip frequency update */
+   if (!sg_policy->need_freq_update)
+   busy = sugov_cpu_is_busy(sg_cpu);
 
util = sugov_get_util(sg_cpu);
max = sg_cpu->max;
@@ -831,6 +837,7 @@ static int sugov_start(struct cpufreq_policy *policy)
sg_policy->last_freq_update_time= 0;
sg_policy->next_freq= 0;
sg_policy->work_in_progress = false;
+   sg_policy->limits_changed   = false;
sg_policy->need_freq_update = false;
sg_policy->cached_raw_freq  = 0;
 
@@ -879,7 +886,7 @@ static void sugov_limits(struct cpufreq_policy *policy)
mutex_unlock(_policy->work_lock);
}
 
-   sg_policy->need_freq_update = true;
+   sg_policy->limits_changed = true;
 }
 
 struct cpufreq_governor schedutil_gov = {
-- 
2.21.0.rc0.269.g1a574e7a288b



Overhead of ring buffer in Ftrace

2019-08-01 Thread Fang Zhou
Hi all,

I’m currently using Ftrace with tracepoints to trace several events in
kernel. But I found the tracing overhead is a little high.

I found the major overhead comes from
“local_dec(_buffer->committing);” in rb_end_commit() function.
local_dec() will invoke atomic_long_dec(), which finally performs
LOCK_PREFIX plus "DECQ" on this variable.

I'm a little confused. cpu_buffer is a per-cpu buffer. Therefore, I
cannot come up with a scenario that two core runs INC or DEC on the
same per-cpu value at the same time.
So, why do we use such heavy-overhead operation here? Can we just
simply use "DECQ" without LOCK_PREFIX?

Thanks,
Tim


Re: [PATCH v2] ARM: dts: aspeed: Add Facebook Wedge100 BMC

2019-08-01 Thread Tao Ren
On 8/1/19, 10:26 PM, "Joel Stanley"  wrote:

>  I've applied both of these to the aspeed tree for 5.4.

Thank you Joel.

Cheers,

Tao



Re: [PATCH v2] ARM: dts: aspeed: Add Facebook Wedge100 BMC

2019-08-01 Thread Joel Stanley
On Fri, 2 Aug 2019 at 05:20, Tao Ren  wrote:
>
> On 8/1/19, 9:21 PM, "Joel Stanley"  wrote:
>
> >  On Fri, 2 Aug 2019 at 04:10, Tao Ren  wrote:
> >>
> >> Add initial version of device tree for Facebook Wedge100 AST2400 BMC
> >> platform.
> >>
> >> Signed-off-by: Tao Ren 
> >> Reviewed-by: Andrew Jeffery 
> >> ---
> >>  Changes in v2:
> >>  - remove "debug" from bootargs.
> >
> > Thanks. I applied wedge40 and then this one fails to apply due to
> > conflicts in the Makefile. Next time you have two patches, send them
> > as a series they apply one atop the other.
>
> I thought about asking you if I should send them as a series although they 
> are logically independent patches..
> Sorry about that and I will do so for future patches.
>
> >  The naming of these two files suggests they come from a family. I
> >  noticed there's very minor differences, a pca9548 switch and the use
> >  of a watchdog.
> >
> >  Are these device trees complete? If yes, do you think it's worthwhile
> >  to have a common wedge description in eg.
> >  aspeed-bmc-facebook-wedge.dtsi, and put the unique description in
> >  respective dts board files?
> >
> >  The upside of this is reduced duplication.
> >
> >  If you have a reason not to, then that is okay and we can leave it as
> >  you submitted them.
>
> Thank you for the suggestion. I'm also considering moving common stuff into 
> "dtsi" file, but let me take care of it in a separate patch, mainly because:
>   1) I have one more BMC platform (galaxy100) which is also similar to wedge.
>   I haven't started the platform, but once I have galaxy100 device tree 
> ready, it would be easier for me to extract common part.
>   2) the device tree is not complete yet.
>   For example, all the i2c devices are still created from userspace.
>   I'm trying to move the logic from userspace to device tree but I 
> haven't decided what to do with those cpld/fpga devices.

Okay, thanks.

I've applied both of these to the aspeed tree for 5.4.

Cheers,

Joel


Re: [PATCH] perf tools: Fix a typo in Makefile

2019-08-01 Thread Mukesh Ojha



On 8/1/2019 8:58 AM, Masanari Iida wrote:

This patch fix a spelling typo in Makefile.

Signed-off-by: Masanari Iida 


Reviewed-by: Mukesh Ojha 

-Mukesh


---
  tools/perf/Documentation/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/Makefile 
b/tools/perf/Documentation/Makefile
index 6d148a40551c..adc5a7e44b98 100644
--- a/tools/perf/Documentation/Makefile
+++ b/tools/perf/Documentation/Makefile
@@ -242,7 +242,7 @@ $(OUTPUT)doc.dep : $(wildcard *.txt) build-docdep.perl
$(PERL_PATH) ./build-docdep.perl >$@+ $(QUIET_STDERR) && \
mv $@+ $@
  
--include $(OUPTUT)doc.dep

+-include $(OUTPUT)doc.dep
  
  _cmds_txt = cmds-ancillaryinterrogators.txt \

cmds-ancillarymanipulators.txt \


Re: [PATCH v2] arm64: zynqmp: Add ZynqMP SDHCI compatible string

2019-08-01 Thread Michal Simek
On 01. 07. 19 7:37, Manish Narani wrote:
> Add the new compatible string for ZynqMP SD Host Controller for its use
> in the Arasan SDHCI driver for some of the ZynqMP specific operations.
> Add required properties for the same.
> 
> Signed-off-by: Manish Narani 
> ---
> This patch depends on the below series of patches:
> https://lkml.org/lkml/2019/7/1/25
> 
> Changes in v2:
>   - Added clock-names for SD card clocks for getting clocks in the driver

Just for a record. I am waiting till binding is Acked.

M


Re: [PATCH v2] ARM: dts: aspeed: Add Facebook Wedge100 BMC

2019-08-01 Thread Tao Ren
On 8/1/19, 9:21 PM, "Joel Stanley"  wrote:

>  On Fri, 2 Aug 2019 at 04:10, Tao Ren  wrote:
>>
>> Add initial version of device tree for Facebook Wedge100 AST2400 BMC
>> platform.
>>
>> Signed-off-by: Tao Ren 
>> Reviewed-by: Andrew Jeffery 
>> ---
>>  Changes in v2:
>>  - remove "debug" from bootargs.
>
> Thanks. I applied wedge40 and then this one fails to apply due to
> conflicts in the Makefile. Next time you have two patches, send them
> as a series they apply one atop the other.

I thought about asking you if I should send them as a series although they are 
logically independent patches..
Sorry about that and I will do so for future patches.

>  The naming of these two files suggests they come from a family. I
>  noticed there's very minor differences, a pca9548 switch and the use
>  of a watchdog.
>  
>  Are these device trees complete? If yes, do you think it's worthwhile
>  to have a common wedge description in eg.
>  aspeed-bmc-facebook-wedge.dtsi, and put the unique description in
>  respective dts board files?
>   
>  The upside of this is reduced duplication.
>  
>  If you have a reason not to, then that is okay and we can leave it as
>  you submitted them.

Thank you for the suggestion. I'm also considering moving common stuff into 
"dtsi" file, but let me take care of it in a separate patch, mainly because:
  1) I have one more BMC platform (galaxy100) which is also similar to wedge.
  I haven't started the platform, but once I have galaxy100 device tree 
ready, it would be easier for me to extract common part.
  2) the device tree is not complete yet.
  For example, all the i2c devices are still created from userspace.
  I'm trying to move the logic from userspace to device tree but I haven't 
decided what to do with those cpld/fpga devices.


Cheers,

Tao



Re: [PATCH] powerpc: Remove inaccessible CMDLINE default

2019-08-01 Thread Christophe Leroy




Le 02/08/2019 à 07:02, Chris Packham a écrit :

Since commit cbe46bd4f510 ("powerpc: remove CONFIG_CMDLINE #ifdef mess")
CONFIG_CMDLINE has always had a value regardless of CONNIG_CMDLINE_BOOL.


s/CONNIG/CONFIG/



For example:

  $ make ARCH=powerpc defconfig
  $ cat .config
  # CONFIG_CMDLINE_BOOL is not set
  CONFIG_CMDLINE=""

When enabling CONNIG_CMDLINE_BOOL this value is kept making the 'default
"..." if CONNIG_CMDLINE_BOOL' ineffective.


s/CONNIG/CONFIG/



  $ ./scripts/config --enable CONFIG_CMDLINE_BOOL
  $ cat .config
  CONFIG_CMDLINE_BOOL=y
  CONFIG_CMDLINE=""

Additionally all the in-tree powerpc defconfigs that set
CONFIG_CMDLINE_BOOL=y also set CONFIG_CMDLINE to something else. For
these reasons remove the inaccessible default.

Signed-off-by: Chris Packham 


Reviewed-by: Christophe Leroy 


---
This should be independent of http://patchwork.ozlabs.org/patch/1140811/ but
I've generated this patch on a stream that has it applied locally.

  arch/powerpc/Kconfig | 1 -
  1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d413fe1b4058..6fca6eba6aee 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -844,7 +844,6 @@ config CMDLINE_BOOL
  
  config CMDLINE

string "Initial kernel command string" if CMDLINE_BOOL
-   default "console=ttyS0,9600 console=tty0 root=/dev/sda2" if CMDLINE_BOOL
default ""
help
  On some platforms, there is currently no way for the boot loader to



I think we could also get rid of CMDLINE_BOOL totally and use CMDLINE != 
"" instead.


Christophe


Re: [PATCH] mailbox: zynqmp-ipi-mailbox: Add of_node_put() before goto

2019-08-01 Thread Michal Simek
On 02. 08. 19 6:59, Nishka Dasgupta wrote:
> On 31/07/19 7:51 PM, Michal Simek wrote:
>> On 31. 07. 19 15:06, Nishka Dasgupta wrote:
>>> On 31/07/19 2:01 PM, Michal Simek wrote:
 On 09. 07. 19 19:28, Nishka Dasgupta wrote:
> Each iteration of for_each_available_child_of_node puts the previous
> node, but in the case of a goto from the middle of the loop, there is
> no put, thus causing a memory leak. Hence add an of_node_put before
> the
> goto.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta 
> ---
>    drivers/mailbox/zynqmp-ipi-mailbox.c | 1 +
>    1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c
> b/drivers/mailbox/zynqmp-ipi-mailbox.c
> index 86887c9a349a..bd80d4c10ec2 100644
> --- a/drivers/mailbox/zynqmp-ipi-mailbox.c
> +++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
> @@ -661,6 +661,7 @@ static int zynqmp_ipi_probe(struct
> platform_device *pdev)
>    if (ret) {
>    dev_err(dev, "failed to probe subdev.\n");
>    ret = -EINVAL;
> +    of_node_put(nc);
>    goto free_mbox_dev;
>    }
>    mbox++;
>

 Patch is good but when you are saying that this was found by Coccinelle
 then it should be added as script to kernel to detect it.
>>>
>>> This particular patch was suggested by a script I did not write myself;
>>> someone else wrote it and sent it to me. How should I proceed in this
>>> case?
>>
>> You can ask him to submit it to kernel.
>> Or you can take it, keep his authorship and send it to:
> 
> I have asked her to submit this script, thank you. Will I need to
> resubmit this patch, however?

I will let Jassi to decide.

Thanks,
Michal


Re: Slowness forming TIPC cluster with explicit node addresses

2019-08-01 Thread Chris Packham
On Mon, 2019-07-29 at 09:04 +1200, Chris Packham wrote:
> On Fri, 2019-07-26 at 13:31 +, Jon Maloy wrote:
> > 
> > 
> > > 
> > > 
> > > -Original Message-
> > > From: netdev-ow...@vger.kernel.org 
> > > On
> > > Behalf Of Chris Packham
> > > Sent: 25-Jul-19 19:37
> > > To: tipc-discuss...@lists.sourceforge.net
> > > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > Subject: Slowness forming TIPC cluster with explicit node
> > > addresses
> > > 
> > > Hi,
> > > 
> > > I'm having problems forming a TIPC cluster between 2 nodes.
> > > 
> > > This is the basic steps I'm going through on each node.
> > > 
> > > modprobe tipc
> > > ip link set eth2 up
> > > tipc node set addr 1.1.5 # or 1.1.6
> > > tipc bearer enable media eth dev eth0
> > eth2, I assume...
> > 
> Yes sorry I keep switching between between Ethernet ports for testing
> so I hand edited the email.
> 
> > 
> > > 
> > > 
> > > 
> > > Then to confirm if the cluster is formed I use tipc link list
> > > 
> > > [root@node-5 ~]# tipc link list
> > > broadcast-link: up
> > > ...
> > > 
> > > Looking at tcpdump the two nodes are sending packets
> > > 
> > > 22:30:05.782320 TIPC v2.0 1.1.5 > 0.0.0, headerlength 60 bytes,
> > > MessageSize
> > > 76 bytes, Neighbor Detection Protocol internal, messageType Link
> > > request
> > > 22:30:05.863555 TIPC v2.0 1.1.6 > 0.0.0, headerlength 60 bytes,
> > > MessageSize
> > > 76 bytes, Neighbor Detection Protocol internal, messageType Link
> > > request
> > > 
> > > Eventually (after a few minutes) the link does come up
> > > 
> > > [root@node-6 ~]# tipc link list
> > > broadcast-link: up
> > > 1001006:eth2-1001005:eth2: up
> > > 
> > > [root@node-5 ~]# tipc link list
> > > broadcast-link: up
> > > 1001005:eth2-1001006:eth2: up
> > > 
> > > When I remove the "tipc node set addr" things seem to kick into
> > > life straight
> > > away
> > > 
> > > [root@node-5 ~]# tipc link list
> > > broadcast-link: up
> > > 0050b61bd2aa:eth2-0050b61e6dfa:eth2: up
> > > 
> > > So there appears to be some difference in behaviour between
> > > having
> > > an
> > > explicit node address and using the default. Unfortunately our
> > > application
> > > relies on setting the node addresses.
> > I do this many times a day, without any problems. If there would be
> > any time difference, I would expect the 'auto configurable' version
> > to be slower, because it involves a DAD step.
> > Are you sure you don't have any other nodes running in your system?
> > 
> > ///jon
> > 
> Nope the two nodes are connected back to back. Does the number of
> Ethernet interfaces make a difference? As you can see I've got 3 on
> each node. One is completely disconnected, one is for booting over
> TFTP
>  (only used by U-boot) and the other is the USB Ethernet I'm using
> for
> testing.
> 

So I can still reproduce this on nodes that only have one network
interface and are the only things connected.

I did find one thing that helps

diff --git a/net/tipc/discover.c b/net/tipc/discover.c
index c138d68e8a69..49921dad404a 100644
--- a/net/tipc/discover.c
+++ b/net/tipc/discover.c
@@ -358,10 +358,10 @@ int tipc_disc_create(struct net *net, struct
tipc_bearer *b,
tipc_disc_init_msg(net, d->skb, DSC_REQ_MSG, b);
 
/* Do we need an address trial period first ? */
-   if (!tipc_own_addr(net)) {
+// if (!tipc_own_addr(net)) {
tn->addr_trial_end = jiffies + msecs_to_jiffies(1000);
msg_set_type(buf_msg(d->skb), DSC_TRIAL_MSG);
-   }
+// }
memcpy(>dest, dest, sizeof(*dest));
d->net = net;
d->bearer_id = b->identity;

I think because with pre-configured addresses the duplicate address
detection is skipped the shorter init phase is skipped. Would is make
sense to unconditionally do the trial step? Or is there some better way
to get things to transition with pre-assigned addresses.

Re: [PATCH] PCI: Mark expected switch fall-through

2019-08-01 Thread Kees Cook
On Thu, Aug 01, 2019 at 08:22:48PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
> 
> This patch fixes the following warning (Building: allmodconfig i386):
> 
> drivers/pci/hotplug/ibmphp_res.c: In function ‘update_bridge_ranges’:
> drivers/pci/hotplug/ibmphp_res.c:1943:16: warning: this statement may fall 
> through [-Wimplicit-fallthrough=]
>function = 0x8;
>~^
> drivers/pci/hotplug/ibmphp_res.c:1944:6: note: here
>   case PCI_HEADER_TYPE_MULTIBRIDGE:
>   ^~~~
> 
> Signed-off-by: Gustavo A. R. Silva 

Reviewed-by: Kees Cook 

-Kees

> ---
>  drivers/pci/hotplug/ibmphp_res.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pci/hotplug/ibmphp_res.c 
> b/drivers/pci/hotplug/ibmphp_res.c
> index 5e8caf7a4452..1e1ba66cfd1e 100644
> --- a/drivers/pci/hotplug/ibmphp_res.c
> +++ b/drivers/pci/hotplug/ibmphp_res.c
> @@ -1941,6 +1941,7 @@ static int __init update_bridge_ranges(struct bus_node 
> **bus)
>   break;
>   case PCI_HEADER_TYPE_BRIDGE:
>   function = 0x8;
> + /* Fall through */
>   case PCI_HEADER_TYPE_MULTIBRIDGE:
>   /* We assume here that only 1 
> bus behind the bridge
>  TO DO: add functionality for 
> several:
> -- 
> 2.22.0
> 

-- 
Kees Cook


Re: [PATCH v4] watchdog: alim1535: Rewriting of alim1535 to use watchdog subsystem

2019-08-01 Thread Mark Balantzyan

Please see: https://lkml.org/lkml/2019/8/2/6

Thank you.



[PATCH] powerpc: Remove inaccessible CMDLINE default

2019-08-01 Thread Chris Packham
Since commit cbe46bd4f510 ("powerpc: remove CONFIG_CMDLINE #ifdef mess")
CONFIG_CMDLINE has always had a value regardless of CONNIG_CMDLINE_BOOL.

For example:

 $ make ARCH=powerpc defconfig
 $ cat .config
 # CONFIG_CMDLINE_BOOL is not set
 CONFIG_CMDLINE=""

When enabling CONNIG_CMDLINE_BOOL this value is kept making the 'default
"..." if CONNIG_CMDLINE_BOOL' ineffective.

 $ ./scripts/config --enable CONFIG_CMDLINE_BOOL
 $ cat .config
 CONFIG_CMDLINE_BOOL=y
 CONFIG_CMDLINE=""

Additionally all the in-tree powerpc defconfigs that set
CONFIG_CMDLINE_BOOL=y also set CONFIG_CMDLINE to something else. For
these reasons remove the inaccessible default.

Signed-off-by: Chris Packham 
---
This should be independent of http://patchwork.ozlabs.org/patch/1140811/ but
I've generated this patch on a stream that has it applied locally.

 arch/powerpc/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d413fe1b4058..6fca6eba6aee 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -844,7 +844,6 @@ config CMDLINE_BOOL
 
 config CMDLINE
string "Initial kernel command string" if CMDLINE_BOOL
-   default "console=ttyS0,9600 console=tty0 root=/dev/sda2" if CMDLINE_BOOL
default ""
help
  On some platforms, there is currently no way for the boot loader to
-- 
2.22.0



Re: [PATCH] mailbox: zynqmp-ipi-mailbox: Add of_node_put() before goto

2019-08-01 Thread Nishka Dasgupta

On 31/07/19 7:51 PM, Michal Simek wrote:

On 31. 07. 19 15:06, Nishka Dasgupta wrote:

On 31/07/19 2:01 PM, Michal Simek wrote:

On 09. 07. 19 19:28, Nishka Dasgupta wrote:

Each iteration of for_each_available_child_of_node puts the previous
node, but in the case of a goto from the middle of the loop, there is
no put, thus causing a memory leak. Hence add an of_node_put before the
goto.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 
---
   drivers/mailbox/zynqmp-ipi-mailbox.c | 1 +
   1 file changed, 1 insertion(+)

diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c
b/drivers/mailbox/zynqmp-ipi-mailbox.c
index 86887c9a349a..bd80d4c10ec2 100644
--- a/drivers/mailbox/zynqmp-ipi-mailbox.c
+++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
@@ -661,6 +661,7 @@ static int zynqmp_ipi_probe(struct
platform_device *pdev)
   if (ret) {
   dev_err(dev, "failed to probe subdev.\n");
   ret = -EINVAL;
+    of_node_put(nc);
   goto free_mbox_dev;
   }
   mbox++;



Patch is good but when you are saying that this was found by Coccinelle
then it should be added as script to kernel to detect it.


This particular patch was suggested by a script I did not write myself;
someone else wrote it and sent it to me. How should I proceed in this case?


You can ask him to submit it to kernel.
Or you can take it, keep his authorship and send it to:


I have asked her to submit this script, thank you. Will I need to 
resubmit this patch, however?


Regards,
Nishka


./scripts/get_maintainer.pl -f scripts/coccinelle/
Julia Lawall  (supporter:COCCINELLE/Semantic
Patches (SmPL))
Gilles Muller  (supporter:COCCINELLE/Semantic
Patches (SmPL))
Nicolas Palix  (supporter:COCCINELLE/Semantic
Patches (SmPL))
Michal Marek  (supporter:COCCINELLE/Semantic
Patches (SmPL))
co...@systeme.lip6.fr (moderated list:COCCINELLE/Semantic Patches (SmPL))
linux-kernel@vger.kernel.org (open list)

Thanks,
Michal





Re: [RFC PATCH 1/2] mmc: sdhci: Manually check card status after reset

2019-08-01 Thread Adrian Hunter
On 1/08/19 6:16 PM, Raul Rangel wrote:
> On Wed, Jun 19, 2019 at 08:56:25AM -0600, Raul Rangel wrote:
>> Your patch looks good. I tried it out and got over 57k insertion/removal
>> iterations. Do you want me to send out your patch, or do you want to do
>> it?
>>
>> Just to recap, the patch you proposed + the AMD SDHCI specific patch fix
>> the problem.
>>
> 
> Just pinging the thread again to see what you would prefer. I can send
> the patch with you in the Signed-off. Or if you would prefer to not
> update the sdhci driver at all, I can add the logic into the AMD
> specific patch.
> 
> I would like to get this in so it lands by 5.4.

You seem not to have answered to my suggestion for a change to sdhci_reinit() 
here:


https://lore.kernel.org/lkml/fcdf6cc4-2729-abe2-85c8-b0d04901c...@intel.com/



Re: linux kernel sources: more misspellings/tyops of iton words

2019-08-01 Thread Joe Perches
On Thu, 2019-08-01 at 21:23 -0700, Joe Perches wrote:
> If any feels like it, here are some more typos from:
> 
> $ git grep -P '\b\w+itons?' | grep -ohP '\b\w+itons?' | sort | uniq -c | sort 
> -rn
>   7 additon
>   6 definitons
>   5 Prediciton
>   5 instruciton
>   4 conditon
>   3 partititon
>   3 notificaiton
>   3 implementaiton
>   3 definiton
>   3 Additon
>   2 veriton
>   2 unconditon
>   2 poriton
>   2 parititon
>   2 initializaiton
>   2 defininitons
>   2 conneciton
>   2 configuraiton
>   1 translaiton
>   1 Transisitons
>   1 traditon
>   1 quesiton
>   1 positon
>   1 posiiton
>   1 partiton
>   1 moniton
>   1 inspeciton
>   1 infomraiton
>   1 implicaitons
>   1 identificaiton
>   1 generaiton
>   1 encrypiton
>   1 destinaiton
>   1 declariton
>   1 confirmaiton
>   1 Configuraiton
>   1 conditons
>   1 calculaiton
>   1 applicaiton
>   1 allocaiton
> 

Here is a treewide -U0 diff of today's -next if
anyone wants to expand it by maintainer/subsystem
or apply it directly
---
 Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt | 2 +-
 Documentation/networking/ila.txt   | 2 +-
 arch/arc/kernel/signal.c   | 2 +-
 arch/arc/mm/cache.c| 2 +-
 arch/arm/mach-s3c24xx/common-smdk.c| 2 +-
 arch/arm/mach-s3c24xx/common.c | 2 +-
 arch/arm/mach-tegra/platsmp.c  | 2 +-
 arch/arm64/include/asm/assembler.h | 2 +-
 arch/ia64/include/asm/sn/clksupport.h  | 2 +-
 arch/powerpc/include/asm/cpm1.h| 2 +-
 arch/powerpc/mm/init_64.c  | 2 +-
 arch/powerpc/platforms/cell/spufs/spu_restore_crt0.S   | 2 +-
 arch/sparc/kernel/traps_64.c   | 2 +-
 arch/x86/kvm/lapic.c   | 2 +-
 crypto/drbg.c  | 2 +-
 drivers/gpu/drm/amd/include/atombios.h | 2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/pptable_v1_0.h | 4 ++--
 drivers/gpu/drm/arm/malidp_hw.c| 2 +-
 drivers/gpu/drm/i915/intel_pm.c| 4 ++--
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c| 2 +-
 drivers/media/platform/mtk-vcodec/venc_drv_if.h| 2 +-
 drivers/media/platform/seco-cec/seco-cec.h | 2 +-
 drivers/message/fusion/lsi/mpi_ioc.h   | 2 +-
 drivers/misc/genwqe/card_ddcb.c| 2 +-
 drivers/misc/pti.c | 4 ++--
 drivers/misc/sgi-xp/xpc.h  | 2 +-
 drivers/misc/sgi-xp/xpc_sn2.c  | 2 +-
 drivers/mtd/spi-nor/spi-nor.c  | 2 +-
 drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c   | 2 +-
 drivers/net/ethernet/mellanox/mlxsw/spectrum2_kvdl.c   | 2 +-
 drivers/net/ethernet/qlogic/qed/qed_sriov.h| 2 +-
 drivers/net/wireless/ath/hw.c  | 2 +-
 drivers/net/wireless/ath/wcn36xx/hal.h | 2 +-
 drivers/nvme/host/fabrics.h| 2 +-
 drivers/scsi/aic7xxx/aic79xx.h | 2 +-
 drivers/scsi/aic7xxx/aic7xxx.h | 2 +-
 drivers/scsi/esp_scsi.c| 2 +-
 drivers/scsi/lpfc/lpfc_bsg.c   | 2 +-
 drivers/scsi/lpfc/lpfc_els.c   | 2 +-
 drivers/staging/fwserial/fwserial.c| 2 +-
 drivers/staging/rtl8188eu/core/rtw_xmit.c  | 2 +-
 drivers/staging/rtl8723bs/core/rtw_xmit.c  | 2 +-
 drivers/target/target_core_transport.c | 2 +-
 drivers/usb/gadget/udc/net2272.c   | 2 +-
 drivers/usb/misc/ldusb.c   | 2 +-
 drivers/usb/serial/io_usbvend.h| 2 +-
 drivers/video/fbdev/au1200fb.c | 2 +-
 drivers/video/fbdev/da8xx-fb.c | 2 +-
 include/linux/mfd/wm831x/regulator.h   | 2 +-
 include/linux/tracepoint.h | 2 +-
 include/rdma/rdma_vt.h | 2 +-
 mm/memory.c| 2 +-
 mm/percpu-internal.h   | 2 +-
 sound/core/pcm_native.c 

Re: linux-next: Tree for Jul 31 - s390 crypto build breakage

2019-08-01 Thread Stephen Rothwell
Hi Herbert,

On Fri, 2 Aug 2019 13:14:14 +1000 Herbert Xu  
wrote:
>
> For now I'm going to back out those two specific patches as the
> rest seem to be valid by themselves.

I have applied the top commit from your tree to linux-next today just
to help with building and testing over the weekend (I had already
merged your tree before you added the revert).

Thanks
-- 
Cheers,
Stephen Rothwell


pgpMA74jciiJk.pgp
Description: OpenPGP digital signature


Re: [PATCH v3] powerpc: Support CMDLINE_EXTEND

2019-08-01 Thread Christophe Leroy




Le 02/08/2019 à 00:50, Chris Packham a écrit :

Bring powerpc in line with other architectures that support extending or
overriding the bootloader provided command line.

The current behaviour is most like CMDLINE_FROM_BOOTLOADER where the
bootloader command line is preferred but the kernel config can provide a
fallback so CMDLINE_FROM_BOOTLOADER is the default. CMDLINE_EXTEND can
be used to append the CMDLINE from the kernel config to the one provided
by the bootloader.

Signed-off-by: Chris Packham 


Reviewed-by: Christophe Leroy 


---
Changes in v3:
- don't use BUG_ON in prom_strlcat
- rearrange things to eliminate prom_strlcpy

Changes in v2:
- incorporate ideas from Christope's patch 
https://patchwork.ozlabs.org/patch/1074126/
- support CMDLINE_FORCE

  arch/powerpc/Kconfig| 20 +-
  arch/powerpc/kernel/prom_init.c | 36 ++---
  2 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 77f6ebf97113..d413fe1b4058 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -852,15 +852,33 @@ config CMDLINE
  some command-line options at build time by entering them here.  In
  most cases you will need to specify the root device here.
  
+choice

+   prompt "Kernel command line type" if CMDLINE != ""
+   default CMDLINE_FROM_BOOTLOADER
+
+config CMDLINE_FROM_BOOTLOADER
+   bool "Use bootloader kernel arguments if available"
+   help
+ Uses the command-line options passed by the boot loader. If
+ the boot loader doesn't provide any, the default kernel command
+ string provided in CMDLINE will be used.
+
+config CMDLINE_EXTEND
+   bool "Extend bootloader kernel arguments"
+   help
+ The command-line arguments provided by the boot loader will be
+ appended to the default kernel command string.
+
  config CMDLINE_FORCE
bool "Always use the default kernel command string"
-   depends on CMDLINE_BOOL
help
  Always use the default kernel command string, even if the boot
  loader passes other arguments to the kernel.
  This is useful if you cannot or don't want to change the
  command-line options your boot loader passes to the kernel.
  
+endchoice

+
  config EXTRA_TARGETS
string "Additional default image types"
help
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 514707ef6779..1c7010cc6ec9 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -298,16 +298,24 @@ static char __init *prom_strstr(const char *s1, const 
char *s2)
return NULL;
  }
  
-static size_t __init prom_strlcpy(char *dest, const char *src, size_t size)

-{
-   size_t ret = prom_strlen(src);
+static size_t __init prom_strlcat(char *dest, const char *src, size_t count)
+{
+   size_t dsize = prom_strlen(dest);
+   size_t len = prom_strlen(src);
+   size_t res = dsize + len;
+
+   /* This would be a bug */
+   if (dsize >= count)
+   return count;
+
+   dest += dsize;
+   count -= dsize;
+   if (len >= count)
+   len = count-1;
+   memcpy(dest, src, len);
+   dest[len] = 0;
+   return res;
  
-	if (size) {

-   size_t len = (ret >= size) ? size - 1 : ret;
-   memcpy(dest, src, len);
-   dest[len] = '\0';
-   }
-   return ret;
  }
  
  #ifdef CONFIG_PPC_PSERIES

@@ -759,10 +767,14 @@ static void __init early_cmdline_parse(void)
  
  	prom_cmd_line[0] = 0;

p = prom_cmd_line;
-   if ((long)prom.chosen > 0)
+
+   if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && (long)prom.chosen > 0)
l = prom_getprop(prom.chosen, "bootargs", p, 
COMMAND_LINE_SIZE-1);
-   if (IS_ENABLED(CONFIG_CMDLINE_BOOL) && (l <= 0 || p[0] == '\0')) /* dbl 
check */
-   prom_strlcpy(prom_cmd_line, CONFIG_CMDLINE, 
sizeof(prom_cmd_line));
+
+   if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) || l <= 0 || p[0] == '\0')
+   prom_strlcat(prom_cmd_line, " " CONFIG_CMDLINE,
+sizeof(prom_cmd_line));
+
prom_printf("command line: %s\n", prom_cmd_line);
  
  #ifdef CONFIG_PPC64




Re: [PATCH v2] powerpc: Support CMDLINE_EXTEND

2019-08-01 Thread Christophe Leroy




Le 02/08/2019 à 00:32, Chris Packham a écrit :

On Thu, 2019-08-01 at 08:14 +0200, Christophe Leroy wrote:


Le 01/08/2019 à 04:12, Chris Packham a écrit :


Bring powerpc in line with other architectures that support
extending or
overriding the bootloader provided command line.

The current behaviour is most like CMDLINE_FROM_BOOTLOADER where
the
bootloader command line is preferred but the kernel config can
provide a
fallback so CMDLINE_FROM_BOOTLOADER is the default. CMDLINE_EXTEND
can
be used to append the CMDLINE from the kernel config to the one
provided
by the bootloader.

Signed-off-by: Chris Packham 
---
While I'm at it does anyone think it's worth getting rid of the
default CMDLINE
value if CMDLINE_BOOL and maybe CMDLINE_BOOL? Every defconfig in
the kernel
that sets CMDLINE_BOOL=y also sets CMDLINE to something other than
"console=ttyS0,9600 console=tty0 root=/dev/sda2". Removing
CMDLINE_BOOL and
unconditionally setting the default value of CMDLINE to "" would
clean up the
Kconfig even more.

Note
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co
mmit/?id=cbe46bd4f5104552b612505b73d366f66efc2341
which is already a step forward.

I guess that default is for users selecting this option manually to
get
a first sensitive CMDLINE. But is it really worth it ?



I'm not even sure if it is working as intended right now. Even without
my changes if I use menuconfig and select CMDLINE_BOOL I end up with
CONFIG_CMDLINE="" in the resulting .config.


I guess if the CONFIG_CMDLINE doesn't exist yet, it will get the default 
value. But if it is already there allthough empty, it will remain empty.
So yes I guess you could just drop it for this reason and the other 
reasons you said.


Christophe



Re: [PATCH v3] mailbox: imx: add support for imx v1 mu

2019-08-01 Thread Oleksij Rempel
On Fri, Aug 02, 2019 at 06:54:27AM +0300, Daniel Baluta wrote:
> One more thing. See below:
> 
> On Wed, Jul 31, 2019 at 12:14 PM Richard Zhu  wrote:
> 
> 
> 
> > -/* Control Register */
> > -#define IMX_MU_xCR 0x24
> >  /* General Purpose Interrupt Enable */
> >  #define IMX_MU_xCR_GIEn(x) BIT(28 + (3 - (x)))
> >  /* Receive Interrupt Enable */
> > @@ -44,6 +36,13 @@ enum imx_mu_chan_type {
> > IMX_MU_TYPE_RXDB,   /* Rx doorbell */
> >  };
> >
> > +struct imx_mu_dcfg {
> 
> Can you rename this into imx_mu_regs ?

I decided not blame this part. Otherwise adding other type of quirks
will lead to more refactoring work.

> > +   u32 xTR[4]; /* Transmit Registers */
> > +   u32 xRR[4]; /* Receive Registers */
> > +   u32 xSR;/* Status Register */
> > +   u32 xCR;/* Control Register */
> > +};
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


linux kernel sources: more misspellings/tyops of iton words

2019-08-01 Thread Joe Perches
If any feels like it, here are some more typos from:

$ git grep -P '\b\w+itons?' | grep -ohP '\b\w+itons?' | sort | uniq -c | sort 
-rn
  7 additon
  6 definitons
  5 Prediciton
  5 instruciton
  4 conditon
  3 partititon
  3 notificaiton
  3 implementaiton
  3 definiton
  3 Additon
  2 veriton
  2 unconditon
  2 poriton
  2 parititon
  2 initializaiton
  2 defininitons
  2 conneciton
  2 configuraiton
  1 translaiton
  1 Transisitons
  1 traditon
  1 quesiton
  1 positon
  1 posiiton
  1 partiton
  1 moniton
  1 inspeciton
  1 infomraiton
  1 implicaitons
  1 identificaiton
  1 generaiton
  1 encrypiton
  1 destinaiton
  1 declariton
  1 confirmaiton
  1 Configuraiton
  1 conditons
  1 calculaiton
  1 applicaiton
  1 allocaiton




Re: [PATCH v2] ARM: dts: aspeed: Add Facebook Wedge100 BMC

2019-08-01 Thread Joel Stanley
On Fri, 2 Aug 2019 at 04:10, Tao Ren  wrote:
>
> Add initial version of device tree for Facebook Wedge100 AST2400 BMC
> platform.
>
> Signed-off-by: Tao Ren 
> Reviewed-by: Andrew Jeffery 
> ---
>  Changes in v2:
>  - remove "debug" from bootargs.

Thanks. I applied wedge40 and then this one fails to apply due to
conflicts in the Makefile. Next time you have two patches, send them
as a series they apply one atop the other.

The naming of these two files suggests they come from a family. I
noticed there's very minor differences, a pca9548 switch and the use
of a watchdog.

Are these device trees complete? If yes, do you think it's worthwhile
to have a common wedge description in eg.
aspeed-bmc-facebook-wedge.dtsi, and put the unique description in
respective dts board files?

The upside of this is reduced duplication.

If you have a reason not to, then that is okay and we can leave it as
you submitted them.

Cheers,

Joel

--- arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts2019-08-02
13:44:26.536934502 +0930
+++ arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts2019-08-02
13:44:02.980670672 +0930
@@ -5,8 +5,8 @@
 #include "aspeed-g4.dtsi"

 / {
-model = "Facebook Wedge 100 BMC";
-compatible = "facebook,wedge100-bmc", "aspeed,ast2400";
+model = "Facebook Wedge 40 BMC";
+compatible = "facebook,wedge40-bmc", "aspeed,ast2400";

 aliases {
 /*
@@ -35,8 +35,7 @@
 };

  {
-status = "okay";
-aspeed,reset-type = "system";
+status = "disabled";
 };

  {
@@ -111,13 +110,6 @@

  {
 status = "okay";
-
-i2c-switch@70 {
-compatible = "nxp,pca9548";
-#address-cells = <1>;
-#size-cells = <0>;
-reg = <0x70>;
-};
 };

>
>  arch/arm/boot/dts/Makefile|   1 +
>  .../boot/dts/aspeed-bmc-facebook-wedge100.dts | 149 ++
>  2 files changed, 150 insertions(+)
>  create mode 100644 arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 39a05a10a2a2..d71504ed82d3 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1273,6 +1273,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
> aspeed-bmc-facebook-cmm.dtb \
> aspeed-bmc-facebook-minipack.dtb \
> aspeed-bmc-facebook-tiogapass.dtb \
> +   aspeed-bmc-facebook-wedge100.dtb \
> aspeed-bmc-facebook-yamp.dtb \
> aspeed-bmc-intel-s2600wf.dtb \
> aspeed-bmc-inspur-fp5280g2.dtb \
> diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts 
> b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts
> new file mode 100644
> index ..b1e10f0c85c9
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright (c) 2018 Facebook Inc.
> +/dts-v1/;
> +
> +#include "aspeed-g4.dtsi"
> +
> +/ {
> +   model = "Facebook Wedge 100 BMC";
> +   compatible = "facebook,wedge100-bmc", "aspeed,ast2400";
> +
> +   aliases {
> +   /*
> +* Override the default uart aliases to avoid breaking
> +* the legacy applications.
> +*/
> +   serial0 = 
> +   serial1 = 
> +   serial2 = 
> +   serial3 = 
> +   };
> +
> +   chosen {
> +   stdout-path = 
> +   bootargs = "console=ttyS2,9600n8 root=/dev/ram rw";
> +   };
> +
> +   memory@4000 {
> +   reg = <0x4000 0x2000>;
> +   };
> +};
> +
> + {
> +   status = "okay";
> +   aspeed,reset-type = "system";
> +};
> +
> + {
> +   status = "okay";
> +   aspeed,reset-type = "system";
> +};
> +
> + {
> +   status = "okay";
> +   flash@0 {
> +   status = "okay";
> +   m25p,fast-read;
> +   label = "fmc0";
> +#include "facebook-bmc-flash-layout.dtsi"
> +   };
> +};
> +
> + {
> +   status = "okay";
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_txd1_default
> +_rxd1_default>;
> +};
> +
> + {
> +   status = "okay";
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_txd3_default
> +_rxd3_default>;
> +};
> +
> + {
> +   status = "okay";
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_txd4_default
> +_rxd4_default>;
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +   no-hw-checksum;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_rgmii2_default _mdio2_default>;
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +
> +   

[PATCH v2 2/2] pinctrl: qcom: Add SC7180 pinctrl driver

2019-08-01 Thread Rajendra Nayak
From: Jitendra Sharma 

Add initial pinctrl driver to support pin configuration with
pinctrl framework for SC7180

Signed-off-by: Jitendra Sharma 
Signed-off-by: Vivek Gautam 
[rnayak: modify to use upstream tile support
 sort and squash some functions]
Signed-off-by: Rajendra Nayak 
Reviewed-by: Bjorn Andersson 
---
 drivers/pinctrl/qcom/Kconfig  |9 +
 drivers/pinctrl/qcom/Makefile |1 +
 drivers/pinctrl/qcom/pinctrl-sc7180.c | 1146 +
 3 files changed, 1156 insertions(+)
 create mode 100644 drivers/pinctrl/qcom/pinctrl-sc7180.c

diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index 8e14a5f2e970..af44dafc35e7 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -158,6 +158,15 @@ config PINCTRL_QCOM_SSBI_PMIC
  which are using SSBI for communication with SoC. Example PMIC's
  devices are pm8058 and pm8921.
 
+config PINCTRL_SC7180
+   tristate "Qualcomm Technologies Inc SC7180 pin controller driver"
+   depends on GPIOLIB && OF
+   select PINCTRL_MSM
+   help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm Technologies Inc TLMM block found on the Qualcomm
+ Technologies Inc SC7180 platform.
+
 config PINCTRL_SDM660
tristate "Qualcomm Technologies Inc SDM660 pin controller driver"
depends on GPIOLIB && OF
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index ebe906872272..f8bb0c265381 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PINCTRL_QCOM_SPMI_PMIC) += pinctrl-spmi-gpio.o
 obj-$(CONFIG_PINCTRL_QCOM_SPMI_PMIC) += pinctrl-spmi-mpp.o
 obj-$(CONFIG_PINCTRL_QCOM_SSBI_PMIC) += pinctrl-ssbi-gpio.o
 obj-$(CONFIG_PINCTRL_QCOM_SSBI_PMIC) += pinctrl-ssbi-mpp.o
+obj-$(CONFIG_PINCTRL_SC7180)   += pinctrl-sc7180.o
 obj-$(CONFIG_PINCTRL_SDM660)   += pinctrl-sdm660.o
 obj-$(CONFIG_PINCTRL_SDM845) += pinctrl-sdm845.o
 obj-$(CONFIG_PINCTRL_SM8150) += pinctrl-sm8150.o
diff --git a/drivers/pinctrl/qcom/pinctrl-sc7180.c 
b/drivers/pinctrl/qcom/pinctrl-sc7180.c
new file mode 100644
index ..6399c8a2bc22
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-sc7180.c
@@ -0,0 +1,1146 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2019, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-msm.h"
+
+static const char * const sc7180_tiles[] = {
+   "north",
+   "south",
+   "west",
+};
+
+enum {
+   NORTH,
+   SOUTH,
+   WEST
+};
+
+#define FUNCTION(fname)\
+   [msm_mux_##fname] = {   \
+   .name = #fname, \
+   .groups = fname##_groups,   \
+   .ngroups = ARRAY_SIZE(fname##_groups),  \
+   }
+
+#define PINGROUP(id, _tile, f1, f2, f3, f4, f5, f6, f7, f8, f9)\
+   {   \
+   .name = "gpio" #id, \
+   .pins = gpio##id##_pins,\
+   .npins = ARRAY_SIZE(gpio##id##_pins),   \
+   .funcs = (int[]){   \
+   msm_mux_gpio, /* gpio mode */   \
+   msm_mux_##f1,   \
+   msm_mux_##f2,   \
+   msm_mux_##f3,   \
+   msm_mux_##f4,   \
+   msm_mux_##f5,   \
+   msm_mux_##f6,   \
+   msm_mux_##f7,   \
+   msm_mux_##f8,   \
+   msm_mux_##f9\
+   },  \
+   .nfuncs = 10,   \
+   .ctl_reg = 0x1000 * id, \
+   .io_reg = 0x1000 * id + 0x4,\
+   .intr_cfg_reg = 0x1000 * id + 0x8,  \
+   .intr_status_reg = 0x1000 * id + 0xc,   \
+   .intr_target_reg = 0x1000 * id + 0x8,   \
+   .tile = _tile,  \
+   .mux_bit = 2,   \
+   .pull_bit = 0,  \
+   .drv_bit = 6,   \
+   .oe_bit = 9,\
+   .in_bit = 0,\
+   .out_bit = 1,   \
+   .intr_enable_bit = 0,   \
+   .intr_status_bit = 0,   \
+   .intr_target_bit = 5,   \
+   .intr_target_kpss_val = 3,  \
+   .intr_raw_status_bit = 4,   \
+   .intr_polarity_bit = 1, \
+   .intr_detection_bit = 2,\
+   

Re: [PATCH v4] watchdog: alim1535: Rewriting of alim1535 to use watchdog subsystem

2019-08-01 Thread Mark Balantzyan
There was some sort of filesystem error that cause the wrong file to be 
saved. Hence, yes, possibly there was no difference betwee the v2 and the 
'v4' (which should have been the 'v3'). Since the last one, though 
unchanged from v2, was a changelog-less 'v3', THIS is an actual 'v4'.


Thank you,
Mark



[PATCH v2 1/2] dt-bindings: pinctrl: qcom: Add SC7180 pinctrl binding

2019-08-01 Thread Rajendra Nayak
From: Jitendra Sharma 

Add the binding for the TLMM pinctrl block found in the SC7180 platform

Signed-off-by: Jitendra Sharma 
Signed-off-by: Vivek Gautam 
[rnayak: Fix some copy-paste issues, sort and fix functions]
Signed-off-by: Rajendra Nayak 
Reviewed-by: Bjorn Andersson 
---
 .../bindings/pinctrl/qcom,sc7180-pinctrl.txt  | 186 ++
 1 file changed, 186 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.txt
new file mode 100644
index ..948cd56cfab7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7180-pinctrl.txt
@@ -0,0 +1,186 @@
+Qualcomm Technologies, Inc. SC7180 TLMM block
+
+This binding describes the Top Level Mode Multiplexer block found in the
+SC7180 platform.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be "qcom,sc7180-pinctrl"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: the base address and size of the north, south and west
+   TLMM tiles
+
+- reg-names:
+   Usage: required
+   Value type: 
+   Defintiion: names for the cells of reg, must contain "north", "south"
+   and "west".
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: should specify the TLMM summary IRQ.
+
+- interrupt-controller:
+   Usage: required
+   Value type: 
+   Definition: identifies this node as an interrupt controller
+
+- #interrupt-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 2. Specifying the pin number and flags, as defined
+   in 
+
+- gpio-controller:
+   Usage: required
+   Value type: 
+   Definition: identifies this node as a gpio controller
+
+- #gpio-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 2. Specifying the pin number and flags, as defined
+   in 
+
+- gpio-ranges:
+   Usage: required
+   Value type: 
+   Definition:  see ../gpio/gpio.txt
+
+- gpio-reserved-ranges:
+   Usage: optional
+   Value type: 
+   Definition: see ../gpio/gpio.txt
+
+Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
+a general description of GPIO and interrupt bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+The pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, drive strength, etc.
+
+
+PIN CONFIGURATION NODES:
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function.
+
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pin configuration subnode:
+
+- pins:
+   Usage: required
+   Value type: 
+   Definition: List of gpio pins affected by the properties specified in
+   this subnode.
+
+   Valid pins are:
+ gpio0-gpio118
+   Supports mux, bias and drive-strength
+
+ sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd,
+ sdc2_data sdc1_rclk
+   Supports bias and drive-strength
+
+ ufs_reset
+   Supports bias and drive-strength
+
+- function:
+   Usage: required
+   Value type: 
+   Definition: Specify the alternative function to be configured for the
+   specified pins. Functions are only valid for gpio pins.
+   Valid values are:
+
+   adsp_ext, agera_pll, aoss_cti, atest_char, atest_char0,
+   atest_char1, atest_char2, atest_char3, atest_tsens,
+   atest_tsens2, atest_usb1, atest_usb10, atest_usb11,
+   atest_usb12, atest_usb13, atest_usb2, atest_usb20,
+   atest_usb21, atest_usb22, atest_usb23, audio_ref,
+   btfm_slimbus, cam_mclk, cci_async, cci_i2c, cci_timer0,
+   cci_timer1, cci_timer2, cci_timer3, cci_timer4,
+   cri_trng, dbg_out, 

[PATCH v4] watchdog: alim1535: Rewriting of alim1535 driver to use watchdog subsystem

2019-08-01 Thread Mark Balantzyan
This patch rewrites the alim1535_wdt driver to use the watchdog subsystem.
By virtue of this, it also fixes a (theoretical) race condition between the
formerly arranged ali_timeout_bits and ali_settimer() interoperation.

Signed-off-by: Mark Balantzyan 

---
 drivers/watchdog/Kconfig|   1 +
 drivers/watchdog/alim1535_wdt.c | 294 ++--
 2 files changed, 50 insertions(+), 245 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9af07fd9..980b0c90 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -853,6 +853,7 @@ config ADVANTECH_WDT
 
 config ALIM1535_WDT
tristate "ALi M1535 PMU Watchdog Timer"
+   select WATCHDOG_CORE
depends on X86 && PCI
---help---
  This is the driver for the hardware watchdog on the ALi M1535 PMU.
diff --git a/drivers/watchdog/alim1535_wdt.c b/drivers/watchdog/alim1535_wdt.c
index 60f0c2eb..747ba12c 100644
--- a/drivers/watchdog/alim1535_wdt.c
+++ b/drivers/watchdog/alim1535_wdt.c
@@ -12,29 +12,20 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
 
 #define WATCHDOG_NAME "ALi_M1535"
 #define WATCHDOG_TIMEOUT 60/* 60 sec default timeout */
 
 /* internal variables */
-static unsigned long ali_is_open;
-static char ali_expect_release;
 static struct pci_dev *ali_pci;
 static u32 ali_timeout_bits;   /* stores the computed timeout */
 static DEFINE_SPINLOCK(ali_lock);  /* Guards the hardware */
 
 /* module parameters */
-static int timeout = WATCHDOG_TIMEOUT;
+static int timeout;
 module_param(timeout, int, 0);
 MODULE_PARM_DESC(timeout,
"Watchdog timeout in seconds. (0 < timeout < 18000, default="
@@ -53,18 +44,15 @@ MODULE_PARM_DESC(nowayout,
  * configuration set.
  */
 
-static void ali_start(void)
+static int ali_start(struct watchdog_device *wdd)
 {
u32 val;
 
-   spin_lock(_lock);
-
pci_read_config_dword(ali_pci, 0xCC, );
val &= ~0x3F;   /* Mask count */
val |= (1 << 25) | ali_timeout_bits;
pci_write_config_dword(ali_pci, 0xCC, val);
-
-   spin_unlock(_lock);
+   return 0;
 }
 
 /*
@@ -73,225 +61,53 @@ static void ali_start(void)
  * Stop the ALi watchdog countdown
  */
 
-static void ali_stop(void)
+static int ali_stop(struct watchdog_device *wdd)
 {
u32 val;
 
-   spin_lock(_lock);
-
pci_read_config_dword(ali_pci, 0xCC, );
val &= ~0x3F;   /* Mask count to zero (disabled) */
val &= ~(1 << 25);  /* and for safety mask the reset enable */
pci_write_config_dword(ali_pci, 0xCC, val);
-
-   spin_unlock(_lock);
-}
-
-/*
- * ali_keepalive   -   send a keepalive to the watchdog
- *
- * Send a keepalive to the timer (actually we restart the timer).
- */
-
-static void ali_keepalive(void)
-{
-   ali_start();
+   return 0;
 }
 
 /*
- * ali_settimer-   compute the timer reload value
+ * ali_set_timeout -   compute the timer reload value
  * @t: time in seconds
  *
  * Computes the timeout values needed
  */
 
-static int ali_settimer(int t)
+static int ali_set_timeout(struct watchdog_device *wdd, unsigned int t)
 {
-   if (t < 0)
-   return -EINVAL;
-   else if (t < 60)
-   ali_timeout_bits = t|(1 << 6);
-   else if (t < 3600)
-   ali_timeout_bits = (t / 60)|(1 << 7);
-   else if (t < 18000)
-   ali_timeout_bits = (t / 300)|(1 << 6)|(1 << 7);
-   else
+   spin_lock(_lock);
+   if (t < 0) {
+   spin_unlock(_lock);
return -EINVAL;
-
-   timeout = t;
-   return 0;
-}
-
-/*
- * /dev/watchdog handling
- */
-
-/*
- * ali_write   -   writes to ALi watchdog
- * @file: file from VFS
- * @data: user address of data
- * @len: length of data
- * @ppos: pointer to the file offset
- *
- * Handle a write to the ALi watchdog. Writing to the file pings
- * the watchdog and resets it. Writing the magic 'V' sequence allows
- * the next close to turn off the watchdog.
- */
-
-static ssize_t ali_write(struct file *file, const char __user *data,
-   size_t len, loff_t *ppos)
-{
-   /* See if we got the magic character 'V' and reload the timer */
-   if (len) {
-   if (!nowayout) {
-   size_t i;
-
-   /* note: just in case someone wrote the
-  magic character five months ago... */
-   ali_expect_release = 0;
-
-   /* scan to see whether or not we got
-  the magic character */
-   for (i = 0; i != len; i++) {
-   char c;
-   if (get_user(c, data + i))
-

[PATCH v2] ARM: dts: aspeed: Add Facebook Wedge100 BMC

2019-08-01 Thread Tao Ren
Add initial version of device tree for Facebook Wedge100 AST2400 BMC
platform.

Signed-off-by: Tao Ren 
Reviewed-by: Andrew Jeffery 
---
 Changes in v2:
 - remove "debug" from bootargs.

 arch/arm/boot/dts/Makefile|   1 +
 .../boot/dts/aspeed-bmc-facebook-wedge100.dts | 149 ++
 2 files changed, 150 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 39a05a10a2a2..d71504ed82d3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1273,6 +1273,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-facebook-cmm.dtb \
aspeed-bmc-facebook-minipack.dtb \
aspeed-bmc-facebook-tiogapass.dtb \
+   aspeed-bmc-facebook-wedge100.dtb \
aspeed-bmc-facebook-yamp.dtb \
aspeed-bmc-intel-s2600wf.dtb \
aspeed-bmc-inspur-fp5280g2.dtb \
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts 
b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts
new file mode 100644
index ..b1e10f0c85c9
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2018 Facebook Inc.
+/dts-v1/;
+
+#include "aspeed-g4.dtsi"
+
+/ {
+   model = "Facebook Wedge 100 BMC";
+   compatible = "facebook,wedge100-bmc", "aspeed,ast2400";
+
+   aliases {
+   /*
+* Override the default uart aliases to avoid breaking
+* the legacy applications.
+*/
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   };
+
+   chosen {
+   stdout-path = 
+   bootargs = "console=ttyS2,9600n8 root=/dev/ram rw";
+   };
+
+   memory@4000 {
+   reg = <0x4000 0x2000>;
+   };
+};
+
+ {
+   status = "okay";
+   aspeed,reset-type = "system";
+};
+
+ {
+   status = "okay";
+   aspeed,reset-type = "system";
+};
+
+ {
+   status = "okay";
+   flash@0 {
+   status = "okay";
+   m25p,fast-read;
+   label = "fmc0";
+#include "facebook-bmc-flash-layout.dtsi"
+   };
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_txd1_default
+_rxd1_default>;
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_txd3_default
+_rxd3_default>;
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_txd4_default
+_rxd4_default>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   no-hw-checksum;
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii2_default _mdio2_default>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   i2c-switch@70 {
+   compatible = "nxp,pca9548";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x70>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
2.17.1



[PATCH v2] ARM: dts: aspeed: Add Facebook Wedge40 BMC

2019-08-01 Thread Tao Ren
Add initial version of device tree for Facebook Wedge40 AST2400 BMC
platform.

Signed-off-by: Tao Ren 
Reviewed-by: Andrew Jeffery 
---
 Changes in v2:
 - remove "debug" from bootargs.

 arch/arm/boot/dts/Makefile|   1 +
 .../boot/dts/aspeed-bmc-facebook-wedge40.dts  | 141 ++
 2 files changed, 142 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 39a05a10a2a2..dfc1011eb3f2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1273,6 +1273,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-facebook-cmm.dtb \
aspeed-bmc-facebook-minipack.dtb \
aspeed-bmc-facebook-tiogapass.dtb \
+   aspeed-bmc-facebook-wedge40.dtb \
aspeed-bmc-facebook-yamp.dtb \
aspeed-bmc-intel-s2600wf.dtb \
aspeed-bmc-inspur-fp5280g2.dtb \
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts 
b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts
new file mode 100644
index ..aaa77a597d1a
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2018 Facebook Inc.
+/dts-v1/;
+
+#include "aspeed-g4.dtsi"
+
+/ {
+   model = "Facebook Wedge 40 BMC";
+   compatible = "facebook,wedge40-bmc", "aspeed,ast2400";
+
+   aliases {
+   /*
+* Override the default uart aliases to avoid breaking
+* the legacy applications.
+*/
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   };
+
+   chosen {
+   stdout-path = 
+   bootargs = "console=ttyS2,9600n8 root=/dev/ram rw";
+   };
+
+   memory@4000 {
+   reg = <0x4000 0x2000>;
+   };
+};
+
+ {
+   status = "okay";
+   aspeed,reset-type = "system";
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   status = "okay";
+   flash@0 {
+   status = "okay";
+   m25p,fast-read;
+   label = "fmc0";
+#include "facebook-bmc-flash-layout.dtsi"
+   };
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_txd1_default
+_rxd1_default>;
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_txd3_default
+_rxd3_default>;
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_txd4_default
+_rxd4_default>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   no-hw-checksum;
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii2_default _mdio2_default>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
2.17.1



Re: [PATCH v2] tracing: Function stack size and its name mismatch in arm64

2019-08-01 Thread Jiping Ma




On 2019年08月01日 17:41, Will Deacon wrote:

On Thu, Aug 01, 2019 at 04:33:40PM +0800, Jiping Ma wrote:

In arm64, the PC of the frame is matched to the last frame function,
rather than the function of his frame. For the following example, the
stack size of occupy_stack_init function should be 3376, rather than 176.

Wrong info:
Depth Size Location (16 entries)
-  
0) 5400 16 __update_load_avg_se.isra.2+0x28/0x220
1) 5384 96 put_prev_entity+0x250/0x338
2) 5288 80 pick_next_task_fair+0x4c4/0x508
3) 5208 72 __schedule+0x100/0x600
4) 5136 184 preempt_schedule_common+0x28/0x48
5) 4952 32 preempt_schedule+0x28/0x30
6) 4920 16 vprintk_emit+0x170/0x1f8
7) 4904 128 vprintk_default+0x48/0x58
8) 4776 64 vprintk_func+0xf8/0x1c8
9) 4712 112 printk+0x70/0x90
10) 4600 176 occupy_stack_init+0x64/0xc0 [kernel_stack]
11) 4424 3376 do_one_initcall+0x68/0x248
12) 1048 144 do_init_module+0x60/0x1f0
13) 904 48 load_module+0x1d50/0x2340
14) 856 352 sys_finit_module+0xd0/0xe8
15) 504 504 el0_svc_naked+0x30/0x34

Correct info:
Depth Size Location (18 entries)
-  
0) 5464 48 cgroup_rstat_updated+0x20/0x100
1) 5416 32 cgroup_base_stat_cputime_account_end.isra.0+0x30/0x60
2) 5384 32 __cgroup_account_cputime+0x3c/0x48
3) 5352 64 update_curr+0xc4/0x1d0
4) 5288 72 pick_next_task_fair+0x444/0x508
5) 5216 184 __schedule+0x100/0x600
6) 5032 32 preempt_schedule_common+0x28/0x48
7) 5000 16 preempt_schedule+0x28/0x30
8) 4984 128 vprintk_emit+0x170/0x1f8
9) 4856 64 vprintk_default+0x48/0x58
10) 4792 112 vprintk_func+0xf8/0x1c8
11) 4680 176 printk+0x70/0x90
12) 4504 80 func_test+0x7c/0xb8 [kernel_stack]
13) 4424 3376 occupy_stack_init+0x7c/0xc0 [kernel_stack]
14) 1048 144 do_one_initcall+0x68/0x248
15) 904 48 do_init_module+0x60/0x1f0
16) 856 352 load_module+0x1d50/0x2340
17) 504 504 sys_finit_module+0xd0/0xe8

Signed-off-by: Jiping Ma 
---
  kernel/trace/trace_stack.c | 28 ++--
  1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
index 5d16f73898db..ed80b95abf06 100644
--- a/kernel/trace/trace_stack.c
+++ b/kernel/trace/trace_stack.c
@@ -40,16 +40,28 @@ static void print_max_stack(void)
  
  	pr_emerg("DepthSize   Location(%d entries)\n"

   "-   \n",
+#ifdef CONFIG_ARM64
+  stack_trace_nr_entries - 1);
+#else
   stack_trace_nr_entries);

Sorry, but I have no idea what the problem is here. All I know is that the
solution looks highly dubious and I find it very hard to believe that the
arm64 backtracing code is uniquely special as to deserve being called out
like this. I suspect there's a bug lurking somewhere, but you really need
to do a better job of explaining the issue rather than simply providing a
couple of backtraces with no context.

*Why* does the frame appear to be off-by-one?
Because the PC is LR in ARM64 stack actually.  Following is ARM64 stack 
layout. Please refer to the figure 3 in 
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf

            LR
            FP
    ..
    LR
            FP
Jiping


Will




Re: [RFC PATCH 05/16] RISC-V: KVM: Implement VCPU interrupts and requests handling

2019-08-01 Thread Anup Patel
On Tue, Jul 30, 2019 at 7:38 PM Paolo Bonzini  wrote:
>
> On 30/07/19 15:35, Anup Patel wrote:
> > On Tue, Jul 30, 2019 at 6:48 PM Paolo Bonzini  wrote:
> >>
> >> On 30/07/19 14:45, Anup Patel wrote:
> >>> Here's some text from RISC-V spec regarding SIP CSR:
> >>> "software interrupt-pending (SSIP) bit in the sip register. A pending
> >>> supervisor-level software interrupt can be cleared by writing 0 to the 
> >>> SSIP bit
> >>> in sip. Supervisor-level software interrupts are disabled when the SSIE 
> >>> bit in
> >>> the sie register is clear."
> >>>
> >>> Without RISC-V hypervisor extension, the SIP is essentially a restricted
> >>> view of MIP CSR. Also as-per above, S-mode SW can only write 0 to SSIP
> >>> bit in SIP CSR whereas it can only be set by M-mode SW or some HW
> >>> mechanism (such as S-mode CLINT).
> >>
> >> But that's not what the spec says.  It just says (just before the
> >> sentence you quoted):
> >>
> >>A supervisor-level software interrupt is triggered on the current
> >>hart by writing 1 to its supervisor software interrupt-pending (SSIP)
> >>bit in the sip register.
> >
> > Unfortunately, this statement does not state who is allowed to write 1
> > in SIP.SSIP bit.
>
> If it doesn't state who is allowed to write 1, whoever has access to sip
> can.
>
> > I quoted MIP CSR documentation to highlight the fact that only M-mode
> > SW can set SSIP bit.
> >
> > In fact, I had same understanding as you have regarding SSIP bit
> > until we had MSIP issue in OpenSBI.
> > (https://github.com/riscv/opensbi/issues/128)
> >
> >> and it's not written anywhere that S-mode SW cannot write 1.  In fact
> >> that text is even under sip, not under mip, so IMO there's no doubt that
> >> S-mode SW _can_ write 1, and the hypervisor must operate accordingly.
> >
> > Without hypervisor support, SIP CSR is nothing but a restricted view of
> > MIP CSR thats why MIP CSR documentation applies here.
>
> But the privileged spec says mip.MSIP is read-only, it cannot be cleared
> (as in the above OpenSBI issue).  So mip.MSIP and sip.SSIP are already
> different in that respect, and I don't see how the spec says that S-mode
> SW cannot set sip.SSIP.
>
> (As an aside, why would M-mode even bother using sip and not mip to
> write 1 to SSIP?).
>
> > I think this discussion deserves a Github issue on RISC-V ISA manual.
>
> Perhaps, but I think it makes more sense this way.  The question remains
> of why M-mode is not allowed to write to MSIP/MEIP/MTIP.  My guess is
> that then MSIP/MEIP/MTIP are simply a read-only view of an external pin,
> so it simplifies hardware a tiny bit by forcing acks to go through the
> MMIO registers.
>
> > If my interpretation is incorrect then it would be really strange that
> > HART in S-mode SW can inject IPI to itself by writing 1 to SIP.SSIP bit.
>
> Well, it can be useful, for example Windows does it when interrupt
> handlers want to schedule some work to happen out of interrupt context.
>  Going through SBI would be unpleasant if it causes an HS-mode trap.

Another way of artificially injecting interrupt would be using interrupt
controller, where Windows can just write to some pending register of
interrupt controller.

I have raised a new Github issue on GitHub for clarity on this. You can
add your comments to this issue as well.
https://github.com/riscv/riscv-isa-manual/issues/425

Also, I have raised a proposal to support mechanism for external entity
(such as PLICv2 with virtualization support) to inject virtual interrupts.
https://github.com/riscv/riscv-isa-manual/issues/429

Regards,
Anup


Re: [PATCH] ARM: dts: aspeed: Add Facebook Wedge40 BMC

2019-08-01 Thread Tao Ren
On 8/1/19, 7:56 PM, "Andrew Jeffery"  wrote:

>On Fri, 2 Aug 2019, at 10:24, Tao Ren wrote: 
>> Add initial version of device tree for Facebook Wedge40 AST2400 BMC
>> platform.
>> 
>> Signed-off-by: Tao Ren 
>  
>  Reviewed-by: Andrew Jeffery 

Thank you Andrew for the quick review (on both patches)!

Cheers,

Tao
 



Re: [PATCH] ARM: dts: aspeed: Add Facebook Wedge100 BMC

2019-08-01 Thread Tao Ren
On 8/1/19, 8:02 PM, "Joel Stanley"  wrote:

>  On Fri, 2 Aug 2019 at 01:02, Tao Ren  wrote:
>> +
>> +   chosen {
>> +   stdout-path = 
>> +   bootargs = "debug console=ttyS2,9600n8 root=/dev/ram rw";
>  
>  Are you sure you want 'debug' in your boot arguments?
> 
> The rest lgtm. I can remove debug when applying, or leave it there if
> it was intentional.

Ahh, I copied bootargs from "/proc/cmdline" on my machine (running old kernel) 
but I don't think I need it.

Thank you for pointing it out. Let me send out v2 patches in a few minutes (so 
you could apply without extra changes).


Cheers,

Tao




Re: [PATCH v3] mailbox: imx: add support for imx v1 mu

2019-08-01 Thread Daniel Baluta
One more thing. See below:

On Wed, Jul 31, 2019 at 12:14 PM Richard Zhu  wrote:



> -/* Control Register */
> -#define IMX_MU_xCR 0x24
>  /* General Purpose Interrupt Enable */
>  #define IMX_MU_xCR_GIEn(x) BIT(28 + (3 - (x)))
>  /* Receive Interrupt Enable */
> @@ -44,6 +36,13 @@ enum imx_mu_chan_type {
> IMX_MU_TYPE_RXDB,   /* Rx doorbell */
>  };
>
> +struct imx_mu_dcfg {

Can you rename this into imx_mu_regs ?

> +   u32 xTR[4]; /* Transmit Registers */
> +   u32 xRR[4]; /* Receive Registers */
> +   u32 xSR;/* Status Register */
> +   u32 xCR;/* Control Register */
> +};


Re: [PATCH] cpufreq: schedutil: Don't skip freq update when limits change

2019-08-01 Thread Viresh Kumar
On 01-08-19, 10:57, Doug Smythies wrote:
> On 2019.07.31 23:17 Viresh Kumar wrote:
> > On 31-07-19, 17:20, Doug Smythies wrote:
> >> Summary:
> >> 
> >> The old way, using UINT_MAX had two purposes: first,
> >> as a "need to do a frequency update" flag; but also second, to
> >> force any subsequent old/new frequency comparison to NOT be "the same,
> >> so why bother actually updating" (see: sugov_update_next_freq). All
> >> patches so far have been dealing with the flag, but only partially
> >> the comparisons. In a busy system, and when schedutil.c doesn't actually
> >> know the currently set system limits, the new frequency is dominated by
> >> values the same as the old frequency. So, when sugov_fast_switch calls 
> >> sugov_update_next_freq, false is usually returned.
> >
> > And finally we know "Why" :)
> >
> > Good work Doug. Thanks for taking it to the end.
> >
> >> However, if we move the resetting of the flag and add another condition
> >> to the "no need to actually update" decision, then perhaps this patch
> >> version 1 will be O.K. It seems to be. (see way later in this e-mail).
> >
> >> With all this new knowledge, how about going back to
> >> version 1 of this patch, and then adding this:
> >> 
> >> diff --git a/kernel/sched/cpufreq_schedutil.c 
> >> b/kernel/sched/cpufreq_schedutil.c
> >> index 808d32b..f9156db 100644
> >> --- a/kernel/sched/cpufreq_schedutil.c
> >> +++ b/kernel/sched/cpufreq_schedutil.c
> >> @@ -100,7 +100,12 @@ static bool sugov_should_update_freq(struct 
> >> sugov_policy *sg_policy, u64 time)
> >>  static bool sugov_update_next_freq(struct sugov_policy *sg_policy, u64 
> >> time,
> >>unsigned int next_freq)
> >>  {
> >> -   if (sg_policy->next_freq == next_freq)
> >> +   /*
> >> +* Always force an update if the flag is set, regardless.
> >> +* In some implementations (intel_cpufreq) the frequency is clamped
> >> +* further downstream, and might not actually be different here.
> >> +*/
> >> +   if (sg_policy->next_freq == next_freq && 
> >> !sg_policy->need_freq_update)
> >> return false;
> >
> > This is not correct because this is an optimization we have in place
> > to make things more efficient. And it was working by luck earlier and
> > my patch broke it for good :)
> 
> Disagree.
> All I did was use a flag where it used to be set to UNIT_MAX, to basically
> implement the same thing.

And the earlier code wasn't fully correct as well, that's why we tried
to fix it earlier. So introducing the UINT_MAX thing again would be
wrong, even if it fixes the problem for you.

Also this won't fix the issue for rest of the governors but just
schedutil. Because this is a driver only problem and there is no point
trying to fix that in a governor.

> > Things need to get a bit more synchronized and something like this may
> > help (completely untested):
> >
> > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> > index cc27d4c59dca..2d84361fbebc 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -2314,6 +2314,18 @@ static int intel_cpufreq_target(struct 
> > cpufreq_policy *policy,
> >return 0;
> > }
> > 
> > +static unsigned int intel_cpufreq_resolve_freq(struct cpufreq_policy 
> > *policy,
> > +  unsigned int target_freq)
> > +{
> > +   struct cpudata *cpu = all_cpu_data[policy->cpu];
> > +   int target_pstate;
> > +
> > +   target_pstate = DIV_ROUND_UP(target_freq, cpu->pstate.scaling);
> > +   target_pstate = intel_pstate_prepare_request(cpu, target_pstate);
> > +
> > +   return target_pstate * cpu->pstate.scaling;
> > +}
> > +
> >  static unsigned int intel_cpufreq_fast_switch(struct cpufreq_policy 
> > *policy,
> >   unsigned int target_freq)
> >  {
> > @@ -2350,6 +2362,7 @@ static struct cpufreq_driver intel_cpufreq = {
> > .verify = intel_cpufreq_verify_policy,
> > .target = intel_cpufreq_target,
> > .fast_switch= intel_cpufreq_fast_switch,
> > +   .resolve_freq   = intel_cpufreq_resolve_freq,
> > .init   = intel_cpufreq_cpu_init,
> > .exit   = intel_pstate_cpu_exit,
> > .stop_cpu   = intel_cpufreq_stop_cpu,
> > 
> > -8<-
> >
> > Please try this with my patch 2.
> 
> O.K.
> 
> > We need patch 2 instead of 1 because
> > of another race condition Rafael noticed.
> 
> Disagree.
> Notice that my modifications to your patch1 addresses
> that condition by moving the clearing of "need_freq_update"
> to sometime later.

As I said above, that isn't the right way of fixing a driver issue in
governor.
 
> > cpufreq_schedutil calls driver specific resolve_freq() to find the new
> > target frequency and this is where the limits should get applied IMO.
> 
> Oh! I didn't 

Re: [PATCH v7 11/20] cpufreq: tegra124: Add suspend and resume support

2019-08-01 Thread Viresh Kumar
On 31-07-19, 14:10, Sowjanya Komatineni wrote:
> This patch adds suspend and resume pm ops for cpufreq driver.
> 
> PLLP is the safe clock source for CPU during system suspend and
> resume as PLLP rate is below the CPU Fmax at Vmin.
> 
> CPUFreq driver suspend switches the CPU clock source to PLLP and
> disables the DFLL clock.
> 
> During system resume, warmboot code powers up the CPU with PLLP
> clock source. So CPUFreq driver resume enabled DFLL clock and
> switches CPU back to DFLL clock source.
> 
> Signed-off-by: Sowjanya Komatineni 
> ---
>  drivers/cpufreq/tegra124-cpufreq.c | 60 
> ++
>  1 file changed, 60 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh


Re: [PATCH v4] watchdog: alim1535: Rewriting of alim1535 to use watchdog subsystem

2019-08-01 Thread Mark Balantzyan
Take a second look. It is different. And I had to amend the title hence 
the second send to include the subsystem, as you so duly tend to remind 
me. It just so happened that I mistyped and skipped a version by...1.


Mark

On Thu, 1 Aug 2019, Guenter Roeck wrote:


On 8/1/19 8:26 PM, Mark Balantzyan wrote:

This patch rewrites the alim1535_wdt driver to use the watchdog subsystem.
By virtue of this, it also fixes a (theoretical) race condition between the
formerly arranged ali_timeout_bits and ali_settimer() interoperation.

Signed-off-by: Mark Balantzyan 



This is v4. A minute ago I received v1. Earlier today I got v2, which I
commented on. I didn't see v3 of this patch. I don't see a change log.
At first glance, I don't see a difference to v2.

Sorry, this is a waste of my time. I won't review or comment further.

Guenter



---
  drivers/watchdog/Kconfig|   1 +
  drivers/watchdog/alim1535_wdt.c | 275 +---
  2 files changed, 37 insertions(+), 239 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9af07fd9..980b0c90 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -853,6 +853,7 @@ config ADVANTECH_WDT
config ALIM1535_WDT
tristate "ALi M1535 PMU Watchdog Timer"
+   select WATCHDOG_CORE
depends on X86 && PCI
---help---
  This is the driver for the hardware watchdog on the ALi M1535 PMU.
diff --git a/drivers/watchdog/alim1535_wdt.c 
b/drivers/watchdog/alim1535_wdt.c

index 60f0c2eb..55648ba8 100644
--- a/drivers/watchdog/alim1535_wdt.c
+++ b/drivers/watchdog/alim1535_wdt.c
@@ -12,26 +12,18 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
-#include 
-#include 
-#include 
-#include 
-#include 
  #include 
  #include 
+#include 
#define WATCHDOG_NAME "ALi_M1535"
  #define WATCHDOG_TIMEOUT 60   /* 60 sec default timeout */
/* internal variables */
-static unsigned long ali_is_open;
-static char ali_expect_release;
  static struct pci_dev *ali_pci;
  static u32 ali_timeout_bits;		/* stores the computed 
timeout */

-static DEFINE_SPINLOCK(ali_lock);  /* Guards the hardware */
/* module parameters */
  static int timeout = WATCHDOG_TIMEOUT;
@@ -53,18 +45,15 @@ MODULE_PARM_DESC(nowayout,
   *configuration set.
   */
  -static void ali_start(void)
+static int ali_start(struct watchdog_device *wdd)
  {
u32 val;
  - spin_lock(_lock);
-
pci_read_config_dword(ali_pci, 0xCC, );
val &= ~0x3F;   /* Mask count */
val |= (1 << 25) | ali_timeout_bits;
pci_write_config_dword(ali_pci, 0xCC, val);
-
-   spin_unlock(_lock);
+   return 0;
  }
/*
@@ -73,18 +62,15 @@ static void ali_start(void)
   *Stop the ALi watchdog countdown
   */
  -static void ali_stop(void)
+static int ali_stop(struct watchdog_device *wdd)
  {
u32 val;
  - spin_lock(_lock);
-
pci_read_config_dword(ali_pci, 0xCC, );
val &= ~0x3F;   /* Mask count to zero (disabled) */
val &= ~(1 << 25);/* and for safety mask the reset enable */
pci_write_config_dword(ali_pci, 0xCC, val);
-
-   spin_unlock(_lock);
+   return 0;
  }
/*
@@ -93,32 +79,24 @@ static void ali_stop(void)
   *Send a keepalive to the timer (actually we restart the timer).
   */
  -static void ali_keepalive(void)
+static int ali_keepalive(struct watchdog_device *wdd)
  {
-   ali_start();
+   ali_start(wdd);
+   return 0;
  }
/*
- * ali_settimer-   compute the timer reload value
+ * ali_set_timeout -   compute the timer reload value
   *@t: time in seconds
   *
   *Computes the timeout values needed
   */
  -static int ali_settimer(int t)
+static int ali_set_timeout(struct watchdog_device *wdd, unsigned int t)
  {
-   if (t < 0)
-   return -EINVAL;
-   else if (t < 60)
-   ali_timeout_bits = t|(1 << 6);
-   else if (t < 3600)
-   ali_timeout_bits = (t / 60)|(1 << 7);
-   else if (t < 18000)
-   ali_timeout_bits = (t / 300)|(1 << 6)|(1 << 7);
-   else
-   return -EINVAL;
-
-   timeout = t;
+   wdd->max_timeout = 60;
+   wdd->min_timeout = 1;
+   wdd->timeout = t;
return 0;
  }
  @@ -126,172 +104,6 @@ static int ali_settimer(int t)
   */dev/watchdog handling
   */
  -/*
- * ali_write   -   writes to ALi watchdog
- * @file: file from VFS
- * @data: user address of data
- * @len: length of data
- * @ppos: pointer to the file offset
- *
- * Handle a write to the ALi watchdog. Writing to the file pings
- * the watchdog and resets it. Writing the magic 'V' sequence allows
- * the next close to turn off the watchdog.
- */
-
-static ssize_t ali_write(struct file *file, const char __user *data,
-   size_t len, loff_t *ppos)
-{
-   /* See if we got the magic 

Re: linux-next: Tree for Jul 31 - s390 crypto build breakage

2019-08-01 Thread Herbert Xu
Hi Stephen:

On Fri, Aug 02, 2019 at 10:20:19AM +1000, Stephen Rothwell wrote:
>
> It might be time to revert all this series and try again.  The
> implementation seems to have not been well thought through from a kernel
> building point of view.  For a start the two commits
> 
>   7cdc0ddbf74a ("crypto: aegis128 - add support for SIMD acceleration")
>   ecc8bc81f2fb ("crypto: aegis128 - provide a SIMD implementation based on 
> NEON intrinsics")

I think the idea was that it would get optimised out if the
implementation is absent which is why it was meant to work in
this order.  But oviously as we have found out this didn't work.

Ard, I think relying on the compiler to optimise something out based
on an assignment within an if statement is just too error-prone.
We'll need a different mechanism for this.

For now I'm going to back out those two specific patches as the
rest seem to be valid by themselves.

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


Re: [PATCH] mm/madvise: reduce code duplication in error handling paths

2019-08-01 Thread Anshuman Khandual



On 08/01/2019 11:58 AM, Mike Rapoport wrote:
> The madvise_behavior() function converts -ENOMEM to -EAGAIN in several
> places using identical code.
> 
> Move that code to a common error handling path.
> 
> No functional changes.
> 
> Signed-off-by: Mike Rapoport 

Reviewed-by: Anshuman Khandual 


Re: [PATCH v4] watchdog: alim1535: Rewriting of alim1535 to use watchdog subsystem

2019-08-01 Thread Guenter Roeck

On 8/1/19 8:26 PM, Mark Balantzyan wrote:

This patch rewrites the alim1535_wdt driver to use the watchdog subsystem.
By virtue of this, it also fixes a (theoretical) race condition between the
formerly arranged ali_timeout_bits and ali_settimer() interoperation.

Signed-off-by: Mark Balantzyan 



This is v4. A minute ago I received v1. Earlier today I got v2, which I
commented on. I didn't see v3 of this patch. I don't see a change log.
At first glance, I don't see a difference to v2.

Sorry, this is a waste of my time. I won't review or comment further.

Guenter



---
  drivers/watchdog/Kconfig|   1 +
  drivers/watchdog/alim1535_wdt.c | 275 +---
  2 files changed, 37 insertions(+), 239 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9af07fd9..980b0c90 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -853,6 +853,7 @@ config ADVANTECH_WDT
  
  config ALIM1535_WDT

tristate "ALi M1535 PMU Watchdog Timer"
+   select WATCHDOG_CORE
depends on X86 && PCI
---help---
  This is the driver for the hardware watchdog on the ALi M1535 PMU.
diff --git a/drivers/watchdog/alim1535_wdt.c b/drivers/watchdog/alim1535_wdt.c
index 60f0c2eb..55648ba8 100644
--- a/drivers/watchdog/alim1535_wdt.c
+++ b/drivers/watchdog/alim1535_wdt.c
@@ -12,26 +12,18 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
-#include 
-#include 
-#include 
-#include 
-#include 
  #include 
  #include 
+#include 
  
  #define WATCHDOG_NAME "ALi_M1535"

  #define WATCHDOG_TIMEOUT 60   /* 60 sec default timeout */
  
  /* internal variables */

-static unsigned long ali_is_open;
-static char ali_expect_release;
  static struct pci_dev *ali_pci;
  static u32 ali_timeout_bits;  /* stores the computed timeout */
-static DEFINE_SPINLOCK(ali_lock);  /* Guards the hardware */
  
  /* module parameters */

  static int timeout = WATCHDOG_TIMEOUT;
@@ -53,18 +45,15 @@ MODULE_PARM_DESC(nowayout,
   *configuration set.
   */
  
-static void ali_start(void)

+static int ali_start(struct watchdog_device *wdd)
  {
u32 val;
  
-	spin_lock(_lock);

-
pci_read_config_dword(ali_pci, 0xCC, );
val &= ~0x3F;   /* Mask count */
val |= (1 << 25) | ali_timeout_bits;
pci_write_config_dword(ali_pci, 0xCC, val);
-
-   spin_unlock(_lock);
+   return 0;
  }
  
  /*

@@ -73,18 +62,15 @@ static void ali_start(void)
   *Stop the ALi watchdog countdown
   */
  
-static void ali_stop(void)

+static int ali_stop(struct watchdog_device *wdd)
  {
u32 val;
  
-	spin_lock(_lock);

-
pci_read_config_dword(ali_pci, 0xCC, );
val &= ~0x3F;   /* Mask count to zero (disabled) */
val &= ~(1 << 25);/* and for safety mask the reset enable */
pci_write_config_dword(ali_pci, 0xCC, val);
-
-   spin_unlock(_lock);
+   return 0;
  }
  
  /*

@@ -93,32 +79,24 @@ static void ali_stop(void)
   *Send a keepalive to the timer (actually we restart the timer).
   */
  
-static void ali_keepalive(void)

+static int ali_keepalive(struct watchdog_device *wdd)
  {
-   ali_start();
+   ali_start(wdd);
+   return 0;
  }
  
  /*

- * ali_settimer-   compute the timer reload value
+ * ali_set_timeout -   compute the timer reload value
   *@t: time in seconds
   *
   *Computes the timeout values needed
   */
  
-static int ali_settimer(int t)

+static int ali_set_timeout(struct watchdog_device *wdd, unsigned int t)
  {
-   if (t < 0)
-   return -EINVAL;
-   else if (t < 60)
-   ali_timeout_bits = t|(1 << 6);
-   else if (t < 3600)
-   ali_timeout_bits = (t / 60)|(1 << 7);
-   else if (t < 18000)
-   ali_timeout_bits = (t / 300)|(1 << 6)|(1 << 7);
-   else
-   return -EINVAL;
-
-   timeout = t;
+   wdd->max_timeout = 60;
+   wdd->min_timeout = 1;
+   wdd->timeout = t;
return 0;
  }
  
@@ -126,172 +104,6 @@ static int ali_settimer(int t)

   */dev/watchdog handling
   */
  
-/*

- * ali_write   -   writes to ALi watchdog
- * @file: file from VFS
- * @data: user address of data
- * @len: length of data
- * @ppos: pointer to the file offset
- *
- * Handle a write to the ALi watchdog. Writing to the file pings
- * the watchdog and resets it. Writing the magic 'V' sequence allows
- * the next close to turn off the watchdog.
- */
-
-static ssize_t ali_write(struct file *file, const char __user *data,
-   size_t len, loff_t *ppos)
-{
-   /* See if we got the magic character 'V' and reload the timer */
-   if (len) {
-   if (!nowayout) {
-   size_t i;
-
-   /* note: just in case someone wrote the
-  magic character five months 

[PATCH net-next] net: can: Fix compiling warning

2019-08-01 Thread Mao Wenan
There are two warings in net/can, fix them by setting bcm_sock_no_ioctlcmd
and raw_sock_no_ioctlcmd as static.

net/can/bcm.c:1683:5: warning: symbol 'bcm_sock_no_ioctlcmd' was not declared. 
Should it be static?
net/can/raw.c:840:5: warning: symbol 'raw_sock_no_ioctlcmd' was not declared. 
Should it be static?

Fixes: 473d924d7d46 ("can: fix ioctl function removal")

Signed-off-by: Mao Wenan 
---
 net/can/bcm.c | 2 +-
 net/can/raw.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/can/bcm.c b/net/can/bcm.c
index bf1d0bbecec8..b8a32b4ac368 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -1680,7 +1680,7 @@ static int bcm_recvmsg(struct socket *sock, struct msghdr 
*msg, size_t size,
return size;
 }
 
-int bcm_sock_no_ioctlcmd(struct socket *sock, unsigned int cmd,
+static int bcm_sock_no_ioctlcmd(struct socket *sock, unsigned int cmd,
 unsigned long arg)
 {
/* no ioctls for socket layer -> hand it down to NIC layer */
diff --git a/net/can/raw.c b/net/can/raw.c
index da386f1fa815..a01848ff9b12 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -837,7 +837,7 @@ static int raw_recvmsg(struct socket *sock, struct msghdr 
*msg, size_t size,
return size;
 }
 
-int raw_sock_no_ioctlcmd(struct socket *sock, unsigned int cmd,
+static int raw_sock_no_ioctlcmd(struct socket *sock, unsigned int cmd,
 unsigned long arg)
 {
/* no ioctls for socket layer -> hand it down to NIC layer */
-- 
2.20.1



[PATCH v4] watchdog: alim1535: Rewriting of alim1535 to use watchdog subsystem

2019-08-01 Thread Mark Balantzyan
This patch rewrites the alim1535_wdt driver to use the watchdog subsystem. 
By virtue of this, it also fixes a (theoretical) race condition between the
formerly arranged ali_timeout_bits and ali_settimer() interoperation.

Signed-off-by: Mark Balantzyan 

---
 drivers/watchdog/Kconfig|   1 +
 drivers/watchdog/alim1535_wdt.c | 275 +---
 2 files changed, 37 insertions(+), 239 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9af07fd9..980b0c90 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -853,6 +853,7 @@ config ADVANTECH_WDT
 
 config ALIM1535_WDT
tristate "ALi M1535 PMU Watchdog Timer"
+   select WATCHDOG_CORE
depends on X86 && PCI
---help---
  This is the driver for the hardware watchdog on the ALi M1535 PMU.
diff --git a/drivers/watchdog/alim1535_wdt.c b/drivers/watchdog/alim1535_wdt.c
index 60f0c2eb..55648ba8 100644
--- a/drivers/watchdog/alim1535_wdt.c
+++ b/drivers/watchdog/alim1535_wdt.c
@@ -12,26 +12,18 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
+#include 
 
 #define WATCHDOG_NAME "ALi_M1535"
 #define WATCHDOG_TIMEOUT 60/* 60 sec default timeout */
 
 /* internal variables */
-static unsigned long ali_is_open;
-static char ali_expect_release;
 static struct pci_dev *ali_pci;
 static u32 ali_timeout_bits;   /* stores the computed timeout */
-static DEFINE_SPINLOCK(ali_lock);  /* Guards the hardware */
 
 /* module parameters */
 static int timeout = WATCHDOG_TIMEOUT;
@@ -53,18 +45,15 @@ MODULE_PARM_DESC(nowayout,
  * configuration set.
  */
 
-static void ali_start(void)
+static int ali_start(struct watchdog_device *wdd)
 {
u32 val;
 
-   spin_lock(_lock);
-
pci_read_config_dword(ali_pci, 0xCC, );
val &= ~0x3F;   /* Mask count */
val |= (1 << 25) | ali_timeout_bits;
pci_write_config_dword(ali_pci, 0xCC, val);
-
-   spin_unlock(_lock);
+   return 0;
 }
 
 /*
@@ -73,18 +62,15 @@ static void ali_start(void)
  * Stop the ALi watchdog countdown
  */
 
-static void ali_stop(void)
+static int ali_stop(struct watchdog_device *wdd)
 {
u32 val;
 
-   spin_lock(_lock);
-
pci_read_config_dword(ali_pci, 0xCC, );
val &= ~0x3F;   /* Mask count to zero (disabled) */
val &= ~(1 << 25);  /* and for safety mask the reset enable */
pci_write_config_dword(ali_pci, 0xCC, val);
-
-   spin_unlock(_lock);
+   return 0;
 }
 
 /*
@@ -93,32 +79,24 @@ static void ali_stop(void)
  * Send a keepalive to the timer (actually we restart the timer).
  */
 
-static void ali_keepalive(void)
+static int ali_keepalive(struct watchdog_device *wdd)
 {
-   ali_start();
+   ali_start(wdd);
+   return 0;
 }
 
 /*
- * ali_settimer-   compute the timer reload value
+ * ali_set_timeout -   compute the timer reload value
  * @t: time in seconds
  *
  * Computes the timeout values needed
  */
 
-static int ali_settimer(int t)
+static int ali_set_timeout(struct watchdog_device *wdd, unsigned int t)
 {
-   if (t < 0)
-   return -EINVAL;
-   else if (t < 60)
-   ali_timeout_bits = t|(1 << 6);
-   else if (t < 3600)
-   ali_timeout_bits = (t / 60)|(1 << 7);
-   else if (t < 18000)
-   ali_timeout_bits = (t / 300)|(1 << 6)|(1 << 7);
-   else
-   return -EINVAL;
-
-   timeout = t;
+   wdd->max_timeout = 60;
+   wdd->min_timeout = 1;
+   wdd->timeout = t;
return 0;
 }
 
@@ -126,172 +104,6 @@ static int ali_settimer(int t)
  * /dev/watchdog handling
  */
 
-/*
- * ali_write   -   writes to ALi watchdog
- * @file: file from VFS
- * @data: user address of data
- * @len: length of data
- * @ppos: pointer to the file offset
- *
- * Handle a write to the ALi watchdog. Writing to the file pings
- * the watchdog and resets it. Writing the magic 'V' sequence allows
- * the next close to turn off the watchdog.
- */
-
-static ssize_t ali_write(struct file *file, const char __user *data,
-   size_t len, loff_t *ppos)
-{
-   /* See if we got the magic character 'V' and reload the timer */
-   if (len) {
-   if (!nowayout) {
-   size_t i;
-
-   /* note: just in case someone wrote the
-  magic character five months ago... */
-   ali_expect_release = 0;
-
-   /* scan to see whether or not we got
-  the magic character */
-   for (i = 0; i != len; i++) {
-   char c;
-   if (get_user(c, data + i))
-   return -EFAULT;

Re: [PATCH] linux/bits.h: Add compile time sanity check of GENMASK inputs

2019-08-01 Thread Masahiro Yamada
On Fri, Aug 2, 2019 at 12:14 PM Joe Perches  wrote:
>
> On Fri, 2019-08-02 at 10:40 +0900, Masahiro Yamada wrote:
> > On Thu, Aug 1, 2019 at 4:27 AM Joe Perches  wrote:
> > > On Wed, 2019-07-31 at 21:03 +0200, Rikard Falkeborn wrote:
> > > > GENMASK() and GENMASK_ULL() are supposed to be called with the high bit
> > > > as the first argument and the low bit as the second argument. Mixing
> > > > them will return a mask with zero bits set.
> > > >
> > > > Recent commits show getting this wrong is not uncommon, see e.g.
> > > > commit aa4c0c9091b0 ("net: stmmac: Fix misuses of GENMASK macro") and
> > > > commit 9bdd7bb3a844 ("clocksource/drivers/npcm: Fix misuse of GENMASK
> > > > macro").
> > > >
> > > > To prevent such mistakes from appearing again, add compile time sanity
> > > > checking to the arguments of GENMASK() and GENMASK_ULL(). If both the
> > > > arguments are known at compile time, and the low bit is higher than the
> > > > high bit, break the build to detect the mistake immediately.
> > > >
> > > > Since GENMASK() is used in declarations, BUILD_BUG_OR_ZERO() must be
> > > > used instead of BUILD_BUG_ON(), and __is_constexpr() must be used 
> > > > instead
> > > > of __builtin_constant_p().
> > > >
> > > > Commit 95b980d62d52 ("linux/bits.h: make BIT(), GENMASK(), and friends
> > > > available in assembly") made the macros in linux/bits.h available in
> > > > assembly. Since neither BUILD_BUG_OR_ZERO() or __is_constexpr() are asm
> > > > compatible, disable the checks if the file is included in an asm file.
> > > >
> > > > Signed-off-by: Rikard Falkeborn 
> > > > ---
> > > > Joe Perches sent a series to fix the existing misuses of GENMASK() that
> > > > needs to be merged before this to avoid build failures. Currently, 7 of
> > > > the patches were not in Linus tree, and 2 were not in linux-next.
> > > >
> > > > Also, there's currently no asm users of bits.h, but since it was made
> > > > asm-compatible just two weeks ago it would be a shame to break it right
> > > > away...
> > > []
> > > > diff --git a/include/linux/bits.h b/include/linux/bits.h
> > > []
> > > > @@ -18,12 +18,22 @@
> > > >   * position @h. For example
> > > >   * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0.
> > > >   */
> > > > +#ifndef __ASSEMBLY__
> > > > +#include 
> > > > +#define GENMASK_INPUT_CHECK(h, l)  
> > > > BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
> > > > + __is_constexpr(h) && __is_constexpr(l), (l) > (h), 0))
> > > > +#else
> > > > +#define GENMASK_INPUT_CHECK(h, l) 0
> > >
> > > A few things:
> > >
> > > o Reading the final code is a bit confusing.
> > >   Perhaps add a comment description saying it's not checked
> > >   in asm .h uses.
> > >
> > > o Maybe use:
> > >   #define GENMASK_INPUT_CHECK(h, l) UL(0)
> >
> > Why?
>
> Consistency with the uses in what's now called __GENMASK

Inconsistent with __GENMASK_ULL.



-- 
Best Regards
Masahiro Yamada


RE: [EXT] Re: [PATCH v3] mailbox: imx: add support for imx v1 mu

2019-08-01 Thread Richard Zhu
> -Original Message-
> From: Daniel Baluta 
> Sent: 2019年8月1日 22:47
> To: Richard Zhu 
> Cc: jassisinghb...@gmail.com; Oleksij Rempel ;
> Aisheng Dong ; Linux Kernel Mailing List
> ; linux-arm-kernel
> ; dl-linux-imx 
> Subject: [EXT] Re: [PATCH v3] mailbox: imx: add support for imx v1 mu
> 
> Hi Richard,
> 
> Thanks for the patch. Please always add linux-...@nxp.com mailing list for imx
> related patches. I missed it.
> 
[Richard Zhu] Okay, roger that.

> Few comments inline.
> 
> Please also update in a separate patch attached to this series the devictree
> bindings doc Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> by adding description for mx7ulp-mu
> 
> 
[Richard Zhu] Okay, the binding doc would be added later.
> 
> > There is a version1.0 MU on i.MX7ULP platform.
> 
> space between version and 1.0
> 
[Richard Zhu] Okay.

> > One new version ID register is added, and it's offset is 0.
> > TRn registers are defined at the offset 0x20 ~ 0x2C.
> > RRn registers are defined at the offset 0x40 ~ 0x4C.
> > SR/CR registers are defined at 0x60/0x64.
> > Extend this driver to support it.
> 
> Do you have a little bit of history about MU versioning? So there was:
> 
> * version 0.5 on i.MX6-es
> * version 1.0 on i.MX7ULP
> 
> Next, is this 1.0 compatbile with i.MX8 right?
> 
[Richard Zhu] Only i.MX7ULP has the version 1.0 MU.
i.MX8 has the same version MU that i.MX6-es have.
IMHO, I don't know why design team do it this way.

> Also, can you please rebase your patch on my 2 bugfixes attached?
[Richard Zhu] Okay, no problem. I would send the v4 version out later after 
rebase your 2 bugfixes patches.
> 
> thanks,
> Daniel.


[PATCH] Rewriting of alim1535 to use watchdog subsystem

2019-08-01 Thread Mark Balantzyan
This patch rewrites the alim1535_wdt driver to use the watchdog subsystem. 
By virtue of this, it also fixes a (theoretical) race condition between the
formerly arranged ali_timeout_bits and ali_settimer() interoperation.

Signed-off-by: Mark Balantzyan 

---
 drivers/watchdog/Kconfig|   1 +
 drivers/watchdog/alim1535_wdt.c | 275 +---
 2 files changed, 37 insertions(+), 239 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9af07fd9..980b0c90 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -853,6 +853,7 @@ config ADVANTECH_WDT
 
 config ALIM1535_WDT
tristate "ALi M1535 PMU Watchdog Timer"
+   select WATCHDOG_CORE
depends on X86 && PCI
---help---
  This is the driver for the hardware watchdog on the ALi M1535 PMU.
diff --git a/drivers/watchdog/alim1535_wdt.c b/drivers/watchdog/alim1535_wdt.c
index 60f0c2eb..55648ba8 100644
--- a/drivers/watchdog/alim1535_wdt.c
+++ b/drivers/watchdog/alim1535_wdt.c
@@ -12,26 +12,18 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
+#include 
 
 #define WATCHDOG_NAME "ALi_M1535"
 #define WATCHDOG_TIMEOUT 60/* 60 sec default timeout */
 
 /* internal variables */
-static unsigned long ali_is_open;
-static char ali_expect_release;
 static struct pci_dev *ali_pci;
 static u32 ali_timeout_bits;   /* stores the computed timeout */
-static DEFINE_SPINLOCK(ali_lock);  /* Guards the hardware */
 
 /* module parameters */
 static int timeout = WATCHDOG_TIMEOUT;
@@ -53,18 +45,15 @@ MODULE_PARM_DESC(nowayout,
  * configuration set.
  */
 
-static void ali_start(void)
+static int ali_start(struct watchdog_device *wdd)
 {
u32 val;
 
-   spin_lock(_lock);
-
pci_read_config_dword(ali_pci, 0xCC, );
val &= ~0x3F;   /* Mask count */
val |= (1 << 25) | ali_timeout_bits;
pci_write_config_dword(ali_pci, 0xCC, val);
-
-   spin_unlock(_lock);
+   return 0;
 }
 
 /*
@@ -73,18 +62,15 @@ static void ali_start(void)
  * Stop the ALi watchdog countdown
  */
 
-static void ali_stop(void)
+static int ali_stop(struct watchdog_device *wdd)
 {
u32 val;
 
-   spin_lock(_lock);
-
pci_read_config_dword(ali_pci, 0xCC, );
val &= ~0x3F;   /* Mask count to zero (disabled) */
val &= ~(1 << 25);  /* and for safety mask the reset enable */
pci_write_config_dword(ali_pci, 0xCC, val);
-
-   spin_unlock(_lock);
+   return 0;
 }
 
 /*
@@ -93,32 +79,24 @@ static void ali_stop(void)
  * Send a keepalive to the timer (actually we restart the timer).
  */
 
-static void ali_keepalive(void)
+static int ali_keepalive(struct watchdog_device *wdd)
 {
-   ali_start();
+   ali_start(wdd);
+   return 0;
 }
 
 /*
- * ali_settimer-   compute the timer reload value
+ * ali_set_timeout -   compute the timer reload value
  * @t: time in seconds
  *
  * Computes the timeout values needed
  */
 
-static int ali_settimer(int t)
+static int ali_set_timeout(struct watchdog_device *wdd, unsigned int t)
 {
-   if (t < 0)
-   return -EINVAL;
-   else if (t < 60)
-   ali_timeout_bits = t|(1 << 6);
-   else if (t < 3600)
-   ali_timeout_bits = (t / 60)|(1 << 7);
-   else if (t < 18000)
-   ali_timeout_bits = (t / 300)|(1 << 6)|(1 << 7);
-   else
-   return -EINVAL;
-
-   timeout = t;
+   wdd->max_timeout = 60;
+   wdd->min_timeout = 1;
+   wdd->timeout = t;
return 0;
 }
 
@@ -126,172 +104,6 @@ static int ali_settimer(int t)
  * /dev/watchdog handling
  */
 
-/*
- * ali_write   -   writes to ALi watchdog
- * @file: file from VFS
- * @data: user address of data
- * @len: length of data
- * @ppos: pointer to the file offset
- *
- * Handle a write to the ALi watchdog. Writing to the file pings
- * the watchdog and resets it. Writing the magic 'V' sequence allows
- * the next close to turn off the watchdog.
- */
-
-static ssize_t ali_write(struct file *file, const char __user *data,
-   size_t len, loff_t *ppos)
-{
-   /* See if we got the magic character 'V' and reload the timer */
-   if (len) {
-   if (!nowayout) {
-   size_t i;
-
-   /* note: just in case someone wrote the
-  magic character five months ago... */
-   ali_expect_release = 0;
-
-   /* scan to see whether or not we got
-  the magic character */
-   for (i = 0; i != len; i++) {
-   char c;
-   if (get_user(c, data + i))
-   return -EFAULT;

linux-next: build warning after merge of the i2c tree

2019-08-01 Thread Stephen Rothwell
Hi all,

After merging the i2c tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

drivers/i2c/busses/i2c-designware-master.c: In function 
'i2c_dw_init_recovery_info':
drivers/i2c/busses/i2c-designware-master.c:658:6: warning: unused variable 'r' 
[-Wunused-variable]
  int r;
  ^

Introduced by commit

  33eb09a02e8d ("i2c: designware: make use of devm_gpiod_get_optional")

-- 
Cheers,
Stephen Rothwell


pgpjz_gDyDKpj.pgp
Description: OpenPGP digital signature


[PATCH] ALSA: hda: Add support of Zhaoxin controller

2019-08-01 Thread Tony W Wang-oc
Add the new PCI ID 0x1d17 0x3288 Zhaoxin controller support

Signed-off-by: Tony W Wang-oc 
---
 sound/pci/hda/hda_intel.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 324a4b2..d08da0e 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -266,6 +266,7 @@ enum {
AZX_DRIVER_CTX,
AZX_DRIVER_CTHDA,
AZX_DRIVER_CMEDIA,
+   AZX_DRIVER_ZHAOXIN,
AZX_DRIVER_GENERIC,
AZX_NUM_DRIVERS, /* keep this as last entry */
 };
@@ -379,6 +380,7 @@ static char *driver_short_names[] = {
[AZX_DRIVER_CTX] = "HDA Creative", 
[AZX_DRIVER_CTHDA] = "HDA Creative",
[AZX_DRIVER_CMEDIA] = "HDA C-Media",
+   [AZX_DRIVER_ZHAOXIN] = "HDA Zhaoxin",
[AZX_DRIVER_GENERIC] = "HD-Audio Generic",
 };
 
@@ -2589,6 +2591,8 @@ static const struct pci_device_id azx_ids[] = {
  .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8,
  .class_mask = 0xff,
  .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_HDMI },
+   /* Zhaoxin */
+   { PCI_DEVICE(0x1d17, 0x3288), .driver_data = AZX_DRIVER_ZHAOXIN },
{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, azx_ids);
-- 
2.7.4


Re: [PATCH] linux/bits.h: Add compile time sanity check of GENMASK inputs

2019-08-01 Thread Joe Perches
On Fri, 2019-08-02 at 10:40 +0900, Masahiro Yamada wrote:
> On Thu, Aug 1, 2019 at 4:27 AM Joe Perches  wrote:
> > On Wed, 2019-07-31 at 21:03 +0200, Rikard Falkeborn wrote:
> > > GENMASK() and GENMASK_ULL() are supposed to be called with the high bit
> > > as the first argument and the low bit as the second argument. Mixing
> > > them will return a mask with zero bits set.
> > > 
> > > Recent commits show getting this wrong is not uncommon, see e.g.
> > > commit aa4c0c9091b0 ("net: stmmac: Fix misuses of GENMASK macro") and
> > > commit 9bdd7bb3a844 ("clocksource/drivers/npcm: Fix misuse of GENMASK
> > > macro").
> > > 
> > > To prevent such mistakes from appearing again, add compile time sanity
> > > checking to the arguments of GENMASK() and GENMASK_ULL(). If both the
> > > arguments are known at compile time, and the low bit is higher than the
> > > high bit, break the build to detect the mistake immediately.
> > > 
> > > Since GENMASK() is used in declarations, BUILD_BUG_OR_ZERO() must be
> > > used instead of BUILD_BUG_ON(), and __is_constexpr() must be used instead
> > > of __builtin_constant_p().
> > > 
> > > Commit 95b980d62d52 ("linux/bits.h: make BIT(), GENMASK(), and friends
> > > available in assembly") made the macros in linux/bits.h available in
> > > assembly. Since neither BUILD_BUG_OR_ZERO() or __is_constexpr() are asm
> > > compatible, disable the checks if the file is included in an asm file.
> > > 
> > > Signed-off-by: Rikard Falkeborn 
> > > ---
> > > Joe Perches sent a series to fix the existing misuses of GENMASK() that
> > > needs to be merged before this to avoid build failures. Currently, 7 of
> > > the patches were not in Linus tree, and 2 were not in linux-next.
> > > 
> > > Also, there's currently no asm users of bits.h, but since it was made
> > > asm-compatible just two weeks ago it would be a shame to break it right
> > > away...
> > []
> > > diff --git a/include/linux/bits.h b/include/linux/bits.h
> > []
> > > @@ -18,12 +18,22 @@
> > >   * position @h. For example
> > >   * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0.
> > >   */
> > > +#ifndef __ASSEMBLY__
> > > +#include 
> > > +#define GENMASK_INPUT_CHECK(h, l)  
> > > BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
> > > + __is_constexpr(h) && __is_constexpr(l), (l) > (h), 0))
> > > +#else
> > > +#define GENMASK_INPUT_CHECK(h, l) 0
> > 
> > A few things:
> > 
> > o Reading the final code is a bit confusing.
> >   Perhaps add a comment description saying it's not checked
> >   in asm .h uses.
> > 
> > o Maybe use:
> >   #define GENMASK_INPUT_CHECK(h, l) UL(0)
> 
> Why?

Consistency with the uses in what's now called __GENMASK




Re: [PATCH v2 06/10] printk: Replace strncmp with str_has_prefix

2019-08-01 Thread Joe Perches
On Fri, 2019-08-02 at 09:47 +0800, Chuhong Yuan wrote:
> strncmp(str, const, len) is error-prone because len
> is easy to have typo.
> The example is the hard-coded len has counting error
> or sizeof(const) forgets - 1.
> So we prefer using newly introduced str_has_prefix
> to substitute such strncmp.
[]
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
[]
> @@ -118,18 +118,20 @@ static unsigned int __read_mostly devkmsg_log = 
> DEVKMSG_LOG_MASK_DEFAULT;
>  
>  static int __control_devkmsg(char *str)
>  {
> + size_t len;
> +
>   if (!str)
>   return -EINVAL;
>  
> - if (!strncmp(str, "on", 2)) {
> + if ((len = str_has_prefix(str, "on"))) {
>   devkmsg_log = DEVKMSG_LOG_MASK_ON;
> - return 2;
> - } else if (!strncmp(str, "off", 3)) {
> + return len;
> + } else if ((len = str_has_prefix(str, "off"))) {
>   devkmsg_log = DEVKMSG_LOG_MASK_OFF;
> - return 3;
> - } else if (!strncmp(str, "ratelimit", 9)) {
> + return len;
> + } else if ((len = str_has_prefix(str, "ratelimit"))) {
>   devkmsg_log = DEVKMSG_LOG_MASK_DEFAULT;
> - return 9;
> + return len;
>   }
>   return -EINVAL;
>  }

All of the else uses above could also be removed.



[PATCH] perf record: Support aarch64 random socket_id assignment

2019-08-01 Thread Tan Xiaojun
Same as the commit 01766229533f ("perf record: Support s390 random
socket_id assignment"), aarch64 also have this problem.

Without this fix:
  [root@localhost perf]# ./perf report --header -I -v
  ...
  socket_id number is too big.You may need to upgrade the perf tool.

  # 
  # captured on: Thu Aug  1 22:58:38 2019
  # header version : 1
  ...
  # Core ID and Socket ID information is not available
  ...

With this fix:
  [root@localhost perf]# ./perf report --header -I -v
  ...
  cpumask list: 0-31
  cpumask list: 32-63
  cpumask list: 64-95
  cpumask list: 96-127

  # 
  # captured on: Thu Aug  1 22:58:38 2019
  # header version : 1
  ...
  # CPU 0: Core ID 0, Socket ID 36
  # CPU 1: Core ID 1, Socket ID 36
  ...
  # CPU 126: Core ID 126, Socket ID 8442
  # CPU 127: Core ID 127, Socket ID 8442
  ...

Signed-off-by: Tan Xiaojun 
---
 tools/perf/util/header.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 20111f8..d57fb74 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -2251,8 +2251,10 @@ static int process_cpu_topology(struct feat_fd *ff, void 
*data __maybe_unused)
/* On s390 the socket_id number is not related to the numbers of cpus.
 * The socket_id number might be higher than the numbers of cpus.
 * This depends on the configuration.
+* AArch64 is the same.
 */
-   if (ph->env.arch && !strncmp(ph->env.arch, "s390", 4))
+   if (ph->env.arch && (!strncmp(ph->env.arch, "s390", 4)
+ || !strncmp(ph->env.arch, "aarch64", 7)))
do_core_id_test = false;
 
for (i = 0; i < (u32)cpu_nr; i++) {
-- 
2.7.4



Re: [PATCH v3] kasan: add memory corruption identification for software tag-based mode

2019-08-01 Thread Walter Wu
On Wed, 2019-07-31 at 20:04 +0300, Andrey Ryabinin wrote:
> 
> On 7/26/19 4:19 PM, Walter Wu wrote:
> > On Fri, 2019-07-26 at 15:52 +0300, Andrey Ryabinin wrote:
> >>
> >> On 7/26/19 3:28 PM, Walter Wu wrote:
> >>> On Fri, 2019-07-26 at 15:00 +0300, Andrey Ryabinin wrote:
> 
> >>>
> >
> >
> > I remember that there are already the lists which you concern. Maybe we
> > can try to solve those problems one by one.
> >
> > 1. deadlock issue? cause by kmalloc() after kfree()?
> 
>  smp_call_on_cpu()
> >>>
> > 2. decrease allocation fail, to modify GFP_NOWAIT flag to GFP_KERNEL?
> 
>  No, this is not gonna work. Ideally we shouldn't have any allocations 
>  there.
>  It's not reliable and it hurts performance.
> 
> >>> I dont know this meaning, we need create a qobject and put into
> >>> quarantine, so may need to call kmem_cache_alloc(), would you agree this
> >>> action?
> >>>
> >>
> >> How is this any different from what you have now?
> > 
> > I originally thought you already agreed the free-list(tag-based
> > quarantine) after fix those issue. If no allocation there,
> 
> If no allocation there, than it must be somewhere else.
> We known exactly the amount of memory we need, so it's possible to 
> preallocate it in advance.
> 
I see. We will implement an extend slub to record five free backtrack
and free pointer tag, and determine whether it is oob or uaf by the free
pointer tag. If you have other ideas, please tell me. Thanks.

 



Re: [PATCH v3 3/3] ARM: dts: aspeed: Add Mihawk BMC platform

2019-08-01 Thread Andrew Jeffery



On Thu, 1 Aug 2019, at 19:48, Ben Pai wrote:
> The Mihawk BMC is an ASPEED ast2500 based BMC that is part of an
> OpenPower Power9 server.
> 
> Signed-off-by: Ben Pai 
> ---
>  arch/arm/boot/dts/Makefile  |   1 +
>  arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts | 902 
>  2 files changed, 903 insertions(+)
>  create mode 100755 arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index eb6de52c1936..cdfe0f43ffd3 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1275,6 +1275,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>   aspeed-bmc-lenovo-hr630.dtb \
>   aspeed-bmc-microsoft-olympus.dtb \
>   aspeed-bmc-opp-lanyang.dtb \
> + aspeed-bmc-opp-mihawk.dtb \
>   aspeed-bmc-opp-palmetto.dtb \
>   aspeed-bmc-opp-romulus.dtb \
>   aspeed-bmc-opp-swift.dtb \
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts 
> b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
> new file mode 100755
> index ..ca42057c0c1f
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
> @@ -0,0 +1,902 @@
> +/dts-v1/;
> +
> +#include "aspeed-g5.dtsi"
> +#include 
> +#include 
> +
> +/ {
> + model = "Mihawk BMC";
> + compatible = "ibm,mihawk-bmc", "aspeed,ast2500";
> +
> +
> + chosen {
> + stdout-path = 
> + bootargs = "console=ttyS4,115200 earlyprintk";
> + };
> +
> + memory@8000 {
> + reg = <0x8000 0x2000>; /* address and size of 
> RAM(512MB) */
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + flash_memory: region@9800 {
> + no-map;
> + reg = <0x9800 0x0400>; /* 64M */
> + };
> +
> + gfx_memory: framebuffer {
> + size = <0x0100>;
> + alignment = <0x0100>;
> + compatible = "shared-dma-pool";
> + reusable;
> + };
> +
> + video_engine_memory: jpegbuffer {
> + size = <0x0200>;/* 32MM */
> + alignment = <0x0100>;
> + compatible = "shared-dma-pool";
> + reusable;
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + air-water {
> + label = "air-water";
> + gpios = < ASPEED_GPIO(F, 6) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + checkstop {
> + label = "checkstop";
> + gpios = < ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + ps0-presence {
> + label = "ps0-presence";
> + gpios = < ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + ps1-presence {
> + label = "ps1-presence";
> + gpios = < ASPEED_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + id-button {
> + label = "id-button";
> + gpios = < ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + poll-interval = <1000>;
> +
> + fan0-presence {
> + label = "fan0-presence";
> + gpios = < 9 GPIO_ACTIVE_LOW>;
> + linux,code = <9>;
> + };
> +
> + fan1-presence {
> + label = "fan1-presence";
> + gpios = < 10 GPIO_ACTIVE_LOW>;
> + linux,code = <10>;
> + };
> +
> + fan2-presence {
> + label = "fan2-presence";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + linux,code = <11>;
> + };
> +
> + fan3-presence {
> + label = "fan3-presence";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + linux,code = <12>;
> + };
> +
> + fan4-presence {
> + label = "fan4-presence";
> + gpios = < 13 GPIO_ACTIVE_LOW>;
> + linux,code = <13>;
> + };
> +
> + fan5-presence {
> + label = "fan5-presence";
> + gpios = < 14 GPIO_ACTIVE_LOW>;
> + linux,code = <14>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + fault {
> + 

Re: [PATCH] ARM: dts: aspeed: Add Facebook Wedge100 BMC

2019-08-01 Thread Joel Stanley
On Fri, 2 Aug 2019 at 01:02, Tao Ren  wrote:
> +
> +   chosen {
> +   stdout-path = 
> +   bootargs = "debug console=ttyS2,9600n8 root=/dev/ram rw";

Are you sure you want 'debug' in your boot arguments?

The rest lgtm. I can remove debug when applying, or leave it there if
it was intentional.

Cheers,

Joel


Re: [PATCH] ARM: dts: aspeed: Add Facebook Wedge40 BMC

2019-08-01 Thread Andrew Jeffery



On Fri, 2 Aug 2019, at 10:24, Tao Ren wrote:
> Add initial version of device tree for Facebook Wedge40 AST2400 BMC
> platform.
> 
> Signed-off-by: Tao Ren 

Reviewed-by: Andrew Jeffery 

> ---
>  arch/arm/boot/dts/Makefile|   1 +
>  .../boot/dts/aspeed-bmc-facebook-wedge40.dts  | 141 ++
>  2 files changed, 142 insertions(+)
>  create mode 100644 arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 39a05a10a2a2..dfc1011eb3f2 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1273,6 +1273,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>   aspeed-bmc-facebook-cmm.dtb \
>   aspeed-bmc-facebook-minipack.dtb \
>   aspeed-bmc-facebook-tiogapass.dtb \
> + aspeed-bmc-facebook-wedge40.dtb \
>   aspeed-bmc-facebook-yamp.dtb \
>   aspeed-bmc-intel-s2600wf.dtb \
>   aspeed-bmc-inspur-fp5280g2.dtb \
> diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts 
> b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts
> new file mode 100644
> index ..764633964ac1
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright (c) 2018 Facebook Inc.
> +/dts-v1/;
> +
> +#include "aspeed-g4.dtsi"
> +
> +/ {
> + model = "Facebook Wedge 40 BMC";
> + compatible = "facebook,wedge40-bmc", "aspeed,ast2400";
> +
> + aliases {
> + /*
> +  * Override the default uart aliases to avoid breaking
> +  * the legacy applications.
> +  */
> + serial0 = 
> + serial1 = 
> + serial2 = 
> + serial3 = 
> + };
> +
> + chosen {
> + stdout-path = 
> + bootargs = "debug console=ttyS2,9600n8 root=/dev/ram rw";
> + };
> +
> + memory@4000 {
> + reg = <0x4000 0x2000>;
> + };
> +};
> +
> + {
> + status = "okay";
> + aspeed,reset-type = "system";
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
> + status = "okay";
> + flash@0 {
> + status = "okay";
> + m25p,fast-read;
> + label = "fmc0";
> +#include "facebook-bmc-flash-layout.dtsi"
> + };
> +};
> +
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_txd1_default
> +  _rxd1_default>;
> +};
> +
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_txd3_default
> +  _rxd3_default>;
> +};
> +
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_txd4_default
> +  _rxd4_default>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + no-hw-checksum;
> + pinctrl-names = "default";
> + pinctrl-0 = <_rgmii2_default _mdio2_default>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> -- 
> 2.17.1
> 
>


Re: [PATCH] ARM: dts: aspeed: Add Facebook Wedge100 BMC

2019-08-01 Thread Andrew Jeffery



On Fri, 2 Aug 2019, at 10:32, Tao Ren wrote:
> Add initial version of device tree for Facebook Wedge100 AST2400 BMC
> platform.
> 
> Signed-off-by: Tao Ren 

Reviewed-by: Andrew Jeffery 

> ---
>  arch/arm/boot/dts/Makefile|   1 +
>  .../boot/dts/aspeed-bmc-facebook-wedge100.dts | 149 ++
>  2 files changed, 150 insertions(+)
>  create mode 100644 arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 39a05a10a2a2..d71504ed82d3 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1273,6 +1273,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>   aspeed-bmc-facebook-cmm.dtb \
>   aspeed-bmc-facebook-minipack.dtb \
>   aspeed-bmc-facebook-tiogapass.dtb \
> + aspeed-bmc-facebook-wedge100.dtb \
>   aspeed-bmc-facebook-yamp.dtb \
>   aspeed-bmc-intel-s2600wf.dtb \
>   aspeed-bmc-inspur-fp5280g2.dtb \
> diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts 
> b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts
> new file mode 100644
> index ..ccd700467ea7
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright (c) 2018 Facebook Inc.
> +/dts-v1/;
> +
> +#include "aspeed-g4.dtsi"
> +
> +/ {
> + model = "Facebook Wedge 100 BMC";
> + compatible = "facebook,wedge100-bmc", "aspeed,ast2400";
> +
> + aliases {
> + /*
> +  * Override the default uart aliases to avoid breaking
> +  * the legacy applications.
> +  */
> + serial0 = 
> + serial1 = 
> + serial2 = 
> + serial3 = 
> + };
> +
> + chosen {
> + stdout-path = 
> + bootargs = "debug console=ttyS2,9600n8 root=/dev/ram rw";
> + };
> +
> + memory@4000 {
> + reg = <0x4000 0x2000>;
> + };
> +};
> +
> + {
> + status = "okay";
> + aspeed,reset-type = "system";
> +};
> +
> + {
> + status = "okay";
> + aspeed,reset-type = "system";
> +};
> +
> + {
> + status = "okay";
> + flash@0 {
> + status = "okay";
> + m25p,fast-read;
> + label = "fmc0";
> +#include "facebook-bmc-flash-layout.dtsi"
> + };
> +};
> +
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_txd1_default
> +  _rxd1_default>;
> +};
> +
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_txd3_default
> +  _rxd3_default>;
> +};
> +
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_txd4_default
> +  _rxd4_default>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + no-hw-checksum;
> + pinctrl-names = "default";
> + pinctrl-0 = <_rgmii2_default _mdio2_default>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +
> + i2c-switch@70 {
> + compatible = "nxp,pca9548";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x70>;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> -- 
> 2.17.1
> 
>


memory leak in tipc_group_create_member

2019-08-01 Thread syzbot

Hello,

syzbot found the following crash on:

HEAD commit:a9815a4f Merge branch 'x86-urgent-for-linus' of git://git...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12a6dbf060
kernel config:  https://syzkaller.appspot.com/x/.config?x=37c48fb52e3789e6
dashboard link: https://syzkaller.appspot.com/bug?extid=f95d90c454864b3b5bc9
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=13be3ecc60
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11c992b460

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+f95d90c454864b3b5...@syzkaller.appspotmail.com

executing program
BUG: memory leak
unreferenced object 0x888122bca200 (size 128):
  comm "syz-executor232", pid 7065, jiffies 4294943817 (age 8.880s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 18 a2 bc 22 81 88 ff ff  ..."
  backtrace:
[<5bada299>] kmemleak_alloc_recursive  
include/linux/kmemleak.h:43 [inline]

[<5bada299>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<5bada299>] slab_alloc mm/slab.c:3319 [inline]
[<5bada299>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[] kmalloc include/linux/slab.h:552 [inline]
[] kzalloc include/linux/slab.h:748 [inline]
[] tipc_group_create_member+0x3c/0x190  
net/tipc/group.c:306
[<05f56f40>] tipc_group_add_member+0x34/0x40  
net/tipc/group.c:327
[<44406683>] tipc_nametbl_build_group+0x9b/0xf0  
net/tipc/name_table.c:600

[<9f71e803>] tipc_sk_join net/tipc/socket.c:2901 [inline]
[<9f71e803>] tipc_setsockopt+0x170/0x490 net/tipc/socket.c:3006
[<7f61cbc2>] __sys_setsockopt+0x10f/0x220 net/socket.c:2084
[] __do_sys_setsockopt net/socket.c:2100 [inline]
[] __se_sys_setsockopt net/socket.c:2097 [inline]
[] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2097
[] do_syscall_64+0x76/0x1a0  
arch/x86/entry/common.c:296

[<271be3e6>] entry_SYSCALL_64_after_hwframe+0x44/0xa9



---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches


Re: [PATCH 2/2] pinctrl: qcom: Add SC7180 pinctrl driver

2019-08-01 Thread Rajendra Nayak




On 8/1/2019 8:06 PM, Bjorn Andersson wrote:

On Thu 01 Aug 03:07 PDT 2019, Rajendra Nayak wrote:

[..]

+static const struct msm_pingroup sc7180_groups[] = {
+   [0] = PINGROUP(0, SOUTH, qup01, cri_trng, _, phase_flag, _, _, _, _, _),
+   [1] = PINGROUP(1, SOUTH, qup01, cri_trng, _, phase_flag, _, _, _, _, _),
+   [2] = PINGROUP(2, SOUTH, qup01, cri_trng, _, phase_flag, _, _, _, _, _),
+   [3] = PINGROUP(3, SOUTH, qup01, sp_cmu, dbg_out, qdss_cti, _, _, _, _, 
_),
+   [4] = PINGROUP(4, NORTH, sdc1_tb, _, qdss_cti, _, _, _, _, _, _), [5] = 
PINGROUP(5, NORTH, sdc2_tb, _, _, _, _, _, _, _, _),
+   [6] = PINGROUP(6, NORTH, qup11, qup11, _, _, _, _, _, _, _), [7] = 
PINGROUP(7, NORTH, qup11, qup11, ddr_bist, _, _, _, _, _, _),


5 and 7 deserve to be on their own line :)


Oops, looks like some formatting mess, I'll fix and resend.



Apart from that:

Reviewed-by: Bjorn Andersson 


thanks for the review.



Regards,
Bjorn



--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation


Re: [PATCH] drivers/macintosh/smu.c: Mark expected switch fall-through

2019-08-01 Thread Michael Ellerman
On Tue, 2019-07-30 at 04:37:04 UTC, Stephen Rothwell wrote:
> Mark switch cases where we are expecting to fall through.
> 
> This patch fixes the following warning (Building: powerpc):
> 
> drivers/macintosh/smu.c: In function 'smu_queue_i2c':
> drivers/macintosh/smu.c:854:21: warning: this statement may fall through [-=
> Wimplicit-fallthrough=3D]
>cmd->info.devaddr &=3D 0xfe;
>~~^~~
> drivers/macintosh/smu.c:855:2: note: here
>   case SMU_I2C_TRANSFER_STDSUB:
>   ^~~~
> 
> Cc: Benjamin Herrenschmidt 
> Cc: Gustavo A. R. Silva 
> Cc: Kees Cook 
> Signed-off-by: Stephen Rothwell 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/7440ea8b2a4430eef5120d0a7faac6c39304ae6d

cheers


Re: [PATCH] powerpc/kasan: fix early boot failure on PPC32

2019-08-01 Thread Michael Ellerman
On Wed, 2019-07-31 at 06:01:42 UTC, Christophe Leroy wrote:
> Due to commit 4a6d8cf90017 ("powerpc/mm: don't use pte_alloc_kernel()
> until slab is available on PPC32"), pte_alloc_kernel() cannot be used
> during early KASAN init.
> 
> Fix it by using memblock_alloc() instead.
> 
> Reported-by: Erhard F. 
> Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support")
> Signed-off-by: Christophe Leroy 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/d7e23b887f67178c4f840781be7a6aa6aeb52ab1

cheers


[PATCH 00/34] put_user_pages(): miscellaneous call sites

2019-08-01 Thread john . hubbard
From: John Hubbard 

Hi,

These are best characterized as miscellaneous conversions: many (not all)
call sites that don't involve biovec or iov_iter, nor mm/. It also leaves
out a few call sites that require some more work. These are mostly pretty
simple ones.

It's probably best to send all of these via Andrew's -mm tree, assuming
that there are no significant merge conflicts with ongoing work in other
trees (which I doubt, given that these are small changes).

These patches apply to the latest linux.git. Patch #1 is also already in
Andrew's tree, but given the broad non-linux-mm Cc list, I thought it
would be more convenient to just include that patch here, so that people
can use linux.git as the base--even though these are probably destined
for linux-mm.

This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions"). That commit
has an extensive description of the problem and the planned steps to
solve it, but the highlites are:

1) Provide put_user_page*() routines, intended to be used
for releasing pages that were pinned via get_user_pages*().

2) Convert all of the call sites for get_user_pages*(), to
invoke put_user_page*(), instead of put_page(). This involves dozens of
call sites, and will take some time.

3) After (2) is complete, use get_user_pages*() and put_user_page*() to
implement tracking of these pages. This tracking will be separate from
the existing struct page refcounting.

4) Use the tracking and identification of these pages, to implement
special handling (especially in writeback paths) when the pages are
backed by a filesystem.

And a few references, also from that commit:

[1] https://lwn.net/Articles/774411/ : "DMA and get_user_pages()"
[2] https://lwn.net/Articles/753027/ : "The Trouble with get_user_pages()"


Ira Weiny (1):
  fs/binfmt_elf: convert put_page() to put_user_page*()

John Hubbard (33):
  mm/gup: add make_dirty arg to put_user_pages_dirty_lock()
  net/rds: convert put_page() to put_user_page*()
  net/ceph: convert put_page() to put_user_page*()
  x86/kvm: convert put_page() to put_user_page*()
  drm/etnaviv: convert release_pages() to put_user_pages()
  drm/i915: convert put_page() to put_user_page*()
  drm/radeon: convert put_page() to put_user_page*()
  media/ivtv: convert put_page() to put_user_page*()
  media/v4l2-core/mm: convert put_page() to put_user_page*()
  genwqe: convert put_page() to put_user_page*()
  scif: convert put_page() to put_user_page*()
  vmci: convert put_page() to put_user_page*()
  rapidio: convert put_page() to put_user_page*()
  oradax: convert put_page() to put_user_page*()
  staging/vc04_services: convert put_page() to put_user_page*()
  drivers/tee: convert put_page() to put_user_page*()
  vfio: convert put_page() to put_user_page*()
  fbdev/pvr2fb: convert put_page() to put_user_page*()
  fsl_hypervisor: convert put_page() to put_user_page*()
  xen: convert put_page() to put_user_page*()
  fs/exec.c: convert put_page() to put_user_page*()
  orangefs: convert put_page() to put_user_page*()
  uprobes: convert put_page() to put_user_page*()
  futex: convert put_page() to put_user_page*()
  mm/frame_vector.c: convert put_page() to put_user_page*()
  mm/gup_benchmark.c: convert put_page() to put_user_page*()
  mm/memory.c: convert put_page() to put_user_page*()
  mm/madvise.c: convert put_page() to put_user_page*()
  mm/process_vm_access.c: convert put_page() to put_user_page*()
  crypt: convert put_page() to put_user_page*()
  nfs: convert put_page() to put_user_page*()
  goldfish_pipe: convert put_page() to put_user_page*()
  kernel/events/core.c: convert put_page() to put_user_page*()

 arch/x86/kvm/svm.c|   4 +-
 crypto/af_alg.c   |   7 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem.c |   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |   9 +-
 drivers/gpu/drm/radeon/radeon_ttm.c   |   2 +-
 drivers/infiniband/core/umem.c|   5 +-
 drivers/infiniband/hw/hfi1/user_pages.c   |   5 +-
 drivers/infiniband/hw/qib/qib_user_pages.c|   5 +-
 drivers/infiniband/hw/usnic/usnic_uiom.c  |   5 +-
 drivers/infiniband/sw/siw/siw_mem.c   |  10 +-
 drivers/media/pci/ivtv/ivtv-udma.c|  14 +--
 drivers/media/pci/ivtv/ivtv-yuv.c |  10 +-
 drivers/media/v4l2-core/videobuf-dma-sg.c |   3 +-
 drivers/misc/genwqe/card_utils.c  |  17 +--
 drivers/misc/mic/scif/scif_rma.c  |  17 ++-
 drivers/misc/vmw_vmci/vmci_context.c  |   2 +-
 drivers/misc/vmw_vmci/vmci_queue_pair.c   |  11 +-
 drivers/platform/goldfish/goldfish_pipe.c |   9 +-
 drivers/rapidio/devices/rio_mport_cdev.c  |   9 +-
 drivers/sbus/char/oradax.c|   2 +-
 .../interface/vchiq_arm/vchiq_2835_arm.c  |  10 +-
 drivers/tee/tee_shm.c |  10 +-
 drivers/vfio/vfio_iommu_type1.c   |   8 +-
 

[PATCH 06/34] drm/i915: convert put_page() to put_user_page*()

2019-08-01 Thread john . hubbard
From: John Hubbard 

For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().

This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").

Note that this effectively changes the code's behavior in
i915_gem_userptr_put_pages(): it now calls set_page_dirty_lock(),
instead of set_page_dirty(). This is probably more accurate.

As Christophe Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [1]

[1] https://lore.kernel.org/r/20190723153640.gb...@lst.de

Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: David Airlie 
Cc: intel-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Hubbard 
---
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 528b61678334..c18008d3cc2a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -527,7 +527,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
}
mutex_unlock(>mm.lock);
 
-   release_pages(pvec, pinned);
+   put_user_pages(pvec, pinned);
kvfree(pvec);
 
i915_gem_object_put(obj);
@@ -640,7 +640,7 @@ static int i915_gem_userptr_get_pages(struct 
drm_i915_gem_object *obj)
__i915_gem_userptr_set_active(obj, true);
 
if (IS_ERR(pages))
-   release_pages(pvec, pinned);
+   put_user_pages(pvec, pinned);
kvfree(pvec);
 
return PTR_ERR_OR_ZERO(pages);
@@ -663,11 +663,8 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj,
i915_gem_gtt_finish_pages(obj, pages);
 
for_each_sgt_page(page, sgt_iter, pages) {
-   if (obj->mm.dirty)
-   set_page_dirty(page);
-
mark_page_accessed(page);
-   put_page(page);
+   put_user_pages_dirty_lock(, 1, obj->mm.dirty);
}
obj->mm.dirty = false;
 
-- 
2.22.0



[PATCH 10/34] genwqe: convert put_page() to put_user_page*()

2019-08-01 Thread john . hubbard
From: John Hubbard 

For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().

This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").

This changes the release code slightly, because each page slot in the
page_list[] array is no longer checked for NULL. However, that check
was wrong anyway, because the get_user_pages() pattern of usage here
never allowed for NULL entries within a range of pinned pages.

Cc: Frank Haverkamp 
Cc: "Guilherme G. Piccoli" 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: John Hubbard 
---
 drivers/misc/genwqe/card_utils.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/misc/genwqe/card_utils.c b/drivers/misc/genwqe/card_utils.c
index 2e1c4d2905e8..2a888f31d2c5 100644
--- a/drivers/misc/genwqe/card_utils.c
+++ b/drivers/misc/genwqe/card_utils.c
@@ -517,24 +517,13 @@ int genwqe_free_sync_sgl(struct genwqe_dev *cd, struct 
genwqe_sgl *sgl)
 /**
  * genwqe_free_user_pages() - Give pinned pages back
  *
- * Documentation of get_user_pages is in mm/gup.c:
- *
- * If the page is written to, set_page_dirty (or set_page_dirty_lock,
- * as appropriate) must be called after the page is finished with, and
- * before put_page is called.
+ * The pages may have been written to, so we call put_user_pages_dirty_lock(),
+ * rather than put_user_pages().
  */
 static int genwqe_free_user_pages(struct page **page_list,
unsigned int nr_pages, int dirty)
 {
-   unsigned int i;
-
-   for (i = 0; i < nr_pages; i++) {
-   if (page_list[i] != NULL) {
-   if (dirty)
-   set_page_dirty_lock(page_list[i]);
-   put_page(page_list[i]);
-   }
-   }
+   put_user_pages_dirty_lock(page_list, nr_pages, dirty);
return 0;
 }
 
-- 
2.22.0



[PATCH 12/34] vmci: convert put_page() to put_user_page*()

2019-08-01 Thread john . hubbard
From: John Hubbard 

For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().

This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").

Note that this effectively changes the code's behavior in
qp_release_pages(): it now ultimately calls set_page_dirty_lock(),
instead of set_page_dirty(). This is probably more accurate.

As Christophe Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [1]

[1] https://lore.kernel.org/r/20190723153640.gb...@lst.de

Cc: Arnd Bergmann 
Cc: Al Viro 
Cc: "Gustavo A. R. Silva" 
Cc: Kees Cook 
Signed-off-by: John Hubbard 
---
 drivers/misc/vmw_vmci/vmci_context.c|  2 +-
 drivers/misc/vmw_vmci/vmci_queue_pair.c | 11 ++-
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/misc/vmw_vmci/vmci_context.c 
b/drivers/misc/vmw_vmci/vmci_context.c
index 16695366ec92..9daa52ee63b7 100644
--- a/drivers/misc/vmw_vmci/vmci_context.c
+++ b/drivers/misc/vmw_vmci/vmci_context.c
@@ -587,7 +587,7 @@ void vmci_ctx_unset_notify(struct vmci_ctx *context)
 
if (notify_page) {
kunmap(notify_page);
-   put_page(notify_page);
+   put_user_page(notify_page);
}
 }
 
diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c 
b/drivers/misc/vmw_vmci/vmci_queue_pair.c
index 8531ae781195..e5434551d0ef 100644
--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
+++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
@@ -626,15 +626,8 @@ static void qp_release_queue_mutex(struct vmci_queue 
*queue)
 static void qp_release_pages(struct page **pages,
 u64 num_pages, bool dirty)
 {
-   int i;
-
-   for (i = 0; i < num_pages; i++) {
-   if (dirty)
-   set_page_dirty(pages[i]);
-
-   put_page(pages[i]);
-   pages[i] = NULL;
-   }
+   put_user_pages_dirty_lock(pages, num_pages, dirty);
+   memset(pages, 0, num_pages * sizeof(struct page *));
 }
 
 /*
-- 
2.22.0



[PATCH 04/34] x86/kvm: convert put_page() to put_user_page*()

2019-08-01 Thread john . hubbard
From: John Hubbard 

For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page().

This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").

Cc: Joerg Roedel 
Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: John Hubbard 
---
 arch/x86/kvm/svm.c  | 4 ++--
 virt/kvm/kvm_main.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 7eafc6907861..ff93c923ed36 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1827,7 +1827,7 @@ static struct page **sev_pin_memory(struct kvm *kvm, 
unsigned long uaddr,
 
 err:
if (npinned > 0)
-   release_pages(pages, npinned);
+   put_user_pages(pages, npinned);
 
kvfree(pages);
return NULL;
@@ -1838,7 +1838,7 @@ static void sev_unpin_memory(struct kvm *kvm, struct page 
**pages,
 {
struct kvm_sev_info *sev = _kvm_svm(kvm)->sev_info;
 
-   release_pages(pages, npages);
+   put_user_pages(pages, npages);
kvfree(pages);
sev->pages_locked -= npages;
 }
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 887f3b0c2b60..4b6a596ea8e9 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1499,7 +1499,7 @@ static int hva_to_pfn_slow(unsigned long addr, bool 
*async, bool write_fault,
 
if (__get_user_pages_fast(addr, 1, 1, ) == 1) {
*writable = true;
-   put_page(page);
+   put_user_page(page);
page = wpage;
}
}
@@ -1831,7 +1831,7 @@ EXPORT_SYMBOL_GPL(kvm_release_page_clean);
 void kvm_release_pfn_clean(kvm_pfn_t pfn)
 {
if (!is_error_noslot_pfn(pfn) && !kvm_is_reserved_pfn(pfn))
-   put_page(pfn_to_page(pfn));
+   put_user_page(pfn_to_page(pfn));
 }
 EXPORT_SYMBOL_GPL(kvm_release_pfn_clean);
 
-- 
2.22.0



[PATCH 07/34] drm/radeon: convert put_page() to put_user_page*()

2019-08-01 Thread john . hubbard
From: John Hubbard 

For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().

This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").

Cc: Alex Deucher 
Cc: Christian König 
Cc: David (ChunMing) Zhou 
Cc: David Airlie 
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Hubbard 
---
 drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index fb3696bc616d..4c9943fa10df 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -540,7 +540,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
kfree(ttm->sg);
 
 release_pages:
-   release_pages(ttm->pages, pinned);
+   put_user_pages(ttm->pages, pinned);
return r;
 }
 
-- 
2.22.0



Re: [PATCH 19/20] pstore: fs superblock limits

2019-08-01 Thread Deepa Dinamani
On Tue, Jul 30, 2019 at 12:36 AM Arnd Bergmann  wrote:
>
> On Tue, Jul 30, 2019 at 6:31 AM Kees Cook  wrote:
> >
> > On Mon, Jul 29, 2019 at 06:49:23PM -0700, Deepa Dinamani wrote:
> > > Also update the gran since pstore has microsecond granularity.
> >
> > So, I'm fine with this, but technically the granularity depends on the
> > backend storage... many have no actual time keeping, though. My point is,
> > pstore's timestamps are really mostly a lie, but the most common backend
> > (ramoops) is seconds-granularity.
> >
> > So, I'm fine with this, but it's a lie but it's a lie that doesn't
> > matter, so ...
> >
> > Acked-by: Kees Cook 
> >
> > I'm open to suggestions to improve it...
>
> If we don't care about using sub-second granularity, then setting it
> to one second unconditionally here will make it always use that and
> report it correctly.

Should this printf in ramoops_write_kmsg_hdr() also be fixed then?

RAMOOPS_KERNMSG_HDR "%lld.%06lu-%c\n",
(time64_t)record->time.tv_sec,
record->time.tv_nsec / 1000,
record->compressed ? 'C' : 'D');
persistent_ram_write(prz, hdr, len);

ramoops_read_kmsg_hdr() doesn't read this as microseconds. Seems like
a mismatch from above.

If we want to agree that we just want seconds granularity for pstore,
we could replace the tv_nsec part to be all 0's if anybody else is
depending on this format.
I could drop this patch from the series and post that patch seperately.

Thanks,
-Deepa


[PATCH 01/34] mm/gup: add make_dirty arg to put_user_pages_dirty_lock()

2019-08-01 Thread john . hubbard
From: John Hubbard 

Provide more capable variation of put_user_pages_dirty_lock(),
and delete put_user_pages_dirty(). This is based on the
following:

1. Lots of call sites become simpler if a bool is passed
into put_user_page*(), instead of making the call site
choose which put_user_page*() variant to call.

2. Christoph Hellwig's observation that set_page_dirty_lock()
is usually correct, and set_page_dirty() is usually a
bug, or at least questionable, within a put_user_page*()
calling chain.

This leads to the following API choices:

* put_user_pages_dirty_lock(page, npages, make_dirty)

* There is no put_user_pages_dirty(). You have to
  hand code that, in the rare case that it's
  required.

Cc: Matthew Wilcox 
Cc: Jan Kara 
Cc: Christoph Hellwig 
Cc: Ira Weiny 
Cc: Jason Gunthorpe 
Signed-off-by: John Hubbard 
---
 drivers/infiniband/core/umem.c |   5 +-
 drivers/infiniband/hw/hfi1/user_pages.c|   5 +-
 drivers/infiniband/hw/qib/qib_user_pages.c |   5 +-
 drivers/infiniband/hw/usnic/usnic_uiom.c   |   5 +-
 drivers/infiniband/sw/siw/siw_mem.c|  10 +-
 include/linux/mm.h |   5 +-
 mm/gup.c   | 115 +
 7 files changed, 58 insertions(+), 92 deletions(-)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 08da840ed7ee..965cf9dea71a 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -54,10 +54,7 @@ static void __ib_umem_release(struct ib_device *dev, struct 
ib_umem *umem, int d
 
for_each_sg_page(umem->sg_head.sgl, _iter, umem->sg_nents, 0) {
page = sg_page_iter_page(_iter);
-   if (umem->writable && dirty)
-   put_user_pages_dirty_lock(, 1);
-   else
-   put_user_page(page);
+   put_user_pages_dirty_lock(, 1, umem->writable && dirty);
}
 
sg_free_table(>sg_head);
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c 
b/drivers/infiniband/hw/hfi1/user_pages.c
index b89a9b9aef7a..469acb961fbd 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -118,10 +118,7 @@ int hfi1_acquire_user_pages(struct mm_struct *mm, unsigned 
long vaddr, size_t np
 void hfi1_release_user_pages(struct mm_struct *mm, struct page **p,
 size_t npages, bool dirty)
 {
-   if (dirty)
-   put_user_pages_dirty_lock(p, npages);
-   else
-   put_user_pages(p, npages);
+   put_user_pages_dirty_lock(p, npages, dirty);
 
if (mm) { /* during close after signal, mm can be NULL */
atomic64_sub(npages, >pinned_vm);
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c 
b/drivers/infiniband/hw/qib/qib_user_pages.c
index bfbfbb7e0ff4..6bf764e41891 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -40,10 +40,7 @@
 static void __qib_release_user_pages(struct page **p, size_t num_pages,
 int dirty)
 {
-   if (dirty)
-   put_user_pages_dirty_lock(p, num_pages);
-   else
-   put_user_pages(p, num_pages);
+   put_user_pages_dirty_lock(p, num_pages, dirty);
 }
 
 /**
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c 
b/drivers/infiniband/hw/usnic/usnic_uiom.c
index 0b0237d41613..62e6ffa9ad78 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom.c
@@ -75,10 +75,7 @@ static void usnic_uiom_put_pages(struct list_head 
*chunk_list, int dirty)
for_each_sg(chunk->page_list, sg, chunk->nents, i) {
page = sg_page(sg);
pa = sg_phys(sg);
-   if (dirty)
-   put_user_pages_dirty_lock(, 1);
-   else
-   put_user_page(page);
+   put_user_pages_dirty_lock(, 1, dirty);
usnic_dbg("pa: %pa\n", );
}
kfree(chunk);
diff --git a/drivers/infiniband/sw/siw/siw_mem.c 
b/drivers/infiniband/sw/siw/siw_mem.c
index 67171c82b0c4..ab83a9cec562 100644
--- a/drivers/infiniband/sw/siw/siw_mem.c
+++ b/drivers/infiniband/sw/siw/siw_mem.c
@@ -63,15 +63,7 @@ struct siw_mem *siw_mem_id2obj(struct siw_device *sdev, int 
stag_index)
 static void siw_free_plist(struct siw_page_chunk *chunk, int num_pages,
   bool dirty)
 {
-   struct page **p = chunk->plist;
-
-   while (num_pages--) {
-   if (!PageDirty(*p) && dirty)
-   put_user_pages_dirty_lock(p, 1);
-   else
-   put_user_page(*p);
-   p++;
-   }
+   put_user_pages_dirty_lock(chunk->plist, num_pages, dirty);
 }
 
 void siw_umem_release(struct siw_umem *umem, bool dirty)
diff --git 

[PATCH 02/34] net/rds: convert put_page() to put_user_page*()

2019-08-01 Thread john . hubbard
From: John Hubbard 

For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().

This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").

Cc: Santosh Shilimkar 
Cc: David S. Miller 
Cc: net...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc: rds-de...@oss.oracle.com
Signed-off-by: John Hubbard 
---
 net/rds/info.c|  5 ++---
 net/rds/message.c |  2 +-
 net/rds/rdma.c| 15 +++
 3 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/net/rds/info.c b/net/rds/info.c
index 03f6fd56d237..ca6af2889adf 100644
--- a/net/rds/info.c
+++ b/net/rds/info.c
@@ -162,7 +162,6 @@ int rds_info_getsockopt(struct socket *sock, int optname, 
char __user *optval,
struct rds_info_lengths lens;
unsigned long nr_pages = 0;
unsigned long start;
-   unsigned long i;
rds_info_func func;
struct page **pages = NULL;
int ret;
@@ -235,8 +234,8 @@ int rds_info_getsockopt(struct socket *sock, int optname, 
char __user *optval,
ret = -EFAULT;
 
 out:
-   for (i = 0; pages && i < nr_pages; i++)
-   put_page(pages[i]);
+   if (pages)
+   put_user_pages(pages, nr_pages);
kfree(pages);
 
return ret;
diff --git a/net/rds/message.c b/net/rds/message.c
index 50f13f1d4ae0..d7b0d266c437 100644
--- a/net/rds/message.c
+++ b/net/rds/message.c
@@ -404,7 +404,7 @@ static int rds_message_zcopy_from_user(struct rds_message 
*rm, struct iov_iter *
int i;
 
for (i = 0; i < rm->data.op_nents; i++)
-   put_page(sg_page(>data.op_sg[i]));
+   put_user_page(sg_page(>data.op_sg[i]));
mmp = >data.op_mmp_znotifier->z_mmp;
mm_unaccount_pinned_pages(mmp);
ret = -EFAULT;
diff --git a/net/rds/rdma.c b/net/rds/rdma.c
index 916f5ec373d8..6762e8696b99 100644
--- a/net/rds/rdma.c
+++ b/net/rds/rdma.c
@@ -162,8 +162,7 @@ static int rds_pin_pages(unsigned long user_addr, unsigned 
int nr_pages,
  pages);
 
if (ret >= 0 && ret < nr_pages) {
-   while (ret--)
-   put_page(pages[ret]);
+   put_user_pages(pages, ret);
ret = -EFAULT;
}
 
@@ -276,7 +275,7 @@ static int __rds_rdma_map(struct rds_sock *rs, struct 
rds_get_mr_args *args,
 
if (IS_ERR(trans_private)) {
for (i = 0 ; i < nents; i++)
-   put_page(sg_page([i]));
+   put_user_page(sg_page([i]));
kfree(sg);
ret = PTR_ERR(trans_private);
goto out;
@@ -464,9 +463,10 @@ void rds_rdma_free_op(struct rm_rdma_op *ro)
 * to local memory */
if (!ro->op_write) {
WARN_ON(!page->mapping && irqs_disabled());
-   set_page_dirty(page);
+   put_user_pages_dirty_lock(, 1, true);
+   } else {
+   put_user_page(page);
}
-   put_page(page);
}
 
kfree(ro->op_notifier);
@@ -481,8 +481,7 @@ void rds_atomic_free_op(struct rm_atomic_op *ao)
/* Mark page dirty if it was possibly modified, which
 * is the case for a RDMA_READ which copies from remote
 * to local memory */
-   set_page_dirty(page);
-   put_page(page);
+   put_user_pages_dirty_lock(, 1, true);
 
kfree(ao->op_notifier);
ao->op_notifier = NULL;
@@ -867,7 +866,7 @@ int rds_cmsg_atomic(struct rds_sock *rs, struct rds_message 
*rm,
return ret;
 err:
if (page)
-   put_page(page);
+   put_user_page(page);
rm->atomic.op_active = 0;
kfree(rm->atomic.op_notifier);
 
-- 
2.22.0



Re: [PATCH v2] watchdog: alim1535: Rewriting of alim1535 to use watchdog subsystem

2019-08-01 Thread Guenter Roeck
On Thu, Aug 01, 2019 at 01:58:34PM -0700, Mark Balantzyan wrote:
> This patch rewrites the alim1535_wdt driver to use the watchdog subsystem. By 
> virtue of this, it also fixes a potential race condition between 
> ali_timeout_bits and ali_settimer().
> 
There is no such race condition, as I explained (or tried
to explain) before. Your tool does not take into account
that the device can only be opened exactly once.

Your description exceeds 75 columns.

> Signed-off-by: Mark Balantzyan 
> ---
>  drivers/watchdog/Kconfig|   1 +
>  drivers/watchdog/alim1535_wdt.c | 275 +---
>  2 files changed, 37 insertions(+), 239 deletions(-)
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 9af07fd9..980b0c90 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -853,6 +853,7 @@ config ADVANTECH_WDT
>  
>  config ALIM1535_WDT
>   tristate "ALi M1535 PMU Watchdog Timer"
> + select WATCHDOG_CORE
>   depends on X86 && PCI
>   ---help---
> This is the driver for the hardware watchdog on the ALi M1535 PMU.
> diff --git a/drivers/watchdog/alim1535_wdt.c b/drivers/watchdog/alim1535_wdt.c
> index 60f0c2eb..55648ba8 100644
> --- a/drivers/watchdog/alim1535_wdt.c
> +++ b/drivers/watchdog/alim1535_wdt.c
> @@ -12,26 +12,18 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 

Not needed.

> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
>  #include 

No longer needed.

>  #include 

Not needed.

> +#include 

Why did you move this include file ?

>  
>  #define WATCHDOG_NAME "ALi_M1535"
>  #define WATCHDOG_TIMEOUT 60  /* 60 sec default timeout */
>  
>  /* internal variables */
> -static unsigned long ali_is_open;
> -static char ali_expect_release;
>  static struct pci_dev *ali_pci;
>  static u32 ali_timeout_bits; /* stores the computed timeout */
> -static DEFINE_SPINLOCK(ali_lock);/* Guards the hardware */
>  
>  /* module parameters */
>  static int timeout = WATCHDOG_TIMEOUT;

Should be set to 0.

> @@ -53,18 +45,15 @@ MODULE_PARM_DESC(nowayout,
>   *   configuration set.
>   */
>  
> -static void ali_start(void)
> +static int ali_start(struct watchdog_device *wdd)
>  {
>   u32 val;
>  
> - spin_lock(_lock);
> -

Side note: Presumably this lock was supposed to guard
accesses to the PCI configuration register by other
drivers, but it never did that. The lock was useless
from the beginning.

>   pci_read_config_dword(ali_pci, 0xCC, );
>   val &= ~0x3F;   /* Mask count */
>   val |= (1 << 25) | ali_timeout_bits;
>   pci_write_config_dword(ali_pci, 0xCC, val);
> -
> - spin_unlock(_lock);
> + return 0;
>  }
>  
>  /*
> @@ -73,18 +62,15 @@ static void ali_start(void)
>   *   Stop the ALi watchdog countdown
>   */
>  
> -static void ali_stop(void)
> +static int ali_stop(struct watchdog_device *wdd)
>  {
>   u32 val;
>  
> - spin_lock(_lock);
> -
>   pci_read_config_dword(ali_pci, 0xCC, );
>   val &= ~0x3F;   /* Mask count to zero (disabled) */
>   val &= ~(1 << 25);  /* and for safety mask the reset enable */
>   pci_write_config_dword(ali_pci, 0xCC, val);
> -
> - spin_unlock(_lock);
> + return 0;
>  }
>  
>  /*
> @@ -93,32 +79,24 @@ static void ali_stop(void)
>   *   Send a keepalive to the timer (actually we restart the timer).
>   */
>  
> -static void ali_keepalive(void)
> +static int ali_keepalive(struct watchdog_device *wdd)
>  {
> - ali_start();
> + ali_start(wdd);
> + return 0;
>  }

If the keepalive function does nothing but call the start function,
it can be omitted.

>  
>  /*
> - *   ali_settimer-   compute the timer reload value
> + *   ali_set_timeout -   compute the timer reload value
>   *   @t: time in seconds
>   *
>   *   Computes the timeout values needed
>   */
>  
> -static int ali_settimer(int t)
> +static int ali_set_timeout(struct watchdog_device *wdd, unsigned int t)
>  {
> - if (t < 0)
> - return -EINVAL;
> - else if (t < 60)
> - ali_timeout_bits = t|(1 << 6);
> - else if (t < 3600)
> - ali_timeout_bits = (t / 60)|(1 << 7);
> - else if (t < 18000)
> - ali_timeout_bits = (t / 300)|(1 << 6)|(1 << 7);
> - else
> - return -EINVAL;
> -
> - timeout = t;
> + wdd->max_timeout = 60;
> + wdd->min_timeout = 1;

This is wrong. max_timeout and min_timeout must be set in the
static declaration of struct watchdog_device. Similar,
wdd.timeout should be initialized there with WATCHDOG_TIMEOUT.

Also, a maximum of 60 seconds does not make sense. The (old)
code above clearly accepts timeouts up to 17999 seconds.

Where is ali_timeout_bits now initialized ?

> + wdd->timeout = t;

wdd->timeout needs to be set to the actual timeout. Per
the above (old) code, this is either a multiple of seconds,
minutes, or five minutes, depending on the requested timeout
value. For 

Re: [PATCH 7/9] clk: sprd: Don't reference clk_init_data after registration

2019-08-01 Thread Chunyan Zhang
On Thu, 1 Aug 2019 at 03:35, Stephen Boyd  wrote:
>
> A future patch is going to change semantics of clk_register() so that
> clk_hw::init is guaranteed to be NULL after a clk is registered. Avoid
> referencing this member here so that we don't run into NULL pointer
> exceptions.
>
> Cc: Chunyan Zhang 
> Cc: Baolin Wang 
> Signed-off-by: Stephen Boyd 
> ---
>
> Please ack so I can take this through clk tree

Acked-by: Chunyan Zhang 

Thanks.

>
>  drivers/clk/sprd/common.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/sprd/common.c b/drivers/clk/sprd/common.c
> index a5bdca1de5d0..9d56eac43832 100644
> --- a/drivers/clk/sprd/common.c
> +++ b/drivers/clk/sprd/common.c
> @@ -76,16 +76,17 @@ int sprd_clk_probe(struct device *dev, struct 
> clk_hw_onecell_data *clkhw)
> struct clk_hw *hw;
>
> for (i = 0; i < clkhw->num; i++) {
> +   const char *name;
>
> hw = clkhw->hws[i];
> -
> if (!hw)
> continue;
>
> +   name = hw->init->name;
> ret = devm_clk_hw_register(dev, hw);
> if (ret) {
> dev_err(dev, "Couldn't register clock %d - %s\n",
> -   i, hw->init->name);
> +   i, name);
> return ret;
> }
> }
> --
> Sent by a computer through tubes
>


[PATCH 1/2] mm/zsmalloc.c: Migration can leave pages in ZS_EMPTY indefinitely

2019-08-01 Thread Henry Burns
In zs_page_migrate() we call putback_zspage() after we have finished
migrating all pages in this zspage. However, the return value is ignored.
If a zs_free() races in between zs_page_isolate() and zs_page_migrate(),
freeing the last object in the zspage, putback_zspage() will leave the page
in ZS_EMPTY for potentially an unbounded amount of time.

To fix this, we need to do the same thing as zs_page_putback() does:
schedule free_work to occur.  To avoid duplicated code, move the
sequence to a new putback_zspage_deferred() function which both
zs_page_migrate() and zs_page_putback() call.

Signed-off-by: Henry Burns 
---
 mm/zsmalloc.c | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 1cda3fe0c2d9..efa660a87787 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1901,6 +1901,22 @@ static void dec_zspage_isolation(struct zspage *zspage)
zspage->isolated--;
 }
 
+static void putback_zspage_deferred(struct zs_pool *pool,
+   struct size_class *class,
+   struct zspage *zspage)
+{
+   enum fullness_group fg;
+
+   fg = putback_zspage(class, zspage);
+   /*
+* Due to page_lock, we cannot free zspage immediately
+* so let's defer.
+*/
+   if (fg == ZS_EMPTY)
+   schedule_work(>free_work);
+
+}
+
 static void replace_sub_page(struct size_class *class, struct zspage *zspage,
struct page *newpage, struct page *oldpage)
 {
@@ -2070,7 +2086,7 @@ static int zs_page_migrate(struct address_space *mapping, 
struct page *newpage,
 * the list if @page is final isolated subpage in the zspage.
 */
if (!is_zspage_isolated(zspage))
-   putback_zspage(class, zspage);
+   putback_zspage_deferred(pool, class, zspage);
 
reset_page(page);
put_page(page);
@@ -2115,15 +2131,9 @@ static void zs_page_putback(struct page *page)
 
spin_lock(>lock);
dec_zspage_isolation(zspage);
-   if (!is_zspage_isolated(zspage)) {
-   fg = putback_zspage(class, zspage);
-   /*
-* Due to page_lock, we cannot free zspage immediately
-* so let's defer.
-*/
-   if (fg == ZS_EMPTY)
-   schedule_work(>free_work);
-   }
+   if (!is_zspage_isolated(zspage))
+   putback_zspage_deferred(pool, class, zspage);
+
spin_unlock(>lock);
 }
 
-- 
2.22.0.770.g0f2c4a37fd-goog



[PATCH 2/2] mm/zsmalloc.c: Fix race condition in zs_destroy_pool

2019-08-01 Thread Henry Burns
In zs_destroy_pool() we call flush_work(>free_work). However, we
have no guarantee that migration isn't happening in the background
at that time.

Since migration can't directly free pages, it relies on free_work
being scheduled to free the pages.  But there's nothing preventing an
in-progress migrate from queuing the work *after*
zs_unregister_migration() has called flush_work().  Which would mean
pages still pointing at the inode when we free it.

Since we know at destroy time all objects should be free, no new
migrations can come in (since zs_page_isolate() fails for fully-free
zspages).  This means it is sufficient to track a "# isolated zspages"
count by class, and have the destroy logic ensure all such pages have
drained before proceeding.  Keeping that state under the class
spinlock keeps the logic straightforward.

Signed-off-by: Henry Burns 
---
 mm/zsmalloc.c | 68 ---
 1 file changed, 65 insertions(+), 3 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index efa660a87787..1f16ed4d6a13 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -53,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -206,6 +207,10 @@ struct size_class {
int objs_per_zspage;
/* Number of PAGE_SIZE sized pages to combine to form a 'zspage' */
int pages_per_zspage;
+#ifdef CONFIG_COMPACTION
+   /* Number of zspages currently isolated by compaction */
+   int isolated;
+#endif
 
unsigned int index;
struct zs_size_stat stats;
@@ -267,6 +272,8 @@ struct zs_pool {
 #ifdef CONFIG_COMPACTION
struct inode *inode;
struct work_struct free_work;
+   /* A workqueue for when migration races with async_free_zspage() */
+   struct wait_queue_head migration_wait;
 #endif
 };
 
@@ -1917,6 +1924,21 @@ static void putback_zspage_deferred(struct zs_pool *pool,
 
 }
 
+static inline void zs_class_dec_isolated(struct zs_pool *pool,
+struct size_class *class)
+{
+   assert_spin_locked(>lock);
+   VM_BUG_ON(class->isolated <= 0);
+   class->isolated--;
+   /*
+* There's no possibility of racing, since wait_for_isolated_drain()
+* checks the isolated count under >lock after enqueuing
+* on migration_wait.
+*/
+   if (class->isolated == 0 && waitqueue_active(>migration_wait))
+   wake_up_all(>migration_wait);
+}
+
 static void replace_sub_page(struct size_class *class, struct zspage *zspage,
struct page *newpage, struct page *oldpage)
 {
@@ -1986,6 +2008,7 @@ static bool zs_page_isolate(struct page *page, 
isolate_mode_t mode)
 */
if (!list_empty(>list) && !is_zspage_isolated(zspage)) {
get_zspage_mapping(zspage, _idx, );
+   class->isolated++;
remove_zspage(class, zspage, fullness);
}
 
@@ -2085,8 +2108,14 @@ static int zs_page_migrate(struct address_space 
*mapping, struct page *newpage,
 * Page migration is done so let's putback isolated zspage to
 * the list if @page is final isolated subpage in the zspage.
 */
-   if (!is_zspage_isolated(zspage))
+   if (!is_zspage_isolated(zspage)) {
+   /*
+* We still hold the class lock while all of this is happening,
+* so we cannot race with zs_destroy_pool()
+*/
putback_zspage_deferred(pool, class, zspage);
+   zs_class_dec_isolated(pool, class);
+   }
 
reset_page(page);
put_page(page);
@@ -2131,9 +2160,11 @@ static void zs_page_putback(struct page *page)
 
spin_lock(>lock);
dec_zspage_isolation(zspage);
-   if (!is_zspage_isolated(zspage))
-   putback_zspage_deferred(pool, class, zspage);
 
+   if (!is_zspage_isolated(zspage)) {
+   putback_zspage_deferred(pool, class, zspage);
+   zs_class_dec_isolated(pool, class);
+   }
spin_unlock(>lock);
 }
 
@@ -2156,8 +2187,36 @@ static int zs_register_migration(struct zs_pool *pool)
return 0;
 }
 
+static bool class_isolated_are_drained(struct size_class *class)
+{
+   bool ret;
+
+   spin_lock(>lock);
+   ret = class->isolated == 0;
+   spin_unlock(>lock);
+   return ret;
+}
+
+/* Function for resolving migration */
+static void wait_for_isolated_drain(struct zs_pool *pool)
+{
+   int i;
+
+   /*
+* We're in the process of destroying the pool, so there are no
+* active allocations. zs_page_isolate() fails for completely free
+* zspages, so we need only wait for each size_class's isolated
+* count to hit zero.
+*/
+   for (i = 0; i < ZS_SIZE_CLASSES; i++) {
+   wait_event(pool->migration_wait,
+  class_isolated_are_drained(pool->size_class[i]));
+   }
+}
+
 static void 

[PATCH v2 10/10] watchdog: Replace strncmp with str_has_prefix

2019-08-01 Thread Chuhong Yuan
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix
to substitute such strncmp.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Revise the description.

 kernel/watchdog.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 7f9e7b9306fe..ac7a4b5f856e 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -70,13 +70,13 @@ void __init hardlockup_detector_disable(void)
 
 static int __init hardlockup_panic_setup(char *str)
 {
-   if (!strncmp(str, "panic", 5))
+   if (str_has_prefix(str, "panic"))
hardlockup_panic = 1;
-   else if (!strncmp(str, "nopanic", 7))
+   else if (str_has_prefix(str, "nopanic"))
hardlockup_panic = 0;
-   else if (!strncmp(str, "0", 1))
+   else if (str_has_prefix(str, "0"))
nmi_watchdog_user_enabled = 0;
-   else if (!strncmp(str, "1", 1))
+   else if (str_has_prefix(str, "1"))
nmi_watchdog_user_enabled = 1;
return 1;
 }
-- 
2.20.1



[PATCH v2 07/10] reboot: Replace strncmp with str_has_prefix

2019-08-01 Thread Chuhong Yuan
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix
to substitute such strncmp.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Revise the description.
  - Utilize str_has_prefix's return value to
eliminate some hard codes.

 kernel/reboot.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/kernel/reboot.c b/kernel/reboot.c
index c4d472b7f1b4..addb52391177 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -520,6 +520,8 @@ EXPORT_SYMBOL_GPL(orderly_reboot);
 
 static int __init reboot_setup(char *str)
 {
+   size_t len;
+
for (;;) {
enum reboot_mode *mode;
 
@@ -530,9 +532,9 @@ static int __init reboot_setup(char *str)
 */
reboot_default = 0;
 
-   if (!strncmp(str, "panic_", 6)) {
+   if ((len = str_has_prefix(str, "panic_"))) {
mode = _reboot_mode;
-   str += 6;
+   str += len;
} else {
mode = _mode;
}
-- 
2.20.1



[PATCH v2 09/10] userns: Replace strncmp with str_has_prefix

2019-08-01 Thread Chuhong Yuan
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix
to substitute such strncmp.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Revise the description.
  - Utilize str_has_prefix's return value to
eliminate some hard codes.

 kernel/user_namespace.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index 8eadadc478f9..e231e902df8a 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -1138,6 +1138,7 @@ ssize_t proc_setgroups_write(struct file *file, const 
char __user *buf,
char kbuf[8], *pos;
bool setgroups_allowed;
ssize_t ret;
+   size_t len;
 
/* Only allow a very narrow range of strings to be written */
ret = -EINVAL;
@@ -1153,12 +1154,11 @@ ssize_t proc_setgroups_write(struct file *file, const 
char __user *buf,
 
/* What is being requested? */
ret = -EINVAL;
-   if (strncmp(pos, "allow", 5) == 0) {
-   pos += 5;
+   if ((len = str_has_prefix(pos, "allow"))) {
+   pos += len;
setgroups_allowed = true;
-   }
-   else if (strncmp(pos, "deny", 4) == 0) {
-   pos += 4;
+   } else if ((len = str_has_prefix(pos, "deny"))) {
+   pos += len;
setgroups_allowed = false;
}
else
-- 
2.20.1



[PATCH v2 03/10] locking/locktorture: Replace strncmp with str_has_prefix

2019-08-01 Thread Chuhong Yuan
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix
to substitute such strncmp.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Newly detected in upstream.

 kernel/locking/locktorture.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
index c513031cd7e3..8dd900247205 100644
--- a/kernel/locking/locktorture.c
+++ b/kernel/locking/locktorture.c
@@ -889,16 +889,16 @@ static int __init lock_torture_init(void)
cxt.nrealwriters_stress = 2 * num_online_cpus();
 
 #ifdef CONFIG_DEBUG_MUTEXES
-   if (strncmp(torture_type, "mutex", 5) == 0)
+   if (str_has_prefix(torture_type, "mutex"))
cxt.debug_lock = true;
 #endif
 #ifdef CONFIG_DEBUG_RT_MUTEXES
-   if (strncmp(torture_type, "rtmutex", 7) == 0)
+   if (str_has_prefix(torture_type, "rtmutex"))
cxt.debug_lock = true;
 #endif
 #ifdef CONFIG_DEBUG_SPINLOCK
-   if ((strncmp(torture_type, "spin", 4) == 0) ||
-   (strncmp(torture_type, "rw_lock", 7) == 0))
+   if ((str_has_prefix(torture_type, "spin")) ||
+   (str_has_prefix(torture_type, "rw_lock")))
cxt.debug_lock = true;
 #endif
 
-- 
2.20.1



[PATCH v2 05/10] PM / sleep: Replace strncmp with str_has_prefix

2019-08-01 Thread Chuhong Yuan
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix
to substitute such strncmp.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Revise the description.

 kernel/power/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/power/main.c b/kernel/power/main.c
index bdbd605c4215..5e5f64bb3a43 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -495,7 +495,7 @@ static suspend_state_t decode_state(const char *buf, size_t 
n)
len = p ? p - buf : n;
 
/* Check hibernation first. */
-   if (len == 4 && !strncmp(buf, "disk", len))
+   if (len == 4 && str_has_prefix(buf, "disk"))
return PM_SUSPEND_MAX;
 
 #ifdef CONFIG_SUSPEND
-- 
2.20.1



[PATCH v2 06/10] printk: Replace strncmp with str_has_prefix

2019-08-01 Thread Chuhong Yuan
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix
to substitute such strncmp.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Revise the description.
  - Utilize str_has_prefix's return value to
eliminate some hard codes.

 kernel/printk/braille.c | 10 ++
 kernel/printk/printk.c  | 14 --
 2 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/kernel/printk/braille.c b/kernel/printk/braille.c
index 1d21ebacfdb8..e451b8b1d3d5 100644
--- a/kernel/printk/braille.c
+++ b/kernel/printk/braille.c
@@ -11,11 +11,13 @@
 
 int _braille_console_setup(char **str, char **brl_options)
 {
-   if (!strncmp(*str, "brl,", 4)) {
+   size_t len;
+
+   if ((len = str_has_prefix(*str, "brl,"))) {
*brl_options = "";
-   *str += 4;
-   } else if (!strncmp(*str, "brl=", 4)) {
-   *brl_options = *str + 4;
+   *str += len;
+   } else if ((len = str_has_prefix(*str, "brl="))) {
+   *brl_options = *str + len;
*str = strchr(*brl_options, ',');
if (!*str) {
pr_err("need port name after brl=\n");
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 1888f6a3b694..21b28c7dd18f 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -118,18 +118,20 @@ static unsigned int __read_mostly devkmsg_log = 
DEVKMSG_LOG_MASK_DEFAULT;
 
 static int __control_devkmsg(char *str)
 {
+   size_t len;
+
if (!str)
return -EINVAL;
 
-   if (!strncmp(str, "on", 2)) {
+   if ((len = str_has_prefix(str, "on"))) {
devkmsg_log = DEVKMSG_LOG_MASK_ON;
-   return 2;
-   } else if (!strncmp(str, "off", 3)) {
+   return len;
+   } else if ((len = str_has_prefix(str, "off"))) {
devkmsg_log = DEVKMSG_LOG_MASK_OFF;
-   return 3;
-   } else if (!strncmp(str, "ratelimit", 9)) {
+   return len;
+   } else if ((len = str_has_prefix(str, "ratelimit"))) {
devkmsg_log = DEVKMSG_LOG_MASK_DEFAULT;
-   return 9;
+   return len;
}
return -EINVAL;
 }
-- 
2.20.1



[PATCH v2 08/10] sched: Replace strncmp with str_has_prefix

2019-08-01 Thread Chuhong Yuan
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix
to substitute such strncmp.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Revise the description.
  - Utilize str_has_prefix's return value to
eliminate some hard codes.

 kernel/sched/debug.c | 5 +++--
 kernel/sched/isolation.c | 9 +
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index f7e4579e746c..43983ff325b7 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -102,10 +102,11 @@ static int sched_feat_set(char *cmp)
 {
int i;
int neg = 0;
+   size_t len;
 
-   if (strncmp(cmp, "NO_", 3) == 0) {
+   if ((len = str_has_prefix(cmp, "NO_"))) {
neg = 1;
-   cmp += 3;
+   cmp += len;
}
 
i = match_string(sched_feat_names, __SCHED_FEAT_NR, cmp);
diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index ccb28085b114..f528bb5996f4 100644
--- a/kernel/sched/isolation.c
+++ b/kernel/sched/isolation.c
@@ -141,16 +141,17 @@ __setup("nohz_full=", housekeeping_nohz_full_setup);
 static int __init housekeeping_isolcpus_setup(char *str)
 {
unsigned int flags = 0;
+   size_t len;
 
while (isalpha(*str)) {
-   if (!strncmp(str, "nohz,", 5)) {
-   str += 5;
+   if ((len = str_has_prefix(str, "nohz,"))) {
+   str += len;
flags |= HK_FLAG_TICK;
continue;
}
 
-   if (!strncmp(str, "domain,", 7)) {
-   str += 7;
+   if ((len = str_has_prefix(str, "domain,"))) {
+   str += len;
flags |= HK_FLAG_DOMAIN;
continue;
}
-- 
2.20.1



[PATCH v2 04/10] module: Replace strncmp with str_has_prefix

2019-08-01 Thread Chuhong Yuan
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix
to substitute such strncmp.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Revise the description.

 kernel/module.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/module.c b/kernel/module.c
index 5933395af9a0..7defa2a4a701 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2251,7 +2251,7 @@ static int simplify_symbols(struct module *mod, const 
struct load_info *info)
switch (sym[i].st_shndx) {
case SHN_COMMON:
/* Ignore common symbols */
-   if (!strncmp(name, "__gnu_lto", 9))
+   if (str_has_prefix(name, "__gnu_lto"))
break;
 
/* We compiled with -fno-common.  These are not
-- 
2.20.1



[PATCH v2 02/10] gcov: Replace strncmp with str_has_prefix

2019-08-01 Thread Chuhong Yuan
strncmp(str, const, len) is error-prone because len
is easy to have typo.
The example is the hard-coded len has counting error
or sizeof(const) forgets - 1.
So we prefer using newly introduced str_has_prefix
to substitute such strncmp.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Revise the description.

 kernel/gcov/fs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/gcov/fs.c b/kernel/gcov/fs.c
index e5eb5ea7ea59..67296c1768b4 100644
--- a/kernel/gcov/fs.c
+++ b/kernel/gcov/fs.c
@@ -354,7 +354,7 @@ static char *get_link_target(const char *filename, const 
struct gcov_link *ext)
  */
 static const char *deskew(const char *basename)
 {
-   if (strncmp(basename, SKEW_PREFIX, sizeof(SKEW_PREFIX) - 1) == 0)
+   if (str_has_prefix(basename, SKEW_PREFIX))
return basename + sizeof(SKEW_PREFIX) - 1;
return basename;
 }
-- 
2.20.1



Re: [PATCH] ima: Allow to import the blacklisted cert signed by secondary CA cert

2019-08-01 Thread Jia Zhang



On 2019/8/2 上午6:57, Mimi Zohar wrote:
> Hi Jia,
> 
> On Thu, 2019-08-01 at 09:23 +0800, Jia Zhang wrote:
>> Similar to .ima, the cert imported to .ima_blacklist is able to be
>> authenticated by a secondary CA cert.
>>
>> Signed-off-by: Jia Zhang 
> 
> The IMA blacklist, which is defined as experimental for a reason, was
> upstreamed prior to the system blacklist.  Any reason you're not using
> the system blacklist?  Before making this sort of change, I'd like
> some input from others.

In our trusted cloud service, the IMA private key is controlled by
tenant for some reason. Some unprofessional operations made by tenant
may lead to the leakage of IMA private key. So the need for importing
the blacklisted is necessary,without system/kexec reboot, on the
contrary, the system blacklist needs a kernel rebuild and system/kexec
reboot, without runtime and fine-grained control.

The secondary CA cert has a similar story, but it is not controlled by
tenant. It is always imported during system/kexec boot to serve
importing IMA trusted cert and IMA blacklisted cert.

Jia

> 
> thanks,
> 
> Mimi
> 


Re: [PATCH] linux/bits.h: Add compile time sanity check of GENMASK inputs

2019-08-01 Thread Masahiro Yamada
On Thu, Aug 1, 2019 at 4:27 AM Joe Perches  wrote:
>
> On Wed, 2019-07-31 at 21:03 +0200, Rikard Falkeborn wrote:
> > GENMASK() and GENMASK_ULL() are supposed to be called with the high bit
> > as the first argument and the low bit as the second argument. Mixing
> > them will return a mask with zero bits set.
> >
> > Recent commits show getting this wrong is not uncommon, see e.g.
> > commit aa4c0c9091b0 ("net: stmmac: Fix misuses of GENMASK macro") and
> > commit 9bdd7bb3a844 ("clocksource/drivers/npcm: Fix misuse of GENMASK
> > macro").
> >
> > To prevent such mistakes from appearing again, add compile time sanity
> > checking to the arguments of GENMASK() and GENMASK_ULL(). If both the
> > arguments are known at compile time, and the low bit is higher than the
> > high bit, break the build to detect the mistake immediately.
> >
> > Since GENMASK() is used in declarations, BUILD_BUG_OR_ZERO() must be
> > used instead of BUILD_BUG_ON(), and __is_constexpr() must be used instead
> > of __builtin_constant_p().
> >
> > Commit 95b980d62d52 ("linux/bits.h: make BIT(), GENMASK(), and friends
> > available in assembly") made the macros in linux/bits.h available in
> > assembly. Since neither BUILD_BUG_OR_ZERO() or __is_constexpr() are asm
> > compatible, disable the checks if the file is included in an asm file.
> >
> > Signed-off-by: Rikard Falkeborn 
> > ---
> > Joe Perches sent a series to fix the existing misuses of GENMASK() that
> > needs to be merged before this to avoid build failures. Currently, 7 of
> > the patches were not in Linus tree, and 2 were not in linux-next.
> >
> > Also, there's currently no asm users of bits.h, but since it was made
> > asm-compatible just two weeks ago it would be a shame to break it right
> > away...
> []
> > diff --git a/include/linux/bits.h b/include/linux/bits.h
> []
> > @@ -18,12 +18,22 @@
> >   * position @h. For example
> >   * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0.
> >   */
> > +#ifndef __ASSEMBLY__
> > +#include 
> > +#define GENMASK_INPUT_CHECK(h, l)  
> > BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
> > + __is_constexpr(h) && __is_constexpr(l), (l) > (h), 0))
> > +#else
> > +#define GENMASK_INPUT_CHECK(h, l) 0
>
> A few things:
>
> o Reading the final code is a bit confusing.
>   Perhaps add a comment description saying it's not checked
>   in asm .h uses.
>
> o Maybe use:
>   #define GENMASK_INPUT_CHECK(h, l) UL(0)

Why?


> o The compiler error message when the arguments are in the
>   wrong order isn't obvious.  Is there some way to improve
>   the compiler error output, maybe by using BUILD_BUG_ON_MSG
>   or some other mechanism?
>
>


-- 
Best Regards
Masahiro Yamada


Re: [BUG] lseek on /proc/meminfo is broken in 4.19.59 maybe due to commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface")

2019-08-01 Thread Sergei Turchanov

Hello!

Yes, your patch fixed this bug.
Thank you very much!

With best regards,
Sergei.

On 01.08.2019 19:14, NeilBrown wrote:

On Thu, Aug 01 2019, Sergei Turchanov wrote:


Hello!

[
   As suggested in previous discussion this behavior may be caused by your
   commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and 
interface")
]

Yes I think I can see what happened.
  removing:
-   if (!m->count) {
-   m->from = 0;
-   m->index++;
-   }

from seq_read meant that ->index didn't get updated in a case that it
needs to be.

Please confirm that the following patch fixes the problem.
I think it is correct, but I need to look it over more carefully in the
morning, and see if I can explain why it is correct.

Thanks for the report.
NeilBrown

diff --git a/fs/seq_file.c b/fs/seq_file.c
index 04f09689cd6d..1600034a929b 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -119,6 +119,7 @@ static int traverse(struct seq_file *m, loff_t offset)
}
if (seq_has_overflowed(m))
goto Eoverflow;
+   p = m->op->next(m, p, >index);
if (pos + m->count > offset) {
m->from = offset - pos;
m->count -= m->from;
@@ -126,7 +127,6 @@ static int traverse(struct seq_file *m, loff_t offset)
}
pos += m->count;
m->count = 0;
-   p = m->op->next(m, p, >index);
if (pos == offset)
break;
}



Original bug report:

Seeking (to an offset within file size) in /proc/meminfo is broken in 4.19.59. 
It does seek to a desired position, but reading from that position returns the 
remainder of file and then a whole copy of file. This doesn't happen with 
/proc/vmstat or /proc/self/maps for example.

Seeking did work correctly in kernel 4.14.47. So it seems something broke in 
the way.

Background: this kind of access pattern (seeking to /proc/meminfo) is used by 
libvirt-lxc fuse driver for virtualized view of /proc/meminfo. So that 
/proc/meminfo is broken in guests when running kernel 4.19.x.

  > On 01.08.2019 17:11, Gao Xiang wrote:

Hi,

I just took a glance, maybe due to
commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and 
interface")

I simply reverted it just now and it seems fine... but I haven't digged into 
this commit.

Maybe you could Cc NeilBrown  for some more advice and
I have no idea whether it's an expected behavior or not...

Thanks,
Gao Xiang

On 2019/8/1 14:16, Sergei Turchanov wrote:


$ ./test /proc/meminfo 0    # Works as expected

MemTotal:   394907728 kB
MemFree:    173738328 kB
...
DirectMap2M:    13062144 kB
DirectMap1G:    390070272 kB

---

$ ./test /proc/meminfo 1024 # returns a copy of file after the remainder

Will seek to 1024


Data read at offset 1024
gePages: 0 kB
ShmemHugePages:    0 kB
ShmemPmdMapped:    0 kB
HugePages_Total:   0
HugePages_Free:    0
HugePages_Rsvd:    0
HugePages_Surp:    0
Hugepagesize:   2048 kB
Hugetlb:   0 kB
DirectMap4k:  245204 kB
DirectMap2M:    13062144 kB
DirectMap1G:    390070272 kB
MemTotal:   394907728 kB
MemFree:    173738328 kB
MemAvailable:   379989680 kB
Buffers:  355812 kB
Cached: 207216224 kB
...
DirectMap2M:    13062144 kB
DirectMap1G:    390070272 kB

As you see, after "DirectMap1G:" line, a whole copy of /proc/meminfo returned by 
"read".

Test program:

#include 
#include 
#include 
#include 
#include 
#include 

#define SIZE 1024
char buf[SIZE + 1];

int main(int argc, char *argv[]) {
      int fd;
      ssize_t rd;
      off_t   ofs = 0;

      if (argc < 2) {
      printf("Usage: test  []\n");
      exit(1);
      }

      if (-1 == (fd = open(argv[1], O_RDONLY))) {
      perror("open failed");
      exit(1);
      }

      if (argc > 2) {
      ofs = atol(argv[2]);
      }
      printf("Will seek to %ld\n", ofs);

      if (-1 == (lseek(fd, ofs, SEEK_SET))) {
      perror("lseek failed");
      exit(1);
      }

      for (;; ofs += rd) {
      printf("\n\nData read at offset %ld\n", ofs);
      if (-1 == (rd = read(fd, buf, SIZE))) {
      perror("read failed");
      exit(1);
      }
      buf[rd] = '\0';
      printf(buf);
      if (rd < SIZE) {
      break;
      }
      }

      return 0;
}





Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S

2019-08-01 Thread Tao Ren
On 7/31/19 10:20 PM, Tao Ren wrote:
> On 7/30/19 11:00 PM, Tao Ren wrote:
>> On 7/30/19 10:53 PM, Heiner Kallweit wrote:
>>> On 31.07.2019 02:12, Tao Ren wrote:
 On 7/29/19 11:00 PM, Heiner Kallweit wrote:
> On 30.07.2019 07:05, Tao Ren wrote:
>> On 7/29/19 8:35 PM, Andrew Lunn wrote:
>>> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote:
 BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit 
 dcdecdcfe1fc
 ("net: phy: switch drivers to use dynamic feature detection"). As 
 dynamic
 feature detection doesn't work when BCM54616S is working in RGMII-Fiber
 mode (different sets of MII Control/Status registers being used), let's
 set "PHY_GBIT_FEATURES" for BCM54616S explicitly.
>>>
>>> Hi Tao
>>>
>>> What exactly does it get wrong?
>>>
>>>  Thanks
>>> Andrew
>>
>> Hi Andrew,
>>
>> BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and 
>> none of the features (1000BaseT/100BaseT/10BaseT) can be detected by 
>> genphy_read_abilities(), because the PHY only reports 
>> 1000BaseX_Full|Half ability in this mode.
>>
> Are you going to use the PHY in copper or fibre mode?
> In case you use fibre mode, why do you need the copper modes set as 
> supported?
> Or does the PHY just start in fibre mode and you want to switch it to 
> copper mode?

 Hi Heiner,

 The phy starts in fiber mode and that's the mode I want.
 My observation is: phydev->link is always 0 (Link status bit is never set 
 in MII_BMSR) by using dynamic ability detection on my machine. I checked 
 phydev->supported and it's set to "AutoNeg | TP | MII | Pause | 
 Asym_Pause" by dynamic ability detection. Is it normal/expected? Or maybe 
 the fix should go to different places? Thank you for your help.

>>>
>>> Not sure whether you stated already which kernel version you're using.
>>> There's a brand-new extension to auto-detect 1000BaseX:
>>> f30e33bcdab9 ("net: phy: Add more 1000BaseX support detection")
>>> It's included in the 5.3-rc series.
>>
>> I'm running kernel 5.2.0. Thank you for the sharing and I didn't know the 
>> patch. Let me check it out.
> 
> I applied above patch and ca72efb6bdc7 ("net: phy: Add detection of 1000BaseX 
> link mode support") to my 5.2.0 tree but got following warning when booting 
> up my machine:
> 
> "PHY advertising (0,0200,62c0) more modes than genphy supports, some 
> modes not advertised".
> 
> The BCM54616S PHY on my machine only reports 1000-X features in 
> RGMII->1000Base-KX mode. Is it a known problem?
> 
> Anyways let me see if I missed some dependency/follow-up patches..

Let's ignore the patch ("net: phy: broadcom: set features explicitly for 
BCM54616S"): as Heiner pointed out, it doesn't make sense to turn on copper 
features for fiber mode (even though it "works" in my environment). I will work 
out new patch if 1000bx-auto-detection patches cannot solve my problem.

Thank you all for spending time on this.


Cheers,

Tao


[PATCH -next] staging: fsl-dpaa2/ethsw: Remove useless set memory to zero use memset()

2019-08-01 Thread Wei Yongjun
The memory return by kzalloc() has already be set to zero, so remove
useless memset(0).

Signed-off-by: Wei Yongjun 
---
 drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c 
b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index 4b94a01513a7..aac98ece2335 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -641,8 +641,6 @@ static int port_fdb_dump(struct sk_buff *skb, struct 
netlink_callback *cb,
if (!dma_mem)
return -ENOMEM;
 
-   memset(dma_mem, 0, fdb_dump_size);
-
fdb_dump_iova = dma_map_single(dev, dma_mem, fdb_dump_size,
   DMA_FROM_DEVICE);
if (dma_mapping_error(dev, fdb_dump_iova)) {





Re: [PATCH 2/2 v3] MIPS: Ingenic: Fix bugs when calculate bogomips/lpj.

2019-08-01 Thread Paul Cercueil

Hi Zhou,



Le jeu. 1 août 2019 à 8:16, Zhou Yanjie  a 
écrit :

Enable BTB lookups for short loops to fix bugs when calculate
bogomips and loops_per_jiffy.


The commit description and the code comment below seem to say two
different things. Are we enabling the BTB lookup optimization, or not?

Also, maybe change the commit title to something more meaningful, e.g.
"MIPS: ingenic: Disable broken BTB lookup optimization" or similar.



Signed-off-by: Zhou Yanjie 
---
 arch/mips/include/asm/mipsregs.h | 4 
 arch/mips/kernel/cpu-probe.c | 7 +++
 2 files changed, 11 insertions(+)

diff --git a/arch/mips/include/asm/mipsregs.h 
b/arch/mips/include/asm/mipsregs.h

index 1e6966e..bdbdc19 100644
--- a/arch/mips/include/asm/mipsregs.h
+++ b/arch/mips/include/asm/mipsregs.h
@@ -689,6 +689,9 @@
 #define MIPS_CONF7_IAR (_ULCAST_(1) << 10)
 #define MIPS_CONF7_AR  (_ULCAST_(1) << 16)

+/* Ingenic Config7 bits */
+#define MIPS_CONF7_BTB_LOOP_EN (_ULCAST_(1) << 4)
+
 /* Config7 Bits specific to MIPS Technologies. */

 /* Performance counters implemented Per TC */
@@ -2813,6 +2816,7 @@ __BUILD_SET_C0(status)
 __BUILD_SET_C0(cause)
 __BUILD_SET_C0(config)
 __BUILD_SET_C0(config5)
+__BUILD_SET_C0(config7)
 __BUILD_SET_C0(intcontrol)
 __BUILD_SET_C0(intctl)
 __BUILD_SET_C0(srsmap)
diff --git a/arch/mips/kernel/cpu-probe.c 
b/arch/mips/kernel/cpu-probe.c

index eb527a1..2bdd3e1 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -1964,6 +1964,13 @@ static inline void cpu_probe_ingenic(struct 
cpuinfo_mips *c, unsigned int cpu)

c->cputype = CPU_XBURST;
c->writecombine = _CACHE_UNCACHED_ACCELERATED;
__cpu_name[cpu] = "Ingenic XBurst";
+   /*
+* The XBurst core by default attempts to avoid branch target
+* buffer lookups by detecting & special casing loops. This
+* feature will cause BogoMIPS and lpj calculate in error.
+* Set cp0 config7 bit 4 to disable this feature.
+*/
+   set_c0_config7(MIPS_CONF7_BTB_LOOP_EN);


Shouldn't it be MIPS_CONF7_BTB_LOOP_DIS then?
Since the feature is disabled when the bit is set.



break;
default:
panic("Unknown Ingenic Processor ID!");
--
2.7.4







[PATCH] PCI: Mark expected switch fall-through

2019-08-01 Thread Gustavo A. R. Silva
Mark switch cases where we are expecting to fall through.

This patch fixes the following warning (Building: allmodconfig i386):

drivers/pci/hotplug/ibmphp_res.c: In function ‘update_bridge_ranges’:
drivers/pci/hotplug/ibmphp_res.c:1943:16: warning: this statement may fall 
through [-Wimplicit-fallthrough=]
   function = 0x8;
   ~^
drivers/pci/hotplug/ibmphp_res.c:1944:6: note: here
  case PCI_HEADER_TYPE_MULTIBRIDGE:
  ^~~~

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/pci/hotplug/ibmphp_res.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/hotplug/ibmphp_res.c b/drivers/pci/hotplug/ibmphp_res.c
index 5e8caf7a4452..1e1ba66cfd1e 100644
--- a/drivers/pci/hotplug/ibmphp_res.c
+++ b/drivers/pci/hotplug/ibmphp_res.c
@@ -1941,6 +1941,7 @@ static int __init update_bridge_ranges(struct bus_node 
**bus)
break;
case PCI_HEADER_TYPE_BRIDGE:
function = 0x8;
+   /* Fall through */
case PCI_HEADER_TYPE_MULTIBRIDGE:
/* We assume here that only 1 
bus behind the bridge
   TO DO: add functionality for 
several:
-- 
2.22.0



Re: Possible mem cgroup bug in kernels between 4.18.0 and 5.3-rc1.

2019-08-01 Thread Masoud Sharbiani



> On Aug 1, 2019, at 11:19 AM, Greg KH  wrote:
> 
> On Thu, Aug 01, 2019 at 11:04:14AM -0700, Masoud Sharbiani wrote:
>> Hey folks,
>> I’ve come across an issue that affects most of 4.19, 4.20 and 5.2 
>> linux-stable kernels that has only been fixed in 5.3-rc1.
>> It was introduced by
>> 
>> 29ef680 memcg, oom: move out_of_memory back to the charge path 
>> 
>> The gist of it is that if you have a memory control group for a process that 
>> repeatedly maps all of the pages of a file with repeated calls to:
>> 
>>   mmap(NULL, pages * PAGE_SIZE, PROT_WRITE|PROT_READ, MAP_FILE|MAP_PRIVATE, 
>> fd, 0)
>> 
>> The memory cg eventually runs out of memory, as it should. However,
>> prior to the 29ef680 commit, it would kill the running process with
>> OOM; After that commit ( and until 5.3-rc1; Haven’t pinpointed the
>> exact commit in between 5.2.0 and 5.3-rc1) the offending process goes
>> into %100 CPU usage, and doesn’t die (prior behavior) or fail the mmap
>> call (which is what happens if one runs the test program with a low
>> ulimit -v value).
>> 
>> Any ideas on how to chase this down further?
> 
> Finding the exact patch that fixes this would be great, as then I can
> add it to the 4.19 and 5.2 stable kernels (4.20 is long end-of-life, no
> idea why you are messing with that one...)
> 
> thanks,
> 
> greg k-h



Allow me to issue a correction: 
Running this test on linux master <629f8205a6cc63d2e8e30956bad958a3507d018f> 
correctly terminates the leaker app with OOM. 
However, running it a second time (after removing the memory cgroup, and 
allowing the test script to run it again), causes this:

 kernel:watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [leaker1:7193]


[  202.511024] CPU: 7 PID: 7193 Comm: leaker1 Not tainted 5.3.0-rc2+ #8
[  202.517378] Hardware name: 
[  202.525554] RIP: 0010:lruvec_lru_size+0x49/0xf0
[  202.530085] Code: 41 89 ed b8 ff ff ff ff 45 31 f6 49 c1 e5 03 eb 19 48 63 
d0 4c 89 e9 48 8b 14 d5 20 b7 11 b5 48 03 8b 88 00 00 00 4c 03 34 11 <48> c7 c6 
80 c5 40 b5 89 c7 e8 29 a7 6f 00 3b 05 57 9d 24 01 72 d1
[  202.548831] RSP: 0018:a7c5480df620 EFLAGS: 0246 ORIG_RAX: 
ff13
[  202.556398] RAX:  RBX: 8f5b7a1af800 RCX: 3859bfa03bc0
[  202.563528] RDX: 8f5b7f80 RSI: 0018 RDI: b540c580
[  202.570662] RBP: 0001 R08:  R09: 0004
[  202.577795] R10: 8f5b62548000 R11:  R12: 0004
[  202.584928] R13: 0008 R14:  R15: 
[  202.592063] FS:  7ff73d835740() GS:8f6b7f84() 
knlGS:
[  202.600149] CS:  0010 DS:  ES:  CR0: 80050033
[  202.605895] CR2: 7f1b1c00e428 CR3: 001021d56006 CR4: 001606e0
[  202.613026] Call Trace:
[  202.615475]  shrink_node_memcg+0xdb/0x7a0
[  202.619488]  ? shrink_slab+0x266/0x2a0
[  202.623242]  ? mem_cgroup_iter+0x10a/0x2c0
[  202.627337]  shrink_node+0xdd/0x4c0
[  202.630831]  do_try_to_free_pages+0xea/0x3c0
[  202.635104]  try_to_free_mem_cgroup_pages+0xf5/0x1e0
[  202.640068]  try_charge+0x279/0x7a0
[  202.643565]  mem_cgroup_try_charge+0x51/0x1a0
[  202.647925]  __add_to_page_cache_locked+0x19f/0x330
[  202.652800]  ? __mod_lruvec_state+0x40/0xe0
[  202.656987]  ? scan_shadow_nodes+0x30/0x30
[  202.661086]  add_to_page_cache_lru+0x49/0xd0
[  202.665361]  iomap_readpages_actor+0xea/0x230
[  202.669718]  ? iomap_migrate_page+0xe0/0xe0
[  202.673906]  iomap_apply+0xb8/0x150
[  202.677398]  iomap_readpages+0xa7/0x1a0
[  202.681237]  ? iomap_migrate_page+0xe0/0xe0
[  202.685424]  read_pages+0x68/0x190
[  202.688829]  __do_page_cache_readahead+0x19c/0x1b0
[  202.693622]  ondemand_readahead+0x168/0x2a0
[  202.697808]  filemap_fault+0x32d/0x830
[  202.701562]  ? __mod_lruvec_state+0x40/0xe0
[  202.705747]  ? page_remove_rmap+0xcf/0x150
[  202.709846]  ? alloc_set_pte+0x240/0x2c0
[  202.713775]  __xfs_filemap_fault+0x71/0x1c0
[  202.717963]  __do_fault+0x38/0xb0
[  202.721280]  __handle_mm_fault+0x73f/0x1080
[  202.725467]  ? __switch_to_asm+0x34/0x70
[  202.729390]  ? __switch_to_asm+0x40/0x70
[  202.733318]  handle_mm_fault+0xce/0x1f0
[  202.737158]  __do_page_fault+0x231/0x480
[  202.741083]  page_fault+0x2f/0x40
[  202.744404] RIP: 0033:0x400c20
[  202.747461] Code: 45 c8 48 89 c6 bf 32 0e 40 00 b8 00 00 00 00 e8 76 fb ff 
ff c7 45 ec 00 00 00 00 eb 36 8b 45 ec 48 63 d0 48 8b 45 c8 48 01 d0 <0f> b6 00 
0f be c0 01 45 e4 8b 45 ec 25 ff 0f 00 00 85 c0 75 10 8b
[  202.766208] RSP: 002b:7ffde95ae460 EFLAGS: 00010206
[  202.771432] RAX: 7ff71e855000 RBX:  RCX: 001a
[  202.778558] RDX: 01dfd000 RSI: 7fe5 RDI: 
[  202.785692] RBP: 7ffde95af4b0 R08:  R09: 7ff73d2a520d
[  202.792823] R10: 0002 R11: 0246 R12: 00400850
[  202.799949] R13: 7ffde95af590 R14:  R15: 



[PATCH] fs/ceph: don't return a value from void function

2019-08-01 Thread john . hubbard
From: John Hubbard 

This fixes a build warning to that effect.

Signed-off-by: John Hubbard 
---

Hi,

I ran into this while working on unrelated changes, to
convert ceph over to put_user_page().

This patch is against the latest linux.git.

thanks,
John Hubbard
NVIDIA


 fs/ceph/debugfs.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/ceph/debugfs.c b/fs/ceph/debugfs.c
index 2eb88ed22993..facb387c2735 100644
--- a/fs/ceph/debugfs.c
+++ b/fs/ceph/debugfs.c
@@ -294,7 +294,6 @@ void ceph_fs_debugfs_init(struct ceph_fs_client *fsc)
 
 void ceph_fs_debugfs_init(struct ceph_fs_client *fsc)
 {
-   return 0;
 }
 
 void ceph_fs_debugfs_cleanup(struct ceph_fs_client *fsc)
-- 
2.22.0



[PATCH] ARM: dts: aspeed: Add Facebook Wedge100 BMC

2019-08-01 Thread Tao Ren
Add initial version of device tree for Facebook Wedge100 AST2400 BMC
platform.

Signed-off-by: Tao Ren 
---
 arch/arm/boot/dts/Makefile|   1 +
 .../boot/dts/aspeed-bmc-facebook-wedge100.dts | 149 ++
 2 files changed, 150 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 39a05a10a2a2..d71504ed82d3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1273,6 +1273,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-facebook-cmm.dtb \
aspeed-bmc-facebook-minipack.dtb \
aspeed-bmc-facebook-tiogapass.dtb \
+   aspeed-bmc-facebook-wedge100.dtb \
aspeed-bmc-facebook-yamp.dtb \
aspeed-bmc-intel-s2600wf.dtb \
aspeed-bmc-inspur-fp5280g2.dtb \
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts 
b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts
new file mode 100644
index ..ccd700467ea7
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge100.dts
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2018 Facebook Inc.
+/dts-v1/;
+
+#include "aspeed-g4.dtsi"
+
+/ {
+   model = "Facebook Wedge 100 BMC";
+   compatible = "facebook,wedge100-bmc", "aspeed,ast2400";
+
+   aliases {
+   /*
+* Override the default uart aliases to avoid breaking
+* the legacy applications.
+*/
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   };
+
+   chosen {
+   stdout-path = 
+   bootargs = "debug console=ttyS2,9600n8 root=/dev/ram rw";
+   };
+
+   memory@4000 {
+   reg = <0x4000 0x2000>;
+   };
+};
+
+ {
+   status = "okay";
+   aspeed,reset-type = "system";
+};
+
+ {
+   status = "okay";
+   aspeed,reset-type = "system";
+};
+
+ {
+   status = "okay";
+   flash@0 {
+   status = "okay";
+   m25p,fast-read;
+   label = "fmc0";
+#include "facebook-bmc-flash-layout.dtsi"
+   };
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_txd1_default
+_rxd1_default>;
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_txd3_default
+_rxd3_default>;
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_txd4_default
+_rxd4_default>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   no-hw-checksum;
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii2_default _mdio2_default>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   i2c-switch@70 {
+   compatible = "nxp,pca9548";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x70>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
2.17.1



[PATCH] ARM: dts: aspeed: Add Facebook Wedge40 BMC

2019-08-01 Thread Tao Ren
Add initial version of device tree for Facebook Wedge40 AST2400 BMC
platform.

Signed-off-by: Tao Ren 
---
 arch/arm/boot/dts/Makefile|   1 +
 .../boot/dts/aspeed-bmc-facebook-wedge40.dts  | 141 ++
 2 files changed, 142 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 39a05a10a2a2..dfc1011eb3f2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1273,6 +1273,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-facebook-cmm.dtb \
aspeed-bmc-facebook-minipack.dtb \
aspeed-bmc-facebook-tiogapass.dtb \
+   aspeed-bmc-facebook-wedge40.dtb \
aspeed-bmc-facebook-yamp.dtb \
aspeed-bmc-intel-s2600wf.dtb \
aspeed-bmc-inspur-fp5280g2.dtb \
diff --git a/arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts 
b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts
new file mode 100644
index ..764633964ac1
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2018 Facebook Inc.
+/dts-v1/;
+
+#include "aspeed-g4.dtsi"
+
+/ {
+   model = "Facebook Wedge 40 BMC";
+   compatible = "facebook,wedge40-bmc", "aspeed,ast2400";
+
+   aliases {
+   /*
+* Override the default uart aliases to avoid breaking
+* the legacy applications.
+*/
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   };
+
+   chosen {
+   stdout-path = 
+   bootargs = "debug console=ttyS2,9600n8 root=/dev/ram rw";
+   };
+
+   memory@4000 {
+   reg = <0x4000 0x2000>;
+   };
+};
+
+ {
+   status = "okay";
+   aspeed,reset-type = "system";
+};
+
+ {
+   status = "disabled";
+};
+
+ {
+   status = "okay";
+   flash@0 {
+   status = "okay";
+   m25p,fast-read;
+   label = "fmc0";
+#include "facebook-bmc-flash-layout.dtsi"
+   };
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_txd1_default
+_rxd1_default>;
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_txd3_default
+_rxd3_default>;
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_txd4_default
+_rxd4_default>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   no-hw-checksum;
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgmii2_default _mdio2_default>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
-- 
2.17.1



Re: [PATCH] KVM: Disable wake-affine vCPU process to mitigate lock holder preemption

2019-08-01 Thread Wanpeng Li
On Thu, 1 Aug 2019 at 20:57, Dario Faggioli  wrote:
>
> On Tue, 2019-07-30 at 17:33 +0800, Wanpeng Li wrote:
> > However, in multiple VMs over-subscribe virtualization scenario, it
> > increases
> > the probability to incur vCPU stacking which means that the sibling
> > vCPUs from
> > the same VM will be stacked on one pCPU. I test three 80 vCPUs VMs
> > running on
> > one 80 pCPUs Skylake server(PLE is supported), the ebizzy score can
> > increase 17%
> > after disabling wake-affine for vCPU process.
> >
> Can't we achieve this by removing SD_WAKE_AFFINE from the relevant
> scheduling domains? By acting on
> /proc/sys/kernel/sched_domain/cpuX/domainY/flags, I mean?
>
> Of course this will impact all tasks, not only KVM vcpus. But if the
> host does KVM only anyway...

Yes, not only kvm host and dedicated kvm host, unless introduce
per-process flags, otherwise can't appeal to both.

Regards,
Wanpeng Li


Re: [PATCH v3 00/10] implement KASLR for powerpc/fsl_booke/32

2019-08-01 Thread Jason Yan




On 2019/8/1 22:36, Diana Madalina Craciun wrote:

Hi Jason,

I have tested these series on a P4080 platform.

Regards,
Diana


Diana, thank you so much.

So can you take a look at the code of this version and give a 
Reviewed-by or Tested-by?


Thanks,
Jason



Re: [PATCH v3 1/3] KVM: Fix leak vCPU's VMCS value into other pCPU

2019-08-01 Thread Wanpeng Li
On Thu, 1 Aug 2019 at 21:31, Sasha Levin  wrote:
>
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: 98f4a1467612 KVM: add kvm_arch_vcpu_runnable() test to 
> kvm_vcpu_on_spin() loop.
>
> The bot has tested the following trees: v5.2.4, v5.1.21, v4.19.62, v4.14.134, 
> v4.9.186, v4.4.186.
>
> v5.2.4: Build failed! Errors:
> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:2483:31: error: ‘struct 
> kvm_vcpu’ has no member named ‘async_pf’
>
> v5.1.21: Build failed! Errors:
> arch/arm64/kvm/../../../virt/kvm/kvm_main.c:2415:31: error: ‘struct 
> kvm_vcpu’ has no member named ‘async_pf’

Thanks for reporting this, after more grep, it seems that just x86 and
s390 enable async_pf in their Makefile. So I can move 'if
(!list_empty_careful(>async_pf.done))' checking to
kvm_arch_dy_runnable(), Paolo, do you have more comments to v3 before
I send a new version?

Regards,
Wanpeng Li


linux-next: manual merge of the jc_docs tree with the cifs tree

2019-08-01 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the jc_docs tree got a conflict in:

  Documentation/admin-guide/cifs/todo.rst

between commit:

  46c8a6b4c39e ("smb3: update TODO list of missing features")

from the cifs tree and commit:

  f139291c7130 ("docs: fs: cifs: convert to ReST and add to admin-guide book")

from the jc_docs tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/admin-guide/cifs/todo.rst
index edbbccda1942,95f18e8c9b8a..
--- a/Documentation/admin-guide/cifs/todo.rst
+++ b/Documentation/admin-guide/cifs/todo.rst
@@@ -13,52 -18,49 +18,52 @@@ a) SMB3 (and SMB3.1.1) missing optiona
 - T10 copy offload ie "ODX" (copy chunk, and "Duplicate Extents" ioctl
   currently the only two server side copy mechanisms supported)
  
 -b) improved sparse file support
 +b) improved sparse file support (fiemap and SEEK_HOLE are implemented
- but additional features would be supportable by the protocol).
++   but additional features would be supportable by the protocol).
  
  c) Directory entry caching relies on a 1 second timer, rather than
- using Directory Leases, currently only the root file handle is cached longer
+using Directory Leases, currently only the root file handle is cached 
longer
  
  d) quota support (needs minor kernel change since quota calls
- to make it to network filesystems or deviceless filesystems)
+to make it to network filesystems or deviceless filesystems)
  
 -e) Additional use cases where we use "compoounding" (e.g. open/query/close
 -   and open/setinfo/close) to reduce the number of roundtrips, and also
 -   open to reduce redundant opens (using deferred close and reference counts
 -   more).
 +e) Additional use cases can be optimized to use "compounding"
- (e.g. open/query/close and open/setinfo/close) to reduce the number
- of roundtrips to the server and improve performance. Various cases
- (stat, statfs, create, unlink, mkdir) already have been improved by
- using compounding but more can be done.  In addition we could significantly
- reduce redundant opens by using deferred close (with handle caching leases)
- and better using reference counters on file handles.
++   (e.g. open/query/close and open/setinfo/close) to reduce the number
++   of roundtrips to the server and improve performance. Various cases
++   (stat, statfs, create, unlink, mkdir) already have been improved by
++   using compounding but more can be done.  In addition we could significantly
++   reduce redundant opens by using deferred close (with handle caching leases)
++   and better using reference counters on file handles.
  
  f) Finish inotify support so kde and gnome file list windows
- will autorefresh (partially complete by Asser). Needs minor kernel
- vfs change to support removing D_NOTIFY on a file.   
+will autorefresh (partially complete by Asser). Needs minor kernel
+vfs change to support removing D_NOTIFY on a file.
  
  g) Add GUI tool to configure /proc/fs/cifs settings and for display of
- the CIFS statistics (started)
+the CIFS statistics (started)
  
  h) implement support for security and trusted categories of xattrs
- (requires minor protocol extension) to enable better support for SELINUX
+(requires minor protocol extension) to enable better support for SELINUX
  
  i) Add support for tree connect contexts (see MS-SMB2) a new SMB3.1.1 protocol
 feature (may be especially useful for virtualization).
  
  j) Create UID mapping facility so server UIDs can be mapped on a per
- mount or a per server basis to client UIDs or nobody if no mapping
- exists. Also better integration with winbind for resolving SID owners
+mount or a per server basis to client UIDs or nobody if no mapping
+exists. Also better integration with winbind for resolving SID owners
  
  k) Add tools to take advantage of more smb3 specific ioctls and features
- (passthrough ioctl/fsctl is now implemented in cifs.ko to allow sending
- various SMB3 fsctls and query info and set info calls directly from user 
space)
- Add tools to make setting various non-POSIX metadata attributes easier
- from tools (e.g. extending what was done in smb-info tool).
 -   (passthrough ioctl/fsctl for sending various SMB3 fsctls to the server
 -   is in progress, and a passthrough query_info call is already implemented
 -   in cifs.ko to allow smb3 info levels queries to be sent from userspace)
++   (passthrough ioctl/fsctl is now implemented in cifs.ko to allow sending
++   various SMB3 fsctls and query info and set info calls directly from user 
space)
++   Add tools to make setting various non-POSIX metadata attributes 

Re: [PATCH] pciehp: fix a race between pciehp and removing operations by sysfs

2019-08-01 Thread Bjorn Helgaas
On Mon, Feb 26, 2018 at 08:41:15PM +0800, Xiongfeng Wang wrote:
> From: Xiongfeng Wang 
> 
> When I run a stress test about pcie hotplug and removing operations by
> sysfs, I got a hange task, and the following call trace is printed.

It's been so long that I'm embarrassed to even respond to this, but
this patch doesn't apply cleanly to v5.3-rc1.  If this is still a
problem, would you mind refreshing it and reposting it?  Thanks.

>  INFO: task kworker/0:2:4413 blocked for more than 120 seconds.
>Tainted: PW  O4.12.0-rc1 #1
>  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>  kworker/0:2 D0  4413  2 0x
>  Workqueue: pciehp-0 pciehp_power_thread
>  Call trace:
>  [] __switch_to+0x94/0xa8
>  [] __schedule+0x1b0/0x708
>  [] schedule+0x40/0xa4
>  [] schedule_preempt_disabled+0x28/0x40
>  [] __mutex_lock.isra.8+0x148/0x50c
>  [] __mutex_lock_slowpath+0x24/0x30
>  [] mutex_lock+0x48/0x54
>  [] pci_lock_rescan_remove+0x20/0x28
>  [] pciehp_unconfigure_device+0x54/0x1cc
>  [] pciehp_disable_slot+0x4c/0xbc
>  [] pciehp_power_thread+0xa0/0xb8
>  [] process_one_work+0x13c/0x3f8
>  [] worker_thread+0x60/0x3e4
>  [] kthread+0x10c/0x138
>  [] ret_from_fork+0x10/0x50
>  INFO: task bash:31732 blocked for more than 120 seconds.
>Tainted: PW  O4.12.0-rc1 #1
>  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>  bashD0 31732  1 0x0009
>  Call trace:
>  [] __switch_to+0x94/0xa8
>  [] __schedule+0x1b0/0x708
>  [] schedule+0x40/0xa4
>  [] schedule_timeout+0x1a0/0x340
>  [] wait_for_common+0x108/0x1bc
>  [] wait_for_completion+0x28/0x34
>  [] flush_workqueue+0x130/0x488
>  [] drain_workqueue+0xc4/0x164
>  [] destroy_workqueue+0x28/0x1f4
>  [] pciehp_release_ctrl+0x34/0xe0
>  [] pciehp_remove+0x30/0x3c
>  [] pcie_port_remove_service+0x3c/0x54
>  [] device_release_driver_internal+0x150/0x1d0
>  [] device_release_driver+0x28/0x34
>  [] bus_remove_device+0xe0/0x11c
>  [] device_del+0x200/0x304
>  [] device_unregister+0x20/0x38
>  [] remove_iter+0x44/0x54
>  [] device_for_each_child+0x4c/0x90
>  [] pcie_port_device_remove+0x2c/0x48
>  [] pcie_portdrv_remove+0x60/0x6c
>  [] pci_device_remove+0x48/0x110
>  [] device_release_driver_internal+0x150/0x1d0
>  [] device_release_driver+0x28/0x34
>  [] pci_stop_bus_device+0x9c/0xac
>  [] pci_stop_and_remove_bus_device_locked+0x24/0x3c
>  [] remove_store+0x74/0x80
>  [] dev_attr_store+0x44/0x5c
>  [] sysfs_kf_write+0x5c/0x74
>  [] kernfs_fop_write+0xcc/0x1dc
>  [] __vfs_write+0x48/0x13c
>  [] vfs_write+0xa8/0x198
>  [] SyS_write+0x54/0xb0
>  [] el0_svc_naked+0x24/0x28
> 
> There is a race condition between these two kinds of operations.
> When the Attention button on a PCIE slot is pressed, 5 seconds later,
> pciehp_power_thread() will be scheduled on slot->wq. This function will
> call pciehp_unconfigure_device(), which will try to get a global mutex
> lock 'pci_rescan_remove_lock'.
> 
> At the same time, we remove the pcie port by sysfs, which results in
> pci_stop_and_remove_bus_device_locked() called. This function will get
> the global mutex lock 'pci_rescan_remove_lock', and then release the
> struct 'ctrl', which will wait until the work_struct on slot->wq is
> finished.
> 
> If pci_stop_and_remove_bus_device_locked() got the mutex lock, and
> before it drains workqueue slot->wq, pciehp_power_thread() is scheduled
> on slot->wq and tries to get the mutex lock but failed, so it will just
> wait. Then pci_stop_and_remove_bus_device_locked() tries to drain workqueue
> slot->wq and wait until work struct 'pciehp_power_thread()' is finished.
> Then a hung_task occurs.
> 
> So this two kinds of operation, removing through attention buttion and
> removing through /sys/devices/pci***/remove, should not be excuted at the
> same time. This patch add a global variable to mark that one of these
> operations is under processing. When this variable is set,  if another
> operation is requested, it will be rejected.
> 
> At first, I want to add a flag for each pci slot to record whether a
> removing operation is under processing. When a bridge is being removed,
> the flags of all the slots below the bridge need to be checked. But it
> is hard for us to guarantee the atomic access. So I just use a global
> flag.
> 
> Signed-off-by: Xiongfeng Wang 
> ---
>  drivers/pci/hotplug/pciehp_ctrl.c |  7 +++
>  drivers/pci/hotplug/pciehp_hpc.c  | 12 +++-
>  drivers/pci/pci-sysfs.c   | 11 +--
>  drivers/pci/remove.c  |  6 ++
>  include/linux/pci.h   |  3 +++
>  5 files changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/hotplug/pciehp_ctrl.c 
> b/drivers/pci/hotplug/pciehp_ctrl.c
> index c684faa..e6fc5d7 100644
> --- a/drivers/pci/hotplug/pciehp_ctrl.c
> +++ b/drivers/pci/hotplug/pciehp_ctrl.c
> @@ -30,6 +30,7 @@ void pciehp_queue_interrupt_event(struct slot *p_slot, u32 
> event_type)
>   info = 

  1   2   3   4   5   6   7   8   9   10   >