Re: [PATCH -next] x86_64: tidy up KASAN_EXTRA

[Ingo Molnar]

* Qian Cai  wrote:

> The commit 585a4c1f9978 ("kasan: remove use after scope bugs
> detection.") removed KASAN_EXTRA, so tidy up leftovers.
> 
> Signed-off-by: Qian Cai 
> ---
>  arch/x86/include/asm/page_64_types.h | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/page_64_types.h 
> b/arch/x86/include/asm/page_64_types.h
> index 0ce558a8150d..8f657286d599 100644
> --- a/arch/x86/include/asm/page_64_types.h
> +++ b/arch/x86/include/asm/page_64_types.h
> @@ -7,11 +7,7 @@
>  #endif
>  
>  #ifdef CONFIG_KASAN
> -#ifdef CONFIG_KASAN_EXTRA
> -#define KASAN_STACK_ORDER 2
> -#else
>  #define KASAN_STACK_ORDER 1
> -#endif
>  #else
>  #define KASAN_STACK_ORDER 0
>  #endif

Acked-by: Ingo Molnar 

Thanks,

Ingo

Re: [PATCH V3 1/3] x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available

[Tianyu Lan]

Hi Thomas:
  Thanks for your review.

On Mon, Feb 11, 2019 at 5:48 AM Thomas Gleixner  wrote:
>
> On Thu, 7 Feb 2019, lantianyu1...@gmail.com wrote:
>
> > From: Lan Tianyu 
> >
> > Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic,
> > set x2apic destination mode to physcial mode when x2apic is available
> > and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs have
> > 8-bit APIC id.
>
> This looks good now. Can that be applied independent of the IOMMU stuff or
> should this go together. If the latter:
>
>Reviewed-by: Thomas Gleixner 
>
> If not, I just queue if for 5.1. Let me know,
>

This patch can be applied independently. Thanks.
-- 
Best regards
Tianyu Lan

Re: [PATCH v1 03/16] powerpc/32: move LOAD_MSR_KERNEL() into head_32.h and use it

[Benjamin Herrenschmidt]

On Mon, 2019-02-11 at 07:26 +0100, Christophe Leroy wrote:
> 
> Le 11/02/2019 à 01:21, Benjamin Herrenschmidt a écrit :
> > On Fri, 2019-02-08 at 12:52 +, Christophe Leroy wrote:
> > >   /*
> > > + * MSR_KERNEL is > 0x8000 on 4xx/Book-E since it include MSR_CE.
> > > + */
> > > +.macro __LOAD_MSR_KERNEL r, x
> > > +.if \x >= 0x8000
> > > +   lis \r, (\x)@h
> > > +   ori \r, \r, (\x)@l
> > > +.else
> > > +   li \r, (\x)
> > > +.endif
> > > +.endm
> > > +#define LOAD_MSR_KERNEL(r, x) __LOAD_MSR_KERNEL r, x
> > > +
> > 
> > You changed the limit from >= 0x1 to >= 0x8000 without a
> > corresponding explanation as to why...
> 
> Yes, the existing LOAD_MSR_KERNEL() was buggy because 'li' takes a 
> signed u16, ie between -0x8000 and 0x7999.

Ah yes, I was only looking at the "large" case which is fine...

> By chance it was working because until now nobody was trying to set 
> MSR_KERNEL | MSR_EE.
> 
> Christophe

Re: [PATCH] Documenation: driver-api: fix gpio/board.rst warning

[Linus Walleij]

On Mon, Feb 11, 2019 at 7:28 AM Randy Dunlap  wrote:

> From: Randy Dunlap 
>
> Fix markup warning: insert a blank line before the list.
>
> Documentation/driver-api/gpio/board.rst:209: WARNING: Unexpected indentation.
>
> Signed-off-by: Randy Dunlap 
> Cc: Linus Walleij 
> Cc: Bartosz Golaszewski 
> Cc: linux-g...@vger.kernel.org

Patch applied.

Yours,
Linus Walleij

Re: [PATCH V3 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

[Tianyu Lan]

Hi Alex:
Thanks for your review.

On Fri, Feb 8, 2019 at 2:15 AM Alex Williamson
 wrote:
>
> On Thu,  7 Feb 2019 23:33:48 +0800
> lantianyu1...@gmail.com wrote:
>
> > From: Lan Tianyu 
> >
> > On the bare metal, enabling X2APIC mode requires interrupt remapping
> > function which helps to deliver irq to cpu with 32-bit APIC ID.
> > Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
> > MSI protocol already supports to deliver interrupt to the CPU whose
> > virtual processor index is more than 255. IO-APIC interrupt still has
> > 8-bit APIC ID limitation.
> >
> > This patch is to add Hyper-V stub IOMMU driver in order to enable
> > X2APIC mode successfully in Hyper-V Linux guest. The driver returns X2APIC
> > interrupt remapping capability when X2APIC mode is available. Otherwise,
> > it creates a Hyper-V irq domain to limit IO-APIC interrupts' affinity
> > and make sure cpus assigned with IO-APIC interrupt have 8-bit APIC ID.
> >
> > Define 24 IO-APIC remapping entries because Hyper-V only expose one
> > single IO-APIC and one IO-APIC has 24 pins according IO-APIC spec(
> > https://pdos.csail.mit.edu/6.828/2016/readings/ia32/ioapic.pdf).
> >
> > Signed-off-by: Lan Tianyu 
> > ---
> > Change since v2:
> >- Improve comment about why save IO-APIC entry in the irq chip data.
> >- Some code improvement.
> >- Improve statement in the IOMMU Kconfig.
> >
> > Change since v1:
> >   - Remove unused pr_fmt
> >   - Make ioapic_ir_domain as static variable
> >   - Remove unused variables cfg and entry in the 
> > hyperv_irq_remapping_alloc()
> >   - Fix comments
> > ---
> >  drivers/iommu/Kconfig |   8 ++
> >  drivers/iommu/Makefile|   1 +
> >  drivers/iommu/hyperv-iommu.c  | 194 
> > ++
> >  drivers/iommu/irq_remapping.c |   3 +
> >  drivers/iommu/irq_remapping.h |   1 +
> >  5 files changed, 207 insertions(+)
> >  create mode 100644 drivers/iommu/hyperv-iommu.c
> ...
> > diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c
> > new file mode 100644
> > index 000..d8572c5
> > --- /dev/null
> > +++ b/drivers/iommu/hyperv-iommu.c
> ...
> > +static int __init hyperv_prepare_irq_remapping(void)
> > +{
> > + struct fwnode_handle *fn;
> > + int i;
> > +
> > + if (!hypervisor_is_type(x86_hyper_type) ||
> > + !x2apic_supported())
> > + return -ENODEV;
> > +
> > + fn = irq_domain_alloc_named_id_fwnode("HYPERV-IR", 0);
> > + if (!fn)
> > + return -ENOMEM;
> > +
> > + ioapic_ir_domain =
> > + irq_domain_create_hierarchy(arch_get_ir_parent_domain(),
> > + 0, IOAPIC_REMAPPING_ENTRY, fn,
> > + &hyperv_ir_domain_ops, NULL);
> > +
> > + irq_domain_free_fwnode(fn);
> > +
> > + /*
> > +  * Hyper-V doesn't provide irq remapping function for
> > +  * IO-APIC and so IO-APIC only accepts 8-bit APIC ID.
> > +  * Cpu's APIC ID is read from ACPI MADT table and APIC IDs
> > +  * in the MADT table on Hyper-v are sorted monotonic increasingly.
> > +  * APIC ID reflects cpu topology. There maybe some APIC ID
> > +  * gaps when cpu number in a socket is not power of two. Prepare
> > +  * max cpu affinity for IOAPIC irqs. Scan cpu 0-255 and set cpu
> > +  * into ioapic_max_cpumask if its APIC ID is less than 256.
> > +  */
> > + for (i = 0; i < 256; i++)
> > + if (cpu_physical_id(i) < 256)
> > + cpumask_set_cpu(i, &ioapic_max_cpumask);
>
> This looks sketchy.  What if NR_CPUS is less than 256?  Thanks,

Nice catch. I should check NR_CPUS here. Will update. Thanks.


-- 
Best regards
Tianyu Lan

Re: [RFC PATCH] perf, bpf: Retain kernel executable code in memory to aid Intel PT tracing

[Alexei Starovoitov]

On Mon, Feb 11, 2019 at 09:54:01AM +0200, Adrian Hunter wrote:
> 
> Which is not really a real use-case.
..
> > perf analysis with PT becomes inaccurate and main goal
> > of retaining accurate instruction info is not achieved.
> 
> For the majority of real use-cases, yes it is.

In our fleet not a single server is using Intel PT, yet you're
proposing to penalize all of them with shrinker-based JIT freeing?
There is no negotiation here.
NACK

Re: [PATCH V3 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

[Tianyu Lan]

On Fri, Feb 8, 2019 at 1:15 AM Vitaly Kuznetsov  wrote:
>
> lantianyu1...@gmail.com writes:
>
> > From: Lan Tianyu 
> >
> > On the bare metal, enabling X2APIC mode requires interrupt remapping
> > function which helps to deliver irq to cpu with 32-bit APIC ID.
> > Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
> > MSI protocol already supports to deliver interrupt to the CPU whose
> > virtual processor index is more than 255. IO-APIC interrupt still has
> > 8-bit APIC ID limitation.
> >
> > This patch is to add Hyper-V stub IOMMU driver in order to enable
> > X2APIC mode successfully in Hyper-V Linux guest. The driver returns X2APIC
> > interrupt remapping capability when X2APIC mode is available. Otherwise,
> > it creates a Hyper-V irq domain to limit IO-APIC interrupts' affinity
> > and make sure cpus assigned with IO-APIC interrupt have 8-bit APIC ID.
> >
> > Define 24 IO-APIC remapping entries because Hyper-V only expose one
> > single IO-APIC and one IO-APIC has 24 pins according IO-APIC spec(
> > https://pdos.csail.mit.edu/6.828/2016/readings/ia32/ioapic.pdf).
> >
> > Signed-off-by: Lan Tianyu 
> > ---
> > Change since v2:
> >- Improve comment about why save IO-APIC entry in the irq chip data.
> >- Some code improvement.
> >- Improve statement in the IOMMU Kconfig.
> >
> > Change since v1:
> >   - Remove unused pr_fmt
> >   - Make ioapic_ir_domain as static variable
> >   - Remove unused variables cfg and entry in the 
> > hyperv_irq_remapping_alloc()
> >   - Fix comments
> > ---
> >  drivers/iommu/Kconfig |   8 ++
> >  drivers/iommu/Makefile|   1 +
> >  drivers/iommu/hyperv-iommu.c  | 194 
> > ++
> >  drivers/iommu/irq_remapping.c |   3 +
> >  drivers/iommu/irq_remapping.h |   1 +
> >  5 files changed, 207 insertions(+)
> >  create mode 100644 drivers/iommu/hyperv-iommu.c
> >
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index 45d7021..6090935 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -437,4 +437,12 @@ config QCOM_IOMMU
> >   help
> > Support for IOMMU on certain Qualcomm SoCs.
> >
> > +config HYPERV_IOMMU
> > + bool "Hyper-V x2APIC IRQ Handling"
> > + depends on HYPERV
> > + select IOMMU_API
> > + help
> > +   Stub IOMMU driver to handle IRQs as to allow Hyper-V Linux
> > +   guests to run with x2APIC mode enabled.
> > +
> >  endif # IOMMU_SUPPORT
> > diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> > index a158a68..8c71a15 100644
> > --- a/drivers/iommu/Makefile
> > +++ b/drivers/iommu/Makefile
> > @@ -32,3 +32,4 @@ obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
> >  obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
> >  obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
> >  obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
> > +obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
> > diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c
> > new file mode 100644
> > index 000..d8572c5
> > --- /dev/null
> > +++ b/drivers/iommu/hyperv-iommu.c
> > @@ -0,0 +1,194 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +/*
> > + * Hyper-V stub IOMMU driver.
> > + *
> > + * Copyright (C) 2019, Microsoft, Inc.
> > + *
> > + * Author : Lan Tianyu 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "irq_remapping.h"
> > +
> > +#ifdef CONFIG_IRQ_REMAP
> > +
> > +/*
> > + * According 82093AA IO-APIC spec , IO APIC has a 24-entry Interrupt
> > + * Redirection Table. Hyper-V exposes one single IO-APIC and so define
> > + * 24 IO APIC remmapping entries.
> > + */
> > +#define IOAPIC_REMAPPING_ENTRY 24
> > +
> > +static cpumask_t ioapic_max_cpumask = { CPU_BITS_NONE };
> > +static struct irq_domain *ioapic_ir_domain;
> > +
> > +static int hyperv_ir_set_affinity(struct irq_data *data,
> > + const struct cpumask *mask, bool force)
> > +{
> > + struct irq_data *parent = data->parent_data;
> > + struct irq_cfg *cfg = irqd_cfg(data);
> > + struct IO_APIC_route_entry *entry;
> > + int ret;
> > +
> > + /* Return error If new irq affinity is out of ioapic_max_cpumask. */
> > + if (!cpumask_subset(mask, &ioapic_max_cpumask))
> > + return -EINVAL;
> > +
> > + ret = parent->chip->irq_set_affinity(parent, mask, force);
> > + if (ret < 0 || ret == IRQ_SET_MASK_OK_DONE)
> > + return ret;
> > +
> > + entry = data->chip_data;
> > + entry->dest = cfg->dest_apicid;
> > + entry->vector = cfg->vector;
> > + send_cleanup_vector(cfg);
> > +
> > + return 0;
> > +}
> > +
> > +static struct irq_chip hyperv_ir_chip = {
> > + .name   = "HYPERV-IR",
> > + .irq_ack= apic_ack_irq,
> > + .irq_set_affinity   = hyperv_ir_set_affinity,
> > +};
> > +
> > +static int hy

Re: [PATCH 1/9] pinctrl: sunxi: Support I/O bias voltage setting on A80

[Linus Walleij]

On Wed, Feb 6, 2019 at 4:32 AM Chen-Yu Tsai  wrote:

> The A80 SoC has configuration registers for I/O bias voltage. Incorrect
> settings would make the affected peripherals inoperable in some cases,
> such as Ethernet RGMII signals biased at 2.5V with the settings still
> at 3.3V. However low speed signals such as MDIO on the same group of
> pins seem to be unaffected.
>
> Previously there was no way to know what the actual voltage used was,
> short of hard-coding a value in the device tree. With the new pin bank
> regulator supply support in place, the driver can now query the
> regulator for its voltage, and if it's valid (as opposed to being the
> dummy regulator), set the bias voltage setting accordingly.
>
> Add a quirk to denote the presence of the configuration registers, and
> a function to set the correct setting based on the voltage read back
> from the regulator.
>
> This is only done when the regulator is first acquired and enabled.
> While it would be nice to have a notifier on the regulator so that when
> the voltage changes, the driver can update the setting, in practice no
> board currently supports dynamic changing of the I/O voltages.
>
> Signed-off-by: Chen-Yu Tsai 

I merged the v5.0-rc6 into my devel branch and applied this patch on
top now.

All the DTS file changes should be merged through ARM SoC, and
they should work fine now.

Yours,
Linus Walleij

Re: [PATCH v3 3/5] i2c:ocores: add polling interface

[Federico Vaga]

On Saturday, February 9, 2019 10:33:53 PM CET Andrew Lunn wrote:
> > +static int ocores_poll_wait(struct ocores_i2c *i2c)
> > +{
> > +   u8 mask;
> > +   int err;
> > +
> > +   if (i2c->state == STATE_DONE || i2c->state == STATE_ERROR) {
> > +   /* transfer is over */
> > +   mask = OCI2C_STAT_BUSY;
> > +   } else {
> > +   /* on going transfer */
> > +   mask = OCI2C_STAT_TIP;
> > +   udelay((8 * 1000) / i2c->bus_clock_khz);
> > +   }
> > +
> > +   /*
> > +* once we are here we expect to get the expected result immediately
> > +* so if after 1ms we timeout then something is broken.
> > +*/
> > +   err = ocores_wait(i2c, OCI2C_STATUS, mask, 0, msecs_to_jiffies(1));
> 
> Hi Federico
> 
> I did some timing tests for this. On my box, we request a udelay of
> 80uS. The kernel actually delays for about 79uS. We then spin in
> ocores_wait() for an additional 10-11uS, which is 3 to 4 iterations.
> 
> There are actually 9 bits on the wire, not 8, since there is an
> ACK/NACK bit after the actual data transfer. So i changed the delay to
> (9 * 1000) / i2c->bus_clock_khz. That resulted in ocores_wait() mostly
> not looping at all. But for reading an 4K AT24 EEPROM, it increased
> the read time by 10ms, from 424ms to 434ms. So we should probably keep
> with 8.
> 
> Tested-by: Andrew Lunn 

I had a similar experience. I will add a comment in the code to explain that 8 
is not a mistake but a conscious decision. Then I will add what you wrote here
in the patch changelog

> 
> Andrew

Re: [PATCH V3 2/3] HYPERV/IOMMU: Add Hyper-V stub IOMMU driver

[Tianyu Lan]

Hi Olaf:
 Thanks for your review.

On Fri, Feb 8, 2019 at 10:52 PM Olaf Hering  wrote:
>
> On Thu, Feb 07, lantianyu1...@gmail.com wrote:
>
> > +++ b/drivers/iommu/Kconfig
> > +config HYPERV_IOMMU
> > + bool "Hyper-V x2APIC IRQ Handling"
> > + depends on HYPERV
> > + select IOMMU_API
> > + help
>
>
> Consider adding 'default HYPERV' like some other drivers already do it.
>
> Olaf

Good suggestion and will update. Thanks.

-- 
Best regards
Tianyu Lan

Re: [PATCH v8 0/5] media/sun6i: Allwinner A64 CSI support

[Jagan Teki]

Mauro and Maxime,

On Mon, Jan 28, 2019 at 2:29 PM Jagan Teki  wrote:
>
> Add CSI support for Allwinner A64. Here is previous series[1]
>
> Changes for v8:
> - update proper enable and disable sequnce for clk_mod
> - fix warning for patch "media: sun6i: Add A64 CSI block support"
> - collect Maxime Acked-by
> Changes for v7:
> - Drop quirk change, and add as suggusted by Maxime
> - Use csi instead csi0 in pinctrl function
> Changes for v6:
> - set the mod rate in seett_power instead of probe
> Changes for v5:
> - Add mod_rate quirk for better handling clk_set code
> Changes for v4:
> - update the compatible string order
> - add proper commit message
> - included BPI-M64 patch
> - skipped amarula-a64 patch
> Changes for v3:
> - update dt-bindings for A64
> - set mod clock via csi driver
> - remove assign clocks from dtsi
> - remove i2c-gpio opendrian
> - fix avdd and dovdd supplies
> - remove vcc-csi pin group supply
>
> [1] https://patchwork.kernel.org/cover/10779831/
>
> Jagan Teki (5):
>   dt-bindings: media: sun6i: Add A64 CSI compatible
>   media: sun6i: Add A64 CSI block support
>   arm64: dts: allwinner: a64: Add A64 CSI controller
>   arm64: dts: allwinner: a64: Add pinmux setting for CSI MCLK on PE1

Any chance to apply this patches? dtsi patch is already been merged
and all been Acked as well.

Re: [RFC PATCH] perf, bpf: Retain kernel executable code in memory to aid Intel PT tracing

[Adrian Hunter]

On 11/02/19 10:18 AM, Alexei Starovoitov wrote:
> On Mon, Feb 11, 2019 at 09:54:01AM +0200, Adrian Hunter wrote:
>>
>> Which is not really a real use-case.
> ..
>>> perf analysis with PT becomes inaccurate and main goal
>>> of retaining accurate instruction info is not achieved.
>>
>> For the majority of real use-cases, yes it is.
> 
> In our fleet not a single server is using Intel PT, yet you're
> proposing to penalize all of them with shrinker-based JIT freeing?

I already responded to that.

> There is no negotiation here.

Apart from Peter and Ingo already having indicated a different approach is
preferred, why not? Shouldn't maintainers provide technical reasons.

[GIT PULL] extcon next for v5.1

[Chanwoo Choi]

Dear Greg,

This is extcon-next pull request for v5.1. I add detailed description of
this pull request on below. Please pull extcon with following updates.

Best Regards,
Chanwoo Choi

The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9:

  Linux 5.0-rc6 (2019-02-10 14:42:20 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-next-for-5.1

for you to fetch changes up to 3dfed89512d3b65f6f092cfaaee53b0698bbf75e:

  extcon: ptn5150: Fix return value check in ptn5150_i2c_probe() (2019-02-11 
17:21:38 +0900)


Vijai Kumar K (1):
  extcon: Add support for ptn5150 extcon driver

Wei Yongjun (1):
  extcon: ptn5150: Fix return value check in ptn5150_i2c_probe()

 .../devicetree/bindings/extcon/extcon-ptn5150.txt  |  27 ++
 drivers/extcon/Kconfig |   8 +
 drivers/extcon/Makefile|   1 +
 drivers/extcon/extcon-ptn5150.c| 339 +
 4 files changed, 375 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
 create mode 100644 drivers/extcon/extcon-ptn5150.c

Re: [PATCH] mmc: spi: Fix card detection during probe

[Linus Walleij]

On Sun, Feb 10, 2019 at 6:31 PM Jonathan Neuschäfer
 wrote:

> When using the mmc_spi driver with a card-detect pin, I noticed that the
> card was not detected immediately after probe, but only after it was
> unplugged and plugged back in (and the CD IRQ fired).
>
> The call tree looks something like this:
>
> mmc_spi_probe
>   mmc_add_host
> mmc_start_host
>   _mmc_detect_change
> mmc_schedule_delayed_work(&host->detect, 0)
>   mmc_rescan
> host->bus_ops->detect(host)
>   mmc_detect
> _mmc_detect_card_removed
>   host->ops->get_cd(host)
> mmc_gpio_get_cd -> -ENOSYS (ctx->cd_gpio not set)
>   mmc_gpiod_request_cd
> ctx->cd_gpio = desc
>
> To fix this issue, call mmc_detect_change after the card-detect GPIO/IRQ
> is registered.
>
> Signed-off-by: Jonathan Neuschäfer 

Seems correct!
Reviewed-by: Linus Walleij 

Yours,
Linus Walleij

Re: [PATCH] Input: matrix_keypad - use flush_delayed_work()

[Dmitry Torokhov]

Hi Sven,

On Sun, Feb 10, 2019 at 12:43:21PM -0500, Sven Van Asbroeck wrote:
> Hi Dmitry,
> 
> On Thu, Feb 7, 2019 at 5:46 PM Dmitry Torokhov
>  wrote:
> >
> > We should be using flush_delayed_work() instead of flush_work() in
> > matrix_keypad_stop() to ensure that we are not missing work that is
> > scheduled but not yet put in the workqueue (i.e. its delay timer has not
> > expired yet).
> >
> 
> Could the following scenario cause a use-after-free?
> (I am adding comments on lines starting with -->)
> 
> a) user closes the device handle:
> 
> static void matrix_keypad_stop(struct input_dev *dev)
> {
> struct matrix_keypad *keypad = input_get_drvdata(dev);
> 
> spin_lock_irq(&keypad->lock);
> keypad->stopped = true;
> spin_unlock_irq(&keypad->lock);
> 
> flush_work(&keypad->work.work);
> -->
> --> new interrupt comes in, and schedules new delayed keypad->work (1)

It will not schedule new work because we check keypad->stopped flag
in ISR.

Thanks.

-- 
Dmitry

Re: [PATCH] drm/doc: Remove solved KMS cleanup task

[Daniel Vetter]

On Fri, Feb 08, 2019 at 05:53:12PM -0200, Shayenne Moura wrote:
> Remove KMS cleanup task from documentation solved by patchset
> https://patchwork.freedesktop.org/series/54310/
> 
> Signed-off-by: Shayenne Moura 

Thanks for your patch, applied to drm-misc-next.
-Daniel

> ---
>  Documentation/gpu/todo.rst | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index cda4a37a02f0..159a4aba49e6 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -398,10 +398,6 @@ KMS cleanups
>  
>  Some of these date from the very introduction of KMS in 2008 ...
>  
> -- drm_display_mode doesn't need to be derived from drm_mode_object. That's
> -  leftovers from older (never merged into upstream) KMS designs where modes
> -  where set using their ID, including support to add/remove modes.
> -
>  - Make ->funcs and ->helper_private vtables optional. There's a bunch of 
> empty
>function tables in drivers, but before we can remove them we need to make 
> sure
>that all the users in helpers and drivers do correctly check for a NULL
> -- 
> 2.17.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 12/28] thunderbolt: Add functions for allocating and releasing hop IDs

[Mika Westerberg]

On Sun, Feb 10, 2019 at 01:13:53PM +0100, Lukas Wunner wrote:
> On Wed, Feb 06, 2019 at 04:17:22PM +0300, Mika Westerberg wrote:
> > Each port has a separate path configuration space that is used for
> > finding the next hop (switch) in the path. Hop ID is an index to this
> > configuration space and hop IDs 0 - 7 are reserved.
> > 
> > In order to get next available hop ID for each direction we provide two
> > pairs of helper functions that can be used to allocate and release hop
> > IDs for a given port.
> [...]
> > +static int tb_port_alloc_hopid(struct tb_port *port, bool in, int 
> > min_hopid,
> > +  int max_hopid)
> > +{
> > +   int port_max_hopid;
> > +   struct ida *ida;
> > +
> > +   if (in) {
> > +   port_max_hopid = port->config.max_in_hop_id;
> > +   ida = &port->in_hopids;
> > +   } else {
> > +   port_max_hopid = port->config.max_out_hop_id;
> > +   ida = &port->out_hopids;
> > +   }
> > +
> > +   /* Hop IDs 0-7 are reserved */
> > +   if (min_hopid < 8)
> > +   min_hopid = 8;
> > +
> > +   if (max_hopid < 0 || max_hopid > port_max_hopid)
> > +   max_hopid = port_max_hopid;
> > +
> > +   return ida_simple_get(ida, min_hopid, max_hopid + 1, GFP_KERNEL);
> > +}
> 
> If there are two Macs at the ends of the daisy-chain with Thunderbolt
> devices in-between, the other Mac may already have established tunnels
> to some of the devices and therefore has occupied hop entries in the
> devices' path config space.  How do you ensure that you don't allocate
> the same entries and overwrite the other Mac's hop entries, thereby
> breaking its tunnels?

If the other Mac has enumerated the device (set the upstream port,
route, depth) then the other Mac cannot access the device. You get an
error (we deal with that in the later patch in the series when we
identify XDomain connections). The Hop ID allocation is only relevant in
a single domain.  Crossing one needs to have protocol such as we have in
case of ThunderboltIP to negotiate Hop IDs used in the link between two
domains.

[PATCH v4 2/5] i2c:ocores: do not handle IRQ if IF is not set

[Federico Vaga]

If the Interrupt Flag (IF) is not set, we should not handle the IRQ:
- the line can be shared with other devices
- it can be a spurious interrupt

To avoid reading twice the status register, the ocores_process() function
expects it to be read by the caller.

Signed-off-by: Federico Vaga 
Acked-by: Peter Korsgaard 
Reviewed-by: Andrew Lunn 

---
 drivers/i2c/busses/i2c-ocores.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index aa85202..fcc2558 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -143,10 +143,9 @@ static inline u8 oc_getreg(struct ocores_i2c *i2c, int reg)
return i2c->getreg(i2c, reg);
 }
 
-static void ocores_process(struct ocores_i2c *i2c)
+static void ocores_process(struct ocores_i2c *i2c, u8 stat)
 {
struct i2c_msg *msg = i2c->msg;
-   u8 stat = oc_getreg(i2c, OCI2C_STATUS);
unsigned long flags;
 
/*
@@ -223,8 +222,12 @@ out:
 static irqreturn_t ocores_isr(int irq, void *dev_id)
 {
struct ocores_i2c *i2c = dev_id;
+   u8 stat = oc_getreg(i2c, OCI2C_STATUS);
+
+   if (!(stat & OCI2C_STAT_IF))
+   return IRQ_NONE;
 
-   ocores_process(i2c);
+   ocores_process(i2c, stat);
 
return IRQ_HANDLED;
 }
-- 
2.15.0

[PATCH v4 4/5] i2c:ocores: add SPDX tag

[Federico Vaga]

It adds the SPDX tag and it removes the old text about the GPLv2.

Signed-off-by: Federico Vaga 
Reviewed-by: Andrew Lunn 

---
 drivers/i2c/busses/i2c-ocores.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index bbe3e96..e87fce0 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * i2c-ocores.c: I2C bus driver for OpenCores I2C controller
  * (https://opencores.org/project/i2c/overview)
@@ -6,10 +7,6 @@
  *
  * Support for the GRLIB port of the controller by
  * Andreas Larsson 
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2.  This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
  */
 
 #include 
-- 
2.15.0

[PATCH v4 3/5] i2c:ocores: add polling interface

[Federico Vaga]

This driver assumes that an interrupt line is always available for
the I2C master. This is not always the case and this patch adds support
for a polling version.

Report from Andrew Lunn:

  I did some timing tests for this. On my box, we request a udelay of
  80uS. The kernel actually delays for about 79uS. We then spin in
  ocores_wait() for an additional 10-11uS, which is 3 to 4 iterations.

  There are actually 9 bits on the wire, not 8, since there is an
  ACK/NACK bit after the actual data transfer. So i changed the delay to
  (9 * 1000) / i2c->bus_clock_khz. That resulted in ocores_wait() mostly
  not looping at all. But for reading an 4K AT24 EEPROM, it increased
  the read time by 10ms, from 424ms to 434ms. So we should probably keep
  with 8.

Signed-off-by: Federico Vaga 
Tested-by: Andrew Lunn 

---
 drivers/i2c/busses/i2c-ocores.c | 180 +++-
 1 file changed, 160 insertions(+), 20 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index fcc2558..d42a324 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#define OCORES_FLAG_POLL BIT(0)
 
 /**
  * @process_lock: protect I2C transfer process.
@@ -35,6 +39,7 @@ struct ocores_i2c {
void __iomem *base;
u32 reg_shift;
u32 reg_io_width;
+   unsigned long flags;
wait_queue_head_t wait;
struct i2c_adapter adap;
struct i2c_msg *msg;
@@ -246,10 +251,117 @@ static void ocores_process_timeout(struct ocores_i2c 
*i2c)
spin_unlock_irqrestore(&i2c->process_lock, flags);
 }
 
-static int ocores_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
+/**
+ * Wait until something change in a given register
+ * @i2c: ocores I2C device instance
+ * @reg: register to query
+ * @mask: bitmask to apply on register value
+ * @val: expected result
+ * @timeout: timeout in jiffies
+ *
+ * Timeout is necessary to avoid to stay here forever when the chip
+ * does not answer correctly.
+ *
+ * Return: 0 on success, -ETIMEDOUT on timeout
+ */
+static int ocores_wait(struct ocores_i2c *i2c,
+  int reg, u8 mask, u8 val,
+  const unsigned long timeout)
+{
+   unsigned long j;
+
+   j = jiffies + timeout;
+   while (1) {
+   u8 status = oc_getreg(i2c, reg);
+
+   if ((status & mask) == val)
+   break;
+
+   if (time_after(jiffies, j))
+   return -ETIMEDOUT;
+   }
+   return 0;
+}
+
+/**
+ * Wait until is possible to process some data
+ * @i2c: ocores I2C device instance
+ *
+ * Used when the device is in polling mode (interrupts disabled).
+ *
+ * Return: 0 on success, -ETIMEDOUT on timeout
+ */
+static int ocores_poll_wait(struct ocores_i2c *i2c)
+{
+   u8 mask;
+   int err;
+
+   if (i2c->state == STATE_DONE || i2c->state == STATE_ERROR) {
+   /* transfer is over */
+   mask = OCI2C_STAT_BUSY;
+   } else {
+   /* on going transfer */
+   mask = OCI2C_STAT_TIP;
+   /*
+* We wait for the data to be transfered (8bit),
+* then we start polling on the ACK/NACK bit
+*/
+   udelay((8 * 1000) / i2c->bus_clock_khz);
+   }
+
+   /*
+* once we are here we expect to get the expected result immediately
+* so if after 1ms we timeout then something is broken.
+*/
+   err = ocores_wait(i2c, OCI2C_STATUS, mask, 0, msecs_to_jiffies(1));
+   if (err)
+   dev_warn(i2c->adap.dev.parent,
+"%s: STATUS timeout, bit 0x%x did not clear in 1ms\n",
+__func__, mask);
+   return err;
+}
+
+
+/**
+ * It handles an IRQ-less transfer
+ * @i2c: ocores I2C device instance
+ *
+ * Even if IRQ are disabled, the I2C OpenCore IP behavior is exactly the same
+ * (only that IRQ are not produced). This means that we can re-use entirely
+ * ocores_isr(), we just add our polling code around it.
+ *
+ * It can run in atomic context
+ */
+static void ocores_process_polling(struct ocores_i2c *i2c)
+{
+   while (1) {
+   irqreturn_t ret;
+   int err;
+
+   err = ocores_poll_wait(i2c);
+   if (err) {
+   i2c->state = STATE_ERROR;
+   break; /* timeout */
+   }
+
+   ret = ocores_isr(-1, i2c);
+   if (ret == IRQ_NONE)
+   break; /* all messages have been transfered */
+   }
+}
+
+static int ocores_xfer_core(struct ocores_i2c *i2c,
+   struct i2c_msg *msgs, int num,
+   bool polling)
 {
-   struct ocores_i2c *i2c = i2c_get_adapdata(adap);

[PATCH v4 1/5] i2c:ocores: stop transfer on timeout

[Federico Vaga]

Detecting a timeout is ok, but we also need to assert a STOP command on
the bus in order to prevent it from generating interrupts when there are
no on going transfers.

Example: very long transmission.

1. ocores_xfer: START a transfer
2. ocores_isr : handle byte by byte the transfer
3. ocores_xfer: goes in timeout [[bugfix here]]
4. ocores_xfer: return to I2C subsystem and to the I2C driver
5. I2C driver : it may clean up the i2c_msg memory
6. ocores_isr : receives another interrupt (pending bytes to be
transferred) but the i2c_msg memory is invalid now

So, since the transfer was too long, we have to detect the timeout and
STOP the transfer.

Another point is that we have a critical region here. When handling the
timeout condition we may have a running IRQ handler. For this reason I
introduce a spinlock.

In order to make easier to understan locking I have:
- added a new function to handle timeout
- modified the current ocores_process() function in order to be protected
  by the new spinlock
Like this it is obvious at first sight that this locking serializes
the execution of ocores_process() and ocores_process_timeout()

Signed-off-by: Federico Vaga 
Reviewed-by: Andrew Lunn 

---
 drivers/i2c/busses/i2c-ocores.c | 54 ++---
 1 file changed, 45 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 87f9caa..aa85202 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -25,7 +25,12 @@
 #include 
 #include 
 #include 
+#include 
 
+/**
+ * @process_lock: protect I2C transfer process.
+ * ocores_process() and ocores_process_timeout() can't run in parallel.
+ */
 struct ocores_i2c {
void __iomem *base;
u32 reg_shift;
@@ -36,6 +41,7 @@ struct ocores_i2c {
int pos;
int nmsgs;
int state; /* see STATE_ */
+   spinlock_t process_lock;
struct clk *clk;
int ip_clock_khz;
int bus_clock_khz;
@@ -141,19 +147,26 @@ static void ocores_process(struct ocores_i2c *i2c)
 {
struct i2c_msg *msg = i2c->msg;
u8 stat = oc_getreg(i2c, OCI2C_STATUS);
+   unsigned long flags;
+
+   /*
+* If we spin here is because we are in timeout, so we are going
+* to be in STATE_ERROR. See ocores_process_timeout()
+*/
+   spin_lock_irqsave(&i2c->process_lock, flags);
 
if ((i2c->state == STATE_DONE) || (i2c->state == STATE_ERROR)) {
/* stop has been sent */
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
wake_up(&i2c->wait);
-   return;
+   goto out;
}
 
/* error? */
if (stat & OCI2C_STAT_ARBLOST) {
i2c->state = STATE_ERROR;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
 
if ((i2c->state == STATE_START) || (i2c->state == STATE_WRITE)) {
@@ -163,7 +176,7 @@ static void ocores_process(struct ocores_i2c *i2c)
if (stat & OCI2C_STAT_NACK) {
i2c->state = STATE_ERROR;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
} else
msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
@@ -184,14 +197,14 @@ static void ocores_process(struct ocores_i2c *i2c)
 
oc_setreg(i2c, OCI2C_DATA, addr);
oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
-   return;
+   goto out;
} else
i2c->state = (msg->flags & I2C_M_RD)
? STATE_READ : STATE_WRITE;
} else {
i2c->state = STATE_DONE;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
-   return;
+   goto out;
}
}
 
@@ -202,6 +215,9 @@ static void ocores_process(struct ocores_i2c *i2c)
oc_setreg(i2c, OCI2C_DATA, msg->buf[i2c->pos++]);
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_WRITE);
}
+
+out:
+   spin_unlock_irqrestore(&i2c->process_lock, flags);
 }
 
 static irqreturn_t ocores_isr(int irq, void *dev_id)
@@ -213,9 +229,24 @@ static irqreturn_t ocores_isr(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+/**
+ * Process timeout event
+ * @i2c: ocores I2C device instance
+ */
+static void ocores_process_timeout(struct ocores_i2c *i2c)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(&i2c->process_lock, flags);
+   i2c->state = STATE_ERROR;
+   oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
+   spin_unlock_irqrestore(&i2c->process_lock, flags);
+}
+
 static int ocores_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int 

[PATCH v4 0/5] i2c:ocores: improvements

[Federico Vaga]

This patch set provides improvements to the i2c-ocore driver.

[V3 -> V4]
- add reviews-by/tested-by
- add comment to justify the formula in
udelay((8 * 1000) / i2c->bus_clock_khz);

[V2 -> V3]
- fix particular error condition on platform_get_irq(). Copied from
  https://patchwork.ozlabs.org/patch/1038409/

[V1 -> V2]
- replaced usleep_range() with udelay() so that the polling version can be
  used in atomic context.
- added dedicated patch for minor style issues
- fixed delay computation
- use spin_lock_irqsave(), instead of spin_trylock_irqsave(). IACK is always
  necessary and a trylock would generate an extra interrupt for nothing
- make the driver ready for an eventual master_xfer_irqless()

[PATCH v4 5/5] i2c:ocores: checkpatch fixes

[Federico Vaga]

Miscellaneous style fixes from checkpatch

Signed-off-by: Federico Vaga 
Reviewed-by: Andrew Lunn 

---
 drivers/i2c/busses/i2c-ocores.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
index 5b80190..ba35d2a 100644
--- a/drivers/i2c/busses/i2c-ocores.c
+++ b/drivers/i2c/busses/i2c-ocores.c
@@ -182,8 +182,9 @@ static void ocores_process(struct ocores_i2c *i2c, u8 stat)
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
goto out;
}
-   } else
+   } else {
msg->buf[i2c->pos++] = oc_getreg(i2c, OCI2C_DATA);
+   }
 
/* end of msg? */
if (i2c->pos == msg->len) {
@@ -202,9 +203,9 @@ static void ocores_process(struct ocores_i2c *i2c, u8 stat)
oc_setreg(i2c, OCI2C_DATA, addr);
oc_setreg(i2c, OCI2C_CMD,  OCI2C_CMD_START);
goto out;
-   } else
-   i2c->state = (msg->flags & I2C_M_RD)
-   ? STATE_READ : STATE_WRITE;
+   }
+   i2c->state = (msg->flags & I2C_M_RD)
+   ? STATE_READ : STATE_WRITE;
} else {
i2c->state = STATE_DONE;
oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_STOP);
@@ -405,7 +406,8 @@ static int ocores_init(struct device *dev, struct 
ocores_i2c *i2c)
u8 ctrl = oc_getreg(i2c, OCI2C_CONTROL);
 
/* make sure the device is disabled */
-   oc_setreg(i2c, OCI2C_CONTROL, ctrl & ~(OCI2C_CTRL_EN|OCI2C_CTRL_IEN));
+   ctrl &= ~(OCI2C_CTRL_EN | OCI2C_CTRL_IEN);
+   oc_setreg(i2c, OCI2C_CONTROL, ctrl);
 
prescale = (i2c->ip_clock_khz / (5 * i2c->bus_clock_khz)) - 1;
prescale = clamp(prescale, 0, 0x);
@@ -462,11 +464,13 @@ MODULE_DEVICE_TABLE(of, ocores_i2c_match);
 #ifdef CONFIG_OF
 /* Read and write functions for the GRLIB port of the controller. Registers are
  * 32-bit big endian and the PRELOW and PREHIGH registers are merged into one
- * register. The subsequent registers has their offset decreased accordingly. 
*/
+ * register. The subsequent registers has their offset decreased accordingly.
+ */
 static u8 oc_getreg_grlib(struct ocores_i2c *i2c, int reg)
 {
u32 rd;
int rreg = reg;
+
if (reg != OCI2C_PRELOW)
rreg--;
rd = ioread32be(i2c->base + (rreg << i2c->reg_shift));
@@ -480,6 +484,7 @@ static void oc_setreg_grlib(struct ocores_i2c *i2c, int 
reg, u8 value)
 {
u32 curr, wr;
int rreg = reg;
+
if (reg != OCI2C_PRELOW)
rreg--;
if (reg == OCI2C_PRELOW || reg == OCI2C_PREHIGH) {
@@ -568,7 +573,7 @@ static int ocores_i2c_of_probe(struct platform_device *pdev,
return 0;
 }
 #else
-#define ocores_i2c_of_probe(pdev,i2c) -ENODEV
+#define ocores_i2c_of_probe(pdev, i2c) -ENODEV
 #endif
 
 static int ocores_i2c_probe(struct platform_device *pdev)
-- 
2.15.0

Re: [PATCH v2 2/4] dt-bindings: gnss: add mediatek binding

[Johan Hovold]

On Mon, Jan 28, 2019 at 04:46:53PM +0100, Loys Ollivier wrote:
> 
> On Fri 25 Jan 2019 at 09:07, Johan Hovold wrote:
> 
> > On Thu, Jan 17, 2019 at 05:54:32PM +0100, Loys Ollivier wrote:
> >> Add binding for Mediatek-based GNSS receivers.
> >> 
> >> Signed-off-by: Loys Ollivier 
> >> ---
> >> 
> >> v2:
> >> Renamed bindings from Globaltop/gtop to Mediatek/mtk.
> >> Moved current-speed as an optional propertie.
> >> Removed the status line in the example.
> >> Added "mediatek,mt3339" compatible.

> >> +++ b/Documentation/devicetree/bindings/gnss/mediatek.txt
> >> @@ -0,0 +1,39 @@
> >> +Mediatek-based GNSS Receiver DT binding
> >> +
> >> +Mediatek chipsets are used in GNSS-receiver modules produced by several
> >> +vendors and can use UART, SPI or I2C interfaces.
> >> +
> >> +Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic
> >> +properties.
> >> +
> >> +Required properties:
> >> +
> >> +- compatible  : Must be one of
> >> +
> >> +  "globaltop,pa6h"
> >> +  "mediatek,mt3339"
> >
> > I'm not sure it makes sense to add the GPS chip itself as it cannot be
> > used stand-alone AFAIU, and either not way would require a lot more
> > resources to be defined than what you add to this binding.
> 
> OK, I find it a bit confusing to have Mediatek bindings but no
> compatible Mediatek SoCs.
> But it is true that it can't be used stand-alone. I will remove this
> reference and also remove it from the mtk.c driver code from this patch
> serie.

> >> +Required properties (I2C):
> >> +- reg : I2C slave address
> >> +
> >> +Required properties (SPI):
> >> +- reg : SPI chip select address
> >
> > While the mt3339 appears to support these interfaces, the globaltop one
> > does not.
> >
> > Have you looked around for a small sample of mt3339-based receivers, to
> > see whether anyone actually provides these?
> 
> Again I'm confused by the fact that it is the Mediatek bindings.
> Hence why I have added it and why it was not present in the v1 that was
> only for Globaltop.

This is no different from the sirfstar driver for receivers based on
those chipsets but manufactured by various other vendors.

> I find it odd mentionning the chipset but not all its interfaces.
> I will remove these sections and only list supported interfaces (i.e.
> UART). Other interfaces can be added afterward if one finds a board that
> provides them.

Right, but please do look around for other receivers using this chipset
so that we can make the binding generic enough to cover those as well
(e.g. by choosing representative resource names).

Johan

Re: [PATCH] iio: adc: ti-ads7950: add GPIO support

[Linus Walleij]

Hi Justin,

thanks for your patch!

On Fri, Feb 8, 2019 at 8:25 PM  wrote:

> From: Justin Chen 
>
> The ADS79XX has GPIO pins that can be used. Add support for the GPIO
> pins using the GPIO chip framework.
>
> Signed-off-by: Justin Chen 
(...)

> @@ -56,11 +61,17 @@ struct ti_ads7950_state {
> struct spi_message  ring_msg;
> struct spi_message  scan_single_msg;
>
> +   struct iio_dev  *indio_dev;
> +   struct gpio_chip*chip;

Why use a pointer here? Correct me if wrong by a struct ti_ads7950_state is
always allocated for each instance of the hardware right?
So just struct gpio_chip chip; should be fine, then just fill in that
struct.

> +   /* Add GPIO chip */
> +   st->chip->label = dev_name(&st->spi->dev);

So it would be st->chip.label = ... etc.

> +   chip = devm_kzalloc(&spi->dev, sizeof(*chip), GFP_KERNEL);
> +   if (!chip)
> +   return -ENOMEM;

And no need to do this.

Apart from that it looks OK to me, but there are some locking comments
I see.

Yours,
Linus Walleij

Re: [GIT PULL] extcon next for v5.1

[Greg KH]

On Mon, Feb 11, 2019 at 05:26:52PM +0900, Chanwoo Choi wrote:
> Dear Greg,
> 
> This is extcon-next pull request for v5.1. I add detailed description of
> this pull request on below. Please pull extcon with following updates.
> 
> Best Regards,
> Chanwoo Choi
> 
> The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9:
> 
>   Linux 5.0-rc6 (2019-02-10 14:42:20 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
> tags/extcon-next-for-5.1

Pulled and pushed out, thanks.

greg k-h

Re: [PATCH 1/2] parport: daisy: use new parport device model

[Greg Kroah-Hartman]

On Sat, Feb 09, 2019 at 08:59:06PM +, Sudip Mukherjee wrote:
> - return bus_register(&parport_bus_type);
> + int retval;
> +
> + retval = bus_register(&parport_bus_type);
> + if (retval)
> + return retval;
> +#ifdef CONFIG_PARPORT_1284
> + daisy_drv_init();
> +#endif

Shouldn't you hide these #ifdef lines in the .h file instead of putting
them in the .c file?

thanks,

greg k-h

[PATCH -mm -V7] mm, swap: fix race between swapoff and some swap operations

[Huang, Ying]

From: Huang Ying 

When swapin is performed, after getting the swap entry information from
the page table, system will swap in the swap entry, without any lock held
to prevent the swap device from being swapoff.  This may cause the race
like below,

CPU 1   CPU 2
-   -
do_swap_page
  swapin_readahead
__read_swap_cache_async
swapoff   swapcache_prepare
  p->swap_map = NULL__swap_duplicate
  p->swap_map[?] /* !!! NULL pointer 
access */

Because swapoff is usually done when system shutdown only, the race may
not hit many people in practice.  But it is still a race need to be fixed.

To fix the race, get_swap_device() is added to check whether the specified
swap entry is valid in its swap device.  If so, it will keep the swap
entry valid via preventing the swap device from being swapoff, until
put_swap_device() is called.

Because swapoff() is very rare code path, to make the normal path runs as
fast as possible, disabling preemption + stop_machine() instead of
reference count is used to implement get/put_swap_device().  From
get_swap_device() to put_swap_device(), the preemption is disabled, so
stop_machine() in swapoff() will wait until put_swap_device() is called.

In addition to swap_map, cluster_info, etc.  data structure in the struct
swap_info_struct, the swap cache radix tree will be freed after swapoff,
so this patch fixes the race between swap cache looking up and swapoff
too.

Races between some other swap cache usages protected via disabling
preemption and swapoff are fixed too via calling stop_machine() between
clearing PageSwapCache() and freeing swap cache data structure.

Alternative implementation could be replacing disable preemption with
rcu_read_lock_sched and stop_machine() with synchronize_sched().

Signed-off-by: "Huang, Ying" 
Not-Nacked-by: Hugh Dickins 
Cc: Paul E. McKenney 
Cc: Minchan Kim 
Cc: Johannes Weiner 
Cc: Tim Chen 
Cc: Mel Gorman 
Cc: Jérôme Glisse 
Cc: Michal Hocko 
Cc: Andrea Arcangeli 
Cc: David Rientjes 
Cc: Rik van Riel 
Cc: Jan Kara 
Cc: Dave Jiang 
Cc: Daniel Jordan 
Cc: Andrea Parri 

Changelog:

v7:

- Rebased on patch: "mm, swap: bounds check swap_info accesses to avoid NULL 
derefs"

v6:

- Add more comments to get_swap_device() to make it more clear about
  possible swapoff or swapoff+swapon.

v5:

- Replace RCU with stop_machine()

v4:

- Use synchronize_rcu() in enable_swap_info() to reduce overhead of
  normal paths further.

v3:

- Re-implemented with RCU to reduce the overhead of normal paths

v2:

- Re-implemented with SRCU to reduce the overhead of normal paths.

- Avoid to check whether the swap device has been swapoff in
  get_swap_device().  Because we can check the origin of the swap
  entry to make sure the swap device hasn't bee swapoff.
---
 include/linux/swap.h |  13 +++-
 mm/memory.c  |   2 +-
 mm/swap_state.c  |  16 -
 mm/swapfile.c| 150 ++-
 4 files changed, 145 insertions(+), 36 deletions(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index 649529be91f2..aecd1430d0a9 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -175,8 +175,9 @@ enum {
SWP_PAGE_DISCARD = (1 << 10),   /* freed swap page-cluster discards */
SWP_STABLE_WRITES = (1 << 11),  /* no overwrite PG_writeback pages */
SWP_SYNCHRONOUS_IO = (1 << 12), /* synchronous IO is efficient */
+   SWP_VALID   = (1 << 13),/* swap is valid to be operated on? */
/* add others here before... */
-   SWP_SCANNING= (1 << 13),/* refcount in scan_swap_map */
+   SWP_SCANNING= (1 << 14),/* refcount in scan_swap_map */
 };
 
 #define SWAP_CLUSTER_MAX 32UL
@@ -460,7 +461,7 @@ extern unsigned int count_swap_pages(int, int);
 extern sector_t map_swap_page(struct page *, struct block_device **);
 extern sector_t swapdev_block(int, pgoff_t);
 extern int page_swapcount(struct page *);
-extern int __swap_count(struct swap_info_struct *si, swp_entry_t entry);
+extern int __swap_count(swp_entry_t entry);
 extern int __swp_swapcount(swp_entry_t entry);
 extern int swp_swapcount(swp_entry_t entry);
 extern struct swap_info_struct *page_swap_info(struct page *);
@@ -470,6 +471,12 @@ extern int try_to_free_swap(struct page *);
 struct backing_dev_info;
 extern int init_swap_address_space(unsigned int type, unsigned long nr_pages);
 extern void exit_swap_address_space(unsigned int type);
+extern struct swap_info_struct *get_swap_device(swp_entry_t entry);
+
+static inline void put_swap_device(struct swap_info_struct *si)
+{
+   preempt_enable();
+}
 
 #else /* CONFIG_SWAP */
 
@@ -576,7 +583,7 @@ static inline int page_swapcount(struct page *page)
return 0;
 }
 
-static inline i

Re: [PATCH] mt76: change the retun type of mt76_dma_attach()

[Sergei Shtylyov]

Hello!

On 11.02.2019 5:13, Ryder Lee wrote:


There is no need to retun 0 in mt76_dma_attach(), so switch it to void.

  ^ r missing :-)


Signed-off-by: Ryder Lee 

[...]

MBR, Sergei

Re: [PATCH v2 7/9] usb: typec: Find the ports by also matching against the device node

[Heikki Krogerus]

Hi Andy,

On Thu, Jan 31, 2019 at 03:35:37PM +0200, Heikki Krogerus wrote:
> On Wed, Jan 30, 2019 at 06:51:56PM +0200, Andy Shevchenko wrote:
> > On Wed, Jan 30, 2019 at 6:03 PM Heikki Krogerus
> >  wrote:
> > >
> > > When the connections are defined in firmware, struct
> > > device_connection will have the fwnode member pointing to
> > > the device node (struct fwnode_handle) of the requested
> > > device, and the endpoint will not be used at all in that
> > > case.
> > 
> > > +   /*
> > > +* FIXME: Check does the fwnode supports the requested SVID. If 
> > > it does
> > > +* we need to return ERR_PTR(-PROBE_DEFER) when there is no 
> > > device.
> > > +*/
> > > +   if (con->fwnode)
> > > +   return class_find_device(typec_class, NULL, con->fwnode,
> > > +typec_port_fwnode_match);
> > > +
> > > +   dev = class_find_device(typec_class, NULL, con->endpoint[ep],
> > > +   typec_port_name_match);
> > > +
> > > +   return dev ? dev : ERR_PTR(-EPROBE_DEFER);
> > 
> > Just  to be clear, this one takes a reference on dev. Is it taken into 
> > account?
> 
> Yes. That is what we want it to do.

Gentle ping. Is the series OK?

thanks,

-- 
heikki

[PATCH 0/2] cpufreq: Allow light-weight tear down on CPU offline

[Viresh Kumar]

The cpufreq core doesn't remove the cpufreq policy anymore on CPU
offline operation, rather that happens when the CPU device gets
unregistered from the kernel. This allows faster recovery when the CPU
comes back online. This is also very useful during system wide
suspend/resume where we offline all non-boot CPUs during suspend and
then bring them back on resume.

This patcset takes the same idea a step ahead to allow drivers to do
light weight tear-down during CPU offline operation and updates the
cpufreq-dt driver to implement the new helper.

Viresh Kumar (2):
  cpufreq: Allow light-weight tear down on CPU offline operation
  cpufreq: dt: Implement light_weight_exit() callback

 drivers/cpufreq/cpufreq-dt.c | 19 +++
 drivers/cpufreq/cpufreq.c| 16 +++-
 include/linux/cpufreq.h  |  1 +
 3 files changed, 31 insertions(+), 5 deletions(-)

-- 
2.20.1.321.g9e740568ce00

[PATCH 2/2] cpufreq: dt: Implement light_weight_exit() callback

[Viresh Kumar]

Implement the light-weight tear down helper to reduce the amount of work
to do on CPU offline/online operation.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq-dt.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 7ba392911cd0..69309a8121f0 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -160,6 +160,15 @@ static int cpufreq_init(struct cpufreq_policy *policy)
const char *name;
int ret;
 
+   /*
+* We did light-weight shutdown earlier, nothing else to initialize here
+* apart from policy->cpus.
+*/
+   if (policy->driver_data) {
+   cpumask_copy(policy->cpus, policy->related_cpus);
+   return 0;
+   }
+
cpu_dev = get_cpu_device(policy->cpu);
if (!cpu_dev) {
pr_err("failed to get cpu%d device\n", policy->cpu);
@@ -295,6 +304,15 @@ static int cpufreq_init(struct cpufreq_policy *policy)
return ret;
 }
 
+static int cpufreq_light_weight_exit(struct cpufreq_policy *policy)
+{
+   /*
+* Preserve policy->driver_data and don't free resources on light-weight
+* tear down.
+*/
+   return 0;
+}
+
 static int cpufreq_exit(struct cpufreq_policy *policy)
 {
struct private_data *priv = policy->driver_data;
@@ -319,6 +337,7 @@ static struct cpufreq_driver dt_cpufreq_driver = {
.get = cpufreq_generic_get,
.init = cpufreq_init,
.exit = cpufreq_exit,
+   .light_weight_exit = cpufreq_light_weight_exit,
.name = "cpufreq-dt",
.attr = cpufreq_dt_attr,
.suspend = cpufreq_generic_suspend,
-- 
2.20.1.321.g9e740568ce00

[PATCH 1/2] cpufreq: Allow light-weight tear down on CPU offline operation

[Viresh Kumar]

The cpufreq core doesn't remove the cpufreq policy anymore on CPU
offline operation, rather that happens when the CPU device gets
unregistered from the kernel. This allows faster recovery when the CPU
comes back online. This is also very useful during system wide
suspend/resume where we offline all non-boot CPUs during suspend and
then bring them back on resume.

This commit takes the same idea a step ahead to allow drivers to do
light weight tear-down during CPU offline operation.

A new callback is introduced, light_weight_exit(), which gets called
when all the CPUs of a policy are removed/offlined and the existing
exit() callback gets called when the policy gets freed.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 16 +++-
 include/linux/cpufreq.h   |  1 +
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 96a69c67a545..215a8bfc78bb 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1421,11 +1421,12 @@ static int cpufreq_offline(unsigned int cpu)
cpufreq_exit_governor(policy);
 
/*
-* Perform the ->exit() even during light-weight tear-down,
-* since this is a core component, and is essential for the
-* subsequent light-weight ->init() to succeed.
+* Perform the ->light_weight_exit() during light-weight tear-down, as
+* that allows fast recovery when the CPU comes back.
 */
-   if (cpufreq_driver->exit) {
+   if (cpufreq_driver->light_weight_exit) {
+   cpufreq_driver->light_weight_exit(policy);
+   } else if (cpufreq_driver->exit) {
cpufreq_driver->exit(policy);
policy->freq_table = NULL;
}
@@ -1454,8 +1455,13 @@ static void cpufreq_remove_dev(struct device *dev, 
struct subsys_interface *sif)
cpumask_clear_cpu(cpu, policy->real_cpus);
remove_cpu_dev_symlink(policy, dev);
 
-   if (cpumask_empty(policy->real_cpus))
+   if (cpumask_empty(policy->real_cpus)) {
+   /* We did light-weight exit earlier, do full tear down now */
+   if (cpufreq_driver->light_weight_exit)
+   cpufreq_driver->exit(policy);
+
cpufreq_policy_free(policy);
+   }
 }
 
 /**
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 9db074ecbbd7..36ce31516041 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -325,6 +325,7 @@ struct cpufreq_driver {
/* optional */
int (*bios_limit)(int cpu, unsigned int *limit);
 
+   int (*light_weight_exit)(struct cpufreq_policy *policy);
int (*exit)(struct cpufreq_policy *policy);
void(*stop_cpu)(struct cpufreq_policy *policy);
int (*suspend)(struct cpufreq_policy *policy);
-- 
2.20.1.321.g9e740568ce00

Re: [PATCH 0/2] udf: Fix corrupt on-disk integrity descriptor following sync()

[Jan Kara]

On Fri 08-02-19 22:06:59, Steve Magnani wrote:
> On 2/8/19 11:34 AM, Steve Magnani wrote:
> > In cases where the next unique ID or file/directory count of the
> > in-core Logical Volume Integrity Descriptor have been updated,
> > a sync() causes a (corrupt) LVID with a stale CRC to be written to disk.
> > 
> > Ordinarily, this is corrected by an update of the on-disk LVID that occurs
> > when the filesystem is unmounted. However, if power is lost or the
> > filesystem resides on a device that is surprise-removed, the corrupt LVID
> > remains and can complicate later remounting or fsck/chkdsk.

Thanks for the patches! I've added them to my tree. Just they seem to be
based on some relatively old kernel which required me to fixup some patch
conflicts. Please try to base your patches on current upstream kernel if
possible. Thanks!

> "Complicate later remounting" turns out to be an understatement.
> Actually it seems that this one event can trigger more silent corruption
> of the filesystem on future remounts.
> 
> The driver will mount without complaint a filesystem that lacks a valid LVID.
> But in this scenario, every time lvid_get_unique_id() is called to generate
> an ID for a new inode or link, it returns zero. It appears that callers
> happily assign this zero to all new inodes or links, with no indication to
> the user or in the syslog that a problem is brewing.
> 
> I lost the entire contents of a flash disk to what was probably an
> instance of this kind of corruption, when I told Windows chkdsk to
> repair it.

Ah, I'm sorry to hear that.

> I'll try to solve that in a separate followon patchset.
> The simplest solution I can think of is to force read-only mount when
> no LVID is available.

Agreed. OSTA UDF standard requires LVID to be present so forcing read-only
mount is perfectly fine.

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH 0/2] cpufreq/opp: rework regulator initialization

[Viresh Kumar]

On 07-02-19, 13:22, Marek Szyprowski wrote:
> Dear All,
> 
> Recent commit 9ac6cb5fbb17 ("i2c: add suspended flag and accessors for
> i2c adapters") added a visible warning for an attempt to do i2c transfer
> over a suspended i2c bus. This revealed a long standing issue in the
> cpufreq-dt driver, which gives a following warning during system
> suspend/resume cycle:

Marek,

I have sent a patchset which is not directly related to the problem
you are facing, but it may solve your problem as a side effect. Can
you please see if that works to solve this issue as well ?

https://lore.kernel.org/lkml/cover.1549874368.git.viresh.ku...@linaro.org/T/#u

Thanks.

-- 
viresh

Re: [PATCH v2] module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity

[Jessica Yu]

+++ Thomas Gleixner [08/02/19 17:02 +0100]:

The original MODULE_LICENSE string for kernel modules licensed under the
GPL v2 (only / or later) was simply "GPL", which was - and still is -
completely sufficient for the purpose of module loading and checking
whether the module is free software or proprietary.

In January 2003 this was changed with commit 3344ea3ad4b7 ("[PATCH]
MODULE_LICENSE and EXPORT_SYMBOL_GPL support"). This commit can be found in
the history git repository which holds the 1:1 import of Linus' bitkeeper
repository:

 
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=3344ea3ad4b7c302c846a680dbaeedf96ed45c02

The main intention of the patch was to refuse linking proprietary modules
against symbols exported with EXPORT_SYMBOL_GPL() at module load time.

As a completely undocumented side effect it also introduced the distinction
between "GPL" and "GPL v2" MODULE_LICENSE() strings:

*  "GPL"   [GNU Public License v2 or later]
*  "GPL v2"[GNU Public License v2]
*  "GPL and additional rights" [GNU Public License v2 rights and more]
*  "Dual BSD/GPL"  [GNU Public License v2
*   or BSD license choice]
*  "Dual MPL/GPL"  [GNU Public License v2
*   or Mozilla license choice]

This distinction was and still is wrong in several aspects:

1) It broke all modules which were using the "GPL" string in the
   MODULE_LICENSE() already and were licensed under GPL v2 only.

   A quick license scan over the tree at that time shows that at least 480
   out of 1484 modules have been affected by this change back then. The
   number is probably way higher as this was just a quick check for
   clearly identifiable license information.

   There was exactly ONE instance of a "GPL v2" module license string in
   the kernel back then - drivers/net/tulip/xircom_tulip_cb.c which
   otherwise had no license information at all. There is no indication
   that the change above is any way related to this driver. The change
   happend with the 2.4.11 release which was on Oct. 9 2001 - so quite
   some time before the above commit. Unfortunately there is no trace on
   the intertubes to any discussion of this.

2) The dual licensed strings became ill defined as well because following
   the "GPL" vs. "GPL v2" distinction all dual licensed (or additional
   rights) MODULE_LICENSE strings would either require those dual licensed
   modules to be licensed under GPL v2 or later or just be unspecified for
   the dual licensing case. Neither choice is coherent with the GPL
   distinction.

Due to the lack of a proper changelog and no real discussion on the patch
submission other than a few implementation details, it's completely unclear
why this distinction was introduced at all. Other than the comment in the
module header file exists no documentation for this at all.

From a license compliance and license scanning POV this distinction is a
total nightmare.

As of 5.0-rc2 2873 out of 9200 instances of MODULE_LICENSE() strings are
conflicting with the actual license in the source code (either SPDX or
license boilerplate/reference). A comparison between the scan of the
history tree and a scan of current Linus tree shows to the extent that the
git rename detection over Linus tree grafted with the history tree is
halfways complete that almost none of the files which got broken in 2003
have been cleaned up vs. the MODULE_LICENSE string. So subtracting those
480 known instances from the conflicting 2800 of today more than 25% of the
module authors got it wrong and it's a high propability that a large
portion of the rest just got it right by chance.

There is no value for the module loader to convey the detailed license
information as the only decision to be made is whether the module is free
software or not.

The "and additional rights", "BSD" and "MPL" strings are not conclusive
license information either. So there is no point in trying to make the GPL
part conclusive and exact. As shown above it's already non conclusive for
dual licensing and incoherent with a large portion of the module source.

As an unintended side effect this distinction causes a major headache for
license compliance, license scanners and the ongoing effort to clean up the
license mess of the kernel.

Therefore remove the well meant, but ill defined, distinction between "GPL"
and "GPL v2" and document that:

 - "GPL" and "GPL v2" both express that the module is licensed under GPLv2
   (without a distinction of 'only' and 'or later') and is therefore kernel
   license compliant.

 - None of the MODULE_LICENSE strings can be used for expressing or
   determining the exact license

 - Their sole purpose is to decide whether the module is free software or
   not.

Add a MODULE_LICENSE subsection to the license rule documentation as well.

Signed-off-by: Thomas Gleixner

Re: [PATCH 1/2] selftests/x86/fsgsbase: Indirect output through a wrapper function

[Ingo Molnar]

* Mark Brown  wrote:

> In preparation for a change to make this test run repeatedly which
> would generate huge amounts of output as is indirect all the printf()
> calls in the program through a wrapper and add a quiet flag which can
> be used to suppress the output.  This is fairly quick and dirty, I'm not
> 100% sure what would be idiomatic here.
> 
> Signed-off-by: Mark Brown 
> ---
>  tools/testing/selftests/x86/fsgsbase.c | 52 --
>  1 file changed, 32 insertions(+), 20 deletions(-)

So this really loses useful output when there is a failure. After this 
patch I get:

  dagon:~/tip/tools/testing/selftests/x86> ./fsgsbase_64 -vv
  [FAIL] 24 errors detected in 1 tries

Not very helpful, and no real command-line way to see the failures.

While previously it would tell me what's going on:

 dagon:~/tip/tools/testing/selftests/x86> ./fsgsbase_64  | grep FAIL
 [FAIL] GS/BASE changed from 0x1/0x1 to 0x1/0x0
 [FAIL] GS/BASE changed from 0x2/0x1 to 0x2/0x0
 [FAIL] GS/BASE changed from 0x3/0x1 to 0x3/0x0
 [FAIL] GS/BASE changed from 0x1/0x1 to 0x1/0x0
 [FAIL] GS/BASE changed from 0x2/0x1 to 0x2/0x0
 [FAIL] GS/BASE changed from 0x3/0x1 to 0x3/0x0
 [FAIL] GS/BASE changed from 0x1/0x1 to 0x1/0x0
 [FAIL] GS/BASE changed from 0x2/0x1 to 0x2/0x0
 [FAIL] GS/BASE changed from 0x3/0x1 to 0x3/0x0
 [FAIL] GS/BASE changed from 0x1/0x1 to 0x1/0x0
 [FAIL] GS/BASE changed from 0x2/0x1 to 0x2/0x0
 [FAIL] GS/BASE changed from 0x3/0x1 to 0x3/0x0
 [FAIL] GS/BASE changed from 0x1/0x2 to 0x1/0x0
 [FAIL] GS/BASE changed from 0x2/0x2 to 0x2/0x0
 [FAIL] GS/BASE changed from 0x3/0x2 to 0x3/0x0
 [FAIL] GS/BASE changed from 0x1/0x2 to 0x1/0x0
 [FAIL] GS/BASE changed from 0x2/0x2 to 0x2/0x0
 [FAIL] GS/BASE changed from 0x3/0x2 to 0x3/0x0
 [FAIL] GS/BASE changed from 0x1/0x2 to 0x1/0x0
 [FAIL] GS/BASE changed from 0x2/0x2 to 0x2/0x0
 [FAIL] GS/BASE changed from 0x3/0x2 to 0x3/0x0
 [FAIL] GS/BASE changed from 0x1/0x2 to 0x1/0x0
 [FAIL] GS/BASE changed from 0x2/0x2 to 0x2/0x0
 [FAIL] GS/BASE changed from 0x3/0x2 to 0x3/0x0

So I believe at least failure messages need to be preserved.

Thanks,

Ingo

Re: [PATCH v2 14/28] thunderbolt: Extend tunnel creation to more than 2 adjacent switches

[Mika Westerberg]

On Sun, Feb 10, 2019 at 04:33:28PM +0100, Lukas Wunner wrote:
> On Wed, Feb 06, 2019 at 04:17:24PM +0300, Mika Westerberg wrote:
> > Now that we can allocate hop IDs per port on a path, we can take
> > advantage of this and create tunnels covering longer paths than just
> > between two adjacent switches. PCIe actually does not need this as it is
> > always a daisy chain between two adjacent switches but this way we do
> > not need to hard-code creation of the tunnel.
> 
> That doesn't seem to be correct, at the bottom of this page there's
> a figure showing a PCI tunnel between non-adjacent switches (blue line):
> 
> https://developer.apple.com/library/archive/documentation/HardwareDrivers/Conceptual/ThunderboltDevGuide/Basics/Basics.html
> 
> I'm not sure if there are advantages to such tunnels:  Reduced latency
> perhaps because packets need not pass through PCIe adapters on the
> in-between device?  Or maybe this allows for more fine-grained traffic
> prioritization?

Interesting.

Are you sure Apple actually uses setup like that? I think I have never
seen such configuration happening on any of the devices I have.

I can update the changelog to mention that if you think it is useful.
Something like below maybe?

 PCIe actually does not need this as it is typically a daisy chain
 between two adjacent switches but this way we do not need to hard-code
 creation of the tunnel.

> > +   i = 0;
> > +   tb_for_each_port(in_port, src, dst)
> > +   i++;
> 
> This looks more complicated than necessary.  Isn't the path length
> always the length of the route string from in_port switch to out_port
> switch, plus 2 for the adapter on each end?  Or do paths without
> adapters exist?

Yes, I think you are right.

> > +   for (i = 0; i < num_hops; i++) {
> > +   in_port = tb_port_get_next(src, dst, out_port);
> > +
> > +   if (in_port->dual_link_port && in_port->link_nr != link_nr)
> > +   in_port = in_port->dual_link_port;
> > +
> > +   ret = tb_port_alloc_in_hopid(in_port, in_hopid, -1);
> > +   if (ret < 0)
> > +   goto err;
> > +   in_hopid = ret;
> > +
> > +   out_port = tb_port_get_next(src, dst, in_port);
> > +   if (!out_port)
> > +   goto err;
> 
> There's a NULL pointer check here, but the invocation of tb_port_get_next()
> further up to assign in_port lacks such a check.  Is it guaranteed to never
> be NULL?

No, I'll add NULL check there.

Re: [PATCH 0/2] Subject: [PATCH 0/2] clocksource: exynos_mct: Clear timer interrupt when shutting down

[Krzysztof Kozlowski]

On Sun, 10 Feb 2019 at 23:51, Stuart Menefy
 wrote:
>
> When debugging suspend problems on Exynos 5260, I had a large number
> of debugging prints going to the serial port after interrupts
> had been disabled but before the timer interrupt was shutdown. This
> was long enough for a timer tick to occur, but as interrupts were
> disabled the ISR didn't run, and so the interrupt wasn't cleared.
> Later when the timer was shutdown the interrupt was left asserted and
> so the wfi at the heart of the suspend code didn't wait, causing
> the suspend to fail.
>
> Currently the code which stops the timer when it is on one-shot mode
> and the interrupt occurs is in exynos4_mct_tick_clear(), meaning if we
> called this from the shutdown code exynos4_mct_tick_stop() could be
> called twice. So first restructure the existing code, so the check for
> one-shot mode and stopping the timer is moved to the ISR, leaving
> exynos4_mct_tick_clear() just clearing the interrupt flag.
>
> Once this has been done simply call exynos4_mct_tick_clear() from
> set_state_shutdown().

For sending the corrected version. This is second revision of the
patchset so please remember to add v2 to the title and changelog in
cover letter. v2 can be easily added with format-patch (-v2).

Best regards,
Krzysztof

Re: [PATCH] regulator: stpmic1: Remove regul_id and *regmap from struct stpmic1_regulator

[Pascal PAILLET-LME]

Hello Axel,

Le 02/09/2019 05:39 AM, Axel Lin a écrit :
> At the context with *rdev available, there is no problem to get regulator
> id and *regmap, so no need to store them in struct stpmic1_regulator.
>
> Signed-off-by: Axel Lin 
> ---
>   drivers/regulator/stpmic1_regulator.c | 10 ++
>   1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/regulator/stpmic1_regulator.c 
> b/drivers/regulator/stpmic1_regulator.c
> index 963e67fa9ca6..dd5c8fb1ff86 100644
> --- a/drivers/regulator/stpmic1_regulator.c
> +++ b/drivers/regulator/stpmic1_regulator.c
> @@ -30,20 +30,16 @@ struct stpmic1_regulator_cfg {
>   
>   /**
>* stpmic1 regulator data: this structure is used as driver data
> - * @regul_id: regulator id
>* @reg_node: DT node of regulator (unused on non-DT platforms)
>* @cfg: stpmic specific regulator description
>* @mask_reset: mask_reset bit value
>* @irq_curlim: current limit interrupt number
> - * @regmap: point to parent regmap structure
>*/
>   struct stpmic1_regulator {
> - unsigned int regul_id;
>   struct device_node *reg_node;
>   const struct stpmic1_regulator_cfg *cfg;
>   u8 mask_reset;
>   int irq_curlim;
> - struct regmap *regmap;
>   };
>   
>   static int stpmic1_set_mode(struct regulator_dev *rdev, unsigned int mode);
> @@ -477,7 +473,7 @@ static int stpmic1_set_icc(struct regulator_dev *rdev)
>   struct stpmic1_regulator *regul = rdev_get_drvdata(rdev);
>   
>   /* enable switch off in case of over current */
> - return regmap_update_bits(regul->regmap, regul->cfg->icc_reg,
> + return regmap_update_bits(rdev->regmap, regul->cfg->icc_reg,
> regul->cfg->icc_mask, regul->cfg->icc_mask);
Maybe this is not compatible with a recommandation from
include/linux/regulator/driver.h:438:
  * This should *not* be used directly by anything except the regulator
  * core and notification injection (which should take the mutex and do
  * no other direct access).

>   }
>
...


thank you,
pascal

Re: [PATCH 0/2] cpufreq/opp: rework regulator initialization

[Viresh Kumar]

On 08-02-19, 17:41, Sudeep Holla wrote:
> Based on Rafael's suggestion, I cooked up something. See if this helps ?
> The policy to cpu dance can be removed and we can just run through the
> online cpumask I think.
> 
> Regards,
> Sudeep
> 
> -->8
> 
> diff --git i/drivers/cpufreq/cpufreq.c w/drivers/cpufreq/cpufreq.c
> index e35a886e00bc..03d65a02a542 100644
> --- i/drivers/cpufreq/cpufreq.c
> +++ w/drivers/cpufreq/cpufreq.c
> @@ -1640,6 +1640,7 @@ EXPORT_SYMBOL(cpufreq_generic_suspend);
>  void cpufreq_suspend(void)
>  {
>   struct cpufreq_policy *policy;
> + int cpu;
>  
>   if (!cpufreq_driver)
>   return;
> @@ -1662,6 +1663,11 @@ void cpufreq_suspend(void)
>   }
>  
>  suspend:
> + if (cpufreq_driver->flags & CPUFREQ_DEFER_INIT_DURING_RESUME)
> + for_each_active_policy(policy)
> + for_each_cpu(cpu, policy->cpus)
> + cpufreq_offline(cpu);

You will offline boot-cpu as well :)

> +
>   cpufreq_suspended = true;
>  }
>  
> @@ -1674,7 +1680,7 @@ void cpufreq_suspend(void)
>  void cpufreq_resume(void)
>  {
>   struct cpufreq_policy *policy;
> - int ret;
> + int ret, cpu;
>  
>   if (!cpufreq_driver)
>   return;
> @@ -1682,6 +1688,11 @@ void cpufreq_resume(void)
>   if (unlikely(!cpufreq_suspended))
>   return;
>  
> + if (cpufreq_driver->flags & CPUFREQ_DEFER_INIT_DURING_RESUME)
> + for_each_active_policy(policy)
> + for_each_cpu(cpu, policy->cpus)
> + cpufreq_online(cpu);
> +
>   cpufreq_suspended = false;
>  
>   if (!has_target() && !cpufreq_driver->resume)
> @@ -2444,14 +2455,16 @@ static enum cpuhp_state hp_online;
>  
>  static int cpuhp_cpufreq_online(unsigned int cpu)
>  {
> - cpufreq_online(cpu);
> + if (!(cpufreq_driver->flags & CPUFREQ_DEFER_INIT_DURING_RESUME))
> + cpufreq_online(cpu);

This isn't correct as we can offline the CPUs without suspend as well
and cpufreq_online/offline should always be called in such cases.

Anyways, I have cc'd you on another series which may end up fixing
this problem as well.

-- 
viresh

Re: [PATCH 2/2] clocksource: exynos_mct: Clear timer interrupt when shutdown

[Krzysztof Kozlowski]

On Sun, 10 Feb 2019 at 23:51, Stuart Menefy
 wrote:
>
> When shutting down the timer, ensure that after we have stopped the
> timer any pending interrupts are cleared. This fixes a problem when
> suspending, as interrupts are disabled before the timer is stopped,
> so the timer interrupt may still be asserted, preventing the system
> entering a low power state when the wfi is executed.
>
> Signed-off-by: Stuart Menefy 
> ---
>  drivers/clocksource/exynos_mct.c | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH 1/2] clocksource: exynos_mct: Move one-shot check from tick clear to ISR

[Krzysztof Kozlowski]

On Sun, 10 Feb 2019 at 23:51, Stuart Menefy
 wrote:
>
> When a timer tick occurs and the clock is in one-shot mode, the timer
> needs to be stopped to prevent it triggering subsequent interrupts.
> Currently this code is in exynos4_mct_tick_clear(), but as it is
> only needed when an ISR occurs move it into exynos4_mct_tick_isr(),
> leaving exynos4_mct_tick_clear() just doing what its name suggests it
> should.
>
> Signed-off-by: Stuart Menefy 
> ---
>  drivers/clocksource/exynos_mct.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH] mt76: change the retun type of mt76_dma_attach()

[Ryder Lee]

On Mon, 2019-02-11 at 11:38 +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 11.02.2019 5:13, Ryder Lee wrote:
> 
> > There is no need to retun 0 in mt76_dma_attach(), so switch it to void.
>^ r missing :-)
> > 
> > Signed-off-by: Ryder Lee 
> [...]
> 
> MBR, Sergei
> 

I will resend a new one.

Thanks
Ryder

Re: [PATCH 2/2] selftests/x86/fsgsbase: Default to trying to run the test repeatedly

[Ingo Molnar]

* Mark Brown  wrote:

> In automated testing it has been found that on many systems the fsgsbase
> test fails intermittently.  This was reported and discussed a while
> back:
> 
> https://lore.kernel.org/lkml/20180126153631.ha7yc33fj5uhitjo@xps/
> 
> with the analysis concluding that this is a hardware issue affecting a
> subset of systems but no fix has been merged as yet.  As well as the
> actual problem found by testing the intermittent test failure is causing
> issues for the people doing the automated testing due to the noise.
> 
> In order to make the testing stable modify the test program to iterate
> through the test repeatedly, choosing 5000 iterations based on prior
> reports and local testing.  This unfortunately greatly increases the
> execution time for the selftests when things succeed which isn't great,
> in my local tests on a range of systems it pushes the execution time up
> to approximately a minute when no failures are encountered.
> 
> Reported-by: Dan Rue 
> Signed-off-by: Mark Brown 
> ---
>  tools/testing/selftests/x86/fsgsbase.c | 27 +-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/x86/fsgsbase.c 
> b/tools/testing/selftests/x86/fsgsbase.c
> index 6cda6daa1f8c..83410749ff1f 100644
> --- a/tools/testing/selftests/x86/fsgsbase.c
> +++ b/tools/testing/selftests/x86/fsgsbase.c
> @@ -379,7 +379,7 @@ static void test_unexpected_base(void)
>   }
>  }
>  
> -int main()
> +int test()
>  {
>   pthread_t thread;
>  
> @@ -437,3 +437,28 @@ int main()
>  
>   return nerrs == 0 ? 0 : 1;
>  }
> +
> +int main()
> +{
> + int tries = 5000;
> + int i;
> +
> + if (tries > 1)
> + quiet = true;
> +
> + for (i = 0; i < tries; i++) {
> + if (test() != 0)
> + break;
> + }
> +
> + if (quiet) {
> + if (nerrs) {
> + printf("[FAIL] %d errors detected in %d tries\n",
> + nerrs, i + 1);
> + } else {
> + printf("[PASS] %d runs succeeded\n", i);
> + }
> + }
> +
> + return nerrs == 0 ? 0 : 1;
> +}

So this isn't very user-friendly either, previously it would run a 
testcase and immediately provide output.

Now it's just starting and 'hanging':

  galatea:~/linux/linux/tools/testing/selftests/x86> ./fsgsbase_64 

I got bored and Ctrl-C-ed it after ~30 seconds.

How long is this supposed to run, and why isn't the user informed?

Also, testcases should really be short, so I think a better approach 
would be to thread the test-case and start an instance on every CPU. That 
should also excercise SMP bugs, if any.

Thanks,

Ingo

Re: [PATCH RESEND] initramfs: cleanup incomplete rootfs

[David Engraf]

On 11.02.19 at 08:56, David Engraf wrote:

On 09.02.19 at 11:35, Andy Shevchenko wrote:
On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton 
 wrote:
On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko 
 wrote:
On Tue, Oct 30, 2018 at 5:22 PM David Engraf 
 wrote:


Unpacking an external initrd may fail e.g. not enough memory. This 
leads

to an incomplete rootfs because some files might be extracted already.
Fixed by cleaning the rootfs so the kernel is not using an incomplete
rootfs.


This breaks my setup where I have U-boot provided more size of
initramfs than needed. This allows a bit of flexibility to increase or
decrease initramfs compressed image without taking care of bootloader.
The proper solution is to do this if we sure that we didn't get enough
memory, otherwise I can't consider the error fatal to clean up rootfs.


OK, thanks.  Maybe David can suggest a fix - I'll queue up a revert
meanwhile.

I don't really understand the failure.  Why does an oversized initramfs
cause unpack_to_rootfs() to fail?


In my case I have got "Junk in compressed archive". I don't know (I
would check if needed) which exact condition I got  since there are
three places with this message. The file itself smaller than the size
passed through bootparam. So, when decomression is finished
(successfully!) we still have a garbarge in the memory which is not
related to archive. Message per se is okay to have, though I consider
this non-fatal.


I can reproduce this special case. The unpacking decompresses the whole 
size instead of checking the archive size. I will have a look how to get 
the real archive size.


I did some checks and manually increased the initramfs size but I always 
get the following kernel panic:


Kernel panic - not syncing: junk in compressed archive
---[ end Kernel panic - not syncing: junk in compressed archive

The panic was not introduced by my patch. Could you please check if you 
get a panic as well or is your rootfs just empty?


I also had a look at the decompression in unpack_to_rootfs(). This 
function already ensures unpacking only the real size of the archive. 
But it is called in a loop, thus it unpacks the first archive and then 
tries to unpack the reset of the data which are garbage in my case.
Is it intended to allow extracting multiple archives as rootfs? If not 
we could remove the loop and unpack only the first archive. Otherwise we 
could ignore errors when the first archive was extracted without errors.


Best regards
- David

Re: [PATCH v6 1/6] irqchip/mtk-sysirq: support 4 interrupt parameters for sysirq

[Marc Zyngier]

On Mon, 11 Feb 2019 06:35:29 +,
Seiya Wang  wrote:
> 
> On Thu, 2019-02-07 at 15:52 +, Marc Zyngier wrote:
> > On 07/02/2019 15:47, Marc Zyngier wrote:
> > > On 07/02/2019 15:20, Matthias Brugger wrote:
> > >>
> > >>
> > >> On 24/01/2019 09:07, Erin Lo wrote:
> > >>> From: Seiya Wang 
> > >>>
> > >>> To support partitioned PPIs, 4 interrupt parameters should be valid
> > >>> for sysirq.
> > >>>
> > >>> Signed-off-by: Seiya Wang 
> > >>> Signed-off-by: Erin Lo 
> > >>> ---
> > >>>  drivers/irqchip/irq-mtk-sysirq.c | 4 ++--
> > >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> > >>>
> > >>> diff --git a/drivers/irqchip/irq-mtk-sysirq.c 
> > >>> b/drivers/irqchip/irq-mtk-sysirq.c
> > >>> index 90aaf19..282736a 100644
> > >>> --- a/drivers/irqchip/irq-mtk-sysirq.c
> > >>> +++ b/drivers/irqchip/irq-mtk-sysirq.c
> > >>> @@ -81,7 +81,7 @@ static int mtk_sysirq_domain_translate(struct 
> > >>> irq_domain *d,
> > >>>unsigned int *type)
> > >>>  {
> > >>> if (is_of_node(fwspec->fwnode)) {
> > >>> -   if (fwspec->param_count != 3)
> > >>> +   if (fwspec->param_count != 3 && fwspec->param_count != 
> > >>> 4)
> > >>
> > >> Where is this 4th parameter used?
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt#n14
> > Sorry, I fired Send way too early.
> > 
> > What I wanted to add is that it is not clear to me why this change would
> > be required here, as this driver only supports SPIs. It could be fixed
> > by just relaxing the binding itself.
> > 
> > Thanks,
> > 
> > M.
> 
> Do you mean that we should change #interrupt-cells back to 3 for sysirq
> and remove the 4th parameters of every spi interrupts in mt8183.dtsi
> (i.e. 3 parameters for spi, 4 for ppi) such that we can discard this
> patch?

It is more subtle than that:

- PPIs must have the affinity parameter in their int-spec (since you
  need that for the PMU)

- SPIs that are directly routed to the GIC must also have the affinity
  parameter (although set to zero).

- SPIs that are routed via the sysirq block (or any other) can use the
  3 parameter variant, as they are not resolved in the context of the
  GIC, but in that of the sysirq.

But in short, yes. You should be able to drop this patch altogether.

> If yes, we may need some time to verify the change before resending the
> patch.

That's absolutely fine.

Thanks,

M.

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

Re: [RESEND PATCH v2] mtd: spi-nor: Fix wrong abbreviation HWCPAS

[Tudor.Ambarus]

On 02/08/2019 08:34 PM, Bean Huo (beanhuo) wrote:
> From: Bean Huo 
> 
> Change SNOR_HWCPAS_READ_OCTAL to SNOR_HWCAPS_READ_OCTAL.
> 
> Signed-off-by: Bean Huo 

Reviewed-by: Tudor Ambarus 

> ---
>  include/linux/mtd/spi-nor.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index 
> 2353af8..b3d360b 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -487,7 +487,7 @@ struct spi_nor_hwcaps {
>  #define SNOR_HWCAPS_READ_4_4_4   BIT(9)
>  #define SNOR_HWCAPS_READ_1_4_4_DTR   BIT(10)
>  
> -#define SNOR_HWCPAS_READ_OCTAL   GENMASK(14, 11)
> +#define SNOR_HWCAPS_READ_OCTAL   GENMASK(14, 11)
>  #define SNOR_HWCAPS_READ_1_1_8   BIT(11)
>  #define SNOR_HWCAPS_READ_1_8_8   BIT(12)
>  #define SNOR_HWCAPS_READ_8_8_8   BIT(13)
> --
> 2.7.4
> 

Re: [PATCH v2 15/28] thunderbolt: Deactivate all paths before restarting them

[Mika Westerberg]

On Mon, Feb 11, 2019 at 07:35:55AM +0100, Lukas Wunner wrote:
> On Wed, Feb 06, 2019 at 04:17:25PM +0300, Mika Westerberg wrote:
> > We can't be sure the paths are actually properly deactivated when a
> > tunnel is restarted after resume.
> 
> Why can't we be sure?  Please provide proper reasoning.

IIRC the reason was that when you suspend, then reconfigure parts of the
topology and resume, establishing the tunnel again went wrong. I'll
update the changelog with a better reasoning.

> > So instead of marking all paths as
> > inactive we go ahead and deactivate them explicitly.
> 
> This seems like a bad idea if the root partition is on a Thunderbolt-
> attached drive, the system is waking from hibernate and the EFI NHI
> driver has already established a tunnel to that drive.  It would seem
> more appropriate to discover tunnels already existing on resume from
> system sleep and then attempt to establish any others that might be
> missing.

That's what we do in the patch following, no? We discover the EFI
created paths and use that information to re-establish tunnels upon S3
resume and also when they are torn down.

> > @@ -183,8 +183,15 @@ int tb_tunnel_restart(struct tb_tunnel *tunnel)
> >  
> > tb_tunnel_info(tunnel, "activating\n");
> >  
> > +   /* Make sure all paths are properly disabled before enable them again */
> 
> This isn't proper English, s/enable/enabling/.

Thanks, I'll fix it up.

Re: [PATCH] livepatch: Enforce reliable stack trace as config dependency

[Petr Mladek]

On Sat 2019-02-09 14:47:28, Kamalesh Babulal wrote:
> While the consistency model was introduced, architectures without the
> reliable stack trace implementation could use the immediate flag for
> livepatching but with its own limitations.
> 
> After removal of the immediate flag by commit d0807da78e11
> ("livepatch: Remove immediate feature"), reliable stack trace became
> enforcing dependency for livepatch support on any architecture. In
> the current code, we ensure that the dependency is met when
> enabling the patch during the module load.
> 
> This dependency check can be improved by moving it to the Kconfig,
> which disables the support for livepatching in the kernel for unmet
> dependencies. This patch moves both HAVE_RELIABLE_STACKTRACE and
> STACKTRACE under config LIVEPATCH, it also removes the
> klp_have_reliable_stack() function.
> 
> Loading a livepatching module on an architecture where reliable
> stack trace is yet to be implemented, the user should see:
> 
> insmod: ERROR: could not insert module ./livepatch-sample.ko: Invalid module 
> format
> 
> ...
> [  286.453463] livepatch_sample: module is marked as livepatch module, but 
> livepatch support is disabled
> 
> [pmla...@suse.com: Suggested to explicitly add CONFIG_STACKTRACE under
>  config LIVEPATCH]
> Signed-off-by: Kamalesh Babulal 

Acked-by: Petr Mladek 

Best Regards,
Petr

Re: [PATCH 1/2] mmc: cqhci: replace NUM_SLOTS with cq_host->num_slots

[Adrian Hunter]

On 8/02/19 8:41 PM, Alamy Liu wrote:
> The IP I'm using has fixed 32 slots for CQ once CQE is enabled in RTL.
> There is no other RO register to say the slot number & which slot that
> DCMD would use.
> 
> I agree that most host controller would have 32 slots for CQ, and use
> the last one for DCMD if enabled (easier design & save gates
> count/size). (15th for DCMD if there were 16 slots in CQ, ...etc). It
> also doesn't make sense to use a slot in the middle of slots for DCMD,
> Both the code (both S.W. & H.W.) would become more complicated.
> Although I don't see it is defined somewhere, I believe that every
> designer would follow.
> (H.W.: increasing gate count -> increasing die size -> increase $;
> complicated design -> higher chance to have bug/error).
> (H.W.: SDHC cq_depth: longer cq_depth -> more memory -> more $. The
> decision would be the trade off between $ & performance. Also, the
> SDHC is not necessary to be used in Cortex-A/Linux. Thus, 16/8
> cq_depth is possible, although I don't know if there is one existed
> out there)
> 
> Another thinking: If all cq_depth is fixed to 32, the mmc driver core
> doesn't even have to detect the cq_depth and eventually choose the
> small one between HC & eMMC (queue.c::mmc_init_queue)

The cqe_qdepth changes depending on whether DCMD is supported.  That is the
kind of detail that belongs to the CQHCI driver not the mmc core.  For
example, theoretically there could be more than one CQE driver
implementation, but it is also nicer to keep a separation between CQHCI and
mmc core.

> 
> Best Regards
> 
> 
> On Fri, Feb 8, 2019 at 2:34 AM Asutosh Das (asd)
>  wrote:
>>
>> On 2/8/2019 8:07 AM, Ritesh Harjani wrote:
>>> Hi Alamy,
>>>
>>> On 2/8/2019 1:00 AM, Alamy Liu wrote:
 It says in B.2.1 in the JESD84-B51.pdf (I don't have JESD84-B51A.pdf):

 /The TDL is located in a memory location known to the CQE, and is
 comprised of up to 32 fixed-size slots. Each slot is comprised of
 one Task Descriptor and one Transfer Descriptor./


 So if the IP has 16 slots, it should still meet the specification.
 Then the configuration could be moved to DTS, maybe:

 cqhci-slotnum = <16>;

 cqhci-dcmd-slotno = <15>;

>>> Does your IP defines this as 16 slots & DCMD slot to be 15?
>>> Because if there is a deviation then IP may also define num_slots by
>>> using some reserved registers.
>>> Also in JESD84-B51.pdf, specific slot no. is used extensively for
>>> defining policies(like in case of DCMD & CQCFG), so in that case
>>> defining via DT may not be that helpful.
>>> Unless there is no other way in your IP to determine the num_slots
>>> except going via DT?
>>>
>>> Let others also provide an opinion here.
>>>
>>> Regards
>>> Ritesh
>>>
>>>

 Please comment.

 Regards,
 Alamy



 On Thu, Jan 31, 2019 at 1:34 AM Adrian Hunter >>> > wrote:

 On 14/01/19 9:17 PM, Alamy Liu wrote:
 > Prevent to use fixed value (NUM_SLOTS) after it had been determined
 > and saved in a variable (cq_host->num_slots).

 num_slots is always 32 (i.e. NUM_SLOTS) so why not go the other
 way and get
 rid of num_slots and just use NUM_SLOTS?

 >
 > Signed-off-by: Alamy Liu >>> >
 > ---
 >  drivers/mmc/host/cqhci.c | 2 +-
 >  1 file changed, 1 insertion(+), 1 deletion(-)
 >
 > diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/host/cqhci.c
 > index 159270e947..26d63594b7 100644
 > --- a/drivers/mmc/host/cqhci.c
 > +++ b/drivers/mmc/host/cqhci.c
 > @@ -699,7 +699,7 @@ static void cqhci_error_irq(struct mmc_host
 *mmc, u32 status, int cmd_error,
 >* The only way to guarantee forward progress is
 to mark at
 >* least one task in error, so if none is
 indicated, pick one.
 >*/
 > - for (tag = 0; tag < NUM_SLOTS; tag++) {
 > + for (tag = 0; tag < cq_host->num_slots; tag++) {
 >   slot = &cq_host->slot[tag];
 >   if (!slot->mrq)
 >   continue;
 >

>> Is it worth exploring to tie up the TDL memory allocations with the
>> queue-depth? Because the queue-depth may vary with vendor; in most host
>> controllers the slot size is 32. And since memory allocations are done
>> on the basis of host slot size there's unused slots in the case of card
>> advertising less than 32 queue-depth.
>> The tricky part would be the DCMD handling though.
>>
>> In the IP in question, what slot is assigned to DCMD?
>>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
> 

Re: [PATCH] mm,memory_hotplug: Explicitly pass the head to isolate_huge_page

[David Hildenbrand]

On 08.02.19 10:06, Oscar Salvador wrote:
> isolate_huge_page() expects we pass the head of hugetlb page to it:
> 
> bool isolate_huge_page(...)
> {
>   ...
>   VM_BUG_ON_PAGE(!PageHead(page), page);
>   ...
> }
> 
> While I really cannot think of any situation where we end up with a
> non-head page between hands in do_migrate_range(), let us make sure
> the code is as sane as possible by explicitly passing the Head.
> Since we already got the pointer, it does not take us extra effort.
> 
> Signed-off-by: Oscar Salvador 
> ---
>  mm/memory_hotplug.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 656ff386ac15..d5f7afda67db 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1378,12 +1378,12 @@ do_migrate_range(unsigned long start_pfn, unsigned 
> long end_pfn)
>  
>   if (PageHuge(page)) {
>   struct page *head = compound_head(page);
> - pfn = page_to_pfn(head) + (1<   if (compound_order(head) > PFN_SECTION_SHIFT) {
>   ret = -EBUSY;
>   break;
>   }
> - isolate_huge_page(page, &source);
> + pfn = page_to_pfn(head) + (1< + isolate_huge_page(head, &source);
>   continue;
>   } else if (PageTransHuge(page))
>   pfn = page_to_pfn(compound_head(page))
> 

Reviewed-by: David Hildenbrand 

-- 

Thanks,

David / dhildenb

Re: [PATCH] fcoe: make use of fip_mode enum complete

[Sedat Dilek]

Hi Lukas,

I have tested your patch with LLVM/Clang from Git (will get version 9)
with (RFC) asm-goto support.

I was able to build with CONFIG_FCOE=m and CONFIG_LIBFCOE=m and boot
on bare metal.

Feel free to add my...

 Tested-by: Sedat Dilek 

If you want to send out a v2 please feel free to add the following Link.

 Link: https://github.com/ClangBuiltLinux/linux/issues/151
("-Wenum-conversion in drivers/scsi/fcoe/fcoe{_ctlr,_transport}.c")

Thanks.

Regards,
- Sedat -

Re: [PATCH][next] can: at91_can: mark expected switch fall-throughs

[Nicolas.Ferre]

On 08/02/2019 at 19:44, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
> 
> Notice that, in this particular case, the /* fall through */
> comments are placed at the bottom of the case statement, which
> is what GCC is expecting to find.
> 
> Warning level 3 was used: -Wimplicit-fallthrough=3
> 
> This patch is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough.
> 
> Signed-off-by: Gustavo A. R. Silva 

Looks good to me:
Acked-by: Nicolas Ferre 

> ---
>   drivers/net/can/at91_can.c | 6 --
>   1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
> index d98c69045b17..1718c20f9c99 100644
> --- a/drivers/net/can/at91_can.c
> +++ b/drivers/net/can/at91_can.c
> @@ -902,7 +902,8 @@ static void at91_irq_err_state(struct net_device *dev,
>   CAN_ERR_CRTL_TX_WARNING :
>   CAN_ERR_CRTL_RX_WARNING;
>   }
> - case CAN_STATE_ERROR_WARNING:   /* fallthrough */
> + /* fall through */
> + case CAN_STATE_ERROR_WARNING:
>   /*
>* from: ERROR_ACTIVE, ERROR_WARNING
>* to  : ERROR_PASSIVE, BUS_OFF
> @@ -951,7 +952,8 @@ static void at91_irq_err_state(struct net_device *dev,
>   netdev_dbg(dev, "Error Active\n");
>   cf->can_id |= CAN_ERR_PROT;
>   cf->data[2] = CAN_ERR_PROT_ACTIVE;
> - case CAN_STATE_ERROR_WARNING:   /* fallthrough */
> + /* fall through */
> + case CAN_STATE_ERROR_WARNING:
>   reg_idr = AT91_IRQ_ERRA | AT91_IRQ_WARN | AT91_IRQ_BOFF;
>   reg_ier = AT91_IRQ_ERRP;
>   break;
> 


-- 
Nicolas Ferre

Re: [PATCH v1 2/2] clk: mediatek: correct cpu clock name for MT8173 SoC

[Matthias Brugger]

On 11/02/2019 08:15, Seiya Wang wrote:
> Change cpu clock name from ca57 to ca72 since MT8173 does use cortex-a72.
> 
> Signed-off-by: Seiya Wang 

Reviewed-by: Matthias Brugger 

> ---
>  drivers/clk/mediatek/clk-mt8173.c  | 4 ++--
>  include/dt-bindings/clock/mt8173-clk.h | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/mediatek/clk-mt8173.c 
> b/drivers/clk/mediatek/clk-mt8173.c
> index 96c292c3e440..deedeb3ea33b 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -533,7 +533,7 @@ static const char * const ca53_parents[] __initconst = {
>   "univpll"
>  };
>  
> -static const char * const ca57_parents[] __initconst = {
> +static const char * const ca72_parents[] __initconst = {
>   "clk26m",
>   "armca15pll",
>   "mainpll",
> @@ -542,7 +542,7 @@ static const char * const ca57_parents[] __initconst = {
>  
>  static const struct mtk_composite cpu_muxes[] __initconst = {
>   MUX(CLK_INFRA_CA53SEL, "infra_ca53_sel", ca53_parents, 0x, 0, 2),
> - MUX(CLK_INFRA_CA57SEL, "infra_ca57_sel", ca57_parents, 0x, 2, 2),
> + MUX(CLK_INFRA_CA72SEL, "infra_ca72_sel", ca72_parents, 0x, 2, 2),
>  };
>  
>  static const struct mtk_composite top_muxes[] __initconst = {
> diff --git a/include/dt-bindings/clock/mt8173-clk.h 
> b/include/dt-bindings/clock/mt8173-clk.h
> index 8aea623dd518..f7e5356fd602 100644
> --- a/include/dt-bindings/clock/mt8173-clk.h
> +++ b/include/dt-bindings/clock/mt8173-clk.h
> @@ -194,7 +194,7 @@
>  #define CLK_INFRA_PMICWRAP   11
>  #define CLK_INFRA_CLK_13M12
>  #define CLK_INFRA_CA53SEL   13
> -#define CLK_INFRA_CA57SEL   14
> +#define CLK_INFRA_CA72SEL   14
>  #define CLK_INFRA_NR_CLK15
>  
>  /* PERI_SYS */
> 

[PATCH] PCI: endpoint: functions: use memcpy_fromio()/memcpy_toio()

[Wen Yang]

Use the IO memcpy() functions when copying from/to IO memory.
These locations were found via sparse.

Signed-off-by: Wen Yang 
Suggested-by: Kishon Vijay Abraham I 
CC: Lorenzo Pieralisi 
CC: Bjorn Helgaas 
CC: Gustavo Pimentel 
CC: Niklas Cassel 
CC: Greg Kroah-Hartman 
CC: Cyrille Pitchen 
CC: linux-...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
 drivers/pci/endpoint/functions/pci-epf-test.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
b/drivers/pci/endpoint/functions/pci-epf-test.c
index 3e86fa3..4bbd26e 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -175,7 +175,7 @@ static int pci_epf_test_read(struct pci_epf_test *epf_test)
goto err_map_addr;
}
 
-   memcpy(buf, src_addr, reg->size);
+   memcpy_fromio(buf, src_addr, reg->size);
 
crc32 = crc32_le(~0, buf, reg->size);
if (crc32 != reg->checksum)
@@ -230,7 +230,7 @@ static int pci_epf_test_write(struct pci_epf_test *epf_test)
get_random_bytes(buf, reg->size);
reg->checksum = crc32_le(~0, buf, reg->size);
 
-   memcpy(dst_addr, buf, reg->size);
+   memcpy_toio(dst_addr, buf, reg->size);
 
/*
 * wait 1ms inorder for the write to complete. Without this delay L3
-- 
2.9.5

Re: [PATCH] x86/alternatives: check int3 breakpoint physical addresses

[Alexandre Chartre]

On 02/10/2019 10:23 PM, Thomas Gleixner wrote:

On Fri, 25 Jan 2019, Alexandre Chartre wrote:

Note that this issue has been observed and reproduced with a custom kernel
with some code mapped to different virtual addresses and using jump labels
As jump labels use text_poke_bp(), crashes were sometimes observed when
updating jump labels.


Rightfully so. text_poke_bp() pokes at the kernels text mapping which is
very well defined and unique. Why would you map the same text to different
virtual addresses and then use a randomly chosen one to poke at it?



As an example, we used to have per-CPU SYSCALL entry trampoline [1] where the
entry_SYSCALL_64_trampoline function was mapped to a different virtual address
for each CPU. So, a syscall would execute entry_SYSCALL_64_trampoline() from a
different virtual address depending on the CPU being used. With that code,
adding a jump label in entry_SYSCALL_64_trampoline() causes the described issue.

This mapping was eventually removed [2]. I don't know if any other code like 
this
is currently present in the kernel (I couldn't find any, but I might not have
covered everything). But, as this past commit have shown, this is definitively
something that can happen.

Thanks,

alex.

---
[1] 3386bc8aed82 ("x86/entry/64: Create a per-CPU SYSCALL entry trampoline")

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3386bc8aed82

[2] bf904d2762ee ("x86/pti/64: Remove the SYSCALL64 entry trampoline")

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bf904d2762ee

Re: [PATCH 1/2] x86/boot: fix KASL when memmap range manipulation is used

[Baoquan He]

On 01/30/19 at 05:40pm, Julian Stecklina wrote:
> diff --git a/arch/x86/boot/compressed/kaslr.c 
> b/arch/x86/boot/compressed/kaslr.c
> index 9ed9709..5657e34 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -155,6 +155,12 @@ parse_memmap(char *p, unsigned long long *start, 
> unsigned long long *size)
>   case '#':
>   case '$':
>   case '!':
> + /*
> +  * % would need some more complex parsing, because regions might
> +  * actually become usable for KASLR, but the simple way of
> +  * ignoring anything that is mentioned in % works for now.
> +  */

This seems to make thing more complicated even though have to. One
concern is whether we need to check the oldtype|newtype , e.g
oldtype=reserverd, newtype=RAM, is it possible to set like that?

Thanks
Baoquan

> + case '%':
>   *start = memparse(p + 1, &p);
>   return 0;
>   case '@':
> -- 
> 2.7.4
> 

Re: linux-next: Fixes tag needs some work in the fbdev tree

[Michal Vokáč]

On 10. 02. 19 21:24, Stephen Rothwell wrote:

Hi Bartlomiej,

In commit

   7d7e58d30e04 ("dt-bindings: display: ssd1307fb: Remove reset-active-low from 
examples")

Fixes tag

   Fixes: 519b4db ("fbdev: ssd1307fb: Remove reset-active-low from the DT binding 
document")

has these problem(s):

   - SHA1 should be at least 12 digits long
 Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
 or later) just making sure it is not set (or set to "auto").


Hi Stephen,

Sorry, that is my fault, I put the Fixes tag into the submitted patch.
Thanks for the git configuration hint. All my machines were configured
correctly except the one I generated the Fixes tag on, ups :(

Normally checkpatch.pl does a good job identifying errors in referenced
commits. Unfortunately it did not complain in this case. Would be nice
to add this check. I skimmed through the appropriate part of the script
but I do not feel like adding this feature myself, Perl is not my domain.

Sorry for the inconvenience.
Michal

Re: [PATCH] x86/alternatives: check int3 breakpoint physical addresses

[Thomas Gleixner]

On Mon, 11 Feb 2019, Alexandre Chartre wrote:
> On 02/10/2019 10:23 PM, Thomas Gleixner wrote:
> > On Fri, 25 Jan 2019, Alexandre Chartre wrote:
> > > Note that this issue has been observed and reproduced with a custom kernel
> > > with some code mapped to different virtual addresses and using jump labels
> > > As jump labels use text_poke_bp(), crashes were sometimes observed when
> > > updating jump labels.
> > 
> > Rightfully so. text_poke_bp() pokes at the kernels text mapping which is
> > very well defined and unique. Why would you map the same text to different
> > virtual addresses and then use a randomly chosen one to poke at it?
> > 
> 
> As an example, we used to have per-CPU SYSCALL entry trampoline [1] where the
> entry_SYSCALL_64_trampoline function was mapped to a different virtual address
> for each CPU. So, a syscall would execute entry_SYSCALL_64_trampoline() from a
> different virtual address depending on the CPU being used. With that code,
> adding a jump label in entry_SYSCALL_64_trampoline() causes the described
> issue.

Right, but we knew that and there was no reason to put a jump label into
that. AFAICT we don't have anything like this in the kernel.

That said, I'm not opposed to apply the patch as is, I just wanted to get a
better understanding about the background.

Thanks,

tglx

Re: [PATCH][RFC] ACPI: add "processor.broadcast_ppc" hook to broadcast _PPC to all online CPUs

[Viresh Kumar]

On 09-02-19, 20:02, Chen Yu wrote:
> On Dell Inc. XPS13 9333, the BIOS changes the value of
> MSR_IA32_MISC_ENABLE_TURBO_DISABLE at runtime (e.g., when
> the power source changes), the maximum frequency of the
> CPU is not updated accordingly. This is due to the policy's
> cpuinfo.max is not updated when _PPC notifier fires.
> 
> Fix this problem by updating the policy's cpuinfo.max
> and broadcast the _PPC notifier to all online CPUs.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=200759
> Reported-and-tested-by: Gabriele Mazzotta 
> Originally-by: Srinivas Pandruvada 
> Signed-off-by: Chen Yu 
> ---
>  drivers/acpi/processor_perflib.c | 16 ++--
>  drivers/cpufreq/cpufreq.c|  2 ++
>  drivers/cpufreq/intel_pstate.c   | 15 ++-
>  3 files changed, 30 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/processor_perflib.c 
> b/drivers/acpi/processor_perflib.c
> index a303fd0e108c..737dbf5aa7f7 100644
> --- a/drivers/acpi/processor_perflib.c
> +++ b/drivers/acpi/processor_perflib.c
> @@ -63,6 +63,10 @@ module_param(ignore_ppc, int, 0644);
>  MODULE_PARM_DESC(ignore_ppc, "If the frequency of your machine gets wrongly" 
> \
>"limited by BIOS, this should help");
>  
> +static int broadcast_ppc;
> +module_param(broadcast_ppc, int, 0644);
> +MODULE_PARM_DESC(broadcast_ppc, "Broadcast the ppc to all online CPUs");
> +
>  #define PPC_REGISTERED   1
>  #define PPC_IN_USE   2
>  
> @@ -180,8 +184,16 @@ void acpi_processor_ppc_has_changed(struct 
> acpi_processor *pr, int event_flag)
>   else
>   acpi_processor_ppc_ost(pr->handle, 0);
>   }
> - if (ret >= 0)
> - cpufreq_update_policy(pr->id);
> + if (ret >= 0) {
> + if (broadcast_ppc) {
> + int cpu;
> +
> + for_each_possible_cpu(cpu)
> + cpufreq_update_policy(cpu);
> + } else {
> + cpufreq_update_policy(pr->id);
> + }
> + }
>  }
>  
>  int acpi_processor_get_bios_limit(int cpu, unsigned int *limit)
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index e35a886e00bc..95e08816b512 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2237,6 +2237,8 @@ static int cpufreq_set_policy(struct cpufreq_policy 
> *policy,
>  
>   policy->min = new_policy->min;
>   policy->max = new_policy->max;
> + policy->cpuinfo.max_freq = new_policy->cpuinfo.max_freq;
> + policy->cpuinfo.min_freq = new_policy->cpuinfo.min_freq;
>   trace_cpu_frequency_limits(policy);
>  
>   policy->cached_target_freq = UINT_MAX;
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index dd66decf2087..e1881313c396 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -2081,11 +2081,24 @@ static void intel_pstate_adjust_policy_max(struct 
> cpufreq_policy *policy,
>  
>  static int intel_pstate_verify_policy(struct cpufreq_policy *policy)
>  {
> + int max_freq;
>   struct cpudata *cpu = all_cpu_data[policy->cpu];
>  
>   update_turbo_state();
> + max_freq = intel_pstate_get_max_freq(cpu);
> +
> + if (acpi_ppc && policy->max == policy->cpuinfo.max_freq &&
> + max_freq != policy->cpuinfo.max_freq) {
> + /*
> +  * System was not running under any constraints, but the
> +  * current max possible frequency is changed. So reset
> +  * policy limits.
> +  */
> + policy->cpuinfo.max_freq = policy->max = max_freq;
> + }
> +
>   cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
> -  intel_pstate_get_max_freq(cpu));
> +  max_freq);
>  
>   if (policy->policy != CPUFREQ_POLICY_POWERSAVE &&
>   policy->policy != CPUFREQ_POLICY_PERFORMANCE)

By TURBO I believe this is about boost-frequencies and you should use
that infrastructure to make it work, isn't it ?

-- 
viresh

Re: [Resend PATCH] mt76: change the return type of mt76_dma_attach()

[Kalle Valo]

Ryder Lee  writes:

> There is no need to return 0 in mt76_dma_attach(), so switch it to void.
>
> Signed-off-by: Ryder Lee 

When you send a new version mark it as v2:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#patch_version_missing

And add a changelog:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#changelog_missing

No need to resend because of this, but please do remember this in the
future.

-- 
Kalle Valo

Re: [PATCH v2] PCI: endpoint: functions: Use kmemdup instead of duplicating its function

[Gustavo Pimentel]

On 11/02/2019 05:48, Kishon Vijay Abraham I wrote:
> Hi Lorenzo,
> 
> On 08/02/19 5:50 PM, Lorenzo Pieralisi wrote:
>> On Thu, Dec 06, 2018 at 08:52:25PM +0800, Wen Yang wrote:
>>> kmemdup has implemented the function that kmalloc() + memcpy().
>>> We prefer to kmemdup rather than code opened implementation.
>>>
>>> This issue was detected with the help of coccinelle.
>>>
>>> Signed-off-by: Wen Yang 
>>> CC: Kishon Vijay Abraham I 
>>> CC: Lorenzo Pieralisi 
>>> CC: Bjorn Helgaas 
>>> CC: Gustavo Pimentel 
>>> CC: Niklas Cassel 
>>> CC: Greg Kroah-Hartman 
>>> CC: Cyrille Pitchen 
>>> CC: linux-...@vger.kernel.org (open list:PCI ENDPOINT SUBSYSTEM)
>>> CC: linux-kernel@vger.kernel.org (open list)
>>> ---
>>>  drivers/pci/endpoint/functions/pci-epf-test.c | 4 +---
>>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> Kishon,
>>
>> this looks OK to me, anything I am missing ?
> 
> For the existing code this might seem the right thing to do but ideally the
> memcpy here should be changed to memcpy_fromio/memcpy_toio.
> 
> Also later when we plan to use DMA (on the endpoint) for data transfer, we 
> have
> to use kzalloc and dma_map_single APIs.

Are you considering to use the eDMA driver that I'm developing?

> 
> So maybe the right thing would be to just fix it to use memcpy_fromio here.
> 
> Thanks
> Kishon
>>
>> Lorenzo
>>
>>> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
>>> b/drivers/pci/endpoint/functions/pci-epf-test.c
>>> index 3e86fa3c7da3..8df6c019f8a2 100644
>>> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
>>> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
>>> @@ -169,14 +169,12 @@ static int pci_epf_test_read(struct pci_epf_test 
>>> *epf_test)
>>> goto err_addr;
>>> }
>>>  
>>> -   buf = kzalloc(reg->size, GFP_KERNEL);
>>> +   buf = kmemdup(src_addr, reg->size, GFP_KERNEL);
>>> if (!buf) {
>>> ret = -ENOMEM;
>>> goto err_map_addr;
>>> }
>>>  
>>> -   memcpy(buf, src_addr, reg->size);
>>> -
>>> crc32 = crc32_le(~0, buf, reg->size);
>>> if (crc32 != reg->checksum)
>>> ret = -EIO;
>>> -- 
>>> 2.19.1
>>>

[PATCH v2] s390: vsie: Use effective CRYCBD.31 to check CRYCBD validity

[Pierre Morel]

When facility.76 MSAX3 is present for the guest we must issue a validity
interception if the CRYCBD is not valid.

The bit CRYCBD.31 is an effective field and tested at each guest
level and has for effect to mask the facility.76

It follows that if CRYCBD.31 is clear and AP is not in use  we do not
have to test the CRYCBD validatity even facility.76 is present in the
host.

Fixes: 6ee74098201b ("KVM: s390: vsie: allow CRYCB FORMAT-0")
Cc: sta...@vger.kernel.org

Signed-off-by: Pierre Morel 
Reported-by: Claudio Imbrenda 
Acked-by: David Hildenbrand 
---
 arch/s390/kvm/vsie.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
index a153257..d62fa14 100644
--- a/arch/s390/kvm/vsie.c
+++ b/arch/s390/kvm/vsie.c
@@ -297,7 +297,7 @@ static int shadow_crycb(struct kvm_vcpu *vcpu, struct 
vsie_page *vsie_page)
scb_s->crycbd = 0;
 
apie_h = vcpu->arch.sie_block->eca & ECA_APIE;
-   if (!apie_h && !key_msk)
+   if (!apie_h && (!key_msk || fmt_o == CRYCB_FORMAT0))
return 0;
 
if (!crycb_addr)
-- 
2.7.4

[PATCH 1/7] dt-bindings: timer: Add Allwinner suniv timer

[Mesih Kilinc]

Add compatible string for Allwinner suniv timer which is similar to
sun4i timer.

Signed-off-by: Mesih Kilinc 
Acked-by: Maxime Ripard 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt 
b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
index 5c2e235..3da9d51 100644
--- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
+++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
@@ -2,7 +2,9 @@ Allwinner A1X SoCs Timer Controller
 
 Required properties:
 
-- compatible : should be "allwinner,sun4i-a10-timer"
+- compatible : should be one of the following:
+  "allwinner,sun4i-a10-timer"
+  "allwinner,suniv-f1c100s-timer"
 - reg : Specifies base physical address and size of the registers.
 - interrupts : The interrupt of the first timer
 - clocks: phandle to the source clock (usually a 24 MHz fixed clock)
-- 
2.7.4

[PATCH 0/7] Timer & SPI support for Allwinner suniv F1C100s

[Mesih Kilinc]

This is followup series for F1C100s initial support patchset. 
All patches merged except patch 1 ~ 2 which is related to timer.
I am resending those since they are already have Acked tags.

Our dt-bindings for F1C100s are merged, we can now use them at our 
device tree source - patch 3.

Also this series add spi support and enables spi flash at Lichee-pi Nano
in patch 4 ~ 7. This patches are based on Icenowy's work.

Thanks!

Mesih Kilinc (7):
  dt-bindings: timer: Add Allwinner suniv timer
  clocksource: sun4i: add a compatible for suniv
  ARM: dts: suniv: Add dt-binding headers for F1C100s
  dt-bindings: spi: Add Support for Allwinner F1C100s
  ARM: dts: suniv: Add SPI device-tree nodes
  ARM: dts: suniv: Add pinmux for SPI0 and SPI1 of F1C100s
  ARM: dts: f1c100s: Activate SPI flash on Lichee Pi Nano

 .../devicetree/bindings/spi/spi-sun6i.txt  |  5 +-
 .../bindings/timer/allwinner,sun4i-timer.txt   |  4 +-
 arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts  | 13 ++
 arch/arm/boot/dts/suniv-f1c100s.dtsi   | 53 +++---
 drivers/clocksource/timer-sun4i.c  |  5 +-
 5 files changed, 70 insertions(+), 10 deletions(-)

-- 
2.7.4

[PATCH 2/7] clocksource: sun4i: add a compatible for suniv

[Mesih Kilinc]

The suniv (new F-series) chip has a timer with less functionality than
the A10 timer, e.g. it has only 3 channels.

Add a new compatible for it. As we didn't use the extra channels on A10
either now, the code needn't to be changed.

The suniv chip is based on ARM926EJ-S CPU, thus it has no architecture timer.

Register sun4i_timer as sched_clock on it.

Signed-off-by: Mesih Kilinc 
Acked-by: Maxime Ripard 
Acked-by: Daniel Lezcano 
---
 drivers/clocksource/timer-sun4i.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/timer-sun4i.c 
b/drivers/clocksource/timer-sun4i.c
index 6e0180a..65f38f6 100644
--- a/drivers/clocksource/timer-sun4i.c
+++ b/drivers/clocksource/timer-sun4i.c
@@ -186,7 +186,8 @@ static int __init sun4i_timer_init(struct device_node *node)
 */
if (of_machine_is_compatible("allwinner,sun4i-a10") ||
of_machine_is_compatible("allwinner,sun5i-a13") ||
-   of_machine_is_compatible("allwinner,sun5i-a10s"))
+   of_machine_is_compatible("allwinner,sun5i-a10s") ||
+   of_machine_is_compatible("allwinner,suniv-f1c100s"))
sched_clock_register(sun4i_timer_sched_read, 32,
 timer_of_rate(&to));
 
@@ -218,3 +219,5 @@ static int __init sun4i_timer_init(struct device_node *node)
 }
 TIMER_OF_DECLARE(sun4i, "allwinner,sun4i-a10-timer",
   sun4i_timer_init);
+TIMER_OF_DECLARE(suniv, "allwinner,suniv-f1c100s-timer",
+  sun4i_timer_init);
-- 
2.7.4

[PATCH 4/7] dt-bindings: spi: Add Support for Allwinner F1C100s

[Mesih Kilinc]

Allwinner suniv F1C100s has similar SPI controllers as sun8i H3.
Add compatible string for it.

Signed-off-by: Mesih Kilinc 
---
 Documentation/devicetree/bindings/spi/spi-sun6i.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-sun6i.txt 
b/Documentation/devicetree/bindings/spi/spi-sun6i.txt
index 435a8e0..33f490f 100644
--- a/Documentation/devicetree/bindings/spi/spi-sun6i.txt
+++ b/Documentation/devicetree/bindings/spi/spi-sun6i.txt
@@ -1,7 +1,10 @@
 Allwinner A31/H3 SPI controller
 
 Required properties:
-- compatible: Should be "allwinner,sun6i-a31-spi" or "allwinner,sun8i-h3-spi".
+- compatible: should be:
+   - "allwinner,sun6i-a31-spi"
+   - "allwinner,sun8i-h3-spi"
+   - "allwinner,suniv-f1c100s-spi", "allwinner,sun8i-h3-spi"
 - reg: Should contain register location and length.
 - interrupts: Should contain interrupt.
 - clocks: phandle to the clocks feeding the SPI controller. Two are
-- 
2.7.4

[PATCH 6/7] ARM: dts: suniv: Add pinmux for SPI0 and SPI1 of F1C100s

[Mesih Kilinc]

PC0~PC4 is pin group for SPI0. PA0~PA4 is pin group for SPI1.
Add device tree nodes for this groups.

Signed-off-by: Mesih Kilinc 
---
 arch/arm/boot/dts/suniv-f1c100s.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/suniv-f1c100s.dtsi 
b/arch/arm/boot/dts/suniv-f1c100s.dtsi
index 1b332d9..a92a411 100644
--- a/arch/arm/boot/dts/suniv-f1c100s.dtsi
+++ b/arch/arm/boot/dts/suniv-f1c100s.dtsi
@@ -96,6 +96,16 @@
pins = "PE0", "PE1";
function = "uart0";
};
+
+   spi0_pc_pins: spi0-pc-pins {
+   pins = "PC0", "PC1", "PC2", "PC3";
+   function = "spi0";
+   };
+
+   spi1_pa_pins: spi1-pa-pins {
+   pins = "PA0", "PA1", "PA2", "PA3";
+   function = "spi1";
+   };
};
 
timer@1c20c00 {
-- 
2.7.4

[PATCH 3/7] ARM: dts: suniv: Add dt-binding headers for F1C100s

[Mesih Kilinc]

dt-binding headers for F1C100s merged now. So add them back to dtsi.

Signed-off-by: Mesih Kilinc 
---
 arch/arm/boot/dts/suniv-f1c100s.dtsi | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/suniv-f1c100s.dtsi 
b/arch/arm/boot/dts/suniv-f1c100s.dtsi
index 6100d3b..953228c 100644
--- a/arch/arm/boot/dts/suniv-f1c100s.dtsi
+++ b/arch/arm/boot/dts/suniv-f1c100s.dtsi
@@ -4,6 +4,9 @@
  * Copyright 2018 Mesih Kilinc 
  */
 
+#include 
+#include 
+
 / {
#address-cells = <1>;
#size-cells = <1>;
@@ -82,7 +85,7 @@
compatible = "allwinner,suniv-f1c100s-pinctrl";
reg = <0x01c20800 0x400>;
interrupts = <38>, <39>, <40>;
-   clocks = <&ccu 37>, <&osc24M>, <&osc32k>;
+   clocks = <&ccu CLK_BUS_PIO>, <&osc24M>, <&osc32k>;
clock-names = "apb", "hosc", "losc";
gpio-controller;
interrupt-controller;
@@ -114,8 +117,8 @@
interrupts = <1>;
reg-shift = <2>;
reg-io-width = <4>;
-   clocks = <&ccu 38>;
-   resets = <&ccu 24>;
+   clocks = <&ccu CLK_BUS_UART0>;
+   resets = <&ccu RST_BUS_UART0>;
status = "disabled";
};
 
@@ -125,8 +128,8 @@
interrupts = <2>;
reg-shift = <2>;
reg-io-width = <4>;
-   clocks = <&ccu 39>;
-   resets = <&ccu 25>;
+   clocks = <&ccu CLK_BUS_UART1>;
+   resets = <&ccu RST_BUS_UART1>;
status = "disabled";
};
 
@@ -136,8 +139,8 @@
interrupts = <3>;
reg-shift = <2>;
reg-io-width = <4>;
-   clocks = <&ccu 40>;
-   resets = <&ccu 26>;
+   clocks = <&ccu CLK_BUS_UART2>;
+   resets = <&ccu RST_BUS_UART2>;
status = "disabled";
};
};
-- 
2.7.4

[PATCH 7/7] ARM: dts: f1c100s: Activate SPI flash on Lichee Pi Nano

[Mesih Kilinc]

The Lichee Pi Nano board has a Winbond W25Q128FVSIQ 128Mbit SPI NOR flash
connected to the SPI0 controller of F1C100s SoC, via the pinmux group at
PC bank; so it's bootable.

Enable this SPI flash.

Signed-off-by: Mesih Kilinc 
---
 arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts 
b/arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts
index a1154e6..52a29be 100644
--- a/arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts
+++ b/arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts
@@ -24,3 +24,16 @@
pinctrl-0 = <&uart0_pe_pins>;
status = "okay";
 };
+
+&spi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&spi0_pc_pins>;
+   status = "okay";
+   flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "winbond,w25q128", "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <5000>;
+   };
+};
-- 
2.7.4

[PATCH 5/7] ARM: dts: suniv: Add SPI device-tree nodes

[Mesih Kilinc]

Allwinner suniv F1C100s has similar SPI controller as sun8i H3.
F1C100s has no dedicated mod clock, instead it uses AHB bus clock.

Add support for both SPI0 and SPI1.

Signed-off-by: Mesih Kilinc 
---
 arch/arm/boot/dts/suniv-f1c100s.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/suniv-f1c100s.dtsi 
b/arch/arm/boot/dts/suniv-f1c100s.dtsi
index 953228c..1b332d9 100644
--- a/arch/arm/boot/dts/suniv-f1c100s.dtsi
+++ b/arch/arm/boot/dts/suniv-f1c100s.dtsi
@@ -143,5 +143,31 @@
resets = <&ccu RST_BUS_UART2>;
status = "disabled";
};
+
+   spi0: spi@1c05000 {
+   compatible = "allwinner,suniv-f1c100s-spi",
+"allwinner,sun8i-h3-spi";
+   reg = <0x01c05000 0x1000>;
+   interrupts = <10>;
+   clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_BUS_SPI0>;
+   clock-names = "ahb", "mod";
+   resets = <&ccu RST_BUS_SPI0>;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   spi1: spi@1c06000 {
+   compatible = "allwinner,suniv-f1c100s-spi",
+"allwinner,sun8i-h3-spi";
+   reg = <0x01c06000 0x1000>;
+   interrupts = <11>;
+   clocks = <&ccu CLK_BUS_SPI1>, <&ccu CLK_BUS_SPI1>;
+   clock-names = "ahb", "mod";
+   resets = <&ccu RST_BUS_SPI1>;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
};
 };
-- 
2.7.4

Re: [PATCH v3 2/4] dt-bindings: gnss: add mediatek binding

[Johan Hovold]

On Wed, Jan 30, 2019 at 09:50:16AM -0600, Rob Herring wrote:
> On Mon, Jan 28, 2019 at 05:37:59PM +0100, Loys Ollivier wrote:
> > Add binding for Mediatek-based GNSS receivers.
> > 
> > Signed-off-by: Loys Ollivier 
> > ---
> > 
> > v3:
> > Removed the I2C and SPI interfaces references.
> > Removed the "mediatek,mt3339" compatible line.
> > Added the optional propertied (reset, fix)
> > Added the pin names for the optional properties.
> > 
> > v2:
> > Renamed bindings from Globaltop/gtop to Mediatek/mtk.
> > Moved current-speed as an optional propertie.
> > Removed the status line in the example.
> > Added "mediatek,mt3339" compatible.
> > 
> >  .../devicetree/bindings/gnss/mediatek.txt  | 37 
> > ++
> >  1 file changed, 37 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/gnss/mediatek.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/gnss/mediatek.txt 
> > b/Documentation/devicetree/bindings/gnss/mediatek.txt
> > new file mode 100644
> > index ..00650d81c5c8
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/gnss/mediatek.txt
> > @@ -0,0 +1,37 @@
> > +Mediatek-based GNSS Receiver DT binding
> > +
> > +Mediatek chipsets are used in GNSS-receiver modules produced by several
> > +vendors and can use an UART interface.

s/an/a/

> > +
> > +Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic
> > +properties.
> > +
> > +Required properties:
> > +
> > +- compatible   : Must be
> > +
> > +   "globaltop,pa6h"
> > +
> > +- vcc-supply   : Main voltage regulator (pin name: VCC)
> > +
> > +Optional properties:
> > +
> > +- gtop,reset-gpios : GPIO used to reset the device
> > + (pin name: RESET, NRESET)
> 
> reset-gpios is the standard name.
> 
> > +- gtop,fix-gpios   : GPIO used to determine device position fix state
> > + (pin name: FIX, 3D_FIX)

I'm thinking we might need a standard name for fix-gpios as well. This
isn't a feature that is globaltop (or mediatek) specific, and other
manufacturers provide similar functionality through pins named UI_FIX,
or even LCKIND (lock indicator).

The pin is typically used to drive an indicator LED AFAIU, but the
characteristics of the signal varies from device to device (fw to fw),
for example, pulse when no lock and low otherwise, or pulse when a 2d or
3d-fix is acquired, etc.

I'm not sure how useful the pulsing would be for software, but someone
might find a use for it in some form.

Rob, is this something we want to keep in the binding, and if so, how
about using a generic name such as "gnss-fix-gpios"?

Johan

Re: linux-next: manual merge of the scsi-mkp tree with Linus' tree

[John Garry]

On 11/02/2019 04:31, Stephen Rothwell wrote:

Hi all,

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

  drivers/scsi/hisi_sas/hisi_sas_v3_hw.c

between commit:

  7bb25a89aad2 ("scsi: hisi_sas: Set protection parameters prior to adding SCSI 
host")

from Linus' tree and commit:

  b3cce125cb1e ("scsi: hisi_sas: Add support for DIX feature for v3 hw")

from the scsi-mkp tree.

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



The merge looks ok, thanks

JFYI, I did mention in the relevant patchset cover letter that the 
series depends on commit 7bb25a89aad2 ("scsi: hisi_sas: Set protection 
parameters prior to adding SCSI host"), which was not on Martin's 5.1 
queue. The series seems to apply cleanly to that same branch without 
this patch.


John

Re: [RFC][Patch v8 6/7] KVM: Enables the kernel to isolate and report free pages

[David Hildenbrand]

On 10.02.19 01:38, Michael S. Tsirkin wrote:
> On Fri, Feb 08, 2019 at 02:05:09PM -0800, Alexander Duyck wrote:
>> On Fri, Feb 8, 2019 at 1:38 PM Michael S. Tsirkin  wrote:
>>>
>>> On Fri, Feb 08, 2019 at 03:41:55PM -0500, Nitesh Narayan Lal wrote:
>> I am also planning to try Michael's suggestion of using MAX_ORDER - 1.
>> However I am still thinking about a workload which I can use to test its
>> effectiveness.
> You might want to look at doing something like min(MAX_ORDER - 1,
> HUGETLB_PAGE_ORDER). I know for x86 a 2MB page is the upper limit for
> THP which is the most likely to be used page size with the guest.
 Sure, thanks for the suggestion.
>>>
>>> Given current hinting in balloon is MAX_ORDER I'd say
>>> share code. If you feel a need to adjust down the road,
>>> adjust both of them with actual testing showing gains.
>>
>> Actually I'm left kind of wondering why we are even going through
>> virtio-balloon for this?
> 
> Just look at what does it do.
> 
> It improves memory overcommit if guests are cooperative, and it does
> this by giving the hypervisor addresses of pages which it can discard.
> 
> It's just *exactly* like the balloon with all the same limitations.

I agree, this belongs to virtio-balloon *unless* we run into real
problems implementing it via an asynchronous mechanism.

> 
>> It seems like this would make much more sense
>> as core functionality of KVM itself for the specific architectures
>> rather than some side thing.

Whatever can be handled in user space and does not have significant
performance impacts should be handled in user space. If we run into real
problems with that approach, fair enough. (e.g. vcpu yielding is a good
example where an implementation in KVM makes sense, not going via QEMU)

> 
> Well same as balloon: whether it's useful to you at all
> would very much depend on your workloads.
> 
> This kind of cooperative functionality is good for co-located
> single-tenant VMs. That's pretty niche.  The core things in KVM
> generally don't trust guests.
> 
> 
>> In addition this could end up being
>> redundant when you start getting into either the s390 or PowerPC
>> architectures as they already have means of providing unused page
>> hints.

I'd like to note that on s390x the functionality is not provided when
running nested guests. And there are real problems getting it ever
supported. (see description below how it works on s390x, the issue for
nested guests are the bits in the guest -> host page tables we cannot
support for nested guests).

Hinting only works for guests running one level under LPAR (with a
recent machine), but not nested guests.

(LPAR -> KVM1 works, LPAR - KVM1 -> KVM2 foes not work for the latter)

So an implementation for s390 would still make sense for this scenario.

> 
> Interesting. Is there host support in kvm?

On s390x there is. It works on page granularity and synchronization
between guest/host ("don't drop a page in the host while the guest is
reusing it") is done via special bits in the host->guest page table.
Instructions in the guest are able to modify these bits. A guest can
configure a "usage state" of it's backed PTEs. E.g. "unused" or "stable".

Whenever a page in the guest is freed/reused, the ESSA instruction is
triggered in the guest. It will modify the page table bits and add the
guest phyical pfn to a buffer in the host. Once that buffer is full,
ESSA will trigger an intercept to the hypervisor. Here, all these
"unused" pages can be zapped.

Also, when swapping a page out in the hypervisor, if it was masked by
the guest as unused or logically zero, instead of swapping out the page,
it can simply be dropped and a fresh zero page can be supplied when the
guest tries to access it.

"ESSA" is implemented in KVM in arch/s390/kvm/priv.c:handle_essa().

So on s390x, it works because the synchronization with the hypervisor is
directly built into hw vitualization support (guest->host page tables +
instruction) and ESSA will not intercept on every call (due to the buffer).
> 
> 
>> I have a set of patches I proposed that add similar functionality via
>> a KVM hypercall for x86 instead of doing it as a part of a Virtio
>> device[1].  I'm suspecting the overhead of doing things this way is
>> much less then having to make multiple madvise system calls from QEMU
>> back into the kernel.
> 
> Well whether it's a virtio device is orthogonal to whether it's an
> madvise call, right? You can build vhost-pagehint and that can
> handle requests in a VQ within balloon and do it
> within host kernel directly.
> 
> virtio rings let you pass multiple pages so it's really hard to
> say which will win outright - maybe it's more important
> to coalesce exits.

We don't know until we measure it.

-- 

Thanks,

David / dhildenb

[PATCH v2] cpufreq: intel_pstate: Reporting reasons why driver prematurely exit

[Erwan Velu]

The init code path have several execeptions where the module can decide not to 
load.
As CONFIG_X86_INTEL_PSTATE is generally set to Y, the return code is not 
reachable.
The initialisation code is neither verbose of the reason why it did choose to 
prematurely exit.

This situation leads to situation where its difficult for a user to determine,
on a given platform, why the driver didn't loaded properly.

This patch is about reporting to the user the reason/context why the driver 
failed to load.
That is a precious hint when debugging a platform.

Signed-off-by: Erwan Velu 
---
 drivers/cpufreq/intel_pstate.c | 39 ++
 1 file changed, 30 insertions(+), 9 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index dd66decf2087..2b10f8864898 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2475,6 +2475,7 @@ static bool __init intel_pstate_no_acpi_pss(void)
kfree(pss);
}
 
+   pr_info("Cannot detect ACPI PSS");
return true;
 }
 
@@ -2484,10 +2485,16 @@ static bool __init intel_pstate_no_acpi_pcch(void)
acpi_handle handle;
 
status = acpi_get_handle(NULL, "\\_SB", &handle);
-   if (ACPI_FAILURE(status))
+   if (ACPI_FAILURE(status)) {
+   pr_info("Cannot detect ACPI SB");
return true;
+   }
 
-   return !acpi_has_method(handle, "PCCH");
+   status = acpi_has_method(handle, "PCCH");
+   if (!status) {
+   pr_info("Cannot detect ACPI PCCH");
+   }
+   return !status;
 }
 
 static bool __init intel_pstate_has_acpi_ppc(void)
@@ -2499,9 +2506,11 @@ static bool __init intel_pstate_has_acpi_ppc(void)
 
if (!pr)
continue;
-   if (acpi_has_method(pr->handle, "_PPC"))
+   if (acpi_has_method(pr->handle, "_PPC")) {
return true;
+   }
}
+   pr_info("Cannot detect ACPI PPC");
return false;
 }
 
@@ -2592,8 +2601,10 @@ static int __init intel_pstate_init(void)
const struct x86_cpu_id *id;
int rc;
 
-   if (no_load)
+   if (no_load) {
+   pr_info("disabling as per user-request\n");
return -ENODEV;
+   }
 
id = x86_match_cpu(hwp_support_ids);
if (id) {
@@ -2606,31 +2617,41 @@ static int __init intel_pstate_init(void)
}
} else {
id = x86_match_cpu(intel_pstate_cpu_ids);
-   if (!id)
+   if (!id) {
+   pr_warn("CPU ID is not in the list of supported 
devices\n");
return -ENODEV;
+   }
 
copy_cpu_funcs((struct pstate_funcs *)id->driver_data);
}
 
-   if (intel_pstate_msrs_not_valid())
+   if (intel_pstate_msrs_not_valid()) {
+   pr_warn("Cannot enable driver as per invalid MSRs\n");
return -ENODEV;
+   }
 
 hwp_cpu_matched:
/*
 * The Intel pstate driver will be ignored if the platform
 * firmware has its own power management modes.
 */
-   if (intel_pstate_platform_pwr_mgmt_exists())
+   if (intel_pstate_platform_pwr_mgmt_exists()) {
+   pr_warn("Platform already taking care of power management\n");
return -ENODEV;
+   }
 
-   if (!hwp_active && hwp_only)
+   if (!hwp_active && hwp_only) {
+   pr_warn("HWP not present\n");
return -ENOTSUPP;
+   }
 
pr_info("Intel P-state driver initializing\n");
 
all_cpu_data = vzalloc(array_size(sizeof(void *), num_possible_cpus()));
-   if (!all_cpu_data)
+   if (!all_cpu_data) {
+   pr_warn("Cannot allocate memory\n");
return -ENOMEM;
+   }
 
intel_pstate_request_control_from_smm();
 
-- 
2.20.1

Re: [PATCH 2/2] sched/fair: Improve the for loop in select_idle_core()

[Peter Zijlstra]

On Thu, Feb 07, 2019 at 04:16:06PM +0530, Viresh Kumar wrote:
> @@ -6081,10 +6082,14 @@ static int select_idle_core(struct task_struct *p, 
> struct sched_domain *sd, int
>   for_each_cpu_wrap(core, cpus, target) {
>   bool idle = true;
>  
> - for_each_cpu(cpu, cpu_smt_mask(core)) {
> - cpumask_clear_cpu(cpu, cpus);
> - if (!available_idle_cpu(cpu))
> + smt = cpu_smt_mask(core);
> + cpumask_andnot(cpus, cpus, smt);

So where the previous code was like 1-2 stores, you just added 16.

(assuming 64bit and NR_CPUS=1024)

And we still do the iteration anyway:

> + for_each_cpu(cpu, smt) {
> + if (!available_idle_cpu(cpu)) {
>   idle = false;
> + break;
> + }
>   }

An actual improvement would've been:

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 38d4669aa2ef..2d352d6d15c7 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6082,7 +6082,7 @@ static int select_idle_core(struct task_struct *p, struct 
sched_domain *sd, int
bool idle = true;
 
for_each_cpu(cpu, cpu_smt_mask(core)) {
-   cpumask_clear_cpu(cpu, cpus);
+   __cpumask_clear_cpu(cpu, cpus);
if (!available_idle_cpu(cpu))
idle = false;
}

Re: [tip:x86/boot] x86/boot: Early parse RSDP and save it in boot_params

[Chao Fan]

On Fri, Feb 08, 2019 at 11:02:48AM -0800, Guenter Roeck wrote:
>Hi,
>
>On Fri, Feb 01, 2019 at 03:01:11AM -0800, tip-bot for Chao Fan wrote:
>> Commit-ID:  3a63f70bf4c3a17f5d9c9bf3bc3288a23bdfefce
>> Gitweb: 
>> https://git.kernel.org/tip/3a63f70bf4c3a17f5d9c9bf3bc3288a23bdfefce
>> Author: Chao Fan 
>> AuthorDate: Wed, 23 Jan 2019 19:08:48 +0800
>> Committer:  Borislav Petkov 
>> CommitDate: Fri, 1 Feb 2019 11:52:55 +0100
>> 
>> x86/boot: Early parse RSDP and save it in boot_params
>> 
>> The RSDP is needed by KASLR so parse it early and save it in
>> boot_params.acpi_rsdp_addr, before KASLR setup runs.
>> 
>> RSDP is needed by other kernel facilities so have the parsing code
>> built-in instead of a long "depends on" line in Kconfig.
>> 
>>  [ bp:
>> - Trim commit message and comments
>> - Add CONFIG_ACPI dependency in the Makefile
>> - Move ->acpi_rsdp_addr assignment with the rest of boot_params 
>> massaging in extract_kernel().
>>  ]
>> 
>
>This patch causes x86_64 boots with efi32 bios to crash early and hard
>(before any console output is seen).
>
>Sample qemu command line:
>
>qemu-system-x86_64 -kernel arch/x86/boot/bzImage -M q35 -cpu SandyBridge \
>   -no-reboot -snapshot -smp 4 \
>   -bios OVMF-pure-efi-32.fd \
>   -m 1G \
>   -usb -device usb-storage,drive=d0 \
>   -drive file=rootfs.squashfs,if=none,id=d0,format=raw \
>   --append 'earlycon=uart8250,io,0x3f8,9600n8 root=/dev/sda rootwait 
> panic=-1 console=ttyS0' \
>   -nographic
>
>This is with qemu 3.1, though details other than "-bios OVMF-pure-efi-32.fd"
>don't really matter.

Yes, I download your ovmf file in linux-build-test/rootfs/firmware/ from
your link. There are two files, efi32 and efi64. Then I try to run:

BIOS=/usr/share/edk2/ovmf/OVMF-pure-efi-32.fd
qemu-system-x86_64 \
-bios $BIOS \
-cdrom /var/lib/libvirt/images/iso/Fedora-Workstation-Live-x86_64-29-1.2.iso \
-hda /var/lib/libvirt/images/fedora-efi32.qcow2 \
-enable-kvm \
-m 5G \
-serial stdio

It can't boot, but if I changed as:
BIOS=/usr/share/edk2/ovmf/OVMF-pure-efi-64.fd

Then the machine booted. So I am not sure how to use this
OVMF-pure-efi-32.fd. If there is somethins wrong in my understand,
please let me know.

Thanks,
Chao Fan

>
>Files used above are available from 
>https://github.com/groeck/linux-build-test/.
>
>The patch can not be reverted alone, but
>
>Revert "x86/boot/KASLR: Limit KASLR to extract the kernel in immovable memory 
>only"
>Revert "x86/boot: Parse SRAT table and count immovable memory regions"
>Revert "x86/boot: Early parse RSDP and save it in boot_params"
>
>fixes the problem.
>
>Bisect log attached below.
>
>Guenter
>
>---
># bad: [a46228f6598a191e25ca160870f20c3cd1743d13] Add linux-next specific 
>files for 20190208
># good: [8834f5600cf3c8db365e18a3d5cac2c2780c81e5] Linux 5.0-rc5
>git bisect start 'HEAD' 'v5.0-rc5'
># good: [d5ee02f33ec5ade9c9afb9d45bfc4f5cb1375e58] Merge remote-tracking 
>branch 'spi-nor/spi-nor/next'
>git bisect good d5ee02f33ec5ade9c9afb9d45bfc4f5cb1375e58
># good: [f34bff29873986d260d7a491fb6f543d12fbe7cd] Merge remote-tracking 
>branch 'devicetree/for-next'
>git bisect good f34bff29873986d260d7a491fb6f543d12fbe7cd
># bad: [68182cb929ec6a676655887cbfb12b09662c1e5b] Merge remote-tracking branch 
>'icc/icc-next'
>git bisect bad 68182cb929ec6a676655887cbfb12b09662c1e5b
># bad: [0a5c6189664123753c298d90dec3a5a6b907f06f] Merge remote-tracking branch 
>'driver-core/driver-core-next'
>git bisect bad 0a5c6189664123753c298d90dec3a5a6b907f06f
># bad: [e2a43b09bfc24369719437b5f8f703c5d7003af2] Merge remote-tracking branch 
>'tip/auto-latest'
>git bisect bad e2a43b09bfc24369719437b5f8f703c5d7003af2
># good: [ba1ef96ac73d2a9851dc64d0a991ac8699aa6a22] Merge branch 'timers/core'
>git bisect good ba1ef96ac73d2a9851dc64d0a991ac8699aa6a22
># good: [473a78a7bbeb7c77b81b596095f59ce4fbbd49dc] spi-atmel: support 
>inter-word delay
>git bisect good 473a78a7bbeb7c77b81b596095f59ce4fbbd49dc
># bad: [132dc31173c99bd252f6a54e3a9fba90f7417a43] Merge branch 'x86/cleanups'
>git bisect bad 132dc31173c99bd252f6a54e3a9fba90f7417a43
># bad: [6eb09d138a331121740a4cf7458ab317979d9a17] Merge branch 'x86/boot'
>git bisect bad 6eb09d138a331121740a4cf7458ab317979d9a17
># good: [e2c403557ebbcd1f0052e1ae51cfaff596cf259d] Merge branch 'x86/asm'
>git bisect good e2c403557ebbcd1f0052e1ae51cfaff596cf259d
># good: [33f0df8d843deb9ec24116dcd79a40ca0ea8e8a9] x86/boot: Search for RSDP 
>in the EFI tables
>git bisect good 33f0df8d843deb9ec24116dcd79a40ca0ea8e8a9
># bad: [3a63f70bf4c3a17f5d9c9bf3bc3288a23bdfefce] x86/boot: Early parse RSDP 
>and save it in boot_params
>git bisect bad 3a63f70bf4c3a17f5d9c9bf3bc3288a23bdfefce
># good: [93a209d495d7d0bc9b6186a4495934f70402] x86/boot: Search for RSDP 
>in memory
>git bisect good 93a209d495d7d0bc9b6186a4495934f70402
># first bad commit: [3a63f70bf4c3a17f5d9c9bf3bc3288a23bdfefce] x86/boot: Early 
>parse RSDP and save it in boot_params
>
>

[PATCH v3] cpufreq: intel_pstate: Reporting reasons why driver prematurely exit

[Erwan Velu]

The init code path have several execeptions where the module can decide not to 
load.
As CONFIG_X86_INTEL_PSTATE is generally set to Y, the return code is not 
reachable.
The initialisation code is neither verbose of the reason why it did choose to 
prematurely exit.

This situation leads to situation where its difficult for a user to determine,
on a given platform, why the driver didn't loaded properly.

This patch is about reporting to the user the reason/context why the driver 
failed to load.
That is a precious hint when debugging a platform.

Signed-off-by: Erwan Velu 
---
 drivers/cpufreq/intel_pstate.c | 36 ++
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index dd66decf2087..ba2e2aee6c20 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2475,6 +2475,7 @@ static bool __init intel_pstate_no_acpi_pss(void)
kfree(pss);
}
 
+   pr_info("Cannot detect ACPI PSS");
return true;
 }
 
@@ -2484,10 +2485,16 @@ static bool __init intel_pstate_no_acpi_pcch(void)
acpi_handle handle;
 
status = acpi_get_handle(NULL, "\\_SB", &handle);
-   if (ACPI_FAILURE(status))
+   if (ACPI_FAILURE(status)) {
+   pr_info("Cannot detect ACPI SB");
return true;
+   }
 
-   return !acpi_has_method(handle, "PCCH");
+   status = acpi_has_method(handle, "PCCH");
+   if (!status) {
+   pr_info("Cannot detect ACPI PCCH");
+   }
+   return !status;
 }
 
 static bool __init intel_pstate_has_acpi_ppc(void)
@@ -2502,6 +2509,7 @@ static bool __init intel_pstate_has_acpi_ppc(void)
if (acpi_has_method(pr->handle, "_PPC"))
return true;
}
+   pr_info("Cannot detect ACPI PPC");
return false;
 }
 
@@ -2592,8 +2600,10 @@ static int __init intel_pstate_init(void)
const struct x86_cpu_id *id;
int rc;
 
-   if (no_load)
+   if (no_load) {
+   pr_info("disabling as per user-request\n");
return -ENODEV;
+   }
 
id = x86_match_cpu(hwp_support_ids);
if (id) {
@@ -2606,31 +2616,41 @@ static int __init intel_pstate_init(void)
}
} else {
id = x86_match_cpu(intel_pstate_cpu_ids);
-   if (!id)
+   if (!id) {
+   pr_warn("CPU ID is not in the list of supported 
devices\n");
return -ENODEV;
+   }
 
copy_cpu_funcs((struct pstate_funcs *)id->driver_data);
}
 
-   if (intel_pstate_msrs_not_valid())
+   if (intel_pstate_msrs_not_valid()) {
+   pr_warn("Cannot enable driver as per invalid MSRs\n");
return -ENODEV;
+   }
 
 hwp_cpu_matched:
/*
 * The Intel pstate driver will be ignored if the platform
 * firmware has its own power management modes.
 */
-   if (intel_pstate_platform_pwr_mgmt_exists())
+   if (intel_pstate_platform_pwr_mgmt_exists()) {
+   pr_warn("Platform already taking care of power management\n");
return -ENODEV;
+   }
 
-   if (!hwp_active && hwp_only)
+   if (!hwp_active && hwp_only) {
+   pr_warn("HWP not present\n");
return -ENOTSUPP;
+   }
 
pr_info("Intel P-state driver initializing\n");
 
all_cpu_data = vzalloc(array_size(sizeof(void *), num_possible_cpus()));
-   if (!all_cpu_data)
+   if (!all_cpu_data) {
+   pr_warn("Cannot allocate memory\n");
return -ENOMEM;
+   }
 
intel_pstate_request_control_from_smm();
 
-- 
2.20.1

Re: [PATCH 0/5] riscv: minor fixes and cleanups

[Johan Hovold]

On Fri, Jan 18, 2019 at 03:03:03PM +0100, Johan Hovold wrote:
> This series fix up some minor issues found through inspection.
> 
> Note that the fourth patch changes which cpu (hart) devicetree nodes
> are enabled by following the Linux convention of considering nodes
> without a status property as enabled.
> 
> These patches are against the riscv-next (and fixes) branch with Andreas
> node-reference fix applied:
> 
>   https://lore.kernel.org/lkml/mvm8szwwo1o@suse.de/
> 
> and have been tested using QEMU.

> Johan Hovold (5):
>   riscv: add missing newlines to printk messages
>   riscv: use pr_info and friends
>   riscv: fix riscv_of_processor_hartid() comment
>   riscv: treat cpu devicetree nodes without status as enabled
>   riscv: use for_each_of_cpu_node iterator

Are these still in your queue, Palmer?

Note that the node-reference dependency mentioned above is now in
Linus's tree.

Johan

Re: [PATCH] locking/rwsem: Remove arch specific rwsem files

[Peter Zijlstra]

On Sun, Feb 10, 2019 at 09:00:50PM -0500, Waiman Long wrote:
> diff --git a/kernel/locking/rwsem.h b/kernel/locking/rwsem.h
> index bad2bca..067e265 100644
> --- a/kernel/locking/rwsem.h
> +++ b/kernel/locking/rwsem.h
> @@ -32,6 +32,26 @@
>  # define DEBUG_RWSEMS_WARN_ON(c)
>  #endif
>  
> +/*
> + * R/W semaphores originally for PPC using the stuff in lib/rwsem.c.
> + * Adapted largely from include/asm-i386/rwsem.h
> + * by Paul Mackerras .
> + */
> +
> +/*
> + * the semaphore definition
> + */
> +#ifdef CONFIG_64BIT
> +# define RWSEM_ACTIVE_MASK   0xL
> +#else
> +# define RWSEM_ACTIVE_MASK   0xL
> +#endif
> +
> +#define RWSEM_ACTIVE_BIAS0x0001L
> +#define RWSEM_WAITING_BIAS   (-RWSEM_ACTIVE_MASK-1)
> +#define RWSEM_ACTIVE_READ_BIAS   RWSEM_ACTIVE_BIAS
> +#define RWSEM_ACTIVE_WRITE_BIAS  (RWSEM_WAITING_BIAS + 
> RWSEM_ACTIVE_BIAS)
> +
>  #ifdef CONFIG_RWSEM_SPIN_ON_OWNER
>  /*
>   * All writes to owner are protected by WRITE_ONCE() to make sure that
> @@ -132,3 +152,113 @@ static inline void rwsem_clear_reader_owned(struct 
> rw_semaphore *sem)
>  {
>  }
>  #endif
> +
> +#ifdef CONFIG_RWSEM_XCHGADD_ALGORITHM
> +/*
> + * lock for reading
> + */
> +static inline void __down_read(struct rw_semaphore *sem)
> +{
> + if (unlikely(atomic_long_inc_return_acquire(&sem->count) <= 0))
> + rwsem_down_read_failed(sem);
> +}
> +
> +static inline int __down_read_killable(struct rw_semaphore *sem)
> +{
> + if (unlikely(atomic_long_inc_return_acquire(&sem->count) <= 0)) {
> + if (IS_ERR(rwsem_down_read_failed_killable(sem)))
> + return -EINTR;
> + }
> +
> + return 0;
> +}
> +
> +static inline int __down_read_trylock(struct rw_semaphore *sem)
> +{
> + long tmp;
> +
> + while ((tmp = atomic_long_read(&sem->count)) >= 0) {
> + if (tmp == atomic_long_cmpxchg_acquire(&sem->count, tmp,
> +tmp + RWSEM_ACTIVE_READ_BIAS)) {
> + return 1;

That really wants to be:

if (atomic_long_try_cmpxchg_acquire(&sem->count, &tmp,
tmp + 
RWSEM_ACTIVE_READ_BIAS))

> + }
> + }
> + return 0;
> +}
> +
> +/*
> + * lock for writing
> + */
> +static inline void __down_write(struct rw_semaphore *sem)
> +{
> + long tmp;
> +
> + tmp = atomic_long_add_return_acquire(RWSEM_ACTIVE_WRITE_BIAS,
> +  &sem->count);
> + if (unlikely(tmp != RWSEM_ACTIVE_WRITE_BIAS))
> + rwsem_down_write_failed(sem);
> +}
> +
> +static inline int __down_write_killable(struct rw_semaphore *sem)
> +{
> + long tmp;
> +
> + tmp = atomic_long_add_return_acquire(RWSEM_ACTIVE_WRITE_BIAS,
> +  &sem->count);
> + if (unlikely(tmp != RWSEM_ACTIVE_WRITE_BIAS))
> + if (IS_ERR(rwsem_down_write_failed_killable(sem)))
> + return -EINTR;
> + return 0;
> +}
> +
> +static inline int __down_write_trylock(struct rw_semaphore *sem)
> +{
> + long tmp;

tmp = RWSEM_UNLOCKED_VALUE;

> +
> + tmp = atomic_long_cmpxchg_acquire(&sem->count, RWSEM_UNLOCKED_VALUE,
> +   RWSEM_ACTIVE_WRITE_BIAS);
> + return tmp == RWSEM_UNLOCKED_VALUE;

return atomic_long_try_cmpxchg_acquire(&sem->count, &tmp,
   RWSEM_ACTIVE_WRITE_BIAS);

> +}
> +
> +/*
> + * unlock after reading
> + */
> +static inline void __up_read(struct rw_semaphore *sem)
> +{
> + long tmp;
> +
> + tmp = atomic_long_dec_return_release(&sem->count);
> + if (unlikely(tmp < -1 && (tmp & RWSEM_ACTIVE_MASK) == 0))
> + rwsem_wake(sem);
> +}
> +
> +/*
> + * unlock after writing
> + */
> +static inline void __up_write(struct rw_semaphore *sem)
> +{
> + if (unlikely(atomic_long_sub_return_release(RWSEM_ACTIVE_WRITE_BIAS,
> + &sem->count) < 0))
> + rwsem_wake(sem);
> +}
> +
> +/*
> + * downgrade write lock to read lock
> + */
> +static inline void __downgrade_write(struct rw_semaphore *sem)
> +{
> + long tmp;
> +
> + /*
> +  * When downgrading from exclusive to shared ownership,
> +  * anything inside the write-locked region cannot leak
> +  * into the read side. In contrast, anything in the
> +  * read-locked region is ok to be re-ordered into the
> +  * write side. As such, rely on RELEASE semantics.
> +  */
> + tmp = atomic_long_add_return_release(-RWSEM_WAITING_BIAS, &sem->count);
> + if (tmp < 0)
> + rwsem_downgrade_wake(sem);
> +}
> +
> +#endif /* CONFIG_RWSEM_XCHGADD_ALGORITHM */

Re: [PATCH] arm64: dts: msm8996: fix blsp2_uart1 4-pin pinconfig

[Johan Hovold]

On Thu, Dec 20, 2018 at 05:17:50PM +0100, Johan Hovold wrote:
> Fix "gpiio5" typo in the (currently unused) blsp2_uart1 4-pin sleep
> config.
> 
> Fixes: 22e6789f9493 ("arm64: dts: msm8996: add blsp2_uart1 pinctrl")
> Cc: Srinivas Kandagatla 
> Signed-off-by: Johan Hovold 

I can't seem to find this one in your tree (or linux-next), Andy. Lost
or simply not applied yet?

Johan

Re: [PATCH net-next v3] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs

[Nicolas Dichtel]

Le 11/02/2019 à 04:54, Callum Sinclair a écrit :
> v1 -> v2:
> Implemented additional flags for static entries
> v2 -> v3:
> Cleaned up flag logic so any combination of routes can be cleared.
> Fixed style errors
> Fixed incorrect flag values
nit: those lines are usually put after the '---', thus they don't appear in the
final commit log (they are useful for reviewers only).

> 
> Currently the only way to clear the forwarding cache was to delete the
> entries one by one using the MRT_DEL_MFC socket option or to destroy and
> recreate the socket.
> 
> Create a new socket option which with the use of optional flags can
> clear any combination of multicast entries (static or not static) and
> multicast vifs (static or not static).
> 
> Calling the new socket option MRT_FLUSH with the flags MRT_FLUSH_MFC and
> MRT_FLUSH_VIFS will clear all entries and vifs on the socket except for
> static entries.
> 
> Signed-off-by: Callum Sinclair 
> ---
ie, here

>  include/uapi/linux/mroute.h  |  9 -
>  include/uapi/linux/mroute6.h |  9 -
>  net/ipv4/ipmr.c  | 73 -
>  net/ipv6/ip6mr.c | 78 +++-
>  4 files changed, 112 insertions(+), 57 deletions(-)
> 
> diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
> index 5d37a9ccce63..11c8c1fc1124 100644
> --- a/include/uapi/linux/mroute.h
> +++ b/include/uapi/linux/mroute.h
> @@ -28,12 +28,19 @@
>  #define MRT_TABLE(MRT_BASE+9)/* Specify mroute table ID  
> */
>  #define MRT_ADD_MFC_PROXY(MRT_BASE+10)   /* Add a (*,*|G) mfc entry  
> */
>  #define MRT_DEL_MFC_PROXY(MRT_BASE+11)   /* Del a (*,*|G) mfc entry  
> */
> -#define MRT_MAX  (MRT_BASE+11)
> +#define MRT_FLUSH(MRT_BASE+12)   /* Flush all mfc entries and/or vifs
> */
> +#define MRT_MAX  (MRT_BASE+12)
>  
>  #define SIOCGETVIFCNTSIOCPROTOPRIVATE/* IP protocol privates 
> */
>  #define SIOCGETSGCNT (SIOCPROTOPRIVATE+1)
>  #define SIOCGETRPF   (SIOCPROTOPRIVATE+2)
>  
> +/* MRT_FLUSH optional flags */
> +#define MRT_FLUSH_MFC1   /* Flush multicast entries */
> +#define MRT_FLUSH_MFC_STATIC 2   /* Flush static multicast entries */
> +#define MRT_FLUSH_VIFS   4   /* Flush multicast vifs */
> +#define MRT_FLUSH_VIFS_STATIC8   /* Flush static multicast vifs 
> */
> +
>  #define MAXVIFS  32
>  typedef unsigned long vifbitmap_t;   /* User mode code depends on this lot */
>  typedef unsigned short vifi_t;
> diff --git a/include/uapi/linux/mroute6.h b/include/uapi/linux/mroute6.h
> index cc006390..ac84ef11b29c 100644
> --- a/include/uapi/linux/mroute6.h
> +++ b/include/uapi/linux/mroute6.h
> @@ -31,12 +31,19 @@
>  #define MRT6_TABLE   (MRT6_BASE+9)   /* Specify mroute table ID  
> */
>  #define MRT6_ADD_MFC_PROXY   (MRT6_BASE+10)  /* Add a (*,*|G) mfc entry  
> */
>  #define MRT6_DEL_MFC_PROXY   (MRT6_BASE+11)  /* Del a (*,*|G) mfc entry  
> */
> -#define MRT6_MAX (MRT6_BASE+11)
> +#define MRT6_FLUSH   (MRT6_BASE+12)  /* Flush all mfc entries and/or vifs
> */
> +#define MRT6_MAX (MRT6_BASE+12)
>  
>  #define SIOCGETMIFCNT_IN6SIOCPROTOPRIVATE/* IP protocol privates 
> */
>  #define SIOCGETSGCNT_IN6 (SIOCPROTOPRIVATE+1)
>  #define SIOCGETRPF   (SIOCPROTOPRIVATE+2)
>  
> +/* MRT6_FLUSH optional flags */
> +#define MRT6_FLUSH_MFC   1   /* Flush multicast entries */
> +#define MRT6_FLUSH_MFC_STATIC2   /* Flush static multicast 
> entries */
> +#define MRT6_FLUSH_VIFS  4   /* Flushing multicast vifs */
> +#define MRT6_FLUSH_VIFS_STATIC   8   /* Flush static multicast vifs 
> */
> +
>  #define MAXMIFS  32
>  typedef unsigned long mifbitmap_t;   /* User mode code depends on this lot */
>  typedef unsigned short mifi_t;
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index e536970557dd..2c95ef8cf224 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
> @@ -110,7 +110,7 @@ static int ipmr_cache_report(struct mr_table *mrt,
>  static void mroute_netlink_event(struct mr_table *mrt, struct mfc_cache *mfc,
>int cmd);
>  static void igmpmsg_netlink_event(struct mr_table *mrt, struct sk_buff *pkt);
> -static void mroute_clean_tables(struct mr_table *mrt, bool all);
> +static void mroute_clean_tables(struct mr_table *mrt, int flags);
>  static void ipmr_expire_process(struct timer_list *t);
>  
>  #ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
> @@ -415,7 +415,8 @@ static struct mr_table *ipmr_new_table(struct net *net, 
> u32 id)
>  static void ipmr_free_table(struct mr_table *mrt)
>  {
>   del_timer_sync(&mrt->ipmr_expire_timer);
> - mroute_clean_tables(mrt, true);
> + mroute_clean_tables(mrt, MRT_FLUSH_VIFS | MRT_FLUSH_VIFS_STATIC |
> + MRT_FLUSH_MFC | 
> MRT_FLUSH_MFC_STATIC);
nit: MRT_FLUSH_MFC must be aligned with 'mrt

Re: [PATCH] locking/rwsem: Remove arch specific rwsem files

[Peter Zijlstra]

On Mon, Feb 11, 2019 at 10:36:01AM +0100, Peter Zijlstra wrote:
> On Sun, Feb 10, 2019 at 09:00:50PM -0500, Waiman Long wrote:
> > +static inline int __down_read_trylock(struct rw_semaphore *sem)
> > +{
> > +   long tmp;
> > +
> > +   while ((tmp = atomic_long_read(&sem->count)) >= 0) {
> > +   if (tmp == atomic_long_cmpxchg_acquire(&sem->count, tmp,
> > +  tmp + RWSEM_ACTIVE_READ_BIAS)) {
> > +   return 1;
> 
> That really wants to be:
> 
>   if (atomic_long_try_cmpxchg_acquire(&sem->count, &tmp,
>   tmp + 
> RWSEM_ACTIVE_READ_BIAS))
> 
> > +   }
> > +   }
> > +   return 0;
> > +}

Also, the is the one case where LL/SC can actually do 'better'. Do you
have benchmarks for say PowerPC or ARM64 ?

Re: [tip:x86/boot] x86/boot: Early parse RSDP and save it in boot_params

[Ard Biesheuvel]

On Mon, 11 Feb 2019 at 01:22, Borislav Petkov  wrote:
>
> On Fri, Feb 08, 2019 at 10:53:22PM +0100, Borislav Petkov wrote:
> > On Fri, Feb 08, 2019 at 12:44:51PM -0800, Guenter Roeck wrote:
> > > Yes, the kernel boots if I comment out that function and have it return 0.
> >
> > Thanks, this localizes the issue significantly.
>
> Some observations:
>
> } else {
> efi_config_table_32_t *tmp_table;
>
> tmp_table = config_tables;
> guid = tmp_table->guid; <--- *
> table = tmp_table->table;
> }
>
> It blows up at that tmp_table->guid deref above. Singlestepping through
> it with gdb shows:
>
> # arch/x86/boot/compressed/acpi.c:114:  guid = 
> tmp_table->guid;
> movq(%rdi), %rax# MEM[(struct efi_config_table_32_t 
> *)config_tables_37].guid, guid
> movq8(%rdi), %rsi   # MEM[(struct efi_config_table_32_t 
> *)config_tables_37].guid, guid
> # arch/x86/boot/compressed/acpi.c:115:  table = 
> tmp_table->table;
> movl16(%rdi), %r10d # MEM[(struct efi_config_table_32_t 
> *)config_tables_37].table, table
> jmp .L30#
>
> and %rdi has:
>
> rdi0x630646870
>
> which is an address above 4G but we're using a 32-bit EFI BIOS.
>
> Which begs the question whether EFI system tables can even be mapped at
> something above 4G with a 32-bit EFI and whether that could work ok.
> Hmm.
>
> Lemme add Ard and mfleming for insight here.
>

