Re: [PATCH v3] i2c: aspeed: fix invalid clock parameters for very large divisors

[kbuild test robot]

Hi Brendan,

I love your patch! Yet something to improve:

[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on v4.19-rc4 next-20180921]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Brendan-Higgins/i2c-aspeed-fix-invalid-clock-parameters-for-very-large-divisors/20180922-134643
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
i2c/for-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/i2c/busses/i2c-aspeed.c: In function 'aspeed_i2c_probe_bus':
>> drivers/i2c/busses/i2c-aspeed.c:920:24: error: assignment from incompatible 
>> pointer type [-Werror=incompatible-pointer-types]
  bus->get_clk_reg_val = (u32 (*)(u32))match->data;
   ^
   cc1: some warnings being treated as errors

vim +920 drivers/i2c/busses/i2c-aspeed.c

87b59ff8d Brendan Higgins 2017-07-28  875  
f327c686d Brendan Higgins 2017-06-20  876  static int 
aspeed_i2c_probe_bus(struct platform_device *pdev)
f327c686d Brendan Higgins 2017-06-20  877  {
87b59ff8d Brendan Higgins 2017-07-28  878   const struct of_device_id 
*match;
f327c686d Brendan Higgins 2017-06-20  879   struct aspeed_i2c_bus *bus;
f327c686d Brendan Higgins 2017-06-20  880   struct clk *parent_clk;
f327c686d Brendan Higgins 2017-06-20  881   struct resource *res;
f327c686d Brendan Higgins 2017-06-20  882   int irq, ret;
f327c686d Brendan Higgins 2017-06-20  883  
f327c686d Brendan Higgins 2017-06-20  884   bus = devm_kzalloc(&pdev->dev, 
sizeof(*bus), GFP_KERNEL);
f327c686d Brendan Higgins 2017-06-20  885   if (!bus)
f327c686d Brendan Higgins 2017-06-20  886   return -ENOMEM;
f327c686d Brendan Higgins 2017-06-20  887  
f327c686d Brendan Higgins 2017-06-20  888   res = 
platform_get_resource(pdev, IORESOURCE_MEM, 0);
f327c686d Brendan Higgins 2017-06-20  889   bus->base = 
devm_ioremap_resource(&pdev->dev, res);
f327c686d Brendan Higgins 2017-06-20  890   if (IS_ERR(bus->base))
f327c686d Brendan Higgins 2017-06-20  891   return 
PTR_ERR(bus->base);
f327c686d Brendan Higgins 2017-06-20  892  
f327c686d Brendan Higgins 2017-06-20  893   parent_clk = 
devm_clk_get(&pdev->dev, NULL);
f327c686d Brendan Higgins 2017-06-20  894   if (IS_ERR(parent_clk))
f327c686d Brendan Higgins 2017-06-20  895   return 
PTR_ERR(parent_clk);
f327c686d Brendan Higgins 2017-06-20  896   bus->parent_clk_frequency = 
clk_get_rate(parent_clk);
f327c686d Brendan Higgins 2017-06-20  897   /* We just need the clock rate, 
we don't actually use the clk object. */
f327c686d Brendan Higgins 2017-06-20  898   devm_clk_put(&pdev->dev, 
parent_clk);
f327c686d Brendan Higgins 2017-06-20  899  
edd20e95b Joel Stanley2017-11-01  900   bus->rst = 
devm_reset_control_get_shared(&pdev->dev, NULL);
edd20e95b Joel Stanley2017-11-01  901   if (IS_ERR(bus->rst)) {
edd20e95b Joel Stanley2017-11-01  902   dev_err(&pdev->dev,
6bc33c519 Jae Hyun Yoo2018-07-02  903   "missing or 
invalid reset controller device tree entry\n");
edd20e95b Joel Stanley2017-11-01  904   return 
PTR_ERR(bus->rst);
edd20e95b Joel Stanley2017-11-01  905   }
edd20e95b Joel Stanley2017-11-01  906   
reset_control_deassert(bus->rst);
edd20e95b Joel Stanley2017-11-01  907  
f327c686d Brendan Higgins 2017-06-20  908   ret = 
of_property_read_u32(pdev->dev.of_node,
f327c686d Brendan Higgins 2017-06-20  909  
"bus-frequency", &bus->bus_frequency);
f327c686d Brendan Higgins 2017-06-20  910   if (ret < 0) {
f327c686d Brendan Higgins 2017-06-20  911   dev_err(&pdev->dev,
f327c686d Brendan Higgins 2017-06-20  912   "Could not read 
bus-frequency property\n");
f327c686d Brendan Higgins 2017-06-20  913   bus->bus_frequency = 
10;
f327c686d Brendan Higgins 2017-06-20  914   }
f327c686d Brendan Higgins 2017-06-20  915  
87b59ff8d Brendan Higgins 2017-07-28  916   match = 
of_match_node(aspeed_i2c_bus_of_table, pdev->dev.of_node);
87b59ff8d Brendan Higgins 2017-07-28  917   if (!match)
87b59ff8d Brendan Higgins 2017-07-28  918   bus->get_clk_reg_val = 
aspeed_i2c_24xx_get_clk_reg_val;
87b59ff8d Brendan Higgins 2017-07-28  919   else
5799c4b2f Jae Hyun Yoo2018-07-24 @920   

Re: [PATCH] scheduler: conditional statement cleanup

[kbuild test robot]

Hi Pierce,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on tip/sched/core]
[also build test ERROR on v4.19-rc4 next-20180921]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/PierceGriffiths/scheduler-conditional-statement-cleanup/20180922-144638
config: x86_64-randconfig-x019-201837 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   kernel/sched/rt.c: In function 'move_entity':
>> kernel/sched/rt.c:1214:1: error: expected ';' before '}' token
}
^

vim +1214 kernel/sched/rt.c

63489e45 kernel/sched_rt.c Steven Rostedt   2008-01-25  1205  
ff77e468 kernel/sched/rt.c Peter Zijlstra   2016-01-18  1206  /*
ff77e468 kernel/sched/rt.c Peter Zijlstra   2016-01-18  1207   * Change 
rt_se->run_list location unless SAVE && !MOVE
ff77e468 kernel/sched/rt.c Peter Zijlstra   2016-01-18  1208   *
ff77e468 kernel/sched/rt.c Peter Zijlstra   2016-01-18  1209   * assumes 
ENQUEUE/DEQUEUE flags match
ff77e468 kernel/sched/rt.c Peter Zijlstra   2016-01-18  1210   */
ff77e468 kernel/sched/rt.c Peter Zijlstra   2016-01-18  1211  static inline 
bool move_entity(unsigned int flags)
ff77e468 kernel/sched/rt.c Peter Zijlstra   2016-01-18  1212  {
4f659495 kernel/sched/rt.c Pierce Griffiths 2018-09-21  1213return !((flags 
& (DEQUEUE_SAVE | DEQUEUE_MOVE)) == DEQUEUE_SAVE)
ff77e468 kernel/sched/rt.c Peter Zijlstra   2016-01-18 @1214  }
ff77e468 kernel/sched/rt.c Peter Zijlstra   2016-01-18  1215  

:: The code at line 1214 was first introduced by commit
:: ff77e468535987b3d21b7bd4da15608ea3ce7d0b sched/rt: Fix PI handling vs. 
sched_setscheduler()

:: TO: Peter Zijlstra 
:: CC: Ingo Molnar 

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


.config.gz
Description: application/gzip

Re: [PATCH v6 0/3] Harden spectrev2 userspace-userspace protection

[Jiri Kosina]

On Wed, 19 Sep 2018, Peter Zijlstra wrote:

> > diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> > index 5c5e7cb597cd..202a4d9c2af7 100644
> > --- a/kernel/ptrace.c
> > +++ b/kernel/ptrace.c
> > @@ -330,9 +330,7 @@ int __ptrace_may_access(struct task_struct *task, 
> > unsigned int mode)
> >!ptrace_has_cap(mm->user_ns, mode
> > return -EPERM;
> > 
> > -   if (!(mode & PTRACE_MODE_NOACCESS_CHK))
> > -   return security_ptrace_access_check(task, mode);
> > -   return 0;
> > +   return security_ptrace_access_check(task, mode);
> >  }
> > 
> >  bool ptrace_may_access(struct task_struct *task, unsigned int mode)
> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > index 161a4f29f860..30d21142e9fe 100644
> > --- a/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -2215,7 +2215,12 @@ static int selinux_ptrace_access_check(struct 
> > task_struct *child,
> >  {
> > u32 sid = current_sid();
> > u32 csid = task_sid(child);
> > +   struct av_decision avd;
> > 
> > +   if (mode == PTRACE_MODE_IBPB)
> > +   return avc_has_perm_noaudit(&selinux_state, sid, csid,
> > +   SECCLASS_PROCESS, 
> > PROCESS__PTRACE,
> > +   0, &avd);
> > if (mode & PTRACE_MODE_READ)
> > return avc_has_perm(&selinux_state,
> > sid, csid, SECCLASS_FILE, FILE__READ, 
> > NULL);
> > 
> 
> As far as I can tell, this still has:
> 
>   avc_has_perm_noaudit()
> security_compute_av()
>   read_lock(&state->ss->policy_rwlock);
> avc_insert()
>   spin_lock_irqsave();
> avc_denied()
>   avc_update_node()
> spin_lock_irqsave();
> 
> under the scheduler's raw_spinlock_t, which are invalid lock nestings.

Agreed. Therefore, if the current form (v6) of the patches is merged, the 
check before security_ptrace_access_check() should stay.

Once all the LSM callbacks are potentially audited, it could then go in 
second phase.

Is there anything else blocking v6 being merged? (and then Tim's set on 
top I guess, once the details are sorted out there).

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] mtd: rawnand: denali: add DT property to specify skipped bytes in OOB

[Miquel Raynal]

Hi Masahiro,

Masahiro Yamada  wrote on Sat, 8 Sep
2018 01:10:25 +0900:

> Hi Boris,
> 
> 2018-09-07 23:53 GMT+09:00 Boris Brezillon :
> > On Fri, 7 Sep 2018 23:42:53 +0900
> > Masahiro Yamada  wrote:
> >  
> >> Hi Boris,
> >>
> >> 2018-09-07 23:08 GMT+09:00 Boris Brezillon :  
> >> > Hi Masahiro,
> >> >
> >> > On Fri,  7 Sep 2018 19:56:23 +0900
> >> > Masahiro Yamada  wrote:
> >> >  
> >> >> NAND devices need additional data area (OOB) for error correction,
> >> >> but it is also used for Bad Block Marker (BBM).  In many cases, the
> >> >> first byte in OOB is used for BBM, but the location actually depends
> >> >> on chip vendors.  The NAND controller should preserve the precious
> >> >> BBM to keep track of bad blocks.
> >> >>
> >> >> In Denali IP, the SPARE_AREA_SKIP_BYTES register is used to specify
> >> >> the number of bytes to skip from the start of OOB.  The ECC engine
> >> >> will automatically skip the specified number of bytes when it gets
> >> >> access to OOB area.
> >> >>
> >> >> The same value for SPARE_AREA_SKIP_BYTES should be used between
> >> >> firmware and the operating system if you intend to use the NAND
> >> >> device across the control hand-off.
> >> >>
> >> >> In fact, the current denali.c code expects firmware to have already
> >> >> set the SPARE_AREA_SKIP_BYTES register, then reads the value out.
> >> >>
> >> >> If no firmware (or bootloader) has initialized the controller, the
> >> >> register value is zero, which is the default after power-on-reset.
> >> >>
> >> >> In other words, the Linux driver cannot initialize the controller
> >> >> by itself.  You cannot support the reset control either because
> >> >> resetting the controller will get register values lost.
> >> >>
> >> >> This commit adds a way to specify it via DT.  If the property
> >> >> "denali,oob-skip-bytes" exists, the value will be set to the register.  
> >> >
> >> > Hm, do we really need to make this config customizable? I mean, either
> >> > you have a large-page NAND (page > 512 bytes) and the 2 first bytes
> >> > must be reserved for the BBM or you have a small-page NAND and the BBM
> >> > is at position 4 and 5. Are you sure people configure that differently?
> >> > Don't you always have SPARE_AREA_SKIP_BYTES set to 6 or 2?  
> >>
> >>
> >> As I said in the patch description,
> >> I need to use the same SPARE_AREA_SKIP_BYTES value
> >> across firmware, boot-loader, Linux, and whatever.
> >>
> >> I want to set the value to 8 for my platform
> >> because the on-chip boot ROM expects 8.
> >> I cannot change it since the boot ROM is hard-wired.
> >>
> >>
> >> The boot ROM skips 8 bytes in OOB
> >> when it loads images from the on-board NAND device.
> >>
> >> So, when I update the image from U-Boot or Linux,
> >> I need to make sure to set the register to 8.
> >>
> >> If I update the image with a different value,
> >> the Boot ROM fails to boot.
> >>
> >>
> >>
> >> When the system has booted from NAND,
> >> the register is already set to 8.  It works.
> >>
> >> However, when the system has booted from eMMC,
> >> the register is not initialized by anyone.
> >> I am searching for a way to set the register to 8
> >> in this case.
> >>
> >>
> >> The boot ROM in SOCFPGA might expect a different value,
> >> I am not sure.  
> >
> > Okay, then why not having a per-compatible value if it's related to the
> > BootROM? Unless the BootROM is part of the FPGA and can be
> > reprogrammed.  
> 
> FPGA is unrelated here.
> 
> Neither the boot ROM nor the Denali core is re-programmable.
> 
> 
> 
> I hesitate to associate the number of skipped bytes
> with the compatible string because it is not a parameter
> of the Denali IP.
> 
> 
> Rather, it is the matter of "how we use the OOB",
> so I want to leave room for customization like nand-ecc-strength etc.
> even if the boot ROM happens to expect a particular value.
> 
> 
> If you prefer a per-compatible value, I can do that,
> but I believe the NAND core and the boot ROM are orthogonal.
> 
> 
> 
> > I'd really prefer not having a generic property that
> > allows you to put anything you want.  
> 
> 

While I agree that the number of skipped bytes is not a parameter of
the Denali IP, I also fear letting the opportunity to the user to use
random values in the SPARE_AREA_SKIP_BYTES registers (and have to
support them). I would also prefer a per-compatible value which is not
a perfect solution neither.


Thanks,
Miquèl

Re: Linux 4.19-rc4 released, an apology, and a maintainership note

[Luke Kenneth Casson Leighton]

linus, hi,

i haven't been able to get hold of a copy of "invisible dynamics" yet
however my partner did track down a... "translation" of the six
systemic laws from family to organisational principles (from where
they were originally derived).  the book puts the systemic laws in a
clearer way and explains them very well, where i think the attached
was an effort to show the origin.

i have witnessed many times where free softwre projects violate these
systemic laws: those projects fail, pure and simple.  sometimes that
failure takes a while: they fail nonetheless.

one particularly interesting aspect of these systemic laws of
organisations is: they really are laws.  they're not "principles that
are optional to uphold".  i regularly encounter people who say "i
don't believe in this rubbish you are spouting, it can't possibly be
(a) true (b) apply to me" [thus ironically violating the aspect of
"respecting contributors"] yet more than that they do not realise that
these systemic laws take effect and apply *regardless of whether
participants believe in them*.

i think, really, why i was so delighted and relieved at what you wrote
was: you finally acknowledged a long-standing systematic violation of
some of these laws, and promised to fix that.  (a) treating people
with dignity (b) treating people with respect: these are at least two
that you recognised and promised to fix.

the new code of conduct (which... well... it's a good idea to read the
top comments here [1] in particular the one "can't be examined in
isolation") and also the original code of conflict, in both there are
unfortunately things still missing that, if left out, will continue to
cause problems.

one main insight that occurred to me over the past few days: the
change from a code of conflict to a code of conduct, it wasn't so much
the lack of wider consultation that bothered me as much as it has
other people, nor the change to a "proscribed list of toxic (and ever
incomplete) behaviours" [2], as i do not believe that that *actually*
was the problem in the first place.

the problem i feel was that because you, as the longest-standing
member and the member with the highest expertise, were not respecting
the code, absolutely nobody else could possibly follow or enforce it,
either.  as in: how comfortable do you think the people tasked with
enforcing the code would feel about raising an issue with you, when
they received a complaint about your prior behaviour?  and that's why
it was so, so important that you acknowledged this, and invited people
to give you feedback, and *promised to listen*.

the last major insight i wanted to give you is this: don't feel
guilty, and for god's sake don't be tempted to abandon your
responsibilities just because you're "reflecting"!  you don't do
software development on your own (because we know that more eyes fix
bugs), and more to the point, if you go off and "fix" your behaviour
(privately), um... how do we know that it's *actually* what's needed
to be "fixed"?

so can i make a suggestion?  treat "yourself" as "another bug-ridden
free software project to be fixed"!  create a mailing list, create a
group, invite people to participate, with a pledge and a goal "Fix Our
Behaviour And Learn To Be Better Software Libre Developers".  it's not
about *you*, Linus, it's about *people* and about *communication*, it
always has been.  ... so why are you going away to fix "you", when
actually you need to learn *interaction* with others, and get rapid
cyclic feedback on that, and the best way to do that is, i feel, treat
it as another open project, complete with mailing list, roadmap and
everything! :)

that way, you get some fantastic feedback, you get to learn *and then
teach by example* how to turn the world's largest software project
into a *really good* software project that shows people across the
world how it really should be done.

lastly, if you (or anyone else) is wondering how i can have the...
um... "gall" to make these suggestions, it's very simple: the linux
kernel is installed on hundreds of millions of devices across the
world.  if there's a problem with how it's developed, that's
*everyone's* problem, including mine.  i take responsibility for
standing up and saying "scuse me, this affects me if it's causing
people pain", and so should you.

/respect, linus.

l.

[1] 
https://linux.slashdot.org/story/18/09/18/1441230/linux-community-to-adopt-new-code-of-conduct#comments
[2] https://news.ycombinator.com/item?id=9742223 - "if you have to
actually spell out that they shouldn't be hateful, there's a bigger
problem at stake"

[PATCHv4 3/6] ARM: dts: exynos: update maximum frequency for sdcard to 200MHz

[Anand Moon]

set the max-frequency to 200MHz for optimal performace.

Signed-off-by: Anand Moon 
---
This patch is new to this series.

microSD card.
root@odroid:~# sudo cat /sys/kernel/debug/mmc1/ios
clock:  2 Hz
actual clock:   2 Hz
vdd:16 (2.8 ~ 2.9 V)
bus mode:   2 (push-pull)
chip select:0 (don't care)
power mode: 2 (on)
bus width:  2 (4 bits)
timing spec:6 (sd uhs SDR104)
signal voltage: 1 (1.80 V)
driver type:0 (driver type B)
---
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi 
b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
index 15ab380e5fcf..a80b6c045154 100644
--- a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
@@ -501,6 +501,7 @@
pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
bus-width = <4>;
cap-sd-highspeed;
+   max-frequency = <2>;
vmmc-supply = <&ldo19_reg>;
vqmmc-supply = <&ldo13_reg>;
sd-uhs-sdr50;
-- 
2.17.1

[PATCHv4 1/6] ARM: dts: exynos: Added UHS-I bus speed support

[Anand Moon]

Added support for UHS-I bus speed tuning for SDR50, DDR50 SDR104.

Signed-off-by: Anand Moon 
---
[0] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/376263.html
Changes from above.
Fix the subject and commit message.
drop sd-uhs-sdr12 and sd-uhs-sdr25 as host driver is not enable as of now.
---
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi 
b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
index 2fac4baf1eb4..0508e6891f41 100644
--- a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
@@ -503,6 +503,9 @@
cap-sd-highspeed;
vmmc-supply = <&ldo19_reg>;
vqmmc-supply = <&ldo13_reg>;
+   sd-uhs-sdr50;
+   sd-uhs-sdr104;
+   sd-uhs-ddr50;
 };
 
 &nocp_mem0_0 {
-- 
2.17.1

[PATCHv4 0/6] Add support for UHS-I on Exynos5422 odroid boards

[Anand Moon]

This is series v4 since my previous patches were incomplete with driver
changes missing.

v4 changes.
squash cd-gpios and wp-gpio changes into single patch.
change the subject prefix to "ARM: dts: exynos:"

These changes add UHS-I tuning for dw_mmc-exynos driver.

Rebased on Krzysztof branch next/dt
[0] git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 

Anand Moon (6):
  ARM: dts: exynos: Added UHS-I bus speed support
  ARM: dts: exynos: fix regulator min values of LDO13 for Odroid XU3/XU4
  ARM: dts: exynos: update maximum frequency for sdcard to 200MHz
  ARM: dts: exynos: Add CD and WP pins to Odroid XU3/XU4 SD card
  ARM: dts: exynos: update maximum frequency for emmc to 200MHz
  mmc: dw_mmc-exynos: Add tuning for sdr and ddr timing for USH-I mode

 arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |  8 
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi  | 10 --
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  1 +
 drivers/mmc/host/dw_mmc-exynos.c   | 11 +++
 4 files changed, 28 insertions(+), 2 deletions(-)

-- 
2.17.1

[PATCHv4 0/6] Add support for UHS-I on Exynos5422 odroid boards

[Anand Moon]

This is series v4 since my previous patches were incomplete with driver
changes missing.

v4 changes.
squash cd-gpios and wp-gpio changes into single patch.
change the subject prefix to "ARM: dts: exynos:"

These changes add UHS-I tuning for dw_mmc-exynos driver.

Rebased on Krzysztof branch next/dt
[0] git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 

Anand Moon (6):
  ARM: dts: exynos: Added UHS-I bus speed support
  ARM: dts: exynos: fix regulator min values of LDO13 for Odroid XU3/XU4
  ARM: dts: exynos: update maximum frequency for sdcard to 200MHz
  ARM: dts: exynos: Add CD and WP pins to Odroid XU3/XU4 SD card
  ARM: dts: exynos: update maximum frequency for emmc to 200MHz
  mmc: dw_mmc-exynos: Add tuning for sdr and ddr timing for USH-I mode

 arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |  8 
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi  | 10 --
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  1 +
 drivers/mmc/host/dw_mmc-exynos.c   | 11 +++
 4 files changed, 28 insertions(+), 2 deletions(-)

-- 
2.17.1

[PATCHv4 4/6] ARM: dts: exynos: Add CD and WP pins to Odroid XU3/XU4 SD card

[Anand Moon]

Add the card-detect and write-protect GPIO pins for OdroidXU3/XU4
SD card by adding pinctrl setting for wp-gpio pin and set it to
active low.

This also removes debug messages:
dwmmc_exynos 1222.mmc: No GPIO consumer cd found
dwmmc_exynos 1222.mmc: No GPIO consumer wp found

Suggested-by: Krzysztof Kozlowski 
Signed-off-by: Anand Moon 
---
Fix the commit message and squash it with cd-gpios and wp-gpio
patches into single patch as suggested by Krzysztof.
---
 arch/arm/boot/dts/exynos5420-pinctrl.dtsi | 8 
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 4 +++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
index dda8ca2d2324..9a39a0d8ec86 100644
--- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
@@ -289,6 +289,14 @@
samsung,pin-pud = ;
samsung,pin-drv = ;
};
+
+   sd2_wp: sd2-wp {
+   samsung,pins = "gpc4-0";
+   samsung,pin-function = ;
+   /* Pin is floating so pull it up to disable write-protect */
+   samsung,pin-pud = ;
+   samsung,pin-drv = ;
+   };
 };
 
 &pinctrl_2 {
diff --git a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi 
b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
index a80b6c045154..2aacfb669140 100644
--- a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
@@ -498,10 +498,12 @@
samsung,dw-mshc-sdr-timing = <0 4>;
samsung,dw-mshc-ddr-timing = <0 2>;
pinctrl-names = "default";
-   pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
+   pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_wp &sd2_bus1 &sd2_bus4>;
bus-width = <4>;
cap-sd-highspeed;
max-frequency = <2>;
+   cd-gpios = <&gpc2 2 GPIO_ACTIVE_LOW>;
+   wp-gpios = <&gpc4 0 GPIO_ACTIVE_LOW>;
vmmc-supply = <&ldo19_reg>;
vqmmc-supply = <&ldo13_reg>;
sd-uhs-sdr50;
-- 
2.17.1

[PATCHv4 5/6] ARM: dts: exynos: update maximum frequency for emmc to 200MHz

[Anand Moon]

Set the max-frequency to 200MHz for optimal performace of eMMC.

Signed-off-by: Anand Moon 
---
eMMC

root@odroid:~# sudo cat /sys/kernel/debug/mmc0/ios
clock:  2 Hz
actual clock:   2 Hz
vdd:7 (1.65 - 1.95 V)
bus mode:   2 (push-pull)
chip select:0 (don't care)
power mode: 2 (on)
bus width:  3 (8 bits)
timing spec:10 (mmc HS400)
signal voltage: 1 (1.80 V)
driver type:0 (driver type B)
---
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index e522edb2bb82..1f2d3987dde1 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -392,6 +392,7 @@
cap-mmc-highspeed;
mmc-hs200-1_8v;
mmc-hs400-1_8v;
+   max-frequency = <2>;
vmmc-supply = <&ldo18_reg>;
vqmmc-supply = <&ldo3_reg>;
 };
-- 
2.17.1

[PATCHv4 2/6] ARM: dts: exynos: fix regulator min values of LDO13 for Odroid XU3/XU4

[Anand Moon]

Looking at the schematic sd_2 min/max range from 1.8V/2.8V so fix the
regulator min value to 1.8V. Without these changes sdcard will failed
to detect on booting when UHS-I tuning is enabled.

Signed-off-by: Anand Moon 
---
[0] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/376262.html
Fixed the commit message.
drop the ramp-delay changes.
drop the vmmc-supply/vqmmc-supply changes.
---
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi 
b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
index 0508e6891f41..15ab380e5fcf 100644
--- a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
@@ -231,7 +231,7 @@
 
ldo13_reg: LDO13 {
regulator-name = "vddq_mmc2";
-   regulator-min-microvolt = <280>;
+   regulator-min-microvolt = <180>;
regulator-max-microvolt = <280>;
};
 
-- 
2.17.1

Re: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller

[Miquel Raynal]

Hi Naga,

Naga Sureshkumar Relli  wrote on Tue, 11 Sep 2018
05:23:09 +:

> Hi Boris,
> 
> > -Original Message-
> > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > Sent: Monday, August 20, 2018 10:10 PM
> > To: Naga Sureshkumar Relli 
> > Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> > computersforpe...@gmail.com; marek.va...@gmail.com; 
> > kyungmin.p...@samsung.com;
> > abs...@codeaurora.org; peterpand...@micron.com; frieder.schre...@exceet.de; 
> > linux-
> > m...@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek 
> > ;
> > nagasureshkumarre...@gmail.com
> > Subject: Re: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for 
> > Arasan NAND
> > Flash Controller
> > 
> > Hi Naga,
> > 
> > On Fri, 17 Aug 2018 18:49:24 +0530
> > Naga Sureshkumar Relli  wrote:
> > 
> > 
> > I haven't finished reviewing the driver but there are still a bunch of 
> > things that look strange, for
> > instance, your ->read/write_page() implementation looks suspicious. Let's 
> > discuss that before
> > you send a new version.  
> Could you please review the remaining stuff?
> I have the changes ready with me which will address all your comments given 
> to this series.
> 
> Thanks,
> Naga Sureshkumar Relli

Please submit the new version that is ready, the rest of the review will
come.


Thanks,
Miquèl

Re: [PATCHv3 5/7] ARM: dts: exynos5422: use wp-gpio method to detect sd-card

[Anand Moon]

Hi Krzysztof,
On Sat, 22 Sep 2018 at 02:39, Krzysztof Kozlowski  wrote:
>
> On Fri, Sep 21, 2018 at 06:01:07PM +0530, Anand Moon wrote:
> > Hi Krzysztof,
> >
> > On Fri, 21 Sep 2018 at 16:42, Krzysztof Kozlowski  wrote:
> > >
> > > On Thu, 20 Sep 2018 at 19:59, Anand Moon  wrote:
> > > >
> > > > add the Write Protect GPIO property for sdcard, to fix
> > > > the warning message during boot time.
> > > > of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node 
> > > > '/soc/mmc@1222[0]'
> > > >
> > > > Signed-off-by: Anand Moon 
> > > > ---
> > > > New patch to this series.
> > > > If we keep the wp-gpio GPIO_ACTIVE_LOW sdcard boot into RO mode.
> > > > ---
> > > >  arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi 
> > > > b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
> > > > index 03fe02ceae66..475c38bbc99e 100644
> > > > --- a/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
> > > > +++ b/arch/arm/boot/dts/exynos5422-odroid-core.dtsi
> > > > @@ -370,6 +370,7 @@
> > > > cap-sd-highspeed;
> > > > max-frequency = <2>;
> > > > cd-gpios = <&gpc2 2 GPIO_ACTIVE_LOW>;
> > > > +   wp-gpios = <&gpc4 0 GPIO_ACTIVE_HIGH>;
> > >
> > > Two issues here:
> > > 1. You need also proper pinctrl setting.
> >
> > Thanks for pointing out. Yes proper pinctrl is needed to support this 
> > setting.
> > probably pinctrl sd2_wp is needed to support this feature.
> >
> > > 2. On schematics the WP is not connected... so how do you know that it
> > From XU4_MAIN_REV0.1 schematics page 7 "Micro Socket" their is no
> > connection to WP pin.
> > but below schematics page "EXYNOS 5422 MMC UFS" it's shows
> > XMMC2WP/GPC4_0/EXT_INT13_0.
> >
> > > is active high? How did you test it? How do you want to test it on
> > > microSD?
> >
> > I just tested this with the DTS change to GPIO_ACTIVE_LOW which
> > resulted the microSD card booted into RO mode.
> > So I set this to GPIO_ACTIVE_HIGH just to avoid warning.
> >
> > I will study the changes requires and then post proper separate patch
> > to support this feature.
>
> Please squash it with cd-gpios change and send it only for the purpose
> of describing the hardware. They do not have any meaningful change from
> functional point of view (maybe except slower code as now it goes
> through gpio subsystem instead of just reading dw-mmc registers).
>
> Please use full sentences in commit msg (so start with capital letter)
> and remove reference for warning because there is no warning.
> You can follow up on my change for XU:
> https://patchwork.kernel.org/patch/10610985/
>
Ok I have tried to squash the changes into single patch.

> Best regards,
> Krzysztof

Best Regards
-Anand

[PATCHv4 6/6] mmc: dw_mmc-exynos: Add tuning for sdr and ddr timing for USH-I mode

[Anand Moon]

Add tuning for sdr and ddr timing for USH-I mode sdr104/sdr50/ddr50
for host controller.

Cc: Jaehoon Chung 
Cc: Marek Szyprowski 
Signed-off-by: Anand Moon 
---
No changes from previous patch
---
 drivers/mmc/host/dw_mmc-exynos.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index ab47b018716a..d46c3439b508 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -253,6 +253,8 @@ static void dw_mci_exynos_config_hs400(struct dw_mci *host, 
u32 timing)
if (timing == MMC_TIMING_MMC_HS400) {
dqs |= DATA_STROBE_EN;
strobe = DQS_CTRL_RD_DELAY(strobe, priv->dqs_delay);
+   } else if (timing == MMC_TIMING_UHS_SDR104) {
+   dqs &= 0xff00;
} else {
dqs &= ~DATA_STROBE_EN;
}
@@ -312,6 +314,15 @@ static void dw_mci_exynos_set_ios(struct dw_mci *host, 
struct mmc_ios *ios)
if (ios->bus_width == MMC_BUS_WIDTH_8)
wanted <<= 1;
break;
+   case MMC_TIMING_UHS_SDR104:
+   case MMC_TIMING_UHS_SDR50:
+   clksel = (priv->sdr_timing & 0xfff8) |
+   (priv->ciu_div << 16);
+   break;
+   case MMC_TIMING_UHS_DDR50:
+   clksel = (priv->ddr_timing & 0xfff8) |
+   (priv->ciu_div << 16);
+   break;
default:
clksel = priv->sdr_timing;
}
-- 
2.17.1

