Re: [RFC PATCH v2 4/4] mm,memory_hotplug: Enable MHP_MEMMAP_ON_MEMORY when supported

[Oscar Salvador]

On Wed, Nov 25, 2020 at 12:20:48PM +0100, Oscar Salvador wrote:
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index b02fd51e5589..1fe645ef0b6c 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -172,6 +172,7 @@ static int acpi_memory_enable_device(struct 
> acpi_memory_device *mem_device)
>   int result, num_enabled = 0;
>   struct acpi_memory_info *info;
>   int node;
> + mhp_t mhp_flags = MHP_NONE;
>  
>   node = acpi_get_node(handle);
>   /*
> @@ -194,8 +195,10 @@ static int acpi_memory_enable_device(struct 
> acpi_memory_device *mem_device)
>   if (node < 0)
>   node = memory_add_physaddr_to_nid(info->start_addr);
>  
> + if (mhp_supports_memmap_on_memory(info->length))
> + mhp_flags |= MHP_MEMMAP_ON_MEMORY;
>   result = __add_memory(node, info->start_addr, info->length,
> -   MHP_NONE);
> +   mhp_flags);
>  
>   /*
>* If the memory block has been used by the kernel, add_memory()

I fortot the following chunk:

diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c 
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 7efe6ec5d14a..3aba817e729e 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -612,6 +612,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
 {
unsigned long block_sz;
int nid, rc;
+   mhp_t mhp_flags = MHP_NONE;
 
if (lmb->flags & DRCONF_MEM_ASSIGNED)
return -EINVAL;
@@ -629,8 +630,10 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
if (nid < 0 || !node_possible(nid))
nid = first_online_node;
 
+   if (mhp_supports_memmap_on_memory(block_sz))
+   mhp_flags |= MHP_MEMMAP_ON_MEMORY;
/* Add the memory */
-   rc = __add_memory(nid, lmb->base_addr, block_sz, MHP_NONE);
+   rc = __add_memory(nid, lmb->base_addr, block_sz, mhp_flags);
if (rc) {
invalidate_lmb_associativity_index(lmb);
return rc;

I will add it for the next spin once I get more feedback. 

-- 
Oscar Salvador
SUSE L3

Re: [PATCH 1/2] KVM: x86: handle !lapic_in_kernel case in kvm_cpu_*_extint

[David Woodhouse]

On Fri, 2020-11-27 at 06:21 -0500, Paolo Bonzini wrote:
> +* FIXME: interrupt.injected represents an interrupt that it's

You can drop the stray apostrophe from that "its" while you're moving
it...



smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v8 3/3] PCI: uniphier: Add misc interrupt handler to invoke PME and AER

[Kunihiko Hayashi]

Hi Bjorn Lorenzo,

On 2020/11/25 19:23, Lorenzo Pieralisi wrote:

On Tue, Nov 24, 2020 at 05:20:37PM -0600, Bjorn Helgaas wrote:

On Wed, Oct 28, 2020 at 10:31:43AM +0900, Kunihiko Hayashi wrote:

This patch adds misc interrupt handler to detect and invoke PME/AER event.

In UniPhier PCIe controller, PME/AER signals are assigned to the same
signal as MSI by the internal logic. These signals should be detected by
the internal register, however, DWC MSI handler can't handle these signals.


I don't know what "PME/AER signals are assigned to the same signal as
MSI" means.


The host controller embeds an interrupt-controller whose IRQ wire output
is cascaded into the main interrupt controller.

The host-bridge embedded controller receives MSI writes from devices
and it turns them into an edge IRQ into the main interrupt controller.

To ack/mask the MSIs at host contoller interrupt controller level, there
is a control register in the host controller that needs handling upon
IRQ reception.


Thanks for explaining that.
In my understanding, PME/AER signals are cascaded to MSI by embedded
interrupt controller (not "assigned").



The *RP* (and AFAIU the RP *only*) signals the PME/AER MSI using the
same wire to the main interrupt controller but its ack/mask is handled
by a different bit in the host bridge control register above, therefore
the cascaded IRQ isr needs to know which virq it is actually handling
to ack/mask accordingly.


Sorry what is RP? Root complex or something?



IMO this should be modelled with a separate IRQ domain and chip for
the root port (yes this implies describing the root port in the dts
file with a separate msi-parent).

This series as it stands is a kludge.


I see. However I need some time to consider the way to separate IRQ domain.
Is there any idea or example to handle PME/AER with IRQ domain?



I'm trying to figure out if this is talking about PME/AER MSI vector
numbers (probably not) or some internal wire that's not
architecturally visible or what.

Probably also not related to the fact that PME, hotplug, and bandwidth
notifications share the same MSI/MSI-X vector.

Is this something that's going to be applicable to all the DWC-based
drivers?


I think that this feature depends on the vendor specification.
At least, the registers to control or check these signals are implemented
in the vendor's logic.



DWC MSI handler calls .msi_host_isr() callback function, that detects
PME/AER signals with the internal register and invokes the interrupt
with PME/AER vIRQ numbers.

These vIRQ numbers is obtained from portdrv in uniphier_add_pcie_port()
function.

Cc: Marc Zyngier 
Cc: Jingoo Han 
Cc: Gustavo Pimentel 
Cc: Lorenzo Pieralisi 
Signed-off-by: Kunihiko Hayashi 
Reviewed-by: Rob Herring 
---
  drivers/pci/controller/dwc/pcie-uniphier.c | 77 +-
  1 file changed, 66 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c 
b/drivers/pci/controller/dwc/pcie-uniphier.c
index 4817626..237537a 100644
--- a/drivers/pci/controller/dwc/pcie-uniphier.c
+++ b/drivers/pci/controller/dwc/pcie-uniphier.c
@@ -21,6 +21,7 @@
  #include 
  
  #include "pcie-designware.h"

+#include "../../pcie/portdrv.h"
  
  #define PCL_PINCTRL0			0x002c

  #define PCL_PERST_PLDN_REGEN  BIT(12)
@@ -44,7 +45,9 @@
  #define PCL_SYS_AUX_PWR_DET   BIT(8)
  
  #define PCL_RCV_INT			0x8108

+#define PCL_RCV_INT_ALL_INT_MASK   GENMASK(28, 25)
  #define PCL_RCV_INT_ALL_ENABLEGENMASK(20, 17)
+#define PCL_RCV_INT_ALL_MSI_MASK   GENMASK(12, 9)
  #define PCL_CFG_BW_MGT_STATUS BIT(4)
  #define PCL_CFG_LINK_AUTO_BW_STATUS   BIT(3)
  #define PCL_CFG_AER_RC_ERR_MSI_STATUS BIT(2)
@@ -68,6 +71,8 @@ struct uniphier_pcie_priv {
struct reset_control *rst;
struct phy *phy;
struct irq_domain *legacy_irq_domain;
+   int aer_irq;
+   int pme_irq;
  };
  
  #define to_uniphier_pcie(x)	dev_get_drvdata((x)->dev)

