Re: [PATCH 07/12] dma-mapping: move CONFIG_DMA_CMA to kernel/dma/Kconfig
On Mon, Feb 11, 2019 at 02:35:49PM +0100, Christoph Hellwig wrote: > This is where all the related code already lives. > > Signed-off-by: Christoph Hellwig > --- > drivers/base/Kconfig | 77 > kernel/dma/Kconfig | 77 > 2 files changed, 77 insertions(+), 77 deletions(-) Much nicer, thanks! Reviewed-by: Greg Kroah-Hartman
Re: RFC: drop ISA support in the synlink tty driver?
On Mon, Feb 11, 2019 at 02:25:33PM +0100, Christoph Hellwig wrote: > Hi Greg and Jiri, > > I've been working hard to get rid of the remaining callers the pass a > NULL struct device to the DMA mapping functions and am almost done. > > The only non-trivial driver is the synclink driver, which has legacy > early 90s style ISA support that doesn't use the device model at all. > > In theory we could convert it to an isa_driver, but without testing > that seems rather dangerous. So for now I would suggest that we > remove the ISA support in this driver - if anyone cares enough we > can resurrect it from the git history and convert it to use the driver > model. No objection from me at all, I'll go queue this up now, thanks. greg k-h
Re: [PATCH 09/12] dma-mapping: remove the DMA_MEMORY_EXCLUSIVE flag
On Mon, Feb 11, 2019 at 02:35:51PM +0100, Christoph Hellwig wrote: > All users of dma_declare_coherent want their allocations to be > exclusive, so default to exclusive allocations. > > Signed-off-by: Christoph Hellwig > --- > Documentation/DMA-API.txt | 9 +-- > arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 12 +++-- > arch/arm/mach-imx/mach-mx31moboard.c | 3 +-- > arch/sh/boards/mach-ap325rxa/setup.c | 5 ++-- > arch/sh/boards/mach-ecovec24/setup.c | 6 ++--- > arch/sh/boards/mach-kfr2r09/setup.c | 5 ++-- > arch/sh/boards/mach-migor/setup.c | 5 ++-- > arch/sh/boards/mach-se/7724/setup.c | 6 ++--- > arch/sh/drivers/pci/fixups-dreamcast.c| 3 +-- > .../soc_camera/sh_mobile_ceu_camera.c | 3 +-- > drivers/usb/host/ohci-sm501.c | 3 +-- > drivers/usb/host/ohci-tmio.c | 2 +- > include/linux/dma-mapping.h | 7 ++ > kernel/dma/coherent.c | 25 ++- > 14 files changed, 29 insertions(+), 65 deletions(-) Reviewed-by: Greg Kroah-Hartman
Re: [PATCH RFC v2] fcoe: make use of fip_mode enum complete
On Mon, Feb 11, 2019 at 6:53 PM Nathan Chancellor
wrote:
>
> On Mon, Feb 11, 2019 at 06:07:51PM +0100, Sedat Dilek wrote:
> > From: Sedat Dilek
> >
> > commit 1917d42d14b7 ("fcoe: use enum for fip_mode") introduces a separate
> > enum for the fip_mode that shall be used during initialisation handling
> > until it is passed to fcoe_ctrl_link_up to set the initial fip_state.
> > That change was incomplete and gcc quietly converted in various places
> > between the fip_mode and the fip_state enum values with implicit enum
> > conversions, which fortunately cannot cause any issues in the actual
> > code's execution.
> >
> > clang however warns about these implicit enum conversions in the scsi
> > drivers. This commit consolidates the use of the two enums, guided by
> > clang's enum-conversion warnings.
> >
> > This commit now completes the use of the fip_mode:
> > It expects and uses fip_mode in {bnx2fc,fcoe}_interface_create and
> > fcoe_ctlr_init, and it explicitly converts from fip_mode to fip_state
> > only at the single point in fcoe_ctlr_link_up.
> >
> > To eliminate that adding or removing values from fip_mode or fip_state enum
> > break the right mapping of values, all fip_mode values are assigned to
> > their fip_state counterparts.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/151
> > Fixes: 1917d42d14b7 ("fcoe: use enum for fip_mode")
> > Reported-by: Dmitry Golovin "Twisted Pair in my Hair"
> > CC: Lukas Bulwahn
> > CC: Nick Desaulniers
> > CC: Nathan Chancellor
> > CC: Hannes Reinecke
> > Suggested-by: Johannes Thumshirn
> > ---
> >
> > [ v2:
> >- Based on the original patch by Lukas Bulwahn
> >- Suggestion by Johannes T. [1] required some changes:
> > + s/case FIP_ST_VMMP_START/case FIP_ST_V*N*MP_START
> > + s/return FIP_ST_AUTO/return FIP_MODE_AUTO
> >- Add Link to ClangBuiltLinux issue #151
> >- S-o-b line later when there is an OK from the FCoE maintainers
> >
> > NOTE: Compile-tested against Linux-v5.0-rc6 with LLVM/Clang from Git with
> > experimental asm-goto support via executing:
> > $ make V=1 CC=clang-9 HOSTCC=clang-9 drivers/scsi/fcoe/
> >
> > [1] https://marc.info/?l=linux-scsi=154745527612152=2
> >
> > -dileks ]
> >
> > drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 2 +-
> > drivers/scsi/fcoe/fcoe.c | 2 +-
> > drivers/scsi/fcoe/fcoe_ctlr.c | 4 ++--
> > drivers/scsi/fcoe/fcoe_transport.c | 2 +-
> > drivers/scsi/qedf/qedf_main.c | 2 +-
> > include/scsi/libfcoe.h | 22 --
> > 6 files changed, 26 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> > b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> > index 2e4e7159ebf9..a75e74ad1698 100644
> > --- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> > +++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
> > @@ -1438,7 +1438,7 @@ static struct bnx2fc_hba *bnx2fc_hba_create(struct
> > cnic_dev *cnic)
> > static struct bnx2fc_interface *
> > bnx2fc_interface_create(struct bnx2fc_hba *hba,
> > struct net_device *netdev,
> > - enum fip_state fip_mode)
> > + enum fip_mode fip_mode)
> > {
> > struct fcoe_ctlr_device *ctlr_dev;
> > struct bnx2fc_interface *interface;
> > diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
> > index cd19be3f3405..8ba8862d3292 100644
> > --- a/drivers/scsi/fcoe/fcoe.c
> > +++ b/drivers/scsi/fcoe/fcoe.c
> > @@ -389,7 +389,7 @@ static int fcoe_interface_setup(struct fcoe_interface
> > *fcoe,
> > * Returns: pointer to a struct fcoe_interface or NULL on error
> > */
> > static struct fcoe_interface *fcoe_interface_create(struct net_device
> > *netdev,
> > - enum fip_state fip_mode)
> > + enum fip_mode fip_mode)
> > {
> > struct fcoe_ctlr_device *ctlr_dev;
> > struct fcoe_ctlr *ctlr;
> > diff --git a/drivers/scsi/fcoe/fcoe_ctlr.c b/drivers/scsi/fcoe/fcoe_ctlr.c
> > index 54da3166da8d..a52d3ad94876 100644
> > --- a/drivers/scsi/fcoe/fcoe_ctlr.c
> > +++ b/drivers/scsi/fcoe/fcoe_ctlr.c
> > @@ -147,7 +147,7 @@ static void fcoe_ctlr_map_dest(struct fcoe_ctlr *fip)
> > * fcoe_ctlr_init() - Initialize the FCoE Controller instance
> > * @fip: The FCoE controller to initialize
> > */
> > -void fcoe_ctlr_init(struct fcoe_ctlr *fip, enum fip_state mode)
> > +void fcoe_ctlr_init(struct fcoe_ctlr *fip, enum fip_mode mode)
> > {
> > fcoe_ctlr_set_state(fip, FIP_ST_LINK_WAIT);
> > fip->mode = mode;
> > @@ -454,7 +454,7 @@ void fcoe_ctlr_link_up(struct fcoe_ctlr *fip)
> > mutex_unlock(>ctlr_mutex);
> > fc_linkup(fip->lp);
> > } else if (fip->state == FIP_ST_LINK_WAIT) {
> > - fcoe_ctlr_set_state(fip, fip->mode);
> > + fcoe_ctlr_set_state(fip, (enum fip_state) fip->mode);
> > switch (fip->mode) {
> > default:
> >
Re: [PATCH] mfd: twl6040: Fix device init errors for ACCCTL register
On 12/02/2019 0.57, Tony Lindgren wrote:
> I noticed that we can get a -EREMOTEIO errors on at least omap4 duovero:
>
> twl6040 0-004b: Failed to write 2d = 19: -121
>
> And then any following register access will produce errors.
>
> There 2d offset above is register ACCCTL that gets written on twl6040
> powerup. With error checking added to the related regcache_sync() call,
> the -EREMOTEIO error is reproducable on twl6040 powerup at least
> duovero.
>
> To fix the error, we need to wait until twl6040 is accessible after the
> powerup. Based on tests on omap4 duovero, we need to wait over 8ms after
> powerup before register write will complete without failures. Let's also
> make sure we warn about possible errors too.
>
> Note that we have twl6040_patch[] reg_sequence with the ACCCTL register
> configuration and regcache_sync() will write the new value to ACCCTL.
Acked-by: Peter Ujfalusi
>
> Cc: Florian Vaussard
> Cc: Peter Ujfalusi
> Signed-off-by: Tony Lindgren
> ---
> drivers/mfd/twl6040.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
> --- a/drivers/mfd/twl6040.c
> +++ b/drivers/mfd/twl6040.c
> @@ -322,8 +322,19 @@ int twl6040_power(struct twl6040 *twl6040, int on)
> }
> }
>
> + /*
> + * Register access can produce errors after power-up unless we
> + * wait at least 8ms based on measurements on duovero.
> + */
> + usleep_range(1, 12000);
> +
> /* Sync with the HW */
> - regcache_sync(twl6040->regmap);
> + ret = regcache_sync(twl6040->regmap);
> + if (ret) {
> + dev_err(twl6040->dev, "%s register write failed: %i\n",
> + __func__, ret);
> + goto out;
> + }
>
> /* Default PLL configuration after power up */
> twl6040->pll = TWL6040_SYSCLK_SEL_LPPLL;
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 06/12] dma-mapping: improve selection of dma_declare_coherent availability
On Mon, Feb 11, 2019 at 02:35:48PM +0100, Christoph Hellwig wrote: > This API is primarily used through DT entries, but two architectures > and two drivers call it directly. So instead of selecting the config > symbol for random architectures pull it in implicitly for the actual > users. Also rename the Kconfig option to describe the feature better. > > Signed-off-by: Christoph Hellwig Reviewed-by: Greg Kroah-Hartman
Re: [PATCH 02/12] device.h: dma_mem is only needed for HAVE_GENERIC_DMA_COHERENT
On Mon, Feb 11, 2019 at 02:35:44PM +0100, Christoph Hellwig wrote: > No need to carry an unused field around. > > Signed-off-by: Christoph Hellwig > --- > include/linux/device.h | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Greg Kroah-Hartman
Re: [PATCHv13 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
On Tue, Feb 12, 2019 at 10:36:23AM +0800, Hean-Loong, Ong via dri-devel wrote:
> From: Ong, Hean Loong
>
> Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II.
> The driver only supports the Intel Arria10 devkit and its variants.
> This driver can be either loaded staticlly or in modules.
> The OF device tree binding is located at:
> Documentation/devicetree/bindings/display/altr,vip-fb2.txt
>
> Signed-off-by: Ong, Hean Loong
It looks like your cover letter and patch 2 didn't make it to the list
somehow. Please check those aren't stuck on your side (list admins didn't
see them yet).
> ---
> drivers/gpu/drm/Kconfig |2 +
> drivers/gpu/drm/Makefile |1 +
> drivers/gpu/drm/ivip/Kconfig | 14 ++
> drivers/gpu/drm/ivip/Makefile |6 +
> drivers/gpu/drm/ivip/intel_vip_conn.c | 91 +
> drivers/gpu/drm/ivip/intel_vip_drv.c | 332
> +
> drivers/gpu/drm/ivip/intel_vip_drv.h | 73 +++
> 7 files changed, 519 insertions(+), 0 deletions(-)
> create mode 100644 drivers/gpu/drm/ivip/Kconfig
> create mode 100644 drivers/gpu/drm/ivip/Makefile
> create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
> create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.c
> create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 4385f00..0251a9f 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -235,6 +235,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
>
> source "drivers/gpu/drm/i915/Kconfig"
>
> +source "drivers/gpu/drm/ivip/Kconfig"
> +
> config DRM_VGEM
> tristate "Virtual GEM provider"
> depends on DRM
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index ce8d1d3..85a5694 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
> obj-$(CONFIG_DRM_MGA)+= mga/
> obj-$(CONFIG_DRM_I810) += i810/
> obj-$(CONFIG_DRM_I915) += i915/
> +obj-$(CONFIG_DRM_IVIP) += ivip/
> obj-$(CONFIG_DRM_MGAG200) += mgag200/
> obj-$(CONFIG_DRM_V3D) += v3d/
> obj-$(CONFIG_DRM_VC4) += vc4/
> diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
> new file mode 100644
> index 000..1d08b90
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/Kconfig
> @@ -0,0 +1,14 @@
> +config DRM_IVIP
> +tristate "Intel FGPA Video and Image Processing"
> +depends on DRM && OF
> +select DRM_GEM_CMA_HELPER
> +select DRM_KMS_HELPER
> +select DRM_KMS_FB_HELPER
> +select DRM_KMS_CMA_HELPER
> +help
> + Choose this option if you have an Intel FPGA Arria 10 system
> + and above with an Intel Display Port IP. This does not support
> + legacy Intel FPGA Cyclone V display port. Currently only
> single
> + frame buffer is supported. Note that ACPI and X_86
> architecture
> + is not supported for Arria10. If M is selected the module
> will be
> + called ivip.
> diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
> new file mode 100644
> index 000..8c54e11
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for the drm device driver. This driver provides support for the
> +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
> +
> +obj-$(CONFIG_DRM_IVIP) += ivip.o
> +ivip-objs := intel_vip_drv.o intel_vip_conn.o
> diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c
> b/drivers/gpu/drm/ivip/intel_vip_conn.c
> new file mode 100644
> index 000..93ce0b3
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
> @@ -0,0 +1,91 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Intel Corporation.
> + *
> + * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
> + * Frame Buffer II driver
> + *
> + * This driver supports the Intel VIP Frame Reader component.
> + * More info on the hardware can be found in the Intel Video
> + * and Image Processing Suite User Guide at this address
> + * http://www.altera.com/literature/ug/ug_vip.pdf.
> + *
> + * Authors:
> + * Walter Goossens
> + * Thomas Chou
> + * Chris Rauer
> + * Ong, Hean-Loong
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static enum drm_connector_status
> +intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
> +{
> + return connector_status_connected;
> +}
> +
> +static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
> +{
> + drm_connector_unregister(connector);
> + drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs intelvipfb_drm_connector_funcs = {
> + .detect = intelvipfb_drm_connector_detect,
> + .reset =
Re: [PATCH 01/18] MIPS: lantiq: pass struct device to DMA API functions
On Thu, Feb 07, 2019 at 11:29:14PM +, Paul Burton wrote: > Would you like this to go through the MIPS tree or elsewhere? If the > latter: > > Acked-by: Paul Burton Please pick it up through the mips tree!
Re: [RFC 1/2] page-flags: Make page lock operation atomic
On Mon 11-02-19 09:56:53, Matthew Wilcox wrote: > On Mon, Feb 11, 2019 at 06:48:46PM +0100, Jan Kara wrote: > > On Mon 11-02-19 13:59:24, Linux Upstream wrote: > > > > > > > >> Signed-off-by: Chintan Pandya > > > > > > > > NAK. > > > > > > > > This is bound to regress some stuff. Now agreed that using non-atomic > > > > ops is tricky, but many are in places where we 'know' there can't be > > > > concurrency. > > > > > > > > If you can show any single one is wrong, we can fix that one, but we're > > > > not going to blanket remove all this just because. > > > > > > Not quite familiar with below stack but from crash dump, found that this > > > was another stack running on some other CPU at the same time which also > > > updates page cache lru and manipulate locks. > > > > > > [84415.344577] [20190123_21:27:50.786264]@1 preempt_count_add+0xdc/0x184 > > > [84415.344588] [20190123_21:27:50.786276]@1 workingset_refault+0xdc/0x268 > > > [84415.344600] [20190123_21:27:50.786288]@1 > > > add_to_page_cache_lru+0x84/0x11c > > > [84415.344612] [20190123_21:27:50.786301]@1 > > > ext4_mpage_readpages+0x178/0x714 > > > [84415.344625] [20190123_21:27:50.786313]@1 ext4_readpages+0x50/0x60 > > > [84415.344636] [20190123_21:27:50.786324]@1 > > > __do_page_cache_readahead+0x16c/0x280 > > > [84415.344646] [20190123_21:27:50.786334]@1 filemap_fault+0x41c/0x588 > > > [84415.344655] [20190123_21:27:50.786343]@1 ext4_filemap_fault+0x34/0x50 > > > [84415.344664] [20190123_21:27:50.786353]@1 __do_fault+0x28/0x88 > > > > > > Not entirely sure if it's racing with the crashing stack or it's simply > > > overrides the the bit set by case 2 (mentioned in 0/2). > > > > So this is interesting. Looking at __add_to_page_cache_locked() nothing > > seems to prevent __SetPageLocked(page) in add_to_page_cache_lru() to get > > reordered into __add_to_page_cache_locked() after page is actually added to > > the xarray. So that one particular instance might benefit from atomic > > SetPageLocked or a barrier somewhere between __SetPageLocked() and the > > actual addition of entry into the xarray. > > There's a write barrier when you add something to the XArray, by virtue > of the call to rcu_assign_pointer(). OK, I've missed rcu_assign_pointer(). Thanks for correction... but... rcu_assign_pointer() is __smp_store_release(, v) and that on x86 seems to be: barrier(); \ WRITE_ONCE(*p, v); \ which seems to provide a compiler barrier but not an SMP barrier? So is x86 store ordering strong enough to make writes appear in the right order? So far I didn't think so... What am I missing? Honza -- Jan Kara SUSE Labs, CR
[PATCH v5 08/10] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver
Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
which is an interrupt controller that does the following:
- Converts events to interrupts that can be understood by
an interrupt router.
- Allows for multiplexing of events to interrupts.
Configuration of the interrupt aggregator registers can only be done by
a system co-processor and the driver needs to send a message to this
co processor over TISCI protocol.
Add support for Interrupt Aggregator driver with 2 IRQ Domains:
- INTA MSI domain that interfaces the devices using which interrupts can be
allocated dynamically.
- INTA domain that is parent to the MSI domain that manages the interrupt
resources.
Signed-off-by: Lokesh Vutla
Signed-off-by: Peter Ujfalusi
---
Changes since v4:
- Allocate the INTA output interrupts during probe.
MAINTAINERS | 1 +
drivers/irqchip/Kconfig | 12 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-ti-sci-inta.c | 531 ++
4 files changed, 545 insertions(+)
create mode 100644 drivers/irqchip/irq-ti-sci-inta.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 970c732b7158..44a3392239d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15069,6 +15069,7 @@ F:
Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
F: drivers/irqchip/irq-ti-sci-intr.c
F: drivers/irqchip/irq-ti-sci-common.c
F: drivers/irqchip/irq-ti-sci-common.h
+F: drivers/irqchip/irq-ti-sci-inta.c
Texas Instruments ASoC drivers
M: Peter Ujfalusi
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index a8d9bed0254b..d16fd39408ad 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -417,6 +417,18 @@ config TI_SCI_INTR_IRQCHIP
If you wish to use interrupt router irq resources managed by the
TI System Controller, say Y here. Otherwise, say N.
+config TI_SCI_INTA_IRQCHIP
+ bool
+ depends on TI_SCI_PROTOCOL && ARCH_K3
+ select IRQ_DOMAIN
+ select IRQ_DOMAIN_HIERARCHY
+ select K3_INTA_MSI_DOMAIN
+ help
+ This enables the irqchip driver support for K3 Interrupt aggregator
+ over TI System Control Interface available on some new TI's SoCs.
+ If you wish to use interrupt aggregator irq resources managed by the
+ TI System Controller, say Y here. Otherwise, say N.
+
endmenu
config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 0499fae148a9..caf6d084e0d4 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o
obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o
obj-$(CONFIG_MADERA_IRQ) += irq-madera.o
obj-$(CONFIG_TI_SCI_INTR_IRQCHIP) += irq-ti-sci-intr.o irq-ti-sci-common.o
+obj-$(CONFIG_TI_SCI_INTA_IRQCHIP) += irq-ti-sci-inta.o irq-ti-sci-common.o
diff --git a/drivers/irqchip/irq-ti-sci-inta.c
b/drivers/irqchip/irq-ti-sci-inta.c
new file mode 100644
index ..131944fec6fe
--- /dev/null
+++ b/drivers/irqchip/irq-ti-sci-inta.c
@@ -0,0 +1,531 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Texas Instruments' K3 Interrupt Aggregator irqchip driver
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "irq-ti-sci-common.h"
+
+#define MAX_EVENTS_PER_VINT64
+
+#define VINT_ENABLE_SET_OFFSET 0x0
+#define VINT_ENABLE_CLR_OFFSET 0x8
+#define VINT_STATUS_OFFSET 0x18
+
+/**
+ * struct ti_sci_inta_event_desc - Description of an event coming to
+ *Interrupt Aggregator.
+ * @global_event: Global event number corresponding to this event
+ * @src_id:TISCI device ID of the event source
+ * @src_index: Event source index within the device.
+ */
+struct ti_sci_inta_event_desc {
+ u16 global_event;
+ u16 src_id;
+ u16 src_index;
+};
+
+/**
+ * struct ti_sci_inta_vint_desc - Description of a virtual interrupt coming out
+ * of Interrupt Aggregator.
+ * @domain:Pointer to IRQ domain to which this vint belongs.
+ * @list: List entry for the vint list
+ * @event_lock:lock to guard the event map
+ * @event_map: Bitmap to manage the allocation of events to vint.
+ * @events:Array of event descriptors assigned to this vint.
+ * @parent_virq: Linux IRQ number that gets attached to parent
+ * @vint_id: TISCI vint ID
+ */
+struct ti_sci_inta_vint_desc {
+ struct irq_domain *domain;
+ struct list_head list;
+ struct mutex event_lock;
+ unsigned long *event_map;
+ struct ti_sci_inta_event_desc
[PATCH v5 07/10] dt-bindings: irqchip: Introduce TISCI Interrupt Aggregator bindings
Add the DT binding documentation for Interrupt Aggregator driver.
Signed-off-by: Lokesh Vutla
---
Changes sine v4:
- None
.../interrupt-controller/ti,sci-inta.txt | 74 +++
MAINTAINERS | 1 +
2 files changed, 75 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
new file mode 100644
index ..17b1fbd90312
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
@@ -0,0 +1,74 @@
+Texas Instruments K3 Interrupt Aggregator
+=
+
+The Interrupt Aggregator (INTA) provides a centralized machine
+which handles the termination of system events to that they can
+be coherently processed by the host(s) in the system. A maximum
+of 64 events can be mapped to a single interrupt.
+
+
+ Interrupt Aggregator
+ +-+
+ | IntmapVINT |
+ | +--+ ++|
+m -->| | vint | bit | | 0 |.|63| vint0 |
+ . | +--+ ++| +--+
+ . | . . | | HOST |
+Globalevents -->| . . |-->| IRQ |
+ . | . . | | CTRL |
+ . | . . | +--+
+n -->| +--+ ++|
+ | | vint | bit | | 0 |.|63| vintx |
+ | +--+ ++|
+ | |
+ +-+
+
+Configuration of these Intmap registers that maps global events to vint is done
+by a system controller (like the Device Memory and Security Controller on K3
+AM654 SoC). Driver should request the system controller to get the range
+of global events and vints assigned to the requesting host. Management
+of these requested resources should be handled by driver and requests
+system controller to map specific global event to vint, bit pair.
+
+Communication between the host processor running an OS and the system
+controller happens through a protocol called TI System Control Interface
+(TISCI protocol). For more details refer:
+Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+TISCI Interrupt Aggregator Node:
+---
+- compatible: Must be "ti,sci-inta".
+- reg: Should contain registers location and length.
+- interrupt-controller:Identifies the node as an interrupt controller
+- #interrupt-cells:Specifies the number of cells needed to encode an
+ interrupt source. The value should be 4.
+ First cell should contain the TISCI device ID of source
+ Second cell should contain the event source offset
+ within the device
+ Third cell specified the interrupt number(vint)
+ reaching Interrupt aggregator.
+ Fourth cell specifies the trigger type as defined
+ in interrupts.txt in this directory.
+- interrupt-parent:phandle of irq parent for TISCI intr.
+- ti,sci: Phandle to TI-SCI compatible System controller node.
+- ti,sci-dev-id: TISCI device ID of the Interrupt Aggregator.
+- ti,sci-rm-range-vint:TISCI subtype id representing the virtual
interrupts
+ (vints) range within this IA, assigned to the
+ requesting host context.
+- ti,sci-rm-range-global-event:TISCI subtype id representing the global
+ events range reaching this IA and are assigned
+ to the requesting host context.
+
+Example:
+
+main_udmass_inta: interrupt-controller@33d0 {
+ compatible = "ti,sci-inta";
+ reg = <0x0 0x33d0 0x0 0x10>;
+ interrupt-controller;
+ interrupt-parent = <_navss_intr>;
+ #interrupt-cells = <4>;
+ ti,sci = <>;
+ ti,sci-dev-id = <179>;
+ ti,sci-rm-range-vint = <0x0>;
+ ti,sci-rm-range-global-event = <0x1>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 823eeb672cf0..970c732b7158 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15065,6 +15065,7 @@ F:
Documentation/devicetree/bindings/clock/ti,sci-clk.txt
F: drivers/clk/keystone/sci-clk.c
F: drivers/reset/reset-ti-sci.c
F:
[PATCH v5 06/10] irqchip: ti-sci-intr: Add support for Interrupt Router driver
Texas Instruments' K3 generation SoCs has an IP Interrupt Router
that does allows for redirection of input interrupts to host
interrupt controller. Interrupt Router inputs are either from a
peripheral or from an Interrupt Aggregator which is another
interrupt controller.
Configuration of the interrupt router registers can only be done by
a system co-processor and the driver needs to send a message to this
co processor over TISCI protocol.
Add support for Interrupt Router driver over TISCI protocol.
Signed-off-by: Lokesh Vutla
---
Changes since v4:
- Moved the ti_sci irq resource handling to ti-sci-common.c from ti_sci.c.
Firmware maintainer rejected the idea of having this in firmware driver as
the resource handling is specific to the client.
- Obtain the number of peripheral interrupts attached to INTR by parsing DT.
Using this information store the max irqs that can be allocated to INTA.
This is done for pre allocating the INTA irqs(vints) during inta driver
probe.
This will not work for cases where there are more that 1 INTAs attached to
INTR, but wanted to show this approach as suggested by Marc.
MAINTAINERS | 3 +
drivers/irqchip/Kconfig | 11 +
drivers/irqchip/Makefile| 1 +
drivers/irqchip/irq-ti-sci-common.c | 131
drivers/irqchip/irq-ti-sci-common.h | 59 ++
drivers/irqchip/irq-ti-sci-intr.c | 315
6 files changed, 520 insertions(+)
create mode 100644 drivers/irqchip/irq-ti-sci-common.c
create mode 100644 drivers/irqchip/irq-ti-sci-common.h
create mode 100644 drivers/irqchip/irq-ti-sci-intr.c
diff --git a/MAINTAINERS b/MAINTAINERS
index c918d9b2ee18..823eeb672cf0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15065,6 +15065,9 @@ F:
Documentation/devicetree/bindings/clock/ti,sci-clk.txt
F: drivers/clk/keystone/sci-clk.c
F: drivers/reset/reset-ti-sci.c
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
+F: drivers/irqchip/irq-ti-sci-intr.c
+F: drivers/irqchip/irq-ti-sci-common.c
+F: drivers/irqchip/irq-ti-sci-common.h
Texas Instruments ASoC drivers
M: Peter Ujfalusi
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 3d1e60779078..a8d9bed0254b 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -406,6 +406,17 @@ config IMX_IRQSTEER
help
Support for the i.MX IRQSTEER interrupt multiplexer/remapper.
+config TI_SCI_INTR_IRQCHIP
+ bool
+ depends on TI_SCI_PROTOCOL && ARCH_K3
+ select IRQ_DOMAIN
+ select IRQ_DOMAIN_HIERARCHY
+ help
+ This enables the irqchip driver support for K3 Interrupt router
+ over TI System Control Interface available on some new TI's SoCs.
+ If you wish to use interrupt router irq resources managed by the
+ TI System Controller, say Y here. Otherwise, say N.
+
endmenu
config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index c93713d24b86..0499fae148a9 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -94,3 +94,4 @@ obj-$(CONFIG_CSKY_APB_INTC) += irq-csky-apb-intc.o
obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o
obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o
obj-$(CONFIG_MADERA_IRQ) += irq-madera.o
+obj-$(CONFIG_TI_SCI_INTR_IRQCHIP) += irq-ti-sci-intr.o irq-ti-sci-common.o
diff --git a/drivers/irqchip/irq-ti-sci-common.c
b/drivers/irqchip/irq-ti-sci-common.c
new file mode 100644
index ..79d9c4e8ea14
--- /dev/null
+++ b/drivers/irqchip/irq-ti-sci-common.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Common Code for TISCI IRQCHIP drivers
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla
+ */
+
+#include
+#include
+#include
+#include
+#include "irq-ti-sci-common.h"
+
+/**
+ * ti_sci_get_free_resource() - Get a free resource from TISCI resource.
+ * @res: Pointer to the TISCI resource
+ *
+ * Return: resource num if all went ok else TI_SCI_RESOURCE_NULL.
+ */
+u16 ti_sci_get_free_resource(struct ti_sci_resource *res)
+{
+ u16 set, free_bit;
+
+ mutex_lock(>request_mutex);
+ for (set = 0; set < res->sets; set++) {
+ free_bit = find_first_zero_bit(res->desc[set].res_map,
+ res->desc[set].num);
+ if (free_bit != res->desc[set].num) {
+ set_bit(free_bit, res->desc[set].res_map);
+ mutex_unlock(>request_mutex);
+ return res->desc[set].start + free_bit;
+ }
+ }
+ mutex_unlock(>request_mutex);
+
+ return TI_SCI_RESOURCE_NULL;
+}
+
+/**
+ * ti_sci_release_resource() - Release a resource from TISCI resource.
+ * @res: Pointer to the TISCI resource
+ * @id:Resource id to be
[PATCH v5 10/10] soc: ti: am6: Enable interrupt controller drivers
Select all the TISCI dependent interrupt controller drivers for AM6 SoC. Suggested-by: Marc Zyngier Signed-off-by: Lokesh Vutla --- Changes since v4: - None drivers/soc/ti/Kconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig index 7640490c2a6a..145b701a3d96 100644 --- a/drivers/soc/ti/Kconfig +++ b/drivers/soc/ti/Kconfig @@ -5,6 +5,11 @@ if ARCH_K3 config ARCH_K3_AM6_SOC bool "K3 AM6 SoC" + select MAILBOX + select TI_MESSAGE_MANAGER + select TI_SCI_PROTOCOL + select TI_SCI_INTR_IRQCHIP + select TI_SCI_INTA_IRQCHIP help Enable support for TI's AM6 SoC Family support -- 2.19.2
[PATCH v5 05/10] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings
Add the DT binding documentation for Interrupt router driver.
Signed-off-by: Lokesh Vutla
---
Changes since v4:
- None
.../interrupt-controller/ti,sci-intr.txt | 85 +++
MAINTAINERS | 1 +
2 files changed, 86 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
new file mode 100644
index ..4b0ca797fda1
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
@@ -0,0 +1,85 @@
+Texas Instruments K3 Interrupt Router
+=
+
+The Interrupt Router (INTR) module provides a mechanism to route M
+interrupt inputs to N interrupt outputs, where all M inputs are selectable
+to be driven per N output. There is one register per output (MUXCNTL_N) that
+controls the selection.
+
+
+ Interrupt Router
+ +--+
+ | Inputs Outputs |
++---+| +--+ |
+| GPIO |--->| | irq0 | | Host IRQ
++---+| +--+ | controller
+ |.+-+ | +---+
++---+|.| 0 | |->| IRQ |
+| INTA |--->|.+-+ | +---+
++---+|. . |
+ | +--+ . |
+ | | irqM |+-+ |
+ | +--+| N | |
+ | +-+ |
+ +--+
+
+Configuration of these MUXCNTL_N registers is done by a system controller
+(like the Device Memory and Security Controller on K3 AM654 SoC). System
+controller will keep track of the used and unused registers within the Router.
+Driver should request the system controller to get the range of GIC IRQs
+assigned to the requesting hosts. It is the drivers responsibility to keep
+track of Host IRQs.
+
+Communication between the host processor running an OS and the system
+controller happens through a protocol called TI System Control Interface
+(TISCI protocol). For more details refer:
+Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+TISCI Interrupt Router Node:
+
+- compatible: Must be "ti,sci-intr".
+- interrupt-controller:Identifies the node as an interrupt controller
+- #interrupt-cells:Specifies the number of cells needed to encode an
+ interrupt source. The value should be 4.
+ First cell should contain the TISCI device ID of source
+ Second cell should contain the interrupt source offset
+ within the device
+ Third cell specifies the trigger type as defined
+ in interrupts.txt in this directory.
+ Fourth cell should be 1 if the irq is coming from
+ interrupt aggregator else 0.
+- ti,sci: Phandle to TI-SCI compatible System controller node.
+- ti,sci-dst-id: TISCI device ID of the destination IRQ controller.
+- ti,sci-rm-range-girq:Array of TISCI subtype ids representing the
host irqs
+ assigned to this interrupt router. Each subtype id
+ corresponds to a range of host irqs.
+
+For more details on TISCI IRQ resource management refer:
+http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html
+
+Example:
+
+The following example demonstrates both interrupt router node and the consumer
+node(main gpio) on the AM654 SoC:
+
+main_intr: interrupt-controller0 {
+ compatible = "ti,sci-intr";
+ interrupt-controller;
+ interrupt-parent = <>;
+ #interrupt-cells = <4>;
+ ti,sci = <>;
+ ti,sci-dst-id = <56>;
+ ti,sci-rm-range-girq = <0x1>;
+};
+
+main_gpio0: gpio@60 {
+ ...
+ interrupt-parent = <_intr>;
+ interrupts = <57 256 IRQ_TYPE_EDGE_RISING 0>,
+ <57 257 IRQ_TYPE_EDGE_RISING 0>,
+ <57 258 IRQ_TYPE_EDGE_RISING 0>,
+ <57 259 IRQ_TYPE_EDGE_RISING 0>,
+ <57 260 IRQ_TYPE_EDGE_RISING 0>,
+ <57 261 IRQ_TYPE_EDGE_RISING 0>;
+ ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 8c68de3cfd80..c918d9b2ee18 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15064,6 +15064,7 @@ F:
Documentation/devicetree/bindings/reset/ti,sci-reset.txt
F: Documentation/devicetree/bindings/clock/ti,sci-clk.txt
F:
[PATCH v5 09/10] soc: ti: Add MSI domain support for K3 Interrupt Aggregator
With the system coprocessor managing the range allocation of the
inputs to Interrupt Aggregator, it is difficult to represent
the device IRQs from DT.
The suggestion is to use MSI in such cases where devices wants
to allocate and group interrupts dynamically.
Create a MSI domain bus layer that allocates and frees MSIs for
a device.
APIs that are implemented are:
- inta_msi_create_irq_domain() that creates a MSI domain
- inta_msi_domain_alloc_irqs() that creates MSIs for the
specified device and source indexes.
- inta_msi_domain_free_irqs() frees the grouped irqs.
Signed-off-by: Lokesh Vutla
---
Changes since v4:
- Dropped support for creating allocation of single MSI.
- Use the existing MSI apis for allocating IRQs
drivers/soc/ti/Kconfig | 6 ++
drivers/soc/ti/Makefile| 1 +
drivers/soc/ti/k3_inta_msi.c | 143 +
include/linux/irqdomain.h | 1 +
include/linux/msi.h| 7 ++
include/linux/soc/ti/k3_inta_msi.h | 21 +
6 files changed, 179 insertions(+)
create mode 100644 drivers/soc/ti/k3_inta_msi.c
create mode 100644 include/linux/soc/ti/k3_inta_msi.h
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index be4570baad96..7640490c2a6a 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -73,4 +73,10 @@ config TI_SCI_PM_DOMAINS
called ti_sci_pm_domains. Note this is needed early in boot before
rootfs may be available.
+config K3_INTA_MSI_DOMAIN
+ bool
+ select GENERIC_MSI_IRQ_DOMAIN
+ help
+ Driver to enable Interrupt Aggregator specific MSI Domain.
+
endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index a22edc0b258a..152b195273ee 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA)+= knav_dma.o
obj-$(CONFIG_AMX3_PM) += pm33xx.o
obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
obj-$(CONFIG_TI_SCI_PM_DOMAINS)+= ti_sci_pm_domains.o
+obj-$(CONFIG_K3_INTA_MSI_DOMAIN) += k3_inta_msi.o
diff --git a/drivers/soc/ti/k3_inta_msi.c b/drivers/soc/ti/k3_inta_msi.c
new file mode 100644
index ..ffce1a7541e2
--- /dev/null
+++ b/drivers/soc/ti/k3_inta_msi.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Texas Instruments' K3 Interrupt Aggregator MSI bus
+ *
+ * Copyright (C) 2018-2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void inta_msi_write_msg(struct irq_data *data, struct msi_msg *msg)
+{
+ /* Nothing to do */
+}
+
+static void inta_msi_compose_msi_msg(struct irq_data *data,
+struct msi_msg *msg)
+{
+ /* Nothing to do */
+}
+
+static void inta_msi_update_chip_ops(struct msi_domain_info *info)
+{
+ struct irq_chip *chip = info->chip;
+
+ BUG_ON(!chip);
+ if (!chip->irq_mask)
+ chip->irq_mask = irq_chip_mask_parent;
+ if (!chip->irq_unmask)
+ chip->irq_unmask = irq_chip_unmask_parent;
+ if (!chip->irq_eoi)
+ chip->irq_eoi = irq_chip_eoi_parent;
+ if (!chip->irq_write_msi_msg)
+ chip->irq_write_msi_msg = inta_msi_write_msg;
+ if (!chip->irq_compose_msi_msg)
+ chip->irq_compose_msi_msg = inta_msi_compose_msi_msg;
+}
+
+struct irq_domain *inta_msi_create_irq_domain(struct fwnode_handle *fwnode,
+ struct msi_domain_info *info,
+ struct irq_domain *parent)
+{
+ struct irq_domain *domain;
+
+ if (info->flags & MSI_FLAG_USE_DEF_CHIP_OPS)
+ inta_msi_update_chip_ops(info);
+
+ domain = msi_create_irq_domain(fwnode, info, parent);
+ if (domain)
+ irq_domain_update_bus_token(domain, DOMAIN_BUS_K3_INTA_MSI);
+
+ return domain;
+}
+EXPORT_SYMBOL_GPL(inta_msi_create_irq_domain);
+
+static void inta_msi_free_descs(struct device *dev)
+{
+ struct msi_desc *desc, *tmp;
+
+ list_for_each_entry_safe(desc, tmp, dev_to_msi_list(dev), list) {
+ list_del(>list);
+ free_msi_entry(desc);
+ }
+}
+
+static int inta_msi_alloc_descs(struct device *dev, u32 dev_id, int nvec,
+ u32 *arr_index, bool share)
+{
+ struct msi_desc *msi_desc;
+ int i;
+
+ for (i = 0; i < nvec; i++) {
+ msi_desc = alloc_msi_entry(dev, 1, NULL);
+ if (!msi_desc)
+ break;
+
+ msi_desc->inta.index = arr_index[i];
+ msi_desc->inta.dev_id = dev_id;
+ msi_desc->inta.share = share;
+ INIT_LIST_HEAD(_desc->list);
+ list_add_tail(_desc->list, dev_to_msi_list(dev));
+ };
+
+ if (i !=
[PATCH v5 03/10] firmware: ti_sci: Add support for IRQ management
TISCI abstracts the handling of IRQ routes where interrupt sources
are not directly connected to host interrupt controller. Add support
for the set of TISCI commands for requesting and releasing IRQs.
Signed-off-by: Lokesh Vutla
---
Changes since v4:
- Updated to the latest sysfw APIs where event irq configuration is broken
down in two parts. One for event to vint map and other for vint to gic map.
- Dropped support for configuring irqs for secondary host to avoid confusion.
This can be added later once the support is required.
drivers/firmware/ti_sci.c | 260 +
drivers/firmware/ti_sci.h | 60 ++
include/linux/soc/ti/ti_sci_protocol.h | 28 +++
3 files changed, 348 insertions(+)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index a2a099b8f62a..729fef77379e 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1782,6 +1782,260 @@ int ti_sci_cmd_get_resource_range_from_shost(const
struct ti_sci_handle *handle,
range_start, range_num);
}
+/**
+ * ti_sci_manage_irq() - Helper api to configure/release the irq route between
+ * the requested source and destination
+ * @handle:Pointer to TISCI handle.
+ * @valid_params: Bit fields defining the validity of certain params
+ * @src_id:Device ID of the IRQ source
+ * @src_index: IRQ source index within the source device
+ * @dst_id:Device ID of the IRQ destination
+ * @dt_host_irq: IRQ number of the destination device
+ * @ia_id: Device ID of the IA, if the IRQ flows through this IA
+ * @vint: Virtual interrupt to be used within the IA
+ * @global_event: Global event number to be used for the requesting event
+ * @vint_status_bit: Virtual interrupt status bit to be used for the event
+ * @s_host:Secondary host ID to which the irq/event is being
+ * requested for.
+ * @type: Request type irq set or release.
+ *
+ * Return: 0 if all went fine, else return appropriate error.
+ */
+static int ti_sci_manage_irq(const struct ti_sci_handle *handle,
+u32 valid_params, u16 src_id, u16 src_index,
+u16 dst_id, u16 dst_host_irq, u16 ia_id, u16 vint,
+u16 global_event, u8 vint_status_bit, u8 s_host,
+u16 type)
+{
+ struct ti_sci_msg_req_manage_irq *req;
+ struct ti_sci_msg_hdr *resp;
+ struct ti_sci_xfer *xfer;
+ struct ti_sci_info *info;
+ struct device *dev;
+ int ret = 0;
+
+ if (IS_ERR(handle))
+ return PTR_ERR(handle);
+ if (!handle)
+ return -EINVAL;
+
+ info = handle_to_ti_sci_info(handle);
+ dev = info->dev;
+
+ xfer = ti_sci_get_one_xfer(info, type, TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+ sizeof(*req), sizeof(*resp));
+ if (IS_ERR(xfer)) {
+ ret = PTR_ERR(xfer);
+ dev_err(dev, "Message alloc failed(%d)\n", ret);
+ return ret;
+ }
+ req = (struct ti_sci_msg_req_manage_irq *)xfer->xfer_buf;
+ req->valid_params = valid_params;
+ req->src_id = src_id;
+ req->src_index = src_index;
+ req->dst_id = dst_id;
+ req->dst_host_irq = dst_host_irq;
+ req->ia_id = ia_id;
+ req->vint = vint;
+ req->global_event = global_event;
+ req->vint_status_bit = vint_status_bit;
+ req->secondary_host = s_host;
+
+ ret = ti_sci_do_xfer(info, xfer);
+ if (ret) {
+ dev_err(dev, "Mbox send fail %d\n", ret);
+ goto fail;
+ }
+
+ resp = (struct ti_sci_msg_hdr *)xfer->xfer_buf;
+
+ ret = ti_sci_is_response_ack(resp) ? 0 : -ENODEV;
+
+fail:
+ ti_sci_put_one_xfer(>minfo, xfer);
+
+ return ret;
+}
+
+/**
+ * ti_sci_set_irq() - Helper api to configure the irq route between the
+ * requested source and destination
+ * @handle:Pointer to TISCI handle.
+ * @valid_params: Bit fields defining the validity of certain params
+ * @src_id:Device ID of the IRQ source
+ * @src_index: IRQ source index within the source device
+ * @dst_id:Device ID of the IRQ destination
+ * @dt_host_irq: IRQ number of the destination device
+ * @ia_id: Device ID of the IA, if the IRQ flows through this IA
+ * @vint: Virtual interrupt to be used within the IA
+ * @global_event: Global event number to be used for the requesting event
+ * @vint_status_bit: Virtual interrupt status bit to be used for the event
+ * @s_host:Secondary host ID to which the irq/event is being
+ * requested for.
+ *
+ * Return: 0 if all went fine, else return appropriate error.
+ */
+static int
[PATCH v5 00/10] Add support for TISCI irqchip drivers
TI AM65x SoC based on K3 architecture introduced support for Events which are message based interrupts with minimal latency. These events are not compatible with regular interrupts and are valid only through an event transport lane. An Interrupt Aggregator(INTA) is introduced to convert these events to interrupts. INTA can also group 64 events into a single interrupt. Now the SoC has many peripherals and a large number of event sources (time sync or DMA), the use of events is completely dependent on a user's specific application, which drives a need for maximum flexibility in which event sources are used in the system. It is also completely up to software control as to how the events are serviced. Because of the huge flexibility there are certain standard peripherals (like GPIO etc)where all interrupts cannot be directly corrected to host interrupt controller. For this purpose, Interrupt Router(INTR) is introduced in the SoC. INTR just does a classic interrupt redirection. So the SoC has 3 types of interrupt controllers: - GIC500 - Interrupt Router - Interrupt Aggregator Below is a diagrammatic view of how SoC integration of these interrupt controllers:(https://pastebin.ubuntu.com/p/9ngV3jdGj2/) Device Index-x Device Index-y | | | | \ / \ / \ (global events) / +---+ +-+ | | | | | INTA | | GPIO | | | | | +---+ +-+ | (vint)| | | \|/| +---+| | |<---+ | INTR| | | +---+ | | \|/ (gic irq) +---+ | | | GIC | | | +---+ While at it, TISCI abstracts the handling of all above IRQ routes where interrupt sources are not directly connected to host interrupt controller. That would be configuration of Interrupt Aggregator and Interrupt Router. This series adds support for: - TISCI commands needed for IRQ configuration - Interrupt Router(INTR) and Interrupt Aggregator(INTA) drivers Changes since v4: - Mentioned the changes in each patch Changes since v3: - Fix documentation for Interrupt Router driver - Rebased on top of latest next. - Fully tested with DMA(using out of tree patches) - Fixed a build error with allmodconfig Grygorii Strashko (1): firmware: ti_sci: Add support to get TISCI handle using of_phandle Lokesh Vutla (8): firmware: ti_sci: Add support for RM core ops firmware: ti_sci: Add support for IRQ management dt-bindings: irqchip: Introduce TISCI Interrupt router bindings irqchip: ti-sci-intr: Add support for Interrupt Router driver dt-bindings: irqchip: Introduce TISCI Interrupt Aggregator bindings irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver soc: ti: Add MSI domain support for K3 Interrupt Aggregator soc: ti: am6: Enable interrupt controller drivers Peter Ujfalusi (1): firmware: ti_sci: Add RM mapping table for am654 .../bindings/arm/keystone/ti,sci.txt | 3 +- .../interrupt-controller/ti,sci-inta.txt | 74 +++ .../interrupt-controller/ti,sci-intr.txt | 85 +++ MAINTAINERS | 6 + drivers/firmware/ti_sci.c | 536 ++ drivers/firmware/ti_sci.h | 102 drivers/irqchip/Kconfig | 23 + drivers/irqchip/Makefile | 2 + drivers/irqchip/irq-ti-sci-common.c | 131 + drivers/irqchip/irq-ti-sci-common.h | 59 ++ drivers/irqchip/irq-ti-sci-inta.c | 531 + drivers/irqchip/irq-ti-sci-intr.c | 315 ++ drivers/soc/ti/Kconfig| 11 + drivers/soc/ti/Makefile | 1 + drivers/soc/ti/k3_inta_msi.c | 143 + include/linux/irqdomain.h | 1 + include/linux/msi.h | 7 + include/linux/soc/ti/k3_inta_msi.h| 21 + include/linux/soc/ti/ti_sci_protocol.h| 72 +++ 19 files changed, 2122 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt create mode 100644
[PATCH v5 02/10] firmware: ti_sci: Add support for RM core ops
TISCI provides support for getting the resources(IRQ, RING etc..)
assigned to a specific device. These resources can be handled by
the client and in turn sends TISCI cmd to configure the resources.
It is very important that client should keep track on usage of these
resources.
Add support for TISCI commands to get resource ranges.
Signed-off-by: Lokesh Vutla
Signed-off-by: Peter Ujfalusi
---
Changes since v4:
- None
drivers/firmware/ti_sci.c | 170 +
drivers/firmware/ti_sci.h | 42 ++
include/linux/soc/ti/ti_sci_protocol.h | 27
3 files changed, 239 insertions(+)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index f0cafa8a2ee9..a2a099b8f62a 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -64,6 +64,22 @@ struct ti_sci_xfers_info {
spinlock_t xfer_lock;
};
+/**
+ * struct ti_sci_rm_type_map - Structure representing TISCI Resource
+ * management representation of dev_ids.
+ * @dev_id:TISCI device ID
+ * @type: Corresponding id as identified by TISCI RM.
+ *
+ * Note: This is used only as a work around for using RM range apis
+ * for AM654 SoC. For future SoCs dev_id will be used as type
+ * for RM range APIs. In order to maintain ABI backward compatibility
+ * type is not being changed for AM654 SoC.
+ */
+struct ti_sci_rm_type_map {
+ u32 dev_id;
+ u16 type;
+};
+
/**
* struct ti_sci_desc - Description of SoC integration
* @default_host_id: Host identifier representing the compute entity
@@ -71,12 +87,14 @@ struct ti_sci_xfers_info {
* @max_msgs: Maximum number of messages that can be pending
* simultaneously in the system
* @max_msg_size: Maximum size of data per message that can be handled.
+ * @rm_type_map: RM resource type mapping structure.
*/
struct ti_sci_desc {
u8 default_host_id;
int max_rx_timeout_ms;
int max_msgs;
int max_msg_size;
+ struct ti_sci_rm_type_map *rm_type_map;
};
/**
@@ -1617,6 +1635,153 @@ static int ti_sci_cmd_core_reboot(const struct
ti_sci_handle *handle)
return ret;
}
+static int ti_sci_get_resource_type(struct ti_sci_info *info, u16 dev_id,
+ u16 *type)
+{
+ struct ti_sci_rm_type_map *rm_type_map = info->desc->rm_type_map;
+ bool found = false;
+ int i;
+
+ /* If map is not provided then assume dev_id is used as type */
+ if (!rm_type_map) {
+ *type = dev_id;
+ return 0;
+ }
+
+ for (i = 0; rm_type_map[i].dev_id; i++) {
+ if (rm_type_map[i].dev_id == dev_id) {
+ *type = rm_type_map[i].type;
+ found = true;
+ break;
+ }
+ }
+
+ if (!found)
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
+ * ti_sci_get_resource_range - Helper to get a range of resources assigned
+ *to a host. Resource is uniquely identified by
+ *type and subtype.
+ * @handle:Pointer to TISCI handle.
+ * @dev_id:TISCI device ID.
+ * @subtype: Resource assignment subtype that is being requested
+ * from the given device.
+ * @s_host:Host processor ID to which the resources are allocated
+ * @range_start: Start index of the resource range
+ * @range_num: Number of resources in the range
+ *
+ * Return: 0 if all went fine, else return appropriate error.
+ */
+static int ti_sci_get_resource_range(const struct ti_sci_handle *handle,
+u32 dev_id, u8 subtype, u8 s_host,
+u16 *range_start, u16 *range_num)
+{
+ struct ti_sci_msg_resp_get_resource_range *resp;
+ struct ti_sci_msg_req_get_resource_range *req;
+ struct ti_sci_xfer *xfer;
+ struct ti_sci_info *info;
+ struct device *dev;
+ u16 type;
+ int ret = 0;
+
+ if (IS_ERR(handle))
+ return PTR_ERR(handle);
+ if (!handle)
+ return -EINVAL;
+
+ info = handle_to_ti_sci_info(handle);
+ dev = info->dev;
+
+ xfer = ti_sci_get_one_xfer(info, TI_SCI_MSG_GET_RESOURCE_RANGE,
+ TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+ sizeof(*req), sizeof(*resp));
+ if (IS_ERR(xfer)) {
+ ret = PTR_ERR(xfer);
+ dev_err(dev, "Message alloc failed(%d)\n", ret);
+ return ret;
+ }
+
+ ret = ti_sci_get_resource_type(info, dev_id, );
+ if (ret) {
+ dev_err(dev, "rm type lookup failed for %u\n", dev_id);
+ goto fail;
+ }
+
+ req = (struct ti_sci_msg_req_get_resource_range *)xfer->xfer_buf;
+ req->secondary_host = s_host;
+ req->type = type
[PATCH v5 04/10] firmware: ti_sci: Add RM mapping table for am654
From: Peter Ujfalusi
Add the resource mapping table for AM654 SoC as defined
in http://downloads.ti.com/tisci/esd/latest/5_soc_doc/am6x/resasg_types.html
Introduce a new compatible for AM654 "ti,am654-sci" for using
this resource map table.
Reviewed-by: Rob Herring
Signed-off-by: Peter Ujfalusi
Signed-off-by: Lokesh Vutla
---
Changes since v4:
- None
.../bindings/arm/keystone/ti,sci.txt | 3 ++-
drivers/firmware/ti_sci.c | 23 +++
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
index b56a02c10ae6..6f0cd31c1520 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
@@ -24,7 +24,8 @@ relationship between the TI-SCI parent node to the child node.
Required properties:
---
-- compatible: should be "ti,k2g-sci"
+- compatible: should be "ti,k2g-sci" for TI 66AK2G SoC
+ should be "ti,am654-sci" for for TI AM654 SoC
- mbox-names:
"rx" - Mailbox corresponding to receive path
"tx" - Mailbox corresponding to transmit path
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 729fef77379e..7f6fed374973 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -2314,10 +2314,33 @@ static const struct ti_sci_desc ti_sci_pmmc_k2g_desc = {
/* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
.max_msgs = 20,
.max_msg_size = 64,
+ .rm_type_map = NULL,
+};
+
+static struct ti_sci_rm_type_map ti_sci_am654_rm_type_map[] = {
+ {.dev_id = 56, .type = 0x00b}, /* GIC_IRQ */
+ {.dev_id = 179, .type = 0x000}, /* MAIN_NAV_UDMASS_IA0 */
+ {.dev_id = 187, .type = 0x009}, /* MAIN_NAV_RA */
+ {.dev_id = 188, .type = 0x006}, /* MAIN_NAV_UDMAP */
+ {.dev_id = 194, .type = 0x007}, /* MCU_NAV_UDMAP */
+ {.dev_id = 195, .type = 0x00a}, /* MCU_NAV_RA */
+ {.dev_id = 0, .type = 0x000}, /* end of table */
+};
+
+/* Description for AM654 */
+static const struct ti_sci_desc ti_sci_pmmc_am654_desc = {
+ .default_host_id = 12,
+ /* Conservative duration */
+ .max_rx_timeout_ms = 1,
+ /* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
+ .max_msgs = 20,
+ .max_msg_size = 60,
+ .rm_type_map = ti_sci_am654_rm_type_map,
};
static const struct of_device_id ti_sci_of_match[] = {
{.compatible = "ti,k2g-sci", .data = _sci_pmmc_k2g_desc},
+ {.compatible = "ti,am654-sci", .data = _sci_pmmc_am654_desc},
{ /* Sentinel */ },
};
MODULE_DEVICE_TABLE(of, ti_sci_of_match);
--
2.19.2
[PATCH v5 01/10] firmware: ti_sci: Add support to get TISCI handle using of_phandle
From: Grygorii Strashko
TISCI has been updated to have support for Resource management(likes
interrupts etc..). And there can be multiple device instances of a
resource type in a SoC. So every driver corresponding to a resource type
should get a TISCI handle so that it can make TISCI calls. And each
DT node corresponding to a device should exist under its corresponding
bus node as per the SoC architecture.
But existing apis in TISCI library assumes that all TISCI users are
child nodes of TISCI. Which is not true in the above case. So introduce
(devm_)ti_sci_get_by_phandle() apis that can be used by TISCI users
to get TISCI handle using of phandle property.
Signed-off-by: Grygorii Strashko
Signed-off-by: Lokesh Vutla
---
Changes since v4:
- None
drivers/firmware/ti_sci.c | 83 ++
include/linux/soc/ti/ti_sci_protocol.h | 17 ++
2 files changed, 100 insertions(+)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 69ed1464175c..f0cafa8a2ee9 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1781,6 +1781,89 @@ const struct ti_sci_handle
*devm_ti_sci_get_handle(struct device *dev)
}
EXPORT_SYMBOL_GPL(devm_ti_sci_get_handle);
+/**
+ * ti_sci_get_by_phandle() - Get the TI SCI handle using DT phandle
+ * @np:device node
+ * @propname: property name containing phandle on TISCI node
+ *
+ * NOTE: The function does not track individual clients of the framework
+ * and is expected to be maintained by caller of TI SCI protocol library.
+ * ti_sci_put_handle must be balanced with successful ti_sci_get_by_phandle
+ * Return: pointer to handle if successful, else:
+ * -EPROBE_DEFER if the instance is not ready
+ * -ENODEV if the required node handler is missing
+ * -EINVAL if invalid conditions are encountered.
+ */
+const struct ti_sci_handle *ti_sci_get_by_phandle(struct device_node *np,
+ const char *property)
+{
+ struct ti_sci_handle *handle = NULL;
+ struct device_node *ti_sci_np;
+ struct ti_sci_info *info;
+ struct list_head *p;
+
+ if (!np) {
+ pr_err("I need a device pointer\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ ti_sci_np = of_parse_phandle(np, property, 0);
+ if (!ti_sci_np)
+ return ERR_PTR(-ENODEV);
+
+ mutex_lock(_sci_list_mutex);
+ list_for_each(p, _sci_list) {
+ info = list_entry(p, struct ti_sci_info, node);
+ if (ti_sci_np == info->dev->of_node) {
+ handle = >handle;
+ info->users++;
+ break;
+ }
+ }
+ mutex_unlock(_sci_list_mutex);
+ of_node_put(ti_sci_np);
+
+ if (!handle)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ return handle;
+}
+EXPORT_SYMBOL_GPL(ti_sci_get_by_phandle);
+
+/**
+ * devm_ti_sci_get_by_phandle() - Managed get handle using phandle
+ * @dev: Device pointer requesting TISCI handle
+ * @propname: property name containing phandle on TISCI node
+ *
+ * NOTE: This releases the handle once the device resources are
+ * no longer needed. MUST NOT BE released with ti_sci_put_handle.
+ * The function does not track individual clients of the framework
+ * and is expected to be maintained by caller of TI SCI protocol library.
+ *
+ * Return: 0 if all went fine, else corresponding error.
+ */
+const struct ti_sci_handle *devm_ti_sci_get_by_phandle(struct device *dev,
+ const char *property)
+{
+ const struct ti_sci_handle *handle;
+ const struct ti_sci_handle **ptr;
+
+ ptr = devres_alloc(devm_ti_sci_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+ handle = ti_sci_get_by_phandle(dev_of_node(dev), property);
+
+ if (!IS_ERR(handle)) {
+ *ptr = handle;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return handle;
+}
+EXPORT_SYMBOL_GPL(devm_ti_sci_get_by_phandle);
+
static int tisci_reboot_handler(struct notifier_block *nb, unsigned long mode,
void *cmd)
{
diff --git a/include/linux/soc/ti/ti_sci_protocol.h
b/include/linux/soc/ti/ti_sci_protocol.h
index 18435e5c6364..515587e9d373 100644
--- a/include/linux/soc/ti/ti_sci_protocol.h
+++ b/include/linux/soc/ti/ti_sci_protocol.h
@@ -217,6 +217,10 @@ struct ti_sci_handle {
const struct ti_sci_handle *ti_sci_get_handle(struct device *dev);
int ti_sci_put_handle(const struct ti_sci_handle *handle);
const struct ti_sci_handle *devm_ti_sci_get_handle(struct device *dev);
+const struct ti_sci_handle *ti_sci_get_by_phandle(struct device_node *np,
+ const char *property);
+const struct ti_sci_handle *devm_ti_sci_get_by_phandle(struct device *dev,
+
Re: [PATCH] clk: samsung: s3c2443: Mark expected switch fall-through
On Mon, 11 Feb 2019 at 19:40, Gustavo A. R. Silva wrote: > > In preparation to enabling -Wimplicit-fallthrough, mark switch > cases where we are expecting to fall through. > > This patch fixes the following warnings: > > drivers/clk/samsung/clk-s3c2443.c: In function ‘s3c2443_common_clk_init’: > drivers/clk/samsung/clk-s3c2443.c:390:3: warning: this statement may fall > through [-Wimplicit-fallthrough=] >samsung_clk_register_alias(ctx, s3c2450_aliases, >^~~~ > ARRAY_SIZE(s3c2450_aliases)); > > drivers/clk/samsung/clk-s3c2443.c:393:2: note: here > case S3C2416: > ^~~~ > > Warning level 3 was used: -Wimplicit-fallthrough=3 > > Notice that, in this particular case, the code comment is modified > in accordance with what GCC is expecting to find. > > This patch is part of the ongoing efforts to enable > -Wimplicit-fallthrough. I saw this in multiple places already and I think fix is wrong. The point is that the code is correct - the fall through is marked properly. It is just the GCC which has to be fixed not the code. You want to adjust the code for specific version of GCC and what if GCC changes its warning? For example GCC might require "fall through: "... or any other syntax. Another point - what about clang's syntax? Best regards, Krzysztof
[PATCH] xarray: Document erasing entries during iteration
The XArray is, in a way, a replacement data structure for linked lists,
as such, on first use developers may wonder if it is safe to remove
items while iterating over the array.
For example, this is fine:
DEFINE_XARRAY(things);
void cleanup()
{
struct thing *thing;
unsigned long index;
xa_for_each(, index, thing)
xa_erase(, index);
}
Document this feature explicitly in the docs and also for the macro
definition.
Signed-off-by: Tobin C. Harding
---
Hi Willy,
I had my first go using the XArray today and during that I wondered if
it was safe to remove items during iteration. Conceptually it seems
fine and it seemed to work just fine in code - is this something people
should not be doing for any reason? Is this the best way to traverse
the tree and get every thing just to erase it? Are we even supposed to
be thinking this is a tree or should we just be thinking it is an array?
(As you might have guessed I _still_ don't know exactly how a radix tree
works :)
Oh, and FTR the XArray is hot - good effort man.
thanks,
Tobin.
Documentation/core-api/xarray.rst | 3 ++-
include/linux/xarray.h| 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/core-api/xarray.rst
b/Documentation/core-api/xarray.rst
index 5d54b27c6eba..2578e0bdaa17 100644
--- a/Documentation/core-api/xarray.rst
+++ b/Documentation/core-api/xarray.rst
@@ -97,7 +97,8 @@ You can copy entries out of the XArray into a plain array by
calling
:c:func:`xa_extract`. Or you can iterate over the present entries in
the XArray by calling :c:func:`xa_for_each`. You may prefer to use
:c:func:`xa_find` or :c:func:`xa_find_after` to move to the next present
-entry in the XArray.
+entry in the XArray. It is safe to call :c:func:`xa_release` on entries
+as you iterate over the array using :c:func:`xa_for_each`.
Calling :c:func:`xa_store_range` stores the same entry in a range
of indices. If you do this, some of the other operations will behave
diff --git a/include/linux/xarray.h b/include/linux/xarray.h
index 5d9d318bcf7a..1f8974281a0a 100644
--- a/include/linux/xarray.h
+++ b/include/linux/xarray.h
@@ -407,6 +407,8 @@ static inline bool xa_marked(const struct xarray *xa,
xa_mark_t mark)
* you should use the xas_for_each() iterator instead. The xas_for_each()
* iterator will expand into more inline code than xa_for_each().
*
+ * It is safe to erase entries from the XArray as you iterate over it.
+ *
* Context: Any context. Takes and releases the RCU lock.
*/
#define xa_for_each(xa, index, entry) \
--
2.20.1
Re: [PATCH v2] driver: platform: Support parsing GpioInt 0 in platform_get_irq()
Hi, On 11-02-19 20:01, egran...@chromium.org wrote: From: Enrico Granata ACPI 5 added support for GpioInt resources as a way to provide information about interrupts mediated via a GPIO controller. Several device buses (e.g. SPI, I2C) have support for retrieving an IRQ specified via this type of resource, and providing it directly to the driver as an IRQ number. This is not currently done for the platform drivers, as platform_get_irq() does not try to parse GpioInt() resources. This requires drivers to either have to support only one possible IRQ resource, or to have code in place to try both as a failsafe. While there is a possibility of ambiguity for devices that exposes multiple IRQs, it is easy and feasible to support the common case of devices that only expose one IRQ which would be of either type depending on the underlying system's architecture. This commit adds support for parsing a GpioInt resource in order to fulfill a request for the index 0 IRQ for a platform device. Signed-off-by: Enrico Granata Looks good to me: Acked-by: Hans de Goede Regards, Hans --- Changes in v2: - only support IRQ index 0 drivers/base/platform.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 1c958eb33ef4d..0d3611cd1b3bc 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -127,7 +127,20 @@ int platform_get_irq(struct platform_device *dev, unsigned int num) irqd_set_trigger_type(irqd, r->flags & IORESOURCE_BITS); } - return r ? r->start : -ENXIO; + if (r) + return r->start; + + /* +* For the index 0 interrupt, allow falling back to GpioInt +* resources. While a device could have both Interrupt and GpioInt +* resources, making this fallback ambiguous, in many common cases +* the device will only expose one IRQ, and this fallback +* allows a common code path across either kind of resource. +*/ + if (num == 0 && has_acpi_companion(>dev)) + return acpi_dev_gpio_irq_get(ACPI_COMPANION(>dev), num); + + return -ENXIO; #endif } EXPORT_SYMBOL_GPL(platform_get_irq);
Re: [PATCH net-next 3/3] staging: fsl-dpaa2: ethsw: Remove getting PORT_BRIDGE_FLAGS
On Mon, Feb 11, 2019 at 01:17:49PM -0800, Florian Fainelli wrote: > There is no code that tries to get the attribute > SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS, remove support for doing that. > > Signed-off-by: Florian Fainelli > --- > drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 5 - > 1 file changed, 5 deletions(-) Acked-by: Greg Kroah-Hartman
Re: [GIT PULL] of: overlay: validation checks, subsequent fixes for v20 -- correction: v4.20
On Mon, Feb 11, 2019 at 02:43:48PM -0600, Alan Tull wrote: > On Mon, Feb 11, 2019 at 1:13 PM Greg Kroah-Hartman > wrote: > > > > On Mon, Feb 11, 2019 at 12:41:40PM -0600, Alan Tull wrote: > > > On Fri, Nov 9, 2018 at 12:58 AM Frank Rowand > > > wrote: > > > > > > What LTSI's are these patches likely to end up in? Just to be clear, > > > I'm not pushing for any specific answer, I just want to know what to > > > expect. > > > > I have no idea what you are asking here. > > > > What patches? > > I probably should have asked my question *below* the pertinent context > of the the 17 patches listed in the pull request, which was: > > > of: overlay: add tests to validate kfrees from overlay removal > > of: overlay: add missing of_node_put() after add new node to changeset > > of: overlay: add missing of_node_get() in __of_attach_node_sysfs > > powerpc/pseries: add of_node_put() in dlpar_detach_node() > > of: overlay: use prop add changeset entry for property in new nodes > > of: overlay: do not duplicate properties from overlay for new nodes > > of: overlay: reorder fields in struct fragment > > of: overlay: validate overlay properties #address-cells and > > #size-cells > > of: overlay: make all pr_debug() and pr_err() messages unique > > of: overlay: test case of two fragments adding same node > > of: overlay: check prevents multiple fragments add or delete same node > > of: overlay: check prevents multiple fragments touching same property > > of: unittest: remove unused of_unittest_apply_overlay() argument > > of: overlay: set node fields from properties when add new overlay node > > of: unittest: allow base devicetree to have symbol metadata > > of: unittest: find overlays[] entry by name instead of index > > of: unittest: initialize args before calling of_*parse_*() > > > What is "LTSI's"? > > I have recently seen some of devicetree patches being picked up for > the 4.20 stable-queue. That seemed to suggest that some, but not all > of these will end up in the next LTS release. If the git commit has the "cc: stable@" marking in it, yes, it will be picked up. Without the actual git ids, it's hard to know what did, and what did not, get backported :) > Also I was wondering if any of this is likely to get backported to > LTSI-4.14. Note, "LTSI" and "LTS" are two different things. "LTSI" is a project run by some LF member companies, and "LTS" are the normal long term kernels that I release on kernel.org. They have vastly different requirements for inclusion in them. If you have questions about LTSI, I recommend go asking on their mailing list. As for showing up in the 4.14 "LTS" kernel, again, I need git commit ids to know for sure. Also, as these are now in Linus's tree, you should be able to look at the stable releases yourself to see if they are present there, right? thanks, greg k-h
[PATCH 10/14] mmc: mvsdio: handle highmem pages
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/mvsdio.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
index e22bbff89c8d..d04c78125a4d 100644
--- a/drivers/mmc/host/mvsdio.c
+++ b/drivers/mmc/host/mvsdio.c
@@ -42,7 +42,8 @@ struct mvsd_host {
unsigned int intr_en;
unsigned int ctrl;
unsigned int pio_size;
- void *pio_ptr;
+ struct scatterlist *pio_sg;
+ unsigned int pio_offset; /* offset in words into the segment */
unsigned int sg_frags;
unsigned int ns_per_clk;
unsigned int clock;
@@ -96,9 +97,9 @@ static int mvsd_setup_data(struct mvsd_host *host, struct
mmc_data *data)
if (tmout_index > MVSD_HOST_CTRL_TMOUT_MAX)
tmout_index = MVSD_HOST_CTRL_TMOUT_MAX;
- dev_dbg(host->dev, "data %s at 0x%08x: blocks=%d blksz=%d tmout=%u
(%d)\n",
+ dev_dbg(host->dev, "data %s at 0x%08llx: blocks=%d blksz=%d tmout=%u
(%d)\n",
(data->flags & MMC_DATA_READ) ? "read" : "write",
- (u32)sg_virt(data->sg), data->blocks, data->blksz,
+ (u64)sg_phys(data->sg), data->blocks, data->blksz,
tmout, tmout_index);
host->ctrl &= ~MVSD_HOST_CTRL_TMOUT_MASK;
@@ -118,10 +119,11 @@ static int mvsd_setup_data(struct mvsd_host *host, struct
mmc_data *data)
* boundary.
*/
host->pio_size = data->blocks * data->blksz;
- host->pio_ptr = sg_virt(data->sg);
+ host->pio_sg = data->sg;
+ host->pio_offset = data->sg->offset / 2;
if (!nodma)
- dev_dbg(host->dev, "fallback to PIO for data at 0x%p
size %d\n",
- host->pio_ptr, host->pio_size);
+ dev_dbg(host->dev, "fallback to PIO for data at 0x%x
size %d\n",
+ host->pio_offset, host->pio_size);
return 1;
} else {
dma_addr_t phys_addr;
@@ -291,8 +293,9 @@ static u32 mvsd_finish_data(struct mvsd_host *host, struct
mmc_data *data,
{
void __iomem *iobase = host->base;
- if (host->pio_ptr) {
- host->pio_ptr = NULL;
+ if (host->pio_sg) {
+ host->pio_sg = NULL;
+ host->pio_offset = 0;
host->pio_size = 0;
} else {
dma_unmap_sg(mmc_dev(host->mmc), data->sg, host->sg_frags,
@@ -376,8 +379,10 @@ static irqreturn_t mvsd_irq(int irq, void *dev)
if (host->pio_size &&
(intr_status & host->intr_en &
(MVSD_NOR_RX_READY | MVSD_NOR_RX_FIFO_8W))) {
- u16 *p = host->pio_ptr;
+ u16 *base = sg_kmap_atomic(host->pio_sg);
+ u16 *p = base + host->pio_offset;
int s = host->pio_size;
+
while (s >= 32 && (intr_status & MVSD_NOR_RX_FIFO_8W)) {
readsw(iobase + MVSD_FIFO, p, 16);
p += 16;
@@ -416,13 +421,15 @@ static irqreturn_t mvsd_irq(int irq, void *dev)
}
dev_dbg(host->dev, "pio %d intr 0x%04x hw_state 0x%04x\n",
s, intr_status, mvsd_read(MVSD_HW_STATE));
- host->pio_ptr = p;
+ host->pio_offset = p - base;
host->pio_size = s;
+ sg_kunmap_atomic(host->pio_sg, base);
irq_handled = 1;
} else if (host->pio_size &&
(intr_status & host->intr_en &
(MVSD_NOR_TX_AVAIL | MVSD_NOR_TX_FIFO_8W))) {
- u16 *p = host->pio_ptr;
+ u16 *base = sg_kmap_atomic(host->pio_sg);
+ u16 *p = base + host->pio_offset;
int s = host->pio_size;
/*
* The TX_FIFO_8W bit is unreliable. When set, bursting
@@ -453,8 +460,9 @@ static irqreturn_t mvsd_irq(int irq, void *dev)
}
dev_dbg(host->dev, "pio %d intr 0x%04x hw_state 0x%04x\n",
s, intr_status, mvsd_read(MVSD_HW_STATE));
- host->pio_ptr = p;
+ host->pio_offset = p - base;
host->pio_size = s;
+ sg_kunmap_atomic(host->pio_sg, base);
irq_handled = 1;
}
@@ -737,6 +745,7 @@ static int mvsd_probe(struct platform_device *pdev)
clk_prepare_enable(host->clk);
mmc->ops = _ops;
+ mmc->need_kmap = 1;
mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
--
2.20.1
[PATCH 03/14] mmc: add a need_kmap flag to struct mmc_host
If we want to get rid of the block layer bounce buffering for highmem we
need to ensure no segment spans multiple pages so that we can kmap it.
Add a flag to struct mmc_host so that we can handle the block and DMA
layer interactions in common code.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/core/queue.c | 13 +
include/linux/mmc/host.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index 35cc138b096d..71cd2411329e 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -370,6 +370,19 @@ static void mmc_setup_queue(struct mmc_queue *mq, struct
mmc_card *card)
blk_queue_max_segments(mq->queue, host->max_segs);
blk_queue_max_segment_size(mq->queue, host->max_seg_size);
+ /*
+* If the host requires kmapping for PIO we need to ensure
+* that no segment spans a page boundary.
+*/
+ if (host->need_kmap) {
+ unsigned int dma_boundary = host->max_seg_size - 1;
+
+ if (dma_boundary >= PAGE_SIZE)
+ dma_boundary = PAGE_SIZE - 1;
+ blk_queue_segment_boundary(mq->queue, dma_boundary);
+ dma_set_seg_boundary(mmc_dev(host), dma_boundary);
+ }
+
INIT_WORK(>recovery_work, mmc_mq_recovery_handler);
INIT_WORK(>complete_work, mmc_blk_mq_complete_work);
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 4eadf01b4a93..87f8a89d2f70 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -397,6 +397,7 @@ struct mmc_host {
unsigned intdoing_retune:1; /* re-tuning in progress */
unsigned intretune_now:1; /* do re-tuning at next req */
unsigned intretune_paused:1; /* re-tuning is temporarily
disabled */
+ unsigned intneed_kmap:1;/* only allow single page
segments */
int rescan_disable; /* disable card detection */
int rescan_entered; /* used with nonremovable
devices */
--
2.20.1
[PATCH 08/14] mmc: s3cmci: handle highmem pages
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/s3cmci.c | 107 +++---
drivers/mmc/host/s3cmci.h | 3 +-
2 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index 10f5219b3b40..989fefea19f1 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -317,26 +317,17 @@ static void s3cmci_check_sdio_irq(struct s3cmci_host
*host)
}
}
-static inline int get_data_buffer(struct s3cmci_host *host,
- u32 *bytes, u32 **pointer)
+static inline int get_data_buffer(struct s3cmci_host *host)
{
- struct scatterlist *sg;
-
- if (host->pio_active == XFER_NONE)
- return -EINVAL;
-
- if ((!host->mrq) || (!host->mrq->data))
- return -EINVAL;
-
if (host->pio_sgptr >= host->mrq->data->sg_len) {
dbg(host, dbg_debug, "no more buffers (%i/%i)\n",
host->pio_sgptr, host->mrq->data->sg_len);
return -EBUSY;
}
- sg = >mrq->data->sg[host->pio_sgptr];
+ host->cur_sg = >mrq->data->sg[host->pio_sgptr];
- *bytes = sg->length;
- *pointer = sg_virt(sg);
+ host->pio_bytes = host->cur_sg->length;
+ host->pio_offset = host->cur_sg->offset;
host->pio_sgptr++;
@@ -422,11 +413,16 @@ static void s3cmci_disable_irq(struct s3cmci_host *host,
bool transfer)
static void do_pio_read(struct s3cmci_host *host)
{
- int res;
u32 fifo;
u32 *ptr;
u32 fifo_words;
void __iomem *from_ptr;
+ void *buf;
+
+ if (host->pio_active == XFER_NONE)
+ goto done;
+ if (!host->mrq || !host->mrq->data)
+ goto done;
/* write real prescaler to host, it might be set slow to fix */
writel(host->prescaler, host->base + S3C2410_SDIPRE);
@@ -435,20 +431,12 @@ static void do_pio_read(struct s3cmci_host *host)
while ((fifo = fifo_count(host))) {
if (!host->pio_bytes) {
- res = get_data_buffer(host, >pio_bytes,
- >pio_ptr);
- if (res) {
- host->pio_active = XFER_NONE;
- host->complete_what = COMPLETION_FINALIZE;
-
- dbg(host, dbg_pio, "pio_read(): "
- "complete (no more data).\n");
- return;
- }
+ if (get_data_buffer(host) < 0)
+ goto done;
dbg(host, dbg_pio,
- "pio_read(): new target: [%i]@[%p]\n",
- host->pio_bytes, host->pio_ptr);
+ "pio_read(): new target: [%i]@[%zu]\n",
+ host->pio_bytes, host->pio_offset);
}
dbg(host, dbg_pio,
@@ -470,63 +458,65 @@ static void do_pio_read(struct s3cmci_host *host)
host->pio_count += fifo;
fifo_words = fifo >> 2;
- ptr = host->pio_ptr;
- while (fifo_words--)
+
+ buf = (sg_kmap_atomic(host->cur_sg) + host->pio_offset);
+ ptr = buf;
+ while (fifo_words--) {
*ptr++ = readl(from_ptr);
- host->pio_ptr = ptr;
+ host->pio_offset += 4;
+ }
if (fifo & 3) {
u32 n = fifo & 3;
u32 data = readl(from_ptr);
- u8 *p = (u8 *)host->pio_ptr;
+ u8 *p = (u8 *)ptr;
while (n--) {
*p++ = data;
data >>= 8;
+ host->pio_offset++;
}
}
+ sg_kunmap_atomic(host->cur_sg, buf);
}
if (!host->pio_bytes) {
- res = get_data_buffer(host, >pio_bytes, >pio_ptr);
- if (res) {
- dbg(host, dbg_pio,
- "pio_read(): complete (no more buffers).\n");
- host->pio_active = XFER_NONE;
- host->complete_what = COMPLETION_FINALIZE;
-
- return;
- }
+ if (get_data_buffer(host) < 0)
+ goto done;
}
enable_imask(host,
S3C2410_SDIIMSK_RXFIFOHALF | S3C2410_SDIIMSK_RXFIFOLAST);
+ return;
+
+done:
+ host->pio_active = XFER_NONE;
+ host->complete_what = COMPLETION_FINALIZE;
+
[PATCH 07/14] mmc: omap: handle chained sglists
Use the proper sg_next() helper to move to the next scatterlist element
to support chained scatterlists.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/omap.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 6741c95f2281..8cd39bc087fa 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -147,7 +147,7 @@ struct mmc_omap_host {
struct mmc_data *stop_data;
unsigned intsg_len;
- int sg_idx;
+ struct scatterlist *cur_sg;
u32 buffer_offset;
u32 buffer_bytes_left;
u32 total_bytes_left;
@@ -645,11 +645,8 @@ mmc_omap_cmd_timer(struct timer_list *t)
static void
mmc_omap_sg_to_buf(struct mmc_omap_host *host)
{
- struct scatterlist *sg;
-
- sg = host->data->sg + host->sg_idx;
- host->buffer_bytes_left = sg->length;
- host->buffer_offset = sg->offset;
+ host->buffer_bytes_left = host->cur_sg->length;
+ host->buffer_offset = host->cur_sg->offset;
if (host->buffer_bytes_left > host->total_bytes_left)
host->buffer_bytes_left = host->total_bytes_left;
}
@@ -666,13 +663,12 @@ mmc_omap_clk_timer(struct timer_list *t)
static void
mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
{
- struct scatterlist *sg = host->data->sg + host->sg_idx;
+ struct scatterlist *sg = host->cur_sg;
int n, nwords;
void *p;
if (host->buffer_bytes_left == 0) {
- host->sg_idx++;
- BUG_ON(host->sg_idx == host->sg_len);
+ host->cur_sg = sg_next(host->cur_sg);
mmc_omap_sg_to_buf(host);
}
n = 64;
@@ -984,7 +980,7 @@ mmc_omap_prepare_data(struct mmc_omap_host *host, struct
mmc_request *req)
}
}
- host->sg_idx = 0;
+ host->cur_sg = host->data->sg;
if (use_dma) {
enum dma_data_direction dma_data_dir;
struct dma_async_tx_descriptor *tx;
--
2.20.1
[PATCH 11/14] mmc: sh_mmcif: handle highmem pages
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/sh_mmcif.c | 59 +++--
1 file changed, 37 insertions(+), 22 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 81bd9afb0980..24c3f13bafdb 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -228,7 +228,7 @@ struct sh_mmcif_host {
bool dying;
long timeout;
void __iomem *addr;
- u32 *pio_ptr;
+ u32 pio_offset;
spinlock_t lock;/* protect sh_mmcif_host::state */
enum sh_mmcif_state state;
enum sh_mmcif_wait_for wait_for;
@@ -595,7 +595,7 @@ static int sh_mmcif_error_manage(struct sh_mmcif_host *host)
return ret;
}
-static bool sh_mmcif_next_block(struct sh_mmcif_host *host, u32 *p)
+static bool sh_mmcif_next_block(struct sh_mmcif_host *host)
{
struct mmc_data *data = host->mrq->data;
@@ -606,10 +606,10 @@ static bool sh_mmcif_next_block(struct sh_mmcif_host
*host, u32 *p)
if (host->sg_blkidx == data->sg->length) {
host->sg_blkidx = 0;
- if (++host->sg_idx < data->sg_len)
- host->pio_ptr = sg_virt(++data->sg);
- } else {
- host->pio_ptr = p;
+ if (++host->sg_idx < data->sg_len) {
+ data->sg++;
+ host->pio_offset = data->sg->offset / 4;
+ }
}
return host->sg_idx != data->sg_len;
@@ -631,8 +631,8 @@ static bool sh_mmcif_read_block(struct sh_mmcif_host *host)
{
struct device *dev = sh_mmcif_host_to_dev(host);
struct mmc_data *data = host->mrq->data;
- u32 *p = sg_virt(data->sg);
- int i;
+ u32 *p;
+ int off, i;
if (host->sd_error) {
data->error = sh_mmcif_error_manage(host);
@@ -640,8 +640,11 @@ static bool sh_mmcif_read_block(struct sh_mmcif_host *host)
return false;
}
+ p = sg_kmap_atomic(data->sg);
+ off = data->sg->offset / 4;
for (i = 0; i < host->blocksize / 4; i++)
- *p++ = sh_mmcif_readl(host->addr, MMCIF_CE_DATA);
+ p[off++] = sh_mmcif_readl(host->addr, MMCIF_CE_DATA);
+ sg_kunmap_atomic(data->sg, p);
/* buffer read end */
sh_mmcif_bitset(host, MMCIF_CE_INT_MASK, MASK_MBUFRE);
@@ -664,7 +667,7 @@ static void sh_mmcif_multi_read(struct sh_mmcif_host *host,
host->wait_for = MMCIF_WAIT_FOR_MREAD;
host->sg_idx = 0;
host->sg_blkidx = 0;
- host->pio_ptr = sg_virt(data->sg);
+ host->pio_offset = data->sg->offset / 4;
sh_mmcif_bitset(host, MMCIF_CE_INT_MASK, MASK_MBUFREN);
}
@@ -673,7 +676,7 @@ static bool sh_mmcif_mread_block(struct sh_mmcif_host *host)
{
struct device *dev = sh_mmcif_host_to_dev(host);
struct mmc_data *data = host->mrq->data;
- u32 *p = host->pio_ptr;
+ u32 *p;
int i;
if (host->sd_error) {
@@ -684,10 +687,14 @@ static bool sh_mmcif_mread_block(struct sh_mmcif_host
*host)
BUG_ON(!data->sg->length);
- for (i = 0; i < host->blocksize / 4; i++)
- *p++ = sh_mmcif_readl(host->addr, MMCIF_CE_DATA);
+ p = sg_kmap_atomic(data->sg);
+ for (i = 0; i < host->blocksize / 4; i++) {
+ p[host->pio_offset++] =
+ sh_mmcif_readl(host->addr, MMCIF_CE_DATA);
+ }
+ sg_kunmap_atomic(data->sg, p);
- if (!sh_mmcif_next_block(host, p))
+ if (!sh_mmcif_next_block(host))
return false;
sh_mmcif_bitset(host, MMCIF_CE_INT_MASK, MASK_MBUFREN);
@@ -711,8 +718,8 @@ static bool sh_mmcif_write_block(struct sh_mmcif_host *host)
{
struct device *dev = sh_mmcif_host_to_dev(host);
struct mmc_data *data = host->mrq->data;
- u32 *p = sg_virt(data->sg);
- int i;
+ u32 *p;
+ int off, i;
if (host->sd_error) {
data->error = sh_mmcif_error_manage(host);
@@ -720,8 +727,11 @@ static bool sh_mmcif_write_block(struct sh_mmcif_host
*host)
return false;
}
+ p = sg_kmap_atomic(data->sg);
+ off = data->sg->offset / 4;
for (i = 0; i < host->blocksize / 4; i++)
- sh_mmcif_writel(host->addr, MMCIF_CE_DATA, *p++);
+ sh_mmcif_writel(host->addr, MMCIF_CE_DATA, p[off++]);
+ sg_kunmap_atomic(data->sg, p);
/* buffer write end */
sh_mmcif_bitset(host, MMCIF_CE_INT_MASK, MASK_MDTRANE);
@@ -744,7 +754,7 @@ static void sh_mmcif_multi_write(struct sh_mmcif_host *host,
host->wait_for = MMCIF_WAIT_FOR_MWRITE;
host->sg_idx = 0;
host->sg_blkidx = 0;
- host->pio_ptr = sg_virt(data->sg);
+
[PATCH 13/14] mmc: core: don't use block layer bounce buffers
All MMC and SD host drivers are highmem safe now, and bounce buffering
for addressing limitations is handled in the DMA layer now.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/core/queue.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index 71cd2411329e..1c92a2a4d641 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -354,17 +354,12 @@ static const struct blk_mq_ops mmc_mq_ops = {
static void mmc_setup_queue(struct mmc_queue *mq, struct mmc_card *card)
{
struct mmc_host *host = card->host;
- u64 limit = BLK_BOUNCE_HIGH;
-
- if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask)
- limit = (u64)dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT;
blk_queue_flag_set(QUEUE_FLAG_NONROT, mq->queue);
blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, mq->queue);
if (mmc_can_erase(card))
mmc_queue_setup_discard(mq->queue, card);
- blk_queue_bounce_limit(mq->queue, limit);
blk_queue_max_hw_sectors(mq->queue,
min(host->max_blk_count, host->max_req_size / 512));
blk_queue_max_segments(mq->queue, host->max_segs);
--
2.20.1
[PATCH 06/14] mmc: omap: handle highmem pages
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/omap.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index c60a7625b1fa..6741c95f2281 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -148,7 +148,7 @@ struct mmc_omap_host {
unsigned intsg_len;
int sg_idx;
- u16 * buffer;
+ u32 buffer_offset;
u32 buffer_bytes_left;
u32 total_bytes_left;
@@ -649,7 +649,7 @@ mmc_omap_sg_to_buf(struct mmc_omap_host *host)
sg = host->data->sg + host->sg_idx;
host->buffer_bytes_left = sg->length;
- host->buffer = sg_virt(sg);
+ host->buffer_offset = sg->offset;
if (host->buffer_bytes_left > host->total_bytes_left)
host->buffer_bytes_left = host->total_bytes_left;
}
@@ -666,7 +666,9 @@ mmc_omap_clk_timer(struct timer_list *t)
static void
mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
{
+ struct scatterlist *sg = host->data->sg + host->sg_idx;
int n, nwords;
+ void *p;
if (host->buffer_bytes_left == 0) {
host->sg_idx++;
@@ -684,15 +686,17 @@ mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
host->total_bytes_left -= n;
host->data->bytes_xfered += n;
+ p = sg_kmap_atomic(sg);
if (write) {
__raw_writesw(host->virt_base + OMAP_MMC_REG(host, DATA),
- host->buffer, nwords);
+ p + host->buffer_offset, nwords);
} else {
__raw_readsw(host->virt_base + OMAP_MMC_REG(host, DATA),
-host->buffer, nwords);
+p + host->buffer_offset, nwords);
}
+ sg_kunmap_atomic(sg, p);
- host->buffer += nwords;
+ host->buffer_offset += nwords;
}
#ifdef CONFIG_MMC_DEBUG
@@ -1250,6 +1254,7 @@ static int mmc_omap_new_slot(struct mmc_omap_host *host,
int id)
mmc->caps |= MMC_CAP_4_BIT_DATA | MMC_CAP_ERASE;
mmc->ops = _omap_ops;
+ mmc->need_kmap = 1;
mmc->f_min = 40;
if (mmc_omap2())
--
2.20.1
remove block layer bounce buffering for MMC v2
Hi everyone, this series converts the remaining MMC host drivers to properly kmap the scatterlist entries it does PIO operations on, and then goes on to remove the usage of block layer bounce buffering (which I plan to remove eventually) from the MMC layer. As a bonus I've converted various drivers to the proper scatterlist helpers so that at least in theory they are ready for chained scatterlists. All the changes are compile tested only as I don't have any of the hardware, so a careful review would be appreciated. Changes since v1: - fix a missing kunmap_atomic in mvsdio - fix a stray whitespace in s3cmci - add new sg_kmap_atomic and sg_kunmap_atomic helpers - set the DMA and block layer dma boundary - use pointer arithmetics to reduce the amount of changes in various drivers
[PATCH 04/14] mmc: davinci: handle highmem pages
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/davinci_mmc.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 9e68c3645e22..6a16d7a1d5bc 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -194,11 +194,12 @@ struct mmc_davinci_host {
#define DAVINCI_MMC_DATADIR_WRITE 2
unsigned char data_dir;
- /* buffer is used during PIO of one scatterlist segment, and
-* is updated along with buffer_bytes_left. bytes_left applies
-* to all N blocks of the PIO transfer.
+ /*
+* buffer_offset is used during PIO of one scatterlist segment, and is
+* updated along with buffer_bytes_left. bytes_left applies to all N
+* blocks of the PIO transfer.
*/
- u8 *buffer;
+ u32 buffer_offset;
u32 buffer_bytes_left;
u32 bytes_left;
@@ -229,8 +230,8 @@ static irqreturn_t mmc_davinci_irq(int irq, void *dev_id);
/* PIO only */
static void mmc_davinci_sg_to_buf(struct mmc_davinci_host *host)
{
+ host->buffer_offset = host->sg->offset;
host->buffer_bytes_left = sg_dma_len(host->sg);
- host->buffer = sg_virt(host->sg);
if (host->buffer_bytes_left > host->bytes_left)
host->buffer_bytes_left = host->bytes_left;
}
@@ -238,7 +239,7 @@ static void mmc_davinci_sg_to_buf(struct mmc_davinci_host
*host)
static void davinci_fifo_data_trans(struct mmc_davinci_host *host,
unsigned int n)
{
- u8 *p;
+ u8 *p, *base;
unsigned int i;
if (host->buffer_bytes_left == 0) {
@@ -246,7 +247,8 @@ static void davinci_fifo_data_trans(struct mmc_davinci_host
*host,
mmc_davinci_sg_to_buf(host);
}
- p = host->buffer;
+ base = sg_kmap_atomic(host->sg);
+ p = base + host->buffer_offset;
if (n > host->buffer_bytes_left)
n = host->buffer_bytes_left;
host->buffer_bytes_left -= n;
@@ -275,7 +277,8 @@ static void davinci_fifo_data_trans(struct mmc_davinci_host
*host,
p = p + (n & 3);
}
}
- host->buffer = p;
+ host->buffer_offset = p - base;
+ sg_kunmap_atomic(host->sg, base);
}
static void mmc_davinci_start_command(struct mmc_davinci_host *host,
@@ -572,7 +575,7 @@ mmc_davinci_prepare_data(struct mmc_davinci_host *host,
struct mmc_request *req)
host->base + DAVINCI_MMCFIFOCTL);
}
- host->buffer = NULL;
+ host->buffer_offset = 0;
host->bytes_left = data->blocks * data->blksz;
/* For now we try to use DMA whenever we won't need partial FIFO
@@ -1291,6 +1294,7 @@ static int davinci_mmcsd_probe(struct platform_device
*pdev)
mmc->ops = _davinci_ops;
mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
+ mmc->need_kmap = 1;
/* With no iommu coalescing pages, each phys_seg is a hw_seg.
* Each hw_seg uses one EDMA parameter RAM slot, always one
--
2.20.1
[PATCH 14/14] dma-mapping: remove dma_max_pfn
These days the DMA mapping code must bounce buffer for any not supported
address, and if they driver needs to optimize for natively supported
ranged it should use dma_get_required_mask.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-mapping.h | 7 ---
include/linux/dma-mapping.h| 7 ---
2 files changed, 14 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index 31d3b96f0f4b..496b36b9a7ff 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -89,13 +89,6 @@ static inline dma_addr_t virt_to_dma(struct device *dev,
void *addr)
}
#endif
-/* The ARM override for dma_max_pfn() */
-static inline unsigned long dma_max_pfn(struct device *dev)
-{
- return dma_to_pfn(dev, *dev->dma_mask);
-}
-#define dma_max_pfn(dev) dma_max_pfn(dev)
-
#define arch_setup_dma_ops arch_setup_dma_ops
extern void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
const struct iommu_ops *iommu, bool coherent);
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f6ded992c183..c6dbc287e466 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -710,13 +710,6 @@ static inline int dma_set_seg_boundary(struct device *dev,
unsigned long mask)
return -EIO;
}
-#ifndef dma_max_pfn
-static inline unsigned long dma_max_pfn(struct device *dev)
-{
- return (*dev->dma_mask >> PAGE_SHIFT) + dev->dma_pfn_offset;
-}
-#endif
-
static inline int dma_get_cache_alignment(void)
{
#ifdef ARCH_DMA_MINALIGN
--
2.20.1
[PATCH 12/14] mmc: sh_mmcif: handle chained sglists
Use the proper sg_next() helper to move to the next scatterlist element
to support chained scatterlists.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/sh_mmcif.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 24c3f13bafdb..9e59dbe6ef30 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -234,7 +234,6 @@ struct sh_mmcif_host {
enum sh_mmcif_wait_for wait_for;
struct delayed_work timeout_work;
size_t blocksize;
- int sg_idx;
int sg_blkidx;
bool power;
bool ccs_enable;/* Command Completion Signal support */
@@ -606,13 +605,13 @@ static bool sh_mmcif_next_block(struct sh_mmcif_host
*host)
if (host->sg_blkidx == data->sg->length) {
host->sg_blkidx = 0;
- if (++host->sg_idx < data->sg_len) {
- data->sg++;
- host->pio_offset = data->sg->offset / 4;
- }
+ data->sg = sg_next(data->sg);
+ if (!data->sg)
+ return false;
+ host->pio_offset = data->sg->offset / 4;
}
- return host->sg_idx != data->sg_len;
+ return true;
}
static void sh_mmcif_single_read(struct sh_mmcif_host *host,
@@ -665,7 +664,6 @@ static void sh_mmcif_multi_read(struct sh_mmcif_host *host,
BLOCK_SIZE_MASK;
host->wait_for = MMCIF_WAIT_FOR_MREAD;
- host->sg_idx = 0;
host->sg_blkidx = 0;
host->pio_offset = data->sg->offset / 4;
@@ -752,7 +750,6 @@ static void sh_mmcif_multi_write(struct sh_mmcif_host *host,
BLOCK_SIZE_MASK;
host->wait_for = MMCIF_WAIT_FOR_MWRITE;
- host->sg_idx = 0;
host->sg_blkidx = 0;
host->pio_offset = data->sg->offset / 4;
--
2.20.1
[PATCH 05/14] mmc: moxart: handle highmem pages
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do a kmap for the page while
doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/moxart-mmc.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/moxart-mmc.c b/drivers/mmc/host/moxart-mmc.c
index a0670e9cd012..116964e6506d 100644
--- a/drivers/mmc/host/moxart-mmc.c
+++ b/drivers/mmc/host/moxart-mmc.c
@@ -311,7 +311,7 @@ static void moxart_transfer_pio(struct moxart_host *host)
if (host->data_len == data->bytes_xfered)
return;
- sgp = sg_virt(host->cur_sg);
+ sgp = kmap(sg_page(host->cur_sg)) + host->cur_sg->offset;
remain = host->data_remain;
if (data->flags & MMC_DATA_WRITE) {
@@ -319,8 +319,7 @@ static void moxart_transfer_pio(struct moxart_host *host)
if (moxart_wait_for_status(host, FIFO_URUN, )
== -ETIMEDOUT) {
data->error = -ETIMEDOUT;
- complete(>pio_complete);
- return;
+ goto done;
}
for (len = 0; len < remain && len < host->fifo_width;) {
iowrite32(*sgp, host->base + REG_DATA_WINDOW);
@@ -335,8 +334,7 @@ static void moxart_transfer_pio(struct moxart_host *host)
if (moxart_wait_for_status(host, FIFO_ORUN, )
== -ETIMEDOUT) {
data->error = -ETIMEDOUT;
- complete(>pio_complete);
- return;
+ goto done;
}
for (len = 0; len < remain && len < host->fifo_width;) {
/* SCR data must be read in big endian. */
@@ -356,10 +354,15 @@ static void moxart_transfer_pio(struct moxart_host *host)
data->bytes_xfered += host->data_remain - remain;
host->data_remain = remain;
- if (host->data_len != data->bytes_xfered)
+ if (host->data_len != data->bytes_xfered) {
+ kunmap(sg_page(host->cur_sg));
moxart_next_sg(host);
- else
- complete(>pio_complete);
+ return;
+ }
+
+done:
+ kunmap(sg_page(host->cur_sg));
+ complete(>pio_complete);
}
static void moxart_prepare_data(struct moxart_host *host)
@@ -614,6 +617,7 @@ static int moxart_probe(struct platform_device *pdev)
spin_lock_init(>lock);
mmc->ops = _ops;
+ mmc->need_kmap = 1;
mmc->f_max = DIV_ROUND_CLOSEST(host->sysclk, 2);
mmc->f_min = DIV_ROUND_CLOSEST(host->sysclk, CLK_DIV_MASK * 2);
mmc->ocr_avail = 0x00; /* Support 2.0v - 3.6v power. */
--
2.20.1
[PATCH 09/14] mmc: s3cmci: handle chained sglists
Use the proper sg_next() helper to move to the next scatterlist element
to support chained scatterlists.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/s3cmci.c | 19 +--
drivers/mmc/host/s3cmci.h | 2 +-
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index 989fefea19f1..df7c27f78abf 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -319,20 +319,19 @@ static void s3cmci_check_sdio_irq(struct s3cmci_host
*host)
static inline int get_data_buffer(struct s3cmci_host *host)
{
- if (host->pio_sgptr >= host->mrq->data->sg_len) {
- dbg(host, dbg_debug, "no more buffers (%i/%i)\n",
- host->pio_sgptr, host->mrq->data->sg_len);
+ if (!host->next_sg) {
+ dbg(host, dbg_debug, "no more buffers (%i)\n",
+ host->mrq->data->sg_len);
return -EBUSY;
}
- host->cur_sg = >mrq->data->sg[host->pio_sgptr];
+ host->cur_sg = host->next_sg;
+ host->next_sg = sg_next(host->next_sg);
host->pio_bytes = host->cur_sg->length;
host->pio_offset = host->cur_sg->offset;
- host->pio_sgptr++;
-
- dbg(host, dbg_sg, "new buffer (%i/%i)\n",
- host->pio_sgptr, host->mrq->data->sg_len);
+ dbg(host, dbg_sg, "new buffer (%i)\n",
+ host->mrq->data->sg_len);
return 0;
}
@@ -1051,8 +1050,8 @@ static int s3cmci_prepare_pio(struct s3cmci_host *host,
struct mmc_data *data)
BUG_ON((data->flags & BOTH_DIR) == BOTH_DIR);
- host->pio_sgptr = 0;
- host->cur_sg = >mrq->data->sg[host->pio_sgptr];
+ host->cur_sg = host->mrq->data->sg;
+ host->next_sg = sg_next(host->cur_sg);
host->pio_bytes = 0;
host->pio_count = 0;
host->pio_active = rw ? XFER_WRITE : XFER_READ;
diff --git a/drivers/mmc/host/s3cmci.h b/drivers/mmc/host/s3cmci.h
index 4320f7d832dc..caf1078d07d1 100644
--- a/drivers/mmc/host/s3cmci.h
+++ b/drivers/mmc/host/s3cmci.h
@@ -51,7 +51,7 @@ struct s3cmci_host {
int dma_complete;
struct scatterlist *cur_sg;
- u32 pio_sgptr;
+ struct scatterlist *next_sg;
u32 pio_bytes;
u32 pio_count;
u32 pio_offset;
--
2.20.1
[PATCH 01/14] scatterlist: add sg_kmap_atomic / sg_kunmap_atomic helpers
This avoids bug prone open coding of the sg offset handling and
also helps to document the limitations of mapping scatterlist
entries.
Signed-off-by: Christoph Hellwig
---
include/linux/scatterlist.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index b96f0d0b5b8f..524cd8448a48 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -2,6 +2,7 @@
#ifndef _LINUX_SCATTERLIST_H
#define _LINUX_SCATTERLIST_H
+#include
#include
#include
#include
@@ -239,6 +240,31 @@ static inline void *sg_virt(struct scatterlist *sg)
return page_address(sg_page(sg)) + sg->offset;
}
+/**
+ * sg_kmap_atomic - map a S/G list entry to a kernel address
+ * @sg:scatterlist entry
+ *
+ * Return a kernel address for scatterlist entry by kmapping it. Note that
+ * this function must only be called on scatterlist entries that do not span
+ * multiple pages.
+ */
+static inline void *sg_kmap_atomic(struct scatterlist *sg)
+{
+ if (WARN_ON_ONCE(sg->offset + sg->length > PAGE_SIZE))
+ return NULL;
+ return kmap_atomic(sg_page(sg)) + sg->offset;
+}
+
+/**
+ * sg_kunmap_atomic - unmap a S/G list entry to a kernel address
+ * @sg:scatterlist entry
+ * @ptr: address returned from sg_kmap_atomic
+ */
+static inline void sg_kunmap_atomic(struct scatterlist *sg, void *ptr)
+{
+ kunmap_atomic(ptr - sg->offset);
+}
+
/**
* sg_init_marker - Initialize markers in sg table
* @sgl: The SG table
--
2.20.1
[PATCH 02/14] mmc: remove the unused use_blk_mq field from struct mmc_host
Signed-off-by: Christoph Hellwig
---
include/linux/mmc/host.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 4d35ff36ceff..4eadf01b4a93 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -397,7 +397,6 @@ struct mmc_host {
unsigned intdoing_retune:1; /* re-tuning in progress */
unsigned intretune_now:1; /* do re-tuning at next req */
unsigned intretune_paused:1; /* re-tuning is temporarily
disabled */
- unsigned intuse_blk_mq:1; /* use blk-mq */
int rescan_disable; /* disable card detection */
int rescan_entered; /* used with nonremovable
devices */
--
2.20.1
Re: [PATCH] efi/libstub: refactor cmd_stubcopy
On Tue, 12 Feb 2019 at 04:45, Masahiro Yamada
wrote:
>
> It took me a while to understand what is going on in the nested
> if-blocks.
>
> Simplify it by removing unneeded code.
>
> - if_changed automatically adds 'set -e', so any failure in the
> series of commands makes it immediately fail as a whole.
> So, the outer if block is entirely redundant.
>
> - Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special
> target"), GNU Make automatically deletes the target on any failure
> in its recipe. The explicit 'rm -f $@' is redundant.
>
> - surrounding commands with ( ) will spawn a subshell to execute them
> in it, but it is rarely useful to do so.
>
> Signed-off-by: Masahiro Yamada
Assuming that it still works as expected:
Acked-by: Ard Biesheuvel
You can test this by adding a statically initialized global function
pointer to any of the libstub source files that get built for ARM.
Thanks!
> ---
>
> drivers/firmware/efi/libstub/Makefile | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/Makefile
> b/drivers/firmware/efi/libstub/Makefile
> index d984509..7788e8a 100644
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -86,12 +86,13 @@ $(obj)/%.stub.o: $(obj)/%.o FORCE
> # this time, use objcopy and leave all sections in place.
> #
> quiet_cmd_stubcopy = STUBCPY $@
> - cmd_stubcopy = if $(STRIP) --strip-debug $(STUBCOPY_RM-y) -o $@ $<; \
> -then if $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y); \
> -then (echo >&2 "$@: absolute symbol references not
> allowed in the EFI stub"; \
> - rm -f $@; /bin/false); \
> -else $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@; fi\
> -else /bin/false; fi
> + cmd_stubcopy = \
> + $(STRIP) --strip-debug $(STUBCOPY_RM-y) -o $@ $<; \
> + if $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y); then\
> + echo "$@: absolute symbol references not allowed in the EFI
> stub" >&2; \
> + /bin/false; \
> + fi; \
> + $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@
>
> #
> # ARM discards the .data section because it disallows r/w data in the
> --
> 2.7.4
>
Re: [RFC PATCH v4 01/12] __wr_after_init: Core and default arch
On 12/02/2019 04:39, Matthew Wilcox wrote:
On Tue, Feb 12, 2019 at 01:27:38AM +0200, Igor Stoppa wrote:
+#ifndef CONFIG_PRMEM
[...]
+#else
+
+#include
It's a mistake to do conditional includes like this. That way you see
include loops with some configs and not others. Our headers are already
so messy, better to just include mm.h unconditionally.
ok
Can I still do the following, in prmem.c ?
#ifdef CONFIG_ARCH_HAS_PRMEM_HEADER
+#include
+#else
+
+struct wr_state {
+ struct mm_struct *prev;
+};
+
+#endif
It's still a conditional include, but it's in a C file, it shouldn't
cause any chance of loops.
The alternative is that each arch supporting prmem must have a
(probably) empty asm/prmem.h header.
I did some reasearch about telling the compiler to include a header only
if it exists, but it doesn't seem to be a gcc feature.
--
igor
[PATCH v2 09/10] mtd: rawnand: denali: remove DENALI_NR_BANKS macro
Use the runtime-detected denali->nbanks instead of hard-coded
DENALI_NR_BANKS (=4).
The actual number of banks depends on the IP configuration, and
can be less than DENALI_NR_BANKS. It is pointless to touch
registers of unsupported banks.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index a162bd1..eb58136 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -40,7 +40,6 @@
#define DENALI_BANK(denali)((denali)->active_bank << 24)
#define DENALI_INVALID_BANK-1
-#define DENALI_NR_BANKS4
static struct denali_chip *to_denali_chip(struct nand_chip *chip)
{
@@ -92,7 +91,7 @@ static void denali_enable_irq(struct denali_controller
*denali)
{
int i;
- for (i = 0; i < DENALI_NR_BANKS; i++)
+ for (i = 0; i < denali->nbanks; i++)
iowrite32(U32_MAX, denali->reg + INTR_EN(i));
iowrite32(GLOBAL_INT_EN_FLAG, denali->reg + GLOBAL_INT_ENABLE);
}
@@ -101,7 +100,7 @@ static void denali_disable_irq(struct denali_controller
*denali)
{
int i;
- for (i = 0; i < DENALI_NR_BANKS; i++)
+ for (i = 0; i < denali->nbanks; i++)
iowrite32(0, denali->reg + INTR_EN(i));
iowrite32(0, denali->reg + GLOBAL_INT_ENABLE);
}
@@ -117,7 +116,7 @@ static void denali_clear_irq_all(struct denali_controller
*denali)
{
int i;
- for (i = 0; i < DENALI_NR_BANKS; i++)
+ for (i = 0; i < denali->nbanks; i++)
denali_clear_irq(denali, i, U32_MAX);
}
@@ -130,7 +129,7 @@ static irqreturn_t denali_isr(int irq, void *dev_id)
spin_lock(>irq_lock);
- for (i = 0; i < DENALI_NR_BANKS; i++) {
+ for (i = 0; i < denali->nbanks; i++) {
irq_status = ioread32(denali->reg + INTR_STATUS(i));
if (irq_status)
ret = IRQ_HANDLED;
--
2.7.4
[PATCH v2 02/10] mtd: rawnand: denali: refactor syndrome layout handling for raw access
The Denali IP adopts the syndrome page layout (payload and ECC are
interleaved). The *_page_raw() and *_oob() callbacks are complicated
because they must hide the underlying layout used by the hardware,
and always return contiguous in-band and out-of-band data.
Currently, similar code is duplicated to reorganize the data layout.
For example, denali_read_page_raw() and denali_write_page_raw() look
almost the same.
The idea for refactoring is to split the code into two parts:
[1] conversion of page layout
[2] what to do at every ECC chunk boundary
For [1], I wrote denali_raw_payload_op() and denali_raw_oob_op().
They manipulate data for the Denali controller's specific page layout
of in-band, out-of-band, respectively.
The difference between write and read is just the operation at
ECC chunk boundaries. For example, denali_read_oob() calls
nand_change_read_column_op(), whereas denali_write_oob() calls
nand_change_write_column_op(). So, I implemented [2] as a callback
passed into [1].
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 354 +++---
1 file changed, 163 insertions(+), 191 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 4ac1314..9287f4f 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -608,159 +608,210 @@ static int denali_data_xfer(struct nand_chip *chip,
void *buf, size_t size,
return denali_pio_xfer(denali, buf, size, page, write);
}
-static void denali_oob_xfer(struct mtd_info *mtd, struct nand_chip *chip,
- int page, int write)
+typedef int denali_change_column_callback(void *buf, unsigned int offset,
+ unsigned int len, void *priv);
+
+static int denali_raw_payload_op(struct nand_chip *chip, void *buf,
+denali_change_column_callback *cb, void *priv)
{
- struct denali_nand_info *denali = mtd_to_denali(mtd);
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_ecc_ctrl *ecc = >ecc;
+ int writesize = mtd->writesize;
+ int oob_skip = denali->oob_skip_bytes;
+ int ret, i, pos, len;
+
+ for (i = 0; i < ecc->steps; i++) {
+ pos = i * (ecc->size + ecc->bytes);
+ len = ecc->size;
+
+ if (pos >= writesize) {
+ pos += oob_skip;
+ } else if (pos + len > writesize) {
+ /* This chunk overwraps the BBM area. Must be split */
+ ret = cb(buf, pos, writesize - pos, priv);
+ if (ret)
+ return ret;
+
+ buf += writesize - pos;
+ len -= writesize - pos;
+ pos = writesize + oob_skip;
+ }
+
+ ret = cb(buf, pos, len, priv);
+ if (ret)
+ return ret;
+
+ buf += len;
+ }
+
+ return 0;
+}
+
+static int denali_raw_oob_op(struct nand_chip *chip, void *buf,
+denali_change_column_callback *cb, void *priv)
+{
+ struct denali_nand_info *denali = to_denali(chip);
+ struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_ecc_ctrl *ecc = >ecc;
int writesize = mtd->writesize;
int oobsize = mtd->oobsize;
- uint8_t *bufpoi = chip->oob_poi;
- int ecc_steps = chip->ecc.steps;
- int ecc_size = chip->ecc.size;
- int ecc_bytes = chip->ecc.bytes;
int oob_skip = denali->oob_skip_bytes;
- size_t size = writesize + oobsize;
- int i, pos, len;
+ int ret, i, pos, len;
/* BBM at the beginning of the OOB area */
- if (write)
- nand_prog_page_begin_op(chip, page, writesize, bufpoi,
- oob_skip);
- else
- nand_read_page_op(chip, page, writesize, bufpoi, oob_skip);
- bufpoi += oob_skip;
+ ret = cb(buf, writesize, oob_skip, priv);
+ if (ret)
+ return ret;
- /* OOB ECC */
- for (i = 0; i < ecc_steps; i++) {
- pos = ecc_size + i * (ecc_size + ecc_bytes);
- len = ecc_bytes;
+ buf += oob_skip;
- if (pos >= writesize)
- pos += oob_skip;
- else if (pos + len > writesize)
- len = writesize - pos;
+ for (i = 0; i < ecc->steps; i++) {
+ pos = ecc->size + i * (ecc->size + ecc->bytes);
- if (write)
- nand_change_write_column_op(chip, pos, bufpoi, len,
- false);
+ if (i == ecc->steps - 1)
+ /* The last chunk includes OOB free */
+ len =
[PATCH v2 06/10] mtd: rawnand: denali: use bool type instead of int where appropriate
Use 'bool' type for the following boolean parameters.
- write (write or read?)
- raw (raw access or not?)
- dma_avail (DMA engine available or not?)
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Use bool for dma_avail as well
drivers/mtd/nand/raw/denali.c | 27 ++-
drivers/mtd/nand/raw/denali.h | 4 ++--
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 7050b1f..f539731 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -360,7 +360,7 @@ static int denali_sw_ecc_fixup(struct nand_chip *chip,
}
static void denali_setup_dma64(struct denali_nand_info *denali,
- dma_addr_t dma_addr, int page, int write)
+ dma_addr_t dma_addr, int page, bool write)
{
uint32_t mode;
const int page_count = 1;
@@ -374,7 +374,8 @@ static void denali_setup_dma64(struct denali_nand_info
*denali,
*burst len = 64 bytes, the number of pages
*/
denali->host_write(denali, mode,
- 0x01002000 | (64 << 16) | (write << 8) | page_count);
+ 0x01002000 | (64 << 16) |
+ (write ? BIT(8) : 0) | page_count);
/* 2. set memory low address */
denali->host_write(denali, mode, lower_32_bits(dma_addr));
@@ -384,7 +385,7 @@ static void denali_setup_dma64(struct denali_nand_info
*denali,
}
static void denali_setup_dma32(struct denali_nand_info *denali,
- dma_addr_t dma_addr, int page, int write)
+ dma_addr_t dma_addr, int page, bool write)
{
uint32_t mode;
const int page_count = 1;
@@ -395,7 +396,7 @@ static void denali_setup_dma32(struct denali_nand_info
*denali,
/* 1. setup transfer type and # of pages */
denali->host_write(denali, mode | page,
- 0x2000 | (write << 8) | page_count);
+ 0x2000 | (write ? BIT(8) : 0) | page_count);
/* 2. set memory high address bits 23:8 */
denali->host_write(denali, mode | ((dma_addr >> 16) << 8), 0x2200);
@@ -457,7 +458,7 @@ static int denali_pio_write(struct denali_nand_info
*denali, const u32 *buf,
}
static int denali_pio_xfer(struct denali_nand_info *denali, void *buf,
- size_t size, int page, int write)
+ size_t size, int page, bool write)
{
if (write)
return denali_pio_write(denali, buf, size, page);
@@ -466,7 +467,7 @@ static int denali_pio_xfer(struct denali_nand_info *denali,
void *buf,
}
static int denali_dma_xfer(struct denali_nand_info *denali, void *buf,
- size_t size, int page, int write)
+ size_t size, int page, bool write)
{
dma_addr_t dma_addr;
uint32_t irq_mask, irq_status, ecc_err_mask;
@@ -523,7 +524,7 @@ static int denali_dma_xfer(struct denali_nand_info *denali,
void *buf,
}
static int denali_data_xfer(struct nand_chip *chip, void *buf, size_t size,
- int page, int raw, int write)
+ int page, bool raw, bool write)
{
struct denali_nand_info *denali = to_denali(chip);
@@ -648,7 +649,7 @@ static int denali_read_page_raw(struct nand_chip *chip,
uint8_t *buf,
if (!buf)
return -EINVAL;
- ret = denali_data_xfer(chip, tmp_buf, size, page, 1, 0);
+ ret = denali_data_xfer(chip, tmp_buf, size, page, true, false);
if (ret)
return ret;
@@ -704,7 +705,7 @@ static int denali_write_page_raw(struct nand_chip *chip,
const uint8_t *buf,
return ret;
}
- return denali_data_xfer(chip, tmp_buf, size, page, 1, 1);
+ return denali_data_xfer(chip, tmp_buf, size, page, true, true);
}
static int denali_change_read_column_op(void *buf, unsigned int offset,
@@ -756,7 +757,7 @@ static int denali_read_page(struct nand_chip *chip, uint8_t
*buf,
int stat = 0;
int ret;
- ret = denali_data_xfer(chip, buf, mtd->writesize, page, 0, 0);
+ ret = denali_data_xfer(chip, buf, mtd->writesize, page, false, false);
if (ret && ret != -EBADMSG)
return ret;
@@ -786,7 +787,7 @@ static int denali_write_page(struct nand_chip *chip, const
uint8_t *buf,
struct mtd_info *mtd = nand_to_mtd(chip);
return denali_data_xfer(chip, (void *)buf, mtd->writesize, page,
- 0, 1);
+ false, true);
}
static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
@@ -1042,7 +1043,7 @@ static int denali_attach_chip(struct nand_chip *chip)
int ret;
if (ioread32(denali->reg + FEATURES) & FEATURES__DMA)
- denali->dma_avail = 1;
+
[PATCH v2 03/10] mtd: rawnand: denali: remove unneeded casts in denali_{read,write}_pio
Since (u32 *) can accept an opaque pointer, the explicit casting
from (void *) to (u32 *) is redundant. Change the function argument type
to remove the casts.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 9287f4f..a2fe2ff 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -478,11 +478,10 @@ static void denali_setup_dma32(struct denali_nand_info
*denali,
denali->host_write(denali, mode | 0x14000, 0x2400);
}
-static int denali_pio_read(struct denali_nand_info *denali, void *buf,
+static int denali_pio_read(struct denali_nand_info *denali, u32 *buf,
size_t size, int page)
{
u32 addr = DENALI_MAP01 | DENALI_BANK(denali) | page;
- uint32_t *buf32 = (uint32_t *)buf;
uint32_t irq_status, ecc_err_mask;
int i;
@@ -494,7 +493,7 @@ static int denali_pio_read(struct denali_nand_info *denali,
void *buf,
denali_reset_irq(denali);
for (i = 0; i < size / 4; i++)
- *buf32++ = denali->host_read(denali, addr);
+ buf[i] = denali->host_read(denali, addr);
irq_status = denali_wait_for_irq(denali, INTR__PAGE_XFER_INC);
if (!(irq_status & INTR__PAGE_XFER_INC))
@@ -506,18 +505,17 @@ static int denali_pio_read(struct denali_nand_info
*denali, void *buf,
return irq_status & ecc_err_mask ? -EBADMSG : 0;
}
-static int denali_pio_write(struct denali_nand_info *denali,
- const void *buf, size_t size, int page)
+static int denali_pio_write(struct denali_nand_info *denali, const u32 *buf,
+ size_t size, int page)
{
u32 addr = DENALI_MAP01 | DENALI_BANK(denali) | page;
- const uint32_t *buf32 = (uint32_t *)buf;
uint32_t irq_status;
int i;
denali_reset_irq(denali);
for (i = 0; i < size / 4; i++)
- denali->host_write(denali, addr, *buf32++);
+ denali->host_write(denali, addr, buf[i]);
irq_status = denali_wait_for_irq(denali,
INTR__PROGRAM_COMP | INTR__PROGRAM_FAIL);
--
2.7.4
[PATCH v2 07/10] mtd: rawnand: denali_pci: rename goto labels
As Documentation/process/coding-style.rst says, choose label names
which say what the goto does. The out_ label style is already
used in denali_dt.c. Rename likewise for denali_pci.c
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mtd/nand/raw/denali_pci.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali_pci.c
b/drivers/mtd/nand/raw/denali_pci.c
index 48e9ac5..02eb599 100644
--- a/drivers/mtd/nand/raw/denali_pci.c
+++ b/drivers/mtd/nand/raw/denali_pci.c
@@ -84,20 +84,20 @@ static int denali_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
if (!denali->host) {
dev_err(>dev, "Spectra: ioremap_nocache failed!");
ret = -ENOMEM;
- goto failed_remap_reg;
+ goto out_unmap_reg;
}
ret = denali_init(denali);
if (ret)
- goto failed_remap_mem;
+ goto out_unmap_host;
pci_set_drvdata(dev, denali);
return 0;
-failed_remap_mem:
+out_unmap_host:
iounmap(denali->host);
-failed_remap_reg:
+out_unmap_reg:
iounmap(denali->reg);
return ret;
}
--
2.7.4
[PATCH v2 04/10] mtd: rawnand: denali: switch over to ->exec_op() from legacy hooks
Implement ->exec_op(), and remove the deprecated hooks.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 234 +++---
1 file changed, 126 insertions(+), 108 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index a2fe2ff..bd7df25 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -206,85 +206,11 @@ static uint32_t denali_wait_for_irq(struct
denali_nand_info *denali,
return denali->irq_status;
}
-static void denali_read_buf(struct nand_chip *chip, uint8_t *buf, int len)
+static void denali_select_target(struct nand_chip *chip, int cs)
{
- struct mtd_info *mtd = nand_to_mtd(chip);
- struct denali_nand_info *denali = mtd_to_denali(mtd);
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- int i;
-
- for (i = 0; i < len; i++)
- buf[i] = denali->host_read(denali, addr);
-}
-
-static void denali_write_buf(struct nand_chip *chip, const uint8_t *buf,
-int len)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- int i;
-
- for (i = 0; i < len; i++)
- denali->host_write(denali, addr, buf[i]);
-}
-
-static void denali_read_buf16(struct nand_chip *chip, uint8_t *buf, int len)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- uint16_t *buf16 = (uint16_t *)buf;
- int i;
-
- for (i = 0; i < len / 2; i++)
- buf16[i] = denali->host_read(denali, addr);
-}
-
-static void denali_write_buf16(struct nand_chip *chip, const uint8_t *buf,
- int len)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- u32 addr = DENALI_MAP11_DATA | DENALI_BANK(denali);
- const uint16_t *buf16 = (const uint16_t *)buf;
- int i;
-
- for (i = 0; i < len / 2; i++)
- denali->host_write(denali, addr, buf16[i]);
-}
-
-static uint8_t denali_read_byte(struct nand_chip *chip)
-{
- uint8_t byte;
-
- denali_read_buf(chip, , 1);
-
- return byte;
-}
-
-static void denali_write_byte(struct nand_chip *chip, uint8_t byte)
-{
- denali_write_buf(chip, , 1);
-}
-
-static void denali_cmd_ctrl(struct nand_chip *chip, int dat, unsigned int ctrl)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- uint32_t type;
-
- if (ctrl & NAND_CLE)
- type = DENALI_MAP11_CMD;
- else if (ctrl & NAND_ALE)
- type = DENALI_MAP11_ADDR;
- else
- return;
-
- /*
-* Some commands are followed by chip->legacy.waitfunc.
-* irq_status must be cleared here to catch the R/B# interrupt later.
-*/
- if (ctrl & NAND_CTRL_CHANGE)
- denali_reset_irq(denali);
+ struct denali_nand_info *denali = to_denali(chip);
- denali->host_write(denali, DENALI_BANK(denali) | type, dat);
+ denali->active_bank = cs;
}
static int denali_check_erased_page(struct nand_chip *chip,
@@ -596,6 +522,8 @@ static int denali_data_xfer(struct nand_chip *chip, void
*buf, size_t size,
{
struct denali_nand_info *denali = to_denali(chip);
+ denali_select_target(chip, chip->cur_cs);
+
iowrite32(raw ? 0 : ECC_ENABLE__FLAG, denali->reg + ECC_ENABLE);
iowrite32(raw ? TRANSFER_SPARE_REG__FLAG : 0,
denali->reg + TRANSFER_SPARE_REG);
@@ -856,24 +784,6 @@ static int denali_write_page(struct nand_chip *chip, const
uint8_t *buf,
0, 1);
}
-static void denali_select_chip(struct nand_chip *chip, int cs)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
-
- denali->active_bank = cs;
-}
-
-static int denali_waitfunc(struct nand_chip *chip)
-{
- struct denali_nand_info *denali = mtd_to_denali(nand_to_mtd(chip));
- uint32_t irq_status;
-
- /* R/B# pin transitioned from low to high? */
- irq_status = denali_wait_for_irq(denali, INTR__INT_ACT);
-
- return irq_status & INTR__INT_ACT ? 0 : NAND_STATUS_FAIL;
-}
-
static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
const struct nand_data_interface *conf)
{
@@ -1185,13 +1095,6 @@ static int denali_attach_chip(struct nand_chip *chip)
mtd_set_ooblayout(mtd, _ooblayout_ops);
- if (chip->options & NAND_BUSWIDTH_16) {
- chip->legacy.read_buf = denali_read_buf16;
- chip->legacy.write_buf = denali_write_buf16;
- } else {
- chip->legacy.read_buf = denali_read_buf;
- chip->legacy.write_buf = denali_write_buf;
- }
chip->ecc.read_page = denali_read_page;
[PATCH v2 10/10] mtd: rawnand: denali: clean up coding style
Eliminate the following reports from 'scripts/checkpatch.pl --strict'.
CHECK: Prefer kernel type 'u8' over 'uint8_t'
CHECK: Prefer kernel type 'u32' over 'uint32_t'
CHECK: Alignment should match open parenthesis
I slightly changed denali_check_erased_page() to make it shorter.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 53 ---
1 file changed, 25 insertions(+), 28 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index eb58136..82b2b8e 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -124,7 +124,7 @@ static irqreturn_t denali_isr(int irq, void *dev_id)
{
struct denali_controller *denali = dev_id;
irqreturn_t ret = IRQ_NONE;
- uint32_t irq_status;
+ u32 irq_status;
int i;
spin_lock(>irq_lock);
@@ -164,7 +164,7 @@ static u32 denali_wait_for_irq(struct denali_controller
*denali, u32 irq_mask,
unsigned int timeout_ms)
{
unsigned long time_left, flags;
- uint32_t irq_status;
+ u32 irq_status;
spin_lock_irqsave(>irq_lock, flags);
@@ -239,20 +239,17 @@ static int denali_check_erased_page(struct nand_chip
*chip,
unsigned int max_bitflips)
{
struct mtd_ecc_stats *ecc_stats = _to_mtd(chip)->ecc_stats;
- uint8_t *ecc_code = chip->oob_poi + denali->oob_skip_bytes;
- int ecc_steps = chip->ecc.steps;
- int ecc_size = chip->ecc.size;
- int ecc_bytes = chip->ecc.bytes;
+ struct nand_ecc_ctrl *ecc = >ecc;
+ u8 *ecc_code = chip->oob_poi + denali->oob_skip_bytes;
int i, stat;
- for (i = 0; i < ecc_steps; i++) {
+ for (i = 0; i < ecc->steps; i++) {
if (!(uncor_ecc_flags & BIT(i)))
continue;
- stat = nand_check_erased_ecc_chunk(buf, ecc_size,
- ecc_code, ecc_bytes,
- NULL, 0,
- chip->ecc.strength);
+ stat = nand_check_erased_ecc_chunk(buf, ecc->size, ecc_code,
+ ecc->bytes, NULL, 0,
+ ecc->strength);
if (stat < 0) {
ecc_stats->failed++;
} else {
@@ -260,8 +257,8 @@ static int denali_check_erased_page(struct nand_chip *chip,
max_bitflips = max_t(unsigned int, max_bitflips, stat);
}
- buf += ecc_size;
- ecc_code += ecc_bytes;
+ buf += ecc->size;
+ ecc_code += ecc->bytes;
}
return max_bitflips;
@@ -273,7 +270,7 @@ static int denali_hw_ecc_fixup(struct nand_chip *chip,
{
struct mtd_ecc_stats *ecc_stats = _to_mtd(chip)->ecc_stats;
int bank = denali->active_bank;
- uint32_t ecc_cor;
+ u32 ecc_cor;
unsigned int max_bitflips;
ecc_cor = ioread32(denali->reg + ECC_COR_INFO(bank));
@@ -304,17 +301,17 @@ static int denali_hw_ecc_fixup(struct nand_chip *chip,
static int denali_sw_ecc_fixup(struct nand_chip *chip,
struct denali_controller *denali,
- unsigned long *uncor_ecc_flags, uint8_t *buf)
+ unsigned long *uncor_ecc_flags, u8 *buf)
{
struct mtd_ecc_stats *ecc_stats = _to_mtd(chip)->ecc_stats;
unsigned int ecc_size = chip->ecc.size;
unsigned int bitflips = 0;
unsigned int max_bitflips = 0;
- uint32_t err_addr, err_cor_info;
+ u32 err_addr, err_cor_info;
unsigned int err_byte, err_sector, err_device;
- uint8_t err_cor_value;
+ u8 err_cor_value;
unsigned int prev_sector = 0;
- uint32_t irq_status;
+ u32 irq_status;
denali_reset_irq(denali);
@@ -379,7 +376,7 @@ static int denali_sw_ecc_fixup(struct nand_chip *chip,
static void denali_setup_dma64(struct denali_controller *denali,
dma_addr_t dma_addr, int page, bool write)
{
- uint32_t mode;
+ u32 mode;
const int page_count = 1;
mode = DENALI_MAP10 | DENALI_BANK(denali) | page;
@@ -404,7 +401,7 @@ static void denali_setup_dma64(struct denali_controller
*denali,
static void denali_setup_dma32(struct denali_controller *denali,
dma_addr_t dma_addr, int page, bool write)
{
- uint32_t mode;
+ u32 mode;
const int page_count = 1;
mode = DENALI_MAP10 | DENALI_BANK(denali);
@@ -429,7 +426,7 @@ static int denali_pio_read(struct denali_controller
*denali, u32 *buf,
size_t size, int page)
{
u32 addr = DENALI_MAP01 | DENALI_BANK(denali) | page;
-
[PATCH v2 01/10] mtd: rawnand: denali: use nand_chip pointer more for internal functions
With the recent refactoring, the NAND driver hooks now take a pointer
to nand_chip. Add to_denali() in order to convert (struct nand_chip *)
to (struct denali_nand_info *) directly. It is more useful than the
current mtd_to_denali().
I changed some helper functions to take (struct nand_chip *). This will
avoid pointer conversion back and forth, and ease further development.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mtd/nand/raw/denali.c | 57 ---
1 file changed, 32 insertions(+), 25 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 24aeafc..4ac1314 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -47,6 +47,11 @@ static inline struct denali_nand_info *mtd_to_denali(struct
mtd_info *mtd)
return container_of(mtd_to_nand(mtd), struct denali_nand_info, nand);
}
+static struct denali_nand_info *to_denali(struct nand_chip *chip)
+{
+ return container_of(chip, struct denali_nand_info, nand);
+}
+
/*
* Direct Addressing - the slave address forms the control information (command
* type, bank, block, and page address). The slave data is the actual data to
@@ -282,12 +287,12 @@ static void denali_cmd_ctrl(struct nand_chip *chip, int
dat, unsigned int ctrl)
denali->host_write(denali, DENALI_BANK(denali) | type, dat);
}
-static int denali_check_erased_page(struct mtd_info *mtd,
- struct nand_chip *chip, uint8_t *buf,
+static int denali_check_erased_page(struct nand_chip *chip,
+ struct denali_nand_info *denali, u8 *buf,
unsigned long uncor_ecc_flags,
unsigned int max_bitflips)
{
- struct denali_nand_info *denali = mtd_to_denali(mtd);
+ struct mtd_ecc_stats *ecc_stats = _to_mtd(chip)->ecc_stats;
uint8_t *ecc_code = chip->oob_poi + denali->oob_skip_bytes;
int ecc_steps = chip->ecc.steps;
int ecc_size = chip->ecc.size;
@@ -303,9 +308,9 @@ static int denali_check_erased_page(struct mtd_info *mtd,
NULL, 0,
chip->ecc.strength);
if (stat < 0) {
- mtd->ecc_stats.failed++;
+ ecc_stats->failed++;
} else {
- mtd->ecc_stats.corrected += stat;
+ ecc_stats->corrected += stat;
max_bitflips = max_t(unsigned int, max_bitflips, stat);
}
@@ -316,11 +321,11 @@ static int denali_check_erased_page(struct mtd_info *mtd,
return max_bitflips;
}
-static int denali_hw_ecc_fixup(struct mtd_info *mtd,
+static int denali_hw_ecc_fixup(struct nand_chip *chip,
struct denali_nand_info *denali,
unsigned long *uncor_ecc_flags)
{
- struct nand_chip *chip = mtd_to_nand(mtd);
+ struct mtd_ecc_stats *ecc_stats = _to_mtd(chip)->ecc_stats;
int bank = denali->active_bank;
uint32_t ecc_cor;
unsigned int max_bitflips;
@@ -346,16 +351,17 @@ static int denali_hw_ecc_fixup(struct mtd_info *mtd,
* Unfortunately, we can not know the total number of corrected bits in
* the page. Increase the stats by max_bitflips. (compromised solution)
*/
- mtd->ecc_stats.corrected += max_bitflips;
+ ecc_stats->corrected += max_bitflips;
return max_bitflips;
}
-static int denali_sw_ecc_fixup(struct mtd_info *mtd,
+static int denali_sw_ecc_fixup(struct nand_chip *chip,
struct denali_nand_info *denali,
unsigned long *uncor_ecc_flags, uint8_t *buf)
{
- unsigned int ecc_size = denali->nand.ecc.size;
+ struct mtd_ecc_stats *ecc_stats = _to_mtd(chip)->ecc_stats;
+ unsigned int ecc_size = chip->ecc.size;
unsigned int bitflips = 0;
unsigned int max_bitflips = 0;
uint32_t err_addr, err_cor_info;
@@ -404,7 +410,7 @@ static int denali_sw_ecc_fixup(struct mtd_info *mtd,
/* correct the ECC error */
flips_in_byte = hweight8(buf[offset] ^ err_cor_value);
buf[offset] ^= err_cor_value;
- mtd->ecc_stats.corrected += flips_in_byte;
+ ecc_stats->corrected += flips_in_byte;
bitflips += flips_in_byte;
max_bitflips = max(max_bitflips, bitflips);
@@ -587,9 +593,11 @@ static int denali_dma_xfer(struct denali_nand_info
*denali, void *buf,
return ret;
}
-static int denali_data_xfer(struct denali_nand_info *denali, void *buf,
- size_t size, int page, int raw, int write)
+static int denali_data_xfer(struct nand_chip *chip, void *buf, size_t
[PATCH v2 00/10] mtd: rawnand: denali: exec_op(), controller/chip separation, and cleanups
I took time for the Denali driver to catch up with the latest framework.
- switch over to exec_op() and remove legacy hooks
- separate controller/chips
- various cleanups
Masahiro Yamada (10):
mtd: rawnand: denali: use nand_chip pointer more for internal
functions
mtd: rawnand: denali: refactor syndrome layout handling for raw access
mtd: rawnand: denali: remove unneeded casts in denali_{read,write}_pio
mtd: rawnand: denali: switch over to ->exec_op() from legacy hooks
mtd: rawnand: denali: use more precise timeout for
NAND_OP_WAITRDT_INSTR
mtd: rawnand: denali: use bool type instead of int where appropriate
mtd: rawnand: denali_pci: rename goto labels
mtd: rawnand: denali: decouple controller and NAND chips
mtd: rawnand: denali: remove DENALI_NR_BANKS macro
mtd: rawnand: denali: clean up coding style
.../devicetree/bindings/mtd/denali-nand.txt| 39 +-
drivers/mtd/nand/raw/denali.c | 1144 +++-
drivers/mtd/nand/raw/denali.h | 119 +-
drivers/mtd/nand/raw/denali_dt.c | 98 +-
drivers/mtd/nand/raw/denali_pci.c | 38 +-
5 files changed, 850 insertions(+), 588 deletions(-)
--
2.7.4
[PATCH v2 05/10] mtd: rawnand: denali: use more precise timeout for NAND_OP_WAITRDT_INSTR
Currently, wait_for_completion_timeout() is always passed in the
hard-coded msec_to_jiffies(1000). There is no specific reason for
1000 msec, but it was chosen to be long enough.
With the exec_op() conversion, NAND_OP_WAITRDY_INSTR provides more
precise timeout value, depending on the preceding command. Let's use
it (+ 100 msec) to bail out earlier in error case. The 100 msec extra
is in case the heavy load on the system.
I am still keeping the hard-coded values for other higher level hooks
such as page_read, page_write, etc. We know the value of tR, tPROG, but
we have unknowledge about the data transfer speed of the DMA engine.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Add extra 100 msec to the wait-period in case the system is under load
drivers/mtd/nand/raw/denali.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index bd7df25..7050b1f 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -176,7 +176,7 @@ static void denali_reset_irq(struct denali_nand_info
*denali)
}
static uint32_t denali_wait_for_irq(struct denali_nand_info *denali,
- uint32_t irq_mask)
+ u32 irq_mask, unsigned int timeout_ms)
{
unsigned long time_left, flags;
uint32_t irq_status;
@@ -195,8 +195,11 @@ static uint32_t denali_wait_for_irq(struct
denali_nand_info *denali,
reinit_completion(>complete);
spin_unlock_irqrestore(>irq_lock, flags);
+ /* Prolong the IRQ wait time in case the system is under heavy load. */
+ timeout_ms += 100;
+
time_left = wait_for_completion_timeout(>complete,
- msecs_to_jiffies(1000));
+ msecs_to_jiffies(timeout_ms));
if (!time_left) {
dev_err(denali->dev, "timeout while waiting for irq 0x%x\n",
irq_mask);
@@ -349,7 +352,7 @@ static int denali_sw_ecc_fixup(struct nand_chip *chip,
* Once handle all ECC errors, controller will trigger an
* ECC_TRANSACTION_DONE interrupt.
*/
- irq_status = denali_wait_for_irq(denali, INTR__ECC_TRANSACTION_DONE);
+ irq_status = denali_wait_for_irq(denali, INTR__ECC_TRANSACTION_DONE, 1);
if (!(irq_status & INTR__ECC_TRANSACTION_DONE))
return -EIO;
@@ -421,7 +424,7 @@ static int denali_pio_read(struct denali_nand_info *denali,
u32 *buf,
for (i = 0; i < size / 4; i++)
buf[i] = denali->host_read(denali, addr);
- irq_status = denali_wait_for_irq(denali, INTR__PAGE_XFER_INC);
+ irq_status = denali_wait_for_irq(denali, INTR__PAGE_XFER_INC, 1);
if (!(irq_status & INTR__PAGE_XFER_INC))
return -EIO;
@@ -444,7 +447,9 @@ static int denali_pio_write(struct denali_nand_info
*denali, const u32 *buf,
denali->host_write(denali, addr, buf[i]);
irq_status = denali_wait_for_irq(denali,
- INTR__PROGRAM_COMP | INTR__PROGRAM_FAIL);
+INTR__PROGRAM_COMP |
+INTR__PROGRAM_FAIL,
+1000);
if (!(irq_status & INTR__PROGRAM_COMP))
return -EIO;
@@ -501,7 +506,7 @@ static int denali_dma_xfer(struct denali_nand_info *denali,
void *buf,
denali_reset_irq(denali);
denali->setup_dma(denali, dma_addr, page, write);
- irq_status = denali_wait_for_irq(denali, irq_mask);
+ irq_status = denali_wait_for_irq(denali, irq_mask, 1000);
if (!(irq_status & INTR__DMA_CMD_COMP))
ret = -EIO;
else if (irq_status & ecc_err_mask)
@@ -1168,12 +1173,13 @@ static void denali_exec_out16(struct denali_nand_info
*denali, u32 type,
buf[i + 1] << 16 | buf[i]);
}
-static int denali_exec_waitrdy(struct denali_nand_info *denali)
+static int denali_exec_waitrdy(struct denali_nand_info *denali,
+ unsigned int timeout_ms)
{
u32 irq_stat;
/* R/B# pin transitioned from low to high? */
- irq_stat = denali_wait_for_irq(denali, INTR__INT_ACT);
+ irq_stat = denali_wait_for_irq(denali, INTR__INT_ACT, timeout_ms);
/* Just in case nand_operation has multiple NAND_OP_WAITRDY_INSTR. */
denali_reset_irq(denali);
@@ -1212,7 +1218,8 @@ static int denali_exec_instr(struct nand_chip *chip,
instr->ctx.data.len);
return 0;
case NAND_OP_WAITRDY_INSTR:
- return denali_exec_waitrdy(denali);
+ return denali_exec_waitrdy(denali,
+ instr->ctx.waitrdy.timeout_ms);
default:
WARN_ONCE(1, "unsupported NAND
[PATCH v2 08/10] mtd: rawnand: denali: decouple controller and NAND chips
Currently, this driver sticks to the legacy NAND model because it was
upstreamed before commit 2d472aba15ff ("mtd: nand: document the NAND
controller/NAND chip DT representation"). However, relying on the
dummy_controller is already deprecated.
Switch over to the new controller/chip representation.
The struct denali_nand_info has been split into denali_controller
and denali_chip, to contain the controller data, per-chip data,
respectively.
One problem is, this commit changes the DT binding. So, as always,
the backward compatibility must be taken into consideration.
In the new binding, the controller node expects
#address-cells = <1>;
#size-cells = <0>;
... since the child nodes represent NAND chips.
In the old binding, the controller node may have subnodes, but they
are MTD partitions.
The denali_dt_is_legacy_binding() exploits it to distinguish old/new
platforms.
Going forward, the old binding is only allowed for existing DT files.
I updated the binding document.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
.../devicetree/bindings/mtd/denali-nand.txt| 39 +-
drivers/mtd/nand/raw/denali.c | 453 -
drivers/mtd/nand/raw/denali.h | 117 +-
drivers/mtd/nand/raw/denali_dt.c | 98 -
drivers/mtd/nand/raw/denali_pci.c | 30 +-
5 files changed, 500 insertions(+), 237 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt
b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index f33da87..de4ddff 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -7,34 +7,47 @@ Required properties:
"socionext,uniphier-denali-nand-v5b" - for Socionext UniPhier (v5b)
- reg : should contain registers location and length for data and reg.
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
+ - #address-cells: should be 1. The cell encodes the chip select connection.
+ - #size-cells : should be 0.
- interrupts : The interrupt number.
- clocks: should contain phandle of the controller core clock, the bus
interface clock, and the ECC circuit clock.
- clock-names: should contain "nand", "nand_x", "ecc"
-Optional properties:
- - nand-ecc-step-size: see nand.txt for details. If present, the value must
be
- 512for "altr,socfpga-denali-nand"
- 1024 for "socionext,uniphier-denali-nand-v5a"
- 1024 for "socionext,uniphier-denali-nand-v5b"
- - nand-ecc-strength: see nand.txt for details. Valid values are:
- 8, 15 for "altr,socfpga-denali-nand"
- 8, 16, 24 for "socionext,uniphier-denali-nand-v5a"
- 8, 16 for "socionext,uniphier-denali-nand-v5b"
- - nand-ecc-maximize: see nand.txt for details
-
-The device tree may optionally contain sub-nodes describing partitions of the
+Sub-nodes:
+ Sub-nodes represent available NAND chips.
+
+ Required properties:
+- reg: should contain the bank ID of the controller to which each chip
+ select is connected.
+
+ Optional properties:
+- nand-ecc-step-size: see nand.txt for details. If present, the value
must be
+512for "altr,socfpga-denali-nand"
+1024 for "socionext,uniphier-denali-nand-v5a"
+1024 for "socionext,uniphier-denali-nand-v5b"
+- nand-ecc-strength: see nand.txt for details. Valid values are:
+8, 15 for "altr,socfpga-denali-nand"
+8, 16, 24 for "socionext,uniphier-denali-nand-v5a"
+8, 16 for "socionext,uniphier-denali-nand-v5b"
+- nand-ecc-maximize: see nand.txt for details
+
+The chip nodes may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
Examples:
nand: nand@ff90 {
#address-cells = <1>;
- #size-cells = <1>;
+ #size-cells = <0>;
compatible = "altr,socfpga-denali-nand";
reg = <0xff90 0x20>, <0xffb8 0x1000>;
reg-names = "nand_data", "denali_reg";
clocks = <_clk>, <_x_clk>, <_ecc_clk>;
clock-names = "nand", "nand_x", "ecc";
interrupts = <0 144 4>;
+
+ nand@0 {
+ reg = <0>;
+ }
};
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index f539731..a162bd1 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -3,7 +3,7 @@
* NAND Flash Controller Device Driver
* Copyright © 2009-2010, Intel Corporation and its suppliers.
*
- * Copyright (c) 2017 Socionext Inc.
+ * Copyright (c) 2017-2019 Socionext Inc.
* Reworked by Masahiro Yamada
*/
@@ -42,14 +42,15 @@
#define DENALI_INVALID_BANK-1
#define DENALI_NR_BANKS4
-static inline struct denali_nand_info *mtd_to_denali(struct mtd_info *mtd)
+static struct denali_chip *to_denali_chip(struct nand_chip *chip)
{
- return
Re: [PATCH 5/5] riscv: use for_each_of_cpu_node iterator
On Fri, Jan 18, 2019 at 03:03:08PM +0100, Johan Hovold wrote: > Use the new for_each_of_cpu_node() helper to iterate over cpu nodes > instead of open coding. Note that this will allow matching also on the > node name instead of the (for FDT) deprecated device_type property. > > Signed-off-by: Johan Hovold I think this is going to conflict with the ELF caps changes from Atish. Maybe the riscv_fill_hwcap hunk should be included in his patch? Otherwise looks good: Reviewed-by: Christoph Hellwig
[PATCH] rpmsg: virtio_rpmsg_bus: acknowledge the received creation message
From: QianWenfa
the two phase handsake make the client could initiate the transfer
immediately without the server side send any dummy message first.
Signed-off-by: Wenfa Qian
Signed-off-by: Xiang Xiao
---
drivers/rpmsg/virtio_rpmsg_bus.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 664f957..e323c98 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -71,6 +71,7 @@ struct virtproc_info {
/* The feature bitmap for virtio rpmsg */
#define VIRTIO_RPMSG_F_NS 0 /* RP supports name service notifications */
+#define VIRTIO_RPMSG_F_ACK 1 /* RP supports name service acknowledge */
/**
* struct rpmsg_hdr - common header for all rpmsg messages
@@ -115,10 +116,12 @@ struct rpmsg_ns_msg {
*
* @RPMSG_NS_CREATE: a new remote service was just created
* @RPMSG_NS_DESTROY: a known remote service was just destroyed
+ * @RPMSG_NS_ACK: acknowledge the previous creation message
*/
enum rpmsg_ns_flags {
RPMSG_NS_CREATE = 0,
RPMSG_NS_DESTROY= 1,
+ RPMSG_NS_ACK= 2,
};
/**
@@ -330,13 +333,14 @@ static int virtio_rpmsg_announce_create(struct
rpmsg_device *rpdev)
int err = 0;
/* need to tell remote processor's name service about this channel ? */
- if (rpdev->announce && rpdev->ept &&
+ if (rpdev->ept && (rpdev->announce ||
+ virtio_has_feature(vrp->vdev, VIRTIO_RPMSG_F_ACK)) &&
virtio_has_feature(vrp->vdev, VIRTIO_RPMSG_F_NS)) {
struct rpmsg_ns_msg nsm;
strncpy(nsm.name, rpdev->id.name, RPMSG_NAME_SIZE);
nsm.addr = rpdev->ept->addr;
- nsm.flags = RPMSG_NS_CREATE;
+ nsm.flags = rpdev->announce ? RPMSG_NS_CREATE : RPMSG_NS_ACK;
err = rpmsg_sendto(rpdev->ept, , sizeof(nsm),
RPMSG_NS_ADDR);
if (err)
@@ -820,6 +824,7 @@ static int rpmsg_ns_cb(struct rpmsg_device *rpdev, void
*data, int len,
struct rpmsg_channel_info chinfo;
struct virtproc_info *vrp = priv;
struct device *dev = >vdev->dev;
+ struct device *tmp;
int ret;
#if defined(CONFIG_DYNAMIC_DEBUG)
@@ -847,21 +852,30 @@ static int rpmsg_ns_cb(struct rpmsg_device *rpdev, void
*data, int len,
msg->name[RPMSG_NAME_SIZE - 1] = '\0';
dev_info(dev, "%sing channel %s addr 0x%x\n",
-msg->flags & RPMSG_NS_DESTROY ? "destroy" : "creat",
+msg->flags == RPMSG_NS_ACK ? "ack" :
+msg->flags == RPMSG_NS_DESTROY ? "destroy" : "creat",
msg->name, msg->addr);
strncpy(chinfo.name, msg->name, sizeof(chinfo.name));
chinfo.src = RPMSG_ADDR_ANY;
chinfo.dst = msg->addr;
- if (msg->flags & RPMSG_NS_DESTROY) {
+ if (msg->flags == RPMSG_NS_DESTROY) {
ret = rpmsg_unregister_device(>vdev->dev, );
if (ret)
dev_err(dev, "rpmsg_destroy_channel failed: %d\n", ret);
- } else {
+ } else if (msg->flags == RPMSG_NS_CREATE) {
newch = rpmsg_create_channel(vrp, );
if (!newch)
dev_err(dev, "rpmsg_create_channel failed\n");
+ } else if (msg->flags == RPMSG_NS_ACK) {
+ chinfo.dst = RPMSG_ADDR_ANY;
+ tmp = rpmsg_find_device(>vdev->dev, );
+ if (tmp) {
+ newch = to_rpmsg_device(tmp);
+ newch->dst = msg->addr;
+ } else
+ dev_err(dev, "rpmsg_find_device failed\n");
}
return 0;
@@ -1028,6 +1042,7 @@ static struct virtio_device_id id_table[] = {
static unsigned int features[] = {
VIRTIO_RPMSG_F_NS,
+ VIRTIO_RPMSG_F_ACK,
};
static struct virtio_driver virtio_ipc_driver = {
--
2.7.4
Re: [PATCH 4/5] riscv: treat cpu devicetree nodes without status as enabled
On Fri, Jan 18, 2019 at 03:03:07PM +0100, Johan Hovold wrote: > Follow the Linux convention and treat devicetree nodes without a status > property as enabled rather than disabled, while also allowing "ok" as a > shorthand for "okay". > > Signed-off-by: Johan Hovold Looks good: Reviewed-by: Christoph Hellwig
Re: [PATCH 3/5] riscv: fix riscv_of_processor_hartid() comment
On Fri, Jan 18, 2019 at 03:03:06PM +0100, Johan Hovold wrote: > The riscv_of_processor_hartid() helper returns -ENODEV when the > specified node isn't an enabled and valid RISC-V hart node. > > Also drop the unnecessary parenthesis around errno defines. > > Signed-off-by: Johan Hovold Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH v3] cpufreq: intel_pstate: Reporting reasons why driver prematurely exit
Le 12/02/2019 à 00:17, Srinivas Pandruvada a écrit : > [...] > To know if the intel_pstate in control, you can look at: > #cat /sys/devices/system/cpu/cpufreq/policy0/scaling_driver > > So if it is not loaded and Intel intend to support a processor model > with intel_pstate, then OEM's platform_power_management policy can > override. So we can add one pr_info to show that driver can't be loaded > because of platform > intel_pstate_platform_pwr_mgmt_exists(), return true. Agreed. But I do think the intel_pstate_msrs_not_valid() case also deserves a pr_warn() as this is a premature exit because of some hardware settings. > If HWP is used we already have a pr_info. If HWP is present it will > always be used unless user overrides. > > The cases where a memory allocation fails you will see other warnings > in the system, so don't need to add in driver. Also if someone > explcitly using kernel command line to either disable or control > features, user knows what he is doing. > > So no need of pr_warn or pr_info except one case for platform mower > management. The others are debug messages only. Ack. I'm sending a v4 this way. Thanks for the review & discussions. Erwan,
Re: [PATCH v5 1/5] irqchip: sifive-plic: Pre-compute context hart base and enable base
On Sat, Jan 19, 2019 at 11:26:21AM +0530, Anup Patel wrote: > This patch does following optimizations: > 1. Pre-compute hart base for each context handler > 2. Pre-compute enable base for each context handler > 3. Have enable lock for each context handler instead > of global plic_toggle_lock > > Signed-off-by: Anup Patel > --- > drivers/irqchip/irq-sifive-plic.c | 47 ++- > 1 file changed, 21 insertions(+), 26 deletions(-) I don't really see the point, but the code looks clean enough and removes a few lines, so: Reviewed-by: Christoph Hellwig
Re: [PATCH 1/5] riscv: add missing newlines to printk messages
On Fri, Jan 18, 2019 at 03:03:04PM +0100, Johan Hovold wrote: > Add missing newline characters to printk messages. > > Also replace two pr_warning with the shorter pr_warn, and fix up the > tense of one error message while at it. > > Signed-off-by: Johan Hovold Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH 2/5] riscv: use pr_info and friends
On Fri, Jan 18, 2019 at 03:03:05PM +0100, Johan Hovold wrote: > Use the pr_info and pr_err macros instead of printk with explicit log > levels. > > Signed-off-by: Johan Hovold Looks good, Reviewed-by: Christoph Hellwig
Re: [RFC PATCH v4 00/12] hardening: statically allocated protected memory
On 12/02/2019 03:26, Kees Cook wrote:
On Mon, Feb 11, 2019 at 5:08 PM igor.sto...@gmail.com
wrote:
On Tue, 12 Feb 2019, 4.47 Kees Cook
On Mon, Feb 11, 2019 at 4:37 PM Igor Stoppa wrote:
On 12/02/2019 02:09, Kees Cook wrote:
On Mon, Feb 11, 2019 at 3:28 PM Igor Stoppa wrote:
It looked like only the memset() needed architecture support. Is there
a reason for not being able to implement memset() in terms of an
inefficient put_user() loop instead? That would eliminate the need for
per-arch support, yes?
So far, yes, however from previous discussion about power arch, I
understood this implementation would not be so easy to adapt.
Lacking other examples where the extra mapping could be used, I did not
want to add code without a use case.
Probably both arm and x86 32 bit could do, but I would like to first get
to the bitter end with memory protection (the other 2 thirds).
Mostly, I hated having just one arch and I also really wanted to have arm64.
Right, I meant, if you implemented the _memset() case with put_user()
in this version, you could drop the arch-specific _memset() and shrink
the patch series. Then you could also enable this across all the
architectures in one patch. (Would you even need the Kconfig patches,
i.e. won't this "Just Work" on everything with an MMU?)
I had similar thoughts, but this answer [1] deflated my hopes (if I understood
it correctly).
It seems that each arch needs to be massaged in separately.
True, but I think x86_64, x86, arm64, and arm will all be "normal".
power may be that way too, but they always surprise me. :)
Anyway, series looks good, but since nothing uses _memset(), it might
make sense to leave it out and put all the arch-enabling into a single
patch to cover the 4 archs above, in an effort to make the series even
smaller.
Actually, I do use it, albeit indirectly.
That's the whole point of having the IMA patch as example.
This is the fragment:
@@ -460,12 +460,13 @@ void ima_update_policy_flag(void)
list_for_each_entry(entry, ima_rules, list) {
if (entry->action & IMA_DO_MASK)
- ima_policy_flag |= entry->action;
+ wr_assign(ima_policy_flag,
+ ima_policy_flag | entry->action);
}
ima_appraise |= (build_ima_appraise | temp_ima_appraise);
if (!ima_appraise)
- ima_policy_flag &= ~IMA_APPRAISE;
+ wr_assign(ima_policy_flag, ima_policy_flag & ~IMA_APPRAISE);
}
wr_assign() does just that.
However, reading again your previous mails, I realize that I might have
misinterpreted what you were suggesting.
If the advice is to have also a default memset_user() which relies on
put_user(), but do not activate the feature by default for every
architecture, I definitely agree that it would be good to have it.
I just didn't think about it before.
What I cannot do is to turn it on for all the architectures prior to
test it and atm I do not have means to do it.
But I now realize that most likely you were just suggesting to have
full, albeit inefficient default support and then let various archs
review/enhance it. I can certainly do this.
Regarding testing I have a question: how much can/should I lean on qemu?
In most cases the MMU might not need to be fully emulated, so I wonder
how well qemu-based testing can ensure that real life scenarios will work.
--
igor
Re: [PATCH v5 4/5] irqchip: sifive-plic: Differentiate between PLIC handler and context
Looks fine, Reviewed-by: Christoph Hellwig
[PATCH] staging: android: ion: Use low_order_gfp_flags for smaller allocations
gfp_flags is always set high_order_gfp_flags even if allocations of
order 0 are made.But for smaller allocations, the system should be able
to reclaim some memory.
Signed-off-by: Jing Xia
Reviewed-by: Yuming Han
Reviewed-by: Zhaoyang Huang
Reviewed-by: Orson Zhai
---
drivers/staging/android/ion/ion_system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_system_heap.c
b/drivers/staging/android/ion/ion_system_heap.c
index 0383f75..20f2103 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -223,10 +223,10 @@ static void ion_system_heap_destroy_pools(struct
ion_page_pool **pools)
static int ion_system_heap_create_pools(struct ion_page_pool **pools)
{
int i;
- gfp_t gfp_flags = low_order_gfp_flags;
for (i = 0; i < NUM_ORDERS; i++) {
struct ion_page_pool *pool;
+ gfp_t gfp_flags = low_order_gfp_flags;
if (orders[i] > 4)
gfp_flags = high_order_gfp_flags;
--
1.9.1
Re: [PATCH v5 2/5] irqchip: sifive-plic: Don't inline plic_toggle() and plic_irq_toggle()
On Sat, Jan 19, 2019 at 11:26:22AM +0530, Anup Patel wrote: > The plic_toggle() uses raw_spin_lock() and plic_irq_toggle has a > for loop so both these functions are not suitable for being inline > hence this patch removes the inline keyword. I still very much disagree. Very strongly with the above rationale, but also (less strongly) with the decision not to inline here.
[PATCH v4] cpufreq: intel_pstate: Reporting reasons why driver prematurely exit
The init code path has several exceptions where the module can decide not to
load.
As CONFIG_X86_INTEL_PSTATE is generally set to Y, the return code is not
reachable.
The initialization code is neither verbose of the reason why it did choose to
prematurely exit.
This situation leads to a situation where its difficult for a user to determine,
on a given platform, why the driver didn't load properly.
This patch is about reporting to the user the reason/context of why the driver
failed to load.
That is a precious hint when debugging a platform.
Signed-off-by: Erwan Velu
---
drivers/cpufreq/intel_pstate.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index dd66decf2087..eb62edcc 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2475,6 +2475,7 @@ static bool __init intel_pstate_no_acpi_pss(void)
kfree(pss);
}
+ pr_debug("Cannot detect ACPI PSS");
return true;
}
@@ -2484,10 +2485,15 @@ static bool __init intel_pstate_no_acpi_pcch(void)
acpi_handle handle;
status = acpi_get_handle(NULL, "\\_SB", );
- if (ACPI_FAILURE(status))
+ if (ACPI_FAILURE(status)) {
+ pr_debug("Cannot detect ACPI SB");
return true;
+ }
- return !acpi_has_method(handle, "PCCH");
+ status = acpi_has_method(handle, "PCCH");
+ if (!status)
+ pr_debug("Cannot detect ACPI PCCH");
+ return !status;
}
static bool __init intel_pstate_has_acpi_ppc(void)
@@ -2502,6 +2508,7 @@ static bool __init intel_pstate_has_acpi_ppc(void)
if (acpi_has_method(pr->handle, "_PPC"))
return true;
}
+ pr_debug("Cannot detect ACPI PPC");
return false;
}
@@ -2539,8 +2546,10 @@ static bool __init
intel_pstate_platform_pwr_mgmt_exists(void)
id = x86_match_cpu(intel_pstate_cpu_oob_ids);
if (id) {
rdmsrl(MSR_MISC_PWR_MGMT, misc_pwr);
- if ( misc_pwr & (1 << 8))
+ if (misc_pwr & (1 << 8)) {
+ pr_debug("MSR_MISC_PWR_MGMT reports enabled HW
coordination");
return true;
+ }
}
idx = acpi_match_platform_list(plat_info);
@@ -2606,22 +2615,28 @@ static int __init intel_pstate_init(void)
}
} else {
id = x86_match_cpu(intel_pstate_cpu_ids);
- if (!id)
+ if (!id) {
+ pr_warn("CPU ID is not in the list of supported
devices\n");
return -ENODEV;
+ }
copy_cpu_funcs((struct pstate_funcs *)id->driver_data);
}
- if (intel_pstate_msrs_not_valid())
+ if (intel_pstate_msrs_not_valid()) {
+ pr_warn("Cannot enable driver as per invalid MSRs\n");
return -ENODEV;
+ }
hwp_cpu_matched:
/*
* The Intel pstate driver will be ignored if the platform
* firmware has its own power management modes.
*/
- if (intel_pstate_platform_pwr_mgmt_exists())
+ if (intel_pstate_platform_pwr_mgmt_exists()) {
+ pr_warn("Platform already taking care of power management\n");
return -ENODEV;
+ }
if (!hwp_active && hwp_only)
return -ENOTSUPP;
--
2.20.1
Re: [PATCH v2 6/6] RISC-V: Implement keepinitrd kernel parameter
On Sat, Jan 19, 2019 at 01:28:59PM +, Anup Patel wrote: > This patch implements keepinitrd kernel parameter. By default, > keepinitrd=1 but users can pass "keepinitrd=0" to free-up > initrd memory at boot-time in free_initrd_mem() function. > > The keepinitrd kernel parameter is already implemented by > unicore32, arm, and arm64 architectures and it is documented > at: Documentation/admin-guide/kernel-parameters.txt But why do we need it? Is there any good reason every not to free the initrd / initramfs memory when it is not used?
[PATCH V2 0/2] cpufreq: Allow light-weight tear down and bring up of CPUs
The cpufreq core doesn't remove the cpufreq policy anymore on CPU offline operation, rather that happens when the CPU device gets unregistered from the kernel. This allows faster recovery when the CPU comes back online. This is also very useful during system wide suspend/resume where we offline all non-boot CPUs during suspend and then bring them back on resume. This patcset takes the same idea a step ahead to allow drivers to do light weight tear-down and bring up during CPU offline/online operations and updates the cpufreq-dt driver to implement the new helpers. V1->V2: - s/light_weight_exit()/offline() - Also introduce the online() counterpart Viresh Kumar (2): cpufreq: Allow light-weight tear down and bring up of CPUs cpufreq: dt: Implement online/offline() callbacks drivers/cpufreq/cpufreq-dt.c | 17 +++ drivers/cpufreq/cpufreq.c| 55 +++- include/linux/cpufreq.h | 2 ++ 3 files changed, 55 insertions(+), 19 deletions(-) -- 2.20.1.321.g9e740568ce00
[PATCH V2 2/2] cpufreq: dt: Implement online/offline() callbacks
Implement the light-weight tear down and bring up helpers to reduce the
amount of work to do on CPU offline/online operation.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq-dt.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 7ba392911cd0..1aefaa1b0ca2 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -295,6 +295,21 @@ static int cpufreq_init(struct cpufreq_policy *policy)
return ret;
}
+static int cpufreq_online(struct cpufreq_policy *policy)
+{
+ /* We did light-weight tear down earlier, nothing to do here */
+ return 0;
+}
+
+static int cpufreq_offline(struct cpufreq_policy *policy)
+{
+ /*
+* Preserve policy->driver_data and don't free resources on light-weight
+* tear down.
+*/
+ return 0;
+}
+
static int cpufreq_exit(struct cpufreq_policy *policy)
{
struct private_data *priv = policy->driver_data;
@@ -319,6 +334,8 @@ static struct cpufreq_driver dt_cpufreq_driver = {
.get = cpufreq_generic_get,
.init = cpufreq_init,
.exit = cpufreq_exit,
+ .online = cpufreq_online,
+ .offline = cpufreq_offline,
.name = "cpufreq-dt",
.attr = cpufreq_dt_attr,
.suspend = cpufreq_generic_suspend,
--
2.20.1.321.g9e740568ce00
Re: [PATCH v2 5/6] RISC-V: Implement compile-time fixed mappings
Looks good, Reviewed-by: Christoph Hellwig
[PATCH V2 1/2] cpufreq: Allow light-weight tear down and bring up of CPUs
The cpufreq core doesn't remove the cpufreq policy anymore on CPU
offline operation, rather that happens when the CPU device gets
unregistered from the kernel. This allows faster recovery when the CPU
comes back online. This is also very useful during system wide
suspend/resume where we offline all non-boot CPUs during suspend and
then bring them back on resume.
This commit takes the same idea a step ahead to allow drivers to do
light weight tear-down and bring-up during CPU offline and online
operations.
A new set of callbacks is introduced, online/offline(). online() gets
called when the first CPU of an inactive policy is brought up and
offline() gets called when all the CPUs of a policy are offlined.
The existing init/exit() callback get called on policy
creation/destruction. They also get called instead of online/offline()
callbacks if the online/offline() callbacks aren't provided.
This also moves around some code to get executed only for the new-policy
case going forward.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 55 +--
include/linux/cpufreq.h | 2 ++
2 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 96a69c67a545..2b3e9d501f49 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1201,28 +1201,39 @@ static int cpufreq_online(unsigned int cpu)
return -ENOMEM;
}
- cpumask_copy(policy->cpus, cpumask_of(cpu));
+ if (!new_policy && cpufreq_driver->online) {
+ ret = cpufreq_driver->online(policy);
+ if (ret) {
+ pr_debug("%s: %d: initialization failed\n", __func__,
+__LINE__);
+ goto out_exit_policy;
+ }
- /* call driver. From then on the cpufreq must be able
-* to accept all calls to ->verify and ->setpolicy for this CPU
-*/
- ret = cpufreq_driver->init(policy);
- if (ret) {
- pr_debug("initialization failed\n");
- goto out_free_policy;
- }
+ /* Recover policy->cpus using related_cpus */
+ cpumask_copy(policy->cpus, policy->related_cpus);
+ } else {
+ cpumask_copy(policy->cpus, cpumask_of(cpu));
- ret = cpufreq_table_validate_and_sort(policy);
- if (ret)
- goto out_exit_policy;
+ /*
+* Call driver. From then on the cpufreq must be able
+* to accept all calls to ->verify and ->setpolicy for this CPU.
+*/
+ ret = cpufreq_driver->init(policy);
+ if (ret) {
+ pr_debug("%s: %d: initialization failed\n", __func__,
+__LINE__);
+ goto out_free_policy;
+ }
- down_write(>rwsem);
+ ret = cpufreq_table_validate_and_sort(policy);
+ if (ret)
+ goto out_exit_policy;
- if (new_policy) {
/* related_cpus should at least include policy->cpus. */
cpumask_copy(policy->related_cpus, policy->cpus);
}
+ down_write(>rwsem);
/*
* affected cpus must always be the one, which are online. We aren't
* managing offline cpus here.
@@ -1421,11 +1432,12 @@ static int cpufreq_offline(unsigned int cpu)
cpufreq_exit_governor(policy);
/*
-* Perform the ->exit() even during light-weight tear-down,
-* since this is a core component, and is essential for the
-* subsequent light-weight ->init() to succeed.
+* Perform the ->offline() during light-weight tear-down, as
+* that allows fast recovery when the CPU comes back.
*/
- if (cpufreq_driver->exit) {
+ if (cpufreq_driver->offline) {
+ cpufreq_driver->offline(policy);
+ } else if (cpufreq_driver->exit) {
cpufreq_driver->exit(policy);
policy->freq_table = NULL;
}
@@ -1454,8 +1466,13 @@ static void cpufreq_remove_dev(struct device *dev,
struct subsys_interface *sif)
cpumask_clear_cpu(cpu, policy->real_cpus);
remove_cpu_dev_symlink(policy, dev);
- if (cpumask_empty(policy->real_cpus))
+ if (cpumask_empty(policy->real_cpus)) {
+ /* We did light-weight exit earlier, do full tear down now */
+ if (cpufreq_driver->offline)
+ cpufreq_driver->exit(policy);
+
cpufreq_policy_free(policy);
+ }
}
/**
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 9db074ecbbd7..b160e98076e3 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -325,6 +325,8 @@ struct cpufreq_driver {
/* optional */
int (*bios_limit)(int cpu, unsigned int
Re: [PATCH v2 2/6] RISC-V: Setup init_mm before parse_early_param()
On Sat, Jan 19, 2019 at 01:28:07PM +, Anup Patel wrote: > We should setup init_mm before doing parse_early_param() > in setup_arch() to be consistent with setup_arch() of > other architectures such as x86, ARM, and ARM64. Please use up all 72 lines in all your commit logs.. Otherwise looks fine: Reviewed-by: Christoph Hellwig
Re: [PATCH 2/5] vfio/spapr_tce: use pinned_vm instead of locked_vm to account pinned pages
On 12/02/2019 09:44, Daniel Jordan wrote:
> Beginning with bc3e53f682d9 ("mm: distinguish between mlocked and pinned
> pages"), locked and pinned pages are accounted separately. The SPAPR
> TCE VFIO IOMMU driver accounts pinned pages to locked_vm; use pinned_vm
> instead.
>
> pinned_vm recently became atomic and so no longer relies on mmap_sem
> held as writer: delete.
>
> Signed-off-by: Daniel Jordan
> ---
> Documentation/vfio.txt | 6 +--
> drivers/vfio/vfio_iommu_spapr_tce.c | 64 ++---
> 2 files changed, 33 insertions(+), 37 deletions(-)
>
> diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
> index f1a4d3c3ba0b..fa37d65363f9 100644
> --- a/Documentation/vfio.txt
> +++ b/Documentation/vfio.txt
> @@ -308,7 +308,7 @@ This implementation has some specifics:
> currently there is no way to reduce the number of calls. In order to make
> things faster, the map/unmap handling has been implemented in real mode
> which provides an excellent performance which has limitations such as
> - inability to do locked pages accounting in real time.
> + inability to do pinned pages accounting in real time.
>
> 4) According to sPAPR specification, A Partitionable Endpoint (PE) is an I/O
> subtree that can be treated as a unit for the purposes of partitioning and
> @@ -324,7 +324,7 @@ This implementation has some specifics:
> returns the size and the start of the DMA window on the PCI bus.
>
> VFIO_IOMMU_ENABLE
> - enables the container. The locked pages accounting
> + enables the container. The pinned pages accounting
> is done at this point. This lets user first to know what
> the DMA window is and adjust rlimit before doing any real job.
>
> @@ -454,7 +454,7 @@ This implementation has some specifics:
>
> PPC64 paravirtualized guests generate a lot of map/unmap requests,
> and the handling of those includes pinning/unpinning pages and updating
> - mm::locked_vm counter to make sure we do not exceed the rlimit.
> + mm::pinned_vm counter to make sure we do not exceed the rlimit.
> The v2 IOMMU splits accounting and pinning into separate operations:
>
> - VFIO_IOMMU_SPAPR_REGISTER_MEMORY/VFIO_IOMMU_SPAPR_UNREGISTER_MEMORY
> ioctls
> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
> b/drivers/vfio/vfio_iommu_spapr_tce.c
> index c424913324e3..f47e020dc5e4 100644
> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> @@ -34,9 +34,11 @@
> static void tce_iommu_detach_group(void *iommu_data,
> struct iommu_group *iommu_group);
>
> -static long try_increment_locked_vm(struct mm_struct *mm, long npages)
> +static long try_increment_pinned_vm(struct mm_struct *mm, long npages)
> {
> - long ret = 0, locked, lock_limit;
> + long ret = 0;
> + s64 pinned;
> + unsigned long lock_limit;
>
> if (WARN_ON_ONCE(!mm))
> return -EPERM;
> @@ -44,39 +46,33 @@ static long try_increment_locked_vm(struct mm_struct *mm,
> long npages)
> if (!npages)
> return 0;
>
> - down_write(>mmap_sem);
> - locked = mm->locked_vm + npages;
> + pinned = atomic64_add_return(npages, >pinned_vm);
> lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> - if (locked > lock_limit && !capable(CAP_IPC_LOCK))
> + if (pinned > lock_limit && !capable(CAP_IPC_LOCK)) {
> ret = -ENOMEM;
> - else
> - mm->locked_vm += npages;
> + atomic64_sub(npages, >pinned_vm);
> + }
>
> - pr_debug("[%d] RLIMIT_MEMLOCK +%ld %ld/%ld%s\n", current->pid,
> + pr_debug("[%d] RLIMIT_MEMLOCK +%ld %ld/%lu%s\n", current->pid,
> npages << PAGE_SHIFT,
> - mm->locked_vm << PAGE_SHIFT,
> - rlimit(RLIMIT_MEMLOCK),
> - ret ? " - exceeded" : "");
> -
> - up_write(>mmap_sem);
> + atomic64_read(>pinned_vm) << PAGE_SHIFT,
> + rlimit(RLIMIT_MEMLOCK), ret ? " - exceeded" : "");
>
> return ret;
> }
>
> -static void decrement_locked_vm(struct mm_struct *mm, long npages)
> +static void decrement_pinned_vm(struct mm_struct *mm, long npages)
> {
> if (!mm || !npages)
> return;
>
> - down_write(>mmap_sem);
> - if (WARN_ON_ONCE(npages > mm->locked_vm))
> - npages = mm->locked_vm;
> - mm->locked_vm -= npages;
> - pr_debug("[%d] RLIMIT_MEMLOCK -%ld %ld/%ld\n", current->pid,
> + if (WARN_ON_ONCE(npages > atomic64_read(>pinned_vm)))
> + npages = atomic64_read(>pinned_vm);
> + atomic64_sub(npages, >pinned_vm);
> + pr_debug("[%d] RLIMIT_MEMLOCK -%ld %ld/%lu\n", current->pid,
> npages << PAGE_SHIFT,
> - mm->locked_vm << PAGE_SHIFT,
> + atomic64_read(>pinned_vm) << PAGE_SHIFT,
>
linux-next: Tree for Feb 12
Hi all, Changes since 20190211: The tegra tree gained a conflict against the imx-mxs tree. The net-next tree gained a conflict against the net tree. The drm-misc tree lost its build failure. The rtc tree lost its build failure. The xarray tree gained a build failure for which I added a merge fix patch. The akpm tree gained a conflict against the bpf tree. Non-merge commits (relative to Linus' tree): 7147 7676 files changed, 298091 insertions(+), 188993 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 296 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (fb7453e61a2b Merge tag 's390-5.0-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux) Merging fixes/master (0dd62c042779 x86/syscalls: Mark expected switch fall-throughs) Merging kbuild-current/fixes (6db2983cd806 kallsyms: Handle too long symbols in kallsyms.c) Merging arc-current/for-curr (a50d1c471ec5 ARC: boot: robustify u-boot arg referencing) Merging arm-current/fixes (1b5ba3507842 ARM: 8824/1: fix a migrating irq bug when hotplug cpu) Merging arm64-fixes/for-next/fixes (ea5736805190 arm64: kexec_file: handle empty command-line) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (5a3840a470c4 powerpc/papr_scm: Use the correct bind address) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (4d73eaee24ff Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging bpf/master (e451eb510684 xsk: share the mmap_sem for page pinning) Merging ipsec/master (f75a2804da39 xfrm: destroy xfrm_state synchronously on net exit path) Merging netfilter/master (8303b7e8f018 netfilter: nat: fix spurious connection timeouts) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (d04ca383860b mt76x0u: fix suspend/resume) Merging mac80211/master (6157ca0d6bfe mac80211: Fix Tx aggregation session tear down with ITXQs) Merging rdma-fixes/for-rc (48396e80fb65 RDMA/srp: Rework SCSI device reset handling) Merging sound-current/for-linus (00a399cad1a0 ALSA: pcm: Revert capture stream behavior change in blocking mode) Merging sound-asoc-fixes/for-linus (bb62989dccca Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (f17b5f06cb92 Linux 5.0-rc4) Merging regulator-fixes/for-linus (a71f59222522 Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (a4a9ebe8cb0f Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (f57a98e1b713 PCI: Work around Synopsys duplicate Device ID (HAPS USB3, NXP i.MX)) Merging driver-core.current/driver-core-linus (d13937116f1e Linux 5.0-rc6) Merging tty.current/tty-linus (d13937116f1e Linux 5.0-rc6) Merging usb.current/usb-linus (d13937116f1e Linux 5.0-rc6) Merging usb-gadget-fixes/fixes (a53469a68eb8 usb: phy: am335x: fix race condition in _probe) Merging usb-serial-fixes/usb-linus (dd9d3d86b08d USB: serial: cp210x: add ID for Ingenico 3070) Merging usb-chipidea-fixes/ci-for-usb-stable (d6d768a0ec3c usb: c
[PATCH v3 0/4] Add max77620 charging & low battery support
This patch set adds support for max77620 backup battery charging and low battery monitoring. Changes in v3: - Add unit suffix to backup battery charging dts properties - Reduce/optimize the low battery monitoring dts properties Changes in v2: - Add devicetree binding documentation Mark Zhang (4): mfd: max77620: Add backup battery charger support mfd: max77620: add documentation for backup battery charging mfd: max77620: Add low battery monitor support mfd: max77620: add documentation for low battery monitoring .../devicetree/bindings/mfd/max77620.txt | 34 ++ drivers/mfd/max77620.c| 115 +- 2 files changed, 148 insertions(+), 1 deletion(-) -- 2.19.2
[PATCH v3 2/4] mfd: max77620: add documentation for backup battery charging
Adding documentation for 3 new backup battery charging dts properties: - maxim,charging-current-microamp - maxim,charging-voltage-microvolt - maxim,output-resister-ohms Signed-off-by: Mark Zhang --- .../devicetree/bindings/mfd/max77620.txt | 20 +++ 1 file changed, 20 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/max77620.txt b/Documentation/devicetree/bindings/mfd/max77620.txt index 9c16d51cc15b..88825eaf2567 100644 --- a/Documentation/devicetree/bindings/mfd/max77620.txt +++ b/Documentation/devicetree/bindings/mfd/max77620.txt @@ -122,6 +122,26 @@ For DT binding details of different sub modules like GPIO, pincontrol, regulator, power, please refer respective device-tree binding document under their respective sub-system directories. +Backup Battery: +== +This sub-node configure charging backup battery of the device. Device has +support of charging the backup battery. The subnode name is "backup-battery". +The property for backup-battery child nodes as: +Presence of this child node will enable the backup battery charging. + +Optional properties: + -maxim,charging-current-microamp: Charging current setting. + The device supports 50/100/200/400/600/800uA. + If this property is unavailable then it will + charge with 50uA. + -maxim,charging-voltage-microvolt: Charging Voltage Limit Setting. + Device supports 250/300/330/35uV. + Default will be set to 2500mV. The voltage will be roundoff + to nearest lower side if other than above is configured. + -maxim,output-resister-ohms: Output resistor on Ohm. + Device supports 100/1000/3000/6000 Ohms. + Default will be set to 1000 Ohm. + Example: #include -- 2.19.2
[PATCH v3 4/4] mfd: max77620: add documentation for low battery monitoring
Adding documentation for low battery monitor properties: - maxim,low-battery-dac-enable - maxim,low-battery-mode Signed-off-by: Mark Zhang --- Documentation/devicetree/bindings/mfd/max77620.txt | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/max77620.txt b/Documentation/devicetree/bindings/mfd/max77620.txt index 88825eaf2567..f5b298ccc929 100644 --- a/Documentation/devicetree/bindings/mfd/max77620.txt +++ b/Documentation/devicetree/bindings/mfd/max77620.txt @@ -142,6 +142,20 @@ Optional properties: Device supports 100/1000/3000/6000 Ohms. Default will be set to 1000 Ohm. +Low-Battery Monitor: +== +max77620 is able to monitor the main battery voltage and shutdown/reset the +chip connected accordingly. + +Optional properties: + - maxim,low-battery-dac-enable: Enable low battery monitoring. + Low battery monitoring will be disabled if missing + this property. + - maxim,low-battery-mode: Shutdown or reset the chip. + The value of this property is "shutdown" which means + a global shutdown will be triggered. Any other values + or missing this property causes a chip reset. + Example: #include -- 2.19.2
[PATCH v3 3/4] mfd: max77620: Add low battery monitor support
This patch adds PMIC configurations for low-battery
monitoring by handling max77620 register CNFGGLBL1.
Signed-off-by: Laxman Dewangan
Signed-off-by: Venkat Reddy Talla
Signed-off-by: Mark Zhang
---
drivers/mfd/max77620.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/max77620.c b/drivers/mfd/max77620.c
index 494d98357f65..6f0c85b2ca26 100644
--- a/drivers/mfd/max77620.c
+++ b/drivers/mfd/max77620.c
@@ -474,6 +474,35 @@ static int max77620_init_backup_battery_charging(struct
max77620_chip *chip)
return ret;
}
+static int max77620_init_low_battery_monitor(struct max77620_chip *chip)
+{
+ struct device *dev = chip->dev;
+ bool bval;
+ int ival;
+ u8 mask = 0;
+ u8 val = 0;
+ int ret;
+
+ mask |= MAX77620_CNFGGLBL1_LBDAC_EN;
+ bval = of_property_read_bool(dev->of_node,
+ "maxim,low-battery-dac-enable");
+ if (bval)
+ val |= MAX77620_CNFGGLBL1_LBDAC_EN;
+
+ mask |= MAX77620_CNFGGLBL1_LBRSTEN | MAX77620_CNFGGLBL1_MPPLD;
+ ival = of_property_match_string(dev->of_node,
+ "maxim,low-battery-mode", "shutdown");
+ if (ival < 0)
+ val |= MAX77620_CNFGGLBL1_LBRSTEN;
+ else
+ val |= MAX77620_CNFGGLBL1_MPPLD;
+
+ ret = regmap_update_bits(chip->rmap, MAX77620_REG_CNFGGLBL1, mask, val);
+ if (ret < 0)
+ dev_err(dev, "Reg CNFGGLBL1 update failed: %d\n", ret);
+ return ret;
+}
+
static int max77620_read_es_version(struct max77620_chip *chip)
{
unsigned int val;
@@ -563,7 +592,11 @@ static int max77620_probe(struct i2c_client *client,
if (ret < 0)
return ret;
- ret = devm_mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE,
+ ret = max77620_init_low_battery_monitor(chip);
+ if (ret < 0)
+ return ret;
+
+ ret = devm_mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE,
mfd_cells, n_mfd_cells, NULL, 0,
regmap_irq_get_domain(chip->top_irq_data));
if (ret < 0) {
--
2.19.2
[PATCH v3 1/4] mfd: max77620: Add backup battery charger support
Add PMIC configurations for backup battery charger, which
is a constant voltage and constant current style charger
with a series output resistance.
The max77620 register CNFGBBC(addr: 0x04) defines the
parameters of backup battery charger. This patch adds
support for it.
Signed-off-by: Laxman Dewangan
Signed-off-by: Venkat Reddy Talla
Signed-off-by: Mark Zhang
---
drivers/mfd/max77620.c | 80 ++
1 file changed, 80 insertions(+)
diff --git a/drivers/mfd/max77620.c b/drivers/mfd/max77620.c
index d8ddd1a6f304..494d98357f65 100644
--- a/drivers/mfd/max77620.c
+++ b/drivers/mfd/max77620.c
@@ -398,6 +398,82 @@ static int max77620_initialise_fps(struct max77620_chip
*chip)
return 0;
}
+static int max77620_init_backup_battery_charging(struct max77620_chip *chip)
+{
+ struct device *dev = chip->dev;
+ struct device_node *np;
+ u32 pval;
+ u8 config;
+ int charging_current;
+ int charging_voltage;
+ int resistor;
+ int ret;
+
+ np = of_get_child_by_name(dev->of_node, "backup-battery");
+ if (!np) {
+ dev_info(dev, "Backup battery charging support disabled\n");
+ ret = regmap_update_bits(chip->rmap, MAX77620_REG_CNFGBBC,
+MAX77620_CNFGBBC_ENABLE, 0);
+ if (ret < 0)
+ dev_err(dev, "Failed to update CNFGBBC: %d\n", ret);
+ return ret;
+ }
+
+ ret = of_property_read_u32(np,
+ "maxim,charging-current-microamp", );
+ charging_current = (!ret) ? pval : 50;
+
+ ret = of_property_read_u32(np,
+ "maxim,charging-voltage-microvolt", );
+ charging_voltage = (!ret) ? pval : 250;
+ charging_voltage /= 1000;
+
+ ret = of_property_read_u32(np,
+ "maxim,output-resister-ohms", );
+ resistor = (!ret) ? pval : 1000;
+
+ config = MAX77620_CNFGBBC_ENABLE;
+ if (charging_current <= 50)
+ config |= 0 << MAX77620_CNFGBBC_CURRENT_SHIFT;
+ else if (charging_current <= 100)
+ config |= 3 << MAX77620_CNFGBBC_CURRENT_SHIFT;
+ else if (charging_current <= 200)
+ config |= 0 << MAX77620_CNFGBBC_CURRENT_SHIFT;
+ else if (charging_current <= 400)
+ config |= 3 << MAX77620_CNFGBBC_CURRENT_SHIFT;
+ else if (charging_current <= 600)
+ config |= 1 << MAX77620_CNFGBBC_CURRENT_SHIFT;
+ else
+ config |= 2 << MAX77620_CNFGBBC_CURRENT_SHIFT;
+
+ if (charging_current > 100)
+ config |= MAX77620_CNFGBBC_LOW_CURRENT_DISABLE;
+
+ if (charging_voltage <= 2500)
+ config |= 0 << MAX77620_CNFGBBC_VOLTAGE_SHIFT;
+ else if (charging_voltage <= 3000)
+ config |= 1 << MAX77620_CNFGBBC_VOLTAGE_SHIFT;
+ else if (charging_voltage <= 3300)
+ config |= 2 << MAX77620_CNFGBBC_VOLTAGE_SHIFT;
+ else
+ config |= 3 << MAX77620_CNFGBBC_VOLTAGE_SHIFT;
+
+ if (resistor <= 100)
+ config |= 0 << MAX77620_CNFGBBC_RESISTOR_SHIFT;
+ else if (resistor <= 1000)
+ config |= 1 << MAX77620_CNFGBBC_RESISTOR_SHIFT;
+ else if (resistor <= 3000)
+ config |= 2 << MAX77620_CNFGBBC_RESISTOR_SHIFT;
+ else if (resistor <= 6000)
+ config |= 3 << MAX77620_CNFGBBC_RESISTOR_SHIFT;
+
+ ret = regmap_write(chip->rmap, MAX77620_REG_CNFGBBC, config);
+ if (ret < 0)
+ dev_err(dev, "Reg 0x%02x write failed, %d\n",
+ MAX77620_REG_CNFGBBC, ret);
+ return ret;
+}
+
static int max77620_read_es_version(struct max77620_chip *chip)
{
unsigned int val;
@@ -483,6 +559,10 @@ static int max77620_probe(struct i2c_client *client,
if (ret < 0)
return ret;
+ ret = max77620_init_backup_battery_charging(chip);
+ if (ret < 0)
+ return ret;
+
ret = devm_mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE,
mfd_cells, n_mfd_cells, NULL, 0,
regmap_irq_get_domain(chip->top_irq_data));
--
2.19.2
Re: [PATCH] livepatch: Enforce reliable stack trace as config dependency
On Mon, Feb 11, 2019 at 08:08:13AM -0600, Josh Poimboeuf wrote:
> On Sat, Feb 09, 2019 at 02:47:28PM +0530, Kamalesh Babulal wrote:
> > After removal of the immediate flag by commit d0807da78e11
> > ("livepatch: Remove immediate feature"), reliable stack trace became
> > enforcing dependency for livepatch support on any architecture. In
> > the current code, we ensure that the dependency is met when
> > enabling the patch during the module load.
> >
> > This dependency check can be improved by moving it to the Kconfig,
> > which disables the support for livepatching in the kernel for unmet
> > dependencies. This patch moves both HAVE_RELIABLE_STACKTRACE and
> > STACKTRACE under config LIVEPATCH, it also removes the
> > klp_have_reliable_stack() function.
> >
> > Loading a livepatching module on an architecture where reliable
> > stack trace is yet to be implemented, the user should see:
> >
> > insmod: ERROR: could not insert module ./livepatch-sample.ko: Invalid
> > module format
> >
> > ...
> > [ 286.453463] livepatch_sample: module is marked as livepatch module, but
> > livepatch support is disabled
>
> Wouldn't the module fail to build in the first place, since
> CONFIG_LIVEPATCH is disabled?
Yes, with this patch applied, the livepatch modules will fail to build.
The intention was to paste the output of a module load, marked as the
livepatch but without the reliable stack trace support. I used the
previously compiled livepatch sample module for the illustration but
yeah we would not have a functioning module build in the first place.
>
> Anyway, I'm not sure about this approach. This patch makes the s390
> livepatch code no longer compilable, turning it into completely dead
> code. So if something changes in the s390 code which causes it to stop
> compiling, nobody will notice.
Fair point, we can drop this patch in favor of getting compile time
testing for s390.
>
> I think I'd rather go in the opposite direction: allow the patches to be
> loaded. Then they can be forced, if needed. That enables both compile
> and runtime testing. That way we don't make any backward progress,
> until such arches get reliable stacktraces.
klp_have_reliable_stack() enforces implementation of reliable
stack trace and run time testing will not be complete with we returning
after the check. We can re-think about enforcing the dependency after
we have the reliable stack trace for s390.
--
Kamalesh
Re: [PATCH -mm -V7] mm, swap: fix race between swapoff and some swap operations
Daniel Jordan writes:
> On Mon, Feb 11, 2019 at 04:38:46PM +0800, Huang, Ying wrote:
>> +struct swap_info_struct *get_swap_device(swp_entry_t entry)
>> +{
>> +struct swap_info_struct *si;
>> +unsigned long type, offset;
>> +
>> +if (!entry.val)
>> +goto out;
>
>> +type = swp_type(entry);
>> +si = swap_type_to_swap_info(type);
>
> These lines can be collapsed into swp_swap_info if you want.
Yes. I can use that function to reduce another line from the patch.
Thanks! Will do that.
>> +if (!si)
>> +goto bad_nofile;
>> +
>> +preempt_disable();
>> +if (!(si->flags & SWP_VALID))
>> +goto unlock_out;
>
> After Hugh alluded to barriers, it seems the read of SWP_VALID could be
> reordered with the write in preempt_disable at runtime. Without smp_mb()
> between the two, couldn't this happen, however unlikely a race it is?
>
> CPU0CPU1
>
> __swap_duplicate()
> get_swap_device()
> // sees SWP_VALID set
>swapoff
>p->flags &= ~SWP_VALID;
>spin_unlock(>lock); // pair w/
> smp_mb
>...
>stop_machine(...)
>p->swap_map = NULL;
> preempt_disable()
> read NULL p->swap_map
Andrea has helped to explain this.
Best Regards,
Huang, Ying
Re: [PATCH 3/3] mm/mincore: provide mapped status when cached status is not allowed
On Tue 12-02-19 04:44:30, Jiri Kosina wrote:
> On Fri, 1 Feb 2019, Vlastimil Babka wrote:
>
> > >> After "mm/mincore: make mincore() more conservative" we sometimes
> > >> restrict the
> > >> information about page cache residency, which we have to do without
> > >> breaking
> > >> existing userspace, if possible. We thus fake the resulting values as 1,
> > >> which
> > >> should be safer than faking them as 0, as there might theoretically
> > >> exist code
> > >> that would try to fault in the page(s) until mincore() returns 1.
> > >>
> > >> Faking 1 however means that such code would not fault in a page even if
> > >> it was
> > >> not in page cache, with unwanted performance implications. We can
> > >> improve the
> > >> situation by revisting the approach of 574823bfab82 ("Change mincore()
> > >> to count
> > >> "mapped" pages rather than "cached" pages") but only applying it to
> > >> cases where
> > >> page cache residency check is restricted. Thus mincore() will return 0
> > >> for an
> > >> unmapped page (which may or may not be resident in a pagecache), and 1
> > >> after
> > >> the process faults it in.
> > >>
> > >> One potential downside is that mincore() will be again able to recognize
> > >> when a
> > >> previously mapped page was reclaimed. While that might be useful for some
> > >> attack scenarios, it's not as crucial as recognizing that somebody else
> > >> faulted
> > >> the page in, and there are also other ways to recognize reclaimed pages
> > >> anyway.
> > >
> > > Is this really worth it? Do we know about any specific usecase that
> > > would benefit from this change? TBH I would rather wait for the report
> > > than add a hard to evaluate side channel.
> >
> > Well it's not that complicated IMHO. Linus said it's worth trying, so
> > let's see how he likes the result. The side channel exists anyway as
> > long as process can e.g. check if its rss shrinked, and I doubt we are
> > going to remove that possibility.
>
> So, where do we go from here?
>
> Either Linus and Andrew like the mincore() return value tweak, or this
> could be further discussed (*). But in either of the cases, I think
> patches 1 and 2 should be at least queued for 5.1.
I would go with patch 1 for 5.1. Patches 2 still sounds controversial or
incomplete to me. And patch 3, well I will leave the decision to
Andrew/Linus.
> (*) I'd personally include it as well, as I don't see how it would break
> anything, it's pretty straightforward, and brings back some sanity to
> mincore() return value.
--
Michal Hocko
SUSE Labs
Re: [PATCH 4.9 000/137] 4.9.156-stable review
On Mon, 11 Feb 2019 at 20:35, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.156 release. > There are 137 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Feb 13 14:17:22 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.156-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.9.156-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: 850a7fe2357647de8e0edd435525ac5a19e99cbf git describe: v4.9.155-138-g850a7fe23576 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.155-138-g850a7fe23576 No regressions (compared to build v4.9.155) No fixes (compared to build v4.9.155) Ran 22129 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.14 000/205] 4.14.99-stable review
On Mon, 11 Feb 2019 at 20:25, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.99 release. > There are 205 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Feb 13 14:17:19 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.99-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.14.99-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 151d6387b56840f9daaf468ec2212d2ac9ccc047 git describe: v4.14.98-206-g151d6387b568 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.98-206-g151d6387b568 No regressions (compared to build v4.14.98) No fixes (compared to build v4.14.98) Ran 7 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * spectre-meltdown-checker-test * ltp-timers-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: Bug#919356: Licensing of include/linux/hash.h
Martin Steigerwald writes: > Well the file has in its header: > > /* Fast hashing routine for a long. >(C) 2002 William Lee Irwin III, IBM */ > > /* > * Knuth recommends primes in approximately golden ratio to the maximum > * integer representable by a machine word for multiplicative hashing. > * Chuck Lever verified the effectiveness of this technique: > * http://www.citi.umich.edu/techreports/reports/citi-tr-00-1.pdf > * > * These primes are chosen to be bit-sparse, that is operations on > * them can use shifts and additions instead of multiplications for > * machines where multiplications are slow. > */ > > It has been quite a while ago. I bet back then I did not regard this > as license information since it does not specify a license. Thus I > assumed it to be GPL-2 as the other files which have no license boiler > plate. I.e.: Check file is it has different license, if not, then > assume it has license as specified in COPYING. > > Not specifying a license can however also mean in this context that it > has no license as the file contains copyright information from another > author. If a work (even one file) “has no license”, that means no special permissions are granted and normal copyright applies: All rights reserved, i.e. not redistributable. So, no license is grounds to consider a work non-free and non-redistributable. If, on the other hand, the file is to be free software, there would need to be a clear grant of some free software license to that work. Given the confusion over this file, I would consider it a significant risk to just assume we have GPLv2 permissions without being told that explicitly by the copyright holder. Rather, the reason we are seeking a clearly-granted free license for this one file, is because we are trying to replace a probably non-free file with the same code in it. It seems we need to keep looking, and in the meantime assume we have no free license in this file. -- \ “If the desire to kill and the opportunity to kill came always | `\ together, who would escape hanging?” —Mark Twain, _Following | _o__) the Equator_ | Ben Finney
Re: Bug#919356: Licensing of include/linux/hash.h
Martin Steigerwald writes: > Well the file has in its header: > > /* Fast hashing routine for a long. >(C) 2002 William Lee Irwin III, IBM */ > > /* > * Knuth recommends primes in approximately golden ratio to the maximum > * integer representable by a machine word for multiplicative hashing. > * Chuck Lever verified the effectiveness of this technique: > * http://www.citi.umich.edu/techreports/reports/citi-tr-00-1.pdf > * > * These primes are chosen to be bit-sparse, that is operations on > * them can use shifts and additions instead of multiplications for > * machines where multiplications are slow. > */ > > It has been quite a while ago. I bet back then I did not regard this > as license information since it does not specify a license. Thus I > assumed it to be GPL-2 as the other files which have no license boiler > plate. I.e.: Check file is it has different license, if not, then > assume it has license as specified in COPYING. > > Not specifying a license can however also mean in this context that it > has no license as the file contains copyright information from another > author. If a work (even one file) “has no license”, that means no special permissions are granted and normal copyright applies: All rights reserved, i.e. not redistributable. So, no license is grounds to consider a work non-free and non-redistributable. If, on the other hand, the file is to be free software, there would need to be a clear grant of some free software license to that work. Given the confusion over this file, I would consider it a significant risk to just assume we have GPLv2 permissions without being told that explicitly by the copyright holder. Rather, the reason we are seeking a clearly-granted free license for this one file, is because we are trying to replace a probably non-free file with the same code in it. It seems we need to keep looking, and in the meantime assume we have no free license in this file. -- \ “If the desire to kill and the opportunity to kill came always | `\ together, who would escape hanging?” —Mark Twain, _Following | _o__) the Equator_ | Ben Finney
Re: Bug#919356: Licensing of include/linux/hash.h
Martin Steigerwald writes: > Well the file has in its header: > > /* Fast hashing routine for a long. >(C) 2002 William Lee Irwin III, IBM */ > > /* > * Knuth recommends primes in approximately golden ratio to the maximum > * integer representable by a machine word for multiplicative hashing. > * Chuck Lever verified the effectiveness of this technique: > * http://www.citi.umich.edu/techreports/reports/citi-tr-00-1.pdf > * > * These primes are chosen to be bit-sparse, that is operations on > * them can use shifts and additions instead of multiplications for > * machines where multiplications are slow. > */ > > It has been quite a while ago. I bet back then I did not regard this > as license information since it does not specify a license. Thus I > assumed it to be GPL-2 as the other files which have no license boiler > plate. I.e.: Check file is it has different license, if not, then > assume it has license as specified in COPYING. > > Not specifying a license can however also mean in this context that it > has no license as the file contains copyright information from another > author. If a work (even one file) “has no license”, that means no special permissions are granted and normal copyright applies: All rights reserved, i.e. not redistributable. So, no license is grounds to consider a work non-free and non-redistributable. If, on the other hand, the file is to be free software, there would need to be a clear grant of some free software license to that work. Given the confusion over this file, I would consider it a significant risk to just assume we have GPLv2 permissions without being told that explicitly by the copyright holder. Rather, the reason we are seeking a clearly-granted free license for this one file, is because we are trying to replace a probably non-free file with the same code in it. It seems we need to keep looking, and in the meantime assume we have no free license in this file. -- \ “If the desire to kill and the opportunity to kill came always | `\ together, who would escape hanging?” —Mark Twain, _Following | _o__) the Equator_ | Ben Finney
Re: [PATCH 4.20 282/352] fs/proc/base.c: use ns_capable instead of capable for timerslack_ns
On Mon, Feb 11, 2019 at 07:02:06PM -0600, Eric W. Biederman wrote:
> Greg Kroah-Hartman writes:
>
> > 4.20-stable review patch. If anyone has any objections, please let me
> > know.
>
> No objection. But I think of this as a feature addition rather than a
> fix for something. As a feature that we now allow something we
> previously did not does this qualify for a backport to stable?
Hi,
I had the exact same thought when I saw this this morning, and was planning
on replying tonight.
> It is probably no more harmful in this instance than adding PCI IDs to a
> driver. So I am not worried. I am curious the current guidelines
> are.
>
> In most cases a small relaxation of permissions like this requires a lot
> of bug fixing as typically code protected by capable(CAP_XXX) has been
> written and tested assuming a trusted root user. Those bug fixes are
> many times too large for a stable backport.
>
> Eric
>
>
> > --
> >
> > [ Upstream commit 8da0b4f692c6d90b09c91f271517db746a22ff67 ]
> >
> > Access to timerslack_ns is controlled by a process having CAP_SYS_NICE
> > in its effective capability set, but the current check looks in the root
> > namespace instead of the process' user namespace. Since a process is
> > allowed to do other activities controlled by CAP_SYS_NICE inside a
> > namespace, it should also be able to adjust timerslack_ns.
> >
> > Link: http://lkml.kernel.org/r/20181030180012.232896-1-bmgor...@google.com
> > Signed-off-by: Benjamin Gordon
> > Acked-by: "Eric W. Biederman"
> > Cc: John Stultz
> > Cc: "Eric W. Biederman"
> > Cc: Kees Cook
> > Cc: "Serge E. Hallyn"
> > Cc: Thomas Gleixner
> > Cc: Arjan van de Ven
> > Cc: Oren Laadan
> > Cc: Ruchi Kandoi
> > Cc: Rom Lemarchand
> > Cc: Todd Kjos
> > Cc: Colin Cross
> > Cc: Nick Kralevich
> > Cc: Dmitry Shmidt
> > Cc: Elliott Hughes
> > Cc: Alexey Dobriyan
> > Signed-off-by: Andrew Morton
> > Signed-off-by: Linus Torvalds
> > Signed-off-by: Sasha Levin
> > ---
> > fs/proc/base.c | 12 +---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > index ce3465479447..98525af0953e 100644
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -2356,10 +2356,13 @@ static ssize_t timerslack_ns_write(struct file
> > *file, const char __user *buf,
> > return -ESRCH;
> >
> > if (p != current) {
> > - if (!capable(CAP_SYS_NICE)) {
> > + rcu_read_lock();
> > + if (!ns_capable(__task_cred(p)->user_ns, CAP_SYS_NICE)) {
> > + rcu_read_unlock();
> > count = -EPERM;
> > goto out;
> > }
> > + rcu_read_unlock();
> >
> > err = security_task_setscheduler(p);
> > if (err) {
> > @@ -2392,11 +2395,14 @@ static int timerslack_ns_show(struct seq_file *m,
> > void *v)
> > return -ESRCH;
> >
> > if (p != current) {
> > -
> > - if (!capable(CAP_SYS_NICE)) {
> > + rcu_read_lock();
> > + if (!ns_capable(__task_cred(p)->user_ns, CAP_SYS_NICE)) {
> > + rcu_read_unlock();
> > err = -EPERM;
> > goto out;
> > }
> > + rcu_read_unlock();
> > +
> > err = security_task_getscheduler(p);
> > if (err)
> > goto out;
[PATCH] drm/mediatek: add mipi_tx driver for mt8183
This patch adds mipi tx driver support for mt8183. Mipi_tx of mt8183 is very different to mt8173. 1.Separate mipi tx setting to mtk_mt8173_mipi_tx.c for mt8173 2.Separate mipi tx setting to mtk_mt8183_mipi_tx.c for mt8183 3.To reuse the common code, make the common functions in mtk_mipi_tx.c Signed-off-by: Jitao Shi --- drivers/gpu/drm/mediatek/Makefile | 2 + drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 352 ++ drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 52 +++ drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c | 290 +++ drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 168 + 5 files changed, 549 insertions(+), 315 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_mipi_tx.h create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile index 82ae49c64221..8067a4be8311 100644 --- a/drivers/gpu/drm/mediatek/Makefile +++ b/drivers/gpu/drm/mediatek/Makefile @@ -12,6 +12,8 @@ mediatek-drm-y := mtk_disp_color.o \ mtk_drm_plane.o \ mtk_dsi.o \ mtk_mipi_tx.o \ + mtk_mt8173_mipi_tx.o \ + mtk_mt8183_mipi_tx.o \ mtk_dpi.o obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c index 90e913108950..7591a38ca565 100644 --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c @@ -11,292 +11,45 @@ * GNU General Public License for more details. */ -#include -#include -#include -#include -#include -#include -#include -#include - -#define MIPITX_DSI_CON 0x00 -#define RG_DSI_LDOCORE_EN BIT(0) -#define RG_DSI_CKG_LDOOUT_EN BIT(1) -#define RG_DSI_BCLK_SEL(3 << 2) -#define RG_DSI_LD_IDX_SEL (7 << 4) -#define RG_DSI_PHYCLK_SEL (2 << 8) -#define RG_DSI_DSICLK_FREQ_SEL BIT(10) -#define RG_DSI_LPTX_CLMP_ENBIT(11) - -#define MIPITX_DSI_CLOCK_LANE 0x04 -#define MIPITX_DSI_DATA_LANE0 0x08 -#define MIPITX_DSI_DATA_LANE1 0x0c -#define MIPITX_DSI_DATA_LANE2 0x10 -#define MIPITX_DSI_DATA_LANE3 0x14 -#define RG_DSI_LNTx_LDOOUT_EN BIT(0) -#define RG_DSI_LNTx_CKLANE_EN BIT(1) -#define RG_DSI_LNTx_LPTX_IPLUS1BIT(2) -#define RG_DSI_LNTx_LPTX_IPLUS2BIT(3) -#define RG_DSI_LNTx_LPTX_IMINUSBIT(4) -#define RG_DSI_LNTx_LPCD_IPLUS BIT(5) -#define RG_DSI_LNTx_LPCD_IMINUSBIT(6) -#define RG_DSI_LNTx_RT_CODE(0xf << 8) - -#define MIPITX_DSI_TOP_CON 0x40 -#define RG_DSI_LNT_INTR_EN BIT(0) -#define RG_DSI_LNT_HS_BIAS_EN BIT(1) -#define RG_DSI_LNT_IMP_CAL_EN BIT(2) -#define RG_DSI_LNT_TESTMODE_EN BIT(3) -#define RG_DSI_LNT_IMP_CAL_CODE(0xf << 4) -#define RG_DSI_LNT_AIO_SEL (7 << 8) -#define RG_DSI_PAD_TIE_LOW_EN BIT(11) -#define RG_DSI_DEBUG_INPUT_EN BIT(12) -#define RG_DSI_PRESERVE(7 << 13) - -#define MIPITX_DSI_BG_CON 0x44 -#define RG_DSI_BG_CORE_EN BIT(0) -#define RG_DSI_BG_CKEN BIT(1) -#define RG_DSI_BG_DIV (0x3 << 2) -#define RG_DSI_BG_FAST_CHARGE BIT(4) -#define RG_DSI_VOUT_MSK(0x3 << 5) -#define RG_DSI_V12_SEL (7 << 5) -#define RG_DSI_V10_SEL (7 << 8) -#define RG_DSI_V072_SEL(7 << 11) -#define RG_DSI_V04_SEL (7 << 14) -#define RG_DSI_V032_SEL(7 << 17) -#define RG_DSI_V02_SEL (7 << 20) -#define RG_DSI_BG_R1_TRIM (0xf << 24) -#define RG_DSI_BG_R2_TRIM (0xf << 28) - -#define MIPITX_DSI_PLL_CON00x50 -#define RG_DSI_MPPLL_PLL_ENBIT(0) -#define RG_DSI_MPPLL_DIV_MSK (0x1ff << 1) -#define RG_DSI_MPPLL_PREDIV(3 << 1) -#define RG_DSI_MPPLL_TXDIV0(3 << 3) -#define RG_DSI_MPPLL_TXDIV1(3 << 5) -#define RG_DSI_MPPLL_POSDIV(7 << 7) -#define RG_DSI_MPPLL_MONVC_EN BIT(10) -#define RG_DSI_MPPLL_MONREF_EN BIT(11) -#define RG_DSI_MPPLL_VOD_ENBIT(12) - -#define MIPITX_DSI_PLL_CON10x54 -#define RG_DSI_MPPLL_SDM_FRA_ENBIT(0) -#define RG_DSI_MPPLL_SDM_SSC_PH_INIT BIT(1) -#define RG_DSI_MPPLL_SDM_SSC_ENBIT(2) -#define RG_DSI_MPPLL_SDM_SSC_PRD (0x << 16) - -#define MIPITX_DSI_PLL_CON20x58 - -#define MIPITX_DSI_PLL_TOP 0x64 -#define RG_DSI_MPPLL_PRESERVE (0xff << 8) - -#define MIPITX_DSI_PLL_PWR 0x68 -#define RG_DSI_MPPLL_SDM_PWR_ONBIT(0) -#define RG_DSI_MPPLL_SDM_ISO_ENBIT(1) -#define
linux-next: manual merge of the akpm tree with the bpf tree
Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
net/xdp/xdp_umem.c
between commit:
e451eb510684 ("xsk: share the mmap_sem for page pinning")
from the bpf tree and patch:
"net/xdp/xdp_umem.c: do not use mmap_sem"
from the akpm tree.
I fixed it up (I dropped the akpm tree patch) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp1DHIDJaLdL.pgp
Description: OpenPGP digital signature
Re: [PATCH v4 2/8] clk: samsung: add new clocks for DMC for Exynos5422 SoC
Hi Lukasz,
On 19. 2. 11. 오후 8:11, Lukasz Luba wrote:
> Hi Chanwoo,
>
> On 2/3/19 10:56 AM, Chanwoo Choi wrote:
>> Hi Lukasz,
>>
>> I recommend that please don't send the version up patchset before
>> finishing the discussion.
>>
>> 2019년 2월 2일 (토) 오전 2:47, Lukasz Luba 님이 작성:
>>>
>>> This patch provides support for clocks needed for Dynamic Memory Controller
>>> in Exynos5422 SoC. It adds CDREX base register addresses, new DIV, MUX and
>>> GATE entries.
>>>
>>> Signed-off-by: Lukasz Luba
>>> ---
>>> drivers/clk/samsung/clk-exynos5420.c | 46
>>>
>>> 1 file changed, 42 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>>> b/drivers/clk/samsung/clk-exynos5420.c
>>> index 34cce3c..f1a4f56 100644
>>> --- a/drivers/clk/samsung/clk-exynos5420.c
>>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>>> @@ -132,6 +132,8 @@
>>> #define BPLL_LOCK 0x20010
>>> #define BPLL_CON0 0x20110
>>> #define SRC_CDREX 0x20200
>>> +#define GATE_BUS_CDREX00x20700
>>> +#define GATE_BUS_CDREX10x20704
>>> #define DIV_CDREX0 0x20500
>>> #define DIV_CDREX1 0x20504
>>> #define KPLL_LOCK 0x28000
>>> @@ -248,6 +250,8 @@ static const unsigned long exynos5x_clk_regs[]
>>> __initconst = {
>>> DIV_CDREX1,
>>> SRC_KFC,
>>> DIV_KFC0,
>>> + GATE_BUS_CDREX0,
>>> + GATE_BUS_CDREX1,
>>> };
>>>
>>> static const unsigned long exynos5800_clk_regs[] __initconst = {
>>> @@ -425,6 +429,10 @@ PNAME(mout_group13_5800_p) = { "dout_osc_div",
>>> "mout_sw_aclkfl1_550_cam" };
>>> PNAME(mout_group14_5800_p) = { "dout_aclk550_cam", "dout_sclk_sw" };
>>> PNAME(mout_group15_5800_p) = { "dout_osc_div", "mout_sw_aclk550_cam"
>>> };
>>> PNAME(mout_group16_5800_p) = { "dout_osc_div", "mout_mau_epll_clk" };
>>> +PNAME(mout_mx_mspll_ccore_phy_p) = { "sclk_bpll", "mout_sclk_dpll",
>>> + "mout_sclk_mpll", "ff_dout_spll2",
>>> + "mout_sclk_spll", "mout_sclk_epll"};
>>> +
>>
>> Remove unneeded extra blank line.
> OK
>>
>>>
>>> /* fixed rate clocks generated outside the soc */
>>> static struct samsung_fixed_rate_clock
>>> @@ -450,7 +458,7 @@ static const struct samsung_fixed_factor_clock
>>> static const struct samsung_fixed_factor_clock
>>> exynos5800_fixed_factor_clks[] __initconst = {
>>> FFACTOR(0, "ff_dout_epll2", "mout_sclk_epll", 1, 2, 0),
>>> - FFACTOR(0, "ff_dout_spll2", "mout_sclk_spll", 1, 2, 0),
>>> + FFACTOR(CLK_FF_DOUT_SPLL2, "ff_dout_spll2", "mout_sclk_spll", 1, 2,
>>> 0),
>>> };
>>>
>>> static const struct samsung_mux_clock exynos5800_mux_clks[] __initconst =
>>> {
>>> @@ -472,11 +480,14 @@ static const struct samsung_mux_clock
>>> exynos5800_mux_clks[] __initconst = {
>>> MUX(0, "mout_aclk300_disp1", mout_group5_5800_p, SRC_TOP2, 24, 2),
>>> MUX(0, "mout_aclk300_gscl", mout_group5_5800_p, SRC_TOP2, 28, 2),
>>>
>>> + MUX(CLK_MOUT_MX_MSPLL_CCORE_PHY, "mout_mx_mspll_ccore_phy",
>>> + mout_mx_mspll_ccore_phy_p, SRC_TOP7, 0, 3),
>>> +
>>> MUX(CLK_MOUT_MX_MSPLL_CCORE, "mout_mx_mspll_ccore",
>>> - mout_mx_mspll_ccore_p, SRC_TOP7, 16, 2),
>>> + mout_mx_mspll_ccore_p, SRC_TOP7, 16, 3),
>>> MUX_F(CLK_MOUT_MAU_EPLL, "mout_mau_epll_clk",
>>> mout_mau_epll_clk_5800_p,
>>> SRC_TOP7, 20, 2, CLK_SET_RATE_PARENT, 0),
>>> - MUX(0, "sclk_bpll", mout_bpll_p, SRC_TOP7, 24, 1),
>>> + MUX(CLK_SCLK_BPLL, "sclk_bpll", mout_bpll_p, SRC_TOP7, 24, 1),
>>> MUX(0, "mout_epll2", mout_epll2_5800_p, SRC_TOP7, 28, 1),
>>>
>>> MUX(0, "mout_aclk550_cam", mout_group3_5800_p, SRC_TOP8, 16, 3),
>>> @@ -648,7 +659,7 @@ static const struct samsung_mux_clock
>>> exynos5x_mux_clks[] __initconst = {
>>
>> The newly added clocks by this patch are supported on all
>> Exynos5420/5422/5800?
> The clocks are the same for Exynos5420/5422/5800 DMCs.
>
>> I'm not sure because on the patch description, you only mentioned the
>> Exynos5422 without Exynos5420/Exynos5800.
> The driver code supports currently only Exynos5422 due to specific
> timings inside, but the clocks are for all three Exynos SoCs.
> It does not harm the Exynos5420/5800.
>>
>> As for now, I can't check the Exynos TRM because I'm in holiday until
>> next Wednesday. I will check them with Exynos542-/5422/5800 TRM on
>> next Thursday.
> OK, please add me to the communication thread with them. We will speed
> up the process (I can test something for them if needed).
>>
>>>
>>> MUX(0, "mout_sclk_mpll", mout_mpll_p, SRC_TOP6, 0, 1),
>>> MUX(CLK_MOUT_VPLL, "mout_sclk_vpll", mout_vpll_p, SRC_TOP6, 4, 1),
>>> - MUX(0, "mout_sclk_spll", mout_spll_p, SRC_TOP6, 8, 1),
>>> +
RE: [PATCH v2 6/9] usb: roles: Find the muxes by also matching against the device node
> -Original Message-
> From: Heikki Krogerus
> Sent: 2019年2月11日 18:46
> To: Jun Li
> Cc: Greg Kroah-Hartman ; Andy Shevchenko
> ; Chen Yu ; Hans de
> Goede ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 6/9] usb: roles: Find the muxes by also matching
> against the
> device node
>
> On Mon, Feb 11, 2019 at 09:58:04AM +, Jun Li wrote:
> > Hi Heikki,
> >
> > > @@ -84,7 +85,12 @@ enum usb_role usb_role_switch_get_role(struct
> > > usb_role_switch *sw) }
> > > EXPORT_SYMBOL_GPL(usb_role_switch_get_role);
> > >
> > > -static int __switch_match(struct device *dev, const void *name)
> > > +static int switch_fwnode_match(struct device *dev, const void
> > > +*fwnode) {
> > > + return dev_fwnode(dev) == fwnode;
> >
> > You missed the comment
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkm
> >
> l.org%2Flkml%2F2019%2F1%2F22%2F437data=02%7C01%7Cjun.li%40nx
> p.com
> > %7C8c2d40d5e5d246da34ad08d6900e31cf%7C686ea1d3bc2b4c6fa92cd99c5
> c301635
> > %7C0%7C0%7C636854788040965224sdata=db4gvXKc9InWiltsweetxXYr
> tPbtfX
> > jshPh%2FnvA24ig%3Dreserved=0
> >
> > return dev_fwnode(dev->parent) == fwnode;
>
> That's actually not the case. struct usb_role_switch_desc has a member for
> fwnode,
> and that's what we use with the actual mux device. Check
> usb_role_switch_register():
>
> ...
> sw->dev.fwnode = desc->fwnode;
> ...
>
> Sorry for not realizing it before.
So desc->fwnode should be initialized before do usb_role_switch_register()?
But seems usb_role_switch_desc is a read-only object so can't be set at runtime.
usb_controller_node {
...
usb-role-switch;
port {
sw_provider_node: endpoint {
remote-endpoint = <_consumer_node>;
};
};
};
typec_node {
...
port {
sw_consumer_node: endpoint {
remote-endpoint = <_provider_node>;
};
};
};
Is my understanding correct?
Thanks
Jun
>
>
> thanks,
>
> --
> heikki
[PATCH] mei: expand minor range when registering chrdev region
Actually, total amount of available minor number
for a single major is MINORMARK + 1. So expand
minor range when registering chrdev region.
Signed-off-by: Chengguang Xu
---
drivers/misc/mei/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c
index 87281b3695e6..3df54f1e1a8b 100644
--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -869,7 +869,7 @@ static const struct file_operations mei_fops = {
static struct class *mei_class;
static dev_t mei_devt;
-#define MEI_MAX_DEVS MINORMASK
+#define MEI_MAX_DEVS (MINORMASK + 1)
static DEFINE_MUTEX(mei_minor_lock);
static DEFINE_IDR(mei_idr);
--
2.20.1
Re: [RESEND PATCH v2 17/33] ARM: davinci: aintc: move timer-specific irq_set_handler() out of irq.c
On 11/02/19 6:30 PM, Marc Zyngier wrote: > On 11/02/2019 12:25, Bartosz Golaszewski wrote: >> +/* >> + * Nobody knows why anymore, but this interrupt has been handled as >> + * a level irq from the very beginning of davinci support in mainline >> + * linux. >> + */ >> +irq_set_handler(DAVINCI_INTC_IRQ(IRQ_TINT1_TINT34), handle_level_irq); >> + > > Now, the real question is: why isn't that set as part of the > set_irq_type() callback, instead of hardcoding it in the platform? > > This is exactly the kind of information that should come as part of the > DT or from the driver as one of the request_irq() flags. > > It would save quite a bit of boilerplate code. True, but I would keep this series feature/bug compatible with existing code. Without that, tracking regression reports will be a nightmare. Its a pretty major change already. We can (and should) fix this, but I prefer thats done as follow-up patch after this series is merged. That way a revert is easy. BTW, I don't quite see which in-kernel module uses this interrupt. It might be some out-of-tree code, or some code that since got removed from kernel. Thanks, Sekhar
Re: [PATCH v2 0/2] drivers: devfreq: fix and optimize workqueue mechanism
Hi Lukasz, On 19. 2. 12. 오전 12:30, Lukasz Luba wrote: > This patch set changes workqueue related features in devfreq framework. > First patch switches to delayed work instead of deferred. > The second switches to regular system work and deletes custom 'devfreq'. > > Using deferred work in this context might harm the system performance. > When the CPU enters idle, deferred work is not fired. The devfreq device's > utilization does not have to be connected with a particular CPU. > The drivers for GPUs, Network on Chip, cache L3 rely on devfreq governor. > They all are missing opportunity to check the HW state and react when > the deferred work is not fired. > A corner test case, when Dynamic Memory Controller is utilized by CPUs running > on full speed, might show x5 worse performance if the crucial CPU is in idle. The devfreq framework keeps the balancing between performance and power-consumption. It is wrong to focus on only either performance or power. This cover-letter focus on the only performance without any power-consumption disadvantages. It is easy to raise the performance with short sampling rate with polling modes. To get the performance, it is good as short as possible of period. Sometimes, when cpu is idle, the device might require the busy state. It is very difficult to catch the always right timing between them. Also, this patch cannot prevent the unneeded wakeup from idle state. Apparently, it only focuses on performance without considering the power-consumption disadvantage. In the embedded device, the power-consumption is very important point. We can not ignore the side effect. Always, I hope to improve the devfreq framwork more that older. But, frankly, it is difficult to agree because it only consider the performance without considering the side-effect. The power management framework always have to consider the power-consumption issue. This point is always true. > > Changes: > v2: > - single patch split into two > - added cover letter > > link for the previous version and discussion: > https://marc.info/?l=linux-pm=154904631226997=2 > > Regards, > Lukasz Luba > > Lukasz Luba (2): > drivers: devfreq: change devfreq workqueue mechanism > drivers: devfreq: change deferred work into delayed > > drivers/devfreq/devfreq.c | 27 +++ > 1 file changed, 7 insertions(+), 20 deletions(-) > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr
On Tue, Feb 12, 2019 at 4:48 AM Dave Young wrote: > > On 02/06/19 at 08:08pm, Dave Young wrote: > > On 02/05/19 at 09:15am, Borislav Petkov wrote: > > > On Mon, Feb 04, 2019 at 03:30:16PM -0700, Jerry Hoemann wrote: > > > > Is your objection only to the second fallback of allocating > > > > memory above >= 4GB? Or are you objecting to allocating from > > > > (896 .. 4GB) as well? > > > > > > My problem is why should the user need to specify high or low allocation > > > explicitly when we can handle all that in the kernel automatically. > > > > > > The presence of crashkernel= on the cmdline sure means that the user > > > wants to allocate memory for a second kernel. > > > > > > Now, if the requested allocation fails, we say: > > > > > > Error reserving crashkernel > > > > > > So, instead of saying that, we can *try* *again* and say > > > > > > Error reserving requested crashkernel at @..., attempting a high range. > > > > > > and run memblock_find_in_range() on the other regions which we deemed > > > are ok to allocate from. > > > > > > Why aren't we doing that by default instead of placing all those > > > different options in front of the user and expecting her/him to know > > > something about all those magic ranges? > > > > As we talked in another reply, for the >4G allocation we can not avoid > > the swiotlb issue, but if one request for 256M in high region and we > > allocate the low part automatically, it will eat more memory eg. 512M. > > > > But probably in case allacation failed in low region ,high is a must for > > kdump > > reservation, since no other choices perhaps we can make that as you said > > That is exactly what Pingfan is doing in this patch. > > Even we make it automatic in kernel, but we have to have some default > value for swiotlb in case crashkernel can not find a free region under 4G. > So this default value can not work for every use cases, people need > manually use crashkernel=,low and crashkernel=,high in case > crashkernel=X does not work. One can tune it for their use: > > 1) crashkernel=X reservation fails, likely the ,low default value is > still too big, one can shrink the value and manually try other value > 2) crashkernel=X reserve successfully on high memory and along with some > default low memory region. But the low region is not enough. In this > case one can increase the > > This should answer the question why ,high and ,low is still needed. > > But for above consumption 1), KASLR can still cause default ,low memory > failed to reserve. So I wonder if KASLR can skip the 0-896M if the > system memory is big enough. > A little fix about the comment. Refer to reserve_crashkernel_low(), low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN); So it should try 0~4G for ",low". And the default size for low is 256M. Given the limited memory region reserved by other component before crashkernel, we always can find a continuous chunk of 256M inside the fragmented [0,4G], which is split by initrd, KASLR. Thanks, Pingfan
Re: [PATCH v2] fs: Allow opening only regular files during execve().
Tetsuo Handa wrote:
> Andrew Morton wrote:
> > > --- a/fs/open.c
> > > +++ b/fs/open.c
> > > @@ -733,6 +733,12 @@ static int do_dentry_open(struct file *f,
> > > return 0;
> > > }
> > >
> > > + /* Any file opened for execve()/uselib() has to be a regular file. */
> > > + if (unlikely(f->f_flags & FMODE_EXEC && !S_ISREG(inode->i_mode))) {
> > > + error = -EACCES;
> > > + goto cleanup_file;
> > > + }
> > > +
> > > if (f->f_mode & FMODE_WRITE && !special_file(inode->i_mode)) {
> > > error = get_write_access(inode);
> > > if (unlikely(error))
> >
> > This change sounds legitimate for various other reasons, but it's a
> > concern that this locking error occurred in the first place. There's a
> > problem somewhere (probably the pipe code) which may bite us in other
> > situations, even with this workaround in place.
> >
> >
>
> This error seems to be introduced in 2.6.39-rc1 by commit a9712bc12c40c172
> ("deal with races in /proc/*/{syscall,stack,personality}"). Thus, I don't
> think that this patch will bite us in other situations.
> Al, how do you want to handle this?
>
According to bisection, commit 8924feff66f35fe2 ("splice: lift pipe_lock out of
splice_to_pipe()")
added in 4.9-rc1 is the trigger of this deadlock. Thus, the fix needs to go to
4.9+.
# bad: [abb5a14fa20fdd400995926134b7be9eb8ce6048] Merge branch 'work.misc' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
# good: [c8d2bc9bc39ebea8437fd974fdbc21847bb897a3] Linux 4.8
# good: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
# good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6
# good: [b562e44f507e863c6792946e4e1b1449fbbac85d] Linux 4.5
# good: [afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc] Linux 4.4
# good: [6a13feb9c82803e2b815eca72fa7a9f5561d7861] Linux 4.3
# good: [64291f7db5bd8150a74ad2036f1037e6a0428df2] Linux 4.2
# good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1
# good: [39a8804455fb23f09157341d3ba7db6d7ae6ee76] Linux 4.0
git bisect start 'HEAD' 'v4.8' 'v4.7' 'v4.6' 'v4.5' 'v4.4' 'v4.3' 'v4.2' 'v4.1'
'v4.0'
# good: [5691f0e9a3e7855832d5fd094801bf600347c2d0] Merge tag 'sound-4.9-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect good 5691f0e9a3e7855832d5fd094801bf600347c2d0
# good: [530a70617cb6325bd7781e7a993d732d6d37915a] Merge branch 'greybus' into
staging-testing
git bisect good 530a70617cb6325bd7781e7a993d732d6d37915a
# good: [bc75450cc3db3485db1e289fef8c1028ba38296a] Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
git bisect good bc75450cc3db3485db1e289fef8c1028ba38296a
# bad: [00e729c933950cda694c49260ff67855fdbfd00a] Merge tag 'armsoc-dt' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad 00e729c933950cda694c49260ff67855fdbfd00a
# bad: [5acb6052ce304d89e36f599f1e27a7c63d389ca0] Merge tag 'armsoc-defconfig'
of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad 5acb6052ce304d89e36f599f1e27a7c63d389ca0
# bad: [d1f5323370fceaed43a7ee38f4c7bfc7e70f28d0] Merge branch
'work.splice_read' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect bad d1f5323370fceaed43a7ee38f4c7bfc7e70f28d0
# good: [87840a2b7e048018d18d60bdac5c09224de85370] Merge branch 'i2c/for-4.9'
of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
git bisect good 87840a2b7e048018d18d60bdac5c09224de85370
# good: [513a4befae06c4469abfb836e8f71977de58c636] Merge branch 'for-4.9/block'
of git://git.kernel.dk/linux-block
git bisect good 513a4befae06c4469abfb836e8f71977de58c636
# good: [cca32b7eeb4ea24fa6596650e06279ad9130af98] ext4: allow DAX writeback
for hole punch
git bisect good cca32b7eeb4ea24fa6596650e06279ad9130af98
# bad: [fba597db4218ac324eee34b64736ea94829c95bf] pipe: add pipe_buf_confirm()
helper
git bisect bad fba597db4218ac324eee34b64736ea94829c95bf
# bad: [d82718e348fee15dbce8f578ff2588982b7cc7ca] fuse_dev_splice_read():
switch to add_to_pipe()
git bisect bad d82718e348fee15dbce8f578ff2588982b7cc7ca
# good: [db85a9eb2e364e24e71f94798e85dbaa8111bb4d] splice: switch
get_iovec_page_array() to iov_iter
git bisect good db85a9eb2e364e24e71f94798e85dbaa8111bb4d
# bad: [79fddc4efd5d4de5cf210fe5ecf4d2734140849a] new helper: add_to_pipe()
git bisect bad 79fddc4efd5d4de5cf210fe5ecf4d2734140849a
# bad: [8924feff66f35fe22ce77aafe3f21eb8e5cff881] splice: lift pipe_lock out of
splice_to_pipe()
git bisect bad 8924feff66f35fe22ce77aafe3f21eb8e5cff881
linux-next: build failure after merge of the xarray tree
Hi all, After merging the xarray tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: In file included from include/linux/list.h:9, from include/linux/module.h:9, from drivers/infiniband/core/device.c:34: drivers/infiniband/core/device.c: In function 'assign_name': include/linux/kernel.h:22:18: warning: passing argument 3 of 'xa_alloc' makes pointer from integer without a cast [-Wint-conversion] #define INT_MAX ((int)(~0U>>1)) ^~~ drivers/infiniband/core/device.c:591:43: note: in expansion of macro 'INT_MAX' ret = xa_alloc(, >index, INT_MAX, device, GFP_KERNEL); ^~~ In file included from include/linux/radix-tree.h:31, from include/linux/idr.h:15, from include/linux/kernfs.h:14, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/module.h:17, from drivers/infiniband/core/device.c:34: include/linux/xarray.h:796:9: note: expected 'void *' but argument is of type 'int' void *entry, struct xa_limit limit, gfp_t gfp) ~~^ drivers/infiniband/core/device.c:591:52: error: incompatible type for argument 4 of 'xa_alloc' ret = xa_alloc(, >index, INT_MAX, device, GFP_KERNEL); ^~ In file included from include/linux/radix-tree.h:31, from include/linux/idr.h:15, from include/linux/kernfs.h:14, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/module.h:17, from drivers/infiniband/core/device.c:34: include/linux/xarray.h:796:32: note: expected 'struct xa_limit' but argument is of type 'struct ib_device *' void *entry, struct xa_limit limit, gfp_t gfp) ^ In file included from include/linux/list.h:9, from include/linux/module.h:9, from drivers/infiniband/core/device.c:34: include/linux/kernel.h:22:18: warning: passing argument 3 of 'xa_alloc' makes pointer from integer without a cast [-Wint-conversion] #define INT_MAX ((int)(~0U>>1)) ^~~ drivers/infiniband/core/device.c:594:44: note: in expansion of macro 'INT_MAX' ret = xa_alloc(, >index, INT_MAX, device, ^~~ In file included from include/linux/radix-tree.h:31, from include/linux/idr.h:15, from include/linux/kernfs.h:14, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/module.h:17, from drivers/infiniband/core/device.c:34: include/linux/xarray.h:796:9: note: expected 'void *' but argument is of type 'int' void *entry, struct xa_limit limit, gfp_t gfp) ~~^ drivers/infiniband/core/device.c:594:53: error: incompatible type for argument 4 of 'xa_alloc' ret = xa_alloc(, >index, INT_MAX, device, ^~ In file included from include/linux/radix-tree.h:31, from include/linux/idr.h:15, from include/linux/kernfs.h:14, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/module.h:17, from drivers/infiniband/core/device.c:34: include/linux/xarray.h:796:32: note: expected 'struct xa_limit' but argument is of type 'struct ib_device *' void *entry, struct xa_limit limit, gfp_t gfp) ^ In file included from include/linux/list.h:9, from include/linux/module.h:9, from drivers/infiniband/core/device.c:34: drivers/infiniband/core/device.c: In function 'assign_client_id': include/linux/kernel.h:22:18: warning: passing argument 3 of 'xa_alloc' makes pointer from integer without a cast [-Wint-conversion] #define INT_MAX ((int)(~0U>>1)) ^~~ drivers/infiniband/core/device.c:826:47: note: in expansion of macro 'INT_MAX' ret = xa_alloc(, >client_id, INT_MAX, client, ^~~ In file included from include/linux/radix-tree.h:31, from include/linux/idr.h:15, from include/linux/kernfs.h:14, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/module.h:17, from drivers/infiniband/core/device.c:34: include/linux/xarray.h:796:9: note: expected 'void *' but argument is of type 'int' void *entry, struct xa_limit limit, gfp_t gfp) ~~^ drivers/infiniband/core/device.c:826:56: error: incompatible type for argument 4 of 'xa_alloc' ret = xa_alloc(,
Re: [RFC][Patch v8 6/7] KVM: Enables the kernel to isolate and report free pages
On Mon, Feb 11, 2019 at 10:28:31AM +0100, David Hildenbrand wrote:
> On 10.02.19 01:38, Michael S. Tsirkin wrote:
> > On Fri, Feb 08, 2019 at 02:05:09PM -0800, Alexander Duyck wrote:
> >> On Fri, Feb 8, 2019 at 1:38 PM Michael S. Tsirkin wrote:
> >>>
> >>> On Fri, Feb 08, 2019 at 03:41:55PM -0500, Nitesh Narayan Lal wrote:
> >> I am also planning to try Michael's suggestion of using MAX_ORDER - 1.
> >> However I am still thinking about a workload which I can use to test
> >> its
> >> effectiveness.
> > You might want to look at doing something like min(MAX_ORDER - 1,
> > HUGETLB_PAGE_ORDER). I know for x86 a 2MB page is the upper limit for
> > THP which is the most likely to be used page size with the guest.
> Sure, thanks for the suggestion.
> >>>
> >>> Given current hinting in balloon is MAX_ORDER I'd say
> >>> share code. If you feel a need to adjust down the road,
> >>> adjust both of them with actual testing showing gains.
> >>
> >> Actually I'm left kind of wondering why we are even going through
> >> virtio-balloon for this?
> >
> > Just look at what does it do.
> >
> > It improves memory overcommit if guests are cooperative, and it does
> > this by giving the hypervisor addresses of pages which it can discard.
> >
> > It's just *exactly* like the balloon with all the same limitations.
>
> I agree, this belongs to virtio-balloon *unless* we run into real
> problems implementing it via an asynchronous mechanism.
>
> >
> >> It seems like this would make much more sense
> >> as core functionality of KVM itself for the specific architectures
> >> rather than some side thing.
>
> Whatever can be handled in user space and does not have significant
> performance impacts should be handled in user space. If we run into real
> problems with that approach, fair enough. (e.g. vcpu yielding is a good
> example where an implementation in KVM makes sense, not going via QEMU)
Just to note, if we wanted to we could add a special kind of VQ where
e.g. kick yields the VCPU. You don't necessarily need a hypercall for
this. A virtio-cpu, yay!
> >
> > Well same as balloon: whether it's useful to you at all
> > would very much depend on your workloads.
> >
> > This kind of cooperative functionality is good for co-located
> > single-tenant VMs. That's pretty niche. The core things in KVM
> > generally don't trust guests.
> >
> >
> >> In addition this could end up being
> >> redundant when you start getting into either the s390 or PowerPC
> >> architectures as they already have means of providing unused page
> >> hints.
>
> I'd like to note that on s390x the functionality is not provided when
> running nested guests. And there are real problems getting it ever
> supported. (see description below how it works on s390x, the issue for
> nested guests are the bits in the guest -> host page tables we cannot
> support for nested guests).
>
> Hinting only works for guests running one level under LPAR (with a
> recent machine), but not nested guests.
>
> (LPAR -> KVM1 works, LPAR - KVM1 -> KVM2 foes not work for the latter)
>
> So an implementation for s390 would still make sense for this scenario.
>
> >
> > Interesting. Is there host support in kvm?
>
> On s390x there is. It works on page granularity and synchronization
> between guest/host ("don't drop a page in the host while the guest is
> reusing it") is done via special bits in the host->guest page table.
> Instructions in the guest are able to modify these bits. A guest can
> configure a "usage state" of it's backed PTEs. E.g. "unused" or "stable".
>
> Whenever a page in the guest is freed/reused, the ESSA instruction is
> triggered in the guest. It will modify the page table bits and add the
> guest phyical pfn to a buffer in the host. Once that buffer is full,
> ESSA will trigger an intercept to the hypervisor. Here, all these
> "unused" pages can be zapped.
>
> Also, when swapping a page out in the hypervisor, if it was masked by
> the guest as unused or logically zero, instead of swapping out the page,
> it can simply be dropped and a fresh zero page can be supplied when the
> guest tries to access it.
>
> "ESSA" is implemented in KVM in arch/s390/kvm/priv.c:handle_essa().
>
> So on s390x, it works because the synchronization with the hypervisor is
> directly built into hw vitualization support (guest->host page tables +
> instruction) and ESSA will not intercept on every call (due to the buffer).
> >
> >
> >> I have a set of patches I proposed that add similar functionality via
> >> a KVM hypercall for x86 instead of doing it as a part of a Virtio
> >> device[1]. I'm suspecting the overhead of doing things this way is
> >> much less then having to make multiple madvise system calls from QEMU
> >> back into the kernel.
> >
> > Well whether it's a virtio device is orthogonal to whether it's an
> > madvise call, right? You can build vhost-pagehint and that can
> > handle requests in a VQ within balloon and
