Re: [kernel-hardening] Re: [PATCH] random: silence compiler warnings and fix race

[Michael Ellerman]

Theodore Ts'o  writes:

> On Mon, Jun 19, 2017 at 10:57:18PM +0200, Jason A. Donenfeld wrote:
>> 
>> With rc6 already released and rc7 coming up, I'd really appreciate you
>> stepping in here and either ACKing the above commit, or giving your
>> two cents about it in case I need to roll something different.
>
> I actually had set up an earlier version of your patch for on Saturday
> while I was in Beijing.  (Like Linus, I'm attending the LinuxCon China
> conference Monday and Tuesday.)  I had even created the signed tag,
> but I didn't send the pull request to Linus because I was waiting to
> see about how discussions over the locking strategy and the spammy log
> messages on PowerPC was going to get resolved.
>
> I've since respun the commit to reflect your newer patch (see the
> random_for_linus_stable tag on random.git) and rebased the dev branch
> on top of that.  Please take a look and comment.
>
> The other open issue I want to resolve before sending a pull request
> this week is whether we want to change the default for
> CONFIG_WARN_UNSEEDED_RANDOM so that the answer is 'n'.

Yes please.

> It *is* spammy for PowerPC, because they aren't getting their CRNG

*some* powerpc machines ...

> initialized quickly enough, so several userspace processes are getting
> fork/exec'ed with an uninitialized CRNG.  That being said, it is a
> valid warning because it means that the initial stack canary for the
> first couple of PowerPC processes are being created without a fully
> initialized CRNG, which may mean that an attacker might be able to
> circumvent the stack canary on the first couple of processes.  So that
> could potentially be a real security issue on Power.  OTOH, most Power
> users aren't going to be able to do anything about the fact the stack
> canaries of the system daemons started during early boot don't have
> strong randomness, so perhaps we should disable the warning by
> default.

powerpc supports a wide range of hardware platforms, some of which are
10-15 years old, and don't have a hardware RNG.

Is there anything we can do on those machines? Seems like our only
option would be to block the boot while some more "entropy" builds up,
but that's unlikely to be popular with users.

On our newer machines (>= Power8) we have a hardware RNG which we wire
up to arch_get_random_seed_long(), so on those machines the warnings
would be valid, because they'd indicate a bug.

So I think it should be up to arches to decide whether this is turned on
via their defconfigs, and the default should be 'n' because a lot of old
hardware won't be able to do anything useful with the warnings.

cheers

Re: [PATCH 2/4] pwm: mediatek: fix clk issue

[John Crispin]

On 20/06/17 08:54, Zhi Mao wrote:

1.fix clock control
  - prepare top/main clk in mtk_pwm_probe() function,
it will increase power consumption
and in original code these clocks is only prepeare but never enabled
  - pwm clock should be enabled before setting pwm registers
in function: mtk_pwm_config()

2.fix pwm source clock selection
  - in original code, the pwm output frequency is not correct
when set bit<3>=1 to PWMCON register.

Signed-off-by: Zhi Mao 


Hi Zhi,

it looks like you sent the series as text/html and also as text/plain 
with lines getting wrapped. You might want to try and use "git send-email"



---
  drivers/pwm/pwm-mediatek.c |   69
  +++-
  1 file changed, 43 insertions(+), 26 deletions(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 5c11bc7..c803ff6 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c

[ ... ]


@@ -61,6 +62,40 @@ static inline struct mtk_pwm_chip *to_mtk_pwm_chip(struct
  pwm_chip *chip)
return container_of(chip, struct mtk_pwm_chip, chip);
  }
  
+static int mtk_pwm_clk_enable(struct pwm_chip *chip, struct pwm_device

  *pwm)

^^ here for example

John


+{
+   struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
+   int ret = 0;
+
+   ret = clk_prepare_enable(pc->clks[MTK_CLK_TOP]);
+   if (ret < 0)
+   return ret;
+
+   ret = clk_prepare_enable(pc->clks[MTK_CLK_MAIN]);
+   if (ret < 0) {
+   clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+   if (ret < 0) {
+   clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
+   clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+   return ret;
+   }
+
+   return ret;
+}
+
+static void mtk_pwm_clk_disable(struct pwm_chip *chip, struct pwm_device
  *pwm)
+{
+   struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
+
+   clk_disable_unprepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+   clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
+   clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+}
+
  static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int
  num,
unsigned int offset)
  {
@@ -81,6 +116,8 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct
  pwm_device *pwm,
struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm];
u32 resolution, clkdiv = 0;
  
+	mtk_pwm_clk_enable(chip, pwm);

+
resolution = NSEC_PER_SEC / clk_get_rate(clk);
  
  	while (period_ns / resolution > 8191) {

@@ -91,10 +128,12 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct
  pwm_device *pwm,
if (clkdiv > 7)
return -EINVAL;
  
-	mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | BIT(3) | clkdiv);

+   mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv);
mtk_pwm_writel(pc, pwm->hwpwm, PWMDWIDTH, period_ns / resolution);
mtk_pwm_writel(pc, pwm->hwpwm, PWMTHRES, duty_ns / resolution);
  
+	mtk_pwm_clk_disable(chip, pwm);

+
return 0;
  }
  
@@ -102,11 +141,8 @@ static int mtk_pwm_enable(struct pwm_chip *chip, struct

  pwm_device *pwm)
  {
struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
u32 value;
-   int ret;
  
-	ret = clk_prepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);

-   if (ret < 0)
-   return ret;
+   mtk_pwm_clk_enable(chip, pwm);
  
  	value = readl(pc->regs);

value |= BIT(pwm->hwpwm);
@@ -124,7 +160,7 @@ static void mtk_pwm_disable(struct pwm_chip *chip,
  struct pwm_device *pwm)
value &= ~BIT(pwm->hwpwm);
writel(value, pc->regs);
  
-	clk_unprepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);

+   mtk_pwm_clk_disable(chip, pwm);
  }
  
  static const struct pwm_ops mtk_pwm_ops = {

@@ -156,14 +192,6 @@ static int mtk_pwm_probe(struct platform_device *pdev)
return PTR_ERR(pc->clks[i]);
}
  
-	ret = clk_prepare(pc->clks[MTK_CLK_TOP]);

-   if (ret < 0)
-   return ret;
-
-   ret = clk_prepare(pc->clks[MTK_CLK_MAIN]);
-   if (ret < 0)
-   goto disable_clk_top;
-
platform_set_drvdata(pdev, pc);
  
  	pc->chip.dev = &pdev->dev;

@@ -174,26 +202,15 @@ static int mtk_pwm_probe(struct platform_device *pdev)
ret = pwmchip_add(&pc->chip);
if (ret < 0) {
dev_err(&pdev->dev, "pwmchip_add() failed: %d\n", ret);
-   goto disable_clk_main;
+   return ret;
}
  
  	return 0;

-
-disable_clk_main:
-   clk_unprepare(pc->clks[MTK_CLK_MAIN]);
-disable_clk_top:
-   clk_unprepare(pc->clks[MTK_CLK_TOP]);
-
-   return ret;
  }
  
  static int mtk_pwm_remove(struct platform_device *pdev)

  {
struct mtk_pwm_chip *pc = platform_get_drvdata(pdev);
-   unsigned int i;
-
-   for (i = 0; i < pc->chip.npwm;

Re: [PATCH v6 1/4] reset: Add APIs to manage array of resets

[Philipp Zabel]

On Tue, 2017-06-20 at 04:21 +0800, kbuild test robot wrote:
> Hi Vivek,
> 
> [auto build test WARNING on pza/reset/next]
> [also build test WARNING on v4.12-rc6 next-20170619]
> [cannot apply to balbi-usb/next]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Philipp-Zabel/reset-Add-APIs-to-manage-array-of-resets/20170620-021320
> base:   git://git.pengutronix.de/git/pza/linux reset/next
> config: i386-randconfig-c0-06200218 (attached as .config)
> compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All warnings (new ones prefixed by >>):
> 
>In file included from drivers/gpu//drm/nouveau/include/nvif/os.h:28:0,
> from drivers/gpu//drm/nouveau/include/nvkm/core/os.h:3,
> from drivers/gpu//drm/nouveau/include/nvkm/core/event.h:3,
> from 
> drivers/gpu//drm/nouveau/include/nvkm/core/device.h:3,
> from 
> drivers/gpu//drm/nouveau/include/nvkm/core/subdev.h:3,
> from 
> drivers/gpu//drm/nouveau/include/nvkm/core/engine.h:4,
> from 
> drivers/gpu//drm/nouveau/include/nvkm/engine/fifo.h:3,
> from drivers/gpu//drm/nouveau/nvkm/engine/fifo/priv.h:4,
> from drivers/gpu//drm/nouveau/nvkm/engine/fifo/chan.h:4,
> from 
> drivers/gpu//drm/nouveau/nvkm/engine/fifo/channv50.h:4,
> from 
> drivers/gpu//drm/nouveau/nvkm/engine/fifo/chang84.c:24:
> >> include/linux/reset.h:110:37: warning: 'struct reset_control_array' 
> >> declared inside parameter list
> void reset_control_array_put(struct reset_control_array *resets)
> ^
> >> include/linux/reset.h:110:37: warning: its scope is only this definition 
> >> or declaration, which is probably not what you want
> 
> vim +110 include/linux/reset.h
> 
> 94return optional ? NULL : ERR_PTR(-ENOTSUPP);
> 95}
> 96
> 97static inline struct reset_control *
> 98devm_reset_control_array_get(struct device *dev, bool shared, 
> bool optional)
> 99{
>100return optional ? NULL : ERR_PTR(-ENOTSUPP);
>101}
>102
>103static inline struct reset_control *
>104of_reset_control_array_get(struct device_node *np, bool shared, 
> bool optional)
>105{
>106return optional ? NULL : ERR_PTR(-ENOTSUPP);
>107}
>108
>109static inline
>  > 110void reset_control_array_put(struct reset_control_array *resets)
>111{
>112}

reset_control_array_put is static now, I forgot to remove this stub.

regards
  * Philipp

Re: [PATCH v2 18/31] efi-stub.txt: standardize document format

[Ard Biesheuvel]

On 17 June 2017 at 17:25, Mauro Carvalho Chehab
 wrote:
> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
>
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx:
>
> - use proper markups for titles;
> - identify literal blocks.
>
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Ard Biesheuvel 


> ---
>  Documentation/efi-stub.txt | 25 +++--
>  1 file changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
> index e15746988261..41df801f9a50 100644
> --- a/Documentation/efi-stub.txt
> +++ b/Documentation/efi-stub.txt
> @@ -1,5 +1,6 @@
> - The EFI Boot Stub
> ----
> +=
> +The EFI Boot Stub
> +=
>
>  On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade
>  as a PE/COFF image, thereby convincing EFI firmware loaders to load
> @@ -25,7 +26,8 @@ a certain sense it *IS* the boot loader.
>  The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option.
>
>
> - How to install bzImage.efi
> +How to install bzImage.efi
> +--
>
>  The bzImage located in arch/x86/boot/bzImage must be copied to the EFI
>  System Partition (ESP) and renamed with the extension ".efi". Without
> @@ -37,14 +39,16 @@ may not need to be renamed. Similarly for arm64, 
> arch/arm64/boot/Image
>  should be copied but not necessarily renamed.
>
>
> - Passing kernel parameters from the EFI shell
> +Passing kernel parameters from the EFI shell
> +
>
> -Arguments to the kernel can be passed after bzImage.efi, e.g.
> +Arguments to the kernel can be passed after bzImage.efi, e.g.::
>
> fs0:> bzImage.efi console=ttyS0 root=/dev/sda4
>
>
> - The "initrd=" option
> +The "initrd=" option
> +
>
>  Like most boot loaders, the EFI stub allows the user to specify
>  multiple initrd files using the "initrd=" option. This is the only EFI
> @@ -54,9 +58,9 @@ kernel when it boots.
>  The path to the initrd file must be an absolute path from the
>  beginning of the ESP, relative path names do not work. Also, the path
>  is an EFI-style path and directory elements must be separated with
> -backslashes (\). For example, given the following directory layout,
> +backslashes (\). For example, given the following directory layout::
>
> -fs0:>
> +  fs0:>
> Kernels\
> bzImage.efi
> initrd-large.img
> @@ -66,7 +70,7 @@ fs0:>
> initrd-medium.img
>
>  to boot with the initrd-large.img file if the current working
> -directory is fs0:\Kernels, the following command must be used,
> +directory is fs0:\Kernels, the following command must be used::
>
> fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img
>
> @@ -76,7 +80,8 @@ which understands relative paths, whereas the rest of the 
> command line
>  is passed to bzImage.efi.
>
>
> - The "dtb=" option
> +The "dtb=" option
> +-
>
>  For the ARM and arm64 architectures, we also need to be able to provide a
>  device tree to the kernel. This is done with the "dtb=" command line option,
> --
> 2.9.4
>

Re: [PATCH v1] uuid: Take const on input of uuid_is_null() and guid_is_null()

[Christoph Hellwig]

Thanks Andy, applied to uuid for-next.

Re: [PATCH 3.10 219/268] tty/serial: atmel: fix race condition (TX+DMA)

[Richard Genoud]

Hi Willy,

You can drop this patch.

There's nothing to fix on 3.10.x since the DMA TX support has been
introduced in 3.12.

Thanks !


2017-06-19 20:31 GMT+02:00 Willy Tarreau :
> From: Richard Genoud 
>
> commit 31ca2c63fdc0aee725cbd4f207c1256f5deaabde upstream.
>
> If uart_flush_buffer() is called between atmel_tx_dma() and
> atmel_complete_tx_dma(), the circular buffer has been cleared, but not
> atmel_port->tx_len.
> That leads to a circular buffer overflow (dumping (UART_XMIT_SIZE -
> atmel_port->tx_len) bytes).
>
> Tested-by: Nicolas Ferre 
> [rg] backport to 3.12
> Signed-off-by: Richard Genoud 
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: Willy Tarreau 
> ---
>  drivers/tty/serial/atmel_serial.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/tty/serial/atmel_serial.c 
> b/drivers/tty/serial/atmel_serial.c
> index 82127ac..41d1df5 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -1090,6 +1090,11 @@ static void atmel_flush_buffer(struct uart_port *port)
> UART_PUT_TCR(port, 0);
> atmel_port->pdc_tx.ofs = 0;
> }
> +   /*
> +* in uart_flush_buffer(), the xmit circular buffer has just
> +* been cleared, so we have to reset its length accordingly.
> +*/
> +   sg_dma_len(&atmel_port->sg_tx) = 0;
>  }
>
>  /*
> --
> 2.8.0.rc2.1.gbe9624a
>

Re: [PATCH][mmc-next][RESEND] mmc: sdhci-pci: make guid intel_dsm_guid static

[Christoph Hellwig]

Thanks Colin,

applied to uuid for-next.

Re: [PATCH 04/11] S.A.R.A. USB Filtering

[Pavel Machek]

On Mon 2017-06-12 18:56:53, Salvatore Mesoraca wrote:
> Introduction of S.A.R.A. USB Filtering.
> It uses the "usb_device_auth" LSM hook to provide a mechanism to decide
> which USB devices should be authorized to connect to the system and
> which shouldn't.
> The main goal is to narrow the attack surface for custom USB devices
> designed to exploit vulnerabilities found in some USB device drivers.
> Via configuration it's possible to allow or to deny authorization, based
> on one or more of: Vendor ID, Product ID, bus name and port number. There
> is also support for "trailing wildcards".

Hmm. Given that USB device provides vendor id/product id, this does
not really stop anyone, right?

AFAICT you can still get USB stick with vid/pid of logitech keyboard,
and kernel will recognize it as a usb stick.

So you should not really filter on vid/pid, but on device
types (sha sum of USB descriptor?).

> Depending on the configuration, it can work both as a white list or as a
> black list.

Blacklisting vid/pid is completely useless. Whitelisting vid/pid is
nearly so. Attacker able to plug USB devices sees devices already
attached, so he can guess right vid/pids quite easily.

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


signature.asc
Description: Digital signature

[PATCH v2 0/2] acpi, gicv3-its, numa: Adding numa node mapping for ITS

[Ganapatrao Kulkarni]

ACPI 6.2 have added SRAT subtable to define proximity domain for ITS
devices. This patchset updates acpi header file from acpica repo and
adds numa node mapping for ITS devices.

v2:
 - Incorporated comments from Lorenzo Pieralisi and Marc Zyngier.

v1: first patch

Ganapatrao Kulkarni (2):
  ACPICA: ACPI 6.2: Add support for new SRAT subtable
  acpi, gicv3-its, numa: Adding numa node mapping for gic-its units

 drivers/irqchip/irq-gic-v3-its.c | 76 +++-
 include/acpi/actbl1.h| 12 ++-
 2 files changed, 86 insertions(+), 2 deletions(-)

-- 
1.8.1.4

[PATCH v2 2/2] acpi, gicv3-its, numa: Adding numa node mapping for gic-its units

[Ganapatrao Kulkarni]

Add code to parse SRAT ITS Affinity sub table as defined in ACPI 6.2
Later in per device probe, ITS devices are mapped to
numa node using ITS id to proximity domain mapping.

Signed-off-by: Ganapatrao Kulkarni 
---
 drivers/irqchip/irq-gic-v3-its.c | 76 +++-
 1 file changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 45ea1933..5865a75 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1833,6 +1833,78 @@ static int __init its_of_probe(struct device_node *node)
 
 #define ACPI_GICV3_ITS_MEM_SIZE (SZ_128K)
 
+#ifdef CONFIG_ACPI_NUMA
+struct its_srat_map {
+   u32 numa_node;  /* numa node id */
+   u32 its_id;  /* GIC ITS ID */
+   struct list_headentry;
+};
+
+static LIST_HEAD(its_srat_maps);
+
+static int acpi_get_its_numa_node(u32 its_id)
+{
+   struct its_srat_map *srat_map;
+
+   list_for_each_entry(srat_map, &its_srat_maps, entry) {
+   if (its_id == srat_map->its_id)
+   return srat_map->numa_node;
+   }
+   return NUMA_NO_NODE;
+}
+
+static int __init
+gic_acpi_parse_srat_its(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+   int pxm, node;
+   struct its_srat_map *srat_map;
+   struct acpi_srat_its_affinity *its_affinity;
+
+   its_affinity = (struct acpi_srat_its_affinity *)header;
+   if (!its_affinity)
+   return -EINVAL;
+
+   if (its_affinity->header.length <
+   sizeof(struct acpi_srat_its_affinity)) {
+   pr_err("SRAT:ITS: Invalid SRAT header length: %d\n",
+   its_affinity->header.length);
+   return -EINVAL;
+   }
+
+   pxm = its_affinity->proximity_domain;
+   node = acpi_map_pxm_to_node(pxm);
+
+   if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
+   pr_err("SRAT:ITS Invalid numa node %d\n", node);
+   return -EINVAL;
+   }
+
+   srat_map = kzalloc(sizeof(*srat_map), GFP_KERNEL);
+   if (!srat_map)
+   return -ENOMEM;
+
+   srat_map->numa_node = node;
+   srat_map->its_id = its_affinity->its_id;
+   list_add(&srat_map->entry, &its_srat_maps);
+   pr_info("ACPI: NUMA: SRAT: ITS: PXM %d -> ITS_ID %d -> NODE %d\n",
+   srat_map->its_id, pxm, node);
+
+   return 0;
+}
+
+static int __init acpi_table_parse_srat_its(void)
+{
+   return acpi_table_parse_entries(ACPI_SIG_SRAT,
+   sizeof(struct acpi_table_srat),
+   ACPI_SRAT_TYPE_GIC_ITS_AFFINITY,
+   gic_acpi_parse_srat_its, 0);
+}
+#else
+#define acpi_table_parse_srat_its(void) { }
+#define acpi_get_its_numa_node(its_id) NUMA_NO_NODE
+#endif
+
 static int __init gic_acpi_parse_madt_its(struct acpi_subtable_header *header,
  const unsigned long end)
 {
@@ -1861,7 +1933,8 @@ static int __init gic_acpi_parse_madt_its(struct 
acpi_subtable_header *header,
goto dom_err;
}
 
-   err = its_probe_one(&res, dom_handle, NUMA_NO_NODE);
+   err = its_probe_one(&res, dom_handle,
+   acpi_get_its_numa_node(its_entry->translation_id));
if (!err)
return 0;
 
@@ -1873,6 +1946,7 @@ static int __init gic_acpi_parse_madt_its(struct 
acpi_subtable_header *header,
 
 static void __init its_acpi_probe(void)
 {
+   acpi_table_parse_srat_its();
acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
  gic_acpi_parse_madt_its, 0);
 }
-- 
1.8.1.4

Re: [RFC PATCH 0/7 v1] powerpc: Memory Protection Keys

[Pavel Machek]

Hi!

> Memory protection keys enable applications to protect its
> address space from inadvertent access or corruption from
> itself.
> 
> The overall idea:
> 
>  A process allocates a   key  and associates it with
>  a  address  range  withinits   address   space.
>  The process  than  can  dynamically  set read/write 
>  permissions on  the   key   without  involving  the 
>  kernel. Any  code that  violates   the  permissions
>  off the address space; as defined by its associated
>  key, will receive a segmentation fault.

Do you have some documentation how userspace should use this? Will it
be possible to hide details in libc so that it works across
architectures? Do you have some kind of library that hides them?

Where would you like it to be used? Web browsers?

How does it interact with ptrace()? With /dev/mem? With /proc/XXX/mem?
Will it enable malware to become very hard to understand?

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


signature.asc
Description: Digital signature

[PATCH v2 1/2] ACPICA: ACPI 6.2: Add support for new SRAT subtable

[Ganapatrao Kulkarni]

Add GIC ITS Affinity (ACPI 6.2) subtable to SRAT table.

ACPICA commit 5bc67f63918da249bfe279ee461d152bb3e6f55b
Link: https://github.com/acpica/acpica/commit/5bc67f6

Signed-off-by: Ganapatrao Kulkarni 
---
 include/acpi/actbl1.h | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index b4ce55c..253c9db 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -1192,7 +1192,8 @@ enum acpi_srat_type {
ACPI_SRAT_TYPE_MEMORY_AFFINITY = 1,
ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY = 2,
ACPI_SRAT_TYPE_GICC_AFFINITY = 3,
-   ACPI_SRAT_TYPE_RESERVED = 4 /* 4 and greater are reserved */
+   ACPI_SRAT_TYPE_GIC_ITS_AFFINITY = 4,/* ACPI 6.2 */
+   ACPI_SRAT_TYPE_RESERVED = 5 /* 5 and greater are reserved */
 };
 
 /*
@@ -1260,6 +1261,15 @@ struct acpi_srat_gicc_affinity {
u32 clock_domain;
 };
 
+/* 4: GIC ITS Affinity (ACPI 6.2) */
+
+struct acpi_srat_its_affinity {
+   struct acpi_subtable_header header;
+   u32 proximity_domain;
+   u16 reserved;
+   u32 its_id;
+};
+
 /* Flags for struct acpi_srat_gicc_affinity */
 
 #define ACPI_SRAT_GICC_ENABLED (1) /* 00: Use affinity structure */
-- 
1.8.1.4

[PATCH v7 2/3] nvmem: add snvs_lpgpr driver

[Oleksij Rempel]

This is a driver for Low Power General Purpose Register (LPGPR)
available on i.MX6 SoCs in Secure Non-Volatile Storage (SNVS)
of this chip.

It is a 32-bit read/write register located in the low power domain.
Since LPGPR is located in the battery-backed power domain, LPGPR can
be used by any application for retaining data during an SoC power-down
mode.

Signed-off-by: Oleksij Rempel 
---
 drivers/nvmem/Kconfig  |  10 +++
 drivers/nvmem/Makefile |   2 +
 drivers/nvmem/snvs_lpgpr.c | 155 +
 3 files changed, 167 insertions(+)
 create mode 100644 drivers/nvmem/snvs_lpgpr.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 101ced4c84be..ea3044c5d6ee 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -144,4 +144,14 @@ config MESON_EFUSE
  This driver can also be built as a module. If so, the module
  will be called nvmem_meson_efuse.
 
+config NVMEM_SNVS_LPGPR
+   tristate "Support for Low Power General Purpose Register"
+   depends on SOC_IMX6 || COMPILE_TEST
+   help
+ This is a driver for Low Power General Purpose Register (LPGPR) 
available on
+ i.MX6 SoCs in Secure Non-Volatile Storage (SNVS) of this chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-snvs-lpgpr.
+
 endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 173140658693..4c589184acee 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -30,3 +30,5 @@ obj-$(CONFIG_NVMEM_VF610_OCOTP)   += nvmem-vf610-ocotp.o
 nvmem-vf610-ocotp-y:= vf610-ocotp.o
 obj-$(CONFIG_MESON_EFUSE)  += nvmem_meson_efuse.o
 nvmem_meson_efuse-y:= meson-efuse.o
+obj-$(CONFIG_NVMEM_SNVS_LPGPR) += nvmem_snvs_lpgpr.o
+nvmem_snvs_lpgpr-y := snvs_lpgpr.o
diff --git a/drivers/nvmem/snvs_lpgpr.c b/drivers/nvmem/snvs_lpgpr.c
new file mode 100644
index ..2aef5ff80d1e
--- /dev/null
+++ b/drivers/nvmem/snvs_lpgpr.c
@@ -0,0 +1,155 @@
+/*
+ * Copyright (c) 2015 Pengutronix, Steffen Trumtrar 
+ * Copyright (c) 2017 Pengutronix, Oleksij Rempel 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IMX6Q_SNVS_HPLR0x00
+#define IMX6Q_GPR_SL   BIT(5)
+#define IMX6Q_SNVS_LPLR0x34
+#define IMX6Q_GPR_HL   BIT(5)
+#define IMX6Q_SNVS_LPGPR   0x68
+
+struct snvs_lpgpr_cfg {
+   int offset;
+   int offset_hplr;
+   int offset_lplr;
+};
+
+struct snvs_lpgpr_priv {
+   struct device_d *dev;
+   struct regmap   *regmap;
+   struct nvmem_config cfg;
+   const struct snvs_lpgpr_cfg *dcfg;
+};
+
+static const struct snvs_lpgpr_cfg snvs_lpgpr_cfg_imx6q = {
+   .offset = IMX6Q_SNVS_LPGPR,
+   .offset_hplr= IMX6Q_SNVS_HPLR,
+   .offset_lplr= IMX6Q_SNVS_LPLR,
+};
+
+static int snvs_lpgpr_write(void *context, unsigned int offset, void *val,
+   size_t bytes)
+{
+   struct snvs_lpgpr_priv *priv = context;
+   const struct snvs_lpgpr_cfg *dcfg = priv->dcfg;
+   unsigned int lock_reg;
+   int ret;
+
+   ret = regmap_read(priv->regmap, dcfg->offset_hplr, &lock_reg);
+   if (ret < 0)
+   return ret;
+
+   if (lock_reg & IMX6Q_GPR_SL)
+   return -EPERM;
+
+   ret = regmap_read(priv->regmap, dcfg->offset_lplr, &lock_reg);
+   if (ret < 0)
+   return ret;
+
+   if (lock_reg & IMX6Q_GPR_HL)
+   return -EPERM;
+
+   return regmap_bulk_write(priv->regmap, dcfg->offset + offset, val,
+   bytes / 4);
+}
+
+static int snvs_lpgpr_read(void *context, unsigned int offset, void *val,
+  size_t bytes)
+{
+   struct snvs_lpgpr_priv *priv = context;
+   const struct snvs_lpgpr_cfg *dcfg = priv->dcfg;
+
+   return regmap_bulk_read(priv->regmap, dcfg->offset + offset,
+  val, bytes / 4);
+}
+
+static int snvs_lpgpr_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct device_node *node = dev->of_node;
+   struct device_node *syscon_node;
+   struct snvs_lpgpr_priv *priv;
+   struct nvmem_config *cfg;
+   struct nvmem_device *nvmem;
+   const struct snvs_lpgpr_cfg *dcfg;
+
+   if (!node)
+   return -ENOENT;
+
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   dcfg = of_device_get_match_data(dev);
+   if (!dcfg)
+   return -EINVAL;
+
+   syscon_node = of_get_parent(node);
+   if (!syscon_node)
+   return -ENODEV;
+
+ 

[PATCH v7 0/3] nvmem: upstream snvs_lpgpr driver

[Oleksij Rempel]

changes v7:
 - split imx6ul patch and squash it with with main patches.
 - spell fixes in the binding documentation
 - return regmap_bulk_read directly.

changes v6:
 - check if device is writable by reading GPR_SL and GPR_HL bits
 - use regmap_bulk_* functions instead of while() { regmap_read/write }
 - add patch for imx6ul

changes v5:
 - use dcfg->offset instead of priv->offset.

changes v4:
 - change dependencies in Kconfig
 - remove unused includes and order them alphabetically
 - set MODULE_LICENSE = GPL v2
 - remove unused int err variable

changes v3:
 - remove regmap and offset properties.

changes v2:
 - correct typos: Registe, parrent...

Oleksij Rempel (3):
  nvmem: dt: document SNVS LPGPR binding
  nvmem: add snvs_lpgpr driver
  ARM: dts: imx6qdl.dtsi/imx6ul.dtsi: add "fsl,imx6q-snvs-lpgpr" node

 .../devicetree/bindings/nvmem/snvs-lpgpr.txt   |  20 +++
 arch/arm/boot/dts/imx6qdl.dtsi |   4 +
 arch/arm/boot/dts/imx6ul.dtsi  |   4 +
 drivers/nvmem/Kconfig  |  10 ++
 drivers/nvmem/Makefile |   2 +
 drivers/nvmem/snvs_lpgpr.c | 155 +
 6 files changed, 195 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
 create mode 100644 drivers/nvmem/snvs_lpgpr.c

-- 
2.11.0

[PATCH v7 3/3] ARM: dts: imx6qdl.dtsi/imx6ul.dtsi: add "fsl,imx6q-snvs-lpgpr" node

[Oleksij Rempel]

This node is for Low Power General Purpose Register which can
be used as Non-Volatile Storage.

Signed-off-by: Oleksij Rempel 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 4 
 arch/arm/boot/dts/imx6ul.dtsi  | 4 
 2 files changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index e426faa9c243..94e992558238 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -769,6 +769,10 @@
mask = <0x60>;
status = "disabled";
};
+
+   snvs_lpgpr: snvs-lpgpr {
+   compatible = "fsl,imx6q-snvs-lpgpr";
+   };
};
 
epit1: epit@020d { /* EPIT1 */
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index b9d7d2d09402..df870abc28f5 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -624,6 +624,10 @@
linux,keycode = ;
wakeup-source;
};
+
+   snvs_lpgpr: snvs-lpgpr {
+   compatible = "fsl,imx6ul-snvs-lpgpr";
+   };
};
 
