Re: [v4] coccinelle: semantic patch for missing put_device()

[Julia Lawall]

On Fri, 15 Feb 2019, Markus Elfring wrote:

> >> So I plan to modify the following to capture both cases:
> >> -local idexpression id;
> >> +expression id;
> >
> > I'm not sure that this is a good idea.
>
> Why have you got doubts here?
>
>
> > There is likely no need for a put in the latter case.
>
> I have got understanding difficulties for such information.
> What did you try to express with this sentence finally?

The whole goal of the semantic patch is to ensure that put_device is
called when needed.  If the value is stored in a structure, then someone
else will likely take care of calling put_device later when the structure
is destroyed.

julia

[PATCH] pinctrl: nomadik: fix possible object reference leak

[WangBo]

The of_find_device_by_node takes a reference to the struct device
when find the match device ,we should release it when fail.

Signed-off-by: WangBo 
---
 drivers/pinctrl/nomadik/pinctrl-nomadik.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/nomadik/pinctrl-nomadik.c 
b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
index 4cc2c47f8778..ec02739bd21b 100644
--- a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
+++ b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
@@ -1056,17 +1056,22 @@ static struct nmk_gpio_chip 
*nmk_gpio_populate_chip(struct device_node *np,
}
if (of_property_read_u32(np, "gpio-bank", &id)) {
dev_err(&pdev->dev, "populate: gpio-bank property not found\n");
+   platform_device_put(gpio_pdev);
return ERR_PTR(-EINVAL);
}
 
/* Already populated? */
nmk_chip = nmk_gpio_chips[id];
-   if (nmk_chip)
+   if (nmk_chip) {
+   platform_device_put(gpio_pdev);
return nmk_chip;
+   }
 
nmk_chip = devm_kzalloc(&pdev->dev, sizeof(*nmk_chip), GFP_KERNEL);
-   if (!nmk_chip)
+   if (!nmk_chip) {
+   platform_device_put(gpio_pdev);
return ERR_PTR(-ENOMEM);
+   }
 
nmk_chip->bank = id;
chip = &nmk_chip->chip;
@@ -1077,13 +1082,17 @@ static struct nmk_gpio_chip 
*nmk_gpio_populate_chip(struct device_node *np,
 
res = platform_get_resource(gpio_pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(&pdev->dev, res);
-   if (IS_ERR(base))
+   if (IS_ERR(base)) {
+   platform_device_put(gpio_pdev);
return ERR_CAST(base);
+   }
nmk_chip->addr = base;
 
clk = clk_get(&gpio_pdev->dev, NULL);
-   if (IS_ERR(clk))
+   if (IS_ERR(clk)) {
+   platform_device_put(gpio_pdev);
return (void *) clk;
+   }
clk_prepare(clk);
nmk_chip->clk = clk;
 
-- 
2.15.2

Re: [PATCH 09/11] lib: consolidate the GENERIC_CSUM symbol

[Masahiro Yamada]

On Thu, Feb 14, 2019 at 2:41 AM Christoph Hellwig  wrote:
>
> Add one definition to lib/Kconfig and let the architectures
> select if it supported.
>
> Signed-off-by: Christoph Hellwig 



> diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
> index 52b4d48e351a..9de1d983a99a 100644
> --- a/arch/unicore32/Kconfig
> +++ b/arch/unicore32/Kconfig
> @@ -29,9 +29,6 @@ config UNICORE32
>   designs licensed by PKUnity Ltd.
>   Please see web page at .
>
> -config GENERIC_CSUM
> -   def_bool y
> -
>  config NO_IOPORT_MAP
> bool
>



You missed to add 'select GENERIC_CSUM' for unicore32.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] powerpc/ptrace: Add prototype for function pt_regs_check

[Mathieu Malaterre]

On Sat, Dec 8, 2018 at 4:46 PM Mathieu Malaterre  wrote:
>
> `pt_regs_check` is a dummy function, its purpose is to break the build
> if struct pt_regs and struct user_pt_regs don't match.
>
> This function has no functionnal purpose, and will get eliminated at
> link time or after init depending on CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
>
> This commit adds a prototype to fix warning at W=1:
>
>   arch/powerpc/kernel/ptrace.c:3339:13: error: no previous prototype for 
> ‘pt_regs_check’ [-Werror=missing-prototypes]
>
> Suggested-by: Christophe Leroy 
> Signed-off-by: Mathieu Malaterre 
> ---
>  arch/powerpc/kernel/ptrace.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> index a398999d0770..341c0060b4c8 100644
> --- a/arch/powerpc/kernel/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace.c
> @@ -3338,6 +3338,10 @@ void do_syscall_trace_leave(struct pt_regs *regs)
> user_enter();
>  }
>
> +void __init pt_regs_check(void);
> +/* dummy function, its purpose is to break the build if struct pt_regs and
> + * struct user_pt_regs don't match.
> + */

Another trick which seems to work with GCC is:

-void __init pt_regs_check(void)
+static inline void __init pt_regs_check(void)

>  void __init pt_regs_check(void)
>  {
> BUILD_BUG_ON(offsetof(struct pt_regs, gpr) !=
> --
> 2.19.2
>

Re: [PATCH 01/11] powerpc: remove dead ifdefs in

[Christophe Leroy]

Le 14/02/2019 à 18:05, Christoph Hellwig a écrit :

On Thu, Feb 14, 2019 at 09:26:19AM +0100, Christophe Leroy wrote:

Could you also remove the 'config GENERIC_CSUM' item in
arch/powerpc/Kconfig ?


All the separate declarations go away later in this series.



I saw, but the purpose of the later patch is to replace arch defined 
GENERIC_CSUM by a common one that arches select. For the powerpc you are 
not in that case as the powerpc does not select GENERIC_CSUM.


So I really believe that all stale bits of remaining GENERIC_CSUM in 
powerpc should go away as a single dedicated patch, as a fix of commit 
d4fde568a34a ("powerpc/64: Use optimized checksum routines on 
little-endian")


Regarding the #ifdef __KERNEL__ , I think we should do a wide cleanup in 
arch/powerpc/include/asm, not only asm/checksum.h


Christophe

答复: [PATCH] x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32

[chenzefeng (A)]

HI, Jiri Kosina,

On Fri, 15 Feb 2019, Jiri Kosina wrote:
>On Fri, 15 Feb 2019, chenzefeng (A) wrote:

>> On x86-64, for 32-bit PC-relacive branches, we can generate PLT32 
>> relocation, instead of PC32 relocation. and R_X86_64_PLT32 can be 
>> treated the same as R_X86_64_PC32 since linux kernel doesn't use PLT.
>> 
>> In linux 4.4 commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as
>> R_X86_64_PC32") been fixed for the module loading, but not fixed for 
>> livepatch relocation, which will fail to load livepatch with the error 
>> message as follow: relocation failed for symbol  at 
>> > address>
>> 
>> Signed-off-by: chenzefeng 

>What kernel version is this patch based on? We've got rid of x86-specific 
>module loading stub and offloaded all the relocation handling to generic kmod 
>loader long time ago.

The patch is based on kernel version Linux 4.4.174.

Thanks.
chenzefeng

Re: [v4] coccinelle: semantic patch for missing put_device()

[Markus Elfring]

> The whole goal of the semantic patch is to ensure that put_device is
> called when needed.

Thanks for this clarification.

The software development goal seems to be clear to some degree.


> If the value is stored in a structure,

Will any further means become relevant for the discussed data processing?


> then someone else will likely take care of calling put_device later
> when the structure is destroyed.

Such a view is reasonable.

Are there any additional source code analysis and software development 
challenges
to consider for safer resource management?

Regards,
Markus

Re: [PATCH] USB: serial: ftdi_sio: add ID for Hjelmslund Electronics USB485

[Johan Hovold]

On Thu, Feb 14, 2019 at 07:45:33PM +, Mans Rullgard wrote:
> This adds the USB ID of the Hjelmslund Electronics USB485 Iso stick.
> 
> Signed-off-by: Mans Rullgard 

Applied, thanks.

Johan

Re: [PATCH] powerpc/ptrace: Add prototype for function pt_regs_check

[Christophe Leroy]

Le 15/02/2019 à 09:11, Mathieu Malaterre a écrit :

On Sat, Dec 8, 2018 at 4:46 PM Mathieu Malaterre  wrote:


`pt_regs_check` is a dummy function, its purpose is to break the build
if struct pt_regs and struct user_pt_regs don't match.

This function has no functionnal purpose, and will get eliminated at
link time or after init depending on CONFIG_LD_DEAD_CODE_DATA_ELIMINATION

This commit adds a prototype to fix warning at W=1:

   arch/powerpc/kernel/ptrace.c:3339:13: error: no previous prototype for 
‘pt_regs_check’ [-Werror=missing-prototypes]

Suggested-by: Christophe Leroy 
Signed-off-by: Mathieu Malaterre 
---
  arch/powerpc/kernel/ptrace.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index a398999d0770..341c0060b4c8 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -3338,6 +3338,10 @@ void do_syscall_trace_leave(struct pt_regs *regs)
 user_enter();
  }

+void __init pt_regs_check(void);
+/* dummy function, its purpose is to break the build if struct pt_regs and
+ * struct user_pt_regs don't match.
+ */


Another trick which seems to work with GCC is:

-void __init pt_regs_check(void)
+static inline void __init pt_regs_check(void)


Does this really work ? Did you test to ensure that the BUILD_BUG_ON 
still detect mismatch between struct pt_regs and struct user_pt_regs ?


Christophe




  void __init pt_regs_check(void)
  {
 BUILD_BUG_ON(offsetof(struct pt_regs, gpr) !=
--
2.19.2

[PATCH] net: dsa: Implement flow_dissect callback for tag_dsa.

[Rundong Ge]

RPS not work for DSA devices since the 'skb_get_hash'
will always get the invalid hash for dsa tagged packets.

"[PATCH] tag_mtk: add flow_dissect callback to the ops struct"
introduced the flow_dissect callback to get the right hash for
MTK tagged packet. And tag_dsa also needs to implement
the callback.

Signed-off-by: Rundong Ge 
---
 net/dsa/tag_dsa.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/net/dsa/tag_dsa.c b/net/dsa/tag_dsa.c
index 8b2f92e..67ff3fa 100644
--- a/net/dsa/tag_dsa.c
+++ b/net/dsa/tag_dsa.c
@@ -146,8 +146,17 @@ static struct sk_buff *dsa_rcv(struct sk_buff *skb, struct 
net_device *dev,
return skb;
 }
 
+static int dsa_tag_flow_dissect(const struct sk_buff *skb, __be16 *proto,
+   int *offset)
+{
+   *offset = 4;
+   *proto = ((__be16 *)skb->data)[1];
+   return 0;
+}
+
 const struct dsa_device_ops dsa_netdev_ops = {
.xmit   = dsa_xmit,
.rcv= dsa_rcv,
+   .flow_dissect   = dsa_tag_flow_dissect,
.overhead = DSA_HLEN,
 };
-- 
1.8.3.1

Re: [PATCH] tee: optee: update optee_msg.h and optee_smc.h to dual license

[Jens Wiklander]

Hi Jerome,

On Fri, Feb 08, 2019 at 04:42:06PM +0100, Jerome Forissier wrote:
> The files optee_msg.h and optee_smc.h (under drivers/tee/optee) contain
> information originating from the OP-TEE OS project [1] [2], where the
> licensing terms are BSD 2-Clause. Therefore, apply a dual license to
> those files.
> 
> [1] https://github.com/OP-TEE/optee_os/blob/master/core/include/optee_msg.h
> [2] 
> https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/include/sm/optee_smc.h
> 
> Signed-off-by: Jerome Forissier 

I'll pick this up.

I'm prefixing the two link lines with "Link:" to avoid the checkpatch
warning.

Thanks,
Jens

Re: [PATCH] efi/libstub: refactor cmd_stubcopy

[Ard Biesheuvel]

On Fri, 15 Feb 2019 at 06:49, Masahiro Yamada
 wrote:
>
> On Tue, Feb 12, 2019 at 4:26 PM Ard Biesheuvel
>  wrote:
> >
> > On Tue, 12 Feb 2019 at 04:45, Masahiro Yamada
> >  wrote:
> > >
> > > It took me a while to understand what is going on in the nested
> > > if-blocks.
> > >
> > > Simplify it by removing unneeded code.
> > >
> > >   - if_changed automatically adds 'set -e', so any failure in the
> > > series of commands makes it immediately fail as a whole.
> > > So, the outer if block is entirely redundant.
> > >
> > >   - Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special
> > > target"), GNU Make automatically deletes the target on any failure
> > > in its recipe. The explicit 'rm -f $@' is redundant.
> > >
> > >   - surrounding commands with ( ) will spawn a subshell to execute them
> > > in it, but it is rarely useful to do so.
> > >
> > > Signed-off-by: Masahiro Yamada 
> >
> > Assuming that it still works as expected:
> >
> > Acked-by: Ard Biesheuvel 
> >
> > You can test this by adding a statically initialized global function
> > pointer to any of the libstub source files that get built for ARM.
> >
> > Thanks!
>
>
> I tried that, and it failed as expected.
>

Great, thanks for double checking.

Are you taking this directly, or do you want me to take it via the EFI
tree? Either is fine with me


>
> $ git diff
> diff --git a/drivers/firmware/efi/libstub/arm32-stub.c
> b/drivers/firmware/efi/libstub/arm32-stub.c
> index becbda4..5ad7bbd 100644
> --- a/drivers/firmware/efi/libstub/arm32-stub.c
> +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> @@ -28,6 +28,8 @@ efi_status_t
> check_platform_features(efi_system_table_t *sys_table_arg)
> return EFI_SUCCESS;
>  }
>
> +void * foo = (void *)check_platform_features;
> +
>  static efi_guid_t screen_info_guid = LINUX_EFI_ARM_SCREEN_INFO_TABLE_GUID;
>
>  struct screen_info *alloc_screen_info(efi_system_table_t *sys_table_arg)
> $ make ARCH=arm  CROSS_COMPILE=arm-linux-gnueabihf- defconfig
> drivers/firmware/efi/libstub/
> *** Default configuration is based on 'multi_v7_defconfig'
> #
> # configuration written to .config
> #
> scripts/kconfig/conf  --syncconfig Kconfig
>   CALLscripts/checksyscalls.sh
>   CC  drivers/firmware/efi/libstub/arm32-stub.o
>   STUBCPY drivers/firmware/efi/libstub/arm32-stub.stub.o
>  R_ARM_ABS32   check_platform_features
> drivers/firmware/efi/libstub/arm32-stub.stub.o: absolute symbol
> references not allowed in the EFI stub
> drivers/firmware/efi/libstub/Makefile:80: recipe for target
> 'drivers/firmware/efi/libstub/arm32-stub.stub.o' failed
> make[3]: *** [drivers/firmware/efi/libstub/arm32-stub.stub.o] Error 1
> make[3]: *** Deleting file 'drivers/firmware/efi/libstub/arm32-stub.stub.o'
> Makefile:1705: recipe for target 'drivers/firmware/efi/libstub/' failed
> make[2]: *** [drivers/firmware/efi/libstub/] Error 2
> /home/masahiro/workspace/bsp/linux/Makefile:300: recipe for target
> '__build_one_by_one' failed
> make[1]: *** [__build_one_by_one] Error 2
> Makefile:160: recipe for target 'sub-make' failed
> make: *** [sub-make] Error 2
>
>
>
>
>
> --
> Best Regards
> Masahiro Yamada

Re: [PATCH] video/macfb: Remove redundant code

[Geert Uytterhoeven]

On Fri, Feb 15, 2019 at 3:19 AM Finn Thain  wrote:
> The value of info->var.bits_per_pixel get checked in macfb_setcolreg().
> Remove additional checks as they are redundant.
>
> macfb_defined.activate gets initialized to FB_ACTIVATE_NOW by the struct
> initializer. Remove redundant assignments.
>
> macfb_defined.bits_per_pixel, .width and .height all get assigned
> unconditionally. Remove redundant initializers.
>
> Cc: linux-m...@lists.linux-m68k.org
> Tested-by: Stan Johnson 
> Signed-off-by: Finn Thain 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2 0/2] drm/omap: panel-tpo-td028ttec1: add backlight support

[Tomi Valkeinen]

On 15/02/2019 09:12, Andreas Kemnade wrote:
> Hi,
> 
> On Fri, 8 Feb 2019 11:13:33 +0200
> Tomi Valkeinen  wrote:
> 
>> On 05/02/2019 08:38, Andreas Kemnade wrote:
>>> This panel has a backlight, so add a property describing that and
>>> add the code to use that.
>>> This makes things like xset dpms force off
>>> also turn off the backlight, so we do not need to rely on additional
>>> userspace programs to do that.
>>>
>>> Andreas Kemnade (2):
>>>   drm/omap: panel-tpo-td028ttec1: add backlight support
>>>   dt-bindings: panel: td028ttec1: add backlight property
>>>
>>>  .../devicetree/bindings/display/panel/tpo,td028ttec1.txt   |  2 ++
>>>  drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c| 10 
>>> ++
>>>  2 files changed, 12 insertions(+)
>>>   
>>
>> Thanks, I'll pick these up.
>>
> 
> hmm, that sounds like: patch accepted, will appear in linux-next soon.
> I have not seen it there, or is it just in some branch not merged into
> linux-next. Any new obstacles?

It's too late to get it to the next merge window, so I'll have to wait
until the merge window is closed before I can send these to drm-next.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH] drm/mediatek: add mipi_tx driver for mt8183

[CK Hu]

Hi, Jitao:

On Tue, 2019-02-12 at 14:19 +0800, Jitao Shi wrote:
> This patch adds mipi tx driver support for mt8183.
> 
> Mipi_tx of mt8183 is very different to mt8173.
> 1.Separate mipi tx setting to mtk_mt8173_mipi_tx.c for mt8173
> 2.Separate mipi tx setting to mtk_mt8183_mipi_tx.c for mt8183
> 3.To reuse the common code, make the common functions in mtk_mipi_tx.c
> 
> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/Makefile |   2 +
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 352 ++
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.h|  52 +++
>  drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c | 290 +++
>  drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 168 +
>  5 files changed, 549 insertions(+), 315 deletions(-)
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_mipi_tx.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> 
> diff --git a/drivers/gpu/drm/mediatek/Makefile 
> b/drivers/gpu/drm/mediatek/Makefile
> index 82ae49c64221..8067a4be8311 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -12,6 +12,8 @@ mediatek-drm-y := mtk_disp_color.o \
> mtk_drm_plane.o \
> mtk_dsi.o \
> mtk_mipi_tx.o \
> +   mtk_mt8173_mipi_tx.o \
> +   mtk_mt8183_mipi_tx.o \
> mtk_dpi.o
>  
>  obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c 
> b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index 90e913108950..7591a38ca565 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -11,292 +11,45 @@
>   * GNU General Public License for more details.
>   */
>  
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#define MIPITX_DSI_CON   0x00
> -#define RG_DSI_LDOCORE_ENBIT(0)
> -#define RG_DSI_CKG_LDOOUT_EN BIT(1)
> -#define RG_DSI_BCLK_SEL  (3 << 2)
> -#define RG_DSI_LD_IDX_SEL(7 << 4)
> -#define RG_DSI_PHYCLK_SEL(2 << 8)
> -#define RG_DSI_DSICLK_FREQ_SEL   BIT(10)
> -#define RG_DSI_LPTX_CLMP_EN  BIT(11)
> -
> -#define MIPITX_DSI_CLOCK_LANE0x04
> -#define MIPITX_DSI_DATA_LANE00x08
> -#define MIPITX_DSI_DATA_LANE10x0c
> -#define MIPITX_DSI_DATA_LANE20x10
> -#define MIPITX_DSI_DATA_LANE30x14
> -#define RG_DSI_LNTx_LDOOUT_ENBIT(0)
> -#define RG_DSI_LNTx_CKLANE_ENBIT(1)
> -#define RG_DSI_LNTx_LPTX_IPLUS1  BIT(2)
> -#define RG_DSI_LNTx_LPTX_IPLUS2  BIT(3)
> -#define RG_DSI_LNTx_LPTX_IMINUS  BIT(4)
> -#define RG_DSI_LNTx_LPCD_IPLUS   BIT(5)
> -#define RG_DSI_LNTx_LPCD_IMINUS  BIT(6)
> -#define RG_DSI_LNTx_RT_CODE  (0xf << 8)
> -
> -#define MIPITX_DSI_TOP_CON   0x40
> -#define RG_DSI_LNT_INTR_EN   BIT(0)
> -#define RG_DSI_LNT_HS_BIAS_ENBIT(1)
> -#define RG_DSI_LNT_IMP_CAL_ENBIT(2)
> -#define RG_DSI_LNT_TESTMODE_EN   BIT(3)
> -#define RG_DSI_LNT_IMP_CAL_CODE  (0xf << 4)
> -#define RG_DSI_LNT_AIO_SEL   (7 << 8)
> -#define RG_DSI_PAD_TIE_LOW_ENBIT(11)
> -#define RG_DSI_DEBUG_INPUT_ENBIT(12)
> -#define RG_DSI_PRESERVE  (7 << 13)
> -
> -#define MIPITX_DSI_BG_CON0x44
> -#define RG_DSI_BG_CORE_ENBIT(0)
> -#define RG_DSI_BG_CKEN   BIT(1)
> -#define RG_DSI_BG_DIV(0x3 << 2)
> -#define RG_DSI_BG_FAST_CHARGEBIT(4)
> -#define RG_DSI_VOUT_MSK  (0x3 << 5)
> -#define RG_DSI_V12_SEL   (7 << 5)
> -#define RG_DSI_V10_SEL   (7 << 8)
> -#define RG_DSI_V072_SEL  (7 << 11)
> -#define RG_DSI_V04_SEL   (7 << 14)
> -#define RG_DSI_V032_SEL  (7 << 17)
> -#define RG_DSI_V02_SEL   (7 << 20)
> -#define RG_DSI_BG_R1_TRIM(0xf << 24)
> -#define RG_DSI_BG_R2_TRIM(0xf << 28)
> -
> -#define MIPITX_DSI_PLL_CON0  0x50
> -#define RG_DSI_MPPLL_PLL_EN  BIT(0)
> -#define RG_DSI_MPPLL_DIV_MSK (0x1ff << 1)
> -#define RG_DSI_MPPLL_PREDIV  (3 << 1)
> -#define RG_DSI_MPPLL_TXDIV0  (3 << 3)
> -#define RG_DSI_MPPLL_TXDIV1  (3 << 5)
> -#define RG_DSI_MPPLL_POSDIV  (7 << 7)
> -#define RG_DSI_MPPLL_MONVC_ENBIT(10)
> -#define RG_DSI_MPPLL_MONREF_EN   BIT(11)
> -#define RG_DSI_MPPLL_VOD_EN  BIT(12)
> -
> -#define MIPITX_DSI_PLL_CON1  0x54
> -#define RG_DSI_MPPLL_SDM_FRA_EN  BIT(0)
> -#define RG_DSI_MPPLL_SDM_SSC_PH_INIT BIT(1)
> -#define RG_DSI_MPPLL_SDM_SSC_EN

[PATCH net-next] net: phy: marvell10g: Don't explicitly set Pause and Asym_Pause

[Maxime Chevallier]

The PHY core expects PHY drivers not to set Pause and Asym_Pause bits,
unless the driver only wants to specify one of them due to HW
limitation. In the case of the Marvell10g driver, we don't need to set
them.

Signed-off-by: Maxime Chevallier 
Suggested-by: Andrew Lunn 
---
 drivers/net/phy/marvell10g.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 496805c0ddfe..c04fe5a75129 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -242,9 +242,6 @@ static int mv3310_config_init(struct phy_device *phydev)
phydev->interface != PHY_INTERFACE_MODE_10GKR)
return -ENODEV;
 
-   __set_bit(ETHTOOL_LINK_MODE_Pause_BIT, phydev->supported);
-   __set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, phydev->supported);
-
if (phydev->c45_ids.devices_in_package & MDIO_DEVS_AN) {
val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_STAT1);
if (val < 0)
-- 
2.19.2

[PATCH] media: atmel: atmel-isc: reworked driver and formats

[Eugen.Hristev]

From: Eugen Hristev 

This change is a redesign in the formats and the way the ISC is
configured w.r.t. sensor format and the output format from the ISC.
I have changed the splitting between sensor output (which is also ISC input)
and ISC output.
The sensor format represents the way the sensor is configured, and what ISC
is receiving.
The format configuration represents the way ISC is interpreting the data and
formatting the output to the subsystem.
Now it's much easier to figure out what is the ISC configuration for input, and
what is the configuration for output.
The non-raw format can be obtained directly from sensor or it can be done
inside the ISC. The controller format list will include a configuration for
each format.
The old supported formats are still in place, if we want to dump the sensor
format directly to the output, the try format routine will detect and
configure the pipeline accordingly.
This also fixes the previous issues when the raw format was NULL which
resulted in many crashes for sensors which did not have the expected/tested
formats.

Signed-off-by: Eugen Hristev 
---
Hello Ken and possibly others using ISC driver,

I would appreciate if you could test this patch with your sensor,
because I do not wish to break anything in your setups.
Feedback is appreciated if any errors appear, so I can fix them.
I tested with ov5640, ov7670, ov7740(only in 4.19 because on latest it's broken
for me...)
Rebased this patch on top of mediatree.git/master
Thanks!

Eugen

 drivers/media/platform/atmel/atmel-isc.c | 882 ---
 1 file changed, 465 insertions(+), 417 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 5017896..7f0a6cc 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -89,35 +89,25 @@ struct isc_subdev_entity {
struct list_head list;
 };
 
-/* Indicate the format is generated by the sensor */
-#define FMT_FLAG_FROM_SENSOR   BIT(0)
-/* Indicate the format is produced by ISC itself */
-#define FMT_FLAG_FROM_CONTROLLER   BIT(1)
-/* Indicate a Raw Bayer format */
-#define FMT_FLAG_RAW_FORMATBIT(2)
-
-#define FMT_FLAG_RAW_FROM_SENSOR   (FMT_FLAG_FROM_SENSOR | \
-FMT_FLAG_RAW_FORMAT)
-
 /*
  * struct isc_format - ISC media bus format information
+   This structure represents the interface between the ISC
+   and the sensor. It's the input format received by
+   the ISC.
  * @fourcc:Fourcc code for this format
  * @mbus_code: V4L2 media bus format code.
- * flags:  Indicate format from sensor or converted by controller
- * @bpp:   Bits per pixel (when stored in memory)
- * (when transferred over a bus)
- * @sd_support:Subdev supports this format
- * @isc_support:   ISC can convert raw format to this format
+ * @cfa_baycfg:If this format is RAW BAYER, indicate the type 
of bayer.
+   this is either BGBG, RGRG, etc.
+ * @pfe_cfg0_bps:  Number of hardware data lines connected to the ISC
  */
 
 struct isc_format {
u32 fourcc;
u32 mbus_code;
-   u32 flags;
-   u8  bpp;
+   u32 cfa_baycfg;
 
boolsd_support;
-   boolisc_support;
+   u32 pfe_cfg0_bps;
 };
 
 /* Pipeline bitmap */