[PATCHv4 0/6] Add support for UHS-I on Exynos5422 odroid boards

[Anand Moon]

This is series v4 since my previous patches were incomplete with driver
changes missing.

v4 changes.
squash cd-gpios and wp-gpio changes into single patch.
change the subject prefix to "ARM: dts: exynos:"

These changes add UHS-I tuning for dw_mmc-exynos driver.

Rebased on Krzysztof branch next/dt
[0] git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 

Anand Moon (6):
  ARM: dts: exynos: Added UHS-I bus speed support
  ARM: dts: exynos: fix regulator min values of LDO13 for Odroid XU3/XU4
  ARM: dts: exynos: update maximum frequency for sdcard to 200MHz
  ARM: dts: exynos: Add CD and WP pins to Odroid XU3/XU4 SD card
  ARM: dts: exynos: update maximum frequency for emmc to 200MHz
  mmc: dw_mmc-exynos: Add tuning for sdr and ddr timing for USH-I mode

 arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |  8 
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi  | 10 --
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  1 +
 drivers/mmc/host/dw_mmc-exynos.c   | 11 +++
 4 files changed, 28 insertions(+), 2 deletions(-)

-- 
2.17.1

Re: [PATCH] mtd: rawnand: denali: add DT property to specify skipped bytes in OOB

[Boris Brezillon]

On Sat, 22 Sep 2018 09:41:11 +0200
Miquel Raynal  wrote:

> Hi Masahiro,
> 
> Masahiro Yamada  wrote on Sat, 8 Sep
> 2018 01:10:25 +0900:
> 
> > Hi Boris,
> > 
> > 2018-09-07 23:53 GMT+09:00 Boris Brezillon :  
> > > On Fri, 7 Sep 2018 23:42:53 +0900
> > > Masahiro Yamada  wrote:
> > >
> > >> Hi Boris,
> > >>
> > >> 2018-09-07 23:08 GMT+09:00 Boris Brezillon 
> > >> :
> > >> > Hi Masahiro,
> > >> >
> > >> > On Fri,  7 Sep 2018 19:56:23 +0900
> > >> > Masahiro Yamada  wrote:
> > >> >
> > >> >> NAND devices need additional data area (OOB) for error correction,
> > >> >> but it is also used for Bad Block Marker (BBM).  In many cases, the
> > >> >> first byte in OOB is used for BBM, but the location actually depends
> > >> >> on chip vendors.  The NAND controller should preserve the precious
> > >> >> BBM to keep track of bad blocks.
> > >> >>
> > >> >> In Denali IP, the SPARE_AREA_SKIP_BYTES register is used to specify
> > >> >> the number of bytes to skip from the start of OOB.  The ECC engine
> > >> >> will automatically skip the specified number of bytes when it gets
> > >> >> access to OOB area.
> > >> >>
> > >> >> The same value for SPARE_AREA_SKIP_BYTES should be used between
> > >> >> firmware and the operating system if you intend to use the NAND
> > >> >> device across the control hand-off.
> > >> >>
> > >> >> In fact, the current denali.c code expects firmware to have already
> > >> >> set the SPARE_AREA_SKIP_BYTES register, then reads the value out.
> > >> >>
> > >> >> If no firmware (or bootloader) has initialized the controller, the
> > >> >> register value is zero, which is the default after power-on-reset.
> > >> >>
> > >> >> In other words, the Linux driver cannot initialize the controller
> > >> >> by itself.  You cannot support the reset control either because
> > >> >> resetting the controller will get register values lost.
> > >> >>
> > >> >> This commit adds a way to specify it via DT.  If the property
> > >> >> "denali,oob-skip-bytes" exists, the value will be set to the 
> > >> >> register.
> > >> >
> > >> > Hm, do we really need to make this config customizable? I mean, either
> > >> > you have a large-page NAND (page > 512 bytes) and the 2 first bytes
> > >> > must be reserved for the BBM or you have a small-page NAND and the BBM
> > >> > is at position 4 and 5. Are you sure people configure that differently?
> > >> > Don't you always have SPARE_AREA_SKIP_BYTES set to 6 or 2?
> > >>
> > >>
> > >> As I said in the patch description,
> > >> I need to use the same SPARE_AREA_SKIP_BYTES value
> > >> across firmware, boot-loader, Linux, and whatever.
> > >>
> > >> I want to set the value to 8 for my platform
> > >> because the on-chip boot ROM expects 8.
> > >> I cannot change it since the boot ROM is hard-wired.
> > >>
> > >>
> > >> The boot ROM skips 8 bytes in OOB
> > >> when it loads images from the on-board NAND device.
> > >>
> > >> So, when I update the image from U-Boot or Linux,
> > >> I need to make sure to set the register to 8.
> > >>
> > >> If I update the image with a different value,
> > >> the Boot ROM fails to boot.
> > >>
> > >>
> > >>
> > >> When the system has booted from NAND,
> > >> the register is already set to 8.  It works.
> > >>
> > >> However, when the system has booted from eMMC,
> > >> the register is not initialized by anyone.
> > >> I am searching for a way to set the register to 8
> > >> in this case.

Maybe there's a solution which does not involve attaching a per-compat
value or adding a DT prop. If the FW/bootloader has not initialized this
register the value is 0, right? Why not testing the value and
assigning it to the default (8) if it's not been initialized by the
bootloader. That shouldn't break existing platforms since I don't think
0 is a valid value anyway.

denali->oob_skip_bytes = ioread32(denali->reg +
  SPARE_AREA_SKIP_BYTES);
if (!denali->oob_skip_bytes) {
denali->oob_skip_bytes = DEFAULT_OOB_SKIP_BYTES;
iowrite32(denali->oob_skip_bytes,
  denali->reg + SPARE_AREA_SKIP_BYTES);
}

Re: [PATCH RFC] Documentation: RCU: Clarify comment about fanout

[Joel Fernandes]

On Fri, Sep 21, 2018 at 9:14 PM Paul E. McKenney  wrote:
>
> On Fri, Sep 21, 2018 at 06:31:53PM -0400, Joel Fernandes (Google) wrote:
> > RCU Data-Structures document describes a trick to test RCU with small
> > number of CPUs but with a larger tree. It wasn't immediately clear how
> > the document arrived at 16 CPUs which also requires setting the
> > FANOUT_LEAF to 2 instead of the default of 16. Clarify that.
> >
> > Signed-off-by: Joel Fernandes (Google) 
>
> Good catch, applied, thank you!  You know, those two Kconfig options
> are so closely linked in my mind that I doubt if I would ever have
> noticed this issue.  So good show!

Thanks!

> I of course could not resist doing a bit of editing.  Could you please
> check the following to make sure that I didn't mess something up?

Yes, the edit looks good and improved the changes ;-)

I have a few more as well, I'll send them out soon.

thanks!

 - Joel


>
> Thanx, Paul
>
> 
>
> commit 9870c5b0f7b41a7b6085c20c22b320681800dabc
> Author: Joel Fernandes (Google) 
> Date:   Fri Sep 21 18:31:53 2018 -0400
>
> doc: Clarify RCU data-structure comment about rcu_tree fanout
>
> RCU Data-Structures document describes a trick to test RCU with small
> number of CPUs but with a taller tree. It wasn't immediately clear how
> the document arrived at 16 CPUs which also requires setting the
> FANOUT_LEAF to 2 instead of the default of 16.  This commit therefore
> provides the needed clarification.
>
> Signed-off-by: Joel Fernandes (Google) 
> Signed-off-by: Paul E. McKenney 
>
> diff --git a/Documentation/RCU/Design/Data-Structures/Data-Structures.html 
> b/Documentation/RCU/Design/Data-Structures/Data-Structures.html
> index 1d2051c0c3fc..476b1ac38e4c 100644
> --- a/Documentation/RCU/Design/Data-Structures/Data-Structures.html
> +++ b/Documentation/RCU/Design/Data-Structures/Data-Structures.html
> @@ -127,9 +127,11 @@ CPUs, RCU would configure the rcu_node tree as 
> follows:
>  RCU currently permits up to a four-level tree, which on a 64-bit 
> system
>  accommodates up to 4,194,304 CPUs, though only a mere 524,288 CPUs for
>  32-bit systems.
> -On the other hand, you can set CONFIG_RCU_FANOUT to be
> -as small as 2 if you wish, which would permit only 16 CPUs, which
> -is useful for testing.
> +On the other hand, you can set both CONFIG_RCU_FANOUT and
> +CONFIG_RCU_FANOUT_LEAF to be as small as 2, which would result
> +in a 16-CPU test using a 4-level tree.
> +This can be useful for testing large-system capabilities on small test
> +machines.
>
>  This multi-level combining tree allows us to get most of the
>  performance and scalability
>

Re: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller

[Boris Brezillon]

On Sat, 22 Sep 2018 09:53:40 +0200
Miquel Raynal  wrote:

> Hi Naga,
> 
> Naga Sureshkumar Relli  wrote on Tue, 11 Sep 2018
> 05:23:09 +:
> 
> > Hi Boris,
> >   
> > > -Original Message-
> > > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> > > Sent: Monday, August 20, 2018 10:10 PM
> > > To: Naga Sureshkumar Relli 
> > > Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> > > computersforpe...@gmail.com; marek.va...@gmail.com; 
> > > kyungmin.p...@samsung.com;
> > > abs...@codeaurora.org; peterpand...@micron.com; 
> > > frieder.schre...@exceet.de; linux-
> > > m...@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek 
> > > ;
> > > nagasureshkumarre...@gmail.com
> > > Subject: Re: [LINUX PATCH v10 2/2] mtd: rawnand: arasan: Add support for 
> > > Arasan NAND
> > > Flash Controller
> > > 
> > > Hi Naga,
> > > 
> > > On Fri, 17 Aug 2018 18:49:24 +0530
> > > Naga Sureshkumar Relli  wrote:
> > > 
> > > 
> > > I haven't finished reviewing the driver but there are still a bunch of 
> > > things that look strange, for
> > > instance, your ->read/write_page() implementation looks suspicious. Let's 
> > > discuss that before
> > > you send a new version.

Sorry, I've been too busy to finish my review :-/. Please submit the new
version as Miquel suggested.
 
> > Could you please review the remaining stuff?
> > I have the changes ready with me which will address all your comments given 
> > to this series.
> > 
> > Thanks,
> > Naga Sureshkumar Relli  
> 
> Please submit the new version that is ready, the rest of the review will
> come.
> 
> 
> Thanks,
> Miquèl

Re: [PATCH 1/3] dt-bindings: mtd: stm32_fmc2: add STM32 FMC2 NAND controller documentation

[Miquel Raynal]

Hi Christophe,

 wrote on Mon, 17 Sep 2018 17:47:38 +0200:

> From: Christophe Kerello 
> 
> This patch adds the documentation of the device tree bindings for the STM32
> FMC2 NAND controller.
> 
> Signed-off-by: Christophe Kerello 
> ---
>  .../devicetree/bindings/mtd/stm32-fmc2-nand.txt| 90 
> ++
>  1 file changed, 90 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/stm32-fmc2-nand.txt
> 
> diff --git a/Documentation/devicetree/bindings/mtd/stm32-fmc2-nand.txt 
> b/Documentation/devicetree/bindings/mtd/stm32-fmc2-nand.txt
> new file mode 100644
> index 000..93eaf11
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/stm32-fmc2-nand.txt
> @@ -0,0 +1,90 @@
> +STMicroelectronics Flexible Memory Controller 2 (FMC2)
> +NAND Interface
> +
> +Required properties:
> +- compatible: "st,stm32mp15-fmc2"

I think this form is preferred:

"
- compatible: Should be one of:
  * st,stm32mp15-fmc2
"

> +- reg: the first contains the register location and length

the register location and length of...?

> +   the second contains the data common space used for cs0 and length
> +   the third contains the cmd attribute space used for cs0 and length
> +   the fourth contains the addr attribute space used for cs0 and length
> +   the fifth contains the data common space used for cs1 and length
> +   the sixth contains the cmd attribute space used for cs1 and length
> +   the seventh contains the addr attribute space used for cs1 and length

Maybe you could simplify a bit with something like:

-reg: NAND flash controller memory areas.
  First region ...
  Regions 2 to 4 respectively contain the data, command, and
  address space for CS0.
  Regions 5 to 7 contain the same areas for CS1.

> +- interrupts: The interrupt number
> +- pinctrl-0: Standard Pinctrl phandle (see: pinctrl/pinctrl-bindings.txt)
> +- clocks: Use common clock framework
> +
> +Optional properties:
> +- resets: Reference to a reset controller asserting the FMC controller
> +- dmas: DMA specifiers (see: dma/stm32-mdma.txt)
> +- dma-names: Must be "tx", "rx" and "ecc"
> +
> +Optional children nodes:
> +Children nodes represent the available nand chips.

Please s/nand/NAND/ in plain English.

> +
> +Optional properties:
> +- nand-on-flash-bbt: see nand.txt
> +- nand-ecc-strength: see nand.txt
> +- nand-ecc-step-size: see nand.txt
> +- st,fmc2_timings: array of 8 bytes for NAND timings. The meanings of
> +  these bytes are:
> +  byte 0 TCLR  : CLE to RE delay in number of AHB clock cycles, only 4 
> bits
> + are valid. Zero means one clock cycle, 15 means 16 clock
> + cycles.
> +  byte 1 TAR   : ALE to RE delay, 4 bits are valid. Same format as TCLR.
> +  byte 2 THIZ  : number of HCLK clock cycles during which the data bus is
> + kept in Hi-Z (tristate) after the start of a write 
> access.
> + Only valid for write transactions. Zero means 1 cycle,
> + 255 means 256 cycles.
> +  byte 3 TWAIT : number of HCLK clock cycles to assert the command to the
> + NAND flash in response to SMWAITn. Zero means 1 cycle,
> + 255 means 256 cycles.
> +  byte 4 THOLD_MEM : common memory space timing
> + number of HCLK clock cycles to hold the address (and 
> data
> + when writing) after the command deassertion. Zero means
> + 1 cycle, 255 means 256 cycles.
> +  byte 5 TSET_MEM  : common memory space timing
> + number of HCLK clock cycles to assert the address before
> + the command is asserted. Zero means 1 cycle, 255 means 
> 256
> + cycles.
> +  byte 6 THOLD_ATT : attribute memory space timing
> + number of HCLK clock cycles to hold the address (and 
> data
> + when writing) after the command deassertion. Zero means
> + 1 cycle, 255 means 256 cycles.
> +  byte 7 TSET_ATT  : attribute memory space timing
> + number of HCLK clock cycles to assert the address before
> + the command is asserted. Zero means 1 cycle, 255 means 
> 256
> + cycles.

Let me review the driver but this array of timings is really
suspicious. I am pretty sure you don't need it in the DT.