-ENOCONTEXT, but let me try in any case:

linux/efi.h has

typedef struct {
  efi_guid_t guid;
  u32 table;
} efi_config_table_32_t;

so if we end up with more than 32 bits set in table, there is
something seriously wrong.

The size of efi_config_table_32_t deviates from efi_config_table_64_t,
so you will have to ensure that you are using the correct stride when
iterating over config_tables.

Re: [PATCH v2] s390: vsie: Use effective CRYCBD.31 to check CRYCBD validity

[Cornelia Huck]

On Mon, 11 Feb 2019 10:20:49 +0100
Pierre Morel  wrote:

> When facility.76 MSAX3 is present for the guest we must issue a validity
> interception if the CRYCBD is not valid.
> 
> The bit CRYCBD.31 is an effective field and tested at each guest
> level and has for effect to mask the facility.76
> 
> It follows that if CRYCBD.31 is clear and AP is not in use  we do not
> have to test the CRYCBD validatity even facility.76 is present in the

s/even/even if/

> host.
> 
> Fixes: 6ee74098201b ("KVM: s390: vsie: allow CRYCB FORMAT-0")
> Cc: sta...@vger.kernel.org
> 
> Signed-off-by: Pierre Morel 
> Reported-by: Claudio Imbrenda 
> Acked-by: David Hildenbrand 
> ---
>  arch/s390/kvm/vsie.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
> index a153257..d62fa14 100644
> --- a/arch/s390/kvm/vsie.c
> +++ b/arch/s390/kvm/vsie.c
> @@ -297,7 +297,7 @@ static int shadow_crycb(struct kvm_vcpu *vcpu, struct 
> vsie_page *vsie_page)
>   scb_s->crycbd = 0;
>  
>   apie_h = vcpu->arch.sie_block->eca & ECA_APIE;
> - if (!apie_h && !key_msk)
> + if (!apie_h && (!key_msk || fmt_o == CRYCB_FORMAT0))
>   return 0;
>  
>   if (!crycb_addr)