@@ -135,16 +125,31 @@ struct isc_format {
 
 #define GAM_ENABLES(GAM_RENABLE | GAM_GENABLE | GAM_BENABLE | GAM_ENABLE)
 
+/*
+ * struct fmt_config - ISC format configuration and internal pipeline
+   This structure represents the internal configuration
+   of the ISC.
+   It also holds the format that ISC will present to v4l2.
+ * @sd_format: Pointer to an isc_format struct that holds the sensor
+   configuration.
+ * @fourcc:Fourcc code for this format.
+ * @bpp:   Bytes per pixel in the current format.
+ * @rlp_cfg_mode:  Configuration of the RLP (rounding, limiting packaging)
+ * @dcfg_imode:Configuration of the input of the DMA module
+ * @dctrl_dview:   Configuration of the output of the DMA module
+ * @bits_pipeline: Configuration of the pipeline, which modules are enabled
+ */
 struct fmt_config {
-   u32 fourcc;
+   struct isc_format   *sd_format;
 
-   u32 pfe_cfg0_bps;
-   u32 cfa_baycfg;
-   u32 rlp_cfg_mode;
-   u32 dcfg_imode;
-   u32 dctrl_dview;
+   u32 fourcc;
+   u8  bpp;
 
-   u32 bits_pipeline;
+   u32 rlp_cfg_mode;
+   u32 dcfg_imode;
+   u32 dctrl_dview;
+
+   u32 bits_pipeline;
 };
 
 #de

RE: [PATCH 2/2] usb: dwc3: Add workaround for host mode VBUS glitch when boot

[Ran Wang]

Hi Felipe,

Sorry for the late response, I didn't receive your mail.

Felipe Balbi  wrotes:
>Hi,
>
>Ran Wang  writes:
>> +static void dwc3_power_off_all_roothub_ports(struct dwc3 *dwc)
>> +{
>> +int i, port_num;
>> +u32 reg, op_regs_base, offset;
>> +void __iomem*xhci_regs;
>> +
>> +/* xhci regs is not mapped yet, do it temperary here */
>> +if (dwc->xhci_resources[0].start) {
>> +xhci_regs = ioremap(dwc->xhci_resources[0].start,
>> +DWC3_XHCI_REGS_END);
>> +if (IS_ERR(xhci_regs)) {
>> +dev_err(dwc->dev, "Failed to ioremap xhci_regs\n");
>> +return;
>> +}
>> +
>> +op_regs_base = HC_LENGTH(readl(xhci_regs));
>> +reg = readl(xhci_regs + XHCI_HCSPARAMS1);
>> +port_num = HCS_MAX_PORTS(reg);
>> +
>> +for (i = 1; i <= port_num; i++) {
>> +offset = op_regs_base + XHCI_PORTSC_BASE + 0x10*(i-1);
>> +reg = readl(xhci_regs + offset);
>> +reg &= ~PORT_POWER;
>> +writel(reg, xhci_regs + offset);
>> +}
>> +
>> +iounmap(xhci_regs);
>
>why can't this be done during xhci_gen_setup()?

Actually I have done experiment like what you suggested (in xhci-plat.c), but 
the timing
seems too late--making VBUS waveform look like a square wave as below:

  Here DWC3 enable host mode, VBUS on
  |
+5V  /-\ 40ms  /---
0V  /   90ms   \__/
   |  |   
   |  Here do xhci reset, VBUS back to +5V again
   Here set all PORTSC[PP] to 0 in xhci_gen_setup()

So I am afraid the solution might have to be added in DWC3 core driver where 
just after host mode enabling code if want fix this :(

Regards,
Ran

Re: [PATCH v5 3/3] powerpc/32: Add KASAN support

[Christophe Leroy]

Le 14/02/2019 à 23:04, Daniel Axtens a écrit :

Hi Christophe,


--- a/arch/powerpc/include/asm/string.h
+++ b/arch/powerpc/include/asm/string.h
@@ -27,6 +27,20 @@ extern int memcmp(const void *,const void *,__kernel_size_t);
  extern void * memchr(const void *,int,__kernel_size_t);
  extern void * memcpy_flushcache(void *,const void *,__kernel_size_t);
  
+void *__memset(void *s, int c, __kernel_size_t count);

+void *__memcpy(void *to, const void *from, __kernel_size_t n);
+void *__memmove(void *to, const void *from, __kernel_size_t n);
+
+#if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__)
+/*
+ * For files that are not instrumented (e.g. mm/slub.c) we
+ * should use not instrumented version of mem* functions.
+ */
+#define memcpy(dst, src, len) __memcpy(dst, src, len)
+#define memmove(dst, src, len) __memmove(dst, src, len)
+#define memset(s, c, n) __memset(s, c, n)
+#endif
+


I'm finding that I miss tests like 'kasan test: kasan_memcmp
out-of-bounds in memcmp' because the uninstrumented asm version is used
instead of an instrumented C version. I ended up guarding the relevant
__HAVE_ARCH_x symbols behind a #ifndef CONFIG_KASAN and only exporting
the arch versions if we're not compiled with KASAN.

I find I need to guard and unexport strncpy, strncmp, memchr and
memcmp. Do you need to do this on 32bit as well, or are those tests
passing anyway for some reason?


Indeed, I didn't try the KASAN test module recently, because my configs 
don't have CONFIG_MODULE by default.


Trying to test it now, I am discovering that module loading oopses with 
latest version of my series, I need to figure out exactly why. Here 
below the oops by modprobing test_module (the one supposed to just say 
hello to the world).


What we see is an access to the RO kasan zero area.

The shadow mem is 0xf7c0..0xffc0
Linear kernel memory is shadowed by 0xf7c0-0xf8bf
0xf8c0-0xffc0 is shadowed read only by the kasan zero page.

Why is kasan trying to access that ? Isn't kasan supposed to not check 
stuff in vmalloc area ?


[  189.087499] BUG: Unable to handle kernel data access at 0xf8eb7818
[  189.093455] Faulting instruction address: 0xc001ab60
[  189.098383] Oops: Kernel access of bad area, sig: 11 [#1]
[  189.103732] BE PAGE_SIZE=16K PREEMPT CMPC885
[  189.111414] Modules linked in: test_module(+)
[  189.115817] CPU: 0 PID: 514 Comm: modprobe Not tainted 
5.0.0-rc5-s3k-dev-00645-g1dd3acf23952 #1016

[  189.124627] NIP:  c001ab60 LR: c0194fe8 CTR: 0003
[  189.129641] REGS: c5645b90 TRAP: 0300   Not tainted 
(5.0.0-rc5-s3k-dev-00645-g1dd3acf23952)

[  189.137924] MSR:  9032   CR: 44002884  XER: 
[  189.144571] DAR: f8eb7818 DSISR: 8a00
[  189.144571] GPR00: c0196620 c5645c40 c5aac000 f8eb7818  
0003 f8eb7817 c01950d0
[  189.144571] GPR08: c00c2720 c95bc010  c95bc1a0 c01965ec 
100d7b30 c0802b80 c5ae0308
[  189.144571] GPR16: c5990480 0124 000f c00bcf7c c5ae0324 
c95bc32c 06b8 0001
[  189.144571] GPR24: c95bc364 c95bc360 c95bc2c0 c95bc1a0 0002 
 0018 f8eb781b

[  189.182611] NIP [c001ab60] __memset+0xb4/0xc0
[  189.186922] LR [c0194fe8] kasan_unpoison_shadow+0x34/0x54
[  189.192136] Call Trace:
[  189.194682] [c5645c50] [c0196620] __asan_register_globals+0x34/0x74
[  189.200900] [c5645c70] [c00c27a4] do_init_module+0xbc/0x5a4
[  189.206392] [c5645ca0] [c00c0d08] load_module+0x2b5c/0x3194
[  189.211901] [c5645e70] [c00c14c8] sys_init_module+0x188/0x1bc
[  189.217572] [c5645f40] [c001311c] ret_from_syscall+0x0/0x38
[  189.223049] --- interrupt: c01 at 0xfda2b50
[  189.223049] LR = 0x10014b18
[  189.230175] Instruction dump:
[  189.233117] 4200fffc 70a50003 4d820020 7ca903a6 38c60003 9c860001 
4200fffc 4e800020
[  189.240859] 2c05 4d820020 7ca903a6 38c3 <9c860001> 4200fffc 
4e800020 7c032040

[  189.248809] ---[ end trace 45cbb1b3215e5959 ]---

Christophe



Regards,
Daniel



  #ifdef CONFIG_PPC64
  #define __HAVE_ARCH_MEMSET32
  #define __HAVE_ARCH_MEMSET64
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 879b36602748..fc4c42262694 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -16,8 +16,9 @@ CFLAGS_prom_init.o  += -fPIC
  CFLAGS_btext.o+= -fPIC
  endif
  
-CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)

-CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
+CFLAGS_early_32.o += -DDISABLE_BRANCH_PROFILING
+CFLAGS_cputable.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) 
-DDISABLE_BRANCH_PROFILING
+CFLAGS_prom_init.o += $(DISABLE_LATENT_ENTROPY_PLUGIN) 
-DDISABLE_BRANCH_PROFILING
  CFLAGS_btext.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
  CFLAGS_prom.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
  
@@ -31,6 +32,10 @@ CFLAGS_REMOVE_btext.o = $(CC_FLAGS_FTRACE)

  CFLAGS_REMOVE_prom.o = $(CC_FLAGS_FTRACE)
  endif
  
+KASAN_SANITIZE_early_32.o := n

+KASAN_SANITIZE_cputable.o := n
+KASAN_SANITIZE_prom_init.o := n
+
  obj-y := 

Re: [PATCH 08/11] lib: consolidate the GENERIC_BUG symbol

[Masahiro Yamada]

On Thu, Feb 14, 2019 at 2:40 AM Christoph Hellwig  wrote:
>
> And just let the architectures that want it select the symbol.
> Same for GENERIC_BUG_RELATIVE_POINTERS.
>
> Signed-off-by: Christoph Hellwig 


This slightly changes the behavior of GENERIC_BUG_RELATIVE_POINTERS
for arm64, riscv, x86.
Previously, GENERIC_BUG_RELATIVE_POINTERS was enabled only when BUG=y.


Having said that, this is not a big deal.
When CONFIG_GENERIC_BUG=n, CONFIG_GENERIC_BUG_RELATIVE_POINTERS
is actually don't care.



If you change this,
could you add some comments in commit description?


> ---

> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index c39dac831f08..913b2ca7ec22 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -85,6 +85,8 @@ config ARM64
> select FRAME_POINTER
> select GENERIC_ALLOCATOR
> select GENERIC_ARCH_TOPOLOGY
> +   select GENERIC_BUG if BUG
> +   select GENERIC_BUG_RELATIVE_POINTERS

Precisely,

  select GENERIC_BUG_RELATIVE_POINTERS if BUG




> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 732614eb3683..c410ed896567 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -19,6 +19,8 @@ config RISCV
> select ARCH_WANT_FRAME_POINTERS
> select CLONE_BACKWARDS
> select COMMON_CLK
> +   select GENERIC_BUG if BUG
> +   select GENERIC_BUG_RELATIVE_POINTERS if 64BIT

Precisely,

  select GENERIC_BUG_RELATIVE_POINTERS if 64BIT && BUG


> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 15ccdd04814e..2a5c12be633e 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -17,12 +17,6 @@ config ARCH_HAS_ILOG2_U64
>  config GENERIC_HWEIGHT
> def_bool y
>
> -config GENERIC_BUG
> -   def_bool y if BUG
> -
> -config GENERIC_BUG_RELATIVE_POINTERS
> -   def_bool y
> -


Hmm, s390 enables GENERIC_BUG_RELATIVE_POINTERS
irrespective of BUG...





> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 1bd4f19b6b28..f4cb31174e1b 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -91,6 +91,8 @@ config X86
> select DCACHE_WORD_ACCESS
> select EDAC_ATOMIC_SCRUB
> select EDAC_SUPPORT
> +   select GENERIC_BUG  if BUG
> +   select GENERIC_BUG_RELATIVE_POINTERSif X86_64

Precisely,

  select GENERIC_BUG_RELATIVE_POINTERSif X86_64 && BUG






--
Best Regards
Masahiro Yamada

Re: [RFC 2/2] soc: samsung: pmu: Add the PMU data of exynos4412 to support low-power state

[Anand Moon]

Hi Krzysztof,

On Fri, 15 Feb 2019 at 13:03, Krzysztof Kozlowski  wrote:
>
> On Thu, 14 Feb 2019 at 19:37, Anand Moon  wrote:
> >
> > Hi Krzysztof,
> >
> > Thanks for your review comments.
> >
> > On Thu, 14 Feb 2019 at 18:29, Krzysztof Kozlowski  wrote:
> > >
> > > On Wed, 13 Feb 2019 at 22:41, Anand Moon  wrote:
> > > >
> > > > This patch adds configration for PMU (Power Management Unit) state
> > > > tuning for exynos4412 SoC in order to enter low-power mode during
> > > > suspend power modes and help resume from suspend state.
> > >
> > > The U3 and Trats2 already enter STOP/S2R so please describe what
> > > exactly you change.
> > >
> > > > Fixes: bfce552d0b1 ("drivers: soc: Add support for Exynos PMU driver")
> > >
> > > How it fixes it? What was broken in that commit?
> >
> > * I was not aware on their is common framework for suspend and resume
> > other than setting this here.I only look in to some the other exynos
> > pmu architecture
> > and referring 3.10.x kernel to model my changes.*
>
> Suspend in general should be working already so adding this code just
> because is not a valid reason. Please specify what is not working
> first.
>

Please accept *my apology* for not studying the code changes required.
Sorry for wasting your precious time in review.

My only intention with this patch was to correctly initialize some PMU
parameters.
which might be wrong. so lets drop this.

> > >
> > > > Cc: Marek Szyprowski 
> > > > Cc: Krzysztof Kozlowski 
> > > > Cc: Chanwoo Choi 
> > > > Signed-off-by: Anand Moon 
> > > > ---
> > > >
> > > > Changes from previous patch.
> > > > New patch to this series to support suspend and resume state
> > > >
> > > > Changes have been tested on microSD card but fails to resume on cMMC.
> > > > It need to be investigated and more debuging
> > > > ---
> > > >  drivers/soc/samsung/exynos4-pmu.c   | 83 +
> > > >  include/linux/soc/samsung/exynos-regs-pmu.h | 21 ++
> > > >  2 files changed, 104 insertions(+)
> > > >
> > > > diff --git a/drivers/soc/samsung/exynos4-pmu.c 
> > > > b/drivers/soc/samsung/exynos4-pmu.c
> > > > index a7cdbf1aac0c..d261a0d2371e 100644
> > > > --- a/drivers/soc/samsung/exynos4-pmu.c
> > > > +++ b/drivers/soc/samsung/exynos4-pmu.c
> > > > @@ -200,10 +200,93 @@ static const struct exynos_pmu_conf 
> > > > exynos4412_pmu_config[] = {
> > > > { PMU_TABLE_END,},
> > > >  };
> > > >
> > > > +static unsigned int const exynos4412_list_feed[] = {
> > > > +   EXYNOS4_ARM_CORE0_OPTION,
> > > > +   EXYNOS4_ARM_CORE1_OPTION,
> > > > +   EXYNOS4_ARM_CORE2_OPTION,
> > > > +   EXYNOS4_ARM_CORE3_OPTION,
> > > > +   EXYNOS4_ARM_COMMON_OPTION,
> > > > +   EXYNOS4_CAM_OPTION,
> > > > +   EXYNOS4_TV_OPTION,
> > > > +   EXYNOS4_MFC_OPTION,
> > > > +   EXYNOS4_G3D_OPTION,
> > > > +   EXYNOS4_LCD0_OPTION,
> > > > +   EXYNOS4_ISP_OPTION,
> > > > +   EXYNOS4_MAUDIO_OPTION,
> > > > +   EXYNOS4_GPS_OPTION,
> > > > +   EXYNOS4_GPS_ALIVE_OPTION,
> > > > +};
> > > > +
> > > > +static void exynos4412_pmu_central_seq(bool enable)
> > >
> > > You name the argument as "enable"  but during initialization and
> > > system running you pass here false. It confuses me. What do you enable
> > > here?
> > >
> >
> > Yep your are correct need to drop this function as already done in
> > common frame work.
> >
> > > > +{
> > > > +   unsigned int value;
> > > > +
> > > > +   value = pmu_raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
> > > > +   if (enable)
> > > > +   value &= ~S5P_CENTRAL_LOWPWR_CFG;
> > > > +   else
> > > > +   value |= S5P_CENTRAL_LOWPWR_CFG;
> > > > +   pmu_raw_writel(value, S5P_CENTRAL_SEQ_CONFIGURATION);
> > >
> > > You duplicate exynos_pm_central_suspend() without removing the original 
> > > code.
> > >
> > > > +
> > > > +   value = pmu_raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION_COREBLK);
> > > > +   if (enable)
> > > > +   value &= ~S5P_CENTRAL_LOWPWR_CFG;
> > > > +   else
> > > > +   value |= S5P_CENTRAL_LOWPWR_CFG;
> > >
> > > As manual says - set this register only if you disable C2C. Our entire
> > > low power configuration for STOP mode is for C2C enabled case so you
> > > add inconsistent configuration.
> >
> > Ok Sorry I overlook this code change.
> >
> > Enable system power down. Set only CENTRAL_SEQ_CONFIGURATION register
> > if you disable C2C.
> > Set both CENTRAL_SEQ_CONFIGURATION and
> > CENTRAL_SEQ_CONFIGURATION_COREBLK registers if you enable C2C.
> >
> > > > +   pmu_raw_writel(value, S5P_CENTRAL_SEQ_CONFIGURATION_COREBLK);
> > > > +}
> > > > +
> > > > +static void exynos4412_pmu_init(void)
> > > > +{
> > > > +   unsigned int value;
> > > > +   int i;
> > > > +
> > > > +   /* Enable USE_STANDBY_WFI for all CORE */
> > > > +   pmu_raw_writel(S5P_USE_STANDBY_WFI_ALL, S5P_CENTRAL_SEQ_OPTION);
> > >
> > > This does not look related to improving suspend... it looks unrelate

Re: [RFC 1/2] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3

[Anand Moon]

Hi Krzysztof,

On Fri, 15 Feb 2019 at 13:01, Krzysztof Kozlowski  wrote:
>
> On Thu, 14 Feb 2019 at 19:35, Anand Moon  wrote:
> >
> > hi Krzysztof,
> >
> > Thanks fro your review comments.
> >
> > On Thu, 14 Feb 2019 at 18:11, Krzysztof Kozlowski  wrote:
> > >
> > > Hi Anand,
> > >
> > > Thanks for the patch. See comments below.
> > >
> > > On Wed, 13 Feb 2019 at 22:41, Anand Moon  wrote:
> > > >
> > > > Add suspend-to-mem node to regulator core to be enabled or disabled
> > > > during system suspend and also support changing the regulator operating
> > > > mode during runtime and when the system enter sleep mode.
> > > >
> > > > Cc: Marek Szyprowski 
> > > > Cc: Krzysztof Kozlowski 
> > > > Cc: Chanwoo Choi 
> > > > Signed-off-by: Anand Moon 
> > > > ---
> > > >
> > > > Changes from previos patch
> > > > [0] https://patchwork.kernel.org/patch/10712549/
> > > >
> > > > Set all the WAKEUP source regulator in suspend-on state.
> > > > LD04, LD012, LD015, LD020, LD022
> > > > Set all the non used regulator in suspend-odd state
> > > > LD02, LD03, LD05, LD06, LD07, LD011, LD013, LDO14, LD016
> > > >
> > > > BUCK5, BUCK6, BUCK7 and not confirable as per driver max77686-regulator
> > > >
> > > > Tested on microSD card and it resumes correcly after suspend.
> > > > eMMC is not able to resume after entering into suspend state,
> > > > which need to be investigated and how to debug more.
> > > > ---
> > > >  .../boot/dts/exynos4412-odroid-common.dtsi| 63 +++
> > > >  arch/arm/boot/dts/exynos4412-odroidu3.dts |  3 +
> > > >  2 files changed, 66 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
> > > > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > index 08d3a0a7b4eb..e984461c37d9 100644
> > > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > @@ -288,6 +288,9 @@
> > > > regulator-min-microvolt = <180>;
> > > > regulator-max-microvolt = <180>;
> > > > regulator-always-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-off-in-suspend;
> > > > +   };
> > >
> > > I see my comment from previous patch was not addressed.
> >
> > I left this unchanged since this regulator is not active linked and used.
> > Ok I will change this to regulator-on-in-suspend,
>
> Why?
>
> Previous patch was setting this to "on". I said that this is noop and
> if you want to add it, I need explanation why this regulator has to
> stay on during suspend.
>
> So you changed to "off"... which is still noop... and you did not
> provide explanation. Now you replied that you will change to "on"...
> so this will be circle. Still without explanation.
>

I will re check with my previous patch and the driver code which
support suspend state.
Ok check the regulator driver max77686-regulator and enable the logs their.

> >
> > From documentation device tree binding regulator.txt
> > "- regulator-always-on: boolean, regulator should never be disabled"
> >
> > But some regulator switches to a low power mode under light current loads
> > and the device automatically switches back to a fast response mode as the
> > output load increases.
> >
> > >
> > > > };
> > > >
> > > > ldo3_reg: LDO3 {
> > > > @@ -295,6 +298,9 @@
> > > > regulator-min-microvolt = <180>;
> > > > regulator-max-microvolt = <180>;
> > > > regulator-always-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-off-in-suspend;
> > > > +   };
> > >
> > > The same...
> >
> > Ok I will change this to regulator-on-in-suspend,
>
> The same - why changing this to on or off? I need explanation why this
> should be in first place.

I will check in the driver code.

>
> > >
> > > > };
> > > >
> > > > ldo4_reg: LDO4 {
> > > > @@ -302,6 +308,9 @@
> > > > regulator-min-microvolt = <280>;
> > > > regulator-max-microvolt = <280>;
> > > > regulator-boot-on;
> > > > +   regulator-state-mem {
> > > > +   regulator-on-in-suspend;
> > > > +   };
> > > > };
> > > >
> > > > ldo5_reg: LDO5 {
> > > > @@ -310,6 +319,9 @@
> > > > regulator-max-microvolt = <180>;
> > > > regulator-always-on;
> > > > regulator-boot-on;
> > > > +   

Re: [PATCH v3 0/9] [RFC] vfio: ap: ioctl definitions for AP Queue Interrupt Control

[Pierre Morel]

On 14/02/2019 21:33, Tony Krowiak wrote:

On 2/14/19 8:51 AM, Pierre Morel wrote:

The subject leads one to believe this patch series introduces
ioctl definitions for AQIC, but there is not a single ioctl
definition in the series. Something like this might be more
appropriate:


This is right Tony, no ioctl here.
I kept the original subject and increment the version number to let 
people know that this is a new version of the implementation of 
PQAP/AQIC interception for which we already had 2 iterations.


May be you are right and I should have change the subject.

Thanks for making this clear.

Regards,
Pierre

--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany

Re: [PATCH] powerpc/ptrace: Add prototype for function pt_regs_check

[Mathieu Malaterre]

On Fri, Feb 15, 2019 at 9:21 AM Christophe Leroy
 wrote:
>
>
>
> Le 15/02/2019 à 09:11, Mathieu Malaterre a écrit :
> > On Sat, Dec 8, 2018 at 4:46 PM Mathieu Malaterre  wrote:
> >>
> >> `pt_regs_check` is a dummy function, its purpose is to break the build
> >> if struct pt_regs and struct user_pt_regs don't match.
> >>
> >> This function has no functionnal purpose, and will get eliminated at
> >> link time or after init depending on CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
> >>
> >> This commit adds a prototype to fix warning at W=1:
> >>
> >>arch/powerpc/kernel/ptrace.c:3339:13: error: no previous prototype for 
> >> ‘pt_regs_check’ [-Werror=missing-prototypes]
> >>
> >> Suggested-by: Christophe Leroy 
> >> Signed-off-by: Mathieu Malaterre 
> >> ---
> >>   arch/powerpc/kernel/ptrace.c | 4 
> >>   1 file changed, 4 insertions(+)
> >>
> >> diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> >> index a398999d0770..341c0060b4c8 100644
> >> --- a/arch/powerpc/kernel/ptrace.c
> >> +++ b/arch/powerpc/kernel/ptrace.c
> >> @@ -3338,6 +3338,10 @@ void do_syscall_trace_leave(struct pt_regs *regs)
> >>  user_enter();
> >>   }
> >>
> >> +void __init pt_regs_check(void);
> >> +/* dummy function, its purpose is to break the build if struct pt_regs and
> >> + * struct user_pt_regs don't match.
> >> + */
> >
> > Another trick which seems to work with GCC is:
> >
> > -void __init pt_regs_check(void)
> > +static inline void __init pt_regs_check(void)
>
> Does this really work ? Did you test to ensure that the BUILD_BUG_ON
> still detect mismatch between struct pt_regs and struct user_pt_regs ?
>

My bad, I was unaware of GCC behavior for static inline in this case.
Sorry for the noise.
Original ugly patch does work though.
>
> >
> >>   void __init pt_regs_check(void)
> >>   {
> >>  BUILD_BUG_ON(offsetof(struct pt_regs, gpr) !=
> >> --
> >> 2.19.2
> >>

Re: [PATCH] arm64: dts: ti: k3-am65: Add MSMC RAM node

[Tero Kristo]

On 05/02/2019 14:25, Roger Quadros wrote:

Tero,

On 11/01/19 11:44, Roger Quadros wrote:

The AM65 SoC has 2MB MSMC RAM. Add this as a mmio-sram
node so drivers can use it via genpool API.

Following areas are marked reserved:
- Lower 128KB for ATF
- 64KB@0xf for SYSFW
- Upper 1MB for cache

The reserved locations are subject to change at runtime by
the bootloader.

Cc: Nishanth Menon 
Cc: Lokesh Vutla 
Cc: Andrew F. Davis 
Signed-off-by: Roger Quadros 


Is this patch good to pick for -next?


Queued for 5.1, thanks.

-Tero



cheers,
-roger


---
  arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 20 
  1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 272cf8f..5a18150 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -6,6 +6,26 @@
   */
  
  &cbass_main {

+   msmc_ram: sram@7000 {
+   compatible = "mmio-sram";
+   reg = <0x0 0x7000 0x0 0x20>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x7000 0x20>;
+
+   atf-sram@0 {
+   reg = <0x0 0x2>;
+   };
+
+   sysfw-sram@f {
+   reg = <0xf 0x1>;
+   };
+
+   l3cache-sram@10 {
+   reg = <0x10 0x10>;
+   };
+   };
+
gic500: interrupt-controller@180 {
compatible = "arm,gic-v3";
#address-cells = <2>;





--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v2] i2c: bcm2835: Clear current buffer pointers and counts after a transfer

[Wolfram Sang]

On Thu, Dec 27, 2018 at 04:42:25PM +0100, Paul Kocialkowski wrote:
> The driver's interrupt handler checks whether a message is currently
> being handled with the curr_msg pointer. When it is NULL, the interrupt
> is considered to be unexpected. Similarly, the i2c_start_transfer
> routine checks for the remaining number of messages to handle in
> num_msgs.
> 
> However, these values are never cleared and always keep the message and
> number relevant to the latest transfer (which might be done already and
> the underlying message memory might have been freed).
> 
> When an unexpected interrupt hits with the DONE bit set, the isr will
> then try to access the flags field of the curr_msg structure, leading
> to a fatal page fault.
> 
> The msg_buf and msg_buf_remaining fields are also never cleared at the
> end of the transfer, which can lead to similar pitfalls.
> 
> Fix these issues by introducing a cleanup function and always calling
> it after a transfer is finished.
> 
> Fixes: e2474541032d ("i2c: bcm2835: Fix hang for writing messages larger than 
> 16 bytes")
> Signed-off-by: Paul Kocialkowski 

Applied to for-current, thanks!



signature.asc
Description: PGP signature

Re: [PATCH] arm64: dts: ti: k3-am65-mcu: Add ADC nodes

[Tero Kristo]

On 12/02/2019 14:22, Vignesh R wrote:

TI AM654 SoC has two ADC instances in the MCU domain. Add DT nodes for
the same.

Signed-off-by: Vignesh R 
---
Tero,

Could you also pick up DT bindings here: 
https://patchwork.kernel.org/patch/10751429/
All the Acks are in place.


Queued for 5.1, including the dt-binding.

Thanks, Tero



  arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi   | 30 +++
  .../arm64/boot/dts/ti/k3-am654-base-board.dts | 12 
  2 files changed, 42 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index 593f718e8fb5..6f7d2b316ded 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -57,4 +57,34 @@
#address-cells = <1>;
#size-cells = <0>;
};
+
+   tscadc0: tscadc@4020 {
+   compatible = "ti,am654-tscadc", "ti,am3359-tscadc";
+   reg = <0x0 0x4020 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&k3_clks 0 2>;
+   assigned-clocks = <&k3_clks 0 2>;
+   assigned-clock-rates = <6000>;
+   clock-names = "adc_tsc_fck";
+
+   adc {
+   #io-channel-cells = <1>;
+   compatible = "ti,am654-adc", "ti,am3359-adc";
+   };
+   };
+
+   tscadc1: tscadc@4021 {
+   compatible = "ti,am654-tscadc", "ti,am3359-tscadc";
+   reg = <0x0 0x4021 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&k3_clks 1 2>;
+   assigned-clocks = <&k3_clks 1 2>;
+   assigned-clock-rates = <6000>;
+   clock-names = "adc_tsc_fck";
+
+   adc {
+   #io-channel-cells = <1>;
+   compatible = "ti,am654-adc", "ti,am3359-adc";
+   };
+   };
  };
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts 
b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index e41fc3a5987b..fb6df5c8f85b 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -163,3 +163,15 @@
#size-cells= <1>;
};
  };