epit1: epit@020d {
-- 
2.11.0

[PATCH v7 1/3] nvmem: dt: document SNVS LPGPR binding

[Oleksij Rempel]

Documentation bindings for the Low Power General Purpose Register
available on i.MX6 SoCs in the Secure Non-Volatile Storage.

Signed-off-by: Oleksij Rempel 
---
 .../devicetree/bindings/nvmem/snvs-lpgpr.txt | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt

diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt 
b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
new file mode 100644
index ..20bc49b49799
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
@@ -0,0 +1,20 @@
+Device tree bindings for Low Power General Purpose Register found in i.MX6Q/D
+Secure Non-Volatile Storage.
+
+This DT node should be represented as a sub-node of a "syscon",
+"simple-mfd" node.
+
+Required properties:
+- compatible: should be one of the fallowing variants:
+   "fsl,imx6q-snvs-lpgpr" for Freescale i.MX6Q/D/DL/S
+   "fsl,imx6ul-snvs-lpgpr" for Freescale i.MX6UL
+
+Example:
+snvs: snvs@020cc000 {
+   compatible = "fsl,sec-v4.0-mon", "syscon", "simple-mfd";
+   reg = <0x020cc000 0x4000>;
+
+   snvs_lpgpr: snvs-lpgpr {
+   compatible = "fsl,imx6q-snvs-lpgpr";
+   };
+};
-- 
2.11.0

Re: __user with scalar data types

[Daniel Vetter]

On Mon, Jun 19, 2017 at 6:34 PM, Al Viro  wrote:
> On Mon, Jun 19, 2017 at 10:15:09AM -0600, Jordan Crouse wrote:
>
>> Which raised a bikeshed debate over whether it is appropriate to mark a 
>> scalar
>> type as __user.  My opinion is that it is appropriate because __user should 
>> mark
>> user memory regardless of the container.
>
> What the hell?  __user is a qualifier like const, volatile, etc.  It's a 
> property
> of *pointer* *type*.  Not some nebulous "marks userland memory" thing.
>
>> I'm looking for opinions or semi-authoritative edicts to determine if we 
>> should
>> either start changing our uapi headers or go off and try to figure out how to
>> make sparse understand this particular usage.
>
> Stop cargo-culting, please.

Yep that's cargo-culted, but from a quick grep only msm and qxl
headers do this (the other __user annotations in uapi/drm are for
pointers, where it's correct). Adding those maintainers.

Also, if you use u64_to_user_ptr helper macro sparse should have
caught this (if not we'd need to improve the macro).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/2] arm64: dts: exynos: Fix wrong label for USB 3.0 controller node

[Dongwoo Lee]

Exynos5433 has two usb 3.0 controllers: usbhost and usbdrd. usbhost
is host-only controller whereas usbdrd supports both peripheral and
host mode. "drd" means dual-role device, so usbhost cannot be labeled
with the name contains "drd". Howerver, the label usbdrd_dwc3_0 was
used for usbhost's dwc3 node. It seems it obviously fault because TM2
and TM2E doesn't use usbhost but dr_mode property is assigned to it.

This patch assigns the proper label for two dwc3 nodes, and apply
changes to the related reference.

Signed-off-by: Dongwoo Lee 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 2 +-
 arch/arm64/boot/dts/exynos/exynos5433.dtsi| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 804a270..477c3bc 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -1202,7 +1202,7 @@
status = "okay";
 };
 
-&usbdrd_dwc3_0 {
+&usbdrd_dwc3 {
dr_mode = "otg";
 };
 
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 727f36a..7fe994b 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -1367,7 +1367,7 @@
ranges;
status = "disabled";
 
-   dwc3@1540 {
+   usbdrd_dwc3: dwc3@1540 {
compatible = "snps,dwc3";
reg = <0x1540 0x1>;
interrupts = ;
@@ -1414,7 +1414,7 @@
ranges;
status = "disabled";
 
-   usbdrd_dwc3_0: dwc3@15a0 {
+   usbhost_dwc3: dwc3@15a0 {
compatible = "snps,dwc3";
reg = <0x15a0 0x1>;
interrupts = ;
-- 
1.9.1

Re: [PATCH v3 1/8] gpio: mockup: improve the debugfs input sanitization

[Linus Walleij]

On Fri, Jun 9, 2017 at 1:41 PM, Bartosz Golaszewski  wrote:

> We're currently only checking the first character of the input to the
> debugfs event files, so a string like '0sdfdsf' is valid and indicates
> a falling edge event.
>
> Be more strict and only allow '0', '1', '0\n' & '1\n'.
>
> While we're at it: move the sanitization code before the irq_enabled
> check so that we indicate an error on invalid input even if nobody is
> waiting for events.
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

[PATCH 2/2] arm64: dts: exynos: Add extcon property for TM2 and TM2E

[Dongwoo Lee]

Since commit 9840354ff429 ("usb: dwc3: Add dual-role support") dwc3
node requires extcon property to be initialized as otg mode, and it
can support dual-role mode operation.

Signed-off-by: Dongwoo Lee 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 477c3bc..4daca1e 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -1204,6 +1204,7 @@
 
 &usbdrd_dwc3 {
dr_mode = "otg";
+   extcon = <&muic>;
 };
 
 &usbdrd30_phy {
-- 
1.9.1

Re: [PATCH v3 2/8] gpio: mockup: tweak gpio_mockup_event_write()

[Linus Walleij]

On Fri, Jun 9, 2017 at 1:41 PM, Bartosz Golaszewski  wrote:

> Invert the logic of the irq_enabled check and only access the private
> data after the input is sanitized.
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH 1/6] ARM: dts: rockchip: add basic dtsi file for RK3229 SoC

[Frank Wang]

Hi Heiko,

On 2017/6/19 20:30, Heiko Stübner wrote:

Hi Frank,

Am Montag, 19. Juni 2017, 18:34:27 CEST schrieb Frank Wang:

On 2017/6/18 2:12, Heiko Stuebner wrote:

Am Donnerstag, 15. Juni 2017, 15:16:15 CEST schrieb Frank Wang:

Due to some tiny differences between RK3228 and RK3229, this patch
adds a basic dtsi file which includes a new CPU opp table and PSCI
brought up support for RK3229.

Signed-off-by: Frank Wang

[...]


+   psci {
+   compatible = "arm,psci-1.0", "arm,psci-0.2";
+   method = "smc";
+   };
+};
+
+&cpu0 {
+   enable-method = "psci";
+};

Hmm, I don't really understand this.
What method of core-bringup does the rk3228 use? In the current
rk322x.dtsi there is no enable-method at all defined.

For non-security, the same with rk3036 SoC, we use rk3036-smp method to
bring-up cores, and for security, we use arm-psci method.
As security become more and more important and required, we would prefer
using arm-psci method, and it is also an easy way to use.


So is the rk3228 firmware using a different method than the rk3229?

No, they are the same. How about I move these changes to rk322x.dtsi?

yep, that is what I was getting at with my question ;-)



And out of curiosity as this is a arm32 without atf, is the psci
implementation (for uboot?) you're using available somewhere?

Ah, it is included in op-tee :-)

Is that super secret or will this be part of the official op-tee [0]
at some point (Similar to the ATF stuff on arm64)?


Hmm, the op-tee itself must keep secure, but the psci part in it can be 
extracted to public, although it may have a bit of secure risk.
Due to Rockchip have amended the frame of op-tee to support psci, we can 
try to upstream these changes to official op-tee or push them to source 
codes of Rockchip in git-hub.



BR.
Frank


Heiko

[0]https://github.com/OP-TEE/optee_os/tree/master/core/arch/arm

Re: [PATCH v3 3/8] gpio: mockup: refuse to accept an odd number of GPIO ranges

[Linus Walleij]

On Fri, Jun 9, 2017 at 1:41 PM, Bartosz Golaszewski  wrote:

> Currently we ignore the last odd range value, since each chip is
> described by two values. Be more strict and require the user to
> pass an even number of ranges.
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v3 5/8] gpio: mockup: don't return magic numbers from probe()

[Linus Walleij]

On Fri, Jun 9, 2017 at 1:41 PM, Bartosz Golaszewski  wrote:

> When the requested number of GPIO lines is 0, return -EINVAL, not
> -1 which is -EPERM.
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v3 4/8] gpio: mockup: improve readability

[Linus Walleij]

On Fri, Jun 9, 2017 at 1:41 PM, Bartosz Golaszewski  wrote:

> We currently shift bits here and there without actually explaining
> what we're doing. Add some helper variables with names indicating
> their purpose to improve the code readability.
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH V2 1/2] hwmon: (ibmpowernv) introduce a legacy_compatibles array

[Shilpasri G Bhat]

On 06/20/2017 11:36 AM, Cédric Le Goater wrote:
> On 06/20/2017 07:08 AM, Shilpasri G Bhat wrote:
>> From: Cédric Le Goater 
>>
>> Today, the type of a PowerNV sensor system is determined with the
>> "compatible" property for legacy Firmwares and with the "sensor-type"
>> for newer ones. The same array of strings is used for both to do the
>> matching and this raises some issue to introduce new sensor types.
>>
>> Let's introduce two different arrays (legacy and current) to make
>> things easier for new sensor types.
>>
>> Signed-off-by: Cédric Le Goater 
>> Tested-by: Shilpasri G Bhat 
> 
> Did you test on a Tuleta (IBM Power) system ? 

I have tested this patch on P9 FSP and Firestone.

> 
> Thanks,
> 
> C. 
> 
>> ---
>>  drivers/hwmon/ibmpowernv.c | 26 ++
>>  1 file changed, 18 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
>> index 862b832..6d8909c 100644
>> --- a/drivers/hwmon/ibmpowernv.c
>> +++ b/drivers/hwmon/ibmpowernv.c
>> @@ -55,17 +55,27 @@ enum sensors {
>>  
>>  #define INVALID_INDEX (-1U)
>>  
>> +/*
>> + * 'compatible' string properties for sensor types as defined in old
>> + * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
>> + */
>> +static const char * const legacy_compatibles[] = {
>> +"ibm,opal-sensor-cooling-fan",
>> +"ibm,opal-sensor-amb-temp",
>> +"ibm,opal-sensor-power-supply",
>> +"ibm,opal-sensor-power"
>> +};
>> +
>>  static struct sensor_group {
>> -const char *name;
>> -const char *compatible;
>> +const char *name; /* matches property 'sensor-type' */
>>  struct attribute_group group;
>>  u32 attr_count;
>>  u32 hwmon_index;
>>  } sensor_groups[] = {
>> -{"fan", "ibm,opal-sensor-cooling-fan"},
>> -{"temp", "ibm,opal-sensor-amb-temp"},
>> -{"in", "ibm,opal-sensor-power-supply"},
>> -{"power", "ibm,opal-sensor-power"}
>> +{ "fan"   },
>> +{ "temp"  },
>> +{ "in"},
>> +{ "power" }
>>  };
>>  
>>  struct sensor_data {
>> @@ -239,8 +249,8 @@ static int get_sensor_type(struct device_node *np)
>>  enum sensors type;
>>  const char *str;
>>  
>> -for (type = 0; type < MAX_SENSOR_TYPE; type++) {
>> -if (of_device_is_compatible(np, sensor_groups[type].compatible))
>> +for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
>> +if (of_device_is_compatible(np, legacy_compatibles[type]))
>>  return type;
>>  }
>>  
>>
> 

Re: [PATCH v3 6/8] gpio: mockup: improve the error message

[Linus Walleij]

On Fri, Jun 9, 2017 at 1:41 PM, Bartosz Golaszewski  wrote:

> Indicate the error number and make the message a bit more elaborate.
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v4] platform/x86: dell-laptop: Fix bogus keyboard backlight sysfs interface

[Pali Rohár]

On Tuesday 20 June 2017 11:05:19 Kai-Heng Feng wrote:
> Dell Latitude 3160 does not have keyboard backlight, but there is a
> sysfs interface for it, which does nothing at all.
> 
> KBD_LED_ON_TOKEN is the only token can be found. Since it doesn't have
> KBD_LED_OFF_TOKEN or KBD_LED_AUTO_*_TOKEN, it should be safe to assume
> at least two tokens should be present to support keyboard backlight.
> Not all models have ON token - they may have multiple AUTO tokens instead.
> 
> Models which do not use SMBIOS token to control keyboard backlight, also
> have this issue. Brightness level is 0 on these models. Verified on Dell
> Inspiron 3565.
> 
> Reports keyboard backlight is supported only when at least two modes are
> present.
> 
> Signed-off-by: Kai-Heng Feng 

Reviewed-by: Pali Rohár 

> ---
> 
> v4:
> Change commit log - not all models have ON token.
> 
> v3:
> Change the logic, there should be at least two modes present to claim it
> supports backlight. Suggested by Pali Rohár.
> 
> v2:
> The only token can be found is actually KBD_LED_ON_TOKEN, which is BIT(5),
> instead of KBD_LED_OFF_TOKEN. Change commit log accordingly.
> 
> Use token bit to make the intention more clear.
> Also consider kbd_mode_levels_count and kbd_info.levels, suggested by
> Pali Rohár.
> 
> Use XOR to simplify the bitmask comparison, suggested by
> Andy Shevchenko.
> 
>  drivers/platform/x86/dell-laptop.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/x86/dell-laptop.c 
> b/drivers/platform/x86/dell-laptop.c
> index ec202094bd50..f42159fd2031 100644
> --- a/drivers/platform/x86/dell-laptop.c
> +++ b/drivers/platform/x86/dell-laptop.c
> @@ -1510,7 +1510,11 @@ static void kbd_init(void)
>   ret = kbd_init_info();
>   kbd_init_tokens();
>  
> - if (kbd_token_bits != 0 || ret == 0)
> + /*
> +  * Only supports keyboard backlight when it has at least two modes.
> +  */
> + if ((ret == 0 && (kbd_info.levels != 0 || kbd_mode_levels_count >= 2))
> + || kbd_get_valid_token_counts() >= 2)
>   kbd_led_present = true;
>  }
>  

-- 
Pali Rohár
pali.ro...@gmail.com

Re: [PATCH v3 7/8] gpio: mockup: add myself as author

[Linus Walleij]

On Fri, Jun 9, 2017 at 1:41 PM, Bartosz Golaszewski  wrote:

> Just taking credit for the recent changes and new features. :)
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v3 8/8] gpio: mockup: use devm_kcalloc() where applicable

[Linus Walleij]

On Fri, Jun 9, 2017 at 1:41 PM, Bartosz Golaszewski  wrote:

> When allocating a zeroed array of objects use devm_kcalloc() instead
> of manually calculating the required size and using devm_kzalloc().
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

[BUG][next-20170619][347de24] PowerPC boot fails with Oops

[Abdul Haleem]

Hi,

commit: 347de24 (powerpc/64s: implement arch-specific hardlockup
watchdog)

linux-next fails to boot on PowerPC Bare-metal box.

Test: boot
Machine type: Power 8 Bare-metal
Kernel: 4.12.0-rc5-next-20170619
gcc: version 4.8.5


In file arch/powerpc/kernel/watchdog.c