Acked-by: Cornelia Huck 

Re: [Xen-devel] [PATCH net-next] xen-netback: mark expected switch fall-through

[Jan Beulich]

>>> On 08.02.19 at 20:58,  wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
> 
> Warning level 3 was used: -Wimplicit-fallthrough=3
> 
> This patch is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/net/xen-netback/xenbus.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/xen-netback/xenbus.c 
> b/drivers/net/xen-netback/xenbus.c
> index 2625740bdc4a..330ddb64930f 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -655,7 +655,7 @@ static void frontend_changed(struct xenbus_device *dev,
>   set_backend_state(be, XenbusStateClosed);
>   if (xenbus_dev_is_online(dev))
>   break;
> - /* fall through if not online */
> + /* fall through - if not online */
>   case XenbusStateUnknown:

Considering the fall-through was already annotated, I don't think
title and description really justify the change. Is the compiler after
a particular wording here?

Jan

Re: [PATCH 0/2] cpufreq/opp: rework regulator initialization

[Marek Szyprowski]

Hi Viresh,

On 2019-02-11 09:44, Viresh Kumar wrote:
> On 07-02-19, 13:22, Marek Szyprowski wrote:
>> Dear All,
>>
>> Recent commit 9ac6cb5fbb17 ("i2c: add suspended flag and accessors for
>> i2c adapters") added a visible warning for an attempt to do i2c transfer
>> over a suspended i2c bus. This revealed a long standing issue in the
>> cpufreq-dt driver, which gives a following warning during system
>> suspend/resume cycle:
> Marek,
>
> I have sent a patchset which is not directly related to the problem
> you are facing, but it may solve your problem as a side effect. Can
> you please see if that works to solve this issue as well ?
>
> https://lore.kernel.org/lkml/cover.1549874368.git.viresh.ku...@linaro.org/T/#u

Thanks for the patch. It indeed solves the problem of the i2c transfer
in cpu hotplug procedure during system resume, although my resources
management rewrite is still valid as a way to fix remaining 'todos' in
the cpufreq-dt driver.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v2 13/28] thunderbolt: Add helper function to iterate from one port to another

[Mika Westerberg]

On Mon, Feb 11, 2019 at 07:16:00AM +0100, Lukas Wunner wrote:
> On Wed, Feb 06, 2019 at 04:17:23PM +0300, Mika Westerberg wrote:
> > We need to be able to walk from one port to another when we are creating
> > paths where there are multiple switches between two ports. For this
> > reason introduce a new function tb_port_get_next() and a new macro
> > tb_for_each_port().
> 
> These names seem fairly generic, they might as well refer to the next port
> on a switch or iterate over the ports on a switch.  E.g. I've proposed a
> tb_sw_for_each_port() macro in this patch:
> 
> https://lore.kernel.org/patchwork/patch/983863/
> 
> I'd suggest renaming tb_port_get_next() to something like
> tb_next_port_on_path() or tb_path_next_port() or tb_path_walk().

OK, tb_next_port_on_path() sounds good to me.

> And I'd suggest dropping tb_for_each_port() because there are only
> two occurrences where it's used, one calculates the path length,
> and I think that's simply the route string length plus 2, and the
> other one in patch 17 isn't even interested in the ports along a path,
> but rather in the switches between the root switch and the end of a path.
> It seems simpler to just iterate from the switch at the end upwards to
> the root switch by following the parent pointer in the switch's
> struct device, or alternatively by bytewise iterating over the route
> string and calling get_switch_at_route() each time.

OK.

> > +/**
> > + * tb_port_get_next() - Return next port for given port
> > + * @start: Start port of the walk
> > + * @end: End port of the walk
> > + * @prev: Previous port (%NULL if this is the first)
> > + *
> > + * This function can be used to walk from one port to another if they
> > + * are connected through zero or more switches. If the @prev is dual
> > + * link port, the function follows that link and returns another end on
> > + * that same link.
> > + *
> > + * If the walk cannot be continued, returns %NULL.
> 
> This sounds as if NULL is returned if an error occurs but that doesn't
> seem to be what the function does.  I'd suggest:
> 
> "If the @end port has been reached, return %NULL."

It returns NULL if @end cannot be reached. So what about:

  "If @end cannot be reached, returns %NULL"

?

> > +struct tb_port *tb_port_get_next(struct tb_port *start, struct tb_port 
> > *end,
> > +struct tb_port *prev)
> > +{
> > +   struct tb_port *port, *next;
> > +
> > +   if (!prev)
> > +   return start;
> > +
> > +   if (prev->sw == end->sw) {
> > +   if (prev != end)
> > +   return end;
> > +   return NULL;
> > +   }
> > +
> > +   /* Switch back to use primary links for walking */
> 
> "Switch back" requires that you switched to something else before,
> which you didn't.  I'd suggest something like:
> 
> "use primary link to discover next port"

OK.

> Why is it necessary to use the primary link anyway?  Is the
> ->remote member not set on the secondary link port?  The reason
> should probably be spelled out in the code comment.

IIRC it was because you may have something in the middle with only one
port (the primary). I'll add a comment here explaining that.

> > +   if (prev->dual_link_port && prev->link_nr)
> > +   port = prev->dual_link_port;
> > +   else
> > +   port = prev;
> > +
> > +   if (start->sw->config.depth < end->sw->config.depth) {
> > +   if (port->remote &&
> > +   port->remote->sw->config.depth > port->sw->config.depth)
> 
> Can we use "if (!tb_is_upstream_port(port))" for consistency with the
> if-clause below?

Yes, I think that should work.

> > +   next = port->remote;
> > +   else
> > +   next = tb_port_at(tb_route(end->sw), port->sw);
> > +   } else if (start->sw->config.depth > end->sw->config.depth) {
> > +   if (tb_is_upstream_port(port))
> > +   next = port->remote;
> > +   else
> > +   next = tb_upstream_port(port->sw);
> > +   } else {
> > +   /* Must be the same switch then */
> > +   if (start->sw != end->sw)
> > +   return NULL;
> > +   return end;
> > +   }
> 
> The else-clause here appears to be dead code, you've already checked
> further up whether prev and end are on the same switch.

OK.

> > +
> > +   /* If prev was dual link return another end of that link then */
> 
> *Here* a "switch back" comment would be appropriate.  Nit: Please either
> end code comments with a period or don't start them with an upper case
> letter.

That's the style I've been using in this driver and elsewhere and is my
preference anyway.

I'll update the comment content, though. :)

Re: [PATCH 1/2] x86/boot: fix KASL when memmap range manipulation is used

[Julian Stecklina]

Baoquan He  writes:

> On 01/30/19 at 05:40pm, Julian Stecklina wrote:
>> diff --git a/arch/x86/boot/compressed/kaslr.c 
>> b/arch/x86/boot/compressed/kaslr.c
>> index 9ed9709..5657e34 100644
>> --- a/arch/x86/boot/compressed/kaslr.c
>> +++ b/arch/x86/boot/compressed/kaslr.c
>> @@ -155,6 +155,12 @@ parse_memmap(char *p, unsigned long long *start, 
>> unsigned long long *size)
>>  case '#':
>>  case '$':
>>  case '!':
>> +/*
>> + * % would need some more complex parsing, because regions might
>> + * actually become usable for KASLR, but the simple way of
>> + * ignoring anything that is mentioned in % works for now.
>> + */
>
> This seems to make thing more complicated even though have to. One
> concern is whether we need to check the oldtype|newtype , e.g
> oldtype=reserverd, newtype=RAM, is it possible to set like that?

With the above patch the boot code will avoid using any region targeted
by % for KASLR. This does mean regions that are changed to be usable via
% are not taken into account.

Julian

Re: [PATCH 0/2] cpufreq/opp: rework regulator initialization

[Viresh Kumar]

On 11-02-19, 10:52, Marek Szyprowski wrote:
> Hi Viresh,
> 
> On 2019-02-11 09:44, Viresh Kumar wrote:
> > On 07-02-19, 13:22, Marek Szyprowski wrote:
> >> Dear All,
> >>
> >> Recent commit 9ac6cb5fbb17 ("i2c: add suspended flag and accessors for
> >> i2c adapters") added a visible warning for an attempt to do i2c transfer
> >> over a suspended i2c bus. This revealed a long standing issue in the
> >> cpufreq-dt driver, which gives a following warning during system
> >> suspend/resume cycle:
> > Marek,
> >
> > I have sent a patchset which is not directly related to the problem
> > you are facing, but it may solve your problem as a side effect. Can
> > you please see if that works to solve this issue as well ?
> >
> > https://lore.kernel.org/lkml/cover.1549874368.git.viresh.ku...@linaro.org/T/#u
> 
> Thanks for the patch. It indeed solves the problem of the i2c transfer
> in cpu hotplug procedure during system resume, although my resources
> management rewrite is still valid as a way to fix remaining 'todos' in
> the cpufreq-dt driver.

Which remaining todos are you talking about ? Sorry I am not able to
recall :(

-- 
viresh

Re: [tip:x86/boot] x86/boot: Early parse RSDP and save it in boot_params

[Chao Fan]

On Mon, Feb 11, 2019 at 09:46:03AM +, Ard Biesheuvel wrote:
>On Mon, 11 Feb 2019 at 01:22, Borislav Petkov  wrote:
>>
>> On Fri, Feb 08, 2019 at 10:53:22PM +0100, Borislav Petkov wrote:
>> > On Fri, Feb 08, 2019 at 12:44:51PM -0800, Guenter Roeck wrote:
>> > > Yes, the kernel boots if I comment out that function and have it return 
>> > > 0.
>> >
>> > Thanks, this localizes the issue significantly.
>>
>> Some observations:
>>
>> } else {
>> efi_config_table_32_t *tmp_table;
>>
>> tmp_table = config_tables;
>> guid = tmp_table->guid; <--- *
>> table = tmp_table->table;
>> }
>>
>> It blows up at that tmp_table->guid deref above. Singlestepping through
>> it with gdb shows:
>>
>> # arch/x86/boot/compressed/acpi.c:114:  guid = 
>> tmp_table->guid;
>> movq(%rdi), %rax# MEM[(struct efi_config_table_32_t 
>> *)config_tables_37].guid, guid
>> movq8(%rdi), %rsi   # MEM[(struct efi_config_table_32_t 
>> *)config_tables_37].guid, guid
>> # arch/x86/boot/compressed/acpi.c:115:  table = 
>> tmp_table->table;
>> movl16(%rdi), %r10d # MEM[(struct efi_config_table_32_t 
>> *)config_tables_37].table, table
>> jmp .L30#
>>
>> and %rdi has:
>>
>> rdi0x630646870
>>
>> which is an address above 4G but we're using a 32-bit EFI BIOS.
>>
>> Which begs the question whether EFI system tables can even be mapped at
>> something above 4G with a 32-bit EFI and whether that could work ok.
>> Hmm.
>>
>> Lemme add Ard and mfleming for insight here.
>>
>
>-ENOCONTEXT, but let me try in any case:
>
>linux/efi.h has
>
>typedef struct {
>  efi_guid_t guid;
>  u32 table;
>} efi_config_table_32_t;
>
>so if we end up with more than 32 bits set in table, there is
>something seriously wrong.
>
>The size of efi_config_table_32_t deviates from efi_config_table_64_t,
>so you will have to ensure that you are using the correct stride when
>iterating over config_tables.