+
+&tscadc0 {
+   adc {
+   ti,adc-channels = <0 1 2 3 4 5 6 7>;
+   };
+};
+
+&tscadc1 {
+   adc {
+   ti,adc-channels = <0 1 2 3 4 5 6 7>;
+   };
+};



--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v2 0/3] arm64: ti: k3-am654: USB support

[Tero Kristo]

On 05/02/2019 14:45, Roger Quadros wrote:

Hi,

The AM654 SoC supports 2 DWC3 USB controller instances. The
AM654 base board supports the 2nd (USB1) instance in high-speed.

This series enables support for USB1 instance on the AM654-base-board.

The series depends on [1] and [2]. Both are in the -next branch of their
respective maintainer trees.

To test you can apply on top of linux-next. As usb/next was just pushed
today, it might have not reached linux-next yet. If so please pull that from 
[3].

If using arm64 defconfig, you need to enable
CONFIG_USB_DWC3_KEYSTONE=y
CONFIG_OMAP_USB2=y
and the necessary USB drivers that you want to test. e.g. USB network adapter.

[1] AM654 USB2 PHY support https://lkml.org/lkml/2018/12/5/908
[2] AM654 DWC3 support 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1896101.html
[3] usb-next 
https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git/log/?h=next

Changelog:
v2
- usb & phy nodes are not kept disabled in k3-am65-main.dtsi.
   Unused ones are disabled in board dts instead.


Series queued for 5.1, thanks.

-Tero



cheers,
-roger


Jyri Sarha (1):
   arm64: dts: ti: am654: Add Main System Control Module node

Roger Quadros (2):
   arm64: dts: ti: k3-am6: add USB support
   arm64: dts: ti: k3-am654-base-board: enable USB1

  arch/arm64/boot/dts/ti/k3-am65-main.dtsi   | 84 ++
  arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 28 +
  2 files changed, 112 insertions(+)



--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v1 1/1] gpio: add driver for Mellanox BlueField GPIO controller

[Bartosz Golaszewski]

czw., 14 lut 2019 o 22:30 Shravan Kumar Ramani 
napisał(a):
>
> This patch adds support for the GPIO controller used by Mellanox
> BlueField SOCs.
>
> Reviewed-by: David Woods 
> Signed-off-by: Shravan Kumar Ramani 
> ---
>  drivers/gpio/Kconfig  |   7 ++
>  drivers/gpio/Makefile |   1 +
>  drivers/gpio/gpio-mlxbf.c | 287 
> ++
>  3 files changed, 295 insertions(+)
>  create mode 100644 drivers/gpio/gpio-mlxbf.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index b5a2845..2bebe92 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -1292,6 +1292,13 @@ config GPIO_MERRIFIELD
> help
>   Say Y here to support Intel Merrifield GPIO.
>
> +config GPIO_MLXBF
> +   tristate "Mellanox BlueField SoC GPIO"
> +   depends on (MELLANOX_PLATFORM && ARM64 && ACPI) || COMPILE_TEST
> +   select GPIO_GENERIC

You're not really depending on it.