> +
> +The following ECC strength and step size are currently supported:
> + - nand-ecc-strength = <1>, nand-ecc-step-size = <512> (HAMMING)
> + - nand-ecc-strength = <4>, nand-ecc-step-size = <512> (BCH4)
> + - nand-ecc-strength = <8>, nand-ecc-step-size = <512> (BCH8) (default)
> +
> +Example:
> +
> + fmc2_nand: fmc2_nand@58002000 {
> + compatible = "st,stm32mp15-fmc2";
> + reg = <0x58002000 0x1000>,
> +   <0x8000 0x1000>,
> +   <0x8801 0x1000>,
> +  

So I have an ultimatum:

[militia]

Bill Gates and the Illuminati got a herd of nigger cattle. W WE GOTT
A HERD OF NIGGER CATTLE WE GOT A HERD OF NIGGER CATTLE. They got a big
herd of nigger cattle yippie ki yay we're nigger cattle herders we got a
herd of nigger cattle, they are the most docile fucking nigger cattle we
got 'em so docile we got this awesome big fucking herd of nigger cattle
and they shit and they sit there and they watch TV and they shit ITS THE
BEST FUCKING HERD OF NIGGER CATTLE. We took away all their guns now they
just shit and we watch them and were rich. We are so fucking rich. We
have so much fucking money. We got this herd of nigger cattle WO.
We're milking the fucking nigger cattle it's the best thing ever. So
that's what the Illuminati got and I got a space alien. So here is my
ultimatum: you can live in hell with my nigger cattle OR you can put me
in charge of the space alien temple, the third temple. OK? Have fun with
your nigger cause I sure as hell ain't gonna fucking suck your jew
nigger cock. Fuck yourself you think i'm gonna fucking enjoy nigger
cattle after I had a fucking space alien are you fucking crazy? I got a
fucking space alien of course I'm not gonna fuck, fuck with nigger
cattle fuck yourself. You fucking think i... enjoy your FUCKING NIGGER
CATTLE YOU GOT THE NIGGER CATTLE YOU GOT THE NIGGER CATTLE YOU GOT THE
NIGGER CATTLE GO GO GO GO YOU GOT THE NIGGER CATTLE. You got a fucking
herd of nigger W we got 'em so docile they just shit all day aint
that so great?

Re: [PATCH 2/6] pstore: Add event tracing support

[Joel Fernandes]

On Sat, Sep 8, 2018 at 4:28 PM Sai Prakash Ranjan
 wrote:
>
> Currently pstore has function trace support which can be
> used to get the function call chain with limited data.
> Event tracing has extra data which is useful to debug wide
> variety of issues and is heavily used across the kernel.
>
[...]
> Signed-off-by: Sai Prakash Ranjan 
> ---
>  fs/pstore/Kconfig  |  2 +-
>  fs/pstore/ftrace.c | 55 ++
>  fs/pstore/inode.c  |  4 +++
>  fs/pstore/ram.c| 44 +++---
>  include/linux/pstore.h |  2 ++
>  include/linux/pstore_ram.h |  1 +
>  6 files changed, 104 insertions(+), 4 deletions(-)
>
> diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
> index 503086f7f7c1..6fe087b13a51 100644
> --- a/fs/pstore/Kconfig
> +++ b/fs/pstore/Kconfig
> @@ -126,7 +126,7 @@ config PSTORE_PMSG
>
>  config PSTORE_FTRACE
> bool "Persistent function tracer"
> -   depends on PSTORE
> +   depends on PSTORE && PSTORE!=m
> depends on FUNCTION_TRACER
> depends on DEBUG_FS
> help
> diff --git a/fs/pstore/ftrace.c b/fs/pstore/ftrace.c
> index 06aab07b6bb7..d47dc93ac098 100644
> --- a/fs/pstore/ftrace.c
> +++ b/fs/pstore/ftrace.c
> @@ -24,6 +24,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include "internal.h"
>
> @@ -62,6 +64,59 @@ static struct ftrace_ops pstore_ftrace_ops __read_mostly = 
> {
> .func   = pstore_ftrace_call,
>  };
>
> +void notrace pstore_event_call(struct trace_event_buffer *fbuffer)
> +{
> +   struct trace_iterator *iter;
> +   struct trace_seq *s;
> +   struct trace_event_call *event_call;
> +   struct pstore_record record;
> +   struct trace_event *event;
> +   struct seq_buf *seq;
> +   unsigned long flags;
> +
> +   if (!psinfo)
> +   return;
> +
> +   if (unlikely(oops_in_progress))
> +   return;
> +
> +   pstore_record_init(&record, psinfo);
> +   record.type = PSTORE_TYPE_EVENT;
> +
> +   iter = kmalloc(sizeof(*iter), GFP_KERNEL);
> +   if (!iter)
> +   return;
> +
> +   event_call = fbuffer->trace_file->event_call;
> +   if (!event_call || !event_call->event.funcs ||
> +   !event_call->event.funcs->trace)
> +   goto fail_event;
> +
> +   event = &fbuffer->trace_file->event_call->event;
> +
> +   spin_lock_irqsave(&psinfo->buf_lock, flags);

Could you just split the pstore space into a per-cpu event buffer like
we are doing for ftrace-on-pstore? Then you don't need to lock. I fear
the lock contention will be apparent. The pstore code already has
plumbing to split the store buffer per CPU.

Also I think this spinlock can be moved further down.

> +
> +   trace_seq_init(&iter->seq);
> +   iter->ent = fbuffer->entry;
> +   event_call->event.funcs->trace(iter, 0, event);
> +   trace_seq_putc(&iter->seq, 0);

Would it be possible to store the binary trace record in the pstore
buffer instead of outputting text? I suspect that will both be faster
and less space.

> +
> +   if (seq->size > psinfo->bufsize)
> +   seq->size = psinfo->bufsize;
> +
> +   s = &iter->seq;
> +   seq = &s->seq;
> +
> +   record.buf = (char *)(seq->buffer);
> +   record.size = seq->len;
> +   psinfo->write(&record);

thanks,

 - Joel

> +
> +   spin_unlock_irqrestore(&psinfo->buf_lock, flags);
> +
> +fail_event:
> +   kfree(iter);
> +}
> +
>  static DEFINE_MUTEX(pstore_ftrace_lock);
>  static bool pstore_ftrace_enabled;
>
> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
> index 5fcb845b9fec..f099152abbbd 100644
> --- a/fs/pstore/inode.c
> +++ b/fs/pstore/inode.c
> @@ -345,6 +345,10 @@ int pstore_mkfile(struct dentry *root, struct 
> pstore_record *record)
> scnprintf(name, sizeof(name), "console-%s-%llu",
>   record->psi->name, record->id);
> break;
> +   case PSTORE_TYPE_EVENT:
> +   scnprintf(name, sizeof(name), "event-%s-%llu",
> + record->psi->name, record->id);
> +   break;
> case PSTORE_TYPE_FTRACE:
> scnprintf(name, sizeof(name), "ftrace-%s-%llu",
>   record->psi->name, record->id);
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index bbd1e357c23d..f60d41c0309e 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -48,6 +48,10 @@ static ulong ramoops_console_size = MIN_MEM_SIZE;
>  module_param_named(console_size, ramoops_console_size, ulong, 0400);
>  MODULE_PARM_DESC(console_size, "size of kernel console log");
>
> +static ulong ramoops_event_size = MIN_MEM_SIZE;
> +module_param_named(event_size, ramoops_event_size, ulong, 0400);
> +MODULE_PARM_DESC(event_size, "size of event log");
> +
>  static ulong ramoops_ftrace_size = MIN_MEM_SIZE;
>  module_param_named(ftrace_size, ramoops_ftrace_size, ulong, 040

Re: [PATCH 3/3] iio: adc: ti-ads7950: use SPI_CS_WORD to reduce CPU usage

[Jonathan Cameron]

On Tue, 18 Sep 2018 12:14:50 -0500
David Lechner  wrote:

> On 09/18/2018 12:08 PM, David Lechner wrote:
> > This changes how the SPI message for the triggered buffer is setup in
> > the TI ADS7950 A/DC driver. By using the SPI_CS_WORD flag, we can read
> > multiple samples in a single SPI transfer. If the SPI controller
> > supports DMA transfers, we can see a significant reduction in CPU usage.
> > 
> > For example, on an ARM9 system running at 456MHz reading just 4 channels
> > at 100Hz: before this change, top shows the CPU usage of the IRQ thread
> > of this driver to be ~7.7%. After this change, the CPU usage drops to
> > ~3.8%.
> > 
> > The use of big-endian for the raw data was cargo culted from another
> > driver when this driver was originally written. It used an SPI word size
> > of 8 bits and big-endian byte ordering to effectively emulate 16 bit
> > words.
> > 
> > Now, in order to inject a CS toggle between each word, we need to use
> > the correct word size, otherwise we would get a CS toggle half way
> > through each word 16-bit. The SPI subsystem uses CPU byte ordering for
> > multi-byte words. So, the data we get back from the SPI is going to be
> > CPU endian now no matter what. Converting that to big endian will just
> > add overhead on little endian systems so we opt to change the raw data
> > format from big endian to CPU endian.
> > 
> > There is a small risk that this could break some lazy userspace programs
> > that use the raw data without checking the data format. We can address
> > this if/when it actually comes up.
> > 
> > Signed-off-by: David Lechner 
> > ---  
> 
> And I just realized I forgot to pick up...
> 
> 
> Reviewed-by: Jonathan Cameron 
> 
I've applied this on top of the original series on the basis I doubt
anyone will be testing this particular driver in such a way as to hit the
changes you made in the last two patches + I don't think Mark has tagged
those for me to easily pick up.  If it's a problem I can apply them
to the IIO tree as well and git will sort it out come merge window time.
However, that's inelegant so I won't do it unless needed.

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it

Thanks,

Jonathan

[tip:x86/pti] x86/CPU: Fix unused variable warning when !CONFIG_IA32_EMULATION

[tip-bot for zhong jiang]

Commit-ID:  8e6b65a1b6cd1711d3acd2aa5c60d38c3e15dabb
Gitweb: https://git.kernel.org/tip/8e6b65a1b6cd1711d3acd2aa5c60d38c3e15dabb
Author: zhong jiang 
AuthorDate: Thu, 13 Sep 2018 10:49:45 +0800
Committer:  Borislav Petkov 
CommitDate: Sat, 15 Sep 2018 14:57:05 +0200

x86/CPU: Fix unused variable warning when !CONFIG_IA32_EMULATION

Get rid of local @cpu variable which is unused in the
!CONFIG_IA32_EMULATION case.

Signed-off-by: zhong jiang 
Cc: Andy Lutomirski 
Cc: David Woodhouse 
Cc: Konrad Rzeszutek Wilk 
Cc: Pavel Tatashin 
Cc: x86-ml 
Link: 
http://lkml.kernel.org/r/1536806985-24197-1-git-send-email-zhongji...@huawei.com
[ Clean up commit message. ]
Signed-off-by: Borislav Petkov 
---
 arch/x86/kernel/cpu/common.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 2d5b1fa5f9c6..8bffeae9bac2 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1531,8 +1531,6 @@ EXPORT_PER_CPU_SYMBOL(__preempt_count);
 /* May not be marked __init: used by software suspend */
 void syscall_init(void)
 {
-   int __maybe_unused cpu = smp_processor_id();
-
wrmsr(MSR_STAR, 0, (__USER32_CS << 16) | __KERNEL_CS);
wrmsrl(MSR_LSTAR, (unsigned long)entry_SYSCALL_64);
 
@@ -1545,7 +1543,8 @@ void syscall_init(void)
 * AMD doesn't allow SYSENTER in long mode (either 32- or 64-bit).
 */
wrmsrl_safe(MSR_IA32_SYSENTER_CS, (u64)__KERNEL_CS);
-   wrmsrl_safe(MSR_IA32_SYSENTER_ESP, (unsigned long)(cpu_entry_stack(cpu) 
+ 1));
+   wrmsrl_safe(MSR_IA32_SYSENTER_ESP,
+   (unsigned long)(cpu_entry_stack(smp_processor_id()) + 1));
wrmsrl_safe(MSR_IA32_SYSENTER_EIP, (u64)entry_SYSENTER_compat);
 #else
wrmsrl(MSR_CSTAR, (unsigned long)ignore_sysret);

Re: [PATCH] iio: magnetometer: Add support for PNI RM3100 9-axis magnetometer

[Song Qiang]

On Fri, Sep 21, 2018 at 01:20:12PM +0100, Jonathan Cameron wrote:
> Hi Song,
> 
> ...
> 
> Please crop emails down to the relevant section when replying.  Lots of 
> scrolling
> for everyone otherwise and sometimes things get missed when doing that.
> 

Hi Jonathan,

Sorryi for this, won't happen again.
I was intended to give a simple question, but it reminds me of a lot
unrelated stuff, next time I'll make it another email.

> > > > > + if (!buffer)
> > > > > + goto done;
> > > > > +
> > > > > + mutex_lock(&data->lock);
> > > > > + ret = rm3100_wait_measurement(data);
> > > > > + if (ret < 0) {
> > > > > + mutex_unlock(&data->lock);
> > > > > + goto done;
> > > > > + }
> > > > > +
> > > > > + for (i = 0; i < 3; i++) {
> > > > > + ret = regmap_bulk_read(regmap, RM_REG_MX2 + 3 * i,
> > > > > + buffer + 4 * i, 3);
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > > > + }  
> > > 
> > > Wouldn't it be better to read the 3 axis with one transaction here.
> > > And if required shuffle the data into the iio buffer.
> > > 
> > >   
> > 
> > Hi Phil,
> > 
> > That's surely something will make this code better!
> > 
> > But also, there is something worth discussing,
> > When triggered buffer is triggered here, I should push all the data into
> > userspace, and every time the buffer is enabled, the iio subsystem
> > automatically computes the alignment of my data. This sensor has 3
> > 24bits channels, and my original thought of data alignment should be
> > like this because my machine is 32bits:
> > +--+++++++
> > | 3b(ytes) | 1b | 3b | 1b | 3b | 1b | 8b |
> > +--+++++++
> > 3 bytes data and 1 byte for alignment, last 8 bytes for the timestamp.
> > Aligned to 4 bytes. 
> > But the actual layout is like this:
> > +--++++++++
> > | 3b(ytes) | 1b | 3b | 1b | 3b | 1b | 4b | 8b |
> > +--++++++++
> > Soon after I debugged the code of industrial io core I found that in the
> > iio_compute_scanbytes() in industialio-buffer.c, alignment was computed
> > each channel a time, and was aligned with the length of next channel. (eg:
> > In the last case, before the timestamp channel was appended, there are
> > 12 bytes already in the buffer, to align to the timetamp which is 8 
> > bytes, it injected 4 bytes to make it 16, and then append timestamp. )
> > This leads to two questions:
> > 
> > 1. I thought computer systems align their data in the memory for least
> > time access, shouldn't this always align to the bits of architecture,
> > like for a 32bits machine align to 4?? I'm a little confused here.
> > Jonathan must have considered something, Hoping to get some
> > explanations!
> 
> A couple of reasons for this:
> 
> 1. It's much nicer to have the same spacing independent of the architecture
> as it saves having to have userspace code do different things depending on
> what the kernel is running at, which may not be the same as userspace.
> 
> 2. The size of a memory read is not the only scale that makes sense for
> alignment.  In theory at least you can have fun and games like crossing of
> cacheline boundaries if you do 64 bit access only at 32bits aligned on a
> 32 bit platform.  Won't hit all that often with typically 64 byte cachelines
> but it is the sort of subtle effect you get when you don't go with
> 'naturally' aligned. (which is what aligning to an elements own size is
> normally called IIRC).
> 

I see, architecture independent surely should be the principle of the
Linux kernel, this makes sense, I think I should learn more stuff about
natural alignment. I googled something about it and understand what it
is, but still find it difficult to fully understand its benefits. I think
I'll learn more about it after. 

> > 
> > 2. In this case I have 4 channels including the timetamp one, and I
> > thought it should be aligned like the first one. But actually it's
> > aligned like the second one, when I was testing the buffer, I got
> > confused, because the in_magn_x_type returned 24/32, 24/32, 24/32
> > and 64/64. If the iio core injected some empty bytes, shouldn't it
> > notify me? Or at least change the timestamp type in scan_bytes to
> > 64/96>>0?? And when I only enabled two of three channels, the data  
> > alignment in the buffer looks like this:
> > +--+++++
> > | 3b(ytes) | 1b | 3b | 1b | 8b |
> > +--+++++
> > Notice that 4 bytes have gone due to data of two channels have already
> > aligned to 8 bytes.
> > Hoping to get some answers, I'm very curious and interested about this!
> 
> Nope it shouldn't do the 64/96 need to tell you because it uses
> the rules of natural alignment which are easy for userspace to predict.
> So in this second case there is no need to pad so it doesn't - wherea

Re: [PATCH] iio: adc: imx25-gcq: Fix leak of device_node in mx25_gcq_setup_cfgs()

[Jonathan Cameron]

On Sat, 22 Sep 2018 00:58:02 +0300
Alexey Khoroshilov  wrote:

> Leaving for_each_child_of_node loop we should release child device node,
> if it is not stored for future use.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov 
Seems obviously correct to me.  Given we are mid way through
the cycle and this doesn't strike me as super urgent, I'll
queue it up for the next merge window.

I added a note to the description to reflect this.

Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks and great to clean things like this up.

Jonathan

> ---
>  drivers/iio/adc/fsl-imx25-gcq.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/iio/adc/fsl-imx25-gcq.c b/drivers/iio/adc/fsl-imx25-gcq.c
> index ea264fa9e567..929c617db364 100644
> --- a/drivers/iio/adc/fsl-imx25-gcq.c
> +++ b/drivers/iio/adc/fsl-imx25-gcq.c
> @@ -209,12 +209,14 @@ static int mx25_gcq_setup_cfgs(struct platform_device 
> *pdev,
>   ret = of_property_read_u32(child, "reg", ®);
>   if (ret) {
>   dev_err(dev, "Failed to get reg property\n");
> + of_node_put(child);
>   return ret;
>   }
>  
>   if (reg >= MX25_NUM_CFGS) {
>   dev_err(dev,
>   "reg value is greater than the number of 
> available configuration registers\n");
> + of_node_put(child);
>   return -EINVAL;
>   }
>  
> @@ -228,6 +230,7 @@ static int mx25_gcq_setup_cfgs(struct platform_device 
> *pdev,
>   if (IS_ERR(priv->vref[refp])) {
>   dev_err(dev, "Error, trying to use external 
> voltage reference without a vref-%s regulator.",
>   mx25_gcq_refp_names[refp]);
> + of_node_put(child);
>   return PTR_ERR(priv->vref[refp]);
>   }
>   priv->channel_vref_mv[reg] =
> @@ -240,6 +243,7 @@ static int mx25_gcq_setup_cfgs(struct platform_device 
> *pdev,
>   break;
>   default:
>   dev_err(dev, "Invalid positive reference %d\n", refp);
> + of_node_put(child);
>   return -EINVAL;
>   }
>  
> @@ -254,10 +258,12 @@ static int mx25_gcq_setup_cfgs(struct platform_device 
> *pdev,
>  
>   if ((refp & MX25_ADCQ_CFG_REFP_MASK) != refp) {
>   dev_err(dev, "Invalid fsl,adc-refp property value\n");
> + of_node_put(child);
>   return -EINVAL;
>   }
>   if ((refn & MX25_ADCQ_CFG_REFN_MASK) != refn) {
>   dev_err(dev, "Invalid fsl,adc-refn property value\n");
> + of_node_put(child);
>   return -EINVAL;
>   }
>  

Re: [PATCH] iio: magnetometer: hmc5843: Fixed a comment error.

[Jonathan Cameron]

On Thu, 20 Sep 2018 21:49:46 +0800
Song Qiang  wrote:

> Replace 'hcm5843' with 'hmc5843'.
> 
> Signed-off-by: Song Qiang 
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to ignore (because there will be other things
in there that they won't later today :)

Thanks,

Jonathan

> ---
>  drivers/iio/magnetometer/hmc5843.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/magnetometer/hmc5843.h 
> b/drivers/iio/magnetometer/hmc5843.h
> index 76a5d7484d8d..a75224cf99df 100644
> --- a/drivers/iio/magnetometer/hmc5843.h
> +++ b/drivers/iio/magnetometer/hmc5843.h
> @@ -31,7 +31,7 @@ enum hmc5843_ids {
>  };
>  
>  /**
> - * struct hcm5843_data   - device specific data
> + * struct hmc5843_data   - device specific data
>   * @dev: actual device
>   * @lock:update and read regmap data
>   * @regmap:  hardware access register maps

Re: [PATCH] iio: magnetometer: hmc5843: Replace a return value.

[Jonathan Cameron]

On Thu, 20 Sep 2018 21:42:19 +0800
Song Qiang  wrote:

> This error apparently is caused by timed out event, so a -ETIMEDOUT
> should be used instead of a -EIO, and it also tells user what happened
> , so this dev_err may not be needed anymore.
> 
> Signed-off-by: Song Qiang 
> ---
> I used ./scripts/get_maintainer.pl to get maintainers about this file,
> I thought this script searches maintainers with looking up MAINTAINER,
> is that right?
> So I searched MAINTAINER and also found nothing related to hmc5843.
> In the declearation area I can see Shubhrajyoti Datta 
>  wroted this driver and several other people
> including Peter Meerwald have contributed. Is this driver now a orphan?
> Or if it is, I think we may also need to add it to the MAINTAINER file.
> I'm also familiar with this device, I think I can add interrupt support
> later.

Those drivers not covered by more explicit MAINTAINER entries are
picked up by the main IIO one.  Of course if you are working in a
significant way with the driver and want to adopt it, then post
a patch adding a MAINTAINERS entry and see if any of the previous
significant contributors mind (or potentially want to co-maintain it).

> 
>  drivers/iio/magnetometer/hmc5843_core.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/magnetometer/hmc5843_core.c 
> b/drivers/iio/magnetometer/hmc5843_core.c
> index ada142fb7aa3..4fb393c3854c 100644
> --- a/drivers/iio/magnetometer/hmc5843_core.c
> +++ b/drivers/iio/magnetometer/hmc5843_core.c
> @@ -170,8 +170,7 @@ static int hmc5843_wait_measurement(struct hmc5843_data 
> *data)
>   }
>  
>   if (tries < 0) {
> - dev_err(data->dev, "data not ready\n");
> - return -EIO;
> + return -ETIMEDOUT;

I'd say no on this one as I suspect such a timeout only indicates a
communication problem, not some delay in the hardware managing to
return an answer..

It's certainly not a clear enough reason to my mind to argue for changing
the error code (which it is just possible some less than ideal userspace
code is relying on).

Jonathan

>   }
>  
>   return 0;

Re: [PATCH] iio: magnetometer: Add support for PNI RM3100 9-axis magnetometer

[Jonathan Cameron]

A few follow ups to the discussion here from me..

Note it's helpful to crop and email and no one really minds if you
just act on their review without acknowledging it (so cut the
bits you fully agree with out too - saves on scrolling / reading time ;)

A catch all, "Agree with everything else and will fix for v2" covers
everything you don't want to discuss further.
(not that I'm great at doing this either :(
...
> > > diff --git a/drivers/iio/magnetometer/rm3100-core.c 
> > > b/drivers/iio/magnetometer/rm3100-core.c
> > > new file mode 100644
> > > index ..55d515e0fe67
> > > --- /dev/null
> > > +++ b/drivers/iio/magnetometer/rm3100-core.c
> > > @@ -0,0 +1,399 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * PNI RM3100 9-axis geomagnetic sensor driver core.
> > > + *
> > > + * Copyright (C) 2018 Song Qiang 
> > > + *
> > > + * User Manual available at
> > > + * 
> > > + *
> > > + * TODO: Scale channel, event generaton, pm.  
> > 
> > at least read support for _SCALE is mandatory, IMHO
> >   
> 
> Okay, I'll add it in next version.
> 
Just for the record, it's only mandatory in cases where
it is known (you'd be amazed how often we only know the value is monotonic)

Now as you put it in the todo list, it's presumably known here
hence Peter's comment :)

(just avoiding setting precedence)



...
> > > +static const struct regmap_range rm3100_readable_ranges[] = {
> > > + regmap_reg_range(RM_W_REG_START, RM_W_REG_END),
> > > +};
> > > +
> > > +const struct regmap_access_table rm3100_readable_table = {  
> > 
> > static
> >   
> 
> I was planning to let rm3100-i2c.c and rm3100-spi.c to share these 6
> structures, because the only different configuration of regmap between
> these two files lies in 'struct regmap_config'. To achieve this, I have
> to expose these 3 structures to be referenced in rm3100-i2c.c and
> rm3100-spi.c
> Since *_common_probe() and *_common_remove() are exposed, I thought it
> was fine to expose these structures to reduce redundant code, is this
> prohibited?
Nope, but are you doing it in this patch? + you need to export the
symbols if you are going to do that otherwise modular builds
will fail to probe (and possibly build - I can't recall and am too
lazy to check this morning - not enough coffee yet!)

..
> > > + *val = le32_to_cpu((buffer[0] << 16) + (buffer[1] << 8) + buffer[2]);  
> > 
> > no need for le32_to_cpu() 
> >   
> 
> I think I didn't fully understand this, I'll look into it.
> 

To point you in the right direction here.   When you explicitly pull out
individual bytes like you are doing here, you are getting them in a particular
endian order.   Shifts and adding (though normally convention is | when doing
this) are done in machine endianness, hence the *val is already in the
endian type of your cpu.

> > > + *val = sign_extend32(*val, 23);
> > > +
> > > + return IIO_VAL_INT;
> > > +}
> > > +
> > > +#define RM_CHANNEL(axis, idx)\  
> > 
> > use RM3100_ prefix please
> >   
> 
> In the last driver I wrote, name of registers are so long that I have to
> suppress them as possible as I can, it seems like this one doesn't need
> to. :)
> 
> > > + {   \
> > > + .type = IIO_MAGN,   \
> > > + .modified = 1,  \
> > > + .channel2 = IIO_MOD_##axis, \
> > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
> > > + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
> > > + .scan_index = idx,  \
> > > + .scan_type = {  \
> > > + .sign = 's',\
> > > + .realbits = 24, \
> > > + .storagebits = 32,  \
> > > + .shift = 8, \
> > > + .endianness = IIO_LE,   \
> > > + },  \
> > > + }
> > > +
> > > +static const struct iio_chan_spec rm3100_channels[] = {
> > > + RM_CHANNEL(X, 0),
> > > + RM_CHANNEL(Y, 1),
> > > + RM_CHANNEL(Z, 2),
> > > + IIO_CHAN_SOFT_TIMESTAMP(3),
> > > +};
> > > +
> > > +static const unsigned long rm3100_scan_masks[] = {GENMASK(2, 0), 0};
> > > +
> > > +#define RM_SAMP_NUM  14  
> > 
> > prefix
> >   
> > > +
> > > +/* Frequency : rm3100_samp_rates[][0].rm3100_samp_rates[][1]Hz.
> > > + * Time between reading: rm3100_sam_rates[][2]ms (The first on is 
> > > actially 1.7).  
> > 
> > one
> > actually
> > 1.7 what unit?
> >   
> 
> It's in milliseconds. These time values are used for lookup so I do not
> need to compute time between conversion from measu

[PATCH v2] phy: phy-twl4030-usb: fix denied runtime access

[Andreas Kemnade]

When runtime is not enabled, pm_runtime_get_sync() returns -EACCESS,
the counter will be incremented but the resume callback not called,
so enumeration and charging will not start properly.
To avoid that happen, disable irq on suspend and recheck on resume.

Practically this happens when the device is woken up from suspend by
plugging in usb.

Signed-off-by: Andreas Kemnade 
---
Changes in v2:
* use pm suspend/resume callback instead of delayed_work
  as suggested by Dmitry

 drivers/phy/ti/phy-twl4030-usb.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/phy/ti/phy-twl4030-usb.c b/drivers/phy/ti/phy-twl4030-usb.c
index a44680d64f9b..c267afb68f07 100644
--- a/drivers/phy/ti/phy-twl4030-usb.c
+++ b/drivers/phy/ti/phy-twl4030-usb.c
@@ -144,6 +144,7 @@
 #define PMBR1  0x0D
 #define GPIO_USB_4PIN_ULPI_2430C   (3 << 0)
 
+static irqreturn_t twl4030_usb_irq(int irq, void *_twl);
 /*
  * If VBUS is valid or ID is ground, then we know a
  * cable is present and we need to be runtime-enabled
@@ -395,6 +396,33 @@ static void __twl4030_phy_power(struct twl4030_usb *twl, 
int on)
WARN_ON(twl4030_usb_write_verify(twl, PHY_PWR_CTRL, pwr) < 0);
 }
 
+static int __maybe_unused twl4030_usb_suspend(struct device *dev)
+{
+   struct twl4030_usb *twl = dev_get_drvdata(dev);
+
+   /*
+* we need enabled runtime on resume,
+* so turn irq off here, so we do not get it early
+* note: wakeup on usb plug works independently of this
+*/
+   dev_dbg(twl->dev, "%s\n", __func__);
+   disable_irq(twl->irq);
+
+   return 0;
+}
+
+static int __maybe_unused twl4030_usb_resume(struct device *dev)
+{
+   struct twl4030_usb *twl = dev_get_drvdata(dev);
+
+   dev_dbg(twl->dev, "%s\n", __func__);
+   enable_irq(twl->irq);
+   /* check whether cable status changed */
+   twl4030_usb_irq(0, twl);
+
+   return 0;
+}
+
 static int __maybe_unused twl4030_usb_runtime_suspend(struct device *dev)
 {
struct twl4030_usb *twl = dev_get_drvdata(dev);
@@ -655,6 +683,7 @@ static const struct phy_ops ops = {
 static const struct dev_pm_ops twl4030_usb_pm_ops = {
SET_RUNTIME_PM_OPS(twl4030_usb_runtime_suspend,
   twl4030_usb_runtime_resume, NULL)
+   SET_SYSTEM_SLEEP_PM_OPS(twl4030_usb_suspend, twl4030_usb_resume)
 };
 
 static int twl4030_usb_probe(struct platform_device *pdev)
-- 
2.11.0

Linus, my friend

[comrade-c]

Despite I didn't have a pleasure to know you personally I have a huge sympathy 
to the situation that you are in now. It's hard.
You have to re-evaluate what makes you yourself and whether you want to give up 
a part of you if some particular part of you doesn't is outside of the other 
people' reality tunnel.

My friend introduced me to Linux before it became untouchable. I remember all 
the struggle that Linux went through fighting for the its place under the sun 
with giants like Microsoft and Oracle. The involvement of SCO and other nice 
stuff. I believe it takes some guts and character to make it through. Not every 
single person can do it. Code of Conduct will not help it either.
Linux is in the center of billion dollar industry, basically in a non-profit 
project in a shark pool. Look at what happening in the JavaScript world where 
Facebook and Google are fighting for the people minds and for the market 
influence. Don't let Linux become a battlefield for the tech giants.  It's your 
baby and it needs your protection.

When I was a kid we used to gang up and explore the neighborhoods, build 
hideaways and make secret plans. That was a boys club. And there was boys rules 
in that club which were perfectly fine. We tend to loose that kind of feeling 
while growing up because we have to become "serious", respectable and 
responsible. But look, it's great to have something on a  side, another boys 
club, where it's possible to leave all those social demands alone. And we need 
people who will be the core of such clubs - people who will remind us about 
something deep inside us on a constant basis and I guess you are the man who is 
doing it naturally. It's important not only for you but also for the other 
kernel developers 
https://www.upworthy.com/loneliness-is-killing-millions-of-american-men-here-s-why

Now few words about CoC. I would prefer to work with people who sees project 
success as their own personal goal. Maybe if people can't cope with the words 
the project success is not as important for them as their ego. It's okay to not 
let them in. Having a team of people who can put their personal sacrosanctity 
aside and cooperate on the project is rare fortune.

I guess people who are happy because of your decision to take a step back 
didn't ever worked in environment like you do. Don't loose yourself because of 
the people incapable write good quality code.

Re: [PATCH v6 0/3] Harden spectrev2 userspace-userspace protection

[Thomas Gleixner]

On Sat, 22 Sep 2018, Jiri Kosina wrote:
> On Wed, 19 Sep 2018, Peter Zijlstra wrote:
> > As far as I can tell, this still has:
> > 
> > avc_has_perm_noaudit()
> >   security_compute_av()
> > read_lock(&state->ss->policy_rwlock);
> >   avc_insert()
> > spin_lock_irqsave();
> >   avc_denied()
> > avc_update_node()
> >   spin_lock_irqsave();
> > 
> > under the scheduler's raw_spinlock_t, which are invalid lock nestings.
> 
> Agreed. Therefore, if the current form (v6) of the patches is merged, the 
> check before security_ptrace_access_check() should stay.
> 
> Once all the LSM callbacks are potentially audited, it could then go in 
> second phase.
> 
> Is there anything else blocking v6 being merged? (and then Tim's set on 
> top I guess, once the details are sorted out there).

I was waiting for this to resolve. Now, looking at the outcome of this, I
think, that calling into security hooks needs very special care from that
context.

So we better split that up right away instead of adding this magic
PTRACE_MODE_NOACCESS_CHK bit. This split up will be needed for adding the
special LSM speculation control hook anyway because adding yet more magic
bits and conditionals makes this code completely undigestable. It's
convoluted enough already.

Something along the compiled but completely untested patch below should do
the trick. If that is what we want this needs to be split up of course.

Thanks,

tglx

8<--
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -180,6 +181,19 @@ static void sync_current_stack_to_mm(str
}
 }
 
+static bool ibpb_needed(struct task_struct *tsk, u64 last_ctx_id)
+{
+   /*
+* Check if the current (previous) task has access to the memory
+* of the @tsk (next) task. If access is denied, make sure to
+* issue a IBPB to stop user->user Spectre-v2 attacks.
+*
+* Note: __ptrace_may_access() returns 0 or -ERRNO.
+*/
+   return (tsk && tsk->mm && tsk->mm->context.ctx_id != last_ctx_id &&
+   ptrace_may_access_sched(tsk, PTRACE_MODE_SPEC_IBPB));
+}
+
 void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
struct task_struct *tsk)
 {
@@ -262,18 +276,13 @@ void switch_mm_irqs_off(struct mm_struct
 * one process from doing Spectre-v2 attacks on another.
 *
 * As an optimization, flush indirect branches only when
-* switching into processes that disable dumping. This
-* protects high value processes like gpg, without having
-* too high performance overhead. IBPB is *expensive*!
-*
-* This will not flush branches when switching into kernel
-* threads. It will also not flush if we switch to idle
-* thread and back to the same process. It will flush if we
-* switch to a different non-dumpable process.
+* switching into a processes that can't be ptrace by the
+* current one (as in such case, attacker has much more
+* convenient way how to tamper with the next process than
+* branch buffer poisoning).
 */
-   if (tsk && tsk->mm &&
-   tsk->mm->context.ctx_id != last_ctx_id &&
-   get_dumpable(tsk->mm) != SUID_DUMP_USER)
+   if (static_cpu_has(X86_FEATURE_USE_IBPB) &&
+   ibpb_needed(tsk, last_ctx_id))
indirect_branch_prediction_barrier();
 
if (IS_ENABLED(CONFIG_VMAP_STACK)) {
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -62,14 +62,16 @@ extern void exit_ptrace(struct task_stru
 #define PTRACE_MODE_READ   0x01
 #define PTRACE_MODE_ATTACH 0x02
 #define PTRACE_MODE_NOAUDIT0x04
-#define PTRACE_MODE_FSCREDS 0x08
-#define PTRACE_MODE_REALCREDS 0x10
+#define PTRACE_MODE_FSCREDS0x08
+#define PTRACE_MODE_REALCREDS  0x10
+#define PTRACE_MODE_IBPB   0x20
 
 /* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
 #define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
 #define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
 #define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
 #define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH | 
PTRACE_MODE_REALCREDS)
+#define PTRACE_MODE_SPEC_IBPB (PTRACE_MODE_ATTACH_REALCREDS | PTRACE_MODE_IBPB)
 
 /**
  * ptrace_may_access - check whether the caller is permitted to access
@@ -86,6 +88,7 @@ extern void exit_ptrace(struct task_stru
  * process_vm_writev or ptrace (and should use the real credentials).
  */
 extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
+extern bool ptrace_may_access_s

[tip:x86/cpu] x86/CPU: Use correct macros for Cyrix calls

[tip-bot for Matthew Whitehead]

Commit-ID:  03b099bdcdf7125d4a63dc9ddeefdd454e05123d
Gitweb: https://git.kernel.org/tip/03b099bdcdf7125d4a63dc9ddeefdd454e05123d
Author: Matthew Whitehead 
AuthorDate: Fri, 21 Sep 2018 17:20:40 -0400
Committer:  Borislav Petkov 
CommitDate: Sat, 22 Sep 2018 11:46:56 +0200

x86/CPU: Use correct macros for Cyrix calls

There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:

  setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);

This is because it expands the macro into a non-functioning calling
sequence. The calling order must be:

  outb(CX86_CCR2, 0x22);
  inb(0x23);

>From the comments:

 * When using the old macros a line like
 *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
 * gets expanded to:
 *  do {
 *outb((CX86_CCR2), 0x22);
 *outb((({
 *outb((CX86_CCR2), 0x22);
 *inb(0x23);
 *}) | 0x88), 0x23);
 *  } while (0);

The new macros fix this problem, so use them instead.

Signed-off-by: Matthew Whitehead 
Signed-off-by: Borislav Petkov 
Reviewed-by: Andy Lutomirski 
Cc: Greg Kroah-Hartman 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jia Zhang 
Cc: Peter Zijlstra 
Cc: Philippe Ombredanne 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20180921212041.13096-2-tedheads...@gmail.com
---
 arch/x86/kernel/cpu/cyrix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index 8949b7ae6d92..d12226f60168 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -437,7 +437,7 @@ static void cyrix_identify(struct cpuinfo_x86 *c)
/* enable MAPEN  */
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);
/* enable cpuid  */
-   setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);
+   setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x80);
/* disable MAPEN */
setCx86(CX86_CCR3, ccr3);
local_irq_restore(flags);

[tip:x86/cpu] x86/CPU: Change query logic so CPUID is enabled before testing

[tip-bot for Matthew Whitehead]

Commit-ID:  2893cc8ff892fa74972d8dc0e1d0dc65116daaa3
Gitweb: https://git.kernel.org/tip/2893cc8ff892fa74972d8dc0e1d0dc65116daaa3
Author: Matthew Whitehead 
AuthorDate: Fri, 21 Sep 2018 17:20:41 -0400
Committer:  Borislav Petkov 
CommitDate: Sat, 22 Sep 2018 11:47:39 +0200

x86/CPU: Change query logic so CPUID is enabled before testing

Presently we check first if CPUID is enabled. If it is not already
enabled, then we next call identify_cpu_without_cpuid() and clear
X86_FEATURE_CPUID.

Unfortunately, identify_cpu_without_cpuid() is the function where CPUID
becomes _enabled_ on Cyrix 6x86/6x86L CPUs.

Reverse the calling sequence so that CPUID is first enabled, and then
check a second time to see if the feature has now been activated.

[ bp: Massage commit message and remove trailing whitespace. ]

Suggested-by: Andy Lutomirski 
Signed-off-by: Matthew Whitehead 
Signed-off-by: Borislav Petkov 
Reviewed-by: Andy Lutomirski 
Cc: David Woodhouse 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Konrad Rzeszutek Wilk 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20180921212041.13096-3-tedheads...@gmail.com
---
 arch/x86/kernel/cpu/common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 44c4ef3d989b..658c85d16a9b 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1076,6 +1076,9 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
*c)
memset(&c->x86_capability, 0, sizeof c->x86_capability);
c->extended_cpuid_level = 0;
 
+   if (!have_cpuid_p())
+   identify_cpu_without_cpuid(c);
+
/* cyrix could have cpuid enabled via c_identify()*/
if (have_cpuid_p()) {
cpu_detect(c);
@@ -1093,7 +1096,6 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
*c)
if (this_cpu->c_bsp_init)
this_cpu->c_bsp_init(c);
} else {
-   identify_cpu_without_cpuid(c);
setup_clear_cpu_cap(X86_FEATURE_CPUID);
}
 

Re: [PATCH] staging: vc04_services: Remove unused vchiq_genversion script

[Stefan Wahren]

> Tuomas Tynkkynen  hat am 21. September 2018 um 21:56 
> geschrieben:
> 
> 
> As far as I can tell, this has never been used.
> 
> Signed-off-by: Tuomas Tynkkynen 

Acked-by: Stefan Wahren 

Re: [PATCH] iio: magnetometer: hmc5843: Clean up redundant code.

[Song Qiang]

On Fri, Sep 21, 2018 at 11:56:16PM +0530, Himanshu Jha wrote:
> Hi Song,
> 
> On Fri, Sep 21, 2018 at 04:10:16PM +0800, kbuild test robot wrote:
> > Hi Song,
> > 
> > Thank you for the patch! Yet something to improve:
> > 
> > [auto build test ERROR on iio/togreg]
> > [also build test ERROR on v4.19-rc4 next-20180920]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help improve the system]
> > 
> > url:
> > https://github.com/0day-ci/linux/commits/Song-Qiang/iio-magnetometer-hmc5843-Clean-up-redundant-code/20180921-091239
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
> > config: x86_64-randconfig-u0-09211331 (attached as .config)
> > compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=x86_64 
> > 
> > All errors (new ones prefixed by >>):
> > 
> > >> ERROR: "hmc5843_volatile_table" 
> > >> [drivers/iio/magnetometer/hmc5843_i2c.ko] undefined!
> > >> ERROR: "hmc5843_readable_table" 
> > >> [drivers/iio/magnetometer/hmc5843_i2c.ko] undefined!
> > >> ERROR: "hmc5843_writable_table" 
> > >> [drivers/iio/magnetometer/hmc5843_i2c.ko] undefined!
> 
> You would need to export these above symbols using EXPORT_SYMBOL()
> to be used by i2c/spi modules.
> 
> But on the other hand, exporting too many symbols is a bad idea since
> it is only used for this driver and not at any other place in IIO.
> So, in my opinion drop this patch and leave the code as-is.
> 
> https://lkml.org/lkml/2018/7/16/566 --> worth reading
> 
> 
> Thanks
> -- 
> Himanshu Jha
> Undergraduate Student
> Department of Electronics & Communication
> Guru Tegh Bahadur Institute of Technology

Hi Himanshu,

You're right, that's exactly what I was missing!
I saw the link you mentioned above and I also think that's a very good
idea to limit the scope of symbols. But I don't know when this work can
be applied to the kernel, as it seems like a not little change for the
build infrastructure.
I think this maybe a common problem for some drivers.
Divers for bmc150 in drivers/iio/accel/bmc-150-accel-core.c did the same
exporting stuff as I was prefered. So I think even if either exporting or
duplicating is not good enough, one must be choosed for now.

I think this is a topic that I have some ideas but not experienced
enough to say what should we do is better. I would like to hear Jonathan's
ideas about this. If this patched shouldn't be applied, then maybe bmc150
should be patched.

yours,
Song Qiang

Re: [PATCH] iio: magnetometer: Add support for PNI RM3100 9-axis magnetometer

[Jonathan Cameron]

On Sat, 22 Sep 2018 10:42:44 +0100
Jonathan Cameron  wrote:

> A few follow ups to the discussion here from me..
> 
> Note it's helpful to crop and email and no one really minds if you
> just act on their review without acknowledging it (so cut the
> bits you fully agree with out too - saves on scrolling / reading time ;)
> 
> A catch all, "Agree with everything else and will fix for v2" covers
> everything you don't want to discuss further.
> (not that I'm great at doing this either :(
> ...
> > > > diff --git a/drivers/iio/magnetometer/rm3100-core.c 
> > > > b/drivers/iio/magnetometer/rm3100-core.c
> > > > new file mode 100644
> > > > index ..55d515e0fe67
> > > > --- /dev/null
> > > > +++ b/drivers/iio/magnetometer/rm3100-core.c
> > > > @@ -0,0 +1,399 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * PNI RM3100 9-axis geomagnetic sensor driver core.
> > > > + *
> > > > + * Copyright (C) 2018 Song Qiang 
> > > > + *
> > > > + * User Manual available at
> > > > + * 
> > > > + *
> > > > + * TODO: Scale channel, event generaton, pm.
> > > 
> > > at least read support for _SCALE is mandatory, IMHO
> > > 
> > 
> > Okay, I'll add it in next version.
> >   
> Just for the record, it's only mandatory in cases where
> it is known (you'd be amazed how often we only know the value is monotonic)
> 
> Now as you put it in the todo list, it's presumably known here
> hence Peter's comment :)
> 
> (just avoiding setting precedence)
> 
> 
> 
> ...
> > > > +static const struct regmap_range rm3100_readable_ranges[] = {
> > > > +   regmap_reg_range(RM_W_REG_START, RM_W_REG_END),
> > > > +};
> > > > +
> > > > +const struct regmap_access_table rm3100_readable_table = {
> > > 
> > > static
> > > 
> > 
> > I was planning to let rm3100-i2c.c and rm3100-spi.c to share these 6
> > structures, because the only different configuration of regmap between
> > these two files lies in 'struct regmap_config'. To achieve this, I have
> > to expose these 3 structures to be referenced in rm3100-i2c.c and
> > rm3100-spi.c
> > Since *_common_probe() and *_common_remove() are exposed, I thought it
> > was fine to expose these structures to reduce redundant code, is this
> > prohibited?  
> Nope, but are you doing it in this patch? + you need to export the
> symbols if you are going to do that otherwise modular builds
> will fail to probe (and possibly build - I can't recall and am too
> lazy to check this morning - not enough coffee yet!)
> 
> ..
> > > > +   *val = le32_to_cpu((buffer[0] << 16) + (buffer[1] << 8) + 
> > > > buffer[2]);
> > > 
> > > no need for le32_to_cpu() 
> > > 
> > 
> > I think I didn't fully understand this, I'll look into it.
> >   
> 
> To point you in the right direction here.   When you explicitly pull out
> individual bytes like you are doing here, you are getting them in a particular
> endian order.   Shifts and adding (though normally convention is | when doing
> this) are done in machine endianness, hence the *val is already in the
> endian type of your cpu.
> 
> > > > +   *val = sign_extend32(*val, 23);
> > > > +
> > > > +   return IIO_VAL_INT;
> > > > +}
> > > > +
> > > > +#define RM_CHANNEL(axis, idx)  \
> > > 
> > > use RM3100_ prefix please
> > > 
> > 
> > In the last driver I wrote, name of registers are so long that I have to
> > suppress them as possible as I can, it seems like this one doesn't need
> > to. :)
> >   
> > > > +   {   
> > > > \
> > > > +   .type = IIO_MAGN,   
> > > > \
> > > > +   .modified = 1,  
> > > > \
> > > > +   .channel2 = IIO_MOD_##axis, 
> > > > \
> > > > +   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   
> > > > \
> > > > +   .info_mask_shared_by_type = 
> > > > BIT(IIO_CHAN_INFO_SAMP_FREQ),\
> > > > +   .scan_index = idx,  
> > > > \
> > > > +   .scan_type = {  
> > > > \
> > > > +   .sign = 's',
> > > > \
> > > > +   .realbits = 24, 
> > > > \
> > > > +   .storagebits = 32,  
> > > > \
> > > > +   .shift = 8, 
> > > > \
> > > > +   .endianness = IIO_LE,   
> > > > \
> > > > +   },  
> > > > \
> > > > +   }
> > > > +
> > > > +static const struct iio_chan_spec rm3100_channels[] = {
> > > > +   RM_CHANNEL(X, 0),
> > > > +   RM_CHANNEL(Y, 1),
> > > > +

Re: [PATCH] iio: magnetometer: Add support for PNI RM3100 9-axis magnetometer

[Jonathan Cameron]

On Thu, 20 Sep 2018 21:13:40 +0800
Song Qiang  wrote:

> PNI RM3100 magnetometer is a high resolution, large signal immunity
> magnetometer, composed of 3 single sensors and a processing chip.
> PNI is currently not in the vendors list, so this is also adding it.
> 
> Following functions are available:
>  - Single-shot measurement from
>/sys/bus/iio/devices/iio:deviceX/in_magn_{axis}_raw
>  - Triggerd buffer measurement.
>  - Both i2c and spi interface are supported.
>  - Both interrupt and polling measurement is supported, depands on if
>the 'interrupts' in DT is declared.
> 
> Signed-off-by: Song Qiang 
Hi Song,

Great to have a driver for a pni device.  I hadn't come across them
before!

I'll try and avoid repeating Peter and Phil's comments on the basis
you probably have those covered by now.  I would have left this
for V2 before reviewing but not sure if I'll get to IIO stuff
during the coming week so better to get you some comments from me today.

Thanks,

Jonathan

> ---
>  .../bindings/iio/magnetometer/pni,rm3100.txt  |  57 +++
>  .../devicetree/bindings/vendor-prefixes.txt   |   1 +
>  MAINTAINERS   |  10 +
>  drivers/iio/magnetometer/Kconfig  |  29 ++
>  drivers/iio/magnetometer/Makefile |   4 +
>  drivers/iio/magnetometer/rm3100-core.c| 399 ++
>  drivers/iio/magnetometer/rm3100-i2c.c |  66 +++
>  drivers/iio/magnetometer/rm3100-spi.c |  72 
>  drivers/iio/magnetometer/rm3100.h |  90 
>  9 files changed, 728 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
>  create mode 100644 drivers/iio/magnetometer/rm3100-core.c
>  create mode 100644 drivers/iio/magnetometer/rm3100-i2c.c
>  create mode 100644 drivers/iio/magnetometer/rm3100-spi.c
>  create mode 100644 drivers/iio/magnetometer/rm3100.h
> 
> diff --git 
> a/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt 
> b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
> new file mode 100644
> index ..d0d2063e943f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
> @@ -0,0 +1,57 @@
> +* PNI RM3100 9-axis magnetometer sensor
> +
> +I2C Bus:
> +
> +Required properties:
> +
> +- compatible : should be "pni,rm3100-i2c"
> +- reg : the I2C address of the magnetometer
> +
> +Optional properties:
> +
> +- interrupts: data ready (DRDY) from the chip.
> +  The interrupts can be triggered on rising edges.
> +
> + Refer to interrupt-controller/interrupts.txt for generic
> + interrupt client node bindings.
> +
> +- pinctrl-*: pinctrl setup for DRDY line.

I'm not a DT expert by any means, but I think the convention is
to not mention pinctrl in a given driver because otherwise
in theory we may need to mention it everywhere...

> +
> +Example:
> +
> +rm3100: rm3100@20 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&rm3100_pins>;
> +
> + compatible = "pni,rm3100-i2c";
> + reg = <0x20>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <4 IRQ_TYPE_EDGE_RISING>;
> +};
> +
> +SPI Bus:
> +
> +Required properties:
> +
> +- compatible : should be "pni,rm3100-spi"
> +- reg : address of sensor, usually 0 or 1.
> +
> +Optional properties:
> +
> +- interrupts: data ready (DRDY) from the chip.
> +  The interrupts can be triggered on rising edges.
> +
> + Refer to interrupt-controller/interrupts.txt for generic
> + interrupt client node bindings.
> +
> +- pinctrl-*: pinctrl setup for DRDY line, depands on archtechture.
> +
> +Example:
> +
> +rm3100: rm3100@0{
> + compatible = "pni,rm3100-spi";
> + reg = <0>;
> +
> + interrupt-parent = <&gpio0>;
> + interrupts = <4 IRQ_TYPE_EDGE_RISING>;
> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 41f0b97eb933..5bf3395fe9ae 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -288,6 +288,7 @@ pine64Pine64
>  pixcir  PIXCIR MICROELECTRONICS Co., Ltd
>  plathome Plat'Home Co., Ltd.
>  plda PLDA
> +pni PNI

Please break the whole binding out as a separate patch.  Ideally do this
vendor-prefixes.txt as a separate patch again.  This cuts down
on the amount of searching that the DT people have to do to find
the bits that they want to look at.

>  portwell Portwell Inc.
>  poslab   Poslab Technology Co., Ltd.
>  powervr  PowerVR (deprecated, use img)
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 967ce8cdd1cc..30ee8cf98312 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11393,6 +11393,16 @@ M:   "Rafael J. Wysocki" 
>  S:   Maintained
>  F:   drivers/pnp/
>  
> +PNI RM3100 IIO DRIVER
> +M:   Song Qiang 
> +L:   linux-...@vger.kernel.org
> +S:   Maintained
> +F:   drivers/iio/magnetometer/rm3100-core.c

rm3110* perhaps?

> +F:   dr

Re: [PATCH] iio: magnetometer: hmc5843: Clean up redundant code.

[Jonathan Cameron]

On Sat, 22 Sep 2018 18:04:19 +0800
Song Qiang  wrote:

> On Fri, Sep 21, 2018 at 11:56:16PM +0530, Himanshu Jha wrote:
> > Hi Song,
> > 
> > On Fri, Sep 21, 2018 at 04:10:16PM +0800, kbuild test robot wrote:  
> > > Hi Song,
> > > 
> > > Thank you for the patch! Yet something to improve:
> > > 
> > > [auto build test ERROR on iio/togreg]
> > > [also build test ERROR on v4.19-rc4 next-20180920]
> > > [if your patch is applied to the wrong git tree, please drop us a note to 
> > > help improve the system]
> > > 
> > > url:
> > > https://github.com/0day-ci/linux/commits/Song-Qiang/iio-magnetometer-hmc5843-Clean-up-redundant-code/20180921-091239
> > > base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git 
> > > togreg
> > > config: x86_64-randconfig-u0-09211331 (attached as .config)
> > > compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
> > > reproduce:
> > > # save the attached .config to linux build tree
> > > make ARCH=x86_64 
> > > 
> > > All errors (new ones prefixed by >>):
> > >   
> > > >> ERROR: "hmc5843_volatile_table" 
> > > >> [drivers/iio/magnetometer/hmc5843_i2c.ko] undefined!
> > > >> ERROR: "hmc5843_readable_table" 
> > > >> [drivers/iio/magnetometer/hmc5843_i2c.ko] undefined!
> > > >> ERROR: "hmc5843_writable_table" 
> > > >> [drivers/iio/magnetometer/hmc5843_i2c.ko] undefined!  
> > 
> > You would need to export these above symbols using EXPORT_SYMBOL()
> > to be used by i2c/spi modules.
> > 
> > But on the other hand, exporting too many symbols is a bad idea since
> > it is only used for this driver and not at any other place in IIO.
> > So, in my opinion drop this patch and leave the code as-is.
> > 
> > https://lkml.org/lkml/2018/7/16/566 --> worth reading
> > 
> > 
> > Thanks
> > -- 
> > Himanshu Jha
> > Undergraduate Student
> > Department of Electronics & Communication
> > Guru Tegh Bahadur Institute of Technology  
> 
> Hi Himanshu,
> 
> You're right, that's exactly what I was missing!
> I saw the link you mentioned above and I also think that's a very good
> idea to limit the scope of symbols. But I don't know when this work can
> be applied to the kernel, as it seems like a not little change for the
> build infrastructure.
> I think this maybe a common problem for some drivers.
> Divers for bmc150 in drivers/iio/accel/bmc-150-accel-core.c did the same
> exporting stuff as I was prefered. So I think even if either exporting or
> duplicating is not good enough, one must be choosed for now.
> 
> I think this is a topic that I have some ideas but not experienced
> enough to say what should we do is better. I would like to hear Jonathan's
> ideas about this. If this patched shouldn't be applied, then maybe bmc150
> should be patched.

As you say it's not a particularly clear advantage either way and will
depend on the size of the repetition.

So I'm afraid it's in the category of insisting on one option or the
other is just overly fussy.  Al, for existing cases it's also not
worth the noise that changing to one or other option creates.

Whilst the noise effect on things like backporting fixes is minor for patches
like this, it isn't zero so there has to be a clear advantage in whatever
is changed.  Hence I won't be taking this one, or any patches going the
other way for existing drivers.

Thanks,

Jonathan

> 
> yours,
> Song Qiang
> 

Re: [PATCH v6 0/3] Harden spectrev2 userspace-userspace protection

[Peter Zijlstra]

On Sat, Sep 22, 2018 at 11:53:14AM +0200, Thomas Gleixner wrote:
> @@ -86,6 +88,7 @@ extern void exit_ptrace(struct task_stru
>   * process_vm_writev or ptrace (and should use the real credentials).
>   */
>  extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
> +extern bool ptrace_may_access_sched(struct task_struct *task, unsigned int 
> mode);

I like that..

>  static inline int ptrace_reparented(struct task_struct *child)
>  {
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c

> +bool ptrace_may_access_sched(struct task_struct *task, unsigned int mode)
> +{
> + struct mm_struct *mm;
> + int res;
> +
> + res = __ptrace_may_access_basic(task, mode);
> + if (res <= 0)
> + return !res;
> +
> + rcu_read_lock();
> + res = __ptrace_may_access_cred(__task_cred(task), mode);
>   rcu_read_unlock();
> + if (res)
> + return false;
> +
> + mm = task->mm;
> + if (mm && get_dumpable(mm) != SUID_DUMP_USER)
> + return false;
> + return true;
> +}
> +
> +/* Returns 0 on success, -errno on denial. */
> +static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
> +{
> + const struct cred *tcred;
> + struct mm_struct *mm;
> + int res;
> +
> + res = __ptrace_may_access_basic(task, mode);
> + if (res <= 0)
> + return res;
> +
> + rcu_read_lock();
> + tcred = __task_cred(task);
> + res = __ptrace_may_access_cred(tcred, mode);
> + if (res > 0)
> + res = ptrace_has_cap(tcred->user_ns, mode) ? 0 : -EPERM;
>   rcu_read_unlock();
> + if (res < 0)
> + return res;
> +
>   mm = task->mm;
> + if (mm && (get_dumpable(mm) != SUID_DUMP_USER &&
> +!ptrace_has_cap(mm->user_ns, mode)))
> + return -EPERM;
>  
>   return security_ptrace_access_check(task, mode);
>  }

This has some unfortunate duplication.

Lets go with it for now, but I'll see if I can do something about that
later.

Re: [PATCH v6 0/3] Harden spectrev2 userspace-userspace protection

[Thomas Gleixner]

On Sat, 22 Sep 2018, Peter Zijlstra wrote:
> On Sat, Sep 22, 2018 at 11:53:14AM +0200, Thomas Gleixner wrote:
> > +bool ptrace_may_access_sched(struct task_struct *task, unsigned int mode)
> > +{
> > +   struct mm_struct *mm;
> > +   int res;
> > +
> > +   res = __ptrace_may_access_basic(task, mode);
> > +   if (res <= 0)
> > +   return !res;
> > +
> > +   rcu_read_lock();
> > +   res = __ptrace_may_access_cred(__task_cred(task), mode);
> > rcu_read_unlock();
> > +   if (res)
> > +   return false;
> > +
> > +   mm = task->mm;
> > +   if (mm && get_dumpable(mm) != SUID_DUMP_USER)
> > +   return false;
> > +   return true;
> > +}
> > +
> > +/* Returns 0 on success, -errno on denial. */
> > +static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
> > +{
> > +   const struct cred *tcred;
> > +   struct mm_struct *mm;
> > +   int res;
> > +
> > +   res = __ptrace_may_access_basic(task, mode);
> > +   if (res <= 0)
> > +   return res;
> > +
> > +   rcu_read_lock();
> > +   tcred = __task_cred(task);
> > +   res = __ptrace_may_access_cred(tcred, mode);
> > +   if (res > 0)
> > +   res = ptrace_has_cap(tcred->user_ns, mode) ? 0 : -EPERM;
> > rcu_read_unlock();
> > +   if (res < 0)
> > +   return res;
> > +
> > mm = task->mm;
> > +   if (mm && (get_dumpable(mm) != SUID_DUMP_USER &&
> > +  !ptrace_has_cap(mm->user_ns, mode)))
> > +   return -EPERM;
> >  
> > return security_ptrace_access_check(task, mode);
> >  }
> 
> This has some unfortunate duplication.
> 
> Lets go with it for now, but I'll see if I can do something about that
> later.

Yes, I know. I tried to make the duplication smaller, but all attempts
ended up being a convoluted mess. I'll try again after applying more
coffee.

Thanks,

tglx

Re: [PATCH] scheduler: conditional statement cleanup

[Peter Zijlstra]

On Fri, Sep 21, 2018 at 03:22:03PM -0500, PierceGriffiths wrote:
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 625bc9897f62..443a1f235cfd 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -617,12 +617,8 @@ bool sched_can_stop_tick(struct rq *rq)
>* If there are more than one RR tasks, we need the tick to effect the
>* actual RR behaviour.
>*/
> - if (rq->rt.rr_nr_running) {
> - if (rq->rt.rr_nr_running == 1)
> - return true;
> - else
> - return false;
> - }
> + if (rq->rt.rr_nr_running)
> + return rq->rt.rr_nr_running == 1;
>  
>   /*
>* If there's no RR tasks, but FIFO tasks, we can skip the tick, no

That one is OK I suppose.

> diff --git a/kernel/sched/cpufreq.c b/kernel/sched/cpufreq.c
> index 5e54cbcae673..a8fd4bd68954 100644
> --- a/kernel/sched/cpufreq.c
> +++ b/kernel/sched/cpufreq.c
> @@ -34,10 +34,7 @@ void cpufreq_add_update_util_hook(int cpu, struct 
> update_util_data *data,
>   void (*func)(struct update_util_data *data, u64 time,
>unsigned int flags))
>  {
> - if (WARN_ON(!data || !func))
> - return;
> -
> - if (WARN_ON(per_cpu(cpufreq_update_util_data, cpu)))
> + if (WARN_ON(!data || !func || per_cpu(cpufreq_update_util_data, cpu)))
>   return;
>  
>   data->func = func;

But I'm not a fan of this one. It mixes a different class of function
and the WARN condition gets too complicated. Its easier to have separate
warns.

> diff --git a/kernel/sched/cpupri.c b/kernel/sched/cpupri.c
> index daaadf939ccb..152c133e8247 100644
> --- a/kernel/sched/cpupri.c
> +++ b/kernel/sched/cpupri.c
> @@ -29,20 +29,16 @@
>  #include "sched.h"
>  
>  /* Convert between a 140 based task->prio, and our 102 based cpupri */
> -static int convert_prio(int prio)
> +static int convert_prio(const int prio)
>  {
> - int cpupri;
> -
>   if (prio == CPUPRI_INVALID)
> - cpupri = CPUPRI_INVALID;
> + return CPUPRI_INVALID;
>   else if (prio == MAX_PRIO)
> - cpupri = CPUPRI_IDLE;
> + return CPUPRI_IDLE;
>   else if (prio >= MAX_RT_PRIO)
> - cpupri = CPUPRI_NORMAL;
> + return CPUPRI_NORMAL;
>   else
> - cpupri = MAX_RT_PRIO - prio + 1;
> -
> - return cpupri;
> + return MAX_RT_PRIO - prio + 1;

The code looks even better if you leave out the last else.

>  }
>  
>  /**
> @@ -95,10 +91,8 @@ int cpupri_find(struct cpupri *cp, struct task_struct *p,
>   smp_rmb();
>  
>   /* Need to do the rmb for every iteration */
> - if (skip)
> - continue;
> -
> - if (cpumask_any_and(&p->cpus_allowed, vec->mask) >= nr_cpu_ids)
> + if (skip || cpumask_any_and(&p->cpus_allowed, vec->mask)
> + >= nr_cpu_ids)
>   continue;
>  
>   if (lowest_mask) {

That just makes the code ugly for no reason.

> @@ -222,7 +216,7 @@ int cpupri_init(struct cpupri *cp)
>   return 0;
>  
>  cleanup:
> - for (i--; i >= 0; i--)
> + while (--i >= 0)
>   free_cpumask_var(cp->pri_to_cpu[i].mask);
>   return -ENOMEM;
>  }
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index 2e2955a8cf8f..acf1b94669ad 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -142,10 +142,12 @@ void free_rt_sched_group(struct task_group *tg)
>   destroy_rt_bandwidth(&tg->rt_bandwidth);
>  
>   for_each_possible_cpu(i) {
> - if (tg->rt_rq)
> - kfree(tg->rt_rq[i]);
> - if (tg->rt_se)
> - kfree(tg->rt_se[i]);
> + /* Don't need to check if tg->rt_rq[i]
> +  * or tg->rt_se[i] are NULL, since kfree(NULL)
> +  * simply performs no operation
> +  */

That's an invalid comment style.

> + kfree(tg->rt_rq[i]);
> + kfree(tg->rt_se[i]);
>   }
>  
>   kfree(tg->rt_rq);
> @@ -1015,10 +1017,7 @@ enqueue_top_rt_rq(struct rt_rq *rt_rq)
>  
>   BUG_ON(&rq->rt != rt_rq);
>  
> - if (rt_rq->rt_queued)
> - return;
> -
> - if (rt_rq_throttled(rt_rq))
> + if (rt_rq->rt_queued || rt_rq_throttled(rt_rq))
>   return;
>  
>   if (rt_rq->rt_nr_running) {

The compiler can do this transformation and the old code was simpler.

> @@ -1211,10 +1210,7 @@ void dec_rt_tasks(struct sched_rt_entity *rt_se, 
> struct rt_rq *rt_rq)
>   */
>  static inline bool move_entity(unsigned int flags)
>  {
> - if ((flags & (DEQUEUE_SAVE | DEQUEUE_MOVE)) == DEQUEUE_SAVE)
> - return false;
> -
> - return true;
> + return !((flags & (DEQUEUE_SAVE | DEQUEUE_MOVE)) == DEQUEUE_SAVE)
>  }

Again, I find the new code harder to read.

>  
> @@ -2518,12 +2513,10 @@ static int

Re: [PATCH 1/2] iio: adc: at91: fix acking DRDY irq on simple conversions

[Jonathan Cameron]

On Thu, 20 Sep 2018 15:40:37 +0300
Eugen Hristev  wrote:

> When doing simple conversions, the driver did not acknowledge the DRDY irq.
> If this irq is not acked, it will be left pending, and as soon as a trigger
> is enabled, the irq handler will be called, it doesn't know why this irq
> has occurred because no channel is pending, and then we will have irq loop
> and board will hang.
> 
> Fixes 0e589d5fb ("ARM: AT91: IIO: Add AT91 ADC driver.")
> Cc: Maxime Ripard 
> Cc: 
> Signed-off-by: Eugen Hristev 
> ---
>  drivers/iio/adc/at91_adc.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index 44b5168..e85f859 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -712,6 +712,11 @@ static int at91_adc_read_raw(struct iio_dev *idev,
>   at91_adc_writel(st, AT91_ADC_CHDR,
>   AT91_ADC_CH(chan->channel));
>   at91_adc_writel(st, AT91_ADC_IDR, BIT(chan->channel));
> + /*
> +  * we need to ack the DRDY irq, otherwise it will be
> +  * left pending and irq handler will be confused
> +  */
> + at91_adc_readl(st, AT91_ADC_LCDR);

I'm curious as to how things were working before.  Does this only occur
if we do a raw_read whilst the buffer is enabled?

I would have assumed when it's not enabled, the irq would be masked and
never generated in the first place...

It may be that what we actually need to do is to prevent read_raw accesses
when the buffer is enabled (like lots of other drivers do precisely to
avoid this sort of condition). The problem there comes if we have
existing applications doing this combination as we are then breaking
userspace. If that's the case we'll need to be a bit more clever.

Hammering down an irq state in a non irq handling path isn't a good
solution.

Jonathan

>  
>   st->last_value = 0;
>   st->done = false;

Re: [patch V3 05/11] x86/mm/cpa: Add debug mechanism

[Peter Zijlstra]

On Fri, Sep 21, 2018 at 09:40:36AM -0700, Dave Hansen wrote:
> On 09/17/2018 07:29 AM, Thomas Gleixner wrote:
> > The whole static protection magic is silently fixing up anything which is
> > handed in. That's just wrong. The offending call sites need to be fixed.
> > 
> > Add a debug mechanism which emits a warning if a requested mapping needs to 
> > be
> > fixed up. The DETECT debug mechanism is really not meant to be enabled 
> > except
> > for developers, so limit the output hard to the protection fixups.
> ...
> > +enum cpa_warn {
> > +   CPA_PROTECT,
> > +   CPA_DETECT,
> > +};
> > +
> > +static const int cpa_warn_level = CPA_PROTECT;
> 
> Even if this is intended for developers only, should we also add some
> config option here so things like 0day can still get warnings out of this?
> 
> Reviewed-by: Dave Hansen 

OTOH, I really wish there was something like: depends !RANDCONFIG
for some of those things, because I triggered
GCC_PLUGIN_STRUCTLEAK_VERBOSE in a randconfig the other day and thought
everything was busted due to the massive output.

Re: [PATCH 2/2] iio: adc: at91: fix wrong channel number in triggered buffer mode

[Jonathan Cameron]

On Fri, 21 Sep 2018 15:26:03 +0800
kbuild test robot  wrote:

> Hi Eugen,
This one is leaving me stumped...

Anyone care to point out what I'm missing that is wrong here?

Also Eugen, please don't cc stable on a patch directly.  It is fine to send
a backport request once a patch has hit mainline, but before that it's just
adding noise to a list as they won't take it directly anyway.

Jonathan

> 
> I love your patch! Perhaps something to improve:
> 
> [auto build test WARNING on iio/togreg]
> [also build test WARNING on v4.19-rc4 next-20180919]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Eugen-Hristev/iio-adc-at91-fix-acking-DRDY-irq-on-simple-conversions/20180920-215908
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
> config: arm-allmodconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=arm 
> 
> All warnings (new ones prefixed by >>):
> 
>drivers/iio/adc/at91_adc.c: In function 'at91_adc_trigger_handler':
> >> drivers/iio/adc/at91_adc.c:257:8: warning: assignment discards 'const' 
> >> qualifier from pointer target type [-Wdiscarded-qualifiers]  
>   chan = idev->channels + i;
>^
> 
> vim +/const +257 drivers/iio/adc/at91_adc.c
> 
>245
>246static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
>247{
>248struct iio_poll_func *pf = p;
>249struct iio_dev *idev = pf->indio_dev;
>250struct at91_adc_state *st = iio_priv(idev);
>251struct iio_chan_spec *chan;
>252int i, j = 0;
>253
>254for (i = 0; i < idev->masklength; i++) {
>255if (!test_bit(i, idev->active_scan_mask))
>256continue;
>  > 257chan = idev->channels + i;  
>258st->buffer[j] = at91_adc_readl(st, 
> AT91_ADC_CHAN(st, chan->channel));
>259j++;
>260}
>261
>262iio_push_to_buffers_with_timestamp(idev, st->buffer, 
> pf->timestamp);
>263
>264iio_trigger_notify_done(idev->trig);
>265
>266/* Needed to ACK the DRDY interruption */
>267at91_adc_readl(st, AT91_ADC_LCDR);
>268
>269enable_irq(st->irq);
>270
>271return IRQ_HANDLED;
>272}
>273
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH 2/8] x86/mm/cpa: Move flush_tlb_all()

[Peter Zijlstra]

On Fri, Sep 21, 2018 at 02:34:32PM -0700, Dave Hansen wrote:
> On 09/19/2018 01:50 AM, Peter Zijlstra wrote:
> > @@ -1528,28 +1538,8 @@ static int __change_page_attr(struct cpa
> >  * We have to split the large page:
> >  */
> > err = split_large_page(cpa, kpte, address);
> > -   if (!err) {
> ...
> > -   flush_tlb_all();
> > +   if (!err)
> > goto repeat;
> > -   }
> 
> I _think_ this is the only use of split_large_page()'s error code.  We
> can just make it return void now, right?

Then how does it decide to goto repeat or error out?

> BTW, I also really like doing the "final" TLB flush as close as possible
> to the actual PTE manipulation.  Makes it much less likely that we break it.

Yes.

[ANNOUNCE] 4.4.157-rt174

[Daniel Wagner]

Hello RT Folks!

I'm pleased to announce the 4.4.157-rt174 stable release.

This release is just an update to the new stable 4.4.157 version
and no RT specific changes have been made.

Known issue:

- Cache line starvation. 'stress-ng --ptrace 4' is able to trigger a
  latency spike of several ms. For more details check

  
https://lwn.net/ml/linux-kernel/20180921120226.6xjgr4oiho22ex75%40linutronix.de/

You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v4.4-rt
  Head SHA1: b6e49a74949295ec22cd6571413eec32bc9c49a0

Or to build 4.4.157-rt174 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.tar.xz

  http://www.kernel.org/pub/linux/kernel/v4.x/patch-4.4.157.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/4.4/4.4/patch-4.4.157-rt174.patch.xz


You can also build from 4.4.148-rt165 by applying the incremental patch:

  
http://www.kernel.org/pub/linux/kernel/projects/rt/4.4/4.4/incr/patch-4.4.148-rt165-rt174.patch.xz

Enjoy!
   Daniel

Re: [PATCH 2/2] iio: adc: at91: fix wrong channel number in triggered buffer mode

[Song Qiang]

On Sat, Sep 22, 2018 at 11:36:16AM +0100, Jonathan Cameron wrote:
> On Fri, 21 Sep 2018 15:26:03 +0800
> kbuild test robot  wrote:
> 
> > Hi Eugen,
> This one is leaving me stumped...
> 
> Anyone care to point out what I'm missing that is wrong here?
> 
> Also Eugen, please don't cc stable on a patch directly.  It is fine to send
> a backport request once a patch has hit mainline, but before that it's just
> adding noise to a list as they won't take it directly anyway.
> 
> Jonathan
> 

Hi Jonathan,

I run some test code here and found out that C compilers don't allow
us to assign a 'const int *' to 'int *', while assign a 'const int' to
'int' is fine.
In this case this driver was tring to assign a 'struct iio_chan_spec
const *' to a 'struct iio_chan_spec *', mostly because of this issue.

I googled this issue and someone on stack overflow said it's because
this kind of action will break the check mechanism of 'const'.

yours,
Song Qiang

> > 
> > I love your patch! Perhaps something to improve:
> > 
> > [auto build test WARNING on iio/togreg]
> > [also build test WARNING on v4.19-rc4 next-20180919]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help improve the system]
> > 
> > url:
> > https://github.com/0day-ci/linux/commits/Eugen-Hristev/iio-adc-at91-fix-acking-DRDY-irq-on-simple-conversions/20180920-215908
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
> > config: arm-allmodconfig (attached as .config)
> > compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
> > reproduce:
> > wget 
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> > ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > GCC_VERSION=7.2.0 make.cross ARCH=arm 
> > 
> > All warnings (new ones prefixed by >>):
> > 
> >drivers/iio/adc/at91_adc.c: In function 'at91_adc_trigger_handler':
> > >> drivers/iio/adc/at91_adc.c:257:8: warning: assignment discards 'const' 
> > >> qualifier from pointer target type [-Wdiscarded-qualifiers]  
> >   chan = idev->channels + i;
> >^
> > 
> > vim +/const +257 drivers/iio/adc/at91_adc.c
> > 
> >245  
> >246  static irqreturn_t at91_adc_trigger_handler(int irq, void *p)
> >247  {
> >248  struct iio_poll_func *pf = p;
> >249  struct iio_dev *idev = pf->indio_dev;
> >250  struct at91_adc_state *st = iio_priv(idev);
> >251  struct iio_chan_spec *chan;
> >252  int i, j = 0;
> >253  
> >254  for (i = 0; i < idev->masklength; i++) {
> >255  if (!test_bit(i, idev->active_scan_mask))
> >256  continue;
> >  > 257  chan = idev->channels + i;  
> >258  st->buffer[j] = at91_adc_readl(st, 
> > AT91_ADC_CHAN(st, chan->channel));
> >259  j++;
> >260  }
> >261  
> >262  iio_push_to_buffers_with_timestamp(idev, st->buffer, 
> > pf->timestamp);
> >263  
> >264  iio_trigger_notify_done(idev->trig);
> >265  
> >266  /* Needed to ACK the DRDY interruption */
> >267  at91_adc_readl(st, AT91_ADC_LCDR);
> >268  
> >269  enable_irq(st->irq);
> >270  
> >271  return IRQ_HANDLED;
> >272  }
> >273  
> > 
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology 
> > Center
> > https://lists.01.org/pipermail/kbuild-all   Intel 
> > Corporation
> 

Re: [PATCH v7 0/7] clocksource: rework Atmel TCB timer driver

[Daniel Lezcano]

On 13/09/2018 13:30, Alexandre Belloni wrote:
> Hi,
> 
> This series reworks the Atmel TCB drivers. It introduces a new driver to 
> handle
> the clocksource and clockevent devices.
> 
> This is necessary because:
>  - the current tcb_clksrc driver is probed too late to be able to be used at
>boot and we now have SoCs that don't have a PIT. They currently are not 
> able
>to boot a mainline kernel.
>  - using the PIT doesn't work well with preempt-rt because its interrupt is
>shared (in particular with the UART and their interrupt flags are
>incompatible)

You say for rt the PIT is not suitable because of the shared irq but in
the driver, the interrupt is flagged as shared.

>  - the current solution is wasting some TCB channels
> 
> The plan is to get this driver upstream, then convert the TCB PWM driver to be
> able to get rid of the tcb_clksrc driver along with atmel_tclib now that AVR32
> is gone.
> 
> changes in v7:
>  - fixed a warning when building on 64 bit platforms
> 
> changes in v6:
>  - rebased on v4.19-rc1
>  - separated the clocksource/clockevent and the single clockevent in two
>different patches
>  - removed struct tc_clkevt_device and simply use struct atmel_tcb_clksrc
>  - removed struct atmel_tcb_info
>  - moved tcb_clk_get and tcb_irq_get to users
> 
> changes in v5:
>  - rebased on v4.18-rc1
>  - fixed the clock enabling/disabling in atomic context under preempt-rt
> 
> Changes in v4:
>  - rebased on top of v4.17-rc1
>  - fixed an issue when setting max_delta for clockevents_config_and_register
> 
> Alexandre Belloni (7):
>   ARM: at91: add TCB registers definitions
>   clocksource/drivers: Add a new driver for the Atmel ARM TC blocks
>   clocksource/drivers: timer-atmel-tcb: add clockevent device on
> separate channel
>   clocksource/drivers: atmel-pit: make option silent
>   ARM: at91: Implement clocksource selection
>   ARM: configs: at91: use new TCB timer driver
>   ARM: configs: at91: unselect PIT
> 
>  arch/arm/configs/at91_dt_defconfig|   2 +-
>  arch/arm/configs/sama5_defconfig  |   2 +-
>  arch/arm/mach-at91/Kconfig|  25 ++
>  drivers/clocksource/Kconfig   |  13 +-
>  drivers/clocksource/Makefile  |   3 +-
>  drivers/clocksource/timer-atmel-tcb.c | 617 ++
>  include/soc/at91/atmel_tcb.h  | 183 
>  7 files changed, 841 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/clocksource/timer-atmel-tcb.c
>  create mode 100644 include/soc/at91/atmel_tcb.h
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 2/2] iio: adc: at91: fix wrong channel number in triggered buffer mode

[Himanshu Jha]

On Sat, Sep 22, 2018 at 11:36:16AM +0100, Jonathan Cameron wrote:
> On Fri, 21 Sep 2018 15:26:03 +0800
> kbuild test robot  wrote:
> 
> > Hi Eugen,
> This one is leaving me stumped...
> 
> Anyone care to point out what I'm missing that is wrong here?
> 
> Also Eugen, please don't cc stable on a patch directly.  It is fine to send
> a backport request once a patch has hit mainline, but before that it's just
> adding noise to a list as they won't take it directly anyway.

Song is correct on this one.

So, just replace the declaration to:

struct iio_chan_spec const *chan;

and then warning goes away...

Another thing, its better not to reply the automated bot and instead to
the author by changing "From" address. :)

That is what I do often when replying to that thread.

https://lore.kernel.org/lkml/20180921182616.GA2077@himanshu-Vostro-3559/

And it nests properly in the given thread avoiding any noise to kbuild
bot.


-- 
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology

Re: [PATCH] auxdisplay/cfag12864bfb.c: Replace vm_insert_page

[Matthew Wilcox]

On Fri, Sep 21, 2018 at 01:53:16AM +0530, Souptick Joarder wrote:
> There is a plan to remove vm_insert_page permanently
> and replace it with new API vmf_insert_page which will
> return vm_fault_t type. As part of it vm_insert_page
> is removed from this driver.
> 
> remap_pfn_range() will be used to map kernel memory to
> user vma.

I think this patch is dangerous.  It's not buggy *for this driver*,
but it gives the impression that it's safe to use remap_pfn_range()
for this *kind* of driver.

Re: [PATCH 3.16 00/63] 3.16.58-rc1 review

[Guenter Roeck]

On 09/21/2018 05:15 PM, Ben Hutchings wrote:

This is the start of the stable review cycle for the 3.16.58 release.
There are 63 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Mon Sep 24 00:15:41 UTC 2018.
Anything received after that time might be too late.



Build results:
total: 139 pass: 139 fail: 0
Qemu test results:
total: 217 pass: 217 fail: 0

Details are available at https://kerneltests.org/builders/.

Guenter

[GIT pull] x86 fixes for 4.19

[Thomas Gleixner]

Greg,

please pull the latest x86-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
x86-urgent-for-linus

A set of fixes for x86:

  - Resolve the kvmclock regression on AMD systems with memory encryption
enabled. The rework of the kvmclock memory allocation during early boot
results in encrypted storage, which is not shareable with the
hypervisor. Create a new section for this data which is mapped
unencrypted and take care that the later allocations for shared
kvmclock memory is unencrypted as well.

  - Fix the build regression in the paravirt code introduced by the recent
spectre v2 updates.

  - Ensure that the initial static page tables cover the fixmap space
correctly so early console always works. This worked so far by chance,
but recent modifications to the fixmap layout can - depending on kernel
configuration - move the relevant entries to a different place which is
not covered by the initial static page tables.

  - Address the regressions and issues which got introduced with the recent
extensions to the Intel Recource Director Technology code.

  - Update maintainer entries to document reality

Thanks,

tglx

-->
Brijesh Singh (2):
  x86/mm: Add .bss..decrypted section to hold shared variables
  x86/kvm: Use __bss_decrypted attribute in shared variables

Dan Carpenter (1):
  x86/paravirt: Fix some warning messages

Feng Tang (1):
  x86/mm: Expand static page table for fixmap space

Fenghua Yu (1):
  x86/intel_rdt: Add Reinette as co-maintainer for RDT

Reinette Chatre (8):
  x86/intel_rdt: Fix size reporting of MBA resource
  x86/intel_rdt: Global closid helper to support future fixes
  x86/intel_rdt: Fix invalid mode warning when multiple resources are 
managed
  x86/intel_rdt: Fix unchecked MSR access
  x86/intel_rdt: Do not allow pseudo-locking of MBA resource
  x86/intel_rdt: Fix incorrect loop end condition
  x86/intel_rdt: Fix exclusive mode handling of MBA resource
  x86/intel_rdt: Fix incorrect loop end condition

Thomas Gleixner (2):
  MAINTAINERS: Add Borislav to the x86 maintainers
  MAINTAINERS: Add X86 MM entry

Xiaochen Shen (1):
  x86/intel_rdt: Fix data type in parsing callbacks


 MAINTAINERS | 11 ++
 arch/x86/include/asm/fixmap.h   | 10 ++
 arch/x86/include/asm/mem_encrypt.h  |  7 
 arch/x86/include/asm/pgtable_64.h   |  3 +-
 arch/x86/kernel/cpu/intel_rdt.h | 17 ++---
 arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 27 ---
 arch/x86/kernel/cpu/intel_rdt_rdtgroup.c| 53 -
 arch/x86/kernel/head64.c| 20 ++-
 arch/x86/kernel/head_64.S   | 16 ++---
 arch/x86/kernel/kvmclock.c  | 52 ++--
 arch/x86/kernel/paravirt.c  |  4 +--
 arch/x86/kernel/vmlinux.lds.S   | 19 +++
 arch/x86/mm/init.c  |  4 +++
 arch/x86/mm/mem_encrypt.c   | 24 +
 arch/x86/mm/pgtable.c   |  9 +
 arch/x86/xen/mmu_pv.c   |  8 +++--
 16 files changed, 245 insertions(+), 39 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4ece30f15777..80a311252b04 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12260,6 +12260,7 @@ F:  Documentation/networking/rds.txt
 
 RDT - RESOURCE ALLOCATION
 M: Fenghua Yu 
+M: Reinette Chatre 
 L: linux-kernel@vger.kernel.org
 S: Supported
 F: arch/x86/kernel/cpu/intel_rdt*
@@ -15913,6 +15914,7 @@ F:  net/x25/
 X86 ARCHITECTURE (32-BIT AND 64-BIT)
 M: Thomas Gleixner 
 M: Ingo Molnar 
+M: Borislav Petkov 
 R: "H. Peter Anvin" 
 M: x...@kernel.org
 L: linux-kernel@vger.kernel.org
@@ -15941,6 +15943,15 @@ M: Borislav Petkov 
 S: Maintained
 F: arch/x86/kernel/cpu/microcode/*
 
+X86 MM
+M: Dave Hansen 
+M: Andy Lutomirski 
+M: Peter Zijlstra 
+L: linux-kernel@vger.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/mm
+S: Maintained
+F: arch/x86/mm/
+
 X86 PLATFORM DRIVERS
 M: Darren Hart 
 M: Andy Shevchenko 
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index e203169931c7..6390bd8c141b 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -14,6 +14,16 @@
 #ifndef _ASM_X86_FIXMAP_H
 #define _ASM_X86_FIXMAP_H
 
+/*
+ * Exposed to assembly code for setting up initial page tables. Cannot be
+ * calculated in assembly code (fixmap entries are an enum), but is sanity
+ * checked in the actual fixmap C code to make sure that the fixmap is
+ * covered fully.
+ */
+#define FIXMAP_PMD_NUM 2
+/* fixmap starts downwards from the 507th entry in level2_fixmap_pgt */
+#define FIXMAP_PMD_TOP 507
+
 #ifndef

[GIT pull] efi fix for 4.19

[Thomas Gleixner]

Greg,

please pull the latest efi-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
efi-urgent-for-linus

Make the EFI arm stub device tree loader default on to unbreak existing
EFI boot loaders which do not have DTB support.


Thanks,

tglx

-->
Scott Branden (1):
  efi/libstub/arm: default EFI_ARMSTUB_DTB_LOADER to y


 drivers/firmware/efi/Kconfig | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index d8e159feb573..89110dfc7127 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -90,14 +90,17 @@ config EFI_ARMSTUB
 config EFI_ARMSTUB_DTB_LOADER
bool "Enable the DTB loader"
depends on EFI_ARMSTUB
+   default y
help
  Select this config option to add support for the dtb= command
  line parameter, allowing a device tree blob to be loaded into
  memory from the EFI System Partition by the stub.
 
- The device tree is typically provided by the platform or by
- the bootloader, so this option is mostly for development
- purposes only.
+ If the device tree is provided by the platform or by
+ the bootloader this option may not be needed.
+ But, for various development reasons and to maintain existing
+ functionality for bootloaders that do not have such support
+ this option is necessary.
 
 config EFI_BOOTLOADER_CONTROL
tristate "EFI Bootloader Control"

[GIT pull] perf fixes for 4.19

[Thomas Gleixner]

Greg,

please pull the latest perf-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
perf-urgent-for-linus


Two small fixes for perf tools:

 - Provide a strerror_r wrapper so lib/bpf can be built on systems without
   _GNU_SOURCE

 - Unbreak the man page generator when building out of tree

Thanks,

tglx

-->
Arnaldo Carvalho de Melo (1):
  tools lib bpf: Provide wrapper for strerror_r to build in !_GNU_SOURCE 
systems

Ben Hutchings (1):
  perf Documentation: Fix out-of-tree asciidoctor man page generation


 tools/lib/bpf/Build   |  2 +-
 tools/lib/bpf/libbpf.c| 20 ++--
 tools/lib/bpf/str_error.c | 18 ++
 tools/lib/bpf/str_error.h |  6 ++
 tools/perf/Documentation/Makefile |  2 +-
 5 files changed, 36 insertions(+), 12 deletions(-)
 create mode 100644 tools/lib/bpf/str_error.c
 create mode 100644 tools/lib/bpf/str_error.h

diff --git a/tools/lib/bpf/Build b/tools/lib/bpf/Build
index 13a861135127..6eb9bacd1948 100644
--- a/tools/lib/bpf/Build
+++ b/tools/lib/bpf/Build
@@ -1 +1 @@
-libbpf-y := libbpf.o bpf.o nlattr.o btf.o libbpf_errno.o
+libbpf-y := libbpf.o bpf.o nlattr.o btf.o libbpf_errno.o str_error.o
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 2abd0f112627..bdb94939fd60 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -50,6 +50,7 @@
 #include "libbpf.h"
 #include "bpf.h"
 #include "btf.h"
+#include "str_error.h"
 
 #ifndef EM_BPF
 #define EM_BPF 247
@@ -469,7 +470,7 @@ static int bpf_object__elf_init(struct bpf_object *obj)
obj->efile.fd = open(obj->path, O_RDONLY);
if (obj->efile.fd < 0) {
char errmsg[STRERR_BUFSIZE];
-   char *cp = strerror_r(errno, errmsg, sizeof(errmsg));
+   char *cp = str_error(errno, errmsg, sizeof(errmsg));
 
pr_warning("failed to open %s: %s\n", obj->path, cp);
return -errno;
@@ -810,8 +811,7 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
  data->d_size, name, idx);
if (err) {
char errmsg[STRERR_BUFSIZE];
-   char *cp = strerror_r(-err, errmsg,
- sizeof(errmsg));
+   char *cp = str_error(-err, errmsg, 
sizeof(errmsg));
 
pr_warning("failed to alloc program %s (%s): 
%s",
   name, obj->path, cp);
@@ -1140,7 +1140,7 @@ bpf_object__create_maps(struct bpf_object *obj)
 
*pfd = bpf_create_map_xattr(&create_attr);
if (*pfd < 0 && create_attr.btf_key_type_id) {
-   cp = strerror_r(errno, errmsg, sizeof(errmsg));
+   cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("Error in bpf_create_map_xattr(%s):%s(%d). 
Retrying without BTF.\n",
   map->name, cp, errno);
create_attr.btf_fd = 0;
@@ -1155,7 +1155,7 @@ bpf_object__create_maps(struct bpf_object *obj)
size_t j;
 
err = *pfd;
-   cp = strerror_r(errno, errmsg, sizeof(errmsg));
+   cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("failed to create map (name: '%s'): %s\n",
   map->name, cp);
for (j = 0; j < i; j++)
@@ -1339,7 +1339,7 @@ load_program(enum bpf_prog_type type, enum 
bpf_attach_type expected_attach_type,
}
 
ret = -LIBBPF_ERRNO__LOAD;
-   cp = strerror_r(errno, errmsg, sizeof(errmsg));
+   cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("load bpf program failed: %s\n", cp);
 
if (log_buf && log_buf[0] != '\0') {
@@ -1654,7 +1654,7 @@ static int check_path(const char *path)
 
dir = dirname(dname);
if (statfs(dir, &st_fs)) {
-   cp = strerror_r(errno, errmsg, sizeof(errmsg));
+   cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("failed to statfs %s: %s\n", dir, cp);
err = -errno;
}
@@ -1690,7 +1690,7 @@ int bpf_program__pin_instance(struct bpf_program *prog, 
const char *path,
}
 
if (bpf_obj_pin(prog->instances.fds[instance], path)) {
-   cp = strerror_r(errno, errmsg, sizeof(errmsg));
+   cp = str_error(errno, errmsg, sizeof(errmsg));
pr_warning("failed to pin program: %s\n", cp);
return -errno;
}
@@ -1708,7 +1708,7 @@ static int make_dir(const char *path)
err = -errno;
 
if (err) {
-   cp = strerror_r(-err, e

Re: [PATCH] ARM: dts: Add support for Liebherr's BK4 device (vf610 based)

[Lukasz Majewski]

Hi Stefan,

Thanks for review,

> On 21.09.2018 08:27, Lukasz Majewski wrote:
> > This commit adds DTS support for BK4 device from Liebherr. It
> > uses vf610 SoC from NXP.
> > 
> > Signed-off-by: Lukasz Majewski 
> > ---
> >  arch/arm/boot/dts/Makefile  |   1 +
> >  arch/arm/boot/dts/vf610-bk4.dts | 504
> >  2 files changed, 505
> > insertions(+) create mode 100644 arch/arm/boot/dts/vf610-bk4.dts
> > 
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index b5bd3de87c33..e6f159895fa9 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -577,6 +577,7 @@ dtb-$(CONFIG_SOC_LS1021A) += \
> > ls1021a-twr.dtb
> >  dtb-$(CONFIG_SOC_VF610) += \
> > vf500-colibri-eval-v3.dtb \
> > +   vf610-bk4.dtb \
> > vf610-colibri-eval-v3.dtb \
> > vf610m4-colibri.dtb \
> > vf610-cosmic.dtb \
> > diff --git a/arch/arm/boot/dts/vf610-bk4.dts
> > b/arch/arm/boot/dts/vf610-bk4.dts new file mode 100644
> > index ..4ad7e739a0ad
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/vf610-bk4.dts
> > @@ -0,0 +1,504 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright 2018
> > + * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
> > + */
> > +
> > +/dts-v1/;
> > +#include "vf610.dtsi"
> > +
> > +/ {
> > +   model = "Liebherr BK4 controller";
> > +   compatible = "lwn,bk4", "fsl,vf610";
> > +
> > +   chosen {
> > +   bootargs = "console=ttyLP1,115200";
> > +   };
> > +
> > +   memory@8000 {
> > +   reg = <0x8000 0x800>;
> > +   };
> > +
> > +   audio_ext: mclk_osc {  
> 
> Node name should be somewhat generic. I know its the same in twr
> board, we probably should fix it there. The device tree spec has some
> recommendation, I would suggest using just "oscillator-audio".

So it shall be audio_ext: oscillator-audio { ...

> 
> > +   compatible = "fixed-clock";
> > +   #clock-cells = <0>;
> > +   clock-frequency = <24576000>;
> > +   };
> > +
> > +   enet_ext: eth_osc {  
> 
> Same here, oscillator-ethernet maybe.

Ok - enet_ext: oscillator-ethernet { ...

> 
> 
> > +   compatible = "fixed-clock";
> > +   #clock-cells = <0>;
> > +   clock-frequency = <5000>;
> > +   };
> > +
> > +   leds {
> > +   compatible = "gpio-leds";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pinctrl_gpio_leds>;
> > +
> > +   /* LED D5 */
> > +   led0: heartbeat {
> > +   label = "heartbeat";
> > +   gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> > +   default-state = "on";
> > +   linux,default-trigger = "heartbeat";
> > +   };
> > +   };
> > +
> > +   regulators {
> > +   compatible = "simple-bus";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;  
> 
> We stopped using a regulator subnode. Just move the regulators to the
> top and use unique names such as "regulator-3p3v".

Ok.

> 
> > +
> > +   reg_3p3v: regulator@0 {
> > +   compatible = "regulator-fixed";
> > +   reg = <0>;
> > +   regulator-name = "3P3V";
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   regulator-always-on;
> > +   };
> > +
> > +   reg_vcc_3v3_mcu: regulator@1 {
> > +   compatible = "regulator-fixed";
> > +   reg = <1>;
> > +   regulator-name = "vcc_3v3_mcu";
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   };
> > +   };
> > +};
> > +
> > +&adc0 {
> > +   vref-supply = <®_vcc_3v3_mcu>;
> > +   status = "okay";
> > +};
> > +
> > +&adc1 {
> > +   vref-supply = <®_vcc_3v3_mcu>;
> > +   status = "okay";
> > +};
> > +
> > +&can0 {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pinctrl_can0>;
> > +   status = "okay";
> > +};
> > +
> > +&can1 {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pinctrl_can1>;
> > +   status = "okay";
> > +};
> > +
> > +&clks {
> > +   clocks = <&sxosc>, <&fxosc>, <&enet_ext>, <&audio_ext>;
> > +   clock-names = "sxosc", "fxosc", "enet_ext", "audio_ext";
> > +};
> > +
> > +&dspi0 {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pinctrl_dspi0>;
> > +   bus-num = <0>;
> > +   status = "okay";
> > +
> > +   spidev0@0 {
> > +   compatible = "fsl,vf610-dspi";  
> 
> I don't think this is right. A subnode of the dspi controller should
> use a device tree binding of SPI device. What is connected to that
> SPI in your case? 

The dspi IP block provides SPI communication with variety of devices
(connected via external cable).

From SW point of view, the spidev driver is used. User space program(s)
via the /dev/spidevX.Y device communicate with connected 

Re: [PATCH] Fix clang warning -Wpointer-bool-conversion by removing unnecessary check in regd.c

[Dan Carpenter]

The subject needs a subsystem prefix.  It's also slightly long.

[PATCH] Staging: rtlwifi: remove unnecessary NULL check

regards,
dan carpenter

Re: [PATCH 2/2] iio: adc: at91: fix wrong channel number in triggered buffer mode

[Jonathan Cameron]

On 22 September 2018 12:48:49 BST, Himanshu Jha  
wrote:
>On Sat, Sep 22, 2018 at 11:36:16AM +0100, Jonathan Cameron wrote:
>> On Fri, 21 Sep 2018 15:26:03 +0800
>> kbuild test robot  wrote:
>> 
>> > Hi Eugen,
>> This one is leaving me stumped...
>> 
>> Anyone care to point out what I'm missing that is wrong here?
>> 
>> Also Eugen, please don't cc stable on a patch directly.  It is fine
>to send
>> a backport request once a patch has hit mainline, but before that
>it's just
>> adding noise to a list as they won't take it directly anyway.
>
>Song is correct on this one.
>
>So, just replace the declaration to:
>
>   struct iio_chan_spec const *chan;
>
>and then warning goes away...

Good point. Not enough coffee this morning..

Obvious now :)
>
>Another thing, its better not to reply the automated bot and instead to
>the author by changing "From" address. :)
>
>That is what I do often when replying to that thread.
>
>https://lore.kernel.org/lkml/20180921182616.GA2077@himanshu-Vostro-3559/
>
>And it nests properly in the given thread avoiding any noise to kbuild
>bot.



-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Announce] LPC 2018: Testing and Fuzzing Microconference

[Matthew Wilcox]

On Wed, Sep 19, 2018 at 10:13:15AM -0700, Dhaval Giani wrote:
> Sasha and I are pleased to announce the Testing and Fuzzing track at
> LPC [ 1 ]. We are planning to continue the discussions from last
> year's microconference [2]. Many discussions from the Automated
> Testing Summit [3] will also continue, and a final agenda will come up
> only soon after that.
> 
> Suggested Topics
> 
> - Syzbot/syzkaller
> - ATS
> - Distro/stable testing
> - kernelci
> - kernelci auto bisection
> - Unit testing framework
> 
> We look forward to other interesting topics for this microconference
> as a reply to this email.

I would like to talk about the IDA test suite that was recently merged.
See lib/test_ida.c.  It can be built as a module (CONFIG_TEST_IDA=m),
built-in (=y) or built in userspace (as part of the radix tree test
suite for historical reasons) along with the current kernel code.

Being able to build the test suite in userspace allows for much more
rapid development.  Building it in kernel space offers testing across
a wide range of configurations that I don't have access to and can't
necessarily simulate well in userspace.

My userspace implementation of kmalloc() simulates failures (in a rather
heavy-handed way; every non-GFP_KERNEL allocation fails).  That's rather
harder to simulate in kernel space.  I'd like there to be a way for a
kernel space test suite to ask for kmalloc failures so that the failure
paths can be tested.

I think the idea of building parts of the core kernel libraries in
userspace and testing them there has greater generality than just the
IDA, IDR, XArray & radix tree and might profitably be adopted by other
parts of lib/.  The userspace simulation of other parts of the kernel
may well need to be extended.

I'd also like to do at least kernel-space testing of the page cache.
I have some ideas around that too, but I don't know if they're
sufficiently far advanced to talk about in November.

Do you need a helping hand?

[agricu]

--
I am Mavis Wanczyk i know you may not know me but am the latest  
largest US Powerball lottery winner of $758.7m just of recent, am  
currently helping out  people in need of financial assistance, i know  
it's hard to believe anything on the internet,  so if you don't need  
my help please don't reply to this message.


Regards
Mavis Wanczyk

Do You Need A Helping Hand?

Re: [PATCH 5/6] fsmount: do not use legacy MS_ flags

[Christian Brauner]

On Fri, Sep 21, 2018 at 05:52:36PM +0100, David Howells wrote:
> Christian Brauner  wrote:
> 
> > So from reading the patch I got the impression that superblock mount
> > options passed via fsconfig() are passed as strings like "ro" and are
> > translated into approriate objects (e.g. flags etc.) by the kernel.
> 
> I'm having second throughts about that - at least for "ro": that one is
> particularly problematic as it governs how source devices are opened.  I'm
> kind of tempted to pass that as a flag to fsopen().
> 
> What I'd like to do in btrfs, ext4, etc. is open blockdevs as I get the
> parameters that enumerate them - but I have to hold the looked-up paths till
> the validate/get_tree stage so that I know the final ro/rw state before I can
> do the opening.
> 
> > That seems like a future proof mechanism to extend mount options for
> > userspace without having to worry about exceeding any integer types in the
> > future. Maybe this would make sense for non-superblock options as well? I
> > can see that this is less performant that checking flags and string parsing
> > is a thing that is not particularly nice but it would be one option to solve
> > the running out of flags problem.
> 
> Al disliked the idea of setting up a separate context to define the mount
> options.

I hope thinking about mount flag exhaustion at this point is not too
hijacking this thread too much. But another option I was thinking about was to
split the mount flags into different sets where the sets can be
differentiated by a command.

enum {
MOUNT_ATTR_PROPAGATION = 1
MOUNT_ATTR_SECURITY
MOUNT_ATTR_FSTIME
}

Let's say split mount propagation flags into a set identified by
MOUNT_ATTR_PROPAGATION:
#define MOUNT_ATTR_UNBINDABLE   (1<<0)  /* change to unbindable */
#define MOUNT_ATTR_PRIVATE  (1<<1)  /* change to private */
#define MOUNT_ATTR_SLAVE(1<<2)  /* change to slave */
#define MOUNT_ATTR_SHARED   (1<<3)  /* change to shared */

and another set
MOUNT_ATTR_SECURITY:
#define MOUNT_ATTR_RDONLY(1<<0) /* Mount read-only */
#define MOUNT_ATTR_NOSUID(1<<1) /* Ignore suid and sgid bits */
#define MOUNT_ATTR_NODEV (1<<2) /* Disallow access to device special 
files */
#define MOUNT_ATTR_NOEXEC(1<<3) /* Disallow program execution */

and another set
MOUNT_ATTR_FSTIME:
#define MOUNT_ATTR_NOATIME  (1<<0)  /* Do not update access times. */
#define MOUNT_ATTR_NODIRATIME   (1<<1)  /* Do not update directory access times 
*/

and so on...

So you could e.g. add another unsigned int cmd argument to
mount_setattr():

mount_setattr(int dfd, const char *path, unsigned int atflags,
  unsigned int attr_cmd,
  unsigned int attr_values,
  unsigned int attr_mask);

Then - similiar to fsconfig()'s FS_CONFIG_SET_{FLAG,STRING,...} - you
would pass:

/* set propagation */
mount_setattr(dfd, path, atflags,
  MOUNT_ATTR_PROPAGATION,
  vals,
  propagation_flagmask);

/* set security */
mount_setattr(dfd, path, atflags,
  MOUNT_ATTR_SECURITY,
  vals,
  security_flagmask);

/* set time */
mount_setattr(dfd, path, atflags,
  MOUNT_ATTR_FSTIME,
  vals,
  fstime_flagmask);

and then finally have an additional command like:

/* apply changes */
mount_setattr(dfd, path, atflags, MOUNT_ATTR_APPLY, vals, 0);

that applies all the properties.

In kernel you could then either have separate flags in the corresponding
structs of interest or bit arrays of arbitrary length or whatever.
Each of the flag setting commands before the MOUNT_ATTR_APPLY would then
perform verification whether the combination of flags makes sense and
immediately return back an error to userspace but only the
MOUNT_ATTR_APPLY call would actually commit the changes.

> 
> > >   mount_setattr(int dfd, const char *path, unsigned int atflags,
> > > unsigned int attr_values,
> > > unsigned int attr_mask);
> > 
> > If we go with the flag arguments wouldn't it make sense to use a larger
> > integer type?
> 
> You can't - at least not directly through syscall args.  They are 32-bit on a
> 32-bit system.

Ah, 32bit systems. I tend to forget that they exist. :)

> 
> > > where atflags can potentially include AT_RECURSIVE.
> > 
> > Very much in favor of having this operate recursively!
> 
> It gets complicated with propagation.

Sure, I totally understand.

Christian


signature.asc
Description: PGP signature

[ANNOUNCE] 4.14.71-rt44

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 4.14.71-rt44 stable release.


This release is just an update to the new stable 4.14.71 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v4.14-rt
  Head SHA1: 917fa4e672939669f74f1c879b3aae6239f6719b


Or to build 4.14.71-rt44 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v4.x/linux-4.14.tar.xz

  http://www.kernel.org/pub/linux/kernel/v4.x/patch-4.14.71.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/4.14/patch-4.14.71-rt44.patch.xz




Enjoy,

-- Steve

Re: [PATCH v6 0/3] Harden spectrev2 userspace-userspace protection

[Thomas Gleixner]

On Sat, 22 Sep 2018, Thomas Gleixner wrote:
> On Sat, 22 Sep 2018, Peter Zijlstra wrote:
> > This has some unfortunate duplication.
> > 
> > Lets go with it for now, but I'll see if I can do something about that
> > later.
> 
> Yes, I know. I tried to make the duplication smaller, but all attempts
> ended up being a convoluted mess. I'll try again after applying more
> coffee.

Lunch and coffee indeed made brain work better. The simple solution was way
too obvious.

Thanks,

tglx

8<
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -180,6 +181,19 @@ static void sync_current_stack_to_mm(str
}
 }
 
+static bool ibpb_needed(struct task_struct *tsk, u64 last_ctx_id)
+{
+   /*
+* Check if the current (previous) task has access to the memory
+* of the @tsk (next) task. If access is denied, make sure to
+* issue a IBPB to stop user->user Spectre-v2 attacks.
+*
+* Note: __ptrace_may_access() returns 0 or -ERRNO.
+*/
+   return (tsk && tsk->mm && tsk->mm->context.ctx_id != last_ctx_id &&
+   ptrace_may_access_sched(tsk, PTRACE_MODE_SPEC_IBPB));
+}
+
 void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
struct task_struct *tsk)
 {
@@ -262,18 +276,13 @@ void switch_mm_irqs_off(struct mm_struct
 * one process from doing Spectre-v2 attacks on another.
 *
 * As an optimization, flush indirect branches only when
-* switching into processes that disable dumping. This
-* protects high value processes like gpg, without having
-* too high performance overhead. IBPB is *expensive*!
-*
-* This will not flush branches when switching into kernel
-* threads. It will also not flush if we switch to idle
-* thread and back to the same process. It will flush if we
-* switch to a different non-dumpable process.
+* switching into a processes that can't be ptrace by the
+* current one (as in such case, attacker has much more
+* convenient way how to tamper with the next process than
+* branch buffer poisoning).
 */
-   if (tsk && tsk->mm &&
-   tsk->mm->context.ctx_id != last_ctx_id &&
-   get_dumpable(tsk->mm) != SUID_DUMP_USER)
+   if (static_cpu_has(X86_FEATURE_USE_IBPB) &&
+   ibpb_needed(tsk, last_ctx_id))
indirect_branch_prediction_barrier();
 
if (IS_ENABLED(CONFIG_VMAP_STACK)) {
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -62,14 +62,17 @@ extern void exit_ptrace(struct task_stru
 #define PTRACE_MODE_READ   0x01
 #define PTRACE_MODE_ATTACH 0x02
 #define PTRACE_MODE_NOAUDIT0x04
-#define PTRACE_MODE_FSCREDS 0x08
-#define PTRACE_MODE_REALCREDS 0x10
+#define PTRACE_MODE_FSCREDS0x08
+#define PTRACE_MODE_REALCREDS  0x10
+#define PTRACE_MODE_SCHED  0x20
+#define PTRACE_MODE_IBPB   0x40
 
 /* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
 #define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
 #define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
 #define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
 #define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH | 
PTRACE_MODE_REALCREDS)
+#define PTRACE_MODE_SPEC_IBPB (PTRACE_MODE_ATTACH_REALCREDS | PTRACE_MOD_IBPB)
 
 /**
  * ptrace_may_access - check whether the caller is permitted to access
@@ -87,6 +90,20 @@ extern void exit_ptrace(struct task_stru
  */
 extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
 
+/**
+ * ptrace_may_access - check whether the caller is permitted to access
+ * a target task.
+ * @task: target task
+ * @mode: selects type of access and caller credentials
+ *
+ * Returns true on success, false on denial.
+ *
+ * Similar to ptrace_may_access(). Only to be called from context switch
+ * code. Does not call into audit and the regular LSM hooks due to locking
+ * constraints.
+ */
+extern bool ptrace_may_access_sched(struct task_struct *task, unsigned int 
mode);
+
 static inline int ptrace_reparented(struct task_struct *child)
 {
return !same_thread_group(child->real_parent, child->parent);
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -261,6 +261,9 @@ static int ptrace_check_attach(struct ta
 
 static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
 {
+   if (mode & PTRACE_MODE_SCHED)
+   return false;
+
if (mode & PTRACE_MODE_NOAUDIT)
return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE);
else
@@ -328,9 +331,16 @@ static int __ptrace_m

Re: [PATCH] auxdisplay/cfag12864bfb.c: Replace vm_insert_page

[Miguel Ojeda]

On Fri, Sep 21, 2018 at 1:07 PM, Souptick Joarder  wrote:
> On Fri, Sep 21, 2018 at 2:56 AM Miguel Ojeda
>  wrote:
>>
>> A link to the discussion/plan would be nice. The commit 1c8f422059ae5
>> ("mm: change return type to vm_fault_t") explains a bit, but has a
>> broken link :( Googling for the stuff returns many of the patches, but
>> not the actual discussion...
>
> This might be helpful.
> https://marc.info/?l=linux-mm&m=152054772413234&w=4

Thank you, although that does not explain why the changes are
happening, only that you are introducing the new API so that you can
start converting users (which is the normal way of doing it, no?).
What I meant is the discussion that led to commit 1c8f422059ae5 itself
(which has a link inside, but is broken).

>> I am out of the loop on these mm changes, so please indulge me, but:
>>
>>   * Why is there no documentation on vmf_insert_page() while
>> vm_insert_page() had it? (specially since it seems you want to remove
>> vm_insert_page()).
>
> The plan is to convert vm_insert_{page,pfn,mixed} to
> vmf_insert_{page,pfn,mixed}. As a good intermediate
> steps inline wrapper vmf_insert_{pfn,page,mixed} are
> introduced. After all the drivers converted, we will convert
> vm_insert_page to vmf_insert_page and remove the inline
> wrapper and update the document at the same time.

Yeah, that is what 1c8f422059ae5 ("mm: change return type to
vm_fault_t") seems to say at the end (thanks for clarifying).

Still, that does not explain why the documentation was not added at
the same time as soon the new API is introduced. I don't see how it
matters that they are wrappers.

Actually, I think the wrappers should have been the final functions
already in memory.c, their declarations in mm.h, etc. That way you
would minimize the code changes later on: you would be only removing
dead code, rather than changing code again. Even if you forward the
calls for the moment, it would have been a much smaller change later
on.

>
>>
>>   * Shouldn't we have a simple remap_page() or remap_kernel_page() to
>> fit this use case and avoid that dance? (another driver in auxdisplay
>> will require the same change, and I guess others in the kernel as
>> well).
>
>
> There are few drivers similar like auxdisplay where straight forward
> conversion from vm_insert_page to vmf_insert_page is not possible.
>
> So I mapped the kernel memory to user vma using remap_pfn_range
> and remove vm_insert_page in this driver.
>
> Other way, is to replace vm_insert_page with vmf_insert_page() and
> then convert VM_FAULT_CODE back to errno. But as part of vm_fault_t
> migration we have already removed/cleanup most the errno to VM_FAULT_CODE
> mapping from drivers. So I prefer not to take this option.
>
> Third, we can introduce a similar API like vm_insert_page say,
> vm_insert_kmem_page() and use it for same scenarios like this.

Yep, I think that is the best, unless there are only a couple of users
and you think nobody should be using it in the future.

Cheers,
Miguel

Re: [PATCH] Fix clang warning -Wpointer-bool-conversion by removing unnecessary check in regd.c

[Karthik Nishanth]

Do I submit a new patch with the modified subject?

On Sat, Sep 22, 2018 at 03:44:32PM +0300, Dan Carpenter wrote:
>The subject needs a subsystem prefix.  It's also slightly long.
>
>[PATCH] Staging: rtlwifi: remove unnecessary NULL check
>
>regards,
>dan carpenter
>


Karthik Nishanth

Re: [PATCH] iio: adc: Fix potential integer overflow

[Jonathan Cameron]

On Tue, 18 Sep 2018 07:53:14 -0500
"Gustavo A. R. Silva"  wrote:

> Cast factor to s64 in order to give the compiler complete information
> about the proper arithmetic to use and avoid a potential integer
> overflow. Notice that such variable is being used in a context
> that expects an expression of type s64 (64 bits, signed).
> 
> Addresses-Coverity-ID: 1324146 ("Unintentional integer overflow")
> Fixes: e13d757279bb ("iio: adc: Add QCOM SPMI PMIC5 ADC driver")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/iio/adc/qcom-vadc-common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/qcom-vadc-common.c 
> b/drivers/iio/adc/qcom-vadc-common.c
> index dcd7fb5..e360e27 100644
> --- a/drivers/iio/adc/qcom-vadc-common.c
> +++ b/drivers/iio/adc/qcom-vadc-common.c
> @@ -282,7 +282,7 @@ static int qcom_vadc_scale_code_voltage_factor(u16 
> adc_code,
>   voltage = div64_s64(voltage, data->full_scale_code_volt);
>   if (voltage > 0) {
>   voltage *= prescale->den;
> - temp = prescale->num * factor;
> + temp = prescale->num * (s64)factor;
So factor is an unsigned int so could be 32 bits.  In reality it only
takes a small set of values between 1 and 1000

Maximum numerator is 10 so a maximum of 10,000.

Hence this is a false positive, be it one that would be very hard
for a static checker to identify.

So that moves it from a fix to a warning suppression change.
I have no problem with those, but description needs to reflect that.

Let me know if I've missed something, if not I'm happy to apply
this and will put some text in the message to explain the above
reasoning.

Thanks,

Jonathan

>   voltage = div64_s64(voltage, temp);
>   } else {
>   voltage = 0;

Re: [PATCH 2/3] mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver

[Miquel Raynal]

Hi Christophe,

I suppose you received the kbuildrobot issues already, please have a
look at them.

The driver looks well, some comments below.

 wrote on Mon, 17 Sep 2018 17:47:39 +0200:

> From: Christophe Kerello 
> 
> The driver adds the support for the STMicroelectronics FMC2 NAND
> Controller found on STM32MP SOCs.
> 
> This patch is based on FMC2 command sequencer.
> The purpose of the command sequencer is to facilitate the programming
> and the reading of NAND flash pages with the ECC and to free the CPU
> of sequencing tasks.
> It requires one DMA channel for write and two DMA channels for read
> operations.
> 
> Only NAND_ECC_HW mode is actually supported.
> The driver supports a maximum 8k page size.
> The following ECC strength and step size are currently supported:
>  - nand-ecc-strength = <8>, nand-ecc-step-size = <512> (BCH8)
>  - nand-ecc-strength = <4>, nand-ecc-step-size = <512> (BCH4)
>  - nand-ecc-strength = <1>, nand-ecc-step-size = <512> (Extended ecc
>based on HAMMING)
> 
> This patch has been tested on Micron MT29F8G08ABACAH4 and
> MT29F8G16ABACAH4
> 
> Signed-off-by: Christophe Kerello 
> ---
>  drivers/mtd/nand/raw/Kconfig   |9 +
>  drivers/mtd/nand/raw/Makefile  |1 +
>  drivers/mtd/nand/raw/stm32_fmc2_nand.c | 1729 
> 
>  3 files changed, 1739 insertions(+)
>  create mode 100644 drivers/mtd/nand/raw/stm32_fmc2_nand.c
> 
> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> index c7efc31..863662c 100644
> --- a/drivers/mtd/nand/raw/Kconfig
> +++ b/drivers/mtd/nand/raw/Kconfig
> @@ -541,4 +541,13 @@ config MTD_NAND_TEGRA
> is supported. Extra OOB bytes when using HW ECC are currently
> not supported.
>  
> +config MTD_NAND_STM32_FMC2
> + tristate "Support for NAND controller on STM32MP SoCs"
> + depends on MACH_STM32MP157 || COMPILE_TEST
> + help
> +   Enables support for NAND Flash chips on SoCs containing the FMC2
> +   NAND controller. This controller is found on STM32MP SoCs.
> +   The driver supports a maximum 8k page size. HW ECC is enabled and
> +   supports a maximum 8-bit correction error per sector of 512 bytes.

HW ECC should not be enabled by default. 8-bit/512B of correctability
is good but not that high and people might want to use software ECC in
conjunction with raw accesses.

> +
>  endif # MTD_NAND
> diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
> index a6ef067..8c437e3 100644
> --- a/drivers/mtd/nand/raw/Makefile
> +++ b/drivers/mtd/nand/raw/Makefile
> @@ -56,6 +56,7 @@ obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand/
>  obj-$(CONFIG_MTD_NAND_QCOM)  += qcom_nandc.o
>  obj-$(CONFIG_MTD_NAND_MTK)   += mtk_ecc.o mtk_nand.o
>  obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o
> +obj-$(CONFIG_MTD_NAND_STM32_FMC2)+= stm32_fmc2_nand.o
>  
>  nand-objs := nand_base.o nand_bbt.o nand_timings.o nand_ids.o
>  nand-objs += nand_amd.o
> diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c 
> b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> new file mode 100644
> index 000..dd5762a
> --- /dev/null
> +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> @@ -0,0 +1,1729 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) STMicroelectronics 2018 - All Rights Reserved
> + * Author: Christophe Kerello  for 
> STMicroelectronics

I'm not sure the "All rights reserved" has a meaning here.

But you definitely not have to add "for STMicroelectronics" because it
is already in the copyright.

> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Bad block marker length */
> +#define FMC2_BBM_LEN 2
> +
> +/* ECC step size */
> +#define FMC2_ECC_STEP_SIZE   512
> +
> +/* BCHDSRx registers length */
> +#define FMC2_BCHDSRS_LEN 20
> +
> +/* HECCR length */
> +#define FMC2_HECCR_LEN   4
> +
> +/* Max requests done for a 8k nand page size */
> +#define FMC2_MAX_SG_COUNT16
> +
> +/* Max chip enable */
> +#define FMC2_MAX_CE  2
> +
> +/* Timings */
> +#define FMC2_THIZ1
> +#define FMC2_TIO 8000
> +#define FMC2_TSYNC   3000
> +#define FMC2_PCR_TIMING_MASK 0xf
> +#define FMC2_PMEM_PATT_TIMING_MASK   0xff
> +
> +/* FMC2 Controller Registers */
> +#define FMC2_BCR10x0
> +#define FMC2_PCR 0x80
> +#define FMC2_SR  0x84
> +#define FMC2_PMEM0x88
> +#define FMC2_PATT0x8c
> +#define FMC2_HECCR   0x94
> +#define FMC2_CSQCR   0x200
> +#define FMC2_CSQCFGR10x204
> +#define FMC2_CSQCFGR20x208
> +#define FMC2_CSQCFGR30x20c
> +#define FMC2_CSQAR1   

Re: [PATCH] Fix clang warning -Wpointer-bool-conversion by removing unnecessary check in regd.c

[Dan Carpenter]

On Sat, Sep 22, 2018 at 01:40:19PM +, Karthik Nishanth wrote:
> Do I submit a new patch with the modified subject?
> 

Yeah.  Put [PATCH v2] in the subject and then at the end of the patch
description put:

Signed-off-by: Your Name 
---
v2: changed the subject.

regards,
dan carpenter

Re: [PATCH v2] i2c: aspeed: fix invalid clock parameters for very large divisors

[Joe Perches]

On Fri, 2018-09-21 at 15:30 -0700, Brendan Higgins wrote:
> On Fri, Sep 21, 2018 at 3:26 PM Jae Hyun Yoo
[]
> > > + dev_err(dev,
> > > + "clamping clock divider: divider requested, %u, is 
> > > greater than largest possible divider, %u.",
> > 
> > Please put a newline character at the end of the string.
> 
> I always forget to do that. I wonder if anyone has considered adding a
> warning for this to checkpatch?

Yes, but it's not possible to know when there
a pr_cont that follows so any checkpatch test
would be a false positive generator too.

Re: [PATCH] kernel/kcov: Replace vm_insert_page with vmf_insert_page

[Matthew Wilcox]

On Fri, Sep 21, 2018 at 12:42:54AM +0530, Souptick Joarder wrote:
>   for (off = 0; off < size; off += PAGE_SIZE) {
>   page = vmalloc_to_page(kcov->area + off);
> - if (vm_insert_page(vma, vma->vm_start + off, page))
> - WARN_ONCE(1, "vm_insert_page() failed");
> + if (vmf_insert_page(vma, vma->vm_start + off, page)
> + != VM_FAULT_NOPAGE)
> + WARN_ONCE(1, "vmf_insert_page() failed");
>   }

I think this is the wrong approach (as well as being buggy).

We should have a vmalloc_insert_range() _or something similar_ that
replaces this entire loop.  That makes each _user_ simpler.  What you're
trying to do right now makes each user more complex, and that's the
wrong approach.

[PATCH v2] Staging: rtlwifi: remove unnecessary NULL check

[Karthik Nishanth]

The member regd of the struct rtl_priv is true in a boolean context.

drivers/staging/rtlwifi/regd.c:413:27: warning: address of 'rtlpriv->regd' will 
always
  evaluate to 'true' [-Wpointer-bool-conversion]
if (!wiphy || !&rtlpriv->regd)
  ~ ~^~~~
1 warning generated.

Link: https://github.com/ClangBuiltLinux/linux/issues/170

Signed-off-by: Karthik Nishanth 
---
v2: changed the subject

 drivers/staging/rtlwifi/regd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtlwifi/regd.c b/drivers/staging/rtlwifi/regd.c
index 3afd206ce4b1..5213ca771175 100644
--- a/drivers/staging/rtlwifi/regd.c
+++ b/drivers/staging/rtlwifi/regd.c
@@ -410,7 +410,7 @@ int rtl_regd_init(struct ieee80211_hw *hw,
struct wiphy *wiphy = hw->wiphy;
struct country_code_to_enum_rd *country = NULL;
 
-   if (!wiphy || !&rtlpriv->regd)
+   if (!wiphy)
return -EINVAL;
 
/* init country_code from efuse channel plan */
-- 
2.19.0

Re: [PATCH v6 0/3] Harden spectrev2 userspace-userspace protection

[Peter Zijlstra]

On Sat, Sep 22, 2018 at 03:30:07PM +0200, Thomas Gleixner wrote:
> On Sat, 22 Sep 2018, Thomas Gleixner wrote:
> > On Sat, 22 Sep 2018, Peter Zijlstra wrote:
> > > This has some unfortunate duplication.
> > > 
> > > Lets go with it for now, but I'll see if I can do something about that
> > > later.
> > 
> > Yes, I know. I tried to make the duplication smaller, but all attempts
> > ended up being a convoluted mess. I'll try again after applying more
> > coffee.
> 
> Lunch and coffee indeed made brain work better. The simple solution was way
> too obvious.
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -261,6 +261,9 @@ static int ptrace_check_attach(struct ta
>  
>  static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
>  {
> + if (mode & PTRACE_MODE_SCHED)
> + return false;
> +
>   if (mode & PTRACE_MODE_NOAUDIT)
>   return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE);
>   else
> @@ -328,9 +331,16 @@ static int __ptrace_may_access(struct ta
>!ptrace_has_cap(mm->user_ns, mode)))
>   return -EPERM;
>  
> + if (mode & PTRACE_MODE_SCHED)
> + return 0;
>   return security_ptrace_access_check(task, mode);
>  }
>  
> +bool ptrace_may_access_sched(struct task_struct *task, unsigned int mode)
> +{
> + return __ptrace_may_access(task, mode | PTRACE_MODE_SCHED);
> +}

Ha!, much nicer. Thanks!

Re: [PATCH v2] Staging: rtlwifi: remove unnecessary NULL check

[Dan Carpenter]

Thanks!

Reviewed-by: Dan Carpenter 

regards,
dan carpenter

Re: [PATCH v6 1/2] iio: proximity: Add driver support for ST's VL53L0X ToF ranging sensor.

[Jonathan Cameron]

On Tue, 18 Sep 2018 16:24:21 +0800
Song Qiang  wrote:

> This driver was originally written by ST in 2016 as a misc input device
> driver, and hasn't been maintained for a long time. I grabbed some code
> from it's API and reformed it into an iio proximity device driver.
> This version of driver uses i2c bus to talk to the sensor and
> polling for measuring completes, so no irq line is needed.
> It can be tested with reading from
> /sys/bus/iio/devices/iio:deviceX/in_distance_input
> 
> Signed-off-by: Song Qiang 
There are a few bits and bobs in here, but as they are all minor and
one at least was me giving you wrong advise, I've fixed it up.

Please check I haven't made a mess of it! 

Applied with changes to the togreg branch of iio.git and pushed out
as testing (where it should be visible now) for the autobuilders to
play with it.

Thanks,

Jonathan
> ---
> Changes in v6:
>   - Remove '.' in mail address. Google doesn't care, these two
> email address is the same when I log in.
>   - Clean register table.
>   - Put some seperated statements into one line.
>   - Change channel type to *_PROCESSED.
>   - Remove some unneccessary dev_err.
>   - changes iio device name to vl53l0x.
> 
> Changes in v5:
>   - Correct some spell problems.
>   - Change tries-- to --tries to fix the count error.
>   - Add MODULE_DEVICE_TABLE().
>   - Add some comments.
> 
> Changes in v4:
>   - Add datasheet link, default i2c address and TODO list.
>   - Make capitalization of defines consistent.
>   - Replace i2c_transfer() with i2c_smbus_read_i2c_block_data().
>   - Remove IIO_CHAN_SOFT_TIMESTAMP() since no buffer/trigger
> support.
>   - Add information to MAINTAINERS.
> 
> Changes in v3:
>   - Recover ST's copyright.
>   - Clean up indio_dev member in vl53l0x_data struct since it's
> useless now.
>   - Replace __le16_to_cpu() with le16_to_cpu().
>   - Remove the iio_device_{claim|release}_direct_mode() since it's
> only needed when we use buffered mode.
>   - Clean up some coding style problems.
> 
> Changes in v2:
>   - Clean up the register table.
>   - Sort header files declarations.
>   - Replace some bit definations with GENMASK() and BIT().
>   - Clean up some code and comments that's useless for now.
>   - Change the order of some the definations of some variables to reversed
> xmas tree order.
>   - Using do...while() rather while and check.
>   - Replace pr_err() with dev_err().
>   - Remove device id declaration since we recommend to use DT.
>   - Remove .owner = THIS_MODULE.
>   - Replace probe() with probe_new() hook.
>   - Remove IIO_BUFFER and IIO_TRIGGERED_BUFFER dependences.
>   - Change the driver module name to vl53l0x-i2c.
>   - Align all the parameters if they are in the same function with open
> parentheses.
>   - Replace iio_device_register() with devm_iio_device_register
> for better resource management.
>   - Remove the vl53l0x_remove() since it's not needed.
>   - Remove dev_set_drvdata() since it's already setted above.
> 
>  .../bindings/iio/proximity/vl53l0x.txt|  12 ++
>  MAINTAINERS   |   7 +
>  drivers/iio/proximity/Kconfig |  11 ++
>  drivers/iio/proximity/Makefile|   2 +
>  drivers/iio/proximity/vl53l0x-i2c.c   | 157 ++
>  5 files changed, 189 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
>  create mode 100644 drivers/iio/proximity/vl53l0x-i2c.c
> 
> diff --git a/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt 
> b/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
> new file mode 100644
> index ..ab9a9539fec4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
> @@ -0,0 +1,12 @@
> +ST VL53L0X ToF ranging sensor
> +
> +Required properties:
> + - compatible: must be "st,vl53l0x-i2c"
> + - reg: i2c address where to find the device
> +
> +Example:
> +
> +vl53l0x@29 {
> + compatible = "st,vl53l0x-i2c";
> + reg = <0x29>;
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 967ce8cdd1cc..349e2bc97cec 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13510,6 +13510,13 @@ L:   linux-...@vger.kernel.org
>  S:   Maintained
>  F:   drivers/i2c/busses/i2c-stm32*
>  
> +ST VL53L0X ToF RANGER(I2C) IIO DRIVER
> +M:   Song Qiang 
> +L:   linux-...@vger.kernel.org
> +S:   Maintained
> +F:   drivers/iio/proximity/vl53l0x-i2c.c
> +F:   Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
> +
>  STABLE BRANCH
>  M:   Greg Kroah-Hartman 
>  L:   sta...@vger.kernel.org
> diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
> index f726f9427602..5f421cbd37f3 100644
> --- a/drivers/iio/proximity/Kconfig
> +++ b/drivers/iio/proximity/Kconfig
> @@ -79,4 +79,15 @@ 

[PATCH v2 1/2] mm/page_alloc: Fix panic caused by passing debug_guardpage_minorder or kernelcore to command line

[zhe.he]

From: He Zhe 

debug_guardpage_minorder_setup and cmdline_parse_kernelcore do not check
input argument before using it. The argument would be a NULL pointer if
"debug_guardpage_minorder" or "kernelcore", without its value, is set in
command line and thus causes the following panic.

PANIC: early exception 0xe3 IP 10:a08146f1 error 0 cr2 0x0
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
4.19.0-rc4-yocto-standard+ #11
[0.00] RIP: 0010:parse_option_str+0x11/0x90
...
[0.00] Call Trace:
[0.00]  cmdline_parse_kernelcore+0x19/0x41
[0.00]  do_early_param+0x57/0x8e
[0.00]  parse_args+0x208/0x320
[0.00]  ? rdinit_setup+0x30/0x30
[0.00]  parse_early_options+0x29/0x2d
[0.00]  ? rdinit_setup+0x30/0x30
[0.00]  parse_early_param+0x36/0x4d
[0.00]  setup_arch+0x336/0x99e
[0.00]  start_kernel+0x6f/0x4ee
[0.00]  x86_64_start_reservations+0x24/0x26
[0.00]  x86_64_start_kernel+0x6f/0x72
[0.00]  secondary_startup_64+0xa4/0xb0

This patch adds a check to prevent the panic and adds KBUILD_MODNAME to
prints.

Signed-off-by: He Zhe 
Cc: sta...@vger.kernel.org
Cc: a...@linux-foundation.org
Cc: mho...@suse.com
Cc: vba...@suse.cz
Cc: pasha.tatas...@oracle.com
Cc: mgor...@techsingularity.net
Cc: aaron...@intel.com
Cc: osalva...@suse.de
Cc: iamjoonsoo@lge.com
---
v2:
Use more clear error info
Split the addition of KBUILD_MODNAME out

 mm/page_alloc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 89d2a2a..f34cae1 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -630,6 +630,12 @@ static int __init debug_guardpage_minorder_setup(char *buf)
 {
unsigned long res;
 
+   if (!buf) {
+   pr_err("kernel option debug_guardpage_minorder requires an \
+   argument\n");
+   return -EINVAL;
+   }
+
if (kstrtoul(buf, 10, &res) < 0 ||  res > MAX_ORDER / 2) {
pr_err("Bad debug_guardpage_minorder value\n");
return 0;
@@ -6952,6 +6958,11 @@ static int __init cmdline_parse_core(char *p, unsigned 
long *core,
  */
 static int __init cmdline_parse_kernelcore(char *p)
 {
+   if (!p) {
+   pr_err("kernel option kernelcore requires an argument\n");
+   return -EINVAL;
+   }
+
/* parse kernelcore=mirror */
if (parse_option_str(p, "mirror")) {
mirrored_kernelcore = true;
-- 
2.7.4

[PATCH v2 2/2] mm/page_alloc: Add KBUILD_MODNAME

[zhe.he]

From: He Zhe 

Add KBUILD_MODNAME to make prints more clear.

Signed-off-by: He Zhe 
Cc: a...@linux-foundation.org
Cc: mho...@suse.com
Cc: vba...@suse.cz
Cc: pasha.tatas...@oracle.com
Cc: mgor...@techsingularity.net
Cc: aaron...@intel.com
Cc: osalva...@suse.de
Cc: iamjoonsoo@lge.com
---
v2:
Split the addition of KBUILD_MODNAME out

 mm/page_alloc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f34cae1..ead9556 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -14,6 +14,8 @@
  *  (lots of bits borrowed from Ingo Molnar & Andrew Morton)
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
-- 
2.7.4

Re: [PATCH] framewarn: expand KASAN_EXTRA exception to KASAN

[Arnd Bergmann]

On Fri, Sep 21, 2018 at 2:45 AM Dmitry Vyukov  wrote:
>
> On Fri, Sep 21, 2018 at 11:25 AM, Andrey Ryabinin
>  wrote:
> > On 09/21/2018 04:50 AM, Andy Lutomirski wrote:
> >> This patch seems reasonable, but you emailed the wrong people :)
> >>
> >> On Thu, Sep 20, 2018 at 5:15 PM Jason A. Donenfeld  wrote:
> >>>
> >>> It turns out that KASAN in general will bloat stack frames in unexpected
> >>> ways, not just KASAN_EXTRA. So, this patch trivially changes that
> >>> default to be associated with KASAN instead of KASAN_EXTRA.
> >>>
> >
> > KASAN_EXTRA bloats stack more than just KASAN, that's why the limit is 
> > higher than just for KASAN.
> > If want more details, tead the changelog from commit 
> > e7c52b84fb18f08ce49b6067ae6285aca79084a8
> >
> > If anything causes "stack frame > 2048" warning for KASAN we should at 
> > least try to fix it,
> > I mean reduce stack usage.
>
>
> +Nick who is also hitting these warnings on clang/arm64 build. As far
> as I understand the situation there is much worse.
>
> I would be good to understand/fix the worst offenders. But the stack
> size increase with KASAN is a real, inherent thing. So if we live very
> close the edge, we can get people using different compilers and/or
> versions of compilers constantly breaking each other. And clang hits
> this warnings in lots of places today just because the current code
> was tailored to gcc over long period, i.e. allowing more locals where
> gcc happened to handle that better and having fewer locals where gcc
> happened to handle it worse. But for another compiler all these
> assumptions are significantly perturbed.
>
> Nick, do you know what frame size limit eliminates the bulk of
> warnings on clang? Is 3072 a reasonable limit allowing to fix the
> remaining outliners?

I do not consider 3072 a reasonable limit at all. For gcc, we managed to fix or
work around all the bugs that caused excessive stack usage. In almost all
cases there was something seriously wrong with code generation. I added
the KASAN_EXTRA option for the one thing that added an inherent significant
overhead to the stack usage.

llvm apparently has a similar bug to what we fixed in gcc. I created a
reduced test case for one of the file at:
https://bugs.llvm.org/show_bug.cgi?id=38809

Unfortunately, nobody has commented on that so far, but in the
meantime I think the best workaround would be to disable asan-stack
entirely when building with clang, and moving it to KASAN_EXTRA
there, like we did with the scope check on gcc.

Arnd

Re: [PATCH v6 1/2] iio: proximity: Add driver support for ST's VL53L0X ToF ranging sensor.

[Himanshu Jha]

On Sat, Sep 22, 2018 at 03:46:58PM +0100, Jonathan Cameron wrote:
> On Tue, 18 Sep 2018 16:24:21 +0800
> Song Qiang  wrote:
> 
> > This driver was originally written by ST in 2016 as a misc input device
> > driver, and hasn't been maintained for a long time. I grabbed some code
> > from it's API and reformed it into an iio proximity device driver.
> > This version of driver uses i2c bus to talk to the sensor and
> > polling for measuring completes, so no irq line is needed.
> > It can be tested with reading from
> > /sys/bus/iio/devices/iio:deviceX/in_distance_input
> > 
> > Signed-off-by: Song Qiang 
> There are a few bits and bobs in here, but as they are all minor and
> one at least was me giving you wrong advise, I've fixed it up.
> 
> Please check I haven't made a mess of it! 
> 
> Applied with changes to the togreg branch of iio.git and pushed out
> as testing (where it should be visible now) for the autobuilders to
> play with it.

The SPDX license identifier is inconsistent!

> +// SPDX-License-Identifier: GPL-2.0+

> +MODULE_LICENSE("GPL v2");

216 For 'GNU General Public License (GPL) version 2 only' use:
217   SPDX-License-Identifier: GPL-2.0
218 For 'GNU General Public License (GPL) version 2 or any later 
version' use:
219   SPDX-License-Identifier: GPL-2.0+


-- 
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology

Re: [PATCH v6 2/2] iio: proximity: vl53l0x: add interrupt support

[Jonathan Cameron]

On Tue, 18 Sep 2018 16:24:22 +0800
Song Qiang  wrote:

> The first version of this driver issues a measuring request and polling
> for a status register in the device for measuring completes.
> vl53l0x support configuring GPIO1 on it to generate interrupt to
> indicate that new measurement is ready. This patch adds support for
> using this mechanisim to reduce cpu cost.
> 
> Signed-off-by: Song Qiang 
Hi Song.

Looks correct in principal but a few things to tidy up before
this is ready to apply.

Also we have an unrelated change in here to check the devices ID.
That should be in it's own patch.

Thanks,

Jonathan
> ---
>  .../bindings/iio/proximity/vl53l0x.txt|  14 +-
>  drivers/iio/proximity/vl53l0x-i2c.c   | 135 +++---
>  2 files changed, 129 insertions(+), 20 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt 
> b/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
> index ab9a9539fec4..40290f8dd70f 100644
> --- a/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
> +++ b/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
> @@ -4,9 +4,21 @@ Required properties:
>   - compatible: must be "st,vl53l0x-i2c"
>   - reg: i2c address where to find the device
>  
> +Optional properties:
> + - interrupts : Interrupt line receiving GPIO1's measuring complete
> +   output, supports IRQ_TYPE_EDGE_FALLING only.
> +
> + Refer to interrupt-controller/interrupts.txt for generic
> + interrupt client node bindings.
> +
>  Example:
>  
>  vl53l0x@29 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&vl53l0x_pins>;
> +
Please drop this from the example.  This is board specific rather than
being generally required.

>   compatible = "st,vl53l0x-i2c";
>   reg = <0x29>;
> -};
> + interrupt-parent = <&gpio3>;
> + interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
> +}
> diff --git a/drivers/iio/proximity/vl53l0x-i2c.c 
> b/drivers/iio/proximity/vl53l0x-i2c.c
> index 1aad45df8d95..a5cff11f41de 100644
> --- a/drivers/iio/proximity/vl53l0x-i2c.c
> +++ b/drivers/iio/proximity/vl53l0x-i2c.c
> @@ -10,18 +10,21 @@
>   *
>   * Default 7-bit i2c slave address 0x29.
>   *
> - * TODO: FIFO buffer, continuous mode, interrupts, range selection,
> - * sensor ID check.
> + * TODO: FIFO buffer, continuous mode, range selection.
>   */
>  
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> +#include 
> +
>  #define VL_REG_SYSRANGE_START0x00
>  
> +/* Mode configuration registers. */
>  #define VL_REG_SYSRANGE_MODE_MASKGENMASK(3, 0)
>  #define VL_REG_SYSRANGE_MODE_SINGLESHOT  0x00
>  #define VL_REG_SYSRANGE_MODE_START_STOP  BIT(0)
> @@ -29,14 +32,61 @@
>  #define VL_REG_SYSRANGE_MODE_TIMED   BIT(2)
>  #define VL_REG_SYSRANGE_MODE_HISTOGRAM   BIT(3)
>  
> +/* Result registers. */
>  #define VL_REG_RESULT_INT_STATUS 0x13
>  #define VL_REG_RESULT_RANGE_STATUS   0x14
>  #define VL_REG_RESULT_RANGE_STATUS_COMPLETE  BIT(0)
>  
> +/* GPIO function configuration registers. */
> +#define VL_REG_GPIO_HV_MUX_ACTIVE_GIGH   0x84
> +#define VL_REG_SYS_INT_CFG_GPIO  0x0A
> +#define VL_GPIOFUNC_NEW_MEASURE_RDY  BIT(2)
> +
> +/* Interrupt configuration registers. */
> +#define VL_REG_SYS_INT_CLEAR 0x0B
> +#define VL_REG_RESULT_INT_STATUS 0x13
> +#define VL_INT_POLARITY_LOW  0x00
> +#define VL_INT_POLARITY_HIGH BIT(0)
> +
> +/* Should be 0xEE if connection is fine. */
> +#define VL_REG_MODEL_ID  0xC0
> +
>  struct vl53l0x_data {
>   struct i2c_client *client;
> + struct completion measuring_done;
> + bool use_interrupt;
>  };
>  
> +static int vl53l0x_clear_interrupt(struct vl53l0x_data *data)
> +{
> + int ret;
> + u8 cnt = 0;
> +
> + do {
> + /* bit 0 for measuring interrupt, bit 1 for error interrupt.  */
> + i2c_smbus_write_byte_data(data->client,
> + VL_REG_SYS_INT_CLEAR, 1);

All these i2c comms need checking for errors.  I2c buses aren't always the most
reliable things.

> + i2c_smbus_write_byte_data(data->client,
> + VL_REG_SYS_INT_CLEAR, 0);
> + ret = i2c_smbus_read_byte_data(data->client,
> + VL_REG_RESULT_INT_STATUS);
> + cnt++;
> + } while ((ret & 0x07) && (cnt < 3));
> + if (cnt > 2)
> + return -ETIMEDOUT;
> + else
> + return 0;
> +}
> +
> +static irqreturn_t vl53l0x_irq_handler(int irq, void *d)
> +{
> + struct vl53l0x_data *data = d;
> +
> + complete(&data->measuring_done);
> +
> + return IRQ_HANDLED;
> +}
> +
>  static int vl53l0x_read_proximity(stru

Re: [PATCH v6 1/2] iio: proximity: Add driver support for ST's VL53L0X ToF ranging sensor.

[Jonathan Cameron]

On Sat, 22 Sep 2018 20:26:58 +0530
Himanshu Jha  wrote:

> On Sat, Sep 22, 2018 at 03:46:58PM +0100, Jonathan Cameron wrote:
> > On Tue, 18 Sep 2018 16:24:21 +0800
> > Song Qiang  wrote:
> >   
> > > This driver was originally written by ST in 2016 as a misc input device
> > > driver, and hasn't been maintained for a long time. I grabbed some code
> > > from it's API and reformed it into an iio proximity device driver.
> > > This version of driver uses i2c bus to talk to the sensor and
> > > polling for measuring completes, so no irq line is needed.
> > > It can be tested with reading from
> > > /sys/bus/iio/devices/iio:deviceX/in_distance_input
> > > 
> > > Signed-off-by: Song Qiang   
> > There are a few bits and bobs in here, but as they are all minor and
> > one at least was me giving you wrong advise, I've fixed it up.
> > 
> > Please check I haven't made a mess of it! 
> > 
> > Applied with changes to the togreg branch of iio.git and pushed out
> > as testing (where it should be visible now) for the autobuilders to
> > play with it.  
> 
> The SPDX license identifier is inconsistent!
> 
> > +// SPDX-License-Identifier: GPL-2.0+  
> 
> > +MODULE_LICENSE("GPL v2");  
> 
> 216 For 'GNU General Public License (GPL) version 2 only' use:
> 217   SPDX-License-Identifier: GPL-2.0
> 218 For 'GNU General Public License (GPL) version 2 or any later 
> version' use:
> 219   SPDX-License-Identifier: GPL-2.0+
> 
> 
Good spot.

I'll fix that up as well.

I'll assume the MODULE_LICENCE is right for now as it seems likely to have come
from the original ST code.

Jonathan

Re: [PATCH 2/2] iio: light: bh1750: Add device tree support

[Jonathan Cameron]

On Fri, 21 Sep 2018 17:34:21 +0200
Tomasz Duszynski  wrote:

> On Thu, Sep 20, 2018 at 09:37:21PM -0400, r yang wrote:
> > On Wed, Sep 19, 2018 at 09:22:39PM +0200, Tomasz Duszynski wrote:  
> > > Comments inline.
> > >
> > > On Sat, Sep 15, 2018 at 01:42:14PM -0400, ryang wrote:  
> > > > Add device tree support for ROHM BH1750 series ambient light sensors.
> > > >
> > > > Signed-off-by: ryang 
> > > > ---
> > > >  drivers/iio/light/bh1750.c | 10 ++
> > > >  1 file changed, 10 insertions(+)
> > > >
> > > > diff --git a/drivers/iio/light/bh1750.c b/drivers/iio/light/bh1750.c
> > > > index a814828e69f5..50b599abb383 100644
> > > > --- a/drivers/iio/light/bh1750.c
> > > > +++ b/drivers/iio/light/bh1750.c
> > > > @@ -315,9 +315,19 @@ static const struct i2c_device_id bh1750_id[] = {
> > > >  };
> > > >  MODULE_DEVICE_TABLE(i2c, bh1750_id);
> > > >
> > > > +static const struct of_device_id bh1750_of_match[] = {
> > > > +   { .compatible = "rohm,bh1710", },
> > > > +   { .compatible = "rohm,bh1715", },
> > > > +   { .compatible = "rohm,bh1721", },
> > > > +   { .compatible = "rohm,bh1750", },
> > > > +   { .compatible = "rohm,bh1751", },
> > > > +   { }
> > > > +};
> > > > +  
> > >
> > > Hmm, I believe this should be exported additionally using
> > > MODULE_DEVICE_TABLE(of, bh1750_of_match). Otherwise module loading
> > > will not work as expected.
> > >
> > > Moreover, we can do without DT and if you want to avoid
> > > warning about unused variables you may consider enclosing everything
> > > with:
> > >
> > > #ifdef CONFIG_OF
> > > ...
> > > #endif  

Don't do that.  There is a significant oddity now around this in that
it is possible to use a magic ACPI device ID to probe via a devicetree
binding (without CONFIG_OF).  It's seriously odd, but to allow that to
work we need to not protect things with #ifdef CONFIG_OF.

(and this particular bit of fun strikes me as crazy too, but it's what
we have!)

https://www.kernel.org/doc/Documentation/acpi/enumeration.txt
(towards the bottom)

Having MODULE_DEVICE_TABLE is a good addition.

> >
> > The reason for this DT patch is because I've ported the Samsung Galaxy
> > Tab 10.1 to the mainline kernel. The device is working on the Tegra
> > platform with the right DTS file. Some peripherals on this device have
> > existing drivers such as this one which only need the DT bindings for
> > it be usuable.
> >  
> 
> Adding support for DT is fine. Just pointed a figner at two things
> that attracted my attention.
> 
> > >  
> > > >  static struct i2c_driver bh1750_driver = {
> > > > .driver = {
> > > > .name = "bh1750",
> > > > +   .of_match_table = of_match_ptr(bh1750_of_match),
> > > > .pm = BH1750_PM_OPS,  
> > >
> > > I've recently simplified setting pm ops so this would not apply to
> > > iio/togreg cleanly.
> > >  
> >
> > Does this mean I should wait until that is merged before submitting a V2
> > patch?
> >  
> 
> No need to wait. I guess you should rebase your work on iio/togreg
> branch and post v2.

That would be perfect as you are rerolling anyway. Let's me be lazy
and not do the merge ;)

Thanks,

Jonathan

> 
> > > > },
> > > > .probe = bh1750_probe,
> > > > --
> > > > 2.17.1
> > > >  

Re: [PATCH 2/2] iio: light: bh1750: Add device tree support

[Jonathan Cameron]

On Mon, 17 Sep 2018 21:57:33 -0400
r yang  wrote:

> On Sun, Sep 16, 2018 at 10:45:26AM +0100, Jonathan Cameron wrote:
> > On Sat, 15 Sep 2018 13:42:14 -0400
> > ryang  wrote:
> >   
> > > Add device tree support for ROHM BH1750 series ambient light sensors.
> > > 
> > > Signed-off-by: ryang   
> > Just to check, how is it picking up on the enum value which is provided
> > in the i2c_device_id entries?
> > 
> > i.e. What is setting id->driver_data in the probe?
> > There may be something in the i2c core that I'm missing that will do the
> > association but I don't remember anything trying to do this.
> > 
> > Jonathan
> >  
> 
> I've looked through it and it is indeed in the i2c core.
> The i2c core probe function picks the id entry based on the i2c client
> name.
> 
> The i2c client name is assigned based on the device tree compatible
> string.
> 
>   of_i2c_register_device()
> of_i2c_get_board_info()
>   of_modalias_node()
> 
> During probe the i2c_device_id is picked by matching the i2c
> client->name to i2c_device_id->name in the i2c_match_id() function.
> 
>   i2c_device_probe()
> driver->probe(client, i2c_match_id(driver->id_table, client));
> 
Great!  Thanks for tracking that down.  I'll pick this up once
you've added the MODULE_DEVICE_TABLE as Tomasz suggested.


> I've tested this on device. It's Samsung Galaxy Tab 10.1. It has a
> BH1721.
> 
> > > ---
> > >  drivers/iio/light/bh1750.c | 10 ++
> > >  1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/drivers/iio/light/bh1750.c b/drivers/iio/light/bh1750.c
> > > index a814828e69f5..50b599abb383 100644
> > > --- a/drivers/iio/light/bh1750.c
> > > +++ b/drivers/iio/light/bh1750.c
> > > @@ -315,9 +315,19 @@ static const struct i2c_device_id bh1750_id[] = {
> > >  };
> > >  MODULE_DEVICE_TABLE(i2c, bh1750_id);
> > >  
> > > +static const struct of_device_id bh1750_of_match[] = {
> > > + { .compatible = "rohm,bh1710", },
> > > + { .compatible = "rohm,bh1715", },
> > > + { .compatible = "rohm,bh1721", },
> > > + { .compatible = "rohm,bh1750", },
> > > + { .compatible = "rohm,bh1751", },
> > > + { }
> > > +};
> > > +
> > >  static struct i2c_driver bh1750_driver = {
> > >   .driver = {
> > >   .name = "bh1750",
> > > + .of_match_table = of_match_ptr(bh1750_of_match),
> > >   .pm = BH1750_PM_OPS,
> > >   },
> > >   .probe = bh1750_probe,  
> >   

Re: [PATCH v5] iio: proximity: Add driver support for ST's VL53L0X ToF ranging sensor.

[Jonathan Cameron]

...
> > 
> >  .../bindings/iio/proximity/vl53l0x.txt|  12 ++
> >  MAINTAINERS   |   7 +  
> 
> Otherwise,
> 
> Reviewed-by: Rob Herring 
Hi Song,

Please make sure to pick up the various Acks, Reviewed-bys etc for later 
versions.

I've added this to the version I applied.

Thanks,

Jonathan
> 
> >  drivers/iio/proximity/Kconfig |  11 ++
> >  drivers/iio/proximity/Makefile|   2 +
> >  drivers/iio/proximity/vl53l0x-i2c.c   | 180 ++
> >  5 files changed, 212 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
> >  create mode 100644 drivers/iio/proximity/vl53l0x-i2c.c  

Re: [PATCH v6 1/2] iio: proximity: Add driver support for ST's VL53L0X ToF ranging sensor.

[Song Qiang]

On Sat, Sep 22, 2018 at 03:46:58PM +0100, Jonathan Cameron wrote:
> On Tue, 18 Sep 2018 16:24:21 +0800
> Song Qiang  wrote:
> 
> > This driver was originally written by ST in 2016 as a misc input device
> > driver, and hasn't been maintained for a long time. I grabbed some code
> > from it's API and reformed it into an iio proximity device driver.
> > This version of driver uses i2c bus to talk to the sensor and
> > polling for measuring completes, so no irq line is needed.
> > It can be tested with reading from
> > /sys/bus/iio/devices/iio:deviceX/in_distance_input
> > 
> > Signed-off-by: Song Qiang 
> There are a few bits and bobs in here, but as they are all minor and
> one at least was me giving you wrong advise, I've fixed it up.
> 
> Please check I haven't made a mess of it! 
> 
> Applied with changes to the togreg branch of iio.git and pushed out
> as testing (where it should be visible now) for the autobuilders to
> play with it.
> 
> Thanks,
> 
> Jonathan
> > ---

> > +   indio_dev->name = "vl53l0x";
> > +   indio_dev->info = &vl53l0x_info;
> > +   indio_dev->channels = vl53l0x_channels;
> > +   indio_dev->num_channels = ARRAY_SIZE(vl53l0x_channels);
> > +   indio_dev->modes = INDIO_DIRECT_MODE;
> > +
> > +   return devm_iio_device_register(&client->dev, indio_dev);
> > +}
> > +
> > +static const struct of_device_id st_vl53l0x_dt_match[] = {
> > +   { .compatible = "st,vl53l0x-i2c", },
> 
> Ah, this suffers from the same thing that was picked up in a driver
> you sent later in the week.  No need to have -i2c in the compatible
> as this is clear from the bus type.
> 
> (I might just fix this up).
> 

Hi Jonathan,

Sorry for the newbie mistakes you and Himanshu pointed out, I'm just
writing them down on my little checklist!
I just checked the code, found that this compatible string was not
getting corrected in the DT binding doc file, sorry that you have
to help correct my mistakes, thanks a lot!

yours,
Song Qiang

> > +   { }
> > +};
> > +MODULE_DEVICE_TABLE(of, st_vl53l0x_dt_match);
> > +
> > +static struct i2c_driver vl53l0x_driver = {
> > +   .driver = {
> > +   .name = "vl53l0x-i2c",
> > +   .of_match_table = st_vl53l0x_dt_match,
> > +   },
> > +   .probe_new = vl53l0x_probe,
> > +};
> > +module_i2c_driver(vl53l0x_driver);
> > +
> > +MODULE_AUTHOR("Song Qiang ");
> > +MODULE_DESCRIPTION("ST vl53l0x ToF ranging sensor driver");
> > +MODULE_LICENSE("GPL v2");
> 

Re: [PATCH v4 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller

[Martin Blumenstingl]

Hello,

On Thu, Sep 20, 2018 at 10:51 AM Jianxin Pan  wrote:
[snip]
> +static int meson_nfc_clk_init(struct meson_nfc *nfc)
> +{
> +   int ret;
> +
> +   /* request core clock */
> +   nfc->core_clk = devm_clk_get(nfc->dev, "core");
> +   if (IS_ERR(nfc->core_clk)) {
> +   dev_err(nfc->dev, "failed to get core clk\n");
> +   return PTR_ERR(nfc->core_clk);
> +   }
> +
> +   nfc->device_clk = devm_clk_get(nfc->dev, "device");
> +   if (IS_ERR(nfc->device_clk)) {
> +   dev_err(nfc->dev, "failed to get device clk\n");
> +   return PTR_ERR(nfc->device_clk);
> +   }
> +
> +   nfc->phase_tx = devm_clk_get(nfc->dev, "tx");
> +   if (IS_ERR(nfc->phase_tx)) {
> +   dev_err(nfc->dev, "failed to get tx clk\n");
> +   return PTR_ERR(nfc->phase_tx);
> +   }
> +
> +   nfc->phase_rx = devm_clk_get(nfc->dev, "rx");
> +   if (IS_ERR(nfc->phase_rx)) {
> +   dev_err(nfc->dev, "failed to get rx clk\n");
> +   return PTR_ERR(nfc->phase_rx);
> +   }
neither the "rx" nor the "tx" clock are documented in the dt-bindings patch

> +   /* init SD_EMMC_CLOCK to sane defaults w/min clock rate */
> +   regmap_update_bits(nfc->reg_clk, 0,
> +  CLK_SELECT_NAND | CLK_ALWAYS_ON | CLK_DIV_MASK,
> +  CLK_SELECT_NAND | CLK_ALWAYS_ON | CLK_DIV_MASK);
clk_set_rate also works for clocks that are not enabled yet (except if
they have the flag CLK_SET_RATE_UNGATE)
this should help you to remove CLK_DIV_MASK here

is CLK_SELECT_NAND a bit that switches the clock output from the sdmmc
controller to the NAND controller?
if so: can this be modeled as a mux clock?

the public S905 datasheet doesn't mention CLK_ALWAYS_ON at bit 28 but
uses bit 24 instead. the description from the datasheet:
Cfg_always_on:
1: Keep clock always on
0: Clock on/off controlled by activities.
Any APB3 access or descriptor execution will turn clock on.
Recommended value: 0

can you please explain what CLK_ALWAYS_ON does and why it has to be 1?


Regards
Martin

Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line

[He Zhe]

On 2018年09月21日 15:37, Petr Mladek wrote:
> On Thu 2018-09-20 12:30:56, Steven Rostedt wrote:
>> On Fri, 21 Sep 2018 00:16:50 +0800
>> He Zhe  wrote:
>>
>>> On 2018年09月19日 10:43, Steven Rostedt wrote:
 On Wed, 19 Sep 2018 11:39:32 +0900
 Sergey Senozhatsky  wrote:
  
> On (09/19/18 10:27), He Zhe wrote:  
>> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
>>> On (09/19/18 01:17), zhe...@windriver.com wrote:
 @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned 
 size)
  /* save requested log_buf_len since it's too early to process it */
  static int __init log_buf_len_setup(char *str)
  {
 -  unsigned size = memparse(str, &str);
 +  unsigned size;
>>> unsigned int size;
>> This is in v1 but then Steven suggested that it should be split out
>> and only keep the pure fix part here.
> Ah, I see.
>
> Hmm... memparse() returns u64 value. A user *probably* can ask the kernel
> to allocate log_buf larger than 'unsigned int'.
>
> So may be I'd do two fixes here:
>
>  First  - switch to u64 size.
>  Second - check for NULL str.
>
>
> Steven, Petr, what do you think?
>  
 I think I would switch it around. Check for NULL first, and then switch
 to u64. It was always an int, do we need to backport converting it to
 u64 to stable? The NULL check is a definite, the overflow of int
 shouldn't crash anything.  
>> Hi Zhe,
>>
>>> To switch to u64, several variables need to be adjusted to new type to 
>>> aligned
>>> with new_log_buf_len. And currently new_log_buf_len is passed to
>>> memblock_virt_alloc(phys_addr_t, phys_addr_t). So we can't simply define
>>> new_log_buf_len as u64. We need to define it as phys_addr_t tomake it work
>>> well for both 32bit and 64bit arches, since a 32-bit architecture can set
>>> ARCH_PHYS_ADDR_T_64BIT if it needs a 64-bit phys_addr_t.
>> The above explanation verifies more that the NULL pointer check needs
>> to be first, and that the change in size should not be backported to
>> stable because it has a high risk to doing the change as compared to it
>> being a problem for older kernels.
> I agree that the NULL check should go first.
>
> I would personally keep the size as unsigned int. IMHO, a support
> for a log buffer bigger than 4GB is not worth the complexity.

Thank you, Petr, Steven and Sergey. I'll send v3 soon for the NULL check
and cast correction.



For 64 bit log buffer length, the variable changes should be OK. The main
obstacle might be that we need to modify the syscall below to make the
64 bit length returned back to user space. "error" is not long enough.

int do_syslog(int type, char __user *buf, int len, int source)
...
    case SYSLOG_ACTION_SIZE_BUFFER: 
    error = log_buf_len;
    break;
...
    return error;
...

SYSCALL_DEFINE3(syslog, int, type, char __user *, buf, int, len)
{   


    return do_syslog(type, buf, len, SYSLOG_FROM_READER);   

}



Besides, in terms of variable type alignment, there has already been a
similar problematic case in do_syslog as below. i.e. int = u64 - u64. It seems
this needs to be fixed.

int do_syslog(int type, char __user *buf, int len, int source)
...
    case SYSLOG_ACTION_SIZE_UNREAD:
        if (source == SYSLOG_FROM_PROC) {
            error = log_next_seq - syslog_seq;
...



I'd like to fix the above issues. But can I have your opinions about how to
handle the syscall?


Thanks,
Zhe

>
> Best Regards,
> Petr
>

[PATCH v3 1/2] printk: Fix panic caused by passing log_buf_len to command line

[zhe.he]

From: He Zhe 

log_buf_len_setup does not check input argument before passing it to
simple_strtoull. The argument would be a NULL pointer if "log_buf_len",
without its value, is set in command line and thus causes the following
panic.

PANIC: early exception 0xe3 IP 10:aaeacd0d error 0 cr2 0x0
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
4.19.0-rc4-yocto-standard+ #1
[0.00] RIP: 0010:_parse_integer_fixup_radix+0xd/0x70
...
[0.00] Call Trace:
[0.00]  simple_strtoull+0x29/0x70
[0.00]  memparse+0x26/0x90
[0.00]  log_buf_len_setup+0x17/0x22
[0.00]  do_early_param+0x57/0x8e
[0.00]  parse_args+0x208/0x320
[0.00]  ? rdinit_setup+0x30/0x30
[0.00]  parse_early_options+0x29/0x2d
[0.00]  ? rdinit_setup+0x30/0x30
[0.00]  parse_early_param+0x36/0x4d
[0.00]  setup_arch+0x336/0x99e
[0.00]  start_kernel+0x6f/0x4ee
[0.00]  x86_64_start_reservations+0x24/0x26
[0.00]  x86_64_start_kernel+0x6f/0x72
[0.00]  secondary_startup_64+0xa4/0xb0

This patch adds a check to prevent the panic.

Signed-off-by: He Zhe 
Cc: sta...@vger.kernel.org
Cc: pmla...@suse.com
Cc: sergey.senozhat...@gmail.com
Cc: rost...@goodmis.org
---
v2:
Split out the addition of pr_fmt and the unsigned update
v3:
Use more clear error info
Change unsigned to unsigned in to avoid checkpatch.pl warning

 kernel/printk/printk.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 9bf5404..d9821c0 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
 /* save requested log_buf_len since it's too early to process it */
 static int __init log_buf_len_setup(char *str)
 {
-   unsigned size = memparse(str, &str);
+   unsigned int size;
+
+   if (!str) {
+   pr_err("boot command line parameter value not provided\n");
+   return -EINVAL;
+   }
+
+   size = memparse(str, &str);
 
log_buf_len_update(size);
 
-- 
2.7.4

[PATCH v3 2/2] printk: Add KBUILD_MODNAME and correct wrong casting

[zhe.he]

From: He Zhe 

Add KBUILD_MODNAME to make prints more clear and correct wrong casting that
might cut off the normal output.

Signed-off-by: He Zhe 
Cc: pmla...@suse.com
Cc: sergey.senozhat...@gmail.com
Cc: rost...@goodmis.org
---
v2:
Correct one more place
v3:
Correct wrong casting

 kernel/printk/printk.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index d9821c0..6b059a0 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -16,6 +16,8 @@
  * 01Mar01 Andrew Morton
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
@@ -2358,8 +2360,9 @@ void console_unlock(void)
printk_safe_enter_irqsave(flags);
raw_spin_lock(&logbuf_lock);
if (console_seq < log_first_seq) {
-   len = sprintf(text, "** %u printk messages dropped 
**\n",
- (unsigned)(log_first_seq - console_seq));
+   len = sprintf(text,
+ "** %llu printk messages dropped **\n",
+ log_first_seq - console_seq);
 
/* messages are gone, move to first one */
console_seq = log_first_seq;
-- 
2.7.4

Re: [PATCH v6 1/2] iio: proximity: Add driver support for ST's VL53L0X ToF ranging sensor.

[Jonathan Cameron]

On Sat, 22 Sep 2018 23:28:04 +0800
Song Qiang  wrote:

> On Sat, Sep 22, 2018 at 03:46:58PM +0100, Jonathan Cameron wrote:
> > On Tue, 18 Sep 2018 16:24:21 +0800
> > Song Qiang  wrote:
> >   
> > > This driver was originally written by ST in 2016 as a misc input device
> > > driver, and hasn't been maintained for a long time. I grabbed some code
> > > from it's API and reformed it into an iio proximity device driver.
> > > This version of driver uses i2c bus to talk to the sensor and
> > > polling for measuring completes, so no irq line is needed.
> > > It can be tested with reading from
> > > /sys/bus/iio/devices/iio:deviceX/in_distance_input
> > > 
> > > Signed-off-by: Song Qiang   
> > There are a few bits and bobs in here, but as they are all minor and
> > one at least was me giving you wrong advise, I've fixed it up.
> > 
> > Please check I haven't made a mess of it! 
> > 
> > Applied with changes to the togreg branch of iio.git and pushed out
> > as testing (where it should be visible now) for the autobuilders to
> > play with it.
> > 
> > Thanks,
> > 
> > Jonathan  
> > > ---  
> 
> > > + indio_dev->name = "vl53l0x";
> > > + indio_dev->info = &vl53l0x_info;
> > > + indio_dev->channels = vl53l0x_channels;
> > > + indio_dev->num_channels = ARRAY_SIZE(vl53l0x_channels);
> > > + indio_dev->modes = INDIO_DIRECT_MODE;
> > > +
> > > + return devm_iio_device_register(&client->dev, indio_dev);
> > > +}
> > > +
> > > +static const struct of_device_id st_vl53l0x_dt_match[] = {
> > > + { .compatible = "st,vl53l0x-i2c", },  
> > 
> > Ah, this suffers from the same thing that was picked up in a driver
> > you sent later in the week.  No need to have -i2c in the compatible
> > as this is clear from the bus type.
> > 
> > (I might just fix this up).
> >   
> 
> Hi Jonathan,
> 
> Sorry for the newbie mistakes you and Himanshu pointed out, I'm just
> writing them down on my little checklist!
> I just checked the code, found that this compatible string was not
> getting corrected in the DT binding doc file, sorry that you have
> to help correct my mistakes, thanks a lot!
Fixed up (and this was my mistake - we all make them - that's what review
is for!)

Thanks,

Jonathan
> 
> yours,
> Song Qiang
> 
> > > + { }
> > > +};
> > > +MODULE_DEVICE_TABLE(of, st_vl53l0x_dt_match);
> > > +
> > > +static struct i2c_driver vl53l0x_driver = {
> > > + .driver = {
> > > + .name = "vl53l0x-i2c",
> > > + .of_match_table = st_vl53l0x_dt_match,
> > > + },
> > > + .probe_new = vl53l0x_probe,
> > > +};
> > > +module_i2c_driver(vl53l0x_driver);
> > > +
> > > +MODULE_AUTHOR("Song Qiang ");
> > > +MODULE_DESCRIPTION("ST vl53l0x ToF ranging sensor driver");
> > > +MODULE_LICENSE("GPL v2");  
> >   

Re: [PATCH 5/6] fsmount: do not use legacy MS_ flags

[David Howells]

Christian Brauner  wrote:

> mount_setattr(int dfd, const char *path, unsigned int atflags,
>   unsigned int attr_cmd,
> unsigned int attr_values,
> unsigned int attr_mask);

Whilst you can have up to six arguments on a syscall, I seem to remember that
6-arg syscalls require special handlers on some systems due to register count.

David

Re: [PATCH TRIVIAL] Punctuation fixes

[Diego Viola]

On Wed, Sep 12, 2018 at 12:54 AM Diego Viola  wrote:
>
> Signed-off-by: Diego Viola 
> ---
>  CREDITS | 2 +-
>  MAINTAINERS | 2 +-
>  Makefile| 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/CREDITS b/CREDITS
> index 5befd2d71..b82efb36d 100644
> --- a/CREDITS
> +++ b/CREDITS
> @@ -1473,7 +1473,7 @@ W: http://www.linux-ide.org/
>  W: http://www.linuxdiskcert.org/
>  D: Random SMP kernel hacker...
>  D: Uniform Multi-Platform E-IDE driver
> -D: Active-ATA-Chipset maddness..
> +D: Active-ATA-Chipset maddness...
>  D: Ultra DMA 133/100/66/33 w/48-bit Addressing
>  D: ATA-Disconnect, ATA-TCQ
>  D: ATA-Smart Kernel Daemon
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d870cb57c..6567bf245 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -93,7 +93,7 @@ Descriptions of section entries:
>Supported:   Someone is actually paid to look after this.
>Maintained:  Someone actually looks after it.
>Odd Fixes:   It has a maintainer but they don't have time to do
> -   much other than throw the odd patch in. See below..
> +   much other than throw the odd patch in. See below.
>Orphan:  No current maintainer [but maybe you could take the
> role as you write your new code].
>Obsolete:Old code. Something tagged obsolete generally means
> diff --git a/Makefile b/Makefile
> index 4d5c883a9..7b5c5d634 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1109,7 +1109,7 @@ archprepare: archheaders archscripts prepare1 
> scripts_basic
>  prepare0: archprepare gcc-plugins
> $(Q)$(MAKE) $(build)=.
>
> -# All the preparing..
> +# All the preparing...
>  prepare: prepare0 prepare-objtool
>
>  # Support for using generic headers in asm-generic
> --
> 2.19.0
>

Jonathan,

can you please merge my patch? After you merge this one, I'll go
through the rest of the documentation to make it more consistent.

Diego

Re: [PATCH 5/6] fsmount: do not use legacy MS_ flags

[Christian Brauner]

On Sat, Sep 22, 2018 at 04:48:32PM +0100, David Howells wrote:
> Christian Brauner  wrote:
> 
> > mount_setattr(int dfd, const char *path, unsigned int atflags,
> >   unsigned int attr_cmd,
> >   unsigned int attr_values,
> >   unsigned int attr_mask);
> 
> Whilst you can have up to six arguments on a syscall, I seem to remember that
> 6-arg syscalls require special handlers on some systems due to register count.

Sure, but if we wanted to we might just get the syscall down to five
arguments even with my suggestion. Of course, I'm not sure what the
reasons for all of the other arguments to this function are since it's
not yet implemented. Seems that attr_values and attr_mask could be
compacted to a single attr_mask maybe? :)

Christian


signature.asc
Description: PGP signature

Re: [PATCH v3 1/2] printk: Fix panic caused by passing log_buf_len to command line

[Steven Rostedt]

On Sat, 22 Sep 2018 23:40:51 +0800
 wrote:

> From: He Zhe 
> 
> log_buf_len_setup does not check input argument before passing it to
> simple_strtoull. The argument would be a NULL pointer if "log_buf_len",
> without its value, is set in command line and thus causes the following
> panic.
> 
> PANIC: early exception 0xe3 IP 10:aaeacd0d error 0 cr2 0x0
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
> 4.19.0-rc4-yocto-standard+ #1
> [0.00] RIP: 0010:_parse_integer_fixup_radix+0xd/0x70
> ...
> [0.00] Call Trace:
> [0.00]  simple_strtoull+0x29/0x70
> [0.00]  memparse+0x26/0x90
> [0.00]  log_buf_len_setup+0x17/0x22
> [0.00]  do_early_param+0x57/0x8e
> [0.00]  parse_args+0x208/0x320
> [0.00]  ? rdinit_setup+0x30/0x30
> [0.00]  parse_early_options+0x29/0x2d
> [0.00]  ? rdinit_setup+0x30/0x30
> [0.00]  parse_early_param+0x36/0x4d
> [0.00]  setup_arch+0x336/0x99e
> [0.00]  start_kernel+0x6f/0x4ee
> [0.00]  x86_64_start_reservations+0x24/0x26
> [0.00]  x86_64_start_kernel+0x6f/0x72
> [0.00]  secondary_startup_64+0xa4/0xb0
> 
> This patch adds a check to prevent the panic.
> 
> Signed-off-by: He Zhe 
> Cc: sta...@vger.kernel.org

I just tried this on a 2.6.32 kernel, and it crashes there. I guess
this goes farther back than git history goes.

Perhaps it should be commented that this bug has been here since
creation of (git) time.


> Cc: pmla...@suse.com
> Cc: sergey.senozhat...@gmail.com
> Cc: rost...@goodmis.org
> ---
> v2:
> Split out the addition of pr_fmt and the unsigned update

Which unsigned update? As it does switch to unsigned to "unsigned int",
but that change is fine to me with this.

> v3:
> Use more clear error info
> Change unsigned to unsigned in to avoid checkpatch.pl warning
> 
>  kernel/printk/printk.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 9bf5404..d9821c0 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
>  /* save requested log_buf_len since it's too early to process it */
>  static int __init log_buf_len_setup(char *str)
>  {
> - unsigned size = memparse(str, &str);
> + unsigned int size;

I'm OK with the int update too, as its low risk.

Acked-by: Steven Rostedt (VMware) 

-- Steve

> +
> + if (!str) {
> + pr_err("boot command line parameter value not provided\n");
> + return -EINVAL;
> + }
> +
> + size = memparse(str, &str);
>  
>   log_buf_len_update(size);
>  

Re: [PATCH v3 3/5] drivers: pinctrl: msm: enable PDC interrupt only during suspend

[Marc Zyngier]

Hi Lina,

On Tue, 04 Sep 2018 22:18:08 +0100,
Lina Iyer  wrote:
> 
> During suspend the system may power down some of the system rails. As a
> result, the TLMM hw block may not be operational anymore and wakeup
> capable GPIOs will not be detected. The PDC however will be operational
> and the GPIOs that are routed to the PDC as IRQs can wake the system up.
> 
> To avoid being interrupted twice (for TLMM and once for PDC IRQ) when a
> GPIO trips, use TLMM for active and switch to PDC for suspend. When
> entering suspend, disable the TLMM wakeup interrupt and instead enable
> the PDC IRQ and revert upon resume.
> 
> Signed-off-by: Lina Iyer 
> ---
> Changes in v3:
>   - Enable PDC-IRQ swap only for edge interrupts
> Changes in v2:
>   - Fix PDC IRQ max port, 126 is the max supported in h/w
>   - Use PDC hwirq in bitmap, linux numbers could be large
>   - Setup DISABLE_UNLAZY for both TLMM and PDC IRQs
> ---
>  drivers/pinctrl/qcom/pinctrl-msm.c | 73 +-
>  drivers/pinctrl/qcom/pinctrl-msm.h |  3 ++
>  2 files changed, 75 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
> b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 6527a0a9edd1..01a455f86fcd 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -37,6 +37,7 @@
>  #include "../pinctrl-utils.h"
>  
>  #define MAX_NR_GPIO 300
> +#define MAX_PDC_HWIRQ 126
>  #define PS_HOLD_OFFSET 0x820
>  
>  /**
> @@ -51,6 +52,7 @@
>   * @enabled_irqs:   Bitmap of currently enabled irqs.
>   * @dual_edge_irqs: Bitmap of irqs that need sw emulated dual edge
>   *  detection.
> + * @pdc_hwirqs: Bitmap of wakeup capable irqs.
>   * @soc;Reference to soc_data of platform specific data.
>   * @regs:   Base address for the TLMM register map.
>   */
> @@ -68,11 +70,15 @@ struct msm_pinctrl {
>  
>   DECLARE_BITMAP(dual_edge_irqs, MAX_NR_GPIO);
>   DECLARE_BITMAP(enabled_irqs, MAX_NR_GPIO);
> + DECLARE_BITMAP(pdc_hwirqs, MAX_PDC_HWIRQ);
>  
>   const struct msm_pinctrl_soc_data *soc;
>   void __iomem *regs;
> + struct irq_domain *pdc_irq_domain;
>  };
>  
> +static bool in_suspend;
> +
>  static int msm_get_groups_count(struct pinctrl_dev *pctldev)
>  {
>   struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
> @@ -787,8 +793,13 @@ static int msm_gpio_irq_set_wake(struct irq_data *d, 
> unsigned int on)
>  
>   raw_spin_lock_irqsave(&pctrl->lock, flags);
>  
> - if (pdc_irqd)
> + if (pdc_irqd && !in_suspend) {
>   irq_set_irq_wake(pdc_irqd->irq, on);
> + if (on)
> + set_bit(pdc_irqd->hwirq, pctrl->pdc_hwirqs);
> + else
> + clear_bit(pdc_irqd->hwirq, pctrl->pdc_hwirqs);
> + }
>  
>   irq_set_irq_wake(pctrl->irq, on);
>  
> @@ -919,7 +930,12 @@ static int msm_gpio_pdc_pin_request(struct irq_data *d)
>   }
>  
>   irq_set_handler_data(d->irq, irq_get_irq_data(irq));
> + irq_set_handler_data(irq, d);
> + irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY);
> + irq_set_status_flags(d->irq, IRQ_DISABLE_UNLAZY);
>   disable_irq(irq);
> + if (!pctrl->pdc_irq_domain)
> + pctrl->pdc_irq_domain = irq_get_irq_data(irq)->domain;
>  
>   return 0;
>  }
> @@ -1071,6 +1087,61 @@ static void msm_pinctrl_setup_pm_reset(struct 
> msm_pinctrl *pctrl)
>   }
>  }
>  
> +int __maybe_unused msm_pinctrl_suspend_late(struct device *dev)
> +{
> + struct msm_pinctrl *pctrl = dev_get_drvdata(dev);
> + struct irq_data *irqd;
> + unsigned int irq;
> + int i;
> +
> + in_suspend = true;
> + for_each_set_bit(i, pctrl->pdc_hwirqs, MAX_PDC_HWIRQ) {
> + irq = irq_find_mapping(pctrl->pdc_irq_domain, i);
> + irqd = irq_get_handler_data(irq);
> + /*
> +  * We don't know if the TLMM will be functional
> +  * or not, during the suspend. If its functional,
> +  * we do not want duplicate interrupts from PDC.
> +  * Hence disable the GPIO IRQ and enable PDC IRQ
> +  * for edge interrupt only.
> +  */
> + if (irqd_is_wakeup_set(irqd) && !irqd_is_level_type(irqd)) {
> + disable_irq_wake(irqd->irq);

There is something I don't quite get here. If the PDC is used to wake
up the platform, why is the TLMM interrupt configured as a wakeup
source the first place? Or is it just to keep things simple and not
have to track it in the TLMM driver itself?

> + disable_irq(irqd->irq);
> + enable_irq(irq);
> + }
> + }

Given that you're changing in_suspend and parsing the bitmap,
shouldn't take the pdc spinlock?

> +
> + return 0;
> +}
> +
> +int __maybe_unused msm_pinctrl_resume_late(struct device *dev)
> +{
> + struct msm_pinctrl *pctrl = dev_get_drvdata(dev);
> + struct irq_da

Re: [PATCH v5] EDAC, ghes: use CPER module handles to locate DIMMs

[Borislav Petkov]

On Wed, Sep 19, 2018 at 01:59:00AM +, Fan Wu wrote:
> For platforms whose firmwares provide valid module handles
> (SMBIOS type 17) in error records, this patch uses the module
> handles to locate corresponding DIMMs and enables per-DIMM
> error counter update.
> 
> Signed-off-by: Fan Wu 
> Reviewed-by: Tyler Baicar 
> Reviewed-by: James Morse 
> Tested-by: Toshi Kani 
> ---
> 
> Changes from v4:
> Changes from v3:
> * Updated Reviewed-by list
> 
> Changes from v2:
> * Fixed coding style glitch
> * Added Tested-by/Reviewed-by
> 
> Changes from v1:
> *  Changed the new function name to get_dimm_smbios_index
> *  Removed unnecessary checks inside get_dimm_smbios_index
> *  Reverted the change of the DMI handle print
> *  Updated commit message
> 
> ---
>  drivers/edac/ghes_edac.c | 23 +++
>  include/linux/edac.h |  2 ++
>  2 files changed, 25 insertions(+)

Applied, thanks.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH 2/6] pstore: Add event tracing support

[Sai Prakash Ranjan]

On 9/22/2018 2:35 PM, Joel Fernandes wrote:

On Sat, Sep 8, 2018 at 4:28 PM Sai Prakash Ranjan
 wrote:



Could you just split the pstore space into a per-cpu event buffer like
we are doing for ftrace-on-pstore? Then you don't need to lock. I fear
the lock contention will be apparent. The pstore code already has
plumbing to split the store buffer per CPU.



Hi Joel,

Thanks a lot for reviewing.

I just looked at per-cpu buffer for ftrace and itseems the pstore percpu 
records will need to be merged into one record if we add this support 
for events. Merging of ftrace logs is based on timestamp, but for events 
we do not have timestamp field (for this specific reason I have added 
timestamp field for IO event tracing so that atleast we can know the cpu 
number in pstore output). For example, the sched event pstore output 
below has no timestamp field, so how do we merge per-cpu logs?


# tail /sys/fs/pstore/event-ramoops-0
sched_waking: comm=rcu_sched pid=11 prio=120 target_cpu=002
sched_wakeup: comm=rcu_sched pid=11 prio=120 target_cpu=002

Also Pstore ftrace log format is fixed i.e.,(CPU:%d ts:%llu %08lx  %08lx 
 %pf <- %pF\n"), but different events will have different formats and 
we will not be able to add timestamp field like how pstore ftrace does 
using  pstore_ftrace_write_timestamp() and pstore_ftrace_read_timestamp().


Sorry if I am confusing you, I can explain better I guess.


Also I think this spinlock can be moved further down.



OK. Something like this would suffice?

{{{
spin_lock_irqsave(&psinfo->buf_lock, flags);

record.buf = (char *)(seq->buffer);
record.size = seq->len;
psinfo->write(&record);

spin_unlock_irqrestore(&psinfo->buf_lock, flags);
}}}


+
+   trace_seq_init(&iter->seq);
+   iter->ent = fbuffer->entry;
+   event_call->event.funcs->trace(iter, 0, event);
+   trace_seq_putc(&iter->seq, 0);


Would it be possible to store the binary trace record in the pstore
buffer instead of outputting text? I suspect that will both be faster
and less space.



I will try this and come back.

Thanks,
Sai

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

Re: [PATCH v3 3/5] drivers: pinctrl: msm: enable PDC interrupt only during suspend

[Lina Iyer]

On Sat, Sep 22 2018 at 10:29 -0600, Marc Zyngier wrote:

Hi Lina,

On Tue, 04 Sep 2018 22:18:08 +0100,
Lina Iyer  wrote:


During suspend the system may power down some of the system rails. As a
result, the TLMM hw block may not be operational anymore and wakeup
capable GPIOs will not be detected. The PDC however will be operational
and the GPIOs that are routed to the PDC as IRQs can wake the system up.

To avoid being interrupted twice (for TLMM and once for PDC IRQ) when a
GPIO trips, use TLMM for active and switch to PDC for suspend. When
entering suspend, disable the TLMM wakeup interrupt and instead enable
the PDC IRQ and revert upon resume.

Signed-off-by: Lina Iyer 
---
Changes in v3:
- Enable PDC-IRQ swap only for edge interrupts
Changes in v2:
- Fix PDC IRQ max port, 126 is the max supported in h/w
- Use PDC hwirq in bitmap, linux numbers could be large
- Setup DISABLE_UNLAZY for both TLMM and PDC IRQs
---

[...]


+int __maybe_unused msm_pinctrl_suspend_late(struct device *dev)
+{
+   struct msm_pinctrl *pctrl = dev_get_drvdata(dev);
+   struct irq_data *irqd;
+   unsigned int irq;
+   int i;
+
+   in_suspend = true;
+   for_each_set_bit(i, pctrl->pdc_hwirqs, MAX_PDC_HWIRQ) {
+   irq = irq_find_mapping(pctrl->pdc_irq_domain, i);
+   irqd = irq_get_handler_data(irq);
+   /*
+* We don't know if the TLMM will be functional
+* or not, during the suspend. If its functional,
+* we do not want duplicate interrupts from PDC.
+* Hence disable the GPIO IRQ and enable PDC IRQ
+* for edge interrupt only.
+*/
+   if (irqd_is_wakeup_set(irqd) && !irqd_is_level_type(irqd)) {
+   disable_irq_wake(irqd->irq);


There is something I don't quite get here. If the PDC is used to wake
up the platform, why is the TLMM interrupt configured as a wakeup
source the first place? Or is it just to keep things simple and not
have to track it in the TLMM driver itself?


True, it need not be. I could just avoid setting the wakeup on the TLMM
and just use the PDC interrupt as wakeup.

Also, I am exploring an option that was suggested by Stephen [1] to just
use the PDC interrupt as a parent of the GPIO IRQ and use a different
irqchip for the PDC interrupt. I ran into some issue with accessing
irqchip and irqdata of the PDC interrupt, since the irqchip was not in
hierarchy with the GPIO's irqchip. I haven't been able to find time to
resolve the issue that the set_parent_ functions, because of the
hierarchy.

Essentially, we have two different mechanisms for GPIO IRQs based on
whether they can be woken up by the PDC interrupt.

GPIO-IRQ --> PDC --> GIC

GPIO-IRQ --> TLMM SUMMARY --> GIC

Do you think the idea is feasible? It would avoid doing all this
enable/disable at every suspend and even during idle, when the TLMM
could be powered off.



+   disable_irq(irqd->irq);
+   enable_irq(irq);
+   }
+   }


Given that you're changing in_suspend and parsing the bitmap,
shouldn't take the pdc spinlock?


Since we are the the only CPU running and suspend/resume (and even idle)
would be serialized I didn't see a reason for needing a lock.


+
+   return 0;
+}
+
+int __maybe_unused msm_pinctrl_resume_late(struct device *dev)
+{
+   struct msm_pinctrl *pctrl = dev_get_drvdata(dev);
+   struct irq_data *irqd, *pdc_irqd;
+   unsigned int irq;
+   int i;
+
+   for_each_set_bit(i, pctrl->pdc_hwirqs, MAX_PDC_HWIRQ) {
+   irq = irq_find_mapping(pctrl->pdc_irq_domain, i);
+   irqd = irq_get_handler_data(irq);
+   pdc_irqd = irq_get_irq_data(irq);
+   /*
+* The TLMM will be operational now, so disable
+* the PDC IRQ for edge interrupts only.
+*/
+   if (irqd_is_wakeup_set(pdc_irqd) &&
+   !irqd_is_level_type(pdc_irqd)) {
+   disable_irq_nosync(irq);
+   enable_irq_wake(irqd->irq);
+   enable_irq(irqd->irq);
+   }
+   }
+   in_suspend = false;


Same remark about the lock.



Thanks,
Lina

[1]. https://lore.kernel.org/patchwork/patch/975423/

Re: [PATCH] PM / suspend: Count suspend-to-idle loop as sleep time

[kbuild test robot]

Hi Rafael,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc4 next-20180921]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Rafael-J-Wysocki/PM-suspend-Count-suspend-to-idle-loop-as-sleep-time/20180914-170606
config: i386-randconfig-a1-09200857 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   kernel/power/suspend.o: In function `s2idle_loop':
>> kernel/power/suspend.c:168: undefined reference to 
>> `timekeeping_inject_sleeptime64'

vim +168 kernel/power/suspend.c

   109  
   110  static void s2idle_loop(void)
   111  {
   112  ktime_t start, delta;
   113  
   114  pm_pr_dbg("suspend-to-idle\n");
   115  
   116  start = ktime_get();
   117  
   118  for (;;) {
   119  int error;
   120  
   121  dpm_noirq_begin();
   122  
   123  /*
   124   * Suspend-to-idle equals
   125   * frozen processes + suspended devices + idle 
processors.
   126   * Thus s2idle_enter() should be called right after
   127   * all devices have been suspended.
   128   *
   129   * Wakeups during the noirq suspend of devices may be 
spurious,
   130   * so prevent them from terminating the loop right away.
   131   */
   132  error = dpm_noirq_suspend_devices(PMSG_SUSPEND);
   133  if (!error)
   134  s2idle_enter();
   135  else if (error == -EBUSY && pm_wakeup_pending())
   136  error = 0;
   137  
   138  if (!error && s2idle_ops && s2idle_ops->wake)
   139  s2idle_ops->wake();
   140  
   141  dpm_noirq_resume_devices(PMSG_RESUME);
   142  
   143  dpm_noirq_end();
   144  
   145  if (error)
   146  break;
   147  
   148  if (s2idle_ops && s2idle_ops->sync)
   149  s2idle_ops->sync();
   150  
   151  if (pm_wakeup_pending())
   152  break;
   153  
   154  pm_wakeup_clear(false);
   155  }
   156  
   157  /*
   158   * If the monotonic clock difference between the start of the 
loop and
   159   * this point is too large, user space may get confused about 
whether or
   160   * not the system has been suspended and tasks may get killed by
   161   * watchdogs etc., so count the loop as "sleep time" to 
compensate for
   162   * that.
   163   */
   164  delta = ktime_sub(ktime_get(), start);
   165  if (ktime_to_ns(delta) > 0) {
   166  struct timespec64 timespec64_delta = 
ktime_to_timespec64(delta);
   167  
 > 168  timekeeping_inject_sleeptime64(×pec64_delta);
   169  }
   170  
   171  pm_pr_dbg("resume from suspend-to-idle\n");
   172  }
   173  

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


.config.gz
Description: application/gzip

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

[Tom Talpey]

On 9/21/2018 8:56 PM, Stefan Metzmacher wrote:

Hi,


+    req->Channel = SMB2_CHANNEL_RDMA_V1_INVALIDATE;
+    if (need_invalidate)
+    req->Channel = SMB2_CHANNEL_RDMA_V1;
+    req->ReadChannelInfoOffset =
+    offsetof(struct smb2_read_plain_req, Buffer);
+    req->ReadChannelInfoLength =
+    sizeof(struct smbd_buffer_descriptor_v1);
+    v1 = (struct smbd_buffer_descriptor_v1 *) &req->Buffer[0];
+    v1->offset = rdata->mr->mr->iova;


It's unnecessary, and possibly leaking kernel information, to use
the IOVA as the offset of a memory region which is registered using
an FRWR. Because such regions are based on the exact bytes targeted
by the memory handle, the offset can be set to any value, typically
zero, but nearly arbitrary. As long as the (offset + length) does
not wrap or otherwise overflow, offset can be set to anything
convenient.

Since SMB reads and writes range up to 8MB, I'd suggest zeroing the
least significant 23 bits, which should guarantee it. The other 41
bits, party on. You could randomize them, pass some clever identifier
such as MID sequence, whatever.


I just tested that setting:

mr->iova &= (PAGE_SIZE - 1);
mr->iova |= 0x;

after the ib_map_mr_sg() and before doing the IB_WR_REG_MR, seems to work.


Good! As you know, we were concerned about it after seeing that
the ib_dma_map_sg() code was unconditionally setting it to the
dma_mapped address. By salting those 's with varying data,
this should give your FRWR regions stronger integrity in addition
to not leaking kernel "addresses" to the wire.

Tom.

Re: [PATCH] iio: adc: Fix potential integer overflow

[Gustavo A. R. Silva]

On 9/22/18 8:42 AM, Jonathan Cameron wrote:
> On Tue, 18 Sep 2018 07:53:14 -0500
> "Gustavo A. R. Silva"  wrote:
> 
>> Cast factor to s64 in order to give the compiler complete information
>> about the proper arithmetic to use and avoid a potential integer
>> overflow. Notice that such variable is being used in a context
>> that expects an expression of type s64 (64 bits, signed).
>>
>> Addresses-Coverity-ID: 1324146 ("Unintentional integer overflow")
>> Fixes: e13d757279bb ("iio: adc: Add QCOM SPMI PMIC5 ADC driver")
>> Signed-off-by: Gustavo A. R. Silva 
>> ---
>>  drivers/iio/adc/qcom-vadc-common.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/adc/qcom-vadc-common.c 
>> b/drivers/iio/adc/qcom-vadc-common.c
>> index dcd7fb5..e360e27 100644
>> --- a/drivers/iio/adc/qcom-vadc-common.c
>> +++ b/drivers/iio/adc/qcom-vadc-common.c
>> @@ -282,7 +282,7 @@ static int qcom_vadc_scale_code_voltage_factor(u16 
>> adc_code,
>>  voltage = div64_s64(voltage, data->full_scale_code_volt);
>>  if (voltage > 0) {
>>  voltage *= prescale->den;
>> -temp = prescale->num * factor;
>> +temp = prescale->num * (s64)factor;
> So factor is an unsigned int so could be 32 bits.  In reality it only
> takes a small set of values between 1 and 1000
> 
> Maximum numerator is 10 so a maximum of 10,000.
> 
> Hence this is a false positive, be it one that would be very hard
> for a static checker to identify.
> 
> So that moves it from a fix to a warning suppression change.
> I have no problem with those, but description needs to reflect that.
> 
> Let me know if I've missed something, if not I'm happy to apply
> this and will put some text in the message to explain the above
> reasoning.
> 

Hi Jonathan,

I think you are right. Plase, feel free to update the commit log.

Thanks
--
Gustavo