Here I use signature to judge it.
If the signature is EFI64_LOADER_SIGNATURE, I will use efi_config_table_64_t,
if the signature is EFI32_LOADER_SIGNATURE, I will use efi_config_table_32_t.
But the efi32 whose signature is EFI32_LOADER_SIGNATURE points to a
address above 4G, I am not sure whether this is normal and works well.

Thanks,
Chao Fan

>
>

Re: [tip:x86/boot] x86/boot: Early parse RSDP and save it in boot_params

[Ard Biesheuvel]

On Mon, 11 Feb 2019 at 10:56, Chao Fan  wrote:
>
> On Mon, Feb 11, 2019 at 09:46:03AM +, Ard Biesheuvel wrote:
> >On Mon, 11 Feb 2019 at 01:22, Borislav Petkov  wrote:
> >>
> >> On Fri, Feb 08, 2019 at 10:53:22PM +0100, Borislav Petkov wrote:
> >> > On Fri, Feb 08, 2019 at 12:44:51PM -0800, Guenter Roeck wrote:
> >> > > Yes, the kernel boots if I comment out that function and have it 
> >> > > return 0.
> >> >
> >> > Thanks, this localizes the issue significantly.
> >>
> >> Some observations:
> >>
> >> } else {
> >> efi_config_table_32_t *tmp_table;
> >>
> >> tmp_table = config_tables;
> >> guid = tmp_table->guid; <--- *
> >> table = tmp_table->table;
> >> }
> >>
> >> It blows up at that tmp_table->guid deref above. Singlestepping through
> >> it with gdb shows:
> >>
> >> # arch/x86/boot/compressed/acpi.c:114:  guid = 
> >> tmp_table->guid;
> >> movq(%rdi), %rax# MEM[(struct efi_config_table_32_t 
> >> *)config_tables_37].guid, guid
> >> movq8(%rdi), %rsi   # MEM[(struct efi_config_table_32_t 
> >> *)config_tables_37].guid, guid
> >> # arch/x86/boot/compressed/acpi.c:115:  table = 
> >> tmp_table->table;
> >> movl16(%rdi), %r10d # MEM[(struct efi_config_table_32_t 
> >> *)config_tables_37].table, table
> >> jmp .L30#
> >>
> >> and %rdi has:
> >>
> >> rdi0x630646870
> >>
> >> which is an address above 4G but we're using a 32-bit EFI BIOS.
> >>
> >> Which begs the question whether EFI system tables can even be mapped at
> >> something above 4G with a 32-bit EFI and whether that could work ok.
> >> Hmm.
> >>
> >> Lemme add Ard and mfleming for insight here.
> >>
> >
> >-ENOCONTEXT, but let me try in any case:
> >
> >linux/efi.h has
> >
> >typedef struct {
> >  efi_guid_t guid;
> >  u32 table;
> >} efi_config_table_32_t;
> >
> >so if we end up with more than 32 bits set in table, there is
> >something seriously wrong.
> >
> >The size of efi_config_table_32_t deviates from efi_config_table_64_t,
> >so you will have to ensure that you are using the correct stride when
> >iterating over config_tables.
>
> Here I use signature to judge it.
> If the signature is EFI64_LOADER_SIGNATURE, I will use efi_config_table_64_t,
> if the signature is EFI32_LOADER_SIGNATURE, I will use efi_config_table_32_t.
> But the efi32 whose signature is EFI32_LOADER_SIGNATURE points to a
> address above 4G, I am not sure whether this is normal and works well.
>

