[PATCH] staging: comedi: comedi_internal.h: Avoid '(' at the end of line

[Nishad Kamdar]

Bring function argument 'struct comedi_subdevice *s' to the
previous line to avoid ending the line with open parenthesis.
Issue found by checkpatch.

Signed-off-by: Nishad Kamdar 
---
 drivers/staging/comedi/comedi_internal.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/comedi_internal.h 
b/drivers/staging/comedi/comedi_internal.h
index 515f293a5d26..914a644ca416 100644
--- a/drivers/staging/comedi/comedi_internal.h
+++ b/drivers/staging/comedi/comedi_internal.h
@@ -32,8 +32,7 @@ void comedi_buf_map_get(struct comedi_buf_map *bm);
 int comedi_buf_map_put(struct comedi_buf_map *bm);
 int comedi_buf_map_access(struct comedi_buf_map *bm, unsigned long offset,
  void *buf, int len, int write);
-struct comedi_buf_map *comedi_buf_map_from_subdev_get(
-   struct comedi_subdevice *s);
+struct comedi_buf_map *comedi_buf_map_from_subdev_get(struct comedi_subdevice 
*s);
 unsigned int comedi_buf_write_n_available(struct comedi_subdevice *s);
 unsigned int comedi_buf_write_n_allocated(struct comedi_subdevice *s);
 void comedi_device_cancel_all(struct comedi_device *dev);
-- 
2.17.1

Re: [PATCH] thunderbolt: remove redundant variable 'approved'

[Mika Westerberg]

On Fri, Jul 13, 2018 at 09:57:25AM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Variable 'approved' is being assigned but is never used hence it is
> redundant and can be removed.
> 
> Cleans up clang warning:
> warning: variable 'approved' set but not used [-Wunused-but-set-variable]
> 
> Signed-off-by: Colin Ian King 

Applied to thunderbolt.git/next, thanks!

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

[Shakeel Butt]

On Sat, Jul 14, 2018 at 10:26 PM Yafang Shao  wrote:
>
> On Sun, Jul 15, 2018 at 12:25 PM, Shakeel Butt  wrote:
> > On Sat, Jul 14, 2018 at 7:10 PM Yafang Shao  wrote:
> >>
> >> On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt  wrote:
> >> > On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao  wrote:
> >> >>
> >> >> try_charge maybe executed in packet receive path, which is in interrupt
> >> >> context.
> >> >> In this situation, the 'current' is the interrupted task, which may has
> >> >> no relation to the rx softirq, So it is nonsense to use 'current'.
> >> >>
> >> >
> >> > Have you actually seen this occurring?
> >>
> >> Hi Shakeel,
> >>
> >> I'm trying to produce this issue, but haven't find it occur yet.
> >>
> >> > I am not very familiar with the
> >> > network code but I can think of two ways try_charge() can be called
> >> > from network code. Either through kmem charging or through
> >> > mem_cgroup_charge_skmem() and both locations correctly handle
> >> > interrupt context.
> >> >
> >>
> >> Why do you say that mem_cgroup_charge_skmem() correctly hanle
> >> interrupt context ?
> >>
> >> Let me show you why mem_cgroup_charge_skmem isn't hanling interrupt
> >> context correctly.
> >>
> >> mem_cgroup_charge_skmem() is calling  try_charge() twice.
> >> The first one is with GFP_NOWAIT as the gfp_mask, and the second one
> >> is with  (GFP_NOWAIT |  __GFP_NOFAIL) as the gfp_mask.
> >>
> >> If page_counter_try_charge() failes at the first time, -ENOMEM is returned.
> >> Then mem_cgroup_charge_skmem() will call try_charge() once more with
> >> __GFP_NOFAIL set, and this time if If page_counter_try_charge() failes
> >> again the '
> >> force' label in  try_charge() will be executed and 0 is returned.
> >>
> >> No matter what, the 'current' will be used and touched, that is
> >> meaning mem_cgroup_charge_skmem() isn't hanling the interrupt context
> >> correctly.
> >>
> >
> > Hi Yafang,
> >
> > If you check mem_cgroup_charge_skmem(), the memcg passed is not
> > 'current' but is from the sock object i.e. sk->sk_memcg for which the
> > network buffer is allocated for.
> >
>
> That's correct, the memcg if from the sock object.
> But the point is, in this situation why 'current' is used in try_charge() ?
> As 'current' is not related with the memcg, which is just a interrupted task.
>

Hmm so you mean the behavior of memcg charging in the interrupt
context depends on the state of the interrupted task. As you have
noted, mem_cgroup_charge_skmem() tries charging again with
__GFP_NOFAIL and the charge succeeds. Basically the memcg charging by
mem_cgroup_charge_skmem() will always succeed irrespective of the
state of the interrupted task. However mem_cgroup_charge_skmem() can
return true if the interrupted task was exiting or a fatal signal is
pending or oom victim or reclaiming memory. Can you please explain why
this is bad?

Shakeel

Re: [PATCH] IB/mlx5: avoid binding a new mpi unit to the same devices repeatedly

[Leon Romanovsky]

On Sat, Jul 14, 2018 at 06:57:01PM +0300, Or Gerlitz wrote:
> On Sat, Jul 14, 2018 at 2:50 AM, Qing Huang  wrote:
> > When a CX5 device is configured in dual-port RoCE mode, after creating
> > many VFs against port 1, creating the same number of VFs against port 2
> > will flood kernel/syslog with something like
> > "mlx5_*:mlx5_ib_bind_slave_port:4266:(pid 5269): port 2 already
> > affiliated."
> >
> > So basically, when traversing mlx5_ib_dev_list, mlx5_ib_add_slave_port()
> > shouldn't repeatedly attempt to bind the new mpi data unit to every device
> > on the list until it finds an unbound device.
>
> Daniel,
>
> What is mpi data unit?

Or,

"mpi" is multi-port information needed for multi-port IB devices
resource sharing.

In simple words, "mpi" holds mapping information between
affiliated ports (master vs. slave) and IB device which it is connected.

Most probably, "mpi data unit" was meant "mpi struct" by Qing.

BTW, Daniel is OOO till 7-23.

Thanks