@@ -167,7 +172,15 @@ static void uniphier_pcie_stop_link(struct dw_pcie *pci)
  
  static void uniphier_pcie_irq_enable(struct uniphier_pcie_priv *priv)

  {
-   writel(PCL_RCV_INT_ALL_ENABLE, priv->base + PCL_RCV_INT);
+   u32 val;
+
+   val = PCL_RCV_INT_ALL_ENABLE;
+   if (pci_msi_enabled())
+   val |= PCL_RCV_INT_ALL_INT_MASK;
+   else
+   val |= PCL_RCV_INT_ALL_MSI_MASK;


I'm confused about how this works.  Root Ports can signal AER errors
with either INTx or MSI.  This is controlled by the architected
Interrupt Disable bit and the MSI/MSI-X enable bits (I'm looking at
PCIe r5.0, sec 6.2.4.1.2).

The code here doesn't look related to those bits.  Does this code mean
that if pci_msi_enabled(), the Root Port will always signal with MSI
(if MSI Enable is set) and will *never* signal with INTx?


According to the spec sheet, we need to set interrupt enable bit for either
INTx or MSI, the other bit should be reset. These bits are in config space
and 

Re: [PATCH] mm: memory_hotplug: put migration failure information under DEBUG_VM

[Michal Hocko]

On Fri 27-11-20 15:53:14, Charan Teja Kalla wrote:
> Thanks Michal!!
> 
> On 11/26/2020 2:48 PM, Michal Hocko wrote:
> > On Wed 25-11-20 16:18:06, Charan Teja Kalla wrote:
> >>
> >>
> >> On 11/24/2020 1:11 PM, Michal Hocko wrote:
> >>> On Mon 23-11-20 20:40:40, Charan Teja Kalla wrote:
> 
>  Thanks Michal!
>  On 11/23/2020 7:43 PM, Michal Hocko wrote:
> > On Mon 23-11-20 19:33:16, Charan Teja Reddy wrote:
> >> When the pages are failed to get isolate or migrate, the page owner
> >> information along with page info is dumped. If there are continuous
> >> failures in migration(say page is pinned) or isolation, the log buffer
> >> is simply getting flooded with the page owner information. As most of
> >> the times page info is sufficient to know the causes for failures of
> >> migration or isolation, place the page owner information under 
> >> DEBUG_VM.
> >
> > I do not see why this path is any different from others that call
> > dump_page. Page owner can add a very valuable information to debug
> > the underlying reasons for failures here. It is an opt-in debugging
> > feature which needs to be enabled explicitly. So I would argue users
> > are ready to accept a lot of data in the kernel log.
> 
>  Just thinking how frequently failures can happen in those paths. In the
>  memory hotplug path, we can flood the page owner logs just by making one
>  page pinned.
> >>>
> >>> If you are operating on a movable zone then pages shouldn't be pinned
> >>> for unbound amount of time. Yeah there are some ways to break this
> >>> fundamental assumption but this is a bigger problem that needs a
> >>> solution.
> >>>
>  Say If it is anonymous page, the page owner information
>  shows is something like below, which is not really telling anything
>  other than how the pinned page is allocated.
> >>>
> >>> Well you can tell an anonymous page from __dump_page, all right, but
> >>> this is not true universally.
> >>>
>  page last allocated via order 0, migratetype Movable, gfp_mask
>  0x100dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO)
>    prep_new_page+0x7c/0x1a4
>    get_page_from_freelist+0x1ac/0x1c4
>    __alloc_pages_nodemask+0x12c/0x378
>    do_anonymous_page+0xac/0x3b4
>    handle_pte_fault+0x2a4/0x3bc
>    __handle_speculative_fault+0x208/0x3c0
>    do_page_fault+0x280/0x508
>    do_translation_fault+0x3c/0x54
>    do_mem_abort+0x64/0xf4
>    el0_da+0x1c/0x20
>   page last free stack trace:
>    free_pcp_prepare+0x320/0x454
>    free_unref_page_list+0x9c/0x2a4
>    release_pages+0x370/0x3c8
>    free_pages_and_swap_cache+0xdc/0x10c
>    tlb_flush_mmu+0x110/0x134
>    tlb_finish_mmu+0x48/0xc0
>    unmap_region+0x104/0x138
>    __do_munmap+0x2ec/0x3b4
>    __arm64_sys_munmap+0x80/0xd8
> 
>  I see at some places in the kernel where they put the dump_page under
>  DEBUG_VM, but in the end I agree that it is up to the users need. Then
>  there are some users who don't care for these page owner logs.
> >>>
> >>> Well, as I've said page_owner requires an explicit enabling and I would
> >>> expect that if somebody enables this tracking then it is expected to see
> >>> the information when we dump a page state.
> >>>
>  And an issue on Embedded systems with these continuous logs being
>  printed to the console is the watchdog timeouts, because console logging
>  happens by disabling the interrupts.
> >>>
> >>> Are you enabling page_owner on those systems unconditionally?
> >>>
> >>
> >> Yes, We do always enable the page owner on just the internal debug
> >> builds for memory analysis, But never on the production kernels. And on
> >> these builds excessive logging, at times because of a pinned page,
> >> causing the watchdog timeouts, is the problem.
> > 
> > OK, I see but I still believe that the debugging might be useful
> > especially when the owner is not really obvious from the page state.
> > I also agree that if the output is swapping the logs then the situation
> > is not really great either. Would something like the below work for your
> > situation?
> > 
> > MAGIC_NUMBER would need to be somehow figured but I would start with 10
> > or so. 
> > 
> > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> > index b44d4c7ba73b..3da5c434fb77 100644
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -1299,6 +1299,8 @@ do_migrate_range(unsigned long start_pfn, unsigned 
> > long end_pfn)
> > LIST_HEAD(source);
> >  
> > for (pfn = start_pfn; pfn < end_pfn; pfn++) {
> > +   int dumped_page = MAGIC_NUMBER;
> > +
> > if (!pfn_valid(pfn))
> > continue;
> > page = pfn_to_page(pfn);
> > @@ -1344,7 +1346,10 @@ do_migrate_range(unsigned long start_pfn, unsigned 
> > long end_pfn)
> >  
> > } else {
> > pr_warn("failed to 

Re: [PATCH v2 1/4] iio: adc: ad7887: convert dual-channel mode to DT/ACPI

[Alexandru Ardelean]

On Sat, Nov 21, 2020 at 5:38 PM Jonathan Cameron  wrote:
>
> On Thu, 19 Nov 2020 12:07:45 +0200
> Alexandru Ardelean  wrote:
>
> > This change converts the configuration of the dual-channel mode from the
> > old platform-data, to the device_property_present() function, which
> > supports both device-tree and ACPI configuration setups.
> >
> > With this change the old platform_data include of the driver can be
> > removed.
> >
> > Signed-off-by: Alexandru Ardelean 
>
> Hi Alexandru,
>
> The set looks good in general, but there is a an oddity in the driver.
> If we don't provide the vref regulator, then the scale is set to reflect
> the internal 2.5V reference.  Fiven the external reference only
> works by overdriving the 2.5V (must be higher than that to have
> an effect) I guess we could in theory clamp it to a minimum of
> 2.5V but anyone wiring up less than that would have built a crazy board
> so we can probably ignore it.
>
> However, as I read the datasheet in dual channel mode it should be set
> to VDD not 2.5V.  Right now you could make it work in a DT file
> by setting VREF==VDD regulator but that's inelegant.
>
> If you agree with my logic, perhaps a follow up patch?

I haven't managed to get around to this one.
Will try next week.


>
> Jonathan
>
>
> > ---
> >
> > I'm wondering if this changeset is what was in mind here:
> >  
> > https://lore.kernel.org/linux-iio/CA+U=DsqF5tu8Be9KXeyCWD2uHvV688Nc3n=z_xi2j6h6dfj...@mail.gmail.com/T/#mbe72e4da3acea3899d0d35402ea81e52a9bc34e6
> > This driver could have been simplified/reduced a whole lot more, but I'm
> > not sure about it. It's a bit of patch-noise, and later
> >
> > Changelog v1 -> v2:
> > * dropped patch 'iio: adc: ad7887: convert driver to full DT probing'
> >   not adding the device_get_match_data() logic anymore
> > * added patch 'iio: adc: ad7887: remove matching code from driver'
> >   hooking the chip info directly to AD7887
> > * added patch 'iio: adc: ad7887: add OF match table'
> >   this just adds an OF table for DT and ACPI
> >
> >  drivers/iio/adc/ad7887.c | 10 +-
> >  include/linux/platform_data/ad7887.h | 21 -
> >  2 files changed, 5 insertions(+), 26 deletions(-)
> >  delete mode 100644 include/linux/platform_data/ad7887.h
> >
> > diff --git a/drivers/iio/adc/ad7887.c b/drivers/iio/adc/ad7887.c
> > index 4f6f0e0e03ee..06f684c053a0 100644
> > --- a/drivers/iio/adc/ad7887.c
> > +++ b/drivers/iio/adc/ad7887.c
> > @@ -23,8 +23,6 @@
> >  #include 
> >  #include 
> >
> > -#include 
> > -
> >  #define AD7887_REF_DIS   BIT(5)  /* on-chip reference disable 
> > */
> >  #define AD7887_DUAL  BIT(4)  /* dual-channel mode */
> >  #define AD7887_CH_AIN1   BIT(3)  /* convert on channel 1, 
> > DUAL=1 */
> > @@ -241,9 +239,9 @@ static void ad7887_reg_disable(void *data)
> >
> >  static int ad7887_probe(struct spi_device *spi)
> >  {
> > - struct ad7887_platform_data *pdata = spi->dev.platform_data;
> >   struct ad7887_state *st;
> >   struct iio_dev *indio_dev;
> > + bool dual_mode;
> >   uint8_t mode;
> >   int ret;
> >
> > @@ -286,7 +284,9 @@ static int ad7887_probe(struct spi_device *spi)
> >   mode = AD7887_PM_MODE4;
> >   if (!st->reg)
> >   mode |= AD7887_REF_DIS;
> > - if (pdata && pdata->en_dual)
> > +
> > + dual_mode = device_property_present(>dev, 
> > "adi,dual-channel-mode");
> > + if (dual_mode)
> >   mode |= AD7887_DUAL;
> >
> >   st->tx_cmd_buf[0] = AD7887_CH_AIN0 | mode;
> > @@ -298,7 +298,7 @@ static int ad7887_probe(struct spi_device *spi)
> >   spi_message_init(>msg[AD7887_CH0]);
> >   spi_message_add_tail(>xfer[0], >msg[AD7887_CH0]);
> >
> > - if (pdata && pdata->en_dual) {
> > + if (dual_mode) {
> >   st->tx_cmd_buf[2] = AD7887_CH_AIN1 | mode;
> >
> >   st->xfer[1].rx_buf = >data[0];
> > diff --git a/include/linux/platform_data/ad7887.h 
> > b/include/linux/platform_data/ad7887.h
> > deleted file mode 100644
> > index 9b4dca6ae70b..
> > --- a/include/linux/platform_data/ad7887.h
> > +++ /dev/null
> > @@ -1,21 +0,0 @@
> > -/* SPDX-License-Identifier: GPL-2.0-or-later */
> > -/*
> > - * AD7887 SPI ADC driver
> > - *
> > - * Copyright 2010 Analog Devices Inc.
> > - */
> > -#ifndef IIO_ADC_AD7887_H_
> > -#define IIO_ADC_AD7887_H_
> > -
> > -/**
> > - * struct ad7887_platform_data - AD7887 ADC driver platform data
> > - * @en_dual: Whether to use dual channel mode. If set to true AIN1 becomes 
> > the
> > - *   second input channel, and Vref is internally connected to Vdd. If set 
> > to
> > - *   false the device is used in single channel mode and AIN1/Vref is used 
> > as
> > - *   VREF input.
> > - */
> > -struct ad7887_platform_data {
> > - bool en_dual;
> > -};
> > -
> > -#endif /* IIO_ADC_AD7887_H_ */
>

Re: [PATCH v3] drivers/perf: Add support for ARMv8.3-SPE

[Suzuki K Poulose]

On 11/27/20 6:03 AM, Wei Li wrote:

Armv8.3 extends the SPE by adding:
- Alignment field in the Events packet, and filtering on this event
   using PMSEVFR_EL1.
- Support for the Scalable Vector Extension (SVE).

The main additions for SVE are:
- Recording the vector length for SVE operations in the Operation Type
   packet. It is not possible to filter on vector length.
- Incomplete predicate and empty predicate fields in the Events packet,
   and filtering on these events using PMSEVFR_EL1.

Update the check of pmsevfr for empty/partial predicated SVE and
alignment event in SPE driver. For adaption by the version of SPE,
expose 'pmsver' as cap attribute to userspace.

Signed-off-by: Wei Li 


nit: Do we need to update the Kconfig help text too ? Right now that says :

--


tristate "Enable support for the ARMv8.2 Statistical Profiling Extension""


help
  Enable perf support for the ARMv8.2 Statistical Profiling
  Extension, which provides periodic sampling of operations in

--

Suzuki

Re: [PATCH] random: avoid arch_get_random_seed_long() when collecting IRQ randomness

[Ard Biesheuvel]

On Fri, 20 Nov 2020 at 16:27, Marc Zyngier  wrote:
>
> On 2020-11-05 15:29, Ard Biesheuvel wrote:
> > When reseeding the CRNG periodically, arch_get_random_seed_long() is
> > called to obtain entropy from an architecture specific source if one
> > is implemented. In most cases, these are special instructions, but in
> > some cases, such as on ARM, we may want to back this using firmware
> > calls, which are considerably more expensive.
> >
> > Another call to arch_get_random_seed_long() exists in the CRNG driver,
> > in add_interrupt_randomness(), which collects entropy by capturing
> > inter-interrupt timing and relying on interrupt jitter to provide
> > random bits. This is done by keeping a per-CPU state, and mixing in
> > the IRQ number, the cycle counter and the return address every time an
> > interrupt is taken, and mixing this per-CPU state into the entropy pool
> > every 64 invocations, or at least once per second. The entropy that is
> > gathered this way is credited as 1 bit of entropy. Every time this
> > happens, arch_get_random_seed_long() is invoked, and the result is
> > mixed in as well, and also credited with 1 bit of entropy.
> >
> > This means that arch_get_random_seed_long() is called at least once
> > per second on every CPU, which seems excessive, and doesn't really
> > scale, especially in a virtualization scenario where CPUs may be
> > oversubscribed: in cases where arch_get_random_seed_long() is backed
> > by an instruction that actually goes back to a shared hardware entropy
> > source (such as RNDRRS on ARM), we will end up hitting it hundreds of
> > times per second.
> >
> > So let's drop the call to arch_get_random_seed_long() from
> > add_interrupt_randomness(), and instead, rely on crng_reseed() to call
> > the arch hook to get random seed material from the platform.
> >
> > Signed-off-by: Ard Biesheuvel 
>
> Looks sensible. Having this on the interrupt path looks quite
> heavy handed, and my understanding of the above is that it has
> an adverse effect on the entropy pool.
>
> Acked-by: Marc Zyngier 
>

Thanks Marc.

Ted, any thoughts?

Re: [PATCH 4/4] USB: gadget: f_midi: setup SuperSpeed Plus descriptors

[Peter Chen]

On 20-11-26 19:09:37, Greg Kroah-Hartman wrote:
> From: Will McVicker 
> 
> Needed for SuperSpeed Plus support for f_midi.  This allows the
> gadget to work properly without crashing at SuperSpeed rates.
> 
> Cc: Felipe Balbi 
> Cc: stable 
> Signed-off-by: Will McVicker 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  drivers/usb/gadget/function/f_midi.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/gadget/function/f_midi.c 
> b/drivers/usb/gadget/function/f_midi.c
> index 85cb15734aa8..ceb67651de4f 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -1048,6 +1048,11 @@ static int f_midi_bind(struct usb_configuration *c, 
> struct usb_function *f)
>   f->ss_descriptors = usb_copy_descriptors(midi_function);
>   if (!f->ss_descriptors)
>   goto fail_f_midi;

Add one blank line, otherwise:

Reviewed-by: Peter Chen 

Peter
> + if (gadget_is_superspeed_plus(c->cdev->gadget)) {
> + f->ssp_descriptors = 
> usb_copy_descriptors(midi_function);
> + if (!f->ssp_descriptors)
> + goto fail_f_midi;
> + }
>   }
>  
>   kfree(midi_function);
> -- 
> 2.29.2
> 

-- 

Thanks,
Peter Chen

Re: [PATCH v3] ASoC: qcom: Fix playback recover problem in suspend resume

[Srinivas Kandagatla]

On 27/11/2020 09:56, Srinivasa Rao Mandadapu wrote:

To support playback continuation after hard suspend(bypass powerd)
  and resume:
Prepare device in  platform trigger callback.
Make I2s and DMA control registers as non volatile.

Looks like there are two changes here, One is fixing the volatile registers!


Other is preparing device after suspend!

Consider splitting them!





Fixes tag is missing here?


Signed-off-by: V Sujith Kumar Reddy 
Signed-off-by: Srinivasa Rao Mandadapu 
---
Changes Since v1 and v2:
   -- Subject lines changed

  sound/soc/qcom/lpass-cpu.c  | 8 ++--
  sound/soc/qcom/lpass-platform.c | 5 +++--
  2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index af684fd..c99be03 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -454,20 +454,16 @@ static bool lpass_cpu_regmap_volatile(struct device *dev, 
unsigned int reg)
struct lpass_variant *v = drvdata->variant;
int i;
  
-	for (i = 0; i < v->i2s_ports; ++i)

-   if (reg == LPAIF_I2SCTL_REG(v, i))
-   return true;
for (i = 0; i < v->irq_ports; ++i)
if (reg == LPAIF_IRQSTAT_REG(v, i))
return true;
  
  	for (i = 0; i < v->rdma_channels; ++i)

-   if (reg == LPAIF_RDMACURR_REG(v, i) || reg == 
LPAIF_RDMACTL_REG(v, i))
+   if (reg == LPAIF_RDMACURR_REG(v, i))
return true;
  
  	for (i = 0; i < v->wrdma_channels; ++i)

-   if (reg == LPAIF_WRDMACURR_REG(v, i + v->wrdma_channel_start) ||
-   reg == LPAIF_WRDMACTL_REG(v, i + 
v->wrdma_channel_start))
+   if (reg == LPAIF_WRDMACURR_REG(v, i + v->wrdma_channel_start))
return true;
  
  	return false;

diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index 80b09de..2b0a7c1 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -481,8 +481,9 @@ static int lpass_platform_pcmops_trigger(struct 
snd_soc_component *component,
return -ENOTRECOVERABLE;
}
switch (cmd) {
-   case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
+   lpass_platform_pcmops_prepare(component, substream);


Can you elaborate the actual issue here?

Are any other registers needs to re-programmed??

Does it make sense to use
regcache_mark_dirty()
regcache_sync() in pm suspend resume path,
instead of calling prepare explicitly?


--srini



+   case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
ret = regmap_fields_write(dmactl->enable, id,
 LPAIF_DMACTL_ENABLE_ON);
@@ -592,7 +593,7 @@ static int lpass_platform_pcmops_trigger(struct 
snd_soc_component *component,
break;
}
  
-	return 0;

+   return ret;
  }
  
  static snd_pcm_uframes_t lpass_platform_pcmops_pointer(

[PATCH 0/3] Add LLCC support for SM8250 SoC

[Manivannan Sadhasivam]

Hello,

This series adds Last Level Cache Controller (LLCC) support for SM8250
SoC from Qualcomm.

All 3 patches in this series are expected to go through arm-soc tree.

Thanks,
Mani

Manivannan Sadhasivam (3):
  dt-bindings: msm: Add LLCC for SM8250
  arm64: dts: qcom: sm8250: Add support for LLCC block
  soc: qcom: llcc-qcom: Add support for SM8250 SoC

 .../bindings/arm/msm/qcom,llcc.yaml   |  1 +
 arch/arm64/boot/dts/qcom/sm8250.dtsi  |  6 +++
 drivers/soc/qcom/llcc-qcom.c  | 40 +++
 include/linux/soc/qcom/llcc-qcom.h|  1 +
 4 files changed, 48 insertions(+)

-- 
2.25.1

[PATCH 1/3] dt-bindings: msm: Add LLCC for SM8250

[Manivannan Sadhasivam]

Add LLCC compatible for SM8250 SoC.

Signed-off-by: Manivannan Sadhasivam 
---
 Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml 
b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
index 0a9889debc7c..c299dc907f6c 100644
--- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
@@ -24,6 +24,7 @@ properties:
   - qcom,sc7180-llcc
   - qcom,sdm845-llcc
   - qcom,sm8150-llcc
+  - qcom,sm8250-llcc
 
   reg:
 items:
-- 
2.25.1

[PATCH 3/3] soc: qcom: llcc-qcom: Add support for SM8250 SoC

[Manivannan Sadhasivam]

SM8250 SoC uses LLCC IP version 2. In this version, the WRSC_EN register
needs to be written to enable the Write Sub Cache for each SCID. Hence,
use a dedicated "write_scid_en" member with predefined values and write
them for SoCs enabling the "llcc_v2" flag.

Signed-off-by: Manivannan Sadhasivam 
---
 drivers/soc/qcom/llcc-qcom.c   | 40 ++
 include/linux/soc/qcom/llcc-qcom.h |  1 +
 2 files changed, 41 insertions(+)

diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c
index 16b421608e9c..3ec4cdffa852 100644
--- a/drivers/soc/qcom/llcc-qcom.c
+++ b/drivers/soc/qcom/llcc-qcom.c
@@ -47,6 +47,7 @@
 
 #define LLCC_TRP_SCID_DIS_CAP_ALLOC   0x21f00
 #define LLCC_TRP_PCB_ACT  0x21f04
+#define LLCC_TRP_WRSC_EN  0x21f20
 
 #define BANK_OFFSET_STRIDE   0x8
 
@@ -73,6 +74,7 @@
  *   then the ways assigned to this client are not flushed on power
  *   collapse.
  * @activate_on_init: Activate the slice immediately after it is programmed
+ * @write_scid_en: Bit enables write cache support for a given scid.
  */
 struct llcc_slice_config {
u32 usecase_id;
@@ -87,12 +89,14 @@ struct llcc_slice_config {
bool dis_cap_alloc;
bool retain_on_pc;
bool activate_on_init;
+   bool write_scid_en;
 };
 
 struct qcom_llcc_config {
const struct llcc_slice_config *sct_data;
int size;
bool need_llcc_cfg;
+   bool llcc_v2;
 };
 
 static const struct llcc_slice_config sc7180_data[] =  {
@@ -147,6 +151,25 @@ static const struct llcc_slice_config sm8150_data[] =  {
{  LLCC_WRCACHE, 31, 128,  1, 1, 0xFFF, 0x0,   0, 0, 0, 0, 0 },
 };
 
+static const struct llcc_slice_config sm8250_data[] =  {
+   { LLCC_CPUSS,1, 3072, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 1, 0 },
+   { LLCC_VIDSC0,   2, 512,  3, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+   { LLCC_AUDIO,6, 1024, 1, 0, 0xfff, 0x0, 0, 0, 0, 0, 0, 0 },
+   { LLCC_CMPT,10, 1024, 1, 0, 0xfff, 0x0, 0, 0, 0, 0, 0, 0 },
+   { LLCC_GPUHTW,  11, 1024, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+   { LLCC_GPU, 12, 1024, 1, 0, 0xfff, 0x0, 0, 0, 0, 1, 0, 1 },
+   { LLCC_MMUHWT,  13, 1024, 1, 1, 0xfff, 0x0, 0, 0, 0, 0, 1, 0 },
+   { LLCC_CMPTDMA, 15, 1024, 1, 0, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+   { LLCC_DISP,16, 3072, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+   { LLCC_VIDFW,   17, 512,  1, 0, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+   { LLCC_AUDHW,   22, 1024, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+   { LLCC_NPU, 23, 3072, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+   { LLCC_WLHW,24, 1024, 1, 0, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+   { LLCC_CVP, 28, 256,  3, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+   { LLCC_APTCM,   30, 128,  3, 0, 0x0,   0x3, 1, 0, 0, 1, 0, 0 },
+   { LLCC_WRCACHE, 31, 256,  1, 1, 0xfff, 0x0, 0, 0, 0, 0, 1, 0 },
+};
+
 static const struct qcom_llcc_config sc7180_cfg = {
.sct_data   = sc7180_data,
.size   = ARRAY_SIZE(sc7180_data),
@@ -164,6 +187,12 @@ static const struct qcom_llcc_config sm8150_cfg = {
.size   = ARRAY_SIZE(sm8150_data),
 };
 
+static const struct qcom_llcc_config sm8250_cfg = {
+   .sct_data   = sm8250_data,
+   .size   = ARRAY_SIZE(sm8250_data),
+   .llcc_v2= true,
+};
+
 static struct llcc_drv_data *drv_data = (void *) -EPROBE_DEFER;
 
 /**
@@ -413,6 +442,16 @@ static int _qcom_llcc_cfg_program(const struct 
llcc_slice_config *config,
return ret;
}
 
+   if (cfg->llcc_v2) {
+   u32 wren;
+
+   wren = config->write_scid_en << config->slice_id;
+   ret = regmap_update_bits(drv_data->bcast_regmap, 
LLCC_TRP_WRSC_EN,
+BIT(config->slice_id), wren);
+   if (ret)
+   return ret;
+   }
+
if (config->activate_on_init) {
desc.slice_id = config->slice_id;
ret = llcc_slice_activate();
@@ -559,6 +598,7 @@ static const struct of_device_id qcom_llcc_of_match[] = {
{ .compatible = "qcom,sc7180-llcc", .data = _cfg },
{ .compatible = "qcom,sdm845-llcc", .data = _cfg },
{ .compatible = "qcom,sm8150-llcc", .data = _cfg },
+   { .compatible = "qcom,sm8250-llcc", .data = _cfg },
{ }
 };
 
diff --git a/include/linux/soc/qcom/llcc-qcom.h 
b/include/linux/soc/qcom/llcc-qcom.h
index 3db6797ba6ff..85f18ae7692f 100644
--- a/include/linux/soc/qcom/llcc-qcom.h
+++ b/include/linux/soc/qcom/llcc-qcom.h
@@ -29,6 +29,7 @@
 #define LLCC_AUDHW   22
 #define LLCC_NPU 23
 #define LLCC_WLHW24
+#define LLCC_CVP 28
 #define LLCC_MODPE   29
 #define LLCC_APTCM   30
 #define LLCC_WRCACHE 31
-- 
2.25.1

Re: [PATCH v6 00/11] clk: at91: clk-master: re-factor master clock

[Claudiu.Beznea]

I have just noticed that the title of this cover letter is wrong.
It should have been:

"clk: at91: adapt for dvfs"

Please let me know if you want me to send a new version for this update.

Thank you,
Claudiu

On 19.11.2020 17:43, Claudiu Beznea wrote:
> Hi,
> 
> SAMA7G5 is capable of DVFS. The supported CPU clock frequencies could be
> obtained from CPU PLL. The hardware block diagram for clock feeding the
> CPU is as follows:
> 
>++
>+-->|divider1|--> CPU clock
>|   ++
> ++   +--+  |   ++
> |CPU PLL |-->|prescaller|--+-->|divider0|--> MCK0 clock
> ++   +--+  ++
> 
> When switching CPU clock frequencies the MCK0 is also changed by DVFS
> driver to avoid its over/under clocking (depending on CPU clock frequency
> requested by DVFS algorithms). Some of IPs feed by MCK0 are MCK0 glich
> aware, some are not. For this MCK0 was removed from the parents list of
> the IPs which are not MCK0 glitch aware (patch 7/11).
> 
> This series adapt AT91 clocks (mostly sam9x60-pll and master clock drivers)
> so that runtime changes of these clocks to be allowed.
> 
> The CPU clock was registered from prescaller clock (see above diagram)
> and no software control has been added for divider1 because the frequencies
> supported by SAMA7G5's CPU could be directly obtained from CPU PLL +
> prescaller.
> 
> On top of this series I also added a fix for sama7g5.c code (patch 1/11).
> Please let me know if you would like me to send this one separtely (it
> would be nice if this fix could be integrated in 5.10).
> 
> Changes were tested on SAMA5D2, SAMA5D3, SAM9X60 and SAMA7G5.
> 
> Thank you,
> Claudiu Beznea
> 
> Changes in v6:
> - remove if (clk_hw_get_flags(hw) & CLK_SET_RATE_GATE) in patch 10/11 as
>   we use different clock ops now for pres, div supporting run-time changes
>   
> Changes in v5:
> - use separate clk_ops for PLLs and master clock div, pres supporting
>   run-time changes (patches 6/11, 10/11)
> - use unsigned long type for f member of struct typeof(sama7g5_plls)
> - document the usage of CLK_IS_CRITICAL
> 
> Changes in v4:
> - added Reviewed-by, Tested-by tags forgoten in v3
> 
> Changes in v3:
> - collected Reviewed-by, Tested-by tags
> - add patches 4/11, 5/11, 9/11
> - in patch 10/11 use CLK_SET_RATE_GATE on MCK div and MCK pres for all
>   the platforms except sama7g5
> 
> Changes in v2:
> - s/at91rm9200_mck_lock/at91sam9260_mck_lock in patch 7/8
> 
> Claudiu Beznea (7):
>   clk: at91: sama7g5: fix compilation error
>   clk: at91: clk-sam9x60-pll: allow runtime changes for pll
>   clk: at91: sama7g5: remove mck0 from parent list of other clocks
>   clk: at91: sama7g5: decrease lower limit for MCK0 rate
>   clk: at91: sama7g5: do not allow cpu pll to go higher than 1GHz
>   clk: at91: clk-master: re-factor master clock
>   clk: at91: sama7g5: register cpu clock
> 
> Eugen Hristev (4):
>   dt-bindings: clock: at91: add sama7g5 pll defines
>   clk: at91: sama7g5: allow SYS and CPU PLLs to be exported and
> referenced in DT
>   clk: at91: clk-master: add 5th divisor for mck master
>   clk: at91: sama7g5: add 5th divisor for mck0 layout and
> characteristics
> 
>  drivers/clk/at91/at91rm9200.c  |  21 ++-
>  drivers/clk/at91/at91sam9260.c |  26 ++-
>  drivers/clk/at91/at91sam9g45.c |  32 +++-
>  drivers/clk/at91/at91sam9n12.c |  36 ++--
>  drivers/clk/at91/at91sam9rl.c  |  23 ++-
>  drivers/clk/at91/at91sam9x5.c  |  28 ++-
>  drivers/clk/at91/clk-master.c  | 337 
> -
>  drivers/clk/at91/clk-sam9x60-pll.c | 145 ++--
>  drivers/clk/at91/dt-compat.c   |  15 +-
>  drivers/clk/at91/pmc.h |  22 ++-
>  drivers/clk/at91/sam9x60.c |  45 +++--
>  drivers/clk/at91/sama5d2.c |  42 +++--
>  drivers/clk/at91/sama5d3.c |  38 +++--
>  drivers/clk/at91/sama5d4.c |  40 +++--
>  drivers/clk/at91/sama7g5.c | 223 
>  include/dt-bindings/clock/at91.h   |  11 ++
>  16 files changed, 840 insertions(+), 244 deletions(-)
> 

[PATCH 2/3] arm64: dts: qcom: sm8250: Add support for LLCC block

[Manivannan Sadhasivam]

Add support for Last Level Cache Controller (LLCC) in SM8250 SoC.
This LLCC is used to provide common cache memory pool for the cores in
the SM8250 SoC thereby minimizing the percore caches.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi 
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 65acd1f381eb..118b6bb29ebc 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -1758,6 +1758,12 @@ usb_1_dwc3: dwc3@a60 {
};
};
 
+   system-cache-controller@920 {
+   compatible = "qcom,sm8250-llcc";
+   reg = <0 0x0920 0 0x1d>, <0 0x0960 0 
0x5>;
+   reg-names = "llcc_base", "llcc_broadcast_base";
+   };
+
usb_2: usb@a8f8800 {
compatible = "qcom,sm8250-dwc3", "qcom,dwc3";
reg = <0 0x0a8f8800 0 0x400>;
-- 
2.25.1

Re: [PATCH] x86/e820: fix the function type for e820__mapped_all

[Borislav Petkov]

On Fri, Nov 13, 2020 at 10:26:54AM -0800, Sami Tolvanen wrote:
> e820__mapped_all is passed as a callback to is_mmconf_reserved, which
> expects a function of type:
> 
>   typedef bool (*check_reserved_t)(u64 start, u64 end, unsigned type);
> 
> This trips indirect call checking with Clang's Control-Flow Integrity
> (CFI). Change the last argument from enum e820_type to unsigned to fix
> the type mismatch.
> 
> Reported-by: Sedat Dilek 
> Signed-off-by: Sami Tolvanen 
> ---
>  arch/x86/include/asm/e820/api.h | 2 +-
>  arch/x86/kernel/e820.c  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/e820/api.h b/arch/x86/include/asm/e820/api.h
> index e8f58ddd06d9..e872a796619d 100644
> --- a/arch/x86/include/asm/e820/api.h
> +++ b/arch/x86/include/asm/e820/api.h
> @@ -12,7 +12,7 @@ extern unsigned long pci_mem_start;
>  
>  extern bool e820__mapped_raw_any(u64 start, u64 end, enum e820_type type);
>  extern bool e820__mapped_any(u64 start, u64 end, enum e820_type type);
> -extern bool e820__mapped_all(u64 start, u64 end, enum e820_type type);
> +extern bool e820__mapped_all(u64 start, u64 end, unsigned type);

I think the proper fix is to fix the typedef to:

typedef bool (*check_reserved_t)(u64 start, u64 end, enum e820_type 
type);

because

* is_mmconf_reserved() is passing in E820_TYPE_RESERVED which is enum e820_type

* is_acpi_reserved() is the other check_reserved_t function ptr and the last arg
type there is unused so it can just as well be enum e820_type.

Thx.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: nohz: Update tick instead of restarting tick in tick_nohz_idle_exit()

[Frederic Weisbecker]

On Mon, Nov 23, 2020 at 09:22:08PM +0800, Yunfeng Ye wrote:
> In realtime scenarios, the "nohz_full" parameter is configured. Tick
> interference is not expected when there is only one realtime thread.
> But when the idle thread is switched to the realtime thread, the tick
> timer is restarted always.
> 
> So on the nohz full mode, it is unnecessary to restart the tick timer
> when there is only one realtime thread. Adding can_stop_full_tick()
> before restarting the tick, if it return true, keep tick stopped.
> 
> Signed-off-by: Yunfeng Ye 

We can indeed stop the tick and avoid it to be re-armed needlessly at this
point.

I'm taking your patch, I may just edit it a little and resend it.

Thanks!

Re: [PATCH] e1000e: Assign DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME to speed up s2ram

[Kai-Heng Feng]

> On Nov 26, 2020, at 22:45, Chen Yu  wrote:
> 
> On Thu, Nov 26, 2020 at 08:05:02PM +0800, Kai-Heng Feng wrote:
>> 
>> 
>>> On Nov 26, 2020, at 19:10, Chen Yu  wrote:
>>> 
>>> On Thu, Nov 26, 2020 at 02:36:42PM +0800, Kai-Heng Feng wrote:
>> 
>> What about plugging ethernet cable and using WoL after system is 
>> suspended?
>> Commit "e1000e: Exclude device from suspend direct complete 
>> optimization" was to address that scenario.
>>> [cut]
 
 I don't think this is right.
 Isn't E1000_WUFC_LNKC already set for runtime suspend?
 What if WoL doesn't have it set?
 
>>> After re-taking a look at your description, please let me elaborate more 
>>> about the scenario.
>>> With this patch applied, and with sysfs wake up disabled, the expected 
>>> behavior is:
>>> 
>>> 1. If NIC is not runtime suspended:
>>> 1.1 s2ram suspend -> wufc will be set to 0(no WoL settings), suspend(), 
>>> suspend_late(), suspend_noirq()
>>> 1.2 s2ram resume  -> NIC resumes normaly
>>> 
>>> 2. If NIC is runtime suspended:
>>> 2.1 s2ram suspend -> wufc set to E1000_WUFC_LNKC, skip the subsequent 
>>> suspend callbacks.
>> 
>> Is it safe to keep E1000_WUFC_LNKC enabled here?
>> 
>> From commit 6bf6be1127f7 ("e1000e: Do not wake up the system via WOL if 
>> device wakeup is disabled"):
>> 
>>   /* Runtime suspend should only enable wakeup for link changes */
>>   if (runtime)
>>   wufc = E1000_WUFC_LNKC;
>>   else if (device_may_wakeup(>dev))
>>   wufc = adapter->wol;
>>   else
>>   wufc = 0;
>> 
>> So it has different wakeup settings for runtime suspend and system suspend, 
>> either device_may_wakeup() true or false.
> Right.
>> Or maybe e1000e devs can confirm E1000_WUFC_LNKC is a safe for system 
>> suspend?
>> 
> Does 'safe' here mean waking up the system?
> For s2ram, whether the NIC can wake up the system from S3 via cable plug is 
> platform
> (BIOS) specific. So the wufc settings here is not directly related to system 
> wake up
> via plug event.

Thanks for the confirmation. How about a different approach? 
Simply use direct-complete to let PM core handle the rest:

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index b30f00891c03..1d1424a20733 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "e1000.h"
 
@@ -6868,6 +6869,20 @@ static void e1000e_disable_aspm_locked(struct pci_dev 
*pdev, u16 state)
__e1000e_disable_aspm(pdev, state, 1);
 }
 
+static int e1000e_pm_prepare(struct device *dev)
+{
+   return pm_runtime_suspended(dev) &&
+  pm_suspend_via_firmware() &&
+  !device_may_wakeup(dev);
+}
+
+static void e1000e_pm_complete(struct device *dev)
+{
+   /* Detect link change */
+   if (pm_runtime_suspended(dev))
+   pm_request_resume(dev);
+}
+
 static int e1000e_pm_thaw(struct device *dev)
 {
struct net_device *netdev = dev_get_drvdata(dev);
@@ -7665,9 +7680,7 @@ static int e1000_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
e1000_print_device_info(adapter);
 
-   dev_pm_set_driver_flags(>dev, DPM_FLAG_NO_DIRECT_COMPLETE);
-
-   if (pci_dev_run_wake(pdev) && hw->mac.type < e1000_pch_cnp)
+   if (pci_dev_run_wake(pdev))
pm_runtime_put_noidle(>dev);
 
return 0;
@@ -7890,6 +7903,8 @@ MODULE_DEVICE_TABLE(pci, e1000_pci_tbl);
 
 static const struct dev_pm_ops e1000_pm_ops = {
 #ifdef CONFIG_PM_SLEEP
+   .prepare= e1000e_pm_prepare,
+   .complete   = e1000e_pm_complete,
.suspend= e1000e_pm_suspend,
.resume = e1000e_pm_resume,
.freeze = e1000e_pm_freeze,


> thanks,
> Chenyu

Re: [PATCH] mm: Don't fault around userfaultfd-registered regions on reads

[Matthew Wilcox]

On Thu, Nov 26, 2020 at 05:23:59PM -0500, Peter Xu wrote:
> For missing mode uffds, fault around does not help because if the page cache
> existed, then the page should be there already.  If the page cache is not
> there, nothing else we can do, either.  If the fault-around code is destined 
> to
> be helpless for userfault-missing vmas, then ideally we can skip it.

But it might have been faulted into the cache by another task, so skipping
it is bad.

> For wr-protected mode uffds, errornously fault in those pages around could 
> lead
> to threads accessing the pages without uffd server's awareness.  For example,
> when punching holes on uffd-wp registered shmem regions, we'll first try to
> unmap all the pages before evicting the page cache but without locking the
> page (please refer to shmem_fallocate(), where unmap_mapping_range() is called
> before shmem_truncate_range()).  When fault-around happens near a hole being
> punched, we might errornously fault in the "holes" right before it will be
> punched.  Then there's a small window before the page cache was finally
> dropped, and after the page will be writable again (NOTE: the uffd-wp protect
> information is totally lost due to the pre-unmap in shmem_fallocate(), so the
> page can be writable within the small window).  That's severe data loss.

Sounds like you have a missing page_mkwrite implementation.

> This patch comes from debugging a data loss issue when working on the uffd-wp
> support on shmem/hugetlbfs.  I posted this out for early review and comments,
> but also because it should already start to benefit missing mode userfaultfd 
> to
> avoid trying to fault around on reads.

A measurable difference?

Re: [PATCH v2] mm/page_alloc: clear all pages in post_alloc_hook() with init_on_alloc=1

[Michal Hocko]

On Fri 20-11-20 19:04:52, David Hildenbrand wrote:
> commit 6471384af2a6 ("mm: security: introduce init_on_alloc=1 and
> init_on_free=1 boot options") resulted with init_on_alloc=1 in all pages
> leaving the buddy via alloc_pages() and friends to be
> initialized/cleared/zeroed on allocation.
> 
> However, the same logic is currently not applied to
> alloc_contig_pages(): allocated pages leaving the buddy aren't cleared
> with init_on_alloc=1 and init_on_free=0. Let's also properly clear
> pages on that allocation path.
> 
> To achieve that, let's move clearing into post_alloc_hook(). This will not
> only affect alloc_contig_pages() allocations but also any pages used as
> migration target in compaction code via compaction_alloc().
> 
> While this sounds sub-optimal, it's the very same handling as when
> allocating migration targets via alloc_migration_target() - pages will
> get properly cleared with init_on_free=1. In case we ever want to optimize
> migration in that regard, we should tackle all such migration users - if we
> believe migration code can be fully trusted.
> 
> With this change, we will see double clearing of pages in some
> cases. One example are gigantic pages (either allocated via CMA, or
> allocated dynamically via alloc_contig_pages()) - which is the right
> thing to do (and to be optimized outside of the buddy in the callers) as
> discussed in:
>   https://lkml.kernel.org/r/20201019182853.7467-1-gpicc...@canonical.com
> 
> This change implies that with init_on_alloc=1
> - All CMA allocations will be cleared
> - Gigantic pages allocated via alloc_contig_pages() will be cleared
> - virtio-mem memory to be unplugged will be cleared. While this is
>   suboptimal, it's similar to memory balloon drivers handling, where
>   all pages to be inflated will get cleared as well.
> - Pages isolated for compaction will be cleared

Yes, this looks much better than the previous version. Thanks for
looking into it deeper!

> Cc: Andrew Morton 
> Cc: Alexander Potapenko 
> Cc: Michal Hocko 
> Cc: Mike Kravetz 
> Cc: Vlastimil Babka 
> Cc: Mike Rapoport 
> Cc: Oscar Salvador 
> Cc: Kees Cook 
> Cc: Michael Ellerman 
> Signed-off-by: David Hildenbrand 

Acked-by: Michal Hocko 

Btw. I think we would benefit from a documentation which would explain
what is the purpose of the two parts of the initialization. What does
belong to prep_new_page resp. post_alloc_hook.

Thanks!
> ---
> 
> This is the follow-up of:
>   "[PATCH v1] mm/page_alloc: clear pages in alloc_contig_pages() with
>   init_on_alloc=1 or __GFP_ZERO"
> 
> v1 -> v2:
> - Let's clear anything that leaves the buddy, also affecting compaction.
> - Don't implement __GFP_ZERO support for now
> 
> ---
>  mm/page_alloc.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index eaa227a479e4..108b81c0dfa8 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2275,6 +2275,9 @@ inline void post_alloc_hook(struct page *page, unsigned 
> int order,
>   kasan_alloc_pages(page, order);
>   kernel_poison_pages(page, 1 << order, 1);
>   set_page_owner(page, order, gfp_flags);
> +
> + if (!free_pages_prezeroed() && want_init_on_alloc(gfp_flags))
> + kernel_init_free_pages(page, 1 << order);
>  }
>  
>  static void prep_new_page(struct page *page, unsigned int order, gfp_t 
> gfp_flags,
> @@ -2282,9 +2285,6 @@ static void prep_new_page(struct page *page, unsigned 
> int order, gfp_t gfp_flags
>  {
>   post_alloc_hook(page, order, gfp_flags);
>  
> - if (!free_pages_prezeroed() && want_init_on_alloc(gfp_flags))
> - kernel_init_free_pages(page, 1 << order);
> -
>   if (order && (gfp_flags & __GFP_COMP))
>   prep_compound_page(page, order);
>  
> -- 
> 2.26.2
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH net-next] net: switch to storing KCOV handle directly in sk_buff

[Marco Elver]

On Thu, 26 Nov 2020 at 17:35, Willem de Bruijn
 wrote:
> On Thu, Nov 26, 2020 at 3:19 AM Marco Elver  wrote:
[...]
> > Will send v2.
>
> Does it make more sense to revert the patch that added the extensions
> and the follow-on fixes and add a separate new patch instead?

That doesn't work, because then we'll end up with a build-broken
commit in between the reverts and the new version, because mac80211
uses skb_get_kcov_handle().

> If adding a new field to the skb, even if only in debug builds,
> please check with pahole how it affects struct layout if you
> haven't yet.

Without KCOV:

/* size: 224, cachelines: 4, members: 72 */
/* sum members: 217, holes: 1, sum holes: 2 */
/* sum bitfield members: 36 bits, bit holes: 2, sum bit holes: 4 bits */
/* forced alignments: 2 */
/* last cacheline: 32 bytes */

With KCOV:

/* size: 232, cachelines: 4, members: 73 */
/* sum members: 225, holes: 1, sum holes: 2 */
/* sum bitfield members: 36 bits, bit holes: 2, sum bit holes: 4 bits */
/* forced alignments: 2 */
/* last cacheline: 40 bytes */


> The skb_extensions idea was mine. Apologies for steering
> this into an apparently unsuccessful direction. Adding new fields
> to skb is very rare because possibly problematic wrt allocation.

[PATCH v2 2/2] ASoC: Add ADAU1372 audio CODEC support

[Alexandre Belloni]

From: Lars-Peter Clausen 

Add support for the Analog Devices ADAU1372 audio CODEC.

[Alexandre Belloni: allow 32kHz for TDM4 in slave mode]
Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Alexandre Belloni 
---

Changes in v2:
 - Fix Microphone bias

 sound/soc/codecs/Kconfig|   16 +
 sound/soc/codecs/Makefile   |6 +
 sound/soc/codecs/adau1372-i2c.c |   40 ++
 sound/soc/codecs/adau1372-spi.c |   58 ++
 sound/soc/codecs/adau1372.c | 1062 +++
 sound/soc/codecs/adau1372.h |   21 +
 6 files changed, 1203 insertions(+)
 create mode 100644 sound/soc/codecs/adau1372-i2c.c
 create mode 100644 sound/soc/codecs/adau1372-spi.c
 create mode 100644 sound/soc/codecs/adau1372.c
 create mode 100644 sound/soc/codecs/adau1372.h

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 34c6dd04b85a..a457300f95da 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -23,6 +23,8 @@ config SND_SOC_ALL_CODECS
imply SND_SOC_AD193X_I2C
imply SND_SOC_AD1980
imply SND_SOC_AD73311
+   imply SND_SOC_ADAU1372_I2C
+   imply SND_SOC_ADAU1372_SPI
imply SND_SOC_ADAU1373
imply SND_SOC_ADAU1761_I2C
imply SND_SOC_ADAU1761_SPI
@@ -363,6 +365,20 @@ config SND_SOC_AD73311
 config SND_SOC_ADAU_UTILS
tristate
 
+config SND_SOC_ADAU1372
+   tristate
+   select SND_SOC_ADAU_UTILS
+
+config SND_SOC_ADAU1372_I2C
+   tristate "Analog Devices ADAU1372 CODEC (I2C)"
+   select SND_SOC_ADAU1372
+   select REGMAP_I2C
+
+config SND_SOC_ADAU1372_SPI
+   tristate "Analog Devices ADAU1372 CODEC (SPI)"
+   select SND_SOC_ADAU1372
+   select REGMAP_SPI
+
 config SND_SOC_ADAU1373
tristate
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 11ce98c25d6c..b31f55c0d741 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -9,6 +9,9 @@ snd-soc-ad193x-i2c-objs := ad193x-i2c.o
 snd-soc-ad1980-objs := ad1980.o
 snd-soc-ad73311-objs := ad73311.o
 snd-soc-adau-utils-objs := adau-utils.o
+snd-soc-adau1372-objs := adau1372.o
+snd-soc-adau1372-i2c-objs := adau1372-i2c.o
+snd-soc-adau1372-spi-objs := adau1372-spi.o
 snd-soc-adau1373-objs := adau1373.o
 snd-soc-adau1701-objs := adau1701.o
 snd-soc-adau17x1-objs := adau17x1.o
@@ -316,6 +319,9 @@ obj-$(CONFIG_SND_SOC_AD193X_I2C)+= snd-soc-ad193x-i2c.o
 obj-$(CONFIG_SND_SOC_AD1980)   += snd-soc-ad1980.o
 obj-$(CONFIG_SND_SOC_AD73311) += snd-soc-ad73311.o
 obj-$(CONFIG_SND_SOC_ADAU_UTILS)   += snd-soc-adau-utils.o
+obj-$(CONFIG_SND_SOC_ADAU1372) += snd-soc-adau1372.o
+obj-$(CONFIG_SND_SOC_ADAU1372_I2C) += snd-soc-adau1372-i2c.o
+obj-$(CONFIG_SND_SOC_ADAU1372_SPI) += snd-soc-adau1372-spi.o
 obj-$(CONFIG_SND_SOC_ADAU1373) += snd-soc-adau1373.o
 obj-$(CONFIG_SND_SOC_ADAU1701) += snd-soc-adau1701.o
 obj-$(CONFIG_SND_SOC_ADAU17X1) += snd-soc-adau17x1.o
diff --git a/sound/soc/codecs/adau1372-i2c.c b/sound/soc/codecs/adau1372-i2c.c
new file mode 100644
index ..fc87a76ff1ee
--- /dev/null
+++ b/sound/soc/codecs/adau1372-i2c.c
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Driver for ADAU1372 codec
+ *
+ * Copyright 2016 Analog Devices Inc.
+ *  Author: Lars-Peter Clausen 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "adau1372.h"
+
+static int adau1372_i2c_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
+{
+   return adau1372_probe(>dev,
+   devm_regmap_init_i2c(client, _regmap_config), NULL);
+}
+
+static const struct i2c_device_id adau1372_i2c_ids[] = {
+   { "adau1372", 0 },
+   { }
+};
+MODULE_DEVICE_TABLE(i2c, adau1372_i2c_ids);
+
+static struct i2c_driver adau1372_i2c_driver = {
+   .driver = {
+   .name = "adau1372",
+   },
+   .probe = adau1372_i2c_probe,
+   .id_table = adau1372_i2c_ids,
+};
+module_i2c_driver(adau1372_i2c_driver);
+
+MODULE_DESCRIPTION("ASoC ADAU1372 CODEC I2C driver");
+MODULE_AUTHOR("Lars-Peter Clausen ");
+MODULE_LICENSE("GPL v2");
diff --git a/sound/soc/codecs/adau1372-spi.c b/sound/soc/codecs/adau1372-spi.c
new file mode 100644
index ..51298e00fbd6
--- /dev/null
+++ b/sound/soc/codecs/adau1372-spi.c
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Driver for ADAU1372 codec
+ *
+ * Copyright 2016 Analog Devices Inc.
+ *  Author: Lars-Peter Clausen 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "adau1372.h"
+
+static void adau1372_spi_switch_mode(struct device *dev)
+{
+   struct spi_device *spi = to_spi_device(dev);
+
+   /*
+* To get the device into SPI mode CLATCH has to be pulled low three
+* times.  Do this by issuing three dummy reads.
+*/
+   spi_w8r8(spi, 0x00);
+   spi_w8r8(spi, 0x00);
+   spi_w8r8(spi, 0x00);
+}
+
+static int adau1372_spi_probe(struct spi_device *spi)
+{
+   struct 

[PATCH v2 1/2] dt-bindings: sound: adau1372: Add bindings documentation

[Alexandre Belloni]

Add device tree binding documentation for Analog Devices ADAU1372.

Signed-off-by: Alexandre Belloni 
Reviewed-by: Rob Herring 
---
Changes in v2:
 - Added Rob's reviewed-by

 .../bindings/sound/adi,adau1372.yaml  | 67 +++
 1 file changed, 67 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/adi,adau1372.yaml

diff --git a/Documentation/devicetree/bindings/sound/adi,adau1372.yaml 
b/Documentation/devicetree/bindings/sound/adi,adau1372.yaml
new file mode 100644
index ..701449311fec
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,adau1372.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/adi,adau1372.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+
+title: Analog Devices ADAU1372 CODEC
+
+maintainers:
+  - Alexandre Belloni 
+
+description: |
+  Analog Devices ADAU1372 four inputs and two outputs codec.
+  
https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1372.pdf
+
+properties:
+  compatible:
+enum:
+  - adi,adau1372
+
+  reg:
+maxItems: 1
+
+  "#sound-dai-cells":
+const: 0
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: "mclk"
+
+  powerdown-gpios:
+description: GPIO used for hardware power-down.
+maxItems: 1
+
+required:
+  - "#sound-dai-cells"
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+
+additionalProperties: false
+
+examples:
+  - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+audio-codec@3c {
+compatible = "adi,adau1372";
+reg = <0x3c>;
+#sound-dai-cells = <0>;
+clock-names = "mclk";
+clocks = <_xtal>;
+};
+};
+
+adau1372z_xtal: clock {
+compatible = "fixed-clock";
+#clock-cells = <0>;
+clock-frequency = <12288000>;
+};
+...
+
-- 
2.28.0

Re: 5.10 regression caused by: "uas: fix sdev->host->dma_dev": many XHCI swiotlb buffer is full / DMAR: Device bounce map failed errors on thunderbolt connected XHCI controller

[Hans de Goede]

Hi,

On 11/27/20 12:41 PM, Hans de Goede wrote:
> Hi,
> 
> On 11/24/20 11:27 AM, Christoph Hellwig wrote:
>> On Mon, Nov 23, 2020 at 03:49:09PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> +Cc Christoph Hellwig 
>>>
>>> Christoph, this is still an issue, so I've been looking around a bit and 
>>> think this
>>> might have something to do with the dma-mapping-5.10 changes.
>>>
>>> Do you have any suggestions to debug this, or is it time to do a git bisect
>>> on this before 5.10 ships with regression?
>>
>> Given that DMAR prefix this seems to be about using intel-iommu + bounce
>> buffering for external devices.  I can't really think of anything specific
>> in 5.10 related to that, so maybe you'll need to bisect.
>>
>> I doub this means we are actually leaking swiotlb buffers, so while
>> I'm pretty sure we broke something in lower layers this also means
>> xhci doesn't handle swiotlb operation very gracefully in general.
> 
> I've done a git bisect, and the result is somewhat surprising. The git-bisect
> points to:
> 
> commit 558033c2828f ("uas: fix sdev->host->dma_dev")
> 
> Use scsi_add_host_with_dma() instead of scsi_add_host().
> 
> When the scsi request queue is initialized/allocated, hw_max_sectors is 
> clamped
> to the dma max mapping size. Therefore, the correct device that should be 
> used
> for the clamping needs to be set.
> 
> The same clamping is still needed in uas as hw_max_sectors could be 
> changed
> there. The original clamping would be invalidated in such cases.
> 
> I do have an UAS drive connected to the thunderbolt-dock, so I guess that this
> change is causing the UAS driver to gobble all all available swiotlb space.

I ran some more tests, I can confirm that reverting:

5df7ef7d32fe "uas: bump hw_max_sectors to 2048 blocks for SS or faster drives"
558033c2828f "uas: fix sdev->host->dma_dev"

Makes the problem go away while running a 5.10 kernel. I also tried doubling
the swiotlb size by adding: swiotlb=65536 to the kernel commandline but that
does not help.

Some more observations:

1. The usb-storage driver does not cause this issue, even though it has a
very similar change.

2. The problem does not happen until I plug an UAS decvice into the dock.

3. The problem continues to happen even after I unplug the UAS device and
rmmod the uas module

3. made me take a bit closer look to the troublesome commit, it passes:
udev->bus->sysdev, which I assume is the XHCI controller itself as device
to scsi_add_host_with_dma, which in turn seems to cause permanent changes
to the dma settings for the XHCI controller. I'm not all that familiar with
the DMA APIs but I'm getting the feeling that passing the actual 
XHCI-controller's
device as dma-device to scsi_add_host_with_dma is simply the wrong thing to
do; and that the intended effects (honor XHCI dma limits, but do not cause
any changes the XHCI dma settings) should be achieved differently.

Note that if this is indeed wrong, the matching usb-storage change should
likely also be dropped.

Regards,

Hans

WARNING: filesystem loop5 was created with 512 inodes, the real maximum is 511, mounting anyway

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:418baf2c Linux 5.10-rc5
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=171555b950
kernel config:  https://syzkaller.appspot.com/x/.config?x=b81aff78c272da44
dashboard link: https://syzkaller.appspot.com/bug?extid=3fd34060f26e766536ff
compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3fd34060f26e76653...@syzkaller.appspotmail.com

BFS-fs: bfs_fill_super(): loop5 is unclean, continuing
BFS-fs: bfs_fill_super(): WARNING: filesystem loop5 was created with 512 
inodes, the real maximum is 511, mounting anyway
BFS-fs: bfs_fill_super(): Last block not available on loop5: 120
BFS-fs: bfs_fill_super(): loop5 is unclean, continuing
BFS-fs: bfs_fill_super(): WARNING: filesystem loop5 was created with 512 
inodes, the real maximum is 511, mounting anyway
BFS-fs: bfs_fill_super(): Last block not available on loop5: 120


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

[PATCH v1] net: phy: micrel: fix interrupt handling

[Oleksij Rempel]

After migration to the shared interrupt support, the KSZ8031 PHY with
enabled interrupt support was not able to notify about link status
change.

Fixes: 59ca4e58b917 ("net: phy: micrel: implement generic .handle_interrupt() 
callback")
Signed-off-by: Oleksij Rempel 
---
 drivers/net/phy/micrel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 97f08f20630b..54e0d75203da 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -207,7 +207,7 @@ static irqreturn_t kszphy_handle_interrupt(struct 
phy_device *phydev)
return IRQ_NONE;
}
 
-   if ((irq_status & KSZPHY_INTCS_STATUS))
+   if (!(irq_status & KSZPHY_INTCS_STATUS))
return IRQ_NONE;
 
phy_trigger_machine(phydev);
-- 
2.29.2

Re: [PATCH] printk: finalize records with trailing newlines

[Petr Mladek]

On Thu 2020-11-26 20:32:18, Kefeng Wang wrote:
> 
> On 2020/11/26 19:48, John Ogness wrote:
> > Any record with a trailing newline (LOG_NEWLINE flag) cannot
> > be continued because the newline has been stripped and will
> > not be visible if the message is appended. This was already
> > handled correctly when committing in log_output() but was
> > not handled correctly when committing in log_store().
> > 
> > Fixes: f5f022e53b87 ("printk: reimplement log_cont using record extension")
> > Signed-off-by: John Ogness 
> > ---
> >   This is an important bugfix for continuous messages and should
> >   be part of the 5.10 release.
> > 
> >   If not applied, newlines will vanish when concatenating
> >   continuous with trailing newlines.
> Thanks for you quick fix.
> 
> Reported-and-tested-by:  Kefeng Wang 

The patch is committed in printk/linux.git, branch
for-5.10-pr_cont-fixup.

I do not have much experience with pushing fixes this late in the
release cycle.

Normally, I would prefer to give it few days in linux-next. But
the fix is quite trivial. And it would be better to have it
in 10-rc6 rather than in rc7 that might be the last rc before
release.

Thanks a lot for report, fix, and testing.

Best Regards,
Petr

Re: [PATCH] Asoc: qcom: Fix for problem in resume with CRAS

[Mark Brown]

On Fri, Nov 27, 2020 at 09:42:03AM +0530, Srinivasa Rao Mandadapu wrote:
> To support playback continuation after resume problem in chrome
> audio server:
> Prepare device in  platform trigger callback.
> Make I2s and DMA control registers as non volatile.

What is the actual issue this is fixing?

As I have previously said please submit patches using subject lines
reflecting the style for the subsystem, this makes it easier for people
to identify relevant patches.  Look at what existing commits in the area
you're changing are doing and make sure your subject lines visually
resemble what they're doing.  There's no need to resubmit to fix this
alone.


signature.asc
Description: PGP signature

Re: [PATCH v2] soc / drm: mediatek: cmdq: Remove timeout handler in helper function

[Matthias Brugger]

Hi Chun-Kuang,

On 20/11/2020 00:46, Chun-Kuang Hu wrote:

Hi, Matthias:

I've provided the example for why of this patch. How do you think
about this patch?



Patch looks good to me. If you want to take it through your tree you can add my
Acked-by: Matthias Brugger 

Beware that you might need a stable tag for it, so that I can merge it into my 
soc branch, in case there are more changes to cmdq-helper.


Regards,
Matthias


Regards,
Chun-Kuang.

Chun-Kuang Hu  於 2020年11月2日 週一 上午8:04寫道：


For each client driver, its timeout handler need to dump hardware register
or its state machine information, and their way to detect timeout are
also different, so remove timeout handler in helper function and
let client driver implement its own timeout handler.

Signed-off-by: Chun-Kuang Hu 
---
v1 is one patch in series "Mediatek DRM driver detect CMDQ execution
timeout by vblank IRQ", but according to Jassi's suggestion [1], send
each patch in different series.

[2] is an example that different client has different way to calculate
timeout. Some client driver care about each packet's execution time, but
some client driver care about the total execution time for all packets.

[1]
https://patchwork.kernel.org/project/linux-mediatek/cover/20200927230422.11610-1-chunkuang...@kernel.org/
[2]
https://patchwork.kernel.org/project/linux-mediatek/patch/20201022094152.17662-1-houlong@mediatek.com/

Changes in v2:
1. Rebase onto Linux 5.10-rc1
---
  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  3 +-
  drivers/soc/mediatek/mtk-cmdq-helper.c  | 41 +
  include/linux/soc/mediatek/mtk-cmdq.h   | 10 +-
  3 files changed, 3 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index ac038572164d..4be5d1fccf2e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -824,8 +824,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
  #if IS_REACHABLE(CONFIG_MTK_CMDQ)
 mtk_crtc->cmdq_client =
 cmdq_mbox_create(mtk_crtc->mmsys_dev,
-drm_crtc_index(_crtc->base),
-2000);
+drm_crtc_index(_crtc->base));
 if (IS_ERR(mtk_crtc->cmdq_client)) {
 dev_dbg(dev, "mtk_crtc %d failed to create mailbox client, writing 
register by CPU now\n",
 drm_crtc_index(_crtc->base));
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 505651b0d715..280d3bd9f675 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -70,14 +70,7 @@ int cmdq_dev_get_client_reg(struct device *dev,
  }
  EXPORT_SYMBOL(cmdq_dev_get_client_reg);

-static void cmdq_client_timeout(struct timer_list *t)
-{
-   struct cmdq_client *client = from_timer(client, t, timer);
-
-   dev_err(client->client.dev, "cmdq timeout!\n");
-}
-
-struct cmdq_client *cmdq_mbox_create(struct device *dev, int index, u32 
timeout)
+struct cmdq_client *cmdq_mbox_create(struct device *dev, int index)
  {
 struct cmdq_client *client;

@@ -85,12 +78,6 @@ struct cmdq_client *cmdq_mbox_create(struct device *dev, int 
index, u32 timeout)
 if (!client)
 return (struct cmdq_client *)-ENOMEM;

-   client->timeout_ms = timeout;
-   if (timeout != CMDQ_NO_TIMEOUT) {
-   spin_lock_init(>lock);
-   timer_setup(>timer, cmdq_client_timeout, 0);
-   }
-   client->pkt_cnt = 0;
 client->client.dev = dev;
 client->client.tx_block = false;
 client->client.knows_txdone = true;
@@ -112,11 +99,6 @@ EXPORT_SYMBOL(cmdq_mbox_create);

  void cmdq_mbox_destroy(struct cmdq_client *client)
  {
-   if (client->timeout_ms != CMDQ_NO_TIMEOUT) {
-   spin_lock(>lock);
-   del_timer_sync(>timer);
-   spin_unlock(>lock);
-   }
 mbox_free_channel(client->chan);
 kfree(client);
  }
@@ -449,18 +431,6 @@ static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data 
data)
 struct cmdq_task_cb *cb = >cb;
 struct cmdq_client *client = (struct cmdq_client *)pkt->cl;

-   if (client->timeout_ms != CMDQ_NO_TIMEOUT) {
-   unsigned long flags = 0;
-
-   spin_lock_irqsave(>lock, flags);
-   if (--client->pkt_cnt == 0)
-   del_timer(>timer);
-   else
-   mod_timer(>timer, jiffies +
- msecs_to_jiffies(client->timeout_ms));
-   spin_unlock_irqrestore(>lock, flags);
-   }
-
 dma_sync_single_for_cpu(client->chan->mbox->dev, pkt->pa_base,
 pkt->cmd_buf_size, DMA_TO_DEVICE);
 if (cb->cb) {
@@ -473,7 +443,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, 
cmdq_async_flush_cb 

[GIT PULL for v5.10-rc6] vidtv driver fixes

[Mauro Carvalho Chehab]

Hi Linus,

Please pull from:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v5.10-3

For a series of fixes for the new the virtual digital TV driver (vidtv),
which is meant to help doing tests with the digital TV core and media
userspace apps and libraries.

They cover a series of issues I found on it, together with a few new things
in order to make it easier to detect problems at the DVB core.


Regards,
Mauro

The following changes since commit 9215f6bb4705ffe205885411394732bfc439dee0:

  media: venus: pm_helpers: Fix kernel module reload (2020-11-16 19:06:10 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v5.10-3

for you to fetch changes up to 44f28934af141149959c4e6495bb60c1903bda32:

  media: vidtv.rst: add kernel-doc markups (2020-11-26 08:05:24 +0100)


media fixes for v5.10-rc6


Daniel W. S. Almeida (6):
  media: vidtv: extract the initial CRC value to into a #define
  media: vidtv: psi: add a Network Information Table (NIT)
  media: vidtv: psi: Implement an Event Information Table (EIT)
  media: vidtv: psi: extract descriptor chaining code into a helper
  media: vidtv: Move s302m specific fields into encoder context
  media: vidtv: psi: fix missing assignments in while loops

Mauro Carvalho Chehab (30):
  media: vidtv: reorganize includes
  media: vidtv: add error checks
  media: vidtv: don't use recursive functions
  media: vidtv: fix the name of the program
  media: vidtv: fix the tone generator logic
  media: vidtv: fix some notes at the tone generator
  media: vidtv: avoid data copy when initializing the multiplexer
  media: vidtv: avoid copying data for PES structs
  media: vidtv: do some cleanups at the driver
  media: vidtv: remove some unused functions
  media: vidtv: pre-initialize mux arrays
  media: vidtv: cleanup null packet initialization logic
  media: vidtv: improve EIT data
  media: vidtv: fix the network ID range
  media: vidtv: properly fill EIT service_id
  media: vidtv: add a PID entry for the NIT table
  media: vidtv: fix service type
  media: vidtv: fix service_id at SDT table
  media: vidtv: add date to the current event
  media: vidtv: simplify PSI write function
  media: vidtv: simplify the crc writing logic
  media: vidtv: cleanup PSI descriptor write function
  media: vidtv: cleanup PSI table header function
  media: vidtv: cleanup PAT write function
  media: vidtv: cleanup PMT write table function
  media: vidtv: simplify SDT write function
  media: vidtv: simplify NIT write function
  media: vidtv: simplify EIT write function
  media: vidtv.rst: update vidtv documentation
  media: vidtv.rst: add kernel-doc markups

 Documentation/driver-api/media/drivers/vidtv.rst |  120 +-
 drivers/media/test-drivers/vidtv/vidtv_bridge.c  |  116 +-
 drivers/media/test-drivers/vidtv/vidtv_bridge.h  |4 +-
 drivers/media/test-drivers/vidtv/vidtv_channel.c |  312 -
 drivers/media/test-drivers/vidtv/vidtv_channel.h |   11 +-
 drivers/media/test-drivers/vidtv/vidtv_common.h  |1 -
 drivers/media/test-drivers/vidtv/vidtv_demod.c   |2 +-
 drivers/media/test-drivers/vidtv/vidtv_demod.h   |   11 +-
 drivers/media/test-drivers/vidtv/vidtv_encoder.h |9 +-
 drivers/media/test-drivers/vidtv/vidtv_mux.c |  248 ++--
 drivers/media/test-drivers/vidtv/vidtv_mux.h |   21 +-
 drivers/media/test-drivers/vidtv/vidtv_pes.c |  179 ++-
 drivers/media/test-drivers/vidtv/vidtv_pes.h |8 +-
 drivers/media/test-drivers/vidtv/vidtv_psi.c | 1521 --
 drivers/media/test-drivers/vidtv/vidtv_psi.h |  282 +++-
 drivers/media/test-drivers/vidtv/vidtv_s302m.c   |  125 +-
 drivers/media/test-drivers/vidtv/vidtv_s302m.h   |9 +-
 drivers/media/test-drivers/vidtv/vidtv_ts.c  |5 +-
 drivers/media/test-drivers/vidtv/vidtv_ts.h  |5 +-
 drivers/media/test-drivers/vidtv/vidtv_tuner.c   |5 +-
 drivers/media/test-drivers/vidtv/vidtv_tuner.h   |1 +
 21 files changed, 2182 insertions(+), 813 deletions(-)

Re: [PATCH v3] arm64: dts: mediatek: Add mt8192 power domains controller

[Matthias Brugger]

On 19/11/2020 15:13, Enric Balletbo Serra wrote:

Hi Weiyi,

Missatge de Weiyi Lu  del dia dj., 19 de nov.
2020 a les 14:10:


On Thu, 2020-11-19 at 13:13 +0100, Enric Balletbo Serra wrote:

Hi Weiyi,

Thank you for the patch

Missatge de Weiyi Lu  del dia dj., 19 de nov.
2020 a les 11:48:


Add power domains controller node for SoC mt8192

Signed-off-by: Weiyi Lu 
---

[...]

+   /* System Power Manager */
+   spm: power-controller {
+   compatible = "mediatek,mt8192-power-controller";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #power-domain-cells = <1>;
+
+   /* power domain of the SoC */
+   audio@MT8192_POWER_DOMAIN_AUDIO {


If you run the dt_bindings_check it should return some errors, as all
these node names should be 'power-domain@'. Which is a bit annoying
because then you will get a bunch of errors like this:

[1.969110] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[1.976997] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[1.984828] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[1.992657] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.000685] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.008566] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.016395] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.024221] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.032049] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.039874] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.047699] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.055524] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.063352] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.071176] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!

But that's another problem that should be handled in debugfs system.



Indeed...so I chose to use different name in dts to avoid problems in
debugfs. It does violate the naming rules.



But your binding will not pass (or trigger warnings) the dtb check
then. Rob was clear that names should be generic. Proper fix is fix
debugfs not the binding.



By the way, is anybody working on this debugfs issue?

Regards,
Matthias

[PATCH] PCI: designware-ep: Fix the pci->num_{ib,ob}_windows reference before they are set

[Kunihiko Hayashi]

The commit 281f1f99cf3a ("PCI: dwc: Detect number of iATU windows") gets
the values of pci->num_ib_windows and pci->num_ob_windows from iATU
registers instead of DT properties.

However, before the values are set, the allocations in dw_pcie_ep_init()
refer them to determine the sizes of window_map. It's necessary to refer
the values after they are set in dw_pcie_setup().

Cc: Rob Herring 
Fixes: 281f1f99cf3a ("PCI: dwc: Detect number of iATU windows")
Signed-off-by: Kunihiko Hayashi 
---
 drivers/pci/controller/dwc/pcie-designware-ep.c | 41 -
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c 
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index bcd1cd9..adc7ca5 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -638,6 +638,7 @@ static unsigned int dw_pcie_ep_find_ext_capability(struct 
dw_pcie *pci, int cap)
 int dw_pcie_ep_init_complete(struct dw_pcie_ep *ep)
 {
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+   struct device *dev = pci->dev;
unsigned int offset;
unsigned int nbars;
u8 hdr_type;
@@ -669,6 +670,25 @@ int dw_pcie_ep_init_complete(struct dw_pcie_ep *ep)
dw_pcie_setup(pci);
dw_pcie_dbi_ro_wr_dis(pci);
 
+   ep->ib_window_map = devm_kcalloc(dev,
+BITS_TO_LONGS(pci->num_ib_windows),
+sizeof(long),
+GFP_KERNEL);
+   if (!ep->ib_window_map)
+   return -ENOMEM;
+
+   ep->ob_window_map = devm_kcalloc(dev,
+BITS_TO_LONGS(pci->num_ob_windows),
+sizeof(long),
+GFP_KERNEL);
+   if (!ep->ob_window_map)
+   return -ENOMEM;
+
+   ep->outbound_addr = devm_kcalloc(dev, pci->num_ob_windows, 
sizeof(phys_addr_t),
+   GFP_KERNEL);
+   if (!ep->outbound_addr)
+   return -ENOMEM;
+
return 0;
 }
 EXPORT_SYMBOL_GPL(dw_pcie_ep_init_complete);
@@ -676,7 +696,6 @@ EXPORT_SYMBOL_GPL(dw_pcie_ep_init_complete);
 int dw_pcie_ep_init(struct dw_pcie_ep *ep)
 {
int ret;
-   void *addr;
u8 func_no;
struct resource *res;
struct pci_epc *epc;
@@ -714,26 +733,6 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
ep->phys_base = res->start;
ep->addr_size = resource_size(res);
 
-   ep->ib_window_map = devm_kcalloc(dev,
-BITS_TO_LONGS(pci->num_ib_windows),
-sizeof(long),
-GFP_KERNEL);
-   if (!ep->ib_window_map)
-   return -ENOMEM;
-
-   ep->ob_window_map = devm_kcalloc(dev,
-BITS_TO_LONGS(pci->num_ob_windows),
-sizeof(long),
-GFP_KERNEL);
-   if (!ep->ob_window_map)
-   return -ENOMEM;
-
-   addr = devm_kcalloc(dev, pci->num_ob_windows, sizeof(phys_addr_t),
-   GFP_KERNEL);
-   if (!addr)
-   return -ENOMEM;
-   ep->outbound_addr = addr;
-
if (pci->link_gen < 1)
pci->link_gen = of_pci_get_max_link_speed(np);
 
-- 
2.7.4

Re: [PATCH] drivers: gpio: use of_match_ptr() and ACPI_PTR() macros

[Enrico Weigelt, metux IT consult]

On 18.11.20 11:01, Andy Shevchenko wrote:

>>> So a system without CONFIG_OF might still make use of .of_match_table?
>>
>> Yep!
> 
> If you are curious:
> https://elixir.bootlin.com/linux/latest/source/drivers/acpi/bus.c#L615

Phuh, this changes everything ... sorry, didn't know that.

If ACPI now can contain OF pieces, we should ask the question whether
of_match_ptr() should be used at all.

Would it be a compromise introducing a new macro (eg. "OF_MATCH_PTR()")
which passes through the pointer if either OF or ACPI is enabled.
Maybe we could introduce a new config item (eg "OF_MATCH_TABLE") for
that, which is enabled by both OF and ACPI. And maybe add an option for
of-compatible checking in ACPI.

How do you folks think about that ?


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

[GIT PULL] Please pull powerpc/linux.git powerpc-5.10-4 tag

[Michael Ellerman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Linus,

Please pull some more powerpc fixes for 5.10.

Note this includes a merge of the powerpc-cve-2020-4788 tag, which you already
have, so that I could fix a build break it introduced. That merge should be a
nop from your POV.

cheers


The following changes since commit da631f7fd623b6c180c8d93a93040d1e0d61291f:

  Linux 5.10-rc2 (2020-11-01 14:43:51 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-5.10-4

for you to fetch changes up to b6b79dd53082db11070b4368d85dd6699ff0b063:

  powerpc/64s: Fix allnoconfig build since uaccess flush (2020-11-23 21:16:42 
+1100)

- --
powerpc fixes for 5.10 #4

A regression fix for a boot failure on some 32-bit machines.

A fix for host crashes in the KVM system reset handling.

A fix for a possible oops in the KVM XIVE interrupt handling on Power9.

A fix for host crashes triggerable via the KVM emulated MMIO handling when
running HPT guests.

A couple of small build fixes.

Thanks to:
  Andreas Schwab, Cédric Le Goater, Christophe Leroy, Erhard Furtner, Greg Kurz,
  Greg Kurz, Németh Márton, Nicholas Piggin, Nick Desaulniers, Serge Belyshev,
  Stephen Rothwell.

- --
Christophe Leroy (1):
  powerpc/32s: Use relocation offset when setting early hash table

Cédric Le Goater (1):
  KVM: PPC: Book3S HV: XIVE: Fix possible oops when accessing ESB page

Michael Ellerman (2):
  powerpc: Drop -me200 addition to build flags
  Merge tag 'powerpc-cve-2020-4788' into fixes

Nicholas Piggin (2):
  powerpc/64s: Fix KVM system reset handling when CONFIG_PPC_PSERIES=y
  powerpc/64s/exception: KVM Fix for host DSI being taken in HPT guest MMU 
context

Stephen Rothwell (1):
  powerpc/64s: Fix allnoconfig build since uaccess flush


 arch/powerpc/Makefile  |  1 -
 arch/powerpc/include/asm/book3s/64/kup-radix.h |  2 ++
 arch/powerpc/kernel/exceptions-64s.S   | 13 +++--
 arch/powerpc/kernel/head_book3s_32.S   |  3 ++-
 arch/powerpc/kvm/book3s_xive_native.c  |  7 +++
 5 files changed, 18 insertions(+), 8 deletions(-)
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl/A8B4ACgkQUevqPMjh
pYCUdQ/9HN2ikGl+dT5h3CoAVZoGsyl6/KQm6t+tVjHHxDWcuH/wOmmpvqRET5th
7uGOJrKEPaWDo3KwmM/Q2Srf74Qtb23n4D62Hi4dTBGoVix1930BIrz/VaQq416T
WwvrZIwbOSOvklbERq/ta4YeXN9fHquAX0dgxQEWPgLugoXCJhKndvAoy+l+0ZLa
F3uOFnqt1IKaQA7wM7I+BbgOlP6rF+VhNPMZmUEvNDsVa6HUhv6/R46c7Un4jKyQ
O8hTn/yz/Sc7kB06LoF9PiHlwtZVuDvwIi+6h5W1LcLCWGIBkEhJkNZ1K6Qwiu7H
YIFvCTLovliLSOYIRjRS+s1a0hSjRUdOcrb/VukzRNP/JFpbzKid8gHkVdG8yEN8
HIXT6W9/YOACr+rviuYJAuA+hk4ll8SHdgbFnr7QGLJKdy9SCUHSWrkgoBHXKig5
eV/bRE0H5WauyqPcct1xP781UKf1zmcNiouvDXmRBoAJalRSVFB5HxpN+GKPQxwu
la/lv/eAujuydJYxlgCHu8pNbn/DhPsIPpbNnXLNOYxiWR8LXESkt4I7dxPJQxvr
pkWuR+T1FAXzF6tor+iK8anpmAmXKrWFQNSC2cCnqBdGtORdARztjHhVWgOCQLiR
H0mN8abC+b7h6LVsRsDieZt5u0+o+G69FvNLxaPQymvnDaQtbQI=
=7BPy
-END PGP SIGNATURE-

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

[John Garry]

On 27/11/2020 09:57, Marc Zyngier wrote:

If I understand the code correctly, MSI_ALLOC_FLAGS_SHARED_DEVICE is
supposed to be set in info->flags in platform_msi_set_desc(), but this
is called per-msi after its_msi_prepare(), so we don't the flags set
at the right time. That's how it looks to me...


Meh. I was trying multiple things, and of course commited the worse
possible approach.

I've updated the branch, having verified that we do get the flag in
the ITS now.


Hi Marc,

That looks to work.

So do you have an upstream plan for this? I ask, as if you go with this, 
then I may change my series to map and unmap all the irqs again - but 
not sure about that.


Thanks,
John

Re: [PATCH] block/rnbd: Adding name to the Contributors List

[Jinpu Wang]

On Fri, Nov 27, 2020 at 1:31 PM Swapnil Ingle  wrote:
>
> Adding name to the Contributors List
>
> Signed-off-by: Swapnil Ingle 
Hi, Swapnil,

Thanks for your past contributions, sorry for missing your name on the list.
Acked-by: Jack Wang 
> ---
>  drivers/block/rnbd/README | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/block/rnbd/README b/drivers/block/rnbd/README
> index 1773c0a..080f58a 100644
> --- a/drivers/block/rnbd/README
> +++ b/drivers/block/rnbd/README
> @@ -90,3 +90,4 @@ Kleber Souza 
>  Lutz Pogrell 
>  Milind Dumbare 
>  Roman Penyaev 
> +Swapnil Ingle 
> --
> 1.8.3.1
>

Re: [PATCH v2 1/3] genirq/affinity: Add irq_update_affinity_desc()

[Marc Zyngier]

On 2020-11-27 12:45, John Garry wrote:

On 27/11/2020 09:57, Marc Zyngier wrote:

If I understand the code correctly, MSI_ALLOC_FLAGS_SHARED_DEVICE is
supposed to be set in info->flags in platform_msi_set_desc(), but 
this

is called per-msi after its_msi_prepare(), so we don't the flags set
at the right time. That's how it looks to me...


Meh. I was trying multiple things, and of course commited the worse
possible approach.

I've updated the branch, having verified that we do get the flag in
the ITS now.


Hi Marc,

That looks to work.


Thanks for having given it a go.


So do you have an upstream plan for this? I ask, as if you go with
this, then I may change my series to map and unmap all the irqs again
- but not sure about that.


I'll write some commit messages, and post that. Either this weekend,
or on Monday at the latest.

Thanks,

M.
--
Jazz is not dead. It just smells funny...

Re: [PATCH 0/2] KVM: x86: cleanup and fix userspace interrupt window

[David Woodhouse]

On Fri, 2020-11-27 at 06:21 -0500, Paolo Bonzini wrote:
> This is my take on the split irqchip bug that David reported.  It's a
> much more complicated patch, but I think it really gets to the bottom
> of the issue and the code is clearer.


Looks good to me; thanks. With the exception of the stray apostrophe
already noted, both:

Reviewed-by: David Woodhouse 
Tested-by: David Woodhouse 

There is a slight caveat that I think we're accepting ExtINT from
userspace PIC sooner than we should, and queuing it up for delivery in
the kernel.

Whereas real hardware might not issue the INTA cycle to ask the PIC
what vector it wants until later. By which time the PIC might give a
different answer. But I don't think anyone cares, even if it can make
an observable difference in practice. And I'm not sure that it's new
with your patches either.



smime.p7s
Description: S/MIME cryptographic signature

[PATCH v2 2/3] drm/msm: Add speed-bin support for a618 gpu

[Akhil P Oommen]

Extend speed-bin support to a618 gpu.

Signed-off-by: Akhil P Oommen 
---
 drivers/gpu/drm/msm/adreno/adreno_device.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index e0ff16c..21db7ae 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -18,6 +18,7 @@ bool snapshot_debugbus = false;
 MODULE_PARM_DESC(snapshot_debugbus, "Include debugbus sections in GPU 
devcoredump (if not fused off)");
 module_param_named(snapshot_debugbus, snapshot_debugbus, bool, 0600);
 
+const u32 a618_speedbins[] = {0, 169, 174};
 const u32 a530v2_speedbins[] = {0, 1, 2, 3, 4, 5, 6, 7};
 
 static const struct adreno_info gpulist[] = {
@@ -196,6 +197,8 @@ static const struct adreno_info gpulist[] = {
.gmem = SZ_512K,
.inactive_period = DRM_MSM_INACTIVE_PERIOD,
.init = a6xx_gpu_init,
+   .speedbins = a618_speedbins,
+   .speedbins_count = ARRAY_SIZE(a618_speedbins),
}, {
.rev = ADRENO_REV(6, 3, 0, ANY_ID),
.revn = 630,
-- 
2.7.4

[PATCH v2 3/3] arm: dts: sc7180: Add support for gpu fuse

[Akhil P Oommen]

Add support for gpu fuse to help identify the supported opps.

Signed-off-by: Akhil P Oommen 
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 6678f1e..8cae3eb 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -675,6 +675,11 @@
reg = <0x25b 0x1>;
bits = <1 3>;
};
+
+   gpu_speed_bin: gpu_speed_bin@1d2 {
+   reg = <0x1d2 0x2>;
+   bits = <5 8>;
+   };
};
 
sdhc_1: sdhci@7c4000 {
@@ -1907,52 +1912,69 @@
operating-points-v2 = <_opp_table>;
qcom,gmu = <>;
 
+   nvmem-cells = <_speed_bin>;
+   nvmem-cell-names = "speed_bin";
+
interconnects = <_noc MASTER_GFX3D 0 _virt 
SLAVE_EBI1 0>;
interconnect-names = "gfx-mem";
 
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
 
+   opp-82500 {
+   opp-hz = /bits/ 64 <82500>;
+   opp-level = 
;
+   opp-peak-kBps = <8532000>;
+   opp-supported-hw = <0x04>;
+   };
+
opp-8 {
opp-hz = /bits/ 64 <8>;
opp-level = 
;
opp-peak-kBps = <8532000>;
+   opp-supported-hw = <0x07>;
};
 
opp-65000 {
opp-hz = /bits/ 64 <65000>;
opp-level = 
;
opp-peak-kBps = <7216000>;
+   opp-supported-hw = <0x07>;
};
 
opp-56500 {
opp-hz = /bits/ 64 <56500>;
opp-level = ;
opp-peak-kBps = <5412000>;
+   opp-supported-hw = <0x07>;
};
 
opp-43000 {
opp-hz = /bits/ 64 <43000>;
opp-level = 
;
opp-peak-kBps = <5412000>;
+   opp-supported-hw = <0x07>;
};
 
opp-35500 {
opp-hz = /bits/ 64 <35500>;
opp-level = ;
opp-peak-kBps = <3072000>;
+   opp-supported-hw = <0x07>;
};
 
opp-26700 {
opp-hz = /bits/ 64 <26700>;
opp-level = 
;
opp-peak-kBps = <3072000>;
+   opp-supported-hw = <0x07>;
};
 
opp-18000 {
opp-hz = /bits/ 64 <18000>;
opp-level = 
;
opp-peak-kBps = <1804000>;
+   opp-supported-hw = <0x07>;
};
};
};
-- 
2.7.4

[PATCH v2 1/3] drm/msm: adreno: Make speed-bin support generic

[Akhil P Oommen]

So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation to
extend speed-bin support to a6x family.

Signed-off-by: Akhil P Oommen 
---
Changes from v1:
1. Added the changes to support a618 sku to the series.
2. Avoid failing probe in case of an unsupported sku. (Rob)

 drivers/gpu/drm/msm/adreno/a5xx_gpu.c  | 34 --
 drivers/gpu/drm/msm/adreno/adreno_device.c |  4 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c| 71 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|  5 +++
 4 files changed, 80 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 8fa5c91..7d42321 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1531,38 +1531,6 @@ static const struct adreno_gpu_funcs funcs = {
.get_timestamp = a5xx_get_timestamp,
 };
 
-static void check_speed_bin(struct device *dev)
-{
-   struct nvmem_cell *cell;
-   u32 val;
-
-   /*
-* If the OPP table specifies a opp-supported-hw property then we have
-* to set something with dev_pm_opp_set_supported_hw() or the table
-* doesn't get populated so pick an arbitrary value that should
-* ensure the default frequencies are selected but not conflict with any
-* actual bins
-*/
-   val = 0x80;
-
-   cell = nvmem_cell_get(dev, "speed_bin");
-
-   if (!IS_ERR(cell)) {
-   void *buf = nvmem_cell_read(cell, NULL);
-
-   if (!IS_ERR(buf)) {
-   u8 bin = *((u8 *) buf);
-
-   val = (1 << bin);
-   kfree(buf);
-   }
-
-   nvmem_cell_put(cell);
-   }
-
-   dev_pm_opp_set_supported_hw(dev, , 1);
-}
-
 struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
 {
struct msm_drm_private *priv = dev->dev_private;
@@ -1588,8 +1556,6 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
 
a5xx_gpu->lm_leakage = 0x4E001A;
 
-   check_speed_bin(>dev);
-
ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 4);
if (ret) {
a5xx_destroy(&(a5xx_gpu->base.base));
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 87c8b03..e0ff16c 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -18,6 +18,8 @@ bool snapshot_debugbus = false;
 MODULE_PARM_DESC(snapshot_debugbus, "Include debugbus sections in GPU 
devcoredump (if not fused off)");
 module_param_named(snapshot_debugbus, snapshot_debugbus, bool, 0600);
 
+const u32 a530v2_speedbins[] = {0, 1, 2, 3, 4, 5, 6, 7};
+
 static const struct adreno_info gpulist[] = {
{
.rev   = ADRENO_REV(2, 0, 0, 0),
@@ -163,6 +165,8 @@ static const struct adreno_info gpulist[] = {
ADRENO_QUIRK_FAULT_DETECT_MASK,
.init = a5xx_gpu_init,
.zapfw = "a530_zap.mdt",
+   .speedbins = a530v2_speedbins,
+   .speedbins_count = ARRAY_SIZE(a530v2_speedbins),
}, {
.rev = ADRENO_REV(5, 4, 0, 2),
.revn = 540,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index f21561d..b342fa4 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "adreno_gpu.h"
 #include "msm_gem.h"
@@ -891,6 +892,69 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem 
*adreno_ocmem)
   adreno_ocmem->hdl);
 }
 
+static int adreno_set_supported_hw(struct device *dev,
+   struct adreno_gpu *adreno_gpu)
+{
+   u8 speedbins_count = adreno_gpu->info->speedbins_count;
+   const u32 *speedbins = adreno_gpu->info->speedbins;
+   struct nvmem_cell *cell;
+   u32 bin, i;
+   u32 val = 0;
+   void *buf, *opp_table;
+
+   cell = nvmem_cell_get(dev, "speed_bin");
+   /*
+* -ENOENT means that the platform doesn't support speedbin which is
+* fine
+*/
+   if (PTR_ERR(cell) == -ENOENT)
+   return 0;
+   else if (IS_ERR(cell))
+   return PTR_ERR(cell);
+
+   if (!speedbins)
+   goto done;
+
+   buf = nvmem_cell_read(cell, NULL);
+   if (IS_ERR(buf)) {
+   nvmem_cell_put(cell);
+   return PTR_ERR(buf);
+   }
+
+   bin = *((u32 *) buf);
+
+   for (i = 0; i < speedbins_count; i++) {
+   if (bin == speedbins[i]) {
+   val = (1 << i);
+   break;
+   }
+   }
+
+   kfree(buf);
+done:
+   nvmem_cell_put(cell);
+
+   if 

Re: [Freedreno] [PATCH] drm/msm: adreno: Make speed-bin support generic

[Akhil P Oommen]

On 11/16/2020 10:44 PM, Jordan Crouse wrote:

On Mon, Nov 16, 2020 at 07:40:03PM +0530, Akhil P Oommen wrote:

On 11/12/2020 10:05 PM, Jordan Crouse wrote:

On Thu, Nov 12, 2020 at 09:19:04PM +0530, Akhil P Oommen wrote:

So far a530v2 gpu has support for detecting its supported opps
based on a fuse value called speed-bin. This patch makes this
support generic across gpu families. This is in preparation to
extend speed-bin support to a6x family.

Signed-off-by: Akhil P Oommen 
---
This patch is rebased on top of msm-next-staging branch in rob's tree.

  drivers/gpu/drm/msm/adreno/a5xx_gpu.c  | 34 --
  drivers/gpu/drm/msm/adreno/adreno_device.c |  4 ++
  drivers/gpu/drm/msm/adreno/adreno_gpu.c| 71 ++
  drivers/gpu/drm/msm/adreno/adreno_gpu.h|  5 +++
  4 files changed, 80 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 8fa5c91..7d42321 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1531,38 +1531,6 @@ static const struct adreno_gpu_funcs funcs = {
.get_timestamp = a5xx_get_timestamp,
  };
-static void check_speed_bin(struct device *dev)
-{
-   struct nvmem_cell *cell;
-   u32 val;
-
-   /*
-* If the OPP table specifies a opp-supported-hw property then we have
-* to set something with dev_pm_opp_set_supported_hw() or the table
-* doesn't get populated so pick an arbitrary value that should
-* ensure the default frequencies are selected but not conflict with any
-* actual bins
-*/
-   val = 0x80;
-
-   cell = nvmem_cell_get(dev, "speed_bin");
-
-   if (!IS_ERR(cell)) {
-   void *buf = nvmem_cell_read(cell, NULL);
-
-   if (!IS_ERR(buf)) {
-   u8 bin = *((u8 *) buf);
-
-   val = (1 << bin);
-   kfree(buf);
-   }
-
-   nvmem_cell_put(cell);
-   }
-
-   dev_pm_opp_set_supported_hw(dev, , 1);
-}
-
  struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
  {
struct msm_drm_private *priv = dev->dev_private;
@@ -1588,8 +1556,6 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
a5xx_gpu->lm_leakage = 0x4E001A;
-   check_speed_bin(>dev);
-
ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 4);
if (ret) {
a5xx_destroy(&(a5xx_gpu->base.base));
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 87c8b03..e0ff16c 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -18,6 +18,8 @@ bool snapshot_debugbus = false;
  MODULE_PARM_DESC(snapshot_debugbus, "Include debugbus sections in GPU devcoredump 
(if not fused off)");
  module_param_named(snapshot_debugbus, snapshot_debugbus, bool, 0600);
+const u32 a530v2_speedbins[] = {0, 1, 2, 3, 4, 5, 6, 7};
+
  static const struct adreno_info gpulist[] = {
{
.rev   = ADRENO_REV(2, 0, 0, 0),
@@ -163,6 +165,8 @@ static const struct adreno_info gpulist[] = {
ADRENO_QUIRK_FAULT_DETECT_MASK,
.init = a5xx_gpu_init,
.zapfw = "a530_zap.mdt",
+   .speedbins = a530v2_speedbins,
+   .speedbins_count = ARRAY_SIZE(a530v2_speedbins),
}, {
.rev = ADRENO_REV(5, 4, 0, 2),
.revn = 540,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index f21561d..cdd0c11 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include "adreno_gpu.h"
  #include "msm_gem.h"
@@ -891,6 +892,69 @@ void adreno_gpu_ocmem_cleanup(struct adreno_ocmem 
*adreno_ocmem)
   adreno_ocmem->hdl);
  }
+static int adreno_set_supported_hw(struct device *dev,
+   struct adreno_gpu *adreno_gpu)
+{
+   u8 speedbins_count = adreno_gpu->info->speedbins_count;
+   const u32 *speedbins = adreno_gpu->info->speedbins;


We don't need to make this generic and put it in the table. Just call the
function from the target specific code and pass the speedbin array and size from
there.


I didn't get you entirely. Do you mean we should avoid keeping speedbin
array in the adreno_gpu->info table?


Exactly.

Jordan
But why duplicate this code if it can be made generic? Could you please 
check the v2 version?


-Akhil.



-Akhil.

+   struct nvmem_cell *cell;
+   u32 bin, i;
+   u32 val = 0;
+   void *buf, *opp_table;
+
+   cell = nvmem_cell_get(dev, "speed_bin");
+   /*
+* -ENOENT means that the platform doesn't support speedbin which is
+* fine
+*/
+   if (PTR_ERR(cell) == -ENOENT)
+   return 0;
+  

[PATCH v2 2/3] mfd: si476x-core.h: fix "regulator" spelling in comment

[Michael Klein]

"regualtor" -> "regulator"

Signed-off-by: Michael Klein 
---
Changes in v2:
  - split patch
  - make subject line more forthcoming

 include/linux/mfd/si476x-core.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mfd/si476x-core.h b/include/linux/mfd/si476x-core.h
index 4708c2b8512a..dd95c37ca134 100644
--- a/include/linux/mfd/si476x-core.h
+++ b/include/linux/mfd/si476x-core.h
@@ -57,7 +57,7 @@ enum si476x_mfd_cells {
  * @SI476X_POWER_DOWN: In this state all regulators are turned off
  * and the reset line is pulled low. The device is completely
  * inactive.
- * @SI476X_POWER_UP_FULL: In this state all the power regualtors are
+ * @SI476X_POWER_UP_FULL: In this state all the power regulators are
  * turned on, reset line pulled high, IRQ line is enabled(polling is
  * active for polling use scenario) and device is turned on with
  * POWER_UP command. The device is ready to be used.
-- 
2.29.2

[PATCH v2 3/3] mfd: da9055: fix "REGULATOR" spelling in register content macro

[Michael Klein]

"REGUALTOR" -> "REGULATOR"

Signed-off-by: Michael Klein 
---
Changes in v2:
  - split patch
  - make subject line more forthcoming

 drivers/regulator/da9055-regulator.c | 4 ++--
 include/linux/mfd/da9055/reg.h   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/da9055-regulator.c 
b/drivers/regulator/da9055-regulator.c
index 73ff5fc7d8d7..c0394ac5e60a 100644
--- a/drivers/regulator/da9055-regulator.c
+++ b/drivers/regulator/da9055-regulator.c
@@ -184,7 +184,7 @@ static int da9055_regulator_get_voltage_sel(struct 
regulator_dev *rdev)
ret &= info->conf.sel_mask;
 
/* Get the voltage for the active register set A/B */
-   if (ret == DA9055_REGUALTOR_SET_A)
+   if (ret == DA9055_REGULATOR_SET_A)
ret = da9055_reg_read(regulator->da9055, volt.reg_a);
else
ret = da9055_reg_read(regulator->da9055, volt.reg_b);
@@ -231,7 +231,7 @@ static int da9055_regulator_set_voltage_sel(struct 
regulator_dev *rdev,
ret &= info->conf.sel_mask;
 
/* Set the voltage */
-   if (ret == DA9055_REGUALTOR_SET_A)
+   if (ret == DA9055_REGULATOR_SET_A)
return da9055_reg_update(regulator->da9055, info->volt.reg_a,
 info->volt.v_mask, selector);
else
diff --git a/include/linux/mfd/da9055/reg.h b/include/linux/mfd/da9055/reg.h
index 54a717b6c3de..1204e6b152d5 100644
--- a/include/linux/mfd/da9055/reg.h
+++ b/include/linux/mfd/da9055/reg.h
@@ -344,8 +344,8 @@
 #defineDA9055_VLDO_GPI_MASK0x60
 #defineDA9055_LDO_CONF_SHIFT   0x07
 #defineDA9055_LDO_CONF_MASK0x80
-#defineDA9055_REGUALTOR_SET_A  0x00
-#defineDA9055_REGUALTOR_SET_B  0x10
+#defineDA9055_REGULATOR_SET_A  0x00
+#defineDA9055_REGULATOR_SET_B  0x10
 
 /* DA9055_REG_ADC_MAN (addr=0x1B) */
 #defineDA9055_ADC_MUX_SHIFT0
-- 
2.29.2

Re: [PATCH 1/2] KVM: x86: handle !lapic_in_kernel case in kvm_cpu_*_extint

[Filippo Sironi]

On 11/27/20 12:21 PM, Paolo Bonzini wrote:


Centralize handling of interrupts from the userspace APIC
in kvm_cpu_has_extint and kvm_cpu_get_extint, since
userspace APIC interrupts are handled more or less the
same as ExtINTs are with split irqchip.  This removes
duplicated code from kvm_cpu_has_injectable_intr and
kvm_cpu_has_interrupt, and makes the code more similar
between kvm_cpu_has_{extint,interrupt} on one side
and kvm_cpu_get_{extint,interrupt} on the other.

Cc: sta...@vger.kernel.org
Signed-off-by: Paolo Bonzini 
---
  arch/x86/kvm/irq.c   | 85 ++--
  arch/x86/kvm/lapic.c |  2 +-
  2 files changed, 35 insertions(+), 52 deletions(-)

diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index 99d118ffc67d..e2d49a506e7f 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -42,15 +42,27 @@ static int pending_userspace_extint(struct kvm_vcpu *v)
   */
  static int kvm_cpu_has_extint(struct kvm_vcpu *v)
  {
-   u8 accept = kvm_apic_accept_pic_intr(v);
+   /*
+* FIXME: interrupt.injected represents an interrupt that it's
+* side-effects have already been applied (e.g. bit from IRR
+* already moved to ISR). Therefore, it is incorrect to rely
+* on interrupt.injected to know if there is a pending
+* interrupt in the user-mode LAPIC.
+* This leads to nVMX/nSVM not be able to distinguish
+* if it should exit from L2 to L1 on EXTERNAL_INTERRUPT on
+* pending interrupt or should re-inject an injected
+* interrupt.
+*/
+   if (!lapic_in_kernel(v))
+   return v->arch.interrupt.injected;

-   if (accept) {
-   if (irqchip_split(v->kvm))
-   return pending_userspace_extint(v);
-   else
-   return v->kvm->arch.vpic->output;
-   } else
+   if (!kvm_apic_accept_pic_intr(v))
 return 0;
+
+   if (irqchip_split(v->kvm))
+   return pending_userspace_extint(v);
+   else
+   return v->kvm->arch.vpic->output;
  }

  /*
@@ -61,20 +73,6 @@ static int kvm_cpu_has_extint(struct kvm_vcpu *v)
   */
  int kvm_cpu_has_injectable_intr(struct kvm_vcpu *v)
  {
-   /*
-* FIXME: interrupt.injected represents an interrupt that it's
-* side-effects have already been applied (e.g. bit from IRR
-* already moved to ISR). Therefore, it is incorrect to rely
-* on interrupt.injected to know if there is a pending
-* interrupt in the user-mode LAPIC.
-* This leads to nVMX/nSVM not be able to distinguish
-* if it should exit from L2 to L1 on EXTERNAL_INTERRUPT on
-* pending interrupt or should re-inject an injected
-* interrupt.
-*/
-   if (!lapic_in_kernel(v))
-   return v->arch.interrupt.injected;
-
 if (kvm_cpu_has_extint(v))
 return 1;

@@ -91,20 +89,6 @@ EXPORT_SYMBOL_GPL(kvm_cpu_has_injectable_intr);
   */
  int kvm_cpu_has_interrupt(struct kvm_vcpu *v)
  {
-   /*
-* FIXME: interrupt.injected represents an interrupt that it's
-* side-effects have already been applied (e.g. bit from IRR
-* already moved to ISR). Therefore, it is incorrect to rely
-* on interrupt.injected to know if there is a pending
-* interrupt in the user-mode LAPIC.
-* This leads to nVMX/nSVM not be able to distinguish
-* if it should exit from L2 to L1 on EXTERNAL_INTERRUPT on
-* pending interrupt or should re-inject an injected
-* interrupt.
-*/
-   if (!lapic_in_kernel(v))
-   return v->arch.interrupt.injected;
-
 if (kvm_cpu_has_extint(v))
 return 1;

@@ -118,16 +102,21 @@ EXPORT_SYMBOL_GPL(kvm_cpu_has_interrupt);
   */
  static int kvm_cpu_get_extint(struct kvm_vcpu *v)
  {
-   if (kvm_cpu_has_extint(v)) {
-   if (irqchip_split(v->kvm)) {
-   int vector = v->arch.pending_external_vector;
-
-   v->arch.pending_external_vector = -1;
-   return vector;
-   } else
-   return kvm_pic_read_irq(v->kvm); /* PIC */
-   } else
+   if (!kvm_cpu_has_extint(v)) {
+   WARN_ON(!lapic_in_kernel(v));
 return -1;
+   }
+
+   if (!lapic_in_kernel(v))
+   return v->arch.interrupt.nr;
+
+   if (irqchip_split(v->kvm)) {
+   int vector = v->arch.pending_external_vector;
+
+   v->arch.pending_external_vector = -1;
+   return vector;
+   } else
+   return kvm_pic_read_irq(v->kvm); /* PIC */
  }

  /*
@@ -135,13 +124,7 @@ static int kvm_cpu_get_extint(struct kvm_vcpu *v)
   */
  int kvm_cpu_get_interrupt(struct kvm_vcpu *v)
  {
-   int vector;
-
-   if (!lapic_in_kernel(v))
-   return v->arch.interrupt.nr;
-
-   vector = 

[PATCH v3 0/2] usb: typec: tps6598x: Export some power supply properties

[Guido Günther]

This allows downstream supplies and userspace to detect whether external power
is supplied.

The Librem 5 has the tp65982 in front of bq25980 charge controller.  Since that
is capable of sinking and sourcing power the online property helps to decide
what to do. It also makes upower happy.

There will be follow up patches providing more properties but these need some
more time to cook and i wanted to check if this is the right way to go?

changes from v2
  - As per kernel test robot
https://lore.kernel.org/linux-usb/202011271005.zjvawx74-...@intel.com/
- Flip USB_ROLE_SWITCH and REGMAP_I2C from 'depends on' to 'select'
  This matches tcpm and avoids a config symbol recursion which went
  unnoticed on my arm64 build but trips up x86_64.

changes from v1
  - As per review comments from Heikki Krogerus

https://lore.kernel.org/linux-usb/20201126123552.gp1008...@kuha.fi.intel.com/
- select POWER_SUPPLY
- use POWER_SUPPLY_USB_TYPE_PD when a PD contract got negotiated

To: Heikki Krogerus ,Greg Kroah-Hartman 
,linux-...@vger.kernel.org,linux-kernel@vger.kernel.org

Guido Günther (2):
  usb: typc: tps6598x: Select USB_ROLE_SWITCH and REGMAP_I2C
  usb: typec: tps6598x: Export some power supply properties

 drivers/usb/typec/Kconfig|   5 +-
 drivers/usb/typec/tps6598x.c | 105 +++
 2 files changed, 108 insertions(+), 2 deletions(-)

-- 
2.29.2

[PATCH v3 1/2] usb: typc: tps6598x: Select USB_ROLE_SWITCH and REGMAP_I2C

[Guido Günther]

This is more in line with what tcpm does and will be needed
to avoid recursive dependency like

 > drivers/power/supply/Kconfig:2:error: recursive dependency detected!
   drivers/power/supply/Kconfig:2: symbol POWER_SUPPLY is selected by 
TYPEC_TPS6598X
   drivers/usb/typec/Kconfig:64: symbol TYPEC_TPS6598X depends on REGMAP_I2C
   drivers/base/regmap/Kconfig:19: symbol REGMAP_I2C is selected by 
CHARGER_ADP5061
   drivers/power/supply/Kconfig:93: symbol CHARGER_ADP5061 depends on 
POWER_SUPPLY
   For a resolution refer to Documentation/kbuild/kconfig-language.rst
   subsection "Kconfig recursive dependency limitations"

when selecting POWER_SUPPLY.

Signed-off-by: Guido Günther 
---
 drivers/usb/typec/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 6c5908a37ee8..772b07e9f188 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -64,8 +64,8 @@ config TYPEC_HD3SS3220
 config TYPEC_TPS6598X
tristate "TI TPS6598x USB Power Delivery controller driver"
depends on I2C
-   depends on REGMAP_I2C
-   depends on USB_ROLE_SWITCH || !USB_ROLE_SWITCH
+   select REGMAP_I2C
+   select USB_ROLE_SWITCH
help
  Say Y or M here if your system has TI TPS65982 or TPS65983 USB Power
  Delivery controller.
-- 
2.29.2

[PATCH v2 1/3] Documentation: mcp16502-regulator: fix spelling mistake

[Michael Klein]

Signed-off-by: Michael Klein 
---
  No changes in v2

 .../devicetree/bindings/regulator/mcp16502-regulator.txt| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt 
b/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
index b8f843fa6092..d86584ed4d93 100644
--- a/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt
@@ -10,7 +10,7 @@ Required properties:
   name. The content of each sub-node is defined by the
   standard binding for regulators; see regulator.txt.
 
-Regualtors of MCP16502 PMIC:
+Regulators of MCP16502 PMIC:
 1) VDD_IO  - Buck (1.2 - 3.7 V)
 2) VDD_DDR - Buck (0.6 - 1.85 V)
 3) VDD_CORE- Buck (0.6 - 1.85 V)
-- 
2.29.2

Re: [PATCH 2/2] KVM: x86: Fix split-irqchip vs interrupt injection window request

[Filippo Sironi]

On 11/27/20 12:21 PM, Paolo Bonzini wrote:


kvm_cpu_accept_dm_intr and kvm_vcpu_ready_for_interrupt_injection are
a hodge-podge of conditions, hacked together to get something that
more or less works.  But what is actually needed is much simpler;
in both cases the fundamental question is, do we have a place to stash
an interrupt if userspace does KVM_INTERRUPT?

In userspace irqchip mode, that is !vcpu->arch.interrupt.injected.
Currently kvm_event_needs_reinjection(vcpu) covers it, but it is
unnecessarily restrictive.

In split irqchip mode it's a bit more complicated, we need to check
kvm_apic_accept_pic_intr(vcpu) (the IRQ window exit is basically an INTACK
cycle and thus requires ExtINTs not to be masked) as well as
!pending_userspace_extint(vcpu).  However, there is no need to
check kvm_event_needs_reinjection(vcpu), since split irqchip keeps
pending ExtINT state separate from event injection state, and checking
kvm_cpu_has_interrupt(vcpu) is wrong too since ExtINT has higher
priority than APIC interrupts.  In fact the latter fixes a bug:
when userspace requests an IRQ window vmexit, an interrupt in the
local APIC can cause kvm_cpu_has_interrupt() to be true and thus
kvm_vcpu_ready_for_interrupt_injection() to return false.  When this
happens, vcpu_run does not exit to userspace but the interrupt window
vmexits keep occurring.  The VM loops without any hope of making progress.

Once we try to fix these with something like

  return kvm_arch_interrupt_allowed(vcpu) &&
-!kvm_cpu_has_interrupt(vcpu) &&
-!kvm_event_needs_reinjection(vcpu) &&
-kvm_cpu_accept_dm_intr(vcpu);
+(!lapic_in_kernel(vcpu)
+ ? !vcpu->arch.interrupt.injected
+ : (kvm_apic_accept_pic_intr(vcpu)
+&& !pending_userspace_extint(v)));

we realize two things.  First, thanks to the previous patch the complex
conditional can reuse !kvm_cpu_has_extint(vcpu).  Second, the interrupt
window request in vcpu_enter_guest()

 bool req_int_win =
 dm_request_for_irq_injection(vcpu) &&
 kvm_cpu_accept_dm_intr(vcpu);

should be kept in sync with kvm_vcpu_ready_for_interrupt_injection():
it is unnecessary to ask the processor for an interrupt window
if we would not be able to return to userspace.  Therefore, the
complex conditional is really the correct implementation of
kvm_cpu_accept_dm_intr(vcpu).  It all makes sense:

- we can accept an interrupt from userspace if there is a place
   to stash it (and, for irqchip split, ExtINTs are not masked).
   Interrupts from userspace _can_ be accepted even if right now
   EFLAGS.IF=0.

- in order to tell userspace we will inject its interrupt ("IRQ
   window open" i.e. kvm_vcpu_ready_for_interrupt_injection), both
   KVM and the vCPU need to be ready to accept the interrupt.

... and this is what the patch implements.

Reported-by: David Woodhouse 
Analyzed-by: David Woodhouse 
Cc: sta...@vger.kernel.org
Signed-off-by: Paolo Bonzini 
---
  arch/x86/include/asm/kvm_host.h |  1 +
  arch/x86/kvm/irq.c  |  2 +-
  arch/x86/kvm/x86.c  | 17 +++--
  3 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index d44858b69353..ddaf3e01a854 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1655,6 +1655,7 @@ int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
  int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
  int kvm_cpu_has_injectable_intr(struct kvm_vcpu *v);
  int kvm_cpu_has_interrupt(struct kvm_vcpu *vcpu);
+int kvm_cpu_has_extint(struct kvm_vcpu *v);
  int kvm_arch_interrupt_allowed(struct kvm_vcpu *vcpu);
  int kvm_cpu_get_interrupt(struct kvm_vcpu *v);
  void kvm_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event);
diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index e2d49a506e7f..fa01f07e449e 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -40,7 +40,7 @@ static int pending_userspace_extint(struct kvm_vcpu *v)
   * check if there is pending interrupt from
   * non-APIC source without intack.
   */
-static int kvm_cpu_has_extint(struct kvm_vcpu *v)
+int kvm_cpu_has_extint(struct kvm_vcpu *v)
  {
 /*
  * FIXME: interrupt.injected represents an interrupt that it's
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 447edc0d1d5a..54124b6211df 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4051,21 +4051,22 @@ static int kvm_vcpu_ioctl_set_lapic(struct kvm_vcpu 
*vcpu,

  static int kvm_cpu_accept_dm_intr(struct kvm_vcpu *vcpu)
  {
-   return (!lapic_in_kernel(vcpu) ||
-   kvm_apic_accept_pic_intr(vcpu));
+   /*
+* We can accept userspace's request for interrupt injection
+* as long as we have a place to store the interrupt number.
+* The actual injection will happen when the CPU is able to
+* deliver the interrupt.
+*/
+   if 

[PATCH v3 2/2] usb: typec: tps6598x: Export some power supply properties

[Guido Günther]

This allows downstream supplies and userspace to detect
whether external power is supplied.

Signed-off-by: Guido Günther 
---
 drivers/usb/typec/Kconfig|   1 +
 drivers/usb/typec/tps6598x.c | 105 +++
 2 files changed, 106 insertions(+)

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 772b07e9f188..365f905a8e49 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -64,6 +64,7 @@ config TYPEC_HD3SS3220
 config TYPEC_TPS6598X
tristate "TI TPS6598x USB Power Delivery controller driver"
depends on I2C
+   select POWER_SUPPLY
select REGMAP_I2C
select USB_ROLE_SWITCH
help
diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
index 3db33bb622c3..8163306f849e 100644
--- a/drivers/usb/typec/tps6598x.c
+++ b/drivers/usb/typec/tps6598x.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -55,6 +56,7 @@ enum {
 };
 
 /* TPS_REG_POWER_STATUS bits */
+#define TPS_POWER_STATUS_CONNECTIONBIT(0)
 #define TPS_POWER_STATUS_SOURCESINKBIT(1)
 #define TPS_POWER_STATUS_PWROPMODE(p)  (((p) & GENMASK(3, 2)) >> 2)
 
@@ -96,8 +98,25 @@ struct tps6598x {
struct typec_partner *partner;
struct usb_pd_identity partner_identity;
struct usb_role_switch *role_sw;
+   struct typec_capability typec_cap;
+
+   struct power_supply *psy;
+   struct power_supply_desc psy_desc;
+   enum power_supply_usb_type usb_type;
+};
+
+static enum power_supply_property tps6598x_psy_props[] = {
+   POWER_SUPPLY_PROP_USB_TYPE,
+   POWER_SUPPLY_PROP_ONLINE,
 };
 
+static enum power_supply_usb_type tps6598x_psy_usb_types[] = {
+   POWER_SUPPLY_USB_TYPE_C,
+   POWER_SUPPLY_USB_TYPE_PD,
+};
+
+static const char *tps6598x_psy_name_prefix = "tps6598x-source-psy-";
+
 /*
  * Max data bytes for Data1, Data2, and other registers. See ch 1.3.2:
  * https://www.ti.com/lit/ug/slvuan1a/slvuan1a.pdf
@@ -248,6 +267,8 @@ static int tps6598x_connect(struct tps6598x *tps, u32 
status)
if (desc.identity)
typec_partner_set_identity(tps->partner);
 
+   power_supply_changed(tps->psy);
+
return 0;
 }
 
@@ -260,6 +281,7 @@ static void tps6598x_disconnect(struct tps6598x *tps, u32 
status)
typec_set_pwr_role(tps->port, TPS_STATUS_PORTROLE(status));
typec_set_vconn_role(tps->port, TPS_STATUS_VCONN(status));
tps6598x_set_data_role(tps, TPS_STATUS_DATAROLE(status), false);
+   power_supply_changed(tps->psy);
 }
 
 static int tps6598x_exec_cmd(struct tps6598x *tps, const char *cmd,
@@ -467,6 +489,85 @@ static const struct regmap_config tps6598x_regmap_config = 
{
.max_register = 0x7F,
 };
 
+static int tps6598x_psy_get_online(struct tps6598x *tps,
+  union power_supply_propval *val)
+{
+   int ret;
+   u16 pwr_status;
+
+   ret = tps6598x_read16(tps, TPS_REG_POWER_STATUS, _status);
+   if (ret < 0)
+   return ret;
+
+   if (!(pwr_status & TPS_POWER_STATUS_CONNECTION) ||
+   !(pwr_status & TPS_POWER_STATUS_SOURCESINK)) {
+   val->intval = 0;
+   } else {
+   val->intval = 1;
+   }
+   return 0;
+}
+
+static int tps6598x_psy_get_prop(struct power_supply *psy,
+enum power_supply_property psp,
+union power_supply_propval *val)
+{
+   struct tps6598x *tps = power_supply_get_drvdata(psy);
+   u16 pwr_status;
+   int ret = 0;
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_USB_TYPE:
+   ret = tps6598x_read16(tps, TPS_REG_POWER_STATUS, _status);
+   if (ret < 0)
+   return ret;
+   if (TPS_POWER_STATUS_PWROPMODE(pwr_status) == TYPEC_PWR_MODE_PD)
+   val->intval = POWER_SUPPLY_USB_TYPE_PD;
+   else
+   val->intval = POWER_SUPPLY_USB_TYPE_C;
+   break;
+   case POWER_SUPPLY_PROP_ONLINE:
+   ret = tps6598x_psy_get_online(tps, val);
+   break;
+   default:
+   ret = -EINVAL;
+   break;
+   }
+
+   return ret;
+}
+
+static int devm_tps6598_psy_register(struct tps6598x *tps)
+{
+   struct power_supply_config psy_cfg = {};
+   const char *port_dev_name = dev_name(tps->dev);
+   size_t psy_name_len = strlen(tps6598x_psy_name_prefix) +
+strlen(port_dev_name) + 1;
+   char *psy_name;
+
+   psy_cfg.drv_data = tps;
+   psy_cfg.fwnode = dev_fwnode(tps->dev);
+   psy_name = devm_kzalloc(tps->dev, psy_name_len, GFP_KERNEL);
+   if (!psy_name)
+   return -ENOMEM;
+
+   snprintf(psy_name, psy_name_len, "%s%s", tps6598x_psy_name_prefix,
+port_dev_name);
+   tps->psy_desc.name = psy_name;
+   tps->psy_desc.type = 

Re: [PATCH] block/rnbd: Adding name to the Contributors List

[Danil Kipnis]

On Fri, Nov 27, 2020 at 1:31 PM Swapnil Ingle  wrote:
>
> Adding name to the Contributors List
>
> Signed-off-by: Swapnil Ingle 

Acked-by: Danil Kipnis 

> ---
>  drivers/block/rnbd/README | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/block/rnbd/README b/drivers/block/rnbd/README
> index 1773c0a..080f58a 100644
> --- a/drivers/block/rnbd/README
> +++ b/drivers/block/rnbd/README
> @@ -90,3 +90,4 @@ Kleber Souza 
>  Lutz Pogrell 
>  Milind Dumbare 
>  Roman Penyaev 
> +Swapnil Ingle 
> --
> 1.8.3.1
>

Re: [PATCH v2 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it

[Richard Weinberger]

On Tue, Nov 24, 2020 at 2:58 PM Pratyush Yadav  wrote:
>
> Hi,
>
> On 18/11/20 11:54PM, Pratyush Yadav wrote:
> > Hi,
> >
> > The Cypress Semper S28 flash family uses 2-bit ECC by default. Under
> > this ECC scheme, multi-pass page programs result in a program error.
> > This means that unlike many other SPI NOR flashes, bit-walking cannot be
> > done. In other words, once a page is programmed, its bits cannot then be
> > flipped to 0 without an erase in between.
> >
> > This causes problems with UBIFS because it uses bit-walking to clear EC
> > and VID magic numbers from a PEB before issuing an erase to preserve the
> > file system correctness in case of power cuts.
> >
> > This series fixes that by setting mtd->writesize to the ECC block size
> > (16) and making sure UBIFS does not try to do a multi-pass write on
> > flashes with writesize > 1.
> >
> > It is based on the xSPI/8D series that adds support for Cypress S28
> > flash [0] (it is in next now). The patches themselves are independent of
> > that series in the sense that they don't rely on 8D support. But since
> > S28 flash is not supported without that series, these patches don't make
> > much sense without it.
> >
> > Tested on Cypress S28HS512T and MT35XU512ABA on J7200 and J721E
> > respectively.
> >
> > [0] https://lore.kernel.org/linux-mtd/20201005153138.6437-1-p.ya...@ti.com/
>
> Any comments on the series? If not, can it be picked up?
>
> > Pratyush Yadav (3):
> >   UBI: Do not zero out EC and VID on ECC-ed NOR flashes
> >   mtd: spi-nor: core: Allow flashes to specify MTD writesize
> >   mtd: spi-nor: spansion: Set ECC block size
> >
> >  drivers/mtd/spi-nor/core.c | 4 +++-
> >  drivers/mtd/spi-nor/core.h | 3 +++
> >  drivers/mtd/spi-nor/spansion.c | 1 +
> >  drivers/mtd/ubi/build.c| 4 +---
> >  drivers/mtd/ubi/io.c   | 9 -
> >  5 files changed, 16 insertions(+), 5 deletions(-)

Can we please have am ACK from NOR folks? :-)

-- 
Thanks,
//richard

RE: [PATCH 1/9] regulator: Update DA9121 dt-bindings

[Adam Ward]

> On Fri, Nov 20, 2020 at 02:47:42PM +0100, Vincent Whitchurch wrote:
> > On Fri, Nov 20, 2020 at 01:14:50PM +0100, Adam Ward wrote:
> Actually, perhaps I'm missing something, but I don't quite see why this
> move to a sub-node is needed.  There is some flexibility in the
> regulator framework for this as I noted earlier
> (https://lore.kernel.org/lkml/20201102154848.tm5nsydaukyd7...@axis.com/).
> For the case of an MFD it certainly makes sense to have a "regulators"
> sub-node but for these chips it seems rather redundant.

This sub-node looks fairly well instituted for devices with multiple regulators.
There's also the possibility to add GPIO support into another sub-node for all 
the variants.

Mark, do you have a preference?

Re: [PATCH] media: vb2: always set buffer cache sync hints

[Hans Verkuil]

On 27/11/2020 10:41, Sergey Senozhatsky wrote:
> We need to always set ->need_cache_sync_on_prepare and
> ->need_cache_sync_on_finish when we initialize vb2 buffer.
> 
> Currently these flags are set/adjusted only in V4L2's
> vb2_queue_or_prepare_buf(), which means that for the code
> paths that don't use V4L2 vb2 will always tell videobuf2
> core to skip ->prepare() and ->finish() cache syncs/flushes.
> 
> This is a quick solution that should do the trick. The
> proper fix, however, is much more complicated and requires
> a rather big videobuf2 refactoring - we need to move cache
> sync/flush decision making out of core videobuf2 to the
> allocators.
> 
> Reported-by: Tomasz Figa 
> Signed-off-by: Sergey Senozhatsky 
> ---
>  drivers/media/common/videobuf2/videobuf2-core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index 5499013cf82e..14a26888a892 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -414,6 +414,8 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum 
> vb2_memory memory,
>   vb->index = q->num_buffers + buffer;
>   vb->type = q->type;
>   vb->memory = memory;
> + vb->need_cache_sync_on_prepare = 1;
> + vb->need_cache_sync_on_finish = 1;

I think this needs a comment, basically explaining what you said in
the commit log. It's not obvious from the code that this is a
workaround.

Regards,

Hans

>   for (plane = 0; plane < num_planes; ++plane) {
>   vb->planes[plane].length = plane_sizes[plane];
>   vb->planes[plane].min_length = plane_sizes[plane];
> 

Re: [PATCH v5 3/5] usb: typec: stusb160x: fix power-opmode property with typec-power-opmode

[Amelie DELAUNAY]

Hi Greg,

gentle reminder for this patch, lost in the middle of a DT series (DT 
part already in stm32-next).


Thanks and regards,
Amelie

On 11/6/20 5:58 PM, Amelie Delaunay wrote:

Device tree property is named typec-power-opmode, not power-opmode.

Fixes: da0cb6310094 ("usb: typec: add support for STUSB160x Type-C controller 
family")
Signed-off-by: Amelie Delaunay 
Reviewed-by: Heikki Krogerus 
---
  drivers/usb/typec/stusb160x.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/typec/stusb160x.c b/drivers/usb/typec/stusb160x.c
index 2a618f02f4f1..d2175044 100644
--- a/drivers/usb/typec/stusb160x.c
+++ b/drivers/usb/typec/stusb160x.c
@@ -562,7 +562,7 @@ static int stusb160x_get_fw_caps(struct stusb160x *chip,
 * Supported power operation mode can be configured through device tree
 * else it is read from chip registers in stusb160x_get_caps.
 */
-   ret = fwnode_property_read_string(fwnode, "power-opmode", _str);
+   ret = fwnode_property_read_string(fwnode, "typec-power-opmode", 
_str);
if (!ret) {
ret = typec_find_pwr_opmode(cap_str);
/* Power delivery not yet supported */

[tip: x86/cleanups] x86/PCI: Make a kernel-doc comment a normal one

[tip-bot2 for Alex Shi]

The following commit has been merged into the x86/cleanups branch of tip:

Commit-ID: 638920a66a17c8e1f4415cbab0d49dc4a344c2a7
Gitweb:
https://git.kernel.org/tip/638920a66a17c8e1f4415cbab0d49dc4a344c2a7
Author:Alex Shi 
AuthorDate:Fri, 13 Nov 2020 16:58:14 +08:00
Committer: Borislav Petkov 
CommitterDate: Fri, 27 Nov 2020 13:43:09 +01:00

x86/PCI: Make a kernel-doc comment a normal one

The comment is using kernel-doc markup but that comment isn't a
kernel-doc comment so make it a normal one to avoid:

  arch/x86/pci/i386.c:373: warning: Function parameter or member \
  'pcibios_assign_resources' not described in 'fs_initcall'

 [ bp: Massage and fixup comment while at it. ]

Signed-off-by: Alex Shi 
Signed-off-by: Borislav Petkov 
Link: 
https://lkml.kernel.org/r/1605257895-5536-5-git-send-email-alex@linux.alibaba.com
---
 arch/x86/pci/i386.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index fa855bb..f2f4a5d 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -366,9 +366,9 @@ static int __init pcibios_assign_resources(void)
return 0;
 }
 
-/**
- * called in fs_initcall (one below subsys_initcall),
- * give a chance for motherboard reserve resources
+/*
+ * This is an fs_initcall (one below subsys_initcall) in order to reserve
+ * resources properly.
  */
 fs_initcall(pcibios_assign_resources);
 

[PATCH] mtd:cfi_cmdset_0002: fix atomic sleep bug when CONFIG_MTD_XIP=y

[Xiaoming Ni]

When CONFIG_MTD_XIP=y, local_irq_disable() is called in xip_disable().
To avoid sleep in interrupt context, we need to call local_irq_enable()
before schedule().

The problem call stack is as follows:
bug1:
do_write_oneword_retry()
xip_disable()
local_irq_disable()
do_write_oneword_once()
schedule()
bug2:
do_write_buffer()
xip_disable()
local_irq_disable()
do_write_buffer_wait()
schedule()
bug3:
do_erase_chip()
xip_disable()
local_irq_disable()
schedule()
bug4:
do_erase_oneblock()
xip_disable()
local_irq_disable()
schedule()

Fixes: 02b15e343aee ("[MTD] XIP for AMD CFI flash.")
Cc: sta...@vger.kernel.org # v2.6.13
Signed-off-by: Xiaoming Ni 
---
 drivers/mtd/chips/cfi_cmdset_0002.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c 
b/drivers/mtd/chips/cfi_cmdset_0002.c
index a1f3e1031c3d..12c3776f093a 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -1682,7 +1682,11 @@ static int __xipram do_write_oneword_once(struct 
map_info *map,
set_current_state(TASK_UNINTERRUPTIBLE);
add_wait_queue(>wq, );
mutex_unlock(>mutex);
+   if (IS_ENABLED(CONFIG_MTD_XIP))
+   local_irq_enable();
schedule();
+   if (IS_ENABLED(CONFIG_MTD_XIP))
+   local_irq_disable();
remove_wait_queue(>wq, );
timeo = jiffies + (HZ / 2); /* FIXME */
mutex_lock(>mutex);
@@ -1962,7 +1966,11 @@ static int __xipram do_write_buffer_wait(struct map_info 
*map,
set_current_state(TASK_UNINTERRUPTIBLE);
add_wait_queue(>wq, );
mutex_unlock(>mutex);
+   if (IS_ENABLED(CONFIG_MTD_XIP))
+   local_irq_enable();
schedule();
+   if (IS_ENABLED(CONFIG_MTD_XIP))
+   local_irq_disable();
remove_wait_queue(>wq, );
timeo = jiffies + (HZ / 2); /* FIXME */
mutex_lock(>mutex);
@@ -2461,7 +2469,11 @@ static int __xipram do_erase_chip(struct map_info *map, 
struct flchip *chip)
set_current_state(TASK_UNINTERRUPTIBLE);
add_wait_queue(>wq, );
mutex_unlock(>mutex);
+   if (IS_ENABLED(CONFIG_MTD_XIP))
+   local_irq_enable();
schedule();
+   if (IS_ENABLED(CONFIG_MTD_XIP))
+   local_irq_disable();
remove_wait_queue(>wq, );
mutex_lock(>mutex);
continue;
@@ -2560,7 +2572,11 @@ static int __xipram do_erase_oneblock(struct map_info 
*map, struct flchip *chip,
set_current_state(TASK_UNINTERRUPTIBLE);
add_wait_queue(>wq, );
mutex_unlock(>mutex);
+   if (IS_ENABLED(CONFIG_MTD_XIP))
+   local_irq_enable();
schedule();
+   if (IS_ENABLED(CONFIG_MTD_XIP))
+   local_irq_disable();
remove_wait_queue(>wq, );
mutex_lock(>mutex);
continue;
-- 
2.27.0

Re: [Intel-gfx] [drm/i915/gem] 59dd13ad31: phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second -54.0% regression

[Chris Wilson]

Quoting Xing Zhengjun (2020-11-27 01:51:41)
> 
> 
> On 11/27/2020 5:34 AM, Chris Wilson wrote:
> > Quoting Xing Zhengjun (2020-11-26 01:44:55)
> >>
> >>
> >> On 11/25/2020 4:47 AM, Chris Wilson wrote:
> >>> Quoting Oliver Sang (2020-11-19 07:20:18)
>  On Fri, Nov 13, 2020 at 04:27:13PM +0200, Joonas Lahtinen wrote:
> > Hi,
> >
> > Could you add intel-...@lists.freedesktop.org into reports going
> > forward.
> >
> > Quoting kernel test robot (2020-11-11 17:58:11)
> >>
> >> Greeting,
> >>
> >> FYI, we noticed a -54.0% regression of 
> >> phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second
> >>  due to commit:
> >
> > How many runs are there on the bad version to ensure the bisect is
> > repeatable?
> 
>  test 4 times.
>  zxing@inn:/result/phoronix-test-suite/performance-true-Radial_Gradient_Paint-1024x1024-jxrendermark-1.2.4-ucode=0xd6-monitor=da39a3ee/lkp-cfl-d1/debian-x86_64-phoronix/x86_64-rhel-8.3/gcc-9/59dd13ad310793757e34afa489dd6fc8544fc3da$
>   grep -r "operations_per_second" */stats.json
>  0/stats.json: 
>  "phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
>   4133.487932,
>  1/stats.json: 
>  "phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
>   4120.421503,
>  2/stats.json: 
>  "phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
>   4188.414835,
>  3/stats.json: 
>  "phoronix-test-suite.jxrendermark.RadialGradientPaint.1024x1024.operations_per_second":
>   4068.549514,
> >>>
> >>> a w/o revert (drm-tip)
> >>> b w/ revert
> >>> +mB+
> >>> | ..b 
> >>>  |
> >>> | ..b.aa  
> >>>  |
> >>> | a.a 
> >>>  |
> >>> | a.a 
> >>>  |
> >>> |  b  b  a
> >>>  |
> >>> |   b  b  b b. a  
> >>>  |
> >>> |   b  bb bbb...  
> >>>  |
> >>> |b   ab bbab.bb.bba b a aab   
> >>> a|
> >>> | |__A__| 
> >>>  |
> >>> | |MA_|   
> >>>  |
> >>> +--+
> >>>   NMin   MaxMedian   Avg  
> >>>   Stddev
> >>> a 120  3621.8761 7356.4442 4606.7895 4607.9132 
> >>> 156.17693
> >>> b 120  2664.0563 6359.9686 4519.5036 4534.4463 
> >>> 95.471121
> >>>
> >>> The patch is not expected to have any impact on the machine you are 
> >>> testing on.
> >>> -Chris
> >>>
> >>
> >> What's your code base?
> >> For my side:
> >> 1) sync the code to the head of Linux mainline
> >> 2) git reset --hard 59dd13ad31
> >> 3) git revert 59dd13ad3107
> >> We compare the test result of commit 59dd13ad3107 (step 2) and
> >> 2052847b06f8 (step 3, revert 59dd13ad3107), the regression should
> >> related with 59dd13ad3107. Each test case we run 5 times.
> > 
> > a 59dd13ad31
> > b revert
> > +mB+
> > |a  
> >|
> > |   aa  
> >|
> > | .bba  
> >|
> > | .bbaab
> >|
> > | .b . b   b
> >|
> > |a   b.. ..bb  bb   
> >|
> > |  b a   b.b.a bb   
> >|
> > |aa  b..aaa..b.b..bab   b a 
> >   .|
> > |  |__A__|  
> >|
> > |  |___A_|  
> >|
> > +--+
> >  NMin   MaxMedian   Avg
> > Stddev
> > a 120  3658.3435 6363.7812 4527.4406  4536.612 
> > 86.095459
> > b 120  3928.9643  6375.829 4576.0482 4585.4224  
> > 157.284
> > 
> 

Re: [PATCH v5 3/5] usb: typec: stusb160x: fix power-opmode property with typec-power-opmode

[Greg Kroah-Hartman]

On Fri, Nov 27, 2020 at 02:01:29PM +0100, Amelie DELAUNAY wrote:
> Hi Greg,
> 
> gentle reminder for this patch, lost in the middle of a DT series (DT part
> already in stm32-next).

Odd, I don't see this anymore, can you resend just this one so I can
apply it directly?

thanks,

greg k-h

RE: [PATCH v2 3/3] mfd: da9055: fix "REGULATOR" spelling in register content macro

[Adam Thomson]

On 27 November 2020 12:52, Michael Klein wrote:

> "REGUALTOR" -> "REGULATOR"
> 
> Signed-off-by: Michael Klein 

Reviewed-by: Adam Thomson 

[PATCH v3 2/3] spi: Add SPI_NO_TX/RX support

[Alexandru Ardelean]

From: Dragos Bogdan 

Transmit/receive only is a valid SPI mode. For example, the MOSI/TX line
might be missing from an ADC while for a DAC the MISO/RX line may be
optional. This patch adds these two new modes: SPI_NO_TX and
SPI_NO_RX. This way, the drivers will be able to identify if any of
these two lines is missing and to adjust the transfers accordingly.

Signed-off-by: Dragos Bogdan 
Signed-off-by: Alexandru Ardelean 
---
 drivers/spi/spi.c| 26 +-
 include/uapi/linux/spi/spi.h |  2 ++
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index cd3c395b4e90..17d4004bd2c6 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1941,6 +1941,9 @@ static int of_spi_parse_dt(struct spi_controller *ctlr, 
struct spi_device *spi,
/* Device DUAL/QUAD mode */
if (!of_property_read_u32(nc, "spi-tx-bus-width", )) {
switch (value) {
+   case 0:
+   spi->mode |= SPI_NO_TX;
+   break;
case 1:
break;
case 2:
@@ -1962,6 +1965,9 @@ static int of_spi_parse_dt(struct spi_controller *ctlr, 
struct spi_device *spi,
 
if (!of_property_read_u32(nc, "spi-rx-bus-width", )) {
switch (value) {
+   case 0:
+   spi->mode |= SPI_NO_RX;
+   break;
case 1:
break;
case 2:
@@ -3329,12 +3335,17 @@ int spi_setup(struct spi_device *spi)
unsignedbad_bits, ugly_bits;
int status;
 
-   /* check mode to prevent that DUAL and QUAD set at the same time
+   /*
+* check mode to prevent that any two of DUAL, QUAD and NO_MOSI/MISO
+* are set at the same time
 */
-   if (((spi->mode & SPI_TX_DUAL) && (spi->mode & SPI_TX_QUAD)) ||
-   ((spi->mode & SPI_RX_DUAL) && (spi->mode & SPI_RX_QUAD))) {
+   if ((hweight_long(spi->mode &
+   (SPI_TX_DUAL | SPI_TX_QUAD | SPI_NO_TX)) > 1) ||
+   (hweight_long(spi->mode &
+   (SPI_RX_DUAL | SPI_RX_QUAD | SPI_NO_RX)) > 1)) {
dev_err(>dev,
-   "setup: can not select dual and quad at the same time\n");
+   "setup: can not select any two of dual, quad and no-rx/tx "
+   "at the same time\n");
return -EINVAL;
}
/* if it is SPI_3WIRE mode, DUAL and QUAD should be forbidden
@@ -3348,7 +3359,8 @@ int spi_setup(struct spi_device *spi)
 * SPI_CS_WORD has a fallback software implementation,
 * so it is ignored here.
 */
-   bad_bits = spi->mode & ~(spi->controller->mode_bits | SPI_CS_WORD);
+   bad_bits = spi->mode & ~(spi->controller->mode_bits | SPI_CS_WORD |
+SPI_NO_TX | SPI_NO_RX);
/* nothing prevents from working with active-high CS in case if it
 * is driven by GPIO.
 */
@@ -3609,6 +3621,8 @@ static int __spi_validate(struct spi_device *spi, struct 
spi_message *message)
 * 2. check tx/rx_nbits match the mode in spi_device
 */
if (xfer->tx_buf) {
+   if (spi->mode & SPI_NO_TX)
+   return -EINVAL;
if (xfer->tx_nbits != SPI_NBITS_SINGLE &&
xfer->tx_nbits != SPI_NBITS_DUAL &&
xfer->tx_nbits != SPI_NBITS_QUAD)
@@ -3622,6 +3636,8 @@ static int __spi_validate(struct spi_device *spi, struct 
spi_message *message)
}
/* check transfer rx_nbits */
if (xfer->rx_buf) {
+   if (spi->mode & SPI_NO_RX)
+   return -EINVAL;
if (xfer->rx_nbits != SPI_NBITS_SINGLE &&
xfer->rx_nbits != SPI_NBITS_DUAL &&
xfer->rx_nbits != SPI_NBITS_QUAD)
diff --git a/include/uapi/linux/spi/spi.h b/include/uapi/linux/spi/spi.h
index ae028d64c779..b504e46a6f18 100644
--- a/include/uapi/linux/spi/spi.h
+++ b/include/uapi/linux/spi/spi.h
@@ -43,5 +43,7 @@
 #defineSPI_TX_OCTAL0x2000  /* transmit with 8 
wires */
 #defineSPI_RX_OCTAL0x4000  /* receive with 8 wires 
*/
 #defineSPI_3WIRE_HIZ   0x8000  /* high impedance 
turnaround */
+#defineSPI_NO_TX   0x1 /* no transmit wire */
+#defineSPI_NO_RX   0x2 /* no receive wire */
 
 #endif /* _UAPI_SPI_H */
-- 
2.27.0

[PATCH v3 3/3] spi: dt-bindings: document zero value for spi-{rx,tx}-bus-width properties

[Alexandru Ardelean]

Following a change to the SPI framework, providing a value of zero for
'spi-rx-bus-width' and 'spi-tx-bus-width' is now possible and will
essentially mean than no RX or TX is allowed.

Signed-off-by: Alexandru Ardelean 
---
 Documentation/devicetree/bindings/spi/spi-controller.yaml | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml 
b/Documentation/devicetree/bindings/spi/spi-controller.yaml
index 1b56d5e40f1f..f1aaaf9b3709 100644
--- a/Documentation/devicetree/bindings/spi/spi-controller.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml
@@ -125,8 +125,9 @@ patternProperties:
   spi-rx-bus-width:
 description:
   Bus width to the SPI bus used for read transfers.
+  If 0 is provided, then no RX will be possible on this devices.
 $ref: /schemas/types.yaml#/definitions/uint32
-enum: [1, 2, 4, 8]
+enum: [0, 1, 2, 4, 8]
 default: 1
 
   spi-rx-delay-us:
@@ -136,8 +137,9 @@ patternProperties:
   spi-tx-bus-width:
 description:
   Bus width to the SPI bus used for write transfers.
+  If 0 is provided, then no RX will be possible on this devices.
 $ref: /schemas/types.yaml#/definitions/uint32
-enum: [1, 2, 4, 8]
+enum: [0, 1, 2, 4, 8]
 default: 1
 
   spi-tx-delay-us:
-- 
2.27.0

[PATCH v3 1/3] spi: uapi: unify SPI modes into a single spi.h header

[Alexandru Ardelean]

This change moves all the SPI mode bits into a separate 'spi.h' header in
uapi. This is meant to re-use these definitions inside the kernel as well
as export them to userspace (via uapi).

The SPI mode definitions have usually been duplicated between between
'include/linux/spi/spi.h' and 'include/uapi/linux/spi/spidev.h', so
whenever adding a new entry, this would need to be put in both headers.

They've been moved from 'include/linux/spi/spi.h', since that seems a bit
more complete; the bits have descriptions and there is the SPI_MODE_X_MASK.

For now, this change does a simple move; no conversions to BIT() macros are
being done at this point. This can be done later, as that requires also
another header inclusion (the 'const.h' header).
The change as-is makes this 'spi.h' header more standalone.

Signed-off-by: Alexandru Ardelean 
---

Personally, I am not sure whether to convert the bitfield tos _BITUL()
macros or not. I feel that not-having these macros makes this uapi spi.h
header more standalone.
If there's a strong insistence to use those _BITUL() macros, I'll do it.
I'm hesitant now, because it requires that this spi.h includes the
'const.h' header.

Changelog v2 -> v3:
* 
https://lore.kernel.org/linux-spi/20201124102152.16548-1-alexandru.ardel...@analog.com/
* dropped 'spi: convert to BIT() all spi_device flags '
  added 'spi: uapi: unify SPI modes into a single spi.h header'

 include/linux/spi/spi.h | 22 +--
 include/uapi/linux/spi/spi.h| 47 +
 include/uapi/linux/spi/spidev.h | 30 +
 3 files changed, 49 insertions(+), 50 deletions(-)
 create mode 100644 include/uapi/linux/spi/spi.h

diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index aa09fdc8042d..a4fedb33d34b 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct dma_chan;
 struct property_entry;
@@ -165,27 +166,6 @@ struct spi_device {
u8  bits_per_word;
boolrt;
u32 mode;
-#defineSPI_CPHA0x01/* clock phase */
-#defineSPI_CPOL0x02/* clock polarity */
-#defineSPI_MODE_0  (0|0)   /* (original MicroWire) 
*/
-#defineSPI_MODE_1  (0|SPI_CPHA)
-#defineSPI_MODE_2  (SPI_CPOL|0)
-#defineSPI_MODE_3  (SPI_CPOL|SPI_CPHA)
-#defineSPI_MODE_X_MASK (SPI_CPOL|SPI_CPHA)
-#defineSPI_CS_HIGH 0x04/* chipselect active 
high? */
-#defineSPI_LSB_FIRST   0x08/* per-word 
bits-on-wire */
-#defineSPI_3WIRE   0x10/* SI/SO signals shared 
*/
-#defineSPI_LOOP0x20/* loopback mode */
-#defineSPI_NO_CS   0x40/* 1 dev/bus, no 
chipselect */
-#defineSPI_READY   0x80/* slave pulls low to 
pause */
-#defineSPI_TX_DUAL 0x100   /* transmit with 2 
wires */
-#defineSPI_TX_QUAD 0x200   /* transmit with 4 
wires */
-#defineSPI_RX_DUAL 0x400   /* receive with 2 wires 
*/
-#defineSPI_RX_QUAD 0x800   /* receive with 4 wires 
*/
-#defineSPI_CS_WORD 0x1000  /* toggle cs after each 
word */
-#defineSPI_TX_OCTAL0x2000  /* transmit with 8 
wires */
-#defineSPI_RX_OCTAL0x4000  /* receive with 8 wires 
*/
-#defineSPI_3WIRE_HIZ   0x8000  /* high impedance 
turnaround */
int irq;
void*controller_state;
void*controller_data;
diff --git a/include/uapi/linux/spi/spi.h b/include/uapi/linux/spi/spi.h
new file mode 100644
index ..ae028d64c779
--- /dev/null
+++ b/include/uapi/linux/spi/spi.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
+/*
+ * include/linux/spi/spi.h
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+  */
+
+#ifndef _UAPI_SPI_H
+#define _UAPI_SPI_H
+
+#defineSPI_CPHA0x01

[no subject]

[george mike]

Hallo

Mein Name ist George Mike. Ich bin von Beruf Rechtsanwalt. Ich möchte
Ihnen anbieten
der nächste Verwandte meines Klienten. Sie erben die Summe von (8,5
Millionen US-Dollar)
Dollar, die mein Kunde vor seinem Tod auf der Bank gelassen hat.

Mein Kunde ist ein Staatsbürger Ihres Landes, der mit seiner Frau bei
einem Autounfall ums Leben gekommen ist
und einziger Sohn. Ich habe Anspruch auf 50% des Gesamtfonds, 50% darauf
sein für dich.
Bitte kontaktieren Sie meine private E-Mail hier für weitere
Informationen: georgemike7...@gmail.com

Vielen Dank im Voraus,
Mr. George Mike,

Re: [PATCH v4 02/14] arm64: Allow mismatched 32-bit EL0 support

[Qais Yousef]

On 11/24/20 15:50, Will Deacon wrote:
> When confronted with a mixture of CPUs, some of which support 32-bit

Confronted made me laugh, well chosen word! :D

For some reason made me think of this :p

https://www.youtube.com/watch?v=NJbXPzSPzxc=1m33s

> applications and others which don't, we quite sensibly treat the system
> as 64-bit only for userspace and prevent execve() of 32-bit binaries.
> 
> Unfortunately, some crazy folks have decided to build systems like this
> with the intention of running 32-bit applications, so relax our
> sanitisation logic to continue to advertise 32-bit support to userspace
> on these systems and track the real 32-bit capable cores in a cpumask
> instead. For now, the default behaviour remains but will be tied to
> a command-line option in a later patch.
> 
> Signed-off-by: Will Deacon 
> ---
>  arch/arm64/include/asm/cpucaps.h|   2 +-
>  arch/arm64/include/asm/cpufeature.h |   8 ++-
>  arch/arm64/kernel/cpufeature.c  | 106 ++--
>  3 files changed, 107 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/cpucaps.h 
> b/arch/arm64/include/asm/cpucaps.h
> index e7d98997c09c..e6f0eb4643a0 100644
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@ -20,7 +20,7 @@
>  #define ARM64_ALT_PAN_NOT_UAO10
>  #define ARM64_HAS_VIRT_HOST_EXTN 11
>  #define ARM64_WORKAROUND_CAVIUM_2745612
> -#define ARM64_HAS_32BIT_EL0  13
> +#define ARM64_HAS_32BIT_EL0_DO_NOT_USE   13

nit: would UNUSED be better here? Worth adding a comment as to why too?

>  #define ARM64_HARDEN_EL2_VECTORS 14
>  #define ARM64_HAS_CNP15
>  #define ARM64_HAS_NO_FPSIMD  16

[...]

> +static bool has_32bit_el0(const struct arm64_cpu_capabilities *entry, int 
> scope)
> +{
> + if (!has_cpuid_feature(entry, scope))
> + return allow_mismatched_32bit_el0;

If a user passes the command line by mistake on a 64bit only system, this will
return true. I'll be honest, I'm not entirely sure what the impact is. I get
lost in the features maze. It is nicely encapsulated, but hard to navigate for
the none initiated :-)

Thanks

--
Qais Yousef

> +
> + if (scope == SCOPE_SYSTEM)
> + pr_info("detected: 32-bit EL0 Support\n");
> +
> + return true;
> +}
> +
>  static bool has_useable_gicv3_cpuif(const struct arm64_cpu_capabilities 
> *entry, int scope)
>  {
>   bool has_sre;
> @@ -1803,10 +1890,9 @@ static const struct arm64_cpu_capabilities 
> arm64_features[] = {
>   },
>  #endif   /* CONFIG_ARM64_VHE */
>   {
> - .desc = "32-bit EL0 Support",
> - .capability = ARM64_HAS_32BIT_EL0,
> + .capability = ARM64_HAS_32BIT_EL0_DO_NOT_USE,
>   .type = ARM64_CPUCAP_SYSTEM_FEATURE,
> - .matches = has_cpuid_feature,
> + .matches = has_32bit_el0,
>   .sys_reg = SYS_ID_AA64PFR0_EL1,
>   .sign = FTR_UNSIGNED,
>   .field_pos = ID_AA64PFR0_EL0_SHIFT,
> @@ -2299,7 +2385,7 @@ static const struct arm64_cpu_capabilities 
> compat_elf_hwcaps[] = {
>   {},
>  };

Re: [PATCH bpf-next v3 3/3] bpf: Add a selftest for bpf_ima_inode_hash

[KP Singh]

On Fri, Nov 27, 2020 at 5:29 AM Andrii Nakryiko
 wrote:
>
> On Tue, Nov 24, 2020 at 7:16 AM KP Singh  wrote:
> >
> > From: KP Singh 
> >

[...]

>
> > +cleanup() {
> > +local tmp_dir="$1"
> > +local mount_img="${tmp_dir}/test.img"
> > +local mount_dir="${tmp_dir}/mnt"
> > +
> > +local loop_devices=$(losetup -j ${mount_img} -O NAME --noheadings)
>
> libbpf and kernel-patches CIs are using BusyBox environment which has
> losetup that doesn't support -j option. Is there some way to work
> around that? What we have is this:
>
> BusyBox v1.31.1 () multi-call binary.
>
> Usage: losetup [-rP] [-o OFS] {-f|LOOPDEV} FILE: associate loop devices
>
> losetup -c LOOPDEV: reread file size
>
> losetup -d LOOPDEV: disassociate
>
> losetup -a: show status

I can try to grep and parse the status output as a fallback. Will send another
fix.

- KP

>
> losetup -f: show next free loop device
>
> -o OFSStart OFS bytes into FILE
>
> -PScan for partitions
>
> -rRead-only
>
> -fShow/use next free loop device
>
>
> > +for loop_dev in "${loop_devices}"; do

[...]

Re: [REGRESSION] omapdrm/N900 display broken

[Ivaylo Dimitrov]

On 27.11.20 г. 13:45 ч., Tomi Valkeinen wrote:

On 27/11/2020 01:17, Ivaylo Dimitrov wrote:

Hi Tomi,

On 26.11.20 г. 16:11 ч., Tomi Valkeinen wrote:

Hi Aaro, Ivaylo,

On 24/11/2020 23:03, Ivaylo Dimitrov wrote:


Is there any progress on the issue? I tried 5.9.1 and still nothing displayed.


Can you test the attached patch?



With this patch I don't see oops that Aaro reported, so:

Tested-by: Ivaylo Dimitrov 

Seems to fix the particular issue, however, now we get another oops. As this is 
not upstream kernel
but one with PVR related patches, I will try again with vanilla 5.9.

Just in case oops rings any bells (the line in question is
https://github.com/maemo-leste/droid4-linux/blob/maemo-5.9/drivers/gpu/drm/omapdrm/omap_gem.c#L801)


Do the PVR patches touch omapdrm? The call stack looks like normal boot time 
probing stuff, not
something happening later (possibly from PVR).



pvr driver is not even enabled in that particular config, however, I see 
"HACK: drm/omap: Add omapdrm plugin API" patch in the tree that touches 
omap-gem.c, I don't really want to just create some noise for problems 
that are created by out-of-tree patches. And yeah, it looks like a 
normal boot time probing stuff. As soon as I have some spare time 
(hopefully later today) I will try vanilla 5.9.x with 
omap2plus_defconfig and will report.


Ivo

Re: [PATCH v4 04/14] arm64: Kill 32-bit applications scheduled on 64-bit-only CPUs

[Qais Yousef]

On 11/24/20 15:50, Will Deacon wrote:
> Scheduling a 32-bit application on a 64-bit-only CPU is a bad idea.
> 
> Ensure that 32-bit applications always take the slow-path when returning
> to userspace on a system with mismatched support at EL0, so that we can
> avoid trying to run on a 64-bit-only CPU and force a SIGKILL instead.
> 
> Signed-off-by: Will Deacon 
> ---

nit: We drop this patch at the end. Can't we avoid it altogether instead?

[...]

> diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> index a8184cad8890..bcb6ca2d9a7c 100644
> --- a/arch/arm64/kernel/signal.c
> +++ b/arch/arm64/kernel/signal.c
> @@ -911,6 +911,19 @@ static void do_signal(struct pt_regs *regs)
>   restore_saved_sigmask();
>  }
>  
> +static bool cpu_affinity_invalid(struct pt_regs *regs)
> +{
> + if (!compat_user_mode(regs))
> + return false;

Silly question. Is there an advantage of using compat_user_mode() vs
is_compat_task()? I see the latter used in the file although struct pt_regs
*regs is passed to the functions calling it.

Nothing's wrong with it, just curious.

Thanks

--
Qais Yousef

> +
> + /*
> +  * We're preemptible, but a reschedule will cause us to check the
> +  * affinity again.
> +  */
> + return !cpumask_test_cpu(raw_smp_processor_id(),
> +  system_32bit_el0_cpumask());
> +}

Re: [PATCH v5 3/5] usb: typec: stusb160x: fix power-opmode property with typec-power-opmode

[Amelie DELAUNAY]

On 11/27/20 2:07 PM, Greg Kroah-Hartman wrote:

On Fri, Nov 27, 2020 at 02:01:29PM +0100, Amelie DELAUNAY wrote:

Hi Greg,

gentle reminder for this patch, lost in the middle of a DT series (DT part
already in stm32-next).


Odd, I don't see this anymore, can you resend just this one so I can
apply it directly?


Sure :) I rebase it and send it right now.

Amelie

[PATCH] scsi: zfcp: fix indentation coding style issue

[Yevhen Viktorov]

code indent should use tabs where possible

Signed-off-by: Yevhen Viktorov 
---
 drivers/s390/scsi/zfcp_def.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/s390/scsi/zfcp_def.h b/drivers/s390/scsi/zfcp_def.h
index da8a5ceb615c..a2a59cbb330a 100644
--- a/drivers/s390/scsi/zfcp_def.h
+++ b/drivers/s390/scsi/zfcp_def.h
@@ -157,7 +157,7 @@ struct zfcp_adapter {
u32 fsf_lic_version;
u32 adapter_features;  /* FCP channel features */
u32 connection_features; /* host connection 
features */
-u32hardware_version;  /* of FCP channel */
+   u32 hardware_version;  /* of FCP channel */
u32 fc_security_algorithms; /* of FCP channel */
u32 fc_security_algorithms_old; /* of FCP channel */
u16 timer_ticks;   /* time int for a tick */
@@ -181,7 +181,7 @@ struct zfcp_adapter {
rwlock_terp_lock;
wait_queue_head_t   erp_done_wqh;
struct zfcp_erp_action  erp_action;/* pending error recovery */
-atomic_terp_counter;
+   atomic_terp_counter;
u32 erp_total_count;   /* total nr of enqueued erp
  actions */
u32 erp_low_mem_count; /* nr of erp actions waiting
@@ -217,7 +217,7 @@ struct zfcp_port {
u32d_id;   /* D_ID */
u32handle; /* handle assigned by FSF */
struct zfcp_erp_action erp_action; /* pending error recovery */
-atomic_t   erp_counter;
+   atomic_t   erp_counter;
u32maxframe_size;
u32supported_classes;
u32connection_info;
-- 
2.26.2

Re: [PATCH v6 00/17] follow_pfn and other iomap races

[Jason Gunthorpe]

On Thu, Nov 19, 2020 at 03:41:29PM +0100, Daniel Vetter wrote:
> I feel like this is ready for some wider soaking. Since the remaining bits
> are all kinda connnected probably simplest if it all goes through -mm.

Did you figure out a sumbission plan for this stuff?

> Daniel Vetter (17):
>   drm/exynos: Stop using frame_vector helpers
>   drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
>   misc/habana: Stop using frame_vector helpers
>   misc/habana: Use FOLL_LONGTERM for userptr
>   mm/frame-vector: Use FOLL_LONGTERM
>   media: videobuf2: Move frame_vector into media subsystem

At the very least it would be good to get those in right away.

>   mm: Add unsafe_follow_pfn
>   media/videbuf1|2: Mark follow_pfn usage as unsafe
>   vfio/type1: Mark follow_pfn as unsafe

I'm surprised nobody from VFIO has remarked on this, I think thety
won't like it

>   mm: Close race in generic_access_phys
>   PCI: Obey iomem restrictions for procfs mmap
>   /dev/mem: Only set filp->f_mapping
>   resource: Move devmem revoke code to resource framework
>   sysfs: Support zapping of binary attr mmaps
>   PCI: Revoke mappings like devmem

This sequence seems fairly stand alone, and in good shape as well

My advice is to put the done things on a branch and get Stephen to put
them in linux-next. You can send a PR to Lins. There is very little mm
stuff in here, and cross subsystem stuff works better in git land,
IMHO.

Jason

Re: [PATCH v4 06/14] arm64: Hook up cmdline parameter to allow mismatched 32-bit EL0

[Qais Yousef]

On 11/24/20 15:50, Will Deacon wrote:
> Allow systems with mismatched 32-bit support at EL0 to run 32-bit
> applications based on a new kernel parameter.
> 
> Signed-off-by: Will Deacon 
> ---
>  Documentation/admin-guide/kernel-parameters.txt | 7 +++
>  arch/arm64/kernel/cpufeature.c  | 7 +++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index 526d65d8573a..f20188c44d83 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -289,6 +289,13 @@
>   do not want to use tracing_snapshot_alloc() as it needs
>   to be done where GFP_KERNEL allocations are allowed.
>  
> + allow_mismatched_32bit_el0 [ARM64]
> + Allow execve() of 32-bit applications and setting of the
> + PER_LINUX32 personality on systems where only a strict
> + subset of the CPUs support 32-bit EL0. When this
> + parameter is present, the set of CPUs supporting 32-bit
> + EL0 is indicated by /sys/devices/system/cpu/aarch32_el0.

Shouldn't we document that a randomly selected 32-bit CPU will be prevented
from being hotplugged out all the time to act as the last man standing for any
currently running 32-bit application.

That was a mouthful! I'm sure you can phrase it better :-)

If we make this the last patch as it was before adding affinity handling, we
can drop patch 4 more easily I think?

Thanks

--
Qais Yousef

[PATCH v5 1/1 RESEND] usb: typec: stusb160x: fix power-opmode property with typec-power-opmode

[Amelie Delaunay]

Device tree property is named typec-power-opmode, not power-opmode.

Fixes: da0cb6310094 ("usb: typec: add support for STUSB160x Type-C controller 
family")
Signed-off-by: Amelie Delaunay 
Reviewed-by: Heikki Krogerus 
---
 drivers/usb/typec/stusb160x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/typec/stusb160x.c b/drivers/usb/typec/stusb160x.c
index 2a618f02f4f1..d2175044 100644
--- a/drivers/usb/typec/stusb160x.c
+++ b/drivers/usb/typec/stusb160x.c
@@ -562,7 +562,7 @@ static int stusb160x_get_fw_caps(struct stusb160x *chip,
 * Supported power operation mode can be configured through device tree
 * else it is read from chip registers in stusb160x_get_caps.
 */
-   ret = fwnode_property_read_string(fwnode, "power-opmode", _str);
+   ret = fwnode_property_read_string(fwnode, "typec-power-opmode", 
_str);
if (!ret) {
ret = typec_find_pwr_opmode(cap_str);
/* Power delivery not yet supported */
-- 
2.17.1

Re: [PATCH v2 3/3] mfd: da9055: fix "REGULATOR" spelling in register content macro

[Lee Jones]

On Fri, 27 Nov 2020, Michael Klein wrote:

> "REGUALTOR" -> "REGULATOR"
> 
> Signed-off-by: Michael Klein 
> ---
> Changes in v2:
>   - split patch
>   - make subject line more forthcoming
> 
>  drivers/regulator/da9055-regulator.c | 4 ++--
>  include/linux/mfd/da9055/reg.h   | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)

Acked-by: Lee Jones 

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v4 07/14] sched: Introduce restrict_cpus_allowed_ptr() to limit task CPU affinity

[Qais Yousef]

On 11/24/20 15:50, Will Deacon wrote:

[...]

> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index d2003a7d5ab5..818c8f7bdf2a 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1860,24 +1860,18 @@ void do_set_cpus_allowed(struct task_struct *p, const 
> struct cpumask *new_mask)
>  }
>  
>  /*
> - * Change a given task's CPU affinity. Migrate the thread to a
> - * proper CPU and schedule it away if the CPU it's executing on
> - * is removed from the allowed bitmask.
> - *
> - * NOTE: the caller must have a valid reference to the task, the
> - * task must not exit() & deallocate itself prematurely. The
> - * call is not atomic; no spinlocks may be held.
> + * Called with both p->pi_lock and rq->lock held; drops both before 
> returning.

nit: wouldn't it be better for the caller to acquire and release the locks?
Not a big deal but it's always confusing when half of the work done outside the
function and the other half done inside.

Thanks

--
Qais Yousef

>   */
> -static int __set_cpus_allowed_ptr(struct task_struct *p,
> -   const struct cpumask *new_mask, bool check)
> +static int __set_cpus_allowed_ptr_locked(struct task_struct *p,
> +  const struct cpumask *new_mask,
> +  bool check,
> +  struct rq *rq,
> +  struct rq_flags *rf)
>  {
>   const struct cpumask *cpu_valid_mask = cpu_active_mask;
>   unsigned int dest_cpu;
> - struct rq_flags rf;
> - struct rq *rq;
>   int ret = 0;
>  
> - rq = task_rq_lock(p, );
>   update_rq_clock(rq);
>  
>   if (p->flags & PF_KTHREAD) {
> @@ -1929,7 +1923,7 @@ static int __set_cpus_allowed_ptr(struct task_struct *p,
>   if (task_running(rq, p) || p->state == TASK_WAKING) {
>   struct migration_arg arg = { p, dest_cpu };
>   /* Need help from migration thread: drop lock and wait. */
> - task_rq_unlock(rq, p, );
> + task_rq_unlock(rq, p, rf);
>   stop_one_cpu(cpu_of(rq), migration_cpu_stop, );
>   return 0;
>   } else if (task_on_rq_queued(p)) {
> @@ -1937,20 +1931,69 @@ static int __set_cpus_allowed_ptr(struct task_struct 
> *p,
>* OK, since we're going to drop the lock immediately
>* afterwards anyway.
>*/
> - rq = move_queued_task(rq, , p, dest_cpu);
> + rq = move_queued_task(rq, rf, p, dest_cpu);
>   }
>  out:
> - task_rq_unlock(rq, p, );
> + task_rq_unlock(rq, p, rf);
>  
>   return ret;
>  }

[PATCH v2 0/6] aarch64: avoid mprotect(PROT_BTI|PROT_EXEC) [BZ #26831]

[Szabolcs Nagy]

This is v2 of
https://sourceware.org/pipermail/libc-alpha/2020-November/119305.html

To enable BTI support, re-mmap executable segments instead of
mprotecting them in case mprotect is seccomp filtered.

I would like linux to change to map the main exe with PROT_BTI when
that is marked as BTI compatible. From the linux side i heard the
following concerns about this:
- it's an ABI change so requires some ABI bump. (this is fine with
  me, i think glibc does not care about backward compat as nothing
  can reasonably rely on the current behaviour, but if we have a
  new bit in auxv or similar then we can save one mprotect call.)
- in case we discover compatibility issues with user binaries it's
  better if userspace can easily disable BTI (e.g. removing the
  mprotect based on some env var, but if kernel adds PROT_BTI and
  mprotect is filtered then we have no reliable way to remove that
  from executables. this problem already exists for static linked
  exes, although admittedly those are less of a compat concern.)
- ideally PROT_BTI would be added via a new syscall that does not
  interfere with PROT_EXEC filtering. (this does not conflict with
  the current patches: even with a new syscall we need a fallback.)
- solve it in systemd (e.g. turn off the filter, use better filter):
  i would prefer not to have aarch64 (or BTI) specific policy in
  user code. and there was no satisfying way to do this portably.

Other concerns about the approach:
- mmap is more expensive than mprotect: in my measurements using
  mmap instead of mprotect is 3-8x slower (and after mmap pages
  have to be faulted in again), but e.g. the exec time of a program
  with 4 deps only increases by < 8% due to the 4 new mmaps. (the
  kernel side resource usage may increase too, i didnt look at that.)
- _dl_signal_error is not valid from the _dl_process_gnu_property
  hook. The v2 set addresses this problem: i could either propagate
  the errors up until they can be handled or solve it in the aarch64
  backend by first recording failures and then dealing with them in
  _dl_open_check. I choose the latter, but did some refactorings in
  _dl_map_object_from_fd that makes the former possible too.

v2:
- [1/6]: New patch that fixes a missed BTI bug found during v2.
- [2-3/6]: New, _dl_map_object_from_fd failure handling improvements,
  these are independent of the rest of the series.
- [4/6]: Move the note handling to a different place (after l_phdr
  setup, but before fd is closed).
- [5/6]: Rebased.
- [6/6]: First record errors and only report them later. (this fixes
  various failure handling issues.)

Szabolcs Nagy (6):
  aarch64: Fix missing BTI protection from dependencies [BZ #26926]
  elf: lose is closely tied to _dl_map_object_from_fd
  elf: Fix failure handling in _dl_map_object_from_fd
  elf: Move note processing after l_phdr is updated
  elf: Pass the fd to note processing
  aarch64: Use mmap to add PROT_BTI instead of mprotect [BZ #26831]

 elf/dl-load.c  | 110 -
 elf/rtld.c |   4 +-
 sysdeps/aarch64/dl-bti.c   |  74 ++---
 sysdeps/aarch64/dl-prop.h  |  14 +++--
 sysdeps/aarch64/linkmap.h  |   2 +-
 sysdeps/generic/dl-prop.h  |   6 +-
 sysdeps/generic/ldsodefs.h |   5 +-
 sysdeps/x86/dl-prop.h  |   6 +-
 8 files changed, 135 insertions(+), 86 deletions(-)

-- 
2.17.1

[PATCH v2 1/6] aarch64: Fix missing BTI protection from dependencies [BZ #26926]

[Szabolcs Nagy]

The _dl_open_check and _rtld_main_check hooks are not called on the
dependencies of a loaded module, so BTI protection was missed on
every module other than the main executable and directly dlopened
libraries.

The fix just iterates over dependencies to enable BTI.

Fixes bug 26926.
---
 sysdeps/aarch64/dl-bti.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/sysdeps/aarch64/dl-bti.c b/sysdeps/aarch64/dl-bti.c
index 196e462520..8f4728adce 100644
--- a/sysdeps/aarch64/dl-bti.c
+++ b/sysdeps/aarch64/dl-bti.c
@@ -51,11 +51,24 @@ enable_bti (struct link_map *map, const char *program)
   return 0;
 }
 
-/* Enable BTI for L if required.  */
+/* Enable BTI for MAP and its dependencies.  */
 
 void
-_dl_bti_check (struct link_map *l, const char *program)
+_dl_bti_check (struct link_map *map, const char *program)
 {
-  if (GLRO(dl_aarch64_cpu_features).bti && l->l_mach.bti)
-enable_bti (l, program);
+  if (!GLRO(dl_aarch64_cpu_features).bti)
+return;
+
+  if (map->l_mach.bti)
+enable_bti (map, program);
+
+  unsigned int i = map->l_searchlist.r_nlist;
+  while (i-- > 0)
+{
+  struct link_map *l = map->l_initfini[i];
+  if (l->l_init_called)
+   continue;
+  if (l->l_mach.bti)
+   enable_bti (l, program);
+}
 }
-- 
2.17.1

[PATCH v2 2/6] elf: lose is closely tied to _dl_map_object_from_fd

[Szabolcs Nagy]

Simple refactoring to keep failure handling next to
_dl_map_object_from_fd.
---
 elf/dl-load.c | 48 
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/elf/dl-load.c b/elf/dl-load.c
index f3201e7c14..21e55deb19 100644
--- a/elf/dl-load.c
+++ b/elf/dl-load.c
@@ -835,30 +835,6 @@ _dl_init_paths (const char *llp, const char *source)
 }
 
 
-static void
-__attribute__ ((noreturn, noinline))
-lose (int code, int fd, const char *name, char *realname, struct link_map *l,
-  const char *msg, struct r_debug *r, Lmid_t nsid)
-{
-  /* The file might already be closed.  */
-  if (fd != -1)
-(void) __close_nocancel (fd);
-  if (l != NULL && l->l_origin != (char *) -1l)
-free ((char *) l->l_origin);
-  free (l);
-  free (realname);
-
-  if (r != NULL)
-{
-  r->r_state = RT_CONSISTENT;
-  _dl_debug_state ();
-  LIBC_PROBE (map_failed, 2, nsid, r);
-}
-
-  _dl_signal_error (code, name, NULL, msg);
-}
-
-
 /* Process PT_GNU_PROPERTY program header PH in module L after
PT_LOAD segments are mapped.  Only one NT_GNU_PROPERTY_TYPE_0
note is handled which contains processor specific properties.  */
@@ -930,6 +906,30 @@ _dl_process_pt_gnu_property (struct link_map *l, const 
ElfW(Phdr) *ph)
 }
 
 
+static void
+__attribute__ ((noreturn, noinline))
+lose (int code, int fd, const char *name, char *realname, struct link_map *l,
+  const char *msg, struct r_debug *r, Lmid_t nsid)
+{
+  /* The file might already be closed.  */
+  if (fd != -1)
+(void) __close_nocancel (fd);
+  if (l != NULL && l->l_origin != (char *) -1l)
+free ((char *) l->l_origin);
+  free (l);
+  free (realname);
+
+  if (r != NULL)
+{
+  r->r_state = RT_CONSISTENT;
+  _dl_debug_state ();
+  LIBC_PROBE (map_failed, 2, nsid, r);
+}
+
+  _dl_signal_error (code, name, NULL, msg);
+}
+
+
 /* Map in the shared object NAME, actually located in REALNAME, and already
opened on FD.  */
 
-- 
2.17.1

[PATCH] f2fs: fix kbytes written stat for multi-device case

[Chao Yu]

From: Chao Yu 

For multi-device case, one f2fs image includes multi devices, so it
needs to account bytes written of all block devices belong to the image
rather than one main block device, fix it.

Signed-off-by: Chao Yu 
---
 fs/f2fs/checkpoint.c | 27 +++
 fs/f2fs/f2fs.h   |  8 +---
 fs/f2fs/super.c  |  5 +
 fs/f2fs/sysfs.c  |  3 ++-
 4 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 9b0628e0d8bc..97ac921bd581 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -1385,6 +1385,27 @@ static void commit_checkpoint(struct f2fs_sb_info *sbi,
f2fs_submit_merged_write(sbi, META_FLUSH);
 }
 
+static inline u64 get_sectors_written(struct block_device *bdev)
+{
+   return bdev->bd_part ?
+   (u64)part_stat_read(bdev->bd_part, sectors[STAT_WRITE]) : 0;
+}
+
+u64 f2fs_get_sectors_written(struct f2fs_sb_info *sbi)
+{
+   if (f2fs_is_multi_device(sbi)) {
+   u64 sectors = 0;
+   int i;
+
+   for (i = 0; i < sbi->s_ndevs; i++)
+   sectors += get_sectors_written(FDEV(i).bdev);
+
+   return sectors;
+   }
+
+   return get_sectors_written(sbi->sb->s_bdev);
+}
+
 static int do_checkpoint(struct f2fs_sb_info *sbi, struct cp_control *cpc)
 {
struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
@@ -1395,7 +1416,6 @@ static int do_checkpoint(struct f2fs_sb_info *sbi, struct 
cp_control *cpc)
__u32 crc32 = 0;
int i;
int cp_payload_blks = __cp_payload(sbi);
-   struct super_block *sb = sbi->sb;
struct curseg_info *seg_i = CURSEG_I(sbi, CURSEG_HOT_NODE);
u64 kbytes_written;
int err;
@@ -1490,9 +1510,8 @@ static int do_checkpoint(struct f2fs_sb_info *sbi, struct 
cp_control *cpc)
 
/* Record write statistics in the hot node summary */
kbytes_written = sbi->kbytes_written;
-   if (sb->s_bdev->bd_part)
-   kbytes_written += BD_PART_WRITTEN(sbi);
-
+   kbytes_written += (f2fs_get_sectors_written(sbi) -
+   sbi->sectors_written_start) >> 1;
seg_i->journal->info.kbytes_written = cpu_to_le64(kbytes_written);
 
if (__remain_node_summaries(cpc->reason)) {
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index bfefdf99cd3e..d32065417616 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1613,13 +1613,6 @@ static inline bool f2fs_is_multi_device(struct 
f2fs_sb_info *sbi)
return sbi->s_ndevs > 1;
 }
 
-/* For write statistics. Suppose sector size is 512 bytes,
- * and the return value is in kbytes. s is of struct f2fs_sb_info.
- */
-#define BD_PART_WRITTEN(s)  \
-(((u64)part_stat_read((s)->sb->s_bdev->bd_part, sectors[STAT_WRITE]) -   \
-   (s)->sectors_written_start) >> 1)
-
 static inline void f2fs_update_time(struct f2fs_sb_info *sbi, int type)
 {
unsigned long now = jiffies;
@@ -3392,6 +3385,7 @@ void f2fs_update_dirty_page(struct inode *inode, struct 
page *page);
 void f2fs_remove_dirty_inode(struct inode *inode);
 int f2fs_sync_dirty_inodes(struct f2fs_sb_info *sbi, enum inode_type type);
 void f2fs_wait_on_all_pages(struct f2fs_sb_info *sbi, int type);
+u64 f2fs_get_sectors_written(struct f2fs_sb_info *sbi);
 int f2fs_write_checkpoint(struct f2fs_sb_info *sbi, struct cp_control *cpc);
 void f2fs_init_ino_entry_info(struct f2fs_sb_info *sbi);
 int __init f2fs_create_checkpoint_caches(void);
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index e71db2a0a9c7..b0c6ef2df7b8 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -3719,10 +3719,7 @@ static int f2fs_fill_super(struct super_block *sb, void 
*data, int silent)
}
 
/* For write statistics */
-   if (sb->s_bdev->bd_part)
-   sbi->sectors_written_start =
-   (u64)part_stat_read(sb->s_bdev->bd_part,
-   sectors[STAT_WRITE]);
+   sbi->sectors_written_start = f2fs_get_sectors_written(sbi);
 
/* Read accumulated write IO statistics if exists */
seg_i = CURSEG_I(sbi, CURSEG_HOT_NODE);
diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
index 8c63a6e61dfd..0a7383e1302d 100644
--- a/fs/f2fs/sysfs.c
+++ b/fs/f2fs/sysfs.c
@@ -97,7 +97,8 @@ static ssize_t lifetime_write_kbytes_show(struct f2fs_attr *a,
 
return sprintf(buf, "%llu\n",
(unsigned long long)(sbi->kbytes_written +
-   BD_PART_WRITTEN(sbi)));
+   ((f2fs_get_sectors_written(sbi) -
+   sbi->sectors_written_start) >> 1)));
 }
 
 static ssize_t features_show(struct f2fs_attr *a,
-- 
2.22.0

[PATCH v2 3/6] elf: Fix failure handling in _dl_map_object_from_fd

[Szabolcs Nagy]

There are many failure paths that call lose to do local cleanups
in _dl_map_object_from_fd, but it did not clean everything.

Handle l_phdr, l_libname and mapped segments in the common failure
handling code.

There are various bits that may not be cleaned properly on failure
(e.g. executable stack, tlsid, incomplete dl_map_segments).
---
 elf/dl-load.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/elf/dl-load.c b/elf/dl-load.c
index 21e55deb19..9c71b7562c 100644
--- a/elf/dl-load.c
+++ b/elf/dl-load.c
@@ -914,8 +914,15 @@ lose (int code, int fd, const char *name, char *realname, 
struct link_map *l,
   /* The file might already be closed.  */
   if (fd != -1)
 (void) __close_nocancel (fd);
+  if (l != NULL && l->l_map_start != 0)
+_dl_unmap_segments (l);
   if (l != NULL && l->l_origin != (char *) -1l)
 free ((char *) l->l_origin);
+  if (l != NULL && !l->l_libname->dont_free)
+free (l->l_libname);
+  if (l != NULL && l->l_phdr_allocated)
+free ((void *) l->l_phdr);
+
   free (l);
   free (realname);
 
@@ -1256,7 +1263,11 @@ _dl_map_object_from_fd (const char *name, const char 
*origname, int fd,
 errstring = _dl_map_segments (l, fd, header, type, loadcmds, nloadcmds,
  maplength, has_holes, loader);
 if (__glibc_unlikely (errstring != NULL))
-  goto call_lose;
+  {
+   /* Mappings can be in an inconsistent state: avoid unmap.  */
+   l->l_map_start = l->l_map_end = 0;
+   goto call_lose;
+  }
 
 /* Process program headers again after load segments are mapped in
case processing requires accessing those segments.  Scan program
@@ -1294,14 +1305,6 @@ _dl_map_object_from_fd (const char *name, const char 
*origname, int fd,
   || (__glibc_unlikely (l->l_flags_1 & DF_1_PIE)
  && __glibc_unlikely ((mode & __RTLD_OPENEXEC) == 0)))
 {
-  /* We are not supposed to load this object.  Free all resources.  */
-  _dl_unmap_segments (l);
-
-  if (!l->l_libname->dont_free)
-   free (l->l_libname);
-
-  if (l->l_phdr_allocated)
-   free ((void *) l->l_phdr);
 
   if (l->l_flags_1 & DF_1_PIE)
errstring
@@ -1392,6 +1395,9 @@ cannot enable executable stack as shared object 
requires");
   /* Signal that we closed the file.  */
   fd = -1;
 
+  /* Failures before this point are handled locally via lose.
+ No more failures are allowed in this function until return.  */
+
   /* If this is ET_EXEC, we should have loaded it as lt_executable.  */
   assert (type != ET_EXEC || l->l_type == lt_executable);
 
-- 
2.17.1

Re: [PATCH v2 2/3] mfd: si476x-core.h: fix "regulator" spelling in comment

[Lee Jones]

On Fri, 27 Nov 2020, Michael Klein wrote:

> "regualtor" -> "regulator"
> 
> Signed-off-by: Michael Klein 
> ---
> Changes in v2:
>   - split patch
>   - make subject line more forthcoming
> 
>  include/linux/mfd/si476x-core.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 01/16] mfd: bcm590xx: drop of_match_ptr from of_device_id table

[Lee Jones]

On Fri, 27 Nov 2020, Miguel Ojeda wrote:

> On Fri, Nov 27, 2020 at 10:21 AM Lee Jones  wrote:
> >
> > It's a per-subsystem convention thing.
> 
> I think some allow both, too. For people that send tree-wide patches,
> it would be if we agreed on the convention...

I have no problem with that ... so long as it's mine. ;)

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 01/17] mm/highmem: Lift memcpy_[to|from]_page and memset_page to core

[Matthew Wilcox]

On Fri, Nov 27, 2020 at 03:06:24PM +0200, Joonas Lahtinen wrote:
> Quoting ira.we...@intel.com (2020-11-24 08:07:39)
> > From: Ira Weiny 
> > 
> > Working through a conversion to a call such as kmap_thread() revealed
> > many places where the pattern kmap/memcpy/kunmap occurred.
> > 
> > Eric Biggers, Matthew Wilcox, Christoph Hellwig, Dan Williams, and Al
> > Viro all suggested putting this code into helper functions.  Al Viro
> > further pointed out that these functions already existed in the iov_iter
> > code.[1]
> > 
> > Placing these functions in 'highmem.h' is suboptimal especially with the
> > changes being proposed in the functionality of kmap.  From a caller
> > perspective including/using 'highmem.h' implies that the functions
> > defined in that header are only required when highmem is in use which is
> > increasingly not the case with modern processors.  Some headers like
> > mm.h or string.h seem ok but don't really portray the functionality
> > well.  'pagemap.h', on the other hand, makes sense and is already
> > included in many of the places we want to convert.
> > 
> > Another alternative would be to create a new header for the promoted
> > memcpy functions, but it masks the fact that these are designed to copy
> > to/from pages using the kernel direct mappings and complicates matters
> > with a new header.
> > 
> > Lift memcpy_to_page(), memcpy_from_page(), and memzero_page() to
> > pagemap.h.
> > 
> > Also, add a memcpy_page(), memmove_page, and memset_page() to cover more
> > kmap/mem*/kunmap. patterns.
> > 
> > [1] 
> > https://lore.kernel.org/lkml/20201013200149.gi3576...@zeniv.linux.org.uk/
> > https://lore.kernel.org/lkml/20201013112544.ga5...@infradead.org/
> > 
> > Cc: Dave Hansen 
> > Suggested-by: Matthew Wilcox 
> > Suggested-by: Christoph Hellwig 
> > Suggested-by: Dan Williams 
> > Suggested-by: Al Viro 
> > Suggested-by: Eric Biggers 
> > Signed-off-by: Ira Weiny 
> 
> 
> 
> > +static inline void memset_page(struct page *page, int val, size_t offset, 
> > size_t len)
> > +{
> > +   char *addr = kmap_atomic(page);
> > +   memset(addr + offset, val, len);
> > +   kunmap_atomic(addr);
> > +}
> 
> Other functions have (page, offset) pair. Insertion of 'val' in the middle 
> here required
> to take a double look during review.

Let's be explicit here.  Your suggested order is:

(page, offset, val, len)

right?  I think I would prefer that to (page, val, offset, len).

[PATCH v2 4/6] elf: Move note processing after l_phdr is updated

[Szabolcs Nagy]

Program headers are processed in two pass: after the first pass
load segments are mmapped so in the second pass target specific
note processing logic can access the notes.

The second pass is moved later so various link_map fields are
set up that may be useful for note processing such as l_phdr.
The second pass should be before the fd is closed so that is
available.
---
 elf/dl-load.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/elf/dl-load.c b/elf/dl-load.c
index 9c71b7562c..b0d65f32cc 100644
--- a/elf/dl-load.c
+++ b/elf/dl-load.c
@@ -1268,21 +1268,6 @@ _dl_map_object_from_fd (const char *name, const char 
*origname, int fd,
l->l_map_start = l->l_map_end = 0;
goto call_lose;
   }
-
-/* Process program headers again after load segments are mapped in
-   case processing requires accessing those segments.  Scan program
-   headers backward so that PT_NOTE can be skipped if PT_GNU_PROPERTY
-   exits.  */
-for (ph = [l->l_phnum]; ph != phdr; --ph)
-  switch (ph[-1].p_type)
-   {
-   case PT_NOTE:
- _dl_process_pt_note (l, [-1]);
- break;
-   case PT_GNU_PROPERTY:
- _dl_process_pt_gnu_property (l, [-1]);
- break;
-   }
   }
 
   if (l->l_ld == 0)
@@ -1386,6 +1371,21 @@ cannot enable executable stack as shared object 
requires");
   if (l->l_tls_initimage != NULL)
 l->l_tls_initimage = (char *) l->l_tls_initimage + l->l_addr;
 
+  /* Process program headers again after load segments are mapped in
+ case processing requires accessing those segments.  Scan program
+ headers backward so that PT_NOTE can be skipped if PT_GNU_PROPERTY
+ exits.  */
+  for (ph = >l_phdr[l->l_phnum]; ph != l->l_phdr; --ph)
+switch (ph[-1].p_type)
+  {
+  case PT_NOTE:
+   _dl_process_pt_note (l, [-1]);
+   break;
+  case PT_GNU_PROPERTY:
+   _dl_process_pt_gnu_property (l, [-1]);
+   break;
+  }
+
   /* We are done mapping in the file.  We no longer need the descriptor.  */
   if (__glibc_unlikely (__close_nocancel (fd) != 0))
 {
-- 
2.17.1

[PATCH v2 5/6] elf: Pass the fd to note processing

[Szabolcs Nagy]

To handle GNU property notes on aarch64 some segments need to
be mmaped again, so the fd of the loaded ELF module is needed.

When the fd is not available (kernel loaded modules), then -1
is passed.

The fd is passed to both _dl_process_pt_gnu_property and
_dl_process_pt_note for consistency. Target specific note
processing functions are updated accordingly.
---
 elf/dl-load.c  | 12 +++-
 elf/rtld.c |  4 ++--
 sysdeps/aarch64/dl-prop.h  |  6 +++---
 sysdeps/generic/dl-prop.h  |  6 +++---
 sysdeps/generic/ldsodefs.h |  5 +++--
 sysdeps/x86/dl-prop.h  |  6 +++---
 6 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/elf/dl-load.c b/elf/dl-load.c
index b0d65f32cc..74039f22a6 100644
--- a/elf/dl-load.c
+++ b/elf/dl-load.c
@@ -837,10 +837,12 @@ _dl_init_paths (const char *llp, const char *source)
 
 /* Process PT_GNU_PROPERTY program header PH in module L after
PT_LOAD segments are mapped.  Only one NT_GNU_PROPERTY_TYPE_0
-   note is handled which contains processor specific properties.  */
+   note is handled which contains processor specific properties.
+   FD is -1 for the kernel mapped main executable otherwise it is
+   the fd used for loading module L.  */
 
 void
-_dl_process_pt_gnu_property (struct link_map *l, const ElfW(Phdr) *ph)
+_dl_process_pt_gnu_property (struct link_map *l, int fd, const ElfW(Phdr) *ph)
 {
   const ElfW(Nhdr) *note = (const void *) (ph->p_vaddr + l->l_addr);
   const ElfW(Addr) size = ph->p_memsz;
@@ -887,7 +889,7 @@ _dl_process_pt_gnu_property (struct link_map *l, const 
ElfW(Phdr) *ph)
  last_type = type;
 
  /* Target specific property processing.  */
- if (_dl_process_gnu_property (l, type, datasz, ptr) == 0)
+ if (_dl_process_gnu_property (l, fd, type, datasz, ptr) == 0)
return;
 
  /* Check the next property item.  */
@@ -1379,10 +1381,10 @@ cannot enable executable stack as shared object 
requires");
 switch (ph[-1].p_type)
   {
   case PT_NOTE:
-   _dl_process_pt_note (l, [-1]);
+   _dl_process_pt_note (l, fd, [-1]);
break;
   case PT_GNU_PROPERTY:
-   _dl_process_pt_gnu_property (l, [-1]);
+   _dl_process_pt_gnu_property (l, fd, [-1]);
break;
   }
 
diff --git a/elf/rtld.c b/elf/rtld.c
index c4ffc8d4b7..ec62567580 100644
--- a/elf/rtld.c
+++ b/elf/rtld.c
@@ -1540,10 +1540,10 @@ dl_main (const ElfW(Phdr) *phdr,
 switch (ph[-1].p_type)
   {
   case PT_NOTE:
-   _dl_process_pt_note (main_map, [-1]);
+   _dl_process_pt_note (main_map, -1, [-1]);
break;
   case PT_GNU_PROPERTY:
-   _dl_process_pt_gnu_property (main_map, [-1]);
+   _dl_process_pt_gnu_property (main_map, -1, [-1]);
break;
   }
 
diff --git a/sysdeps/aarch64/dl-prop.h b/sysdeps/aarch64/dl-prop.h
index b0785bda83..2016d1472e 100644
--- a/sysdeps/aarch64/dl-prop.h
+++ b/sysdeps/aarch64/dl-prop.h
@@ -35,13 +35,13 @@ _dl_open_check (struct link_map *m)
 }
 
 static inline void __attribute__ ((always_inline))
-_dl_process_pt_note (struct link_map *l, const ElfW(Phdr) *ph)
+_dl_process_pt_note (struct link_map *l, int fd, const ElfW(Phdr) *ph)
 {
 }
 
 static inline int
-_dl_process_gnu_property (struct link_map *l, uint32_t type, uint32_t datasz,
- void *data)
+_dl_process_gnu_property (struct link_map *l, int fd, uint32_t type,
+ uint32_t datasz, void *data)
 {
   if (type == GNU_PROPERTY_AARCH64_FEATURE_1_AND)
 {
diff --git a/sysdeps/generic/dl-prop.h b/sysdeps/generic/dl-prop.h
index f1cf576fe3..df27ff8e6a 100644
--- a/sysdeps/generic/dl-prop.h
+++ b/sysdeps/generic/dl-prop.h
@@ -37,15 +37,15 @@ _dl_open_check (struct link_map *m)
 }
 
 static inline void __attribute__ ((always_inline))
-_dl_process_pt_note (struct link_map *l, const ElfW(Phdr) *ph)
+_dl_process_pt_note (struct link_map *l, int fd, const ElfW(Phdr) *ph)
 {
 }
 
 /* Called for each property in the NT_GNU_PROPERTY_TYPE_0 note of L,
processing of the properties continues until this returns 0.  */
 static inline int __attribute__ ((always_inline))
-_dl_process_gnu_property (struct link_map *l, uint32_t type, uint32_t datasz,
- void *data)
+_dl_process_gnu_property (struct link_map *l, int fd, uint32_t type,
+ uint32_t datasz, void *data)
 {
   return 0;
 }
diff --git a/sysdeps/generic/ldsodefs.h b/sysdeps/generic/ldsodefs.h
index b1da03cafe..89eab4719d 100644
--- a/sysdeps/generic/ldsodefs.h
+++ b/sysdeps/generic/ldsodefs.h
@@ -933,8 +933,9 @@ extern void _dl_rtld_di_serinfo (struct link_map *loader,
 Dl_serinfo *si, bool counting);
 
 /* Process PT_GNU_PROPERTY program header PH in module L after
-   PT_LOAD segments are mapped.  */
-void _dl_process_pt_gnu_property (struct link_map *l, const ElfW(Phdr) *ph);
+   PT_LOAD segments are mapped from file FD.  */
+void 

[PATCH v2 6/6] aarch64: Use mmap to add PROT_BTI instead of mprotect [BZ #26831]

[Szabolcs Nagy]

Re-mmap executable segments if possible instead of using mprotect
to add PROT_BTI. This allows using BTI protection with security
policies that prevent mprotect with PROT_EXEC.

If the fd of the ELF module is not available because it was kernel
mapped then mprotect is used and failures are ignored.  To protect
the main executable even when mprotect is filtered the linux kernel
will have to be changed to add PROT_BTI to it.

Computing the mapping bounds follows _dl_map_object_from_fd more
closely now.

The delayed failure reporting is mainly needed because currently
_dl_process_gnu_properties does not propagate failures such that
the required cleanups happen. Using the link_map_machine struct for
error propagation is not ideal, but this seemed to be the least
intrusive solution.

Fixes bug 26831.
---
 sysdeps/aarch64/dl-bti.c  | 67 +--
 sysdeps/aarch64/dl-prop.h |  8 -
 sysdeps/aarch64/linkmap.h |  2 +-
 3 files changed, 52 insertions(+), 25 deletions(-)

diff --git a/sysdeps/aarch64/dl-bti.c b/sysdeps/aarch64/dl-bti.c
index 8f4728adce..34b5294f92 100644
--- a/sysdeps/aarch64/dl-bti.c
+++ b/sysdeps/aarch64/dl-bti.c
@@ -19,39 +19,62 @@
 #include 
 #include 
 #include 
+#include 
 
-static int
-enable_bti (struct link_map *map, const char *program)
+/* See elf/dl-load.h.  */
+#ifndef MAP_COPY
+# define MAP_COPY (MAP_PRIVATE | MAP_DENYWRITE)
+#endif
+
+/* Enable BTI protection for MAP.  */
+
+void
+_dl_bti_protect (struct link_map *map, int fd)
 {
+  const size_t pagesz = GLRO(dl_pagesize);
   const ElfW(Phdr) *phdr;
-  unsigned prot;
 
   for (phdr = map->l_phdr; phdr < >l_phdr[map->l_phnum]; ++phdr)
 if (phdr->p_type == PT_LOAD && (phdr->p_flags & PF_X))
   {
-   void *start = (void *) (phdr->p_vaddr + map->l_addr);
-   size_t len = phdr->p_memsz;
+   size_t vstart = ALIGN_DOWN (phdr->p_vaddr, pagesz);
+   size_t vend = ALIGN_UP (phdr->p_vaddr + phdr->p_filesz, pagesz);
+   off_t off = ALIGN_DOWN (phdr->p_offset, pagesz);
+   void *start = (void *) (vstart + map->l_addr);
+   size_t len = vend - vstart;
 
-   prot = PROT_EXEC | PROT_BTI;
+   /* Add PROT_BTI.  */
+   unsigned prot = PROT_EXEC | PROT_BTI;
if (phdr->p_flags & PF_R)
  prot |= PROT_READ;
if (phdr->p_flags & PF_W)
  prot |= PROT_WRITE;
 
-   if (__mprotect (start, len, prot) < 0)
- {
-   if (program)
- _dl_fatal_printf ("%s: mprotect failed to turn on BTI\n",
-   map->l_name);
-   else
- _dl_signal_error (errno, map->l_name, "dlopen",
-   N_("mprotect failed to turn on BTI"));
- }
+   if (fd == -1)
+ /* Ignore failures for kernel mapped binaries.  */
+ __mprotect (start, len, prot);
+   else
+ map->l_mach.bti_fail = __mmap (start, len, prot,
+MAP_FIXED|MAP_COPY|MAP_FILE,
+fd, off) == MAP_FAILED;
   }
-  return 0;
 }
 
-/* Enable BTI for MAP and its dependencies.  */
+
+static void
+bti_failed (struct link_map *l, const char *program)
+{
+  if (program)
+_dl_fatal_printf ("%s: %s: failed to turn on BTI protection\n",
+ program, l->l_name);
+  else
+/* Note: the errno value is not available any more.  */
+_dl_signal_error (0, l->l_name, "dlopen",
+ N_("failed to turn on BTI protection"));
+}
+
+
+/* Report BTI protection failures for MAP and its dependencies.  */
 
 void
 _dl_bti_check (struct link_map *map, const char *program)
@@ -59,16 +82,14 @@ _dl_bti_check (struct link_map *map, const char *program)
   if (!GLRO(dl_aarch64_cpu_features).bti)
 return;
 
-  if (map->l_mach.bti)
-enable_bti (map, program);
+  if (map->l_mach.bti_fail)
+bti_failed (map, program);
 
   unsigned int i = map->l_searchlist.r_nlist;
   while (i-- > 0)
 {
   struct link_map *l = map->l_initfini[i];
-  if (l->l_init_called)
-   continue;
-  if (l->l_mach.bti)
-   enable_bti (l, program);
+  if (l->l_mach.bti_fail)
+   bti_failed (l, program);
 }
 }
diff --git a/sysdeps/aarch64/dl-prop.h b/sysdeps/aarch64/dl-prop.h
index 2016d1472e..e926e54984 100644
--- a/sysdeps/aarch64/dl-prop.h
+++ b/sysdeps/aarch64/dl-prop.h
@@ -19,6 +19,8 @@
 #ifndef _DL_PROP_H
 #define _DL_PROP_H
 
+extern void _dl_bti_protect (struct link_map *, int) attribute_hidden;
+
 extern void _dl_bti_check (struct link_map *, const char *)
 attribute_hidden;
 
@@ -43,6 +45,10 @@ static inline int
 _dl_process_gnu_property (struct link_map *l, int fd, uint32_t type,
  uint32_t datasz, void *data)
 {
+  if (!GLRO(dl_aarch64_cpu_features).bti)
+/* Skip note processing.  */
+return 0;
+
   if (type == GNU_PROPERTY_AARCH64_FEATURE_1_AND)
 {
   /* Stop if the property note is ill-formed.  */
@@ -51,7 +57,7 @@ 

Re: [PATCH 7/8] rtc: rework rtc_register_device() resource management

[Lee Jones]

On Fri, 27 Nov 2020, Bartosz Golaszewski wrote:

> On Fri, Nov 27, 2020 at 10:16 AM Lee Jones  wrote:
> >
> >
> >
> > On Mon, 9 Nov 2020 at 16:34, Bartosz Golaszewski  wrote:
> >>
> >> From: Bartosz Golaszewski 
> >>
> >> rtc_register_device() is a managed interface but it doesn't use devres
> >> by itself - instead it marks an rtc_device as "registered" and the devres
> >> callback for devm_rtc_allocate_device() takes care of resource release.
> >>
> >> This doesn't correspond with the design behind devres where managed
> >> structures should not be aware of being managed. The correct solution
> >> here is to register a separate devres callback for unregistering the
> >> device.
> >>
> >> While at it: rename rtc_register_device() to devm_rtc_register_device()
> >> and add it to the list of managed interfaces in devres.rst. This way we
> >> can avoid any potential confusion of driver developers who may expect
> >> there to exist a corresponding unregister function.
> >>
> >> Signed-off-by: Bartosz Golaszewski 
> >> ---
> >>  .../driver-api/driver-model/devres.rst|  1 +
> >>  arch/alpha/kernel/rtc.c   |  2 +-
> >>  drivers/mfd/menelaus.c|  2 +-
> >
> >
> > This patch should have been sent to and Acked by MFD too.
> >
> 
> Sorry Lee, I missed the fact that there were changes outside of
> drivers/rtc/. Other than skipping the MFD maintainer - do you see
> anything wrong in that bit?

No real harm done.

The patch looks fine from an MFD standpoint.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v4 08/14] arm64: exec: Adjust affinity for compat tasks with mismatched 32-bit EL0

[Qais Yousef]

On 11/24/20 15:50, Will Deacon wrote:
> When exec'ing a 32-bit task on a system with mismatched support for
> 32-bit EL0, try to ensure that it starts life on a CPU that can actually
> run it.
> 
> Signed-off-by: Will Deacon 
> ---
>  arch/arm64/kernel/process.c | 42 -
>  1 file changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 1540ab0fbf23..72116b0c7c73 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -625,6 +626,45 @@ unsigned long arch_align_stack(unsigned long sp)
>   return sp & ~0xf;
>  }
>  
> +static void adjust_compat_task_affinity(struct task_struct *p)
> +{
> + cpumask_var_t cpuset_mask;
> + const struct cpumask *possible_mask = system_32bit_el0_cpumask();
> + const struct cpumask *newmask = possible_mask;
> +
> + /*
> +  * Restrict the CPU affinity mask for a 32-bit task so that it contains
> +  * only the 32-bit-capable subset of its original CPU mask. If this is
> +  * empty, then try again with the cpuset allowed mask. If that fails,
> +  * forcefully override it with the set of all 32-bit-capable CPUs that
> +  * we know about.
> +  *
> +  * From the perspective of the task, this looks similar to what would
> +  * happen if the 64-bit-only CPUs were hot-unplugged at the point of
> +  * execve().
> +  */
> + if (!restrict_cpus_allowed_ptr(p, possible_mask))
> + goto out;
> +
> + if (alloc_cpumask_var(_mask, GFP_KERNEL)) {
> + cpuset_cpus_allowed(p, cpuset_mask);
> + if (cpumask_and(cpuset_mask, cpuset_mask, possible_mask)) {
> + newmask = cpuset_mask;
> + goto out_set_mask;
> + }
> + }

Wouldn't it be better to move this logic to restrict_cpus_allowed_ptr()?
I think it should always take cpusets into account and it's not special to
this particular handling here, no?

> +
> + if (printk_ratelimit()) {
> + printk_deferred("Overriding affinity for 32-bit process %d (%s) 
> to CPUs %*pbl\n",
> + task_pid_nr(p), p->comm, 
> cpumask_pr_args(newmask));
> + }

We have 2 cases where the affinity could have been overridden but we won't
print anything:

1. restrict_cpus_allowed_ptr()
2. intersection of cpuset_mask and possible mask drops some cpus.

Shouldn't we print something in these cases too?

IMO it would be better to move this print to restrict_cpus_allowed_ptr() too.

Thanks

--
Qais Yousef

> +out_set_mask:
> + set_cpus_allowed_ptr(p, newmask);
> + free_cpumask_var(cpuset_mask);
> +out:
> + set_tsk_thread_flag(current, TIF_NOTIFY_RESUME);
> +}
> +
>  /*
>   * Called from setup_new_exec() after (COMPAT_)SET_PERSONALITY.
>   */
> @@ -635,7 +675,7 @@ void arch_setup_new_exec(void)
>   if (is_compat_task()) {
>   mmflags = MMCF_AARCH32;
>   if (static_branch_unlikely(_mismatched_32bit_el0))
> - set_tsk_thread_flag(current, TIF_NOTIFY_RESUME);
> + adjust_compat_task_affinity(current);
>   }
>  
>   current->mm->context.flags = mmflags;
> -- 
> 2.29.2.454.gaff20da3a2-goog
> 

Re: [RFC 1/2] dt-bindings: thermal: sprd: Add virtual thermal documentation

[Daniel Lezcano]

Hi Lukasz,

On 27/11/2020 10:27, Lukasz Luba wrote:
> 
> 
> On 11/27/20 8:35 AM, gao.yunxi...@gmail.com wrote:
>> From: "jeson.gao" 
>>
>> virtual thermal node definition description in dts file
>>
>> Signed-off-by: jeson.gao 
>> ---

[ ... ]

> It's coming back. There were attempts to solve this problem.
> Javi tried to solved this using hierarchical thermal zones [1].
> It was even agreed (IIRC during LPC) but couldn't continue. Then Eduardo
> was going to continue this (last message at [3]). Unfortunately,
> development stopped.
> 
> I also have out-of-tree similar implementation for my Odroid-xu4,
> which does no have an 'SoC' sensor, but have CPU sensors and needs
> some aggregation function to get temperature.
> 
> I can pick up Javi's patches and continue 'hierarchical thermal zones'
> approach.
> 
> Javi, Daniel, Rui what do you think?

I already worked on the hierarchical thermal zones and my opinion is
that fits not really well.

We want to define a new feature because the thermal framework is built
on the 1:1 relationship between a governor and a thermal zone.

Practically speaking, we want to mitigate two thermal zones from one
governor, especially here the IPA governor.

The DTPM framework is being implemented to solve that by providing an
automatic power rebalancing between the power manageable capable devices.

In our case, the IPA would stick on the 'sustainable-power' resulting on
the aggregation of the two performance domains and set the power limit
on the parent node. The automatic power rebalancing will ensure maximum
throughput between the two performance domains instead of capping the whole.


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH][next] media: vidtv: fix a read from an object after it has been freed

[Colin King]

From: Colin Ian King 

Currently the call to vidtv_psi_pat_table_destroy frees the object
m->si.pat however m->si.pat->num_pmt is being accessed after the
free.  Fix this by destroying m->si.pat after the m->si.pmt_secs[]
objects have been freed.

Addresses-Coverity: ("Read from pointer after free")
Fixes: 039b7caed173 ("media: vidtv: add a PID entry for the NIT table")
Signed-off-by: Colin Ian King 
---
 drivers/media/test-drivers/vidtv/vidtv_channel.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/test-drivers/vidtv/vidtv_channel.c 
b/drivers/media/test-drivers/vidtv/vidtv_channel.c
index 8ad6c0744d36..7838e6272712 100644
--- a/drivers/media/test-drivers/vidtv/vidtv_channel.c
+++ b/drivers/media/test-drivers/vidtv/vidtv_channel.c
@@ -504,11 +504,11 @@ void vidtv_channel_si_destroy(struct vidtv_mux *m)
 {
u32 i;
 
-   vidtv_psi_pat_table_destroy(m->si.pat);
-
for (i = 0; i < m->si.pat->num_pmt; ++i)
vidtv_psi_pmt_table_destroy(m->si.pmt_secs[i]);
 
+   vidtv_psi_pat_table_destroy(m->si.pat);
+
kfree(m->si.pmt_secs);
vidtv_psi_sdt_table_destroy(m->si.sdt);
vidtv_psi_nit_table_destroy(m->si.nit);
-- 
2.29.2

Re: [PATCH v2 2/5] clk: Add CLK_GET_PARENT_NOCACHE flag (fwd)

[Julia Lawall]

Please check line 2432.  Based on the preceeding tests, there may be a
NULL pointer dereference.

julia

-- Forwarded message --
Date: Fri, 27 Nov 2020 06:27:51 +0800
From: kernel test robot 
To: kbu...@lists.01.org
Cc: l...@intel.com, Julia Lawall 
Subject: Re: [PATCH v2 2/5] clk: Add CLK_GET_PARENT_NOCACHE flag

CC: kbuild-...@lists.01.org
In-Reply-To: <1606394409-12755-3-git-send-email-abel.v...@nxp.com>
References: <1606394409-12755-3-git-send-email-abel.v...@nxp.com>
TO: Abel Vesa 
TO: Stephen Boyd 
TO: Sascha Hauer 
TO: Peng Fan 
TO: Fabio Estevam 
TO: Anson Huang 
TO: Dong Aisheng 
TO: Jacky Bai 
CC: NXP Linux Team 
CC: linux-...@vger.kernel.org
CC: Linux Kernel Mailing List 

Hi Abel,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on shawnguo/for-next]
[also build test WARNING on clk/clk-next v5.10-rc5 next-20201126]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Abel-Vesa/clk-imx-Register-the-dram_apb-and-dram_alt-as-read-only/20201126-204442
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git 
for-next
:: branch date: 10 hours ago
:: commit date: 10 hours ago
config: x86_64-randconfig-c002-20201127 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 
Reported-by: Julia Lawall 


"coccinelle warnings: (new ones prefixed by >>)"
>> drivers/clk/clk.c:2432:23-29: ERROR: clk -> core is NULL but dereferenced.
   drivers/clk/clk.c:2432:50-56: ERROR: clk -> core is NULL but dereferenced.

vim +2432 drivers/clk/clk.c

05e4e881cde17e7 Abel Vesa2020-11-26  2413
4dff95dc9477a34 Stephen Boyd 2015-04-30  2414  /**
4dff95dc9477a34 Stephen Boyd 2015-04-30  2415   * clk_get_parent - return the 
parent of a clk
4dff95dc9477a34 Stephen Boyd 2015-04-30  2416   * @clk: the clk whose parent 
gets returned
4dff95dc9477a34 Stephen Boyd 2015-04-30  2417   *
4dff95dc9477a34 Stephen Boyd 2015-04-30  2418   * Simply returns clk->parent.  
Returns NULL if clk is NULL.
4935b22c46ea5e2 James Hogan  2013-07-29  2419   */
4dff95dc9477a34 Stephen Boyd 2015-04-30  2420  struct clk 
*clk_get_parent(struct clk *clk)
4dff95dc9477a34 Stephen Boyd 2015-04-30  2421  {
4dff95dc9477a34 Stephen Boyd 2015-04-30  2422   struct clk *parent;
da0f0b2c3ad2ad9 Tomasz Figa  2013-09-29  2423
fc4a05d4b0eb1a0 Stephen Boyd 2015-06-25  2424   if (!clk)
fc4a05d4b0eb1a0 Stephen Boyd 2015-06-25  2425   return NULL;
fc4a05d4b0eb1a0 Stephen Boyd 2015-06-25  2426
4dff95dc9477a34 Stephen Boyd 2015-04-30  2427   clk_prepare_lock();
05e4e881cde17e7 Abel Vesa2020-11-26  2428   if (clk->core && 
(clk->core->flags & CLK_GET_PARENT_NOCACHE))
05e4e881cde17e7 Abel Vesa2020-11-26  2429   parent = 
__clk_get_parent(clk->core)->hw->clk;
05e4e881cde17e7 Abel Vesa2020-11-26  2430   else
fc4a05d4b0eb1a0 Stephen Boyd 2015-06-25  2431   /* TODO: Create a 
per-user clk and change callers to call clk_put */
fc4a05d4b0eb1a0 Stephen Boyd 2015-06-25 @2432   parent = 
!clk->core->parent ? NULL : clk->core->parent->hw->clk;
4dff95dc9477a34 Stephen Boyd 2015-04-30  2433   clk_prepare_unlock();
4935b22c46ea5e2 James Hogan  2013-07-29  2434
4dff95dc9477a34 Stephen Boyd 2015-04-30  2435   return parent;
4935b22c46ea5e2 James Hogan  2013-07-29  2436  }
4dff95dc9477a34 Stephen Boyd 2015-04-30  2437  
EXPORT_SYMBOL_GPL(clk_get_parent);
4935b22c46ea5e2 James Hogan  2013-07-29  2438

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

.config.gz
Description: application/gzip

Re: [PATCH] mm: Don't fault around userfaultfd-registered regions on reads

[Peter Xu]

On Fri, Nov 27, 2020 at 10:16:05AM +0200, Mike Rapoport wrote:
> On Thu, Nov 26, 2020 at 05:23:59PM -0500, Peter Xu wrote:
> > Faulting around for reads are in most cases helpful for the performance so 
> > that
> > continuous memory accesses may avoid another trip of page fault.  However it
> > may not always work as expected.
> > 
> > For example, userfaultfd registered regions may not be the best candidate 
> > for
> > pre-faults around the reads.
> > 
> > For missing mode uffds, fault around does not help because if the page cache
> > existed, then the page should be there already.  If the page cache is not
> > there, nothing else we can do, either.  If the fault-around code is 
> > destined to
> > be helpless for userfault-missing vmas, then ideally we can skip it.
> > 
> > For wr-protected mode uffds, errornously fault in those pages around could 
> > lead
> > to threads accessing the pages without uffd server's awareness.  For 
> > example,
> > when punching holes on uffd-wp registered shmem regions, we'll first try to
> > unmap all the pages before evicting the page cache but without locking the
> > page (please refer to shmem_fallocate(), where unmap_mapping_range() is 
> > called
> > before shmem_truncate_range()).  When fault-around happens near a hole being
> > punched, we might errornously fault in the "holes" right before it will be
> > punched.  Then there's a small window before the page cache was finally
> > dropped, and after the page will be writable again (NOTE: the uffd-wp 
> > protect
> > information is totally lost due to the pre-unmap in shmem_fallocate(), so 
> > the
> > page can be writable within the small window).  That's severe data loss.
> > 
> > Let's grant the userspace full control of the uffd-registered ranges, rather
> > than trying to do the tricks.
> > 
> > Cc: Hugh Dickins 
> > Cc: Andrea Arcangeli 
> > Cc: Andrew Morton 
> > Cc: Mike Rapoport 
> > Signed-off-by: Peter Xu 
> 
> One nit below, except that
> 
> Reviewed-by: Mike Rapoport 

Thanks!

> > +static inline bool vma_registered_userfaultfd(struct vm_area_struct *vma)
> > +{
> > +   return userfaultfd_missing(vma) || userfaultfd_wp(vma);
> > +}
> 
> We have userfaultfd_armed() that does exectly this, don't we?

Yes, will fix that up.

-- 
Peter Xu

Re: [PATCH v4 09/14] cpuset: Don't use the cpu_possible_mask as a last resort for cgroup v1

[Qais Yousef]

On 11/24/20 15:50, Will Deacon wrote:
> If the scheduler cannot find an allowed CPU for a task,
> cpuset_cpus_allowed_fallback() will widen the affinity to cpu_possible_mask
> if cgroup v1 is in use.
> 
> In preparation for allowing architectures to provide their own fallback
> mask, just return early if we're not using cgroup v2 and allow
> select_fallback_rq() to figure out the mask by itself.

What about cpuset_attach()? When a task attaches to a new group its affinity
could be reset to possible_cpu_mask if it moves to top_cpuset or the
intersection of effective_cpus & cpu_online_mask.

Probably handled with later patches.

/me continue to look at the rest

Okay so in patch 11 we make set_cpus_allowed_ptr() fail. cpuset_attach will
just do WARN_ON_ONCE() and carry on.

I think we can fix that by making sure cpuset_can_attach() will fail. Which can
be done by fixing task_can_attach() to take into account the new arch
task_cpu_possible_mask()?

Thanks

--
Qais Yousef

> 
> Cc: Li Zefan 
> Cc: Tejun Heo 
> Cc: Johannes Weiner 
> Reviewed-by: Quentin Perret 
> Signed-off-by: Will Deacon 
> ---
>  kernel/cgroup/cpuset.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index 57b5b5d0a5fd..e970737c3ed2 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -3299,9 +3299,11 @@ void cpuset_cpus_allowed(struct task_struct *tsk, 
> struct cpumask *pmask)
>  
>  void cpuset_cpus_allowed_fallback(struct task_struct *tsk)
>  {
> + if (!is_in_v2_mode())
> + return; /* select_fallback_rq will try harder */
> +
>   rcu_read_lock();
> - do_set_cpus_allowed(tsk, is_in_v2_mode() ?
> - task_cs(tsk)->cpus_allowed : cpu_possible_mask);
> + do_set_cpus_allowed(tsk, task_cs(tsk)->cpus_allowed);
>   rcu_read_unlock();
>  
>   /*
> -- 
> 2.29.2.454.gaff20da3a2-goog
> 

[RFC PATCH 0/3] net: Adding the Sparx5 Switch Driver

[Steen Hegelund]

This series provides the Microchip Sparx5 Switch Driver

The Sparx5 Carrier Ethernet and Industrial switch family delivers 64 Ethernet
ports and up to 200 Gbps of switching bandwidth.

It provides a rich set of Ethernet switching features such as hierarchical QoS,
hardware-based OAM  and service activation testing, protection switching,
IEEE 1588, and Synchronous Ethernet.

Using provider bridging (Q-in-Q) and MPLS/MPLS-TP technology, it delivers MEF CE
2.0 Ethernet virtual connections (EVCs) and features advanced TCAM 
classification
in both ingress and egress.

Per-EVC features include advanced L3-aware classification, a rich set of
statistics, OAM for end-to-end performance monitoring, and dual-rate policing
and shaping.

Time sensitive networking (TSN) is supported through a comprehensive set of
features including frame preemption, cut-through, frame replication and
elimination for reliability, enhanced scheduling: credit-based shaping,
time-aware shaping, cyclic queuing, and forwarding, and per-stream
policing and filtering.

Together with IEEE 1588 and IEEE 802.1AS support, this guarantees low-latency
deterministic networking for Fronthaul, Carrier, and Industrial Ethernet.

The Sparx5 switch family consists of following SKUs:

- VSC7546 Sparx5-64
  up to 64 Gbps of bandwidth with the following primary port configurations:
  - 6 *10G
  - 16 * 2.5G + 2 * 10G
  - 24 * 1G + 4 * 10G

- VSC7549 Sparx5-90
  up to 90 Gbps of bandwidth with the following primary port configurations:
  - 9 * 10G
  - 16 * 2.5G + 4 * 10G
  - 48 * 1G + 4 * 10G

- VSC7552 Sparx5-128
  up to 128 Gbps of bandwidth with the following primary port configurations:
  - 12 * 10G
  - 16 * 2.5G + 8 * 10G
  - 48 * 1G + 8 * 10G

- VSC7556 Sparx5-160
  up to 160 Gbps of bandwidth with the following primary port configurations:
  - 16 * 10G
  - 10 * 10G + 2 * 25G
  - 16 * 2.5G + 10 * 10G
  - 48 * 1G + 10 * 10G

- VSC7558 Sparx5-200
  up to 200 Gbps of bandwidth with the following primary port configurations:
  - 20 * 10G
  - 8 * 25G

In addition, the device supports one 10/100/1000/2500/5000 Mbps SGMII/SerDes
node processor interface (NPI) Ethernet port.

The Sparx5 support is developed on the PCB134 and PCB135 evaluation boards.

- PCB134 main networking features:
  - 12x SFP+ front 10G module slots (connected to Sparx5 through SFI).
  - 8x SFP28 front 25G module slots (connected to Sparx5 through SFI high 
speed).
  - Optional, one additional 10/100/1000BASE-T (RJ45) Ethernet port
(on-board VSC8211 PHY connected to Sparx5 through SGMII).

- PCB135 main networking features:
  - 48x1G (10/100/1000M) RJ45 front ports using 12xVSC8514 QuadPHY’s each
connected to VSC7558 through QSGMII.
  - 4x10G (1G/2.5G/5G/10G) RJ45 front ports using the AQR407 10G QuadPHY each
port connects to VSC7558 through SFI.
  - 4x SFP28 25G module slots on back connected to VSC7558 through SFI high
speed.
  - Optional, one additional 1G (10/100/1000M) RJ45 port using an on-board
VSC8211 PHY, which can be connected to VSC7558 NPI port through SGMII using
a loopback add-on PCB)

This series provides support for:
  - SFPs and DAC cables via PHYLINK with a number of 5G, 10G and 25G devices
and media types.
  - Port module configuration for 10M to 25G speeds with SGMII, QSGMII,
1000BASEX, 2500BASEX and 10GBASER as appropriate for these modes.
  - SerDes configuration via the Sparx5 SerDes driver (see below).
  - Host mode providing register based injection and extraction.
  - Switch mode providing MAC/VLAN table learning and Layer2 switching offloaded
to the Sparx5 switch.
  - STP state, VLAN support, host/bridge port mode, Forwarding DB, and
configuration and statistics via ethtool.

More support will be added at a later stage.

The Sparx5 Switch chip register model can be browsed here:
Link: https://microchip-ung.github.io/sparx-5_reginfo/reginfo_sparx-5.html

The series depends on the following series currently on their way
into the kernel:

- Sparx5 SerDes Driver
  Link: 
https://lore.kernel.org/r/20201123114234.2292766-1-steen.hegel...@microchip.com/

- Serial GPIO Controller
  Link: 
https://lore.kernel.org/r/20201113145151.68900-1-lars.povl...@microchip.com/

Steen Hegelund (3):
  dt-bindings: net: sparx5: Add sparx5-switch bindings
  net: sparx5: Add Sparx5 switchdev driver
  arm64: dts: sparx5: Add the Sparx5 switch node

 .../bindings/net/microchip,sparx5-switch.yaml |  633 +++
 arch/arm64/boot/dts/microchip/sparx5.dtsi |  364 ++
 .../dts/microchip/sparx5_pcb134_board.dtsi|  424 +-
 .../dts/microchip/sparx5_pcb135_board.dtsi|  602 ++-
 drivers/net/ethernet/microchip/Kconfig|2 +
 drivers/net/ethernet/microchip/Makefile   |2 +
 drivers/net/ethernet/microchip/sparx5/Kconfig |8 +
 .../net/ethernet/microchip/sparx5/Makefile|   11 +
 .../microchip/sparx5/sparx5_calendar.c|  593 +++
 .../ethernet/microchip/sparx5/sparx5_common.h |  162 +
 .../microchip/sparx5/sparx5_ethtool.c 

[RFC PATCH 1/3] dt-bindings: net: sparx5: Add sparx5-switch bindings

[Steen Hegelund]

Document the Sparx5 switch device driver bindings

Signed-off-by: Steen Hegelund 
---
 .../bindings/net/microchip,sparx5-switch.yaml | 633 ++
 1 file changed, 633 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml

diff --git a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml 
b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
new file mode 100644
index ..34af605af533
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
@@ -0,0 +1,633 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/microchip,sparx5-switch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip Sparx5 Ethernet switch controller
+
+maintainers:
+  - Lars Povlsen 
+  - Steen Hegelund 
+
+description: |
+  The SparX-5 Enterprise Ethernet switch family provides a rich set of
+  Enterprise switching features such as advanced TCAM-based VLAN and
+  QoS processing enabling delivery of differentiated services, and
+  security through TCAM-based frame processing using versatile content
+  aware processor (VCAP).
+
+  IPv4/IPv6 Layer 3 (L3) unicast and multicast routing is supported
+  with up to 18K IPv4/9K IPv6 unicast LPM entries and up to 9K IPv4/3K
+  IPv6 (S,G) multicast groups.
+
+  L3 security features include source guard and reverse path
+  forwarding (uRPF) tasks. Additional L3 features include VRF-Lite and
+  IP tunnels (IP over GRE/IP).
+
+  The SparX-5 switch family targets managed Layer 2 and Layer 3
+  equipment in SMB, SME, and Enterprise where high port count
+  1G/2.5G/5G/10G switching with 10G/25G aggregation links is required.
+
+properties:
+  $nodename:
+pattern: "^switch@[0-9a-f]+$"
+
+  compatible:
+const: microchip,sparx5-switch
+
+  reg:
+minItems: 153
+
+  reg-names:
+minItems: 153
+items:
+  - const: dev2g5_0
+  - const: dev5g_0
+  - const: pcs5g_br_0
+  - const: dev2g5_1
+  - const: dev5g_1
+  - const: pcs5g_br_1
+  - const: dev2g5_2
+  - const: dev5g_2
+  - const: pcs5g_br_2
+  - const: dev2g5_6
+  - const: dev5g_6
+  - const: pcs5g_br_6
+  - const: dev2g5_7
+  - const: dev5g_7
+  - const: pcs5g_br_7
+  - const: dev2g5_8
+  - const: dev5g_8
+  - const: pcs5g_br_8
+  - const: dev2g5_9
+  - const: dev5g_9
+  - const: pcs5g_br_9
+  - const: dev2g5_10
+  - const: dev5g_10
+  - const: pcs5g_br_10
+  - const: dev2g5_11
+  - const: dev5g_11
+  - const: pcs5g_br_11
+  - const: dev2g5_12
+  - const: dev10g_0
+  - const: pcs10g_br_0
+  - const: dev2g5_14
+  - const: dev10g_2
+  - const: pcs10g_br_2
+  - const: dev2g5_15
+  - const: dev10g_3
+  - const: pcs10g_br_3
+  - const: dev2g5_16
+  - const: dev2g5_17
+  - const: dev2g5_18
+  - const: dev2g5_19
+  - const: dev2g5_20
+  - const: dev2g5_21
+  - const: dev2g5_22
+  - const: dev2g5_23
+  - const: dev2g5_32
+  - const: dev2g5_33
+  - const: dev2g5_34
+  - const: dev2g5_35
+  - const: dev2g5_36
+  - const: dev2g5_37
+  - const: dev2g5_38
+  - const: dev2g5_39
+  - const: dev2g5_40
+  - const: dev2g5_41
+  - const: dev2g5_42
+  - const: dev2g5_43
+  - const: dev2g5_44
+  - const: dev2g5_45
+  - const: dev2g5_46
+  - const: dev2g5_47
+  - const: dev2g5_57
+  - const: dev25g_1
+  - const: pcs25g_br_1
+  - const: dev2g5_59
+  - const: dev25g_3
+  - const: pcs25g_br_3
+  - const: dev2g5_60
+  - const: dev25g_4
+  - const: pcs25g_br_4
+  - const: dev2g5_64
+  - const: dev5g_64
+  - const: pcs5g_br_64
+  - const: port_conf
+  - const: dev2g5_3
+  - const: dev5g_3
+  - const: pcs5g_br_3
+  - const: dev2g5_4
+  - const: dev5g_4
+  - const: pcs5g_br_4
+  - const: dev2g5_5
+  - const: dev5g_5
+  - const: pcs5g_br_5
+  - const: dev2g5_13
+  - const: dev10g_1
+  - const: pcs10g_br_1
+  - const: dev2g5_24
+  - const: dev2g5_25
+  - const: dev2g5_26
+  - const: dev2g5_27
+  - const: dev2g5_28
+  - const: dev2g5_29
+  - const: dev2g5_30
+  - const: dev2g5_31
+  - const: dev2g5_48
+  - const: dev10g_4
+  - const: pcs10g_br_4
+  - const: dev2g5_49
+  - const: dev10g_5
+  - const: pcs10g_br_5
+  - const: dev2g5_50
+  - const: dev10g_6
+  - const: pcs10g_br_6
+  - const: dev2g5_51
+  - const: dev10g_7
+  - const: pcs10g_br_7
+  - const: dev2g5_52
+  - const: dev10g_8
+  - const: pcs10g_br_8
+  - const: dev2g5_53
+  - const: dev10g_9
+  - const: pcs10g_br_9
+  - const: dev2g5_54
+  - const: dev10g_10
+  - const: pcs10g_br_10
+  - const: dev2g5_55
+  - const: dev10g_11
+  - const: 

[RFC PATCH 3/3] arm64: dts: sparx5: Add the Sparx5 switch node

[Steen Hegelund]

This provides switchdev support for the Microship Sparx5 PCB134 and PCB135
reference boards.

This commit depends on the following series currently on their way
into the kernel:

- Sparx5 SerDes Driver
  Link: 
https://lore.kernel.org/r/20201123114234.2292766-1-steen.hegel...@microchip.com/

- Serial GPIO Controller
  Link: 
https://lore.kernel.org/r/20201113145151.68900-1-lars.povl...@microchip.com/

Signed-off-by: Steen Hegelund 
---
 arch/arm64/boot/dts/microchip/sparx5.dtsi | 364 +++
 .../dts/microchip/sparx5_pcb134_board.dtsi| 424 ++--
 .../dts/microchip/sparx5_pcb135_board.dtsi| 602 +-
 3 files changed, 1330 insertions(+), 60 deletions(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi 
b/arch/arm64/boot/dts/microchip/sparx5.dtsi
index 08d0c2fe208e..8119ea1029e0 100644
--- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
@@ -267,6 +267,21 @@ emmc_pins: emmc-pins {
"GPIO_46", "GPIO_47";
function = "emmc";
};
+
+   miim1_pins: miim1-pins {
+   pins = "GPIO_56", "GPIO_57";
+   function = "miim";
+   };
+
+   miim2_pins: miim2-pins {
+   pins = "GPIO_58", "GPIO_59";
+   function = "miim";
+   };
+
+   miim3_pins: miim3-pins {
+   pins = "GPIO_52", "GPIO_53";
+   function = "miim";
+   };
};
 
sgpio0: gpio@61101036c {
@@ -379,6 +394,44 @@ tmon0: tmon@610508110 {
clocks = <_clk>;
};
 
+   mdio0: mdio@6110102b0 {
+   compatible = "mscc,ocelot-miim";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x6 0x110102b0 0x24>;
+   };
+
+   mdio1: mdio@6110102d4 {
+   compatible = "mscc,ocelot-miim";
+   status = "disabled";
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x6 0x110102d4 0x24>;
+   };
+
+   mdio2: mdio@6110102f8 {
+   compatible = "mscc,ocelot-miim";
+   status = "disabled";
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x6 0x110102d4 0x24>;
+   };
+
+   mdio3: mdio@61101031c {
+   compatible = "mscc,ocelot-miim";
+   status = "disabled";
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x6 0x1101031c 0x24>;
+   };
+
serdes: serdes@10808000 {
compatible = "microchip,sparx5-serdes";
#phy-cells = <1>;
@@ -574,5 +627,316 @@ serdes: serdes@10808000 {
"sd_lane_25g_32";
};
 
+   switch: switch@6 {
+   compatible = "microchip,sparx5-switch";
+   reg =   <0x6 0x10004000 0x4000>, /* dev2g5_0 */
+   <0x6 0x10008000 0x4000>, /* dev5g_0 */
+   <0x6 0x1000c000 0x4000>, /* pcs5g_br_0 */
+   <0x6 0x1001 0x4000>, /* dev2g5_1 */
+   <0x6 0x10014000 0x4000>, /* dev5g_1 */
+   <0x6 0x10018000 0x4000>, /* pcs5g_br_1 */
+   <0x6 0x1001c000 0x4000>, /* dev2g5_2 */
+   <0x6 0x1002 0x4000>, /* dev5g_2 */
+   <0x6 0x10024000 0x4000>, /* pcs5g_br_2 */
+   <0x6 0x10028000 0x4000>, /* dev2g5_6 */
+   <0x6 0x1002c000 0x4000>, /* dev5g_6 */
+   <0x6 0x1003 0x4000>, /* pcs5g_br_6 */
+   <0x6 0x10034000 0x4000>, /* dev2g5_7 */
+   <0x6 0x10038000 0x4000>, /* dev5g_7 */
+   <0x6 0x1003c000 0x4000>, /* pcs5g_br_7 */
+   <0x6 0x1004 0x4000>, /* dev2g5_8 */
+   <0x6 0x10044000 0x4000>, /* dev5g_8 */
+   

Re: [PATCH 1/1] perf diff: fix error return value in __cmd_diff()

[Namhyung Kim]

Hello,

On Tue, Nov 24, 2020 at 7:37 PM Zhen Lei  wrote:
>
> An appropriate return value should be set on the failed path.
>
> Reported-by: Hulk Robot 
> Signed-off-by: Zhen Lei 

Acked-by: Namhyung Kim 

Thanks,
Namhyung

> ---
>  tools/perf/builtin-diff.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
> index 584e2e1a3793..cefc71506409 100644
> --- a/tools/perf/builtin-diff.c
> +++ b/tools/perf/builtin-diff.c
> @@ -1222,8 +1222,10 @@ static int __cmd_diff(void)
> if (compute == COMPUTE_STREAM) {
> d->evlist_streams = evlist__create_streams(
> d->session->evlist, 5);
> -   if (!d->evlist_streams)
> +   if (!d->evlist_streams) {
> +   ret = -ENOMEM;
> goto out_delete;
> +   }
> }
> }
>
> --
> 2.26.0.106.g9fadedd
>
>

[PATCH net-next v3] net/nfc/nci: Support NCI 2.x initial sequence

[bongsu . jeon2]

From: Bongsu Jeon 

implement the NCI 2.x initial sequence to support NCI 2.x NFCC.
Since NCI 2.0, CORE_RESET and CORE_INIT sequence have been changed.
If NFCEE supports NCI 2.x, then NCI 2.x initial sequence will work.

In NCI 1.0, Initial sequence and payloads are as below:
(DH) (NFCC)
 |  -- CORE_RESET_CMD --> |
 |  <-- CORE_RESET_RSP -- |
 |  -- CORE_INIT_CMD -->  |
 |  <-- CORE_INIT_RSP --  |
 CORE_RESET_RSP payloads are Status, NCI version, Configuration Status.
 CORE_INIT_CMD payloads are empty.
 CORE_INIT_RSP payloads are Status, NFCC Features,
Number of Supported RF Interfaces, Supported RF Interface,
Max Logical Connections, Max Routing table Size,
Max Control Packet Payload Size, Max Size for Large Parameters,
Manufacturer ID, Manufacturer Specific Information.

In NCI 2.0, Initial Sequence and Parameters are as below:
(DH) (NFCC)
 |  -- CORE_RESET_CMD --> |
 |  <-- CORE_RESET_RSP -- |
 |  <-- CORE_RESET_NTF -- |
 |  -- CORE_INIT_CMD -->  |
 |  <-- CORE_INIT_RSP --  |
 CORE_RESET_RSP payloads are Status.
 CORE_RESET_NTF payloads are Reset Trigger,
Configuration Status, NCI Version, Manufacturer ID,
Manufacturer Specific Information Length,
Manufacturer Specific Information.
 CORE_INIT_CMD payloads are Feature1, Feature2.
 CORE_INIT_RSP payloads are Status, NFCC Features,
Max Logical Connections, Max Routing Table Size,
Max Control Packet Payload Size,
Max Data Packet Payload Size of the Static HCI Connection,
Number of Credits of the Static HCI Connection,
Max NFC-V RF Frame Size, Number of Supported RF Interfaces,
Supported RF Interfaces.

Signed-off-by: Bongsu Jeon 
---
 Changes in v3:
  - remove the unused struct nci_core_reset_rsp_nci_ver2.
  - remove the __packed because of no need.
  - remove the unnecessary brackets.
  - change the asignment code for ndev->num_supported_rf_interfaces.

 Changes in v2:
  - fix the warning of type casting.
  - changed the __u8 type to unsigned char.

 include/net/nfc/nci.h | 34 +
 net/nfc/nci/core.c| 24 +--
 net/nfc/nci/ntf.c | 21 +
 net/nfc/nci/rsp.c | 81 ++-
 4 files changed, 143 insertions(+), 17 deletions(-)

diff --git a/include/net/nfc/nci.h b/include/net/nfc/nci.h
index 0550e0380..825c6d2 100644
--- a/include/net/nfc/nci.h
+++ b/include/net/nfc/nci.h
@@ -25,6 +25,8 @@
 #define NCI_MAX_PARAM_LEN  251
 #define NCI_MAX_PAYLOAD_SIZE   255
 #define NCI_MAX_PACKET_SIZE258
+#define NCI_MAX_LARGE_PARAMS_NCI_v215
+#define NCI_VER_2_MASK 0x20
 
 /* NCI Status Codes */
 #define NCI_STATUS_OK  0x00
@@ -131,6 +133,9 @@
 #define NCI_LF_CON_BITR_F_212  0x02
 #define NCI_LF_CON_BITR_F_424  0x04
 
+/* NCI 2.x Feature Enable Bit */
+#define NCI_FEATURE_DISABLE0x00
+
 /* NCI Reset types */
 #define NCI_RESET_TYPE_KEEP_CONFIG 0x00
 #define NCI_RESET_TYPE_RESET_CONFIG0x01
@@ -220,6 +225,11 @@ struct nci_core_reset_cmd {
 } __packed;
 
 #define NCI_OP_CORE_INIT_CMD   nci_opcode_pack(NCI_GID_CORE, 0x01)
+/* To support NCI 2.x */
+struct nci_core_init_v2_cmd {
+   unsigned char   feature1;
+   unsigned char   feature2;
+};
 
 #define NCI_OP_CORE_SET_CONFIG_CMD nci_opcode_pack(NCI_GID_CORE, 0x02)
 struct set_config_param {
@@ -334,6 +344,20 @@ struct nci_core_init_rsp_2 {
__le32  manufact_specific_info;
 } __packed;
 
+/* To support NCI ver 2.x */
+struct nci_core_init_rsp_nci_ver2 {
+   unsigned char   status;
+   __le32  nfcc_features;
+   unsigned char   max_logical_connections;
+   __le16  max_routing_table_size;
+   unsigned char   max_ctrl_pkt_payload_len;
+   unsigned char   max_data_pkt_hci_payload_len;
+   unsigned char   number_of_hci_credit;
+   __le16  max_nfc_v_frame_size;
+   unsigned char   num_supported_rf_interfaces;
+   unsigned char   supported_rf_interfaces[];
+} __packed;
+
 #define NCI_OP_CORE_SET_CONFIG_RSP nci_opcode_pack(NCI_GID_CORE, 0x02)
 struct nci_core_set_config_rsp {
__u8status;
@@ -372,6 +396,16 @@ struct nci_nfcee_discover_rsp {
 /* --- */
 /*  NCI Notifications  */
 /* --- */
+#define NCI_OP_CORE_RESET_NTF  nci_opcode_pack(NCI_GID_CORE, 0x00)
+struct nci_core_reset_ntf {
+   unsigned char   reset_trigger;
+   unsigned char   config_status;
+   unsigned char   nci_ver;
+   unsigned char   manufact_id;
+   unsigned char   manufacturer_specific_len;
+   __le32  manufact_specific_info;
+} __packed;
+
 #define 

Re: [PATCH] media: ov8856: Remove 3280x2464 mode

[Robert Foss]

Thanks for digging into this everyone!

Assuming Tomasz doesn't find any stretching, I think we can conclude
that this mode works, and should be kept. Thanks Dongchun for parsing
the datasheet and finding the Bayer mode issue for the two other
recently added resolutions.

On Fri, 27 Nov 2020 at 11:26, Tomasz Figa  wrote:
>
> On Thu, Nov 26, 2020 at 7:00 PM Robert Foss  wrote:
> >
> > On Wed, 25 Nov 2020 at 08:32, Tomasz Figa  wrote:
> > >
> > > Hi Bingbu,
> > >
> > > On Wed, Nov 25, 2020 at 1:15 PM Bingbu Cao  
> > > wrote:
> > > >
> > > >
> > > >
> > > > On 11/24/20 6:20 PM, Robert Foss wrote:
> > > > > On Tue, 24 Nov 2020 at 10:42, Bingbu Cao  
> > > > > wrote:
> > > > >>
> > > > >> Hi, Robert
> > > > >>
> > > > >> I remember that the full size of ov8856 image sensor is 3296x2480 
> > > > >> and we can get the 3280x2464
> > > > >> frames based on current settings.
> > > > >>
> > > > >> Do you have any issues with this mode?
> > > > >
> > > > > As far as I can tell using the 3280x2464 mode actually yields an
> > > > > output resolution that is 3264x2448.
> > > > >
> > > > > What does your hardware setup look like? And which revision of the
> > > > > sensor are you using?
> > > > >
> > > >
> > > > Robert, the sensor revision I am using is v1.1. I just checked the 
> > > > actual output pixels on our
> > > > hardware, the output resolution with 2464 mode is 3280x2464, no black 
> > > > pixels.
> > > >
> > > > As Tomasz said, some ISP has the requirement of extra pixel padding, 
> > > > From the ov8856 datasheet,
> > > > the central 3264x2448 pixels are *suggested* to be output from the 
> > > > pixel array and the boundary
> > > > pixels can be used for additional processing. In my understanding, the 
> > > > 32 dummy lines are not
> > > > black lines.
> > >
> > > The datasheet says that only 3264x2448 are active pixels. What pixel
> > > values are you seeing outside of that central area? In the datasheet,
> > > those look like "optically black" pixels, which are not 100% black,
> > > but rather as if the sensor cells didn't receive any light - noise can
> > > be still there.
> > >
> >
> > I've been developing support for some Qcom ISP functionality, and
> > during the course of this I ran into the issue I was describing, where
> > the 3280x2464 mode actually outputs 3264x2448.
> >
> > I can think of two reasons for this, either ISP driver bugs on my end
> > or the fact that the sensor is being run outside of the specification
> > and which could be resulting in differences between how the ov8856
> > sensors behave.
>
> I just confirmed and we're indeed using this mode in a number of our
> projects based on the Intel ISP and it seems to be producing a proper
> image with all pixels of the 3280x2464 matrix having proper values.
> I'm now double checking whether this isn't some processing done by the
> ISP, but I suspect the quality would be bad if it stretched the
> central 3264x2448 part into the 3280x2464 frame.
>
> Best regards,
> Tomasz

Re: [PATCH 3/3] soc: qcom: llcc-qcom: Add support for SM8250 SoC

[Sai Prakash Ranjan]

Hi Mani,

On 2020-11-27 17:41, Manivannan Sadhasivam wrote:
SM8250 SoC uses LLCC IP version 2. In this version, the WRSC_EN 
register

needs to be written to enable the Write Sub Cache for each SCID. Hence,
use a dedicated "write_scid_en" member with predefined values and write
them for SoCs enabling the "llcc_v2" flag.

Signed-off-by: Manivannan Sadhasivam 
---
 drivers/soc/qcom/llcc-qcom.c   | 40 ++
 include/linux/soc/qcom/llcc-qcom.h |  1 +
 2 files changed, 41 insertions(+)

diff --git a/drivers/soc/qcom/llcc-qcom.c 
b/drivers/soc/qcom/llcc-qcom.c

index 16b421608e9c..3ec4cdffa852 100644
--- a/drivers/soc/qcom/llcc-qcom.c
+++ b/drivers/soc/qcom/llcc-qcom.c
@@ -47,6 +47,7 @@

 #define LLCC_TRP_SCID_DIS_CAP_ALLOC   0x21f00
 #define LLCC_TRP_PCB_ACT  0x21f04
+#define LLCC_TRP_WRSC_EN  0x21f20

 #define BANK_OFFSET_STRIDE   0x8

@@ -73,6 +74,7 @@
  *   then the ways assigned to this client are not flushed 
on power

  *   collapse.
  * @activate_on_init: Activate the slice immediately after it is 
programmed

+ * @write_scid_en: Bit enables write cache support for a given scid.
  */
 struct llcc_slice_config {
u32 usecase_id;
@@ -87,12 +89,14 @@ struct llcc_slice_config {
bool dis_cap_alloc;
bool retain_on_pc;
bool activate_on_init;
+   bool write_scid_en;
 };

 struct qcom_llcc_config {
const struct llcc_slice_config *sct_data;
int size;
bool need_llcc_cfg;
+   bool llcc_v2;
 };


We can extract the version from HW info register and so
would not have to maintain a flag for every new version
of LLCC. I had a patch to do that which I have sent to you
now, perhaps you can check if that works for you and take
it with this series?

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v2] i2c: qcom: Fix IRQ error misassignement

[Robert Foss]

During cci_isr() errors read from register fields belonging to
i2c master1 are currently assigned to the status field belonging to
i2c master0. This patch corrects this error, and always assigns
master1 errors to the status field of master1.

Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver")

Reported-by: Loic Poulain 
Suggested-by: Loic Poulain 
Signed-off-by: Robert Foss 
---
 drivers/i2c/busses/i2c-qcom-cci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qcom-cci.c 
b/drivers/i2c/busses/i2c-qcom-cci.c
index f13735beca58..1c259b5188de 100644
--- a/drivers/i2c/busses/i2c-qcom-cci.c
+++ b/drivers/i2c/busses/i2c-qcom-cci.c
@@ -194,9 +194,9 @@ static irqreturn_t cci_isr(int irq, void *dev)
if (unlikely(val & CCI_IRQ_STATUS_0_I2C_M1_ERROR)) {
if (val & CCI_IRQ_STATUS_0_I2C_M1_Q0_NACK_ERR ||
val & CCI_IRQ_STATUS_0_I2C_M1_Q1_NACK_ERR)
-   cci->master[0].status = -ENXIO;
+   cci->master[1].status = -ENXIO;
else
-   cci->master[0].status = -EIO;
+   cci->master[1].status = -EIO;
 
writel(CCI_HALT_REQ_I2C_M1_Q0Q1, cci->base + CCI_HALT_REQ);
ret = IRQ_HANDLED;
-- 
2.27.0