This is impossible. The 'table' member of efi_config_table_32_t is
only 32 bits wide, so how can it contain an address over 4 GB ?

Re: [PATCH] x86/alternatives: check int3 breakpoint physical addresses

[Alexandre Chartre]

On 02/11/2019 10:15 AM, Thomas Gleixner wrote:

On Mon, 11 Feb 2019, Alexandre Chartre wrote:

On 02/10/2019 10:23 PM, Thomas Gleixner wrote:

On Fri, 25 Jan 2019, Alexandre Chartre wrote:

Note that this issue has been observed and reproduced with a custom kernel
with some code mapped to different virtual addresses and using jump labels
As jump labels use text_poke_bp(), crashes were sometimes observed when
updating jump labels.


Rightfully so. text_poke_bp() pokes at the kernels text mapping which is
very well defined and unique. Why would you map the same text to different
virtual addresses and then use a randomly chosen one to poke at it?



As an example, we used to have per-CPU SYSCALL entry trampoline [1] where the
entry_SYSCALL_64_trampoline function was mapped to a different virtual address
for each CPU. So, a syscall would execute entry_SYSCALL_64_trampoline() from a
different virtual address depending on the CPU being used. With that code,
adding a jump label in entry_SYSCALL_64_trampoline() causes the described
issue.