>
> Or.
>
> >
> > Reported-by: Gerald Gibson 
> > Signed-off-by: Qing Huang 
> > ---
> >  drivers/infiniband/hw/mlx5/main.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/infiniband/hw/mlx5/main.c 
> > b/drivers/infiniband/hw/mlx5/main.c
> > index b3ba9a2..1ddd1d3 100644
> > --- a/drivers/infiniband/hw/mlx5/main.c
> > +++ b/drivers/infiniband/hw/mlx5/main.c
> > @@ -6068,7 +6068,8 @@ static void *mlx5_ib_add_slave_port(struct 
> > mlx5_core_dev *mdev, u8 port_num)
> >
> > mutex_lock(&mlx5_ib_multiport_mutex);
> > list_for_each_entry(dev, &mlx5_ib_dev_list, ib_dev_list) {
> > -   if (dev->sys_image_guid == mpi->sys_image_guid)
> > +   if (dev->sys_image_guid == mpi->sys_image_guid &&
> > +   !dev->port[mlx5_core_native_port_num(mdev) - 1].mp.mpi)
> > bound = mlx5_ib_bind_slave_port(dev, mpi);
> >
> > if (bound) {
> > --
> > 2.9.3
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature

[GIT PULL] ARM: SoC fixes

[Olof Johansson]

Hi Linus,

The following changes since commit f0463f3619fd10e0cbaa5195bf2bc264a77a586d:

  Merge tag 'omap-for-v4.18/fixes-signed' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes 
(2018-07-05 14:59:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/armsoc-fixes

for you to fetch changes up to 13e66ceea1600f1061181acc2d4e0fac1a7d0333:

  Merge tag 'omap-for-v4.18/fixes-rc4-signed' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes 
(2018-07-14 15:14:02 -0700)


ARM: SoC fixes for 4.18-rc

 - A fix for OMAP5 and DRA7 to make the branch predictor hardening
   settings take proper effect on secondary cores
 - Disable USB OTG on am3517 since current driver isn't working
 - Fix thermal sensor register settings on Armada 38x
 - Fix suspend/resume IRQs on pxa3xx


Adam Ford (1):
  ARM: dts: am3517.dtsi:  Disable reference to OMAP3 OTG controller

Baruch Siach (1):
  ARM: dts: armada-38x: use the new thermal binding

Daniel Mack (1):
  ARM: pxa: irq: fix handling of ICMR registers in suspend/resume

Nishanth Menon (1):
  ARM: DRA7/OMAP5: Enable ACTLR[0] (Enable invalidates of BTB) for 
secondary cores

Olof Johansson (3):
  Merge tag 'pxa-fixes-4.18' of https://github.com/rjarzmik/linux into fixes
  Merge tag 'mvebu-fixes-4.18-1' of git://git.infradead.org/linux-mvebu 
into fixes
  Merge tag 'omap-for-v4.18/fixes-rc4-signed' of 
git://git.kernel.org/.../tmlind/linux-omap into fixes

 arch/arm/boot/dts/am3517.dtsi |  5 +
 arch/arm/boot/dts/armada-38x.dtsi |  2 +-
 arch/arm/mach-omap2/omap-smp.c| 41 +++
 arch/arm/mach-pxa/irq.c   |  4 ++--
 4 files changed, 49 insertions(+), 3 deletions(-)

Re: [Ksummit-discuss] bug-introducing patches

[Willy Tarreau]

On Sat, Jul 14, 2018 at 11:09:13PM +0200, Pavel Machek wrote:
> > For anyone interested in making sure that obscure (whatever that means)
> > drivers are tested for stable releases, but does not want to spend time on 
> > it,
> > all I can recommend is to implement qemu support for it and let me know,
> > and I'll be happy to add a respective test to my test farm.
> 
> Umm. Yes, qemu support for every driver would be nice, but will not happen.

Well, I would argue that driver code changes much less than core code
between kernel versions, and that most of the changes in drivers are
mostly infrastructure changes. Drivers don't evolve much in general,
they are written, tested, merged, they receive fixes and then they
only receive infrastructure changes that touch all drivers in the same
category.

When you backport fixes to drivers, it is very common that the code
looks almost the same between even a very old kernel and mainline, and
when not, the adaptations generally look quite straightforward, and if
not it means the driver changed significantly and in this case we don't
backport the fix as we don't even know if it is relevant.

I've always had much more difficulties backporting fixes under the arch/
subdir where stuff changes all the time. Sometimes a patch applies but
doesn't even compile. I learned not to play black magic in this area
because some patches are subtle and if the code changed you often need
the author and/or maintainers to double-check. Some subsystems like KVM
improve a lot over time and are difficult to backport to as well, and
even if you manage to properly backport a fix you're uncertain how to
verify you backported it well. Similarly you don't want to improvise
yourself the backporter of the year in this area.

Drivers are often OK and are the ones harder to test, so in the end
you don't miss much by your limited ability to test a backport there.

What I can certainly say as a stable kernel user is that the regression
rate is so low compared to the fix rate that I never have any problem
upgrading to a more recent version in the same branch, because the
number of problems that will be fixed is much higher than the risk of
a single regression.

As Guenter says, we can always improve, but the most important is to
deliver fixes in a timely manner. When you see that any LTS branch
accumulates around 5000 fixes over time, you understand that any
single new kernel being released contains around 5000 bugs left to be
found. Fixing them quickly is much more important to me (as a user)
than ensuring that I will not reach 5001 by inheriting from a poorly
tested backport.

My hope is that thanks to all the automated testing in place we can
further accelerate the backport rate so that a stable kernel reaches
in 2 months the level of quality that we previously used to reach only
after one year. And I think we're already about there, as both 4.4.x
and 4.9.x in their early versions (x < 10) were already very good for
various use cases. 4.17.5 I'm using on this PC looks pretty slick as
well. Overall it means that we can provide a clean upgrade path for
users so that they don't stick to bogus or insecure kernels by fear
of upgrading. We can always argue that a bug may appear once in a
while but for me while technically this is true, stastistically this
is just FUD and is not relevant to end users' real usage.

Willy

Re: [PATCH v5 6/7] Bluetooth: mediatek: Add protocol support for MediaTek serial devices

[Sean Wang]

On Sat, 2018-07-14 at 18:32 +0200, Marcel Holtmann wrote:
> Hi Sean,
> 
> > This adds a driver to run on the top of btuart driver for the MediaTek
> > serial protocol based on running H:4, which can enable the built-in
> > Bluetooth device inside MT7622 SoC.
> > 
> > Signed-off-by: Sean Wang 
> > ---
> > drivers/bluetooth/Kconfig |  11 ++
> > drivers/bluetooth/Makefile|   2 +
> > drivers/bluetooth/btmtkuart.c | 352 
> > ++
> > drivers/bluetooth/btmtkuart.h | 116 ++
> > drivers/bluetooth/btuart.c|  18 +++
> > 5 files changed, 499 insertions(+)
> > create mode 100644 drivers/bluetooth/btmtkuart.c
> > create mode 100644 drivers/bluetooth/btmtkuart.h
> > 
> > diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> > index 00fdf5f..4d7d640 100644
> > --- a/drivers/bluetooth/Kconfig
> > +++ b/drivers/bluetooth/Kconfig
> > @@ -85,6 +85,17 @@ config BT_HCIBTUART
> >   Say Y here to compile support for Bluetooth UART devices into the
> >   kernel or say M to compile it as module (btuart).
> > 
> > +config BT_HCIBTUART_MTK
> > +   tristate "MediaTek HCI UART driver"
> > +   depends on BT_HCIBTUART
> > +   help
> > + MediaTek Bluetooth HCI UART driver.
> > + This driver is required if you want to use MediaTek Bluetooth
> > + with serial interface.
> > +
> > + Say Y here to compile support for MediaTek Bluetooth UART devices
> > + into the kernel or say M to compile it as module (btmtkuart).
> > +
> > config BT_HCIUART
> > tristate "HCI UART driver"
> > depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS
> > diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> > index 60a19cb..c9a8926 100644
> > --- a/drivers/bluetooth/Makefile
> > +++ b/drivers/bluetooth/Makefile
> > @@ -26,6 +26,8 @@ obj-$(CONFIG_BT_BCM)  += btbcm.o
> > obj-$(CONFIG_BT_RTL)+= btrtl.o
> > obj-$(CONFIG_BT_QCA)+= btqca.o
> > 
> > +obj-$(CONFIG_BT_HCIBTUART_MTK) += btmtkuart.o
> > +
> > obj-$(CONFIG_BT_HCIUART_NOKIA)  += hci_nokia.o
> > 
> > obj-$(CONFIG_BT_HCIRSI) += btrsi.o
> > diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
> > new file mode 100644
> > index 000..9eed21c
> > --- /dev/null
> > +++ b/drivers/bluetooth/btmtkuart.c
> > @@ -0,0 +1,352 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (c) 2018 MediaTek Inc.
> > +
> > +/*
> > + * Bluetooth support for MediaTek serial devices
> > + *
> > + * Author: Sean Wang 
> > + *
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +#include "btmtkuart.h"
> > +#include "btuart.h"
> > +#include "h4_recv.h"
> > +
> > +static void mtk_stp_reset(struct mtk_stp_splitter *sp)
> > +{
> > +   sp->cursor = 2;
> > +   sp->dlen = 0;
> > +}
> > +
> > +static const unsigned char *
> > +mtk_stp_split(struct btuart_dev *bdev, struct mtk_stp_splitter *sp,
> > + const unsigned char *data, int count, int *sz_h4)
> > +{
> > +   struct mtk_stp_hdr *shdr;
> > +
> > +   /* The cursor is reset when all the data of STP is consumed out. */
> > +   if (!sp->dlen && sp->cursor >= 6)
> > +   sp->cursor = 0;
> > +
> > +   /* Filling pad until all STP info is obtained. */
> > +   while (sp->cursor < 6 && count > 0) {
> > +   sp->pad[sp->cursor] = *data;
> > +   sp->cursor++;
> > +   data++;
> > +   count--;
> > +   }
> > +
> > +   /* Retrieve STP info and have a sanity check. */
> > +   if (!sp->dlen && sp->cursor >= 6) {
> > +   shdr = (struct mtk_stp_hdr *)&sp->pad[2];
> > +   sp->dlen = shdr->dlen1 << 8 | shdr->dlen2;
> > +
> > +   /* Resync STP when unexpected data is being read. */
> > +   if (shdr->prefix != 0x80 || sp->dlen > 2048) {
> > +   bt_dev_err(bdev->hdev, "stp format unexpect (%d, %d)",
> > +  shdr->prefix, sp->dlen);
> > +   mtk_stp_reset(sp);
> > +   }
> > +   }
> > +
> > +   /* Directly quit when there's no data found for H4 can process. */
> > +   if (count <= 0)
> > +   return NULL;
> > +
> > +   /* Tranlate to how much the size of data H4 can handle so far. */
> > +   *sz_h4 = min_t(int, count, sp->dlen);
> > +   /* Update the remaining size of STP packet. */
> > +   sp->dlen -= *sz_h4;
> > +
> > +   /* Data points to STP payload which can be handled by H4. */
> > +   return data;
> > +}
> > +
> > +static int mtk_stp_send(struct btuart_dev *bdev, struct sk_buff *skb)
> > +{
> > +   struct mtk_stp_hdr *shdr;
> > +   struct sk_buff *new_skb;
> > +   int dlen;
> > +
> > +   memcpy(skb_push(skb, 1), &hci_skb_pkt_type(skb), 1);
> > +   dlen = skb->len;
> > +
> > +   /* Make sure of STP header at least has 4-bytes free space to fill. */
> > +   if (unlikely(skb_headroom(skb) < sizeof(*shdr))) {
> > +   new_skb = skb_re

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

[Yafang Shao]

On Sun, Jul 15, 2018 at 12:25 PM, Shakeel Butt  wrote:
> On Sat, Jul 14, 2018 at 7:10 PM Yafang Shao  wrote:
>>
>> On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt  wrote:
>> > On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao  wrote:
>> >>
>> >> try_charge maybe executed in packet receive path, which is in interrupt
>> >> context.
>> >> In this situation, the 'current' is the interrupted task, which may has
>> >> no relation to the rx softirq, So it is nonsense to use 'current'.
>> >>
>> >
>> > Have you actually seen this occurring?
>>
>> Hi Shakeel,
>>
>> I'm trying to produce this issue, but haven't find it occur yet.
>>
>> > I am not very familiar with the
>> > network code but I can think of two ways try_charge() can be called
>> > from network code. Either through kmem charging or through
>> > mem_cgroup_charge_skmem() and both locations correctly handle
>> > interrupt context.
>> >
>>
>> Why do you say that mem_cgroup_charge_skmem() correctly hanle
>> interrupt context ?
>>
>> Let me show you why mem_cgroup_charge_skmem isn't hanling interrupt
>> context correctly.
>>
>> mem_cgroup_charge_skmem() is calling  try_charge() twice.
>> The first one is with GFP_NOWAIT as the gfp_mask, and the second one
>> is with  (GFP_NOWAIT |  __GFP_NOFAIL) as the gfp_mask.
>>
>> If page_counter_try_charge() failes at the first time, -ENOMEM is returned.
>> Then mem_cgroup_charge_skmem() will call try_charge() once more with
>> __GFP_NOFAIL set, and this time if If page_counter_try_charge() failes
>> again the '
>> force' label in  try_charge() will be executed and 0 is returned.
>>
>> No matter what, the 'current' will be used and touched, that is
>> meaning mem_cgroup_charge_skmem() isn't hanling the interrupt context
>> correctly.
>>
>
> Hi Yafang,
>
> If you check mem_cgroup_charge_skmem(), the memcg passed is not
> 'current' but is from the sock object i.e. sk->sk_memcg for which the
> network buffer is allocated for.
>

That's correct, the memcg if from the sock object.
But the point is, in this situation why 'current' is used in try_charge() ?
As 'current' is not related with the memcg, which is just a interrupted task.


> If the network buffers is allocated through kmem interface, the
> charging is bypassed altogether (through memcg_kmem_bypass()) for
> interrupt context.
>

Yes.

Thanks
Yafang

Re: [PATCH v5 1/7] dt-bindings: net: bluetooth: Add mediatek-bluetooth

[Sean Wang]

On Sat, 2018-07-14 at 18:26 +0200, Marcel Holtmann wrote:
> Hi Sean,
> 
> > Add binding document for a SoC built-in device using MediaTek protocol.
> > Which could be found on MT7622 SoC or other similar MediaTek SoCs.
> > 
> > Signed-off-by: Sean Wang 
> > Reviewed-by: Rob Herring 
> > ---
> > .../devicetree/bindings/net/mediatek-bluetooth.txt | 35 
> > ++
> > 1 file changed, 35 insertions(+)
> > create mode 100644 
> > Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt 
> > b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
> > new file mode 100644
> > index 000..1335429
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
> > @@ -0,0 +1,35 @@
> > +MediaTek SoC built-in Bluetooth Devices
> > +==
> > +
> > +This device is a serial attached device to BTIF device and thus it must be 
> > a
> > +child node of the serial node with BTIF. The dt-bindings details for BTIF
> > +device can be known via Documentation/devicetree/bindings/serial/8250.txt.
> > +
> > +Required properties:
> > +
> > +- compatible:  Must be one of
> > + "mediatek,mt7622-bluetooth"": for MT7622 SoC
> 
> this does not match with the example below. And one of, should be normally be 
> a list.
> 

Thanks! I'll remove the words "one of" from the compatible description,
and the extra " being added accidentally.

And the below example fully shows the bluetooth device and its attached
bus (mediatek,mt7622-btif) to let people know clearly how to enable the
bluetooth device.

The current document just describes the bluetooth device and as for the
attached bus, it is already present at
Documentation/devicetree/bindings/serial/8250.txt.

Sean


> > +- clocks:  Should be the clock specifiers corresponding to the entry in
> > +   clock-names property.
> > +- clock-names: Should contain "ref" entries.
> > +- power-domains: Phandle to the power domain that the device is part of
> > +
> > +Example:
> > +
> > +   btif: serial@1100c000 {
> > +   compatible = "mediatek,mt7622-btif",
> > +"mediatek,mtk-btif";
> > +   reg = <0 0x1100c000 0 0x1000>;
> > +   interrupts = ;
> > +   clocks = <&pericfg CLK_PERI_BTIF_PD>;
> > +   clock-names = "main";
> > +   reg-shift = <2>;
> > +   reg-io-width = <4>;
> > +
> > +   bluetooth {
> > +   compatible = "mediatek,mt7622-bluetooth";
> > +   power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>;
> > +   clocks = <&clk25m>;
> > +   clock-names = "ref";
> > +   };
> > +   };
> 
> Regards
> 
> Marcel
> 

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

[Shakeel Butt]

On Sat, Jul 14, 2018 at 7:10 PM Yafang Shao  wrote:
>
> On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt  wrote:
> > On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao  wrote:
> >>
> >> try_charge maybe executed in packet receive path, which is in interrupt
> >> context.
> >> In this situation, the 'current' is the interrupted task, which may has
> >> no relation to the rx softirq, So it is nonsense to use 'current'.
> >>
> >
> > Have you actually seen this occurring?
>
> Hi Shakeel,
>
> I'm trying to produce this issue, but haven't find it occur yet.
>
> > I am not very familiar with the
> > network code but I can think of two ways try_charge() can be called
> > from network code. Either through kmem charging or through
> > mem_cgroup_charge_skmem() and both locations correctly handle
> > interrupt context.
> >
>
> Why do you say that mem_cgroup_charge_skmem() correctly hanle
> interrupt context ?
>
> Let me show you why mem_cgroup_charge_skmem isn't hanling interrupt
> context correctly.
>
> mem_cgroup_charge_skmem() is calling  try_charge() twice.
> The first one is with GFP_NOWAIT as the gfp_mask, and the second one
> is with  (GFP_NOWAIT |  __GFP_NOFAIL) as the gfp_mask.
>
> If page_counter_try_charge() failes at the first time, -ENOMEM is returned.
> Then mem_cgroup_charge_skmem() will call try_charge() once more with
> __GFP_NOFAIL set, and this time if If page_counter_try_charge() failes
> again the '
> force' label in  try_charge() will be executed and 0 is returned.
>
> No matter what, the 'current' will be used and touched, that is
> meaning mem_cgroup_charge_skmem() isn't hanling the interrupt context
> correctly.
>

Hi Yafang,

If you check mem_cgroup_charge_skmem(), the memcg passed is not
'current' but is from the sock object i.e. sk->sk_memcg for which the
network buffer is allocated for.

If the network buffers is allocated through kmem interface, the
charging is bypassed altogether (through memcg_kmem_bypass()) for
interrupt context.

regards,
Shakeel

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

[Bart Van Assche]

On Sat, 2018-07-14 at 18:59 -0700, Linus Torvalds wrote:
> On Sat, Jul 14, 2018 at 6:57 PM Linus Torvalds 
>  wrote:
> > Honestly, I'd like to just encourage people to get the sparse update
> > from Luc Van Oostenryck instead.
> > 
> > For a while there it looked like Chris Li would just pull from Luc,
> > and we'd have timely releases, but that really doesn't seem to have
> > ended up happening after all. So right now it's probably just best to
> > get Luc's tree instead from
> > 
> > https://github.com/lucvoo/sparse-dev
> > 
> > which also ends up fixing a lot of other issues.
> 
> Oh,
>  and I meant to cc Luc on that email, but then forgot. So here he is cc'd now.

(+ Konstantin)

Something that is confusing for kernel developers is that the sparse wiki
(https://sparse.wiki.kernel.org/index.php/Main_Page) refers kernel developers
to an outdated sparse tree. Should something be done about this inconsistency?
Should the sparse wiki point at one of Luc's sparse trees or should perhaps
Luc be granted access to the tree that wiki points at
(https://git.kernel.org/pub/scm/devel/sparse/sparse.git)?

Thanks,

Bart.

[PATCH] arm64: cpuinfo: Include cleartext implementer and part strings

[Olof Johansson]

There's some use in printing out what the implementer and part numbers
decode to for cases where they're known.

I filled in the table based on public information; mostly from ARM TRMs
and other tools (and some of the SSBD tables in the kernel, etc).

Apple IDs came from
https://github.com/apple/darwin-xnu/blob/master/osfmk/arm/cpuid.h

Signed-off-by: Olof Johansson 
---
 arch/arm64/kernel/cpuinfo.c | 79 +++--
 1 file changed, 76 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index e9ab7b3..9a7c25d 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -121,6 +121,67 @@ static const char *const compat_hwcap2_str[] = {
 };
 #endif /* CONFIG_COMPAT */
 
+struct midr_info {
+   unsigned int mask;
+   unsigned int val;
+   char *id;
+};
+
+static const struct midr_info midr_part[] = {
+   // ARM
+   { .mask = 0xff00fff0, .val = 0x4100d030, .id = "Cortex-A53" },
+   { .mask = 0xff00fff0, .val = 0x4100d040, .id = "Cortex-A35" },
+   { .mask = 0xff00fff0, .val = 0x4100d070, .id = "Cortex-A57" },
+   { .mask = 0xff00fff0, .val = 0x4100d080, .id = "Cortex-A72" },
+   { .mask = 0xff00fff0, .val = 0x4100d090, .id = "Cortex-A73" },
+   { .mask = 0xff00fff0, .val = 0x4100d0a0, .id = "Cortex-A75" },
+   { .mask = 0xff00fff0, .val = 0x4100d0f0, .id = "Cortex-A55" },
+   // Broadcom
+   { .mask = 0xff00fff0, .val = 0x42001000, .id = "Brahma-B53" },
+   { .mask = 0xff00fff0, .val = 0x42005160, .id = "ThunderX2" },
+   // Cavium
+   { .mask = 0xff00fff0, .val = 0x43000a00, .id = "ThunderX" },
+   { .mask = 0xff00fff0, .val = 0x43000a10, .id = "ThunderX 88xx" },
+   { .mask = 0xff00fff0, .val = 0x43000a20, .id = "ThunderX 81xx" },
+   { .mask = 0xff00fff0, .val = 0x43000a30, .id = "ThunderX 83xx" },
+   { .mask = 0xff00fff0, .val = 0x43000af0, .id = "ThunderX2 99xx" },
+   // Nvidia
+   { .mask = 0xff00fff0, .val = 0x4e00, .id = "Denver" },
+   { .mask = 0xff00fff0, .val = 0x4e30, .id = "Denver 2" },
+   // Applied Micro
+   { .mask = 0xff00fff0, .val = 0x5000, .id = "X-Gene" },
+   // Qualcomm
+   { .mask = 0xff00fff0, .val = 0x51002010, .id = "Kryo" },
+   { .mask = 0xff00fff0, .val = 0x51002050, .id = "Kryo" },
+   { .mask = 0xff00fff0, .val = 0x51002110, .id = "Kryo" },
+   { .mask = 0xff00fff0, .val = 0x51008000, .id = "Falkor V1/Kryo" },
+   { .mask = 0xff00fff0, .val = 0x51008010, .id = "Kryo V2" },
+   { .mask = 0xff00fff0, .val = 0x5100c000, .id = "Falkor" },
+   { .mask = 0xff00fff0, .val = 0x5100c010, .id = "Saphira" },
+   // Samsung
+   { .mask = 0xff00fff0, .val = 0x5310, .id = "M1" },
+   // Apple
+   { .mask = 0xff00fff0, .val = 0x6110, .id = "Cyclone" },
+   { .mask = 0xff00fff0, .val = 0x6120, .id = "Typhoon" },
+   { .mask = 0xff00fff0, .val = 0x6130, .id = "Typhoon/Capri" },
+   { .mask = 0xff00fff0, .val = 0x6140, .id = "Twister" },
+   { .mask = 0xff00fff0, .val = 0x6150, .id = "Twister/Elba/Malta" },
+   { .mask = 0xff00fff0, .val = 0x6160, .id = "Hurricane" },
+   { .mask = 0xff00fff0, .val = 0x6170, .id = "Hurricane/Myst" },
+};
+
+static const struct midr_info midr_impl[] = {
+   { .mask = 0xff00, .val = 0x4100, .id = "ARM" },
+   { .mask = 0xff00, .val = 0x4200, .id = "Broadcom" },
+   { .mask = 0xff00, .val = 0x4300, .id = "Cavium" },
+   { .mask = 0xff00, .val = 0x4d00, .id = "Motorola" },
+   { .mask = 0xff00, .val = 0x4e00, .id = "Nvidia" },
+   { .mask = 0xff00, .val = 0x5000, .id = "Applied Micro" },
+   { .mask = 0xff00, .val = 0x5100, .id = "Qualcomm" },
+   { .mask = 0xff00, .val = 0x5300, .id = "Samsung" },
+   { .mask = 0xff00, .val = 0x6100, .id = "Apple" },
+};
+
 static int c_show(struct seq_file *m, void *v)
 {
int i, j;
@@ -129,6 +190,16 @@ static int c_show(struct seq_file *m, void *v)
for_each_online_cpu(i) {
struct cpuinfo_arm64 *cpuinfo = &per_cpu(cpu_data, i);
u32 midr = cpuinfo->reg_midr;
+   char *impl = NULL;
+   char *part = NULL;
+
+   for (j = 0; !impl && j < ARRAY_SIZE(midr_impl); j++)
+   if ((midr & midr_impl[j].mask) == midr_impl[j].val)
+   impl = midr_impl[j].id;
+
+   for (j = 0; !part && j < ARRAY_SIZE(midr_part); j++)
+   if ((midr & midr_part[j].mask) == midr_part[j].val)
+   part = midr_part[j].id;
 
/*
 * glibc reads /proc/cpuinfo to determine the number of
@@ -168,11 +239,12 @@ static int c_show(struct seq_file *m, void *v)
}
seq_puts(m, "\n");
 
-   seq_printf(m

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

[Bart Van Assche]

On Sat, 2018-07-14 at 18:59 -0700, Linus Torvalds wrote:
> On Sat, Jul 14, 2018 at 6:57 PM Linus Torvalds
>  wrote:
> > 
> > Honestly, I'd like to just encourage people to get the sparse update
> > from Luc Van Oostenryck instead.
> > 
> > For a while there it looked like Chris Li would just pull from Luc,
> > and we'd have timely releases, but that really doesn't seem to have
> > ended up happening after all. So right now it's probably just best to
> > get Luc's tree instead from
> > 
> > https://github.com/lucvoo/sparse-dev
> > 
> > which also ends up fixing a lot of other issues.
> > 
> > Linus
>
> Oh,
>  and I meant to cc Luc on that email, but then forgot. So here he is cc'd now.
> 
> Linus

Hello everyone,

I will switch to Luc's sparse tree.

Thank you for the feedback.

Bart.

[PATCH] x86/boot: Fix if_changed build flip/flop

[Kees Cook]

The if_changed kbuild function can only be used once per target. If not
it will effectively always trigger, flipping back and forth between the
two commands getting recorded. Instead, merge the two commands into a
single function to get stable build artifacts (i.e. .vmlinux.cmd).

Reported-by: Dirk Gouders 
Suggested-by: Masahiro Yamada 
Fixes: 98f78525371b ("x86/boot: Refuse to build with data relocations")
Signed-off-by: Kees Cook 
---
 arch/x86/boot/compressed/Makefile | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index fa42f895fdde..169c2feda14a 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -106,9 +106,13 @@ define cmd_check_data_rel
done
 endef
 
+# We need to run two commands under "if_changed", so merge them into a
+# single invocation.
+quiet_cmd_check-and-link-vmlinux = LD  $@
+  cmd_check-and-link-vmlinux = $(cmd_check_data_rel); $(cmd_ld)
+
 $(obj)/vmlinux: $(vmlinux-objs-y) FORCE
-   $(call if_changed,check_data_rel)
-   $(call if_changed,ld)
+   $(call if_changed,check-and-link-vmlinux)
 
 OBJCOPYFLAGS_vmlinux.bin :=  -R .comment -S
 $(obj)/vmlinux.bin: vmlinux FORCE
-- 
2.17.1


-- 
Kees Cook
Pixel Security

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

[Yafang Shao]

On Sun, Jul 15, 2018 at 10:10 AM, Yafang Shao  wrote:
> On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt  wrote:
>> On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao  wrote:
>>>
>>> try_charge maybe executed in packet receive path, which is in interrupt
>>> context.
>>> In this situation, the 'current' is the interrupted task, which may has
>>> no relation to the rx softirq, So it is nonsense to use 'current'.
>>>
>>
>> Have you actually seen this occurring?
>
> Hi Shakeel,
>
> I'm trying to produce this issue, but haven't find it occur yet.
>
>> I am not very familiar with the
>> network code but I can think of two ways try_charge() can be called
>> from network code. Either through kmem charging or through
>> mem_cgroup_charge_skmem() and both locations correctly handle
>> interrupt context.
>>
>
> Why do you say that mem_cgroup_charge_skmem() correctly hanle
> interrupt context ?
>
> Let me show you why mem_cgroup_charge_skmem isn't hanling interrupt
> context correctly.
>
> mem_cgroup_charge_skmem() is calling  try_charge() twice.
> The first one is with GFP_NOWAIT as the gfp_mask, and the second one
> is with  (GFP_NOWAIT |  __GFP_NOFAIL) as the gfp_mask.
>
> If page_counter_try_charge() failes at the first time, -ENOMEM is returned.
> Then mem_cgroup_charge_skmem() will call try_charge() once more with
> __GFP_NOFAIL set, and this time if If page_counter_try_charge() failes
> again the '
> force' label in  try_charge() will be executed and 0 is returned.
>
> No matter what, the 'current' will be used and touched, that is
> meaning mem_cgroup_charge_skmem() isn't hanling the interrupt context
> correctly.
>
> Pls. let me know if I miss something.
>
>

Maybe bellow change is better,
@@ -2123,6 +2123,9 @@ static int try_charge(struct mem_cgroup *memcg,
gfp_t gfp_mask,
goto retry;
}

+   if (!gfpflags_allow_blocking(gfp_mask))
+   goto nomem;
+
/*
 * Unlike in global OOM situations, memcg is not in a physical
 * memory shortage.  Allow dying and OOM-killed tasks to
@@ -2146,9 +2149,6 @@ static int try_charge(struct mem_cgroup *memcg,
gfp_t gfp_mask,
if (unlikely(task_in_memcg_oom(current)))
goto nomem;

-   if (!gfpflags_allow_blocking(gfp_mask))
-   goto nomem;

Thanks
Yafang

Re: [PATCH 1/1] f2fs: checkpoint disabling

[Jaegeuk Kim]

On 07/11, Daniel Rosenberg wrote:
> This adds a lightweight non-persistent snapshotting scheme to f2fs.
> 
> To use, mount with the option checkpoint=disable, and to return to
> normal operation, remount with checkpoint=enable. If the filesystem
> is shut down before remounting with checkpoint=enable, it will revert
> back to its apparent state when it was first mounted with
> checkpoint=disable. This is useful for situations where you wish to be
> able to roll back the state of the disk in case of some critical
> failure.
> 
> Signed-off-by: Daniel Rosenberg 
> ---
> 
> This probably needs some work in the mount/remount areas to ensure it
> plays nicely with all combinations of other options.
> I'm also unsure how it should interact with statfs.
> 
> It currently handles accounting for free space in checkpoint disabled
> mode by setting up addition tracking for free data blocks, node blocks,
> and segments. These are used in inc_valid_block_cnt and inc_valid_node_cnt
> to track what the state will be once the blocks are actually allocated.
> We choose new current segments in SSR mode first to avoid the edge case
> where the disk is not yet full, but we only have dirty segments remaining
> that happen to not be of the right type. We also agressively add segments
> to the dirty list instead of pre-free when it is possible to reuse them to
> allow us to continue without a checkpoint as long as possible.
> 
>  Documentation/filesystems/f2fs.txt |   5 ++
>  fs/f2fs/data.c |  21 ++
>  fs/f2fs/f2fs.h |  63 +++-
>  fs/f2fs/file.c |  18 +
>  fs/f2fs/gc.c   |   4 +
>  fs/f2fs/segment.c  |  96 +++-
>  fs/f2fs/segment.h  |  66 +
>  fs/f2fs/super.c| 115 +++--
>  8 files changed, 326 insertions(+), 62 deletions(-)
> 
> diff --git a/Documentation/filesystems/f2fs.txt 
> b/Documentation/filesystems/f2fs.txt
> index 69f8de9957397..a026b353a99d4 100644
> --- a/Documentation/filesystems/f2fs.txt
> +++ b/Documentation/filesystems/f2fs.txt
> @@ -193,6 +193,11 @@ fsync_mode=%s  Control the policy of fsync. 
> Currently supports "posix",
> non-atomic files likewise "nobarrier" mount option.
>  test_dummy_encryption  Enable dummy encryption, which provides a fake fscrypt
> context. The fake fscrypt context is used by xfstests.
> +checkpoint=%s  Set to "disable" to turn off checkpointing. Set to 
> "enable"
> +   to reenable checkpointing. Is enabled by default. 
> While
> +   disabled, any unmounting or unexpected shutdowns will 
> cause
> +   the filesystem contents to appear as they did when the
> +   filesystem was mounted with that option.
>  
>  
> 
>  DEBUGFS ENTRIES
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 83d4cff445f53..b3fa713fd42bf 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -1654,9 +1654,20 @@ bool f2fs_should_update_inplace(struct inode *inode, 
> struct f2fs_io_info *fio)
>  bool f2fs_should_update_outplace(struct inode *inode, struct f2fs_io_info 
> *fio)
>  {
>   struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
> + struct seg_entry *se;
> + unsigned int segno, offset;
>  
>   if (test_opt(sbi, LFS))
>   return true;
> + if (test_opt(sbi, DISABLE_CHECKPOINT)) {

struct seg_entry *se;
unsigned int segno, offset;

> + if (fio->old_blkaddr == NULL_ADDR)
-
NEW_ADDR

> + return true;
> + segno = GET_SEGNO(sbi, fio->old_blkaddr);
> + se = get_seg_entry(sbi, segno);
> + offset = GET_BLKOFF_FROM_SEG0(sbi, fio->old_blkaddr);
> + if (f2fs_test_bit(offset, se->ckpt_valid_map))
> + return true;
> + }
>   if (S_ISDIR(inode->i_mode))
>   return true;
>   if (f2fs_is_atomic_file(inode))
> @@ -1684,9 +1695,12 @@ int f2fs_do_write_data_page(struct f2fs_io_info *fio)
>  {
>   struct page *page = fio->page;
>   struct inode *inode = page->mapping->host;
> + struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
>   struct dnode_of_data dn;
>   struct extent_info ei = {0,0,0};
>   bool ipu_force = false;
> + bool need_tmp_grab = test_opt(sbi, DISABLE_CHECKPOINT);
> + blkcnt_t tmp_block = 1;
>   int err = 0;
>  
>   set_new_dnode(&dn, inode, NULL, NULL, 0);
> @@ -1750,6 +1764,11 @@ int f2fs_do_write_data_page(struct f2fs_io_info *fio)
>   if (err)
>   goto out_writepage;
>  
> + if (need_tmp_grab) {
> + err = inc_valid_block_count(sbi, dn.inode, &tmp_bl

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

[Yafang Shao]

On Sat, Jul 14, 2018 at 11:38 PM, Shakeel Butt  wrote:
> On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao  wrote:
>>
>> try_charge maybe executed in packet receive path, which is in interrupt
>> context.
>> In this situation, the 'current' is the interrupted task, which may has
>> no relation to the rx softirq, So it is nonsense to use 'current'.
>>
>
> Have you actually seen this occurring?

Hi Shakeel,

I'm trying to produce this issue, but haven't find it occur yet.

> I am not very familiar with the
> network code but I can think of two ways try_charge() can be called
> from network code. Either through kmem charging or through
> mem_cgroup_charge_skmem() and both locations correctly handle
> interrupt context.
>

Why do you say that mem_cgroup_charge_skmem() correctly hanle
interrupt context ?

Let me show you why mem_cgroup_charge_skmem isn't hanling interrupt
context correctly.

mem_cgroup_charge_skmem() is calling  try_charge() twice.
The first one is with GFP_NOWAIT as the gfp_mask, and the second one
is with  (GFP_NOWAIT |  __GFP_NOFAIL) as the gfp_mask.

If page_counter_try_charge() failes at the first time, -ENOMEM is returned.
Then mem_cgroup_charge_skmem() will call try_charge() once more with
__GFP_NOFAIL set, and this time if If page_counter_try_charge() failes
again the '
force' label in  try_charge() will be executed and 0 is returned.

No matter what, the 'current' will be used and touched, that is
meaning mem_cgroup_charge_skmem() isn't hanling the interrupt context
correctly.

Pls. let me know if I miss something.


Thanks
Yafang

Re: [PATCH v7] add param that allows bootline control of hardened usercopy

[Kees Cook]

On Wed, Jul 4, 2018 at 10:47 AM, Vlastimil Babka  wrote:
> On 07/04/2018 06:52 PM, Kees Cook wrote:
>> This produces less efficient code in the general case, and I'd like to
>> keep the general case (hardening enabled) as fast as possible.
>
> How specifically is the code less efficient? It should be always a
> static key check (no-op thanks to the code patching involved) and a
> function call in the "hardening enabled" case, just in different order.
> And in either case compiled out if it's a constant.

My understanding from reading the jump label comments[1] is that on
order produces:

NOP
do normal thing
label1:
do rest of function
RET
label2:
do exceptional thing
jump label1

where "NOP" is changed to "JMP label2" when toggled, and the other is:

JMP label1
do exceptional thing
JMP label2
label1:
do normal thing
label2:
do rest of function
RET

where "JMP label1" is changed to NOP when toggled. (i.e. does the
default do NOP, thing, function, or does the default to JMP, thing,
JMP, function)

-Kees

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/jump_label.h#n334

-- 
Kees Cook
Pixel Security

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

[Linus Torvalds]

Oh,
 and I meant to cc Luc on that email, but then forgot. So here he is cc'd now.

Linus

On Sat, Jul 14, 2018 at 6:57 PM Linus Torvalds
 wrote:
>
> Honestly, I'd like to just encourage people to get the sparse update
> from Luc Van Oostenryck instead.
>
> For a while there it looked like Chris Li would just pull from Luc,
> and we'd have timely releases, but that really doesn't seem to have
> ended up happening after all. So right now it's probably just best to
> get Luc's tree instead from
>
> https://github.com/lucvoo/sparse-dev
>
> which also ends up fixing a lot of other issues.
>
> Linus

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

[Linus Torvalds]

On Sat, Jul 14, 2018 at 6:49 PM Kees Cook  wrote:
>
> I'm fine with this; it'll only activate for sparse. I'd like to get
> Linus's eyes on it, though, since this macro caused us SO much pain
> that I'm nervous to change it without some greater level of review. :)

Honestly, I'd like to just encourage people to get the sparse update
from Luc Van Oostenryck instead.

For a while there it looked like Chris Li would just pull from Luc,
and we'd have timely releases, but that really doesn't seem to have
ended up happening after all. So right now it's probably just best to
get Luc's tree instead from

https://github.com/lucvoo/sparse-dev

which also ends up fixing a lot of other issues.

Linus

Re: [PATCH] kernel.h: Avoid that sparse complains about using sizeof(void)

[Kees Cook]

On Thu, Jul 5, 2018 at 9:17 AM, Bart Van Assche  wrote:
> The macro __is_constexpr() causes sparse to report the following:
>
> warning: expression using sizeof(void)
>
> Avoid this by using __builtin_constant_p() instead.
>
> Fixes: 3c8ba0d61d04 ("kernel.h: Retain constant expression output for 
> max()/min()")
> Signed-off-by: Bart Van Assche 
> Cc: Linus Torvalds 
> Cc: Martin Uecker 
> Cc: Kees Cook 
> Cc: Ingo Molnar 
> Cc: Miguel Ojeda 
> Cc: 
> ---
>  include/linux/kernel.h | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index d23123238534..a9f0d0d48971 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -811,13 +811,19 @@ static inline void ftrace_dump(enum ftrace_dump_mode 
> oops_dump_mode) { }
>  #define __typecheck(x, y) \
> (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
>
> +#ifndef __CHECKER__
>  /*
>   * This returns a constant expression while determining if an argument is
>   * a constant expression, most importantly without evaluating the argument.
> - * Glory to Martin Uecker 
> + * Glory to Martin Uecker . However, 
> this
> + * macro causes sparse to report the warning "expression using sizeof(void)".
> + * Hence use __builtin_constant_p() instead when using sparse.
>   */
>  #define __is_constexpr(x) \
> (sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))
> +#else
> +#define __is_constexpr(x) __builtin_constant_p((x))
> +#endif
>
>  #define __no_side_effects(x, y) \
> (__is_constexpr(x) && __is_constexpr(y))

I'm fine with this; it'll only activate for sparse. I'd like to get
Linus's eyes on it, though, since this macro caused us SO much pain
that I'm nervous to change it without some greater level of review. :)

Acked-by: Kees Cook 

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v13 2/2] Add oom victim's memcg to the oom context information

[禹舟键]

Hi David
Could I use use plain old %d? Just like this,
pr_cont(",task=%s,pid=%d,uid=%d\n", p->comm, p->pid,
from_kuid(&init_user_ns, task_uid(p)));

Thanks

[PATCH] RISC-V: Don't increment sepc after breakpoint.

[Jim Wilson]

Adding 4 to sepc is pointless, and is wrong if we executed a 2-byte
compressed breakpoint.  This plus a corresponding gdb patch allows
compressed breakpoints to work in gdb.  Gdb maintainers have already
agreed that this is the right approach.

Signed-off-by: Jim Wilson 
---
 arch/riscv/kernel/traps.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
index 14fcec5bdd24..ae323071c786 100644
--- a/arch/riscv/kernel/traps.c
+++ b/arch/riscv/kernel/traps.c
@@ -150,7 +150,6 @@ asmlinkage void do_trap_break(struct pt_regs *regs)
 #endif /* CONFIG_GENERIC_BUG */
 
do_trap_siginfo(SIGTRAP, TRAP_BRKPT, regs->sepc, current);
-   regs->sepc += 0x4;
 }
 
 #ifdef CONFIG_GENERIC_BUG
-- 
2.17.1

Re: [PATCH] base: core: Remove WARN_ON from link dependencies check

[Mark Brown]

On Thu, Jul 12, 2018 at 10:06:23AM +0200, Benjamin Gaignard wrote:
> In some cases the link between between customer and supplier
> already exist. Do not warn about already existing dependencies
> because device_link_add() take care of this case.

Reviwed-by: Mark Brown 


signature.asc
Description: PGP signature

Applied "ASoC: allow soc-core to pick up name prefixes from component nodes" to the asoc tree

[Mark Brown]

The patch

   ASoC: allow soc-core to pick up name prefixes from component nodes

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From aefba45539bc4868c1fae336410aec907ee0882a Mon Sep 17 00:00:00 2001
From: Jerome Brunet 
Date: Fri, 13 Jul 2018 14:50:43 +0200
Subject: [PATCH] ASoC: allow soc-core to pick up name prefixes from component
 nodes

When the component does not match the configuration table provided
by the card, let soc-core check the component node for a name prefix

Signed-off-by: Jerome Brunet 
Signed-off-by: Mark Brown 
---
 sound/soc/soc-core.c | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 00bd58d167dd..3be0310d5c81 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1193,15 +1193,27 @@ void snd_soc_remove_dai_link(struct snd_soc_card *card,
 }
 EXPORT_SYMBOL_GPL(snd_soc_remove_dai_link);
 
+static void soc_set_of_name_prefix(struct snd_soc_component *component)
+{
+   struct device_node *component_of_node = component->dev->of_node;
+   const char *str;
+   int ret;
+
+   if (!component_of_node && component->dev->parent)
+   component_of_node = component->dev->parent->of_node;
+
+   ret = of_property_read_string(component_of_node, "sound-name-prefix",
+ &str);
+   if (!ret)
+   component->name_prefix = str;
+}
+
 static void soc_set_name_prefix(struct snd_soc_card *card,
struct snd_soc_component *component)
 {
int i;
 
-   if (card->codec_conf == NULL)
-   return;
-
-   for (i = 0; i < card->num_configs; i++) {
+   for (i = 0; i < card->num_configs && card->codec_conf; i++) {
struct snd_soc_codec_conf *map = &card->codec_conf[i];
struct device_node *component_of_node = component->dev->of_node;
 
@@ -1213,8 +1225,14 @@ static void soc_set_name_prefix(struct snd_soc_card 
*card,
if (map->dev_name && strcmp(component->name, map->dev_name))
continue;
component->name_prefix = map->name_prefix;
-   break;
+   return;
}
+
+   /*
+* If there is no configuration table or no match in the table,
+* check if a prefix is provided in the node
+*/
+   soc_set_of_name_prefix(component);
 }
 
 static int soc_probe_component(struct snd_soc_card *card,
-- 
2.18.0

Applied "ASoC: trace: remove snd_soc_codec" to the asoc tree

[Mark Brown]

The patch

   ASoC: trace: remove snd_soc_codec

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 211b4415ecb254e167837206756dea123342689c Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto 
Date: Wed, 28 Mar 2018 02:18:13 +
Subject: [PATCH] ASoC: trace: remove snd_soc_codec

snd_soc_codec is replaced to snd_soc_component,
and it is not used in this file.
Let's remove it

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
---
 include/trace/events/asoc.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h
index ccd1a3bdff46..40c300fe704d 100644
--- a/include/trace/events/asoc.h
+++ b/include/trace/events/asoc.h
@@ -12,7 +12,6 @@
 #define DAPM_ARROW(dir) (((dir) == SND_SOC_DAPM_DIR_OUT) ? "->" : "<-")
 
 struct snd_soc_jack;
-struct snd_soc_codec;
 struct snd_soc_card;
 struct snd_soc_dapm_widget;
 struct snd_soc_dapm_path;
-- 
2.18.0

Applied "ASoC: add DT documentation for the sound-name-prefix property" to the asoc tree

[Mark Brown]

The patch

   ASoC: add DT documentation for the sound-name-prefix property

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From d5418ae3f9443f911d4324c0cade988ced39cfbe Mon Sep 17 00:00:00 2001
From: Jerome Brunet 
Date: Fri, 13 Jul 2018 14:50:42 +0200
Subject: [PATCH] ASoC: add DT documentation for the sound-name-prefix property

Signed-off-by: Jerome Brunet 
Signed-off-by: Mark Brown 
---
 .../devicetree/bindings/sound/name-prefix.txt | 24 +++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/name-prefix.txt

diff --git a/Documentation/devicetree/bindings/sound/name-prefix.txt 
b/Documentation/devicetree/bindings/sound/name-prefix.txt
new file mode 100644
index ..645775908657
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/name-prefix.txt
@@ -0,0 +1,24 @@
+Name prefix:
+
+Card implementing the routing property define the connection between
+audio components as list of string pair. Component using the same
+sink/source names may use the name prefix property to prepend the
+name of their sinks/sources with the provided string.
+
+Optional name prefix property:
+- sound-name-prefix : string using as prefix for the sink/source names of
+ the component.
+
+Example: Two instances of the same component.
+
+amp0: analog-amplifier@0 {
+   compatible = "simple-audio-amplifier";
+   enable-gpios = <&gpio GPIOH_3 0>;
+   sound-name-prefix = "FRONT";
+};
+
+amp1: analog-amplifier@1 {
+   compatible = "simple-audio-amplifier";
+   enable-gpios = <&gpio GPIOH_4 0>;
+   sound-name-prefix = "BACK";
+};
-- 
2.18.0

Re: [PATCH] regulator: core: fix _regulator_do_disable return value

[Mark Brown]

On Fri, Jul 13, 2018 at 05:48:54PM +0200, Marco Felsch wrote:
> On 18-07-13 14:07, Mark Brown wrote:

> > This is fine - consumers shouldn't expect that a disable will cause
> > anything to actually get powered off, constraints or other consumers
> > might mean that the disable doesn't actually happen.  It's just the same
> > as a consumer with an always on flag.

> Okay, I understand that the behaviour should be like the always-on
> contrain. But now the behaviour of the core is like my v1 of
> "Re-Enable support to disable switch regulators". It's like a 'simulated
> off', which wasn't a good solution for you. The difference is, that the
> 'simulated off' is now made in the core.

Right, there's a difference between what the core (which does actually
explicitly turn things on and off) sees and what the consumers (which
only increment and decrement reference counts which may happen to result
in something being turned off immediately but also might not) see.


signature.asc
Description: PGP signature

Re: [PATCH v2 1/3] dt-bindings: pfuze100: add optional disable switch-regulators binding

[Mark Brown]

On Fri, Jul 13, 2018 at 02:50:01PM +0200, Marco Felsch wrote:

> +Optional properties:
> +- fsl,pfuze-support-disable: Boolean, if present disable all unused switch
> +  regulators to save power consumption. Attention, till 4.18 these regulators

The property name sounds like it affects all the regulators but really
it's just the sw ones - how about adding -sw at the end?  Bit of a
bikeshed but it does end up in an ABI.


signature.asc
Description: PGP signature

[PATCH] ACPI: battery: remove redundant old_present check on insertion

[Lucas Magasweran]

From: Lucas Rangit Magasweran 

On removal battery_present changes from 1 to 0 after calling
acpi_battery_get_statu() and battery->update_time is set to 0
before returning.

On insertion battery_present changes from 0 to 1 after calling
acpi_battery_get_status() and acpi_battery_get_info() is called
because battery->update_time is 0.

The old_present condition is therefore redundant.

This was added in the commit below when there was a path without
sysfs that would skip getting the newly inserted battery info.

commit 50b178512b7d ("Newly inserted battery might differ from one
just removed, so update of battery info fields is required.")

Signed-off-by: Lucas Rangit Magasweran 
---
 drivers/acpi/battery.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index f88bc9f..c280e8e 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -918,10 +918,11 @@ static void acpi_battery_quirks(struct acpi_battery 
*battery)
 
 static int acpi_battery_update(struct acpi_battery *battery, bool resume)
 {
-   int result, old_present = acpi_battery_present(battery);
-   result = acpi_battery_get_status(battery);
+   int result = acpi_battery_get_status(battery);
+
if (result)
return result;
+
if (!acpi_battery_present(battery)) {
sysfs_remove_battery(battery);
battery->update_time = 0;
@@ -931,8 +932,7 @@ static int acpi_battery_update(struct acpi_battery 
*battery, bool resume)
if (resume)
return 0;
 
-   if (!battery->update_time ||
-   old_present != acpi_battery_present(battery)) {
+   if (!battery->update_time) {
result = acpi_battery_get_info(battery);
if (result)
return result;
-- 
2.7.4

Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

[Pavel Machek]

On Sun 2018-07-15 00:29:25, Pavel Machek wrote:
> On Sun 2018-07-15 00:02:57, Jacek Anaszewski wrote:
> > Hi Pavel,
> > 
> > On 07/14/2018 11:20 PM, Pavel Machek wrote:
> > >Hi!
> > >
> > >>>It also drew my attention to the issue of desired pattern sysfs
> > >>>interface semantics on uninitialized pattern. In your implementation
> > >>>user seems to be unable to determine if the pattern is activated
> > >>>or not. We should define the semantics for this use case and
> > >>>describe it in the documentation. Possibly pattern could
> > >>>return alone new line character then.
> > >
> > >Let me take a step back: we have triggers.. like LED blinking.
> > >
> > >How is that going to interact with patterns? We probably want the
> > >patterns to be ignored in that case...?
> > >
> > >Which suggest to me that we should treat patterns as a trigger. I
> > >believe we do something similar with blinking already.
> > >
> > >Then it is easy to determine if pattern is active, and pattern
> > >vs. trigger issue is solved automatically.
> > 
> > I'm all for it. I proposed this approach during the previous
> > discussions related to possible pattern interface implementations,
> > but you seemed not to be so enthusiastic in [0].
> > 
> > [0] https://lkml.org/lkml/2017/4/7/350
> 
> Hmm. Reading my own email now, I can't decipher it.
> 
> I believe I meant "changing patterns from kernel in response to events
> is probably overkill"... or something like that.

Anyway -- to clean up the confusion -- I'd like to see

echo pattern > trigger
echo "1 2 3 4 5 6 7 8" > somewhere

to activate pattern, and

echo none > trigger

to stop it.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH] ACPI: battery: use cache_time as cache "enabled"

[Lucas Magasweran]

From: Lucas Rangit Magasweran 

When battery state is not cached the module parameter cache_time is 0
and battery->update_time starts at 0. However, it set to jiffies in
each call to acpi_battery_get_state() and should not be used to
determine if a cache time is used.

Using battery->update_time causes the evaluation of time_before()
even though cache_time is 0.

This is a minor issue as the behavior is still as expected.
Even if kernel HZ was very slow and jiffies remained equal, the
expected branch (false) would be taken because time_before() is
used instead of time_before_eq().

Signed-off-by: Lucas Rangit Magasweran 
---
 drivers/acpi/battery.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index d79ad84..f88bc9f 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -549,7 +549,7 @@ static int acpi_battery_get_state(struct acpi_battery 
*battery)
if (!acpi_battery_present(battery))
return 0;
 
-   if (battery->update_time &&
+   if (cache_time &&
time_before(jiffies, battery->update_time +
msecs_to_jiffies(cache_time)))
return 0;
-- 
2.7.4

[PATCH 2/2] staging: olpc_dcon: add missing identifier names

[Cristian Kubis]

Add missing function argument identifier names as suggested by
checkpatch.pl.

Signed-off-by: Cristian Kubis 
---
 drivers/staging/olpc_dcon/olpc_dcon.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/olpc_dcon/olpc_dcon.h 
b/drivers/staging/olpc_dcon/olpc_dcon.h
index fa89bb97c7b0..c987aaf894e7 100644
--- a/drivers/staging/olpc_dcon/olpc_dcon.h
+++ b/drivers/staging/olpc_dcon/olpc_dcon.h
@@ -91,10 +91,10 @@ struct dcon_priv {
 };
 
 struct dcon_platform_data {
-   int (*init)(struct dcon_priv *);
+   int (*init)(struct dcon_priv *dcon);
void (*bus_stabilize_wiggle)(void);
-   void (*set_dconload)(int);
-   int (*read_status)(u8 *);
+   void (*set_dconload)(int load);
+   int (*read_status)(u8 *status);
 };
 
 #include 
-- 
2.18.0

[PATCH 1/2] staging: olpc_dcon: prefer 'help' in KConfig

[Cristian Kubis]

Fix for a style warning reported by checkpatch.pl in KConfig
suggesting to use 'help' instead of '---help---'.

Signed-off-by: Cristian Kubis 
---
 drivers/staging/olpc_dcon/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/olpc_dcon/Kconfig 
b/drivers/staging/olpc_dcon/Kconfig
index d277f048789e..c91a56f77bcb 100644
--- a/drivers/staging/olpc_dcon/Kconfig
+++ b/drivers/staging/olpc_dcon/Kconfig
@@ -4,7 +4,7 @@ config FB_OLPC_DCON
depends on I2C
depends on (GPIO_CS5535 || GPIO_CS5535=n)
select BACKLIGHT_CLASS_DEVICE
-   ---help---
+   help
  In order to support very low power operation, the XO laptop uses a
  secondary Display CONtroller, or DCON.  This secondary controller
  is present in the video pipeline between the primary display
@@ -18,7 +18,7 @@ config FB_OLPC_DCON_1
bool "OLPC XO-1 DCON support"
depends on FB_OLPC_DCON && GPIO_CS5535
default y
-   ---help---
+   help
  Enable support for the DCON in XO-1 model laptops.  The kernel
  communicates with the DCON using model-specific code.  If you
  have an XO-1 (or if you're unsure what model you have), you should
@@ -28,7 +28,7 @@ config FB_OLPC_DCON_1_5
bool "OLPC XO-1.5 DCON support"
depends on FB_OLPC_DCON && ACPI
default y
-   ---help---
+   help
  Enable support for the DCON in XO-1.5 model laptops.  The kernel
  communicates with the DCON using model-specific code.  If you
  have an XO-1.5 (or if you're unsure what model you have), you
-- 
2.18.0

[PATCH 0/2] staging: olpc_dcon: fix style warnings

[Cristian Kubis]

Series of patches fixing two different kinds of style warnings in olpc_dcon
as reported by checkpatch.pl.

Cristian Kubis (2):
  staging: olpc_dcon: prefer 'help' in KConfig
  staging: olpc_dcon: add missing identifier names

 drivers/staging/olpc_dcon/Kconfig | 6 +++---
 drivers/staging/olpc_dcon/olpc_dcon.h | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.18.0

Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

[Pavel Machek]

On Sun 2018-07-15 00:02:57, Jacek Anaszewski wrote:
> Hi Pavel,
> 
> On 07/14/2018 11:20 PM, Pavel Machek wrote:
> >Hi!
> >
> >>>It also drew my attention to the issue of desired pattern sysfs
> >>>interface semantics on uninitialized pattern. In your implementation
> >>>user seems to be unable to determine if the pattern is activated
> >>>or not. We should define the semantics for this use case and
> >>>describe it in the documentation. Possibly pattern could
> >>>return alone new line character then.
> >
> >Let me take a step back: we have triggers.. like LED blinking.
> >
> >How is that going to interact with patterns? We probably want the
> >patterns to be ignored in that case...?
> >
> >Which suggest to me that we should treat patterns as a trigger. I
> >believe we do something similar with blinking already.
> >
> >Then it is easy to determine if pattern is active, and pattern
> >vs. trigger issue is solved automatically.
> 
> I'm all for it. I proposed this approach during the previous
> discussions related to possible pattern interface implementations,
> but you seemed not to be so enthusiastic in [0].
> 
> [0] https://lkml.org/lkml/2017/4/7/350

Hmm. Reading my own email now, I can't decipher it.

I believe I meant "changing patterns from kernel in response to events
is probably overkill"... or something like that.

Sorry about confusion,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v9 1/5] clocksource/drivers/timer-mediatek: Add system timer bindings

[Daniel Lezcano]

On 06/07/2018 01:11, Stanley Chu wrote:
> This patch adds bindings of new "System Timer" on Mediatek SoCs.
> 
> Remove RTC clock in the same time because it is not used by
> both "General Purpose Timer" and "System Timer" now.
> 
> Signed-off-by: Stanley Chu 
> ---

I have applied the series for 4.19.

Thanks!

  -- Daniel


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [GIT PULL 3/3] ARM: defconfig: Pull for v4.19

[Olof Johansson]

On Thu, Jul 12, 2018 at 06:46:39PM +0200, Krzysztof Kozlowski wrote:
> Hi,
> 
> Rebased on v4.18-rc2.
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819:
> 
>   Linux 4.18-rc2 (2018-06-24 20:54:29 +0800)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-defconfig-4.19
> 
> for you to fetch changes up to 24ede29d026a9f00aa3f4e7a5531803af4810734:
> 
>   ARM: s5pv210_defconfig: Enable options needed to boot typical Linux distro 
> (2018-07-07 10:49:16 +0200)
> 
> 
> Samsung defconfig changes for v4.19
> 
> Enable options needed for booting full system on S5Pv210-based Samsung
> Galaxy S mobile phones.

Thanks!


-Olof

Re: [GIT PULL 1/3] ARM: dts: exynos: Pull for v4.19

[Olof Johansson]

On Thu, Jul 12, 2018 at 06:46:40PM +0200, Krzysztof Kozlowski wrote:
> Hi,
> 
> Rebased on v4.18-rc2.
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819:
> 
>   Linux 4.18-rc2 (2018-06-24 20:54:29 +0800)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-dt-4.19
> 
> for you to fetch changes up to 57f4e8bc1c3ebbd06a278107edeb6af95b53e5bf:
> 
>   dt-bindings: samsung: Document bindings for SGH-T959P board (2018-07-07 
> 12:28:07 +0200)

Merged, thanks!


-Olof

Re: [GIT PULL 2/3] arm64: dts: exynos: Pull for v4.19

[Olof Johansson]

On Thu, Jul 12, 2018 at 06:46:41PM +0200, Krzysztof Kozlowski wrote:
> Hi,
> 
> Rebased on v4.18-rc2.
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819:
> 
>   Linux 4.18-rc2 (2018-06-24 20:54:29 +0800)
> 
> are available in the git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-dt64-4.19
> 
> for you to fetch changes up to 17aa1530f1ff89ca4e21765e5f4d9e6bcd464eb2:
> 
>   arm64: dts: exynos: Remove leading 0x from unit addresses in Exynos5433 
> (2018-06-25 18:38:49 +0200)


Merged, thanks!


-Olof

Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

[Jacek Anaszewski]

Hi Pavel,

On 07/14/2018 11:20 PM, Pavel Machek wrote:

Hi!


It also drew my attention to the issue of desired pattern sysfs
interface semantics on uninitialized pattern. In your implementation
user seems to be unable to determine if the pattern is activated
or not. We should define the semantics for this use case and
describe it in the documentation. Possibly pattern could
return alone new line character then.


Let me take a step back: we have triggers.. like LED blinking.

How is that going to interact with patterns? We probably want the
patterns to be ignored in that case...?

Which suggest to me that we should treat patterns as a trigger. I
believe we do something similar with blinking already.

Then it is easy to determine if pattern is active, and pattern
vs. trigger issue is solved automatically.


I'm all for it. I proposed this approach during the previous
discussions related to possible pattern interface implementations,
but you seemed not to be so enthusiastic in [0].

[0] https://lkml.org/lkml/2017/4/7/350

--
Best regards,
Jacek Anaszewski

Re: [PATCH] vme: ca91cx42: remove redundant variable i

[Martyn Welch]

On Sat, Jul 14, 2018 at 05:33:32PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Variable i is being assigned but is never used hence it is redundant
> and can be removed.
> 
> Cleans up clang warning:
> warning: variable 'i' set but not used [-Wunused-but-set-variable]
> 
> Signed-off-by: Colin Ian King 

Reviewed-by: Martyn Welch 

> ---
>  drivers/vme/bridges/vme_ca91cx42.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/vme/bridges/vme_ca91cx42.c 
> b/drivers/vme/bridges/vme_ca91cx42.c
> index 5dd284008630..53bdc256805f 100644
> --- a/drivers/vme/bridges/vme_ca91cx42.c
> +++ b/drivers/vme/bridges/vme_ca91cx42.c
> @@ -970,7 +970,6 @@ static unsigned int ca91cx42_master_rmw(struct 
> vme_master_resource *image,
>  {
>   u32 result;
>   uintptr_t pci_addr;
> - int i;
>   struct ca91cx42_driver *bridge;
>   struct device *dev;
>  
> @@ -978,7 +977,6 @@ static unsigned int ca91cx42_master_rmw(struct 
> vme_master_resource *image,
>   dev = image->parent->parent;
>  
>   /* Find the PCI address that maps to the desired VME address */
> - i = image->number;
>  
>   /* Locking as we can only do one of these at a time */
>   mutex_lock(&bridge->vme_rmw);
> -- 
> 2.17.1
> 

Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface

[Pavel Machek]

Hi!

> > It also drew my attention to the issue of desired pattern sysfs
> > interface semantics on uninitialized pattern. In your implementation
> > user seems to be unable to determine if the pattern is activated
> > or not. We should define the semantics for this use case and
> > describe it in the documentation. Possibly pattern could
> > return alone new line character then.

Let me take a step back: we have triggers.. like LED blinking.

How is that going to interact with patterns? We probably want the
patterns to be ignored in that case...?

Which suggest to me that we should treat patterns as a trigger. I
believe we do something similar with blinking already.

Then it is easy to determine if pattern is active, and pattern
vs. trigger issue is solved automatically.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [Ksummit-discuss] bug-introducing patches

[Pavel Machek]

Hi!

> >Well, 0day, kernelci etc... is nice... until the change is in the
> >driver. Most of the kernel are drivers, remember?
> >
> >I don't know. I'd say that if patch is important enough for -stable,
> >there should be someone testing it. For core kernel changes, that can
> >be 0day bot, but for drivers...
> >
> 
> For my part I am just glad that we were able to pick up a fix in xhci code
> just last week, tested or not, from -stable, instead of having to track it
> down ourselves. Similar for many other driver patches which _do_ affect us
> (like the flurry of ext4 patches this week). Granted, there are lots of
> patches which we don't use/need, but even there it is surprising how many
> problems are found with existing testing.
> 
> For anyone interested in making sure that obscure (whatever that means)
> drivers are tested for stable releases, but does not want to spend time on it,
> all I can recommend is to implement qemu support for it and let me know,
> and I'll be happy to add a respective test to my test farm.

Umm. Yes, qemu support for every driver would be nice, but will not happen.

> However, ultimately, stable release candidates are public. Everyone is
> invited to test them. Anyone interested in a specific release and
> driver

Yes, they are public. SubmittingPatches says every patch should be
tested, and that's clearly not happening for -stable. And I'd like
those patch marked such.

> >And problem exists on mainline, too.
> >
> >Hmm. Patch for obscure driver. Wow, nice, is WellKnownName actually
> >using that driver? Aha, no, he is not; he is doing global
> >search&replace, and did not test the patch...
> >
> 
> Ah, like me with the strncpy(x, y, strlen(y)) -> memcpy() replacements
> I did a week or so ago ? You are right, I only compile tested those and
> otherwise trusted my ability to understand C code. If that caused any
> problems, please let me know, and hopefully I'll be able to learn something
> from it.

Yes, such stuff. No, I was not talking about you. I did not want to
give concrete example, but...

# > get_monotonic_boottime() is deprecated, so let's convert this to
# > the simpler ktime_get_boot_ns().
# >
# > Signed-off-by: 
# 
# Have you tested it?
#
...
#   > -curr_boot = timespec_to_ns(&boot_time) * cpus;
# 
# Original code is pretty weird (notice the * cpus), so I'm
# double-checking.

Yes, often you can guess that patch was probably not tested, but it
would be nice to have

Tested: compile

annotation to take away the guesswork. It took me a while an some head
scratching in this concrete example, and it is not first time this
happened.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[GIT PULL] RTC fixes for 4.18

[Alexandre Belloni]

Hi Linus,

Here are two fixes for 4.18.

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git 
tags/rtc-4.18-2

for you to fetch changes up to fd6792bb022e43faa0c4a45b6f25285e21206f9d:

  rtc: fix alarm read and set offset (2018-07-13 10:37:54 +0200)


RTC fixes for 4.18

 - an important core fix for RTCs using the core offsetting only one driver is
affected.
 - a fix for the error path of mrst


Alexandre Belloni (1):
  rtc: fix alarm read and set offset

Dan Carpenter (1):
  rtc: mrst: fix error code in probe()

 drivers/rtc/interface.c | 8 +---
 drivers/rtc/rtc-mrst.c  | 4 +---
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [Ksummit-discuss] bug-introducing patches

[Guenter Roeck]

On 07/14/2018 12:47 PM, Pavel Machek wrote:

Hi!


The way I see it, if a commit can get one or two tested-by, it's a good
alternative to a week in -next.


Agreed. Even their own actually. And I'm not kidding. Those who run large
amounts of tests on certain patches could really mention is in tested-by,
as opposed to the most common cases where the code was just regularly
tested.


Actually, it would be cool to get "Tested: no" and "Tested: compile"
tags in the commit mesages. Sometimes it is clear from the context
that patch was not tested (treewide update of time to 64bit), but
sometime it is not.

This is especially problem for -stable, as it seems that lately
patches are backported from new version without any testing.



When I started my own testing some five years ago, most architectures
did not even build in stable releases. At that time, the only tests being
done on stable release candidates were a number of build tests, and most
of the results were ignored.

Today, we have 0day, kernelci, kerneltests, Linaro's LKFT, and more, plus
several merge and boot tests done by individuals. Stable release candidates
are build tested on all supported architectures, with hundreds of

...

Sure, testing is still far from perfect and needs to be improved. However,
requiring that every patch applied to stable releases be tested individually
(where ? on all affected architectures ?) would be the wrong
direction.


Well, 0day, kernelci etc... is nice... until the change is in the
driver. Most of the kernel are drivers, remember?

I don't know. I'd say that if patch is important enough for -stable,
there should be someone testing it. For core kernel changes, that can
be 0day bot, but for drivers...



For my part I am just glad that we were able to pick up a fix in xhci code
just last week, tested or not, from -stable, instead of having to track it
down ourselves. Similar for many other driver patches which _do_ affect us
(like the flurry of ext4 patches this week). Granted, there are lots of
patches which we don't use/need, but even there it is surprising how many
problems are found with existing testing.

For anyone interested in making sure that obscure (whatever that means)
drivers are tested for stable releases, but does not want to spend time on it,
all I can recommend is to implement qemu support for it and let me know,
and I'll be happy to add a respective test to my test farm.

However, ultimately, stable release candidates are public. Everyone is
invited to test them. Anyone interested in a specific release and driver
is invited take stable release candidates and do the necessary testing,
just like I and several others do.


And problem exists on mainline, too.

Hmm. Patch for obscure driver. Wow, nice, is WellKnownName actually
using that driver? Aha, no, he is not; he is doing global
search&replace, and did not test the patch...



Ah, like me with the strncpy(x, y, strlen(y)) -> memcpy() replacements
I did a week or so ago ? You are right, I only compile tested those and
otherwise trusted my ability to understand C code. If that caused any
problems, please let me know, and hopefully I'll be able to learn something
from it.

Really, there are infrastructure changes all the time. Sometimes I am asked
to run a complete test sequence with those, but most of the time they are
applied to -next and people wait for the fallout. That may not be perfect but,
seriously, the only alternative would be to declare that in-kernel APIs
shall not be changed anymore. I don't think that would be feasible.

Thanks,
Guenter

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

[Cyrill Gorcunov]

On Sat, Jul 14, 2018 at 02:39:24PM -0500, Eric W. Biederman wrote:
> Josh Triplett  writes:
> 
> > On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote:
> >> For a config option that no one has come forward with an actual real
> >> world use case for disabling, that cost seems much too high.
> >
> > The real-world use case is precisely as stated: code size, both storage
> > and RAM.
> 
> That is theoretical.  Which platform will break or feel distressed if we
> make it unconditional.  That is real world.
> 
> > I regularly encounter systems I'd *like* to put Linux in that have
> > around 1MB of storage and 1MB of RAM, or even less.
> 
> Yes.  There is so little code behind CONFIG_CHECKPOINT_RESTART that it
> won't help with that.
> 
> But if minification is the actual requirement for disabling
> CONFIG_CHECKPOINT_RESTART than CONFIG_CHECKPIONT_RESTART is properly
> behind expert and it needs to be default y instead of default n.

I happened to miss this thread, sorry. So as far as I remember it
was me who introduced this option in first place, and initially
I placed it under expert so it won't be enabled by default. Lately
we found that some of functionality introduced for criu sake actually
pretty convenient for other tools (for example vmflags reported in
procfs) so we dropped CONFIG_ option out for such blocks and merged
them into kernel directly. I won't mind if left is merged into the
kernel, there should not be that many places.

Re: [PATCH 2/2] ARM: dts: pxa: add mioa701 board description

[Robert Jarzmik]

Rob Herring  writes:

Hi Rob,

>> +   /* compatible = "mitac,mioa701"; */
>> +   compatible = "marvell,pxa270";
>
> Why the comment?
Leftover, I'll remove it.

>> +   pstore_region:region@0xa200 {
>
> Drop the 0x
Done.

>> +   compatible = 
>> "linux,contiguous-memory-region";
>> +   reg = <0xa200 1048576>;
>
> Use hex for the size.
Ok.

>> +   ffuart: uart@4010 {
>
> Should be "serial@...". You'll have to fix in the base dtsi.
Ok for all of these.
>> +   pxai2c1: i2c@40301680 {
>> +   mrvl,i2c-fast-mode;
>> +   pinctrl-names = "default";
>> +   pinctrl-0 = <&pinctrl_i2c_default>;
>> +   status = "okay";
>> +
>> +   mt9m111: camera@5d {
>> +   compatible = "micron,mt9m111";
>> +   reg = <0x5d>;
>> +   gpios = <&gpio 56 GPIO_ACTIVE_HIGH>;
>> +
>> +   remote = <&pxa_camera>;
>
> Not needed with the graph:
I don't understand that, do you mean the port node is not needed ?

>
>> +   port {
>> +   mt9m111_1: endpoint {
>> +   bus-width = <8>;
>> +   remote-endpoint = 
>> <&pxa_camera>;
>> +   };
>> +   };
>> +   };
>> +   };
>> +   gpio-keys {
>> +   compatible = "gpio-keys";
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   autorepeat;
>> +   pinctrl-names = "default";
>> +   pinctrl-0 = <&pinctrl_gpiokeys_default>;
>> +   status = "okay";
>
> Don't need status here? It shouldn't be defined in the base dtsi.
Heuh what ? The status is just above, and gpio-keys is not defined in any dtsi.

>> +
>> +   button@0 {
>
> If you have unit-address there should also be a reg property. Just
> drop and name the node 'power' or 'power-button'. And similarly for
> the rest.
Ok.

>> +
>> +   regulators {
>> +   compatible = "simple-bus";
>
> Drop this and move children to the top level. This is not an mmio bus.
Ok.

>> +   docg3: flash@0 {
>
> This probably should be a child of the bus controller.
Most certainly yes.

>
>> +   compatible = "m-systems,diskonchip-g3";
>> +   reg = <0x0 0x2000>;
>> +   };
>> +
>> +   panel {
>> +   compatible = "toshiba,ltm0305a776";
>> +   lcd-type = "color-tft";
>
> This should be implied by the compatible.
Mmm no. Actually, this is used by the framebuffer controller, ie. pxafb to set
it up. And I don't think adding a list of panel compatibles in pxafb is a good
idea.
The corresponding code is in : drivers/video/fbdev/pxafb.c, see
"static const char * const lcd_types[]".

>> +   display-timings {
>> +   native-mode = <&timing0>;
>
> We generally imply this from the compatible (i.e. use simple-panel).
But you suppose there is an actual driver for the panel, right ? But there is
none.

> Could use another level of indentation.
Sure.

>> +   ac_charger: charger@1 {
>
> Drop the unit-address.
Ok.

Thanks for the review.

-- 
Robert

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

[Josh Triplett]

On Sat, Jul 14, 2018 at 02:39:24PM -0500, Eric W. Biederman wrote:
> Josh Triplett  writes:
> 
> > On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote:
> >> For a config option that no one has come forward with an actual real
> >> world use case for disabling, that cost seems much too high.
> >
> > The real-world use case is precisely as stated: code size, both storage
> > and RAM.
> 
> That is theoretical.

No, it isn't. I've *watched* the kernel's size trend steadily upward
over time. And it largely happens in individual features that don't
think *their* contribution to size is all that large.

> > I regularly encounter systems I'd *like* to put Linux in that have
> > around 1MB of storage and 1MB of RAM, or even less.
> 
> Yes.  There is so little code behind CONFIG_CHECKPOINT_RESTART that it
> won't help with that.

It adds up; there are hundreds more small features like it.

> But if minification is the actual requirement for disabling
> CONFIG_CHECKPOINT_RESTART than CONFIG_CHECKPIONT_RESTART is properly
> behind expert and it needs to be default y instead of default n.

I don't have any objection to *that*, as long as the option remains.

[PATCH] x86/events/intel/ds: Fix bts_interrupt_threshold alignment

[Hugh Dickins]

Markus reported that BTS is sporadically missing the tail of the trace
in the perf_event data buffer: [decode error (1): instruction overflow]
shown in GDB; and bisected it to the conversion of debug_store to PTI.

A little "optimization" crept into alloc_bts_buffer(), which mistakenly
placed bts_interrupt_threshold away from the 24-byte record boundary.
Intel SDM Vol 3B 17.4.9 says "This address must point to an offset from
the BTS buffer base that is a multiple of the BTS record size."

Revert "max" from a byte count to a record count, to calculate the
bts_interrupt_threshold correctly: which turns out to fix problem seen.

Fixes: c1961a4631da ("x86/events/intel/ds: Map debug buffers in cpu_entry_area")
Signed-off-by: Hugh Dickins 
Reported-and-tested-by: Markus T Metzger 
Cc:  # v4.14+
---
Sorry for the spam: I missed out [PATCH] and x...@kernel.org yesterday.

 arch/x86/events/intel/ds.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- 4.18-rc4/arch/x86/events/intel/ds.c 2018-06-03 14:15:21.0 -0700
+++ linux/arch/x86/events/intel/ds.c2018-07-12 17:38:28.471378616 -0700
@@ -408,9 +408,11 @@ static int alloc_bts_buffer(int cpu)
ds->bts_buffer_base = (unsigned long) cea;
ds_update_cea(cea, buffer, BTS_BUFFER_SIZE, PAGE_KERNEL);
ds->bts_index = ds->bts_buffer_base;
-   max = BTS_RECORD_SIZE * (BTS_BUFFER_SIZE / BTS_RECORD_SIZE);
-   ds->bts_absolute_maximum = ds->bts_buffer_base + max;
-   ds->bts_interrupt_threshold = ds->bts_absolute_maximum - (max / 16);
+   max = BTS_BUFFER_SIZE / BTS_RECORD_SIZE;
+   ds->bts_absolute_maximum = ds->bts_buffer_base +
+   max * BTS_RECORD_SIZE;
+   ds->bts_interrupt_threshold = ds->bts_absolute_maximum -
+   (max / 16) * BTS_RECORD_SIZE;
return 0;
 }
 

Re: [PATCH 1/2] mux:adgs1408/1409: New driver for Analog Devices ADGS1408/1409 mux …

[Peter Rosin]

On 2018-07-14 16:02, Lars-Peter Clausen wrote:
> On 07/14/2018 02:04 PM, Peter Rosin wrote:
> [...]
>>> +static int adgs140x_spi_reg_write(struct spi_device *spi,
>>> +   u8 reg_addr, u8 reg_data)
>>> +{
>>> +   u8 tx_buf[2];
>>> +
>>> +   tx_buf[0] = reg_addr;
>>> +   tx_buf[1] = reg_data;
>>> +
>>> +   return spi_write_then_read(spi, tx_buf, sizeof(tx_buf), NULL, 0);
>>
>>  return spi_write(spi, tx_buf, sizeof(tx_buf));
> 
> Be aware spi_write_then_read() can handle on stack buffers, spi_write() can't.
> 

How obvious...

But ok, I guess the ugliness is warranted.

Cheers,
Peter

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

[Josh Triplett]

On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote:
> For a config option that no one has come forward with an actual real
> world use case for disabling, that cost seems much too high.

The real-world use case is precisely as stated: code size, both storage
and RAM.

I regularly encounter systems I'd *like* to put Linux in that have
around 1MB of storage and 1MB of RAM, or even less.

Re: [Ksummit-discuss] bug-introducing patches

[Pavel Machek]

Hi!

> >>>The way I see it, if a commit can get one or two tested-by, it's a good
> >>>alternative to a week in -next.
> >>
> >>Agreed. Even their own actually. And I'm not kidding. Those who run large
> >>amounts of tests on certain patches could really mention is in tested-by,
> >>as opposed to the most common cases where the code was just regularly
> >>tested.
> >
> >Actually, it would be cool to get "Tested: no" and "Tested: compile"
> >tags in the commit mesages. Sometimes it is clear from the context
> >that patch was not tested (treewide update of time to 64bit), but
> >sometime it is not.
> >
> >This is especially problem for -stable, as it seems that lately
> >patches are backported from new version without any testing.
> 
> 
> When I started my own testing some five years ago, most architectures
> did not even build in stable releases. At that time, the only tests being
> done on stable release candidates were a number of build tests, and most
> of the results were ignored.
> 
> Today, we have 0day, kernelci, kerneltests, Linaro's LKFT, and more, plus
> several merge and boot tests done by individuals. Stable release candidates
> are build tested on all supported architectures, with hundreds of
...
> Sure, testing is still far from perfect and needs to be improved. However,
> requiring that every patch applied to stable releases be tested individually
> (where ? on all affected architectures ?) would be the wrong
>direction.

Well, 0day, kernelci etc... is nice... until the change is in the
driver. Most of the kernel are drivers, remember?

I don't know. I'd say that if patch is important enough for -stable,
there should be someone testing it. For core kernel changes, that can
be 0day bot, but for drivers...

And problem exists on mainline, too.

Hmm. Patch for obscure driver. Wow, nice, is WellKnownName actually
using that driver? Aha, no, he is not; he is doing global
search&replace, and did not test the patch...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

[Eric W. Biederman]

Josh Triplett  writes:

> On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote:
>> For a config option that no one has come forward with an actual real
>> world use case for disabling, that cost seems much too high.
>
> The real-world use case is precisely as stated: code size, both storage
> and RAM.

That is theoretical.  Which platform will break or feel distressed if we
make it unconditional.  That is real world.

> I regularly encounter systems I'd *like* to put Linux in that have
> around 1MB of storage and 1MB of RAM, or even less.

Yes.  There is so little code behind CONFIG_CHECKPOINT_RESTART that it
won't help with that.

But if minification is the actual requirement for disabling
CONFIG_CHECKPOINT_RESTART than CONFIG_CHECKPIONT_RESTART is properly
behind expert and it needs to be default y instead of default n.

Eric

Re: [PATCH 12/18] staging: gasket: annotate ioctl arg with __user

[Todd Poynor]

>> I think I'm following 
>> http://www.kroah.com/log/linux/linux-staging-update.html,
>> but if I'm off in the weeds do clue me in, thanks.
>
> That's something I wrote 9 years ago :)

Still the top search result for how to work in staging, suggest an update. :)

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

[Eric W. Biederman]

Kees Cook  writes:

> On Fri, Jul 13, 2018 at 1:55 PM, Andrew Morton
>  wrote:
>> On Thu, 12 Jul 2018 11:33:33 -0500 ebied...@xmission.com (Eric W. Biederman) 
>> wrote:
>>> What is the value of disabling this functionality ever?
>>>
>>> Is there any reason why we don't just delete CONFIG_CHECKPOINT_RESTORE
>>> entirely?
>>
>> For the vast number of Linux machines which aren't servers?  Check out
>> some defconfigs - only one of arm's 119 defconfigs selects it.
>
> Right, and I would bet the minification folks would like to keep it
> out of their builds too. I think we should keep the config.

I take it then you are volunteering to test with and without the config
option?

Even if the config option is kept I intend to rip it out every time I
wind up touching code with it in.  Config options have a real cost in
testing and development.

For a config option that no one has come forward with an actual real
world use case for disabling, that cost seems much too high.

Eric

Re: [PATCH v5 0/6] fs/dcache: Track & limit # of negative dentries

[Linus Torvalds]

On Sat, Jul 14, 2018 at 11:36 AM Al Viro  wrote:
>
> OK, this
> /*
>  * No ordinary (disk based) filesystem counts links as inodes;
>  * but each new link needs a new dentry, pinning lowmem, and
>  * tmpfs dentries cannot be pruned until they are unlinked.
>  */
> ret = shmem_reserve_inode(inode->i_sb);
> if (ret)
> goto out;
> will probably help (on ramfs it won't, though).

Nobody who cares about memory use would use ramfs and then allow
random users on it.

I think you can exhaust memory more easily on ramfs by just writing a
huge file. Do we have any limits at all?

ramfs is fine for things like initramfs, but I think the comment says it all:

 * NOTE! This filesystem is probably most useful
 * not as a real filesystem, but as an example of
 * how virtual filesystems can be written.

and even that comment may have been more correct back in 2000 than it is today.

 Linus

Re: [Ksummit-discuss] bug-introducing patches

[Guenter Roeck]

On 07/14/2018 10:38 AM, Pavel Machek wrote:

Hi!


The way I see it, if a commit can get one or two tested-by, it's a good
alternative to a week in -next.


Agreed. Even their own actually. And I'm not kidding. Those who run large
amounts of tests on certain patches could really mention is in tested-by,
as opposed to the most common cases where the code was just regularly
tested.


Actually, it would be cool to get "Tested: no" and "Tested: compile"
tags in the commit mesages. Sometimes it is clear from the context
that patch was not tested (treewide update of time to 64bit), but
sometime it is not.

This is especially problem for -stable, as it seems that lately
patches are backported from new version without any testing.



When I started my own testing some five years ago, most architectures
did not even build in stable releases. At that time, the only tests being
done on stable release candidates were a number of build tests, and most
of the results were ignored.

Today, we have 0day, kernelci, kerneltests, Linaro's LKFT, and more, plus
several merge and boot tests done by individuals. Stable release candidates
are build tested on all supported architectures, with hundreds of 
configurations.
Each stable release candidate is boot tested on qemu with more than 150
configurations on each architecture supported by qemu. A substantial amount of
boot tests run on real hardware. On key architectures, more sophisticated tests
such as kerneltests and LTP ensure that no new regressions are introduced.

What is new is that many more patches are being applied and backported
to stable releases, at least to degree due to Sasha's scripts, but also due
to tools like syzbot running on older kernels and finding problems which
have been fixed upstream, but the fix has not been backported.

At the same time, stable release test coverage has been improved substantially
over the last few years. I am _much_ more confident with stable releases
than I used to be a few of years ago.

Sure, there are regressions. However, the regression rate is very low (last
time I checked it was around 0.1% to 0.3% per stable release for us). Sure,
I would like to further reduce regression rate, to improve stability but also
because each and every regression is used by someone to argue that stable 
releases
would be unreliable. However, this is more a matter of perception than reality.
Reality is that more than 90% of all CVEs are fixed in stable releases by the 
time
they are published as affecting a stable release. Reality is that a substantial
percentage of problems reported by syzbot _are_ being fixed in stable releases.
Reality is that, by the time bugs are reported from the field, it is more and
more likely that we find out that the bug has already been fixed in a later
release due to a stable release merge.

Given all that, I think it is quite misleading to claim that the number of
patches applied to stable releases would create additional problems, or that
patches would be applied "without any testing". On the contrary, I would argue
that the additional testing now being performed _enabled_ us to apply more
patches (bug fixes) to stable releases.

Sure, testing is still far from perfect and needs to be improved. However,
requiring that every patch applied to stable releases be tested individually
(where ? on all affected architectures ?) would be the wrong direction.
What we need to do is to further improve test coverage. We should have no
regressions, but we need to get there by improving test coverage, not by
demanding explicit per-patch and per-release testing (which would be all
but impossible anyway - no one has the infrastructure necessary to test
a patch on all affected architectures).

I would encourage everyone interested in kernel testing to attend the
kernel test sessions at Linux Plumbers and ELC later this year to discuss
concerns and possible solutions.

Thanks,
Guenter

Re: [PATCH v5 0/6] fs/dcache: Track & limit # of negative dentries

[Al Viro]

On Sat, Jul 14, 2018 at 07:34:45PM +0100, Al Viro wrote:
> On Sat, Jul 14, 2018 at 11:00:32AM -0700, Linus Torvalds wrote:
> > On Sat, Jul 14, 2018 at 10:35 AM Pavel Machek  wrote:
> > >
> > > Could we allocate -ve entries from separate slab?
> > 
> > No, because negative dentrires don't stay negative.
> > 
> > Every single positive dentry starts out as a negative dentry that is
> > passed in to "lookup()" to maybe be made positive.
> > 
> > And most of the time they do turn positive, because most of the
> > time people actually open files that exist.
> > 
> > But then occasionally you don't, because you're just blindly opening a
> > filename whether it exists or not (to _check_ whether it's there).
> 
> BTW, one point that might not be realized by everyone: negative dentries
> are *not* the hard case.
> mount -t tmpfs none /mnt
> touch /mnt/a
> for i in `seq 10`; do ln /mnt/a /mnt/$i; done
> 
> and you've got 10 *unevictable* dentries, with the time per iteration
> being not all that high (especially if you just call link(2) in a loop).
> They are all positive and all pinned.  And you've got only one inode
> there and no persistently opened files, so rlimit and quota won't help
> any.

OK, this
/*   
 * No ordinary (disk based) filesystem counts links as inodes;
 * but each new link needs a new dentry, pinning lowmem, and
 * tmpfs dentries cannot be pruned until they are unlinked.
 */
ret = shmem_reserve_inode(inode->i_sb);
if (ret)
goto out;
will probably help (on ramfs it won't, though).

Re: [PATCH v5 0/6] fs/dcache: Track & limit # of negative dentries

[Al Viro]

On Sat, Jul 14, 2018 at 11:00:32AM -0700, Linus Torvalds wrote:
> On Sat, Jul 14, 2018 at 10:35 AM Pavel Machek  wrote:
> >
> > Could we allocate -ve entries from separate slab?
> 
> No, because negative dentrires don't stay negative.
> 
> Every single positive dentry starts out as a negative dentry that is
> passed in to "lookup()" to maybe be made positive.
> 
> And most of the time they do turn positive, because most of the
> time people actually open files that exist.
> 
> But then occasionally you don't, because you're just blindly opening a
> filename whether it exists or not (to _check_ whether it's there).

BTW, one point that might not be realized by everyone: negative dentries
are *not* the hard case.
mount -t tmpfs none /mnt
touch /mnt/a
for i in `seq 10`; do ln /mnt/a /mnt/$i; done

and you've got 10 *unevictable* dentries, with the time per iteration
being not all that high (especially if you just call link(2) in a loop).
They are all positive and all pinned.  And you've got only one inode
there and no persistently opened files, so rlimit and quota won't help
any.

Re: [PATCH v5 0/6] fs/dcache: Track & limit # of negative dentries

[Linus Torvalds]

On Sat, Jul 14, 2018 at 10:35 AM Pavel Machek  wrote:
>
> Could we allocate -ve entries from separate slab?

No, because negative dentrires don't stay negative.

Every single positive dentry starts out as a negative dentry that is
passed in to "lookup()" to maybe be made positive.

And most of the time they do turn positive, because most of the
time people actually open files that exist.

But then occasionally you don't, because you're just blindly opening a
filename whether it exists or not (to _check_ whether it's there).

  Linus

[PATCH 1/2] staging:r8188eu: Use lib80211 to encrypt (TKIP) tx frames

[Ivan Safonov]

Put data to skb, decrypt with lib80211_crypt_tkip, and place back to tx buffer.

MIC calculation will be replaced later.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_security.c | 419 +-
 1 file changed, 77 insertions(+), 342 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c 
b/drivers/staging/rtl8188eu/core/rtw_security.c
index a01290467c64..ada69efd61b3 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -12,121 +12,6 @@
 #include 
 #include 
 
-/* WEP related = */
-
-#define CRC32_POLY 0x04c11db7
-
-struct arc4context {
-   u32 x;
-   u32 y;
-   u8 state[256];
-};
-
-static void arcfour_init(struct arc4context *parc4ctx, u8 *key, u32key_len)
-{
-   u32 t, u;
-   u32 keyindex;
-   u32 stateindex;
-   u8 *state;
-   u32 counter;
-
-   state = parc4ctx->state;
-   parc4ctx->x = 0;
-   parc4ctx->y = 0;
-   for (counter = 0; counter < 256; counter++)
-   state[counter] = (u8)counter;
-   keyindex = 0;
-   stateindex = 0;
-   for (counter = 0; counter < 256; counter++) {
-   t = state[counter];
-   stateindex = (stateindex + key[keyindex] + t) & 0xff;
-   u = state[stateindex];
-   state[stateindex] = (u8)t;
-   state[counter] = (u8)u;
-   if (++keyindex >= key_len)
-   keyindex = 0;
-   }
-}
-
-static u32 arcfour_byte(struct arc4context *parc4ctx)
-{
-   u32 x;
-   u32 y;
-   u32 sx, sy;
-   u8 *state;
-
-   state = parc4ctx->state;
-   x = (parc4ctx->x + 1) & 0xff;
-   sx = state[x];
-   y = (sx + parc4ctx->y) & 0xff;
-   sy = state[y];
-   parc4ctx->x = x;
-   parc4ctx->y = y;
-   state[y] = (u8)sx;
-   state[x] = (u8)sy;
-   return state[(sx + sy) & 0xff];
-}
-
-static void arcfour_encrypt(struct arc4context *parc4ctx, u8 *dest, u8 *src, 
u32 len)
-{
-   u32 i;
-
-   for (i = 0; i < len; i++)
-   dest[i] = src[i] ^ (unsigned char)arcfour_byte(parc4ctx);
-}
-
-static int bcrc32initialized;
-static u32 crc32_table[256];
-
-static u8 crc32_reverseBit(u8 data)
-{
-   return (u8)((data<<7)&0x80) | ((data<<5)&0x40) | ((data<<3)&0x20) |
-  ((data<<1)&0x10) | ((data>>1)&0x08) | ((data>>3)&0x04) |
-  ((data>>5)&0x02) | ((data>>7)&0x01);
-}
-
-static void crc32_init(void)
-{
-   if (bcrc32initialized == 1) {
-   return;
-   } else {
-   int i, j;
-   u32 c;
-   u8 *p = (u8 *)&c, *p1;
-   u8 k;
-
-   c = 0x1234;
-
-   for (i = 0; i < 256; ++i) {
-   k = crc32_reverseBit((u8)i);
-   for (c = ((u32)k) << 24, j = 8; j > 0; --j)
-   c = c & 0x8000 ? (c << 1) ^ CRC32_POLY : (c 
<< 1);
-   p1 = (u8 *)&crc32_table[i];
-
-   p1[0] = crc32_reverseBit(p[3]);
-   p1[1] = crc32_reverseBit(p[2]);
-   p1[2] = crc32_reverseBit(p[1]);
-   p1[3] = crc32_reverseBit(p[0]);
-   }
-   bcrc32initialized = 1;
-   }
-}
-
-static __le32 getcrc32(u8 *buf, int len)
-{
-   u8 *p;
-   u32  crc;
-
-   if (bcrc32initialized == 0)
-   crc32_init();
-
-   crc = 0x;   /* preload shift register, per CRC-32 spec */
-
-   for (p = buf; len > 0; ++p, --len)
-   crc = crc32_table[(crc ^ *p) & 0xff] ^ (crc >> 8);
-   return cpu_to_le32(~crc);/* transmit complement, per CRC-32 spec */
-}
-
 /*
Need to consider the fragment  situation
 */
@@ -395,202 +280,24 @@ void rtw_seccalctkipmic(u8 *key, u8 *header, u8 *data, 
u32 data_len, u8 *mic_cod
 #define P1K_SIZE10/*  80-bit Phase1 key*/
 #define RC4_KEY_SIZE 16/* 128-bit RC4KEY (104 bits unknown) */
 
-/* 2-unsigned char by 2-unsigned char subset of the full AES S-box table */
-static const unsigned short Sbox1[2][256] = {  /* Sbox for hash (can be in 
ROM) */
-{
-   0xC6A5, 0xF884, 0xEE99, 0xF68D, 0xFF0D, 0xD6BD, 0xDEB1, 0x9154,
-   0x6050, 0x0203, 0xCEA9, 0x567D, 0xE719, 0xB562, 0x4DE6, 0xEC9A,
-   0x8F45, 0x1F9D, 0x8940, 0xFA87, 0xEF15, 0xB2EB, 0x8EC9, 0xFB0B,
-   0x41EC, 0xB367, 0x5FFD, 0x45EA, 0x23BF, 0x53F7, 0xE496, 0x9B5B,
-   0x75C2, 0xE11C, 0x3DAE, 0x4C6A, 0x6C5A, 0x7E41, 0xF502, 0x834F,
-   0x685C, 0x51F4, 0xD134, 0xF908, 0xE293, 0xAB73, 0x6253, 0x2A3F,
-   0x080C, 0x9552, 0x4665, 0x9D5E, 0x3028, 0x37A1, 0x0A0F, 0x2FB5,
-   0x0E09, 0x2436, 0x1B9B, 0xDF3D, 0xCD26, 0x4E69, 0x7FCD, 0xEA9F,
-   0x121B, 0x1D9E, 0x5874, 0x342E, 0x362D, 0xDCB2, 0xB4EE, 0x5BFB,
-   0xA4F6, 0x764D, 0xB761, 0x7DCE, 0x527B, 0xDD3E, 0x5E71, 0x1397,
-   0xA6

[PATCH 2/2] staging:r8188eu: Use lib80211 to encrypt (CCMP) tx frames

[Ivan Safonov]

Put data to skb, decrypt with lib80211_crypt_ccmp, and place back to tx buffer.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_security.c | 778 +++---
 1 file changed, 72 insertions(+), 706 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c 
b/drivers/staging/rtl8188eu/core/rtw_security.c
index ada69efd61b3..508d3299b4e9 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -462,554 +462,107 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8 
*precvframe)
return res;
 }
 
-/* 3   = AES related = */
-
-
-#define MAX_MSG_SIZE   2048
-/*/
-/ SBOX Table */
-/*/
-
-static  u8 sbox_table[256] = {
-   0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5,
-   0x30, 0x01, 0x67, 0x2b, 0xfe, 0xd7, 0xab, 0x76,
-   0xca, 0x82, 0xc9, 0x7d, 0xfa, 0x59, 0x47, 0xf0,
-   0xad, 0xd4, 0xa2, 0xaf, 0x9c, 0xa4, 0x72, 0xc0,
-   0xb7, 0xfd, 0x93, 0x26, 0x36, 0x3f, 0xf7, 0xcc,
-   0x34, 0xa5, 0xe5, 0xf1, 0x71, 0xd8, 0x31, 0x15,
-   0x04, 0xc7, 0x23, 0xc3, 0x18, 0x96, 0x05, 0x9a,
-   0x07, 0x12, 0x80, 0xe2, 0xeb, 0x27, 0xb2, 0x75,
-   0x09, 0x83, 0x2c, 0x1a, 0x1b, 0x6e, 0x5a, 0xa0,
-   0x52, 0x3b, 0xd6, 0xb3, 0x29, 0xe3, 0x2f, 0x84,
-   0x53, 0xd1, 0x00, 0xed, 0x20, 0xfc, 0xb1, 0x5b,
-   0x6a, 0xcb, 0xbe, 0x39, 0x4a, 0x4c, 0x58, 0xcf,
-   0xd0, 0xef, 0xaa, 0xfb, 0x43, 0x4d, 0x33, 0x85,
-   0x45, 0xf9, 0x02, 0x7f, 0x50, 0x3c, 0x9f, 0xa8,
-   0x51, 0xa3, 0x40, 0x8f, 0x92, 0x9d, 0x38, 0xf5,
-   0xbc, 0xb6, 0xda, 0x21, 0x10, 0xff, 0xf3, 0xd2,
-   0xcd, 0x0c, 0x13, 0xec, 0x5f, 0x97, 0x44, 0x17,
-   0xc4, 0xa7, 0x7e, 0x3d, 0x64, 0x5d, 0x19, 0x73,
-   0x60, 0x81, 0x4f, 0xdc, 0x22, 0x2a, 0x90, 0x88,
-   0x46, 0xee, 0xb8, 0x14, 0xde, 0x5e, 0x0b, 0xdb,
-   0xe0, 0x32, 0x3a, 0x0a, 0x49, 0x06, 0x24, 0x5c,
-   0xc2, 0xd3, 0xac, 0x62, 0x91, 0x95, 0xe4, 0x79,
-   0xe7, 0xc8, 0x37, 0x6d, 0x8d, 0xd5, 0x4e, 0xa9,
-   0x6c, 0x56, 0xf4, 0xea, 0x65, 0x7a, 0xae, 0x08,
-   0xba, 0x78, 0x25, 0x2e, 0x1c, 0xa6, 0xb4, 0xc6,
-   0xe8, 0xdd, 0x74, 0x1f, 0x4b, 0xbd, 0x8b, 0x8a,
-   0x70, 0x3e, 0xb5, 0x66, 0x48, 0x03, 0xf6, 0x0e,
-   0x61, 0x35, 0x57, 0xb9, 0x86, 0xc1, 0x1d, 0x9e,
-   0xe1, 0xf8, 0x98, 0x11, 0x69, 0xd9, 0x8e, 0x94,
-   0x9b, 0x1e, 0x87, 0xe9, 0xce, 0x55, 0x28, 0xdf,
-   0x8c, 0xa1, 0x89, 0x0d, 0xbf, 0xe6, 0x42, 0x68,
-   0x41, 0x99, 0x2d, 0x0f, 0xb0, 0x54, 0xbb, 0x16
-};
-
-/*/
-/ Function Prototypes /
-/*/
-
-static void bitwise_xor(u8 *ina, u8 *inb, u8 *out);
-static void construct_mic_iv(u8 *mic_header1, int qc_exists, int a4_exists, u8 
*mpdu, uint payload_length, u8 *pn_vector);
-static void construct_mic_header1(u8 *mic_header1, int header_length, u8 
*mpdu);
-static void construct_mic_header2(u8 *mic_header2, u8 *mpdu, int a4_exists, 
int qc_exists);
-static void construct_ctr_preload(u8 *ctr_preload, int a4_exists, int 
qc_exists, u8 *mpdu, u8 *pn_vector, int c);
-static void xor_128(u8 *a, u8 *b, u8 *out);
-static void xor_32(u8 *a, u8 *b, u8 *out);
-static u8 sbox(u8 a);
-static void next_key(u8 *key, int round);
-static void byte_sub(u8 *in, u8 *out);
-static void shift_row(u8 *in, u8 *out);
-static void mix_column(u8 *in, u8 *out);
-static void aes128k128d(u8 *key, u8 *data, u8 *ciphertext);
-
-//
-/* aes128k128d()   */
-/* Performs a 128 bit AES encrypt with  */
-/* 128 bit data.   */
-//
-static void xor_128(u8 *a, u8 *b, u8 *out)
-{
-   int i;
-
-   for (i = 0; i < 16; i++)
-   out[i] = a[i] ^ b[i];
-}
-
-static void xor_32(u8 *a, u8 *b, u8 *out)
-{
-   int i;
-
-   for (i = 0; i < 4; i++)
-   out[i] = a[i] ^ b[i];
-}
-
-static u8 sbox(u8 a)
-{
-   return sbox_table[(int)a];
-}
-
-static void next_key(u8 *key, int round)
-{
-   u8 rcon;
-   u8 sbox_key[4];
-   u8 rcon_table[12] = {
-   0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80,
-   0x1b, 0x36, 0x36, 0x36
-   };
-
-   sbox_key[0] = sbox(key[13]);
-   sbox_key[1] = sbox(key[14]);
-   sbox_key[2] = sbox(key[15]);
-   sbox_key[3] = sbox(key[12]);
-
-   rcon = rcon_table[round];
-
-   xor_32(&key[0], sbox_key, &key[0]);
-   key[0] = key[0] ^ rcon;
-
-   xor_32(&key[4], &key[0], &key[4]);
-   xor_32(&key[8], &key[4], &key[8]);
-   xor_32(&key[12], &key[8], &key[12]);
-}
-
-static void byte_sub(u8 *in, u8 *out)
-{
-   int i;
-   for (i = 0; i < 16; i++)
-   out[i] = sbox(in[i]);
-}
-
-static void shift_row(u8 *in, u8 *out)
-{
-   out[0] =  in[0];
-   out[1] =  in[5];
-   out[2] =  in[10];
-   out[3] 

Re: bug-introducing patches

[Pavel Machek]

Hi!

> > The way I see it, if a commit can get one or two tested-by, it's a good
> > alternative to a week in -next.
> 
> Agreed. Even their own actually. And I'm not kidding. Those who run large
> amounts of tests on certain patches could really mention is in tested-by,
> as opposed to the most common cases where the code was just regularly
> tested.

Actually, it would be cool to get "Tested: no" and "Tested: compile"
tags in the commit mesages. Sometimes it is clear from the context
that patch was not tested (treewide update of time to 64bit), but
sometime it is not.

This is especially problem for -stable, as it seems that lately
patches are backported from new version without any testing.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v5 0/6] fs/dcache: Track & limit # of negative dentries

[Pavel Machek]

> > Yes, "should be".  I could understand that the presence of huge
> > nunmbers of -ve dentries could result in undesirable reclaim of
> > pagecache, etc.  Triggering oom-killings is very bad, and presumably
> > has the same cause.
> > 
> > Before we go and add a large amount of code to do the shrinker's job
> > for it, we should get a full understanding of what's going wrong.  Is
> > it because the dentry_lru had a mixture of +ve and -ve dentries? 
> > Should we have a separate LRU for -ve dentries?  Are we appropriately
> > aging the various dentries?  etc.
> > 
> > It could be that tuning/fixing the current code will fix whatever
> > problems inspired this patchset.
> 
> What I think is contributing to the problems and could lead to reclaim
> oddities is the internal fragmentation of dentry slab cache. Dentries are
> relatively small, you get 21 per page on my system, so if trivial to
> reclaim negative dentries get mixed with a small amount of unreclaimable
> positive dentries, you can get a lot of pages in dentry slab cache that are
> unreclaimable.

Could we allocate -ve entries from separate slab?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v5 5/7] Bluetooth: Extend btuart driver for join more vendor devices

[Marcel Holtmann]

Hi Sean,

> Adding an independent btuart.h header allows these essential definitions
> can be reused in vendor driver. Also, struct btuart_vnd is extended with
> additional callbacks such as .init initializing vendor data, .shtudown,
> .recv and .send supporting SoC specific framing for that btuart can
> simply adapt to various Bluetooth uart-based devices.
> 
> Signed-off-by: Sean Wang 
> ---
> drivers/bluetooth/btuart.c | 73 --
> drivers/bluetooth/btuart.h | 30 +++
> 2 files changed, 68 insertions(+), 35 deletions(-)
> create mode 100644 drivers/bluetooth/btuart.h
> 
> diff --git a/drivers/bluetooth/btuart.c b/drivers/bluetooth/btuart.c
> index a900aac..65d0086 100644
> --- a/drivers/bluetooth/btuart.c
> +++ b/drivers/bluetooth/btuart.c
> @@ -33,35 +33,11 @@
> #include 
> 
> #include "h4_recv.h"
> +#include "btuart.h"
> #include "btbcm.h"
> 
> #define VERSION "1.0"
> 
> -struct btuart_vnd {
> - const struct h4_recv_pkt *recv_pkts;
> - int recv_pkts_cnt;
> - unsigned int manufacturer;
> - int (*open)(struct hci_dev *hdev);
> - int (*close)(struct hci_dev *hdev);
> - int (*setup)(struct hci_dev *hdev);
> -};
> -
> -struct btuart_dev {
> - struct hci_dev *hdev;
> - struct serdev_device *serdev;
> -
> - struct work_struct tx_work;
> - unsigned long tx_state;
> - struct sk_buff_head txq;
> -
> - struct sk_buff *rx_skb;
> -
> - const struct btuart_vnd *vnd;
> -};

I really like to avoid this since it is not clean. Frankly I prefer to keep the 
btuart.c driver for drivers that really just use H:4 as transport protocol. If 
the protocol is only H:4 alike and has extra headers, then it should be a 
separate driver.

The common H:4 handling is abstracted in h4_recv.h already anyway and we can 
add more pieces if needed. However I also wonder since you have extra framing 
that the complex H:4 state keeping might be not needed at all. So it could be 
simplified.

Regards

Marcel

Re: [PATCH v5 4/7] Bluetooth: Add new quirk for non-persistent setup settings

[Marcel Holtmann]

Hi Sean,

> Add a new quirk HCI_QUIRK_NON_PERSISTENT_SETUP allowing that a quirk that
> runs setup() after every open() and not just after the first open().
> 
> Signed-off-by: Sean Wang 
> ---
> include/net/bluetooth/hci.h | 9 +
> net/bluetooth/hci_core.c| 3 ++-
> 2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index 73e48be..d3ec5b2a8 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -183,6 +183,15 @@ enum {
>* during the hdev->setup vendor callback.
>*/
>   HCI_QUIRK_NON_PERSISTENT_DIAG,
> +
> + /* When this quirk is set, setup() would be run after every
> +  * open() and not just after the first open().
> +  *
> +  * This quirk can be set before hci_register_dev is called or
> +  * during the hdev->setup vendor callback.
> +  *
> +  */
> + HCI_QUIRK_NON_PERSISTENT_SETUP,
> };
> 
> /* HCI device flags */
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index f5c21004..0111280 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -1396,7 +1396,8 @@ static int hci_dev_do_open(struct hci_dev *hdev)
>   atomic_set(&hdev->cmd_cnt, 1);
>   set_bit(HCI_INIT, &hdev->flags);
> 
> - if (hci_dev_test_flag(hdev, HCI_SETUP)) {
> + if (hci_dev_test_flag(hdev, HCI_SETUP) ||
> + test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
>   hci_sock_dev_event(hdev, HCI_DEV_SETUP);

can you include the extract of btmon on how the HCI_DEV_SETUP event shows up in 
the traces? I remember that I asked about something like that.

Regards

Marcel

[PATCH] vme: ca91cx42: remove redundant variable i

[Colin King]

From: Colin Ian King 

Variable i is being assigned but is never used hence it is redundant
and can be removed.

Cleans up clang warning:
warning: variable 'i' set but not used [-Wunused-but-set-variable]

Signed-off-by: Colin Ian King 
---
 drivers/vme/bridges/vme_ca91cx42.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/vme/bridges/vme_ca91cx42.c 
b/drivers/vme/bridges/vme_ca91cx42.c
index 5dd284008630..53bdc256805f 100644
--- a/drivers/vme/bridges/vme_ca91cx42.c
+++ b/drivers/vme/bridges/vme_ca91cx42.c
@@ -970,7 +970,6 @@ static unsigned int ca91cx42_master_rmw(struct 
vme_master_resource *image,
 {
u32 result;
uintptr_t pci_addr;
-   int i;
struct ca91cx42_driver *bridge;
struct device *dev;
 
@@ -978,7 +977,6 @@ static unsigned int ca91cx42_master_rmw(struct 
vme_master_resource *image,
dev = image->parent->parent;
 
/* Find the PCI address that maps to the desired VME address */
-   i = image->number;
 
/* Locking as we can only do one of these at a time */
mutex_lock(&bridge->vme_rmw);
-- 
2.17.1

Re: [PATCH v5 6/7] Bluetooth: mediatek: Add protocol support for MediaTek serial devices

[Marcel Holtmann]

Hi Sean,

> This adds a driver to run on the top of btuart driver for the MediaTek
> serial protocol based on running H:4, which can enable the built-in
> Bluetooth device inside MT7622 SoC.
> 
> Signed-off-by: Sean Wang 
> ---
> drivers/bluetooth/Kconfig |  11 ++
> drivers/bluetooth/Makefile|   2 +
> drivers/bluetooth/btmtkuart.c | 352 ++
> drivers/bluetooth/btmtkuart.h | 116 ++
> drivers/bluetooth/btuart.c|  18 +++
> 5 files changed, 499 insertions(+)
> create mode 100644 drivers/bluetooth/btmtkuart.c
> create mode 100644 drivers/bluetooth/btmtkuart.h
> 
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 00fdf5f..4d7d640 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -85,6 +85,17 @@ config BT_HCIBTUART
> Say Y here to compile support for Bluetooth UART devices into the
> kernel or say M to compile it as module (btuart).
> 
> +config BT_HCIBTUART_MTK
> + tristate "MediaTek HCI UART driver"
> + depends on BT_HCIBTUART
> + help
> +   MediaTek Bluetooth HCI UART driver.
> +   This driver is required if you want to use MediaTek Bluetooth
> +   with serial interface.
> +
> +   Say Y here to compile support for MediaTek Bluetooth UART devices
> +   into the kernel or say M to compile it as module (btmtkuart).
> +
> config BT_HCIUART
>   tristate "HCI UART driver"
>   depends on SERIAL_DEV_BUS || !SERIAL_DEV_BUS
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index 60a19cb..c9a8926 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -26,6 +26,8 @@ obj-$(CONFIG_BT_BCM)+= btbcm.o
> obj-$(CONFIG_BT_RTL)  += btrtl.o
> obj-$(CONFIG_BT_QCA)  += btqca.o
> 
> +obj-$(CONFIG_BT_HCIBTUART_MTK)   += btmtkuart.o
> +
> obj-$(CONFIG_BT_HCIUART_NOKIA)+= hci_nokia.o
> 
> obj-$(CONFIG_BT_HCIRSI)   += btrsi.o
> diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
> new file mode 100644
> index 000..9eed21c
> --- /dev/null
> +++ b/drivers/bluetooth/btmtkuart.c
> @@ -0,0 +1,352 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2018 MediaTek Inc.
> +
> +/*
> + * Bluetooth support for MediaTek serial devices
> + *
> + * Author: Sean Wang 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "btmtkuart.h"
> +#include "btuart.h"
> +#include "h4_recv.h"
> +
> +static void mtk_stp_reset(struct mtk_stp_splitter *sp)
> +{
> + sp->cursor = 2;
> + sp->dlen = 0;
> +}
> +
> +static const unsigned char *
> +mtk_stp_split(struct btuart_dev *bdev, struct mtk_stp_splitter *sp,
> +   const unsigned char *data, int count, int *sz_h4)
> +{
> + struct mtk_stp_hdr *shdr;
> +
> + /* The cursor is reset when all the data of STP is consumed out. */
> + if (!sp->dlen && sp->cursor >= 6)
> + sp->cursor = 0;
> +
> + /* Filling pad until all STP info is obtained. */
> + while (sp->cursor < 6 && count > 0) {
> + sp->pad[sp->cursor] = *data;
> + sp->cursor++;
> + data++;
> + count--;
> + }
> +
> + /* Retrieve STP info and have a sanity check. */
> + if (!sp->dlen && sp->cursor >= 6) {
> + shdr = (struct mtk_stp_hdr *)&sp->pad[2];
> + sp->dlen = shdr->dlen1 << 8 | shdr->dlen2;
> +
> + /* Resync STP when unexpected data is being read. */
> + if (shdr->prefix != 0x80 || sp->dlen > 2048) {
> + bt_dev_err(bdev->hdev, "stp format unexpect (%d, %d)",
> +shdr->prefix, sp->dlen);
> + mtk_stp_reset(sp);
> + }
> + }
> +
> + /* Directly quit when there's no data found for H4 can process. */
> + if (count <= 0)
> + return NULL;
> +
> + /* Tranlate to how much the size of data H4 can handle so far. */
> + *sz_h4 = min_t(int, count, sp->dlen);
> + /* Update the remaining size of STP packet. */
> + sp->dlen -= *sz_h4;
> +
> + /* Data points to STP payload which can be handled by H4. */
> + return data;
> +}
> +
> +static int mtk_stp_send(struct btuart_dev *bdev, struct sk_buff *skb)
> +{
> + struct mtk_stp_hdr *shdr;
> + struct sk_buff *new_skb;
> + int dlen;
> +
> + memcpy(skb_push(skb, 1), &hci_skb_pkt_type(skb), 1);
> + dlen = skb->len;
> +
> + /* Make sure of STP header at least has 4-bytes free space to fill. */
> + if (unlikely(skb_headroom(skb) < sizeof(*shdr))) {
> + new_skb = skb_realloc_headroom(skb, sizeof(*shdr));
> + kfree_skb(skb);
> + skb = new_skb;
> + }
> +
> + /* Build for STP packet format. */
> + shdr = skb_push(skb, sizeof(*shdr));
> + mtk_make_stp_hdr(shdr, 0, dlen);
> +

Re: [PATCH v5 2/7] serdev: add dev_pm_domain_attach|detach()

[Marcel Holtmann]

Hi Sean,

> In order to open up the required power gate before any operation can be
> effectively performed over the serial bus between CPU and serdev, it's
> clearly essential to add common attach functions for PM domains to serdev
> at the probe phase.
> 
> Similarly, the relevant dettach function for the PM domains should be
> properly and reversely added at the remove phase.
> 
> Signed-off-by: Sean Wang 
> Reviewed-by: Ulf Hansson 
> Cc: Rob Herring 
> Cc: Ulf Hansson 
> Cc: Greg Kroah-Hartman 
> Cc: Jiri Slaby 
> Cc: linux-ser...@vger.kernel.org
> ---
> drivers/tty/serdev/core.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)

can we take this through the serial subsystem? Or should I just take it when 
the driver is ready to be included?

Regards

Marcel

Re: [PATCH v5 1/7] dt-bindings: net: bluetooth: Add mediatek-bluetooth

[Marcel Holtmann]

Hi Sean,

> Add binding document for a SoC built-in device using MediaTek protocol.
> Which could be found on MT7622 SoC or other similar MediaTek SoCs.
> 
> Signed-off-by: Sean Wang 
> Reviewed-by: Rob Herring 
> ---
> .../devicetree/bindings/net/mediatek-bluetooth.txt | 35 ++
> 1 file changed, 35 insertions(+)
> create mode 100644 
> Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt 
> b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
> new file mode 100644
> index 000..1335429
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt
> @@ -0,0 +1,35 @@
> +MediaTek SoC built-in Bluetooth Devices
> +==
> +
> +This device is a serial attached device to BTIF device and thus it must be a
> +child node of the serial node with BTIF. The dt-bindings details for BTIF
> +device can be known via Documentation/devicetree/bindings/serial/8250.txt.
> +
> +Required properties:
> +
> +- compatible:Must be one of
> +   "mediatek,mt7622-bluetooth"": for MT7622 SoC

this does not match with the example below. And one of, should be normally be a 
list.

> +- clocks:Should be the clock specifiers corresponding to the entry in
> + clock-names property.
> +- clock-names:   Should contain "ref" entries.
> +- power-domains: Phandle to the power domain that the device is part of
> +
> +Example:
> +
> + btif: serial@1100c000 {
> + compatible = "mediatek,mt7622-btif",
> +  "mediatek,mtk-btif";
> + reg = <0 0x1100c000 0 0x1000>;
> + interrupts = ;
> + clocks = <&pericfg CLK_PERI_BTIF_PD>;
> + clock-names = "main";
> + reg-shift = <2>;
> + reg-io-width = <4>;
> +
> + bluetooth {
> + compatible = "mediatek,mt7622-bluetooth";
> + power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>;
> + clocks = <&clk25m>;
> + clock-names = "ref";
> + };
> + };

Regards

Marcel

[PATCH] keys: trusted: remove redundant variable keyhndl

[Colin King]

From: Colin Ian King 

Variable keyhndl is being assigned but is never used hence it is
redundant and can be removed.

Cleans up clang warning:
warning: variable 'keyhndl' set but not used [-Wunused-but-set-variable]

Signed-off-by: Colin Ian King 
---
 security/keys/trusted.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index b69d3b1777c2..0400c1a00467 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -585,7 +585,6 @@ static int tpm_unseal(struct tpm_buf *tb,
uint32_t authhandle2 = 0;
unsigned char cont = 0;
uint32_t ordinal;
-   uint32_t keyhndl;
int ret;
 
/* sessions for unsealing key and data */
@@ -601,7 +600,6 @@ static int tpm_unseal(struct tpm_buf *tb,
}
 
ordinal = htonl(TPM_ORD_UNSEAL);
-   keyhndl = htonl(SRKHANDLE);
ret = tpm_get_random(NULL, nonceodd, TPM_NONCE_SIZE);
if (ret != TPM_NONCE_SIZE) {
pr_info("trusted_key: tpm_get_random failed (%d)\n", ret);
-- 
2.17.1

Re: [PATCH] rtc: jz4740: Add support for the JZ4725B, JZ4760, JZ4770

[Alexandre Belloni]

On 14/07/2018 15:50:08+0200, Paul Cercueil wrote:
> > >  > This would avoid that change (and the test would preferably be
> > >  > (rtc->type == ID_JZ4780))
> > > 
> > >  That branch should be taken if the SoC is JZ4760, JZ4770 or JZ4780.
> > >  It should not be taken if the SoC is JZ4740 or JZ4725B.
> > 
> > Sure but you can achieve that with only 2 ids...
> > 
> > > 
> > >  > >  ret = jz4780_rtc_enable_write(rtc);
> > >  > >  if (ret == 0)
> > >  > >  ret = jz4740_rtc_wait_write_ready(rtc);
> > >  > >  @@ -300,6 +303,9 @@ static void jz4740_rtc_power_off(void)
> > >  > >
> > >  > >   static const struct of_device_id jz4740_rtc_of_match[] = {
> > >  > >  { .compatible = "ingenic,jz4740-rtc", .data = (void
> > > *)ID_JZ4740 },
> > >  > >  +   { .compatible = "ingenic,jz4725b-rtc", .data = (void
> > > *)ID_JZ4725B
> > >  > > },
> > >  > >  +   { .compatible = "ingenic,jz4760-rtc", .data = (void
> > > *)ID_JZ4760 },
> > >  > >  +   { .compatible = "ingenic,jz4770-rtc", .data = (void
> > > *)ID_JZ4770 },
> > 
> > By doing the correct mapping here e.g:
> > 
> > { .compatible = "ingenic,jz4725b-rtc", .data = (void *)ID_JZ4740 },
> 
> Not very pretty and future-proof if you ask me...
> But you're the boss...
> 

I think it makes the code simpler to follow . Regarding future
proofness, you will have to add code and probably use a switch case at
the time you need to handle an RTC differently. At that time, the >=
test trick will not work anymore anyway.


-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[PATCH] apparmor: remove redundant pointer 'info'

[Colin King]

From: Colin Ian King 

Pointer 'info' is being assigned but is never used hence it is
redundant and can be removed.

Cleans up clang warning:
warning: variable 'info' set but not used [-Wunused-but-set-variable]

Signed-off-by: Colin Ian King 
---
 security/apparmor/domain.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/security/apparmor/domain.c b/security/apparmor/domain.c
index 098d546d8253..410d9ce09861 100644
--- a/security/apparmor/domain.c
+++ b/security/apparmor/domain.c
@@ -1006,7 +1006,6 @@ static struct aa_label *build_change_hat(struct 
aa_profile *profile,
 const char *name, bool sibling)
 {
struct aa_profile *root, *hat = NULL;
-   const char *info = NULL;
int error = 0;
 
if (sibling && PROFILE_IS_HAT(profile)) {
@@ -1014,7 +1013,6 @@ static struct aa_label *build_change_hat(struct 
aa_profile *profile,
} else if (!sibling && !PROFILE_IS_HAT(profile)) {
root = aa_get_profile(profile);
} else {
-   info = "conflicting target types";
error = -EPERM;
goto audit;
}
@@ -1025,10 +1023,8 @@ static struct aa_label *build_change_hat(struct 
aa_profile *profile,
if (COMPLAIN_MODE(profile)) {
hat = aa_new_null_profile(profile, true, name,
  GFP_KERNEL);
-   if (!hat) {
-   info = "failed null profile create";
+   if (!hat)
error = -ENOMEM;
-   }
}
}
aa_put_profile(root);
-- 
2.17.1

Re: [PATCH] gpio: mxc: add power management support

[Fabio Estevam]

Hi Anson,

On Fri, Jul 13, 2018 at 10:53 PM, Anson Huang  wrote:

> Here are the details, i.MX7D LPSR mode and i.MX8QM/8QXP etc.' suspend/resume
> may cause GPIO bank lose power, so need to save/restore, for other i.MX SoCs,
> although no need to do save/restore, but doing it is NOT harmful, so do you 
> think
> we should add SoC type check here?

I think it would be safer to restrict the save/restore operations to mx7/mx8.

You can add a fsl,imx7d-gpio compatible entry in the driver.

Thanks

[PATCH] mm/hmm.c: remove redundant variables align_start and align_end

[Colin King]

From: Colin Ian King 

Variables align_start and align_end are being assigned but are
never used hence they are redundant and can be removed.

Cleans up clang warnings:
warning: variable 'align_start' set but not used [-Wunused-but-set-variable]
warning: variable 'align_size' set but not used [-Wunused-but-set-variable]

Signed-off-by: Colin Ian King 
---
 mm/hmm.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/mm/hmm.c b/mm/hmm.c
index caf9df27599e..76e7a058b32f 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -973,10 +973,7 @@ static RADIX_TREE(hmm_devmem_radix, GFP_KERNEL);
 
 static void hmm_devmem_radix_release(struct resource *resource)
 {
-   resource_size_t key, align_start, align_size;
-
-   align_start = resource->start & ~(PA_SECTION_SIZE - 1);
-   align_size = ALIGN(resource_size(resource), PA_SECTION_SIZE);
+   resource_size_t key;
 
mutex_lock(&hmm_devmem_lock);
for (key = resource->start;
-- 
2.17.1

Re: [PATCH V2] ARM: dts: imx6sl-evk: add missing GPIO iomux setting

[Fabio Estevam]

Hi Anson,

On Fri, Jul 13, 2018 at 10:53 PM, Anson Huang  wrote:
> On i.MX6SL EVK board, the MX6SL_PAD_KEY_ROW5 pin is
> used as lcd 3v3 regulator control pin, need to make
> sure MX6SL_PAD_KEY_ROW5 is muxed as GPIO function
> for controlling lcd 3v3 regulator.
>
> Signed-off-by: Anson Huang 

Looks good now, thanks:

Reviewed-by; Fabio Estevam 

Re: [PATCH] IB/mlx5: avoid binding a new mpi unit to the same devices repeatedly

[Or Gerlitz]

On Sat, Jul 14, 2018 at 2:50 AM, Qing Huang  wrote:
> When a CX5 device is configured in dual-port RoCE mode, after creating
> many VFs against port 1, creating the same number of VFs against port 2
> will flood kernel/syslog with something like
> "mlx5_*:mlx5_ib_bind_slave_port:4266:(pid 5269): port 2 already
> affiliated."
>
> So basically, when traversing mlx5_ib_dev_list, mlx5_ib_add_slave_port()
> shouldn't repeatedly attempt to bind the new mpi data unit to every device
> on the list until it finds an unbound device.

Daniel,

What is mpi data unit?

Or.

>
> Reported-by: Gerald Gibson 
> Signed-off-by: Qing Huang 
> ---
>  drivers/infiniband/hw/mlx5/main.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/mlx5/main.c 
> b/drivers/infiniband/hw/mlx5/main.c
> index b3ba9a2..1ddd1d3 100644
> --- a/drivers/infiniband/hw/mlx5/main.c
> +++ b/drivers/infiniband/hw/mlx5/main.c
> @@ -6068,7 +6068,8 @@ static void *mlx5_ib_add_slave_port(struct 
> mlx5_core_dev *mdev, u8 port_num)
>
> mutex_lock(&mlx5_ib_multiport_mutex);
> list_for_each_entry(dev, &mlx5_ib_dev_list, ib_dev_list) {
> -   if (dev->sys_image_guid == mpi->sys_image_guid)
> +   if (dev->sys_image_guid == mpi->sys_image_guid &&
> +   !dev->port[mlx5_core_native_port_num(mdev) - 1].mp.mpi)
> bound = mlx5_ib_bind_slave_port(dev, mpi);
>
> if (bound) {
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] staging: comedi: comedi_fops: Shift assignment operator '=' to previous line

[Nishad Kamdar]

Shift '=' assignment operator to the end of previous
line to conform to preferred kernel style line wrapping.
Issue reported by checkpatch CHECK.

Signed-off-by: Nishad Kamdar 
---
 drivers/staging/comedi/comedi_fops.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/comedi_fops.c 
b/drivers/staging/comedi/comedi_fops.c
index 1f3b1106f478..e18b61cdbdeb 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -79,8 +79,8 @@ MODULE_PARM_DESC(comedi_default_buf_size_kb,
 "default asynchronous buffer size in KiB (default "
 __MODULE_STRING(CONFIG_COMEDI_DEFAULT_BUF_SIZE_KB) ")");
 
-unsigned int comedi_default_buf_maxsize_kb
-   = CONFIG_COMEDI_DEFAULT_BUF_MAXSIZE_KB;
+unsigned int comedi_default_buf_maxsize_kb =
+   CONFIG_COMEDI_DEFAULT_BUF_MAXSIZE_KB;
 module_param(comedi_default_buf_maxsize_kb, uint, 0644);
 MODULE_PARM_DESC(comedi_default_buf_maxsize_kb,
 "default maximum size of asynchronous buffer in KiB (default "
-- 
2.17.1

Re: [PATCH] mm: avoid bothering interrupted task when charge memcg in softirq

[Shakeel Butt]

On Sat, Jul 14, 2018 at 1:32 AM Yafang Shao  wrote:
>
> try_charge maybe executed in packet receive path, which is in interrupt
> context.
> In this situation, the 'current' is the interrupted task, which may has
> no relation to the rx softirq, So it is nonsense to use 'current'.
>

Have you actually seen this occurring? I am not very familiar with the
network code but I can think of two ways try_charge() can be called
from network code. Either through kmem charging or through
mem_cgroup_charge_skmem() and both locations correctly handle
interrupt context.

Shakeel

[PATCH v2 2/2] pinctrl: meson-g12a: add pinctrl driver support

[Yixun Lan]

Add the pinctrl driver for Meson-G12A SoC which share the similar IP as
the previous Meson-AXG SoC.

Starting from Meson-AXG SoC, the pinctrl controller block use 4
continues register bits to specific the pin mux function, while comparing
to old generation SoC which using variable length register bits for
the pin mux definition. The new design greatly simplify the software model.

For the detail example, one 32bit register can be divided into 8 parts,
each has 4 bits whose value start from 0 - 7, each can describe one pin,
the value 0 is always devoted to GPIO function, while 1 - 7 devoted to
the mux pin function.

Please note, the GPIOE is actually located at AO (always on) bank.

Acked-by: Martin Blumenstingl 
Signed-off-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 drivers/pinctrl/meson/Kconfig  |6 +
 drivers/pinctrl/meson/Makefile |1 +
 drivers/pinctrl/meson/pinctrl-meson-g12a.c | 1433 
 3 files changed, 1440 insertions(+)
 create mode 100644 drivers/pinctrl/meson/pinctrl-meson-g12a.c

diff --git a/drivers/pinctrl/meson/Kconfig b/drivers/pinctrl/meson/Kconfig
index c80951d6caff..9ab537eb78a3 100644
--- a/drivers/pinctrl/meson/Kconfig
+++ b/drivers/pinctrl/meson/Kconfig
@@ -47,4 +47,10 @@ config PINCTRL_MESON_AXG
 config PINCTRL_MESON_AXG_PMX
bool
 
+config PINCTRL_MESON_G12A
+   bool "Meson g12a Soc pinctrl driver"
+   depends on ARM64
+   select PINCTRL_MESON_AXG_PMX
+   default y
+
 endif
diff --git a/drivers/pinctrl/meson/Makefile b/drivers/pinctrl/meson/Makefile
index 3c6580c2d9d7..cf283f48f9d8 100644
--- a/drivers/pinctrl/meson/Makefile
+++ b/drivers/pinctrl/meson/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_PINCTRL_MESON_GXBB) += pinctrl-meson-gxbb.o
 obj-$(CONFIG_PINCTRL_MESON_GXL) += pinctrl-meson-gxl.o
 obj-$(CONFIG_PINCTRL_MESON_AXG_PMX) += pinctrl-meson-axg-pmx.o
 obj-$(CONFIG_PINCTRL_MESON_AXG) += pinctrl-meson-axg.o
+obj-$(CONFIG_PINCTRL_MESON_G12A) += pinctrl-meson-g12a.o
diff --git a/drivers/pinctrl/meson/pinctrl-meson-g12a.c 
b/drivers/pinctrl/meson/pinctrl-meson-g12a.c
new file mode 100644
index ..ca5cec40ac34
--- /dev/null
+++ b/drivers/pinctrl/meson/pinctrl-meson-g12a.c
@@ -0,0 +1,1433 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Pin controller and GPIO driver for Amlogic Meson G12A SoC.
+ *
+ * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
+ * Author: Xingyu Chen 
+ * Author: Yixun Lan 
+ */
+
+#include 
+#include "pinctrl-meson.h"
+#include "pinctrl-meson-axg-pmx.h"
+
+static const struct pinctrl_pin_desc meson_g12a_periphs_pins[] = {
+   MESON_PIN(GPIOZ_0),
+   MESON_PIN(GPIOZ_1),
+   MESON_PIN(GPIOZ_2),
+   MESON_PIN(GPIOZ_3),
+   MESON_PIN(GPIOZ_4),
+   MESON_PIN(GPIOZ_5),
+   MESON_PIN(GPIOZ_6),
+   MESON_PIN(GPIOZ_7),
+   MESON_PIN(GPIOZ_8),
+   MESON_PIN(GPIOZ_9),
+   MESON_PIN(GPIOZ_10),
+   MESON_PIN(GPIOZ_11),
+   MESON_PIN(GPIOZ_12),
+   MESON_PIN(GPIOZ_13),
+   MESON_PIN(GPIOZ_14),
+   MESON_PIN(GPIOZ_15),
+   MESON_PIN(GPIOH_0),
+   MESON_PIN(GPIOH_1),
+   MESON_PIN(GPIOH_2),
+   MESON_PIN(GPIOH_3),
+   MESON_PIN(GPIOH_4),
+   MESON_PIN(GPIOH_5),
+   MESON_PIN(GPIOH_6),
+   MESON_PIN(GPIOH_7),
+   MESON_PIN(GPIOH_8),
+   MESON_PIN(BOOT_0),
+   MESON_PIN(BOOT_1),
+   MESON_PIN(BOOT_2),
+   MESON_PIN(BOOT_3),
+   MESON_PIN(BOOT_4),
+   MESON_PIN(BOOT_5),
+   MESON_PIN(BOOT_6),
+   MESON_PIN(BOOT_7),
+   MESON_PIN(BOOT_8),
+   MESON_PIN(BOOT_9),
+   MESON_PIN(BOOT_10),
+   MESON_PIN(BOOT_11),
+   MESON_PIN(BOOT_12),
+   MESON_PIN(BOOT_13),
+   MESON_PIN(BOOT_14),
+   MESON_PIN(BOOT_15),
+   MESON_PIN(GPIOC_0),
+   MESON_PIN(GPIOC_1),
+   MESON_PIN(GPIOC_2),
+   MESON_PIN(GPIOC_3),
+   MESON_PIN(GPIOC_4),
+   MESON_PIN(GPIOC_5),
+   MESON_PIN(GPIOC_6),
+   MESON_PIN(GPIOC_7),
+   MESON_PIN(GPIOA_0),
+   MESON_PIN(GPIOA_1),
+   MESON_PIN(GPIOA_2),
+   MESON_PIN(GPIOA_3),
+   MESON_PIN(GPIOA_4),
+   MESON_PIN(GPIOA_5),
+   MESON_PIN(GPIOA_6),
+   MESON_PIN(GPIOA_7),
+   MESON_PIN(GPIOA_8),
+   MESON_PIN(GPIOA_9),
+   MESON_PIN(GPIOA_10),
+   MESON_PIN(GPIOA_11),
+   MESON_PIN(GPIOA_12),
+   MESON_PIN(GPIOA_13),
+   MESON_PIN(GPIOA_14),
+   MESON_PIN(GPIOA_15),
+   MESON_PIN(GPIOX_0),
+   MESON_PIN(GPIOX_1),
+   MESON_PIN(GPIOX_2),
+   MESON_PIN(GPIOX_3),
+   MESON_PIN(GPIOX_4),
+   MESON_PIN(GPIOX_5),
+   MESON_PIN(GPIOX_6),
+   MESON_PIN(GPIOX_7),
+   MESON_PIN(GPIOX_8),
+   MESON_PIN(GPIOX_9),
+   MESON_PIN(GPIOX_10),
+   MESON_PIN(GPIOX_11),
+   MESON_PIN(GPIOX_12),
+   MESON_PIN(GPIOX_13),
+   MESON_PIN(GPIOX_14),
+   MESON_PIN(GPIOX_15),
+   MESON_PIN(GPIOX_16),
+   MESON_PIN(GPIOX_17),
+   MESON_PIN(GPIOX_18),
+   MESON_PIN(GPIOX_19),

[PATCH v2 0/2] pinctrl: meson-g12a: add pinctrl driver support

[Yixun Lan]

This patch series try to add pinctrl driver support for
the Meson-G12A SoC.

Changes since v1 at [1]
 - add Martin's Ack, Xingyu's Signed-off
 - squash patch 1,2 (documentation & header file)
 - explain pinctrl IP
 - notice GPIOE located in AO bank

[1] https://lkml.kernel.org/r/20180704224511.29350-1-yixun@amlogic.com

Yixun Lan (2):
  documentation: pinctrl: Add compatibles for Amlogic Meson G12A pin
controllers
  pinctrl: meson-g12a: add pinctrl driver support

 .../bindings/pinctrl/meson,pinctrl.txt|2 +
 drivers/pinctrl/meson/Kconfig |6 +
 drivers/pinctrl/meson/Makefile|1 +
 drivers/pinctrl/meson/pinctrl-meson-g12a.c| 1433 +
 include/dt-bindings/gpio/meson-g12a-gpio.h|  114 ++
 5 files changed, 1556 insertions(+)
 create mode 100644 drivers/pinctrl/meson/pinctrl-meson-g12a.c
 create mode 100644 include/dt-bindings/gpio/meson-g12a-gpio.h

-- 
2.18.0

Re: [PATCH 3/3] pinctrl: meson-g12a: add pinctrl driver support

[Martin Blumenstingl]

Hi Yixun,

On Wed, Jul 4, 2018 at 4:50 PM Yixun Lan  wrote:
>
> Add the pinctrl driver for Meson-G12A SoC which share the similar IP as
> the previous Meson-AXG SoC.
my understanding is that:
- AXG and G12A use the same mechanism (register layout) to configure
the pin controller
- however, the pin mapping differs between AXG and G12A (because G12A
has more pins in the GPIOZ bank, G12A has a GPIOH bank which AXG
doesn't have at all, G12A has less pins in the GPIOA and GPIOX
 banks than AXG and finally AXG has a GPIOY bank which G12A doesn't have)

maybe you can update the commit description to make it clear that
- "similar IP" means that the pinmux ops (register layout) are the same
- a new driver is needed due to the differences in the pins

I am assuming that the pin function names are taken from the
datasheets (as I don't have access to the datasheets of this SoC)
these names are slightly inconsistent, but if it's what's written in
the datasheet then I'm fine with it.
an example (there are too many places to name them all):
"uart_rx_ao_a" (this is for the RX line of the uart_ao_a controller)
vs "pwm_ao_a_hiz" (this is for the "HIZ" line of the the pwm_ao_a
controller) -> to have a consistent naming it would either have to be
"uart_ao_a_rx" or "pwm_hiz_ao_a"

> Signed-off-by: Yixun Lan 
with the few notes fixed (see below):
Acked-by: Martin Blumenstingl 

> ---
>  drivers/pinctrl/meson/Kconfig  |6 +
>  drivers/pinctrl/meson/Makefile |1 +
>  drivers/pinctrl/meson/pinctrl-meson-g12a.c | 1432 
>  3 files changed, 1439 insertions(+)
>  create mode 100644 drivers/pinctrl/meson/pinctrl-meson-g12a.c
>
> diff --git a/drivers/pinctrl/meson/Kconfig b/drivers/pinctrl/meson/Kconfig
> index c80951d6caff..9ab537eb78a3 100644
> --- a/drivers/pinctrl/meson/Kconfig
> +++ b/drivers/pinctrl/meson/Kconfig
> @@ -47,4 +47,10 @@ config PINCTRL_MESON_AXG
>  config PINCTRL_MESON_AXG_PMX
> bool
>
> +config PINCTRL_MESON_G12A
> +   bool "Meson g12a Soc pinctrl driver"
> +   depends on ARM64
> +   select PINCTRL_MESON_AXG_PMX
> +   default y
> +
>  endif
> diff --git a/drivers/pinctrl/meson/Makefile b/drivers/pinctrl/meson/Makefile
> index 3c6580c2d9d7..cf283f48f9d8 100644
> --- a/drivers/pinctrl/meson/Makefile
> +++ b/drivers/pinctrl/meson/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_PINCTRL_MESON_GXBB) += pinctrl-meson-gxbb.o
>  obj-$(CONFIG_PINCTRL_MESON_GXL) += pinctrl-meson-gxl.o
>  obj-$(CONFIG_PINCTRL_MESON_AXG_PMX) += pinctrl-meson-axg-pmx.o
>  obj-$(CONFIG_PINCTRL_MESON_AXG) += pinctrl-meson-axg.o
> +obj-$(CONFIG_PINCTRL_MESON_G12A) += pinctrl-meson-g12a.o
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-g12a.c 
> b/drivers/pinctrl/meson/pinctrl-meson-g12a.c
> new file mode 100644
> index ..2711bad5d252
> --- /dev/null
> +++ b/drivers/pinctrl/meson/pinctrl-meson-g12a.c
> @@ -0,0 +1,1432 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Pin controller and GPIO driver for Amlogic Meson G12A SoC.
> + *
> + * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
> + * Author: Xingyu Chen 
> + * Author: Yixun Lan 
same as with the dt-bindings patch: do we also need a "Signed-off-by"
from Xingyu Chen?

> + */
> +
> +#include 
> +#include "pinctrl-meson.h"
> +#include "pinctrl-meson-axg-pmx.h"
> +
> +static const struct pinctrl_pin_desc meson_g12a_periphs_pins[] = {
> +   MESON_PIN(GPIOZ_0),
> +   MESON_PIN(GPIOZ_1),
> +   MESON_PIN(GPIOZ_2),
> +   MESON_PIN(GPIOZ_3),
> +   MESON_PIN(GPIOZ_4),
> +   MESON_PIN(GPIOZ_5),
> +   MESON_PIN(GPIOZ_6),
> +   MESON_PIN(GPIOZ_7),
> +   MESON_PIN(GPIOZ_8),
> +   MESON_PIN(GPIOZ_9),
> +   MESON_PIN(GPIOZ_10),
> +   MESON_PIN(GPIOZ_11),
> +   MESON_PIN(GPIOZ_12),
> +   MESON_PIN(GPIOZ_13),
> +   MESON_PIN(GPIOZ_14),
> +   MESON_PIN(GPIOZ_15),
> +   MESON_PIN(GPIOH_0),
> +   MESON_PIN(GPIOH_1),
> +   MESON_PIN(GPIOH_2),
> +   MESON_PIN(GPIOH_3),
> +   MESON_PIN(GPIOH_4),
> +   MESON_PIN(GPIOH_5),
> +   MESON_PIN(GPIOH_6),
> +   MESON_PIN(GPIOH_7),
> +   MESON_PIN(GPIOH_8),
> +   MESON_PIN(BOOT_0),
> +   MESON_PIN(BOOT_1),
> +   MESON_PIN(BOOT_2),
> +   MESON_PIN(BOOT_3),
> +   MESON_PIN(BOOT_4),
> +   MESON_PIN(BOOT_5),
> +   MESON_PIN(BOOT_6),
> +   MESON_PIN(BOOT_7),
> +   MESON_PIN(BOOT_8),
> +   MESON_PIN(BOOT_9),
> +   MESON_PIN(BOOT_10),
> +   MESON_PIN(BOOT_11),
> +   MESON_PIN(BOOT_12),
> +   MESON_PIN(BOOT_13),
> +   MESON_PIN(BOOT_14),
> +   MESON_PIN(BOOT_15),
> +   MESON_PIN(GPIOC_0),
> +   MESON_PIN(GPIOC_1),
> +   MESON_PIN(GPIOC_2),
> +   MESON_PIN(GPIOC_3),
> +   MESON_PIN(GPIOC_4),
> +   MESON_PIN(GPIOC_5),
> +   MESON_PIN(GPIOC_6),
> +   MESON_PIN(GPIOC_7),
> +   MESON_PIN(GPIOA_0),
> +   MESON_PIN(GPIOA_1),
> +   MESON_PIN(GPIOA_2),
> +   MESON_PIN(GPIOA_3),
> +   ME

[PATCH v2 1/2] documentation: pinctrl: Add compatibles for Amlogic Meson G12A pin controllers

[Yixun Lan]

Add new compatible name for Amlogic's Meson-G12A pin controllers,
add a dt-binding header file which document the detail pin names.

Acked-by: Martin Blumenstingl 
Signed-off-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 .../bindings/pinctrl/meson,pinctrl.txt|   2 +
 include/dt-bindings/gpio/meson-g12a-gpio.h| 114 ++
 2 files changed, 116 insertions(+)
 create mode 100644 include/dt-bindings/gpio/meson-g12a-gpio.h

diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
index 54ecb8ab7788..82ead40311f6 100644
--- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
@@ -13,6 +13,8 @@ Required properties for the root node:
  "amlogic,meson-gxl-aobus-pinctrl"
  "amlogic,meson-axg-periphs-pinctrl"
  "amlogic,meson-axg-aobus-pinctrl"
+ "amlogic,meson-g12a-periphs-pinctrl"
+ "amlogic,meson-g12a-aobus-pinctrl"
  - reg: address and size of registers controlling irq functionality
 
 === GPIO sub-nodes ===
diff --git a/include/dt-bindings/gpio/meson-g12a-gpio.h 
b/include/dt-bindings/gpio/meson-g12a-gpio.h
new file mode 100644
index ..f7bd69350d18
--- /dev/null
+++ b/include/dt-bindings/gpio/meson-g12a-gpio.h
@@ -0,0 +1,114 @@
+/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */
+/*
+ * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
+ * Author: Xingyu Chen 
+ */
+
+#ifndef _DT_BINDINGS_MESON_G12A_GPIO_H
+#define _DT_BINDINGS_MESON_G12A_GPIO_H
+
+/* First GPIO chip */
+#define GPIOAO_0   0
+#define GPIOAO_1   1
+#define GPIOAO_2   2
+#define GPIOAO_3   3
+#define GPIOAO_4   4
+#define GPIOAO_5   5
+#define GPIOAO_6   6
+#define GPIOAO_7   7
+#define GPIOAO_8   8
+#define GPIOAO_9   9
+#define GPIOAO_10  10
+#define GPIOAO_11  11
+#define GPIOE_012
+#define GPIOE_113
+#define GPIOE_214
+
+/* Second GPIO chip */
+#define GPIOZ_00
+#define GPIOZ_11
+#define GPIOZ_22
+#define GPIOZ_33
+#define GPIOZ_44
+#define GPIOZ_55
+#define GPIOZ_66
+#define GPIOZ_77
+#define GPIOZ_88
+#define GPIOZ_99
+#define GPIOZ_10   10
+#define GPIOZ_11   11
+#define GPIOZ_12   12
+#define GPIOZ_13   13
+#define GPIOZ_14   14
+#define GPIOZ_15   15
+#define GPIOH_016
+#define GPIOH_117
+#define GPIOH_218
+#define GPIOH_319
+#define GPIOH_420
+#define GPIOH_521
+#define GPIOH_622
+#define GPIOH_723
+#define GPIOH_824
+#define BOOT_0 25
+#define BOOT_1 26
+#define BOOT_2 27
+#define BOOT_3 28
+#define BOOT_4 29
+#define BOOT_5 30
+#define BOOT_6 31
+#define BOOT_7 32
+#define BOOT_8 33
+#define BOOT_9 34
+#define BOOT_1035
+#define BOOT_1136
+#define BOOT_1237
+#define BOOT_1338
+#define BOOT_1439
+#define BOOT_1540
+#define GPIOC_041
+#define GPIOC_142
+#define GPIOC_243
+#define GPIOC_344
+#define GPIOC_445
+#define GPIOC_546
+#define GPIOC_647
+#define GPIOC_748
+#define GPIOA_049
+#define GPIOA_150
+#define GPIOA_251
+#define GPIOA_352
+#define GPIOA_453
+#define GPIOA_554
+#define GPIOA_655
+#define GPIOA_756
+#define GPIOA_857
+#define GPIOA_958
+#define GPIOA_10   59
+#define GPIOA_11   60
+#define GPIOA_12   61
+#define GPIOA_13   62
+#define GPIOA_14   63
+#define GPIOA_15   64
+#define GPIOX_065
+#define GPIOX_166
+#define GPIOX_267
+#define GPIOX_368
+#define GPIOX_469
+#define GPIOX_570
+#define GPIOX_671
+#define GPIOX_772
+#define GPIOX_873
+#define GPIOX_974
+#define GPIOX_10   75
+#define GPIOX_11   76
+#define GPIOX_12   77
+#define GPIOX_13   78
+#define GPIOX_14   79
+#define GPIOX_15   80
+#define GPIOX_16   81
+#define GPIOX_17   82
+#define GPIOX_18   83
+#define GPIOX_19   84
+
+#endif /* _DT_BINDINGS_MESON_G12A_GPIO_H */
-- 
2.18.0

REGRESSION: [RESEND PATCH v3 1/4] backlight: pwm_bl: linear interpolation between brightness-levels

[Marcel Ziswiler]

On Mon, 2018-04-09 at 10:33 +0200, Enric Balletbo i Serra wrote:
> Setting num-interpolated-steps in the dts will allow you to have
> linear
> interpolation between values of brightness-levels. This way a high
> resolution pwm duty cycle can be used without having to list out
> every
> possible value in the dts. This system also allows for gamma
> corrected
> values.
> 
> The most simple example is interpolate between two brightness values
> a
> number of steps, this can be done setting the following in the dts:
> 
>   brightness-levels = <0 65535>;
>   num-interpolated-steps = <1024>;
>   default-brightness-level = <512>;
> 
> This will create a brightness-level table with the following values:
> 
>   <0 63 126 189 252 315 378 441 ... 64260 64323 64386 64449 65535>
> 
> Another use case can be describe a gamma corrected curve, as we have
> better sensitivity at low luminance than high luminance we probably
> want have smaller steps for low brightness levels values and bigger
> steps for high brightness levels values. This can be achieved with
> the following in the dts:
> 
>   brightness-levels = <0 4096 65535>;
>   num-interpolated-steps = <1024>;
>   default-brightness-level = <512>;
> 
> This will create a brightness-levels table with the following values:
> 
>   <0 4 8 12 16 20 ... 4096 4156 4216 4276 ... 65535>
> 
> Signed-off-by: Enric Balletbo i Serra 
> Acked-by: Daniel Thompson 
> ---
>  drivers/video/backlight/pwm_bl.c | 83
> 
>  1 file changed, 83 insertions(+)
> 
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index 8e3f1245f5c5..f0a108ab570a 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -147,7 +147,11 @@ static int pwm_backlight_parse_dt(struct device
> *dev,
> struct platform_pwm_backlight_data
> *data)
>  {
>   struct device_node *node = dev->of_node;
> + unsigned int num_levels = 0;
> + unsigned int levels_count;
> + unsigned int num_steps;
>   struct property *prop;
> + unsigned int *table;
>   int length;
>   u32 value;
>   int ret;
> @@ -167,6 +171,7 @@ static int pwm_backlight_parse_dt(struct device
> *dev,
>   /* read brightness levels from DT property */
>   if (data->max_brightness > 0) {
>   size_t size = sizeof(*data->levels) * data-
> >max_brightness;
> + unsigned int i, j, n = 0;
>  
>   data->levels = devm_kzalloc(dev, size, GFP_KERNEL);
>   if (!data->levels)
> @@ -184,6 +189,84 @@ static int pwm_backlight_parse_dt(struct device
> *dev,
>   return ret;
>  
>   data->dft_brightness = value;
> +
> + /*
> +  * This property is optional, if is set enables
> linear
> +  * interpolation between each of the values of
> brightness levels
> +  * and creates a new pre-computed table.
> +  */
> + of_property_read_u32(node, "num-interpolated-steps",
> +  &num_steps);
> +
> + /*
> +  * Make sure that there is at least two entries in
> the
> +  * brightness-levels table, otherwise we can't
> interpolate
> +  * between two points.
> +  */
> + if (num_steps) {
> + if (data->max_brightness < 2) {
> + dev_err(dev, "can't interpolate\n");
> + return -EINVAL;
> + }
> +
> + /*
> +  * Recalculate the number of brightness
> levels, now
> +  * taking in consideration the number of
> interpolated
> +  * steps between two levels.
> +  */
> + for (i = 0; i < data->max_brightness - 1;
> i++) {
> + if ((data->levels[i + 1] - data-
> >levels[i]) /
> +num_steps)
> + num_levels += num_steps;
> + else
> + num_levels++;
> + }
> + num_levels++;
> + dev_dbg(dev, "new number of brightness
> levels: %d\n",
> + num_levels);
> +
> + /*
> +  * Create a new table of brightness levels
> with all the
> +  * interpolated steps.
> +  */
> + size = sizeof(*table) * num_levels;
> + table = devm_kzalloc(dev, size, GFP_KERNEL);
> + if (!table)
> + return -ENOMEM;
> +
> + /* Fill the interpolated table. */
> + levels_count = 0;
> + for (i = 0; i < data->max_brightness - 1;
> i++) {
> + 

Re: [PATCH 2/3] dt-bindings: pinctrl: meson-g12a: document pin name

[Yixun Lan]

HI Martin

thanks for the comments

On 07/14/2018 10:47 PM, Martin Blumenstingl wrote:
> Hi Yixun,
> 
> On Wed, Jul 4, 2018 at 4:49 PM Yixun Lan  wrote:
>>
>> Document the pins for Amlogic's Meson-G12A SoC.
> I suggest to combine patch 1 (adding the compatible string) and 2 (this one)
> 
> as discussed in the cover letter: it would be great if you could add a
> comment (at least to the commit message) stating that GPIOE is
> actually located (checked with the ASIC / hardware team) in the AO
> bank
> 
sure, I will state this in commit message, and will also put a note in code.

>> Signed-off-by: Yixun Lan 
> with that:
> Acked-by: Martin Blumenstingl 
> 
thanks, I assume I can add your Ack to this whole patch series
(dt-binding patch and pinctrl driver patch)?

>> ---
>>  include/dt-bindings/gpio/meson-g12a-gpio.h | 114 +
>>  1 file changed, 114 insertions(+)
>>  create mode 100644 include/dt-bindings/gpio/meson-g12a-gpio.h
>>
>> diff --git a/include/dt-bindings/gpio/meson-g12a-gpio.h 
>> b/include/dt-bindings/gpio/meson-g12a-gpio.h
>> new file mode 100644
>> index ..f7bd69350d18
>> --- /dev/null
>> +++ b/include/dt-bindings/gpio/meson-g12a-gpio.h
>> @@ -0,0 +1,114 @@
>> +/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */
>> +/*
>> + * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
>> + * Author: Xingyu Chen 
> (since I'm not sure about all the licensing bits:) do we also need a
> "Signed-off-by" from Xingyu Chen?
> 
sure, this pinctrl driver is mostly Xingyu's work, I will add this.
> 
> Regards
> Martin
> 
> .
> 

Re: [PATCH 2/3] dt-bindings: pinctrl: meson-g12a: document pin name

[Martin Blumenstingl]

Hi Yixun,

On Wed, Jul 4, 2018 at 4:49 PM Yixun Lan  wrote:
>
> Document the pins for Amlogic's Meson-G12A SoC.
I suggest to combine patch 1 (adding the compatible string) and 2 (this one)

as discussed in the cover letter: it would be great if you could add a
comment (at least to the commit message) stating that GPIOE is
actually located (checked with the ASIC / hardware team) in the AO
bank

> Signed-off-by: Yixun Lan 
with that:
Acked-by: Martin Blumenstingl 

> ---
>  include/dt-bindings/gpio/meson-g12a-gpio.h | 114 +
>  1 file changed, 114 insertions(+)
>  create mode 100644 include/dt-bindings/gpio/meson-g12a-gpio.h
>
> diff --git a/include/dt-bindings/gpio/meson-g12a-gpio.h 
> b/include/dt-bindings/gpio/meson-g12a-gpio.h
> new file mode 100644
> index ..f7bd69350d18
> --- /dev/null
> +++ b/include/dt-bindings/gpio/meson-g12a-gpio.h
> @@ -0,0 +1,114 @@
> +/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */
> +/*
> + * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
> + * Author: Xingyu Chen 
(since I'm not sure about all the licensing bits:) do we also need a
"Signed-off-by" from Xingyu Chen?


Regards
Martin

Re: [PATCH 0/3] pinctrl: meson-g12a: add pinctrl driver support

[Yixun Lan]

Hi Martin

see my comments

On 07/14/2018 10:36 PM, Martin Blumenstingl wrote:
> On Tue, Jul 10, 2018 at 12:07 AM Martin Blumenstingl
>  wrote:
>>
>> Hi Linus,
>>
>> On Mon, Jul 9, 2018 at 3:35 PM Linus Walleij  
>> wrote:
>>>
>>> On Wed, Jul 4, 2018 at 4:48 PM Yixun Lan  wrote:

 This patch series try to add pinctrl driver support for
 the Meson-G12A SoC.


 Yixun Lan (3):
   documentation: Add compatibles for Amlogic Meson G12A pin controllers
   dt-bindings: pinctrl: meson-g12a: document pin name
   pinctrl: meson-g12a: add pinctrl driver support
>>>
>>> Overall this looks good to me, could we get some review or ACKs
>>> from Beniamino, Martin and/or Carlo as an indication that everything
>>> seems all right before I apply the series?
>> I do not have any documentation for this hardware (I'm not even sure
>> if this is the successor to AXG/"the Audio SoCs" or rather a successor
>> of GXL or GXM/"the OTT/STB SoCs"
> for those who are interested: according to [0] the marketing name of
> this SoC will be "A311D" - specs from the linked PDF:
A311D is the G12B SoC series
This pinctrl patch is target for G12A for now, but can be very easily
extend to support G12B..
> - CPU: Quad Cortex-A73 + Dual Cortex-A53 (max frequency: TBD)
> - GPU: ARM G52 MP4 (4ppc)
> - Memory: DDR3/4 LPDDR3/4
> - Video decoding: 4K H265&VP9&AVS2
> - Video Encoding: 1080P H264 H265
> - HDMI-Tx: 4K2K
> - Ethernet: 10/100M/1000M
> - AV output: CVBS
> - IP License: Dolby, DTS
> 
> W400 is the reference board for this SoC, it comes with:
> - EMMC
> - WIFI AP6398S
> - DDR 2GB
> 
yes, W400 for G12B, and U200 for G12A

> if I had to guess then I would say it's the successor of the GXL (or
> GXM?) family
> 
Yes, successor of GXL

> 
> Regards
> Martin
> 
> 
> [0] 
> http://openlinux.amlogic.com:8000/download/doc/Amlogic_A311D_Buildroot_Preview_Release_Notes_V20180706.pdf
> 
> .
> 

Re: [PATCH 1/3] soc: amlogic: Add Meson GX Clock Measure driver

[Martin Blumenstingl]

Hi Neil,

On Wed, Jul 11, 2018 at 10:37 AM Neil Armstrong  wrote:
>
> On 09/07/2018 23:41, Kevin Hilman wrote:
> > Martin Blumenstingl  writes:
> >
> >> Hi Neil,
> >>
> >> On Wed, Jul 4, 2018 at 10:41 AM Neil Armstrong  
> >> wrote:
> >>>
> >>> Hi Martin,
> >>>
> >>> On 03/07/2018 21:18, Martin Blumenstingl wrote:
>  Hi Neil,
> 
>  On Tue, Jul 3, 2018 at 3:23 PM Neil Armstrong  
>  wrote:
> >
> > The Amlogic Meson GX SoCs embeds a clock measurer IP to measure the 
> > internal
> > clock paths frequencies.
> > The precision is in the order of the MHz.
> >
> > Signed-off-by: Neil Armstrong 
> > ---
> >  drivers/soc/amlogic/Kconfig|   8 ++
> >  drivers/soc/amlogic/Makefile   |   1 +
> >  drivers/soc/amlogic/meson-gx-clk-measure.c | 224 
> > +
> >  3 files changed, 233 insertions(+)
> >  create mode 100644 drivers/soc/amlogic/meson-gx-clk-measure.c
> >
> > diff --git a/drivers/soc/amlogic/Kconfig b/drivers/soc/amlogic/Kconfig
> > index b04f6e4..4a3217d 100644
> > --- a/drivers/soc/amlogic/Kconfig
> > +++ b/drivers/soc/amlogic/Kconfig
> > @@ -1,5 +1,13 @@
> >  menu "Amlogic SoC drivers"
> >
> > +config MESON_GX_CLK_MEASURE
> > +   bool "Amlogic Meson GX SoC Clock Measure driver"
> > +   depends on ARCH_MESON || COMPILE_TEST
> > +   default ARCH_MESON
> > +   help
> > + Say yes to support of Measuring a set of internal SoC clocks
> > + from the debugfs interface.
> > +
> >  config MESON_GX_SOCINFO
> > bool "Amlogic Meson GX SoC Information driver"
> > depends on ARCH_MESON || COMPILE_TEST
> > diff --git a/drivers/soc/amlogic/Makefile b/drivers/soc/amlogic/Makefile
> > index 8fa3218..a0ad966 100644
> > --- a/drivers/soc/amlogic/Makefile
> > +++ b/drivers/soc/amlogic/Makefile
> > @@ -1,3 +1,4 @@
> > +obj-$(CONFIG_MESON_GX_CLK_MEASURE) += meson-gx-clk-measure.o
> >  obj-$(CONFIG_MESON_GX_SOCINFO) += meson-gx-socinfo.o
> >  obj-$(CONFIG_MESON_GX_PM_DOMAINS) += meson-gx-pwrc-vpu.o
> >  obj-$(CONFIG_MESON_MX_SOCINFO) += meson-mx-socinfo.o
> > diff --git a/drivers/soc/amlogic/meson-gx-clk-measure.c 
> > b/drivers/soc/amlogic/meson-gx-clk-measure.c
> > new file mode 100644
> > index 000..434d9f3
> > --- /dev/null
> > +++ b/drivers/soc/amlogic/meson-gx-clk-measure.c
> >>>
> >>> [...]
> >>>
> > +   CLK_MSR_ID(57, "wave420l_c"),
> > +   CLK_MSR_ID(58, "wave420l_b"),
>  AFAIK the Chips&Media WAVE420L video codec is only available on GXM 
>  (S912)
>  I assume reading this on GXBB or GXL simply reads 0?
> >>>
> >>> Yes
> >>>
> 
> > +   CLK_MSR_ID(59, "hcodec"),
> > +   CLK_MSR_ID(60, "alt_32k"),
> > +   CLK_MSR_ID(61, "gpio_msr"),
> > +   CLK_MSR_ID(62, "hevc"),
> > +   CLK_MSR_ID(66, "vid_lock"),
> > +   CLK_MSR_ID(70, "pwm_f"),
> > +   CLK_MSR_ID(71, "pwm_e"),
> > +   CLK_MSR_ID(72, "pwm_d"),
> > +   CLK_MSR_ID(73, "pwm_C"),
>  should this be pwm_c (instead of pwm_C)?
> 
> > +   CLK_MSR_ID(75, "aoclkx2_int"),
> > +   CLK_MSR_ID(76, "aoclk_int"),
> > +   CLK_MSR_ID(77, "rng_ring_osc_0"),
> > +   CLK_MSR_ID(78, "rng_ring_osc_1"),
> > +   CLK_MSR_ID(79, "rng_ring_osc_2"),
> > +   CLK_MSR_ID(80, "rng_ring_osc_3"),
> > +   CLK_MSR_ID(81, "vapb"),
> > +   CLK_MSR_ID(82, "ge2d"),
> > +};
>  I did a quick check whether the clock IDs are really the same for all GX 
>  SoCs:
>  apart from clocks missing on older SoCs (see for example the WAVE420L
>  clocks above) there were only minor renames but no conflicts!
> >>>
> >>> I did the same work ! I will add this detail to the commit log.
> >>> Thanks for checking ;-)
> >> :)
> >>
> 
> > +
> > +static int meson_gx_measure_id(struct meson_gx_msr *priv, unsigned int 
> > id)
> > +{
> > +   unsigned int val;
> > +   int ret;
> > +
> > +   regmap_write(priv->regmap, MSR_CLK_REG0, 0);
> > +
> > +   /* Set measurement gate to 50uS */
> > +   regmap_update_bits(priv->regmap, MSR_CLK_REG0, MSR_CLK_DIV,
> > +  FIELD_PREP(MSR_CLK_DIV, DIV_50US));
> > +
> > +   /* Set ID */
> > +   regmap_update_bits(priv->regmap, MSR_CLK_REG0, MSR_CLK_SRC,
> > +  FIELD_PREP(MSR_CLK_SRC, id));
> > +
> > +   /* Enable & Start */
> > +   regmap_update_bits(priv->regmap, MSR_CLK_REG0,
> > +  MSR_RUN | MSR_ENABLE,
> > +  MSR_RUN | MSR_ENABLE);
> > +
> > +   ret = regmap_read_poll_timeout(priv->regmap, MSR_CLK_REG0,
> > +  val, !(val & MSR_BUSY), 10,

Re: [PATCH 0/3] pinctrl: meson-g12a: add pinctrl driver support

[Martin Blumenstingl]

On Tue, Jul 10, 2018 at 12:07 AM Martin Blumenstingl
 wrote:
>
> Hi Linus,
>
> On Mon, Jul 9, 2018 at 3:35 PM Linus Walleij  wrote:
> >
> > On Wed, Jul 4, 2018 at 4:48 PM Yixun Lan  wrote:
> > >
> > > This patch series try to add pinctrl driver support for
> > > the Meson-G12A SoC.
> > >
> > >
> > > Yixun Lan (3):
> > >   documentation: Add compatibles for Amlogic Meson G12A pin controllers
> > >   dt-bindings: pinctrl: meson-g12a: document pin name
> > >   pinctrl: meson-g12a: add pinctrl driver support
> >
> > Overall this looks good to me, could we get some review or ACKs
> > from Beniamino, Martin and/or Carlo as an indication that everything
> > seems all right before I apply the series?
> I do not have any documentation for this hardware (I'm not even sure
> if this is the successor to AXG/"the Audio SoCs" or rather a successor
> of GXL or GXM/"the OTT/STB SoCs"
for those who are interested: according to [0] the marketing name of
this SoC will be "A311D" - specs from the linked PDF:
- CPU: Quad Cortex-A73 + Dual Cortex-A53 (max frequency: TBD)
- GPU: ARM G52 MP4 (4ppc)
- Memory: DDR3/4 LPDDR3/4
- Video decoding: 4K H265&VP9&AVS2
- Video Encoding: 1080P H264 H265
- HDMI-Tx: 4K2K
- Ethernet: 10/100M/1000M
- AV output: CVBS
- IP License: Dolby, DTS

W400 is the reference board for this SoC, it comes with:
- EMMC
- WIFI AP6398S
- DDR 2GB

if I had to guess then I would say it's the successor of the GXL (or
GXM?) family


Regards
Martin


[0] 
http://openlinux.amlogic.com:8000/download/doc/Amlogic_A311D_Buildroot_Preview_Release_Notes_V20180706.pdf

Re: [PATCH 10/39] x86/entry/32: Handle Entry from Kernel-Mode on Entry-Stack

[Andy Lutomirski]

> On Jul 14, 2018, at 1:01 AM, Joerg Roedel  wrote:
> 
> On Fri, Jul 13, 2018 at 11:26:54PM -0700, Andy Lutomirski wrote:
>>> So based on that, I did the above because the entry-stack is a per-cpu
>>> data structure and I am not sure that we always return from the exception
>>> on the same CPU where we got it. Therefore the path is called
>>> PARANOID_... :)
>> 
>> But we should just be able to IRET and end up right back on the entry
>> stack where we were when we got interrupted.
> 
> Yeah, but using another CPUs entry-stack is a bad idea, no? Especially
> since the owning CPU might have overwritten our content there already.
> 
>> On x86_64, we *definitely* can’t schedule in NMI, MCE, or #DB because
>> we’re on a percpu stack. Are you *sure* we need this patch?
> 
> I am sure we need this patch, but not 100% sure that we really can
> change CPUs in this path. We are not only talking about NMI, #MC and
> #DB, but also about #GP and every other exception that can happen while
> writing segments registers or on iret. With this implementation we are
> on the safe side for this unlikely slow-path.

Oh, right, exceptions while writing segment regs. IRET is special, though.

But I’m still unconvinced. If any code executed with IRQs enabled on the entry 
stack, then that code is terminally buggy. If you’re executing with IRQs off, 
you’re not going to get migrated.  64-bit kernels run on percpu stacks all the 
time, and it’s not a problem.

IRET errors are genuinely special and, if they’re causing a problem for you, we 
should fix them the same way we deal with them on x86_64. M

> 
> Regards,
> 
>Joerg

Re: [PATCH v10 2/3] tracepoint: Make rcuidle tracepoint callers use SRCU

[Mathieu Desnoyers]

- On Jul 13, 2018, at 5:55 PM, Joel Fernandes, Google 
j...@joelfernandes.org wrote:

> From: "Joel Fernandes (Google)" 
> 
> In recent tests with IRQ on/off tracepoints, a large performance
> overhead ~10% is noticed when running hackbench. This is root caused to
> calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the
> tracepoint code. Following a long discussion on the list [1] about this,
> we concluded that srcu is a better alternative for use during rcu idle.
> Although it does involve extra barriers, its lighter than the sched-rcu
> version which has to do additional RCU calls to notify RCU idle about
> entry into RCU sections.
> 
> In this patch, we change the underlying implementation of the
> trace_*_rcuidle API to use SRCU. This has shown to improve performance
> alot for the high frequency irq enable/disable tracepoints.
> 
> Test: Tested idle and preempt/irq tracepoints.
> 
> Here are some performance numbers:
> 
> With a run of the following 30 times on a single core x86 Qemu instance
> with 1GB memory:
> hackbench -g 4 -f 2 -l 3000
> 
> Completion times in seconds. CONFIG_PROVE_LOCKING=y.
> 
> No patches (without this series)
> Mean: 3.048
> Median: 3.025
> Std Dev: 0.064
> 
> With Lockdep using irq tracepoints with RCU implementation:
> Mean: 3.451   (-11.66 %)
> Median: 3.447 (-12.22%)
> Std Dev: 0.049
> 
> With Lockdep using irq tracepoints with SRCU implementation (this series):
> Mean: 3.020   (I would consider the improvement against the "without
>  this series" case as just noise).
> Median: 3.013
> Std Dev: 0.033
> 
> [1] https://patchwork.kernel.org/patch/10344297/
> 
> Reviewed-by: Mathieu Desnoyers 

I'm fine with the changes done since last iteration.

Acked-by: Mathieu Desnoyers 

Thanks!

Mathieu

> Cleaned-up-by: Peter Zijlstra 
> Signed-off-by: Joel Fernandes (Google) 
> ---
> include/linux/tracepoint.h | 45 +++---
> kernel/tracepoint.c| 16 +-
> 2 files changed, 52 insertions(+), 9 deletions(-)
> 
> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index 19a690b559ca..97e1d365a817 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -15,6 +15,7 @@
>  */
> 
> #include 
> +#include 
> #include 
> #include 
> #include 
> @@ -33,6 +34,8 @@ struct trace_eval_map {
> 
> #define TRACEPOINT_DEFAULT_PRIO   10
> 
> +extern struct srcu_struct tracepoint_srcu;
> +
> extern int
> tracepoint_probe_register(struct tracepoint *tp, void *probe, void *data);
> extern int
> @@ -75,10 +78,16 @@ int unregister_tracepoint_module_notifier(struct
> notifier_block *nb)
>  * probe unregistration and the end of module exit to make sure there is no
>  * caller executing a probe when it is freed.
>  */
> +#ifdef CONFIG_TRACEPOINTS
> static inline void tracepoint_synchronize_unregister(void)
> {
> + synchronize_srcu(&tracepoint_srcu);
>   synchronize_sched();
> }
> +#else
> +static inline void tracepoint_synchronize_unregister(void)
> +{ }
> +#endif
> 
> #ifdef CONFIG_HAVE_SYSCALL_TRACEPOINTS
> extern int syscall_regfunc(void);
> @@ -129,18 +138,34 @@ extern void syscall_unregfunc(void);
>  * as "(void *, void)". The DECLARE_TRACE_NOARGS() will pass in just
>  * "void *data", where as the DECLARE_TRACE() will pass in "void *data, 
> proto".
>  */
> -#define __DO_TRACE(tp, proto, args, cond, rcucheck)  \
> +#define __DO_TRACE(tp, proto, args, cond, rcuidle)   \
>   do {\
>   struct tracepoint_func *it_func_ptr;\
>   void *it_func;  \
>   void *__data;   \
> + int __maybe_unused idx = 0; \
>   \
>   if (!(cond))\
>   return; \
> - if (rcucheck)   \
> - rcu_irq_enter_irqson(); \
> - rcu_read_lock_sched_notrace();  \
> - it_func_ptr = rcu_dereference_sched((tp)->funcs);   \
> + \
> + /* srcu can't be used from NMI */   \
> + if (rcuidle && in_nmi())\
> + WARN_ON_ONCE(1);\
> + \
> + /* keep srcu and sched-rcu usage consistent */  \
> + preempt_disable_notrace();  \
> + \
> + /*

Re: [PATCH 1/3] dt-bindings: clk: g12a: New binding for Meson-G12A SoC

[Martin Blumenstingl]

On Wed, Jul 11, 2018 at 3:06 PM Jian Hu  wrote:
>
>
>
> On 2018/7/10 17:29, Jerome Brunet wrote:
> > On Mon, 2018-07-09 at 19:12 +0800, Jian Hu wrote:
> >> Add new binding for Meson-G12A SoC Everything-Else part
> >
> > nitpick: I would prefer if the words 'clock' and 'controller' was somewhere 
> > in
> > the description.
> >
> > Maybe "add new clock controller compatible for the EE domain of the g12a 
> > SoC" ?
>
> Patch 1 and 2 have squashed, the commit message focuse which one？
I would use the information from both commit messages (for example you
could use the what Jerome already suggested and extend it with "and
add a header file which contains preprocessor macros to identify the
clocks provided by this clock controller")


Regards
Martin

Re: [PATCH 1/2] mux:adgs1408/1409: New driver for Analog Devices ADGS1408/1409 mux …

[Lars-Peter Clausen]

On 07/14/2018 02:04 PM, Peter Rosin wrote:
[...]
>> +static int adgs140x_spi_reg_write(struct spi_device *spi,
>> +u8 reg_addr, u8 reg_data)
>> +{
>> +u8 tx_buf[2];
>> +
>> +tx_buf[0] = reg_addr;
>> +tx_buf[1] = reg_data;
>> +
>> +return spi_write_then_read(spi, tx_buf, sizeof(tx_buf), NULL, 0);
> 
>   return spi_write(spi, tx_buf, sizeof(tx_buf));

Be aware spi_write_then_read() can handle on stack buffers, spi_write() can't.

Re: [PATCH] rtc: jz4740: Add support for the JZ4725B, JZ4760, JZ4770

[Paul Cercueil]

Le sam. 14 juil. 2018 à 15:32, Alexandre Belloni 
 a écrit :

On 14/07/2018 15:25:33+0200, Paul Cercueil wrote:

 Hi Alexandre,

 Le sam. 14 juil. 2018 à 15:19, Alexandre Belloni
  a écrit :
 > Hello,
 >
 > On 13/07/2018 17:14:24+0200, Paul Cercueil wrote:
 > >  The RTC in the JZ4725B works just like the one in the JZ4740.
 > >
 > >  The RTC in the JZ4760 and JZ4770 work just like the one in the
 > > JZ4780.
 > >
 > >  Signed-off-by: Paul Cercueil 
 > >  ---
 > >   Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt 
|  3

 > > +++
 > >   drivers/rtc/rtc-jz4740.c 
| 11

 > > ++-
 > >   2 files changed, 13 insertions(+), 1 deletion(-)
 > >
 > >  diff --git
 > > a/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
 > > b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
 > >  index 41c7ae18fd7b..a9e821de84f2 100644
 > >  --- 
a/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
 > >  +++ 
b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt

 > >  @@ -4,6 +4,9 @@ Required properties:
 > >
 > >   - compatible: One of:
 > > - "ingenic,jz4740-rtc" - for use with the JZ4740 SoC
 > >  +  - "ingenic,jz4725b-rtc" - for use with the JZ4725B SoC
 > >  +  - "ingenic,jz4760-rtc" - for use with the JZ4760 SoC
 > >  +  - "ingenic,jz4770-rtc" - for use with the JZ4770 SoC
 > > - "ingenic,jz4780-rtc" - for use with the JZ4780 SoC
 > >   - reg: Address range of rtc register set
 > >   - interrupts: IRQ number for the alarm interrupt
 > >  diff --git a/drivers/rtc/rtc-jz4740.c 
b/drivers/rtc/rtc-jz4740.c

 > >  index d0a891777f44..1c867e3a0ea5 100644
 > >  --- a/drivers/rtc/rtc-jz4740.c
 > >  +++ b/drivers/rtc/rtc-jz4740.c
 > >  @@ -54,6 +54,9 @@
 > >
 > >   enum jz4740_rtc_type {
 > >  ID_JZ4740,
 > >  +   ID_JZ4725B,
 > >  +   ID_JZ4760,
 > >  +   ID_JZ4770,
 >
 > I wouldn't introduce those ids unless there are handling 
differences at

 > some point.

 Well there are handling differences, see below.

 > >  ID_JZ4780,
 > >   };
 > >
 > >  @@ -114,7 +117,7 @@ static inline int 
jz4740_rtc_reg_write(struct

 > > jz4740_rtc *rtc, size_t reg,
 > >   {
 > >  int ret = 0;
 > >
 > >  -   if (rtc->type >= ID_JZ4780)
 > >  +   if (rtc->type >= ID_JZ4760)
 >
 > This would avoid that change (and the test would preferably be
 > (rtc->type == ID_JZ4780))

 That branch should be taken if the SoC is JZ4760, JZ4770 or JZ4780.
 It should not be taken if the SoC is JZ4740 or JZ4725B.


Sure but you can achieve that with only 2 ids...



 > >  ret = jz4780_rtc_enable_write(rtc);
 > >  if (ret == 0)
 > >  ret = jz4740_rtc_wait_write_ready(rtc);
 > >  @@ -300,6 +303,9 @@ static void jz4740_rtc_power_off(void)
 > >
 > >   static const struct of_device_id jz4740_rtc_of_match[] = {
 > >   	{ .compatible = "ingenic,jz4740-rtc", .data = (void 
*)ID_JZ4740 },
 > >  +	{ .compatible = "ingenic,jz4725b-rtc", .data = (void 
*)ID_JZ4725B

 > > },
 > >  +	{ .compatible = "ingenic,jz4760-rtc", .data = (void 
*)ID_JZ4760 },
 > >  +	{ .compatible = "ingenic,jz4770-rtc", .data = (void 
*)ID_JZ4770 },


By doing the correct mapping here e.g:

{ .compatible = "ingenic,jz4725b-rtc", .data = (void *)ID_JZ4740 },


Not very pretty and future-proof if you ask me...
But you're the boss...

 > >   	{ .compatible = "ingenic,jz4780-rtc", .data = (void 
*)ID_JZ4780 },

 > >  {},
 > >   };
 > >  @@ -428,6 +434,9 @@ static const struct dev_pm_ops 
jz4740_pm_ops = {

 > >
 > >   static const struct platform_device_id jz4740_rtc_ids[] = {
 > >  { "jz4740-rtc", ID_JZ4740 },
 > >  +   { "jz4725b-rtc", ID_JZ4725B },
 > >  +   { "jz4760-rtc", ID_JZ4760 },
 > >  +   { "jz4770-rtc", ID_JZ4770 },


And here


 > >  { "jz4780-rtc", ID_JZ4780 },
 > >  {}
 > >   };
 > >  --
 > >  2.11.0
 > >
 >
 > --
 > Alexandre Belloni, Bootlin (formerly Free Electrons)
 > Embedded Linux and Kernel engineering
 > https://bootlin.com



--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH] rtc: jz4740: Add support for the JZ4725B, JZ4760, JZ4770

[Alexandre Belloni]

On 14/07/2018 15:25:33+0200, Paul Cercueil wrote:
> Hi Alexandre,
> 
> Le sam. 14 juil. 2018 à 15:19, Alexandre Belloni
>  a écrit :
> > Hello,
> > 
> > On 13/07/2018 17:14:24+0200, Paul Cercueil wrote:
> > >  The RTC in the JZ4725B works just like the one in the JZ4740.
> > > 
> > >  The RTC in the JZ4760 and JZ4770 work just like the one in the
> > > JZ4780.
> > > 
> > >  Signed-off-by: Paul Cercueil 
> > >  ---
> > >   Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt |  3
> > > +++
> > >   drivers/rtc/rtc-jz4740.c | 11
> > > ++-
> > >   2 files changed, 13 insertions(+), 1 deletion(-)
> > > 
> > >  diff --git
> > > a/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
> > > b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
> > >  index 41c7ae18fd7b..a9e821de84f2 100644
> > >  --- a/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
> > >  +++ b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
> > >  @@ -4,6 +4,9 @@ Required properties:
> > > 
> > >   - compatible: One of:
> > > - "ingenic,jz4740-rtc" - for use with the JZ4740 SoC
> > >  +  - "ingenic,jz4725b-rtc" - for use with the JZ4725B SoC
> > >  +  - "ingenic,jz4760-rtc" - for use with the JZ4760 SoC
> > >  +  - "ingenic,jz4770-rtc" - for use with the JZ4770 SoC
> > > - "ingenic,jz4780-rtc" - for use with the JZ4780 SoC
> > >   - reg: Address range of rtc register set
> > >   - interrupts: IRQ number for the alarm interrupt
> > >  diff --git a/drivers/rtc/rtc-jz4740.c b/drivers/rtc/rtc-jz4740.c
> > >  index d0a891777f44..1c867e3a0ea5 100644
> > >  --- a/drivers/rtc/rtc-jz4740.c
> > >  +++ b/drivers/rtc/rtc-jz4740.c
> > >  @@ -54,6 +54,9 @@
> > > 
> > >   enum jz4740_rtc_type {
> > >   ID_JZ4740,
> > >  +ID_JZ4725B,
> > >  +ID_JZ4760,
> > >  +ID_JZ4770,
> > 
> > I wouldn't introduce those ids unless there are handling differences at
> > some point.
> 
> Well there are handling differences, see below.
> 
> > >   ID_JZ4780,
> > >   };
> > > 
> > >  @@ -114,7 +117,7 @@ static inline int jz4740_rtc_reg_write(struct
> > > jz4740_rtc *rtc, size_t reg,
> > >   {
> > >   int ret = 0;
> > > 
> > >  -if (rtc->type >= ID_JZ4780)
> > >  +if (rtc->type >= ID_JZ4760)
> > 
> > This would avoid that change (and the test would preferably be
> > (rtc->type == ID_JZ4780))
> 
> That branch should be taken if the SoC is JZ4760, JZ4770 or JZ4780.
> It should not be taken if the SoC is JZ4740 or JZ4725B.

Sure but you can achieve that with only 2 ids...

> 
> > >   ret = jz4780_rtc_enable_write(rtc);
> > >   if (ret == 0)
> > >   ret = jz4740_rtc_wait_write_ready(rtc);
> > >  @@ -300,6 +303,9 @@ static void jz4740_rtc_power_off(void)
> > > 
> > >   static const struct of_device_id jz4740_rtc_of_match[] = {
> > >   { .compatible = "ingenic,jz4740-rtc", .data = (void *)ID_JZ4740 
> > > },
> > >  +{ .compatible = "ingenic,jz4725b-rtc", .data = (void 
> > > *)ID_JZ4725B
> > > },
> > >  +{ .compatible = "ingenic,jz4760-rtc", .data = (void *)ID_JZ4760 
> > > },
> > >  +{ .compatible = "ingenic,jz4770-rtc", .data = (void *)ID_JZ4770 
> > > },

By doing the correct mapping here e.g:

{ .compatible = "ingenic,jz4725b-rtc", .data = (void *)ID_JZ4740 },

> > >   { .compatible = "ingenic,jz4780-rtc", .data = (void *)ID_JZ4780 
> > > },
> > >   {},
> > >   };
> > >  @@ -428,6 +434,9 @@ static const struct dev_pm_ops jz4740_pm_ops = {
> > > 
> > >   static const struct platform_device_id jz4740_rtc_ids[] = {
> > >   { "jz4740-rtc", ID_JZ4740 },
> > >  +{ "jz4725b-rtc", ID_JZ4725B },
> > >  +{ "jz4760-rtc", ID_JZ4760 },
> > >  +{ "jz4770-rtc", ID_JZ4770 },

And here

> > >   { "jz4780-rtc", ID_JZ4780 },
> > >   {}
> > >   };
> > >  --
> > >  2.11.0
> > > 
> > 
> > --
> > Alexandre Belloni, Bootlin (formerly Free Electrons)
> > Embedded Linux and Kernel engineering
> > https://bootlin.com
> 

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH] rtc: jz4740: Add support for the JZ4725B, JZ4760, JZ4770

[Paul Cercueil]

Hi Alexandre,

Le sam. 14 juil. 2018 à 15:19, Alexandre Belloni 
 a écrit :

Hello,

On 13/07/2018 17:14:24+0200, Paul Cercueil wrote:

 The RTC in the JZ4725B works just like the one in the JZ4740.

 The RTC in the JZ4760 and JZ4770 work just like the one in the 
JZ4780.


 Signed-off-by: Paul Cercueil 
 ---
  Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt |  3 
+++
  drivers/rtc/rtc-jz4740.c | 11 
++-

  2 files changed, 13 insertions(+), 1 deletion(-)

 diff --git 
a/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt 
b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt

 index 41c7ae18fd7b..a9e821de84f2 100644
 --- a/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
 +++ b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
 @@ -4,6 +4,9 @@ Required properties:

  - compatible: One of:
- "ingenic,jz4740-rtc" - for use with the JZ4740 SoC
 +  - "ingenic,jz4725b-rtc" - for use with the JZ4725B SoC
 +  - "ingenic,jz4760-rtc" - for use with the JZ4760 SoC
 +  - "ingenic,jz4770-rtc" - for use with the JZ4770 SoC
- "ingenic,jz4780-rtc" - for use with the JZ4780 SoC
  - reg: Address range of rtc register set
  - interrupts: IRQ number for the alarm interrupt
 diff --git a/drivers/rtc/rtc-jz4740.c b/drivers/rtc/rtc-jz4740.c
 index d0a891777f44..1c867e3a0ea5 100644
 --- a/drivers/rtc/rtc-jz4740.c
 +++ b/drivers/rtc/rtc-jz4740.c
 @@ -54,6 +54,9 @@

  enum jz4740_rtc_type {
ID_JZ4740,
 +  ID_JZ4725B,
 +  ID_JZ4760,
 +  ID_JZ4770,


I wouldn't introduce those ids unless there are handling differences 
at

some point.


Well there are handling differences, see below.


ID_JZ4780,
  };

 @@ -114,7 +117,7 @@ static inline int jz4740_rtc_reg_write(struct 
jz4740_rtc *rtc, size_t reg,

  {
int ret = 0;

 -  if (rtc->type >= ID_JZ4780)
 +  if (rtc->type >= ID_JZ4760)


This would avoid that change (and the test would preferably be 
(rtc->type == ID_JZ4780))


That branch should be taken if the SoC is JZ4760, JZ4770 or JZ4780.
It should not be taken if the SoC is JZ4740 or JZ4725B.


ret = jz4780_rtc_enable_write(rtc);
if (ret == 0)
ret = jz4740_rtc_wait_write_ready(rtc);
 @@ -300,6 +303,9 @@ static void jz4740_rtc_power_off(void)

  static const struct of_device_id jz4740_rtc_of_match[] = {
{ .compatible = "ingenic,jz4740-rtc", .data = (void *)ID_JZ4740 },
 +	{ .compatible = "ingenic,jz4725b-rtc", .data = (void *)ID_JZ4725B 
},

 +  { .compatible = "ingenic,jz4760-rtc", .data = (void *)ID_JZ4760 },
 +  { .compatible = "ingenic,jz4770-rtc", .data = (void *)ID_JZ4770 },
{ .compatible = "ingenic,jz4780-rtc", .data = (void *)ID_JZ4780 },
{},
  };
 @@ -428,6 +434,9 @@ static const struct dev_pm_ops jz4740_pm_ops = {

  static const struct platform_device_id jz4740_rtc_ids[] = {
{ "jz4740-rtc", ID_JZ4740 },
 +  { "jz4725b-rtc", ID_JZ4725B },
 +  { "jz4760-rtc", ID_JZ4760 },
 +  { "jz4770-rtc", ID_JZ4770 },
{ "jz4780-rtc", ID_JZ4780 },
{}
  };
 --
 2.11.0



--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH] Input: synaptics - Lenovo ThinkPad T25 and T480 devices should use RMI

[kitsunyan]

Hi, Teika. (Yes, you are right.)

I should've worried about real name earlier since I already sent the patch from 
pseudonym. I don't mind if the patch will be authored by maintainer, replacing 
my sign with "reported-by". (Hope it's possible.)

Regards,
kitsunyan

On 14/07/18 09:35, Teika Kazura wrote:
> Hi, kitsunyan. (Привет, perhaps?) Thanks for you patch, but the "signed-off" 
> tag needs your real name. You can re-submit your patch conforming to that 
> rule. Or if you're ok, the kernel maintainer can instead sign it off, adding 
> "reported-by: kitsunyan ". (I'm not sure about the latter 
> case. Sorry if I'm wrong.)
>
> You can find the instruction in  tree>/Documentation/process/submitting-patches.rst .
>
> Best regards / Пока, 
> Teika (Teika kazura)
>
>
> From: kitsunyan 
> Subject: [PATCH] Input: synaptics - Lenovo ThinkPad T25 and T480 devices 
> should use RMI
> Date: Sat,  7 Jul 2018 08:19:12 +0300
>
>> The touchpads on both T25 and T480 are accessible over SMBUS/RMI.
>>
>> Signed-off-by: kitsunyan 
>> ---
>>  drivers/input/mouse/synaptics.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/input/mouse/synaptics.c 
>> b/drivers/input/mouse/synaptics.c
>> index 55d33500d55e..be934a082424 100644
>> --- a/drivers/input/mouse/synaptics.c
>> +++ b/drivers/input/mouse/synaptics.c
>> @@ -175,7 +175,9 @@ static const char * const smbus_pnp_ids[] = {
>>  "LEN0071", /* T480 */
>>  "LEN0072", /* X1 Carbon Gen 5 (2017) - Elan/ALPS trackpoint */
>>  "LEN0073", /* X1 Carbon G5 (Elantech) */
>> +"LEN008e", /* T25 */
>>  "LEN0092", /* X1 Carbon 6 */
>> +"LEN0093", /* T480 */
>>  "LEN0096", /* X280 */
>>  "LEN0097", /* X280 -> ALPS trackpoint */
>>  "LEN200f", /* T450s */
>> -- 
>> 2.18.0

Re: [PATCH] rtc: jz4740: Add support for the JZ4725B, JZ4760, JZ4770

[Alexandre Belloni]

Hello,

On 13/07/2018 17:14:24+0200, Paul Cercueil wrote:
> The RTC in the JZ4725B works just like the one in the JZ4740.
> 
> The RTC in the JZ4760 and JZ4770 work just like the one in the JZ4780.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt |  3 +++
>  drivers/rtc/rtc-jz4740.c | 11 ++-
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt 
> b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
> index 41c7ae18fd7b..a9e821de84f2 100644
> --- a/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
> +++ b/Documentation/devicetree/bindings/rtc/ingenic,jz4740-rtc.txt
> @@ -4,6 +4,9 @@ Required properties:
>  
>  - compatible: One of:
>- "ingenic,jz4740-rtc" - for use with the JZ4740 SoC
> +  - "ingenic,jz4725b-rtc" - for use with the JZ4725B SoC
> +  - "ingenic,jz4760-rtc" - for use with the JZ4760 SoC
> +  - "ingenic,jz4770-rtc" - for use with the JZ4770 SoC
>- "ingenic,jz4780-rtc" - for use with the JZ4780 SoC
>  - reg: Address range of rtc register set
>  - interrupts: IRQ number for the alarm interrupt
> diff --git a/drivers/rtc/rtc-jz4740.c b/drivers/rtc/rtc-jz4740.c
> index d0a891777f44..1c867e3a0ea5 100644
> --- a/drivers/rtc/rtc-jz4740.c
> +++ b/drivers/rtc/rtc-jz4740.c
> @@ -54,6 +54,9 @@
>  
>  enum jz4740_rtc_type {
>   ID_JZ4740,
> + ID_JZ4725B,
> + ID_JZ4760,
> + ID_JZ4770,

I wouldn't introduce those ids unless there are handling differences at
some point.

>   ID_JZ4780,
>  };
>  
> @@ -114,7 +117,7 @@ static inline int jz4740_rtc_reg_write(struct jz4740_rtc 
> *rtc, size_t reg,
>  {
>   int ret = 0;
>  
> - if (rtc->type >= ID_JZ4780)
> + if (rtc->type >= ID_JZ4760)

This would avoid that change (and the test would preferably be (rtc->type == 
ID_JZ4780))

>   ret = jz4780_rtc_enable_write(rtc);
>   if (ret == 0)
>   ret = jz4740_rtc_wait_write_ready(rtc);
> @@ -300,6 +303,9 @@ static void jz4740_rtc_power_off(void)
>  
>  static const struct of_device_id jz4740_rtc_of_match[] = {
>   { .compatible = "ingenic,jz4740-rtc", .data = (void *)ID_JZ4740 },
> + { .compatible = "ingenic,jz4725b-rtc", .data = (void *)ID_JZ4725B },
> + { .compatible = "ingenic,jz4760-rtc", .data = (void *)ID_JZ4760 },
> + { .compatible = "ingenic,jz4770-rtc", .data = (void *)ID_JZ4770 },
>   { .compatible = "ingenic,jz4780-rtc", .data = (void *)ID_JZ4780 },
>   {},
>  };
> @@ -428,6 +434,9 @@ static const struct dev_pm_ops jz4740_pm_ops = {
>  
>  static const struct platform_device_id jz4740_rtc_ids[] = {
>   { "jz4740-rtc", ID_JZ4740 },
> + { "jz4725b-rtc", ID_JZ4725B },
> + { "jz4760-rtc", ID_JZ4760 },
> + { "jz4770-rtc", ID_JZ4770 },
>   { "jz4780-rtc", ID_JZ4780 },
>   {}
>  };
> -- 
> 2.11.0
> 

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[tip:core/urgent] objtool: Use '.strtab' if '.shstrtab' doesn't exist, to support ORC tables on Clang

[tip-bot for Simon Ser]

Commit-ID:  6d77d3b43ad84a48b502f02dc618e7c36737bdfe
Gitweb: https://git.kernel.org/tip/6d77d3b43ad84a48b502f02dc618e7c36737bdfe
Author: Simon Ser 
AuthorDate: Mon, 9 Jul 2018 11:17:22 -0500
Committer:  Ingo Molnar 
CommitDate: Sat, 14 Jul 2018 14:59:42 +0200

objtool: Use '.strtab' if '.shstrtab' doesn't exist, to support ORC tables on 
Clang

Clang puts its section header names in the '.strtab' section instead of
'.shstrtab', which causes objtool to fail with a "can't find
.shstrtab section" warning when attempting to write ORC metadata to an
object file.

If '.shstrtab' doesn't exist, use '.strtab' instead.

Signed-off-by: Simon Ser 
Signed-off-by: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/d1c1c3fe55872be433da7bc5e1860538506229ba.1531153015.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 tools/objtool/elf.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 0d1acb704f64..7ec85d567598 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -519,10 +519,12 @@ struct section *elf_create_section(struct elf *elf, const 
char *name,
sec->sh.sh_flags = SHF_ALLOC;
 
 
-   /* Add section name to .shstrtab */
+   /* Add section name to .shstrtab (or .strtab for Clang) */
shstrtab = find_section_by_name(elf, ".shstrtab");
+   if (!shstrtab)
+   shstrtab = find_section_by_name(elf, ".strtab");
if (!shstrtab) {
-   WARN("can't find .shstrtab section");
+   WARN("can't find .shstrtab or .strtab section");
return NULL;
}