> +   help
> + Say Y here if you want GPIO support on Mellanox BlueField SoC.
> +
>  config GPIO_ML_IOH
> tristate "OKI SEMICONDUCTOR ML7213 IOH GPIO support"
> depends on X86 || COMPILE_TEST
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 37628f8..8d54279 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -83,6 +83,7 @@ obj-$(CONFIG_GPIO_MENZ127)+= gpio-menz127.o
>  obj-$(CONFIG_GPIO_MERRIFIELD)  += gpio-merrifield.o
>  obj-$(CONFIG_GPIO_MC33880) += gpio-mc33880.o
>  obj-$(CONFIG_GPIO_MC9S08DZ60)  += gpio-mc9s08dz60.o
> +obj-$(CONFIG_GPIO_MLXBF)   += gpio-mlxbf.o
>  obj-$(CONFIG_GPIO_ML_IOH)  += gpio-ml-ioh.o
>  obj-$(CONFIG_GPIO_MM_LANTIQ)   += gpio-mm-lantiq.o
>  obj-$(CONFIG_GPIO_MOCKUP)  += gpio-mockup.o
> diff --git a/drivers/gpio/gpio-mlxbf.c b/drivers/gpio/gpio-mlxbf.c
> new file mode 100644
> index 000..e5c50db
> --- /dev/null
> +++ b/drivers/gpio/gpio-mlxbf.c
> @@ -0,0 +1,287 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Number of pins on BlueField */
> +#define MLXBF_GPIO_NR 54
> +
> +/* Pad Electrical Controls. */
> +#define GPIO_PAD_CONTROL__FIRST_WORD 0x0700
> +#define GPIO_PAD_CONTROL_1__FIRST_WORD 0x0708
> +#define GPIO_PAD_CONTROL_2__FIRST_WORD 0x0710
> +#define GPIO_PAD_CONTROL_3__FIRST_WORD 0x0718
> +
> +#define GPIO_PIN_DIR_I 0x1040
> +#define GPIO_PIN_DIR_O 0x1048
> +#define GPIO_PIN_STATE 0x1000
> +#define GPIO_SCRATCHPAD 0x20
> +
> +#ifdef CONFIG_PM
> +struct bluefield_context_save_regs {
> +   u64 gpio_scratchpad;
> +   u64 gpio_pad_control[MLXBF_GPIO_NR];
> +   u64 gpio_pin_dir_i;
> +   u64 gpio_pin_dir_o;
> +};
> +#endif
> +
> +/* Device state structure. */
> +struct gpio_state {
> +   struct list_head node;

Why do you need that? You're not using it anywhere AFAICT.

> +   struct platform_device *pdev;

You're not using this either.

> +
> +   struct gpio_chip gc;
> +
> +   /* Must hold this lock to modify shared data. */
> +   spinlock_t lock;
> +
> +   /* Memory Address */
> +   void __iomem *dc_base;
> +
> +#ifdef CONFIG_PM
> +   struct bluefield_context_save_regs csave_regs;
> +#endif
> +};
> +
> +/* GPIO driver set input pins */
> +static int gpio_bf_set_input(struct gpio_chip *chip, unsigned int offset)
> +{
> +   struct gpio_state *gs = gpiochip_get_data(chip);
> +   u64 in;
> +   u64 out;
> +
> +   if (offset > MLXBF_GPIO_NR - 1) {
> +   dev_err(chip->parent, "gpio input pins: Invalid offset %d\n",
> +   offset);
> +   return -EINVAL;
> +   }

You don't need that, the subsystem makes sure this doesn't happen.
Same elsewhere.

> +
> +   out = readq(gs->dc_base + GPIO_PIN_DIR_O);
> +   in = readq(gs->dc_base + GPIO_PIN_DIR_I);
> +
> +   writeq(out & ~BIT(offset), gs->dc_base + GPIO_PIN_DIR_O);
> +   writeq(in | BIT(offset), gs->dc_base + GPIO_PIN_DIR_I);
> +

If you used the mmio regmap in this driver you could avoid both the
locking (regmap uses a spinlock if fast_io is set to true) and manual
bit updating here. You would do something like:
regmap_update_bits(map, gs->dc_base + GPIO_PIN_DIR_O, out &
BIT(offset), ~BIT(offset)).

> +   return 0;
> +}
> +
> +/* GPIO driver set output pins */
> +static int gpio_bf_set_output(struct gpio_chip *chip, unsigned int offset)
> +{
> +   struct gpio_state *gs = gpiochip_get_data(chip);
> +   u64 in;
> +   u64 out;
> +
> +   if (offset > MLXBF_GPIO_NR - 1) {
> +   dev_err(chip->parent, "gpio output pins: Invalid offset %d\n",
> +   offset);
> +   return -EINVAL;
> +   }
> +
> +   out = readq(gs->dc_base + GPIO_PIN_DIR_O);
> +   in = readq(gs->dc_base + GPIO_PIN_DIR_I);
> +
> +   writeq(out | 

RE: [PATCH v5 07/12] perf/x86: no counter allocation support

[Wang, Wei W]

On Friday, February 15, 2019 12:26 AM, Andi Kleen wrote:
> > diff --git a/include/uapi/linux/perf_event.h
> > b/include/uapi/linux/perf_event.h index 9de8780..ec97a70 100644
> > --- a/include/uapi/linux/perf_event.h
> > +++ b/include/uapi/linux/perf_event.h
> > @@ -372,7 +372,8 @@ struct perf_event_attr {
> > context_switch :  1, /* context switch data */
> > write_backward :  1, /* Write ring buffer from
> end to beginning */
> > namespaces :  1, /* include namespaces
> data */
> > -   __reserved_1   : 35;
> > +   no_counter :  1, /* no counter allocation */
> 
> Not sure we really want to expose this in the user ABI. Perhaps make it a
> feature of the in kernel API only?

OK. I plan to move it to the perf_event struct.

Best,
Wei

Re: [PATCH v2] i2c: aspeed: Add multi-master use case support

[Wolfram Sang]

On Mon, Feb 11, 2019 at 10:54:44AM -0800, Jae Hyun Yoo wrote:
> In multi-master environment, this driver's master cannot know
> exactly when a peer master sends data to this driver's slave so
> cases can be happened that this master tries sending data through
> the master_xfer function but slave data from a peer master is still
> being processed or slave xfer is started by a peer immediately
> after it queues a master command. To support multi-master use cases
> properly, this H/W provides arbitration in physical level and it
> provides priority based command handling too to avoid conflicts in
> multi-master environment, means that if a master and a slave events
> happen at the same time, H/W will handle a higher priority event
> first and a pending event will be handled when bus comes back to
> the idle state.
> 
> To support this H/W feature properly, this patch adds the 'pending'
> state of master and its handling code so that the pending master
> xfer can be continued after slave operation properly.
> 
> Signed-off-by: Jae Hyun Yoo 
> Reviewed-by: Brendan Higgins 

Applied to for-next, thanks!



signature.asc
Description: PGP signature

RE: [PATCH v5 12/12] KVM/VMX/vPMU: support to report GLOBAL_STATUS_LBRS_FROZEN

[Wang, Wei W]

On Friday, February 15, 2019 12:32 AM, Andi Kleen wrote:
> 
> > +static void intel_pmu_get_global_status(struct kvm_pmu *pmu,
> > +   struct msr_data *msr_info)
> > +{
> > +   u64 guest_debugctl, freeze_lbr_bits =
> DEBUGCTLMSR_FREEZE_LBRS_ON_PMI |
> > + DEBUGCTLMSR_LBR;
> > +
> > +   if (!pmu->global_status) {
> > +   msr_info->data = 0;
> > +   return;
> > +   }
> > +
> > +   msr_info->data = pmu->global_status;
> > +   if (pmu->version >= 4) {
> > +   guest_debugctl = vmcs_read64(GUEST_IA32_DEBUGCTL);
> > +   if ((guest_debugctl & freeze_lbr_bits) == freeze_lbr_bits)
> 
> It should only check for the freeze bit, the freeze bit can be set even when
> LBRs are disabled.
> 
> Also you seem to set the bit unconditionally?
> That doesn't seem right. It should only be set after an overflow.
> 
> So the PMI injection needs to set it.

OK. The freeze bits need to be cleared by IA32_PERF_GLOBAL_STATUS_RESET, which 
seems not supported by the perf code yet (thus guest won't clear them). Would 
handle_irq_v4 also need to be changed to support that?

Best,
Wei

Re: [RFC 5/5] arm64: dts: imx8mq: Add the opp table and the cpu-supply nodes

[Abel Vesa]

On 19-02-14 16:55:22, Angus Ainslie wrote:
> On 2019-02-13 11:05, Abel Vesa wrote:
> > Add the opp table containing only non over drive opps.
> > Also add the cpu-supply nodes for the A53 cores in the EVK board.
> > 
> > Signed-off-by: Abel Vesa 
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 17 +
> >  arch/arm64/boot/dts/freescale/imx8mq.dtsi| 23
> > +++
> >  2 files changed, 40 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> > b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> > index 54737bf..114359e 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> > @@ -31,6 +31,23 @@
> > gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
> > enable-active-high;
> > };
> > +
> > +};
> > +
> > +&A53_0 {
> > +   cpu-supply = <&sw1a_reg>;
> > +};
> > +
> > +&A53_1 {
> > +   cpu-supply = <&sw1a_reg>;
> > +};
> > +
> > +&A53_2 {
> > +   cpu-supply = <&sw1a_reg>;
> > +};
> > +
> > +&A53_3 {
> > +   cpu-supply = <&sw1a_reg>;
> >  };
> > 
> >  &fec1 {
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > index 1a89062..89b2d5f 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > @@ -91,6 +91,7 @@
> > clocks = <&clk IMX8MQ_CLK_ARM>;
> > enable-method = "psci";
> > next-level-cache = <&A53_L2>;
> > +   operating-points-v2 = <&a53_0_opp_table>;
> > };
> > 
> > A53_1: cpu@1 {
> > @@ -101,6 +102,7 @@
> > clocks = <&clk IMX8MQ_CLK_ARM>;
> > enable-method = "psci";
> > next-level-cache = <&A53_L2>;
> > +   operating-points-v2 = <&a53_0_opp_table>;
> > };
> > 
> > A53_2: cpu@2 {
> > @@ -111,6 +113,7 @@
> > clocks = <&clk IMX8MQ_CLK_ARM>;
> > enable-method = "psci";
> > next-level-cache = <&A53_L2>;
> > +   operating-points-v2 = <&a53_0_opp_table>;
> > };
> > 
> > A53_3: cpu@3 {
> > @@ -121,6 +124,7 @@
> > clocks = <&clk IMX8MQ_CLK_ARM>;
> > enable-method = "psci";
> > next-level-cache = <&A53_L2>;
> > +   operating-points-v2 = <&a53_0_opp_table>;
> > };
> > 
> > A53_L2: l2-cache0 {
> > @@ -666,6 +670,25 @@
> > status = "disabled";
> > };
> > 
> > +
> > +   a53_0_opp_table: opp-table {
> > +   compatible = "operating-points-v2";
> > +   opp-shared;
> > +
> > +   opp-8 {
> > +   opp-hz = /bits/ 64 <8>;
> > +   opp-microvolt = <90>;
> > +   clock-latency-ns = <15>;
> > +   };
> > +
> > +   opp-10 {
> > +   opp-hz = /bits/ 64 <10>;
> > +   opp-microvolt = <90>;
> 
> Shouldn't this be
> 
> opp-microvolt = <100>;
> 

Hmm, I looked into some older datasheet which said the maximum non
overdrive is 1GHz.

But the latest one I could find:

https://www.nxp.com/docs/en/data-sheet/IMX8MDQLQIEC.pdf

says it's 0.8GHz. 

So I'll fix it in the next version.

Thanks.

> > +   clock-latency-ns = <15>;
> > +   opp-suspend;
> > +   };
> > +   };
> > +
> > gic: interrupt-controller@3880 {
> > compatible = "arm,gic-v3";
> > reg = <0x3880 0x1>, /* GIC Dist */
> 

Re: [PATCH v2] staging: erofs: keep corrupted fs from crashing kernel in erofs_namei()

[Gao Xiang]

Hi Chao,

On 2019/2/15 15:02, Chao Yu wrote:
> On 2019/2/1 20:16, Gao Xiang wrote:
>> As Al pointed out, "
>> ... and while we are at it, what happens to
>>  unsigned int nameoff = le16_to_cpu(de[mid].nameoff);
>>  unsigned int matched = min(startprfx, endprfx);
>>
>>  struct qstr dname = QSTR_INIT(data + nameoff,
>>  unlikely(mid >= ndirents - 1) ?
>>  maxsize - nameoff :
>>  le16_to_cpu(de[mid + 1].nameoff) - nameoff);
>>
>>  /* string comparison without already matched prefix */
>>  int ret = dirnamecmp(name, &dname, &matched);
>> if le16_to_cpu(de[...].nameoff) is not monotonically increasing?  I.e.
>> what's to prevent e.g. (unsigned)-1 ending up in dname.len?
>>
>> Corrupted fs image shouldn't oops the kernel.. "
>>
>> Revisit the related lookup flow to address the issue.
>>
>> Fixes: d72d1ce60174 ("staging: erofs: add namei functions")
>> Cc:  # 4.19+
>> Suggested-by: Al Viro 
>> Signed-off-by: Gao Xiang 
>> ---
>> [ It should be better get reviewed first and for linux-next... ]
>>
>> change log v2:
>>  - fix the missing "kunmap_atomic" pointed out by Dan;
>>  - minor cleanup;
>>
>>  drivers/staging/erofs/namei.c | 187 
>> ++
>>  1 file changed, 99 insertions(+), 88 deletions(-)
>>
>> diff --git a/drivers/staging/erofs/namei.c b/drivers/staging/erofs/namei.c
>> index 5596c52e246d..321c881d720f 100644
>> --- a/drivers/staging/erofs/namei.c
>> +++ b/drivers/staging/erofs/namei.c
>> @@ -15,74 +15,77 @@
>>  
>>  #include 
>>  
>> -/* based on the value of qn->len is accurate */
>> -static inline int dirnamecmp(struct qstr *qn,
>> -struct qstr *qd, unsigned int *matched)
>> +struct erofs_qstr {
>> +const unsigned char *name;
>> +const unsigned char *end;
>> +};
>> +
>> +/* based on the end of qn is accurate and it must have the trailing '\0' */
>> +static inline int dirnamecmp(const struct erofs_qstr *qn,
>> + const struct erofs_qstr *qd,
>> + unsigned int *matched)
>>  {
>> -unsigned int i = *matched, len = min(qn->len, qd->len);
>> -loop:
>> -if (unlikely(i >= len)) {
>> -*matched = i;
>> -if (qn->len < qd->len) {
>> -/*
>> - * actually (qn->len == qd->len)
>> - * when qd->name[i] == '\0'
>> - */
>> -return qd->name[i] == '\0' ? 0 : -1;
>> +unsigned int i = *matched;
>> +
>> +/*
>> + * on-disk error, let's only BUG_ON in the debugging mode.
>> + * otherwise, it will return 1 to just skip the invalid name
>> + * and go on (in consideration of the lookup performance).
>> + */
>> +DBG_BUGON(qd->name > qd->end);
> 
> qd->name == qd->end is not allowed as well?

Make sense, it is only used for debugging mode, let me send another patch 
later...

> 
> So will it be better to return directly here?
> 
>   if (unlikely(qd->name >= qd->end)) {
>   DBG_BUGON(1);
>   return 1;
>   }

Corrupted image is rare happened in normal systems, I tend to only use
DBG_BUGON here, and  qn->name[i] is of course not '\0', so it will return 1;

> 
>> +
>> +/* qd could not have trailing '\0' */
>> +/* However it is absolutely safe if < qd->end */
>> +while (qd->name + i < qd->end && qd->name[i] != '\0') {
>> +if (qn->name[i] != qd->name[i]) {
>> +*matched = i;
>> +return qn->name[i] > qd->name[i] ? 1 : -1;
>>  }
>> -return (qn->len > qd->len);
>> +++i;
>>  }
>> -
>> -if (qn->name[i] != qd->name[i]) {
>> -*matched = i;
>> -return qn->name[i] > qd->name[i] ? 1 : -1;
>> -}
>> -
>> -++i;
>> -goto loop;
>> +*matched = i;
>> +/* See comments in __d_alloc on the terminating NUL character */
>> +return qn->name[i] == '\0' ? 0 : 1;
>>  }
>>  
>> -static struct erofs_dirent *find_target_dirent(
>> -struct qstr *name,
>> -u8 *data, int maxsize)
>> +#define nameoff_from_disk(off, sz)  (le16_to_cpu(off) & ((sz) - 1))
>> +
>> +static struct erofs_dirent *find_target_dirent(struct erofs_qstr *name,
>> +   u8 *data,
>> +   unsigned int dirblksize,
>> +   const int ndirents)
>>  {
>> -unsigned int ndirents, head, back;
>> +int head, back;
>>  unsigned int startprfx, endprfx;
>>  struct erofs_dirent *const de = (struct erofs_dirent *)data;
>>  
>> -/* make sure that maxsize is valid */
>> -BUG_ON(maxsize < sizeof(struct erofs_dirent));
>> -
>> -ndirents = le16_to_cpu(de->nameoff) / sizeof(*de);
>> -
>> -/* corrupted dir (may be unnecessary...) */
>> -BUG_ON(!ndirents);
>> -
>> -head = 0;
>> +/* since the 1st dirent has been evaluated previously */
>> +head = 1;
>> 

Re: [RFC PATCH v5 03/12] __wr_after_init: Core and default arch

[Peter Zijlstra]

On Fri, Feb 15, 2019 at 01:10:33AM +0200, Igor Stoppa wrote:
> 
> 
> On 14/02/2019 13:28, Peter Zijlstra wrote:
> > On Thu, Feb 14, 2019 at 12:41:32AM +0200, Igor Stoppa wrote:
> 
> [...]
> 
> > > +#define wr_rcu_assign_pointer(p, v) ({   \
> > > + smp_mb();   \
> > > + wr_assign(p, v);\
> > > + p;  \
> > > +})
> > 
> > This requires that wr_memcpy() (through wr_assign) is single-copy-atomic
> > for native types. There is not a comment in sight that states this.
> 
> Right, I kinda expected native-aligned <-> atomic, but it's not necessarily
> true. It should be confirmed when enabling write rare on a new architecture.
> I'll add the comment.
> 
> > Also, is this true of x86/arm64 memcpy ?
> 
> 
> For x86_64:
> https://elixir.bootlin.com/linux/v5.0-rc6/source/arch/x86/include/asm/uaccess.h#L462
> the mov"itype"  part should deal with atomic copy of native, aligned types.
> 
> 
> For arm64:
> https://elixir.bootlin.com/linux/v5.0-rc6/source/arch/arm64/lib/copy_template.S#L110
> .Ltiny15 deals with copying less than 16 bytes, which includes pointers.
> When the data is aligned, the copy of a pointer should be atomic.
> 

Where are the comments and Changelog notes ? How is an arch maintainer
to be aware of this requirement when adding support for his/her arch?

Re: [PATCH v7 1/6] dt-bindings: mtk-sysirq: Add compatible for Mediatek MT8183

[Marc Zyngier]

On Fri, 15 Feb 2019 07:21:50 +,
Matthias Brugger  wrote:
> 
> 
> 
> On 2/15/19 7:02 AM, Erin Lo wrote:
> > This adds dt-binding documentation of SYSIRQ for Mediatek MT8183 SoC
> > Platform.
> > 
> > Signed-off-by: Erin Lo 
> > Acked-by: Rob Herring 
> > ---
> 
> Reviewed-by: Matthias Brugger 
> 
> Marc you want me to take it through my tree?

Yes please.

Thanks,

M.

-- 
Jazz is not dead, it just smell funny.

RE: [PATCH v5 10/12] KVM/x86/lbr: lazy save the guest lbr stack

[Wang, Wei W]

On Friday, February 15, 2019 9:50 AM, Like Xu wrote:
> To: Wang, Wei W ; linux-kernel@vger.kernel.org;
> k...@vger.kernel.org; pbonz...@redhat.com; a...@linux.intel.com;
> pet...@infradead.org
> Cc: Liang, Kan ; mi...@redhat.com;
> rkrc...@redhat.com; Xu, Like ; ja...@google.com;
> arei.gong...@huawei.com; jmatt...@google.com
> Subject: Re: [PATCH v5 10/12] KVM/x86/lbr: lazy save the guest lbr stack
> 
> On 2019/2/14 17:06, Wei Wang wrote:
> > When the vCPU is scheduled in:
> > - if the lbr feature was used in the last vCPU time slice, set the lbr
> >stack to be interceptible, so that the host can capture whether the
> >lbr feature will be used in this time slice;
> > - if the lbr feature wasn't used in the last vCPU time slice, disable
> >the vCPU support of the guest lbr switching.
> >
> > Upon the first access to one of the lbr related MSRs (since the vCPU
> > was scheduled in):
> > - record that the guest has used the lbr;
> > - create a host perf event to help save/restore the guest lbr stack;
> 
> Based on commit "15ad71460" and guest-use-lbr-only usage, is this possible
> to create none of host perf event for vcpu and simply reuse
> __intel_pmu_lbr_save/restore in intel_pmu_sched_out/in and keep the
> lbr_stack sync with kvm_pmu->lbr_stack rather than task_ctx of perf_event ?

Yes, both method should work. People may have different opinions about
kvm or perf to own the job of lbr switching. Let's see.. if most people vote for
kvm to do the switching, I'll make that change.
Otherwise, I'll stay with what we already have.

Best,
Wei

[PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Hsin-Yi Wang]

i2c_get_dma_safe_msg_buf() allocates space based on msg->len. If threshold is
0 and msg->len is also 0, function makes zero-length allocation, which returns
a special ZERO_SIZE_PTR instead of a NULL pointer, and this will cause later
code to fail. Modify the threshold to > 0 so the function returns NULL pointer.

Fixes: fc66b39fe36a ("i2c: mediatek: Use DMA safe buffers for i2c transactions")
Signed-off-by: Hsin-Yi Wang 
---
 drivers/i2c/busses/i2c-mt65xx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index a74ef76705e0..2bb4d20ead32 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -503,7 +503,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs,
writel(I2C_DMA_INT_FLAG_NONE, i2c->pdmabase + OFFSET_INT_FLAG);
writel(I2C_DMA_CON_RX, i2c->pdmabase + OFFSET_CON);
 
-   dma_rd_buf = i2c_get_dma_safe_msg_buf(msgs, 0);
+   dma_rd_buf = i2c_get_dma_safe_msg_buf(msgs, 1);
if (!dma_rd_buf)
return -ENOMEM;
 
@@ -526,7 +526,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs,
writel(I2C_DMA_INT_FLAG_NONE, i2c->pdmabase + OFFSET_INT_FLAG);
writel(I2C_DMA_CON_TX, i2c->pdmabase + OFFSET_CON);
 
-   dma_wr_buf = i2c_get_dma_safe_msg_buf(msgs, 0);
+   dma_wr_buf = i2c_get_dma_safe_msg_buf(msgs, 1);
if (!dma_wr_buf)
return -ENOMEM;
 
@@ -549,7 +549,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs,
writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_INT_FLAG);
writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_CON);
 
-   dma_wr_buf = i2c_get_dma_safe_msg_buf(msgs, 0);
+   dma_wr_buf = i2c_get_dma_safe_msg_buf(msgs, 1);
if (!dma_wr_buf)
return -ENOMEM;
 
@@ -561,7 +561,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct 
i2c_msg *msgs,
return -ENOMEM;
}
 
-   dma_rd_buf = i2c_get_dma_safe_msg_buf((msgs + 1), 0);
+   dma_rd_buf = i2c_get_dma_safe_msg_buf((msgs + 1), 1);
if (!dma_rd_buf) {
dma_unmap_single(i2c->dev, wpaddr,
 msgs->len, DMA_TO_DEVICE);
-- 
2.18.1

Re: [PATCH v3 5/6] dt-bindings: i2c: Add Mediatek MT8183 i2c binding

[Wolfram Sang]

On Thu, Feb 14, 2019 at 09:54:28AM +0800, Qii Wang wrote:
> On Tue, 2019-02-05 at 14:16 +0100, Wolfram Sang wrote:
> > > +  - mediatek,share-i3c: i3c controller can share i2c function.
> > 
> > I am not happy with this binding. There must be a better way of using
> > the I3C controller in I2C mode. I think it would be easier to tell if we
> > had an I3C driver to see how it implements I2C fallback there. Is the
> > I3C driver on the way?
> > 
> 
> I am very sorry for the late reply due to the Chinese New Year holiday.

No worries. I hope you enjoyed the holidays!

> After confirmation, for I2C mode in I3C controller, we will push an I3C
> driver to implement I2C fallback there later, and we will remove
> "mediatek,share-i3c" for i2c controller driver in the next patch.

The problem with DT bindings is that you need to support them forever
once you introduced them. Because there might be old device trees on
boards out there which need the property. So, I don't like the idea of
having a temporary binding which is meant to be removed anyway. My take
is that you should just send out the I3C driver which will handle the
I2C support then.

Adding Rob to CC in case he has a different opinion.



signature.asc
Description: PGP signature

Re: [PATCH v2] staging: erofs: keep corrupted fs from crashing kernel in erofs_namei()

[Gao Xiang]

Hi Dan,

On 2019/2/15 15:57, Dan Carpenter wrote:
> On Fri, Feb 15, 2019 at 03:02:25PM +0800, Chao Yu wrote:
>> On 2019/2/1 20:16, Gao Xiang wrote:
>>> +   /*
>>> +* on-disk error, let's only BUG_ON in the debugging mode.
>>> +* otherwise, it will return 1 to just skip the invalid name
>>> +* and go on (in consideration of the lookup performance).
>>> +*/
>>> +   DBG_BUGON(qd->name > qd->end);
>>
>> qd->name == qd->end is not allowed as well?
>>
>> So will it be better to return directly here?
>>
>>  if (unlikely(qd->name >= qd->end)) {
>>  DBG_BUGON(1);
>>  return 1;
>>  }
> 
> Please don't add likely/unlikely() annotations unless you have
> benchmarked it and it makes a difference.

I tend not to add this branch above since the current logic can handle
qd->name >= qd->end (it only happens in corrupted images) and
it will return 1;

Let's just leave DBG_BUGON(qd->name > qd->end); here for debugging use
(to detect corrupted image in some degree earlier).

Thanks,
Gao Xiang

> 
> regards,
> dan carpenter
> 
> 

RE: [RFC][Patch v8 0/7] KVM: Guest Free Page Hinting

[Wang, Wei W]

On Thursday, February 14, 2019 5:43 PM, David Hildenbrand wrote:
> Yes indeed, that is the important bit. They must not be put pack to the
> buddy before they have been processed by the hypervisor. But as the pages
> are not in the buddy, no one allocating a page will stumble over such a page
> and try to allocate it. Threads trying to allocate memory will simply pick
> another buddy page instead of "busy waiting" for that page to be finished
> reporting.

What if a guest thread try to allocate some pages but the buddy cannot satisfy
because all the pages are isolated? Would it be the same case that the guest 
thread
gets blocked by waiting all the isolated pages to get madvised by the host and
returned to the guest buddy, or even worse, some guest threads get killed due 
to oom?

Best,
Wei

Re: 答复: [PATCH] x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32

[Petr Mladek]

On Fri 2019-02-15 08:17:36, chenzefeng (A) wrote:
> HI, Jiri Kosina,
> 
> On Fri, 15 Feb 2019, Jiri Kosina wrote:
> >On Fri, 15 Feb 2019, chenzefeng (A) wrote:
> 
> >> On x86-64, for 32-bit PC-relacive branches, we can generate PLT32 
> >> relocation, instead of PC32 relocation. and R_X86_64_PLT32 can be 
> >> treated the same as R_X86_64_PC32 since linux kernel doesn't use PLT.
> >> 
> >> In linux 4.4 commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as
> >> R_X86_64_PC32") been fixed for the module loading, but not fixed for 
> >> livepatch relocation, which will fail to load livepatch with the error 
> >> message as follow: relocation failed for symbol  at 
> >>  >> address>
> >> 
> >> Signed-off-by: chenzefeng 
> 
> >What kernel version is this patch based on? We've got rid of x86-specific 
> >module loading stub and offloaded all the relocation handling to generic 
> >kmod loader long time ago.

The livepatch-specific code has been removed in v4.7, see
the commit 425595a7fc2096ab46c ("livepatch: reuse module
loader code to write relocations").

> The patch is based on kernel version Linux 4.4.174.

The patch would make sense only for 4.4 stable kernel
and it looks fine for this purpose.

Please, send the patch to sta...@vger.kernel.org if
Greg misses it in this thread.

Best Regards,
Petr

Re: [PATCH v2 06/15] clocksource/drivers/timer-milbeaut: Introduce timer for Milbeaut SoCs

[Arnd Bergmann]

On Fri, Feb 15, 2019 at 3:25 AM Sugaya, Taichi
 wrote:
> On 2019/02/15 0:18, Arnd Bergmann wrote:
> > On Thu, Feb 14, 2019 at 3:44 PM Daniel Lezcano
> >  wrote:
> >>
> >> On 13/02/2019 11:34, Sugaya, Taichi wrote:
> >>> Hi,
> >>>
> >>> On 2019/02/12 18:06, Daniel Lezcano wrote:
>  On 08/02/2019 13:26, Sugaya Taichi wrote:
> > Add timer driver for Milbeaut SoCs series.
> >
> > The timer has two 32-bit width down counters, one of which is configured
> > as a clockevent device and the other is configured as a clock source.
> >
> > Signed-off-by: Sugaya Taichi 
> 
>  Do want me to take it through my tree?
> 
> >>>
> >>> Yes, please.
> >>>
> >>> By the way, the patch series includes other sub-system drivers, so
> >>> should it be splitted into each driver patch ?
> >>
> >> Well usually changes are per sub-systems but in case of first submission
> >> you may ask linux-soc@ team to take all the patches together with the
> >> acked-by tags from those subsystems maintainer.
> >>
> >> Added in Cc: Arnd@ and linux-soc@
> >>
> >> I'll wait a bit before applying the patch you clarify this.
> >
> > Yes, I think merging them all together is best here.
> >
> > I saw the patches fly past but did not do a complete review,
> > but if all other review comments are addressed, I'd suggest
> > sending the entire series for inclusion to linux-...@vger.kernel.org
> > with the Acked-by/Reviewed-by tags from subsystem maintainers
> > added in.
>
> Thank you for suggestion.
> OK. I will send the series to the ML with the Acked-by/Reviewed-by tags.

One correction: please send the patches to address "s...@kernel.org"
for inclusion.

  Arnd

Re: [net-next] net: stmmac: handle endianness in dwmac4_get_timestamp

[Alexandre Torgue]

On 2/14/19 7:09 PM, Florian Fainelli wrote:

On 2/14/19 9:26 AM, Alexandre Torgue wrote:

GMAC IP is little-endian and used on several kind of CPU (big or little
endian). Main callbacks functions of the stmmac drivers take care about
it. It was not the case for dwmac4_get_timestamp function.


This is clearly a bugfix, so you should be targeting the 'net' tree and
provide a Fixes: tag so this can be backported to relevant stable kernels.



Ok Florian, I just have to find the right commit to fix :)



Signed-off-by: Alexandre Torgue 

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index 20299f6..736e296 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -241,15 +241,18 @@ static inline void dwmac4_get_timestamp(void *desc, u32 
ats, u64 *ts)
  static int dwmac4_rx_check_timestamp(void *desc)
  {
struct dma_desc *p = (struct dma_desc *)desc;
+   unsigned int rdes0 = le32_to_cpu(p->des0);
+   unsigned int rdes1 = le32_to_cpu(p->des1);
+   unsigned int rdes3 = le32_to_cpu(p->des3);
u32 own, ctxt;
int ret = 1;
  
-	own = p->des3 & RDES3_OWN;

-   ctxt = ((p->des3 & RDES3_CONTEXT_DESCRIPTOR)
+   own = rdes3 & RDES3_OWN;
+   ctxt = ((rdes3 & RDES3_CONTEXT_DESCRIPTOR)
>> RDES3_CONTEXT_DESCRIPTOR_SHIFT);
  
  	if (likely(!own && ctxt)) {

-   if ((p->des0 == 0x) && (p->des1 == 0x))
+   if ((rdes0 == 0x) && (rdes1 == 0x))
/* Corrupted value */
ret = -EINVAL;
else

Re: [PATCH v5] coccinelle: semantic code search for missing put_device()

[Markus Elfring]

> In a function, for a local variable returned by calling
> of_find_device_by_node(),

I suggest to reconsider this information once more.

1. Will an other wording be more appropriate for the storage of
   a function return value?

2. Can the restriction “local” be omitted?

3. Will any macros be involved eventually?


> c, for the rest of the situation, the current function should release the
>reference by calling put_device,

Can it happen that on other function will perform the desired reference release?


> this code search will report the
>corresponding error message.

Rewording?
A code search can report an error with a specific confidence.


> v5->v4:

Such version information would be sufficient also without arrows, wouldn't it?


> - add a SPDX identifierfix

Would you like to fix a typo at the end?


> +@script:python depends on report@
> +p1 << search.p1;
> +p2 << search.p2;
> +@@
> +
> +coccilib.report.print_report(p2[0], "ERROR: missing put_device; "
> +   + "call of_find_device_by_node on line "
> +   + p1[0].line
> +   + ", but without a corresponding object release "
> +   + "within this function.")

I find your interpretation of my reminder for the preferred avoidance
of split string literals interesting somehow.

Can the following source code variant be more appropriate?

+coccilib.report.print_report(p2[0],
+ "WARNING: missing put_device - 
of_find_device_by_node() call on line "
+ + p1[0].line
+ + ", but without a corresponding object release 
within this function.")


Will any more advanced error diagnostics be eventually developed?

Regards,
Markus

Re: Userspace regression in LTS and stable kernels

[Michal Hocko]

On Fri 15-02-19 08:00:22, Greg KH wrote:
> On Thu, Feb 14, 2019 at 12:20:27PM -0800, Andrew Morton wrote:
> > On Thu, 14 Feb 2019 09:56:46 -0800 Linus Torvalds 
> >  wrote:
> > 
> > > On Wed, Feb 13, 2019 at 3:37 PM Richard Weinberger
> > >  wrote:
> > > >
> > > > Your shebang line exceeds BINPRM_BUF_SIZE.
> > > > Before the said commit the kernel silently truncated the shebang line
> > > > (and corrupted it),
> > > > now it tells the user that the line is too long.
> > > 
> > > It doesn't matter if it "corrupted" things by truncating it. All that
> > > matters is "it used to work, now it doesn't"
> > > 
> > > Yes, maybe it never *should* have worked. And yes, it's sad that
> > > people apparently had cases that depended on this odd behavior, but
> > > there we are.
> > > 
> > > I see that Kees has a patch to fix it up.
> > > 
> > 
> > Greg, I think we have a problem here.
> > 
> > 8099b047ecc431518 ("exec: load_script: don't blindly truncate shebang
> > string") wasn't marked for backporting.  And, presumably as a
> > consequence, Kees's fix "exec: load_script: allow interpreter argument
> > truncation" was not marked for backporting.
> > 
> > 8099b047ecc431518 hasn't even appeared in a Linus released kernel, yet
> > it is now present in 4.9.x, 4.14.x, 4.19.x and 4.20.x.
> 
> It came in 5.0-rc1, so it fits the "in a Linus released kernel"
> requirement.  If we are to wait until it shows up in a -final, that
> would be months too late for almost all of these types of patches that
> are picked up.

rc1 is just a too early. Waiting few more rcs or even a final release
for something that people do not see as an issue should be just fine.
Consider this particular patch and tell me why it had to be rushed in
the first place. The original code was broken for _years_ but I do not
remember anybody would be complaining.

> > I don't know if Oleg considered backporting that patch.  I certainly
> > did (I always do), and I decided against doing so.  Yet there it is.
> 
> This came in through Sasha's tools, which give people a week or so to
> say "hey, this isn't a stable patch!" and it seems everyone ignored that
> :(

I thought we were through this already. Automagic autoselection of
patches in the core kernel (or mmotm tree patches in particular) is too
dangerous. We try hard to consider each and every patch for stable. Even
if something slips through then it is much more preferred to ask for a
stable backport in the respective email thread and wait for a conclusion
before adding it.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Wolfram Sang]

On Fri, Feb 15, 2019 at 05:02:02PM +0800, Hsin-Yi Wang wrote:
> i2c_get_dma_safe_msg_buf() allocates space based on msg->len. If threshold is
> 0 and msg->len is also 0, function makes zero-length allocation, which returns
> a special ZERO_SIZE_PTR instead of a NULL pointer, and this will cause later
> code to fail. Modify the threshold to > 0 so the function returns NULL 
> pointer.
> 
> Fixes: fc66b39fe36a ("i2c: mediatek: Use DMA safe buffers for i2c 
> transactions")
> Signed-off-by: Hsin-Yi Wang 

Right. But we need to fix i2c_get_dma_safe_msg_buf(), so it will be
handled for all callers. Do you want to add a check if msg->len is 0 or
shall I? Both fine for me.



signature.asc
Description: PGP signature

Re: [PATCH 01/11] dt-bindings: Add vendor prefix for Silicon Linux.

[Andreas Färber]

Hi Lukasz and Fabrizio,

Am 15.02.19 um 07:52 schrieb Lukasz Majewski:
> The best approach is to run:
> 
> git format patch -1 
> 
> And then 
> 
> scripts/get_maintainer.pl 0001-xxx
> 
> You shall see the the list of people to send the patch.

No, that does not answer his question. And please don't top-post.

>> Who is the best person for taking this patch?

The answer is: whomever is taking dt-bindings patches in the following
10 patches that make use of this prefix, once you have a Reviewed-by
from Rob. So, most likely the Renesas kernel maintainer(s), i.e. Simon,
which differs from get_maintainers.pl of vendor-prefixes.txt.

Regards,
Andreas

>>> From: Fabrizio Castro 
>>> Sent: 16 January 2019 18:38
>>> Subject: [PATCH 01/11] dt-bindings: Add vendor prefix for Silicon
>>> Linux.
>>>
>>> From: Biju Das 
>>>
>>> Add Silicon Linux to the list of devicetree vendor prefixes.
>>>
>>> Website: http://www.si-linux.co.jp
>>>
>>> Signed-off-by: Biju Das 
>>> Signed-off-by: Fabrizio Castro 
>>> Reviewed-by: Chris Paterson 
>>> ---
>>>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
>>> b/Documentation/devicetree/bindings/vendor-prefixes.txt index
>>> 4b1a2a8..02a7037 100644 ---
>>> a/Documentation/devicetree/bindings/vendor-prefixes.txt +++
>>> b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -344,6
>>> +344,7 @@ sgxSGX Sensortech sharpSharp Corporation
>>>  shimafujiShimafuji Electric, Inc.
>>>  si-enSi-En Technology Ltd.
>>> +si-linuxSilicon Linux Corporation
>>>  sifiveSiFive, Inc.
>>>  sigmaSigma Designs, Inc.
>>>  siiSeiko Instruments, Inc.
>>> --
>>> 2.7.4  
>>
>>
>>
>> Renesas Electronics Europe GmbH,Geschaeftsfuehrer/President : Michael
>> Hannawald, Sitz der Gesellschaft/Registered office: Duesseldorf,
>> Arcadiastrasse 10, 40472 Duesseldorf,
>> Germany,Handelsregister/Commercial Register: Duesseldorf, HRB 3708
>> USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE
>> reg. no.: DE 14978647
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
> 


-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [f2fs-dev] [PATCH] f2fs: do not use mutex lock in atomic context

[Chao Yu]

On 2019/2/15 12:28, Ritesh Harjani wrote:
> 
> On 2/14/2019 9:40 PM, Chao Yu wrote:
>> On 2019-2-14 15:46, Sahitya Tummala wrote:
>>> On Wed, Feb 13, 2019 at 11:25:31AM +0800, Chao Yu wrote:
 On 2019/2/4 16:06, Sahitya Tummala wrote:
> Fix below warning coming because of using mutex lock in atomic context.
>
> BUG: sleeping function called from invalid context at 
> kernel/locking/mutex.c:98
> in_atomic(): 1, irqs_disabled(): 0, pid: 585, name: sh
> Preemption disabled at: __radix_tree_preload+0x28/0x130
> Call trace:
>   dump_backtrace+0x0/0x2b4
>   show_stack+0x20/0x28
>   dump_stack+0xa8/0xe0
>   ___might_sleep+0x144/0x194
>   __might_sleep+0x58/0x8c
>   mutex_lock+0x2c/0x48
>   f2fs_trace_pid+0x88/0x14c
>   f2fs_set_node_page_dirty+0xd0/0x184
>
> Do not use f2fs_radix_tree_insert() to avoid doing cond_resched() with
> spin_lock() acquired.
>
> Signed-off-by: Sahitya Tummala 
> ---
>   fs/f2fs/trace.c | 20 +---
>   1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/fs/f2fs/trace.c b/fs/f2fs/trace.c
> index ce2a5eb..d0ab533 100644
> --- a/fs/f2fs/trace.c
> +++ b/fs/f2fs/trace.c
> @@ -14,7 +14,7 @@
>   #include "trace.h"
>   
>   static RADIX_TREE(pids, GFP_ATOMIC);
> -static struct mutex pids_lock;
> +static spinlock_t pids_lock;
>   static struct last_io_info last_io;
>   
>   static inline void __print_last_io(void)
> @@ -58,23 +58,29 @@ void f2fs_trace_pid(struct page *page)
>   
>   set_page_private(page, (unsigned long)pid);
>   
> +retry:
>   if (radix_tree_preload(GFP_NOFS))
>   return;
>   
> - mutex_lock(&pids_lock);
> + spin_lock(&pids_lock);
>   p = radix_tree_lookup(&pids, pid);
>   if (p == current)
>   goto out;
>   if (p)
>   radix_tree_delete(&pids, pid);
>   
> - f2fs_radix_tree_insert(&pids, pid, current);
> 
> Do you know why do we have a retry logic here? When anyways we have 
> called for radix_tree_delete with pid key?
> Which should ensure the slot is empty, no?
> Then why in the original code (f2fs_radix_tree_insert), we were 
> retrying. For what condition a retry was needed?

Hi,

f2fs_radix_tree_insert is used in many places, it was introduced to used in
some paths we should not failed.

And here, I guess we used it for the same purpose, if we failed to insert
@current pointer into radix, next time, we may not skip calling
trace_printk, actually it will print the same current->comm info as
previous one, it's redundant.

Thanks,

> 
> Regards
> Ritesh
> 
> 
> + if (radix_tree_insert(&pids, pid, current)) {
> + spin_unlock(&pids_lock);
> + radix_tree_preload_end();
> + cond_resched();
> + goto retry;
> + }
>   
>   trace_printk("%3x:%3x %4x %-16s\n",
>   MAJOR(inode->i_sb->s_dev), 
> MINOR(inode->i_sb->s_dev),
>   pid, current->comm);
 Hi Sahitya,

 Can trace_printk sleep? For safety, how about moving it out of spinlock?

>>> Hi Chao,
>>>
>>> Yes, trace_printk() is safe to use in atomic context (unlike printk).
>> Hi Sahitya,
>>
>> Thanks for your confirmation. :)
>>
>> Reviewed-by: Chao Yu 
>>
>> Thanks,
>>
>>> Thanks,
>>> Sahitya.
>>>
 Thanks,

>   out:
> - mutex_unlock(&pids_lock);
> + spin_unlock(&pids_lock);
>   radix_tree_preload_end();
>   }
>   
> @@ -119,7 +125,7 @@ void f2fs_trace_ios(struct f2fs_io_info *fio, int 
> flush)
>   
>   void f2fs_build_trace_ios(void)
>   {
> - mutex_init(&pids_lock);
> + spin_lock_init(&pids_lock);
>   }
>   
>   #define PIDVEC_SIZE 128
> @@ -147,7 +153,7 @@ void f2fs_destroy_trace_ios(void)
>   pid_t next_pid = 0;
>   unsigned int found;
>   
> - mutex_lock(&pids_lock);
> + spin_lock(&pids_lock);
>   while ((found = gang_lookup_pids(pid, next_pid, PIDVEC_SIZE))) {
>   unsigned idx;
>   
> @@ -155,5 +161,5 @@ void f2fs_destroy_trace_ios(void)
>   for (idx = 0; idx < found; idx++)
>   radix_tree_delete(&pids, pid[idx]);
>   }
> - mutex_unlock(&pids_lock);
> + spin_unlock(&pids_lock);
>   }
>
>>
>> ___
>> Linux-f2fs-devel mailing list
>> linux-f2fs-de...@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> 
> .
> 

[PATCH] x86/boot: Move detecting acpi=off in cmdline to get_rsdp_addr()

[Chao Fan]

If "acpi=off" specified in cmdline, the whole functions of acpi.c
should not work, there is no need to ealy parse RSDP, so detect
"acpi=off" in the very first place.

Also replace magic number with macro.

Signed-off-by: Chao Fan 
---
 arch/x86/boot/compressed/acpi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
index 0ef4ad55b29b..5510a2105b7b 100644
--- a/arch/x86/boot/compressed/acpi.c
+++ b/arch/x86/boot/compressed/acpi.c
@@ -213,8 +213,13 @@ static acpi_physical_address bios_get_rsdp_addr(void)
 /* Return RSDP address on success, otherwise 0. */
 acpi_physical_address get_rsdp_addr(void)
 {
+   char arg[MAX_ACPI_ARG_LENGTH];
acpi_physical_address pa;
 
+   if (cmdline_find_option("acpi", arg, sizeof(arg)) == 3 &&
+   !strncmp(arg, "off", 3))
+   return 0;
+
pa = get_acpi_rsdp();
 
if (!pa)
@@ -235,9 +240,9 @@ static unsigned long get_acpi_srat_table(void)
 {
unsigned long root_table, acpi_table;
struct acpi_table_header *header;
+   char arg[MAX_ACPI_ARG_LENGTH];
struct acpi_table_rsdp *rsdp;
u32 num_entries, size, len;
-   char arg[10];
u8 *entry;
 
rsdp = (struct acpi_table_rsdp *)(long)boot_params->acpi_rsdp_addr;
@@ -299,13 +304,8 @@ int count_immovable_mem_regions(void)
unsigned long table_addr, table_end, table;
struct acpi_subtable_header *sub_table;
struct acpi_table_header *table_header;
-   char arg[MAX_ACPI_ARG_LENGTH];
int num = 0;
 
-   if (cmdline_find_option("acpi", arg, sizeof(arg)) == 3 &&
-   !strncmp(arg, "off", 3))
-   return 0;
-
table_addr = get_acpi_srat_table();
if (!table_addr)
return 0;
-- 
2.20.1

Re: [PATCH v3 1/9] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem

[Cornelia Huck]

On Thu, 14 Feb 2019 13:30:59 -0500
Tony Krowiak  wrote:

> On 2/14/19 12:36 PM, Pierre Morel wrote:
> > On 14/02/2019 17:57, Cornelia Huck wrote:  
> >> On Thu, 14 Feb 2019 16:47:30 +0100 Pierre Morel
> >>  wrote:
> >>  
> >>> On 14/02/2019 15:54, Cornelia Huck wrote:  
>  On Thu, 14 Feb 2019 14:51:01 +0100 Pierre Morel
>   wrote:  

> > -    matrix_dev->device.type = &vfio_ap_dev_type; 
> > dev_set_name(&matrix_dev->device, "%s", VFIO_AP_DEV_NAME); 
> > matrix_dev->device.parent = root_device; +
> > matrix_dev->device.bus = &matrix_bus; matrix_dev->device.release = 
> > vfio_ap_matrix_dev_release; -
> > matrix_dev->device.driver = &vfio_ap_drv.driver; +
> > matrix_dev->vfio_ap_drv = &vfio_ap_drv;  
> 
>  Can't you get that structure through matrix_dev->device.driver
>  instead when you need it in the function below?  
> >>>
> >>> Not anymore. We have two different drivers and devices matrix_drv
> >>> <-> matrix_dev and vfio_ap_drv <-> ap_devices
> >>>
> >>> The driver behind the matrix_dev->dev->driver is matrix_drv what is
> >>> needed here is vfio_ap_drv.  
> >>
> >> Wait, we had tacked a driver for ap devices unto a matrix device,
> >> which is not on the ap bus?  
> 
> It's really a bit more complicated than that. Without going into a
> lengthy description of the history of AP passthrough support, suffice it
> to say that we needed a device to serve as the parent of each mediated
> device used to configure a matrix of AP adapter IDs and domain indexes
> identifying the devices to which a guest would be granted access. The
> AP devices themselves are attached to the AP bus, but the matrix device
> is an artificial (virtual?) device whose sole purpose in life is to
> serve as an anchor for the mediated devices whose sysfs interfaces are
> created and managed by the vfio_ap device driver. The matrix device
> itself is created by the vfio_ap device driver - when it is initialized 
> - for that purpose. In hindsight, maybe there was a better way to
> implement this, but neither this patch nor this discussion belongs in
> this series. It distracts from discussion of interrupt support which is
> the sole purpose of the patch series.

The we-need-a-parent part is fine; but whatever we're doing with that
driver just looks wrong, so that even the new bus that basically does
nothing looks better...

> 
> > 
> > ...yes -(
> >   
> >> Maybe that's what trips libudev? >
> >> (And reading further in the current code, it seems we clear that 
> >> structure _after_ the matrix device had been setup, so how can that 
> >> even work? Where am I confused?)  
> > 
> > On device_register there were no bus, so the core just do not look for a 
> > driver and this field was nor tested nor overwritten.

Hm... so has the callback in driver_for_each_device() in
vfio_ap_verify_queue_reserved() ever been invoked at all? It seems this
patch fixes more than just libudev issues...

> >   
> >>  
> >>>  
>   
> >
> > ret = device_register(&matrix_dev->device); if (ret) goto
> > matrix_reg_err;
> >
> > +    ret = driver_register(&matrix_driver.drv); +    if (ret) 
> > +    goto
> > matrix_drv_err; +  
> 
>  As you already have several structures that can be registered
>  exactly once (the root device, the bus, the driver, ...), you can
>  already be sure that there's only one device on the bus, can't
>  you?  
> >>>
> >>> hum, no I don't think so, no device can register before this module
> >>> is loaded, but what does prevent a device to register later from
> >>> another module?  
> >>
> >> Not unless you export the interface, I guess.
> >>  
> > 
> > :) definitively right
> > thanks, this will simplify the code in the next version.
> > I will take the patch away from this series to get the way to stable as 
> > Christian requested.

Yeah, makes sense.

Re: [PATCH 1/4] arm64: dts: rockchip: rockpro64 dts make regulator more readable

[Heiko Stübner]

Am Mittwoch, 13. Februar 2019, 18:06:37 CET schrieb Akash Gajjar:
> rename dc12, vcc_sys, vcc1v8_pmu regulators and make it more redable as per
> the schematic of rk3399-rockpro64.
> 
> Signed-off-by: Akash Gajjar 

applied for (hopefully) 5.1

Thanks
Heiko

RE: [RFC][Patch v8 0/7] KVM: Guest Free Page Hinting

[Wang, Wei W]

On Thursday, February 14, 2019 6:01 PM, David Hildenbrand wrote:
> And how to preload without locking?

The memory is preload per-CPU. It's usually called outside the lock.

Best,
Wei

Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Hsin-Yi Wang]

Ok, I can add a check in another patch. Should we return NULL pointer
if msg->len is 0 or print out some warnings? Thanks.

On Fri, Feb 15, 2019 at 5:10 PM Wolfram Sang  wrote:
>
> On Fri, Feb 15, 2019 at 05:02:02PM +0800, Hsin-Yi Wang wrote:
> > i2c_get_dma_safe_msg_buf() allocates space based on msg->len. If threshold 
> > is
> > 0 and msg->len is also 0, function makes zero-length allocation, which 
> > returns
> > a special ZERO_SIZE_PTR instead of a NULL pointer, and this will cause later
> > code to fail. Modify the threshold to > 0 so the function returns NULL 
> > pointer.
> >
> > Fixes: fc66b39fe36a ("i2c: mediatek: Use DMA safe buffers for i2c 
> > transactions")
> > Signed-off-by: Hsin-Yi Wang 
>
> Right. But we need to fix i2c_get_dma_safe_msg_buf(), so it will be
> handled for all callers. Do you want to add a check if msg->len is 0 or
> shall I? Both fine for me.
>

[PATCH 0/4] bug fixes in ntb_hw_amd and ntb_perf

[Mehta, Sanju]

From: Sanjay R Mehta 

Add bug fix for ntb_perf and ntb_hw_amd

Sanjay R Mehta (4):
  NTB: ntb_perf: Increased the number of message retries to 1000
  NTB: ntb_perf: Disable NTB link after clearing peer XLAT registers
  NTB: ntb_perf: Clear stale values in doorbell and command SPAD
register
  NTB: ntb_hw_amd: set peer limit register

 drivers/ntb/hw/amd/ntb_hw_amd.c |  8 
 drivers/ntb/test/ntb_perf.c | 14 +++---
 2 files changed, 15 insertions(+), 7 deletions(-)

-- 
2.7.4

Re: [PATCH v4 3/3] i2c: at91: added slave mode support

[Wolfram Sang]

On Tue, Jan 15, 2019 at 11:43:51PM +0100, Wolfram Sang wrote:
> 
> > All errors (new ones prefixed by >>):
> > 
> > >> ERROR: "at91_init_twi_bus_slave" [drivers/i2c/busses/i2c-at91.ko] 
> > >> undefined!
> > >> ERROR: "at91_twi_probe_slave" [drivers/i2c/busses/i2c-at91.ko] undefined!
> 
> That needs to be fixed. Rest looks good to me!

Ludovic, do you have time to fix it? I would really like to apply this
series for the next merge window.



signature.asc
Description: PGP signature

[PATCH 1/4] NTB: ntb_perf: Increased the number of message retries to 1000

[Mehta, Sanju]

From: Sanjay R Mehta 

while waiting for the peer ntb_perf to initialize scratchpad
registers, local side ntb_perf  might have already exhausted the
maximum number of retries which is currently set to 500. To avoid
this and to give little more time to the peer ntb_perf for scratchpad
initialization, increased the number of retries to 1000

Signed-off-by: Sanjay R Mehta 
---
 drivers/ntb/test/ntb_perf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ntb/test/ntb_perf.c b/drivers/ntb/test/ntb_perf.c
index 2a9d6b0..a828d0e 100644
--- a/drivers/ntb/test/ntb_perf.c
+++ b/drivers/ntb/test/ntb_perf.c
@@ -100,7 +100,7 @@ MODULE_DESCRIPTION("PCIe NTB Performance Measurement Tool");
 #define DMA_TRIES  100
 #define DMA_MDELAY 10
 
-#define MSG_TRIES  500
+#define MSG_TRIES  1000
 #define MSG_UDELAY_LOW 1000
 #define MSG_UDELAY_HIGH2000
 
-- 
2.7.4

Re: [GIT PULL 00/43] perf/core improvements and fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit af63147c1edacfb75a28885a7cd7e6f44e626164:
> 
>   perf/x86/intel: Add counter freezing quirk for Goldmont (2019-02-11 
> 08:00:42 +0100)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo-5.1-20190214
> 
> for you to fetch changes up to 44ec8396e2dadf0f0806767642cfac9e04d0d5b1:
> 
>   tools build feature sched_getcpu: Undef _GNU_SOURCE at the end (2019-02-14 
> 15:39:21 -0300)
> 
> 
> perf/core improvements and fixes:
> 
> perf list:
> 
>   Jiri Olsa:
> 
>   - Display metric expressions for --details option
> 
> perf record:
> 
>   Alexey Budankov:
> 
>   - Implement --affinity=node|cpu option, leftover, the other patches
> in this kit were already applied.
> 
> perf trace:
> 
>   Arnaldo Carvalho de Melo:
> 
>   - Fix segfaults due to not properly handling negative file descriptor 
> syscall args.
> 
>   - Fix segfault related to the 'waitid' 'options' prefix showing logic.
> 
>   - Filter out 'gnome-terminal*' if it is a parent of 'perf trace', to reduce 
> the
> syscall feedback loop in system wide sessions.
> 
> BPF:
> 
>   Song Liu:
> 
>   - Silence "Couldn't synthesize bpf events" warning for EPERM.
> 
> Build system:
> 
>   Arnaldo Carvalho de Melo:
> 
>   - Fix the test-all.c feature detection fast path that was broken for
> quite a while leading to longer build times.
> 
> Event parsing:
> 
>   Jiri Olsa:
> 
>   - Fix legacy events symbol separator parsing
> 
> cs-etm:
> 
>   Mathieu Poirier:
> 
>   - Fix some error path return errors and plug some memory leaks.
> 
>   - Add proper header file for symbols
> 
>   - Remove unused structure fields.
> 
>   - Modularize auxtrace_buffer fetch, decoder and packet processing loop.
> 
> Vendor events:
> 
>   Paul Clarke:
> 
>   - Add assorted metrics for the Power8 and Power9 architectures.
> 
> perf report:
> 
>   Thomas Richter:
> 
>   - Add s390 diagnostic sampling descriptor size
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Alexey Budankov (1):
>   perf record: Implement --affinity=node|cpu option
> 
> Arnaldo Carvalho de Melo (11):
>   tools feature: Undef _GNU_SOURCE at the end of feature tests
>   perf beauty ioctl cmd: The 'fd' arg is signed
>   perf trace: Check if the 'fd' is negative when mapping it to pathname
>   perf beauty waitid options: Fix up prefix showing logic
>   tools build: Add -lrt to FEATURE_CHECK_LDFLAGS-libaio
>   perf trace: Filter out gnome-terminal* parent
>   perf coresight: Do not test for libopencsd by default
>   perf unwind: Do not put libunwind-{x86,aarch64} in FEATURE_TESTS_BASIC
>   tools build: Add test-reallocarray.c to test-all.c to fix the build
>   perf build: Add missing FEATURE_CHECK_LDFLAGS-libcrypto
>   tools build feature sched_getcpu: Undef _GNU_SOURCE at the end
> 
> Jiri Olsa (7):
>   perf tools: Compile perf with libperf-in.o instead of libperf.a
>   perf tools: Rename LIB_FILE to LIBPERF_A
>   perf tools: Rename build libperf to perf
>   perf tools: Fix legacy events symbol separator parsing
>   perf list: Display metric expressions for --details option
>   perf header: Get rid of write_it label
>   perf header: Remove unused 'cpu_nr' field  from 'struct cpu_topo'
> 
> Mathieu Poirier (14):
>   perf cs-etm: Add proper header file for symbols
>   perf cs-etm: Remove unused structure field "state"
>   perf cs-etm: Remove unused structure field "time" and "timestamp"
>   perf cs-etm: Fix wrong return values in error path
>   perf cs-etm: Introducing function cs_etm_decoder__init_dparams()
>   perf cs-etm: Fix memory leak in error path
>   perf cs-etm: Introducing function cs_etm__init_trace_params()
>   perf cs-etm: Fix erroneous comment
>   perf cs-etm: Cleaning up function cs_etm__alloc_queue()
>   perf cs-etm: Rethink kernel address initialisation
>   perf cs-etm: Make cs_etm__run_decoder() queue independent
>   perf cs-etm: Modularize main decoder function
>   perf cs-etm: Modularize main packet processing loop
>   perf cs-etm: Modularize auxtrace_buffer fetch function
> 
> Paul Clarke (8):
>   perf vendor events power8: Cpi_breakdown & estimated_dcache_miss_cpi 
> metrics
>   perf vendor events power8: Dl1_reload, instruction_misses, l2_stats, 
> lsu_rejects, memory & pteg_reloads metrics
>   perf vendor events power8: Branch_prediction, latency, bus_stats, 
> instruction_mix & instruction_stats metrics
>   perf vendor events power8: Translaton & general metrics
>   perf vendor events power9: Cpi_breakdown & estimated_dcache_m

Re: [PATCH 2/4] arm64: dts: rockchip: rockpro64 dts remove unused node

[Heiko Stübner]

Am Mittwoch, 13. Februar 2019, 18:06:38 CET schrieb Akash Gajjar:
> lcd panel pinmux and vcc1v8_s3 regulator is redundant and has a no impact,
> so removing it.
> 
> Signed-off-by: Akash Gajjar 

vcc1v8_s3 is actually also a emmc supply, so I'd like to keep it around
for completenes sake.

I've now dropped the regulator portions so that only the lcd-pinmux
gets removed and reworded the commit message accordingly
and applied the result for 5.1

Thanks
Heiko

[PATCH 2/4] NTB: ntb_perf: Disable NTB link after clearing peer XLAT registers

[Mehta, Sanju]

From: Sanjay R Mehta 

If ntb link disabled before clearing peer's XLAT register, the clearing
won't have any effect since the link is already down. So modified the
sequence so that the link is down only towards the end of the function
after clearing the XLAT register

Signed-off-by: Sanjay R Mehta 
---
 drivers/ntb/test/ntb_perf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/ntb/test/ntb_perf.c b/drivers/ntb/test/ntb_perf.c
index a828d0e..4a3fba4 100644
--- a/drivers/ntb/test/ntb_perf.c
+++ b/drivers/ntb/test/ntb_perf.c
@@ -737,8 +737,6 @@ static void perf_disable_service(struct perf_ctx *perf)
 {
int pidx;
 
-   ntb_link_disable(perf->ntb);
-
if (perf->cmd_send == perf_msg_cmd_send) {
u64 inbits;
 
@@ -755,6 +753,8 @@ static void perf_disable_service(struct perf_ctx *perf)
 
for (pidx = 0; pidx < perf->pcnt; pidx++)
flush_work(&perf->peers[pidx].service);
+
+   ntb_link_disable(perf->ntb);
 }
 
 
/*==
-- 
2.7.4

[PATCH 3/4] NTB: ntb_perf: Clear stale values in doorbell and command SPAD register

[Mehta, Sanju]

From: Sanjay R Mehta 

when ntb_perf is unloaded, the command scratchpad register still
retains the last initialized value of PERF_CMD_INVAL. When ntb_perf
is re-loaded and reads peer command scratchpad register and it mis
interprets the peer state as initialized.

To avoid this, clearing the local side command scratchpad register
in perf_disable_service

Signed-off-by: Sanjay R Mehta 
---
 drivers/ntb/test/ntb_perf.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/ntb/test/ntb_perf.c b/drivers/ntb/test/ntb_perf.c
index 4a3fba4..c7d1a48 100644
--- a/drivers/ntb/test/ntb_perf.c
+++ b/drivers/ntb/test/ntb_perf.c
@@ -754,6 +754,14 @@ static void perf_disable_service(struct perf_ctx *perf)
for (pidx = 0; pidx < perf->pcnt; pidx++)
flush_work(&perf->peers[pidx].service);
 
+   for (pidx = 0; pidx < perf->pcnt; pidx++) {
+   struct perf_peer *peer = &perf->peers[pidx];
+
+   ntb_spad_write(perf->ntb, PERF_SPAD_CMD(peer->gidx), 0);
+   }
+
+   ntb_db_clear(perf->ntb, PERF_SPAD_NOTIFY(perf->gidx));
+
ntb_link_disable(perf->ntb);
 }
 
-- 
2.7.4

[PATCH 4/4] NTB: ntb_hw_amd: set peer limit register

[Mehta, Sanju]

From: Sanjay R Mehta 

As per amd ntb spec it says that peer limit register
must be programmed

Signed-off-by: Sanjay R Mehta 
---
 drivers/ntb/hw/amd/ntb_hw_amd.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
index efb214f..cd463e1 100644
--- a/drivers/ntb/hw/amd/ntb_hw_amd.c
+++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
@@ -160,8 +160,8 @@ static int amd_ntb_mw_set_trans(struct ntb_dev *ntb, int 
pidx, int idx,
}
 
/* set and verify setting the limit */
-   write64(limit, mmio + limit_reg);
-   reg_val = read64(mmio + limit_reg);
+   write64(limit, peer_mmio + limit_reg);
+   reg_val = read64(peer_mmio + limit_reg);
if (reg_val != limit) {
write64(base_addr, mmio + limit_reg);
write64(0, peer_mmio + xlat_reg);
@@ -183,8 +183,8 @@ static int amd_ntb_mw_set_trans(struct ntb_dev *ntb, int 
pidx, int idx,
}
 
/* set and verify setting the limit */
-   writel(limit, mmio + limit_reg);
-   reg_val = readl(mmio + limit_reg);
+   writel(limit, peer_mmio + limit_reg);
+   reg_val = readl(peer_mmio + limit_reg);
if (reg_val != limit) {
writel(base_addr, mmio + limit_reg);
writel(0, peer_mmio + xlat_reg);
-- 
2.7.4

Re: Userspace regression in LTS and stable kernels

[Greg Kroah-Hartman]

On Fri, Feb 15, 2019 at 10:10:00AM +0100, Michal Hocko wrote:
> On Fri 15-02-19 08:00:22, Greg KH wrote:
> > On Thu, Feb 14, 2019 at 12:20:27PM -0800, Andrew Morton wrote:
> > > On Thu, 14 Feb 2019 09:56:46 -0800 Linus Torvalds 
> > >  wrote:
> > > 
> > > > On Wed, Feb 13, 2019 at 3:37 PM Richard Weinberger
> > > >  wrote:
> > > > >
> > > > > Your shebang line exceeds BINPRM_BUF_SIZE.
> > > > > Before the said commit the kernel silently truncated the shebang line
> > > > > (and corrupted it),
> > > > > now it tells the user that the line is too long.
> > > > 
> > > > It doesn't matter if it "corrupted" things by truncating it. All that
> > > > matters is "it used to work, now it doesn't"
> > > > 
> > > > Yes, maybe it never *should* have worked. And yes, it's sad that
> > > > people apparently had cases that depended on this odd behavior, but
> > > > there we are.
> > > > 
> > > > I see that Kees has a patch to fix it up.
> > > > 
> > > 
> > > Greg, I think we have a problem here.
> > > 
> > > 8099b047ecc431518 ("exec: load_script: don't blindly truncate shebang
> > > string") wasn't marked for backporting.  And, presumably as a
> > > consequence, Kees's fix "exec: load_script: allow interpreter argument
> > > truncation" was not marked for backporting.
> > > 
> > > 8099b047ecc431518 hasn't even appeared in a Linus released kernel, yet
> > > it is now present in 4.9.x, 4.14.x, 4.19.x and 4.20.x.
> > 
> > It came in 5.0-rc1, so it fits the "in a Linus released kernel"
> > requirement.  If we are to wait until it shows up in a -final, that
> > would be months too late for almost all of these types of patches that
> > are picked up.
> 
> rc1 is just a too early. Waiting few more rcs or even a final release
> for something that people do not see as an issue should be just fine.
> Consider this particular patch and tell me why it had to be rushed in
> the first place. The original code was broken for _years_ but I do not
> remember anybody would be complaining.

This patch was in 4.20.10, which was released on Feb 12 while 5.0-rc1
came out on Jan 6.  Over a month delay.

> > > I don't know if Oleg considered backporting that patch.  I certainly
> > > did (I always do), and I decided against doing so.  Yet there it is.
> > 
> > This came in through Sasha's tools, which give people a week or so to
> > say "hey, this isn't a stable patch!" and it seems everyone ignored that
> > :(
> 
> I thought we were through this already. Automagic autoselection of
> patches in the core kernel (or mmotm tree patches in particular) is too
> dangerous. We try hard to consider each and every patch for stable. Even
> if something slips through then it is much more preferred to ask for a
> stable backport in the respective email thread and wait for a conclusion
> before adding it.

We have a list of blacklisted files/subsystems for people that do not
want this to happen to their area of the kernel.  The patch seemed to
make sense, and it passed all known tests that we currently have.

Sometimes things will slip through like this, it happens.  And really, a
3 day turn-around-time to resolve this is pretty good, don't you think?

It also seems like we need another test to catch this problem from ever
happening again :)

thanks,

greg k-h

Re: [PATCH 3/4] arm64: dts: rockchip: rockpro64 dts rename LED labels and default trigger

[Heiko Stübner]

Am Mittwoch, 13. Februar 2019, 18:06:39 CET schrieb Akash Gajjar:
> rename white and red LEDs with status and heartbeat respectively.
> replace red LED default state off with default-trigger heartbeat.
> 
> Signed-off-by: Akash Gajjar 

Hmm, in the schematics the leds are named work + diy as in the current
devicetree, so I'd like to keep node names + pinctrl matching schematics
please.

And changing the functionality of the LEDs would require a bit more
rationale in the commit message on why that is something we want.


Heiko

> ---
>  .../arm64/boot/dts/rockchip/rk3399-rockpro64.dts | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts index
> c9a2b26d7cad..dab53d2eb676 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
> @@ -43,17 +43,17 @@
>   leds {
>   compatible = "gpio-leds";
>   pinctrl-names = "default";
> - pinctrl-0 = <&work_led_gpio>, <&diy_led_gpio>;
> + pinctrl-0 = <&status_led_gpio>, <&heartbeat_led_gpio>;
> 
> - work-led {
> - label = "work";
> + status-led {
> + label = "rockpro64:white:status";
>   default-state = "on";
>   gpios = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>;
>   };
> 
> - diy-led {
> - label = "diy";
> - default-state = "off";
> + heartbeat-led {
> + label = "rockpor64:red:heartbeat";
> + linux,default-trigger = "heartbeat";
>   gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
>   };
>   };
> @@ -502,11 +502,11 @@
>   };
> 
>   leds {
> - work_led_gpio: work_led-gpio {
> + status_led_gpio: status-led-gpio {
>   rockchip,pins = <0 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
>   };
> 
> - diy_led_gpio: diy_led-gpio {
> + heartbeat_led_gpio: heartbeat-led-gpio {
>   rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
>   };
>   };

Linux 4.9.157

[Greg KH]

I'm announcing the release of the 4.9.157 kernel.

No one should upgrade to this release, use 4.9.158 instead.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 
 arch/arm/mach-iop32x/n2100.c|3 
 arch/arm/mach-tango/pm.c|6 -
 arch/arm/mach-tango/pm.h|7 +
 arch/arm/mach-tango/setup.c |2 
 arch/mips/kernel/mips-cm.c  |2 
 arch/mips/pci/pci-octeon.c  |   10 +-
 arch/mips/vdso/Makefile |4 -
 drivers/gpu/drm/drm_modes.c |2 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |9 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |2 
 drivers/hid/hid-debug.c |  122 
 drivers/iio/chemical/atlas-ph-sensor.c  |7 -
 drivers/misc/vexpress-syscfg.c  |2 
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c   |   15 +--
 fs/cifs/Kconfig |2 
 fs/debugfs/inode.c  |7 +
 fs/nfsd/nfs4state.c |   57 +-
 fs/nfsd/state.h |2 
 fs/nfsd/xdr4.h  |   13 ++-
 include/linux/hid-debug.h   |9 +-
 kernel/signal.c |   58 ++-
 net/batman-adv/hard-interface.c |5 -
 net/batman-adv/soft-interface.c |2 
 net/ceph/messenger.c|5 -
 net/mac80211/tx.c   |   12 ++-
 net/xfrm/xfrm_user.c|   13 ++-
 samples/mei/mei-amt-version.c   |2 
 28 files changed, 248 insertions(+), 134 deletions(-)

Aaro Koskinen (1):
  MIPS: OCTEON: don't set octeon_dma_bar_type if PCI is disabled

Dan Carpenter (1):
  misc: vexpress: Off by one in vexpress_syscfg_exec()

Eric W. Biederman (2):
  signal: Always notice exiting tasks
  signal: Better detection of synchronous signals

Felix Fietkau (1):
  mac80211: ensure that mgmt tx skbs have tailroom for encryption

Florian Westphal (1):
  xfrm: refine validation of template and selector families

Greg Kroah-Hartman (3):
  debugfs: fix debugfs_rename parameter checking
  Revert "cifs: In Kconfig CONFIG_CIFS_POSIX needs depends on legacy 
(insecure cifs)"
  Linux 4.9.157

Ilya Dryomov (1):
  libceph: avoid KEEPALIVE_PENDING races in ceph_con_keepalive()

J. Bruce Fields (2):
  nfsd4: fix cached replies to solo SEQUENCE compounds
  nfsd4: catch some false session retries

Marc Gonzalez (1):
  ARM: tango: Improve ARCH_MULTIPLATFORM compatibility

Martin Kepplinger (1):
  mtd: rawnand: gpmi: fix MX28 bus master lockup problem

Matt Ranostay (1):
  iio: chemical: atlas-ph-sensor: correct IIO_TEMP values to millicelsius

Paul Burton (1):
  MIPS: VDSO: Include $(ccflags-vdso) in o32,n32 .lds builds

Russell King (1):
  ARM: iop32x/n2100: fix PCI IRQ mapping

Sven Eckelmann (2):
  batman-adv: Avoid WARN on net_device without parent in netns
  batman-adv: Force mac header to start of data on xmit

Thomas Hellstrom (2):
  drm/vmwgfx: Fix setting of dma masks
  drm/vmwgfx: Return error code from vmw_execbuf_copy_fence_user

Tina Zhang (1):
  drm/modes: Prevent division by zero htotal

Tomas Winkler (1):
  samples: mei: use /dev/mei0 instead of /dev/mei

Vladimir Kondratiev (1):
  mips: cm: reprime error cause

Vladis Dronov (1):
  HID: debug: fix the ring buffer implementation



signature.asc
Description: PGP signature

Re: Linux 4.9.157

[Greg KH]

diff --git a/Makefile b/Makefile
index 956923115f7e..4eb7a17e18f1 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 156
+SUBLEVEL = 157
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/arm/mach-iop32x/n2100.c b/arch/arm/mach-iop32x/n2100.c
index c1cd80ecc219..a904244264ce 100644
--- a/arch/arm/mach-iop32x/n2100.c
+++ b/arch/arm/mach-iop32x/n2100.c
@@ -75,8 +75,7 @@ void __init n2100_map_io(void)
 /*
  * N2100 PCI.
  */
-static int __init
-n2100_pci_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+static int n2100_pci_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
int irq;
 
diff --git a/arch/arm/mach-tango/pm.c b/arch/arm/mach-tango/pm.c
index b05c6d6f99d0..08d813234b2d 100644
--- a/arch/arm/mach-tango/pm.c
+++ b/arch/arm/mach-tango/pm.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include "smc.h"
+#include "pm.h"
 
 static int tango_pm_powerdown(unsigned long arg)
 {
@@ -23,10 +24,7 @@ static const struct platform_suspend_ops tango_pm_ops = {
.valid = suspend_valid_only_mem,
 };
 
-static int __init tango_pm_init(void)
+void __init tango_pm_init(void)
 {
suspend_set_ops(&tango_pm_ops);
-   return 0;
 }
-
-late_initcall(tango_pm_init);
diff --git a/arch/arm/mach-tango/pm.h b/arch/arm/mach-tango/pm.h
new file mode 100644
index ..35ea705a0ee2
--- /dev/null
+++ b/arch/arm/mach-tango/pm.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifdef CONFIG_SUSPEND
+void __init tango_pm_init(void);
+#else
+#define tango_pm_init NULL
+#endif
diff --git a/arch/arm/mach-tango/setup.c b/arch/arm/mach-tango/setup.c
index f14b6c7d255b..2b48e1098ea3 100644
--- a/arch/arm/mach-tango/setup.c
+++ b/arch/arm/mach-tango/setup.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include "smc.h"
+#include "pm.h"
 
 static void tango_l2c_write(unsigned long val, unsigned int reg)
 {
@@ -14,4 +15,5 @@ DT_MACHINE_START(TANGO_DT, "Sigma Tango DT")
.dt_compat  = tango_dt_compat,
.l2c_aux_mask   = ~0,
.l2c_write_sec  = tango_l2c_write,
+   .init_late  = tango_pm_init,
 MACHINE_END
diff --git a/arch/mips/kernel/mips-cm.c b/arch/mips/kernel/mips-cm.c
index 659e6d3ae335..60177a612cb1 100644
--- a/arch/mips/kernel/mips-cm.c
+++ b/arch/mips/kernel/mips-cm.c
@@ -424,5 +424,5 @@ void mips_cm_error_report(void)
}
 
/* reprime cause register */
-   write_gcr_error_cause(0);
+   write_gcr_error_cause(cm_error);
 }
diff --git a/arch/mips/pci/pci-octeon.c b/arch/mips/pci/pci-octeon.c
index 308d051fc45c..7c512834a8f1 100644
--- a/arch/mips/pci/pci-octeon.c
+++ b/arch/mips/pci/pci-octeon.c
@@ -573,6 +573,11 @@ static int __init octeon_pci_setup(void)
if (octeon_has_feature(OCTEON_FEATURE_PCIE))
return 0;
 
+   if (!octeon_is_pci_host()) {
+   pr_notice("Not in host mode, PCI Controller not initialized\n");
+   return 0;
+   }
+
/* Point pcibios_map_irq() to the PCI version of it */
octeon_pcibios_map_irq = octeon_pci_pcibios_map_irq;
 
@@ -584,11 +589,6 @@ static int __init octeon_pci_setup(void)
else
octeon_dma_bar_type = OCTEON_DMA_BAR_TYPE_BIG;
 
-   if (!octeon_is_pci_host()) {
-   pr_notice("Not in host mode, PCI Controller not initialized\n");
-   return 0;
-   }
-
/* PCI I/O and PCI MEM values */
set_io_port_base(OCTEON_PCI_IOSPACE_BASE);
ioport_resource.start = 0;
diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index c3dc12a8b7d9..0b845cc7fbdc 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -116,7 +116,7 @@ $(obj)/%-o32.o: $(src)/%.c FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
 
-$(obj)/vdso-o32.lds: KBUILD_CPPFLAGS := -mabi=32
+$(obj)/vdso-o32.lds: KBUILD_CPPFLAGS := $(ccflags-vdso) -mabi=32
 $(obj)/vdso-o32.lds: $(src)/vdso.lds.S FORCE
$(call if_changed_dep,cpp_lds_S)
 
@@ -156,7 +156,7 @@ $(obj)/%-n32.o: $(src)/%.c FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
 
-$(obj)/vdso-n32.lds: KBUILD_CPPFLAGS := -mabi=n32
+$(obj)/vdso-n32.lds: KBUILD_CPPFLAGS := $(ccflags-vdso) -mabi=n32
 $(obj)/vdso-n32.lds: $(src)/vdso.lds.S FORCE
$(call if_changed_dep,cpp_lds_S)
 
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index e14366de0e6e..97387cfbbeb5 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -753,7 +753,7 @@ int drm_mode_hsync(const struct drm_display_mode *mode)
if (mode->hsync)
return mode->hsync;
 
-   if (mode->htotal < 0)
+   if (mode->htotal <= 0)
return 0;
 
calc_val = (mode->clock * 1000) / mode->htotal; /* hsync in Hz */
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 29abd28c19b3..4b556e698f13 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu

Re: Linux 4.9.158

[Greg KH]

diff --git a/Makefile b/Makefile
index 4eb7a17e18f1..2b8434aaeece 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 157
+SUBLEVEL = 158
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/fs/binfmt_script.c b/fs/binfmt_script.c
index 634bdbb23851..afdf4e3cafc2 100644
--- a/fs/binfmt_script.c
+++ b/fs/binfmt_script.c
@@ -43,14 +43,10 @@ static int load_script(struct linux_binprm *bprm)
fput(bprm->file);
bprm->file = NULL;
 
-   for (cp = bprm->buf+2;; cp++) {
-   if (cp >= bprm->buf + BINPRM_BUF_SIZE)
-   return -ENOEXEC;
-   if (!*cp || (*cp == '\n'))
-   break;
-   }
+   bprm->buf[BINPRM_BUF_SIZE - 1] = '\0';
+   if ((cp = strchr(bprm->buf, '\n')) == NULL)
+   cp = bprm->buf+BINPRM_BUF_SIZE-1;
*cp = '\0';
-
while (cp > bprm->buf) {
cp--;
if ((*cp == ' ') || (*cp == '\t'))

Linux 4.9.158

[Greg KH]

I'm announcing the release of the 4.9.158 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile   |2 +-
 fs/binfmt_script.c |   10 +++---
 2 files changed, 4 insertions(+), 8 deletions(-)

Greg Kroah-Hartman (1):
  Linux 4.9.158

Linus Torvalds (1):
  Revert "exec: load_script: don't blindly truncate shebang string"



signature.asc
Description: PGP signature

Linux 4.14.100

[Greg KH]

I'm announcing the release of the 4.14.100 kernel.

No one should use this, use 4.14.101 instead.

The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.14.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile |2 
 arch/arm/mach-iop32x/n2100.c |3 
 arch/arm/mach-tango/pm.c |6 
 arch/arm/mach-tango/pm.h |7 
 arch/arm/mach-tango/setup.c  |2 
 arch/mips/kernel/mips-cm.c   |2 
 arch/mips/pci/pci-octeon.c   |   10 -
 arch/mips/vdso/Makefile  |4 
 drivers/gpu/drm/drm_modes.c  |2 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |9 -
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |2 
 drivers/hid/hid-debug.c  |  122 +
 drivers/iio/adc/axp288_adc.c |   76 ++--
 drivers/iio/chemical/atlas-ph-sensor.c   |7 
 drivers/misc/vexpress-syscfg.c   |2 
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c|   15 -
 drivers/uio/uio.c|  206 +--
 fs/debugfs/inode.c   |7 
 fs/ext4/fsync.c  |   13 -
 include/linux/hid-debug.h|9 -
 include/linux/uio_driver.h   |4 
 kernel/signal.c  |   58 ++
 kernel/trace/trace_uprobe.c  |2 
 net/batman-adv/hard-interface.c  |5 
 net/batman-adv/soft-interface.c  |2 
 net/ceph/messenger.c |5 
 net/mac80211/tx.c|   12 +
 net/xfrm/xfrm_user.c |   13 +
 samples/mei/mei-amt-version.c|2 
 tools/perf/tests/attr/base-record|2 
 tools/perf/tests/attr/test-record-group  |1 
 tools/perf/tests/attr/test-record-group-sampling |2 
 tools/perf/tests/attr/test-record-group1 |1 
 tools/perf/tests/attr/test-stat-C0   |1 
 tools/perf/tests/attr/test-stat-basic|1 
 tools/perf/tests/attr/test-stat-default  |4 
 tools/perf/tests/attr/test-stat-detailed-1   |8 
 tools/perf/tests/attr/test-stat-detailed-2   |   13 +
 tools/perf/tests/attr/test-stat-detailed-3   |   13 +
 tools/perf/tests/attr/test-stat-group|2 
 tools/perf/tests/attr/test-stat-group1   |2 
 tools/perf/tests/attr/test-stat-no-inherit   |1 
 42 files changed, 460 insertions(+), 200 deletions(-)

Aaro Koskinen (1):
  MIPS: OCTEON: don't set octeon_dma_bar_type if PCI is disabled

Andreas Ziegler (1):
  tracing: uprobes: Fix typo in pr_fmt string

Dan Carpenter (1):
  misc: vexpress: Off by one in vexpress_syscfg_exec()

Eric W. Biederman (2):
  signal: Always notice exiting tasks
  signal: Better detection of synchronous signals

Felix Fietkau (1):
  mac80211: ensure that mgmt tx skbs have tailroom for encryption

Florian Westphal (1):
  xfrm: refine validation of template and selector families

Greg Kroah-Hartman (2):
  debugfs: fix debugfs_rename parameter checking
  Linux 4.14.100

Hailong Liu (1):
  uio: fix wrong return value from uio_mmap()

Hamish Martin (2):
  uio: Reduce return paths from uio_write()
  uio: Prevent device destruction while fds are open

Hans de Goede (1):
  iio: adc: axp288: Fix TS-pin handling

Ilya Dryomov (1):
  libceph: avoid KEEPALIVE_PENDING races in ceph_con_keepalive()

Jiri Olsa (3):
  perf tests attr: Fix task term values
  perf tests attr: Fix group stat tests
  perf tests attr: Make hw events optional

Marc Gonzalez (1):
  ARM: tango: Improve ARCH_MULTIPLATFORM compatibility

Martin Kepplinger (1):
  mtd: rawnand: gpmi: fix MX28 bus master lockup problem

Matt Ranostay (1):
  iio: chemical: atlas-ph-sensor: correct IIO_TEMP values to millicelsius

Paul Burton (1):
  MIPS: VDSO: Include $(ccflags-vdso) in o32,n32 .lds builds

Russell King (1):
  ARM: iop32x/n2100: fix PCI IRQ mapping

Sven Eckelmann (2):
  batman-adv: Avoid WARN on net_device without parent in netns
  batman-adv: Force mac header to start of data on xmit

Theodore Ts'o (1):
  Revert "ext4: use ext4_write_inode() when fsyncing w/o a journal"

Thomas Hellstrom (2):
  drm/vmwgfx: Fix setting of dma masks
  drm/vmwgfx: Return error code from vmw_execbuf_copy_fence_user

Tina Zhang (1):
  drm/modes: Prevent division by zero htotal

Tomas Winkler (1):
  samples: mei: use /dev/me

[ANNOUNCE] 4.4.174-rt178

[Daniel Wagner]

Hello RT Folks!

I'm pleased to announce the 4.4.174-rt178 stable release.

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

You can get this release via the git tree at:

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

  branch: v4.4-rt
  Head SHA1: 9be24e580f9f3125b09794b025b4a856c57f43ec

Or to build 4.4.174-rt178 directly, the following patches should be applied:

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

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

  
http://www.kernel.org/pub/linux/kernel/projects/rt/4.4/4.4/patch-4.4.174-rt178.patch.xz


You can also build from 4.4.169-rt177 by applying the incremental patch:

  
http://www.kernel.org/pub/linux/kernel/projects/rt/4.4/4.4/incr/patch-4.4.169-rt177-rt178.patch.xz

Enjoy!
   Daniel

Linux 4.14.101

[Greg KH]

I'm announcing the release of the 4.14.101 kernel.

All users of the 4.14 kernel series must upgrade.

The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.14.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile   |2 +-
 fs/binfmt_script.c |   10 +++---
 2 files changed, 4 insertions(+), 8 deletions(-)

Greg Kroah-Hartman (1):
  Linux 4.14.101

Linus Torvalds (1):
  Revert "exec: load_script: don't blindly truncate shebang string"



signature.asc
Description: PGP signature

Linux 4.19.23

[Greg KH]

I'm announcing the release of the 4.19.23 kernel.

All users of the 4.19 kernel series must upgrade.

The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.19.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile   |2 +-
 fs/binfmt_script.c |   10 +++---
 2 files changed, 4 insertions(+), 8 deletions(-)

Greg Kroah-Hartman (1):
  Linux 4.19.23

Linus Torvalds (1):
  Revert "exec: load_script: don't blindly truncate shebang string"



signature.asc
Description: PGP signature

Re: Linux 4.14.101

[Greg KH]

diff --git a/Makefile b/Makefile
index 86fa9a371383..d5b20b618517 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 14
-SUBLEVEL = 100
+SUBLEVEL = 101
 EXTRAVERSION =
 NAME = Petit Gorille
 
diff --git a/fs/binfmt_script.c b/fs/binfmt_script.c
index d0078cbb718b..7cde3f46ad26 100644
--- a/fs/binfmt_script.c
+++ b/fs/binfmt_script.c
@@ -42,14 +42,10 @@ static int load_script(struct linux_binprm *bprm)
fput(bprm->file);
bprm->file = NULL;
 
-   for (cp = bprm->buf+2;; cp++) {
-   if (cp >= bprm->buf + BINPRM_BUF_SIZE)
-   return -ENOEXEC;
-   if (!*cp || (*cp == '\n'))
-   break;
-   }
+   bprm->buf[BINPRM_BUF_SIZE - 1] = '\0';
+   if ((cp = strchr(bprm->buf, '\n')) == NULL)
+   cp = bprm->buf+BINPRM_BUF_SIZE-1;
*cp = '\0';
-
while (cp > bprm->buf) {
cp--;
if ((*cp == ' ') || (*cp == '\t'))

Re: Linux 4.14.100

[Greg KH]

diff --git a/Makefile b/Makefile
index 3b10c8b542e2..86fa9a371383 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 14
-SUBLEVEL = 99
+SUBLEVEL = 100
 EXTRAVERSION =
 NAME = Petit Gorille
 
diff --git a/arch/arm/mach-iop32x/n2100.c b/arch/arm/mach-iop32x/n2100.c
index c1cd80ecc219..a904244264ce 100644
--- a/arch/arm/mach-iop32x/n2100.c
+++ b/arch/arm/mach-iop32x/n2100.c
@@ -75,8 +75,7 @@ void __init n2100_map_io(void)
 /*
  * N2100 PCI.
  */
-static int __init
-n2100_pci_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+static int n2100_pci_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
int irq;
 
diff --git a/arch/arm/mach-tango/pm.c b/arch/arm/mach-tango/pm.c
index 028e50c6383f..a32c3b631484 100644
--- a/arch/arm/mach-tango/pm.c
+++ b/arch/arm/mach-tango/pm.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include "smc.h"
+#include "pm.h"
 
 static int tango_pm_powerdown(unsigned long arg)
 {
@@ -24,10 +25,7 @@ static const struct platform_suspend_ops tango_pm_ops = {
.valid = suspend_valid_only_mem,
 };
 
-static int __init tango_pm_init(void)
+void __init tango_pm_init(void)
 {
suspend_set_ops(&tango_pm_ops);
-   return 0;
 }
-
-late_initcall(tango_pm_init);
diff --git a/arch/arm/mach-tango/pm.h b/arch/arm/mach-tango/pm.h
new file mode 100644
index ..35ea705a0ee2
--- /dev/null
+++ b/arch/arm/mach-tango/pm.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifdef CONFIG_SUSPEND
+void __init tango_pm_init(void);
+#else
+#define tango_pm_init NULL
+#endif
diff --git a/arch/arm/mach-tango/setup.c b/arch/arm/mach-tango/setup.c
index 677dd7b5efd9..824f90737b04 100644
--- a/arch/arm/mach-tango/setup.c
+++ b/arch/arm/mach-tango/setup.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include "smc.h"
+#include "pm.h"
 
 static void tango_l2c_write(unsigned long val, unsigned int reg)
 {
@@ -15,4 +16,5 @@ DT_MACHINE_START(TANGO_DT, "Sigma Tango DT")
.dt_compat  = tango_dt_compat,
.l2c_aux_mask   = ~0,
.l2c_write_sec  = tango_l2c_write,
+   .init_late  = tango_pm_init,
 MACHINE_END
diff --git a/arch/mips/kernel/mips-cm.c b/arch/mips/kernel/mips-cm.c
index 8f5bd04f320a..7f3f136572de 100644
--- a/arch/mips/kernel/mips-cm.c
+++ b/arch/mips/kernel/mips-cm.c
@@ -457,5 +457,5 @@ void mips_cm_error_report(void)
}
 
/* reprime cause register */
-   write_gcr_error_cause(0);
+   write_gcr_error_cause(cm_error);
 }
diff --git a/arch/mips/pci/pci-octeon.c b/arch/mips/pci/pci-octeon.c
index 3e92a06fa772..4adb8f1fcbc7 100644
--- a/arch/mips/pci/pci-octeon.c
+++ b/arch/mips/pci/pci-octeon.c
@@ -572,6 +572,11 @@ static int __init octeon_pci_setup(void)
if (octeon_has_feature(OCTEON_FEATURE_PCIE))
return 0;
 
+   if (!octeon_is_pci_host()) {
+   pr_notice("Not in host mode, PCI Controller not initialized\n");
+   return 0;
+   }
+
/* Point pcibios_map_irq() to the PCI version of it */
octeon_pcibios_map_irq = octeon_pci_pcibios_map_irq;
 
@@ -583,11 +588,6 @@ static int __init octeon_pci_setup(void)
else
octeon_dma_bar_type = OCTEON_DMA_BAR_TYPE_BIG;
 
-   if (!octeon_is_pci_host()) {
-   pr_notice("Not in host mode, PCI Controller not initialized\n");
-   return 0;
-   }
-
/* PCI I/O and PCI MEM values */
set_io_port_base(OCTEON_PCI_IOSPACE_BASE);
ioport_resource.start = 0;
diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index ce196046ac3e..d1a60690e690 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -121,7 +121,7 @@ $(obj)/%-o32.o: $(src)/%.c FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
 
-$(obj)/vdso-o32.lds: KBUILD_CPPFLAGS := -mabi=32
+$(obj)/vdso-o32.lds: KBUILD_CPPFLAGS := $(ccflags-vdso) -mabi=32
 $(obj)/vdso-o32.lds: $(src)/vdso.lds.S FORCE
$(call if_changed_dep,cpp_lds_S)
 
@@ -161,7 +161,7 @@ $(obj)/%-n32.o: $(src)/%.c FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
 
-$(obj)/vdso-n32.lds: KBUILD_CPPFLAGS := -mabi=n32
+$(obj)/vdso-n32.lds: KBUILD_CPPFLAGS := $(ccflags-vdso) -mabi=n32
 $(obj)/vdso-n32.lds: $(src)/vdso.lds.S FORCE
$(call if_changed_dep,cpp_lds_S)
 
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 4a3f68a33844..3e3035c9e96b 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -751,7 +751,7 @@ int drm_mode_hsync(const struct drm_display_mode *mode)
if (mode->hsync)
return mode->hsync;
 
-   if (mode->htotal < 0)
+   if (mode->htotal <= 0)
return 0;
 
calc_val = (mode->clock * 1000) / mode->htotal; /* hsync in Hz */
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 86d25f18aa99..3bc7915097ad 100644
--- a/drivers/gpu/drm/vm

Re: [PATCH v3 3/3] pwm: core: add consumer device link

[Claudiu.Beznea]

On 13.02.2019 12:50, Fabrice Gasnier wrote:
> Add a device link between the PWM consumer and the PWM provider. This
> enforces the PWM user to get suspended before the PWM provider. It
> allows proper synchronization of suspend/resume sequences: the PWM user
> is responsible for properly stopping PWM, before the provider gets
> suspended: see [1]. Add the device link in:
> - of_pwm_get()
> - pwm_get()
> - devm_ variants
> as it requires a reference to the device for the PWM consumer.
> 
> [1] https://lkml.org/lkml/2019/2/5/770
> 
> Suggested-by: Thierry Reding 
> Signed-off-by: Fabrice Gasnier 
> ---
> Changes in v3:
> - add struct device to of_get_pwm() arguments to handle device link from
>   there.
> ---
>  drivers/pwm/core.c  | 14 +++---
>  include/linux/pwm.h |  6 --
>  2 files changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 1581f6a..8cb5d4bc 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -638,6 +638,7 @@ static struct pwm_chip *of_node_to_pwmchip(struct 
> device_node *np)
>  
>  /**
>   * of_pwm_get() - request a PWM via the PWM framework
> + * @dev: device for PWM consumer
>   * @np: device node to get the PWM from
>   * @con_id: consumer name
>   *
> @@ -655,7 +656,8 @@ static struct pwm_chip *of_node_to_pwmchip(struct 
> device_node *np)
>   * Returns: A pointer to the requested PWM device or an ERR_PTR()-encoded
>   * error code on failure.
>   */
> -struct pwm_device *of_pwm_get(struct device_node *np, const char *con_id)
> +struct pwm_device *of_pwm_get(struct device *dev, struct device_node *np,
> +   const char *con_id)
>  {
>   struct pwm_device *pwm = NULL;
>   struct of_phandle_args args;
> @@ -689,6 +691,9 @@ struct pwm_device *of_pwm_get(struct device_node *np, 
> const char *con_id)
>   if (IS_ERR(pwm))
>   goto put;
>  
> + if (!device_link_add(dev, pwm->chip->dev, DL_FLAG_AUTOREMOVE_CONSUMER))
> + pr_debug("%s(): device link not added\n", __func__);
> +

Just asking... will this mechanism also be working for PWMs requested via
sysfs? At a first look it seems not.

Thank you,
Claudiu Beznea

>   /*
>* If a consumer name was not given, try to look it up from the
>* "pwm-names" property if it exists. Otherwise use the name of
> @@ -771,7 +776,7 @@ struct pwm_device *pwm_get(struct device *dev, const char 
> *con_id)
>  
>   /* look up via DT first */
>   if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node)
> - return of_pwm_get(dev->of_node, con_id);
> + return of_pwm_get(dev, dev->of_node, con_id);
>  
>   /*
>* We look up the provider in the static table typically provided by
> @@ -851,6 +856,9 @@ struct pwm_device *pwm_get(struct device *dev, const char 
> *con_id)
>   pwm->args.period = chosen->period;
>   pwm->args.polarity = chosen->polarity;
>  
> + if (!device_link_add(dev, pwm->chip->dev, DL_FLAG_AUTOREMOVE_CONSUMER))
> + pr_debug("%s(): device link not added\n", __func__);
> +
>   return pwm;
>  }
>  EXPORT_SYMBOL_GPL(pwm_get);
> @@ -939,7 +947,7 @@ struct pwm_device *devm_of_pwm_get(struct device *dev, 
> struct device_node *np,
>   if (!ptr)
>   return ERR_PTR(-ENOMEM);
>  
> - pwm = of_pwm_get(np, con_id);
> + pwm = of_pwm_get(dev, np, con_id);
>   if (!IS_ERR(pwm)) {
>   *ptr = pwm;
>   devres_add(dev, ptr);
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index d5199b5..895e074 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -406,7 +406,8 @@ struct pwm_device *of_pwm_xlate_with_flags(struct 
> pwm_chip *pc,
>   const struct of_phandle_args *args);
>  
>  struct pwm_device *pwm_get(struct device *dev, const char *con_id);
> -struct pwm_device *of_pwm_get(struct device_node *np, const char *con_id);
> +struct pwm_device *of_pwm_get(struct device *dev, struct device_node *np,
> +   const char *con_id);
>  void pwm_put(struct pwm_device *pwm);
>  
>  struct pwm_device *devm_pwm_get(struct device *dev, const char *con_id);
> @@ -494,7 +495,8 @@ static inline struct pwm_device *pwm_get(struct device 
> *dev,
>   return ERR_PTR(-ENODEV);
>  }
>  
> -static inline struct pwm_device *of_pwm_get(struct device_node *np,
> +static inline struct pwm_device *of_pwm_get(struct device *dev,
> + struct device_node *np,
>   const char *con_id)
>  {
>   return ERR_PTR(-ENODEV);
> 

Linux 4.19.22

[Greg KH]

I'm announcing the release of the 4.19.22 kernel.

Don't use this, use 4.19.23 instead.

The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.19.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile  |2 
 arch/arm/boot/dts/da850.dtsi  |2 
 arch/arm/mach-iop32x/n2100.c  |3 
 arch/arm/mach-tango/pm.c  |6 -
 arch/arm/mach-tango/pm.h  |7 +
 arch/arm/mach-tango/setup.c   |2 
 arch/mips/kernel/mips-cm.c|2 
 arch/mips/loongson64/common/reset.c   |7 +
 arch/mips/pci/pci-octeon.c|   10 +-
 arch/mips/vdso/Makefile   |5 -
 arch/powerpc/include/asm/book3s/64/pgtable.h  |   22 +---
 arch/powerpc/mm/pgtable-book3s64.c|   22 
 drivers/ata/libata-core.c |1 
 drivers/firmware/arm_scmi/bus.c   |9 +
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c |1 
 drivers/gpu/drm/drm_modes.c   |2 
 drivers/gpu/drm/i915/intel_ddi.c  |2 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |9 +
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c   |2 
 drivers/iio/adc/axp288_adc.c  |   76 ---
 drivers/iio/adc/ti-ads8688.c  |3 
 drivers/iio/chemical/atlas-ph-sensor.c|7 -
 drivers/misc/mei/hw-me-regs.h |2 
 drivers/misc/mei/pci-me.c |2 
 drivers/misc/mic/vop/vop_main.c   |4 
 drivers/misc/vexpress-syscfg.c|2 
 drivers/mtd/mtdpart.c |4 
 drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c |   13 +-
 drivers/mtd/nand/spi/core.c   |   46 -
 drivers/pinctrl/intel/pinctrl-cherryview.c|8 -
 drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c |2 
 fs/debugfs/inode.c|7 +
 fs/ext4/fsync.c   |   13 --
 include/linux/sunrpc/xprt.h   |5 +
 kernel/signal.c   |   58 +++-
 kernel/trace/trace_uprobe.c   |2 
 net/batman-adv/hard-interface.c   |5 -
 net/batman-adv/soft-interface.c   |2 
 net/ceph/messenger.c  |5 -
 net/mac80211/tx.c |   12 +-
 net/sunrpc/clnt.c |6 -
 net/sunrpc/xprtrdma/svc_rdma_sendto.c |  105 --
 net/sunrpc/xprtrdma/svc_rdma_transport.c  |   13 +-
 net/xfrm/xfrm_policy.c|5 -
 net/xfrm/xfrm_user.c  |   13 +-
 samples/mei/mei-amt-version.c |2 
 tools/iio/iio_generic_buffer.c|2 
 47 files changed, 401 insertions(+), 139 deletions(-)

Aaro Koskinen (1):
  MIPS: OCTEON: don't set octeon_dma_bar_type if PCI is disabled

Andreas Ziegler (1):
  tracing: uprobes: Fix typo in pr_fmt string

Aneesh Kumar K.V (1):
  powerpc/radix: Fix kernel crash with mremap()

Bartosz Golaszewski (1):
  ARM: dts: da850: fix interrupt numbers for clocksource

Benedict Wong (1):
  xfrm: Make set-mark default behavior backward compatible

Benjamin Coddington (1):
  SUNRPC: Always drop the XPRT_LOCK on XPRT_CLOSE_WAIT

Boris Brezillon (3):
  mtd: Make sure mtd->erasesize is valid even if the partition is of size 0
  mtd: spinand: Handle the case where PROGRAM LOAD does not reset the cache
  mtd: spinand: Fix the error/cleanup path in spinand_init()

Chen-Yu Tsai (1):
  pinctrl: sunxi: Correct number of IRQ banks on H6 main pin controller

Chuck Lever (2):
  svcrdma: Reduce max_send_sges
  svcrdma: Remove max_sge check at connect time

Dan Carpenter (1):
  misc: vexpress: Off by one in vexpress_syscfg_exec()

Dan Murphy (1):
  iio: ti-ads8688: Update buffer allocation for timestamps

Dmitry Torokhov (1):
  pinctrl: cherryview: fix Strago DMI workaround

Eric W. Biederman (2):
  signal: Always notice exiting tasks
  signal: Better detection of synchronous signals

Felix Fietkau (1):
  mac80211: ensure that mgmt tx skbs have tailroom for encryption

Florian Westphal (1):
  xfrm: refine validation of template and selector families

Greg Kroah-Hartman (2):
  debugfs: fix debugfs_rename parameter checking
  Linux 4.19.22

Gustavo A. R. Silva (1):
  drm/amd/powerplay: Fix missing break in switch

Hans de Goede (2):
  

Re: Linux 4.19.22

[Greg KH]

diff --git a/Makefile b/Makefile
index ba5f14d38d8e..8cfcb01fcd7b 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 19
-SUBLEVEL = 21
+SUBLEVEL = 22
 EXTRAVERSION =
 NAME = "People's Front"
 
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 47aa53ba6b92..559659b399d0 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -476,7 +476,7 @@
clocksource: timer@2 {
compatible = "ti,da830-timer";
reg = <0x2 0x1000>;
-   interrupts = <12>, <13>;
+   interrupts = <21>, <22>;
interrupt-names = "tint12", "tint34";
clocks = <&pll0_auxclk>;
};
diff --git a/arch/arm/mach-iop32x/n2100.c b/arch/arm/mach-iop32x/n2100.c
index 3b73813c6b04..23e8c93515d4 100644
--- a/arch/arm/mach-iop32x/n2100.c
+++ b/arch/arm/mach-iop32x/n2100.c
@@ -75,8 +75,7 @@ void __init n2100_map_io(void)
 /*
  * N2100 PCI.
  */
-static int __init
-n2100_pci_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+static int n2100_pci_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
int irq;
 
diff --git a/arch/arm/mach-tango/pm.c b/arch/arm/mach-tango/pm.c
index 028e50c6383f..a32c3b631484 100644
--- a/arch/arm/mach-tango/pm.c
+++ b/arch/arm/mach-tango/pm.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include "smc.h"
+#include "pm.h"
 
 static int tango_pm_powerdown(unsigned long arg)
 {
@@ -24,10 +25,7 @@ static const struct platform_suspend_ops tango_pm_ops = {
.valid = suspend_valid_only_mem,
 };
 
-static int __init tango_pm_init(void)
+void __init tango_pm_init(void)
 {
suspend_set_ops(&tango_pm_ops);
-   return 0;
 }
-
-late_initcall(tango_pm_init);
diff --git a/arch/arm/mach-tango/pm.h b/arch/arm/mach-tango/pm.h
new file mode 100644
index ..35ea705a0ee2
--- /dev/null
+++ b/arch/arm/mach-tango/pm.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifdef CONFIG_SUSPEND
+void __init tango_pm_init(void);
+#else
+#define tango_pm_init NULL
+#endif
diff --git a/arch/arm/mach-tango/setup.c b/arch/arm/mach-tango/setup.c
index 677dd7b5efd9..824f90737b04 100644
--- a/arch/arm/mach-tango/setup.c
+++ b/arch/arm/mach-tango/setup.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include "smc.h"
+#include "pm.h"
 
 static void tango_l2c_write(unsigned long val, unsigned int reg)
 {
@@ -15,4 +16,5 @@ DT_MACHINE_START(TANGO_DT, "Sigma Tango DT")
.dt_compat  = tango_dt_compat,
.l2c_aux_mask   = ~0,
.l2c_write_sec  = tango_l2c_write,
+   .init_late  = tango_pm_init,
 MACHINE_END
diff --git a/arch/mips/kernel/mips-cm.c b/arch/mips/kernel/mips-cm.c
index 8f5bd04f320a..7f3f136572de 100644
--- a/arch/mips/kernel/mips-cm.c
+++ b/arch/mips/kernel/mips-cm.c
@@ -457,5 +457,5 @@ void mips_cm_error_report(void)
}
 
/* reprime cause register */
-   write_gcr_error_cause(0);
+   write_gcr_error_cause(cm_error);
 }
diff --git a/arch/mips/loongson64/common/reset.c 
b/arch/mips/loongson64/common/reset.c
index a60715e11306..b26892ce871c 100644
--- a/arch/mips/loongson64/common/reset.c
+++ b/arch/mips/loongson64/common/reset.c
@@ -59,7 +59,12 @@ static void loongson_poweroff(void)
 {
 #ifndef CONFIG_LEFI_FIRMWARE_INTERFACE
mach_prepare_shutdown();
-   unreachable();
+
+   /*
+* It needs a wait loop here, but mips/kernel/reset.c already calls
+* a generic delay loop, machine_hang(), so simply return.
+*/
+   return;
 #else
void (*fw_poweroff)(void) = (void *)loongson_sysconf.poweroff_addr;
 
diff --git a/arch/mips/pci/pci-octeon.c b/arch/mips/pci/pci-octeon.c
index 5017d5843c5a..fc29b85cfa92 100644
--- a/arch/mips/pci/pci-octeon.c
+++ b/arch/mips/pci/pci-octeon.c
@@ -568,6 +568,11 @@ static int __init octeon_pci_setup(void)
if (octeon_has_feature(OCTEON_FEATURE_PCIE))
return 0;
 
+   if (!octeon_is_pci_host()) {
+   pr_notice("Not in host mode, PCI Controller not initialized\n");
+   return 0;
+   }
+
/* Point pcibios_map_irq() to the PCI version of it */
octeon_pcibios_map_irq = octeon_pci_pcibios_map_irq;
 
@@ -579,11 +584,6 @@ static int __init octeon_pci_setup(void)
else
octeon_dma_bar_type = OCTEON_DMA_BAR_TYPE_BIG;
 
-   if (!octeon_is_pci_host()) {
-   pr_notice("Not in host mode, PCI Controller not initialized\n");
-   return 0;
-   }
-
/* PCI I/O and PCI MEM values */
set_io_port_base(OCTEON_PCI_IOSPACE_BASE);
ioport_resource.start = 0;
diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index 34605ca21498..6f10312e0c76 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -8,6 +8,7 @@ ccflags-vdso := \
$(filter -E%,$(KBUILD_CFLAGS)) \
$(filt

Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()

[Wolfram Sang]

On Fri, Feb 15, 2019 at 05:17:27PM +0800, Hsin-Yi Wang wrote:
> Ok, I can add a check in another patch. Should we return NULL pointer
> if msg->len is 0 or print out some warnings? Thanks.

No warning, msg->len == 0 is a valid setting. But interesting question:
I was about to say NULL, but your driver would assume ENOMEM there and
discard the message which is also not correct since msg->len == 0 is a
valid setting. So, should we just return msg->buf then? Will this work
with your driver? Can it handle zero-length transfers?

> On Fri, Feb 15, 2019 at 5:10 PM Wolfram Sang  wrote:
> >
> > On Fri, Feb 15, 2019 at 05:02:02PM +0800, Hsin-Yi Wang wrote:
> > > i2c_get_dma_safe_msg_buf() allocates space based on msg->len. If 
> > > threshold is
> > > 0 and msg->len is also 0, function makes zero-length allocation, which 
> > > returns
> > > a special ZERO_SIZE_PTR instead of a NULL pointer, and this will cause 
> > > later
> > > code to fail. Modify the threshold to > 0 so the function returns NULL 
> > > pointer.
> > >
> > > Fixes: fc66b39fe36a ("i2c: mediatek: Use DMA safe buffers for i2c 
> > > transactions")
> > > Signed-off-by: Hsin-Yi Wang 
> >
> > Right. But we need to fix i2c_get_dma_safe_msg_buf(), so it will be
> > handled for all callers. Do you want to add a check if msg->len is 0 or
> > shall I? Both fine for me.
> >


signature.asc
Description: PGP signature

Linux 4.20.9

[Greg KH]

I'm announcing the release of the 4.20.9 kernel.

Stay away from this, use 4.20.10 instead.

The updated 4.20.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.20.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile  |2 
 arch/arm/boot/dts/da850.dtsi  |2 
 arch/arm/mach-iop32x/n2100.c  |3 
 arch/arm/mach-tango/pm.c  |6 -
 arch/arm/mach-tango/pm.h  |7 +
 arch/arm/mach-tango/setup.c   |2 
 arch/mips/boot/dts/xilfpga/nexys4ddr.dts  |8 -
 arch/mips/kernel/mips-cm.c|2 
 arch/mips/loongson64/common/reset.c   |7 +
 arch/mips/pci/pci-octeon.c|   10 +-
 arch/mips/vdso/Makefile   |5 -
 arch/powerpc/include/asm/book3s/64/pgtable.h  |   22 +---
 arch/powerpc/mm/pgtable-book3s64.c|   22 
 arch/powerpc/platforms/pseries/papr_scm.c |5 -
 drivers/ata/libata-core.c |1 
 drivers/firmware/arm_scmi/bus.c   |9 +
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c |1 
 drivers/gpu/drm/drm_modes.c   |2 
 drivers/gpu/drm/i915/intel_ddi.c  |2 
 drivers/gpu/drm/i915/intel_display.c  |   51 +-
 drivers/gpu/drm/rockchip/rockchip_rgb.c   |   11 --
 drivers/gpu/drm/rockchip/rockchip_rgb.h   |   11 --
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |9 +
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c   |2 
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |4 
 drivers/iio/adc/axp288_adc.c  |   76 ---
 drivers/iio/adc/ti-ads8688.c  |3 
 drivers/iio/chemical/atlas-ph-sensor.c|7 -
 drivers/misc/mei/hw-me-regs.h |2 
 drivers/misc/mei/pci-me.c |2 
 drivers/misc/mic/vop/vop_main.c   |4 
 drivers/misc/vexpress-syscfg.c|2 
 drivers/mtd/mtdpart.c |4 
 drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c |   13 +-
 drivers/mtd/nand/spi/core.c   |   46 -
 drivers/pinctrl/intel/pinctrl-cherryview.c|8 -
 drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c |2 
 fs/debugfs/inode.c|7 +
 fs/ext4/fsync.c   |   13 --
 kernel/signal.c   |   63 -
 kernel/trace/trace_uprobe.c   |9 +
 net/batman-adv/hard-interface.c   |5 -
 net/batman-adv/soft-interface.c   |2 
 net/ceph/messenger.c  |5 -
 net/mac80211/tx.c |   12 +-
 net/sunrpc/xprtrdma/svc_rdma_sendto.c |  105 --
 net/sunrpc/xprtrdma/svc_rdma_transport.c  |9 -
 net/wireless/ap.c |2 
 net/wireless/core.h   |2 
 net/wireless/sme.c|2 
 net/xfrm/xfrm_policy.c|5 -
 net/xfrm/xfrm_user.c  |   13 +-
 samples/mei/mei-amt-version.c |2 
 tools/iio/iio_generic_buffer.c|2 
 54 files changed, 460 insertions(+), 173 deletions(-)

Aaro Koskinen (1):
  MIPS: OCTEON: don't set octeon_dma_bar_type if PCI is disabled

Andreas Ziegler (2):
  tracing/uprobes: Fix output for multiple string arguments
  tracing: uprobes: Fix typo in pr_fmt string

Aneesh Kumar K.V (1):
  powerpc/radix: Fix kernel crash with mremap()

Bartosz Golaszewski (1):
  ARM: dts: da850: fix interrupt numbers for clocksource

Benedict Wong (1):
  xfrm: Make set-mark default behavior backward compatible

Boris Brezillon (3):
  mtd: Make sure mtd->erasesize is valid even if the partition is of size 0
  mtd: spinand: Handle the case where PROGRAM LOAD does not reset the cache
  mtd: spinand: Fix the error/cleanup path in spinand_init()

Chen-Yu Tsai (1):
  pinctrl: sunxi: Correct number of IRQ banks on H6 main pin controller

Chuck Lever (1):
  svcrdma: Remove max_sge check at connect time

Dan Carpenter (1):
  misc: vexpress: Off by one in vexpress_syscfg_exec()

Dan Murphy (1):
  iio: ti-ads8688: Update buffer allocation for timestamps

Dmitry Torokhov (1):
  pinctrl: cherryview: fix Strago DMI workaround

Eric W. Biederman (3):
  signal: Always attempt to allocate siginfo for SIGSTOP
  signal: Always notice exiting task

Re: [PATCH] Fix resume for ELAN2097 touchscreen.

[Kai-Heng Feng]

Hi Jiri and James,

> On Feb 15, 2019, at 15:35, Jiri Kosina  wrote:
> 
> On Thu, 14 Feb 2019, james broadus wrote:
> 
>>> This should be fixed in hid.git#for-5.1/i2c-hid already by commit
>>> 1475af255e18f. Could you please confirm that?
>>> 
>> 
>> Hi Jiri. That change mutes the log messages, but I'm still counting 
>> around 35000 interrupts per second after resume and touch does not work. 
>> With the reset, the device works properly.
> 
> Ah, I see. Should your patch then actually replace 1475af255e18f?

Sorry for the late reply, was off because of Lunar new year.

Commit 1475af255e18f is to silence the message when using the touchpad, so it’s 
different to this patch.

I’ve seen similar bugs happens on new platforms that defaults S2Idle (Modern 
Standby), but user uses S3 instead.
On those systems, S3 was never tested, so the BIOS doesn’t cut the touchpad’s 
power off during S3, and the IRQ line wasn’t getting properly reset.

So if the platform defaults to S2Idle but user wants to use S3, this issue 
happens.
If that’s the case, maybe it’s better to report to the platform vendor.

Kai-Heng

> 
> Thanks,
> 
> -- 
> Jiri Kosina
> SUSE Labs
> 

Linux 4.20.10

[Greg KH]

I'm announcing the release of the 4.20.10 kernel.

All users of the 4.20 kernel series must upgrade.

The updated 4.20.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.20.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile   |2 +-
 fs/binfmt_script.c |   10 +++---
 2 files changed, 4 insertions(+), 8 deletions(-)

Greg Kroah-Hartman (1):
  Linux 4.20.10

Linus Torvalds (1):
  Revert "exec: load_script: don't blindly truncate shebang string"



signature.asc
Description: PGP signature

[tip:perf/core] perf record: Implement --affinity=node|cpu option

[tip-bot for Alexey Budankov]

Commit-ID:  f4fe11b7bf7ff6a1ccf15d7a9484f0ff7d1e92ae
Gitweb: https://git.kernel.org/tip/f4fe11b7bf7ff6a1ccf15d7a9484f0ff7d1e92ae
Author: Alexey Budankov 
AuthorDate: Tue, 22 Jan 2019 20:52:03 +0300
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Mon, 11 Feb 2019 12:32:21 -0300

perf record: Implement --affinity=node|cpu option

Implement --affinity=node|cpu option for the record mode defaulting
to system affinity mask bouncing.

Signed-off-by: Alexey Budankov 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/083f5422-ece9-10dd-8305-bf59c860f...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-record.txt |  5 +
 tools/perf/builtin-record.c  | 18 ++
 2 files changed, 23 insertions(+)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index 02b4aa2621e7..8f0c2be34848 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -454,6 +454,11 @@ Use  control blocks in asynchronous (Posix AIO) trace 
writing mode (default:
 Asynchronous mode is supported only when linking Perf tool with libc library
 providing implementation for Posix AIO API.
 
+--affinity=mode::
+Set affinity mask of trace reading thread according to the policy defined by 
'mode' value:
+  node - thread affinity mask is set to NUMA node cpu mask of the processed 
mmap buffer
+  cpu  - thread affinity mask is set to cpu of the processed mmap buffer
+
 --all-kernel::
 Configure all used events to run in kernel space.
 
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 3fdfbaebd95e..6c3719ac901d 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1656,6 +1656,21 @@ static int parse_clockid(const struct option *opt, const 
char *str, int unset)
return -1;
 }
 
+static int record__parse_affinity(const struct option *opt, const char *str, 
int unset)
+{
+   struct record_opts *opts = (struct record_opts *)opt->value;
+
+   if (unset || !str)
+   return 0;
+
+   if (!strcasecmp(str, "node"))
+   opts->affinity = PERF_AFFINITY_NODE;
+   else if (!strcasecmp(str, "cpu"))
+   opts->affinity = PERF_AFFINITY_CPU;
+
+   return 0;
+}
+
 static int record__parse_mmap_pages(const struct option *opt,
const char *str,
int unset __maybe_unused)
@@ -1964,6 +1979,9 @@ static struct option __record_options[] = {
 &nr_cblocks_default, "n", "Use  control blocks in 
asynchronous trace writing mode (default: 1, max: 4)",
 record__aio_parse),
 #endif
+   OPT_CALLBACK(0, "affinity", &record.opts, "node|cpu",
+"Set affinity mask of trace reading thread to NUMA node 
cpu mask or cpu of processed mmap buffer",
+record__parse_affinity),
OPT_END()
 };
 

Re: [patch V5 4/8] nvme-pci: Simplify interrupt allocation

[Marc Zyngier]

On Thu, 14 Feb 2019 20:47:59 +,
Thomas Gleixner  wrote:
> 
> From: Ming Lei 
> 
> The NVME PCI driver contains a tedious mechanism for interrupt
> allocation, which is necessary to adjust the number and size of interrupt
> sets to the maximum available number of interrupts which depends on the
> underlying PCI capabilities and the available CPU resources.
> 
> It works around the former short comings of the PCI and core interrupt
> allocation mechanims in combination with interrupt sets.
> 
> The PCI interrupt allocation function allows to provide a maximum and a
> minimum number of interrupts to be allocated and tries to allocate as
> many as possible. This worked without driver interaction as long as there
> was only a single set of interrupts to handle.
> 
> With the addition of support for multiple interrupt sets in the generic
> affinity spreading logic, which is invoked from the PCI interrupt
> allocation, the adaptive loop in the PCI interrupt allocation did not
> work for multiple interrupt sets. The reason is that depending on the
> total number of interrupts which the PCI allocation adaptive loop tries
> to allocate in each step, the number and the size of the interrupt sets
> need to be adapted as well. Due to the way the interrupt sets support was
> implemented there was no way for the PCI interrupt allocation code or the
> core affinity spreading mechanism to invoke a driver specific function
> for adapting the interrupt sets configuration.
> 
> As a consequence the driver had to implement another adaptive loop around
> the PCI interrupt allocation function and calling that with maximum and
> minimum interrupts set to the same value. This ensured that the
> allocation either succeeded or immediately failed without any attempt to
> adjust the number of interrupts in the PCI code.
> 
> The core code now allows drivers to provide a callback to recalculate the
> number and the size of interrupt sets during PCI interrupt allocation,
> which in turn allows the PCI interrupt allocation function to be called
> in the same way as with a single set of interrupts. The PCI code handles
> the adaptive loop and the interrupt affinity spreading mechanism invokes
> the driver callback to adapt the interrupt set configuration to the
> current loop value. This replaces the adaptive loop in the driver
> completely.
> 
> Implement the NVME specific callback which adjusts the interrupt sets
> configuration and remove the adaptive allocation loop.
> 
> [ tglx: Simplify the callback further and restore the dropped adjustment of
>   number of sets ]
> 
> Signed-off-by: Ming Lei 
> Signed-off-by: Thomas Gleixner 
> 
> ---
>  drivers/nvme/host/pci.c |  108 
> 
>  1 file changed, 28 insertions(+), 80 deletions(-)
> 
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -2041,41 +2041,32 @@ static int nvme_setup_host_mem(struct nv
>   return ret;
>  }
>  
> -/* irq_queues covers admin queue */
> -static void nvme_calc_io_queues(struct nvme_dev *dev, unsigned int 
> irq_queues)
> +/*
> + * nirqs is the number of interrupts available for write and read
> + * queues. The core already reserved an interrupt for the admin queue.
> + */
> +static void nvme_calc_irq_sets(struct irq_affinity *affd, unsigned int 
> nrirqs)
>  {
> - unsigned int this_w_queues = write_queues;
> -
> - WARN_ON(!irq_queues);
> -
> - /*
> -  * Setup read/write queue split, assign admin queue one independent
> -  * irq vector if irq_queues is > 1.
> -  */
> - if (irq_queues <= 2) {
> - dev->io_queues[HCTX_TYPE_DEFAULT] = 1;
> - dev->io_queues[HCTX_TYPE_READ] = 0;
> - return;
> - }
> + struct nvme_dev *dev = affd->priv;
> + unsigned int nr_read_queues;
>  
>   /*
> -  * If 'write_queues' is set, ensure it leaves room for at least
> -  * one read queue and one admin queue
> -  */
> - if (this_w_queues >= irq_queues)
> - this_w_queues = irq_queues - 2;
> -
> - /*
> -  * If 'write_queues' is set to zero, reads and writes will share
> -  * a queue set.
> -  */
> - if (!this_w_queues) {
> - dev->io_queues[HCTX_TYPE_DEFAULT] = irq_queues - 1;
> - dev->io_queues[HCTX_TYPE_READ] = 0;
> - } else {
> - dev->io_queues[HCTX_TYPE_DEFAULT] = this_w_queues;
> - dev->io_queues[HCTX_TYPE_READ] = irq_queues - this_w_queues - 1;
> - }
> +  * If only one interrupt is available, combine write and read
> +  * queues. If 'write_queues' is set, ensure it leaves room for at
> +  * least one read queue.

[Full disclaimer: I only have had two coffees this morning, and it is
only at the fourth that my brain is able to kick in...]

I don't know much about NVME, but I feel like there is a small
disconnect between the code and the above comment, which says "leave
room for at least one read queue"...

> +  */
> +

Re: Linux 4.19.23

[Greg KH]

diff --git a/Makefile b/Makefile
index 8cfcb01fcd7b..3dcf3f2363c1 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 19
-SUBLEVEL = 22
+SUBLEVEL = 23
 EXTRAVERSION =
 NAME = "People's Front"
 
diff --git a/fs/binfmt_script.c b/fs/binfmt_script.c
index d0078cbb718b..7cde3f46ad26 100644
--- a/fs/binfmt_script.c
+++ b/fs/binfmt_script.c
@@ -42,14 +42,10 @@ static int load_script(struct linux_binprm *bprm)
fput(bprm->file);
bprm->file = NULL;
 
-   for (cp = bprm->buf+2;; cp++) {
-   if (cp >= bprm->buf + BINPRM_BUF_SIZE)
-   return -ENOEXEC;
-   if (!*cp || (*cp == '\n'))
-   break;
-   }
+   bprm->buf[BINPRM_BUF_SIZE - 1] = '\0';
+   if ((cp = strchr(bprm->buf, '\n')) == NULL)
+   cp = bprm->buf+BINPRM_BUF_SIZE-1;
*cp = '\0';
-
while (cp > bprm->buf) {
cp--;
if ((*cp == ' ') || (*cp == '\t'))

Re: Linux 4.20.9

[Greg KH]

diff --git a/Makefile b/Makefile
index d7d190781010..c9b831f5e873 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 20
-SUBLEVEL = 8
+SUBLEVEL = 9
 EXTRAVERSION =
 NAME = Shy Crocodile
 
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 47aa53ba6b92..559659b399d0 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -476,7 +476,7 @@
clocksource: timer@2 {
compatible = "ti,da830-timer";
reg = <0x2 0x1000>;
-   interrupts = <12>, <13>;
+   interrupts = <21>, <22>;
interrupt-names = "tint12", "tint34";
clocks = <&pll0_auxclk>;
};
diff --git a/arch/arm/mach-iop32x/n2100.c b/arch/arm/mach-iop32x/n2100.c
index 3b73813c6b04..23e8c93515d4 100644
--- a/arch/arm/mach-iop32x/n2100.c
+++ b/arch/arm/mach-iop32x/n2100.c
@@ -75,8 +75,7 @@ void __init n2100_map_io(void)
 /*
  * N2100 PCI.
  */
-static int __init
-n2100_pci_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+static int n2100_pci_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
int irq;
 
diff --git a/arch/arm/mach-tango/pm.c b/arch/arm/mach-tango/pm.c
index 028e50c6383f..a32c3b631484 100644
--- a/arch/arm/mach-tango/pm.c
+++ b/arch/arm/mach-tango/pm.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include "smc.h"
+#include "pm.h"
 
 static int tango_pm_powerdown(unsigned long arg)
 {
@@ -24,10 +25,7 @@ static const struct platform_suspend_ops tango_pm_ops = {
.valid = suspend_valid_only_mem,
 };
 
-static int __init tango_pm_init(void)
+void __init tango_pm_init(void)
 {
suspend_set_ops(&tango_pm_ops);
-   return 0;
 }
-
-late_initcall(tango_pm_init);
diff --git a/arch/arm/mach-tango/pm.h b/arch/arm/mach-tango/pm.h
new file mode 100644
index ..35ea705a0ee2
--- /dev/null
+++ b/arch/arm/mach-tango/pm.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifdef CONFIG_SUSPEND
+void __init tango_pm_init(void);
+#else
+#define tango_pm_init NULL
+#endif
diff --git a/arch/arm/mach-tango/setup.c b/arch/arm/mach-tango/setup.c
index 677dd7b5efd9..824f90737b04 100644
--- a/arch/arm/mach-tango/setup.c
+++ b/arch/arm/mach-tango/setup.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include "smc.h"
+#include "pm.h"
 
 static void tango_l2c_write(unsigned long val, unsigned int reg)
 {
@@ -15,4 +16,5 @@ DT_MACHINE_START(TANGO_DT, "Sigma Tango DT")
.dt_compat  = tango_dt_compat,
.l2c_aux_mask   = ~0,
.l2c_write_sec  = tango_l2c_write,
+   .init_late  = tango_pm_init,
 MACHINE_END
diff --git a/arch/mips/boot/dts/xilfpga/nexys4ddr.dts 
b/arch/mips/boot/dts/xilfpga/nexys4ddr.dts
index 2152b7ba65fb..cc8dbea0911f 100644
--- a/arch/mips/boot/dts/xilfpga/nexys4ddr.dts
+++ b/arch/mips/boot/dts/xilfpga/nexys4ddr.dts
@@ -90,11 +90,11 @@
interrupts = <0>;
};
 
-   axi_i2c: i2c@10A0 {
+   axi_i2c: i2c@10a0 {
compatible = "xlnx,xps-iic-2.00.a";
interrupt-parent = <&axi_intc>;
interrupts = <4>;
-   reg = < 0x10A0 0x1 >;
+   reg = < 0x10a0 0x1 >;
clocks = <&ext>;
xlnx,clk-freq = <0x5f5e100>;
xlnx,family = "Artix7";
@@ -106,9 +106,9 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   ad7420@4B {
+   ad7420@4b {
compatible = "adi,adt7420";
-   reg = <0x4B>;
+   reg = <0x4b>;
};
} ;
 };
diff --git a/arch/mips/kernel/mips-cm.c b/arch/mips/kernel/mips-cm.c
index 8f5bd04f320a..7f3f136572de 100644
--- a/arch/mips/kernel/mips-cm.c
+++ b/arch/mips/kernel/mips-cm.c
@@ -457,5 +457,5 @@ void mips_cm_error_report(void)
}
 
/* reprime cause register */
-   write_gcr_error_cause(0);
+   write_gcr_error_cause(cm_error);
 }
diff --git a/arch/mips/loongson64/common/reset.c 
b/arch/mips/loongson64/common/reset.c
index a60715e11306..b26892ce871c 100644
--- a/arch/mips/loongson64/common/reset.c
+++ b/arch/mips/loongson64/common/reset.c
@@ -59,7 +59,12 @@ static void loongson_poweroff(void)
 {
 #ifndef CONFIG_LEFI_FIRMWARE_INTERFACE
mach_prepare_shutdown();
-   unreachable();
+
+   /*
+* It needs a wait loop here, but mips/kernel/reset.c already calls
+* a generic delay loop, machine_hang(), so simply return.
+*/
+   return;
 #else
void (*fw_poweroff)(void) = (void *)loongson_sysconf.poweroff_addr;
 
diff --git a/arch/mips/pci/pci-octeon.c b/arch/mips/pci/pci-octeon.c
index 5017d5843c5a..fc29b85cfa92 100644
--- a/arch/mips/pci/pci-octeon.c
+++ b/arch/mips/pci/pci-octeon.c
@@ -568,6 +568,11 @@ static int __init octeon_pci_setup(void)
if (octeon_has_feature(OCTEON_FEATURE_PCIE))
return 0;
 
+   if (!octe

Re: [PATCH 4/4] arm64: dts: rockchip: rockpro64 dts add usb regulator

[Heiko Stübner]

Am Mittwoch, 13. Februar 2019, 18:06:40 CET schrieb Akash Gajjar:
> vcc5v0_host and vcc5v0_typec is supplied by vcc5v0_usb and not vcc5v0_sys.
> add node for vcc5v0_usb fixed regulator.
> 
> Signed-off-by: Akash Gajjar 

applied for (hopefully) 5.1

Thanks
Heiko

Re: Linux 4.20.10

[Greg KH]

diff --git a/Makefile b/Makefile
index c9b831f5e873..6f7a8172de44 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 20
-SUBLEVEL = 9
+SUBLEVEL = 10
 EXTRAVERSION =
 NAME = Shy Crocodile
 
diff --git a/fs/binfmt_script.c b/fs/binfmt_script.c
index d0078cbb718b..7cde3f46ad26 100644
--- a/fs/binfmt_script.c
+++ b/fs/binfmt_script.c
@@ -42,14 +42,10 @@ static int load_script(struct linux_binprm *bprm)
fput(bprm->file);
bprm->file = NULL;
 
-   for (cp = bprm->buf+2;; cp++) {
-   if (cp >= bprm->buf + BINPRM_BUF_SIZE)
-   return -ENOEXEC;
-   if (!*cp || (*cp == '\n'))
-   break;
-   }
+   bprm->buf[BINPRM_BUF_SIZE - 1] = '\0';
+   if ((cp = strchr(bprm->buf, '\n')) == NULL)
+   cp = bprm->buf+BINPRM_BUF_SIZE-1;
*cp = '\0';
-
while (cp > bprm->buf) {
cp--;
if ((*cp == ' ') || (*cp == '\t'))

[tip:perf/core] perf cs-etm: Add proper header file for symbols

[tip-bot for Mathieu Poirier]

Commit-ID:  859dcf64389c93a647f230a7cfd206d30bc9d286
Gitweb: https://git.kernel.org/tip/859dcf64389c93a647f230a7cfd206d30bc9d286
Author: Mathieu Poirier 
AuthorDate: Fri, 8 Feb 2019 15:35:43 -0700
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 14 Feb 2019 13:30:52 -0300

perf cs-etm: Add proper header file for symbols

After 'commit e22c1c751140 ("perf thread: Don't include symbol.h,
symbol_conf.h is enough")'

Compilation of the perf tools is broken when using the functionality
provided by the openCSD library:

[...]

...   timerfd: [ on  ]
...  sched_getcpu: [ on  ]
...   sdt: [ OFF ]
... setns: [ on  ]
...libopencsd: [ on  ]

[...]

  CC   util/arm-spe.o
  CC   util/arm-spe-pkt-decoder.o
  CC   util/s390-cpumsf.o
  CC   util/cs-etm.o
  CC   util/parse-branch-options.o
util/cs-etm.c: In function ‘cs_etm__mem_access’:
util/cs-etm.c:297:24: error: storage size of ‘al’ isn’t known
  struct  addr_location al;

And rightly so since file cs-etm.c doesn't include symbol.h, something
that is rectified in this patch.

Signed-off-by: Mathieu Poirier 
Cc: Jiri Olsa 
Cc: Peter Zijlstra 
Cc: Suzuki K Poulouse 
Cc: linux-arm-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/20190208223543.31836-1-mathieu.poir...@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/cs-etm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 8b3f882d6e2f..0b11d653cfbe 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -25,6 +25,7 @@
 #include "machine.h"
 #include "map.h"
 #include "perf.h"
+#include "symbol.h"
 #include "thread.h"
 #include "thread_map.h"
 #include "thread-stack.h"

Re: [PATCH 0/2] extcon: Intel Cherry Trail Whiskey Cove PMIC and external charger tweaks

[Hans de Goede]

Hi,

On 15-02-19 08:01, Yauhen Kharuzhy wrote:

On Thu, Feb 14, 2019 at 04:05:26PM +0100, Hans de Goede wrote:





I would do something similar with the fuel-gauge in
drivers/platform/x86/intel_cht_int33fe.c, one option would
be to simply count the number of resources in the ACPI
resource table for the INT33FE device, versions with
the Type-C port have 7 resources, where as your INT33FE
device has only 3.

I'm even thinking that it might be best to rename
intel_cht_int33fe.c to intel_cht_int33fe_typec.c and add
a check for the resource table having 7 entries there, then
you can make a intel_cht_int33fe_micro_usb.c copy and strip
that mostly empty. Both would bind to the same "INT33FE"
id and they would both silently bail with -ENODEV if the
resource-count (or the PTYP value) don't match.

The reason I'm thinking of having 2 drivers is because
the current intel_cht_int33fe.c is quite special / ugly and
already has enough ifs.

If you do a stand-alone intel_cht_int33fe_micro_usb.c that can
hopefully be much simpler.

Andy what is your take on having separate intel_cht_int33fe_typec.c
and intel_cht_int33fe_micro_usb.c drivers, both binding to
the "INT33FE" ACPI-ID (with its totally !@#%$#-ed up "API") ?

Having 2 drivers bind to the same id and exit silently with -ENODEV
is somewhat normal for USB ids where we also sometimes have these
kinda ID clashes with different devices hiding behind the same id.


Hmm... And we need to handle case when all three INT33FE devices are
enabled in the DSDT...


I would not worry about that, I've never seen that and even then
counting the resources + the PTYP check should catch this.


Instead of separating of driver to two (and more when we will find new
CHT device...) I think about some kind of configuration variants table
with selection by PTYP/resource count/etc. But typeC devices will
require to define interconnections for example and we will get yet
another hardly readable code with quirks, autodetection magic and big
constant tables...


Right, the issue is the code for the variant with the Type-C connector
is just quite ugly, also with the cht_int33fe_check_for_max17047 firmware
bug workaround, I would prefer to keep that isolated to a single
file for just the devices which need all these kludges.

The version for your device should be much cleaner and if we need
another variant we can maybe make your version be a generic version
for this with some config table, but adding more special casing to
the current code is not a good idea IMHO.


OK, I plan to start to make some experiments with this at weekend.


Sounds good.

Regards,

Hans

Re: [PATCH v3 2/9] s390: ap: kvm: setting a hook for PQAP instructions

[Cornelia Huck]

On Thu, 14 Feb 2019 17:45:06 +0100
Pierre Morel  wrote:

> On 14/02/2019 16:54, Cornelia Huck wrote:
> > On Thu, 14 Feb 2019 14:51:02 +0100
> > Pierre Morel  wrote:
> >   
> >> This patch adds interception code for the PQAP instructions,
> >> and a callback inside the KVM arch structure for s390.
> >>
> >> If a VFIO-AP drivers needs to intercept PQAP/AQIC or PQAP/TAPQ  
> > 
> > s/drivers/driver/  
> 
> thanks. OK
> 

> >> + *
> >> + * This callback only handles PQAP/AQIC instruction and  
> > 
> > Here you only talk about PQAP/AQIC, what about PQAP/TAPQ mentioned in
> > the patch description?  
> 
> I can add "for now" or "in this patch" or suppress the reference to 
> PAPQ/TAPQ

I'd just add a note to the patch description that this patch only
handles PQAP/AQCI and that handling PQAP/TAPQ is something for a
follow-on patch.

> 
> >   
> >> + * calls a dedicated callback for this instruction if
> >> + * a driver did register one in the CRYPTO satellite of the
> >> + * SIE block.
> >> + *
> >> + * Do not change the behavior if, return -EOPNOTSUPP if:
> >> + * - the hook is not used do not change the behavior.  
> > 
> > The hook is not used? Or not set?  
> 
> I think "is not set" is better.

Ok.

> 
> > (I don't think you need to repeat "do
> > not change the behavior".)  
> 
> OK
> 
> >   
> >> + * - AP instructions are not available or not available to the guest
> >> + * - the instruction is not PQAP with function code indicating
> >> + *   AQIC do not change the previous behavior.
> >> + *
> >> + * For PQAP/AQIC instruction, verify privilege and specifications
> >> + *
> >> + * return the value returned by the callback.
> >> + */
> >> +static int handle_pqap(struct kvm_vcpu *vcpu)
> >> +{
> >> +  uint8_t fc;
> >> +
> >> +  /* Verify that the hook callback is registered */
> >> +  if (!vcpu->kvm->arch.crypto.pqap_hook)
> >> +  return -EOPNOTSUPP;
> >> +  /* Verify that the AP instruction are available */
> >> +  if (!ap_instructions_available())
> >> +  return -EOPNOTSUPP;
> >> +  /* Verify that the guest is allowed to use AP instructions */
> >> +  if (!(vcpu->arch.sie_block->eca & ECA_APIE))
> >> +  return -EOPNOTSUPP;
> >> +  /* Verify that the function code is AQIC */
> >> +  fc = vcpu->run->s.regs.gprs[0] >> 24;
> >> +  if (fc != 0x03)
> >> +  return -EOPNOTSUPP;
> >> +
> >> +  /* PQAP instructions are allowed for guest kernel only */
> >> +  if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE)
> >> +  return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP);
> >> +  /* AQIC instruction is allowed only if facility 65 is available */
> >> +  if (!test_kvm_facility(vcpu->kvm, 65))
> >> +  return kvm_s390_inject_program_int(vcpu, PGM_SPECIFICATION);
> >> +  /* All right, call the callback */
> >> +  return vcpu->kvm->arch.crypto.pqap_hook(vcpu);  
> > 
> > Can that callback also return -EOPNOTSUPP to order to drop to user
> > space?  
> 
> Yes.
> Why not?

Maybe also mention that in the function description?

[tip:perf/core] perf report: Add s390 diagnosic sampling descriptor size

[tip-bot for Thomas Richter]

Commit-ID:  2187d87eacd46f6214ce3dc9cfd7a558375a4153
Gitweb: https://git.kernel.org/tip/2187d87eacd46f6214ce3dc9cfd7a558375a4153
Author: Thomas Richter 
AuthorDate: Mon, 11 Feb 2019 11:06:27 +0100
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 14 Feb 2019 13:31:08 -0300

perf report: Add s390 diagnosic sampling descriptor size

On IBM z13 machine types 2964 and 2965 the descriptor
sizes for sampling and diagnostic sampling entries
might be missing in the trailer entry and are set to zero.

This leads to a perf report failure when processing diagnostic
sampling entries.

This patch adds missing descriptor sizes when the trailer entry
contains zero for these fields.

Output before:
  [root@s38lp82 perf]#  ./perf report --stdio | fgrep Samples
  0xabbf0 [0x8]: failed to process type: 68
  Error:
  failed to process sample
  [root@s38lp82 perf]#

Output after:
  [root@s38lp82 perf]#  ./perf report --stdio | fgrep Samples
  # Total Lost Samples: 0
  # Samples: 3K of event 'SF_CYCLES_BASIC_DIAG'
  # Samples: 162  of event 'CF_DIAG'
  [root@s38lp82 perf]#

Fixes: 2b1444f2e28b ("perf report: Add raw report support for s390 auxiliary 
trace")

Signed-off-by: Thomas Richter 
Reviewed-by: Hendrik Brueckner 
Cc: Heiko Carstens 
Cc: Martin Schwidefsky 
Link: http://lkml.kernel.org/r/20190211100627.85714-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/s390-cpumsf.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tools/perf/util/s390-cpumsf.c b/tools/perf/util/s390-cpumsf.c
index d9525d220db1..c215704931dc 100644
--- a/tools/perf/util/s390-cpumsf.c
+++ b/tools/perf/util/s390-cpumsf.c
@@ -352,6 +352,11 @@ static bool s390_cpumsf_validate(int machine_type,
*dsdes = 85;
*bsdes = 32;
break;
+   case 2964:
+   case 2965:
+   *dsdes = 112;
+   *bsdes = 32;
+   break;
default:
/* Illegal trailer entry */
return false;

[tip:perf/core] perf vendor events power8: Cpi_breakdown & estimated_dcache_miss_cpi metrics

[tip-bot for Paul Clarke]

Commit-ID:  dd81eafacc52961ed1b2bf3e998b92ccfd9108bc
Gitweb: https://git.kernel.org/tip/dd81eafacc52961ed1b2bf3e998b92ccfd9108bc
Author: Paul Clarke 
AuthorDate: Thu, 7 Feb 2019 12:53:11 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 14 Feb 2019 13:31:08 -0300

perf vendor events power8: Cpi_breakdown & estimated_dcache_miss_cpi metrics

POWER8 metrics are not well publicized.

Some are here:

  
https://www.ibm.com/support/knowledgecenter/en/SSFK5S_2.2.0/com.ibm.cluster.pedev.v2r2.pedev100.doc/bl7ug_derivedmetricspower8.htm

This patch is for metric groups:
- cpi_breakdown
- estimated_dcache_miss_cpi

Signed-off-by: Paul Clarke 
Cc: Ananth N Mavinakayanahalli 
Cc: Carl Love 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Naveen N. Rao 
Cc: Sukadev Bhattiprolu 
Link: http://lkml.kernel.org/r/20190207175314.31813-2...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../pmu-events/arch/powerpc/power8/metrics.json| 461 +
 1 file changed, 461 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
new file mode 100644
index ..377b76226c08
--- /dev/null
+++ b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
@@ -0,0 +1,461 @@
+[
+{
+"BriefDescription": "Cycles stalled due to CRU or BRU operations",
+"MetricExpr": "PM_CMPLU_STALL_BRU_CRU / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "bru_cru_stall_cpi"
+},
+{
+"BriefDescription": "Cycles stalled due to ISU Branch Operations",
+"MetricExpr": "PM_CMPLU_STALL_BRU / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "bru_stall_cpi"
+},
+{
+"BriefDescription": "Cycles in which a Group Completed",
+"MetricExpr": "PM_GRP_CMPL / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "completion_cpi"
+},
+{
+"BriefDescription": "Cycles stalled by CO queue full",
+"MetricExpr": "PM_CMPLU_STALL_COQ_FULL / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "coq_full_stall_cpi"
+},
+{
+"BriefDescription": "Cycles stalled due to CRU Operations",
+"MetricExpr": "(PM_CMPLU_STALL_BRU_CRU - PM_CMPLU_STALL_BRU) / 
PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "cru_stall_cpi"
+},
+{
+"BriefDescription": "Cycles stalled by flushes",
+"MetricExpr": "PM_CMPLU_STALL_FLUSH / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "flush_stall_cpi"
+},
+{
+"BriefDescription": "Cycles stalled by FXU Multi-Cycle Instructions",
+"MetricExpr": "PM_CMPLU_STALL_FXLONG / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "fxu_multi_cyc_cpi"
+},
+{
+"BriefDescription": "Cycles stalled by FXU",
+"MetricExpr": "PM_CMPLU_STALL_FXU / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "fxu_stall_cpi"
+},
+{
+"BriefDescription": "Other cycles stalled by FXU",
+"MetricExpr": "(PM_CMPLU_STALL_FXU / PM_RUN_INST_CMPL) - 
(PM_CMPLU_STALL_FXLONG / PM_RUN_INST_CMPL)",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "fxu_stall_other_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty due to Branch Mispredicts",
+"MetricExpr": "PM_GCT_NOSLOT_BR_MPRED / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_br_mpred_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty due to Branch Mispredicts and 
Icache Misses",
+"MetricExpr": "PM_GCT_NOSLOT_BR_MPRED_ICMISS / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_br_mpred_ic_miss_cpi"
+},
+{
+"BriefDescription": "GCT empty cycles",
+"MetricExpr": "PM_GCT_NOSLOT_CYC / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty where dispatch was held",
+"MetricExpr": "(PM_GCT_NOSLOT_DISP_HELD_MAP + 
PM_GCT_NOSLOT_DISP_HELD_SRQ + PM_GCT_NOSLOT_DISP_HELD_ISSQ + 
PM_GCT_NOSLOT_DISP_HELD_OTHER) / PM_RUN_INST_CMPL)",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_disp_held_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty where dispatch was held due to 
issue queue",
+"MetricExpr": "PM_GCT_NOSLOT_DISP_HELD_ISSQ / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_breakdown",
+"MetricName": "gct_empty_disp_held_issq_cpi"
+},
+{
+"BriefDescription": "Cycles GCT empty where dispatch was held due to 
maps",
+"MetricExpr": "PM_GCT_NOSLOT_DISP_HELD_MAP / PM_RUN_INST_CMPL",
+"MetricGroup": "cpi_br

Re: [PATCH] nvmem: core: fix the return value check when calling the notifier chain

[Srinivas Kandagatla]

On 14/02/2019 16:23, Bartosz Golaszewski wrote:

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index f7301bb4ef3b..a3bed2d9aec7 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -687,7 +687,7 @@ struct nvmem_device *nvmem_register(const struct 
nvmem_config *config)
goto err_remove_cells;
  
  	rval = blocking_notifier_call_chain(&nvmem_notifier, NVMEM_ADD, nvmem);

-   if (rval)
+   if (rval < 0)
goto err_remove_cells;


rval will be masked with STOP MASK, so the above statement could be 
false even if we have error.

So you should consider returning an errono which can be understood by user:

may be something like this:

if (rval & NOTIFY_STOP_MASK) {
rval = notifier_to_errno(rval);
goto err_remove_cells
}


--srini

[tip:perf/core] perf vendor events power8: Dl1_reload, instruction_misses, l2_stats, lsu_rejects, memory & pteg_reloads metrics

[tip-bot for Paul Clarke]

Commit-ID:  ffe18505ba1d641a4935321d3c525e4e2efd64c3
Gitweb: https://git.kernel.org/tip/ffe18505ba1d641a4935321d3c525e4e2efd64c3
Author: Paul Clarke 
AuthorDate: Thu, 7 Feb 2019 12:53:12 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 14 Feb 2019 13:31:09 -0300

perf vendor events power8: Dl1_reload, instruction_misses, l2_stats, 
lsu_rejects, memory & pteg_reloads metrics

POWER8 metrics are not well publicized.

Some are here:

  
https://www.ibm.com/support/knowledgecenter/en/SSFK5S_2.2.0/com.ibm.cluster.pedev.v2r2.pedev100.doc/bl7ug_derivedmetricspower8.htm

This patch is for metric groups:
- dl1_reloads_percent_per_inst
- dl1_reloads_percent_per_ref
- instruction_misses_percent_per_inst
- l2_stats
- lsu_rejects
- memory
- pteg_reloads_percent_per_inst
- pteg_reloads_percent_per_ref

Signed-off-by: Paul Clarke 
Cc: Ananth N Mavinakayanahalli 
Cc: Carl Love 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Naveen N. Rao 
Cc: Sukadev Bhattiprolu 
Link: http://lkml.kernel.org/r/20190207175314.31813-3...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../pmu-events/arch/powerpc/power8/metrics.json| 702 +
 1 file changed, 702 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
index 377b76226c08..9a6ec8aadffd 100644
--- a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
@@ -356,6 +356,288 @@
 "MetricGroup": "cpi_breakdown",
 "MetricName": "vsu_stall_vector_other_cpi"
 },
+{
+"BriefDescription": "% of DL1 Reloads from Distant L2 or L3 (Modified) 
per Inst",
+"MetricExpr": "PM_DATA_FROM_DL2L3_MOD * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dl2l3_mod_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Distant L2 or L3 (Shared) 
per Inst",
+"MetricExpr": "PM_DATA_FROM_DL2L3_SHR * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dl2l3_shr_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Distant L4 per Inst",
+"MetricExpr": "PM_DATA_FROM_DL4 * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dl4_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 Reloads from Distant Memory per Inst",
+"MetricExpr": "PM_DATA_FROM_DMEM * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_dmem_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L2, other core per 
Inst",
+"MetricExpr": "PM_DATA_FROM_L21_MOD * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l21_mod_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from Private L2, other core per 
Inst",
+"MetricExpr": "PM_DATA_FROM_L21_SHR * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l21_shr_rate_percent"
+},
+{
+"BriefDescription": "Percentage of L2 load hits per instruction where 
the L2 experienced a Load-Hit-Store conflict",
+"MetricExpr": "PM_DATA_FROM_L2_DISP_CONFLICT_LDHITST * 100 / 
PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_lhs_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from L2 per Inst",
+"MetricExpr": "PM_DATA_FROM_L2MISS * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_miss_rate_percent"
+},
+{
+"BriefDescription": "Percentage of L2 load hits per instruction where 
the L2 did not experience a conflict",
+"MetricExpr": "PM_DATA_FROM_L2_NO_CONFLICT * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_no_conflict_rate_percent"
+},
+{
+"BriefDescription": "Percentage of L2 load hits per instruction where 
the L2 experienced some conflict other than Load-Hit-Store",
+"MetricExpr": "PM_DATA_FROM_L2_DISP_CONFLICT_OTHER * 100 / 
PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_other_conflict_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloads from L2 per Inst",
+"MetricExpr": "PM_DATA_FROM_L2 * 100 / PM_RUN_INST_CMPL",
+"MetricGroup": "dl1_reloads_percent_per_inst",
+"MetricName": "dl1_reload_from_l2_rate_percent"
+},
+{
+"BriefDescription": "% of DL1 reloa

Re: [PATCH v2 2/2] cpufreq / cppc: Work around for Hisilicon CPPC cpufreq

[Rafael J. Wysocki]

On Fri, Feb 15, 2019 at 2:25 AM Xiongfeng Wang
 wrote:
>
>
>
> On 2019/2/15 7:15, Rafael J. Wysocki wrote:
> > On Thursday, February 14, 2019 2:58:21 PM CET Xiongfeng Wang wrote:
> >>
> >> On 2019/2/14 18:58, Rafael J. Wysocki wrote:
> >>> On Thu, Feb 14, 2019 at 8:46 AM Xiongfeng Wang
> >>>  wrote:
> 
>  Hisilicon chips do not support delivered performance counter register
>  and reference performance counter register. But the platform can
>  calculate the real performance using its own method. This patch provide
>  a workaround for this problem, and other platforms can also use this
>  workaround framework. We reuse the desired performance register to
>  store the real performance calculated by the platform. After the
>  platform finished the frequency adjust, it gets the real performance and
>  writes it into desired performance register. OS can use it to calculate
>  the real frequency.
> 
>  Signed-off-by: Xiongfeng Wang 
>  ---
>   drivers/cpufreq/cppc_cpufreq.c | 70 
>  ++
>   1 file changed, 70 insertions(+)
> 
>  diff --git a/drivers/cpufreq/cppc_cpufreq.c 
>  b/drivers/cpufreq/cppc_cpufreq.c
>  index fd25c21c..da96fec 100644
>  --- a/drivers/cpufreq/cppc_cpufreq.c
>  +++ b/drivers/cpufreq/cppc_cpufreq.c
>  @@ -33,6 +33,16 @@
>   /* Offest in the DMI processor structure for the max frequency */
>   #define DMI_PROCESSOR_MAX_SPEED  0x14
> 
>  +struct cppc_workaround_info {
>  +   char oem_id[ACPI_OEM_ID_SIZE +1];
>  +   char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
>  +   u32 oem_revision;
>  +   unsigned int (*get_rate)(unsigned int cpu);
>  +};
>  +
>  +/* CPPC workaround for get_rate callback */
>  +unsigned int (*cppc_wa_get_rate)(unsigned int cpu);
>  +
> >>>
> >>> First off, please don't split the workaround material into two parts.
> >>> IOW, the other new function added below can go here just fine IMO.
> >>>
>   /*
>    * These structs contain information parsed from per CPU
>    * ACPI _CPC structures.
>  @@ -334,6 +344,9 @@ static unsigned int cppc_cpufreq_get_rate(unsigned 
>  int cpunum)
>  struct cppc_cpudata *cpu = all_cpu_data[cpunum];
>  int ret;
> 
>  +   if (cppc_wa_get_rate)
>  +   return cppc_wa_get_rate(cpunum);
> >>>
> >>> Second, what is the value of using the function pointer above?
> >>>
> >>> All we need for now is a flag to indicate whether or not to call
> >>> hisi_cppc_cpufreq_get_rate() here and return its return value.
> >>
> >> How about adding a pointer of 'struct cppc_workaround_info' to indicate 
> >> whether we have
> >> found a matches workaround ?
> >> If I use a flag, I will need another variable to indicate which item of 
> >> the workaround array 'wa_info'
> >> to use.
> >
> > And why do you need to distinguish one of them from the other?
> >
>
> I was thinking about future extension. Different platform may have different 
> implementation
> of 'get_rate' in the future.

That's right, but whoever adds this in the future may change the
driver accordingly.  They will have to make changes to it anyway.

[tip:perf/core] perf vendor events power8: Branch_prediction, latency, bus_stats, instruction_mix & instruction_stats metrics

[tip-bot for Paul Clarke]

Commit-ID:  69ba708f4df6250dfa0410297024eeedd7ab3362
Gitweb: https://git.kernel.org/tip/69ba708f4df6250dfa0410297024eeedd7ab3362
Author: Paul Clarke 
AuthorDate: Thu, 7 Feb 2019 12:53:13 -0500
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Thu, 14 Feb 2019 13:31:09 -0300

perf vendor events power8: Branch_prediction, latency, bus_stats, 
instruction_mix & instruction_stats metrics

POWER8 metrics are not well publicized.  Some are here:

  
https://www.ibm.com/support/knowledgecenter/en/SSFK5S_2.2.0/com.ibm.cluster.pedev.v2r2.pedev100.doc/bl7ug_derivedmetricspower8.htm

This patch is for metric groups:
- branch_prediction
- latency
- bus_stats
- instruction_mix
- instruction_stats_percent_per_ref

Signed-off-by: Paul Clarke 
Cc: Ananth N Mavinakayanahalli 
Cc: Carl Love 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Naveen N. Rao 
Cc: Sukadev Bhattiprolu 
Link: http://lkml.kernel.org/r/20190207175314.31813-4...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../pmu-events/arch/powerpc/power8/metrics.json| 492 +
 1 file changed, 492 insertions(+)

diff --git a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json 
b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
index 9a6ec8aadffd..d8b710e12377 100644
--- a/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
+++ b/tools/perf/pmu-events/arch/powerpc/power8/metrics.json
@@ -1,4 +1,100 @@
 [
+{
+"BriefDescription": "% of finished branches that were treated as BC+8",
+"MetricExpr": "PM_BR_BC_8_CONV / PM_BRU_FIN * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "bc_8_branch_ratio_percent"
+},
+{
+"BriefDescription": "% of finished branches that were pairable but not 
treated as BC+8",
+"MetricExpr": "PM_BR_BC_8 / PM_BRU_FIN * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "bc_8_not_converted_branch_ratio_percent"
+},
+{
+"BriefDescription": "Percent of mispredicted branches out of all 
predicted (correctly and incorrectly) branches that completed",
+"MetricExpr": "PM_BR_MPRED_CMPL / (PM_BR_PRED_BR0 + PM_BR_PRED_BR1) * 
100",
+"MetricGroup": "branch_prediction",
+"MetricName": "br_misprediction_percent"
+},
+{
+"BriefDescription": "% of Branch miss predictions per instruction",
+"MetricExpr": "PM_BR_MPRED_CMPL / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "branch_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Count cache branch misprediction per instruction",
+"MetricExpr": "PM_BR_MPRED_CCACHE / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ccache_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Percent of count catch mispredictions out of all 
completed branches that required count cache predictionn",
+"MetricExpr": "PM_BR_MPRED_CCACHE / (PM_BR_PRED_CCACHE_BR0 + 
PM_BR_PRED_CCACHE_BR1) * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ccache_misprediction_percent"
+},
+{
+"BriefDescription": "CR MisPredictions per Instruction",
+"MetricExpr": "PM_BR_MPRED_CR / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "cr_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Link stack branch misprediction",
+"MetricExpr": "(PM_BR_MPRED_TA - PM_BR_MPRED_CCACHE) / 
PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "lstack_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Percent of link stack mispredictions out of all 
completed branches that required link stack prediction",
+"MetricExpr": "(PM_BR_MPRED_TA - PM_BR_MPRED_CCACHE) / 
(PM_BR_PRED_LSTACK_BR0 + PM_BR_PRED_LSTACK_BR1) * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "lstack_misprediction_percent"
+},
+{
+"BriefDescription": "TA MisPredictions per Instruction",
+"MetricExpr": "PM_BR_MPRED_TA / PM_RUN_INST_CMPL * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ta_mispredict_rate_percent"
+},
+{
+"BriefDescription": "Percent of target address mispredictions out of 
all completed branches that required address prediction",
+"MetricExpr": "PM_BR_MPRED_TA / (PM_BR_PRED_CCACHE_BR0 + 
PM_BR_PRED_CCACHE_BR1 + PM_BR_PRED_LSTACK_BR0 + PM_BR_PRED_LSTACK_BR1) * 100",
+"MetricGroup": "branch_prediction",
+"MetricName": "ta_misprediction_percent"
+},
+{
+"BriefDescription": "Percent of branches completed that were taken",
+"MetricExpr": "PM_BR_TAKEN_CMPL * 100 / PM_BR_CMPL",
+"MetricGroup": "branch_prediction",
+"MetricName": "taken_branches_percent"
+},
+{
+"BriefDescription": "Percent of chip+gro

[PATCH] staging: r8822be: check kzalloc return or bail

[Nicholas Mc Guire]

The kzalloc() in halmac_parse_psd_data_88xx() can fail and return NULL
so check the psd_set->data after allocation and if allocation failed
return HALMAC_CMD_PROCESS_ERROR.

Signed-off-by: Nicholas Mc Guire 
Fixes: 938a0447f094 ("staging: r8822be: Add code for halmac sub-drive")
---

Problem was located with an experimental coccinelle script

Patch was compile tested with: x86_64_defconfig + STAGING=y,
R8822BE=m
(with a smatch error that looks like a false-positive

  CHECK   drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c:624 
halmac_func_write_logical_efuse_88xx() error: uninitialized symbol 
'pg_efuse_header2'.
  CC [M]  drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.o

as the initialization of pg_efuse_header2 is under the same if condition (line 
592) as the
use at line 624 it is initialized)

Patch is agaisnt 5.0-rc6 (localversion-next is next-20190215)

 drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c 
b/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
index 53f55f12..bf783a0 100644
--- a/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
+++ b/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
@@ -2466,8 +2466,11 @@ halmac_parse_psd_data_88xx(struct halmac_adapter 
*halmac_adapter, u8 *c2h_buf,
segment_size = (u8)PSD_DATA_GET_SEGMENT_SIZE(c2h_buf);
psd_set->data_size = total_size;
 
-   if (!psd_set->data)
+   if (!psd_set->data) {
psd_set->data = kzalloc(psd_set->data_size, GFP_KERNEL);
+   if (!psd_set->data)
+   return HALMAC_CMD_PROCESS_ERROR;
+   }
 
if (segment_id == 0)
psd_set->segment_size = segment_size;
-- 
2.1.4

Re: [PATCH] x86/boot: Move detecting acpi=off in cmdline to get_rsdp_addr()

[Borislav Petkov]

On Fri, Feb 15, 2019 at 05:10:47PM +0800, Chao Fan wrote:
> If "acpi=off" specified in cmdline, the whole functions of acpi.c
> should not work, there is no need to ealy parse RSDP, so detect
> "acpi=off" in the very first place.
> 
> Also replace magic number with macro.
> 
> Signed-off-by: Chao Fan 
> ---
>  arch/x86/boot/compressed/acpi.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
> index 0ef4ad55b29b..5510a2105b7b 100644
> --- a/arch/x86/boot/compressed/acpi.c
> +++ b/arch/x86/boot/compressed/acpi.c
> @@ -213,8 +213,13 @@ static acpi_physical_address bios_get_rsdp_addr(void)
>  /* Return RSDP address on success, otherwise 0. */
>  acpi_physical_address get_rsdp_addr(void)
>  {
> + char arg[MAX_ACPI_ARG_LENGTH];
>   acpi_physical_address pa;
>  
> + if (cmdline_find_option("acpi", arg, sizeof(arg)) == 3 &&
> + !strncmp(arg, "off", 3))
> + return 0;

This place looks wrong because we have a get_acpi_rsdp() call before
that which overrides acpi=off practically.

Also, if you move it to get_rsdp_addr(), add a static variable recording
the previous result of the cmdline parsing because I don't want it
parsing cmdline each time it is called.

Thx.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH 0/2] extcon: Intel Cherry Trail Whiskey Cove PMIC and external charger tweaks

[Andy Shevchenko]

On Fri, Feb 15, 2019 at 10:31 AM Hans de Goede  wrote:
> On 14-02-19 15:15, Yauhen Kharuzhy wrote:

> I would do something similar with the fuel-gauge in
> drivers/platform/x86/intel_cht_int33fe.c, one option would
> be to simply count the number of resources in the ACPI
> resource table for the INT33FE device, versions with
> the Type-C port have 7 resources, where as your INT33FE
> device has only 3.
>
> I'm even thinking that it might be best to rename
> intel_cht_int33fe.c to intel_cht_int33fe_typec.c and add
> a check for the resource table having 7 entries there, then
> you can make a intel_cht_int33fe_micro_usb.c copy and strip
> that mostly empty. Both would bind to the same "INT33FE"
> id and they would both silently bail with -ENODEV if the
> resource-count (or the PTYP value) don't match.
>
> The reason I'm thinking of having 2 drivers is because
> the current intel_cht_int33fe.c is quite special / ugly and
> already has enough ifs.
>
> If you do a stand-alone intel_cht_int33fe_micro_usb.c that can
> hopefully be much simpler.
>
> Andy what is your take on having separate intel_cht_int33fe_typec.c
> and intel_cht_int33fe_micro_usb.c drivers, both binding to
> the "INT33FE" ACPI-ID (with its totally !@#%$#-ed up "API") ?

Depends on how code would look better, though I care about users that
they will not get additional Kconfig option and broken their
configurations when new piece of code landed up. So, from mine, as
user, prospective, we may split driver as we wish, but we should get
it working as previously for the existing cases.

> Having 2 drivers bind to the same id and exit silently with -ENODEV
> is somewhat normal for USB ids where we also sometimes have these
> kinda ID clashes with different devices hiding behind the same id.

-- 
With Best Regards,
Andy Shevchenko

Re: mmotm 2019-02-14-15-22 uploaded (drivers/misc/fastrpc.c)

[Srinivas Kandagatla]

Thanks for Reporting this Randy,
I will send a patch to fix this!

On 15/02/2019 03:20, Randy Dunlap wrote:

On 2/14/19 3:23 PM, a...@linux-foundation.org wrote:

The mm-of-the-moment snapshot 2019-02-14-15-22 has been uploaded to

http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (5.x
or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series


on x86_64:

when CONFIG_DMA_SHARED_BUFFER is not set:

ld: drivers/misc/fastrpc.o: in function `fastrpc_free_map':
fastrpc.c:(.text+0xbe): undefined reference to `dma_buf_unmap_attachment'
ld: fastrpc.c:(.text+0xcb): undefined reference to `dma_buf_detach'
ld: fastrpc.c:(.text+0xd4): undefined reference to `dma_buf_put'
ld: drivers/misc/fastrpc.o: in function `fastrpc_map_create':
fastrpc.c:(.text+0xb2b): undefined reference to `dma_buf_get'
ld: fastrpc.c:(.text+0xb47): undefined reference to `dma_buf_attach'
ld: fastrpc.c:(.text+0xb61): undefined reference to `dma_buf_map_attachment'
ld: fastrpc.c:(.text+0xc36): undefined reference to `dma_buf_put'
ld: fastrpc.c:(.text+0xc48): undefined reference to `dma_buf_detach'
ld: drivers/misc/fastrpc.o: in function `fastrpc_device_ioctl':
fastrpc.c:(.text+0x1756): undefined reference to `dma_buf_get'
ld: fastrpc.c:(.text+0x1776): undefined reference to `dma_buf_put'
ld: fastrpc.c:(.text+0x1780): undefined reference to `dma_buf_put'
ld: fastrpc.c:(.text+0x1abf): undefined reference to `dma_buf_export'
ld: fastrpc.c:(.text+0x1ae7): undefined reference to `dma_buf_fd'
ld: fastrpc.c:(.text+0x1cb5): undefined reference to `dma_buf_put'
ld: fastrpc.c:(.text+0x1cca): undefined reference to `dma_buf_put'




--srini