Right, but we knew that and there was no reason to put a jump label into
that. AFAICT we don't have anything like this in the kernel.


In our particular case, we have introduced a jump label in JMP_NOSPEC (which
is used by entry_SYSCALL_64_trampoline()) to have the option to dynamically
enable/disable retpoline at runtime. So that's when we faced this issue.


That said, I'm not opposed to apply the patch as is, I just wanted to get a
better understanding about the background.


Sure. I am aware this is a corner case, and I was precisely looking for feedback
to check if it is worth fixing that issue. So I appreciate your reply, and I 
would
understand if the patch is rejected because that's a case that we are just not
expecting to happen.

Thanks,

alex.

RE: [PATCH v2 6/9] usb: roles: Find the muxes by also matching against the device node

[Jun Li]

Hi Heikki,

> @@ -84,7 +85,12 @@ enum usb_role usb_role_switch_get_role(struct
> usb_role_switch *sw)  }  EXPORT_SYMBOL_GPL(usb_role_switch_get_role);
> 
> -static int __switch_match(struct device *dev, const void *name)
> +static int switch_fwnode_match(struct device *dev, const void *fwnode)
> +{
> + return dev_fwnode(dev) == fwnode;

You missed the comment
https://lkml.org/lkml/2019/1/22/437

return dev_fwnode(dev->parent) == fwnode;

Jun

Re: [PATCH v4 1/4] gpu: ipu-v3: ipu-ic: Rename yuv2rgb encoding matrices

[Philipp Zabel]

On Fri, 2019-02-08 at 17:47 -0800, Steve Longerbeam wrote:
> The ycbcr2rgb and inverse rgb2ycbcr matrices define the BT.601 encoding
> coefficients, so rename them to indicate that. And add some comments
> to make clear these are BT.601 coefficients encoding between YUV limited
> range and RGB full range. The ic_csc_rgb2rgb matrix is just an identity
> matrix, so rename to ic_csc_identity. No functional changes.
> 
> Signed-off-by: Steve Longerbeam 
> ---
> Changes in v2:
> - rename ic_csc_rgb2rgb matrix to ic_csc_identity.
> ---
>  drivers/gpu/ipu-v3/ipu-ic.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
> index 594c3cbc8291..3ef61f0b509b 100644
> --- a/drivers/gpu/ipu-v3/ipu-ic.c
> +++ b/drivers/gpu/ipu-v3/ipu-ic.c
> @@ -183,11 +183,13 @@ struct ic_csc_params {
>  };
>  
>  /*
> + * BT.601 encoding from RGB full range to YUV limited range:
> + *
>   * Y = R *  .299 + G *  .587 + B *  .114;
>   * U = R * -.169 + G * -.332 + B *  .500 + 128.;
>   * V = R *  .500 + G * -.419 + B * -.0813 + 128.;

Hm, this is a conversion to full range BT.601. For limited range, the
matrix coefficients

   0.2990  0.5870  0.1140
  -0.1687 -0.3313  0.5000
   0.5000 -0.4187 -0.0813

should be multiplied with 219/255 (Y) and 224/255 (U,V), respectively:

  Y = R *  .2568 + G *  .5041 + B *  .0979 + 16;
  U = R * -.1482 + G * -.2910 + B *  .4392 + 128;
  V = R *  .4392 + G * -.3678 + B * -.0714 + 128;

>   */
> -static const struct ic_csc_params ic_csc_rgb2ycbcr = {
> +static const struct ic_csc_params ic_csc_rgb2ycbcr_bt601 = {
>   .coeff = {
>   { 77, 150, 29 },
>   { 469, 427, 128 },
> @@ -197,8 +199,11 @@ static const struct ic_csc_params ic_csc_rgb2ycbcr = {
>   .scale = 1,
>  };
>  
> -/* transparent RGB->RGB matrix for graphics combining */
> -static const struct ic_csc_params ic_csc_rgb2rgb = {
> +/*
> + * identity matrix, used for transparent RGB->RGB graphics
> + * combining.
> + */
> +static const struct ic_csc_params ic_csc_identity = {
>   .coeff = {
>   { 128, 0, 0 },
>   { 0, 128, 0 },
> @@ -208,11 +213,13 @@ static const struct ic_csc_params ic_csc_rgb2rgb = {
>  };
>  
>  /*
> + * Inverse BT.601 encoding from YUV limited range to RGB full range:
> + *
>   * R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));
>   * G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));
>   * B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128);
>   */

This looks correct.

> -static const struct ic_csc_params ic_csc_ycbcr2rgb = {
> +static const struct ic_csc_params ic_csc_ycbcr2rgb_bt601 = {
>   .coeff = {
>   { 149, 0, 204 },
>   { 149, 462, 408 },
> @@ -238,11 +245,11 @@ static int init_csc(struct ipu_ic *ic,
>   (priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
>  
>   if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
> - params = &ic_csc_ycbcr2rgb;
> + params = &ic_csc_ycbcr2rgb_bt601;
>   else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
> - params = &ic_csc_rgb2ycbcr;
> + params = &ic_csc_rgb2ycbcr_bt601;
>   else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_RGB)
> - params = &ic_csc_rgb2rgb;
> + params = &ic_csc_identity;
>   else {
>   dev_err(priv->ipu->dev, "Unsupported color space conversion\n");
>   return -EINVAL;

regards
Philipp

Re: [PATCH v4 2/4] gpu: ipu-v3: ipu-ic: Simplify selection of encoding matrix

[Philipp Zabel]

On Fri, 2019-02-08 at 17:47 -0800, Steve Longerbeam wrote:
> Simplify the selection of the Y'CbCr encoding matrices in init_csc().
> A side-effect of this change is that init_csc() now allows YUV->YUV
> using the identity matrix, intead of returning error.
> 
> Signed-off-by: Steve Longerbeam 

Note that this only works if both YUV encodings have the same range.

regards
Philipp

Re: [PATCH] drivers: devfreq: change devfreq workqueue mechanism

[Lukasz Luba]

Hi Matthias,

My apologize for late response, I did not have access to mailbox.
Thank you for review, please check the comments below.

On 2/5/19 1:39 AM, Matthias Kaehlcke wrote:
> Hi Lukasz,
> 
> On Fri, Feb 01, 2019 at 07:38:03PM +0100, Lukasz Luba wrote:
>> This patch removes devfreq's custom workqueue and uses system one.
>> It switches from queue_delayed_work() to schedule_delayed_work().
>> It also changes deferred work to delayed work, which is now not missed
>> when timer is put on CPU that entered idle state.
>> The devfreq framework governor was not called, thus changing the frequency
>> of the device did not happen.
>> Benchmarks for stressing Dynamic Memory Controller show x2
>> performance boost with this patch when 'simpleondemand_governor' is
>> responsible for monitoring the device load and frequency changes.
>> With this patch, the scheduled delayed work is done no mater CPUs' idle.
>> It also does not wake up the system when it enters suspend (this
>> functionality stays the same).
>> All of the drivers in devfreq which rely on periodic, guaranteed wakeup
>> intervals should benefit from it.
>>
>> Signed-off-by: Lukasz Luba 
>> ---
>>   drivers/devfreq/devfreq.c | 27 +++
>>   1 file changed, 7 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index 0ae3de7..c200b3c 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -31,13 +31,6 @@
>>   
>>   static struct class *devfreq_class;
>>   
>> -/*
>> - * devfreq core provides delayed work based load monitoring helper
>> - * functions. Governors can use these or can implement their own
>> - * monitoring mechanism.
>> - */
>> -static struct workqueue_struct *devfreq_wq;
>> -
>>   /* The list of all device-devfreq governors */
>>   static LIST_HEAD(devfreq_governor_list);
>>   /* The list of all device-devfreq */
>> @@ -391,8 +384,8 @@ static void devfreq_monitor(struct work_struct *work)
>>  if (err)
>>  dev_err(&devfreq->dev, "dvfs failed with (%d) error\n", err);
>>   
>> -queue_delayed_work(devfreq_wq, &devfreq->work,
>> -msecs_to_jiffies(devfreq->profile->polling_ms));
>> +schedule_delayed_work(&devfreq->work,
>> +  msecs_to_jiffies(devfreq->profile->polling_ms));
>>  mutex_unlock(&devfreq->lock);
>>   }
>>   
>> @@ -407,9 +400,9 @@ static void devfreq_monitor(struct work_struct *work)
>>*/
>>   void devfreq_monitor_start(struct devfreq *devfreq)
>>   {
>> -INIT_DEFERRABLE_WORK(&devfreq->work, devfreq_monitor);
>> +INIT_DELAYED_WORK(&devfreq->work, devfreq_monitor);
>>  if (devfreq->profile->polling_ms)
>> -queue_delayed_work(devfreq_wq, &devfreq->work,
>> +schedule_delayed_work(&devfreq->work,
>>  msecs_to_jiffies(devfreq->profile->polling_ms));
>>   }
>>   EXPORT_SYMBOL(devfreq_monitor_start);
>> @@ -473,7 +466,7 @@ void devfreq_monitor_resume(struct devfreq *devfreq)
>>   
>>  if (!delayed_work_pending(&devfreq->work) &&
>>  devfreq->profile->polling_ms)
>> -queue_delayed_work(devfreq_wq, &devfreq->work,
>> +schedule_delayed_work(&devfreq->work,
>>  msecs_to_jiffies(devfreq->profile->polling_ms));
>>   
>>  devfreq->last_stat_updated = jiffies;
>> @@ -516,7 +509,7 @@ void devfreq_interval_update(struct devfreq *devfreq, 
>> unsigned int *delay)
>>   
>>  /* if current delay is zero, start polling with new delay */
>>  if (!cur_delay) {
>> -queue_delayed_work(devfreq_wq, &devfreq->work,
>> +schedule_delayed_work(&devfreq->work,
>>  msecs_to_jiffies(devfreq->profile->polling_ms));
>>  goto out;
>>  }
>> @@ -527,7 +520,7 @@ void devfreq_interval_update(struct devfreq *devfreq, 
>> unsigned int *delay)
>>  cancel_delayed_work_sync(&devfreq->work);
>>  mutex_lock(&devfreq->lock);
>>  if (!devfreq->stop_polling)
>> -queue_delayed_work(devfreq_wq, &devfreq->work,
>> +schedule_delayed_work(&devfreq->work,
>>msecs_to_jiffies(devfreq->profile->polling_ms));
>>  }
>>   out:
>> @@ -1430,12 +1423,6 @@ static int __init devfreq_init(void)
>>  return PTR_ERR(devfreq_class);
>>  }
>>   
>> -devfreq_wq = create_freezable_workqueue("devfreq_wq");
>> -if (!devfreq_wq) {
>> -class_destroy(devfreq_class);
>> -pr_err("%s: couldn't create workqueue\n", __FILE__);
>> -return -ENOMEM;
>> -}
>>  devfreq_class->dev_groups = devfreq_groups;
>>   
>>  return 0;
> 
> If I understand correctly this changes three things:
> 
> 1. use system workqueue instead of custom one
> 
> should be fine with the cwmq's we have nowadays
> 
> 
> 2. use non-freezable workqueue
> 
>``WQ_FREEZABLE``
>  A freezable wq pa

[PATCH] perf report: Add s390 diagnosic sampling descriptor size

[Thomas Richter]

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

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

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

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

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

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

Signed-off-by: Thomas Richter 
Reviewed-by: Hendrik Brueckner 
---
 tools/perf/util/s390-cpumsf.c | 5 +
 1 file changed, 5 insertions(+)

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

Re: [tip:x86/boot] x86/boot: Early parse RSDP and save it in boot_params

[Borislav Petkov]

On Mon, Feb 11, 2019 at 05:30:33PM +0800, Chao Fan wrote:
> Yes, I download your ovmf file in linux-build-test/rootfs/firmware/ from
> your link. There are two files, efi32 and efi64. Then I try to run:

You need both OVMF-pure-efi-32.fd and rootfs.squashfs from the repo. And
then this works here. Just put the script below and the two files in a
directory and point to the kernel where you're building with -kernel.

---
#!/bin/bash

qemu-system-x86_64 -kernel ~/kernel/linux/arch/x86/boot/bzImage -M q35 -cpu 
SandyBridge \
-no-reboot -snapshot -smp 1 \
-gdb tcp::1235 \
-bios OVMF-pure-efi-32.fd \
-m 1G \
-net nic,model=rtl8139,macaddr=12:34:56:78:12:34 \
-usb -device usb-storage,drive=d0 \
-drive file=rootfs.squashfs,if=none,id=d0,format=raw \
--append 'earlycon=uart8250,io,0x3f8,9600n8 root=/dev/sda rootwait 
panic=-1 earlyprintk=ttyS0,115200,keep console=ttyS0,115200' \
-monitor pty \
-serial file:log

I've added some options for debugging.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)