Re: [PATCH v2 06/14] irqchip: add initial support for ompic
On Wed, Sep 13, 2017 at 06:21:39PM +0100, Marc Zyngier wrote:
> On Sun, Sep 10 2017 at 3:49:18 pm BST, Stafford Horne
> wrote:
> > From: Stefan Kristiansson
> >
> > IPI driver for the Open Multi-Processor Interrupt Controller (ompic) as
> > described in the Multicore support section of the OpenRISC 1.2
> > proposed architecture specification:
> >
> >
> > https://github.com/stffrdhrn/doc/raw/arch-1.2-proposal/openrisc-arch-1.2-rev0.pdf
> >
> > Each OpenRISC core contains a full interrupt controller which is used in
> > the SMP architecture for interrupt balancing. This IPI device, the
> > ompic, is the only external device required for enabling SMP on
> > OpenRISC.
> >
> > Pending ops are stored in a memory bit mask which can allow multiple
> > pending operations to be set and serviced at a time. This is mostly
> > borrowed from the alpha IPI implementation.
> >
> > Signed-off-by: Stefan Kristiansson
> > [sho...@gmail.com: converted ops to bitmask, wrote commit message]
> > Signed-off-by: Stafford Horne
> > ---
> >
> > Changes since v1
> > - Added openrisc, prefix
> > - Clarified 8 bytes per cpu
> > - Removed #interrupt-cells as this will not be an irq parent
> > - Changed ops to be percpu
> > - Added DTS and intialization failure validations
> >
> > .../interrupt-controller/openrisc,ompic.txt| 19 ++
> > arch/openrisc/Kconfig | 1 +
> > drivers/irqchip/Kconfig| 3 +
> > drivers/irqchip/Makefile | 1 +
> > drivers/irqchip/irq-ompic.c| 205
> > +
> > 5 files changed, 229 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt
> > create mode 100644 drivers/irqchip/irq-ompic.c
> >
> > diff --git
> > a/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt
> > b/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt
> > new file mode 100644
> > index ..346e6042d62f
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/interrupt-controller/openrisc,ompic.txt
> > @@ -0,0 +1,19 @@
> > +Open Multi-Processor Interrupt Controller
> > +
> > +Required properties:
> > +
> > +- compatible : This should be "openrisc,ompic"
> > +- reg : Specifies base physical address and size of the register space. The
> > + size is based on the number of cores the controller has been configured
> > + to handle, this should be set to 8 bytes per cpu core.
> > +- interrupt-controller : Identifies the node as an interrupt controller
> > +- interrupts : Specifies the interrupt line to which the ompic is wired.
> > +
> > +Example:
> > +
> > +ompic: ompic {
> > + compatible = "openrisc,ompic";
> > + reg = <0x9800 16>;
> > + interrupt-controller;
> > + interrupts = <1>;
> > +};
> > diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
> > index b49acda5e8f4..34eb4e90f56c 100644
> > --- a/arch/openrisc/Kconfig
> > +++ b/arch/openrisc/Kconfig
> > @@ -30,6 +30,7 @@ config OPENRISC
> > select NO_BOOTMEM
> > select ARCH_USE_QUEUED_SPINLOCKS
> > select ARCH_USE_QUEUED_RWLOCKS
> > + select OMPIC if SMP
> >
> > config CPU_BIG_ENDIAN
> > def_bool y
> > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> > index f1fd5f44d1d4..0e4c96c90b86 100644
> > --- a/drivers/irqchip/Kconfig
> > +++ b/drivers/irqchip/Kconfig
> > @@ -145,6 +145,9 @@ config CLPS711X_IRQCHIP
> > select SPARSE_IRQ
> > default y
> >
> > +config OMPIC
> > + bool
> > +
> > config OR1K_PIC
> > bool
> > select IRQ_DOMAIN
> > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> > index e88d856cc09c..123047d7a20d 100644
> > --- a/drivers/irqchip/Makefile
> > +++ b/drivers/irqchip/Makefile
> > @@ -17,6 +17,7 @@ obj-$(CONFIG_DW_APB_ICTL) += irq-dw-apb-ictl.o
> > obj-$(CONFIG_METAG)+= irq-metag-ext.o
> > obj-$(CONFIG_METAG_PERFCOUNTER_IRQS) += irq-metag.o
> > obj-$(CONFIG_CLPS711X_IRQCHIP) += irq-clps711x.o
> > +obj-$(CONFIG_OMPIC)+= irq-ompic.o
> > obj-$(CONFIG_OR1K_PIC) += irq-or1k-pic.o
> > obj-$(CONFIG_ORION_IRQCHIP)+= irq-orion.o
> > obj-$(CONFIG_OMAP_IRQCHIP) += irq-omap-intc.o
> > diff --git a/drivers/irqchip/irq-ompic.c b/drivers/irqchip/irq-ompic.c
> > new file mode 100644
> > index ..cd2616b6639b
> > --- /dev/null
> > +++ b/drivers/irqchip/irq-ompic.c
> > @@ -0,0 +1,205 @@
> > +/*
> > + * Open Multi-Processor Interrupt Controller driver
> > + *
> > + * Copyright (C) 2014 Stefan Kristiansson
> >
> > + * Copyright (C) 2017 Stafford Horne
> > + *
> > + * This file is licensed under the terms of the GNU General Public License
> > + * version 2. This program is licensed "as is" without any warranty of any
> > + * kind, whether express or implied.
> > + *
> > + * The ompic device handles
Re: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier usages
On (09/08/17 10:25), Luck, Tony wrote: > On Fri, Sep 08, 2017 at 03:18:30PM +0900, Sergey Senozhatsky wrote: > > if the addr is not in kernel .text, then try dereferencing it and check > > if the dereferenced addr is in kernel .text. > > If it really is a function pointer, then we know that it is safe > to dereference. But if it isn't, then maybe not? yes. I thought about it - we can do %pS on a pointer to a global structure. so that simple heuristic would not work reliably. we parse ELF sections, and we know the address range of .opd section, so we can check if the supplied pointer is within the .opd section or not. .opd does exist on ia64. not sure what's the name of ELF descriptor section on ppc64/parisc64. if we will be able to simply do .opd->address <= ptr <= .opd->address + .opd->size then it mostly should work for us. I guess. > If it is a function pointer then dereferening will indeed give > us a .text address. But if it isn't, it might still give us a > .text address (we could reduce the probability of a false hit > by checking that the .text address was exactly on a symbol with > no offset ... but data values that happen to be the addresses of > function entry points are possible). hm. yes, need to think more. -ss
[PATCH v1] ARM: dts: socfpga: fix nand compatible
the compatible was changed with patch:
|commit a56609c4c3f34de76d905e39160511b3c53310ac
|Author: Masahiro Yamada
|Date: Thu Mar 30 15:45:53 2017 +0900
|
| mtd: nand: denali_dt: enable HW_ECC_FIXUP for Altera SOCFPGA variant
|
| There are various customizable parameters, so several variants for
| this IP. A generic compatible like "denali,denali-nand-dt" is
| useless. Moreover, there are multiple things wrong with this string.
| (Refer to Rob's comment [1])
|
| The "denali,denali-nand-dt" was added by Altera for the SOCFPGA port.
| Replace it with a more specific string "altr,socfpga-denali-nand".
| There are no users (in upstream) of the old compatible string.
|
| The Denali IP on SOCFPGA incorporates the hardware ECC fixup engine.
| So, this capability should be associated with the compatible.
|
| [1] https://lkml.org/lkml/2016/12/1/450
Signed-off-by: Oleksij Rempel
---
arch/arm/boot/dts/socfpga.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 7e24dc8e82d4..d697f5062624 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -744,7 +744,7 @@
nand0: nand@ff90 {
#address-cells = <0x1>;
#size-cells = <0x1>;
- compatible = "denali,denali-nand-dt";
+ compatible = "altr,socfpga-denali-nand";
reg = <0xff90 0x10>,
<0xffb8 0x1>;
reg-names = "nand_data", "denali_reg";
--
2.11.0
Re: [GIT PULL] overlayfs update for 4.14
On Wed, Sep 13, 2017 at 6:25 PM, Linus Torvalds wrote: > On Wed, Sep 13, 2017 at 7:05 AM, Miklos Szeredi wrote: >> >> There are also some bug fixes, one in particular (random ioctl's shouldn't be >> able to modify lower layers) that touches some vfs code, but of course no-op >> for >> non-overlay fs. > > Argh. I _despise_ those changes to 'd_real()'. > > I reall ythink you should have made it a bit in the f_flags argument > instead. The whole "pick the upper file" is _very_ similar to the > file->f_flags bits conceptually - those change how accesses are done > in other ways (eg O_DIRECT etc), and it's entirely possible that some > day maybe you'd even want to expose it to user space as a O_UPPER flag > to open (which would then only succeed if the file is in the upper > overlay, and never open the lower filesystem). > > So adding _another_ field that is only for overlayfs and makes > absolutely no sense in any other context is nasty. It's wrong. That's > not a "VFS layer interface" any more. It's just an ugly hack that > makes no sense outside of overlayfs. d_real() is currently is *the* overlayfs-op: $ git grep -l "\.d_real" fs/overlayfs/super.c It might find other uses in the future, but for now that's the fact. I could have merged D_REAL_UPPER into f_flags, but it would have polluted the O_ namespace (which is a uapi) with an internal flag. Look at the MS_ flags mess to see how mixing internal and external flags is a really bad idea. Changing internal interfaces is so much easier than userspace interfaces. So this is not set in stone, and since currently overlayfs is the only user of the d_real api, it's really trivial to change around if we find some other use for it. But if we try to think up some interface (e.g. the O_UPPER that you suggested) then we'll be stuck with it even if it makes no sense, or worse, causes problems. So let's just wait until the need for something comes up, then we can massage the internal interface to our liking. Thanks, Miklos
Re: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier usages
Hi, On (09/08/17 22:49), Helge Deller wrote: [..] > Sergey, I'm sure there is a way how you can get it somehow to work the way > you describe above, but even then nobody can guarantee you that it > will work in 100% of the cases. > > It's somehow like "we have %lu and %c specifiers, and it's basically > the same, so let's try to figure out at runtime which one should be > used based on analysis of what was given as argument". > It may work somehow, but not always. > > What about the idea of a %luS specifier (or something other) ? the idea is to have less format specifiers ;) %pF/%pf is a subtle ABI detail, which made it to API. I'm OK to keep %pf/%pF, if we won't be able to improve %ps/%pS. otherwise, I'd prefer to get rid of it. -ss
[PATCH] intel-wmi-thunderbolt: fix some error cases
These were raised by Lukas Wunner as potential DOS attacks against
the system log by passing bad data to sysfs.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/intel-wmi-thunderbolt.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/intel-wmi-thunderbolt.c
b/drivers/platform/x86/intel-wmi-thunderbolt.c
index 32fb6cc..c2257bd 100644
--- a/drivers/platform/x86/intel-wmi-thunderbolt.c
+++ b/drivers/platform/x86/intel-wmi-thunderbolt.c
@@ -41,13 +41,10 @@ static ssize_t force_power_store(struct device *dev,
if (mode == 0 || mode == 1) {
status = wmi_evaluate_method(INTEL_WMI_THUNDERBOLT_GUID, 0, 1,
&input, NULL);
- if (ACPI_FAILURE(status)) {
- pr_err("intel-wmi-thunderbolt: failed setting %s\n",
- buf);
+ if (ACPI_FAILURE(status))
return -ENODEV;
- }
} else {
- pr_err("intel-wmi-thunderbolt: unsupported mode: %d", mode);
+ return -EINVAL;
}
return count;
}
--
2.7.4
Re: [PATCH v1 4/5] mmc: sdhci-msm: Add ops to do sdhc register write
On 30/08/17 15:51, Vijay Viswanath wrote:
> Register writes which change voltage of IO lines or turn the IO bus
> on/off require controller to be ready before progressing further. When
> the controller is ready, it will generate a power irq which needs to be
> handled. The thread which initiated the register write should wait for
> power irq to complete. This will be done through the new sdhc msm write
> APIs which will check whether the particular write can trigger a power
> irq and wait for it with a timeout if it is expected.
> The SDHC core power control IRQ gets triggered when -
> * There is a state change in power control bit (bit 0)
> of SDHCI_POWER_CONTROL register.
> * There is a state change in 1.8V enable bit (bit 3) of
> SDHCI_HOST_CONTROL2 register.
> * Bit 1 of SDHCI_SOFTWARE_RESET is set.
>
> Signed-off-by: Vijay Viswanath
Acked-by: Adrian Hunter
> ---
> drivers/mmc/host/sdhci-msm.c | 69
> +++-
> 1 file changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index e3e385e..a4a78b5 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -1070,7 +1070,6 @@ static void sdhci_msm_check_power_status(struct
> sdhci_host *host, u32 req_type)
> __WARN_printf("%s: pwr_irq for req: (%d) timed out\n",
> mmc_hostname(host->mmc), req_type);
> }
> - msm_host->pwr_irq_flag = 0;
> pr_debug("%s: %s: request %d done\n", mmc_hostname(host->mmc),
> __func__, req_type);
> }
> @@ -1250,6 +1249,70 @@ static void sdhci_msm_set_clock(struct sdhci_host
> *host, unsigned int clock)
> __sdhci_msm_set_clock(host, clock);
> }
>
> +#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
> +/*
> + * Platform specific register write functions. This is so that, if any
> + * register write needs to be followed up by platform specific actions,
> + * they can be added here. These functions can go to sleep when writes
> + * to certain registers are done.
> + * These functions are relying on sdhci_set_ios not using spinlock.
> + */
> +static int __sdhci_msm_check_write(struct sdhci_host *host, u16 val, int reg)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> + u32 req_type = 0;
> +
> + switch (reg) {
> + case SDHCI_HOST_CONTROL2:
> + req_type = (val & SDHCI_CTRL_VDD_180) ? REQ_IO_LOW :
> + REQ_IO_HIGH;
> + break;
> + case SDHCI_SOFTWARE_RESET:
> + if (host->pwr && (val & SDHCI_RESET_ALL))
> + req_type = REQ_BUS_OFF;
> + break;
> + case SDHCI_POWER_CONTROL:
> + req_type = !val ? REQ_BUS_OFF : REQ_BUS_ON;
> + break;
> + }
> +
> + if (req_type) {
> + msm_host->pwr_irq_flag = 0;
> + /*
> + * Since this register write may trigger a power irq, ensure
> + * all previous register writes are complete by this point.
> + */
> + mb();
> + }
> + return req_type;
> +}
> +
> +/* This function may sleep*/
> +static void sdhci_msm_writew(struct sdhci_host *host, u16 val, int reg)
> +{
> + u32 req_type = 0;
> +
> + req_type = __sdhci_msm_check_write(host, val, reg);
> + writew_relaxed(val, host->ioaddr + reg);
> +
> + if (req_type)
> + sdhci_msm_check_power_status(host, req_type);
> +}
> +
> +/* This function may sleep*/
> +static void sdhci_msm_writeb(struct sdhci_host *host, u8 val, int reg)
> +{
> + u32 req_type = 0;
> +
> + req_type = __sdhci_msm_check_write(host, val, reg);
> +
> + writeb_relaxed(val, host->ioaddr + reg);
> +
> + if (req_type)
> + sdhci_msm_check_power_status(host, req_type);
> +}
> +#endif
> static const struct of_device_id sdhci_msm_dt_match[] = {
> { .compatible = "qcom,sdhci-msm-v4" },
> {},
> @@ -1264,6 +1327,10 @@ static void sdhci_msm_set_clock(struct sdhci_host
> *host, unsigned int clock)
> .get_max_clock = sdhci_msm_get_max_clock,
> .set_bus_width = sdhci_set_bus_width,
> .set_uhs_signaling = sdhci_msm_set_uhs_signaling,
> +#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
> + .write_w = sdhci_msm_writew,
> + .write_b = sdhci_msm_writeb,
> +#endif
> };
>
> static const struct sdhci_pltfm_data sdhci_msm_pdata = {
>
Re: [PATCH v1 5/5] mmc: Kconfig: Enable CONFIG_MMC_SDHCI_IO_ACCESSORS
On 30/08/17 15:51, Vijay Viswanath wrote: > Enable CONFIG_MMC_SDHCI_IO_ACCESSORS so that SDHC controller specific > register read and write APIs, if registered, can be used. Missing signed-off Why don't you put this patch earlier in the patch set and then you don't need all the ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS ? > --- > drivers/mmc/host/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > index 2db84dd..64a9298 100644 > --- a/drivers/mmc/host/Kconfig > +++ b/drivers/mmc/host/Kconfig > @@ -420,6 +420,7 @@ config MMC_SDHCI_MSM > tristate "Qualcomm SDHCI Controller Support" > depends on ARCH_QCOM || (ARM && COMPILE_TEST) > depends on MMC_SDHCI_PLTFM > + select CONFIG_MMC_SDHCI_IO_ACCESSORS CONFIG_MMC_SDHCI_IO_ACCESSORS -> MMC_SDHCI_IO_ACCESSORS > help > This selects the Secure Digital Host Controller Interface (SDHCI) > support present in Qualcomm SOCs. The controller supports >
Re: [PATCH v1 3/5] mmc: sdhci-msm: Add support to wait for power irq
On 30/08/17 15:51, Vijay Viswanath wrote:
> From: Sahitya Tummala
>
> Add support API which will check if power irq is expected to be
> generated and wait for the power irq to come and complete if the irq is
> expected.
>
> Signed-off-by: Sahitya Tummala
> Signed-off-by: Vijay Viswanath
One comment below.
> ---
> drivers/mmc/host/sdhci-msm.c | 124
> ++-
> 1 file changed, 122 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 42a65ab..e3e385e 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -123,6 +123,10 @@
> #define CMUX_SHIFT_PHASE_MASK(7 << CMUX_SHIFT_PHASE_SHIFT)
>
> #define MSM_MMC_AUTOSUSPEND_DELAY_MS 50
> +
> +/* Timeout value to avoid infinite waiting for pwr_irq */
> +#define MSM_PWR_IRQ_TIMEOUT_MS 5000
> +
> struct sdhci_msm_host {
> struct platform_device *pdev;
> void __iomem *core_mem; /* MSM SDCC mapped address */
> @@ -138,6 +142,12 @@ struct sdhci_msm_host {
> bool calibration_done;
> u8 saved_tuning_phase;
> bool use_cdclp533;
> + u32 curr_pwr_state;
> + u32 curr_io_level;
> +#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
> + wait_queue_head_t pwr_irq_wait;
> + bool pwr_irq_flag;
> +#endif
> };
>
> static unsigned int msm_get_clock_rate_for_bus_mode(struct sdhci_host *host,
> @@ -995,6 +1005,87 @@ static void sdhci_msm_set_uhs_signaling(struct
> sdhci_host *host,
> sdhci_msm_hs400(host, &mmc->ios);
> }
>
> +#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
> +static inline void sdhci_msm_init_pwr_irq_wait(struct sdhci_msm_host
> *msm_host)
> +{
> + init_waitqueue_head(&msm_host->pwr_irq_wait);
> +}
> +
> +static inline void sdhci_msm_complete_pwr_irq_wait(
> + struct sdhci_msm_host *msm_host)
> +{
> + wake_up(&msm_host->pwr_irq_wait);
> +}
> +
> +/*
> + * sdhci_msm_check_power_status API should be called when registers writes
> + * which can toggle sdhci IO bus ON/OFF or change IO lines HIGH/LOW happens.
> + * To what state the register writes will change the IO lines should be
> passed
> + * as the argument req_type. This API will check whether the IO line's state
> + * is already the expected state and will wait for power irq only if
> + * power irq is expected to be trigerred based on the current IO line state
> + * and expected IO line state.
> + */
> +static void sdhci_msm_check_power_status(struct sdhci_host *host, u32
> req_type)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> + bool done = false;
> +
> + pr_debug("%s: %s: request %d curr_pwr_state %x curr_io_level %x\n",
> + mmc_hostname(host->mmc), __func__, req_type,
> + msm_host->curr_pwr_state, msm_host->curr_io_level);
> +
> + /*
> + * The IRQ for request type IO High/LOW will be generated when -
> + * there is a state change in 1.8V enable bit (bit 3) of
> + * SDHCI_HOST_CONTROL2 register. The reset state of that bit is 0
> + * which indicates 3.3V IO voltage. So, when MMC core layer tries
> + * to set it to 3.3V before card detection happens, the
> + * IRQ doesn't get triggered as there is no state change in this bit.
> + * The driver already handles this case by changing the IO voltage
> + * level to high as part of controller power up sequence. Hence, check
> + * for host->pwr to handle a case where IO voltage high request is
> + * issued even before controller power up.
> + */
> + if ((req_type & REQ_IO_HIGH) && !host->pwr) {
> + pr_debug("%s: do not wait for power IRQ that never comes,
> req_type: %d\n",
> + mmc_hostname(host->mmc), req_type);
> + return;
> + }
> + if ((req_type & msm_host->curr_pwr_state) ||
> + (req_type & msm_host->curr_io_level))
> + done = true;
> + /*
> + * This is needed here to hanlde a case where IRQ gets
> + * triggered even before this function is called so that
> + * x->done counter of completion gets reset. Otherwise,
> + * next call to wait_for_completion returns immediately
> + * without actually waiting for the IRQ to be handled.
> + */
This isn't true anymore. If there is always an interrupt following the
register write, then you can always call wait_event_timeout() because
if the interrupt has already happened msm_host->pwr_irq_flag will already be
true.
However if the interrupt only happens if the pwr_state of io_level changes,
then you do need to check those, to avoid waiting for an interrupt that is
not coming.
> + if (!done) {
> + if (!wait_event_timeout(msm_host->pwr_irq_wait,
> + msm_host->pwr_irq_flag,
> + msecs_to_jiffies(MSM_PWR_IRQ_TIMEOUT_MS)))
>
Re: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier usages
Hi,
On (09/08/17 22:23), Yu, Fenghua wrote:
> > From: Sergey Senozhatsky [mailto:sergey.senozhatsky.w...@gmail.com]
> > On (09/07/17 16:05), Luck, Tony wrote:
> > +static inline bool __mod_text_address(struct module *mod,
> > + unsigned long addr) {
> > + /* Make sure it's within the text section. */
> > + if (!within(addr, mod->init_layout.base, mod->init_layout.text_size)
> > + && !within(addr, mod->core_layout.base, mod-
> > >core_layout.text_size))
> > + return false;
> > + return true;
> > +}
>
> The __mod_text_address() may be defined only on IA64, PPC64 and PARISC since
> it's only called in those cases.
sure. well, I didn't post the exact patch. __mod_text_address() was
supposed to be used from __module_text_address() /* I factored out
__mod_text_address() from that function, basically */
---
@@ -4305,9 +4323,7 @@ struct module *__module_text_address(unsigned long addr)
{
struct module *mod = __module_address(addr);
if (mod) {
- /* Make sure it's within the text section. */
- if (!within(addr, mod->init_layout.base,
mod->init_layout.text_size)
- && !within(addr, mod->core_layout.base,
mod->core_layout.text_size))
+ if (!__mod_text_address(mod, addr))
mod = NULL;
}
return mod;
---
-ss
Re: [PATCH v1 1/5] mmc: sdhci-msm: fix issue with power irq
On 30/08/17 15:51, Vijay Viswanath wrote:
> From: Subhash Jadavani
>
> SDCC controller reset (SW_RST) during probe may trigger power irq if
> previous status of PWRCTL was either BUS_ON or IO_HIGH_V. So before we
> enable the power irq interrupt in GIC (by registering the interrupt
> handler), we need to ensure that any pending power irq interrupt status
> is acknowledged otherwise power irq interrupt handler would be fired
> prematurely.
>
> Signed-off-by: Subhash Jadavani
> Signed-off-by: Vijay Viswanath
Acked-by: Adrian Hunter
> ---
> drivers/mmc/host/sdhci-msm.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 9d601dc..d636251 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -1250,6 +1250,21 @@ static int sdhci_msm_probe(struct platform_device
> *pdev)
> CORE_VENDOR_SPEC_CAPABILITIES0);
> }
>
> + /*
> + * Power on reset state may trigger power irq if previous status of
> + * PWRCTL was either BUS_ON or IO_HIGH_V. So before enabling pwr irq
> + * interrupt in GIC, any pending power irq interrupt should be
> + * acknowledged. Otherwise power irq interrupt handler would be
> + * fired prematurely.
> + */
> + sdhci_msm_voltage_switch(host);
> +
> + /*
> + * Ensure that above writes are propogated before interrupt enablement
> + * in GIC.
> + */
> + mb();
> +
> /* Setup IRQ for handling power/voltage tasks with PMIC */
> msm_host->pwr_irq = platform_get_irq_byname(pdev, "pwr_irq");
> if (msm_host->pwr_irq < 0) {
> @@ -1259,6 +1274,9 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> goto clk_disable;
> }
>
> + /* Enable pwr irq interrupts */
> + writel_relaxed(INT_MASK, msm_host->core_mem + CORE_PWRCTL_MASK);
> +
> ret = devm_request_threaded_irq(&pdev->dev, msm_host->pwr_irq, NULL,
> sdhci_msm_pwr_irq, IRQF_ONESHOT,
> dev_name(&pdev->dev), host);
>
Re: [PATCH v1 2/5] mmc: sdhci-msm: Fix HW issue with power IRQ handling during reset
On 30/08/17 15:51, Vijay Viswanath wrote:
> From: Sahitya Tummala
>
> There is a rare scenario in HW, where the first clear pulse could
> be lost when the actual reset and clear/read of status register
> are happening at the same time. Fix this by retrying upto 10 times
> to ensure the status register gets cleared. Otherwise, this will
> lead to a spurious power IRQ which results in system instability.
>
> Signed-off-by: Sahitya Tummala
> Signed-off-by: Vijay Viswanath
Acked-by: Adrian Hunter
> ---
> drivers/mmc/host/sdhci-msm.c | 46
>
> 1 file changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index d636251..42a65ab 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -995,17 +995,52 @@ static void sdhci_msm_set_uhs_signaling(struct
> sdhci_host *host,
> sdhci_msm_hs400(host, &mmc->ios);
> }
>
> -static void sdhci_msm_voltage_switch(struct sdhci_host *host)
> +static void sdhci_msm_dump_pwr_ctrl_regs(struct sdhci_host *host)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> +
> + pr_err("%s: PWRCTL_STATUS: 0x%08x | PWRCTL_MASK: 0x%08x | PWRCTL_CTL:
> 0x%08x\n",
> + mmc_hostname(host->mmc),
> + readl_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS),
> + readl_relaxed(msm_host->core_mem + CORE_PWRCTL_MASK),
> + readl_relaxed(msm_host->core_mem + CORE_PWRCTL_CTL));
> +}
> +
> +static void sdhci_msm_handle_pwr_irq(struct sdhci_host *host, int irq)
> {
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> u32 irq_status, irq_ack = 0;
> + int retry = 10;
>
> irq_status = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
> irq_status &= INT_MASK;
>
> writel_relaxed(irq_status, msm_host->core_mem + CORE_PWRCTL_CLEAR);
>
> + /*
> + * There is a rare HW scenario where the first clear pulse could be
> + * lost when actual reset and clear/read of status register is
> + * happening at a time. Hence, retry for at least 10 times to make
> + * sure status register is cleared. Otherwise, this will result in
> + * a spurious power IRQ resulting in system instability.
> + */
> + while (irq_status & readl_relaxed(msm_host->core_mem +
> + CORE_PWRCTL_STATUS)) {
> + if (retry == 0) {
> + pr_err("%s: Timedout clearing (0x%x) pwrctl status
> register\n",
> + mmc_hostname(host->mmc), irq_status);
> + sdhci_msm_dump_pwr_ctrl_regs(host);
> + WARN_ON(1);
> + break;
> + }
> + writel_relaxed(irq_status,
> + msm_host->core_mem + CORE_PWRCTL_CLEAR);
> + retry--;
> + udelay(10);
> + }
> +
> if (irq_status & (CORE_PWRCTL_BUS_ON | CORE_PWRCTL_BUS_OFF))
> irq_ack |= CORE_PWRCTL_BUS_SUCCESS;
> if (irq_status & (CORE_PWRCTL_IO_LOW | CORE_PWRCTL_IO_HIGH))
> @@ -1017,13 +1052,17 @@ static void sdhci_msm_voltage_switch(struct
> sdhci_host *host)
>* switches are handled by the sdhci core, so just report success.
>*/
> writel_relaxed(irq_ack, msm_host->core_mem + CORE_PWRCTL_CTL);
> +
> + pr_debug("%s: %s: Handled IRQ(%d), irq_status=0x%x, ack=0x%x\n",
> + mmc_hostname(msm_host->mmc), __func__, irq, irq_status,
> + irq_ack);
> }
>
> static irqreturn_t sdhci_msm_pwr_irq(int irq, void *data)
> {
> struct sdhci_host *host = (struct sdhci_host *)data;
>
> - sdhci_msm_voltage_switch(host);
> + sdhci_msm_handle_pwr_irq(host, irq);
>
> return IRQ_HANDLED;
> }
> @@ -1106,7 +1145,6 @@ static void sdhci_msm_set_clock(struct sdhci_host
> *host, unsigned int clock)
> .get_max_clock = sdhci_msm_get_max_clock,
> .set_bus_width = sdhci_set_bus_width,
> .set_uhs_signaling = sdhci_msm_set_uhs_signaling,
> - .voltage_switch = sdhci_msm_voltage_switch,
> };
>
> static const struct sdhci_pltfm_data sdhci_msm_pdata = {
> @@ -1257,7 +1295,7 @@ static int sdhci_msm_probe(struct platform_device *pdev)
>* acknowledged. Otherwise power irq interrupt handler would be
>* fired prematurely.
>*/
> - sdhci_msm_voltage_switch(host);
> + sdhci_msm_handle_pwr_irq(host, 0);
>
> /*
>* Ensure that above writes are propogated before interrupt enablement
>
Re: [PATCH v2] ipv4: Namespaceify tcp_fastopen knob
> On 2017年9月13日, at 下午9:02, Eric Dumazet wrote: > > On Wed, 2017-09-13 at 05:44 -0700, Eric Dumazet wrote: >> On Wed, 2017-09-13 at 19:19 +0800, Haishuang Yan wrote: >>> Different namespace application might require enable TCP Fast Open >>> feature independently of the host. >>> >> >> Poor changelog, no actual description / list of sysctls that are moved >> to per netns. >> >> And looking at the patch, it seems your conversion is not complete. >> >> So I will ask you to provide more evidence that you tested your patch >> next time you submit it. > > I suggest you move one sysctl at a time, in a patch series. > > It will be easier to document and test for you, and review for us. > > Thanks. > Okay, I will split my patch for each sysctl change. Thanks.
[PATCH] megaraid: kmemleak: Track page allocation for fusion
From: Shu Wang
Kmemleak reports about a thousand false positives for fusion->
cmd_list[]. Root casue is the cmd_list objects are allocated from
slab allocator, and stored its pointer in object allocated by page
allocator. The fix will tell kmemleak to track and scan fusion
object.
Before patch:
kmemleak: 1004 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
unreferenced object 0x88042584e000 (size 8192):
backtrace:
kmemleak_alloc+0x4a/0xa0
__kmalloc+0xec/0x220
megasas_alloc_cmdlist_fusion+0x3e/0x140 [megaraid_sas]
megasas_alloc_cmds_fusion+0x44/0x450 [megaraid_sas]
megasas_init_adapter_fusion+0x21d/0x6e0 [megaraid_sas]
megasas_init_fw+0x357/0xd30 [megaraid_sas]
megasas_probe_one.part.34+0x5be/0x1040 [megaraid_sas]
megasas_probe_one+0x46/0xc0 [megaraid_sas]
local_pci_probe+0x45/0xa0
work_for_cpu_fn+0x14/0x20
process_one_work+0x149/0x360
worker_thread+0x1d8/0x3c0
kthread+0x109/0x140
ret_from_fork+0x25/0x30
Signed-off-by: Shu Wang
---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 11bd2e698b84..621299edd8de 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include
#include
@@ -4512,7 +4513,9 @@ megasas_alloc_fusion_context(struct megasas_instance
*instance)
dev_err(&instance->pdev->dev, "Failed from %s %d\n",
__func__, __LINE__);
return -ENOMEM;
}
- }
+ } else
+ kmemleak_alloc(instance->ctrl_context,
+ sizeof(struct fusion_context), 1, GFP_KERNEL);
fusion = instance->ctrl_context;
@@ -4548,9 +4551,11 @@ megasas_free_fusion_context(struct megasas_instance
*instance)
if (is_vmalloc_addr(fusion))
vfree(fusion);
- else
+ else {
free_pages((ulong)fusion,
instance->ctrl_context_pages);
+ kmemleak_free(fusion);
+ }
}
}
--
2.13.5
Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)
Hi Tycho,
On 2017/9/13 2:13, Tycho Andersen wrote:
> Hi Yisheng,
>
>> On Tue, Sep 12, 2017 at 04:05:22PM +0800, Yisheng Xie wrote:
>>> IMO, before a page is allocated, it is in buddy system, which means it is
>>> free
>>> and no other 'map' on the page except direct map. Then if the page is
>>> allocated
>>> to user, XPFO should unmap the direct map. otherwise the ret2dir may works
>>> at
>>> this window before it is freed. Or maybe I'm still missing anything.
>>
>> I agree that it seems broken. I'm just not sure why the test doesn't
>> fail. It's certainly worth understanding.
>
> Ok, so I think what's going on is that the page *is* mapped and unmapped by
> the
> kernel as Juerg described, but only in certain cases. See prep_new_page(),
> which has the following:
>
> if (!free_pages_prezeroed() && (gfp_flags & __GFP_ZERO))
> for (i = 0; i < (1 << order); i++)
> clear_highpage(page + i);
>
> clear_highpage() maps and unmaps the pages, so that's why xpfo works with this
> set.
Oh, I really missed this point. For we need zero the memory before user get
them.
Thanks a lot for figuring out.
>
> I tried with CONFIG_PAGE_POISONING_ZERO=y and page_poison=y, and the
> XPFO_READ_USER test does not fail, i.e. the read succeeds. So, I think we need
> to include this zeroing condition in xpfo_alloc_pages(), something like the
> patch below. Unfortunately, this fails to boot for me, probably for an
> unrelated reason that I'll look into.
Yes, seems need to fix in this case, and I also a litter puzzle about why boot
fail.
Thanks
Yisheng Xie
>
> Thanks a lot!
>
> Tycho
>
>
>>From bfc21a6438cf8c56741af94cac939f1b0f63752c Mon Sep 17 00:00:00 2001
> From: Tycho Andersen
> Date: Tue, 12 Sep 2017 12:06:41 -0600
> Subject: [PATCH] draft of unmapping patch
>
> Signed-off-by: Tycho Andersen
> ---
> include/linux/xpfo.h | 5 +++--
> mm/compaction.c | 2 +-
> mm/internal.h| 2 +-
> mm/page_alloc.c | 10 ++
> mm/xpfo.c| 10 --
> 5 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/xpfo.h b/include/linux/xpfo.h
> index b24be9ac4a2d..c991bf7f051d 100644
> --- a/include/linux/xpfo.h
> +++ b/include/linux/xpfo.h
> @@ -29,7 +29,7 @@ void xpfo_flush_kernel_tlb(struct page *page, int order);
>
> void xpfo_kmap(void *kaddr, struct page *page);
> void xpfo_kunmap(void *kaddr, struct page *page);
> -void xpfo_alloc_pages(struct page *page, int order, gfp_t gfp);
> +void xpfo_alloc_pages(struct page *page, int order, gfp_t gfp, bool
> will_map);
> void xpfo_free_pages(struct page *page, int order);
>
> bool xpfo_page_is_unmapped(struct page *page);
> @@ -49,7 +49,8 @@ void xpfo_temp_unmap(const void *addr, size_t size, void
> **mapping,
>
> static inline void xpfo_kmap(void *kaddr, struct page *page) { }
> static inline void xpfo_kunmap(void *kaddr, struct page *page) { }
> -static inline void xpfo_alloc_pages(struct page *page, int order, gfp_t gfp)
> { }
> +static inline void xpfo_alloc_pages(struct page *page, int order, gfp_t gfp,
> + bool will_map) { }
> static inline void xpfo_free_pages(struct page *page, int order) { }
>
> static inline bool xpfo_page_is_unmapped(struct page *page) { return false; }
> diff --git a/mm/compaction.c b/mm/compaction.c
> index fb548e4c7bd4..9a58e65c 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -76,7 +76,7 @@ static void map_pages(struct list_head *list)
> order = page_private(page);
> nr_pages = 1 << order;
>
> - post_alloc_hook(page, order, __GFP_MOVABLE);
> + post_alloc_hook(page, order, __GFP_MOVABLE, false);
> if (order)
> split_page(page, order);
>
> diff --git a/mm/internal.h b/mm/internal.h
> index 4ef49fc55e58..1a0331ec2b2d 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -165,7 +165,7 @@ extern void __free_pages_bootmem(struct page *page,
> unsigned long pfn,
> unsigned int order);
> extern void prep_compound_page(struct page *page, unsigned int order);
> extern void post_alloc_hook(struct page *page, unsigned int order,
> - gfp_t gfp_flags);
> + gfp_t gfp_flags, bool will_map);
> extern int user_min_free_kbytes;
>
> #if defined CONFIG_COMPACTION || defined CONFIG_CMA
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 09fdf1bad21f..f73809847c58 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1750,7 +1750,7 @@ static bool check_new_pages(struct page *page, unsigned
> int order)
> }
>
> inline void post_alloc_hook(struct page *page, unsigned int order,
> - gfp_t gfp_flags)
> + gfp_t gfp_flags, bool will_map)
> {
> set_page_private(page, 0);
> set_page_refcounted(page);
> @@ -1759,18 +1
[PATCH v2] tools: objtool: fix memory leak in elf_create_rela_section()
Let's free the allocated char array relaname before returning in order to avoid leaking memory. Signed-off-by: Martin Kepplinger --- I should've allocated some brain resources before freeing some computer's. tools/objtool/elf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c index 6e9f980a7d26..1e89a5f8bfc9 100644 --- a/tools/objtool/elf.c +++ b/tools/objtool/elf.c @@ -508,6 +508,7 @@ struct section *elf_create_rela_section(struct elf *elf, struct section *base) strcat(relaname, base->name); sec = elf_create_section(elf, relaname, sizeof(GElf_Rela), 0); + free(relaname); if (!sec) return NULL; -- 2.11.0
Re: [Outreachy kernel] [PATCH] staging: irda: Remove typedef struct
On Wed, 13 Sep 2017, Haneen Mohammed wrote:
> This patch remove typedef from a structure with all its ocurrences
> since using typedefs for structures is discouraged.
> Issue found using Coccinelle:
>
> @r1@
> type T;
> @@
>
> typedef struct { ... } T;
>
> @script:python c1@
> T2;
> T << r1.T;
> @@
> if T[-2:] =="_t" or T[-2:] == "_T":
> coccinelle.T2 = T[:-2];
> else:
> coccinelle.T2 = T;
>
> print T, coccinelle.T2
>
> @r2@
> type r1.T;
> identifier c1.T2;
> @@
> -typedef
> struct
> + T2
> { ... }
> -T
> ;
>
> @r3@
> type r1.T;
> identifier c1.T2;
> @@
> -T
> +struct T2
>
> Signed-off-by: Haneen Mohammed
Acked-by: Julia Lawall
> ---
> drivers/staging/irda/include/net/irda/qos.h | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/irda/include/net/irda/qos.h
> b/drivers/staging/irda/include/net/irda/qos.h
> index 05a5a24..a0315b5 100644
> --- a/drivers/staging/irda/include/net/irda/qos.h
> +++ b/drivers/staging/irda/include/net/irda/qos.h
> @@ -58,23 +58,23 @@
> #define IR_1600 0x02
>
> /* Quality of Service information */
> -typedef struct {
> +struct qos_value {
> __u32 value;
> __u16 bits; /* LSB is first byte, MSB is second byte */
> -} qos_value_t;
> +};
>
> struct qos_info {
> magic_t magic;
>
> - qos_value_t baud_rate; /* IR_11520O | ... */
> - qos_value_t max_turn_time;
> - qos_value_t data_size;
> - qos_value_t window_size;
> - qos_value_t additional_bofs;
> - qos_value_t min_turn_time;
> - qos_value_t link_disc_time;
> + struct qos_value baud_rate; /* IR_11520O | ... */
> + struct qos_value max_turn_time;
> + struct qos_value data_size;
> + struct qos_value window_size;
> + struct qos_value additional_bofs;
> + struct qos_value min_turn_time;
> + struct qos_value link_disc_time;
>
> - qos_value_t power;
> + struct qos_value power;
> };
>
> extern int sysctl_max_baud_rate;
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/20170914045538.GA24121%40Haneen.
> For more options, visit https://groups.google.com/d/optout.
>
[PATCH] scsi: libiscsi: Fix an error handling path in 'iscsi_session_setup()'
All error handling paths in this function go through 'iscsi_host_dec_session_cnt()' except this one. Fix it and properly decrement the number of active sessions in such a case. Signed-off-by: Christophe JAILLET --- drivers/scsi/libiscsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c index bd4605a34f54..5d195375ba75 100644 --- a/drivers/scsi/libiscsi.c +++ b/drivers/scsi/libiscsi.c @@ -2779,7 +2779,7 @@ iscsi_session_setup(struct iscsi_transport *iscsit, struct Scsi_Host *shost, "must be a power of 2.\n", total_cmds); total_cmds = rounddown_pow_of_two(total_cmds); if (total_cmds < ISCSI_TOTAL_CMDS_MIN) - return NULL; + goto dec_session_count; printk(KERN_INFO "iscsi: Rounding can_queue to %d.\n", total_cmds); } -- 2.11.0
Re: [PATCH 2/9] Implement containers as kernel objects
On 2017-09-06 09:03, Serge E. Hallyn wrote: > Quoting Richard Guy Briggs (r...@redhat.com): > ... > > > I believe we are going to need a container ID to container definition > > > (namespace, etc.) mapping mechanism regardless of if the container ID > > > is provided by userspace or a kernel generated serial number. This > > > mapping should be recorded in the audit log when the container ID is > > > created/defined. > > > > Agreed. > > > > > > As was suggested in one of the previous threads, if there are any > > > > events not > > > > associated with a task (incoming network packets) we log the namespace > > > > ID and > > > > then only concern ourselves with its container serial number or > > > > container name > > > > once it becomes associated with a task at which point that tracking > > > > will be > > > > more important anyways. > > > > > > Agreed. After all, a single namespace can be shared between multiple > > > containers. For those security officers who need to track individual > > > events like this they will have the container ID mapping information > > > in the logs as well so they should be able to trace the unassociated > > > event to a set of containers. > > > > > > > I'm not convinced that a userspace or kernel generated UUID is that > > > > useful > > > > since they are large, not human readable and may not be globally unique > > > > given > > > > the "pets vs cattle" direction we are going with potentially identical > > > > conditions in hosts or containers spawning containers, but I see no > > > > need to > > > > restrict them. > > > > > > From a kernel perspective I think an int should suffice; after all, > > > you can't have more containers then you have processes. If the > > > container engine requires something more complex, it can use the int > > > as input to its own mapping function. > > > > PIDs roll over. That already causes some ambiguity in reporting. If a > > system is constantly spawning and reaping containers, especially > > single-process containers, I don't want to have to worry about that ID > > rolling to keep track of it even though there should be audit records of > > the spawn and death of each container. There isn't significant cost > > added here compared with some of the other overhead we're dealing with. > > Strawman proposal: > > 1. Each clone/unshare/setns involving a namespace type generates an audit > message along the lines of: > > PID 9512 (pid in init_pid_ns) in auditnsid 0001 cloned > CLONE_NEWNS|CLONE_NEWNET > new auditnsid: 0002 > associated namespaces: (list of all namespace filesystem inode numbers) As you will have seen, this is pretty much what my most recent proposal suggests. > 2. Userspace (i.e. the container logging deamon here) can watch the audit log > for all messages relating to auditnsid 0002. Presumably there will be > messages along the lines of "PID 9513 in auditnsid 0002 cloned...". The > container logging daemon can track those messages and add the new auditnsids > to the list it watches. Yes. > 3. If a container is migrated (checkpointed and restored here or elsewhere), > userspace can just follow the appropriate logs for the new containers. Yes. > Userspace does not ever *request* a auditnsid. They are ephemeral, just a > tool to track the namespaces through the audit log. They are however > guaranteed > to never be re-used until reboot. Well, this is where things get controvertial... I had wanted this, a kernel-generated serial number unique to a running kernel to track every container initiation, but this does have some CRIU challenges pointed out by Eric Biederman. Nested containers will not have a consistent view on a new host and no way to make it consistent. If we could guarantee that containers would never be nested, this could be workable. I think nesting is inevitable in the future given the variety and creativity of the orchestration tools, so restricting this seems short-sighted. At the moment the approch is to let the orchestrator determine the ID of a container. Some have argued for as small as u32 and others for a full UUID. A u32 runs the risk of rolling, so a u64 seems like a reasonable step to solve that issue. Others would like to be able to store a full UUID which seemed like a good idea on the outset, but on further thinking, this is something the orchestrator can manage while minimising the number of bits of required information per audit record to guarantee we can identify the provenance of a particular audit event. Let's see if we can make it work with a u64. > (Feels like someone must have proposed this before) Thsee ideas have been thrown around a few times and I'm starting to understand them better. > -serge - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635
[PATCH] dmaengine: imx-sdma: Correct addr widths
The driver also supports 2_BYTES and 1_BYTE in sdma_prep_slave_sg(). So this patch just adds them to the lists. Signed-off-by: Nicolin Chen --- drivers/dma/imx-sdma.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index a67ec1b..2be8d0d 100644 --- a/drivers/dma/imx-sdma.c +++ b/drivers/dma/imx-sdma.c @@ -178,6 +178,10 @@ #define SDMA_WATERMARK_LEVEL_HWE BIT(29) #define SDMA_WATERMARK_LEVEL_CONT BIT(31) +#define SDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \ +BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \ +BIT(DMA_SLAVE_BUSWIDTH_4_BYTES)) + /* * Mode/Count of data node descriptors - IPCv2 */ @@ -1851,8 +1855,8 @@ static int sdma_probe(struct platform_device *pdev) sdma->dma_device.device_prep_dma_cyclic = sdma_prep_dma_cyclic; sdma->dma_device.device_config = sdma_config; sdma->dma_device.device_terminate_all = sdma_disable_channel_with_delay; - sdma->dma_device.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES); - sdma->dma_device.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES); + sdma->dma_device.src_addr_widths = SDMA_DMA_BUSWIDTHS; + sdma->dma_device.dst_addr_widths = SDMA_DMA_BUSWIDTHS; sdma->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV); sdma->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT; sdma->dma_device.device_issue_pending = sdma_issue_pending; -- 2.1.4
Re: [PATCH 4.9 00/14] 4.9.50-stable review
On Thu, Sep 14, 2017 at 04:18:03AM +0200, Willy Tarreau wrote: > On Wed, Sep 13, 2017 at 02:30:46PM -0700, Greg Kroah-Hartman wrote: > > > Yes. I don't recall if it is a direct --force or if you would have to > > > remove the original tag first (with git push :refs/tags/). > > > > Ah, but then if someone had pulled the old tag, they would have to > > delete it locally before they can pull in the new one. That's the main > > reason I'll not do this... > > In fact not, the tags are automatically replaced upon pull. I've been > using such a crappy workflow for some time in the past, sharing human > errors with coworkers... Git is pretty tolerant to this. It's just > that it's terribly confusing because you can then have two people with > the same tag name pointing to different commit IDs, I really hate this, > it only works when all users are in the same office and you shout > "sorry I messed up, I'm pushing the tag again". > > > Again, use the make command that we have just for this reason... > > It also has the benefit of always reporting the same version for all > users including those only downloading the -rc patch. > It reports the same version, but it is not necessarily the same code. There are cases where a rc is updated, but not the Makefile. That happens quite a lot, actually. This is similar to mainline, which currently claims to be v4.13.0 until -rc1, then it claims to be -rc1 until -rc2, and so on. Guenter
Re: [PATCH] checkpatch: support function pointers for unnamed function definition arguments
On Thu, 2017-09-14 at 11:01 +0800, Miles Chen wrote:
> Current unnamed function definition argument does not include function
> pointer cases and it reports warnings like:
>
> WARNING: function definition argument 'void' should also have an identifier
> name
>
> Support function pointers for unnamed function arguments.
>
> Signed-off-by: Miles Chen
> ---
> scripts/checkpatch.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index dd2c262..dc6da15 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -5957,7 +5957,7 @@ sub process {
>
> # check for function declarations that have arguments without identifier
> names
> if (defined $stat &&
> - $stat =~
> /^.\s*(?:extern\s+)?$Type\s*$Ident\s*\(\s*([^{]+)\s*\)\s*;/s &&
> + $stat =~
> /^.\s*(?:extern\s+)?$Type\s*\(?\s*\*?\s*$Ident\s*\)\s*\(\s*([^{]+)\s*\)\s*;/s
> &&
Better would be to specifically support function pointers like:
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 05dd72693621..7289c1eb0b19 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5957,7 +5957,7 @@ sub process {
# check for function declarations that have arguments without identifier names
if (defined $stat &&
- $stat =~
/^.\s*(?:extern\s+)?$Type\s*$Ident\s*\(\s*([^{]+)\s*\)\s*;/s &&
+ $stat =~
/^.\s*(?:extern\s+)?$Type\s*(?:$Ident|\(\s*\*\s*$Ident\s*\))\s*\(\s*([^{]+)\s*\)\s*;/s
&&
$1 ne "void") {
my $args = trim($1);
while ($args =~
m/\s*($Type\s*(?:$Ident|\(\s*\*\s*$Ident?\s*\)\s*$balanced_parens)?)/g) {
Re: [PATCH] tools: objtool: fix memory leak in elf_create_rela_section()
* Josh Poimboeuf wrote:
> From: Martin Kepplinger
>
> Let's free the allocated char array relaname before returning
> in order to avoid leaking memory.
>
> Signed-off-by: Martin Kepplinger
> Signed-off-by: Josh Poimboeuf
> ---
> tools/objtool/elf.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
> index 6e9f980a7d26..6aacbc31316d 100644
> --- a/tools/objtool/elf.c
> +++ b/tools/objtool/elf.c
> @@ -508,8 +508,12 @@ struct section *elf_create_rela_section(struct elf *elf,
> struct section *base)
> strcat(relaname, base->name);
>
> sec = elf_create_section(elf, relaname, sizeof(GElf_Rela), 0);
> - if (!sec)
> + if (!sec) {
> + free(relaname);
> return NULL;
> + }
> +
> + free(relaname);
Erm, I'm quite sure if you read this code a second time you'll see how this
pattern could be improved! ;-)
Thanks,
Ingo
Re: RFC: Audit Kernel Container IDs
On 2017-09-13 14:33, Carlos O'Donell wrote: > On 09/13/2017 12:13 PM, Richard Guy Briggs wrote: > > Containers are a userspace concept. The kernel knows nothing of them. > > I am looking at this RFC from a userspace perspective, particularly from > the loader's point of view and the unshare syscall and the semantics that > arise from the use of it. > > At a high level what you are doing is providing a way to group, without > hierarchy, processes and namespaces. The processes can move between > container's if they have CAP_CONTAINER_ADMIN and can open and write to > a special proc file. > > * With unshare a thread may dissociate part of its execution context and > therefore see a distinct mount namespace. When you say "process" in this > particular RFC do you exclude the fact that a thread might be in a > distinct container from the rest of the threads in the process? > > > The Linux audit system needs a way to be able to track the container > > provenance of events and actions. Audit needs the kernel's help to do > > this. > > * Why does the Linux audit system need to tracker container provenance? - ability to filter unwanted, irrelevant or unimportant messages before they fill queue so important messages don't get lost. This is a certification requirement. - ability to make security claims about containers, require tracking of actions within those containers to ensure compliance with established security policies. - ability to route messages from events to relevant audit daemon instance or host audit daemon instance or both, as required or determined by user-initiated rules > - How does it help to provide better audit messages? > > - Is it be enough to list the namespace that a process occupies? We started with that approach back more than 4 years ago and found it helped, but didn't go far enough in terms of quick and inexpensive record filtering and left some doubt about provenance of events in the case of non-user context events (incoming network packets). > * Why does it need the kernel's help? > > - Is there a race condition that is only fixable with kernel support? This was a concern, but relatively minor compared with the other benefits. > - Or is it easier with kernel help but not required? It is much easier and much less expensive. > Providing background on these questions would help clarify the > design requirements. Here are some references that should help provide some background: https://github.com/linux-audit/audit-kernel/issues/32 RFE: add namespace IDs to audit records https://github.com/linux-audit/audit-documentation/wiki/SPEC-Virtualization-Manager-Guest-Lifecycle-Events SPEC Virtualization Manager Guest Lifecycle Events https://lwn.net/Articles/699819/ Audit, namespaces, and containers https://lwn.net/Articles/723561/ Containers as kernel objects (my reply, with references: https://lkml.org/lkml/2017/8/14/15 ) https://bugzilla.redhat.com/show_bug.cgi?id=1045666 audit: add namespace IDs to log records > > Since the concept of a container is entirely a userspace concept, a > > trigger signal from the userspace container orchestration system > > initiates this. This will define a point in time and a set of resources > > associated with a particular container with an audit container ID. > > Please don't use the word 'signal', I suggest 'register' since you are > writing to a filesystem. Ok, that's a very reasonable request. 'signal' has a previous meaning. > > The trigger is a pseudo filesystem (proc, since PID tree already exists) > > write of a u64 representing the container ID to a file representing a > > process that will become the first process in a new container. > > This might place restrictions on mount namespaces required to define a > > container, or at least careful checking of namespaces in the kernel to > > verify permissions of the orchestrator so it can't change its own > > container ID. > > A bind mount of nsfs may be necessary in the container orchestrator's > > mntNS. > > > > Require a new CAP_CONTAINER_ADMIN to be able to write to the pseudo > > filesystem to have this action permitted. At that time, record the > > child container's user-supplied 64-bit container identifier along with > > What is a "child container?" Containers don't have any hierarchy. Maybe some don't, but that's not likely to last long given the abstraction and nesting of orchestration tools. This must be nestable. > I assume that if you don't have CAP_CONTAINER_ADMIN, that nothing prevents > your continued operation as we have today? Correct. It won't prevent processes that otherwise have permissions today from creating all the namespaces it wishes. > > the child container's first process (which may become the container's > > "init" process) process ID (referenced from the initial PID namespace), > > all namespace IDs (in the form of a nsfs device
Re: [patch V2 25/29] lockup_detector: Implement init time detection of perf
* Thomas Gleixner wrote: > On Wed, 13 Sep 2017, Don Zickus wrote: > > > +/* Return 0, if a NMI watchdog is available. Error code otherwise */ > > > +int __weak __init void watchdog_nmi_probe(void) > > > > ^^^ compile error, can't have 'int' and 'void'. Removing 'void' fixes it. > > Yes, I know. I feel stupid because I'm 100% sure that I compiled it So there a Kconfig dependency on that - defconfig won't show it, which might be why you didn't see it? Thanks, Ingo
Re: [patch V2 00/29] lockup_detector: Cure hotplug deadlocks and replace duct tape
* Don Zickus wrote: > On Tue, Sep 12, 2017 at 09:36:54PM +0200, Thomas Gleixner wrote: > > The lockup detector is broken is several ways: > > > > - It's deadlock prone vs. CPU hotplug in various ways. Some of these > > are due to recursive cpus_read_lock() others are due to > > cpus_read_lock() from CPU hotplug callbacks which immediately lock > > the machine because cpus are write locked. > > > > - The handling of the cpu hotplug threads happens sideways to the > > smpboot thread infrastructure, which is racy and pointless > > > > - The handling of the user space sysctl interface is a complete > > trainwreck as it fiddles directly with variables which can be > > modified or evaluated by the running watchdogs. > > > > - The perf event initialization is a trainwreck as it tries to create > > perf events over and over even if perf is not functional (no > > hardware, ). To avoid excessive dmesg spam it contains magic > > printk ratelimiting along with either wrong or useless messages. > > > > - The code structure is horrible as ifdef sections are scattered all > > over the place which makes it unreadable > > > > - There is more wreckage, but see the changelogs for the ugly details. > > > > Aside from the simple compile issue in patch 25. I have no issues with this > patchset. Thanks Thomas! > > Reviewed-by: Don Zickus Thanks guys! I've applied the series and will push it out after some testing. Thanks, Ingo
[PATCH] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD
According to Spec, it is ILLEGAL to set STE.S1STALLD if STALL_MODEL
is not 0b00, which means we should not disable stall mode if stall
or terminate mode is not configuable.
As Jean-Philippe's suggestion, this patch introduce a feature bit
ARM_SMMU_FEAT_STALL_FORCE, which means smmu only supports stall force.
Therefore, we can avoid the ILLEGAL setting of STE.S1STALLD.by checking
ARM_SMMU_FEAT_STALL_FORCE.
This patch keeps the ARM_SMMU_FEAT_STALLS as the meaning of stall supported
(force or configuable) to easy to expand the future function, i.e. we can
only use ARM_SMMU_FEAT_STALLS to check whether we should register fault
handle or enable master can_stall, etc to supporte platform SVM.
After apply this patch, the feature bit and S1STALLD setting will be like:
STALL_MODEL FEATURE S1STALLD
0b00 ARM_SMMU_FEAT_STALLS 0b1
0b01 !ARM_SMMU_FEAT_STALLS && !ARM_SMMU_FEAT_STALL_FORCE 0b0
0b10 ARM_SMMU_FEAT_STALLS && ARM_SMMU_FEAT_STALL_FORCE0b0
Signed-off-by: Yisheng Xie
---
drivers/iommu/arm-smmu-v3.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index e67ba6c..d2a3627 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -603,7 +603,8 @@ struct arm_smmu_device {
#define ARM_SMMU_FEAT_TRANS_S1 (1 << 9)
#define ARM_SMMU_FEAT_TRANS_S2 (1 << 10)
#define ARM_SMMU_FEAT_STALLS (1 << 11)
-#define ARM_SMMU_FEAT_HYP (1 << 12)
+#define ARM_SMMU_FEAT_STALL_FORCE (1 << 12)
+#define ARM_SMMU_FEAT_HYP (1 << 13)
u32 features;
#define ARM_SMMU_OPT_SKIP_PREFETCH (1 << 0)
@@ -1112,7 +1113,8 @@ static void arm_smmu_write_strtab_ent(struct
arm_smmu_device *smmu, u32 sid,
#endif
STRTAB_STE_1_STRW_NSEL1 << STRTAB_STE_1_STRW_SHIFT);
- if (smmu->features & ARM_SMMU_FEAT_STALLS)
+ if (smmu->features & ARM_SMMU_FEAT_STALLS &&
+ !(smmu->features & ARM_SMMU_FEAT_STALL_FORCE))
dst[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
val |= (ste->s1_cfg->cdptr_dma & STRTAB_STE_0_S1CTXPTR_MASK
@@ -2536,9 +2538,10 @@ static int arm_smmu_device_hw_probe(struct
arm_smmu_device *smmu)
coherent ? "true" : "false");
switch (reg & IDR0_STALL_MODEL_MASK << IDR0_STALL_MODEL_SHIFT) {
- case IDR0_STALL_MODEL_STALL:
- /* Fallthrough */
case IDR0_STALL_MODEL_FORCE:
+ smmu->features |= ARM_SMMU_FEAT_STALL_FORCE;
+ /* Fallthrough */
+ case IDR0_STALL_MODEL_STALL:
smmu->features |= ARM_SMMU_FEAT_STALLS;
}
--
1.7.12.4
[PATCH 1/1] irqchip/gicv3: iterate over possible CPUs by for_each_possible_cpu()
From: zijun_hu
get_cpu_number() doesn't use existing helper to iterate over possible
CPUs, so error happens in case of discontinuous @cpu_possible_mask
such as 0b0001.
fixed by using existing helper for_each_possible_cpu().
Signed-off-by: zijun_hu
---
drivers/irqchip/irq-gic-v3.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 19d642eae096..2a0427c2971e 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -990,7 +990,7 @@ static int get_cpu_number(struct device_node *dn)
{
const __be32 *cell;
u64 hwid;
- int i;
+ int cpu;
cell = of_get_property(dn, "reg", NULL);
if (!cell)
@@ -1004,9 +1004,9 @@ static int get_cpu_number(struct device_node *dn)
if (hwid & ~MPIDR_HWID_BITMASK)
return -1;
- for (i = 0; i < num_possible_cpus(); i++)
- if (cpu_logical_map(i) == hwid)
- return i;
+ for_each_possible_cpu(cpu)
+ if (cpu_logical_map(cpu) == hwid)
+ return cpu;
return -1;
}
--
1.9.1
[PATCH v2 3/3] media: ov7670: Add the s_power operation
Add the s_power operation which is responsible for manipulating the
power dowm mode through the PWDN pin and the reset operation through
the RESET pin.
Signed-off-by: Wenyou Yang
---
Changes in v2:
- Add the patch to support the get_fmt ops.
- Remove the redundant invoking ov7670_init_gpio().
drivers/media/i2c/ov7670.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index efc738112e2a..d1211ae48f63 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1530,6 +1530,22 @@ static int ov7670_s_register(struct v4l2_subdev *sd,
const struct v4l2_dbg_regis
}
#endif
+static int ov7670_s_power(struct v4l2_subdev *sd, int on)
+{
+ struct ov7670_info *info = to_state(sd);
+
+ if (info->pwdn_gpio)
+ gpiod_direction_output(info->pwdn_gpio, !on);
+ if (on && info->resetb_gpio) {
+ gpiod_set_value(info->resetb_gpio, 1);
+ usleep_range(500, 1000);
+ gpiod_set_value(info->resetb_gpio, 0);
+ usleep_range(3000, 5000);
+ }
+
+ return 0;
+}
+
/* --- */
static const struct v4l2_subdev_core_ops ov7670_core_ops = {
@@ -1539,6 +1555,7 @@ static const struct v4l2_subdev_core_ops ov7670_core_ops
= {
.g_register = ov7670_g_register,
.s_register = ov7670_s_register,
#endif
+ .s_power = ov7670_s_power,
};
static const struct v4l2_subdev_video_ops ov7670_video_ops = {
@@ -1645,23 +1662,25 @@ static int ov7670_probe(struct i2c_client *client,
if (ret)
return ret;
- ret = ov7670_init_gpio(client, info);
- if (ret)
- goto clk_disable;
-
info->clock_speed = clk_get_rate(info->clk) / 100;
if (info->clock_speed < 10 || info->clock_speed > 48) {
ret = -EINVAL;
goto clk_disable;
}
+ ret = ov7670_init_gpio(client, info);
+ if (ret)
+ goto clk_disable;
+
+ ov7670_s_power(sd, 1);
+
/* Make sure it's an ov7670 */
ret = ov7670_detect(sd);
if (ret) {
v4l_dbg(1, debug, client,
"chip found @ 0x%x (%s) is not an ov7670 chip.\n",
client->addr << 1, client->adapter->name);
- goto clk_disable;
+ goto power_off;
}
v4l_info(client, "chip found @ 0x%02x (%s)\n",
client->addr << 1, client->adapter->name);
@@ -1734,6 +1753,8 @@ static int ov7670_probe(struct i2c_client *client,
media_entity_cleanup(&info->sd.entity);
hdl_free:
v4l2_ctrl_handler_free(&info->hdl);
+power_off:
+ ov7670_s_power(sd, 0);
clk_disable:
clk_disable_unprepare(info->clk);
return ret;
@@ -1749,6 +1770,7 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_ctrl_handler_free(&info->hdl);
clk_disable_unprepare(info->clk);
media_entity_cleanup(&info->sd.entity);
+ ov7670_s_power(sd, 0);
return 0;
}
--
2.13.0
[PATCH v2 2/3] media: ov7670: Add the get_fmt callback
Add the get_fmt callback, also enable V4L2_SUBDEV_FL_HAS_DEVNODE flag
to make this subdev has device node.
Signed-off-by: Wenyou Yang
---
Changes in v2: None
drivers/media/i2c/ov7670.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 5c8460ee65c3..efc738112e2a 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -230,6 +230,7 @@ struct ov7670_info {
struct v4l2_ctrl *saturation;
struct v4l2_ctrl *hue;
};
+ struct v4l2_mbus_framefmt format;
struct ov7670_format_struct *fmt; /* Current format */
struct clk *clk;
struct gpio_desc *resetb_gpio;
@@ -973,6 +974,29 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
fmt->width = wsize->width;
fmt->height = wsize->height;
fmt->colorspace = ov7670_formats[index].colorspace;
+
+ info->format.code = fmt->code;
+ info->format.width = fmt->width;
+ info->format.height = fmt->height;
+ info->format.colorspace = fmt->colorspace;
+
+ return 0;
+}
+
+static int ov7670_get_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *format)
+{
+ struct ov7670_info *info = to_state(sd);
+ struct v4l2_mbus_framefmt *fmt;
+
+ if (format->which == V4L2_SUBDEV_FORMAT_TRY)
+ fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
+ else
+ fmt = &info->format;
+
+ format->format = *fmt;
+
return 0;
}
@@ -1526,6 +1550,7 @@ static const struct v4l2_subdev_pad_ops ov7670_pad_ops = {
.enum_frame_interval = ov7670_enum_frame_interval,
.enum_frame_size = ov7670_enum_frame_size,
.enum_mbus_code = ov7670_enum_mbus_code,
+ .get_fmt = ov7670_get_fmt,
.set_fmt = ov7670_set_fmt,
};
@@ -1698,6 +1723,7 @@ static int ov7670_probe(struct i2c_client *client,
v4l2_ctrl_handler_setup(&info->hdl);
+ info->sd.flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
ret = v4l2_async_register_subdev(&info->sd);
if (ret < 0)
goto entity_cleanup;
--
2.13.0
[PATCH v2 1/3] media: ov7670: Add entity pads initialization
Add the media entity pads initialization.
Signed-off-by: Wenyou Yang
---
Changes in v2: None
drivers/media/i2c/ov7670.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index e88549f0e704..5c8460ee65c3 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -213,6 +213,7 @@ struct ov7670_devtype {
struct ov7670_format_struct; /* coming later */
struct ov7670_info {
struct v4l2_subdev sd;
+ struct media_pad pad;
struct v4l2_ctrl_handler hdl;
struct {
/* gain cluster */
@@ -1688,14 +1689,23 @@ static int ov7670_probe(struct i2c_client *client,
v4l2_ctrl_auto_cluster(2, &info->auto_exposure,
V4L2_EXPOSURE_MANUAL, false);
v4l2_ctrl_cluster(2, &info->saturation);
+
+ info->pad.flags = MEDIA_PAD_FL_SOURCE;
+ info->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+ ret = media_entity_pads_init(&info->sd.entity, 1, &info->pad);
+ if (ret < 0)
+ goto hdl_free;
+
v4l2_ctrl_handler_setup(&info->hdl);
ret = v4l2_async_register_subdev(&info->sd);
if (ret < 0)
- goto hdl_free;
+ goto entity_cleanup;
return 0;
+entity_cleanup:
+ media_entity_cleanup(&info->sd.entity);
hdl_free:
v4l2_ctrl_handler_free(&info->hdl);
clk_disable:
@@ -1712,6 +1722,7 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(&info->hdl);
clk_disable_unprepare(info->clk);
+ media_entity_cleanup(&info->sd.entity);
return 0;
}
--
2.13.0
[PATCH v2 0/3] media: ov7670: Add entity init and power operation
This patch set is to add the media entity pads initialization, the s_power operation and get_fmt callback support. Changes in v2: - Add the patch to support the get_fmt ops. - Remove the redundant invoking ov7670_init_gpio(). Wenyou Yang (3): media: ov7670: Add entity pads initialization media: ov7670: Add the get_fmt callback media: ov7670: Add the s_power operation drivers/media/i2c/ov7670.c | 71 ++ 1 file changed, 65 insertions(+), 6 deletions(-) -- 2.13.0
Re: [Outreachy kernel] Re: [PATCH v2 1/2] include: linux: sysfs: Add __ATTR_NAMED macro
On Wed, 13 Sep 2017, Joe Perches wrote: > On Thu, 2017-09-14 at 00:43 +0300, Dan Carpenter wrote: > > He was exagerating a bit to call it a "static checker" warning... > > Not really. > > False positives and false negatives exist in just about > every static > checker. > > > It's just checkpatch.pl complaining about adding spaces around the - > > operator. > > checkpatch is a brain-damaged by design static checker. > regexes can only be sensitive to patterns, not compiled code. > > > The sysfs file has a hyphen in the middle. > > Another option would be to use an underscore instead. There are already underscores on either side. julia > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To post to this group, send email to outreachy-ker...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/1505339903.8969.20.camel%40perches.com. > For more options, visit https://groups.google.com/d/optout. >
Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates
On Thursday 14 September 2017 03:28 AM, Franklin S Cooper Jr wrote:
>
>
> On 08/18/2017 02:39 PM, Franklin S Cooper Jr wrote:
>> During test transmitting using CAN-FD at high bitrates (4 Mbps) only
>> resulted in errors. Scoping the signals I noticed that only a single bit
>> was being transmitted and with a bit more investigation realized the actual
>> MCAN IP would go back to initialization mode automatically.
>>
>> It appears this issue is due to the MCAN needing to use the Transmitter
>> Delay Compensation Mode as defined in the MCAN User's Guide. When this
>> mode is used the User's Guide indicates that the Transmitter Delay
>> Compensation Offset register should be set. The document mentions that this
>> register should be set to (1/dbitrate)/2*(Func Clk Freq).
>>
>> Additional CAN-CIA's "Bit Time Requirements for CAN FD" document indicates
>> that this TDC mode is only needed for data bit rates above 2.5 Mbps.
>> Therefore, only enable this mode and only set TDCO when the data bit rate
>> is above 2.5 Mbps.
>>
>> Signed-off-by: Franklin S Cooper Jr
>> ---
>> I'm pretty surprised that this hasn't been implemented already since
>> the primary purpose of CAN-FD is to go beyond 1 Mbps and the MCAN IP
>> supports up to 10 Mbps.
>>
>> So it will be nice to get comments from users of this driver to understand
>> if they have been able to use CAN-FD beyond 2.5 Mbps without this patch.
>> If they haven't what did they do to get around it if they needed higher
>> speeds.
>>
>> Meanwhile I plan on testing this using a more "realistic" CAN bus to insure
>> everything still works at 5 Mbps which is the max speed of my CAN
>> transceiver.
>
> ping. Anyone has any thoughts on this?
I added Dong who authored the m_can driver and Wenyou who added the only
in-kernel user of the driver for any help.
Thanks,
Sekhar
>>
>> drivers/net/can/m_can/m_can.c | 24 +++-
>> 1 file changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
>> index f4947a7..720e073 100644
>> --- a/drivers/net/can/m_can/m_can.c
>> +++ b/drivers/net/can/m_can/m_can.c
>> @@ -126,6 +126,12 @@ enum m_can_mram_cfg {
>> #define DBTP_DSJW_SHIFT 0
>> #define DBTP_DSJW_MASK (0xf << DBTP_DSJW_SHIFT)
>>
>> +/* Transmitter Delay Compensation Register (TDCR) */
>> +#define TDCR_TDCO_SHIFT 8
>> +#define TDCR_TDCO_MASK (0x7F << TDCR_TDCO_SHIFT)
>> +#define TDCR_TDCF_SHIFT 0
>> +#define TDCR_TDCF_MASK (0x7F << TDCR_TDCO_SHIFT)
>> +
>> /* Test Register (TEST) */
>> #define TEST_LBCK BIT(4)
>>
>> @@ -977,6 +983,8 @@ static int m_can_set_bittiming(struct net_device *dev)
>> const struct can_bittiming *dbt = &priv->can.data_bittiming;
>> u16 brp, sjw, tseg1, tseg2;
>> u32 reg_btp;
>> +u32 enable_tdc = 0;
>> +u32 tdco;
>>
>> brp = bt->brp - 1;
>> sjw = bt->sjw - 1;
>> @@ -991,9 +999,23 @@ static int m_can_set_bittiming(struct net_device *dev)
>> sjw = dbt->sjw - 1;
>> tseg1 = dbt->prop_seg + dbt->phase_seg1 - 1;
>> tseg2 = dbt->phase_seg2 - 1;
>> +
>> +/* TDC is only needed for bitrates beyond 2.5 MBit/s
>> + * Specified in the "Bit Time Requirements for CAN FD" document
>> + */
>> +if (dbt->bitrate > 250) {
>> +enable_tdc = DBTP_TDC;
>> +/* Equation based on Bosch's M_CAN User Manual's
>> + * Transmitter Delay Compensation Section
>> + */
>> +tdco = priv->can.clock.freq / (dbt->bitrate * 2);
>> +m_can_write(priv, M_CAN_TDCR, tdco << TDCR_TDCO_SHIFT);
>> +}
>> +
>> reg_btp = (brp << DBTP_DBRP_SHIFT) | (sjw << DBTP_DSJW_SHIFT) |
>> (tseg1 << DBTP_DTSEG1_SHIFT) |
>> -(tseg2 << DBTP_DTSEG2_SHIFT);
>> +(tseg2 << DBTP_DTSEG2_SHIFT) | enable_tdc;
>> +
>> m_can_write(priv, M_CAN_DBTP, reg_btp);
>> }
>>
>>
[PATCH] staging: irda: Remove typedef struct
This patch remove typedef from a structure with all its ocurrences
since using typedefs for structures is discouraged.
Issue found using Coccinelle:
@r1@
type T;
@@
typedef struct { ... } T;
@script:python c1@
T2;
T << r1.T;
@@
if T[-2:] =="_t" or T[-2:] == "_T":
coccinelle.T2 = T[:-2];
else:
coccinelle.T2 = T;
print T, coccinelle.T2
@r2@
type r1.T;
identifier c1.T2;
@@
-typedef
struct
+ T2
{ ... }
-T
;
@r3@
type r1.T;
identifier c1.T2;
@@
-T
+struct T2
Signed-off-by: Haneen Mohammed
---
drivers/staging/irda/include/net/irda/qos.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/irda/include/net/irda/qos.h
b/drivers/staging/irda/include/net/irda/qos.h
index 05a5a24..a0315b5 100644
--- a/drivers/staging/irda/include/net/irda/qos.h
+++ b/drivers/staging/irda/include/net/irda/qos.h
@@ -58,23 +58,23 @@
#define IR_1600 0x02
/* Quality of Service information */
-typedef struct {
+struct qos_value {
__u32 value;
__u16 bits; /* LSB is first byte, MSB is second byte */
-} qos_value_t;
+};
struct qos_info {
magic_t magic;
- qos_value_t baud_rate; /* IR_11520O | ... */
- qos_value_t max_turn_time;
- qos_value_t data_size;
- qos_value_t window_size;
- qos_value_t additional_bofs;
- qos_value_t min_turn_time;
- qos_value_t link_disc_time;
+ struct qos_value baud_rate; /* IR_11520O | ... */
+ struct qos_value max_turn_time;
+ struct qos_value data_size;
+ struct qos_value window_size;
+ struct qos_value additional_bofs;
+ struct qos_value min_turn_time;
+ struct qos_value link_disc_time;
- qos_value_t power;
+ struct qos_value power;
};
extern int sysctl_max_baud_rate;
--
2.7.4
Re: [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation
> I think the changelog for this series of conversions > should show that you've validated the change by > inspecting the return call chain at each modified line. > > Also, it seems you've cc'd the same mailing lists for > all of the patches modified by this series. > > It would be better to individually address each patch > in the series only cc'ing the appropriate maintainers > and mailing lists. > > A cover letter would be good too. Point noted. Thanks. - Allen
[PATCH] Input: add support for HiDeep touchscreen
The HiDeep touchscreen device is a capacitive multi-touch controller
mainly for multi-touch supported devices use. It use I2C interface for
communication to IC and provide axis X, Y, Z locations for ten finger
touch through input event interface to userspace.
It support the Crimson and the Lime two type IC. They are different
the number of channel supported and FW size. But the working protocol
is same.
Signed-off-by: Anthony Kim
---
.../bindings/input/touchscreen/hideep.txt | 42 +
.../devicetree/bindings/vendor-prefixes.txt|1 +
drivers/input/touchscreen/Kconfig | 11 +
drivers/input/touchscreen/Makefile |1 +
drivers/input/touchscreen/hideep.c | 1274
5 files changed, 1329 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/hideep.txt
create mode 100644 drivers/input/touchscreen/hideep.c
diff --git a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
new file mode 100644
index 000..86b3a97
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
@@ -0,0 +1,42 @@
+* HiDeep Finger and Stylus touchscreen controller
+
+Required properties:
+- compatible : must be "hideep,hideep-ts"
+- reg : I2C slave address, (e.g. 0x6C).
+- interrupt-parent : Interrupt controller to which the chip is connected.
+- interrupts : Interrupt to which the chip is connected.
+
+Optional properties:
+- vdd-supply : It is the controller supply for controlling
+main voltage(3.3V) through the
regulator.
+- vid-supply : It is the controller supply for controlling
+ IO voltage(1.8V) through the regulator.
+- reset-gpios : Define for reset gpio pin.
+ It is to use for reset IC.
+- touchscreen-size-x : X axis size of touchscreen
+- touchscreen-size-y : Y axis size of touchscreen
+- linux,keycodes : Specifies an array of numeric keycode values to
+ be used for reporting button presses. The array can
+ contain up to 3 entries.
+
+Example:
+
+#include "dt-bindings/input/input.h"
+
+i2c@ {
+
+ /* ... */
+
+ touchscreen@6c {
+ compatible = "hideep,hideep-ts";
+ reg = <0x6c>;
+ interrupt-parent = <&gpx1>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ vdd-supply = <&ldo15_reg>";
+ vid-supply = <&ldo18_reg>;
+ reset-gpios = <&gpx1 5 0>;
+ touchscreen-size-x = 1079;
+ touchscreen-size-y = 1919;
+ linux,keycodes = , , ;
+ };
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index c03d201..aa2a301 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -131,6 +131,7 @@ gw Gateworks Corporation
hannstar HannStar Display Corporation
haoyu Haoyu Microelectronic Co. Ltd.
hardkernel Hardkernel Co., Ltd
+hideep HiDeep Inc.
himax Himax Technologies, Inc.
hisilicon Hisilicon Limited.
hitHitachi Ltd.
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 64b30fe..d0c8dafc 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -344,6 +344,17 @@ config TOUCHSCREEN_GOODIX
To compile this driver as a module, choose M here: the
module will be called goodix.
+config TOUCHSCREEN_HIDEEP
+ tristate "HiDeep Touch IC"
+ depends on I2C
+ help
+ Say Y here if you have a touchscreen using HiDeep.
+
+ If unsure, say N.
+
+ To compile this driver as a moudle, choose M here : the
+ module will be called hideep_ts.
+
config TOUCHSCREEN_ILI210X
tristate "Ilitek ILI210X based touchscreen"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
index 6badce8..873b67e 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_TOUCHSCREEN_EGALAX) += egalax_ts.o
obj-$(CONFIG_TOUCHSCREEN_EGALAX_SERIAL)+= egalax_ts_serial.o
obj-$(CONFIG_TOUCHSCREEN_FUJITSU) += fujitsu_ts.o
obj-$(CONFIG_TOUCHSCREEN_GOODIX) += goodix.o
+obj-$(CONFIG_TOUCHSCREEN_HIDEEP) += hideep.o
obj-$(CONFIG_TOUCHSCREEN_ILI210X) += ili210x.o
obj-$(CONFIG_TOUCHSCREEN_IMX6UL_TSC) += imx6ul_tsc.o
obj-$(CONFIG_TOUCHSCREEN_INEXIO) += inexio.o
diff --git a/drivers/input/touchscreen/hideep.c
b/drivers/input/touchscreen/hideep.c
new file mode 100644
index 000..f1b021b
--- /dev/null
+++ b/drivers/input/touchscreen/hideep.c
@@ -
[lkp-robot] [kprobes] e1ce3eee7d: BUG:using_smp_processor_id()in_preemptible
FYI, we noticed the following commit:
commit: e1ce3eee7dcda03f2b2f2d64e2cb2f3a993a3b34 ("kprobes: Use
synchronize_rcu_tasks() for optprobe with CONFIG_PREEMPT")
url:
https://github.com/0day-ci/linux/commits/Masami-Hiramatsu/kprobes-Use-synchronize_rcu_tasks-for-optprobe-with-CONFIG_PREEMPT/20170913-034557
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -smp 2
-m 512M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
++++
|| 80cee03bf1 | e1ce3eee7d |
++++
| boot_successes | 28 | 5 |
| boot_failures | 0 | 23 |
| BUG:using_smp_processor_id()in_preemptible | 0 | 23 |
++++
[ 14.675660] BUG: using smp_processor_id() in preemptible [] code:
swapper/0/1
[ 14.700932] caller is debug_smp_processor_id+0x17/0x20
[ 14.725623] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0-06467-ge1ce3ee
#2
[ 14.729560] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.9.3-20161025_171302-gandalf 04/01/2014
[ 14.772244] Call Trace:
[ 14.772244] dump_stack+0x65/0x87
[ 14.772244] check_preemption_disabled+0xda/0xe0
[ 14.772244] debug_smp_processor_id+0x17/0x20
[ 14.772244] optimized_callback+0x1f/0xf0
[ 14.772244] 0xa0002370
[ 14.772244] ? init_test_probes+0x2cf/0x530
[ 14.772244] init_kprobes+0x1e6/0x1f1
[ 14.772244] ? debugfs_kprobe_init+0xa5/0xa5
[ 14.772244] do_one_initcall+0x4e/0x190
[ 14.772244] kernel_init_freeable+0x113/0x194
[ 14.772244] ? rest_init+0x130/0x130
[ 14.772244] kernel_init+0x9/0xf2
[ 14.772244] ret_from_fork+0x25/0x30
[ 16.007679] Kprobe smoke test: passed successfully
[ 16.025466] Initialise system trusted keyrings
[ 16.062596] workingset: timestamp_bits=46 max_order=17 bucket_order=0
[ 16.151965] efs: 1.0a - http://aeschi.ch.eu.org/efs/
[ 16.164959] fuse init (API version 7.26)
[ 16.183177] orangefs_debugfs_init: called with debug mask: :none: :0:
[ 16.196644] orangefs_init: module version upstream loaded
[ 16.209245] NILFS version 2 loaded
[ 16.226230] gfs2: GFS2 installed
[ 16.326266] NET: Registered protocol family 38
[ 16.344018] Key type asymmetric registered
[ 16.353442] Asymmetric key parser 'x509' registered
[ 16.364981] Block layer SCSI generic (bsg) driver version 0.4 loaded (major
249)
[ 16.382476] io scheduler noop registered
[ 16.392812] io scheduler cfq registered (default)
[ 16.405978] test_printf: all 260 tests passed
[ 16.432644] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64
[ 16.443171] crc32: self tests passed, processed 225944 bytes in 2307458 nsec
[ 16.456977] crc32c: CRC_LE_BITS = 64
[ 16.464432] crc32c: self tests passed, processed 225944 bytes in 620214 nsec
[ 16.636881] crc32_combine: 8373 self tests passed
[ 16.770158] crc32c_combine: 8373 self tests passed
[ 16.784290] switchtec: loaded.
[ 16.791607] rivafb_setup START
[ 16.801335] input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[ 16.817701] ACPI: Power Button [PWRF]
[ 16.848025] HDLC line discipline maxframe=4096
[ 16.859952] N_HDLC line discipline registered.
[ 16.874756] r3964: Philips r3964 Driver $Revision: 1.10 $
[ 16.886652] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 16.983539] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a
16550A
[ 17.114800] 00:06: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a
16550A
[ 17.138674] MOXA Intellio family driver version 6.0k
[ 17.151640] SyncLink serial driver $Revision: 4.38 $
[ 17.232501] SyncLink serial driver $Revision: 4.38 $, tty major#244
[ 17.248116] Non-volatile memory driver v1.3
[ 17.258912] telclk_interrupt = 0xf non-mcpbl0010 hw.
[ 17.304320] Floppy drive(s): fd0 is 2.88M AMI BIOS
[ 17.309997] loop: module loaded
[ 17.344349] null: module loaded
[ 17.352804] dummy-irq: no IRQ given. Use irq=N
[ 17.365157] Silicon Labs C2 port support v. 0.51.0 - (C) 2007 Rodolfo
Giometti
[ 17.381691] FDC 0 is a S82078B
[ 17.395387] c2port c2port0: C2 port uc added
[ 17.405402] c2port c2port0: uc flash has 30 blocks x 512 bytes (15360 bytes
total)
[ 17.425464] Uniform Multi-Platform E-IDE driver
[ 17.437073] Loading iSCSI transport class v2.0-870.
[ 17.455730] aic94xx: Adaptec aic94xx SAS/SATA driver version 1.0.3 loaded
[ 17.478968] iscsi: registered transport (qla4xxx)
[ 17.492261] QLogic iSCSI HBA Driver
[ 17.502789] mpt3sas version 15.100.00.00 loaded
[ 17.516825] VMware PVSCSI driver - version 1.0.7.0-k
[ 17.568251] scsi host0: scsi_debug: version 1.86 [20160430]
[ 17.568251] dev
Re: [RESEND][PATCH] kvm: x86: Do not handle MMIO request in fast_page_fault
On Wed, Sep 13, 2017 at 04:39:56PM +0200, Radim Krčmář wrote:
> 2017-09-05 18:37+0800, changbin...@intel.com:
> > From: Changbin Du
> >
> > If it is a MMIO request, it should be handled by slow path. This patch
> > actually fixed below warning when mmu debug is enabled.
> >
> > WARNING: CPU: 5 PID: 2282 at arch/x86/kvm/mmu.c:226
> > fast_page_fault+0x41b/0x520
> > CPU: 5 PID: 2282 Comm: qemu-system-x86 Not tainted 4.13.0-rc6+ #34
> > task: 9b47f5286000 task.stack: b18d03b28000
> > RIP: 0010:fast_page_fault+0x41b/0x520
> > Call Trace:
> > tdp_page_fault+0xfb/0x290
> > kvm_mmu_page_fault+0x61/0x120
> > handle_ept_misconfig+0x1ba/0x1c0
> > vmx_handle_exit+0xb8/0xd70
> > ? kvm_arch_vcpu_ioctl_run+0x9b6/0x18e0
> > kvm_arch_vcpu_ioctl_run+0xa5a/0x18e0
> > ? kvm_arch_vcpu_load+0x62/0x230
> > kvm_vcpu_ioctl+0x340/0x6c0
> > ? kvm_vcpu_ioctl+0x340/0x6c0
> > ? lock_acquire+0xf5/0x1f0
> > do_vfs_ioctl+0xa2/0x670
> > ? __fget+0x107/0x200
> > SyS_ioctl+0x79/0x90
> > entry_SYSCALL_64_fastpath+0x23/0xc2
> >
> > Signed-off-by: Changbin Du
> > ---
> > arch/x86/kvm/mmu.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> > index 9d3f275..63c3360 100644
> > --- a/arch/x86/kvm/mmu.c
> > +++ b/arch/x86/kvm/mmu.c
> > @@ -3180,6 +3180,9 @@ static bool fast_page_fault(struct kvm_vcpu *vcpu,
> > gva_t gva, int level,
> > iterator.level < level)
> > break;
> >
> > + if (is_mmio_spte(spte))
> > + break;
>
> Hm, handle_ept_misconfig() calls kvm_mmu_page_fault with error_code =
> PFERR_RSVD_MASK. This error_code gets propagated and checked at the
> beginning of page_fault_can_be_fast(), where it should break the
> function execution.
>
> How did the execution get all the way to the loop?
>
hmm, a recent Paolo's cleanup patch already fixed it.
e08d26f ("KVM: x86: simplify ept_misconfig")
In the past, PFERR_RSVD_MASK is not set.
So this patch doesnt need any more. thanks.
> Thanks.
--
Thanks,
Changbin Du
signature.asc
Description: PGP signature
[PATCH 2/3] drm/rockchip: Add support for Rockchip Soc RGB output interface
Like rockchip rv1108 crtc can directly output parallel and serial
RGB data to panel or conversion chip, so we add this driver to
probe encoder and connector.
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/rockchip/Kconfig| 9 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
drivers/gpu/drm/rockchip/rockchip_rgb.c | 327
5 files changed, 340 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0c31f0a..ff1c781 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -8,6 +8,7 @@ config DRM_ROCKCHIP
select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP
select DRM_DW_HDMI if ROCKCHIP_DW_HDMI
select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
+ select DRM_RGB if ROCKCHIP_RGB
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
help
Choose this option if you have a Rockchip soc chipset.
@@ -65,4 +66,12 @@ config ROCKCHIP_LVDS
Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
support LVDS, rgb, dual LVDS output mode. say Y to enable its
driver.
+
+config ROCKCHIP_RGB
+ bool "Rockchip RGB support"
+ help
+ Choose this option to enable support for Rockchip RGB output.
+ Like Rockchip rv1108 SoC CRTC can directly output parallel and
+ serial RGB format to panel or connect to a conversion chip.
+ say Y to enable its driver.
endif
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index a881d2c..f32a17f 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -13,5 +13,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
+rockchipdrm-$(CONFIG_ROCKCHIP_RGB) += rockchip_rgb.o
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 082c251..36e602a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -449,6 +449,8 @@ static int __init rockchip_drm_init(void)
CONFIG_ROCKCHIP_LVDS);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
CONFIG_ROCKCHIP_ANALOGIX_DP);
+ ADD_ROCKCHIP_SUB_DRIVER(rockchip_rgb_driver,
+ CONFIG_ROCKCHIP_RGB);
ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
ADD_ROCKCHIP_SUB_DRIVER(dw_hdmi_rockchip_pltfm_driver,
CONFIG_ROCKCHIP_DW_HDMI);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 498dfbc..6b0ec7e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -70,5 +70,6 @@ extern struct platform_driver dw_mipi_dsi_driver;
extern struct platform_driver inno_hdmi_driver;
extern struct platform_driver rockchip_dp_driver;
extern struct platform_driver rockchip_lvds_driver;
+extern struct platform_driver rockchip_rgb_driver;
extern struct platform_driver vop_platform_driver;
#endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c
b/drivers/gpu/drm/rockchip/rockchip_rgb.c
new file mode 100644
index 000..0f0e6b464
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c
@@ -0,0 +1,327 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ * Sandy Huang
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define connector_to_rgb(c) container_of(c, struct rockchip_rgb, connector)
+#define encoder_to_rgb(c) container_of(c, struct rockchip_rgb, encoder)
+
+struct rockchip_rgb {
+ struct device *dev;
+ struct drm_device *drm_dev;
+ struct drm_panel *panel;
+ struct drm_bridge *bridge;
+ struct drm_connector connector;
+ struct drm_encoder encoder;
+ struct dev_pin_info *pins;
+ int output_mode;
+};
+
+static inline int name_to_
[PATCH 1/3] dt-bindings: Add document for rockchip RGB output interface
This path add support rv1108 rgb output interface driver.
Signed-off-by: Sandy Huang
---
.../bindings/display/rockchip/rockchip-rgb.txt | 80 ++
1 file changed, 80 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
new file mode 100644
index 000..4164512
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
@@ -0,0 +1,80 @@
+Rockchip RV1108 RGB interface
+
+
+Required properties:
+- compatible: matching the soc type:
+ - "rockchip,rv1108-rgb";
+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this interface.
+
+Required nodes:
+- rockchip,rgb-mode: should be "p888", "p666", "p565", "s888", "s888-dummy"
+ - p888: output r8-g8-b8 at each dclk cycle for per-pixel
+ - p666: output r6-g6-b6 at each dclk cycle for per-pixel
+ - p565: output r5-g6-b5 at each dclk cycle for per-pixel
+ - s888: output r8-g8-b8 in three dclk cycle for per-pixel
+ - s888-dmmy: output r8-g8-b8-dummy in four dclk cycle for per-pixel
+
+The rgb has two video ports described by:
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+Their connections are modeled using the OF graph bindings specified in
+ Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP input, the remote endpoint maybe vopb/vopl/vop
+- video port 1 for either a panel or subsequent encoder
+
+the panel described by:
+ Documentation/devicetree/bindings/display/panel/simple-panel.txt
+Panel other required properties:
+- ports for remote rgb output.
+
+Example:
+
+panel: panel {
+ compatible = "auo,b101ean01";
+ enable-gpios = <&gpio7 21 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ panel_in_rgb: endpoint {
+ remote-endpoint = <&rgb_out_panel>;
+ };
+ };
+};
+
+For Rockchip RV1108:
+
+ rgb: rgb {
+ compatible = "rockchip,rv1108-rgb";
+ pinctrl-names = "lcdc";
+ pinctrl-0 = <&lcdc_ctl>;
+ rockchip,rgb-mode = "p888";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rgb_in: port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rgb_in_vop: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vop_out_rgb>;
+ };
+ };
+
+ rgb_out: port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rgb_out_panel: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_in_rgb>;
+ };
+ };
+ };
+ };
--
2.7.4
[PATCH 0/3] Add support rockchip RGB output interface
This patches add support some rockchip Soc like rv1108, the VOP can directly output parallel and serial RGB data to panel or to conversion chip. So we add this driver to probe encoder and connector to support this case. Sandy Huang (3): dt-bindings: Add document for rockchip RGB output interface drm/rockchip: Add support for Rockchip Soc RGB output interface drm/rockchip: vop: Add more RGB output interface type .../bindings/display/rockchip/rockchip-rgb.txt | 80 + drivers/gpu/drm/rockchip/Kconfig | 9 + drivers/gpu/drm/rockchip/Makefile | 1 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 2 + drivers/gpu/drm/rockchip/rockchip_drm_drv.h| 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.h| 2 + drivers/gpu/drm/rockchip/rockchip_rgb.c| 327 + 7 files changed, 422 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c -- 2.7.4
[PATCH 3/3] drm/rockchip: vop: Add more RGB output interface type
This patch add serial RGB output interface for rockchip vop, the
more info about serial RGB output interface described at the
following file:
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 56bbd2e..59a01c3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -209,6 +209,8 @@ struct vop_data {
#define ROCKCHIP_OUT_MODE_P888 0
#define ROCKCHIP_OUT_MODE_P666 1
#define ROCKCHIP_OUT_MODE_P565 2
+#define ROCKCHIP_OUT_MODE_S888 8
+#define ROCKCHIP_OUT_MODE_S888_DUMMY 12
/* for use special outface */
#define ROCKCHIP_OUT_MODE_ 15
--
2.7.4
linux-next: Tree for Sep 14
Hi all, Please do not add any v4.15 related material to your linux-next included branches until after v4.14-rc1 has been released. Changes since 20170913: The vfs tree gained a conflict against the btrfs-kdave tree. Non-merge commits (relative to Linus' tree): 746 1078 files changed, 39588 insertions(+), 9357 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 and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) 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. Below is a summary of the state of the merge. I am currently merging 267 trees (counting Linus' and 41 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 (46c1e79fee41 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig entry) Merging kbuild-current/fixes (64236e315955 kbuild: update comments of Makefile.asm-generic) Merging arc-current/for-curr (1ee55a8f7f6b ARC: Re-enable MMU upon Machine Check exception) Merging arm-current/fixes (746a272e4414 ARM: 8692/1: mm: abort uaccess retries upon fatal signal) Merging m68k-current/for-linus (558d5ad276c9 m68k/mac: Avoid soft-lockup warning after mach_power_off) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (1a92a80ad386 powerpc/mm: Ensure cpumask update is ordered) Merging sparc/master (6470812e2226 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (6fa9c623a03c MAINTAINERS: review Renesas DT bindings as well) Merging ipsec/master (23e9fcfef1f3 vti: fix NULL dereference in xfrm_input()) Merging netfilter/master (90c4ae4e2c1d netfilter: xt_hashlimit: fix build error caused by 64bit division) Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook mask only if set) Merging wireless-drivers/master (f957dd3c8db2 brcmfmac: feature check for multi-scheduled scan fails on bcm4345 devices) Merging mac80211/master (126f760ca94d rds: Fix incorrect statistics counting) Merging sound-current/for-linus (fc27fe7e8dee ALSA: seq: Cancel pending autoload work at unbinding device) Merging pci-current/for-linus (8e1101d25164 PCI/MSI: Don't warn when irq_create_affinity_masks() returns NULL) Merging driver-core.current/driver-core-linus (d34fc1adf01f Merge branch 'akpm' (patches from Andrew)) Merging tty.current/tty-linus (d34fc1adf01f Merge branch 'akpm' (patches from Andrew)) Merging usb.current/usb-linus (d34fc1adf01f Merge branch 'akpm' (patches from Andrew)) Merging usb-gadget-fixes/fixes (b7d44c36a6f6 usb: renesas_usbhs: gadget: fix unused-but-set-variable warning) Merging usb-serial-fixes/usb-linus (fd1b8668af59 USB: serial: option: add D-Link DWM-222 device ID) Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: check before accessing ci_role in ci_role_show) Merging phy/fixes (5771a8c08880 Linux v4.13-rc1) Merging staging.current/staging-linus (f007cad159e9 Revert "firmware: add sanity check on shutdown/suspend") Merging char-misc.current/char-misc-linus (d34fc1adf01f Merge branch 'akpm' (patches from Andrew)) Merging input-current/for-linus (a6cbfa1e6d38 Merge branch 'next' into for-linus) Merging
[PATCH v2] ASoC: fsl_ssi: Caculate bit clock rate using slot number and width
The set_sysclk() now is used to override the output bit clock rate.
But this is not a common way to implement a set_dai_sysclk(). And
this creates a problem when a general machine driver (simple-card
for example) tries to do set_dai_sysclk() by passing an input clock
rate for the baud clock instead of setting the bit clock rate as
fsl_ssi driver expected.
So this patch solves this problem by firstly removing set_sysclk()
since the hw_params() can calculate the bit clock rate. Secondly,
in order not to break those TDM use cases which previously might
have been using set_sysclk() to override the bit clock rate, this
patch changes the driver to calculate the bit clock rate using the
slot number and the slot width from the via set_tdm_slot().
The patch also removes an obsolete comment of the dir parameter.
Signed-off-by: Nicolin Chen
---
sound/soc/fsl/fsl_ssi.c | 46 ++
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 64598d1..f2f51e06 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -197,12 +197,13 @@ struct fsl_ssi_soc_data {
* @use_dma: DMA is used or FIQ with stream filter
* @use_dual_fifo: DMA with support for both FIFOs used
* @fifo_deph: Depth of the SSI FIFOs
+ * @slot_width: width of each DAI slot
+ * @slots: number of slots
* @rxtx_reg_val: Specific register settings for receive/transmit configuration
*
* @clk: SSI clock
* @baudclk: SSI baud clock for master mode
* @baudclk_streams: Active streams that are using baudclk
- * @bitclk_freq: bitclock frequency set by .set_dai_sysclk
*
* @dma_params_tx: DMA transmit parameters
* @dma_params_rx: DMA receive parameters
@@ -233,12 +234,13 @@ struct fsl_ssi_private {
bool use_dual_fifo;
bool has_ipg_clk_name;
unsigned int fifo_depth;
+ unsigned int slot_width;
+ unsigned int slots;
struct fsl_ssi_rxtx_reg_val rxtx_reg_val;
struct clk *clk;
struct clk *baudclk;
unsigned int baudclk_streams;
- unsigned int bitclk_freq;
/* regcache for volatile regs */
u32 regcache_sfcsr;
@@ -700,8 +702,8 @@ static void fsl_ssi_shutdown(struct snd_pcm_substream
*substream,
* Note: This function can be only called when using SSI as DAI master
*
* Quick instruction for parameters:
- * freq: Output BCLK frequency = samplerate * 32 (fixed) * channels
- * dir: SND_SOC_CLOCK_OUT -> TxBCLK, SND_SOC_CLOCK_IN -> RxBCLK.
+ * freq: Output BCLK frequency = samplerate * slots * slot_width
+ * (In 2-channel I2S Master mode, slot_width is fixed 32)
*/
static int fsl_ssi_set_bclk(struct snd_pcm_substream *substream,
struct snd_soc_dai *cpu_dai,
@@ -712,15 +714,21 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream
*substream,
int synchronous = ssi_private->cpu_dai_drv.symmetric_rates, ret;
u32 pm = 999, div2, psr, stccr, mask, afreq, factor, i;
unsigned long clkrate, baudrate, tmprate;
+ unsigned int slots = params_channels(hw_params);
+ unsigned int slot_width = 32;
u64 sub, savesub = 10;
unsigned int freq;
bool baudclk_is_used;
- /* Prefer the explicitly set bitclock frequency */
- if (ssi_private->bitclk_freq)
- freq = ssi_private->bitclk_freq;
- else
- freq = params_channels(hw_params) * 32 * params_rate(hw_params);
+ /* Override slots and slot_width if being specifically set... */
+ if (ssi_private->slots)
+ slots = ssi_private->slots;
+ /* ...but keep 32 bits if slots is 2 -- I2S Master mode */
+ if (ssi_private->slot_width && slots != 2)
+ slot_width = ssi_private->slot_width;
+
+ /* Generate bit clock based on the slot number and slot width */
+ freq = slots * slot_width * params_rate(hw_params);
/* Don't apply it to any non-baudclk circumstance */
if (IS_ERR(ssi_private->baudclk))
@@ -805,16 +813,6 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream
*substream,
return 0;
}
-static int fsl_ssi_set_dai_sysclk(struct snd_soc_dai *cpu_dai,
- int clk_id, unsigned int freq, int dir)
-{
- struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
-
- ssi_private->bitclk_freq = freq;
-
- return 0;
-}
-
/**
* fsl_ssi_hw_params - program the sample size
*
@@ -1095,6 +1093,12 @@ static int fsl_ssi_set_dai_tdm_slot(struct snd_soc_dai
*cpu_dai, u32 tx_mask,
struct regmap *regs = ssi_private->regs;
u32 val;
+ /* The word length should be 8, 10, 12, 16, 18, 20, 22 or 24 */
+ if (slot_width & 1 || slot_width < 8 || slot_width > 24) {
+ dev_err(cpu_dai->dev, "invalid slot width: %d\n", slot_width);
+ return -EINVAL;
+ }
+
/* The slot number should be >= 2 if using Network mode or I2S mod
[PATCH] checkpatch: support function pointers for unnamed function definition arguments
Current unnamed function definition argument does not include function
pointer cases and it reports warnings like:
WARNING: function definition argument 'void' should also have an identifier name
+unsigned int (*dummy)(void);
Support function pointers for unnamed function arguments.
Signed-off-by: Miles Chen
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index dd2c262..dc6da15 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5957,7 +5957,7 @@ sub process {
# check for function declarations that have arguments without identifier names
if (defined $stat &&
- $stat =~
/^.\s*(?:extern\s+)?$Type\s*$Ident\s*\(\s*([^{]+)\s*\)\s*;/s &&
+ $stat =~
/^.\s*(?:extern\s+)?$Type\s*\(?\s*\*?\s*$Ident\s*\)\s*\(\s*([^{]+)\s*\)\s*;/s &&
$1 ne "void") {
my $args = trim($1);
while ($args =~
m/\s*($Type\s*(?:$Ident|\(\s*\*\s*$Ident?\s*\)\s*$balanced_parens)?)/g) {
--
1.9.1
[PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
If fanout_add is preempted after running po-> fanout = match and before running __fanout_link, it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink so, we need add mutex_lock(&fanout_mutex) to __unregister_prot_hook or add spin_lock(&po->bind_lock) before po-> fanout = match test on linux 4.1.12: ./trinity -c setsockopt -C 2 -X & BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()! Kernel panic - not syncing: BUG! CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: GW O4.1.12 #1 Hardware name: Hisilicon PhosphorHi1382 FPGA (DT) Call trace: [] dump_backtrace+0x0/0xf8 [] show_stack+0x20/0x28 [] dump_stack+0xac/0xe4 [] panic+0xf8/0x268 [] __unregister_prot_hook+0xa0/0x144 [] packet_set_ring+0x280/0x5b4 [] packet_setsockopt+0x320/0x950 [] SyS_setsockopt+0xa4/0xd4 Signed-off-by: nixiaoming Tested-by: wudesheng --- net/packet/af_packet.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index 008a45c..0300146 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -365,10 +365,12 @@ static void __unregister_prot_hook(struct sock *sk, bool sync) po->running = 0; + mutex_lock(&fanout_mutex); if (po->fanout) __fanout_unlink(sk, po); else __dev_remove_pack(&po->prot_hook); + mutex_unlock(&fanout_mutex); __sock_put(sk); -- 2.11.0.1
[PATCH] gpio: thunderx: remove unused .map() hook from irq_domain_ops
This driver implements .alloc() hook, so .map() is not used.
Signed-off-by: Masahiro Yamada
---
drivers/gpio/gpio-thunderx.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
index 57efb25..b5adb79 100644
--- a/drivers/gpio/gpio-thunderx.c
+++ b/drivers/gpio/gpio-thunderx.c
@@ -417,18 +417,6 @@ static struct irq_chip thunderx_gpio_irq_chip = {
.flags = IRQCHIP_SET_TYPE_MASKED
};
-static int thunderx_gpio_irq_map(struct irq_domain *d, unsigned int irq,
-irq_hw_number_t hwirq)
-{
- struct thunderx_gpio *txgpio = d->host_data;
-
- if (hwirq >= txgpio->chip.ngpio)
- return -EINVAL;
- if (!thunderx_gpio_is_gpio_nowarn(txgpio, hwirq))
- return -EPERM;
- return 0;
-}
-
static int thunderx_gpio_irq_translate(struct irq_domain *d,
struct irq_fwspec *fwspec,
irq_hw_number_t *hwirq,
@@ -455,7 +443,6 @@ static int thunderx_gpio_irq_alloc(struct irq_domain *d,
unsigned int virq,
}
static const struct irq_domain_ops thunderx_gpio_irqd_ops = {
- .map= thunderx_gpio_irq_map,
.alloc = thunderx_gpio_irq_alloc,
.translate = thunderx_gpio_irq_translate
};
--
2.7.4
[PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
If fanout_add is preempted after running po-> fanout = match and before running __fanout_link, it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink so, we need add mutex_lock(&fanout_mutex) to __unregister_prot_hook or add spin_lock(&po->bind_lock) before po-> fanout = match test on linux 4.1.42: ./trinity -c setsockopt -C 2 -X & BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()! Kernel panic - not syncing: BUG! CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: GW O4.1.12 #1 Hardware name: Hisilicon PhosphorHi1382 FPGA (DT) Call trace: [] dump_backtrace+0x0/0xf8 [] show_stack+0x20/0x28 [] dump_stack+0xac/0xe4 [] panic+0xf8/0x268 [] __unregister_prot_hook+0xa0/0x144 [] packet_set_ring+0x280/0x5b4 [] packet_setsockopt+0x320/0x950 [] SyS_setsockopt+0xa4/0xd4 Signed-off-by: nixiaoming Tested-by: wudesheng --- net/packet/af_packet.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index 008a45c..0300146 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -365,10 +365,12 @@ static void __unregister_prot_hook(struct sock *sk, bool sync) po->running = 0; + mutex_lock(&fanout_mutex); if (po->fanout) __fanout_unlink(sk, po); else __dev_remove_pack(&po->prot_hook); + mutex_unlock(&fanout_mutex); __sock_put(sk); -- 2.11.0.1
[PATCH 1/1] Coccinelle: array_size: report even if include is missing
Rule r does not depend on rule i (which is the include of linux/kernel.h) so the output should not depend on i in org and report mode. Signed-off-by: Jérémy Lefaure --- I have tested this patch in report mode on the file drivers/staging/rtlwifi/phydm/rtl8822b/halhwimg8822b_rf.c which does not use ARRAY_SIZE and does not include linux/kernel.h. scripts/coccinelle/misc/array_size.cocci | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/coccinelle/misc/array_size.cocci b/scripts/coccinelle/misc/array_size.cocci index 6ec05710b017..09520f0941f0 100644 --- a/scripts/coccinelle/misc/array_size.cocci +++ b/scripts/coccinelle/misc/array_size.cocci @@ -72,13 +72,13 @@ position p; (sizeof(E)@p /sizeof(T)) ) -@script:python depends on i&&org@ +@script:python depends on org@ p << r.p; @@ coccilib.org.print_todo(p[0], "WARNING should use ARRAY_SIZE") -@script:python depends on i&&report@ +@script:python depends on report@ p << r.p; @@ -- 2.14.1
[PATCH] signal: remove unused variable
Reported-by: Stephen Rothwell
Fixes: 9b24ec57688a ("get_compat_sigset()")
Signed-off-by: Dmitry V. Levin
---
kernel/signal.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index 3198a7d2e5ff..36a523640894 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -3440,7 +3440,6 @@ COMPAT_SYSCALL_DEFINE4(rt_sigaction, int, sig,
if (act) {
compat_uptr_t handler;
- compat_sigset_t mask;
ret = get_user(handler, &act->sa_handler);
new_ka.sa.sa_handler = compat_ptr(handler);
#ifdef __ARCH_HAS_SA_RESTORER
--
ldv
Re: [PATCH 2/2 v2] sched/wait: Introduce lock breaker in wake_up_page_bit
On Wed, Sep 13, 2017 at 7:12 PM, Tim Chen wrote: > > BTW, will you be merging these 2 patches in 4.14? Yes, and thanks for reminding me. In fact, would you mind sending me the latest versions, rather than me digging them out of the disaster area that is my mailbox and possibly picking an older version? Linus
RE: [Intel-wired-lan] [PATCH] igb: check memory allocation failure
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf > Of Christophe JAILLET > Sent: Monday, August 28, 2017 10:13 AM > To: Waskiewicz Jr, Peter ; Kirsher, Jeffrey T > > Cc: net...@vger.kernel.org; kernel-janit...@vger.kernel.org; intel-wired- > l...@lists.osuosl.org; linux-kernel@vger.kernel.org > Subject: Re: [Intel-wired-lan] [PATCH] igb: check memory allocation failure > > Le 28/08/2017 à 01:09, Waskiewicz Jr, Peter a écrit : > > On 8/27/17 2:42 AM, Christophe JAILLET wrote: > >> Check memory allocation failures and return -ENOMEM in such cases, as > >> already done for other memory allocations in this function. > >> > >> This avoids NULL pointers dereference. > >> > >> Signed-off-by: Christophe JAILLET > >> --- > >>drivers/net/ethernet/intel/igb/igb_main.c | 2 ++ > >>1 file changed, 2 insertions(+) > >> This seems to be fine from a "it does not break in testing" perspective, so... Tested-by: Aaron Brown > -PJ > > > Hi, > > in fact, there is no leak because the only caller of 'igb_sw_init()' > (i.e. 'igb_probe()'), already frees these resources in case of error, > see [1] > > These resources are also freed in 'igb_remove()'. > > Best reagrds, > CJ > > [1]: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux- > next.git/tree/drivers/net/ethernet/intel/igb/igb_main.c#n2775 But is PJ's comment saying that it is not really necessary? If so I tend to lean towards the don't touch it if it's not broken perspective.
Re: [PATCH 4.9 00/14] 4.9.50-stable review
On Wed, Sep 13, 2017 at 02:30:46PM -0700, Greg Kroah-Hartman wrote: > > Yes. I don't recall if it is a direct --force or if you would have to > > remove the original tag first (with git push :refs/tags/). > > Ah, but then if someone had pulled the old tag, they would have to > delete it locally before they can pull in the new one. That's the main > reason I'll not do this... In fact not, the tags are automatically replaced upon pull. I've been using such a crappy workflow for some time in the past, sharing human errors with coworkers... Git is pretty tolerant to this. It's just that it's terribly confusing because you can then have two people with the same tag name pointing to different commit IDs, I really hate this, it only works when all users are in the same office and you shout "sorry I messed up, I'm pushing the tag again". > Again, use the make command that we have just for this reason... It also has the benefit of always reporting the same version for all users including those only downloading the -rc patch. Willy
[PATCH] f2fs: show flush list status in sysfs
This patch adds to show flush list status in sysfs.
Signed-off-by: Chao Yu
---
fs/f2fs/debug.c | 5 -
fs/f2fs/f2fs.h | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
index 87f449845f5f..00c1d4a9f356 100644
--- a/fs/f2fs/debug.c
+++ b/fs/f2fs/debug.c
@@ -61,6 +61,8 @@ static void update_general_status(struct f2fs_sb_info *sbi)
atomic_read(&SM_I(sbi)->fcc_info->issued_flush);
si->nr_flushing =
atomic_read(&SM_I(sbi)->fcc_info->issing_flush);
+ si->flush_list_empty =
+ llist_empty(&SM_I(sbi)->fcc_info->issue_list);
}
if (SM_I(sbi) && SM_I(sbi)->dcc_info) {
si->nr_discarded =
@@ -349,10 +351,11 @@ static int stat_show(struct seq_file *s, void *v)
seq_printf(s, " - Inner Struct Count: tree: %d(%d), node:
%d\n",
si->ext_tree, si->zombie_tree, si->ext_node);
seq_puts(s, "\nBalancing F2FS Async:\n");
- seq_printf(s, " - IO (CP: %4d, Data: %4d, Flush: (%4d %4d), "
+ seq_printf(s, " - IO (CP: %4d, Data: %4d, Flush: (%4d %4d
%4d), "
"Discard: (%4d %4d)) cmd: %4d undiscard:%4u\n",
si->nr_wb_cp_data, si->nr_wb_data,
si->nr_flushing, si->nr_flushed,
+ si->flush_list_empty,
si->nr_discarding, si->nr_discarded,
si->nr_discard_cmd, si->undiscard_blks);
seq_printf(s, " - inmem: %4d, atomic IO: %4d (Max. %4d), "
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 5d33d5a84b07..c5d3d15b57c9 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2704,7 +2704,8 @@ struct f2fs_stat_info {
int free_nids, avail_nids, alloc_nids;
int total_count, utilization;
int bg_gc, nr_wb_cp_data, nr_wb_data;
- int nr_flushing, nr_flushed, nr_discarding, nr_discarded;
+ int nr_flushing, nr_flushed, flush_list_empty;
+ int nr_discarding, nr_discarded;
int nr_discard_cmd;
unsigned int undiscard_blks;
int inline_xattr, inline_inode, inline_dir, append, update, orphans;
--
2.13.1.388.g69e6b9b4f4a9
Re: [PATCH 2/2 v2] sched/wait: Introduce lock breaker in wake_up_page_bit
On 08/29/2017 09:24 AM, Linus Torvalds wrote: > On Tue, Aug 29, 2017 at 9:13 AM, Tim Chen wrote: >> >> It is affecting not a production use, but the customer's acceptance >> test for their systems. So I suspect it is a stress test. > > Can you gently poke them and ask if they might make theie stress test > code available? > > Tell them that we have a fix, but right now it's delayed into 4.14 > because we have no visibility into what it is that it actually fixes, > and whether it's all that critical or just some microbenchmark. > > Linus, Here's what the customer think happened and is willing to tell us. They have a parent process that spawns off 10 children per core and kicked them to run. The child processes all access a common library. We have 384 cores so 3840 child processes running. When migration occur on a page in the common library, the first child that access the page will page fault and lock the page, with the other children also page faulting quickly and pile up in the page wait list, till the first child is done. Probably some kind of access pattern of the common library induces the page migration to happen. BTW, will you be merging these 2 patches in 4.14? Thanks. Tim
Re: [PATCH v2 1/2] dt-bindings: spi: Add Spreadtrum ADI controller documentation
Hi Rob, On 14 September 2017 at 03:51, Rob Herring wrote: > On Fri, Sep 08, 2017 at 04:33:41PM +0800, Baolin Wang wrote: >> This patch adds the binding documentation for Spreadtrum ADI >> controller device. >> >> Signed-off-by: Baolin Wang >> --- >> Changes since v1: >> - Add more documentation the 'sprd,hw-channels' property and why need >> one hardware spinlock. >> --- >> .../devicetree/bindings/spi/spi-sprd-adi.txt | 58 >> >> 1 file changed, 58 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/spi/spi-sprd-adi.txt >> >> diff --git a/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt >> b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt >> new file mode 100644 >> index 000..0f76336 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/spi/spi-sprd-adi.txt >> @@ -0,0 +1,58 @@ >> +Spreadtrum ADI controller based on SPI framework > > "SPI framework" is not relevant to bindings. OK, I will remove this in next version. > >> + >> +ADI is the abbreviation of Anolog-Digital interface, which is used to access >> +analog chip (such as PMIC) from digital chip. ADI controller follows the SPI >> +framework for its hardware implementation is alike to SPI bus and its timing >> +is compatile to SPI timing. >> + >> +ADI controller has 50 channels including 2 software read/write channels and >> +48 hardware channels to access analog chip. For 2 software read/write >> channels, >> +users should set ADI registers to access analog chip. For hardware channels, >> +we can configure them to allow other hardware components to use it >> independently, >> +which means we can just link one analog chip address to one hardware >> channel, >> +then users can access the mapped analog chip address by this hardware >> channel >> +triggered by hardware components instead of ADI software channels. >> + >> +Thus we introduce one property named "sprd,hw-channels" to configure >> hardware >> +channels, the first value specifies the hardware channel id which is used to >> +transfer data triggered by hardware automatically, and the second value >> specifies >> +the analog chip address where user want to access by hardware components. >> + >> +Another hand since we have multi-subsystems will use unique ADI to access >> analog > > Drop "Another hand" OK. > >> +chip, when one system is reading/writing data by ADI software channels, that >> +should be under one hardware spinlock protection to prevent other systems >> from >> +reading/writing data by ADI software channels at the same time, or two >> parallel >> +routine of setting ADI registers will make ADI controller registers chaos to >> +lead incorrect results. Then we need one hardware spinlock to synchronize >> between >> +the multiple subsystems. >> + >> +Required properties: >> +- compatible: Should be "sprd,sc9860-adi". >> +- reg: Offset and length of ADI-SPI controller register space. >> +- hwlocks: Reference to a phandle of a hwlock provider node. >> +- hwlock-names: Reference to hwlock name strings defined in the same order >> + as the hwlocks, should be "adi". >> +- #address-cells: Number of cells required to define a chip select address >> + on the ADI-SPI bus. Should be set to 1. >> +- #size-cells: Size of cells required to define a chip select address size >> + on the ADI-SPI bus. Should be set to 0. >> + >> +Optional properties: >> +- sprd,hw-channels: The first value specifies the hardware channel id which >> + is used to transfer data triggered by hardware automatically, and >> + the second value specifies the analog chip address where user want >> + to access by hardware components. > > Need to say this is an array of values up to ? channels. OK. Will add in next version. > > I wonder if this should be a slave property. Is there a relationship It is not a slave property, it is used to configure ADI controller to support to access analog chip by hardware automatically. > between the SPI address (i.e. chip select) and the "analog chip I think they are not related. The "analog chip address" is like the offset address of one SPI slave (analog chip can be recognized as one SPI slave). > address"? It sounds like the h/w channels are a protocol specific to a > particular PMIC/MFD that this controller supports. Yes. Very appreciated for your comments. -- Baolin.wang Best Regards
Re: [PATCH 01/12] mmc: dt-bindings: update Mediatek MMC bindings
On Wed, 2017-09-13 at 09:10 -0500, Rob Herring wrote:
> On Tue, Sep 12, 2017 at 05:07:41PM +0800, Chaotian Jing wrote:
> > Change the comptiable for support of multi-platform
> > Add description for reg
> > Add description for source_cg
> > Add description for mediatek,latch-ck
>
> This is at least the 3rd patch with exactly the same vague subject.
> Please make the subject somewhat unique.
>
Thx, will change the subject at next version
> >
> > Signed-off-by: Chaotian Jing
> > ---
> > Documentation/devicetree/bindings/mmc/mtk-sd.txt | 13 ++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > index 4182ea3..405cd06 100644
> > --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > @@ -7,10 +7,15 @@ This file documents differences between the core
> > properties in mmc.txt
> > and the properties used by the msdc driver.
> >
> > Required properties:
> > -- compatible: Should be "mediatek,mt8173-mmc","mediatek,mt8135-mmc"
> > +- compatible: value should be either of the following.
> > + "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135
> > + "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
> > + "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
> > + "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
> > +- reg: physical base address of the controller and length
> > - interrupts: Should contain MSDC interrupt number
> > -- clocks: MSDC source clock, HCLK
> > -- clock-names: "source", "hclk"
> > +- clocks: MSDC source clock, HCLK, source_cg
> > +- clock-names: "source", "hclk", "source_cg"
>
> All chips support source_cg? That's not backwards compatible for
> existing compatible strings if the driver requires it.
Not all chips support source_cg, for chips which do not support
source_cg, no need source_cg here, and the driver will parse it
to know if current chip support it.
>
> > - pinctrl-names: should be "default", "state_uhs"
> > - pinctrl-0: should contain default/high speed pin ctrl
> > - pinctrl-1: should contain uhs mode pin ctrl
> > @@ -30,6 +35,8 @@ Optional properties:
> > - mediatek,hs400-cmd-resp-sel-rising: HS400 command response sample
> > selection
> >If present,HS400 command responses are
> > sampled on rising edges.
> >If not present,HS400 command responses
> > are sampled on falling edges.
> > +- mediatek,latch-ck: Some projects do not support enhance_rx, need set
> > correct latch-ck to avoid data crc
>
> What's a project?
eg, MT2701
>
> > +error caused by stop clock(fifo full)
> >
> > Examples:
> > mmc0: mmc@1123 {
> > --
> > 1.8.1.1.dirty
> >
Re: [PATCH v2 2/2] spi: Add ADI driver for Spreadtrum platform
Hi Rob,
On 14 September 2017 at 03:45, Rob Herring wrote:
> On Fri, Sep 08, 2017 at 04:33:42PM +0800, Baolin Wang wrote:
>> This patch adds ADI driver based on SPI framework for
>> Spreadtrum SC9860 platform.
>>
>> Signed-off-by: Baolin Wang
>> ---
>
> [...]
>
>> +++ b/drivers/spi/spi-sprd-adi.c
>> @@ -0,0 +1,419 @@
>> +/*
>> + * Copyright (C) 2017 Spreadtrum Communications Inc.
>> + *
>> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>
> Kernel code should generally not be MIT license.
OK. Will fix in next version.
>
> [...]
>
>> +static int sprd_adi_drain_fifo(struct sprd_adi *sadi)
>> +{
>> + u32 timeout = ADI_FIFO_DRAIN_TIMEOUT;
>> + u32 sts;
>> +
>> + do {
>> + sts = readl_relaxed(sadi->base + REG_ADI_ARM_FIFO_STS);
>> + if (sts & BIT_FIFO_EMPTY)
>> + break;
>> +
>> + cpu_relax();
>> + } while (--timeout);
>
> You can use readl_poll_timeout.
The readl_poll_timeout() function might be sleep, but we can not sleep
when reading/writing data through ADI controller, since the routine is
under hardware spinlock protection. Moreover it is usually very quick
to jump the loop and we no need to sleep here.
>
>> +
>> + if (timeout == 0) {
>> + dev_err(sadi->dev, "drain write fifo timeout\n");
>> + return -EBUSY;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int sprd_adi_fifo_is_full(struct sprd_adi *sadi)
>> +{
>> + return readl_relaxed(sadi->base + REG_ADI_ARM_FIFO_STS) &
>> BIT_FIFO_FULL;
>> +}
>> +
>> +static int sprd_adi_read(struct sprd_adi *sadi, u32 reg_paddr, u32
>> *read_val)
>> +{
>> + int read_timeout = ADI_READ_TIMEOUT;
>> + u32 val, rd_addr;
>> +
>> + /*
>> + * Set the physical register address need to read into RD_CMD register,
>> + * then ADI controller will start to transfer automatically.
>> + */
>> + writel_relaxed(reg_paddr, sadi->base + REG_ADI_RD_CMD);
>> +
>> + /*
>> + * Wait read operation complete, the BIT_RD_CMD_BUSY will be set
>> + * simultaneously when writing read command to register, and the
>> + * BIT_RD_CMD_BUSY will be cleared after the read operation is
>> + * completed.
>> + */
>> + do {
>> + val = readl_relaxed(sadi->base + REG_ADI_RD_DATA);
>> + if (!(val & BIT_RD_CMD_BUSY))
>> + break;
>> +
>> + cpu_relax();
>> + } while (--read_timeout);
>
> readl_poll_timeout
The same reason as above. Thanks for your comments.
--
Baolin.wang
Best Regards
Re: linux-next: build warning after merge of the vfs tree
Hi Al,
On Fri, 8 Sep 2017 09:25:45 +1000 Stephen Rothwell
wrote:
>
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> kernel/signal.c: In function 'C_SYSC_rt_sigaction':
> kernel/signal.c:3405:19: warning: unused variable 'mask' [-Wunused-variable]
>compat_sigset_t mask;
>^
>
> Introduced by commit
>
> fc271087ebcb ("signal: replace sigset_to_compat() with put_compat_sigset()")
I am still getting this warning ...
--
Cheers,
Stephen Rothwell
Re: [PATCH v2 RESEND 0/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system
Hi all, PING! Do anyone has any suggestion about this issue? This bug blocks SGI system's boot, KASLR has to be disabled on SGI system if they want to run tests. Thanks Baoquan On 09/07/17 at 03:42pm, Baoquan He wrote: > This is v2 post RESEND. Add Mike's Acked-by to patch 2/2 as he suggested > in private mail. And update patches log slightly. > > This patchset is trying to fix a bug that SGI UV system casually hang > during boot with KASLR enabled. The root cause is that mm KASLR adapts > size of the direct mapping section only based on the system RAM size. > Then later when map SGI UV MMIOH region into the direct mapping during > rest_init() invocation, it might go beyond of the directing mapping > section and step into VMALLOC or VMEMMAP area, then BUG_ON triggered. > > The fix is adding a helper function is_early_uv_system to check UV system > earlier, then call the helper function in kernel_randomize_memory() to > check if it's a SGI UV system, if yes, we keep the size of direct mapping > section to be 64TB just as nokslr. > > With this fix, SGI UV system can have 64TB direct mapping size always, > and the starting address of direct mapping/vmalloc/vmemmap and the padding > between them can still be randomized to enhance the system security. > > v1->v2: > 1. Mike suggested making is_early_uv_system() an inline function and be > put in include/asm/uv/uv.h so that they can adjust them easier in the > future. > > 2. Split the v1 code into uv part and mm KASLR part as Mike suggested. > > Baoquan He (2): > x86/UV: Introduce a helper function to check UV system at earlier > stage > x86/mm/KASLR: Do not adapt the size of the direct mapping section for > SGI UV system > > arch/x86/include/asm/uv/uv.h | 6 ++ > arch/x86/mm/kaslr.c | 3 ++- > 2 files changed, 8 insertions(+), 1 deletion(-) > > -- > 2.5.5 >
Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion
On Wed, Sep 13, 2017 at 06:10:48PM -0700, Jaegeuk Kim wrote:
> Android triggers umount(2) by init process, which is definitely not a kernel
> thread. But, we've seen some kernel panics which say umount(2) was succeeded,
> but ext4 triggered a kernel panic due to EIO after then like below. I'm also
> not sure task_work_run() would be also safe enoughly. May I ask where I can
> find sys_umount() calls task_work_run()?
ret_{fast,slow}_syscall ->
slow_work_pending ->
do_work_pending() ->
tracehook_notify_resume() ->
task_work_run()
It's not sys_umount() (or any other sys_...()) - it's syscall dispatcher after
having called one of those and before returning to userland. What is guaranteed
is that after successful task_work_add() the damn thing will be run in context
of originating process before it returns from syscall. So any subsequent
syscalls from that process are guaranteed to happen after the work has run.
The same happens if the process exits rather than returns to userland
(do_exit() ->
exit_task_work() -> task_work_run()), but for that you would need it to die in
umount(2) (e.g. get kill -9 delivered on the way out).
Please, check if you are seeing task_work_add() failure in there and if you do,
I would like to see a stack trace. IOW, slap WARN_ON(1); right after
if (!task_work_add(task, &mnt->mnt_rcu, true))
return;
and see what (if anything) gets printed.
[PATCH v9 2/4] ARM: dts: rockchip: add RGA device node for RK3288
This patch add the RGA dt config of rk3288 SoC.
Signed-off-by: Jacob Chen
Signed-off-by: Yakir Yang
---
arch/arm/boot/dts/rk3288.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 595d395..ca6c63a 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -953,6 +953,17 @@
status = "okay";
};
+ rga: rga@ff92 {
+ compatible = "rockchip,rk3288-rga";
+ reg = <0xff92 0x180>;
+ interrupts = ;
+ clocks = <&cru ACLK_RGA>, <&cru HCLK_RGA>, <&cru SCLK_RGA>;
+ clock-names = "aclk", "hclk", "sclk";
+ power-domains = <&power RK3288_PD_VIO>;
+ resets = <&cru SRST_RGA_CORE>, <&cru SRST_RGA_AXI>, <&cru
SRST_RGA_AHB>;
+ reset-names = "core", "axi", "ahb";
+ };
+
vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
reg = <0xff93 0x19c>;
--
2.7.4
[PATCH v9 1/4] rockchip/rga: v4l2 m2m support
Rockchip RGA is a separate 2D raster graphic acceleration unit. It
accelerates 2D graphics operations, such as point/line drawing, image
scaling, rotation, BitBLT, alpha blending and image blur/sharpness
The drvier is mostly based on s5p-g2d v4l2 m2m driver
And supports various operations from the rendering pipeline.
- copy
- fast solid color fill
- rotation
- flip
- alpha blending
The code in rga-hw.c is used to configure regs according to operations
The code in rga-buf.c is used to create private mmu table for RGA.
changes in V7:
- fix some warning reported by "checkpatch --strict"
Signed-off-by: Jacob Chen
---
drivers/media/platform/Kconfig| 11 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/rockchip-rga/Makefile |3 +
drivers/media/platform/rockchip-rga/rga-buf.c | 156
drivers/media/platform/rockchip-rga/rga-hw.c | 435 +++
drivers/media/platform/rockchip-rga/rga-hw.h | 437 +++
drivers/media/platform/rockchip-rga/rga.c | 1030 +
drivers/media/platform/rockchip-rga/rga.h | 110 +++
8 files changed, 2184 insertions(+)
create mode 100644 drivers/media/platform/rockchip-rga/Makefile
create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
create mode 100644 drivers/media/platform/rockchip-rga/rga.c
create mode 100644 drivers/media/platform/rockchip-rga/rga.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7e7cc49..9b79350 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -458,6 +458,17 @@ config VIDEO_RENESAS_VSP1
To compile this driver as a module, choose M here: the module
will be called vsp1.
+config VIDEO_ROCKCHIP_RGA
+ tristate "Rockchip Raster 2d Grapphic Acceleration Unit"
+ depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+ depends on ARCH_ROCKCHIP || COMPILE_TEST
+ select VIDEOBUF2_DMA_SG
+ select V4L2_MEM2MEM_DEV
+ default n
+ ---help---
+ This is a v4l2 driver for Rockchip SOC RGA2
+ 2d graphics accelerator.
+
config VIDEO_TI_VPE
tristate "TI VPE (Video Processing Engine) driver"
depends on VIDEO_DEV && VIDEO_V4L2
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c1ef946..06039c3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -62,6 +62,8 @@ obj-$(CONFIG_VIDEO_RENESAS_FDP1) += rcar_fdp1.o
obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/
+obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga/
+
obj-y += omap/
obj-$(CONFIG_VIDEO_AM437X_VPFE)+= am437x/
diff --git a/drivers/media/platform/rockchip-rga/Makefile
b/drivers/media/platform/rockchip-rga/Makefile
new file mode 100644
index 000..92fe254
--- /dev/null
+++ b/drivers/media/platform/rockchip-rga/Makefile
@@ -0,0 +1,3 @@
+rockchip-rga-objs := rga.o rga-hw.o rga-buf.o
+
+obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga.o
diff --git a/drivers/media/platform/rockchip-rga/rga-buf.c
b/drivers/media/platform/rockchip-rga/rga-buf.c
new file mode 100644
index 000..373c36f
--- /dev/null
+++ b/drivers/media/platform/rockchip-rga/rga-buf.c
@@ -0,0 +1,156 @@
+/*
+ * Copyright (C) 2017 Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Jacob Chen
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "rga-hw.h"
+#include "rga.h"
+
+static int
+rga_queue_setup(struct vb2_queue *vq,
+ unsigned int *nbuffers, unsigned int *nplanes,
+ unsigned int sizes[], struct device *alloc_devs[])
+{
+ struct rga_ctx *ctx = vb2_get_drv_priv(vq);
+ struct rga_frame *f = rga_get_frame(ctx, vq->type);
+
+ if (IS_ERR(f))
+ return PTR_ERR(f);
+
+ if (*nplanes)
+ return sizes[0] < f->size ? -EINVAL : 0;
+
+ sizes[0] = f->size;
+ *nplanes = 1;
+
+ return 0;
+}
+
+static int rga_buf_prepare(struct vb2_buffer *vb)
+{
+ struct rga_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
+ struct rga_frame *f = rga_get_frame(ctx, vb->vb2_queue->type);
+
+ if (IS_ERR(f))
+ return PTR_ERR(f);
+
+ vb2_set_plane_payload(vb, 0, f->size);
+
+ return 0;
+}
+
+static void rga_buf_queue(struc
Re: [PATCH v9 0/4] Add Rockchip RGA V4l2 support
Hi all, 2017-09-14 9:19 GMT+08:00 Jacob Chen : > This patch series add a v4l2 m2m drvier for rockchip RGA direct rendering > based 2d graphics acceleration module. > > Recently I tried to add protduff support for gstreamer on rockchip platform, > and i found that API > were not very suitable for my purpose. > It shouldn't go upstream until we can figure out what people need, > > change in V9: > - remove protduff things > - test with the latest v4l2-compliance > > change in V8: > - remove protduff things > > change in V6,V7: > - correct warning in checkpatch.pl > > change in V5: > - v4l2-compliance: handle invalid pxielformat > - v4l2-compliance: add subscribe_event > - add colorspace support > > change in V4: > - document the controls. > - change according to Hans's comments > > change in V3: > - rename the controls. > - add pm_runtime support. > - enable node by default. > - correct spelling in documents. > > change in V2: > - generalize the controls. > - map buffers (10-50 us) in every cmd-run rather than in buffer-import to > avoid get_free_pages failed on > actively used systems. > - remove status in dt-bindings examples. > > Jacob Chen (4): > rockchip/rga: v4l2 m2m support > ARM: dts: rockchip: add RGA device node for RK3288 > arm64: dts: rockchip: add RGA device node for RK3399 > dt-bindings: Document the Rockchip RGA bindings > > .../devicetree/bindings/media/rockchip-rga.txt | 33 + > arch/arm/boot/dts/rk3288.dtsi | 11 + > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 + > drivers/media/platform/Kconfig | 11 + > drivers/media/platform/Makefile|2 + > drivers/media/platform/rockchip-rga/Makefile |3 + > drivers/media/platform/rockchip-rga/rga-buf.c | 156 +++ > drivers/media/platform/rockchip-rga/rga-hw.c | 435 + > drivers/media/platform/rockchip-rga/rga-hw.h | 437 + > drivers/media/platform/rockchip-rga/rga.c | 1030 > > drivers/media/platform/rockchip-rga/rga.h | 110 +++ > 11 files changed, 2239 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt > create mode 100644 drivers/media/platform/rockchip-rga/Makefile > create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c > create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c > create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h > create mode 100644 drivers/media/platform/rockchip-rga/rga.c > create mode 100644 drivers/media/platform/rockchip-rga/rga.h > > -- > 2.7.4 > v4l2-compliance SHA : d7c41e2576c09f37b33fe8bf2e38615703086045 Driver Info: Driver name : rockchip-rga Card type : rockchip-rga Bus info : platform:rga Driver version: 4.13.0 Capabilities : 0x84208000 Video Memory-to-Memory Streaming Extended Pix Format Device Capabilities Device Caps : 0x04208000 Video Memory-to-Memory Streaming Extended Pix Format Compliance test for device /dev/video0 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK test VIDIOC_QUERYCTRL: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 5 Private Controls: 0 Format ioctls: test VIDI
[PATCH v9 4/4] dt-bindings: Document the Rockchip RGA bindings
Add DT bindings documentation for Rockchip RGA
Signed-off-by: Jacob Chen
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
---
.../devicetree/bindings/media/rockchip-rga.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt
diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.txt
b/Documentation/devicetree/bindings/media/rockchip-rga.txt
new file mode 100644
index 000..fd5276a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-rga.txt
@@ -0,0 +1,33 @@
+device-tree bindings for rockchip 2D raster graphic acceleration controller
(RGA)
+
+RGA is a standalone 2D raster graphic acceleration unit. It accelerates 2D
+graphics operations, such as point/line drawing, image scaling, rotation,
+BitBLT, alpha blending and image blur/sharpness.
+
+Required properties:
+- compatible: value should be one of the following
+ "rockchip,rk3288-rga";
+ "rockchip,rk3399-rga";
+
+- interrupts: RGA interrupt specifier.
+
+- clocks: phandle to RGA sclk/hclk/aclk clocks
+
+- clock-names: should be "aclk", "hclk" and "sclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: should be "core", "axi" and "ahb"
+
+Example:
+SoC-specific DT entry:
+ rga: rga@ff68 {
+ compatible = "rockchip,rk3399-rga";
+ reg = <0xff68 0x1>;
+ interrupts = ;
+ clocks = <&cru ACLK_RGA>, <&cru HCLK_RGA>, <&cru SCLK_RGA_CORE>;
+ clock-names = "aclk", "hclk", "sclk";
+
+ resets = <&cru SRST_RGA_CORE>, <&cru SRST_A_RGA>, <&cru
SRST_H_RGA>;
+ reset-names = "core, "axi", "ahb";
+ };
--
2.7.4
[PATCH v9 0/4] Add Rockchip RGA V4l2 support
This patch series add a v4l2 m2m drvier for rockchip RGA direct rendering based 2d graphics acceleration module. Recently I tried to add protduff support for gstreamer on rockchip platform, and i found that API were not very suitable for my purpose. It shouldn't go upstream until we can figure out what people need, change in V9: - remove protduff things - test with the latest v4l2-compliance change in V8: - remove protduff things change in V6,V7: - correct warning in checkpatch.pl change in V5: - v4l2-compliance: handle invalid pxielformat - v4l2-compliance: add subscribe_event - add colorspace support change in V4: - document the controls. - change according to Hans's comments change in V3: - rename the controls. - add pm_runtime support. - enable node by default. - correct spelling in documents. change in V2: - generalize the controls. - map buffers (10-50 us) in every cmd-run rather than in buffer-import to avoid get_free_pages failed on actively used systems. - remove status in dt-bindings examples. Jacob Chen (4): rockchip/rga: v4l2 m2m support ARM: dts: rockchip: add RGA device node for RK3288 arm64: dts: rockchip: add RGA device node for RK3399 dt-bindings: Document the Rockchip RGA bindings .../devicetree/bindings/media/rockchip-rga.txt | 33 + arch/arm/boot/dts/rk3288.dtsi | 11 + arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 + drivers/media/platform/Kconfig | 11 + drivers/media/platform/Makefile|2 + drivers/media/platform/rockchip-rga/Makefile |3 + drivers/media/platform/rockchip-rga/rga-buf.c | 156 +++ drivers/media/platform/rockchip-rga/rga-hw.c | 435 + drivers/media/platform/rockchip-rga/rga-hw.h | 437 + drivers/media/platform/rockchip-rga/rga.c | 1030 drivers/media/platform/rockchip-rga/rga.h | 110 +++ 11 files changed, 2239 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt create mode 100644 drivers/media/platform/rockchip-rga/Makefile create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h create mode 100644 drivers/media/platform/rockchip-rga/rga.c create mode 100644 drivers/media/platform/rockchip-rga/rga.h -- 2.7.4
[PATCH v9 3/4] arm64: dts: rockchip: add RGA device node for RK3399
This patch add the RGA dt config of RK3399 SoC.
Signed-off-by: Jacob Chen
Signed-off-by: Yakir Yang
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 5b78ce1..fa15770 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1153,6 +1153,17 @@
status = "disabled";
};
+ rga: rga@ff68 {
+ compatible = "rockchip,rk3399-rga";
+ reg = <0x0 0xff68 0x0 0x1>;
+ interrupts = ;
+ clocks = <&cru ACLK_RGA>, <&cru HCLK_RGA>, <&cru SCLK_RGA_CORE>;
+ clock-names = "aclk", "hclk", "sclk";
+ resets = <&cru SRST_RGA_CORE>, <&cru SRST_A_RGA>, <&cru
SRST_H_RGA>;
+ reset-names = "core", "axi", "ahb";
+ power-domains = <&power RK3399_PD_RGA>;
+ };
+
efuse0: efuse@ff69 {
compatible = "rockchip,rk3399-efuse";
reg = <0x0 0xff69 0x0 0x80>;
--
2.7.4
Re: [PATCH V3 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode
Hi, Andrew, It will cause data corruption, at least on MIPS: step 1, dma_map_single step 2, cache_invalidate (no writeback) step 3, dma_from_device step 4, dma_unmap_single If a DMA buffer and a kernel structure share a same cache line, and if the kernel structure has dirty data, cache_invalidate (no writeback) may cause data lost. Huacai -- Original -- From: "Andrew Morton"; Date: Thu, Sep 14, 2017 05:52 AM To: "Huacai Chen"; Cc: "Fuxin Zhang"; "linux-mm"; "linux-kernel"; "stable"; Subject: Re: [PATCH V3 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode On Wed, 13 Sep 2017 17:20:51 +0800 Huacai Chen wrote: > In non-coherent DMA mode, kernel uses cache flushing operations to > maintain I/O coherency, so the dmapool objects should be aligned to > ARCH_DMA_MINALIGN. What are the user-visible effects of this bug?
Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion
On 09/14, Al Viro wrote:
> On Wed, Sep 13, 2017 at 04:31:16PM -0700, Jaegeuk Kim wrote:
> > Hi Al,
> >
> > On 09/14, Al Viro wrote:
> > > On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote:
> > > > + if (!retval && (flags & UMOUNT_WAIT)) {
> > > > + if (likely(!(current->flags & PF_KTHREAD)))
> > > > + task_work_run();
> > >
> > > This is complete crap. The same damn thing will be done by
> > > caller of sys_umount() pretty much immediately afterwards.
> > > I'm not sure what it is that you are trying to paper over,
> > > but this is just plain wrong.
> >
> > Okay.
> >
> > > What _is_ the semantics of UMOUNT_WAIT? What does it guarantee,
> > > and what would be supplying it to umount(2)?
> >
> > When android tries to reboot the system, it calls umount(2) without any
> > flag.
> > Then, mntput_no_expire() will add delayed_mntput_work() which finally does
> > cleanup_mnt() later. In the mean time, android proceeded to shutdown all
> > the UFS devices.
>
> Why has task_work_add() failed? Or is that umount(2) issued by a kernel
> thread?
Android triggers umount(2) by init process, which is definitely not a kernel
thread. But, we've seen some kernel panics which say umount(2) was succeeded,
but ext4 triggered a kernel panic due to EIO after then like below. I'm also
not sure task_work_run() would be also safe enoughly. May I ask where I can
find sys_umount() calls task_work_run()?
[254012.860565] c4 12426 [] panic+0x184/0x37c
[254012.860589] c4 12426 [] __ext4_abort+0x198/0x19c
[254012.860606] c4 12426 [] ext4_put_super+0x80/0x2b4
[254012.860629] c4 12426 [] generic_shutdown_super+0x68/0xd0
[254012.860646] c4 12426 [] kill_block_super+0x1c/0x5c
[254012.860663] c4 12426 [] deactivate_locked_super+0x5c/0xc0
[254012.860679] c4 12426 [] deactivate_super+0x68/0x74
[254012.860696] c4 12426 [] cleanup_mnt+0xb0/0x12c
[254012.860712] c4 12426 [] delayed_mntput+0x38/0x4c
[254012.860737] c4 12426 [] process_one_work+0x1e0/0x490
[254012.860753] c4 12426 [] worker_thread+0x314/0x494
[254012.860771] c4 12426 [] kthread+0xdc/0xec
[254012.860790] c4 12426 [] ret_from_fork+0x10/0x30
[PATCH v2 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up
Changes from v1
- Enhance commit msg
- Prevent WARN in cpumask_test_cpu() in cpudl_find() when best_cpu == -1
-8<-
>From 7735382d07ae6a61d740ae39ba2ecf169d43b8a2 Mon Sep 17 00:00:00 2001
From: Byungchul Park
Date: Wed, 22 Mar 2017 14:25:56 +0900
Subject: [PATCH v2 1/2] sched/deadline: Add cpudl_maximum_dl() for clean-up
Current code uses cpudl_maximum() to get the root node's cpu, while it
directly accesses the root node like 'cp->elements[0].dl' to get the
root node's dl. It would be more readible to add a function for the dl,
as well. Added it.
Signed-off-by: Byungchul Park
---
kernel/sched/cpudeadline.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index 8d9562d..9f02035 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -108,11 +108,16 @@ static void cpudl_heapify(struct cpudl *cp, int idx)
cpudl_heapify_down(cp, idx);
}
-static inline int cpudl_maximum(struct cpudl *cp)
+static inline int cpudl_maximum_cpu(struct cpudl *cp)
{
return cp->elements[0].cpu;
}
+static inline u64 cpudl_maximum_dl(struct cpudl *cp)
+{
+ return cp->elements[0].dl;
+}
+
/*
* cpudl_find - find the best (later-dl) CPU in the system
* @cp: the cpudl max-heap context
@@ -130,11 +135,11 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
cpumask_and(later_mask, cp->free_cpus, &p->cpus_allowed)) {
return 1;
} else {
- int best_cpu = cpudl_maximum(cp);
+ int best_cpu = cpudl_maximum_cpu(cp);
WARN_ON(best_cpu != -1 && !cpu_present(best_cpu));
if (cpumask_test_cpu(best_cpu, &p->cpus_allowed) &&
- dl_time_before(dl_se->deadline, cp->elements[0].dl)) {
+ dl_time_before(dl_se->deadline, cpudl_maximum_dl(cp))) {
if (later_mask)
cpumask_set_cpu(best_cpu, later_mask);
--
1.9.1
[PATCH v2 2/2] sched/deadline: Initialize cp->elements[].cpu to an invalid value
Currently, migrating tasks to cpu0 unconditionally happens when the
heap is empty, since cp->elements[].cpu was initialized to 0(=cpu0).
We have to distinguish between the empty case and cpu0 to avoid the
unnecessary migrantions. Therefore, it has to return an invalid value
e.i. -1 in that case.
Signed-off-by: Byungchul Park
---
kernel/sched/cpudeadline.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index 9f02035..bcf903f 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -138,6 +138,12 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
int best_cpu = cpudl_maximum_cpu(cp);
WARN_ON(best_cpu != -1 && !cpu_present(best_cpu));
+ /*
+* The heap tree is empry for now, just return.
+*/
+ if (best_cpu == -1)
+ return 0;
+
if (cpumask_test_cpu(best_cpu, &p->cpus_allowed) &&
dl_time_before(dl_se->deadline, cpudl_maximum_dl(cp))) {
if (later_mask)
@@ -265,8 +271,10 @@ int cpudl_init(struct cpudl *cp)
return -ENOMEM;
}
- for_each_possible_cpu(i)
+ for_each_possible_cpu(i) {
+ cp->elements[i].cpu = -1;
cp->elements[i].idx = IDX_INVALID;
+ }
return 0;
}
--
1.9.1
Re: [PATCH v1 1/4] perf annotate: create a new hists to manage multiple events samples
On 9/11/2017 9:33 AM, Jin, Yao wrote:
>
>
> On 9/8/2017 9:43 PM, Arnaldo Carvalho de Melo wrote:
>> Em Wed, Aug 16, 2017 at 06:18:33PM +0800, Jin Yao escreveu:
>>> An issue is found during using perf annotate.
>>>
>>> perf record -e cycles,branches ...
>>> perf annotate main --stdio
>>>
>>> The result only shows cycles. It should show both cycles and
>>> branches on the left side. It works with "--group", but need
>>> this to work even without groups.
>>>
>>> In current design, the hists is per event. So we need a new
>>> hists to manage the samples for multiple events and use a new
>>> hist_event data structure to save the map/symbol information
>>> for per event.
>> Humm, why do we need another hists? Don't we have one per evsel, don't
>> we have a evlist from where to get all of those evsels, can't we just
>> use that to add one column per evsel?
>>
>> - Arnaldo
>>
>
> Hi Arnaldo,
>
> I'm considering a case.
>
> Suppose we sample 2 events ("branches" and "cache-misses"). The samples of
> "branches" are hit in function A and the samples of "cache-misses" are hit in
> function B.
>
> The branches evsel has one hists and cache-misses evsel has another hists.
>
> The hists of branches evsel has one hist-entry which stands for the function
> A symbol. The hists of cache-misses evsel has one hist-entry which stands for
> the function B symbol.
>
> If we start to show the instructions in function B from cache-misses evsel,
> we will lose the function A.
>
> Because even if we get the branches evsel from the link in cache-misses
> evsel, but the function A is before function B and function B has been
> displayed yet, so the function A is lost.
>
> Considering the number of events can be greater than 2, the code will be much
> more complicated. So using a global hists should be an easy solution.
>
> Thanks
> Jin Yao
>
Hi Arnaldo,
Could the solution of using a new hists for multiple events be accepted?
Or anything I should update in the patches?
Thanks
Jin Yao
Re: [PATCH v4 4/4] [media] exynos-gsc: Add hardware rotation limits
On 09/13/2017 09:13 PM, Sylwester Nawrocki wrote:
On 09/13/2017 01:41 PM, Hoegeun Kwon wrote:
@@ -1004,11 +1088,33 @@ static irqreturn_t gsc_irq_handler(int irq,
void *priv)
.num_clocks = 1,
};
+static struct gsc_driverdata gsc_v_5250_drvdata = {
+.variant = {
+[0] = &gsc_v_5250_variant,
+[1] = &gsc_v_5250_variant,
+[2] = &gsc_v_5250_variant,
+[3] = &gsc_v_5250_variant,
+},
+.num_entities = 4,
+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+.variant = {
+[0] = &gsc_v_5420_variant,
+[1] = &gsc_v_5420_variant,
+},
+.num_entities = 4,
Shouldn't num_enities be 2 here? You don't need to resend, I can
amend that when applying.
Yes, num_enities is 2.
Sorry I made a mistake.
Thanks Sylwester.
Best regards,
Hoegeun
+.clk_names = { "gscl" },
+.num_clocks = 1,
+};
+
--
Regards,
Sylwester
Re: Regression for Power PC in 4.14-rc0 - bisected to commit 31bfdb036f12
On 09/13/2017 07:37 PM, Andrew Donnellan wrote:
On 14/09/17 10:07, Larry Finger wrote:
When booting my PowerBook Aluminum G4, I get a pop-up screen that says "The
system is running in low-graphics mode. Your screen, graphics card, and input
device settings could not be detected correctly. You will need to configure
these yourself." This is a big-endian 74xx CPU. The lscpu command says it is a
PowerBook5,6 model.
This problem has been bisected to commit 31bfdb036f12 ("powerpc: Use
instruction emulation infrastructure to handle alignment faults"). I am
confident of the accuracy of the bisection.
Attached is the configuration.
Try with https://patchwork.ozlabs.org/patch/813153/
(A selftest for the instruction emulation will make its way upstream
eventually...)
That patch does fix my problem. Thanks for the quick response.
Larry
Re: [PATCH 2/2] cpufreq: dt: add support for rockchip rv1108
Hi Viresh:
On 2017年09月14日 03:18, Viresh Kumar wrote:
On 21-08-17, 17:10, Andy Yan wrote:
Add the compatible string to support the generic device tree
cpufreq-dt driver on rockchip rv1108 soc.
Signed-off-by: Andy Yan
---
drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 1c26292..2d71c09 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -69,6 +69,7 @@ static const struct of_device_id machines[] __initconst = {
{ .compatible = "renesas,r8a7794", },
{ .compatible = "renesas,sh73a0", },
+ { .compatible = "rockchip,rv1108", },
{ .compatible = "rockchip,rk2928", },
{ .compatible = "rockchip,rk3036", },
{ .compatible = "rockchip,rk3066a", },
You use operating-points-v2 or the V1 bindings for this SoC? The SoCs using
operating-points-v2 don't need such changes anymore.
Yes, I use operating-points-v2.
Re: [PATCH -mm -v4 3/5] mm, swap: VMA based swap readahead
Hi, Andrew,
Andrew Morton writes:
> On Wed, 13 Sep 2017 10:40:19 +0900 Minchan Kim wrote:
>
>> Every zram users like low-end android device has used 0 page-cluster
>> to disable swap readahead because it has no seek cost and works as
>> synchronous IO operation so if we do readahead multiple pages,
>> swap falut latency would be (4K * readahead window size). IOW,
>> readahead is meaningful only if it doesn't bother faulted page's
>> latency.
>>
>> However, this patch introduces additional knob /sys/kernel/mm/swap/
>> vma_ra_max_order as well as page-cluster. It means existing users
>> has used disabled swap readahead doesn't work until they should be
>> aware of new knob and modification of their script/code to disable
>> vma_ra_max_order as well as page-cluster.
>>
>> I say it's a *regression* and wanted to fix it but Huang's opinion
>> is that it's not a functional regression so userspace should be fixed
>> by themselves.
>> Please look into detail of discussion in
>> http://lkml.kernel.org/r/%3c1505183833-4739-4-git-send-email-minc...@kernel.org%3E
>
> hm, tricky problem. I do agree that linking the physical and virtual
> readahead schemes in the proposed fashion is unfortunate. I also agree
> that breaking existing setups (a bit) is also unfortunate.
>
> Would it help if, when page-cluster is written to zero, we do
>
> printk_once("physical readahead disabled, virtual readahead still
> enabled. Disable virtual readhead via
> /sys/kernel/mm/swap/vma_ra_max_order").
>
> Or something like that. It's pretty lame, but it should help alert the
> zram-readahead-disabling people to the issue?
This sounds good for me.
Hi, Minchan, what do you think about this? I think for low-end android
device, the end-user may have no opportunity to upgrade to the latest
kernel, the device vendor should care about this. For desktop users,
the warning proposed by Andrew may help to remind them for the new knob.
Best Regards,
Huang, Ying
Re: Regression for Power PC in 4.14-rc0 - bisected to commit 31bfdb036f12
On 14/09/17 10:07, Larry Finger wrote:
When booting my PowerBook Aluminum G4, I get a pop-up screen that says
"The system is running in low-graphics mode. Your screen, graphics
card, and input device settings could not be detected correctly. You
will need to configure these yourself." This is a big-endian 74xx CPU.
The lscpu command says it is a PowerBook5,6 model.
This problem has been bisected to commit 31bfdb036f12 ("powerpc: Use
instruction emulation infrastructure to handle alignment faults"). I am
confident of the accuracy of the bisection.
Attached is the configuration.
Try with https://patchwork.ozlabs.org/patch/813153/
(A selftest for the instruction emulation will make its way upstream
eventually...)
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com IBM Australia Limited
Re: [RFC PATCH 1/2] autofs: set compat flag on sbi when daemon uses 32bit addressation
On 01/09/17 19:21, Stanislav Kinsburskiy wrote:
> Signed-off-by: Stanislav Kinsburskiy
> ---
> fs/autofs4/autofs_i.h |3 +++
> fs/autofs4/dev-ioctl.c |3 +++
> fs/autofs4/inode.c |4 +++-
> 3 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
> index 4737615..3da105f 100644
> --- a/fs/autofs4/autofs_i.h
> +++ b/fs/autofs4/autofs_i.h
> @@ -120,6 +120,9 @@ struct autofs_sb_info {
> struct list_head active_list;
> struct list_head expiring_list;
> struct rcu_head rcu;
> +#ifdef CONFIG_COMPAT
> + unsigned is32bit:1;
> +#endif
> };
>
> static inline struct autofs_sb_info *autofs4_sbi(struct super_block *sb)
> diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
> index b7c816f..467d6c4 100644
> --- a/fs/autofs4/dev-ioctl.c
> +++ b/fs/autofs4/dev-ioctl.c
> @@ -397,6 +397,9 @@ static int autofs_dev_ioctl_setpipefd(struct file *fp,
> sbi->pipefd = pipefd;
> sbi->pipe = pipe;
> sbi->catatonic = 0;
> +#ifdef CONFIG_COMPAT
> + sbi->is32bit = is_compat_task();
> +#endif
> }
> out:
> put_pid(new_pid);
> diff --git a/fs/autofs4/inode.c b/fs/autofs4/inode.c
> index 09e7d68..21d3c0b 100644
> --- a/fs/autofs4/inode.c
> +++ b/fs/autofs4/inode.c
> @@ -301,7 +301,9 @@ int autofs4_fill_super(struct super_block *s, void *data,
> int silent)
> } else {
> sbi->oz_pgrp = get_task_pid(current, PIDTYPE_PGID);
> }
> -
> +#ifdef CONFIG_COMPAT
> + sbi->is32bit = is_compat_task();
> +#endif
> if (autofs_type_trigger(sbi->type))
> __managed_dentry_set_managed(root);
>
>
Not sure about this.
Don't you think it would be better to avoid the in code #ifdefs by doing some
checks and defines in the header file and defining what's need to just use
is_compat_task().
Not sure 2 patches are needed for this either ..
Ian
Re: [RFC PATCH 0/2] autofs: fix autofs_v5_packet dlivery in compat mode
On 01/09/17 19:21, Stanislav Kinsburskiy wrote: > The problem is that in compat mode struct autofs_v5_packet has to have > different size > (i.e. 4 bytes less). I regret (several times over) my original decision to not make v5 packets packed I have to say the description of the problem is not all that good. > > This is RFC because: > 1) This issue is hidden, because autofs pipe has O_DIRECT and the rest of the > epacket is truncated when read. > 2) X86 arch doesn't have is_compat_task() helper > 3) It's now clear, what to do if "pgrp" option is specified. I don't understand what the "pgrp" option has to do with this? > > The following series implements... > > --- > > Stanislav Kinsburskiy (2): > autofs: set compat flag on sbi when daemon uses 32bit addressation > autofs: sent 32-bit sized packet for 32-bit process > > > fs/autofs4/autofs_i.h |3 +++ > fs/autofs4/dev-ioctl.c |3 +++ > fs/autofs4/inode.c |4 +++- > fs/autofs4/waitq.c |5 + > 4 files changed, 14 insertions(+), 1 deletion(-) >
Re: [PATCH v3 04/20] mm: VMA sequence count
Hi,
On (09/13/17 18:56), Laurent Dufour wrote:
> Hi Sergey,
>
> On 13/09/2017 13:53, Sergey Senozhatsky wrote:
> > Hi,
> >
> > On (09/08/17 20:06), Laurent Dufour wrote:
[..]
> > ok, so what I got on my box is:
> >
> > vm_munmap() -> down_write_killable(&mm->mmap_sem)
> > do_munmap()
> > __split_vma()
> >__vma_adjust() -> write_seqcount_begin(&vma->vm_sequence)
> >-> write_seqcount_begin_nested(&next->vm_sequence,
> > SINGLE_DEPTH_NESTING)
> >
> > so this gives 3 dependencies ->mmap_sem -> ->vm_seq
> > ->vm_seq -> ->vm_seq/1
> > ->mmap_sem -> ->vm_seq/1
> >
> >
> > SyS_mremap() -> down_write_killable(¤t->mm->mmap_sem)
> > move_vma() -> write_seqcount_begin(&vma->vm_sequence)
> > -> write_seqcount_begin_nested(&new_vma->vm_sequence,
> > SINGLE_DEPTH_NESTING);
> > move_page_tables()
> >__pte_alloc()
> > pte_alloc_one()
> > __alloc_pages_nodemask()
> > fs_reclaim_acquire()
> >
> >
> > I think here we have prepare_alloc_pages() call, that does
> >
> > -> fs_reclaim_acquire(gfp_mask)
> > -> fs_reclaim_release(gfp_mask)
> >
> > so that adds one more dependency ->mmap_sem -> ->vm_seq->
> > fs_reclaim
> > ->mmap_sem -> ->vm_seq/1 ->
> > fs_reclaim
> >
> >
> > now, under memory pressure we hit the slow path and perform direct
> > reclaim. direct reclaim is done under fs_reclaim lock, so we end up
> > with the following call chain
> >
> > __alloc_pages_nodemask()
> > __alloc_pages_slowpath()
> > __perform_reclaim() -> fs_reclaim_acquire(gfp_mask);
> >try_to_free_pages()
> > shrink_node()
> > shrink_active_list()
> > rmap_walk_file() -> i_mmap_lock_read(mapping);
> >
> >
> > and this break the existing dependency. since we now take the leaf lock
> > (fs_reclaim) first and the the root lock (->mmap_sem).
>
> Thanks for looking at this.
> I'm sorry, I should have miss something.
no prob :)
> My understanding is that there are 2 chains of locks:
> 1. from __vma_adjust() mmap_sem -> i_mmap_rwsem -> vm_seq
> 2. from move_vmap() mmap_sem -> vm_seq -> fs_reclaim
> 2. from __alloc_pages_nodemask() fs_reclaim -> i_mmap_rwsem
yes, as far as lockdep warning suggests.
> So the solution would be to have in __vma_adjust()
> mmap_sem -> vm_seq -> i_mmap_rwsem
>
> But this will raised the following dependency from unmap_mapping_range()
> unmap_mapping_range() -> i_mmap_rwsem
> unmap_mapping_range_tree()
> unmap_mapping_range_vma()
>zap_page_range_single()
> unmap_single_vma()
> unmap_page_range() -> vm_seq
>
> And there is no way to get rid of it easily as in unmap_mapping_range()
> there is no VMA identified yet.
>
> That's being said I can't see any clear way to get lock dependency cleaned
> here.
> Furthermore, this is not clear to me how a deadlock could happen as vm_seq
> is a sequence lock, and there is no way to get blocked here.
as far as I understand,
seq locks can deadlock, technically. not on the write() side, but on
the read() side:
read_seqcount_begin()
raw_read_seqcount_begin()
__read_seqcount_begin()
and __read_seqcount_begin() spins for ever
__read_seqcount_begin()
{
repeat:
ret = READ_ONCE(s->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
return ret;
}
so if there are two CPUs, one doing write_seqcount() and the other one
doing read_seqcount() then what can happen is something like this
CPU0CPU1
fs_reclaim_acquire()
write_seqcount_begin()
fs_reclaim_acquire()read_seqcount_begin()
write_seqcount_end()
CPU0 can't write_seqcount_end() because of fs_reclaim_acquire() from
CPU1, CPU1 can't read_seqcount_begin() because CPU0 did write_seqcount_begin()
and now waits for fs_reclaim_acquire(). makes sense?
-ss
linux-next: manual merge of the vfs tree with the btrfs-kdave tree
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/btrfs/root-tree.c
between commit:
8b591d54b74b ("btrfs: Clean up dead code in root-tree")
from the btrfs-kdave tree and commit:
bc98a42c1f7d ("VFS: Convert sb->s_flags & MS_RDONLY to sb_rdonly(sb)")
from the vfs tree.
I fixed it up (the former removed the code updated by the latter, so I
did that) 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.
[David Sterba: just wondering if all the commits that appeared in the
btrfs-kdave tree today (so late in the merge window) are really destined
for v4.14?]
--
Cheers,
Stephen Rothwell
Regression for Power PC in 4.14-rc0 - bisected to commit 31bfdb036f12
When booting my PowerBook Aluminum G4, I get a pop-up screen that says "The
system is running in low-graphics mode. Your screen, graphics card, and input
device settings could not be detected correctly. You will need to configure
these yourself." This is a big-endian 74xx CPU. The lscpu command says it is a
PowerBook5,6 model.
This problem has been bisected to commit 31bfdb036f12 ("powerpc: Use instruction
emulation infrastructure to handle alignment faults"). I am confident of the
accuracy of the bisection.
Attached is the configuration.
Thanks,
Larry
#
# Automatically generated file; DO NOT EDIT.
# Linux/powerpc 4.13.0-rc2 Kernel Configuration
#
# CONFIG_PPC64 is not set
#
# Processor support
#
CONFIG_PPC_BOOK3S_32=y
# CONFIG_PPC_85xx is not set
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_PPC_BOOK3S=y
CONFIG_6xx=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
CONFIG_PPC_HAVE_PMU_SUPPORT=y
CONFIG_PPC_PERF_CTRS=y
# CONFIG_FORCE_SMP is not set
# CONFIG_SMP is not set
# CONFIG_PPC_DOORBELL is not set
CONFIG_VDSO32=y
CONFIG_CPU_BIG_ENDIAN=y
CONFIG_PPC32=y
CONFIG_32BIT=y
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
# CONFIG_ARCH_DMA_ADDR_T_64BIT is not set
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MAX=17
CONFIG_ARCH_MMAP_RND_BITS_MIN=11
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=17
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
# CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK is not set
CONFIG_NR_IRQS=512
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK=y
CONFIG_PPC=y
# CONFIG_GENERIC_CSUM is not set
CONFIG_EARLY_PRINTK=y
CONFIG_PANIC_TIMEOUT=180
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_EPAPR_BOOT is not set
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_KERNEL_GZIP=y
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TINY_SRCU=y
# CONFIG_TASKS_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_RCU_NEED_SEGCBLIST is not set
CONFIG_BUILD_BIN2C=y
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=20
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_CGROUPS=y
# CONFIG_MEMCG is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_SOCK_CGROUP_DATA is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set
CONFIG_CC_O
[PATCH] mm,compaction: serialize waitqueue_active() checks (for real)
Andrea brought to my attention that the L->{L,S} guarantees
are completely bogus for this case. I was looking at the diagram,
from the offending commit, when that _is_ the race, we had the
load reordered already.
What we need is at least S->L semantics, thus simply use
wq_has_sleeper() to serialize the call for good.
Fixes: 46acef048a6 (mm,compaction: serialize waitqueue_active() checks)
Reported-by: Andrea Parri
Signed-off-by: Davidlohr Bueso
---
mm/compaction.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index fb548e4c7bd4..d1ad2cf6c758 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1999,17 +1999,16 @@ void wakeup_kcompactd(pg_data_t *pgdat, int order, int
classzone_idx)
if (pgdat->kcompactd_max_order < order)
pgdat->kcompactd_max_order = order;
- /*
-* Pairs with implicit barrier in wait_event_freezable()
-* such that wakeups are not missed in the lockless
-* waitqueue_active() call.
-*/
smp_acquire__after_ctrl_dep();
if (pgdat->kcompactd_classzone_idx > classzone_idx)
pgdat->kcompactd_classzone_idx = classzone_idx;
- if (!waitqueue_active(&pgdat->kcompactd_wait))
+ /*
+* Pairs with implicit barrier in wait_event_freezable()
+* such that wakeups are not missed.
+*/
+ if (!wq_has_sleeper(&pgdat->kcompactd_wait))
return;
if (!kcompactd_node_suitable(pgdat))
--
2.12.0
Re: [Patch v2 2/2] libiscsi: Remove iscsi_destroy_session
On 07/13/2017 09:11 AM, Khazhismel Kumykov wrote:
> iscsi_session_teardown was the only user of this function. Function
> currently is just short for iscsi_remove_session + iscsi_free_session.
>
> Signed-off-by: Khazhismel Kumykov
Why is this needed? I dislike changes that don't fix anything.
> ---
> drivers/scsi/scsi_transport_iscsi.c | 16
> include/scsi/scsi_transport_iscsi.h | 1 -
> 2 files changed, 17 deletions(-)
>
> diff --git a/drivers/scsi/scsi_transport_iscsi.c
> b/drivers/scsi/scsi_transport_iscsi.c
> index a424eaeafeb0..924ac408d8a9 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -2210,22 +2210,6 @@ void iscsi_free_session(struct iscsi_cls_session
> *session)
> }
> EXPORT_SYMBOL_GPL(iscsi_free_session);
>
> -/**
> - * iscsi_destroy_session - destroy iscsi session
> - * @session: iscsi_session
> - *
> - * Can be called by a LLD or iscsi_transport. There must not be
> - * any running connections.
> - */
> -int iscsi_destroy_session(struct iscsi_cls_session *session)
> -{
> - iscsi_remove_session(session);
> - ISCSI_DBG_TRANS_SESSION(session, "Completing session destruction\n");
> - iscsi_free_session(session);
> - return 0;
> -}
> -EXPORT_SYMBOL_GPL(iscsi_destroy_session);
> -
> /**
> * iscsi_create_conn - create iscsi class connection
> * @session: iscsi cls session
> diff --git a/include/scsi/scsi_transport_iscsi.h
> b/include/scsi/scsi_transport_iscsi.h
> index 6183d20a01fb..b266d2a3bcb1 100644
> --- a/include/scsi/scsi_transport_iscsi.h
> +++ b/include/scsi/scsi_transport_iscsi.h
> @@ -434,7 +434,6 @@ extern struct iscsi_cls_session
> *iscsi_create_session(struct Scsi_Host *shost,
> unsigned int target_id);
> extern void iscsi_remove_session(struct iscsi_cls_session *session);
> extern void iscsi_free_session(struct iscsi_cls_session *session);
> -extern int iscsi_destroy_session(struct iscsi_cls_session *session);
> extern struct iscsi_cls_conn *iscsi_create_conn(struct iscsi_cls_session
> *sess,
> int dd_size, uint32_t cid);
> extern int iscsi_destroy_conn(struct iscsi_cls_conn *conn);
>
--
Lee Duncan
SUSE Labs
Re: [PATCH] mm: Restore mmput_async
On Wed, Sep 13, 2017 at 3:57 PM, Andrew Morton
wrote:
> On Wed, 13 Sep 2017 18:44:11 -0400 Sherry Yang wrote:
>
>> On Wed, Sep 13, 2017 at 6:09 PM, Andrew Morton
>> wrote:
>> > On Wed, 13 Sep 2017 17:59:27 -0400 Sherry Yang wrote:
>> >
>> >> Restore asynchronous mmput, allowing mmput_async to be called
>> >> from an atomic context in Android binder shrinker callback.
>> >>
>> >> mmput_async was initially introduced in ec8d7c14e
>> >> ("mm, oom_reaper: do not mmput synchronously from the
>> >> oom reaper context"), and was removed in 212925802
>> >> ("mm: oom: let oom_reap_task and exit_mmap run concurrently")
>> >
>> > Presumably there's a patch somewhere which adds a call to mmput_async()
>> > into drivers/android/binder.c? Where is that patch?
>>
>> The patch that uses mmput_async() is
>> https://lkml.org/lkml/2017/9/8/785. Gmail doesn't seem to respect
>> in-reply-to.
>
> (Top-posting repaired. Please don't!)
>
> Is it necessary for binder_alloc_free_page() to take a ref on the mm?
> As long as alloc->tsk doesn't exit during binder_alloc_free_page()'s
> execution, that task's reference on the mm should be sufficient to keep
> the mm alive?
>
alloc->tsk can exit during binder_alloc_free_page. We don't hold a
reference to the task's mm struct while we don't actively use it, as
this would prevent the driver from getting closed when a process dies.
--
Arve Hjønnevåg
mmotm 2017-09-13-16-59 uploaded
The mm-of-the-moment snapshot 2017-09-13-16-59 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (4.x or 4.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/ To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/ and use of this tree is similar to http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above. This mmotm tree contains the following patches against 4.13: (patches marked "*" will be included in linux-next) origin.patch i-need-old-gcc.patch * idr-remove-warn_on_once-when-trying-to-replace-negative-id.patch * drivers-media-cec-cec-adapc-fix-build-with-gcc-444.patch * procfs-remove-unused-variable.patch * test_bitmap-use-ull-suffix-for-64-bit-constants.patch * fscache-fix-fscache_objlist_show-format-processing.patch * ib-mlx4-fix-sprintf-format-warning.patch * treewide-remove-gfp_temporary-allocation-flag.patch * arm64-stacktrace-avoid-listing-stacktrace-functions-in-stacktrace.patch * mm-page_owner-skip-unnecessary-stack_trace-entries.patch * mm-skip-hwpoisoned-pages-when-onlining-pages.patch * ksm-fix-unlocked-iteration-over-vmas-in-cmp_and_merge_page.patch * mm-hugetlb-soft_offline-save-compound-page-order-before-page-migration.patch * sh-sh7722-remove-nonexistent-gpio_ptq7-to-fix-pinctrl-registration.patch * sh-sh7757-remove-nonexistent-gpio_pt7_resv-to-fix-pinctrl-registration.patch * sh-sh7264-remove-nonexistent-gpio_ph-to-fix-pinctrl-registration.patch * sh-sh7269-remove-nonexistent-gpio_ph-to-fix-pinctrl-registration.patch * z3fold-fix-potential-race-in-z3fold_reclaim_page.patch * mm-oom_reaper-skip-mm-structs-with-mmu-notifiers.patch * mm-oom_reaper-skip-mm-structs-with-mmu-notifiers-checkpatch-fixes.patch * mm-memcg-remove-hotplug-locking-from-try_charge.patch * mm-memory_hotplug-do-not-back-off-draining-pcp-free-pages-from-kworker-context.patch * arm-arch-arm-include-asm-pageh-needs-personalityh.patch * ocfs2-get-rid-of-ocfs2_is_o2cb_active-function.patch * ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called.patch * ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called-fix.patch * ocfs2-give-an-obvious-tip-for-dismatch-cluster-names.patch * ocfs2-give-an-obvious-tip-for-dismatch-cluster-names-v2.patch * ocfs2-move-some-definitions-to-header-file.patch * ocfs2-fix-some-small-problems.patch * ocfs2-add-kobject-for-online-file-check.patch * ocfs2-add-duplicative-ino-number-check.patch * block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch * dentry-fix-kmemcheck-splat-at-take_dentry_name_snapshot.patch mm.patch * mm-compaction-kcompactd-should-not-ignore-pageblock-skip.patch * mm-compaction-persistently-skip-hugetlbfs-pageblocks.patch * mm-compaction-persistently-skip-hugetlbfs-pageblocks-fix.patch * mm-cma-manage-the-memory-of-the-cma-area-by-using-the-zone_movable.patch * mm-cma-remove-alloc_cma.patch * arm-cma-avoid-double-mapping-to-the-cma-area-if-config_highmem-=-y.patch * mm-page_alloc-return-0-in-ca
[PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT
From: Rob Landley
Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move
/dev/console open after devtmpfs mount.
Add workaround for Debian bug that was copied by Ubuntu.
Signed-off-by: Rob Landley
---
v2 discussion: http://lkml.iu.edu/hypermail/linux/kernel/1705.2/05611.html
drivers/base/Kconfig | 14 --
fs/namespace.c | 14 ++
init/main.c | 15 +--
3 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index f046d21..97352d4 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -48,16 +48,10 @@ config DEVTMPFS_MOUNT
bool "Automount devtmpfs at /dev, after the kernel mounted the rootfs"
depends on DEVTMPFS
help
- This will instruct the kernel to automatically mount the
- devtmpfs filesystem at /dev, directly after the kernel has
- mounted the root filesystem. The behavior can be overridden
- with the commandline parameter: devtmpfs.mount=0|1.
- This option does not affect initramfs based booting, here
- the devtmpfs filesystem always needs to be mounted manually
- after the rootfs is mounted.
- With this option enabled, it allows to bring up a system in
- rescue mode with init=/bin/sh, even when the /dev directory
- on the rootfs is completely empty.
+ Automatically mount devtmpfs at /dev on the root filesystem, which
+ lets the system to come up in rescue mode with [rd]init=/bin/sh.
+ Override with devtmpfs.mount=0 on the commandline. Initramfs can
+ create a /dev dir as needed, other rootfs needs the mount point.
config STANDALONE
bool "Select only drivers that don't need compile-time external
firmware"
diff --git a/fs/namespace.c b/fs/namespace.c
index f8893dc..06057d7 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2417,7 +2417,21 @@ static int do_add_mount(struct mount *newmnt, struct
path *path, int mnt_flags)
err = -EBUSY;
if (path->mnt->mnt_sb == newmnt->mnt.mnt_sb &&
path->mnt->mnt_root == path->dentry)
+ {
+ if (IS_ENABLED(CONFIG_DEVTMPFS_MOUNT) &&
+ !strcmp(path->mnt->mnt_sb->s_type->name, "devtmpfs"))
+ {
+ /* Debian's kernel config enables DEVTMPFS_MOUNT, then
+ its initramfs setup script tries to mount devtmpfs
+ again, and if the second mount-over-itself fails
+ the script overmounts a tmpfs on /dev to hide the
+ existing contents, then boot fails with empty /dev.
*/
+ printk(KERN_WARNING "Debian bug workaround for devtmpfs
overmount.");
+
+ err = 0;
+ }
goto unlock;
+ }
err = -EINVAL;
if (d_is_symlink(newmnt->mnt.mnt_root))
diff --git a/init/main.c b/init/main.c
index 0ee9c686..0d8e5ec 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1065,12 +1065,6 @@ static noinline void __init kernel_init_freeable(void)
do_basic_setup();
- /* Open the /dev/console on the rootfs, this should never fail */
- if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
- pr_err("Warning: unable to open an initial console.\n");
-
- (void) sys_dup(0);
- (void) sys_dup(0);
/*
* check if there is an early userspace init. If yes, let it do all
* the work
@@ -1082,8 +1076,17 @@ static noinline void __init kernel_init_freeable(void)
if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) {
ramdisk_execute_command = NULL;
prepare_namespace();
+ } else if (IS_ENABLED(CONFIG_DEVTMPFS_MOUNT)) {
+ sys_mkdir("/dev", 0755);
+ devtmpfs_mount("/dev");
}
+ /* Open the /dev/console on the rootfs, this should never fail */
+ if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
+ pr_err("Warning: unable to open an initial console.\n");
+ (void) sys_dup(0);
+ (void) sys_dup(0);
+
/*
* Ok, we have completed the initial bootup, and
* we're essentially up and running. Get rid of the
Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion
On Wed, Sep 13, 2017 at 04:31:16PM -0700, Jaegeuk Kim wrote:
> Hi Al,
>
> On 09/14, Al Viro wrote:
> > On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote:
> > > + if (!retval && (flags & UMOUNT_WAIT)) {
> > > + if (likely(!(current->flags & PF_KTHREAD)))
> > > + task_work_run();
> >
> > This is complete crap. The same damn thing will be done by
> > caller of sys_umount() pretty much immediately afterwards.
> > I'm not sure what it is that you are trying to paper over,
> > but this is just plain wrong.
>
> Okay.
>
> > What _is_ the semantics of UMOUNT_WAIT? What does it guarantee,
> > and what would be supplying it to umount(2)?
>
> When android tries to reboot the system, it calls umount(2) without any flag.
> Then, mntput_no_expire() will add delayed_mntput_work() which finally does
> cleanup_mnt() later. In the mean time, android proceeded to shutdown all
> the UFS devices.
Why has task_work_add() failed? Or is that umount(2) issued by a kernel thread?
Re: [PATCH v4 01/18] fpga: bridge: support getting bridge from device
Hi Alan,
Two minor nits below.
Matthew Gerlach
On Wed, 13 Sep 2017, Alan Tull wrote:
Add two functions for getting the FPGA bridge from the device
rather than device tree node. This is to enable writing code
that will support using FPGA bridges without device tree.
Rename one old function to make it clear that it is device
tree-ish. This leaves us with 3 functions for getting a bridge:
* fpga_bridge_get
Get the bridge given the device.
* fpga_bridges_get_to_list
Given the device, get the bridge and add it to a list.
* of_fpga_bridges_get_to_list
Renamed from priviously existing fpga_bridges_get_to_list.
Given the device node, get the bridge and add it to a list.
Signed-off-by: Alan Tull
---
v2: use list_for_each_entry
static the bridge_list_lock
update copyright and author email
v3: no change to this patch in this version of patchset
v4: no change to this patch in this version of patchset
---
drivers/fpga/fpga-bridge.c | 110 +++
drivers/fpga/fpga-region.c | 11 ++--
include/linux/fpga/fpga-bridge.h | 7 ++-
3 files changed, 100 insertions(+), 28 deletions(-)
diff --git a/drivers/fpga/fpga-bridge.c b/drivers/fpga/fpga-bridge.c
index fcd2bd3..af6d97e 100644
--- a/drivers/fpga/fpga-bridge.c
+++ b/drivers/fpga/fpga-bridge.c
@@ -2,6 +2,7 @@
* FPGA Bridge Framework Driver
*
* Copyright (C) 2013-2016 Altera Corporation, All Rights Reserved.
+ * Copyright (C) 2017 Intel Corporation
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@@ -70,29 +71,12 @@ int fpga_bridge_disable(struct fpga_bridge *bridge)
}
EXPORT_SYMBOL_GPL(fpga_bridge_disable);
-/**
- * of_fpga_bridge_get - get an exclusive reference to a fpga bridge
- *
- * @np: node pointer of a FPGA bridge
- * @info: fpga image specific information
- *
- * Return fpga_bridge struct if successful.
- * Return -EBUSY if someone already has a reference to the bridge.
- * Return -ENODEV if @np is not a FPGA Bridge.
- */
-struct fpga_bridge *of_fpga_bridge_get(struct device_node *np,
- struct fpga_image_info *info)
-
+struct fpga_bridge *__fpga_bridge_get(struct device *dev,
+ struct fpga_image_info *info)
Should this be a static function?
I was recently told by mtd maintainers that function names prefixed with
__ should be avoided.
{
- struct device *dev;
struct fpga_bridge *bridge;
int ret = -ENODEV;
- dev = class_find_device(fpga_bridge_class, NULL, np,
- fpga_bridge_of_node_match);
- if (!dev)
- goto err_dev;
-
bridge = to_fpga_bridge(dev);
if (!bridge)
goto err_dev;
@@ -117,8 +101,58 @@ struct fpga_bridge *of_fpga_bridge_get(struct device_node
*np,
put_device(dev);
return ERR_PTR(ret);
}
+
+/**
+ * of_fpga_bridge_get - get an exclusive reference to a fpga bridge
+ *
+ * @np: node pointer of a FPGA bridge
+ * @info: fpga image specific information
+ *
+ * Return fpga_bridge struct if successful.
+ * Return -EBUSY if someone already has a reference to the bridge.
+ * Return -ENODEV if @np is not a FPGA Bridge.
+ */
+struct fpga_bridge *of_fpga_bridge_get(struct device_node *np,
+ struct fpga_image_info *info)
+{
+ struct device *dev;
+
+ dev = class_find_device(fpga_bridge_class, NULL, np,
+ fpga_bridge_of_node_match);
+ if (!dev)
+ return ERR_PTR(-ENODEV);
+
+ return __fpga_bridge_get(dev, info);
+}
EXPORT_SYMBOL_GPL(of_fpga_bridge_get);
+static int fpga_bridge_dev_match(struct device *dev, const void *data)
+{
+ return dev->parent == data;
+}
+
+/**
+ * fpga_bridge_get - get an exclusive reference to a fpga bridge
+ * @dev: parent device that fpga bridge was registered with
+ *
+ * Given a device, get an exclusive reference to a fpga bridge.
+ *
+ * Return: fpga manager struct or IS_ERR() condition containing error code.
+ */
+struct fpga_bridge *fpga_bridge_get(struct device *dev,
+ struct fpga_image_info *info)
+{
+ struct device *bridge_dev;
+
+ bridge_dev = class_find_device(fpga_bridge_class, NULL, dev,
+ fpga_bridge_dev_match);
+ if (!bridge_dev)
+ return ERR_PTR(-ENODEV);
+
+ return __fpga_bridge_get(bridge_dev, info);
+}
+EXPORT_SYMBOL_GPL(fpga_bridge_get);
+
/**
* fpga_bridge_put - release a reference to a bridge
*
@@ -206,7 +240,7 @@ void fpga_bridges_put(struct list_head *bridge_list)
EXPORT_SYMBOL_GPL(fpga_bridges_put);
/**
- * fpga_bridges_get_to_list - get a bridge, add it to a list
+ * of_fpga_bridge_get_to_list - get a bridge, add it to a list
*
* @np: node pointer of a FPGA bridge
* @info: fpga image specific information
@@ -216,14 +250,44 @@
Re: [PATCH][pinctrl-next] pinctrl/amd: make functions amd_gpio_suspend and amd_gpio_resume static
On Thu, Sep 14, 2017 at 12:15 AM, Colin King wrote: > > From: Colin Ian King > > The functions amd_gpio_suspend and amd_gpio_resume are local to the > source and do not need to be in global scope, so make them static. > > Cleans up sparse warnings: > symbol 'amd_gpio_suspend' was not declared. Should it be static? > symbol 'amd_gpio_resume' was not declared. Should it be static? > > Signed-off-by: Colin Ian King Reviewed-by: Daniel Drake
Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion
Hi Al,
On 09/14, Al Viro wrote:
> On Wed, Sep 13, 2017 at 01:09:41PM -0700, Jaegeuk Kim wrote:
> > + if (!retval && (flags & UMOUNT_WAIT)) {
> > + if (likely(!(current->flags & PF_KTHREAD)))
> > + task_work_run();
>
> This is complete crap. The same damn thing will be done by
> caller of sys_umount() pretty much immediately afterwards.
> I'm not sure what it is that you are trying to paper over,
> but this is just plain wrong.
Okay.
> What _is_ the semantics of UMOUNT_WAIT? What does it guarantee,
> and what would be supplying it to umount(2)?
When android tries to reboot the system, it calls umount(2) without any flag.
Then, mntput_no_expire() will add delayed_mntput_work() which finally does
cleanup_mnt() later. In the mean time, android proceeded to shutdown all
the UFS devices, but filesystem would be still alive and tries to trigger
some I/Os. At this moment, I'd like to avoid EIO, since ext4 can issue kernel
panic because of error=panic.
So, what I'm trying to do is 1) adding a flag to wait for umount() completion,
2) issuing umount(2) with UMOUNT_WAIT in android. Then, it can guarantee there'd
be no I/Os after sucessful umount().
Could you please correct me?
Thanks,
[PATCH] driver core: suppress sending MODALIAS in UNBIND uevents
The current udev rules cause modules to be loaded on all device events save
for "remove". With the introduction of KOBJ_BIND/KOBJ_UNBIND this causes
issues, as driver modules that have devices bound to their drivers get
immediately reloaded, and it appears to the user that module unloading doe
snot work.
The standard udev matching rule is foillowing:
ENV{MODALIAS}=="?*", RUN{builtin}+="kmod load $env{MODALIAS}"
Given that MODALIAS data is not terribly useful for UNBIND event, let's zap
it from the generated uevent environment until we get userspace updated
with the correct udev rule that only loads modules on "add" event.
Reported-by: Jakub Kicinski
Tested-by: Jakub Kicinski
Fixes: 1455cf8dbfd0 ("driver core: emit uevents when device is bound ...")
Signed-off-by: Dmitry Torokhov
---
lib/kobject_uevent.c | 49 +
1 file changed, 41 insertions(+), 8 deletions(-)
diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index e590523ea476..f237a09a5862 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -294,6 +294,26 @@ static void cleanup_uevent_env(struct subprocess_info
*info)
}
#endif
+static void zap_modalias_env(struct kobj_uevent_env *env)
+{
+ static const char modalias_prefix[] = "MODALIAS=";
+ int i;
+
+ for (i = 0; i < env->envp_idx;) {
+ if (strncmp(env->envp[i], modalias_prefix,
+ sizeof(modalias_prefix) - 1)) {
+ i++;
+ continue;
+ }
+
+ if (i != env->envp_idx - 1)
+ memmove(&env->envp[i], &env->envp[i + 1],
+ sizeof(env->envp[i]) * env->envp_idx - 1);
+
+ env->envp_idx--;
+ }
+}
+
/**
* kobject_uevent_env - send an uevent with environmental data
*
@@ -409,16 +429,29 @@ int kobject_uevent_env(struct kobject *kobj, enum
kobject_action action,
}
}
- /*
-* Mark "add" and "remove" events in the object to ensure proper
-* events to userspace during automatic cleanup. If the object did
-* send an "add" event, "remove" will automatically generated by
-* the core, if not already done by the caller.
-*/
- if (action == KOBJ_ADD)
+ switch (action) {
+ case KOBJ_ADD:
+ /*
+* Mark "add" event so we can make sure we deliver "remove"
+* event to userspace during automatic cleanup. If
+* the object did send an "add" event, "remove" will
+* automatically generated by the core, if not already done
+* by the caller.
+*/
kobj->state_add_uevent_sent = 1;
- else if (action == KOBJ_REMOVE)
+ break;
+
+ case KOBJ_REMOVE:
kobj->state_remove_uevent_sent = 1;
+ break;
+
+ case KOBJ_UNBIND:
+ zap_modalias_env(env);
+ break;
+
+ default:
+ break;
+ }
mutex_lock(&uevent_sock_mutex);
/* we will send an event, so request a new sequence number */
--
2.14.1.690.gbb1197296e-goog
--
Dmitry
Re: [PATCH v2] net: smsc911x: Quieten netif during suspend
On 09/13/2017 10:42 AM, Geert Uytterhoeven wrote:
> If the network interface is kept running during suspend, the net core
> may call net_device_ops.ndo_start_xmit() while the Ethernet device is
> still suspended, which may lead to a system crash.
>
> E.g. on sh73a0/kzm9g and r8a73a4/ape6evm, the external Ethernet chip is
> driven by a PM controlled clock. If the Ethernet registers are accessed
> while the clock is not running, the system will crash with an imprecise
> external abort.
>
> As this is a race condition with a small time window, it is not so easy
> to trigger at will. Using pm_test may increase your chances:
>
> # echo 0 > /sys/module/printk/parameters/console_suspend
> # echo platform > /sys/power/pm_test
> # echo mem > /sys/power/state
>
> To fix this, make sure the network interface is quietened during
> suspend.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Florian Fainelli
You may want to take the opportunity to suspend the PHY device
(conversely resume it) if WoL is not enabled on this device.
Thanks!
> ---
> This is v2 of the series "[PATCH 0/2] net: Fix crashes due to activity
> during suspend", which degenerated into a single patch after commit
> ebc8254aeae34226 ("Revert "net: phy: Correctly process PHY_HALTED in
> phy_stop_machine()"") made "[PATCH 1/2] net: phy: Freeze PHY polling before
> suspending devices" no longer needed.
>
> v2:
> - Spelling s/quit/quiet/g.
>
> No stacktrace is provided, as the imprecise external abort is usually
> reported from an innocent looking and unrelated function like
> __loop_delay(), cpu_idle_poll(), or arch_timer_read_counter_long().
> ---
> drivers/net/ethernet/smsc/smsc911x.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/smsc/smsc911x.c
> b/drivers/net/ethernet/smsc/smsc911x.c
> index 0b6a39b003a4e188..012fb66eed8dd618 100644
> --- a/drivers/net/ethernet/smsc/smsc911x.c
> +++ b/drivers/net/ethernet/smsc/smsc911x.c
> @@ -2595,6 +2595,11 @@ static int smsc911x_suspend(struct device *dev)
> struct net_device *ndev = dev_get_drvdata(dev);
> struct smsc911x_data *pdata = netdev_priv(ndev);
>
> + if (netif_running(ndev)) {
> + netif_stop_queue(ndev);
> + netif_device_detach(ndev);
> + }
> +
> /* enable wake on LAN, energy detection and the external PME
>* signal. */
> smsc911x_reg_write(pdata, PMT_CTRL,
> @@ -2628,7 +2633,15 @@ static int smsc911x_resume(struct device *dev)
> while (!(smsc911x_reg_read(pdata, PMT_CTRL) & PMT_CTRL_READY_) && --to)
> udelay(1000);
>
> - return (to == 0) ? -EIO : 0;
> + if (to == 0)
> + return -EIO;
> +
> + if (netif_running(ndev)) {
> + netif_device_attach(ndev);
> + netif_start_queue(ndev);
> + }
> +
> + return 0;
> }
>
> static const struct dev_pm_ops smsc911x_pm_ops = {
>
--
Florian
Re: [PATCH] add SERIO_WIPO
Hi Michael, On Fri, Sep 08, 2017 at 11:43:42AM +, Graichen Michael wrote: > From d4122cfe5f177198ae80d0c973eb29559c762fd3 Mon Sep 17 00:00:00 2001 > From: dev > Date: Fri, 8 Sep 2017 13:21:32 +0200 > Subject: [PATCH] add SERIO_WIPO > > --- > include/uapi/linux/serio.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/serio.h b/include/uapi/linux/serio.h > index ac217c6..fc32a0f 100644 > --- a/include/uapi/linux/serio.h > +++ b/include/uapi/linux/serio.h > @@ -1,6 +1,6 @@ > /* > * Copyright (C) 1999-2002 Vojtech Pavlik > -* > + * > * This program is free software; you can redistribute it and/or modify it > * under the terms of the GNU General Public License version 2 as published > by > * the Free Software Foundation. > @@ -81,5 +81,6 @@ > #define SERIO_EGALAX 0x3f > #define SERIO_PULSE8_CEC 0x40 > #define SERIO_RAINSHADOW_CEC 0x41 > +#define SERIO_WIPO 0x42 What will be using this new definition? > #endif /* _UAPI_SERIO_H */ > -- > 2.7.4 > Thanks. -- Dmitry
Re: [PATCH v2 1/2] include: linux: sysfs: Add __ATTR_NAMED macro
On 13 September 2017 14:58:23 GMT-07:00, Joe Perches wrote: >On Thu, 2017-09-14 at 00:43 +0300, Dan Carpenter wrote: >> He was exagerating a bit to call it a "static checker" warning... > >Not really. > >False positives and false negatives exist in just about >every static >checker. > >> It's just checkpatch.pl complaining about adding spaces around the - >> operator. > >checkpatch is a brain-damaged by design static checker. >regexes can only be sensitive to patterns, not compiled code. > >> The sysfs file has a hyphen in the middle. > >Another option would be to use an underscore instead. Userspace ABI plus it really does mean subtract. Used in description of differential channels. Most such IIO ABI is generated by the IIO core, this just comes up with corner cases of the ABI. Jonathan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH 1/2] KVM: nVMX: Fix nested #PF intends to break L1's vmlauch/vmresume
2017-09-14 5:45 GMT+08:00 Paolo Bonzini :
> On 13/09/2017 13:03, Wanpeng Li wrote:
>> From: Wanpeng Li
>>
>> [ cut here ]
>> WARNING: CPU: 4 PID: 5280 at /home/kernel/linux/arch/x86/kvm//vmx.c:11394
>> nested_vmx_vmexit+0xc2b/0xd70 [kvm_intel]
>> CPU: 4 PID: 5280 Comm: qemu-system-x86 Tainted: GW OE 4.13.0+ #17
>> RIP: 0010:nested_vmx_vmexit+0xc2b/0xd70 [kvm_intel]
>> Call Trace:
>> ? emulator_read_emulated+0x15/0x20 [kvm]
>> ? segmented_read+0xae/0xf0 [kvm]
>> vmx_inject_page_fault_nested+0x60/0x70 [kvm_intel]
>> ? vmx_inject_page_fault_nested+0x60/0x70 [kvm_intel]
>> x86_emulate_instruction+0x733/0x810 [kvm]
>> vmx_handle_exit+0x2f4/0xda0 [kvm_intel]
>> ? kvm_arch_vcpu_ioctl_run+0xd2f/0x1c60 [kvm]
>> kvm_arch_vcpu_ioctl_run+0xdab/0x1c60 [kvm]
>> ? kvm_arch_vcpu_load+0x62/0x230 [kvm]
>> kvm_vcpu_ioctl+0x340/0x700 [kvm]
>> ? kvm_vcpu_ioctl+0x340/0x700 [kvm]
>> ? __fget+0xfc/0x210
>> do_vfs_ioctl+0xa4/0x6a0
>> ? __fget+0x11d/0x210
>> SyS_ioctl+0x79/0x90
>> entry_SYSCALL_64_fastpath+0x23/0xc2
>>
>> A nested #PF is triggered during L0 emulating instruction for L2. However, it
>> doesn't consider we should not break L1's vmlauch/vmresme. This patch fixes
>> it by queuing the #PF exception instead ,requesting an immediate VM exit from
>> L2 and keeping the exception for L1 pending for a subsequent nested VM exit.
>>
>> Cc: Paolo Bonzini
>> Cc: Radim Krčmář
>> Signed-off-by: Wanpeng Li
>> ---
>> arch/x86/kvm/vmx.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index 4253ade..fda9dd6 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -9829,7 +9829,8 @@ static void vmx_inject_page_fault_nested(struct
>> kvm_vcpu *vcpu,
>>
>> WARN_ON(!is_guest_mode(vcpu));
>>
>> - if (nested_vmx_is_page_fault_vmexit(vmcs12, fault->error_code)) {
>> + if (nested_vmx_is_page_fault_vmexit(vmcs12, fault->error_code) &&
>> + !to_vmx(vcpu)->nested.nested_run_pending) {
>> vmcs12->vm_exit_intr_error_code = fault->error_code;
>> nested_vmx_vmexit(vcpu, EXIT_REASON_EXCEPTION_NMI,
>> PF_VECTOR | INTR_TYPE_HARD_EXCEPTION |
>>
>
> Is vmx_inject_page_fault_nested even needed at all these days?
>
> kvm_inject_page_fault's call to kvm_queue_exception_e should transform
> into an L2->L1 vmexit when vmx_check_nested_events is called.
I saw L0 reboot/hang after do something like below:
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4253ade..96b4f6f 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -9822,24 +9822,6 @@ static bool
nested_vmx_is_page_fault_vmexit(struct vmcs12 *vmcs12,
return inequality ^ bit;
}
-static void vmx_inject_page_fault_nested(struct kvm_vcpu *vcpu,
- struct x86_exception *fault)
-{
- struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
-
- WARN_ON(!is_guest_mode(vcpu));
-
- if (nested_vmx_is_page_fault_vmexit(vmcs12, fault->error_code)) {
- vmcs12->vm_exit_intr_error_code = fault->error_code;
- nested_vmx_vmexit(vcpu, EXIT_REASON_EXCEPTION_NMI,
- PF_VECTOR | INTR_TYPE_HARD_EXCEPTION |
- INTR_INFO_DELIVER_CODE_MASK |
INTR_INFO_VALID_MASK,
- fault->address);
- } else {
- kvm_inject_page_fault(vcpu, fault);
- }
-}
-
static inline bool nested_vmx_merge_msr_bitmap(struct kvm_vcpu *vcpu,
struct vmcs12 *vmcs12);
@@ -10654,7 +10636,7 @@ static int prepare_vmcs02(struct kvm_vcpu
*vcpu, struct vmcs12 *vmcs12,
return 1;
if (!enable_ept)
- vcpu->arch.walk_mmu->inject_page_fault =
vmx_inject_page_fault_nested;
+ vcpu->arch.walk_mmu->inject_page_fault = kvm_inject_page_fault;
/*
Regards,
Wanpeng Li
Re: [PATCH v2 1/2] include: linux: sysfs: Add __ATTR_NAMED macro
On 13 September 2017 12:23:31 GMT-07:00, Lars-Peter Clausen
wrote:
>On 09/13/2017 08:58 PM, Greg KH wrote:
>> On Wed, Sep 13, 2017 at 06:03:10PM +0100, Jonathan Cameron wrote:
>>> On Wed, 13 Sep 2017 14:14:07 +0530
>>> Himanshi Jain wrote:
>>>
Add __ATTR_NAMED macro similar to __ATTR but taking name as a
string instead of implicit conversion of argument to string using
the macro _stringify(_name).
Signed-off-by: Himanshi Jain
---
include/linux/sysfs.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index aa02c32..20321cf 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -104,6 +104,13 @@ struct attribute_group {
.store = _store, \
}
+#define __ATTR_NAMED(_name, _mode, _show, _store) {
\
>>>
>>> I'm not sure about the naming here. The normal __ATTR macro is also
>>> 'named'. Maybe something as awful as
>>>
>>> __ATTR_STRING_NAME ?
>>>
>>> Greg what do you think?
>>
>> ick ick ick.
>>
>>> This is all to allow us to have names with operators in them without
>>> checkpatch complaining about them... A worthwhile aim just to stop
>>> more people wasting time trying to 'fix' those cases by adding
>spaces.
>>
>> Yeah, but this really seems "heavy" for just a crazy sysfs name in a
>> macro. Adding a whole new "core" define for that is a hard sell...
>>
>> I also want to get rid of the "generic" __ATTR type macros, and force
>> people to use the proper _RW and friends instead. I don't want to
>add
>> another new one that people will start to use that I later have to
>> change...
>>
>> So no, I don't like this, how about just changing your macros
>instead?
>> No one else has this problem :)
>
>Nobody else realized they have this problem yet. E.g. there are a few
>users
>of __ATTR in block/genhd.c that have the same issue and are likely to
>generate the same false positives from static checkers.
For IIO there is the option of moving these over to the core generated
available callbacks, but
that won't work in every case and is a more major change. I need to shift a
few more drivers
over to the available callbacks and see how well it works out. Might find time
to do one in a
gap between interesting talks this afternoon...
If I am feeling really keen I might write this missing docs I promised a while
back on that stuff. Jet lag dependant...
Jonathan
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [PATCH] tpm/tpm_crb: Use start method value from ACPI table directly
On Wed, Sep 13, 2017 at 03:33:51PM -0500, anjia...@codeaurora.org wrote:
> On 2017-09-06 07:39, Jarkko Sakkinen wrote:
> > On Fri, Aug 25, 2017 at 06:28:55PM -0500, Jiandi An wrote:
> > > This patch gets rid of dealing with intermediate flag for start method
> > > and use start method value from ACPI table directly.
> > >
> > > For ARM64, the locality is handled by Trust Zone in FW. The layout
> > > does not have crb_regs_head. It is hitting the following line.
> > > dev_warn(dev, FW_BUG "Bad ACPI memory layout");
> > >
> > > Current code excludes CRB_FL_ACPI_START for this check. Now since
> > > ARM64 support for TPM CRB is added, CRB_FL_CRB_SMC_START should also
> > > be
> > > excluded from this check.
> > >
> > > For goIdle and cmdReady where code was excluding CRB_FL_ACPI_START
> > > only
> > > (do nothing for ACPI start method), CRB_FL_CRB_SMC_START was also
> > > excluded as ARM64 SMC start method does not have TPM_CRB_CTRL_REQ.
> > >
> > > However with special PPT workaround requiring CRB_FL_CRB_START to be
> > > set in addition to CRB_FL_ACPI_START and the addition flag of SMC
> > > start method CRB_FL_CRB_SMC_START, the code has become difficult to
> > > maintain and undrestand. It is better to make code deal with start
> > > method value from ACPI table directly.
> > >
> > > Signed-off-by: Jiandi An
> > > ---
> > > drivers/char/tpm/tpm_crb.c | 59
> > > +++---
> > > 1 file changed, 29 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> > > index 8f0a98d..7b3c2a8 100644
> > > --- a/drivers/char/tpm/tpm_crb.c
> > > +++ b/drivers/char/tpm/tpm_crb.c
> > > @@ -92,14 +92,9 @@ enum crb_status {
> > > CRB_DRV_STS_COMPLETE= BIT(0),
> > > };
> > >
> > > -enum crb_flags {
> > > - CRB_FL_ACPI_START = BIT(0),
> > > - CRB_FL_CRB_START= BIT(1),
> > > - CRB_FL_CRB_SMC_START= BIT(2),
> > > -};
> > > -
> > > struct crb_priv {
> > > - unsigned int flags;
> > > + u32 sm;
> > > + const char *hid;
> > > void __iomem *iobase;
> > > struct crb_regs_head __iomem *regs_h;
> > > struct crb_regs_tail __iomem *regs_t;
> > > @@ -128,14 +123,16 @@ struct tpm2_crb_smc {
> > > * Anyhow, we do not wait here as a consequent CMD_READY request
> > > * will be handled correctly even if idle was not completed.
> > > *
> > > - * The function does nothing for devices with ACPI-start method.
> > > + * The function does nothing for devices with ACPI-start method
> > > + * or SMC-start method.
> > > *
> > > * Return: 0 always
> > > */
> > > static int __maybe_unused crb_go_idle(struct device *dev, struct
> > > crb_priv *priv)
> > > {
> > > - if ((priv->flags & CRB_FL_ACPI_START) ||
> > > - (priv->flags & CRB_FL_CRB_SMC_START))
> > > + if ((priv->sm == ACPI_TPM2_START_METHOD) ||
> > > + (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_START_METHOD) ||
> > > + (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_ARM_SMC))
> > > return 0;
> > >
> > > iowrite32(CRB_CTRL_REQ_GO_IDLE, &priv->regs_t->ctrl_req);
> > > @@ -174,14 +171,16 @@ static bool crb_wait_for_reg_32(u32 __iomem
> > > *reg, u32 mask, u32 value,
> > > * The device should respond within TIMEOUT_C.
> > > *
> > > * The function does nothing for devices with ACPI-start method
> > > + * or SMC-start method.
> > > *
> > > * Return: 0 on success -ETIME on timeout;
> > > */
> > > static int __maybe_unused crb_cmd_ready(struct device *dev,
> > > struct crb_priv *priv)
> > > {
> > > - if ((priv->flags & CRB_FL_ACPI_START) ||
> > > - (priv->flags & CRB_FL_CRB_SMC_START))
> > > + if ((priv->sm == ACPI_TPM2_START_METHOD) ||
> > > + (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_START_METHOD) ||
> > > + (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_ARM_SMC))
> > > return 0;
> > >
> > > iowrite32(CRB_CTRL_REQ_CMD_READY, &priv->regs_t->ctrl_req);
> > > @@ -325,13 +324,20 @@ static int crb_send(struct tpm_chip *chip, u8
> > > *buf, size_t len)
> > > /* Make sure that cmd is populated before issuing start. */
> > > wmb();
> > >
> > > - if (priv->flags & CRB_FL_CRB_START)
> > > + /* The reason for the extra quirk is that the PTT in 4th Gen Core
> > > CPUs
> > > + * report only ACPI start but in practice seems to require both
> > > + * CRB start, hence invoking CRB start method if hid == MSFT0101.
> > > + */
> > > + if ((priv->sm == ACPI_TPM2_COMMAND_BUFFER) ||
> > > + (priv->sm == ACPI_TPM2_MEMORY_MAPPED) ||
> > > + (!strcmp(priv->hid, "MSFT0101")))
> > > iowrite32(CRB_START_INVOKE, &priv->regs_t->ctrl_start);
> > >
> > > - if (priv->flags & CRB_FL_ACPI_START)
> > > + if ((priv->sm == ACPI_TPM2_START_METHOD) ||
> > > + (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_START_METHOD))
> > > rc = crb_do_acpi_start(chip);
> > >
> > > - if (priv->flags & CRB_FL_CRB_SMC_START) {
> > > + if (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_ARM_
Re: [PATCH v2 1/4] tpm: ignore burstcount to improve tpm_tis send() performance.
On Wed, Sep 13, 2017 at 11:39:03AM -0700, Peter Huewe wrote:
>
>
> Am 12. September 2017 17:45:08 GMT-07:00 schrieb Jarkko Sakkinen
> :
> >On Wed, Sep 06, 2017 at 08:56:36AM -0400, Nayna Jain wrote:
> >> The TPM burstcount status indicates the number of bytes that can
> >> be sent to the TPM without causing bus wait states. Effectively,
> >> it is the number of empty bytes in the command FIFO. Further,
> >> some TPMs have a static burstcount, when the value remains zero
> >> until the entire FIFO is empty.
> >>
> >> This patch adds an optimization to check for burstcount only once.
> >> And if it is valid, it writes all the bytes at once, permitting
> >> wait states. The performance of a 34 byte extend on a TPM 1.2 with
> >> an 8 byte burstcount improved from 41 msec to 14 msec.
> >>
> >> This functionality is enabled only by passing module
> >> parameter ignore_burst_count=1. By default, this parameter
> >> is disabled.
> >>
> >> After this change, performance on a TPM 1.2 with an 8 byte
> >> burstcount for 1000 extends improved from ~41sec to ~14sec.
> >>
> >> Suggested-by: Ken Goldman in
> >> conjunction with the TPM Device Driver work group.
> >> Signed-off-by: Nayna Jain
> >> Acked-by: Mimi Zohar
> >> ---
> >> Documentation/admin-guide/kernel-parameters.txt | 8
> >> drivers/char/tpm/tpm_tis_core.c | 24
> >+---
> >> 2 files changed, 29 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> >b/Documentation/admin-guide/kernel-parameters.txt
> >> index 4e303be83df6..3c59bb91e1ee 100644
> >> --- a/Documentation/admin-guide/kernel-parameters.txt
> >> +++ b/Documentation/admin-guide/kernel-parameters.txt
> >> @@ -1465,6 +1465,14 @@
> >>mode generally follows that for the NaN encoding,
> >>except where unsupported by hardware.
> >>
> >> + ignore_burst_count [TPM_TIS_CORE]
> >> + tpm_tis_core driver queries for the burstcount before
> >> + every send call in a loop. However, it causes delay to
> >> + the send command for TPMs with low burstcount value.
> >> + Setting this value to 1, will make driver to query for
> >> + burstcount only once in the loop to improve the
> >> + performance. By default, its value is set to 0.
> >> +
> >>ignore_loglevel [KNL]
> >>Ignore loglevel setting - this will print /all/
> >>kernel messages to the console. Useful for debugging.
> >> diff --git a/drivers/char/tpm/tpm_tis_core.c
> >b/drivers/char/tpm/tpm_tis_core.c
> >> index 63bc6c3b949e..6b9bf4c4d434 100644
> >> --- a/drivers/char/tpm/tpm_tis_core.c
> >> +++ b/drivers/char/tpm/tpm_tis_core.c
> >> @@ -31,6 +31,11 @@
> >> #include "tpm.h"
> >> #include "tpm_tis_core.h"
> >>
> >> +static bool ignore_burst_count = false;
> >> +module_param(ignore_burst_count, bool, 0444);
> >> +MODULE_PARM_DESC(ignore_burst_count,
> >> + "Ignore burstcount value while writing data");
> >> +
> >> /* Before we attempt to access the TPM we must see that the valid
> >bit is set.
> >> * The specification says that this bit is 0 at reset and remains 0
> >until the
> >> * 'TPM has gone through its self test and initialization and has
> >established
> >> @@ -256,6 +261,7 @@ static int tpm_tis_send_data(struct tpm_chip
> >*chip, u8 *buf, size_t len)
> >> {
> >>struct tpm_tis_data *priv = dev_get_drvdata(&chip->dev);
> >>int rc, status, burstcnt;
> >> + int sendcnt;
> >>size_t count = 0;
> >>bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND;
> >>
> >> @@ -271,19 +277,31 @@ static int tpm_tis_send_data(struct tpm_chip
> >*chip, u8 *buf, size_t len)
> >>}
> >>
> >>while (count < len - 1) {
> >> +
> >> + /*
> >> + * Get the initial burstcount to ensure TPM is ready to
> >> + * accept data, even when waiting for burstcount is disabled.
> >> + */
> >>burstcnt = get_burstcount(chip);
> >>if (burstcnt < 0) {
> >>dev_err(&chip->dev, "Unable to read burstcount\n");
> >>rc = burstcnt;
> >>goto out_err;
> >>}
> >> - burstcnt = min_t(int, burstcnt, len - count - 1);
> >> +
> >> + if (ignore_burst_count)
> >> + sendcnt = len - 1;
> >> + else
> >> + sendcnt = min_t(int, burstcnt, len - count - 1);
> >> +
> >>rc = tpm_tis_write_bytes(priv, TPM_DATA_FIFO(priv->locality),
> >> - burstcnt, buf + count);
> >> + sendcnt, buf + count);
> >>if (rc < 0)
> >>goto out_err;
> >>
> >> - count += burstcnt;
> >> + count += sendcnt;
> >> + if (ignore_burst_count)
> >> + continue;
> >>
> >>