void soft_nmi_interrupt(struct pt_regs *regs)
{
unsigned long flags;
int cpu = raw_smp_processor_id();
u64 tb;

if (!cpumask_test_cpu(cpu, &wd_cpus_enabled))
return;

>>> nmi_enter();
tb = get_tb();



commit 347de24231df9f82969e2de3ad9f6976f1856a0f
Author: Nicholas Piggin 
Date:   Sat Jun 17 09:33:56 2017 +1000

powerpc/64s: implement arch-specific hardlockup watchdog

Implement an arch-speicfic watchdog rather than use the perf-based
hardlockup detector.

The new watchdog takes the soft-NMI directly, rather than going
through
perf.  Perf interrupts are to be made maskable in future, so that
would
prevent the perf detector from working in those regions.



boot logs:
--
cpuidle: using governor menu
pstore: using zlib compression
pstore: Registered nvram as persistent store backend
[ cut here ]
kernel BUG at arch/powerpc/kernel/watchdog.c:206!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=2048 
NUMA 
PowerNV
Modules linked in:
CPU: 67 PID: 0 Comm: swapper/67 Not tainted 4.12.0-rc5-next-20170619 #1
task: c00f272be700 task.stack: c00f2736c000
NIP: c002c5fc LR: c002c5e8 CTR: c016f570
REGS: c0003fcd7a00 TRAP: 0700   Not tainted
(4.12.0-rc5-next-20170619)
MSR: 90021033 
  CR: 22004022  XER: 2000  
CFAR: c0149c6c SOFTE: 0 
GPR00: c002c5e8 c0003fcd7c80 c105e900
 
GPR04:  00073388 c00fff7cf014
 
GPR08: 000ffea9 0010 4000
 
GPR12: 90009033 cfd57080 c00f2736ff90
 
GPR16:   40376a80
40376ac8 
GPR20: c00ffe63 0001 0002
 
GPR24:  c00f2736c000 c00f2736c080
0008 
GPR28: c0003fcd7d80 0003 0008
0043 
NIP [c002c5fc] soft_nmi_interrupt+0x9c/0x2e0
LR [c002c5e8] soft_nmi_interrupt+0x88/0x2e0
Call Trace:
Instruction dump:
eba1ffe8 ebc1fff0 ebe1fff8 7c0803a6 4e800020 7c7c1b78 4811d615 6000 
78290464 8129000c 552902d6 79290020 <0b09> 78290464 8149000c
3d4a0011 
[ cut here ]
kernel BUG at arch/powerpc/kernel/watchdog.c:206!
[ cut here ]
kernel BUG at arch/powerpc/kernel/watchdog.c:206!
[ cut here ]
kernel BUG at arch/powerpc/kernel/watchdog.c:206!
[ cut here ]
kernel BUG at arch/powerpc/kernel/watchdog.c:206!
random: print_oops_end_marker+0x6c/0xa0 get_random_bytes called with
crng_init=0
---[ end trace 9756c1a885c69f33 ]---
-- 


Regard's

Abdul Haleem
IBM Linux Technology Centre


 kernel:kexec: Starting new kernel
[  205.035822] kexec: waiting for cpu 48 (physical 168) to enter 1 state
[  205.035955] kexec: waiting for cpu 0 (physical 32) to enter OPAL
[  205.036870] kexec: waiting for cpu 2 (physical 34) to enter OPAL
[  205.037038] kexec: waiting for cpu 21 (physical 53) to enter OPAL
[0.00] opal: OPAL detected !
[0.00] Page sizes from device-tree:
[0.00] base_shift=12: shift=12, sllp=0x, avpnm=0x, 
tlbiel=1, penc=0
[0.00] base_shift=12: shift=16, sllp=0x, avpnm=0x, 
tlbiel=1, penc=7
[0.00] base_shift=12: shift=24, sllp=0x, avpnm=0x, 
tlbiel=1, penc=56
[0.00] base_shift=16: shift=16, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=1
[0.00] base_shift=16: shift=24, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=8
[0.00] base_shift=24: shift=24, sllp=0x0100, avpnm=0x0001, 
tlbiel=0, penc=0
[0.00] base_shift=34: shift=34, sllp=0x0120, avpnm=0x07ff, 
tlbiel=0, penc=3
[0.00] Using 1TB segments
[0.00] Initializing hash mmu with SLB
[0.00] Linux version 4.12.0-rc5-next-20170619 
(r...@ltc-test-ci3.aus.stglabs.ibm.com) (gcc version 4.8.5 20150623 (Red Hat 
4.8.5-11) (GCC) ) #1 SMP Tue Jun 20 12:17:53 IST 2017
[0.00] Found initrd at 0xc291:0xc3bea97a
[0.00] Using PowerNV machine description
[0.00] bootconsole [udbg0] enabled
[0.00] CPU maps initialized for 8 threads per core
 -> smp_release_cpus()
spinning_secondaries = 79
 <- smp_release_cpus()
[0.00] -
[0.00] ppc64_pft_size= 0x0
[0.00] phys_mem_size = 0x10
[0.00] dcache_bsize  = 0x80
[0.00] icache_bsize  = 0x80
[0.00] cpu_features  = 0x17fc7aed18500249
[0.00]   possible= 0x5fff

Re: [PATCH V2 1/2] hwmon: (ibmpowernv) introduce a legacy_compatibles array

[Cédric Le Goater]

On 06/20/2017 07:08 AM, Shilpasri G Bhat wrote:
> From: Cédric Le Goater 
> 
> Today, the type of a PowerNV sensor system is determined with the
> "compatible" property for legacy Firmwares and with the "sensor-type"
> for newer ones. The same array of strings is used for both to do the
> matching and this raises some issue to introduce new sensor types.
> 
> Let's introduce two different arrays (legacy and current) to make
> things easier for new sensor types.
> 
> Signed-off-by: Cédric Le Goater 
> Tested-by: Shilpasri G Bhat 

Did you test on a Tuleta (IBM Power) system ? 

Thanks,

C. 

> ---
>  drivers/hwmon/ibmpowernv.c | 26 ++
>  1 file changed, 18 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index 862b832..6d8909c 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -55,17 +55,27 @@ enum sensors {
>  
>  #define INVALID_INDEX (-1U)
>  
> +/*
> + * 'compatible' string properties for sensor types as defined in old
> + * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
> + */
> +static const char * const legacy_compatibles[] = {
> + "ibm,opal-sensor-cooling-fan",
> + "ibm,opal-sensor-amb-temp",
> + "ibm,opal-sensor-power-supply",
> + "ibm,opal-sensor-power"
> +};
> +
>  static struct sensor_group {
> - const char *name;
> - const char *compatible;
> + const char *name; /* matches property 'sensor-type' */
>   struct attribute_group group;
>   u32 attr_count;
>   u32 hwmon_index;
>  } sensor_groups[] = {
> - {"fan", "ibm,opal-sensor-cooling-fan"},
> - {"temp", "ibm,opal-sensor-amb-temp"},
> - {"in", "ibm,opal-sensor-power-supply"},
> - {"power", "ibm,opal-sensor-power"}
> + { "fan"   },
> + { "temp"  },
> + { "in"},
> + { "power" }
>  };
>  
>  struct sensor_data {
> @@ -239,8 +249,8 @@ static int get_sensor_type(struct device_node *np)
>   enum sensors type;
>   const char *str;
>  
> - for (type = 0; type < MAX_SENSOR_TYPE; type++) {
> - if (of_device_is_compatible(np, sensor_groups[type].compatible))
> + for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
> + if (of_device_is_compatible(np, legacy_compatibles[type]))
>   return type;
>   }
>  
> 

Re: [PATCH v7 03/36] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings

[Borislav Petkov]

On Fri, Jun 16, 2017 at 01:50:23PM -0500, Tom Lendacky wrote:
> The ioremap() function is intended for mapping MMIO. For RAM, the
> memremap() function should be used. Convert calls from ioremap() to
> memremap() when re-mapping RAM.
> 
> This will be used later by SME to control how the encryption mask is
> applied to memory mappings, with certain memory locations being mapped
> decrypted vs encrypted.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/dmi.h   |8 
>  arch/x86/kernel/acpi/boot.c  |6 +++---
>  arch/x86/kernel/kdebugfs.c   |   34 +++---
>  arch/x86/kernel/ksysfs.c |   28 ++--
>  arch/x86/kernel/mpparse.c|   10 +-
>  arch/x86/pci/common.c|4 ++--
>  drivers/firmware/dmi-sysfs.c |5 +++--
>  drivers/firmware/pcdp.c  |4 ++--
>  drivers/sfi/sfi_core.c   |   22 +++---
>  9 files changed, 55 insertions(+), 66 deletions(-)

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH V2 2/2] hwmon: (ibmpowernv) Add current(A) sensor

[Cédric Le Goater]

On 06/20/2017 07:08 AM, Shilpasri G Bhat wrote:
> This patch exports current(A) sensors in inband sensors copied to
> main memory by OCC.
> 
> Signed-off-by: Shilpasri G Bhat 

Reviewed-by: Cédric Le Goater 

Thanks,

C.

> ---
> Changes from V1:
> - Rebased on top of Cedric's patch to remove legay-compatible type for
>   the current(A) sensor.
> 
>  drivers/hwmon/ibmpowernv.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index 6d8909c..9b11b13 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -50,6 +50,7 @@ enum sensors {
>   TEMP,
>   POWER_SUPPLY,
>   POWER_INPUT,
> + CURRENT,
>   MAX_SENSOR_TYPE,
>  };
>  
> @@ -75,7 +76,8 @@ enum sensors {
>   { "fan"   },
>   { "temp"  },
>   { "in"},
> - { "power" }
> + { "power" },
> + { "curr"  },
>  };
>  
>  struct sensor_data {
> 

Re: [RFC v2 08/12] powerpc: Handle exceptions caused by violation of pkey protection.

[Anshuman Khandual]

On 06/17/2017 09:22 AM, Ram Pai wrote:
> Handle Data and Instruction exceptions caused by memory
> protection-key.
> 
> Signed-off-by: Ram Pai 
> (cherry picked from commit a5e5217619a0c475fe0cacc3b0cf1d3d33c79a09)

To which tree this commit belongs to ?

> 
> Conflicts:
>   arch/powerpc/include/asm/reg.h
>   arch/powerpc/kernel/exceptions-64s.S
> ---
>  arch/powerpc/include/asm/mmu_context.h | 12 +
>  arch/powerpc/include/asm/pkeys.h   |  9 
>  arch/powerpc/include/asm/reg.h |  7 +--
>  arch/powerpc/mm/fault.c| 21 +++-
>  arch/powerpc/mm/pkeys.c| 90 
> ++
>  5 files changed, 134 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/mmu_context.h 
> b/arch/powerpc/include/asm/mmu_context.h
> index da7e943..71fffe0 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -175,11 +175,23 @@ static inline void arch_bprm_mm_init(struct mm_struct 
> *mm,
>  {
>  }
> 
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> +bool arch_pte_access_permitted(pte_t pte, bool write);
> +bool arch_vma_access_permitted(struct vm_area_struct *vma,
> + bool write, bool execute, bool foreign);
> +#else /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> +static inline bool arch_pte_access_permitted(pte_t pte, bool write)
> +{
> + /* by default, allow everything */
> + return true;
> +}
>  static inline bool arch_vma_access_permitted(struct vm_area_struct *vma,
>   bool write, bool execute, bool foreign)
>  {
>   /* by default, allow everything */
>   return true;
>  }

Right, these are the two functions the core VM expects the
arch to provide.

> +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> +
>  #endif /* __KERNEL__ */
>  #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
> diff --git a/arch/powerpc/include/asm/pkeys.h 
> b/arch/powerpc/include/asm/pkeys.h
> index 9b6820d..405e7db 100644
> --- a/arch/powerpc/include/asm/pkeys.h
> +++ b/arch/powerpc/include/asm/pkeys.h
> @@ -14,6 +14,15 @@
>   VM_PKEY_BIT3 | \
>   VM_PKEY_BIT4)
> 
> +static inline u16 pte_flags_to_pkey(unsigned long pte_flags)
> +{
> + return ((pte_flags & H_PAGE_PKEY_BIT4) ? 0x1 : 0x0) |
> + ((pte_flags & H_PAGE_PKEY_BIT3) ? 0x2 : 0x0) |
> + ((pte_flags & H_PAGE_PKEY_BIT2) ? 0x4 : 0x0) |
> + ((pte_flags & H_PAGE_PKEY_BIT1) ? 0x8 : 0x0) |
> + ((pte_flags & H_PAGE_PKEY_BIT0) ? 0x10 : 0x0);
> +}

Add defines for the above 0x1, 0x2, 0x4, 0x8 etc ?

> +
>  #define pkey_to_vmflag_bits(key) (((key & 0x1UL) ? VM_PKEY_BIT0 : 0x0UL) | \
>   ((key & 0x2UL) ? VM_PKEY_BIT1 : 0x0UL) |\
>   ((key & 0x4UL) ? VM_PKEY_BIT2 : 0x0UL) |\
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index 2dcb8a1..a11977f 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -285,9 +285,10 @@
>  #define   DSISR_UNSUPP_MMU   0x0008  /* Unsupported MMU config */
>  #define   DSISR_SET_RC   0x0004  /* Failed setting of 
> R/C bits */
>  #define   DSISR_PGDIRFAULT  0x0002  /* Fault on page directory */
> -#define   DSISR_PAGE_FAULT_MASK (DSISR_BIT32 | \
> - DSISR_PAGEATTR_CONFLT | \
> - DSISR_BADACCESS |   \
> +#define   DSISR_PAGE_FAULT_MASK (DSISR_BIT32 |   \
> + DSISR_PAGEATTR_CONFLT | \
> + DSISR_BADACCESS |   \
> + DSISR_KEYFAULT |\
>   DSISR_BIT43)

This should have been cleaned up before adding new
DSISR_KEYFAULT reason code into it. But I guess its
okay.

>  #define SPRN_TBRL0x10C   /* Time Base Read Lower Register (user, R/O) */
>  #define SPRN_TBRU0x10D   /* Time Base Read Upper Register (user, R/O) */
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 3a7d580..c31624f 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -216,9 +216,10 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> address,
>* bits we are interested in.  But there are some bits which
>* indicate errors in DSISR but can validly be set in SRR1.
>*/
> - if (trap == 0x400)
> + if (trap == 0x400) {
>   error_code &= 0x4820;
> - else
> + flags |= FAULT_FLAG_INSTRUCTION;
> + } else
>   is_write = error_code & DSISR_ISSTORE;
>  #else

Why adding the FAULT_FLAG_INSTRUCTION here ?

>   is_write = error_code & ESR_DST;
> @@ -261,6 +262,13 @@ int do_page_fault(struct pt_regs *regs, unsigned long 
> address,
>   }
>  #endif
> 
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> + if (error_code & DSISR_KEYFAULT) {
> + code = SEGV_PKUERR;
> +  

Re: [PATCH 3.10 219/268] tty/serial: atmel: fix race condition (TX+DMA)

[Willy Tarreau]

Hi Richard,

On Tue, Jun 20, 2017 at 09:04:03AM +0200, Richard Genoud wrote:
> Hi Willy,
> 
> You can drop this patch.
> 
> There's nothing to fix on 3.10.x since the DMA TX support has been
> introduced in 3.12.

I've already dropped it as it broke some build.

Thanks!
Willy

Re: [PATCH v7 00/16] mtd: nand: denali: Denali NAND IP improvements

[Boris Brezillon]

On Tue, 13 Jun 2017 22:45:34 +0900
Masahiro Yamada  wrote:

> This patch series intends to solve various problems.
> 
> [1] The driver just retrieves the OOB area as-is
> whereas the controller uses syndrome page layout.
> [2] ONFi devices are not working
> [3] It can not read Bad Block Marker
> 
> Outstanding changes are:
>  - Fix raw/oob callbacks for syndrome page layout
>  - Implement setup_data_interface() callback
>  - Fix/implement more commands for ONFi devices
>  - Allow to skip the driver internal bounce buffer
>  - Support PIO in case DMA is not supported
>  - Switch from ->cmdfunc over to ->cmd_ctrl
> 
> 18 patches were merged by v2.
> 11 patches were merged by v3.
> 2 patches were merged by v4.
> 5 patches were merged by v5.
> Here is the rest of the series.
> 
> v1: https://lkml.org/lkml/2016/11/26/144
> v2: https://lkml.org/lkml/2017/3/22/804
> v3: https://lkml.org/lkml/2017/3/30/90
> v4: https://lkml.org/lkml/2017/6/5/1005
> 
> 
> Masahiro Yamada (16):
>   mtd: nand: denali: set NAND_ECC_CUSTOM_PAGE_ACCESS
>   mtd: nand: denali: remove unneeded find_valid_banks()
>   mtd: nand: denali: handle timing parameters by setup_data_interface()
>   mtd: nand: denali: rework interrupt handling
>   mtd: nand: denali: switch over to cmd_ctrl instead of cmdfunc
>   mtd: nand: denali: fix bank reset function to detect the number of
> chips
>   mtd: nand: denali: use interrupt instead of polling for bank reset
>   mtd: nand: denali: propagate page to helpers via function argument
>   mtd: nand: denali: merge struct nand_buf into struct denali_nand_info
>   mtd: nand: denali: use flag instead of register macro for direction
>   mtd: nand: denali: fix raw and oob accessors for syndrome page layout
>   mtd: nand: denali: support hardware-assisted erased page detection
>   mtd: nand: denali: skip driver internal bounce buffer when possible
>   mtd: nand: denali: use non-managed kmalloc() for DMA buffer
>   mtd: nand: denali: enable bad block table scan
>   mtd: nand: denali: avoid magic numbers and rename for clarification

Applied patches 1 to 15 and v8 of patch 16.

Thanks a lot for your patience and the cleanup/rework you've done.

BTW, I'd be happy to have you flagged as the maintainer of the NAND
denali driver. If you like the idea, just send a patch adding an entry
in MAINTAINERS.

Regards,

Boris

> 
>  drivers/mtd/nand/denali.c | 1724 
> ++---
>  drivers/mtd/nand/denali.h |   63 +-
>  drivers/mtd/nand/denali_dt.c  |   15 +-
>  drivers/mtd/nand/denali_pci.c |   22 +-
>  4 files changed, 806 insertions(+), 1018 deletions(-)
> 

Re: WMI and Kernel:User interface

[Pali Rohár]

On Monday 19 June 2017 20:37:25 Darren Hart wrote:
> dell-wmi:
> Type and code, where type may be, for example, "sequence" and then each byte 
> of
> buffen length is processed as a key.

It is more complicated. Buffer can contain more sequences (each has own
length) and each sequence can contain different hotkey + additional info.

So I doubt it would be possible to describe in context-free grammar
specification of even buffer... And something more complicated (as L0 or
L1) is not a good idea to parse in kernel.

-- 
Pali Rohár
pali.ro...@gmail.com

Re: [PATCH 1/7] drm/bridge: Support hotplugging panel-bridge.

[Laurent Pinchart]

Hi Archit,

On Tuesday 20 Jun 2017 09:18:00 Archit Taneja wrote:
> On 06/16/2017 08:13 PM, Eric Anholt wrote:
> > Archit Taneja  writes:
> >> On 06/16/2017 02:11 AM, Eric Anholt wrote:
> >>> If the panel-bridge is being set up after the drm_mode_config_reset(),
> >>> then the connector's state would never get initialized, and we'd
> >>> dereference the NULL in the hotplug path.  We also need to register
> >>> the connector, so that userspace can get at it.
> >> 
> >> Shouldn't the KMS driver make sure the panel-bridge is set up before
> >> drm_mode_config_reset? Is it the case when we're inserting the
> >> panel-bridge driver as a module?
> >> 
> >> 
> >> All the connectors that have been added are registered automatically
> >> when drm_dev_register() is called by the KMS driver. Registering a
> >> connector in the middle of setting up our driver is prone to race
> >> conditions if the userspace decides to use them immediately.
> > 
> > Yeah, this is fixing initializing panel_bridge at DSI host_attach time,
> > which in the case of a panel module that creates the DSI device
> > (adv7533-style, like you said I should use as a reference) will be after
> > drm_mode_config_reset() and drm_dev_register().
> 
> Okay. In the case of the msm kms driver, we defer probe until the
> adv7533 module is inserted, only then we proceed to drm_mode_config_reset()
> and drm_dev_register(). I assumed this was the general practice followed by
> most kms drivers. I.,e the kms driver defers probe until all connector
> related modules are inserted, and only then proceed to create a drm device.

I'd love to see support for a more dynamic approach that would allow 
registering outputs at runtime. Until that's implemented, however, I agree 
with your statement, drivers should wait until all components are available 
before registering the DRM device.

> Feedback from others on this would be appreciated, though.

-- 
Regards,

Laurent Pinchart

Re: [GIT PULL] Improve cp110 clk support on Marvell Armada 7K/8K

[Gregory CLEMENT]

Hi Stephen,
 
 On mar., juin 20 2017, Stephen Boyd  wrote:

> On 06/19, Gregory CLEMENT wrote:
>> 
>> Hi Mike, Stephen,
>> 
>> This time I turned the series in a pull request so I removed the
>> device tree binding part which will be in an other series for Rob
>> Herring and I also removed the dt part that I will take care of once
>> you will have pulled this one.
>> 
>> I hope this will be easier for you to apply this way.
>> 
>
> Ok. It wasn't clear what was going on and I forgot to ask in the
> lastest patch series. Pulled into clk-next, but I had to apply
> this patch on top:

Thanks for the pull and the fix patch!

Gregory

>
> ---8<
> From: Stephen Boyd 
> Subject: [PATCH] clk: mvebu: cp110: Minor cleanups
>
> Mark an array of strings static const and remove the dereference
> of a function pointer when assigning to the platform driver probe
> struct member.
>
> drivers/clk/mvebu/cp110-system-controller.c:89:12:
> warning: symbol 'gate_base_names' was not declared. Should it be static?
> drivers/clk/mvebu/cp110-system-controller.c:447:18:
> error: cannot dereference this type
>
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/clk/mvebu/cp110-system-controller.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/mvebu/cp110-system-controller.c 
> b/drivers/clk/mvebu/cp110-system-controller.c
> index b034b79345ec..ca9a0a536174 100644
> --- a/drivers/clk/mvebu/cp110-system-controller.c
> +++ b/drivers/clk/mvebu/cp110-system-controller.c
> @@ -86,7 +86,7 @@ enum {
>  #define CP110_GATE_EIP15025
>  #define CP110_GATE_EIP19726
>  
> -const char *gate_base_names[] = {
> +static const char * const gate_base_names[] = {
>   [CP110_GATE_AUDIO]  = "audio",
>   [CP110_GATE_COMM_UNIT]  = "communit",
>   [CP110_GATE_NAND]   = "nand",
> @@ -437,14 +437,13 @@ static int cp110_clk_probe(struct platform_device *pdev)
>   return cp110_syscon_common_probe(pdev, pdev->dev.of_node->parent);
>  }
>  
> -
>  static const struct of_device_id cp110_syscon_legacy_of_match[] = {
>   { .compatible = "marvell,cp110-system-controller0", },
>   { }
>  };
>  
>  static struct platform_driver cp110_syscon_legacy_driver = {
> - .probe = *cp110_syscon_legacy_clk_probe,
> + .probe = cp110_syscon_legacy_clk_probe,
>   .driver = {
>   .name   = "marvell-cp110-system-controller0",
>   .of_match_table = cp110_syscon_legacy_of_match,
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: [RFC PATCH 1/2] mm: introduce bmap_walk()

[Christoph Hellwig]

On Mon, Jun 19, 2017 at 07:19:57PM +0100, Al Viro wrote:
> Speaking of iomap, what's supposed to happen when doing a write into what
> used to be a hole?  Suppose we have a file with a megabyte hole in it
> and there's some process mmapping that range.  Another process does
> write over the entire range.  We call ->iomap_begin() and allocate
> disk blocks.  Then we start copying data into those.  In the meanwhile,
> the first process attempts to fetch from address in the middle of that
> hole.  What should happen?

Right now the buffered iomap code expects delayed allocations.
So ->iomap_begin will only reserve block in memory, and not even
mark the blocks as allocated in the page / buffer_head.  The fact
that the block is allocated is only propagated into the page buffer_head
on a page by page basis in the actor.

> Should the blocks we'd allocated in ->iomap_begin() be immediately linked
> into the whatever indirect locks/btree/whatnot we are using?  That would
> require zeroing all of them first - otherwise that readpage will read
> uninitialized block.  Another variant would be to delay linking them
> in until ->iomap_end(), but...  Suppose we get the page evicted by
> memory pressure after the writer is finished with it.  If ->readpage()
> comes before ->iomap_end(), we'll need to somehow figure out that it's
> not a hole anymore, or we'll end up with an uptodate page full of zeroes
> observed by reads after successful write().

Delayed blocks are ignored by the read code, so it will read 'through'
them.

> The comment you've got in linux/iomap.h would seem to suggest the second
> interpretation, but neither it nor anything in Documentation discusses the
> relations with readpage/writepage...

I'll see if I can come up with some better documentation.

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

[Borislav Petkov]

On Fri, Jun 16, 2017 at 01:51:15PM -0500, Tom Lendacky wrote:
> Add support to the early boot code to use Secure Memory Encryption (SME).
> Since the kernel has been loaded into memory in a decrypted state, encrypt
> the kernel in place and update the early pagetables with the memory
> encryption mask so that new pagetable entries will use memory encryption.
> 
> The routines to set the encryption mask and perform the encryption are
> stub routines for now with functionality to be added in a later patch.
> 
> Because of the need to have the routines available to head_64.S, the
> mem_encrypt.c is always built and #ifdefs in mem_encrypt.c will provide
> functionality or stub routines depending on CONFIG_AMD_MEM_ENCRYPT.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/mem_encrypt.h |8 +++
>  arch/x86/kernel/head64.c   |   33 +-
>  arch/x86/kernel/head_64.S  |   39 
> ++--
>  arch/x86/mm/Makefile   |4 +---
>  arch/x86/mm/mem_encrypt.c  |   24 ++
>  5 files changed, 93 insertions(+), 15 deletions(-)

...

> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index b99d469..9a78277 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -11,6 +11,9 @@
>   */
>  
>  #include 
> +#include 
> +
> +#ifdef CONFIG_AMD_MEM_ENCRYPT
>  
>  /*
>   * Since SME related variables are set early in the boot process they must
> @@ -19,3 +22,24 @@
>   */
>  unsigned long sme_me_mask __section(.data) = 0;
>  EXPORT_SYMBOL_GPL(sme_me_mask);
> +
> +void __init sme_encrypt_kernel(void)
> +{
> +}

Just the minor:

void __init sme_encrypt_kernel(void) { }

in case you have to respin.

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

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

Build regressions/improvements in v4.12-rc6

[Geert Uytterhoeven]

Below is the list of build error/warning regressions/improvements in
v4.12-rc6[1] compared to v4.11[2].

Summarized:
  - build errors: +2/-1
  - build warnings: +27127/-5636

JFYI, when comparing v4.12-rc6[1] to v4.12-rc5[3], the summaries are:
  - build errors: +4/-
  - build warnings: +565/-5931

Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.

Happy fixing! ;-)

Thanks to the linux-next team for providing the build service.

[1] 
http://kisskb.ellerman.id.au/kisskb/head/41f1830f5a7af77cf5c86359aba3cbd706687e52/
 (267 out of 270 configs)
[2] 
http://kisskb.ellerman.id.au/kisskb/head/a351e9b9fc24e982ec2f0e76379a49826036da12/
 (all 270 configs)
[3] 
http://kisskb.ellerman.id.au/kisskb/head/32c1431eea4881a6b17bd7c639315010aeefa452/
 (267 out of 270 configs)


*** ERRORS ***

2 error regressions:
  + /home/kisskb/slave/src/arch/sh/boards/mach-sh03/setup.c: error: implicit 
declaration of function 'ioremap_prot' [-Werror=implicit-function-declaration]: 
 => 85:2
  + error: "__udivdi3" [fs/ufs/ufs.ko] undefined!:  => N/A

1 error improvements:
  - error: rtnetlink.c: relocation truncated to fit: R_AVR32_11H_PCREL against 
`.text'+21b6c: (.text+0x21f78), (.text+0x21f8e) => 


*** WARNINGS ***

27127 warning regressions:

[Deleted 26376 lines about "warning: ... [-Wpointer-sign]" on 
parisc-allmodconfig]
[Deleted 551 lines about "warning: -ffunction-sections disabled; it makes 
profiling impossible [enabled by default]" on parisc-allmodconfig]

  + /home/kisskb/slave/src/arch/m68k/include/asm/uaccess_mm.h: warning: 
'info.fd' may be used uninitialized in this function [-Wuninitialized]:  => 
328:3
  + /home/kisskb/slave/src/arch/mn10300/lib/checksum.c: warning: ignoring 
return value of 'copy_from_user', declared with attribute warn_unused_result 
[-Wunused-result]:  => 56:16
  + /home/kisskb/slave/src/arch/sh/boards/mach-sh03/setup.c: warning: 
assignment makes pointer from integer without a cast [enabled by default]:  => 
85:14
  + /home/kisskb/slave/src/arch/sh/kernel/cpu/sh4/../sh3/../../entry-common.S: 
Warning: overflow in branch to __restore_all; converted into longer instruction 
sequence:  => 89
  + /home/kisskb/slave/src/arch/sh/kernel/cpu/sh4/../sh3/../../entry-common.S: 
Warning: overflow in branch to syscall_call; converted into longer instruction 
sequence:  => 208
  + /home/kisskb/slave/src/arch/sh/kernel/cpu/sh4/../sh3/../../entry-common.S: 
Warning: overflow in branch to syscall_trace_entry; converted into longer 
instruction sequence:  => 356, 358
  + /home/kisskb/slave/src/crypto/async_tx/raid6test.c: warning: 
'raid6_dual_recov.constprop.0' uses dynamic stack allocation [enabled by 
default]:  => 128:1
  + /home/kisskb/slave/src/drivers/block/rbd.c: warning: 'ret' may be used 
uninitialized in this function [-Wuninitialized]:  => 3442:3
  + /home/kisskb/slave/src/drivers/char/tpm/tpm2-cmd.c: warning: 'blob_handle' 
may be used uninitialized in this function [-Wuninitialized]:  => 747:24
  + /home/kisskb/slave/src/drivers/crypto/chelsio/chcr_algo.c: warning: 
'chcr_copy_assoc.isra.18' uses dynamic stack allocation [enabled by default]:  
=> 1345:1
  + /home/kisskb/slave/src/drivers/gpio/gpio-dln2.c: warning: 'packed' 
attribute ignored for field of type '__le16' [-Wattributes]:  => 73:2
  + /home/kisskb/slave/src/drivers/gpio/gpio-wm831x.c: warning: 'powerdomain' 
may be used uninitialized in this function [-Wuninitialized]:  => 234:13
  + /home/kisskb/slave/src/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c: warning: 
(near initialization for 'r_stage[0]') [-Wmissing-braces]:  => 224:7
  + /home/kisskb/slave/src/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c: warning: 
(near initialization for 'stage[0]') [-Wmissing-braces]:  => 223:7
  + /home/kisskb/slave/src/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c: warning: 
missing braces around initializer [-Wmissing-braces]:  => 223:7, 224:7
  + /home/kisskb/slave/src/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: warning: 
(near initialization for 'pe.left') [-Wmissing-braces]:  => 893:9
  + /home/kisskb/slave/src/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: warning: 
(near initialization for 'step.x') [-Wmissing-braces]:  => 892:9
  + /home/kisskb/slave/src/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: warning: 
missing braces around initializer [-Wmissing-braces]:  => 892:9, 893:9
  + 
/home/kisskb/slave/src/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r367.c: 
warning: 'acr_r367_ls_write_wpr' uses dynamic stack allocation [enabled by 
default]:  => 302:1
  + 
/home/kisskb/slave/src/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_msgqueue.c:
 warning: 'acr_ls_msgqueue_post_run' uses dynamic stack allocation [enabled by 
default]:  => 100:1
  + /home/kisskb/slave/src/drivers/ide/ide-floppy.c: warning: 'pc' may be used 
uninitialized in this function [-Wuninitialized]:  => 301:2
  + /home/kisskb/slave/src/drivers/iio/industrialio-core.c: warning: 'name' may 
be used uninitialized in this function [-Wunin

Re: __user with scalar data types

[Gerd Hoffmann]

  Hi,

> Yep that's cargo-culted, but from a quick grep only msm and qxl
> headers do this (the other __user annotations in uapi/drm are for
> pointers, where it's correct). Adding those maintainers.

Yep, those looks pointless indeed.

> Also, if you use u64_to_user_ptr helper macro sparse should have
> caught this (if not we'd need to improve the macro).

And qxl should actually use it.

Fix attached (compile-tested only so far), does that look ok?

cheers,
  Gerddiff --git a/include/uapi/drm/qxl_drm.h b/include/uapi/drm/qxl_drm.h
index 7eef422130..880999d2d8 100644
--- a/include/uapi/drm/qxl_drm.h
+++ b/include/uapi/drm/qxl_drm.h
@@ -80,8 +80,8 @@ struct drm_qxl_reloc {
 };
 
 struct drm_qxl_command {
-	__u64	 __user command; /* void* */
-	__u64	 __user relocs; /* struct drm_qxl_reloc* */
+	__u64		command; /* void* */
+	__u64		relocs; /* struct drm_qxl_reloc* */
 	__u32		type;
 	__u32		command_size;
 	__u32		relocs_num;
@@ -91,7 +91,7 @@ struct drm_qxl_command {
 struct drm_qxl_execbuffer {
 	__u32		flags;		/* for future use */
 	__u32		commands_num;
-	__u64	 __user commands;	/* struct drm_qxl_command* */
+	__u64		commands;	/* struct drm_qxl_command* */
 };
 
 struct drm_qxl_update_area {
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index 0b82a87916..31effed4a3 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -163,7 +163,7 @@ static int qxl_process_single_command(struct qxl_device *qdev,
 		return -EINVAL;
 
 	if (!access_ok(VERIFY_READ,
-		   (void *)(unsigned long)cmd->command,
+		   u64_to_user_ptr(cmd->command),
 		   cmd->command_size))
 		return -EFAULT;
 
@@ -183,7 +183,9 @@ static int qxl_process_single_command(struct qxl_device *qdev,
 
 	/* TODO copy slow path code from i915 */
 	fb_cmd = qxl_bo_kmap_atomic_page(qdev, cmd_bo, (release->release_offset & PAGE_SIZE));
-	unwritten = __copy_from_user_inatomic_nocache(fb_cmd + sizeof(union qxl_release_info) + (release->release_offset & ~PAGE_SIZE), (void *)(unsigned long)cmd->command, cmd->command_size);
+	unwritten = __copy_from_user_inatomic_nocache
+		(fb_cmd + sizeof(union qxl_release_info) + (release->release_offset & ~PAGE_SIZE),
+		 u64_to_user_ptr(cmd->command), cmd->command_size);
 
 	{
 		struct qxl_drawable *draw = fb_cmd;
@@ -201,10 +203,9 @@ static int qxl_process_single_command(struct qxl_device *qdev,
 	num_relocs = 0;
 	for (i = 0; i < cmd->relocs_num; ++i) {
 		struct drm_qxl_reloc reloc;
+		struct drm_qxl_reloc __user *u = u64_to_user_ptr(cmd->relocs);
 
-		if (copy_from_user(&reloc,
-   &((struct drm_qxl_reloc *)(uintptr_t)cmd->relocs)[i],
-   sizeof(reloc))) {
+		if (copy_from_user(&reloc, u + i, sizeof(reloc))) {
 			ret = -EFAULT;
 			goto out_free_bos;
 		}
@@ -282,10 +283,10 @@ static int qxl_execbuffer_ioctl(struct drm_device *dev, void *data,
 
 	for (cmd_num = 0; cmd_num < execbuffer->commands_num; ++cmd_num) {
 
-		struct drm_qxl_command *commands =
-			(struct drm_qxl_command *)(uintptr_t)execbuffer->commands;
+		struct drm_qxl_command __user *commands =
+			u64_to_user_ptr(execbuffer->commands);
 
-		if (copy_from_user(&user_cmd, &commands[cmd_num],
+		if (copy_from_user(&user_cmd, commands + cmd_num,
    sizeof(user_cmd)))
 			return -EFAULT;
 

Re: [PATCH v2] sched/fair: WARN and refuse to set buddy when !se->on_rq

[Konstantin Khlebnikov]

On 19.06.2017 17:05, Daniel Axtens wrote:

Hi Konstantin and Peter,

Just checking if this version was OK with you - I hadn't heard anything
and I noticed it's not in -next so I just wanted to check to see if
there were any other changes you wanted.


Looks good for me. Exactly that debug helped me alot at that time.



Regards,
Daniel


Daniel Axtens  writes:


If we set a next or last buddy for a se that is not on_rq, we will
end up taking a NULL pointer dereference in wakeup_preempt_entity
via pick_next_task_fair.

Detect when we would be about to do that, throw a warning and
then refuse to actually set it.

This has been suggested at least twice[0][1]: just do it.

[0] https://marc.info/?l=linux-kernel&m=146651668921468&w=2
[1] https://lkml.org/lkml/2016/6/16/663

Cc: Konstantin Khlebnikov 
Cc: Ben Segall 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Daniel Axtens 

---

I recently had to debug a problem with these (we hadn't backported
Konstantin's patches in this area) and this would have saved a lot
of time/pain.

v2: use SCHED_WARN_ON to restrict when the test is run. This is a
 macro for WARN_ON_ONCE, which is convenient.
---
  kernel/sched/fair.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d71109321841..44b94cfe02cb 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6168,8 +6168,11 @@ static void set_last_buddy(struct sched_entity *se)
if (entity_is_task(se) && unlikely(task_of(se)->policy == SCHED_IDLE))
return;
  
-	for_each_sched_entity(se)

+   for_each_sched_entity(se) {
+   if (SCHED_WARN_ON(!se->on_rq))
+   return;
cfs_rq_of(se)->last = se;
+   }
  }
  
  static void set_next_buddy(struct sched_entity *se)

@@ -6177,8 +6180,11 @@ static void set_next_buddy(struct sched_entity *se)
if (entity_is_task(se) && unlikely(task_of(se)->policy == SCHED_IDLE))
return;
  
-	for_each_sched_entity(se)

+   for_each_sched_entity(se) {
+   if (SCHED_WARN_ON(!se->on_rq))
+   return;
cfs_rq_of(se)->next = se;
+   }
  }
  
  static void set_skip_buddy(struct sched_entity *se)

--
2.11.0

Re: Build regressions/improvements in v4.12-rc6

[Geert Uytterhoeven]

On Tue, Jun 20, 2017 at 9:39 AM, Geert Uytterhoeven
 wrote:
> JFYI, when comparing v4.12-rc6[1] to v4.12-rc5[3], the summaries are:
>   - build errors: +4/-

  + /home/kisskb/slave/src/arch/sh/boards/mach-sh03/setup.c: error:
implicit declaration of function 'ioremap_prot'
[-Werror=implicit-function-declaration]:  => 85:2

sh-randconfig

  + error: "__udivdi3" [fs/ufs/ufs.ko] undefined!:  => N/A

Lots of 32-bit platforms

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

[PATCH 0/2] Enable USB dual-role operation for TM2 and TM2E

[Dongwoo Lee]

Since commit 9840354ff429 ("usb: dwc3: Add dual-role support") USB
dual-role operation on TM2 and TM2E can be enabled by simply adding
extcon property. However, exynos5433 dt has the mislabeled dwc3 node,
and thus we should resolve it first to apply the property.

This patchset fixes up the device tree fault and adds extcon property
to activate dual-role operation.

Dongwoo Lee (2):
  arm64: dts: exynos: Fix wrong label for USB 3.0 controller node
  arm64: dts: exynos: Add extcon property for TM2 and TM2E

 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 3 ++-
 arch/arm64/boot/dts/exynos/exynos5433.dtsi| 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

-- 
1.9.1

Re: [PATCH 2/2] mmc: sdhci-of-at91: set clocks and presets after resume from deepest PM

[Adrian Hunter]

On 16/06/17 10:29, Quentin Schulz wrote:
> This adds deepest (Backup+Self-Refresh) PM support to the ATMEL SAMA5D2
> SoC's SDHCI controller.
> 
> When resuming from deepest state, it is required to restore preset
> registers as the registers are lost since VDD core has been shut down
> when entering deepest state on the SAMA5D2. The clocks need to be
> reconfigured as well.
> 
> The other registers and init process are taken care of by the SDHCI
> core.
> 
> Signed-off-by: Quentin Schulz 
> ---
>  drivers/mmc/host/sdhci-of-at91.c | 34 --
>  1 file changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-of-at91.c 
> b/drivers/mmc/host/sdhci-of-at91.c
> index fb8c6011f13d..300513fc1068 100644
> --- a/drivers/mmc/host/sdhci-of-at91.c
> +++ b/drivers/mmc/host/sdhci-of-at91.c
> @@ -207,6 +207,37 @@ static int sdhci_at91_set_clks_presets(struct device 
> *dev)
>  }
>  
>  #ifdef CONFIG_PM

Should be CONFIG_PM_SLEEP for suspend / resume callbacks.

> +static int sdhci_at91_suspend(struct device *dev)
> +{
> + struct sdhci_host *host = dev_get_drvdata(dev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_at91_priv *priv = sdhci_pltfm_priv(pltfm_host);
> + int ret;
> +
> + ret = sdhci_suspend_host(host);
> +
> + if (host->runtime_suspended)
> + return ret;

Suspending while runtime suspended seems like a bad idea.  Have you
considered just adding sdhci_at91_set_clks_presets() to
sdhci_at91_runtime_resume()?

> +
> + clk_disable_unprepare(priv->gck);
> + clk_disable_unprepare(priv->hclock);
> + clk_disable_unprepare(priv->mainck);
> +
> + return ret;
> +}
> +
> +static int sdhci_at91_resume(struct device *dev)
> +{
> + struct sdhci_host *host = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = sdhci_at91_set_clks_presets(dev);
> + if (ret)
> + return ret;
> +
> + return sdhci_resume_host(host);
> +}
> +
>  static int sdhci_at91_runtime_suspend(struct device *dev)
>  {
>   struct sdhci_host *host = dev_get_drvdata(dev);
> @@ -256,8 +287,7 @@ static int sdhci_at91_runtime_resume(struct device *dev)
>  #endif /* CONFIG_PM */
>  
>  static const struct dev_pm_ops sdhci_at91_dev_pm_ops = {
> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> - pm_runtime_force_resume)
> + SET_SYSTEM_SLEEP_PM_OPS(sdhci_at91_suspend, sdhci_at91_resume)
>   SET_RUNTIME_PM_OPS(sdhci_at91_runtime_suspend,
>  sdhci_at91_runtime_resume,
>  NULL)
> 

Re: [ANNOUNCE] v4.11.5-rt1

[Mike Galbraith]

On Mon, 2017-06-19 at 18:29 +0200, Mike Galbraith wrote:
> On Mon, 2017-06-19 at 10:41 -0400, Steven Rostedt wrote:
> > On Mon, 19 Jun 2017 16:13:41 +0200
> > Sebastian Andrzej Siewior  wrote:
> > 
> > 
> > > > Hmm, it shouldn't affect futexes, as it's only called by rtmutex when
> > > > waiter->savestate is true. And that should always be false for futex.  
> > > 
> > > you still have sleeping locks like the hb-lock (which might matter in
> > > case the task blocks on the lock and does not continue for some reason).
> > 
> > But then I'd expect this to be an issue with any spinlock in the kernel.
> 
> Thing to do is set a trap for the bugger.

See ! and ?

vogelweide:~/:[1]# grep MIKE trace 
MIKE 913.728104: start
MIKE  futex_wait-7496  [031] ...   913.729160: sched_process_fork: 
comm=futex_wait pid=7496 child_comm=futex_wait child_pid=7497
MIKE  futex_wait-7496  [031] ...   913.729253: sched_process_fork: 
comm=futex_wait pid=7496 child_comm=futex_wait child_pid=7499
MIKE  futex_wait-7496  [031] ...   913.729307: sched_process_fork: 
comm=futex_wait pid=7496 child_comm=futex_wait child_pid=7500
MIKE  futex_wait-7496  [031] ...   913.729348: sched_process_fork: 
comm=futex_wait pid=7496 child_comm=futex_wait child_pid=7501
MIKE  futex_wait-7496  [031] d...2..   913.729430: sched_switch: 
prev_comm=futex_wait prev_pid=7496 prev_prio=120 prev_state=S ==> 
next_comm=swapper/31 next_pid=0 next_prio=120
MIKE--futex_wait-7500  [005] d...2..   920.040320: sched_switch: 
prev_comm=futex_wait prev_pid=7500 prev_prio=120 prev_state=S ==> 
next_comm=swapper/5 next_pid=0 next_prio=120
MIKE  futex_wait-7497  [058] d...211   920.060009: sched_waking: 
comm=futex_wait pid=7501 prio=120 target_cpu=044
MIKE  futex_wait-7497  [058] d...311   920.060012: sched_wake_idle_without_ipi: 
cpu=44
MIKE  futex_wait-7497  [058] d...311   920.060012: sched_wakeup: 
comm=futex_wait pid=7501 prio=120 target_cpu=044
MIKE--futex_wait-7497  [058] d...2..   920.060035: sched_switch: 
prev_comm=futex_wait prev_pid=7497 prev_prio=120 prev_state=S ==> 
next_comm=swapper/58 next_pid=0 next_prio=120
MIKE  futex_wait-7499  [043] dN..411   920.060035: sched_wakeup: 
comm=ktimersoftd/43 pid=438 prio=0 target_cpu=043
MIKE! futex_wait-7499  [043] .N..111   920.060037: wake_up_lock_sleeper: 
futex_wait:7497 state:1 saved_state:0
MIKE! futex_wait-7499  [043] dN..211   920.060037: try_to_wake_up: 
futex_wait:7497 WF_LOCK_SLEEPER !(p->state:1 & state:2) bailing
MIKE 920.060037: futex_wait-7497 is never awakened again until ^C cleanup, 
7499/7501 still standing
MIKE  futex_wait-7499  [043] 111   920.060066: wake_up_lock_sleeper: 
futex_wait:7501 state:2 saved_state:0
MIKE  futex_wait-7499  [043] d...211   920.060066: try_to_wake_up: 
futex_wait:7501 WF_LOCK_SLEEPER !(p->state:0 & state:2) bailing
MIKE  futex_wait-7499  [043] 111   920.060606: wake_up_lock_sleeper: 
futex_wait:7501 state:2 saved_state:0
MIKE 920.355048: huh? wake_up_lock_sleeper sees state=2 but try_to_wake_up then 
sees state=0 and bails ?!?
MIKE  futex_wait-7501  [044] 111   920.355048: wake_up_lock_sleeper: 
futex_wait:7499 state:2 saved_state:0
MIKE  futex_wait-7501  [044] d...211   920.355049: try_to_wake_up: 
futex_wait:7499 WF_LOCK_SLEEPER !(p->state:0 & state:2) bailing
MIKE  futex_wait-7499  [048] d..h311   920.355060: sched_stat_runtime: 
comm=futex_wait pid=7499 runtime=168537 [ns] vruntime=4850005377 [ns]
MIKE  futex_wait-7499  [048] d...311   920.355061: sched_waking: 
comm=ksoftirqd/48 pid=489 prio=120 target_cpu=048
MIKE  futex_wait-7499  [048] d...411   920.355062: sched_stat_runtime: 
comm=futex_wait pid=7499 runtime=2972 [ns] vruntime=4850008349 [ns]
MIKE  futex_wait-7499  [048] d.L.411   920.355063: sched_wakeup: 
comm=ksoftirqd/48 pid=489 prio=120 target_cpu=048
MIKE  futex_wait-7499  [048] d.L.311   920.355064: sched_waking: 
comm=ktimersoftd/48 pid=488 prio=0 target_cpu=048
MIKE  futex_wait-7499  [048] dNL.411   920.355065: sched_wakeup: 
comm=ktimersoftd/48 pid=488 prio=0 target_cpu=048
MIKE  futex_wait-7499  [048] .NL.111   920.355066: wake_up_lock_sleeper: 
futex_wait:7501 state:0 saved_state:0
MIKE  futex_wait-7499  [048] dNL.211   920.355067: try_to_wake_up: 
futex_wait:7501 WF_LOCK_SLEEPER !(p->state:0 & state:2) bailing
MIKE  futex_wait-7499  [048] dNL.211   920.355067: sched_stat_runtime: 
comm=futex_wait pid=7499 runtime=2011 [ns] vruntime=4850010360 [ns]
MIKE  futex_wait-7499  [048] d...211   920.355068: sched_switch: 
prev_comm=futex_wait prev_pid=7499 prev_prio=120 prev_state=R+ ==> 
next_comm=ktimersoftd/48 next_pid=488 next_prio=0
MIKE   <...>-488   [048] d...2..   920.355070: sched_switch: 
prev_comm=ktimersoftd/48 prev_pid=488 prev_prio=0 prev_state=S ==> 
next_comm=ksoftirqd/48 next_pid=489 next_prio=120
MIKE   <...>-489   [048] d...2..   920.355071: sched_stat_runtime: 
comm=ksoftirqd/48 pid=489 runtime=1925 [ns] vruntime=4838010274 [ns]
MIKE   <...>-489   [048] d...2..   920.355072: sched_switch: 
prev_comm=

Re: [PATCH v10 4/5] i2c: aspeed: added driver for Aspeed I2C

[Wolfram Sang]

On Mon, Jun 19, 2017 at 05:58:19PM -0700, Brendan Higgins wrote:
> On Mon, Jun 19, 2017 at 7:21 AM, Wolfram Sang  wrote:
> >
> > And any chance for a MAINTAINERS entry?
> >
> 
> We already have one:
> http://elixir.free-electrons.com/linux/v4.11.5/source/MAINTAINERS#L1090
> 
> However, if you would like me to own this driver, I could add an entry
> for myself.

As far as get_maintainers.pl prints out someone responsibe, I am very
happy. The above line won't work for I2C (and maybe some other
subsystems), though,  because we are one directory level deeper
(drivers/i2c/busses/*aspeed*). That might want fixing.



signature.asc
Description: PGP signature

[PATCH] backlight: pwm_bl: make of_device_ids const

[Arvind Yadav]

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by  work with const
of_device_ids. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/video/backlight/pwm_bl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 002f1ce..9bd1768 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -178,7 +178,7 @@ static int pwm_backlight_parse_dt(struct device *dev,
return 0;
 }
 
-static struct of_device_id pwm_backlight_of_match[] = {
+static const struct of_device_id pwm_backlight_of_match[] = {
{ .compatible = "pwm-backlight" },
{ }
 };
-- 
1.9.1

[criu] 1M guard page ruined restore

[Cyrill Gorcunov]

Hi Hugh! We're running our tests on latest vanilla kernel all the time,
and recently we've got an issue on restore:

https://github.com/xemul/criu/issues/322

 | (00.410614)  4: cg: Cgroups 1 inherited from parent
 | (00.410858)  4: Opened local page read 3 (parent 0)
 | (00.410961)  4: premap 0x40-0x406000 -> 
7fe65badf000
 | (00.410981)  4: premap 0x605000-0x606000 -> 
7fe65bae5000
 | (00.410997)  4: premap 0x606000-0x607000 -> 
7fe65bae6000
 | (00.411013)  4: premap 0x00025a-0x00025c1000 -> 
7fe65bae7000
 | (00.411036)  4: Error (criu/mem.c:726): Unable to remap a private vma: 
Invalid argument
 | (00.412779)  1: Error (criu/cr-restore.c:1465): 4 exited, status=1

Andrew has narrowed it down to the commit

 | commit 1be7107fbe18eed3e319a6c3e83c78254b693acb
 | Author: Hugh Dickins 
 | Date:   Mon Jun 19 04:03:24 2017 -0700
 | 
 | mm: larger stack guard gap, between vmas

and looking into the patch I see the procfs output has been changed

 | diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
 | index f0c8b33..520802d 100644
 | --- a/fs/proc/task_mmu.c
 | +++ b/fs/proc/task_mmu.c
 | @@ -300,11 +300,7 @@ show_map_vma(struct seq_file *m, struct vm_area_struct 
*vma, int is_pid)
 |  
 | /* We don't show the stack guard page in /proc/maps */
 | start = vma->vm_start;
 | -   if (stack_guard_page_start(vma, start))
 | -   start += PAGE_SIZE;
 | end = vma->vm_end;
 | -   if (stack_guard_page_end(vma, end))
 | -   end -= PAGE_SIZE;
 |  
 | seq_setwidth(m, 25 + sizeof(void *) * 6 - 1);
 | seq_printf(m, "%08lx-%08lx %c%c%c%c %08llx %02x:%02x %lu ",

For which we of course are not ready because we've been implying the
guard page is returned here so we adjust addresses locally when saving
them into images.

So now we need to figure out somehow if show_map_vma accounts 
[PAGE_SIZE|guard_area] or not,
I guess we might use kernel version here but it won't be working fine on custom 
kernels,
or kernels with the patch backported.

Second I guess we might need to detect @stack_guard_gap runtime as
well but not yet sure because we only have found this problem and
hasn't been investigating it deeply yet. Hopefully will do in a
day or couple (I guess we still have some time before the final
kernel release).

Cyrill

Re: [PATCH 04/11] S.A.R.A. USB Filtering

[Salvatore Mesoraca]

2017-06-20 9:07 GMT+02:00 Pavel Machek :
> Hmm. Given that USB device provides vendor id/product id, this does
> not really stop anyone, right?
>
> AFAICT you can still get USB stick with vid/pid of logitech keyboard,
> and kernel will recognize it as a usb stick.

There are a number of ways by which a device can be assigned to a driver.
vid/pid is the most common for the most esoteric devices: i.e. less used/most
dangerous.
However you are right, a final version of this feature should have included
"interface matching" too and even something much more specific like serial
matching.
Anyway, because of lack of interest in having this feature included in kernel
space (something similar can already be done in user-space) it has been
abandoned.
You are answering to an old version of S.A.R.A. that can now be considered
obsolete.
Thank you anyway for your comment.

Salvatore

Re: [PATCH V2 1/2] hwmon: (ibmpowernv) introduce a legacy_compatibles array

[Cédric Le Goater]

On 06/20/2017 09:15 AM, Shilpasri G Bhat wrote:
> 
> 
> On 06/20/2017 11:36 AM, Cédric Le Goater wrote:
>> On 06/20/2017 07:08 AM, Shilpasri G Bhat wrote:
>>> From: Cédric Le Goater 
>>>
>>> Today, the type of a PowerNV sensor system is determined with the
>>> "compatible" property for legacy Firmwares and with the "sensor-type"
>>> for newer ones. The same array of strings is used for both to do the
>>> matching and this raises some issue to introduce new sensor types.
>>>
>>> Let's introduce two different arrays (legacy and current) to make
>>> things easier for new sensor types.
>>>
>>> Signed-off-by: Cédric Le Goater 
>>> Tested-by: Shilpasri G Bhat 
>>
>> Did you test on a Tuleta (IBM Power) system ? 
> 
> I have tested this patch on P9 FSP and Firestone.

OK. I just gave it a try on a Tuleta, P8 FSP, IBM Power system
Looks good.

Thanks,

C.

> 
>>
>> Thanks,
>>
>> C. 
>>
>>> ---
>>>  drivers/hwmon/ibmpowernv.c | 26 ++
>>>  1 file changed, 18 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
>>> index 862b832..6d8909c 100644
>>> --- a/drivers/hwmon/ibmpowernv.c
>>> +++ b/drivers/hwmon/ibmpowernv.c
>>> @@ -55,17 +55,27 @@ enum sensors {
>>>  
>>>  #define INVALID_INDEX (-1U)
>>>  
>>> +/*
>>> + * 'compatible' string properties for sensor types as defined in old
>>> + * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
>>> + */
>>> +static const char * const legacy_compatibles[] = {
>>> +   "ibm,opal-sensor-cooling-fan",
>>> +   "ibm,opal-sensor-amb-temp",
>>> +   "ibm,opal-sensor-power-supply",
>>> +   "ibm,opal-sensor-power"
>>> +};
>>> +
>>>  static struct sensor_group {
>>> -   const char *name;
>>> -   const char *compatible;
>>> +   const char *name; /* matches property 'sensor-type' */
>>> struct attribute_group group;
>>> u32 attr_count;
>>> u32 hwmon_index;
>>>  } sensor_groups[] = {
>>> -   {"fan", "ibm,opal-sensor-cooling-fan"},
>>> -   {"temp", "ibm,opal-sensor-amb-temp"},
>>> -   {"in", "ibm,opal-sensor-power-supply"},
>>> -   {"power", "ibm,opal-sensor-power"}
>>> +   { "fan"   },
>>> +   { "temp"  },
>>> +   { "in"},
>>> +   { "power" }
>>>  };
>>>  
>>>  struct sensor_data {
>>> @@ -239,8 +249,8 @@ static int get_sensor_type(struct device_node *np)
>>> enum sensors type;
>>> const char *str;
>>>  
>>> -   for (type = 0; type < MAX_SENSOR_TYPE; type++) {
>>> -   if (of_device_is_compatible(np, sensor_groups[type].compatible))
>>> +   for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
>>> +   if (of_device_is_compatible(np, legacy_compatibles[type]))
>>> return type;
>>> }
>>>  
>>>
>>
> 

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

[Willy Tarreau]

On Tue, Jun 20, 2017 at 09:31:00AM +0200, Rafal Milecki wrote:
> Do you know if my name will appear correctly in git [0]?
> 
> [0] 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=linux-3.10.y

I would have almost promised it was going to be OK but it's bogus so
it probably happened during the patch manipulation, thus I'll fix it
before the final release :

   
https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/linux-stable.git/commit/?h=linux-3.10.y-queue&id=73148299c53be25

Willy

Re: [PATCH] arm: aspeed: Add Aspeed board file with clocksource devicetree fixup

[Linus Walleij]

On Fri, Jun 9, 2017 at 2:52 PM, Andrew Jeffery  wrote:

> So the fttmr010 bindings describe the clocks and clock-names properties
> as optional (a little confusingly, "Optionally required properties").

We should remove that. The timer frequency is strictly required.

> I guess keeping in mind the bindings describe the hardware and not the
> driver this might be reasonable, but the driver fails init if they're
> not present. arch/arm/boot/dts/moxart.dtsi doesn't specify clock-names
> either so I would have thought systems based on it would also fail.

It was added in
commit f46b563f2f270e451b2e1cee78573508cc1de256
"ARM: dts: augment Moxa and Aspeed DTS for FTTMR010"

Moxart only uses DT for boot, and Jonas controls all deployments of the
mainline kernel.

> Regardless, if it's the case that Moxa systems now fail to init the
> clocksource then the Aspeed-specific init_time() solution is even less
> attractive. moxart.dtsi dates back to December 2013 ("448e7edefa92 ARM:
> moxart: add MOXA ART SoC device tree files").

Moxart is deploying the DTBs with the kernel, they go hand-in-hand.
Backward compatibility with old DTBs here would just be an academic
exercise.

> The old binding is less of a problem for Aspeed systems as we don't yet
> have a clk driver upstream. Joel only recently added fixed-clock nodes
> in 4.12 so Aspeed systems could boot without DTS modifications.

The mentioned commit also adds the clocks to Aspeed AFAICT, is there
any problem in the real world, like did I miss some Aspeed platform?

Patching around drivers to make old DTBs work is something we should
only do when there are wide deployments for common users, such as people
buying products with a DTB inside them. Until such devices are shipped,
I consider the DT bindings still in flux.

Yours,
Linus Walleij

Re: [PATCH 2/2] mmc: sdhci-of-at91: set clocks and presets after resume from deepest PM

[Quentin Schulz]

Hi Adrian,

On 20/06/2017 09:39, Adrian Hunter wrote:
> On 16/06/17 10:29, Quentin Schulz wrote:
>> This adds deepest (Backup+Self-Refresh) PM support to the ATMEL SAMA5D2
>> SoC's SDHCI controller.
>>
>> When resuming from deepest state, it is required to restore preset
>> registers as the registers are lost since VDD core has been shut down
>> when entering deepest state on the SAMA5D2. The clocks need to be
>> reconfigured as well.
>>
>> The other registers and init process are taken care of by the SDHCI
>> core.
>>
>> Signed-off-by: Quentin Schulz 
>> ---
>>  drivers/mmc/host/sdhci-of-at91.c | 34 --
>>  1 file changed, 32 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-of-at91.c 
>> b/drivers/mmc/host/sdhci-of-at91.c
>> index fb8c6011f13d..300513fc1068 100644
>> --- a/drivers/mmc/host/sdhci-of-at91.c
>> +++ b/drivers/mmc/host/sdhci-of-at91.c
>> @@ -207,6 +207,37 @@ static int sdhci_at91_set_clks_presets(struct device 
>> *dev)
>>  }
>>  
>>  #ifdef CONFIG_PM
> 
> Should be CONFIG_PM_SLEEP for suspend / resume callbacks.
> 

So I let this CONFIG_PM around the runtime_suspend/resume but put
another CONFIG_PM_SLEEP around the suspend/resume functions?

>> +static int sdhci_at91_suspend(struct device *dev)
>> +{
>> +struct sdhci_host *host = dev_get_drvdata(dev);
>> +struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> +struct sdhci_at91_priv *priv = sdhci_pltfm_priv(pltfm_host);
>> +int ret;
>> +
>> +ret = sdhci_suspend_host(host);
>> +
>> +if (host->runtime_suspended)
>> +return ret;
> 
> Suspending while runtime suspended seems like a bad idea.  Have you
> considered just adding sdhci_at91_set_clks_presets() to
> sdhci_at91_runtime_resume()?
> 

Adding sdhci_at91_set_clks_presets() to runtime_resume() seems a bad
idea as well. You don't need to recompute the clock rate, set it and set
the presets registers each time you do a runtime_resume. As the
runtime_pm of sdhci has a quite aggressive policy of activation, this
seems like a bad idea on the optimization side.

Thanks,
Quentin

>> +
>> +clk_disable_unprepare(priv->gck);
>> +clk_disable_unprepare(priv->hclock);
>> +clk_disable_unprepare(priv->mainck);
>> +
>> +return ret;
>> +}
>> +
>> +static int sdhci_at91_resume(struct device *dev)
>> +{
>> +struct sdhci_host *host = dev_get_drvdata(dev);
>> +int ret;
>> +
>> +ret = sdhci_at91_set_clks_presets(dev);
>> +if (ret)
>> +return ret;
>> +
>> +return sdhci_resume_host(host);
>> +}
>> +
>>  static int sdhci_at91_runtime_suspend(struct device *dev)
>>  {
>>  struct sdhci_host *host = dev_get_drvdata(dev);
>> @@ -256,8 +287,7 @@ static int sdhci_at91_runtime_resume(struct device *dev)
>>  #endif /* CONFIG_PM */
>>  
>>  static const struct dev_pm_ops sdhci_at91_dev_pm_ops = {
>> -SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>> -pm_runtime_force_resume)
>> +SET_SYSTEM_SLEEP_PM_OPS(sdhci_at91_suspend, sdhci_at91_resume)
>>  SET_RUNTIME_PM_OPS(sdhci_at91_runtime_suspend,
>> sdhci_at91_runtime_resume,
>> NULL)
>>
> 

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [GIT PULL] pinctrl: samsung: Pinctrl update for v4.13

[Linus Walleij]

On Fri, Jun 9, 2017 at 6:48 PM, Krzysztof Kozlowski  wrote:

> The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6:
>
>   Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/samsung.git 
> tags/samsung-pinctrl-4.13
>
> for you to fetch changes up to a453f3693f2aa9ebba623f8cff1e3d7c5df96ddd:
>
>   pinctrl: samsung: Explicitly cast pointer returned by of_iomap() to iomem 
> (2017-06-07 20:40:48 +0200)

Pulled into my "devel" branch on the pin control tree.

Pushing it to the build servers hoping all works.

Thanks for your efforts to maintain Samsung pin control, it is
much appreciated!

Yours,
Linus Walleij

Re: [PATCH v11 5/6] i2c: designware: add SLAVE mode functions

[Jarkko Nikula]

On 06/19/2017 07:22 PM, Wolfram Sang wrote:



I wonder if we haven't reached a state where Luis just could fix the
buildbot error (missing 'select I2C_SLAVE') and the thing pointed out by
Andy and we handle further small fixes incrementally during the v4.13
cycle? AFAICS there is no major show-stopper, or am I wrong?


I would go with the following plan:
1. Push 1-4
2. Resend 5-6 with addressed pointed issues for one more (fast) round


Good, so I'll pick up 1-4 now. Thanks!


Yep, that's easier for everyone.

--
Jarkko

Re: [PATCH 1/2] mmc: sdhci-of-at91: factor out clks and presets setting

[Quentin Schulz]

Hi Adrian,

On 20/06/2017 08:36, Adrian Hunter wrote:
> On 16/06/17 10:29, Quentin Schulz wrote:
>> The setting of clocks and presets is currently done in probe only but
>> once deep PM support is added, it'll be needed in the resume function.
>>
>> Let's create a function for this setting.
>>
>> Signed-off-by: Quentin Schulz 
> 
> Apart from cosmetic comment below:
> 
> Acked-by: Adrian Hunter 
> 
>> ---
>>  drivers/mmc/host/sdhci-of-at91.c | 147 
>> ++-
>>  1 file changed, 82 insertions(+), 65 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-of-at91.c 
>> b/drivers/mmc/host/sdhci-of-at91.c
>> index 7611fd679f1a..fb8c6011f13d 100644
>> --- a/drivers/mmc/host/sdhci-of-at91.c
>> +++ b/drivers/mmc/host/sdhci-of-at91.c
>> @@ -128,6 +128,84 @@ static const struct of_device_id sdhci_at91_dt_match[] 
>> = {
>>  };
>>  MODULE_DEVICE_TABLE(of, sdhci_at91_dt_match);
>>  
>> +static int sdhci_at91_set_clks_presets(struct device *dev)
>> +{
>> +struct sdhci_host *host = dev_get_drvdata(dev);
>> +struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> +struct sdhci_at91_priv *priv = sdhci_pltfm_priv(pltfm_host);
>> +int ret;
>> +unsigned intcaps0, caps1;
>> +unsigned intclk_base, clk_mul;
>> +unsigned intgck_rate, real_gck_rate;
>> +unsigned intpreset_div;
> 
> Too much whitespace.
> 

Simply moved some variables from the original code (see sdhci_at91_probe
below).

Thanks,
Quentin

>> +
>> +/*
>> + * The mult clock is provided by as a generated clock by the PMC
>> + * controller. In order to set the rate of gck, we have to get the
>> + * base clock rate and the clock mult from capabilities.
>> + */
>> +clk_prepare_enable(priv->hclock);
>> +caps0 = readl(host->ioaddr + SDHCI_CAPABILITIES);
>> +caps1 = readl(host->ioaddr + SDHCI_CAPABILITIES_1);
>> +clk_base = (caps0 & SDHCI_CLOCK_V3_BASE_MASK) >> SDHCI_CLOCK_BASE_SHIFT;
>> +clk_mul = (caps1 & SDHCI_CLOCK_MUL_MASK) >> SDHCI_CLOCK_MUL_SHIFT;
>> +gck_rate = clk_base * 100 * (clk_mul + 1);
>> +ret = clk_set_rate(priv->gck, gck_rate);
>> +if (ret < 0) {
>> +dev_err(dev, "failed to set gck");
>> +clk_disable_unprepare(priv->hclock);
>> +return ret;
>> +}
>> +/*
>> + * We need to check if we have the requested rate for gck because in
>> + * some cases this rate could be not supported. If it happens, the rate
>> + * is the closest one gck can provide. We have to update the value
>> + * of clk mul.
>> + */
>> +real_gck_rate = clk_get_rate(priv->gck);
>> +if (real_gck_rate != gck_rate) {
>> +clk_mul = real_gck_rate / (clk_base * 100) - 1;
>> +caps1 &= (~SDHCI_CLOCK_MUL_MASK);
>> +caps1 |= ((clk_mul << SDHCI_CLOCK_MUL_SHIFT) &
>> +  SDHCI_CLOCK_MUL_MASK);
>> +/* Set capabilities in r/w mode. */
>> +writel(SDMMC_CACR_KEY | SDMMC_CACR_CAPWREN,
>> +   host->ioaddr + SDMMC_CACR);
>> +writel(caps1, host->ioaddr + SDHCI_CAPABILITIES_1);
>> +/* Set capabilities in ro mode. */
>> +writel(0, host->ioaddr + SDMMC_CACR);
>> +dev_info(dev, "update clk mul to %u as gck rate is %u Hz\n",
>> + clk_mul, real_gck_rate);
>> +}
>> +
>> +/*
>> + * We have to set preset values because it depends on the clk_mul
>> + * value. Moreover, SDR104 is supported in a degraded mode since the
>> + * maximum sd clock value is 120 MHz instead of 208 MHz. For that
>> + * reason, we need to use presets to support SDR104.
>> + */
>> +preset_div = DIV_ROUND_UP(real_gck_rate, 2400) - 1;
>> +writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
>> +   host->ioaddr + SDHCI_PRESET_FOR_SDR12);
>> +preset_div = DIV_ROUND_UP(real_gck_rate, 5000) - 1;
>> +writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
>> +   host->ioaddr + SDHCI_PRESET_FOR_SDR25);
>> +preset_div = DIV_ROUND_UP(real_gck_rate, 1) - 1;
>> +writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
>> +   host->ioaddr + SDHCI_PRESET_FOR_SDR50);
>> +preset_div = DIV_ROUND_UP(real_gck_rate, 12000) - 1;
>> +writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
>> +   host->ioaddr + SDHCI_PRESET_FOR_SDR104);
>> +preset_div = DIV_ROUND_UP(real_gck_rate, 5000) - 1;
>> +writew(SDHCI_AT91_PRESET_COMMON_CONF | preset_div,
>> +   host->ioaddr + SDHCI_PRESET_FOR_DDR50);
>> +
>> +clk_prepare_enable(priv->mainck);
>> +clk_prepare_enable(priv->gck);
>> +
>> +return 0;
>> +}
>> +
>>  #ifdef CONFIG_PM
>>  static int sdhci_at91_runtime_suspend(struct device *dev)
>>  {
>> @@ -192,11 +270,7 @@ static int sdhci_at91_probe(struct platform_device 
>> *pdev)
>>  struct sdhci_host   *host;
>>

Re: [PATCH v6 02/10] gpio-exar/8250-exar: Fix passing in of parent PCI device

[Linus Walleij]

On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka  wrote:

> This fixes reloading of the GPIO driver for the same platform device
> instance as created by the exar UART driver: First of all, the driver
> sets drvdata to its own value during probing and does not restore the
> original value on exit. But this won't help anyway as the core clears
> drvdata after the driver left.
>
> Set the platform device parent instead.
>
> Signed-off-by: Jan Kiszka 
> Reviewed-by: Andy Shevchenko 
> Acked-by: Linus Walleij 
> Acked-by: Greg Kroah-Hartman 

Patch applied to the GPIO tree so we advance this series.

Patch 1 does not apply.

Let's see how it goes.

Yours,
Linus Walleij

Re: [PATCH v6 03/10] gpio: exar: Allocate resources on behalf of the platform device

[Linus Walleij]

On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka  wrote:

> Do not allocate resources on behalf of the parent device but on our own.
> Otherwise, cleanup does not properly work if gpio-exar is removed but
> not the parent device.
>
> Signed-off-by: Jan Kiszka 
> Reviewed-by: Andy Shevchenko 
> Acked-by: Linus Walleij 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] random: silence compiler warnings and fix race

[Jason A. Donenfeld]

Hey Ted,

On Tue, Jun 20, 2017 at 02:03:44AM -0400, Theodore Ts'o wrote:
> I actually had set up an earlier version of your patch for on Saturday
> while I was in Beijing.  (Like Linus, I'm attending the LinuxCon China
> conference Monday and Tuesday.)  I had even created the signed tag,
> I've since respun the commit to reflect your newer patch (see the
> random_for_linus_stable tag on random.git) and rebased the dev branch
> on top of that.  Please take a look and comment.

So it looks like you've gone with 4a072c71f49. If that looks good
(moving the lock, etc) to you, then great, we're done. If there are
still locking objections (are there?), then we'll need to revisit.

> but I didn't send the pull request to Linus because I was waiting to
> see about how discussions over the locking strategy and the spammy log
> messages on PowerPC was going to get resolved.
> The other open issue I want to resolve before sending a pull request
> this week is whether we want to change the default for
> CONFIG_WARN_UNSEEDED_RANDOM so that the answer is 'n'.

In the v1 of this patch many moons ago, it was just vanilla, default y,
but due to the spamminess, I thought folks would revolt. So I made a
change:

Specifically, I added `depends on DEBUG_KERNEL`. This means that these
useful warnings will only poke other kernel developers. This is probably
exactly what we want. If the various associated developers see a warning
coming from their particular subsystem, they'll be more motivated to
fix it. Ordinary users on distribution kernels shouldn't see the
warnings or the spam at all, since typically users aren't using
DEBUG_KERNEL.

Then, to make things _even less_ annoying to kernel developers, you
added a nice patch on top to squelch repeated messages.

So, I still think this current strategy is a good one, of default y, but
depends on DEBUG_KERNEL.

Regards,
Jason

Re: [RFC v2 07/12] powerpc: Macro the mask used for checking DSI exception

[Anshuman Khandual]

On 06/17/2017 09:22 AM, Ram Pai wrote:
> Replace the magic number used to check for DSI exception
> with a meaningful value.
> 
> Signed-off-by: Ram Pai 
> ---
>  arch/powerpc/include/asm/reg.h   | 9 -
>  arch/powerpc/kernel/exceptions-64s.S | 2 +-
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index 7e50e47..2dcb8a1 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -272,16 +272,23 @@
>  #define SPRN_DAR 0x013   /* Data Address Register */
>  #define SPRN_DBCR0x136   /* e300 Data Breakpoint Control Reg */
>  #define SPRN_DSISR   0x012   /* Data Storage Interrupt Status Register */
> +#define   DSISR_BIT320x8000  /* not defined */
>  #define   DSISR_NOHPTE   0x4000  /* no translation found 
> */
> +#define   DSISR_PAGEATTR_CONFLT  0x2000  /* page attribute 
> conflict */
> +#define   DSISR_BIT350x1000  /* not defined */
>  #define   DSISR_PROTFAULT0x0800  /* protection fault */
>  #define   DSISR_BADACCESS0x0400  /* bad access to CI or G */
>  #define   DSISR_ISSTORE  0x0200  /* access was a store */
>  #define   DSISR_DABRMATCH0x0040  /* hit data breakpoint */
> -#define   DSISR_NOSEGMENT0x0020  /* SLB miss */
>  #define   DSISR_KEYFAULT 0x0020  /* Key fault */
> +#define   DSISR_BIT430x0010  /* not defined */
>  #define   DSISR_UNSUPP_MMU   0x0008  /* Unsupported MMU config */
>  #define   DSISR_SET_RC   0x0004  /* Failed setting of 
> R/C bits */
>  #define   DSISR_PGDIRFAULT  0x0002  /* Fault on page directory */
> +#define   DSISR_PAGE_FAULT_MASK (DSISR_BIT32 | \
> + DSISR_PAGEATTR_CONFLT | \
> + DSISR_BADACCESS |   \
> + DSISR_BIT43)

Sorry missed this one. Seems like there are couple of unnecessary
line additions in the subsequent patch which adds the new PKEY
reason code.

-#define   DSISR_PAGE_FAULT_MASK (DSISR_BIT32 | \
-   DSISR_PAGEATTR_CONFLT | \
-   DSISR_BADACCESS |   \
+#define   DSISR_PAGE_FAULT_MASK (DSISR_BIT32 | \
+   DSISR_PAGEATTR_CONFLT | \
+   DSISR_BADACCESS |   \
+   DSISR_KEYFAULT |\
DSISR_BIT43)

Re: [PATCH v6 05/10] gpio: exar: Fix reading of directions and values

[Linus Walleij]

On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka  wrote:

> First, the logic for translating a register bit to the return code of
> exar_get_direction and exar_get_value were wrong. And second, there was
> a flip regarding the register bank in exar_get_direction.
>
> Signed-off-by: Jan Kiszka 
> Reviewed-by: Andy Shevchenko 
> Acked-by: Linus Walleij 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v6 04/10] gpio: exar: Fix iomap request

[Linus Walleij]

On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka  wrote:

> The UART driver already maps the resource for us. Trying to do this here
> only fails and leaves us with a non-working device.
>
> Signed-off-by: Jan Kiszka 
> Reviewed-by: Andy Shevchenko 
> Acked-by: Linus Walleij 

This patch does not apply to the GPIO tree.

I don't know why.

Yours,
Linus Walleij

Re: [PATCH v2] mfd: Add driver for RAVE Supervisory Processor

[Lee Jones]

On Mon, 12 Jun 2017, Andrey Smirnov wrote:

> Add a driver for RAVE Supervisory Processor, an MCU implementing
> varoius bits of housekeeping functionality (watchdoging, backlight
> control, LED control, etc) on RAVE family of products by Zodiac
> Inflight Innovations.
> 
> This driver implementes core MFD/serdev device as well as
> communication subroutines necessary for commanding the device.
> 
> Cc: cphe...@gmail.com
> Cc: Lucas Stach 
> Cc: Nikita Yushchenko 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov 
> ---
> 
> Changes since [v1]:
> 
>  - Fix MODULE_LICENSE to specify "GPL v2"
> 
>  - Fix a bug in rave_sp_get_status()
> 
>  - Use %zu to fix warning repored by kbuild test robot
> 
>  - Remove "status" properties from examples zii,rave-sp.txt as well as
>clarify the fact that device node is expected to be a child of a
>serial device node
> 
> NOTE:
> 
>  * The driver for "zii,rave-sp-watchdog" exists, but I haven't
>submitted it yet, becuase I wanted to make sure that API exposed by
>this MFD is acceptable and doesn't need drastic changes
> 
>  * This driver is dependent on crc_ccitt_false() introduced in
>2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next'
> 
> 
> [v1] lkml.kernel.org/r/20170606180643.14258-1-andrew.smir...@gmail.com
> 
> 
>  .../devicetree/bindings/mfd/zii,rave-sp.txt|   36 +

This should be a separate patch.

>  drivers/mfd/Kconfig|9 +
>  drivers/mfd/Makefile   |1 +
>  drivers/mfd/rave-sp.c  | 1009 
> 
>  include/linux/rave-sp.h|   54 ++
>  5 files changed, 1109 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/zii,rave-sp.txt
>  create mode 100644 drivers/mfd/rave-sp.c
>  create mode 100644 include/linux/rave-sp.h
> 
> diff --git a/Documentation/devicetree/bindings/mfd/zii,rave-sp.txt 
> b/Documentation/devicetree/bindings/mfd/zii,rave-sp.txt
> new file mode 100644
> index 000..903c889
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/zii,rave-sp.txt
> @@ -0,0 +1,36 @@
> +Zodiac Inflight Innovations RAVE Supervisory Processor
> +
> +RAVE Supervisory Processor communicates with SoC over UART and is
> +presented to the kernel as a "serdev". Given that it is expected that

Please revisit this sentence.

> +its device-tree node is specified as a child of a node corresponding
> +to UART controller used for communication.

This is unusual.  I believe we sometimes do this with I2C devices, but
we don't normally have the supported comms medium as the parent.

> +Required parent device properties:
> +
> + - compatible: Should be one of:
> + - "zii,rave-sp-niu"
> + - "zii,rave-sp-mezz"
> + - "zii,rave-sp-esb"
> + - "zii,rave-sp-rdu1"
> + - "zii,rave-sp-rdu2"
> +
> + - current-speed: Should be set to baud rate SP device is using
> +
> +RAVE SP consists of the following sub-devices:
> +
> +DeviceDescription
> +-----
> +rave-sp-wdt  : Watchdog

What else does it contain.

MFDs always have more than one device.

> +Example of usage:
> +
> + rdu {

What is an RDU?

> + compatible = "zii,rave-sp-rdu2";
> + current-speed = <100>;
> +
> + watchdog {
> + compatible = "zii,rave-sp-watchdog";
> + };
> + };
> +
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 3eb5c93..6cab311 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -867,6 +867,15 @@ config MFD_SPMI_PMIC
> Say M here if you want to include support for the SPMI PMIC
> series as a module.  The module will be called "qcom-spmi-pmic".
>  
> +config MFD_RAVE_SP
> + tristate "RAVE SP MCU core driver"
> + select MFD_CORE
> + select SERIAL_DEV_BUS
> + select CRC_CCITT
> + help
> +   Select this to get support for the RAVE Supervisory
> +   Processor driver

Missing '.'.

>  config MFD_RDC321X
>   tristate "RDC R-321x southbridge"
>   select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index c16bf1e..bc3df0a 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -221,3 +221,4 @@ obj-$(CONFIG_MFD_SUN4I_GPADC) += sun4i-gpadc.o
>  
>  obj-$(CONFIG_MFD_STM32_TIMERS)   += stm32-timers.o
>  obj-$(CONFIG_MFD_MXS_LRADC) += mxs-lradc.o
> +obj-$(CONFIG_MFD_RAVE_SP)+= rave-sp.o
> diff --git a/drivers/mfd/rave-sp.c b/drivers/mfd/rave-sp.c
> new file mode 100644
> index 000..41cdbd2
> --- /dev/null
> +++ b/drivers/mfd/rave-sp.c
> @@ -0,0 +1,1009 @@
> +/*
> + * rave-sp.c - Multifunction core driver for Zodiac Inflight Innovations

Drop the filename please, they have a habit of becoming incorrect

> + * SP MCU that is connected 

Re: [PATCH v6 00/10] serial/gpio: exar: Fixes and support for IOT2000

[Linus Walleij]

On Fri, Jun 9, 2017 at 8:33 PM, Jan Kiszka  wrote:

> This makes the gpio-exar driver usable, which was prevented by a number
> of fatal bugs, and adds support for the SIMATIC IOT2040 to the 8250-exar
> driver and, indirectly, to gpio-exar as well. It's a cross-subsystem
> series, so I'm also cross-posting to the serial and gpio lists.
>
> Changes in v6:

I merged some of the patches, that applied. Let's see if they survive
in linux-next, else I guess we need to fix this in the -rcs or for the next
kernel cycle.

Yours,
Linus Walleij

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

[Willy Tarreau]

On Tue, Jun 20, 2017 at 10:14:05AM +0200, Rafal Milecki wrote:
> On 2017-06-20 09:58, Willy Tarreau wrote:
> > On Tue, Jun 20, 2017 at 09:31:00AM +0200, Rafal Milecki wrote:
> > > Do you know if my name will appear correctly in git [0]?
> > > 
> > > [0] 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=linux-3.10.y
> > 
> > I would have almost promised it was going to be OK but it's bogus so
> > it probably happened during the patch manipulation, thus I'll fix it
> > before the final release :
> > 
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/linux-stable.git/commit/?h=linux-3.10.y-queue&id=73148299c53be25
> 
> OK, thanks!

I've now fixed it but I found a few other occurrences, I'm going to fix
all of them at once.

Cheers,
willy

Re: [PATCH v7 1/3] ACPI/IORT: Fixup SMMUv3 resource size for Cavium ThunderX2 SMMUv3 model

[Robert Richter]

On 30.05.17 17:33:39, Geetha sowjanya wrote:
> From: Linu Cherian 
> 
> Cavium ThunderX2 implementation doesn't support second page in SMMU
> register space. Hence, resource size is set as 64k for this model.
> 
> Signed-off-by: Linu Cherian 
> Signed-off-by: Geetha Sowjanya 
> ---
>  drivers/acpi/arm64/iort.c |   10 +-
>  1 files changed, 9 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index c5fecf9..bba2b59 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -833,12 +833,20 @@ static void __init arm_smmu_v3_init_resources(struct 
> resource *res,
>  {
>   struct acpi_iort_smmu_v3 *smmu;
>   int num_res = 0;
> + unsigned long size = SZ_128K;
>  
>   /* Retrieve SMMUv3 specific data */
>   smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
>  
> + /*
> +  * Override the size, for Cavium ThunderX2 implementation
> +  * which doesn't support the page 1 SMMU register space.
> +  */
> + if (smmu->model == ACPI_IORT_SMMU_CAVIUM_CN99XX)

Geetha,

please resubmit the series since the macro changed to
ACPI_IORT_SMMU_V3_CAVIUM_CN99XX:

 
https://github.com/acpica/acpica/commit/d00a4eb86e64bb4fa70f57ab5e5ca0a4ca2ad8ef#diff-a572aac2ccc26fe4a901616d7fdba859R1053

-Robert

> + size = SZ_64K;
> +
>   res[num_res].start = smmu->base_address;
> - res[num_res].end = smmu->base_address + SZ_128K - 1;
> + res[num_res].end = smmu->base_address + size - 1;
>   res[num_res].flags = IORESOURCE_MEM;
>  
>   num_res++;
> -- 
> 1.7.1
> 

[PATCH v9 0/3] Tango PCIe controller support

[Marc Gonzalez]

Marc Z pointed out that posting partial series is not ideal.
Collect last-minute fixups into a single patch series.

- Bump series to v9 to avoid any ambiguity
- Add Rob's Ack on patch 1

Marc Gonzalez (3):
  PCI: Add DT binding for tango PCIe controller
  PCI: Add tango PCIe host bridge support
  PCI: Add tango MSI controller support

 .../devicetree/bindings/pci/tango-pcie.txt |  29 ++
 drivers/pci/host/Kconfig   |   8 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pcie-tango.c  | 390 +
 include/linux/pci_ids.h|   2 +
 5 files changed, 430 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/tango-pcie.txt
 create mode 100644 drivers/pci/host/pcie-tango.c

-- 
2.11.0

[PATCH v9 3/3] PCI: Add tango MSI controller support

[Marc Gonzalez]

The MSI controller in Tango supports 256 message-signaled interrupts,
and a single doorbell address.

Signed-off-by: Marc Gonzalez 
---
 drivers/pci/host/pcie-tango.c | 226 ++
 1 file changed, 226 insertions(+)

diff --git a/drivers/pci/host/pcie-tango.c b/drivers/pci/host/pcie-tango.c
index 67aaadcc1c5e..5c47a4cc03e3 100644
--- a/drivers/pci/host/pcie-tango.c
+++ b/drivers/pci/host/pcie-tango.c
@@ -1,16 +1,229 @@
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 #define MSI_MAX 256
 
 #define SMP8759_MUX0x48
 #define SMP8759_TEST_OUT   0x74
+#define SMP8759_STATUS 0x80
+#define SMP8759_ENABLE 0xa0
+#define SMP8759_DOORBELL   0xa002e07c
 
 struct tango_pcie {
+   DECLARE_BITMAP(used_msi, MSI_MAX);
+   spinlock_t used_msi_lock;
void __iomem *mux;
+   void __iomem *msi_status;
+   void __iomem *msi_enable;
+   phys_addr_t msi_doorbell;
+   struct irq_domain *irq_dom;
+   struct irq_domain *msi_dom;
+   int irq;
 };
 
+/*** MSI CONTROLLER SUPPORT ***/
+
+static void tango_msi_isr(struct irq_desc *desc)
+{
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   struct tango_pcie *pcie = irq_desc_get_handler_data(desc);
+   unsigned long status, base, virq, idx, pos = 0;
+
+   chained_irq_enter(chip, desc);
+   spin_lock(&pcie->used_msi_lock);
+
+   while ((pos = find_next_bit(pcie->used_msi, MSI_MAX, pos)) < MSI_MAX) {
+   base = round_down(pos, 32);
+   status = readl_relaxed(pcie->msi_status + base / 8);
+   for_each_set_bit(idx, &status, 32) {
+   virq = irq_find_mapping(pcie->irq_dom, base + idx);
+   generic_handle_irq(virq);
+   }
+   pos = base + 32;
+   }
+
+   spin_unlock(&pcie->used_msi_lock);
+   chained_irq_exit(chip, desc);
+}
+
+static void tango_ack(struct irq_data *d)
+{
+   struct tango_pcie *pcie = d->chip_data;
+   u32 offset = (d->hwirq / 32) * 4;
+   u32 bit = BIT(d->hwirq % 32);
+
+   writel_relaxed(bit, pcie->msi_status + offset);
+}
+
+static void update_msi_enable(struct irq_data *d, bool unmask)
+{
+   unsigned long flags;
+   struct tango_pcie *pcie = d->chip_data;
+   u32 offset = (d->hwirq / 32) * 4;
+   u32 bit = BIT(d->hwirq % 32);
+   u32 val;
+
+   spin_lock_irqsave(&pcie->used_msi_lock, flags);
+   val = readl_relaxed(pcie->msi_enable + offset);
+   val = unmask ? val | bit : val & ~bit;
+   writel_relaxed(val, pcie->msi_enable + offset);
+   spin_unlock_irqrestore(&pcie->used_msi_lock, flags);
+}
+
+static void tango_mask(struct irq_data *d)
+{
+   update_msi_enable(d, false);
+}
+
+static void tango_unmask(struct irq_data *d)
+{
+   update_msi_enable(d, true);
+}
+
+static int tango_set_affinity(struct irq_data *d,
+   const struct cpumask *mask, bool force)
+{
+   return -EINVAL;
+}
+
+static void tango_compose_msi_msg(struct irq_data *d, struct msi_msg *msg)
+{
+   struct tango_pcie *pcie = d->chip_data;
+   msg->address_lo = lower_32_bits(pcie->msi_doorbell);
+   msg->address_hi = upper_32_bits(pcie->msi_doorbell);
+   msg->data = d->hwirq;
+}
+
+static struct irq_chip tango_chip = {
+   .irq_ack= tango_ack,
+   .irq_mask   = tango_mask,
+   .irq_unmask = tango_unmask,
+   .irq_set_affinity   = tango_set_affinity,
+   .irq_compose_msi_msg= tango_compose_msi_msg,
+};
+
+static void msi_ack(struct irq_data *d)
+{
+   irq_chip_ack_parent(d);
+}
+
+static void msi_mask(struct irq_data *d)
+{
+   pci_msi_mask_irq(d);
+   irq_chip_mask_parent(d);
+}
+
+static void msi_unmask(struct irq_data *d)
+{
+   pci_msi_unmask_irq(d);
+   irq_chip_unmask_parent(d);
+}
+
+static struct irq_chip msi_chip = {
+   .name = "MSI",
+   .irq_ack = msi_ack,
+   .irq_mask = msi_mask,
+   .irq_unmask = msi_unmask,
+};
+
+static struct msi_domain_info msi_dom_info = {
+   .flags  = MSI_FLAG_PCI_MSIX
+   | MSI_FLAG_USE_DEF_DOM_OPS
+   | MSI_FLAG_USE_DEF_CHIP_OPS,
+   .chip   = &msi_chip,
+};
+
+static int tango_irq_domain_alloc(struct irq_domain *dom,
+   unsigned int virq, unsigned int nr_irqs, void *args)
+{
+   int pos;
+   unsigned long flags;
+   struct tango_pcie *pcie = dom->host_data;
+
+   spin_lock_irqsave(&pcie->used_msi_lock, flags);
+   pos = find_first_zero_bit(pcie->used_msi, MSI_MAX);
+   if (pos >= MSI_MAX) {
+   spin_unlock_irqrestore(&pcie->used_msi_lock, flags);
+   return -ENOSPC;
+   }
+   __set_bit(pos, pcie->used_msi);
+   spin_unlock_irqrestore(&pcie->used_msi_lock, flags);
+   irq_domain_set_info(dom, virq, pos, &tango_chip,
+   pcie, handle_edge_irq, NULL, NULL);
+
+   return 0;
+}

Re: [PATCH 01/11] Fix coding style of driver/staging/ccree/ssi_aead.c ERROR: space required after that

[Dan Carpenter]

Subject is wrong.  It should be:

[PATCH 1/11] Staging: ccree: add spaces blah blah blah

On Tue, Jun 20, 2017 at 01:19:44PM +0800, Jhih-Ming Huang wrote:
> From: Jhih-Ming Hunag 
> 

No need.

> In this series patches, I fix all of the coding style error in 
> driver/staging/ccree/ssi_aead.c from 54 errors to 0 error.

You could put this into the cover letter.  When we put this into the
final git log we don't see the series only individual patches.

> 
> The first patch fixed 'ERROR: space required after that'.
> 

This patch fixes ...

regards,
dan carpenter

[PATCH 0/2] add mt2712 spi support

[Leilk Liu]

This series are based on 4.12-rc1 and provide 2 patches to support mt2712 IC.

Change in this series:
1. update document to add mt2712;
2. add mt7622_compat.

Leilk Liu (2):
  spi: mediatek: Add bindings for mediatek MT2712 soc platform
  spi: mediatek: add spi support for mt2712 IC

 .../devicetree/bindings/spi/spi-mt65xx.txt |1 +
 drivers/spi/spi-mt65xx.c   |7 +++
 2 files changed, 8 insertions(+)

--
1.7.9.5

[PATCH 1/2] spi: mediatek: Add bindings for mediatek MT2712 soc platform

[Leilk Liu]

This patch adds a DT binding documentation for the MT2712 soc.

Signed-off-by: Leilk Liu 
---
 .../devicetree/bindings/spi/spi-mt65xx.txt |1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt 
b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
index c0b1f01..e0318cf 100644
--- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
+++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
@@ -3,6 +3,7 @@ Binding for MTK SPI controller
 Required properties:
 - compatible: should be one of the following.
 - mediatek,mt2701-spi: for mt2701 platforms
+- mediatek,mt2712-spi: for mt2712 platforms
 - mediatek,mt6589-spi: for mt6589 platforms
 - mediatek,mt7622-spi: for mt7622 platforms
 - mediatek,mt8135-spi: for mt8135 platforms
-- 
1.7.9.5

[PATCH 2/2] spi: mediatek: add spi support for mt2712 IC

[Leilk Liu]

this patch add support for mt2712 IC.

Signed-off-by: Leilk Liu 
---
 drivers/spi/spi-mt65xx.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index ec7755b..86bf456 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -105,6 +105,10 @@ struct mtk_spi {
 
 static const struct mtk_spi_compatible mtk_common_compat;
 
+static const struct mtk_spi_compatible mt2712_compat = {
+   .must_tx = true,
+};
+
 static const struct mtk_spi_compatible mt7622_compat = {
.must_tx = true,
.enhance_timing = true,
@@ -130,6 +134,9 @@ struct mtk_spi {
{ .compatible = "mediatek,mt2701-spi",
.data = (void *)&mtk_common_compat,
},
+   { .compatible = "mediatek,mt2712-spi",
+   .data = (void *)&mt2712_compat,
+   },
{ .compatible = "mediatek,mt6589-spi",
.data = (void *)&mtk_common_compat,
},
-- 
1.7.9.5

Re: [RFC v2 06/12] powerpc: Program HPTE key protection bits.

[Anshuman Khandual]

On 06/17/2017 09:22 AM, Ram Pai wrote:
> Map the PTE protection key bits to the HPTE key protection bits,
> while creatiing HPTE  entries.
> 
> Signed-off-by: Ram Pai 
> ---
>  arch/powerpc/include/asm/book3s/64/mmu-hash.h | 5 +
>  arch/powerpc/include/asm/pkeys.h  | 7 +++
>  arch/powerpc/mm/hash_utils_64.c   | 5 +
>  3 files changed, 17 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h 
> b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> index cfb8169..3d7872c 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
> @@ -90,6 +90,8 @@
>  #define HPTE_R_PP0   ASM_CONST(0x8000)
>  #define HPTE_R_TSASM_CONST(0x4000)
>  #define HPTE_R_KEY_HIASM_CONST(0x3000)
> +#define HPTE_R_KEY_BIT0  ASM_CONST(0x2000)
> +#define HPTE_R_KEY_BIT1  ASM_CONST(0x1000)
>  #define HPTE_R_RPN_SHIFT 12
>  #define HPTE_R_RPN   ASM_CONST(0x0000)
>  #define HPTE_R_RPN_3_0   ASM_CONST(0x01fff000)
> @@ -104,6 +106,9 @@
>  #define HPTE_R_C ASM_CONST(0x0080)
>  #define HPTE_R_R ASM_CONST(0x0100)
>  #define HPTE_R_KEY_LOASM_CONST(0x0e00)
> +#define HPTE_R_KEY_BIT2  ASM_CONST(0x0800)
> +#define HPTE_R_KEY_BIT3  ASM_CONST(0x0400)
> +#define HPTE_R_KEY_BIT4  ASM_CONST(0x0200)
> 

Should we indicate/document how these 5 bits are not contiguous
in the HPTE format for any given real page ?

>  #define HPTE_V_1TB_SEG   ASM_CONST(0x4000)
>  #define HPTE_V_VRMA_MASK ASM_CONST(0x4001ff00)
> diff --git a/arch/powerpc/include/asm/pkeys.h 
> b/arch/powerpc/include/asm/pkeys.h
> index 0f3dca8..9b6820d 100644
> --- a/arch/powerpc/include/asm/pkeys.h
> +++ b/arch/powerpc/include/asm/pkeys.h
> @@ -27,6 +27,13 @@
>   ((vm_flags & VM_PKEY_BIT3) ? H_PAGE_PKEY_BIT1 : 0x0UL) | \
>   ((vm_flags & VM_PKEY_BIT4) ? H_PAGE_PKEY_BIT0 : 0x0UL))
> 
> +#define calc_pte_to_hpte_pkey_bits(pteflags) \
> + (((pteflags & H_PAGE_PKEY_BIT0) ? HPTE_R_KEY_BIT0 : 0x0UL) |\
> + ((pteflags & H_PAGE_PKEY_BIT1) ? HPTE_R_KEY_BIT1 : 0x0UL) | \
> + ((pteflags & H_PAGE_PKEY_BIT2) ? HPTE_R_KEY_BIT2 : 0x0UL) | \
> + ((pteflags & H_PAGE_PKEY_BIT3) ? HPTE_R_KEY_BIT3 : 0x0UL) | \
> + ((pteflags & H_PAGE_PKEY_BIT4) ? HPTE_R_KEY_BIT4 : 0x0UL))
> +

We can drop calc_ in here. pte_to_hpte_pkey_bits should be
sufficient.

[PATCH v9 2/3] PCI: Add tango PCIe host bridge support

[Marc Gonzalez]

This driver is required to work around several hardware bugs
in the PCIe controller.

NB: Revision 1 does not support legacy interrupts, or IO space.

Signed-off-by: Marc Gonzalez 
---
 drivers/pci/host/Kconfig  |   8 +++
 drivers/pci/host/Makefile |   1 +
 drivers/pci/host/pcie-tango.c | 164 ++
 include/linux/pci_ids.h   |   2 +
 4 files changed, 175 insertions(+)
 create mode 100644 drivers/pci/host/pcie-tango.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d7e7c0a827c3..5183d9095c3a 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -285,6 +285,14 @@ config PCIE_ROCKCHIP
  There is 1 internal PCIe port available to support GEN2 with
  4 slots.
 
+config PCIE_TANGO
+   bool "Tango PCIe controller"
+   depends on ARCH_TANGO && PCI_MSI && OF
+   select PCI_HOST_COMMON
+   help
+ Say Y here to enable PCIe controller support for Sigma Designs
+ Tango systems, such as SMP8759 and later chips.
+
 config VMD
depends on PCI_MSI && X86_64
tristate "Intel Volume Management Device Driver"
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 084cb4983645..fc7ea90196f3 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -32,4 +32,5 @@ obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
 obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
 obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
 obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
+obj-$(CONFIG_PCIE_TANGO) += pcie-tango.o
 obj-$(CONFIG_VMD) += vmd.o
diff --git a/drivers/pci/host/pcie-tango.c b/drivers/pci/host/pcie-tango.c
new file mode 100644
index ..67aaadcc1c5e
--- /dev/null
+++ b/drivers/pci/host/pcie-tango.c
@@ -0,0 +1,164 @@
+#include 
+#include 
+#include 
+
+#define MSI_MAX 256
+
+#define SMP8759_MUX0x48
+#define SMP8759_TEST_OUT   0x74
+
+struct tango_pcie {
+   void __iomem *mux;
+};
+
+/*** HOST BRIDGE SUPPORT ***/
+
+static int smp8759_config_read(struct pci_bus *bus,
+   unsigned int devfn, int where, int size, u32 *val)
+{
+   int ret;
+   struct pci_config_window *cfg = bus->sysdata;
+   struct tango_pcie *pcie = dev_get_drvdata(cfg->parent);
+
+   /*
+* QUIRK #1
+* Reads in configuration space outside devfn 0 return garbage.
+*/
+   if (devfn != 0)
+   return PCIBIOS_FUNC_NOT_SUPPORTED;
+
+   /*
+* QUIRK #2
+* Unfortunately, config and mem spaces are muxed.
+* Linux does not support such a setting, since drivers are free
+* to access mem space directly, at any time.
+* Therefore, we can only PRAY that config and mem space accesses
+* NEVER occur concurrently.
+*/
+   writel_relaxed(1, pcie->mux);
+   ret = pci_generic_config_read(bus, devfn, where, size, val);
+   writel_relaxed(0, pcie->mux);
+
+   return ret;
+}
+
+static int smp8759_config_write(struct pci_bus *bus,
+   unsigned int devfn, int where, int size, u32 val)
+{
+   int ret;
+   struct pci_config_window *cfg = bus->sysdata;
+   struct tango_pcie *pcie = dev_get_drvdata(cfg->parent);
+
+   writel_relaxed(1, pcie->mux);
+   ret = pci_generic_config_write(bus, devfn, where, size, val);
+   writel_relaxed(0, pcie->mux);
+
+   return ret;
+}
+
+static struct pci_ecam_ops smp8759_ecam_ops = {
+   .bus_shift  = 20,
+   .pci_ops= {
+   .map_bus= pci_ecam_map_bus,
+   .read   = smp8759_config_read,
+   .write  = smp8759_config_write,
+   }
+};
+
+static const struct of_device_id tango_pcie_ids[] = {
+   { .compatible = "sigma,smp8759-pcie" },
+   { /* sentinel */ },
+};
+
+static int tango_check_pcie_link(void __iomem *test_out)
+{
+   int i;
+
+   writel_relaxed(16, test_out);
+   for (i = 0; i < 10; ++i) {
+   u32 ltssm_state = readl_relaxed(test_out) >> 8;
+   if ((ltssm_state & 0x1f) == 0xf) /* L0 */
+   return 0;
+   usleep_range(3000, 4000);
+   }
+
+   return -ENODEV;
+}
+
+static int smp8759_init(struct tango_pcie *pcie, void __iomem *base)
+{
+   pcie->mux   = base + SMP8759_MUX;
+
+   return tango_check_pcie_link(base + SMP8759_TEST_OUT);
+}
+
+static int tango_pcie_probe(struct platform_device *pdev)
+{
+   int ret = -EINVAL;
+   void __iomem *base;
+   struct resource *res;
+   struct tango_pcie *pcie;
+   struct device *dev = &pdev->dev;
+
+   pr_err("MAJOR ISSUE: PCIe config and mem spaces are muxed\n");
+   pr_err("Tainting kernel... Use driver at your own risk\n");
+   add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
+
+   pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
+   if (!pcie)
+   return -ENOMEM;
+
+   platform

[PATCH v9 1/3] PCI: Add DT binding for tango PCIe controller

[Marc Gonzalez]

Binding for the Sigma Designs SMP8759 SoC.

Acked-by: Rob Herring 
Signed-off-by: Marc Gonzalez 
---
 .../devicetree/bindings/pci/tango-pcie.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/tango-pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/tango-pcie.txt 
b/Documentation/devicetree/bindings/pci/tango-pcie.txt
new file mode 100644
index ..244683836a79
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/tango-pcie.txt
@@ -0,0 +1,29 @@
+Sigma Designs Tango PCIe controller
+
+Required properties:
+
+- compatible: "sigma,smp8759-pcie"
+- reg: address/size of PCI configuration space, address/size of register area
+- bus-range: defined by size of PCI configuration space
+- device_type: "pci"
+- #size-cells: <2>
+- #address-cells: <3>
+- msi-controller
+- ranges: translation from system to bus addresses
+- interrupts: spec for misc interrupts, spec for MSI
+
+Example:
+
+   pcie@2e000 {
+   compatible = "sigma,smp8759-pcie";
+   reg = <0x5000 0x40>, <0x2e000 0x100>;
+   bus-range = <0 3>;
+   device_type = "pci";
+   #size-cells = <2>;
+   #address-cells = <3>;
+   msi-controller;
+   ranges = <0x0200 0x0 0x0040  0x5040  0x0 0x3c0>;
+   interrupts =
+   <54 IRQ_TYPE_LEVEL_HIGH>, /* misc interrupts */
+   <55 IRQ_TYPE_LEVEL_HIGH>; /* MSI */
+   };
-- 
2.11.0

Re: [PATCH 1/2] x86/boot/KASLR: Adapt process_e820_entry for all kinds of memory map

[Chao Fan]

On Thu, Jun 15, 2017 at 03:52:48PM +0800, Baoquan He wrote:
>Now function process_e820_entry is only used to process e820 memory
>entry. Adapt it for memory region only, not just for e820. Later
>we will use it to process efi mirror regions.
>
>So rename the original process_e820_entry to process_mem_region, and
>extract and wrap the e820 specific processing code into process_e820_entry.
>
>Signed-off-by: Baoquan He 

Hi Bao,

Maybe some code annotations should be changed, for example:

/* Walk e820 and find a random address. */
random_addr = find_random_phys_addr(min_addr, output_size);

Cause you will walk efi map firstly, and then e820 map(or not).

Thanks,
Chao Fan

>---
> arch/x86/boot/compressed/kaslr.c | 60 ++--
> 1 file changed, 33 insertions(+), 27 deletions(-)
>
>diff --git a/arch/x86/boot/compressed/kaslr.c 
>b/arch/x86/boot/compressed/kaslr.c
>index fe318b4..c2ed051 100644
>--- a/arch/x86/boot/compressed/kaslr.c
>+++ b/arch/x86/boot/compressed/kaslr.c
>@@ -479,35 +479,31 @@ static unsigned long slots_fetch_random(void)
>   return 0;
> }
> 
>-static void process_e820_entry(struct boot_e820_entry *entry,
>+static void process_mem_region(struct mem_vector *entry,
>  unsigned long minimum,
>  unsigned long image_size)
> {
>   struct mem_vector region, overlap;
>   struct slot_area slot_area;
>   unsigned long start_orig, end;
>-  struct boot_e820_entry cur_entry;
>-
>-  /* Skip non-RAM entries. */
>-  if (entry->type != E820_TYPE_RAM)
>-  return;
>+  struct mem_vector cur_entry;
> 
>   /* On 32-bit, ignore entries entirely above our maximum. */
>-  if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= KERNEL_IMAGE_SIZE)
>+  if (IS_ENABLED(CONFIG_X86_32) && entry->start >= KERNEL_IMAGE_SIZE)
>   return;
> 
>   /* Ignore entries entirely below our minimum. */
>-  if (entry->addr + entry->size < minimum)
>+  if (entry->start + entry->size < minimum)
>   return;
> 
>   /* Ignore entries above memory limit */
>-  end = min(entry->size + entry->addr, mem_limit);
>-  if (entry->addr >= end)
>+  end = min(entry->size + entry->start, mem_limit);
>+  if (entry->start >= end)
>   return;
>-  cur_entry.addr = entry->addr;
>-  cur_entry.size = end - entry->addr;
>+  cur_entry.start = entry->start;
>+  cur_entry.size = end - entry->start;
> 
>-  region.start = cur_entry.addr;
>+  region.start = cur_entry.start;
>   region.size = cur_entry.size;
> 
>   /* Give up if slot area array is full. */
>@@ -522,7 +518,7 @@ static void process_e820_entry(struct boot_e820_entry 
>*entry,
>   region.start = ALIGN(region.start, CONFIG_PHYSICAL_ALIGN);
> 
>   /* Did we raise the address above this e820 region? */
>-  if (region.start > cur_entry.addr + cur_entry.size)
>+  if (region.start > cur_entry.start + cur_entry.size)
>   return;
> 
>   /* Reduce size by any delta from the original address. */
>@@ -562,12 +558,31 @@ static void process_e820_entry(struct boot_e820_entry 
>*entry,
>   }
> }
> 
>-static unsigned long find_random_phys_addr(unsigned long minimum,
>- unsigned long image_size)
>+static void process_e820_entry(unsigned long minimum,unsigned long image_size)
> {
>   int i;
>-  unsigned long addr;
>+  struct mem_vector region;
>+  struct boot_e820_entry *entry;
>+
>+  /* Verify potential e820 positions, appending to slots list. */
>+for (i = 0; i < boot_params->e820_entries; i++) {
>+entry = &boot_params->e820_table[i];
>+/* Skip non-RAM entries. */
>+if (entry->type != E820_TYPE_RAM)
>+continue;
>+region.start = entry->addr;
>+region.size = entry->size;
>+process_mem_region(®ion, minimum, image_size);
>+if (slot_area_index == MAX_SLOT_AREA) {
>+debug_putstr("Aborted e820 scan (slot_areas 
>full)!\n");
>+break;
>+}
>+}
>+}
> 
>+static unsigned long find_random_phys_addr(unsigned long minimum,
>+ unsigned long image_size)
>+{
>   /* Check if we had too many memmaps. */
>   if (memmap_too_large) {
>   debug_putstr("Aborted e820 scan (more than 4 memmap= args)!\n");
>@@ -577,16 +592,7 @@ static unsigned long find_random_phys_addr(unsigned long 
>minimum,
>   /* Make sure minimum is aligned. */
>   minimum = ALIGN(minimum, CONFIG_PHYSICAL_ALIGN);
> 
>-  /* Verify potential e820 positions, appending to slots list. */
>-  for (i = 0; i < boot_params->e820_entries; i++) {
>-  process_e820_entry(&boot_params->e820_table[i], minim

Re: [PATCH 02/11] Fix ERROR: spaces required around that

[Dan Carpenter]

On Tue, Jun 20, 2017 at 01:20:59PM +0800, Jhih-Ming Huang wrote:
> From: Jhih-Ming Hunag 
> 
> Fixed 'ERROR: spaces required around that'
> 

You're breaking the patches up in a bad way.  This one should be
combined with the previous patch.

regards,
dan carpenter

Re: [PATCH v7 11/36] x86/mm: Add SME support for read_cr3_pa()

[Borislav Petkov]

On Fri, Jun 16, 2017 at 01:51:55PM -0500, Tom Lendacky wrote:
> The cr3 register entry can contain the SME encryption mask that indicates
> the PGD is encrypted.  The encryption mask should not be used when
> creating a virtual address from the cr3 register, so remove the SME
> encryption mask in the read_cr3_pa() function.
> 
> During early boot SME will need to use a native version of read_cr3_pa(),
> so create native_read_cr3_pa().
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/processor-flags.h |3 ++-
>  arch/x86/include/asm/processor.h   |5 +
>  2 files changed, 7 insertions(+), 1 deletion(-)

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH] phy: brcm-sata: fix a timeout test in init

[Vivek Gautam]

On 06/19/2017 04:26 PM, Dan Carpenter wrote:

We want to timeout with try set to zero so this should be a pre-op
instead of post-op.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/phy/broadcom/phy-brcm-sata.c 
b/drivers/phy/broadcom/phy-brcm-sata.c
index ccbc3d994998..48fb016ce689 100644
--- a/drivers/phy/broadcom/phy-brcm-sata.c
+++ b/drivers/phy/broadcom/phy-brcm-sata.c
@@ -329,7 +329,7 @@ static int brcm_nsp_sata_init(struct brcm_sata_port *port)
  
  	/* Wait for pll_seq_done bit */

try = 50;
-   while (try--) {
+   while (--try) {


Do we want to try reading the status 50 times? If yes, won't your change
break that? It will rather run the loop 49 times.

Thanks
Vivek


val = brcm_sata_phy_rd(base, BLOCK0_REG_BANK,
BLOCK0_XGXSSTATUS);
if (val & BLOCK0_XGXSSTATUS_PLL_LOCK)


--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 05/11] Fix ERROR: space prohibited after that open parenthesis '('

[Dan Carpenter]

On Tue, Jun 20, 2017 at 01:21:46PM +0800, Jhih-Ming Huang wrote:
> From: Jhih-Ming Hunag 
> 
> Fixed "ERROR: space prohibited after that open parenthesis '('".
> 
> Signed-off-by: Jhih-Ming Hunag 
> ---
>  drivers/staging/ccree/ssi_aead.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/staging/ccree/ssi_aead.c 
> b/drivers/staging/ccree/ssi_aead.c
> index 6bcab5a..5166874 100644
> --- a/drivers/staging/ccree/ssi_aead.c
> +++ b/drivers/staging/ccree/ssi_aead.c
> @@ -1375,10 +1375,10 @@ static int validate_data_size(struct ssi_aead_ctx 
> *ctx,
>  static unsigned int format_ccm_a0(u8 *pA0Buff, u32 headerSize)
>  {
>   unsigned int len = 0;
> - if ( headerSize == 0 ) {
> + if (headerSize == 0 ) {

Remove the other space as well.  I looked ahead in the series so I see
that you do it later, but it should be done here.

regards,
dan carpenter

Re: [PATCH v5 2/3] PCI: Add tango PCIe host bridge support

[Marc Gonzalez]

On 19/06/2017 16:50, Marc Gonzalez wrote:

> On 07/06/2017 10:19, Marc Gonzalez wrote:
> 
>> On 31/05/2017 15:33, Marc Gonzalez wrote:
>>
>>> +static int tango_pcie_probe(struct platform_device *pdev)
>>> +{
>>> +   int ret = -EINVAL;
>>> +   void __iomem *base;
>>> +   struct resource *res;
>>> +   struct tango_pcie *pcie;
>>> +   struct device *dev = &pdev->dev;
>>> +
>>> +   pr_err("MAJOR ISSUE: PCIe config and mem spaces are muxed\n");
>>> +   pr_err("Tainting kernel... Use driver at your own risk\n");
>>> +   add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
>>
>> Hello Bjorn,
>>
>> In v4, your only comment was
>> "[muxing config and mem spaces] is a major issue and possibly even
>> a security problem [which requires at least an error message and a
>> kernel taint].
>>
>> Were there any other issues with the host bridge support?
> 
> Hello Bjorn,
> 
> I imagine you are now only waiting for Marc Z's Ack of patch 3/3 ?
> (AFAIU, all issues have been addressed as of v8 3/3.)
> 
> Rob has Acked patch 1/3 -- thanks Rob.
> 
> Assuming all issues with patch 2/3 have already been addressed,
> then this driver can land in time for 4.13 right?

Hello Bjorn, Marc,

Patch series v9 supersedes all previously posted patches.

Regards.

Shawn Guo: your attetion is needed here Re: [PATCH v8 00/34] i.MX Media Driver

[Pavel Machek]

Hi!

> >> But as Pavel pointed out, in fact we are missing many
> >> Acks still, for all of the dts source changes (patches
> >> 4-14), as well as really everything else (imx-media staging
> >> driver patches).
> > 
> > No Acks needed for the staging part. It's staging, so not held
> > to the same standards as non-staging parts. That doesn't mean
> > Acks aren't welcome, of course.
> 
> Acks are wanted for particular i.MX DTS changes including device
> tree binding descriptions.
> 
> Shawn, please bless the series.

Hmm. I changed the subject to grab Shawn's attetion.

But his acks should not be needed for forward progress. Yes, it would
be good, but he does not react -- so just reorder the series so that
dts changes come last, then apply the parts you can apply: driver can
go in.

And actually... if maintainer does not respond at all, there are ways
to deal with that, too...

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


signature.asc
Description: Digital signature

Re: [PATCH 0/7] rwsem: Implement down_read_killable()

[David Howells]

David Rientjes  wrote:

> I would have expected to see down_read_killable() actually used somewhere 
> after its implementation as part of this patchset.

There are some places we should be using down_{read|write}_interruptible(), if
it existed, dressed as inode_lock{,_shared}_interruptible().

David

Re: [PATCH 3/3] arm64: dts: register Hi3660's thermal sensor

[Wangtao (Kevin, Kirin)]

在 2017/6/20 15:38, Guodong Xu 写道:



2017年6月20日 上午11:49，"Tao Wang" mailto:kevin.wang...@hisilicon.com>>写道：

Bind thermal sensor driver for Hi3660.

Signed-off-by: Tao Wang mailto:kevin.wang...@hisilicon.com>>
Signed-off-by: Leo Yan mailto:leo@linaro.org>>
---
  arch/arm64/boot/dts/hisilicon/hi3660.dtsi |7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 3983086..cc67958 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -156,5 +156,12 @@


i am wondering which tree this patch should be applied to. Actually Olof Johansson 
o...@lixom.net  just merged hi3660 dts into his tree. 
You should better rebase you dts patch onto that.

Can you share me the git path?



 clock-names = "uartclk", "apb_pclk";
 status = "disabled";
 };
+
+   tsensor: tsensor {
+   compatible = "hisilicon,thermal-hi3660";
+   reg = <0x0 0xfff3 0x0 0x1000>;
+   #thermal-sensor-cells = <1>;
+   status = "ok";


please remove status ok. that's default. redundant.

ok


+   };
 };
  };
--
1.7.9.5


___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org 

http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 

Re: [PATCH] random: silence compiler warnings and fix race

[Jeffrey Walton]

On Tue, Jun 20, 2017 at 4:14 AM, Jason A. Donenfeld  wrote:
>...
> Specifically, I added `depends on DEBUG_KERNEL`. This means that these
> useful warnings will only poke other kernel developers. This is probably
> exactly what we want. If the various associated developers see a warning
> coming from their particular subsystem, they'll be more motivated to
> fix it. Ordinary users on distribution kernels shouldn't see the
> warnings or the spam at all, since typically users aren't using
> DEBUG_KERNEL.

I think it is a bad idea to suppress all messages from a security
engineering point of view.

Many folks don't run debug kernels. Most of the users who want or need
to know of the issues won't realize its happening. Consider, the
reason we learned of systemd's problems was due to dmesg's.

Suppressing all messages for all configurations cast a wider net than
necessary. Configurations that could potentially be detected and fixed
likely will go unnoticed. If the problem is not brought to light, then
it won't be fixed.

I feel like the kernel is making policy decisions for some
organizations. For those who have hardware that is effectively
unfixable, then organization has to decide what to do based on their
risk adversity. They may decide to live with the risk, or they may
decide to refresh the hardware. However, without information on the
issue, they may not even realize they have an actionable item.

Jeff

Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Gerd Hoffmann]

  Hi,

> > Hmm, plane isn't really an ID, it is a type, with type being either
> > DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR, so I don't think
> > the
> > flage above make sense.
> 
> The intention was that ..._REGION_ID and ...PLANE_ID are describing
> what the vfio_device_query_gfx_plane.id field represents, either a
> region index or a plane identifier.  The type of plane would be
> represented within the vfio_device_gfx_plane_info struct.

The planes don't really have an id, we should rename that to
plane_type, or maybe drm_plane_type (simliar to the drm_format_*
fields), to avoid that confusion.

plane_type is set by userspace to specify what kind of plane it asks
for.

> > Also I think it would be useful to have some way to figure the
> > device
> > capabilities as the userspace workflow will look quite different
> > for
> > the two cases.
> 
> In the region case, VFIO_DEVICE_GET_REGION_INFO would include a
> device
> specific region with a hopefully common identifier to identify it as
> a
> graphics framebuffer.

Ok, that should work to figure whenever the mdev supports a plane
region or not.

> In the dmabuf case,VFIO_DEVICE_QUERY_GFX_PLANE would indicate the
> plane as a "plane ID" and some sort of
> VFIO_DEVICE_GET_GFX_PLANE(VFIO_GFX_TYPE_DMABUF) ioctl would be
> necessary to get a file descriptor to that plane.
> 
> What else are you thinking we need?  Thanks,

I need to know whenever the mdev supports dmabufs or not, at device
initialization time (because dmabufs require opengl support), when
VFIO_DEVICE_QUERY_GFX_PLANE doesn't work due to the guest not having
the device initialized yet.

Maybe we should have a error field in the ioctl struct, or we need to
clearly define error codes so the kernel doesn't just throw EINVAL in
all cases.

Or just a VFIO_DEVICE_GFX_CAPS ioctl which returns NONE, REGION or
DMABUF.

cheers,
  Gerd

Re: __user with scalar data types

[Daniel Vetter]

On Tue, Jun 20, 2017 at 9:42 AM, Gerd Hoffmann  wrote:
>> Yep that's cargo-culted, but from a quick grep only msm and qxl
>> headers do this (the other __user annotations in uapi/drm are for
>> pointers, where it's correct). Adding those maintainers.
>
> Yep, those looks pointless indeed.
>
>> Also, if you use u64_to_user_ptr helper macro sparse should have
>> caught this (if not we'd need to improve the macro).
>
> And qxl should actually use it.
>
> Fix attached (compile-tested only so far), does that look ok?

Yup. Assuming sparse is happy: Acked-by: me.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH v3 19/21] dt-bindings: mmc: dw_mmc-k3: add document of hi3660 mmc

[Ulf Hansson]

Hi Wei,

On 19 June 2017 at 15:00, Wei Xu  wrote:
> Hi Ulf,
>
> On 2017/6/19 13:43, Ulf Hansson wrote:
>> On 14 June 2017 at 10:23, Guodong Xu  wrote:
>>> Add bindings for hi3660 mmc support
>>>
>>> Signed-off-by: Li Wei 
>>> Signed-off-by: Guodong Xu 
>>> ---
>>>  Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt 
>>> b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
>>> index df37058..8af1afc 100644
>>> --- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
>>> @@ -12,6 +12,7 @@ extensions to the Synopsys Designware Mobile Storage Host 
>>> Controller.
>>>  Required Properties:
>>>
>>>  * compatible: should be one of the following.
>>> +  - "hisilicon,hi3660-dw-mshc": for controllers with hi3660 specific 
>>> extensions.
>>>- "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific 
>>> extensions.
>>>- "hisilicon,hi6220-dw-mshc": for controllers with hi6220 specific 
>>> extensions.
>>>
>>> --
>>> 2.10.2
>>>
>>
>> Thanks, applied for next!
>
> Thanks!
> Last week I had applied the v4 patch set[1]
> and this patch is included.
> But it should be fine for the upper gatekeeper to merge
> since these 2 patch are same.

No, that's not how git works.

If the patch has the same hash, that would be fine, but that isn't the
case here as we have two different hashes for the same change.

To deal with this, I have just dropped the change from my tree and
leave it to you to carry the patch. Feel free to add my ack for it.

Kind regards
Uffe

Re: [RFC] gpio: about the need to manage irq mapping dynamically.

[Linus Walleij]

On Thu, Jun 15, 2017 at 6:20 PM, Jerome Brunet  wrote:

> To handle this we tried:
> - [0]: To create the mapping in the gpio_to_irq. Linus, you pointed out that
> this is not allowed as gpio_to_irq is callable in irq context, therefore it
> should not sleep. Actually 3 drivers [2] are calling gpio_to_irq in irq
> handlers.

This is not the problem. The problem is that gpio_to_irq() is entirely
optional: it is not at all requires to have called gpio_to_irq() before using
an IRQ from a GPIO line, as the interrupt chips and gpio chips are
orthogonal.

So if gpio_to_irq() is called, then a mapping needs to be retrieved, using
an irqdomain or similar, and if one does not already exist, it should be mapped
at this point.

But actually doing the mapping/unmapping of IRQs and related resource
management should be handled by the irqchip/irqdomain, not ever by
gpio_to_irq().

And someone may just be requesting an IRQ from the irqchip without
calling gpio_to_irq(). Anytime. And with devicetree this happens all of the
time.

> I would also add that "gpio_to_irq" has no "free" counter part, so this 
> approach
> leaks mappings.

Exactly.

> The fact that 26 gpio drivers [3] create mapping in the
> gpio_to_irq callback shows that the problem of managing the irq mapping is not
> specific to Amlogic and that an evolution might be useful.

Calling irq_create_mapping() in gpio_to_irq() is not a problem if
the mapping is free:ed elsewhere. But yeah, there are lots of old
drivers with old and erroneous solutions to this problem.

> - [1]: To create an empty domain to get a virq for each pins but delay the 
> setup
> of the interrupt hierarchy to the "irq_request_resources" callback. Testing 
> this
> approach led me to some nasty race conditions in the interrupt handlers. I
> discussed this solution with Marc and he told me that doing the setup of the
> interrupt hierarchy in the irqchip callbacks is "too late" . If I understood
> correctly (Marc feel to correct me if necessary), you should only get a virq
> when the full interrupt hierarchy is setup, from the triggering device to the
> CPU.

OK I am as always confused by "virq" which I guess means "virtual IRQ"
which is confusing since all Linux IRQ numbers are in some sense
virtual, and since this has nothing to do with virtualization, which is another
area where IRQchips are very delicate.

But I get it.

> With this last comment, I don't think there is a (clean) way ATM for a gpio
> driver to create the mapping "on demand". By "on-demand", I mean the consumer
> drivers doing this kind of thing:
>
> ret = request_irq(gpio_to_irq(GPIOX_Y), ... )
>
> I would to like propose a way to fix that.

OK solutions are good

> It is not going to be a oneline fix,
> but I'm convinced we can do it w/o breaking anything:
>
> 1) Introduce new gpio driver callbacks (.irq_prepare, .irq_unprepare): Drivers
> will be free to implement those callbacks or not. Driver which can create all
> their mappings at probe time would obviously skip those.
>
> 2) Introduce gpio_irq_prepare and gpio_irq_unprepare to the gpio API: This
> functions would do refcounting to handle shared irq and avoid wrongly 
> disposing
> of used mappings. Then call the new drivers callbacks, if defined. A devm
> version of gpio_irq_prepare might be usefull
>
> 3) Add calls to gpio_irq_prepare to consumer drivers probe/init which use the
> gpio_to_irq callback. I don't think this is going to be that hard to do, but
> it's going be to long and boring ...

So how are you intending to deal with mixed semantics when, as in the
devicetree case, the GPIO driver is also flagged as an interrupt-controller
and consumers can request IRQs from it with just platform_get_irq()
and expect it to work?

It seems this usecase drives a truck through that approach.

The keyword is separation of concerns, the irqchip abstraction should
deal with interrupts, we do not want the gpiochip to do half of the work.

Here is an example from arch/arm/boot/dts/ste-snowball.dts:

ethernet@0 {
compatible = "smsc,lan9115";
reg = <0 0x1>;
interrupts = <12 IRQ_TYPE_EDGE_RISING>;
interrupt-parent = <&gpio4>;
(...)
};

Notice: no GPIOs are taken by this driver, this ethernet driver does not know
that its interrupt is supplied by a GPIO, in fact on many platforms
this ethernet
chip has a dedicated IRQ line so that should not be required, i.e. the ethernet
chip does not need to know that a GPIO controller is supplying this interrupt,
why should it? It is just some interrupt.

The driver looks like so drivers/net/ethernet/smsc/smsc911x.c:

irq = platform_get_irq(pdev, 0);

And that is all it does.

The above usecase is not uncommon.

If this interrupt+GPIO controller was using your scheme, where would these
new callbacks be called?

Yours,
Linus Walleij

Re: [PATCH] Revert "HID: magicmouse: Set multi-touch keybits for Magic Mouse"

[Jiri Kosina]

On Thu, 15 Jun 2017, Daniel Stone wrote:

> Setting these bits causes libinput to fail to initialize the device;
> setting BTN_TOUCH and BTN_TOOL_FINGER causes it to treat the mouse as a
> touchpad, and it then refuses to continue when it discovers ABS_X is not
> set.
> 
> This breaks all known Wayland compositors, as well as Xorg when the
> libinput driver is being used.
> 
> This reverts commit f4b65b9563216b3e01a5cc844c3ba68901d9b195.

Queued for 4.12. Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: linux-next: manual merge of the uuid tree with the arm64 tree

[Will Deacon]

On Mon, Jun 19, 2017 at 12:41:38PM -0600, Baicar, Tyler wrote:
> On 6/19/2017 4:22 AM, Will Deacon wrote:
> >On Mon, Jun 19, 2017 at 01:06:30PM +0300, Andy Shevchenko wrote:
> >>On Mon, 2017-06-19 at 10:19 +0100, Will Deacon wrote:
> >>>Hi Stephen, Christoph, Tyler,
> >>>On Fri, Jun 16, 2017 at 03:21:36PM +1000, Stephen Rothwell wrote:
> >>>Apologies for this: I've just dropped the offending merge from the
> >>>arm64
> >>>tree so you can include the uuid tree in -next again.
> >>>
> >>>Tyler: please rebase your patches on top of Christoph's uuid-types
> >>>branch
> >>>and send me a new series.
> >>To have better coordination, please, look at my WIP branch regarding
> >>UUID stuff:
> >>http://bitbucket.org/andy-shev/linux/branch/topic%2Fuuid
> >That link doesn't work for me. Is there anything specific Tyler should be
> >paying attention to on that branch?
> That link doesn't work for me either, but I assume it is the topic/uuid
> branch here:
> 
> https://bitbucket.org/andy-shev/linux/branches/
> 
> I'll rebase my patches on top of this branch and send them to you Will.

The conflict in -next came from Christoph's tree:

  http://git.infradead.org/users/hch/uuid.git/heads

hence why I mentioned the uuid-types branch above. It's not clear to me
how Andy's branch fits in with this.

Will

RE: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Zhang, Tina]

Hi,

Thanks for all the comments. Here are the summaries:

1. Modify the structures to make it more general.
struct vfio_device_gfx_plane_info {
__u64 start;
__u64 drm_format_mod;
__u32 drm_format;
__u32 width;
__u32 height;
__u32 stride;
__u32 size;
__u32 x_pos;
__u32 y_pos;
__u32 generation;
};
struct vfio_device_query_gfx_plane {
__u32 argsz;
__u32 flags;
#define VFIO_GFX_PLANE_FLAGS_REGION_ID  (1 << 0)
#define VFIO_GFX_PLANE_FLAGS_PLANE_ID   (1 << 1)
struct vfio_device_gfx_plane_info plane_info;
__u32 id; 
};
2. Remove dmabuf mgr fd and add these two ioctl commands to the vfio device fd.
VFIO_DEVICE_QUERY_GFX_PLANE : used to query vfio_device_gfx_plane_info.
VFIO_DEVICE_GET_DMABUF_FD: used to create and return the dmabuf fd.

Am I correct? Thanks.

Tina


> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Alex Williamson
> Sent: Monday, June 19, 2017 10:56 PM
> To: Gerd Hoffmann 
> Cc: intel-...@lists.freedesktop.org; linux-kernel@vger.kernel.org; Kirti
> Wankhede ; Chen, Xiaoguang
> ; intel-gvt-...@lists.freedesktop.org; Lv, Zhiyuan
> 
> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
> 
> On Mon, 19 Jun 2017 08:38:32 +0200
> Gerd Hoffmann  wrote:
> 
> >   Hi,
> >
> > > My suggestion was to use vfio device fd for this ioctl and have
> > > dmabuf mgr fd as member in above query_plane structure, for region
> > > type it would be set to 0.
> >
> > Region type should be DRM_PLANE_TYPE_PRIMARY
> >
> > > Can't mmap that page to get surface information. There is no way to
> > > synchronize between QEMU reading this mmapped region and vendor
> > > driver writing it. There could be race condition in these two
> > > operations.
> > > Read
> > > on this page should be trapped and blocking, so that surface in that
> > > region is only updated when its asked for.
> >
> > Does it make sense to have a "generation" field in the plane_info
> > struct (which gets increased each time the struct changes) ?
> 
> It seems less cumbersome than checking each field to see if it has changed.
> Thanks,
> 
> Alex
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: linux-next: manual merge of the uuid tree with the arm64 tree

[Christoph Hellwig]

On Tue, Jun 20, 2017 at 09:40:08AM +0100, Will Deacon wrote:
> > >>To have better coordination, please, look at my WIP branch regarding
> > >>UUID stuff:
> > >>http://bitbucket.org/andy-shev/linux/branch/topic%2Fuuid
> > >That link doesn't work for me. Is there anything specific Tyler should be
> > >paying attention to on that branch?
> > That link doesn't work for me either, but I assume it is the topic/uuid
> > branch here:
> > 
> > https://bitbucket.org/andy-shev/linux/branches/
> > 
> > I'll rebase my patches on top of this branch and send them to you Will.
> 
> The conflict in -next came from Christoph's tree:
> 
>   http://git.infradead.org/users/hch/uuid.git/heads
> 
> hence why I mentioned the uuid-types branch above. It's not clear to me
> how Andy's branch fits in with this.

I think Andy is preparing various uuid conversion in it and wanted to
make sure you don't do any work he already did or which conflicts with
this work.

For now please just base it on my uuid-types tree.

Re: [PATCH] phy: brcm-sata: fix a timeout test in init

[Dan Carpenter]

On Tue, Jun 20, 2017 at 01:56:35PM +0530, Vivek Gautam wrote:
> 
> 
> On 06/19/2017 04:26 PM, Dan Carpenter wrote:
> > We want to timeout with try set to zero so this should be a pre-op
> > instead of post-op.
> > 
> > Signed-off-by: Dan Carpenter 
> > 
> > diff --git a/drivers/phy/broadcom/phy-brcm-sata.c 
> > b/drivers/phy/broadcom/phy-brcm-sata.c
> > index ccbc3d994998..48fb016ce689 100644
> > --- a/drivers/phy/broadcom/phy-brcm-sata.c
> > +++ b/drivers/phy/broadcom/phy-brcm-sata.c
> > @@ -329,7 +329,7 @@ static int brcm_nsp_sata_init(struct brcm_sata_port 
> > *port)
> > /* Wait for pll_seq_done bit */
> > try = 50;
> > -   while (try--) {
> > +   while (--try) {
> 
> Do we want to try reading the status 50 times? If yes, won't your change
> break that? It will rather run the loop 49 times.
> 

Yeah.  I know.  I'm pretty sure that 50 is a rough number, and not an
exact thing.

regards,
dan carpenter

Re: [PATCH v2] firmware: qcom_scm: Fix to allow COMPILE_TEST-ing

[Stanimir Varbanov]

Hi Bjorn,

On 06/20/2017 12:00 AM, Bjorn Andersson wrote:
> On Mon 19 Jun 05:19 PDT 2017, Stanimir Varbanov wrote:
> 
>> Hi Olof,
>>
>> On 06/19/2017 02:25 PM, Stanimir Varbanov wrote:
>>> Hi Olof,
>>>
>>> On 06/19/2017 08:35 AM, Olof Johansson wrote:
 Hi,

 On Thu, Jun 8, 2017 at 8:23 AM, Stanimir Varbanov
> [..]

 It probably makes more sense to stub the driver->scm interface than
 the internal scm interface if what you're looking for is driver
 compile_test coverage.
>>>
>>> Actually, this is the state of qcom_scm if we don't apply the this
>>> patch, and it didn't help. Thinking more on that it looks like that
>>> adding COMPILE_TEST in 'config QCOM_SCM' is controversial.
>>>
>>> Arnd, Andy any ideas how to proceed. If this patch is not get merged
>>> (and I/we cannot find better solution) the video driver for qualcomm
>>> platforms will be rejected for 4.13.
>>>
>>
>> Currently the dependences are:
>>
>> VIDEO_QCOM_VENUS selects QCOM_MDT_LOADER
>> QCOM_MDT_LOADER selects QCOM_SCM
>>
>> And I came to this,
>>
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index 9fca977ef18d..b8657c561eae 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -12,7 +12,7 @@ config QCOM_GSBI
>>
>>  config QCOM_MDT_LOADER
>> tristate
>> -   select QCOM_SCM
>> +   depends on QCOM_SCM || COMPILE_TEST
> 
> The problem with this is that QCOM_SCM is not user selectable and you
> can't select MDT_LOADER if you make it depend on QCOM_SCM - as this
> might not be enabled by the user (if you make it user selectable).
> 
> 
> The problem that I see changing this is that there's no point in making
> QCOM_SCM and QCOM_MDT_LOADER user selectable - they don't serve a
> purpose on their own.
> 
> 
> PS. Don't you depend on scm functionality directly from the venus driver
> as well?

Yes, qcom video codec driver depends directly on QCOM_SCM. But I'm
relying on the fact that QCOM_MDT_LOADER depends on QCOM_SCM, and
probably QCOM_MDT_LOADER will need to depends on QCOM_SCM forever.

-- 
regards,
Stan

Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

[Maxime Ripard]

On Thu, Jun 15, 2017 at 09:24:08AM +0530, Vinod Koul wrote:
> On Wed, Jun 14, 2017 at 11:04:39AM +0200, Maxime Ripard wrote:
> > On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote:
> > > > SoC info is in compatible, so there's no reason to make it a property.
> > > 
> > > that's why it would need to be optional for the SoC's that needs these..
> > 
> > There's nothing optional about that behaviour, it's mandatory for the
> > SoC that need it, and useless on the SoC that don't.
> 
> And why should kernel put strings for each hw behaviour.

You will have strings in the kernel for each hw behaviour,
disregarding on whether you base the behaviour on the compatible or a
set of properties. In fact, you will have *much* more strings in the
kernel in the latter case.

> I am expecting DT to tell me if this SoC is a special case or not
> and kernel shall handle accordingly

How is this not the case here?

The DT tells you that this SoC is a special case through a compatible
already.

> > Plus, that would require changing the DT binding, which isn't
> > something we can do.
> 
> Any reason why bindings can't change..? I though this was support for new
> SoC...

No, this is a rework of an existing code to support a new SoC. The
code is already there, and the binding too. It has been for 3 years.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature