Re: [PATCH v3] mm: add mremap flag for preserving the old mapping
On Mon, Sep 29, 2014 at 9:55 PM, Daniel Micay wrote: > This introduces the MREMAP_RETAIN flag for preserving the source mapping > when MREMAP_MAYMOVE moves the pages to a new destination. Accesses to > the source location will fault and cause fresh pages to be mapped in. > > For consistency, the old_len >= new_len case could decommit the pages > instead of unmapping. However, userspace can accomplish the same thing > via madvise and a coherent definition of the flag is possible without > the extra complexity. IMO this needs very clear documentation of exactly what it does. Does it preserve the contents of the source pages? (If so, why? Aren't you wasting a bunch of time on page faults and possibly unnecessary COWs?) Does it work on file mappings? Can it extend file mappings while it moves them? If you MREMAP_RETAIN a partially COWed private mapping, what happens? Does it work on special mappings? If so, please prevent it from doing so. mremapping x86's vdso is a thing, and duplicating x86's vdso should not become a thing, because x86_32 in particular will become extremely confused. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 29/38] Introduce dev_printk_string() and dev_printk_header()
On 09/29/2014 06:58 PM, Greg Kroah-Hartman wrote: On Mon, Sep 29, 2014 at 01:58:58PM +0200, Hannes Reinecke wrote: Introducing dev_printk_string() and dev_printk_header() to allow using an external buffer for printing via dev_printk(). Cc: Greg Kroah-Hartman Cc: Steven Rostedt Cc: LKML Signed-off-by: Hannes Reinecke --- drivers/base/core.c| 24 include/linux/device.h | 12 2 files changed, 36 insertions(+) I don't understand, what are you trying to do with this? I don't see any follow-on patches that use this, nor can I find a 00/38 patch for this series... Well, I've copied lkml only for the generic interface changes. The main bulk of patches have been posted to linux-scsi. But it seems I should have posted all of them to lkml, too. As I'll have to redo the patchset anyway as Steven Rostedt isn't so sure about his seq_buf patches I'll be posting the next series to both, lkml and linux-scsi. Or do you prefer to keep the printk() patches as a separate patchset and have the scsi fixes on top of that? Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: checkpatch: CHECK: No space is necessary after a cast
Joe Perches writes:
> On Mon, 2014-09-29 at 14:49 +0300, Kalle Valo wrote:
>> Hi Joe,
>>
>> I have a problem with checkpatch. On ath10k we have this function:
>>
>> static inline struct ath10k_skb_cb *ATH10K_SKB_CB(struct sk_buff *skb)
>> {
>> BUILD_BUG_ON(sizeof(struct ath10k_skb_cb) >
>> IEEE80211_TX_INFO_DRIVER_DATA_SIZE);
>> return (struct ath10k_skb_cb *)_SKB_CB(skb)->driver_data;
>> }
>>
>> And the BUILD_BUG_ON triggers this warning:
>>
>> drivers/net/wireless/ath/ath10k/core.h:85: CHECK: No space is necessary
>> after a cast
>>
>> Any advice how to handle that?
>
> It's a checkpatch false positive that could be fixed.
>
> It needs something like another test to look for
> sizeof(type) as not a cast and more arithmetic/comparison
> uses.
>
> Maybe you can test this?
It works, thank you!
Tested-by: Kalle Valo
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/6] drivers: uio: Add X-Gene QMTM UIO driver
On Tue, Sep 30, 2014 at 09:56:07AM +0530, Ankit Jindal wrote:
> The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
> and Traffic manager) which is hardware based Queue or Ring
> manager. This QMTM device can be used in conjunction with
> other devices such as DMA Engine, Ethernet, Security Engine,
> etc to assign work based on queues or rings.
>
> This patch allows user space access to X-Gene QMTM device.
>
> Signed-off-by: Ankit Jindal
> Signed-off-by: Tushar Jagad
> ---
> drivers/uio/Kconfig |8 ++
> drivers/uio/Makefile |1 +
> drivers/uio/uio_xgene_qmtm.c | 278
> ++
> 3 files changed, 287 insertions(+)
> create mode 100644 drivers/uio/uio_xgene_qmtm.c
>
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index 5a90914..76b1858 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -135,4 +135,12 @@ config UIO_MF624
>
> If you compile this as a module, it will be called uio_mf624.
>
> +config UIO_XGENE_QMTM
> + tristate "Applied Micro X-Gene QMTM driver"
> + depends on OF
> + help
> + Userspace I/O interface for the X-Gene QMTM. The userspace part of
> + this driver will be available for download from the Applied Micro
> + web site (http://www.apm.com/).
> +
> endif
> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> index d3218bd..633eaa0 100644
> --- a/drivers/uio/Makefile
> +++ b/drivers/uio/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_UIO_PCI_GENERIC) += uio_pci_generic.o
> obj-$(CONFIG_UIO_NETX) += uio_netx.o
> obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
> obj-$(CONFIG_UIO_MF624) += uio_mf624.o
> +obj-$(CONFIG_UIO_XGENE_QMTM) += uio_xgene_qmtm.o
> diff --git a/drivers/uio/uio_xgene_qmtm.c b/drivers/uio/uio_xgene_qmtm.c
> new file mode 100644
> index 000..36d9000
> --- /dev/null
> +++ b/drivers/uio/uio_xgene_qmtm.c
> @@ -0,0 +1,278 @@
> +/*
> + * X-Gene Queue Manager Traffic Manager (QMTM) UIO driver (uio_xgene_qmtm)
> + *
> + * This driver exports QMTM CSRs, Fabric and memory for queues to user-space
> + *
> + * Copyright (C) 2014 Applied Micro - http://www.apm.com/
> + * Copyright (C) 2014 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; 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
> +#include
> +#include
> +
> +#define DRV_NAME "qmtm_uio"
> +#define DRV_VERSION "1.0"
> +
> +#define QMTM_CFG_MEM_RAM_SHUTDOWN0xd070
> +
> +#define QMTM_DEFAULT_QSIZE 65536
> +
> +struct uio_qmtm_dev {
> + struct uio_info *info;
> + struct clk *qmtm_clk;
> +};
> +
> +/* QMTM CSR read/write routine */
> +static inline void qmtm_csr_write(struct uio_qmtm_dev *qmtm_dev, u32 offset,
> + u32 data)
> +{
> + void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
> +
> + writel(data, addr + offset);
> +}
> +
> +static inline u32 qmtm_csr_read(struct uio_qmtm_dev *qmtm_dev, u32 offset)
> +{
> + void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
> +
> + return readl(addr + offset);
> +}
> +
> +static int qmtm_reset(struct uio_qmtm_dev *qmtm_dev)
> +{
> + u32 val;
> + int wait = 1000;
> +
> + /* reset the internal memory of the device */
> + qmtm_csr_write(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN, 0);
> +
> + /* check whether device internal memory is out of reset or not */
> + while (1) {
Seems to me that
while (wait--) {
...
}
return -EBUSY;
would be much easier to understand.
Also, not sure if EBUSY is really appropriate here.
ETIMEDOUT, maybe ?
> + val = qmtm_csr_read(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN);
> +
> + if (val != 0x)
> + return 0;
> +
> + if (!wait--)
> + return -EBUSY;
> +
> + udelay(1);
> + }
> +}
> +
> +static void qmtm_cleanup(struct platform_device *pdev,
> + struct uio_qmtm_dev *qmtm_dev)
> +{
> + struct uio_info *info = qmtm_dev->info;
> +
> + uio_unregister_device(info);
> +
> + clk_disable_unprepare(qmtm_dev->qmtm_clk);
> +}
> +
> +static int qmtm_probe(struct platform_device *pdev)
> +{
> + struct uio_info *info;
> + struct uio_qmtm_dev *qmtm_dev;
> + struct resource *csr;
> + struct resource *fabric;
> + struct resource qpool;
> + unsigned int num_queues;
> + unsigned int devid;
> + phandle qpool_phandle;
> + struct device_node
Re: [PATCH] s390: remove unused Kconfig params
Hi Heiko, On 09/27/2014 09:57 AM, Heiko Carstens wrote: > On Sat, Sep 27, 2014 at 08:25:30AM +0200, Michael Opdenacker wrote: >> Remove the below Kconfig parameters, which are no longer >> used anywhere in the source code and Makefiles: >> >> HAVE_MARCH_Z900_FEATURES >> HAVE_MARCH_Z990_FEATURES >> >> Signed-off-by: Michael Opdenacker > What I wrote you a year ago is still true: > > https://lkml.org/lkml/2013/11/4/69 Thanks for your reply. I forgot about my earlier submission, as I only keep track of patches that haven't been accepted yet. I will keep track of "hopeless" rejected patches too... There are multiple opinions about whether adding stuff not needed yet, or adding stuff only once they are needed. Anyway, as a maintainer, the decision is yours! Cheers, Michael. -- Michael Opdenacker, CEO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com +33 484 258 098 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net 1/1 V2] hyperv: Fix a bug in netvsc_start_xmit()
From: "K. Y. Srinivasan" Date: Sun, 28 Sep 2014 22:16:43 -0700 > After the packet is successfully sent, we should not touch the skb > as it may have been freed. This patch is based on the work done by > Long Li . > > In this version of the patch I have fixed issues pointed out by David. > David, please queue this up for stable. > > Signed-off-by: K. Y. Srinivasan > Tested-by: Long Li Applied and queued up for -stable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] ARM: DT: apq8064: Add usb host support.
On Mon 29 Sep 02:15 PDT 2014, Srinivas Kandagatla wrote:
> This patch adds device tree nodes to support two usb hosts on APQ8064
> SOC.
>
Sorry for not looking at the entire series before answering patch 1.
I still think you should add all the regulators in the first patch anyways.
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -263,6 +263,91 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> + pm8921_s3: pm8921-s3 {
> + compatible = "qcom,rpm-pm8921-smps";
> + reg = ;
> +
> + regulator-min-microvolt = <100>;
> + regulator-max-microvolt = <140>;
> + qcom,boot-load = <49360>;
As it was unclear how to handle load in the driver I dropped boot-load for now.
Please leave it out until someone have added it to the driver.
> + qcom,switch-mode-frequency = <320>;
> + regulator-always-on;
> + };
> +
> + pm8921_l3: pm8921-l3 {
> + compatible = "qcom,rpm-pm8921-pldo";
> + reg = ;
> +
> + regulator-min-microvolt = <305>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + qcom,boot-load = <5>;
Dito
> + };
> +
> + pm8921_l23: pm8921-l23 {
> + compatible = "qcom,rpm-pm8921-pldo";
> + reg = ;
> +
> + regulator-min-microvolt = <100>;
> + regulator-max-microvolt = <180>;
> + qcom,boot-load = <5>;
Dito
> + regulator-always-on;
Why are all these "always-on"?
> + };
> +
> + };
> +
>
> /* Temporary fixed regulator */
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ARM: DT: apq8064: add rpm support
On Mon 29 Sep 02:14 PDT 2014, Srinivas Kandagatla wrote:
> This patch adds rpm node to apq8064 dt as rpm would be used by other
> devices for regulator support.
>
> Signed-off-by: Srinivas Kandagatla
> ---
> arch/arm/boot/dts/qcom-apq8064.dtsi | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
> b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index b3154c0..9c2c8e6 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -3,6 +3,7 @@
> #include "skeleton.dtsi"
> #include
> #include
> +#include
> #include
> #include
>
> @@ -246,6 +247,24 @@
> #reset-cells = <1>;
> };
>
> + apcs: syscon@2011000 {
> + compatible = "syscon";
> + reg = <0x2011000 0x1000>;
> + };
> +
> + rpm@108000 {
> + compatible = "qcom,rpm-apq8064";
> + reg = <0x108000 0x1000>;
> + qcom,ipc = < 0x8 2>;
I don't like your indentation, but please stick with one way of doing it :)
> +
> + interrupts = <0 19 0>, <0 21 0>, <0 22 0>;
> + interrupt-names = "ack", "err", "wakeup";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
This part looks good.
But how about adding all the regulators here as well?
Like:
pm8921_l5: pm8921-l5 {
compatible = "qcom,rpm-pm8921-pldo";
reg = ;
};
...
That way we can update the references from this file (while still allowing the
dts to override it if needed). I'm not sure if we should add some sane defaults
or just completely deferr specifying the voltage ranges to the dts. The benefit
of the latter is that the regulators not configured by the dts author will not
be accessible.
But simply listing all the nodes here would be nice and I dont see much reason
to postpone this work.
> + };
> +
> /* Temporary fixed regulator */
> vsdcc_fixed: vsdcc-regulator {
> compatible = "regulator-fixed";
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] regmap: fix possible ZERO_SIZE_PTR pointer dereferencing error.
Hi, > > > diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c > > index 455a877..3d93e38 100644 > > --- a/drivers/base/regmap/regmap.c > > +++ b/drivers/base/regmap/regmap.c > > @@ -1716,6 +1716,9 @@ out: > > Whatever you're using to generate the patches isn't annotating with the > function being changed like git normally does which isn't great for > working out what the best return value should be. Yes, I will add more detail info about the return value in future of these kind patches. Thanks, BRs Xiubo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] clocksource: Update to the newer memory functions.
Use ioread{16,32} instead of read{w,l}_relaxed.
For read{w,l}_relaxed accessor, if one arch has its own defination,
then used it. Or will use the generic one, which will be read as LE
endian as default.
For some ARCHes, such PowerPC, if using the clocksource mmio, the
read{w,l}_relaxed will couldn't be used directly. There must be its
own BE accessor in its individual clocksource driver.
The ioread{16,32} will be read as LE endian as default if the arch
hasn't any defination of it too, like read{w,l}_relaxed do.
To prepare supporting the BE APIs and to be more unified with them,
using ioread{16,32}[be] is a good chioce here.
Signed-off-by: Xiubo Li
---
drivers/clocksource/mmio.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clocksource/mmio.c b/drivers/clocksource/mmio.c
index 1593ade..d3cbf70 100644
--- a/drivers/clocksource/mmio.c
+++ b/drivers/clocksource/mmio.c
@@ -22,22 +22,22 @@ static inline struct clocksource_mmio
*to_mmio_clksrc(struct clocksource *c)
cycle_t clocksource_mmio_readl_up(struct clocksource *c)
{
- return (cycle_t)readl_relaxed(to_mmio_clksrc(c)->reg);
+ return (cycle_t)ioread32(to_mmio_clksrc(c)->reg);
}
cycle_t clocksource_mmio_readl_down(struct clocksource *c)
{
- return ~(cycle_t)readl_relaxed(to_mmio_clksrc(c)->reg) & c->mask;
+ return ~(cycle_t)ioread32(to_mmio_clksrc(c)->reg) & c->mask;
}
cycle_t clocksource_mmio_readw_up(struct clocksource *c)
{
- return (cycle_t)readw_relaxed(to_mmio_clksrc(c)->reg);
+ return (cycle_t)ioread16(to_mmio_clksrc(c)->reg);
}
cycle_t clocksource_mmio_readw_down(struct clocksource *c)
{
- return ~(cycle_t)readw_relaxed(to_mmio_clksrc(c)->reg) & c->mask;
+ return ~(cycle_t)ioread16(to_mmio_clksrc(c)->reg) & c->mask;
}
/**
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] clocksource: Add BE APIs support for clocksource counter reading.
Signed-off-by: Xiubo Li
---
drivers/clocksource/mmio.c | 20
include/linux/clocksource.h | 4
2 files changed, 24 insertions(+)
diff --git a/drivers/clocksource/mmio.c b/drivers/clocksource/mmio.c
index d3cbf70..d35a407 100644
--- a/drivers/clocksource/mmio.c
+++ b/drivers/clocksource/mmio.c
@@ -20,21 +20,41 @@ static inline struct clocksource_mmio
*to_mmio_clksrc(struct clocksource *c)
return container_of(c, struct clocksource_mmio, clksrc);
}
+cycle_t clocksource_mmio_readl_up_be(struct clocksource *c)
+{
+ return (cycle_t)ioread32be(to_mmio_clksrc(c)->reg);
+}
+
cycle_t clocksource_mmio_readl_up(struct clocksource *c)
{
return (cycle_t)ioread32(to_mmio_clksrc(c)->reg);
}
+cycle_t clocksource_mmio_readl_down_be(struct clocksource *c)
+{
+ return ~(cycle_t)ioread32be(to_mmio_clksrc(c)->reg) & c->mask;
+}
+
cycle_t clocksource_mmio_readl_down(struct clocksource *c)
{
return ~(cycle_t)ioread32(to_mmio_clksrc(c)->reg) & c->mask;
}
+cycle_t clocksource_mmio_readw_up_be(struct clocksource *c)
+{
+ return (cycle_t)ioread16be(to_mmio_clksrc(c)->reg);
+}
+
cycle_t clocksource_mmio_readw_up(struct clocksource *c)
{
return (cycle_t)ioread16(to_mmio_clksrc(c)->reg);
}
+cycle_t clocksource_mmio_readw_down_be(struct clocksource *c)
+{
+ return ~(cycle_t)ioread16be(to_mmio_clksrc(c)->reg) & c->mask;
+}
+
cycle_t clocksource_mmio_readw_down(struct clocksource *c)
{
return ~(cycle_t)ioread16(to_mmio_clksrc(c)->reg) & c->mask;
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 653f0e2..931a037 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -327,9 +327,13 @@ static inline void __clocksource_updatefreq_khz(struct
clocksource *cs, u32 khz)
extern int timekeeping_notify(struct clocksource *clock);
+extern cycle_t clocksource_mmio_readl_up_be(struct clocksource *);
extern cycle_t clocksource_mmio_readl_up(struct clocksource *);
+extern cycle_t clocksource_mmio_readl_down_be(struct clocksource *);
extern cycle_t clocksource_mmio_readl_down(struct clocksource *);
+extern cycle_t clocksource_mmio_readw_up_be(struct clocksource *);
extern cycle_t clocksource_mmio_readw_up(struct clocksource *);
+extern cycle_t clocksource_mmio_readw_down_be(struct clocksource *);
extern cycle_t clocksource_mmio_readw_down(struct clocksource *);
extern int clocksource_mmio_init(void __iomem *, const char *,
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/2] clocksource: Add BE APIs support.
Change in V3:
- Provide a separate patch for using newer memory accessors.
Change in V2:
- Using ioread{16,32}[be]() instead of readl_relaxed().
- Add clocksource_mmio_readX_Y_be() supports only.
Xiubo Li (2):
clocksource: Update to the newer memory functions.
clocksource: Add BE APIs support for clocksource counter reading.
drivers/clocksource/mmio.c | 28
include/linux/clocksource.h | 4
2 files changed, 28 insertions(+), 4 deletions(-)
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PULL for 3.18] overlay filesystem v24
David Howells: > Miklos Szeredi wrote: > > > I'd like to propose overlayfs for inclusion into 3.18. > > > > Al, would you mind giving it a review? > > > > Git tree is here: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git > > overlayfs.current > > Tested-by: David Howells Does it mean overlayfs passed all your unionmount-testsuite? And does the test suite contain tests for "inode-based" union? For example, - read(2) may get the obsoleted filedata (fstat(2) for metadata too). - fcntl(F_SETLK) may be broken by copy-up. - inotify may not work when it refers to the file before being copied-up. - unnecessary copy-up may happen, for example mmap(MAP_PRIVATE) after open(O_RDWR). - exporting via NFS and fhandle systemcalls will not work. A few releases ago, OFD file-lock was introduced to improve the behaviour of POSIX lock. POSIX lock has made users confused and I am afraid that the similar story will come up because of the "name-based" union behaviour. Of course the story is not limited to the file-lock. If I remember correctly, are you the one who consitunes the development of UnionMount? Is the development totally stopped? Next paragraph is what I wrote several times. AUFS is an "inode-based" stackable filesystem and solved them many years ago. But I have to admit that AUFS is big. Yes it is grown up. I don't stop including overlayfs into mainline, but if the development of UnionMount is really stopped, then I'd ask people to consider merging aufs as well as overlayfs. http://aufs.sf.net J. R. Okajima -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ARM: DT: apq8064: add rpm support
On Mon 29 Sep 15:17 PDT 2014, Stephen Boyd wrote:
> On 09/29/14 02:14, Srinivas Kandagatla wrote:
> > @@ -246,6 +247,24 @@
> > #reset-cells = <1>;
> > };
> >
> > + apcs: syscon@2011000 {
> > + compatible = "syscon";
> > + reg = <0x2011000 0x1000>;
> > + };
>
> This is actually a clock controller block that hw designers decided was
> good place to shove the ipc bits (because there's room!). Can we call it
>
> l2cc: clock-controller@2011000 {
> compatible = "syscon";
> reg = <0x2011000 0x1000>;
> };
>
> Eventually I'll add the specific krait compatible when we merge krait
> clock support:
>
> l2cc: clock-controller@2011000 {
> compatible = "qcom,kpss-gcc", "syscon";
> reg = <0x2011000 0x1000>;
> clock-output-names = "acpu_l2_aux";
> };
>
As long as we can get hold of the regmap that would be fine. I pressume the
idea is to have the kpss-gcc using syscon, just like the rpm. But hopefully the
syscon patches that are floating around (merged?) will allow any driver to
expose a "syscon regmap".
> > +
> > + rpm@108000 {
> > + compatible = "qcom,rpm-apq8064";
> > + reg = <0x108000 0x1000>;
> > + qcom,ipc = < 0x8 2>;
>
> There are actually 3 ipc bits. I guess if we ever have to use the other
> two we'll extend this binding to have the other bits specified some
> other way?
I haven't seen any indications of us using more than this bit. If we want to do
that, we could simply make it < 8 2 8 3 8 4> (or whatever
those indices are). That way this should be easy it keep compatible.
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix getsockopt(SO_PEERNAME) buffer size against potential future buffer overflow
From: Samuel Thibault Date: Sun, 28 Sep 2014 15:55:45 +0200 > In net/core/sock.c's sock_getsockopt, the address buffer size is > hardcoded to 128. It happens that sizeof(struct sockaddr_storage) is > indeed 128, but that is just luck and would probably not get updated > whenever sockaddr_storage would grow. This patch makes it simply use > sockaddr_storage instead. > > Signed-off-by: Samuel Thibault sockaddr_storage's size is a user exported API and therefore can never, ever, change. If you want to change 128 to _K_SS_MAXSIZE or similar, fine. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] drivers/rtc/rtc-snvs: Add clock support
>> This patch adds clock enable and disable support
>> for the SNVS peripheral which is required by the
>> SNVS RTC.
>>
>> Signed-off-by: Sanchayan Maity
>> ---
>> drivers/rtc/rtc-snvs.c | 48
>> +++-
>> 1 file changed, 39 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-snvs.c b/drivers/rtc/rtc-snvs.c
>> index fa384fe..f3e8f05 100644
>> --- a/drivers/rtc/rtc-snvs.c
>> +++ b/drivers/rtc/rtc-snvs.c
>> @@ -17,6 +17,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> /* These register offsets are relative to LP (Low Power) range */
>> #define SNVS_LPCR 0x04
>> @@ -39,6 +40,7 @@ struct snvs_rtc_data {
>> void __iomem *ioaddr;
>> int irq;
>> spinlock_t lock;
>> +struct clk *clk;
>> };
>>
>> static u32 rtc_read_lp_counter(void __iomem *ioaddr)
>> @@ -260,8 +262,31 @@ static int snvs_rtc_probe(struct platform_device *pdev)
>> if (data->irq < 0)
>> return data->irq;
>>
>> +ret = devm_request_irq(>dev, data->irq, snvs_rtc_irq_handler,
>> + IRQF_SHARED, "rtc alarm", >dev);
>> +if (ret) {
>> +dev_err(>dev, "failed to request irq %d: %d\n",
>> +data->irq, ret);
>> +return ret;
>> +}
>> +
>> +data->clk = devm_clk_get(>dev, "snvs");
>> +if (IS_ERR(data->clk)) {
>> +dev_err(>dev, "failed getting clock, err = %ld\n",
>> +PTR_ERR(data->clk));
>> +ret = PTR_ERR(data->clk);
>> +return ret;
>> +}
>> +
>> platform_set_drvdata(pdev, data);
>>
>> +ret = clk_prepare_enable(data->clk);
>> +if (ret) {
>> +dev_err(>dev,
>> +"Could not prepare or enable the snvs clock\n");
>> +return ret;
>> +}
>> +
>> spin_lock_init(>lock);
>>
>> /* Initialize glitch detect */
>> @@ -275,23 +300,20 @@ static int snvs_rtc_probe(struct platform_device *pdev)
>>
>> device_init_wakeup(>dev, true);
>>
>> -ret = devm_request_irq(>dev, data->irq, snvs_rtc_irq_handler,
>> - IRQF_SHARED, "rtc alarm", >dev);
>> -if (ret) {
>> -dev_err(>dev, "failed to request irq %d: %d\n",
>> -data->irq, ret);
>> -return ret;
>> -}
>> -
>
> Is there a reason why you moved the irq request before enabling/getting
> the clocks? AFAIK the irq is quite independent from the clock of that
> IP, so you could that leave here. Try to make as few changes to the code
> as possible to archive your goal.
Ok. Will fix this, if the patch gets accepted in some form. Seems separating the
patch for SNVS node addition to the VF610 dts will be better.
>
>> data->rtc = devm_rtc_device_register(>dev, pdev->name,
>> _rtc_ops, THIS_MODULE);
>> if (IS_ERR(data->rtc)) {
>> ret = PTR_ERR(data->rtc);
>> dev_err(>dev, "failed to register rtc: %d\n", ret);
>> -return ret;
>> +goto error_rtc_device_register;
>> }
>>
>> return 0;
>> +
>> +error_rtc_device_register:
>> +clk_disable_unprepare(data->clk);
>> +
>> +return ret;
>> }
>>
>> #ifdef CONFIG_PM_SLEEP
>> @@ -302,16 +324,24 @@ static int snvs_rtc_suspend(struct device *dev)
>> if (device_may_wakeup(dev))
>> enable_irq_wake(data->irq);
>>
>> +clk_disable_unprepare(data->clk);
>> +
>> return 0;
>> }
>>
>> static int snvs_rtc_resume(struct device *dev)
>> {
>> +int ret;
>> +
>> struct snvs_rtc_data *data = dev_get_drvdata(dev);
>>
>> if (device_may_wakeup(dev))
>> disable_irq_wake(data->irq);
>>
>> +ret = clk_prepare_enable(data->clk);
>> +if (ret)
>> +return ret;
>> +
>> return 0;
>> }
>> #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] mm: add mremap flag for preserving the old mapping
This introduces the MREMAP_RETAIN flag for preserving the source mapping
when MREMAP_MAYMOVE moves the pages to a new destination. Accesses to
the source location will fault and cause fresh pages to be mapped in.
For consistency, the old_len >= new_len case could decommit the pages
instead of unmapping. However, userspace can accomplish the same thing
via madvise and a coherent definition of the flag is possible without
the extra complexity.
Motivation:
TCMalloc and jemalloc avoid releasing virtual memory in order to reduce
virtual memory fragmentation. A call to munmap or mremap would leave a
hole in the address space. Instead, unused pages are lazily returned to
the operating system via MADV_DONTNEED.
Since mremap cannot be used to elide copies, TCMalloc and jemalloc end
up being significantly slower for patterns like repeated vector / hash
table reallocations. Consider the typical vector building pattern:
#include
#include
int main(void) {
void *ptr = NULL;
size_t old_size = 0;
for (size_t size = 4; size < (1 << 30); size *= 2) {
ptr = realloc(ptr, size);
if (!ptr) return 1;
memset(ptr + old_size, 0xff, size - old_size);
old_size = size;
}
}
glibc (baseline, uses mremap already): 0.135s
jemalloc without MREMAP_RETAIN: 0.226s
jemalloc with MREMAP_RETAIN: 0.112s
TCMalloc without MREMAP_RETAIN: 0.238s
(the improvement should be similar to jemalloc)
In practice, in-place growth never occurs because the heap grows in the
downwards direction for all 3 allocators. TCMalloc and jemalloc pay for
enormous copies while glibc is only spending time writing new elements
to the vector. Even if it was grown in the other direction, real-world
applications would end up blocking in-place growth with new allocations.
The allocators could attempt to map the source location again after an
mremap call, but there is no guarantee of success in a multi-threaded
program and fragmentating memory over time is considered unacceptable.
Signed-off-by: Daniel Micay
---
include/uapi/linux/mman.h | 1 +
mm/mremap.c | 39 ---
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/include/uapi/linux/mman.h b/include/uapi/linux/mman.h
index ade4acd..4e9a546 100644
--- a/include/uapi/linux/mman.h
+++ b/include/uapi/linux/mman.h
@@ -5,6 +5,7 @@
#define MREMAP_MAYMOVE 1
#define MREMAP_FIXED 2
+#define MREMAP_RETAIN 4
#define OVERCOMMIT_GUESS 0
#define OVERCOMMIT_ALWAYS 1
diff --git a/mm/mremap.c b/mm/mremap.c
index 05f1180..079334a 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -235,7 +235,8 @@ unsigned long move_page_tables(struct vm_area_struct *vma,
static unsigned long move_vma(struct vm_area_struct *vma,
unsigned long old_addr, unsigned long old_len,
- unsigned long new_len, unsigned long new_addr, bool *locked)
+ unsigned long new_len, unsigned long new_addr, bool retain,
+ bool *locked)
{
struct mm_struct *mm = vma->vm_mm;
struct vm_area_struct *new_vma;
@@ -287,15 +288,7 @@ static unsigned long move_vma(struct vm_area_struct *vma,
old_len = new_len;
old_addr = new_addr;
new_addr = -ENOMEM;
- }
-
- /* Conceal VM_ACCOUNT so old reservation is not undone */
- if (vm_flags & VM_ACCOUNT) {
- vma->vm_flags &= ~VM_ACCOUNT;
- excess = vma->vm_end - vma->vm_start - old_len;
- if (old_addr > vma->vm_start &&
- old_addr + old_len < vma->vm_end)
- split = 1;
+ retain = false;
}
/*
@@ -310,6 +303,19 @@ static unsigned long move_vma(struct vm_area_struct *vma,
hiwater_vm = mm->hiwater_vm;
vm_stat_account(mm, vma->vm_flags, vma->vm_file, new_len>>PAGE_SHIFT);
+ /* Leave the old mapping in place for MREMAP_RETAIN. */
+ if (retain)
+ goto out;
+
+ /* Conceal VM_ACCOUNT so old reservation is not undone */
+ if (vm_flags & VM_ACCOUNT) {
+ vma->vm_flags &= ~VM_ACCOUNT;
+ excess = vma->vm_end - vma->vm_start - old_len;
+ if (old_addr > vma->vm_start &&
+ old_addr + old_len < vma->vm_end)
+ split = 1;
+ }
+
if (do_munmap(mm, old_addr, old_len) < 0) {
/* OOM: unable to split vma, just get accounts right */
vm_unacct_memory(excess >> PAGE_SHIFT);
@@ -324,6 +330,7 @@ static unsigned long move_vma(struct vm_area_struct *vma,
vma->vm_next->vm_flags |= VM_ACCOUNT;
}
+out:
if (vm_flags & VM_LOCKED) {
mm->locked_vm += new_len >> PAGE_SHIFT;
*locked = true;
@@ -392,7 +399,8 @@ Eagain:
}
static unsigned long mremap_to(unsigned long addr, unsigned
Re: [PATCH v3 3/5] mm/hugetlb: fix getting refcount 0 page in hugetlb_fault()
On Mon, 15 Sep 2014, Naoya Horiguchi wrote: > When running the test which causes the race as shown in the previous patch, > we can hit the BUG "get_page() on refcount 0 page" in hugetlb_fault(). Two minor comments... > @@ -3192,22 +3208,19 @@ int hugetlb_fault(struct mm_struct *mm, struct > vm_area_struct *vma, >* Note that locking order is always pagecache_page -> page, >* so no worry about deadlock. That sentence of comment is stale and should be deleted, now that you're only doing a trylock_page(page) here. > out_mutex: > mutex_unlock(_fault_mutex_table[hash]); > + if (need_wait_lock) > + wait_on_page_locked(page); > return ret; > } It will be hard to trigger any problem from this (I guess it would need memory hotremove), but you ought really to hold a reference to page while doing a wait_on_page_locked(page). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] Documentation: Add documentation for the PCI switch PEX8xxx I2C driver
Signed-off-by: Rajat Jain Signed-off-by: Rajat Jain Signed-off-by: Guenter Roeck --- Documentation/PCI/pex8xxx_i2c.txt | 134 + 1 file changed, 134 insertions(+) create mode 100644 Documentation/PCI/pex8xxx_i2c.txt diff --git a/Documentation/PCI/pex8xxx_i2c.txt b/Documentation/PCI/pex8xxx_i2c.txt new file mode 100644 index 000..9195242 --- /dev/null +++ b/Documentation/PCI/pex8xxx_i2c.txt @@ -0,0 +1,134 @@ + +The PEX8xxx I2C Interface driver + +Rajat Jain - Sep 2014 + + +0. Why have an I2C interface to a PCIe switch? +~~ +Other than the regular PCI express interface, most modern PCIe switches (e.g. +from IDT and PLX) have an I2C based secondary interface. This interface allows +access to all the registers of the switch. Some of these registers may not even +be accessible over the regular PCI interface. Also, there are certain registers +that can be written to, using only the I2C interface and may only be read-only +using the PCI interface. + +This I2C interface is often used in designs involving these switches, and can +be used for a variety of use cases where the switch needs to be configured +independent of the PCI subsystem (and likely before PCI enumeration). Some +examples: + +* Dividing a PCIe switch into multiple "virtual" switches. Using this feature, + a switch could be connected to 2 root ports for instance, each managing its + own PCI hierarchy, and the traffic from one virtual switch does not leak into + another. + +* Managing Transparent / Non-transparent bridging, and changing them on-the-fly. + There are ports that can be converted into "Non-transparent" bridge ports. + Essentially this is used to create different domains (not visible to + software). In a dynamic distributed system, it may be desirable to change a + transparent bridge to non-transparent or vice versa, for example, to handle a + failover situation. + +* Buggy hardware / Bad EEPROM configuration. There may be cases where an errata + involving register writes need to be applied before enumerating over PCI. + Also these switches are typically attached to an EEPROM that is supposed to + initialize the switch. If that EEPROM is not present, or contains bad + initialization data, this I2C interface can be used to fix that. + +* Changing switch configuration on the fly. In a multi-homed or complex + distributed systemsystem, there may be a need to change the switch + configuration (eg. change the upstream port, or the port or lane + configuration etc) to address run time scenarios (CPU plug out etc). + +1. What devices does this driver support? +~ +PEX8xxx represents a family of PCI Express switches from the vendor PLX. +(http://www.plxtech.com/products/expresslane/switches). Currently this driver +supports the following PLX switch devices: +PEX8614 +PEX8618 +PEX8713 + +2. What does this "PEX8xxx I2C Interface driver" do? + +This driver is an I2C client driver that allows talking to the said PEX8XXX +PCIe switches over the I2C interface. In a nutshell, it currently provides: + +* API calls to read / write the PEX8xxx switch device. +* A sysfs interface, to read / write the PEX8xxx switch device. + +The API calls are self explanatory (all reads / writes are 32 bit wide, but +the argument "byte_mask" can be used to selectively mask out the bytes): + +int pex8xxx_read(struct i2c_client *client, u8 stn, u8 mode, u8 byte_mask, + u8 port, u32 reg, u32 *val); +int pex8xxx_write(struct i2c_client *client, u8 stn, u8 mode, u8 byte_mask, + u8 port, u32 reg, u32 val) + +The arguments correspond to the arguments as described in the Chapter 7 +"I2C/SMBus Slave Interface Operation" of the all the switch datasheets. +http://www.plxtech.com/products/expresslane/pex8614#technicaldocumentation +http://www.plxtech.com/products/expresslane/pex8618#technicaldocumentation +http://www.plxtech.com/products/expresslane/pex8713#technicaldocumentation + +The sysfs interface is described in the next section. + +3. The PEX8xxx I2C driver sysfs Interface +~ +The sysfs interface allows to read / write / dump the registers of any given +port of the pex8xxx switch. Note that all reads / writes are 32 bit wide. For +all pex8xxx devices, the following sysfs attributes are provided by this driver +in the directory /sys/bus/i2c/drivers/pex8xxx// + +* "port_num" (RW) - The port number whose registers are to be read / written. +* "reg_addr" (RW) - The register offset (within the port register space) that +is to be read / written. +* "reg_value"(RW) - When read, it gives the value of the
[PATCH 2/4] pci/pex8xxx: Add sysfs interface for userspace access.
Add the sysfs ABI for the I2C interface the PLX pex8xxx PCIe switch.
The ABI is documented, and a patch to "Documentation" accompanies this
patch.
Signed-off-by: Rajat Jain
Signed-off-by: Rajat Jain
Signed-off-by: Guenter Roeck
---
drivers/pci/Kconfig |4 +-
drivers/pci/pex8xxx_i2c.c | 282 -
2 files changed, 284 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 29233aa..6a2b7dd 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -122,7 +122,9 @@ config PEX8XXX_I2C
Select this if you want I2C interface support for the PLX PEX8xxx
family of PCI express switches. Currently this I2C driver supports
PEX8614, PEX8618, PEX8713 switches. It provides read / write API
- calls to talk to the switch (over I2C).
+ calls to talk to the switch (over I2C), and a sysfs interface to
+ provide the ability to debug. This is documented in
+ Documentation/PCI/pex8xxx_i2c.txt.
If built as a module, the driver will be called pex8xxx_i2c.
diff --git a/drivers/pci/pex8xxx_i2c.c b/drivers/pci/pex8xxx_i2c.c
index ab59417..e38998e 100644
--- a/drivers/pci/pex8xxx_i2c.c
+++ b/drivers/pci/pex8xxx_i2c.c
@@ -17,6 +17,8 @@
#define PCI_DEVICE_ID_PLX_8618 0x8618
#define PCI_DEVICE_ID_PLX_8713 0x8713
+#define PEX8XXX_PORT_REG_SPACE 4096
+
/* Supported devices */
enum chips { pex8614, pex8618, pex8713 };
@@ -55,8 +57,21 @@ enum chips { pex8614, pex8618, pex8713 };
struct pex8xxx_dev {
enum chips devtype;
+ u32 reg_addr;
+ u8 port_num;
+ u8 port_mode; /* PEX8713 only */
+ u8 port_stn; /* PEX8713 only */
+ struct attribute_group attr_group;
+ bool (*port_is_valid)(u8 port);
};
+static inline struct pex8xxx_dev *pex8xxx_get_drvdata(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+
+ return i2c_get_clientdata(client);
+}
+
/**
* pex8xxx_read() - Read a (32 bit) register from the PEX8xxx device.
* @client:struct i2c_client*, representing the pex8xxx device.
@@ -175,6 +190,257 @@ int pex8xxx_write(struct i2c_client *client, u8 stn, u8
mode, u8 byte_mask,
}
EXPORT_SYMBOL(pex8xxx_write);
+/*
+ * Different PCIe switch can have different port validators.
+ * Also, some switches have discontinuous port number configurations.
+ */
+static bool pex8618_port_is_valid(u8 port)
+{
+ return port <= 15;
+}
+
+static bool pex8713_port_is_valid(u8 port)
+{
+ return port <= 5 || (port >= 8 && port <= 13);
+}
+
+static bool pex8614_port_is_valid(u8 port)
+{
+ return port <= 2 ||
+ (port >= 4 && port <= 10) ||
+ port == 12 ||
+ port == 14;
+}
+
+static ssize_t port_num_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct pex8xxx_dev *pex8xxx = pex8xxx_get_drvdata(dev);
+
+ return sprintf(buf, "%d\n", pex8xxx->port_num);
+}
+static ssize_t port_num_store(struct device *dev, struct device_attribute
*attr,
+ const char *buf, size_t count)
+{
+ struct pex8xxx_dev *pex8xxx = pex8xxx_get_drvdata(dev);
+ u8 port_num;
+
+ if (kstrtou8(buf, 0, _num))
+ return -EINVAL;
+
+ if (!pex8xxx->port_is_valid(port_num))
+ return -EINVAL;
+
+ pex8xxx->port_num = port_num;
+ return count;
+}
+static DEVICE_ATTR_RW(port_num);
+
+static ssize_t port_mode_show(struct device *dev, struct device_attribute
*attr,
+ char *buf)
+{
+ struct pex8xxx_dev *pex8xxx = pex8xxx_get_drvdata(dev);
+ char *str;
+
+ switch (pex8xxx->port_mode) {
+ case MODE_TRANSPARENT:
+ str = "transparent";
+ break;
+ case MODE_NT_LINK:
+ str = "nt-link";
+ break;
+ case MODE_NT_VIRT:
+ str = "nt-virtual";
+ break;
+ case MODE_DMA:
+ str = "dma";
+ break;
+ default:
+ str = "unknown";
+ break;
+ }
+ return sprintf(buf, "%s\n", str);
+}
+static ssize_t port_mode_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct pex8xxx_dev *pex8xxx = pex8xxx_get_drvdata(dev);
+
+ if (!strcmp(buf, "transparent\n"))
+ pex8xxx->port_mode = MODE_TRANSPARENT;
+ else if (!strcmp(buf, "nt-link\n"))
+ pex8xxx->port_mode = MODE_NT_LINK;
+ else if (!strcmp(buf, "nt-virtual\n"))
+ pex8xxx->port_mode = MODE_NT_VIRT;
+ else if (!strcmp(buf, "dma\n"))
+ pex8xxx->port_mode = MODE_DMA;
+ else
+ return
linux-next: manual merge of the battery tree with the arm-soc tree
Hi Sebastian,
Today's linux-next merge of the battery tree got conflicts in
drivers/power/reset/Kconfig and drivers/power/reset/Makefile between
commit 0e545f57b708 ("power: reset: driver for the Versatile syscon
reboot") from the arm-soc tree and commit f0745f3696e8 ("power: reset:
Add restart functionality for STiH41x platforms") from the battery tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/power/reset/Kconfig
index 527a0f47ef44,a178e9c50a20..
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@@ -69,9 -59,16 +77,16 @@@ config POWER_RESET_MS
help
Power off and restart support for Qualcomm boards.
+ config POWER_RESET_LTC2952
+ bool "LTC2952 PowerPath power-off driver"
+ depends on OF_GPIO && POWER_RESET
+ help
+ This driver supports an external powerdown trigger and board power
+ down via the LTC2952. Bindings are made in the device tree.
+
config POWER_RESET_QNAP
bool "QNAP power-off driver"
- depends on OF_GPIO && POWER_RESET && PLAT_ORION
+ depends on OF_GPIO && PLAT_ORION
help
This driver supports turning off QNAP NAS devices by sending
commands to the microcontroller which controls the main power.
@@@ -92,15 -89,13 +107,21 @@@ config POWER_RESET_SUN6
help
Reboot support for the Allwinner A31 SoCs.
+ config POWER_RESET_ST
+ bool "ST restart power-off driver"
+ depends on POWER_RESET && ARCH_STI
+ help
+ Power off and reset support for STMicroelectronics boards.
+
+config POWER_RESET_VERSATILE
+ bool "ARM Versatile family reboot driver"
+ depends on ARM
+ depends on MFD_SYSCON
+ depends on OF
+ help
+Power off and restart support for ARM Versatile family of
+reference boards.
+
config POWER_RESET_VEXPRESS
bool "ARM Versatile Express power-off and reset driver"
depends on ARM || ARM64
diff --cc drivers/power/reset/Makefile
index 73221009f2bf,ab8cd348a099..
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@@ -9,7 -9,7 +11,8 @@@ obj-$(CONFIG_POWER_RESET_LTC2952) += lt
obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_SUN6I) += sun6i-reboot.o
+ obj-$(CONFIG_POWER_RESET_ST) += st-poweroff.o
+obj-$(CONFIG_POWER_RESET_VERSATILE) += arm-versatile-reboot.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
signature.asc
Description: PGP signature
[PATCH 3/4] MAINTAINERS: Add new device driver entry for PEX pex8xxx
Signed-off-by: Rajat Jain Signed-off-by: Rajat Jain Signed-off-by: Guenter Roeck --- MAINTAINERS |7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3705430..0ef7a92 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7003,6 +7003,13 @@ S: Maintained F: include/linux/personality.h F: include/uapi/linux/personality.h +PEX8XXX I2C DRIVER +M: Rajat Jain +L: linux-...@vger.kernel.org +S: Maintained +F: drivers/pci/pex8xxx_i2c.c +F: include/linux/i2c/pex8xxx_i2c.h + PHONET PROTOCOL M: Remi Denis-Courmont S: Supported -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] pci: Add I2C driver for the PLX PEX8xxx PCIe switch
Add a driver that allows talking to the I2C interface of the PLX PEX8xxx
family of PCI Express switches. More details about the need and use cases
have been described in the documentation being added as part of this
patchset.
Currently the devices supported and tested with this driver are:
PEX8614
PEX8618
PEX8713
It should be fairly straight forward to support other PLX8xxx devices,
since they use fairly similar command formats. Currently limited to
these 3 devices primarily due to lack of hardware for testing (on other
devices)..
Signed-off-by: Rajat Jain
Signed-off-by: Rajat Jain
Signed-off-by: Guenter Roeck
---
drivers/pci/Kconfig | 11 ++
drivers/pci/Makefile|2 +
drivers/pci/pex8xxx_i2c.c | 258 +++
include/linux/i2c/pex8xxx_i2c.h | 36 ++
4 files changed, 307 insertions(+)
create mode 100644 drivers/pci/pex8xxx_i2c.c
create mode 100644 include/linux/i2c/pex8xxx_i2c.h
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 893503f..29233aa 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -115,4 +115,15 @@ config PCI_LABEL
def_bool y if (DMI || ACPI)
select NLS
+config PEX8XXX_I2C
+ tristate "PLX PEX8xxx Switch I2C interface driver"
+ depends on I2C
+ help
+ Select this if you want I2C interface support for the PLX PEX8xxx
+ family of PCI express switches. Currently this I2C driver supports
+ PEX8614, PEX8618, PEX8713 switches. It provides read / write API
+ calls to talk to the switch (over I2C).
+
+ If built as a module, the driver will be called pex8xxx_i2c.
+
source "drivers/pci/host/Kconfig"
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index e04fe2d..9759947 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -63,3 +63,5 @@ ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
# PCI host controller drivers
obj-y += host/
+
+obj-$(CONFIG_PEX8XXX_I2C) += pex8xxx_i2c.o
diff --git a/drivers/pci/pex8xxx_i2c.c b/drivers/pci/pex8xxx_i2c.c
new file mode 100644
index 000..ab59417
--- /dev/null
+++ b/drivers/pci/pex8xxx_i2c.c
@@ -0,0 +1,258 @@
+/*
+ * Driver for the PEX8xxx I2C slave interface
+ *
+ * Rajat Jain
+ * Copyright 2014 Juniper Networks
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+
+#define PCI_DEVICE_ID_PLX_8614 0x8614
+#define PCI_DEVICE_ID_PLX_8618 0x8618
+#define PCI_DEVICE_ID_PLX_8713 0x8713
+
+/* Supported devices */
+enum chips { pex8614, pex8618, pex8713 };
+
+#define MAXSTN 2
+#define MAXMODE4
+
+/* Common Register defines */
+#define PEX8XXX_CMD(val) (((val) & 7) << 24)
+#define PEX8XXX_CMD_WR 0x03
+#define PEX8XXX_CMD_RD 0x04
+
+#define PEX8XXX_BYTE_ENA(val) (((val) & 0xF) << 10)
+#define PEX8XXX_REG(val) (((val) >> 2) & 0x3FF)
+
+/* PEX8614/8618 Device specific register defines */
+#define PEX861X_PORT(val) (((val) & 0x1F) << 15)
+
+#define PEX861X_I2C_CMD(cmd, port, mode, stn, reg, byte_mask) \
+ (PEX8XXX_CMD(cmd) | \
+PEX861X_PORT(port) | \
+PEX8XXX_BYTE_ENA(byte_mask) | \
+PEX8XXX_REG(reg))
+
+/* PEX8713 Device specific register defines */
+#define PEX8713_MODE(val) (((val) & 3) << 20)
+#define PEX8713_STN(val) (((val) & 3) << 18)
+#define PEX8713_PORT(val) (((val) & 7) << 15)
+
+#define PEX8713_I2C_CMD(cmd, port, mode, stn, reg, byte_mask) \
+ (PEX8XXX_CMD(cmd) | \
+PEX8713_MODE(mode) | \
+PEX8713_STN(stn) | \
+PEX8713_PORT(port) | \
+PEX8XXX_BYTE_ENA(byte_mask) | \
+PEX8XXX_REG(reg))
+
+struct pex8xxx_dev {
+ enum chips devtype;
+};
+
+/**
+ * pex8xxx_read() - Read a (32 bit) register from the PEX8xxx device.
+ * @client:struct i2c_client*, representing the pex8xxx device.
+ * @stn: Station number (Used on some PLX switches such as PEX8713 that
+ * support multi stations. Ignored on switches that don't support
+ * it)
+ * @mode: Port mode (Transparent / Non-transparent etc)
+ * @byte_mask: Byte enable mask.
+ * @port: Port number
+ * @reg: Register offset to read.
+ * @val: Pointer where the result is to be written.
+ *
+ * Return: 0 on Success, Error value otherwise.
+ */
+int pex8xxx_read(struct i2c_client *client, u8 stn, u8 mode, u8 byte_mask,
+u8 port, u32 reg, u32 *val)
+{
+ struct pex8xxx_dev *pex8xxx =
[PATCH 0/4] Driver for talking to PLX PEX8xxx PCIe switch over I2C
Most of the PLX PCI Express switches (and also switches from other vendors such IDT) provide an I2C based secondary interface to access and program the switch. This can be used to program the switch in situations where the PCIe interface may not be suitable, or even available. (For instance, we may need to program the device in a particular fashion before we even begin enumerating on the PCI, or to even enable the PCIe interface of the device). More information on usecases and other details has been provided in the documentation being added as part of this patchset. This is a driver that allows talking to the PLX PEX8xxx family of PCIe switches over its I2C interface. Here are the patch descriptions: [Patch 1/4] - Adds the PEX8xxx driver that exports API calls to read / write. [Patch 2/4] - Adds a sysfs interface, to allow access to the switch. [Patch 3/4] - Adds the MAINTAINERS entry. [Patch 4/4] - Adds the documentation in Documentation/PCI/pex8xxx_i2c.txt Since this is a driver for a PCIe switch, I currently put it under /driver/pci/. I'm very open to suggestions for moving this around (Does introducing drivers/pci/switch/ seem any better?). Especially I can see that the drivers/pci/Kconfig appears under "Bus Options" in the main menu which does not look like the right place for this driver. I am looking for suggestions here. Looking forward to comments, Thanks, Rajat Rajat Jain (4): pci: Add I2C driver for the PLX PEX8xxx PCIe switch pci/pex8xxx: Add sysfs interface for userspace access. MAINTAINERS: Add new device driver entry for PEX pex8xxx Documentation: Add documentation for the PCI switch PEX8xxx I2C driver Documentation/PCI/pex8xxx_i2c.txt | 134 + MAINTAINERS |7 + drivers/pci/Kconfig | 13 + drivers/pci/Makefile |2 + drivers/pci/pex8xxx_i2c.c | 538 + include/linux/i2c/pex8xxx_i2c.h | 36 +++ 6 files changed, 730 insertions(+) create mode 100644 Documentation/PCI/pex8xxx_i2c.txt create mode 100644 drivers/pci/pex8xxx_i2c.c create mode 100644 include/linux/i2c/pex8xxx_i2c.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/15] powerpc/cell: Move data segment faulting code out of cell platform
On Mon, 2014-09-29 at 14:00 +0530, Aneesh Kumar K.V wrote:
> Michael Neuling writes:
>
> > From: Ian Munsie
> >
> > __spu_trap_data_seg() currently contains code to determine the VSID and ESID
> > required for a particular EA and mm struct.
> >
> > This code is generically useful for other co-processors. This moves the
> > code
> > of the cell platform so it can be used by other powerpc code.
> >
> > Signed-off-by: Ian Munsie
> > Signed-off-by: Michael Neuling
> > ---
> > arch/powerpc/include/asm/mmu-hash64.h | 2 ++
> > arch/powerpc/mm/copro_fault.c | 48
> > ++
> > arch/powerpc/mm/slb.c | 3 ---
> > arch/powerpc/platforms/cell/spu_base.c | 41 +++--
> > 4 files changed, 54 insertions(+), 40 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/mmu-hash64.h
> > b/arch/powerpc/include/asm/mmu-hash64.h
> > index d765144..fd19a53 100644
> > --- a/arch/powerpc/include/asm/mmu-hash64.h
> > +++ b/arch/powerpc/include/asm/mmu-hash64.h
> > @@ -180,6 +180,8 @@ static inline unsigned int mmu_psize_to_shift(unsigned
> > int mmu_psize)
> > * we work in all cases including 4k page size.
> > */
> > #define VPN_SHIFT 12
> > +#define slb_vsid_shift(ssize) \
> > + ((ssize) == MMU_SEGSIZE_256M ? SLB_VSID_SHIFT : SLB_VSID_SHIFT_1T)
>
> can it be static inline similar to segment_shift() ?
Yep.
>
> >
> > /*
> > * HPTE Large Page (LP) details
> > diff --git a/arch/powerpc/mm/copro_fault.c b/arch/powerpc/mm/copro_fault.c
> > index ba7df14..4105a63 100644
> > --- a/arch/powerpc/mm/copro_fault.c
> > +++ b/arch/powerpc/mm/copro_fault.c
> > @@ -90,3 +90,51 @@ out_unlock:
> > return ret;
> > }
> > EXPORT_SYMBOL_GPL(copro_handle_mm_fault);
> > +
> > +int copro_data_segment(struct mm_struct *mm, u64 ea, u64 *esid, u64 *vsid)
> > +{
> > + int psize, ssize;
> > +
> > + *esid = (ea & ESID_MASK) | SLB_ESID_V;
> > +
> > + switch (REGION_ID(ea)) {
> > + case USER_REGION_ID:
> > + pr_devel("copro_data_segment: 0x%llx -- USER_REGION_ID\n", ea);
> > +#ifdef CONFIG_PPC_MM_SLICES
> > + psize = get_slice_psize(mm, ea);
> > +#else
> > + psize = mm->context.user_psize;
> > +#endif
>
> We don't need that.
>
> #ifdef CONFIG_PPC_STD_MMU_64
> #define get_slice_psize(mm, addr) ((mm)->context.user_psize)
OK
>
>
> > + ssize = user_segment_size(ea);
> > + *vsid = (get_vsid(mm->context.id, ea, ssize)
> > + << slb_vsid_shift(ssize)) | SLB_VSID_USER
> > + | (ssize == MMU_SEGSIZE_1T ? SLB_VSID_B_1T : 0);
> > + break;
> > + case VMALLOC_REGION_ID:
> > + pr_devel("copro_data_segment: 0x%llx -- VMALLOC_REGION_ID\n",
> > ea);
> > + if (ea < VMALLOC_END)
> > + psize = mmu_vmalloc_psize;
> > + else
> > + psize = mmu_io_psize;
> > + *vsid = (get_kernel_vsid(ea, mmu_kernel_ssize)
> > + << SLB_VSID_SHIFT) | SLB_VSID_KERNEL
> > + | (mmu_kernel_ssize == MMU_SEGSIZE_1T ? SLB_VSID_B_1T :
> > 0);
> > + break;
> > + case KERNEL_REGION_ID:
> > + pr_devel("copro_data_segment: 0x%llx -- KERNEL_REGION_ID\n",
> > ea);
> > + psize = mmu_linear_psize;
> > + *vsid = (get_kernel_vsid(ea, mmu_kernel_ssize)
> > + << SLB_VSID_SHIFT) | SLB_VSID_KERNEL
> > + | (mmu_kernel_ssize == MMU_SEGSIZE_1T ? SLB_VSID_B_1T :
> > 0);
> > + break;
> > + default:
> > + /* Future: support kernel segments so that drivers can use the
> > +* CoProcessors */
> > + pr_debug("invalid region access at %016llx\n", ea);
> > + return 1;
> > + }
> > + *vsid |= mmu_psize_defs[psize].sllp;
> > +
> > + return 0;
> > +}
>
> large part of this is same as what we do in hash_page. And we are not
> really updating vsid here, it is vsid slb encoding. So why not abstract
> the vsid part and use that in hash_page also ? That would have also taken
> care of the above #ifdef.
Ok, I've merge these two variants.
Going to repost this whole series again soon. I'll be in there.
Thanks for the comments.
Mikey
>
> > +EXPORT_SYMBOL_GPL(copro_data_segment);
> > diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> > index 0399a67..6e450ca 100644
> > --- a/arch/powerpc/mm/slb.c
> > +++ b/arch/powerpc/mm/slb.c
> > @@ -46,9 +46,6 @@ static inline unsigned long mk_esid_data(unsigned long
> > ea, int ssize,
> > return (ea & slb_esid_mask(ssize)) | SLB_ESID_V | slot;
> > }
> >
> > -#define slb_vsid_shift(ssize) \
> > - ((ssize) == MMU_SEGSIZE_256M? SLB_VSID_SHIFT: SLB_VSID_SHIFT_1T)
> > -
> > static inline unsigned long mk_vsid_data(unsigned long ea, int ssize,
> > unsigned long flags)
> > {
> > diff --git a/arch/powerpc/platforms/cell/spu_base.c
> >
Re: pipe/page fault oddness.
On Mon, Sep 29, 2014 at 09:27:09PM -0700, Linus Torvalds wrote:
> On Mon, Sep 29, 2014 at 8:33 PM, Dave Jones wrote:
> >
> > Looking at the dump, there's only one running trinity child,
> > with all the others blocking on it.
> >
> > trinity-c49 R running task12856 19464 7633 0x0004
> > 8800a09bf960 0002 8800a09bf9f8 88021965
> > 001d4080 8800a09bffd8 001d4080
> > 88023f755bc0 88021965 8800a09bffd8 88010b017e00
> > Call Trace:
> > [] handle_mm_fault+0x3a7/0xcd0
> > [] __do_page_fault+0x1a4/0x600
> > [] do_page_fault+0x1e/0x70
> > [] page_fault+0x22/0x30
> > [] ? copy_page_to_iter+0x3b3/0x500
> > [] pipe_read+0xdf/0x330
> >
> > Running the function tracer on that pid shows it spinning forever..
> > http://codemonkey.org.uk/junk/pipe-trace.txt
> >
> > Kernel bug (missing EFAULT check somewhere perhaps?), or is this a
> > case where the fuzzer asked the kernel to do something stupid, and it
> > obliged ?
>
> Hmm. It looks like copy_page_to_iter_iovec() is broken and keeps not
> making any progress while just faulting.
>
> I don't see how that could happen, though. All the loops there are
> conditional on the user copies *not* failing (ie "!left"), and they
> seem to properly update "iov".
>
> Mind sending a disassembly of your "copy_page_to_iter" function, in
> particular around that whole "0x3b3/0x500" area which is where the
> page fault seems to happen?
>
> Adding Al to the cc, since this code is from his commit 6e58e79db8a1
> ("introduce copy_page_to_iter, kill loop over iovec in
> generic_file_aio_read()") but I don't see anything obviously wrong
> there.
>
> Al? Do you see something I don't? Dave's function trace does seem to
> say that it doesn't even get back to pipe_read(), though, so the loop
> really must be inside copy_page_to_iter().
I'll take a look tomorrow morning after I get some sleep - 19 hours of uptime,
on top of 5 hours of sleep, on top of ~20 hours of uptime ;-/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] hwspinlock: qcom: Add support for Qualcomm HW Mutex block
From: Kumar Gala
Add driver for Qualcomm Hardware Mutex block that exists on newer
Qualcomm SoCs.
Cc: Jeffrey Hugo
Cc: Eric Holmberg
Cc: Courtney Cavin
Signed-off-by: Kumar Gala
[bjorn: added pm_runtime calls, from Courtney,
added sfpb-mutex compatible,
updated DT binding documentation formatting,
replaced msm prefix with qcom,
cleaned up includes]
Signed-off-by: Bjorn Andersson
---
We need this driver to add support for the shared memory manager, so I'm
reviving Kumars patch from a year ago, with some additional sprinkles on top.
Changes since v3:
- Reverted back to getting stride from of_match, per Kumars request
Changes since v2:
- MODULE_DEVICE_TABLE
- Changed prefix to qcom
- Cleaned up includes
- Rely on reg and num-locks to figure out stride, instead of of_match data
Changes since v1:
- Added the pm_runtime calls needed to be able to boot a kernel with
pm_runtime and this driver, patch from Courtney.
- Added sfpb-mutex compatible, for re-use of the driver in family A platforms.
- Updated formatting of DT binding documentation, while adding the extra
compatible.
- Dropped Stephen Boyds Reviewed-by due to these changes.
.../devicetree/bindings/hwlock/qcom-hwspinlock.txt | 35 +
drivers/hwspinlock/Kconfig | 11 ++
drivers/hwspinlock/Makefile|1 +
drivers/hwspinlock/qcom_hwspinlock.c | 151
4 files changed, 198 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
create mode 100644 drivers/hwspinlock/qcom_hwspinlock.c
diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
new file mode 100644
index 000..27c7c80
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
@@ -0,0 +1,35 @@
+Qualcomm Hardware Mutex Block:
+
+The hardware block provides mutexes utilized between different processors
+on the SoC as part of the communication protocol used by these processors.
+
+- compatible:
+ Usage: required
+ Value type:
+ Definition: must be one of:
+ "qcom,sfpb-mutex",
+ "qcom,tcsr-mutex"
+
+- reg:
+ Usage: required
+ Value type:
+ Definition: base address and size of the mutex registers
+
+- reg-names:
+ Usage: required
+ Value type:
+ Definition: must be "mutex-base"
+
+- qcom,num-locks:
+ Usage: required
+ Value type:
+ Definition: the number of locks/mutex available in this block
+
+Example:
+
+ hwlock@fd484000 {
+ compatible = "qcom,tcsr-mutex";
+ reg = <0xfd484000 0x1000>;
+ reg-names = "mutex-base";
+ qcom,num-locks = <32>;
+ };
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 3612cb5..af4c7e6 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -8,6 +8,17 @@ config HWSPINLOCK
menu "Hardware Spinlock drivers"
+config HWSPINLOCK_QCOM
+ tristate "Qualcomm Hardware Spinlock device"
+ depends on ARCH_QCOM
+ select HWSPINLOCK
+ help
+ Say y here to support the Qualcomm Hardware Mutex functionality, which
+ provides a synchronisation mechanism for the various processors on
+ the SoC.
+
+ If unsure, say N.
+
config HWSPINLOCK_OMAP
tristate "OMAP Hardware Spinlock device"
depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX ||
SOC_AM43XX
diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
index 93eb64b..f3bff48 100644
--- a/drivers/hwspinlock/Makefile
+++ b/drivers/hwspinlock/Makefile
@@ -3,5 +3,6 @@
#
obj-$(CONFIG_HWSPINLOCK) += hwspinlock_core.o
+obj-$(CONFIG_HWSPINLOCK_QCOM) += qcom_hwspinlock.o
obj-$(CONFIG_HWSPINLOCK_OMAP) += omap_hwspinlock.o
obj-$(CONFIG_HSEM_U8500) += u8500_hsem.o
diff --git a/drivers/hwspinlock/qcom_hwspinlock.c
b/drivers/hwspinlock/qcom_hwspinlock.c
new file mode 100644
index 000..d1b3328
--- /dev/null
+++ b/drivers/hwspinlock/qcom_hwspinlock.c
@@ -0,0 +1,151 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014, Sony Mobile Communications AB
+ *
+ * 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 "hwspinlock_internal.h"
+
+#define
Re: [resend rfc v4]pwm: add BCM2835 PWM driver
On 09/29/2014 08:40 AM, Bart Tanghe wrote:
> Add pwm driver for Broadcom BCM2835 processor (Raspberry Pi)
> Signed-off-by: Bart Tanghe
There needs to be a blank line between the description and the tags.
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt
> b/Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt
> +Required properties:
> +- compatible: should be "brcm,bcm2835-pwm"
> +- reg: physical base address and length of the controller's registers
This needs to document the clock property too.
It'd be nice to require clock-names rather than doing clock lookup by
index, but I suppose it's not too much of a problem with this device.
> diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
> +/*
> + * Copyright (C) 2014 Thomas more
But the git commit doesn't have "Thomas More" as the author, nor Thomas'
Signed-off-by line. Can you explain the history of this code?
> +static int bcm2835_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
> + u32 value;
> +
> + value = readl(pc->base) & ~(PWM_CONTROL_MASK << 8 * pwm->pwm);
> + value |= (PWM_CONTROL_ENABLE << (8 * pwm->pwm));
It'd be nice to use a #define rather than hard-coded "8" here. Perhaps:
#define PWM_CONTROL_STRIDE 8
Why does _request() enable the PWM output; shouldn't that be deferred
until _enable()? _free() might not want to disable the output, if the
PWM core guarantees that _disable() is always called.
> +static int bcm2835_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> + int duty_ns, int period_ns)
> +{
> + struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
> +
> + if (period_ns > MIN_PERIOD) {
> + writel(duty_ns / pc->scaler,
> + pc->base + DUTY + pwm->pwm * CHANNEL);
> + writel(period_ns / pc->scaler,
> + pc->base + PERIOD + pwm->pwm * CHANNEL);
> + } else {
> + dev_err(pc->dev, "Period not supported\n");
> + }
The "else" case should propagate the error. It'd be better to do the
error-checking first to remove an indent level from the rest of the code:
if (period_ns <= MIN_PERIOD) {
dev_err(...);
return -EINVAL;
}
writel(...);
> +static int bcm2835_set_polarity(struct pwm_chip *chip, struct pwm_device
> *pwm,
> + enum pwm_polarity polarity)
> +{
> + struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
> + u32 value;
> +
> + if (polarity == PWM_POLARITY_NORMAL) {
> + value = readl(pc->base);
> + value &= ~(PWM_POLARITY << 8 * pwm->pwm);
> + writel(value, pc->base);
> + } else if (polarity == PWM_POLARITY_INVERSED) {
> + value = readl(pc->base);
> + value |= PWM_POLARITY << (8 * pwm->pwm);
> + writel(value, pc->base);
> + }
If you move the readl/writel outside the if statement, you remove the
duplication of code.
> +static const struct pwm_ops bcm2835_pwm_ops = {
...
> + .owner = THIS_MODULE,
> +};
Doesn't something in the driver core automatically set .owner now?
Perhaps that's only for certain subsystems though?
> +MODULE_AUTHOR("Bart Tanghe http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/5] mm/hugetlb: take page table lock in follow_huge_pmd()
On Mon, 15 Sep 2014, Naoya Horiguchi wrote:
> We have a race condition between move_pages() and freeing hugepages,
I've been looking through these 5 today, and they're much better now,
thank you. But a new concern below, and a minor correction to 3/5.
> --- mmotm-2014-09-09-14-42.orig/mm/gup.c
> +++ mmotm-2014-09-09-14-42/mm/gup.c
> @@ -162,33 +162,16 @@ struct page *follow_page_mask(struct vm_area_struct
> *vma,
>
> pmd = pmd_offset(pud, address);
> if (pmd_none(*pmd))
> return no_page_table(vma, flags);
> - if (pmd_huge(*pmd) && vma->vm_flags & VM_HUGETLB) {
> - page = follow_huge_pmd(mm, address, pmd, flags & FOLL_WRITE);
> - if (flags & FOLL_GET) {
> - /*
> - * Refcount on tail pages are not well-defined and
> - * shouldn't be taken. The caller should handle a NULL
> - * return when trying to follow tail pages.
> - */
> - if (PageHead(page))
> - get_page(page);
> - else
> - page = NULL;
> - }
> - return page;
> - }
> + if (pmd_huge(*pmd) && vma->vm_flags & VM_HUGETLB)
> + return follow_huge_pmd(mm, address, pmd, flags);
This code here allows for pmd_none() and pmd_huge(), and for pmd_numa()
and pmd_trans_huge() below; but makes no explicit allowance for !present
migration and hwpoison entries.
Is it assumed that the pmd_bad() test in follow_page_pte() will catch
those? But what of races? migration entries are highly volatile. And
is it assumed that a migration entry cannot pass the pmd_huge() test?
That may be true of x86 today, I'm not certain; but if the soft-dirty
people catch up with the hugetlb-migration people, that might change
(they #define _PAGE_SWP_SOFT_DIRTY _PAGE_PSE).
Why pmd_huge() does not itself test for present, I cannot say; but it
probably didn't matter at all before hwpoison and migration were added.
Mind you, with __get_user_pages()'s is_vm_hugtlb_page() test avoiding
all this code, maybe the only thing that can stumble here is your own
hugetlb migration code; but that appears to be guarded only by
down_read of mmap_sem, so races would be possible (if userspace
is silly enough or malicious enough to do so).
What we have here today looks too fragile to me, but it's probably
best dealt with by a separate patch.
Or I may be over-anxious, and there may be something "obvious"
that I'm missing, which saves us from further change.
> if ((flags & FOLL_NUMA) && pmd_numa(*pmd))
> return no_page_table(vma, flags);
> if (pmd_trans_huge(*pmd)) {
> diff --git mmotm-2014-09-09-14-42.orig/mm/hugetlb.c
> mmotm-2014-09-09-14-42/mm/hugetlb.c
> index 34351251e164..941832ee3d5a 100644
> --- mmotm-2014-09-09-14-42.orig/mm/hugetlb.c
> +++ mmotm-2014-09-09-14-42/mm/hugetlb.c
> @@ -3668,26 +3668,34 @@ follow_huge_addr(struct mm_struct *mm, unsigned long
> address,
>
> struct page * __weak
> follow_huge_pmd(struct mm_struct *mm, unsigned long address,
> - pmd_t *pmd, int write)
> + pmd_t *pmd, int flags)
> {
> - struct page *page;
> + struct page *page = NULL;
> + spinlock_t *ptl;
>
> - page = pte_page(*(pte_t *)pmd);
> - if (page)
> - page += ((address & ~PMD_MASK) >> PAGE_SHIFT);
> + ptl = pmd_lockptr(mm, pmd);
> + spin_lock(ptl);
> +
> + if (!pmd_huge(*pmd))
> + goto out;
And similarly here. Though at least here we now have the necessary
lock, so it's no longer racy, and maybe this pmd_huge() test just needs
to be replaced by a pmd_present() test? Or are both needed?
> +
> + page = pte_page(*(pte_t *)pmd) + ((address & ~PMD_MASK) >> PAGE_SHIFT);
> +
> + if (flags & FOLL_GET)
> + get_page(page);
> +out:
> + spin_unlock(ptl);
> return page;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/6] uio: Add new UIO_MEM_PHYS_CACHE type for mem regions
Currently, three types of mem regions are supported: UIO_MEM_PHYS,
UIO_MEM_LOGICAL and UIO_MEM_VIRTUAL. Among these UIO_MEM_PHYS helps
UIO driver export physcial memory to user space as non-cacheable
user memory. Typcially memory-mapped registers of a device are exported
to user space as UIO_MEM_PHYS type mem region. The UIO_MEM_PHYS type
is not efficient if dma-capable devices are capable of maintaining coherency
with CPU caches.
This patch adds new type UIO_MEM_PHYS_CACHE for mem regions to enable
cacheable access to physical memory from user space.
Signed-off-by: Ankit Jindal
Signed-off-by: Tushar Jagad
---
drivers/uio/uio.c | 11 ---
include/linux/uio_driver.h |1 +
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 97e6444..120a84b 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -644,7 +644,7 @@ static const struct vm_operations_struct
uio_physical_vm_ops = {
#endif
};
-static int uio_mmap_physical(struct vm_area_struct *vma)
+static int uio_mmap_physical(struct vm_area_struct *vma, bool cacheable)
{
struct uio_device *idev = vma->vm_private_data;
int mi = uio_find_mem_index(vma);
@@ -659,7 +659,9 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
return -EINVAL;
vma->vm_ops = _physical_vm_ops;
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+
+ if (!cacheable)
+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
/*
* We cannot use the vm_iomap_memory() helper here,
@@ -707,10 +709,13 @@ static int uio_mmap(struct file *filep, struct
vm_area_struct *vma)
switch (idev->info->mem[mi].memtype) {
case UIO_MEM_PHYS:
- return uio_mmap_physical(vma);
+ return uio_mmap_physical(vma, false);
case UIO_MEM_LOGICAL:
case UIO_MEM_VIRTUAL:
return uio_mmap_logical(vma);
+ case UIO_MEM_PHYS_CACHE:
+ return uio_mmap_physical(vma, true);
+
default:
return -EINVAL;
}
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 1ad4724..40ca3f3 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -118,6 +118,7 @@ extern void uio_event_notify(struct uio_info *info);
#define UIO_MEM_PHYS 1
#define UIO_MEM_LOGICAL2
#define UIO_MEM_VIRTUAL 3
+#define UIO_MEM_PHYS_CACHE 4
/* defines for uio_port->porttype */
#define UIO_PORT_NONE 0
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pipe/page fault oddness.
On Mon, Sep 29, 2014 at 09:27:09PM -0700, Linus Torvalds wrote: > On Mon, Sep 29, 2014 at 8:33 PM, Dave Jones wrote: > > > > Looking at the dump, there's only one running trinity child, > > with all the others blocking on it. > > > > trinity-c49 R running task12856 19464 7633 0x0004 > > 8800a09bf960 0002 8800a09bf9f8 88021965 > > 001d4080 8800a09bffd8 001d4080 > > 88023f755bc0 88021965 8800a09bffd8 88010b017e00 > > Call Trace: > > [] handle_mm_fault+0x3a7/0xcd0 > > [] __do_page_fault+0x1a4/0x600 > > [] do_page_fault+0x1e/0x70 > > [] page_fault+0x22/0x30 > > [] ? copy_page_to_iter+0x3b3/0x500 > > [] pipe_read+0xdf/0x330 > > > > Running the function tracer on that pid shows it spinning forever.. > > http://codemonkey.org.uk/junk/pipe-trace.txt > > > > Kernel bug (missing EFAULT check somewhere perhaps?), or is this a > > case where the fuzzer asked the kernel to do something stupid, and it > > obliged ? > > Hmm. It looks like copy_page_to_iter_iovec() is broken and keeps not > making any progress while just faulting. > > I don't see how that could happen, though. All the loops there are > conditional on the user copies *not* failing (ie "!left"), and they > seem to properly update "iov". > > Mind sending a disassembly of your "copy_page_to_iter" function, in > particular around that whole "0x3b3/0x500" area which is where the > page fault seems to happen? Whole file is at http://codemonkey.org.uk/junk/iov_iter.txt gcc is 4.8.3 btw Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] thermal: Add QPNP PMIC temperature alarm driver
On Monday 29 September 2014 07:24 PM, Ivan T. Ivanov wrote:
> On Fri, 2014-09-26 at 16:51 +0530, Kiran Padwal wrote:
>> On Thursday 25 September 2014 07:00 PM, Ivan T. Ivanov wrote:
>>> Add support for the temperature alarm peripheral found inside
>>> Qualcomm plug-and-play (QPNP) PMIC chips. The temperature alarm
>>> peripheral outputs a pulse on an interrupt line whenever the
>>> thermal over temperature stage value changes. Implement an ISR
>>> to manage this interrupt.
>>>
>>
>>
>>
>>> + * This function updates the internal temp value based on the
>>> + * current thermal stage and threshold as well as the previous stage
>>> + */
>>> +static int qpnp_tm_update_temp_no_adc(struct qpnp_tm_chip *chip)
>>> +{
>>> + unsigned int stage;
>>> + int rc;
>>> + u8 reg;
>>> +
>>> + rc = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, );
>>> + if (rc < 0)
>>> + return rc;
>>> +
>>> + stage = reg & STATUS_STAGE_MASK;
>>
>> During compilation, getting a waring as below,
>>
>> drivers/thermal/qpnp-temp-alarm.c: In function ‘qpnp_tm_update_temp_no_adc’:
>> drivers/thermal/qpnp-temp-alarm.c:135:8: warning: ‘reg’ may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>> stage = reg & STATUS_STAGE_MASK;
>
> Could you share compiler version and options which you are using.
> I am unable to trigger this warning. Looking code I can not
> see how this could happen.
I have Linaro cross tool chain with version-4.8.3 and I am simply doing "make
zImage" without any option.
Thanks,
--Kiran
>
>>
>>> +
>>> + if (stage > chip->stage) {
>>> + /* increasing stage, use lower bound */
>>> + chip->temp = (stage - 1) * TEMP_STAGE_STEP +
>>> +chip->thresh * TEMP_THRESH_STEP +
>>> +TEMP_STAGE_HYSTERESIS + TEMP_THRESH_MIN;
>>> + } else if (stage < chip->stage) {
>>> + /* decreasing stage, use upper bound */
>>> + chip->temp = stage * TEMP_STAGE_STEP +
>>> +chip->thresh * TEMP_THRESH_STEP -
>>> +TEMP_STAGE_HYSTERESIS + TEMP_THRESH_MIN;
>>> + }
>>> +
>>> + chip->stage = stage;
>>> +
>>> + return 0;
>>> +}
>>> +
>>
>>
>>
>>> +
>>> +#define QPNP_TM_PM_OPS (_tm_pm_ops)
>>> +#else
>>> +#define QPNP_TM_PM_OPS NULL
>>> +#endif
>>> +
>>> +static struct of_device_id qpnp_tm_match_table[] = {
>>
>> It must be static const struct of_device_id, because all OF functions handle
>> it as const.
>
> Sure, will fix it.
>
> Thank you,
> Ivan
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/6] drivers: uio: Add X-Gene QMTM UIO driver
The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
and Traffic manager) which is hardware based Queue or Ring
manager. This QMTM device can be used in conjunction with
other devices such as DMA Engine, Ethernet, Security Engine,
etc to assign work based on queues or rings.
This patch allows user space access to X-Gene QMTM device.
Signed-off-by: Ankit Jindal
Signed-off-by: Tushar Jagad
---
drivers/uio/Kconfig |8 ++
drivers/uio/Makefile |1 +
drivers/uio/uio_xgene_qmtm.c | 278 ++
3 files changed, 287 insertions(+)
create mode 100644 drivers/uio/uio_xgene_qmtm.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 5a90914..76b1858 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -135,4 +135,12 @@ config UIO_MF624
If you compile this as a module, it will be called uio_mf624.
+config UIO_XGENE_QMTM
+ tristate "Applied Micro X-Gene QMTM driver"
+ depends on OF
+ help
+ Userspace I/O interface for the X-Gene QMTM. The userspace part of
+ this driver will be available for download from the Applied Micro
+ web site (http://www.apm.com/).
+
endif
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index d3218bd..633eaa0 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_UIO_PCI_GENERIC) += uio_pci_generic.o
obj-$(CONFIG_UIO_NETX) += uio_netx.o
obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
obj-$(CONFIG_UIO_MF624) += uio_mf624.o
+obj-$(CONFIG_UIO_XGENE_QMTM) += uio_xgene_qmtm.o
diff --git a/drivers/uio/uio_xgene_qmtm.c b/drivers/uio/uio_xgene_qmtm.c
new file mode 100644
index 000..36d9000
--- /dev/null
+++ b/drivers/uio/uio_xgene_qmtm.c
@@ -0,0 +1,278 @@
+/*
+ * X-Gene Queue Manager Traffic Manager (QMTM) UIO driver (uio_xgene_qmtm)
+ *
+ * This driver exports QMTM CSRs, Fabric and memory for queues to user-space
+ *
+ * Copyright (C) 2014 Applied Micro - http://www.apm.com/
+ * Copyright (C) 2014 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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
+#include
+#include
+
+#define DRV_NAME "qmtm_uio"
+#define DRV_VERSION "1.0"
+
+#define QMTM_CFG_MEM_RAM_SHUTDOWN 0xd070
+
+#define QMTM_DEFAULT_QSIZE 65536
+
+struct uio_qmtm_dev {
+ struct uio_info *info;
+ struct clk *qmtm_clk;
+};
+
+/* QMTM CSR read/write routine */
+static inline void qmtm_csr_write(struct uio_qmtm_dev *qmtm_dev, u32 offset,
+ u32 data)
+{
+ void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
+
+ writel(data, addr + offset);
+}
+
+static inline u32 qmtm_csr_read(struct uio_qmtm_dev *qmtm_dev, u32 offset)
+{
+ void __iomem *addr = qmtm_dev->info->mem[0].internal_addr;
+
+ return readl(addr + offset);
+}
+
+static int qmtm_reset(struct uio_qmtm_dev *qmtm_dev)
+{
+ u32 val;
+ int wait = 1000;
+
+ /* reset the internal memory of the device */
+ qmtm_csr_write(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN, 0);
+
+ /* check whether device internal memory is out of reset or not */
+ while (1) {
+ val = qmtm_csr_read(qmtm_dev, QMTM_CFG_MEM_RAM_SHUTDOWN);
+
+ if (val != 0x)
+ return 0;
+
+ if (!wait--)
+ return -EBUSY;
+
+ udelay(1);
+ }
+}
+
+static void qmtm_cleanup(struct platform_device *pdev,
+ struct uio_qmtm_dev *qmtm_dev)
+{
+ struct uio_info *info = qmtm_dev->info;
+
+ uio_unregister_device(info);
+
+ clk_disable_unprepare(qmtm_dev->qmtm_clk);
+}
+
+static int qmtm_probe(struct platform_device *pdev)
+{
+ struct uio_info *info;
+ struct uio_qmtm_dev *qmtm_dev;
+ struct resource *csr;
+ struct resource *fabric;
+ struct resource qpool;
+ unsigned int num_queues;
+ unsigned int devid;
+ phandle qpool_phandle;
+ struct device_node *qpool_node;
+ int ret;
+
+ qmtm_dev = devm_kzalloc(>dev, sizeof(struct uio_qmtm_dev),
+ GFP_KERNEL);
+ if (!qmtm_dev)
+ return -ENOMEM;
+
+ qmtm_dev->info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
+ if (!qmtm_dev->info)
+ return -ENOMEM;
+
+ /* Power on qmtm in case its not done as part of boot-loader */
+ qmtm_dev->qmtm_clk = devm_clk_get(>dev, NULL);
+ if
[PATCH v2 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver
This patch adds device tree binding documentation for
X-Gene QMTM UIO driver.
Signed-off-by: Ankit Jindal
Signed-off-by: Tushar Jagad
---
.../devicetree/bindings/uio/uio_xgene_qmtm.txt | 53
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
diff --git a/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
new file mode 100644
index 000..288ed92
--- /dev/null
+++ b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
@@ -0,0 +1,53 @@
+APM X-Gene QMTM UIO nodes
+
+The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
+and Traffic manager). It is a device for managing hardware queues.
+It also implements QoS among hardware queues hence term "traffic"
+manager is present in its name. QMTM UIO nodes are defined for user
+space access to this device using UIO framework.
+
+Required properties:
+- compatible: Should be "apm,xgene-qmtm"
+- reg: Address and length of the register set for the device. It contains the
+ information of registers in the same order as described by reg-names.
+- reg-names: Should contain the register set names
+ - "csr": QMTM control and status register address space.
+ - "fabric": QMTM memory mapped access to queue states.
+- qpool: Points to the phandle of the node defining memory location for
+creating QMTM queues. This could point either to the reserved-memory
+node (as-per reserved memory bindings) or to the node of on-chip
+SRAM etc. It is expected that size and location of qpool memory will
+be configurable via bootloader.
+- clocks: Reference to the clock entry.
+- num-queues: Number of queues under this QMTM device.
+- devid: QMTM identification number for the system having multiple QMTM
devices.
+This is used to form a unique id (a tuple of queue number and
+device id) for the queues belonging to this device.
+
+Example:
+ qmtm1_uio_qpool: qmtm1_uio_qpool {
+ reg = <0x0 0x0 0x0 0x0>
+ };
+
+ qmtm1clk: qmtmclk@1f20c000 {
+ compatible = "apm,xgene-device-clock";
+ clock-output-names = "qmtm1clk";
+ status = "ok";
+ };
+
+ qmtm1_uio: qmtm_uio@1f20 {
+ compatible = "apm,xgene-qmtm";
+ status = "disabled";
+ reg = <0x0 0x1f20 0x0 0x1>,
+ <0x0 0x1b00 0x0 0x40>;
+ reg-names = "csr", "fabric";
+ qpool = <_uio_qpool>;
+ clocks = < 0>;
+ num-queues = <0x400>;
+ devid = <1>;
+ };
+
+ /* Board-specific peripheral configurations */
+ _uio {
+ status = "ok";
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/6] uio: code style cleanup
This patch fixes the indentation of switch-case block in uio driver.
Signed-off-by: Ankit Jindal
Signed-off-by: Tushar Jagad
---
drivers/uio/uio.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index a673e5b..97e6444 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -706,13 +706,13 @@ static int uio_mmap(struct file *filep, struct
vm_area_struct *vma)
}
switch (idev->info->mem[mi].memtype) {
- case UIO_MEM_PHYS:
- return uio_mmap_physical(vma);
- case UIO_MEM_LOGICAL:
- case UIO_MEM_VIRTUAL:
- return uio_mmap_logical(vma);
- default:
- return -EINVAL;
+ case UIO_MEM_PHYS:
+ return uio_mmap_physical(vma);
+ case UIO_MEM_LOGICAL:
+ case UIO_MEM_VIRTUAL:
+ return uio_mmap_logical(vma);
+ default:
+ return -EINVAL;
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/6] MAINTAINERS: Add entry for APM X-Gene QMTM UIO driver
Add entry to maintainer list for APM X-Gene QMTM UIO driver. Signed-off-by: Ankit Jindal Signed-off-by: Tushar Jagad --- MAINTAINERS |7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5e7866a..138663f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -727,6 +727,13 @@ S: Supported F: drivers/net/ethernet/apm/xgene/ F: Documentation/devicetree/bindings/net/apm-xgene-enet.txt +APPLIED MICRO (APM) X-GENE QMTM UIO DRIVER +M: Ankit Jindal +M: Tushar Jagad +S: Supported +F: drivers/uio/uio_xgene_qmtm.c +F: Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt + APTINA CAMERA SENSOR PLL M: Laurent Pinchart L: linux-me...@vger.kernel.org -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/6] UIO driver for APM X-Gene QMTM
This patchset enables user space access to APM X-Gene QMTM using UIO framework. The patchset also introduces new type UIO_MEM_PHYS_CACHE for mem regions because APM X-Gene QMTM device supports cache coherency with CPU caches. Changes since v1: - Factor-out formating related change in uio/uio.c as separate patch. - Use devm_xxx() APIs where appilicable. - Some cleanups and buggy loop fixed in qmtm_reset(). - Removed open and release functions. - Use phandle for specifying QMTM qpool resource. - Removed "uio" from the compatible string. - Added more information about QMTM in binding documentation. Ankit Jindal (6): uio: code style cleanup uio: Add new UIO_MEM_PHYS_CACHE type for mem regions Documentation: Update documentation for UIO_MEM_PHYS_CACHE drivers: uio: Add X-Gene QMTM UIO driver Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver MAINTAINERS: Add entry for APM X-Gene QMTM UIO driver Documentation/DocBook/uio-howto.tmpl |5 +- .../devicetree/bindings/uio/uio_xgene_qmtm.txt | 53 MAINTAINERS|7 + drivers/uio/Kconfig|8 + drivers/uio/Makefile |1 + drivers/uio/uio.c | 23 +- drivers/uio/uio_xgene_qmtm.c | 278 include/linux/uio_driver.h |1 + 8 files changed, 365 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt create mode 100644 drivers/uio/uio_xgene_qmtm.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/6] Documentation: Update documentation for UIO_MEM_PHYS_CACHE
This patch updates UIO documentation for new mem region type UIO_MEM_PHYS_CACHE. Signed-off-by: Ankit Jindal Signed-off-by: Tushar Jagad --- Documentation/DocBook/uio-howto.tmpl |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index bbe9c1f..baa9185 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl @@ -529,8 +529,9 @@ the memory region, it will show up in the corresponding sysfs node. int memtype: Required if the mapping is used. Set this to UIO_MEM_PHYS if you you have physical memory on your card to be mapped. Use UIO_MEM_LOGICAL for logical -memory (e.g. allocated with kmalloc()). There's also -UIO_MEM_VIRTUAL for virtual memory. +memory (e.g. allocated with kmalloc()). There are also +UIO_MEM_VIRTUAL for virtual memory, and +UIO_MEM_PHYS_CACHE for cacheable access to physical memory. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] ARM: move #include into cacheflush.h
On Mon, 29 Sep 2014, Brian Norris wrote: > There are several places where an explicit include of is needed > just because cacheflush.h uses one of its macros in v7_exit_coherency_flush(). > Let's put the include in the proper header. > > These obviously have some dependencies, so I'd focus on: > (1) Is patch 1 acceptable? If so, then: Well, I'm wondering if it is really a gain to force a dependency for cp15.h on every user of cacheflush.h just because of the seldomly used v7_exit_coherency_flush(). But I don't mind either ways. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pipe/page fault oddness.
On Mon, Sep 29, 2014 at 8:33 PM, Dave Jones wrote:
>
> Looking at the dump, there's only one running trinity child,
> with all the others blocking on it.
>
> trinity-c49 R running task12856 19464 7633 0x0004
> 8800a09bf960 0002 8800a09bf9f8 88021965
> 001d4080 8800a09bffd8 001d4080
> 88023f755bc0 88021965 8800a09bffd8 88010b017e00
> Call Trace:
> [] handle_mm_fault+0x3a7/0xcd0
> [] __do_page_fault+0x1a4/0x600
> [] do_page_fault+0x1e/0x70
> [] page_fault+0x22/0x30
> [] ? copy_page_to_iter+0x3b3/0x500
> [] pipe_read+0xdf/0x330
>
> Running the function tracer on that pid shows it spinning forever..
> http://codemonkey.org.uk/junk/pipe-trace.txt
>
> Kernel bug (missing EFAULT check somewhere perhaps?), or is this a
> case where the fuzzer asked the kernel to do something stupid, and it obliged
> ?
Hmm. It looks like copy_page_to_iter_iovec() is broken and keeps not
making any progress while just faulting.
I don't see how that could happen, though. All the loops there are
conditional on the user copies *not* failing (ie "!left"), and they
seem to properly update "iov".
Mind sending a disassembly of your "copy_page_to_iter" function, in
particular around that whole "0x3b3/0x500" area which is where the
page fault seems to happen?
Adding Al to the cc, since this code is from his commit 6e58e79db8a1
("introduce copy_page_to_iter, kill loop over iovec in
generic_file_aio_read()") but I don't see anything obviously wrong
there.
Al? Do you see something I don't? Dave's function trace does seem to
say that it doesn't even get back to pipe_read(), though, so the loop
really must be inside copy_page_to_iter().
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/3] cap11xx: make driver generic for variant support
cap1106 driver can support much more one device make the driver
generic for support of similiar parts.
Signed-off-by: Matt Ranostay
---
.../bindings/input/{cap1106.txt => cap11xx.txt}| 5 +-
drivers/input/keyboard/Kconfig | 8 +-
drivers/input/keyboard/Makefile| 2 +-
drivers/input/keyboard/cap1106.c | 341 -
drivers/input/keyboard/cap11xx.c | 340
5 files changed, 348 insertions(+), 348 deletions(-)
rename Documentation/devicetree/bindings/input/{cap1106.txt => cap11xx.txt}
(89%)
delete mode 100644 drivers/input/keyboard/cap1106.c
create mode 100644 drivers/input/keyboard/cap11xx.c
diff --git a/Documentation/devicetree/bindings/input/cap1106.txt
b/Documentation/devicetree/bindings/input/cap11xx.txt
similarity index 89%
rename from Documentation/devicetree/bindings/input/cap1106.txt
rename to Documentation/devicetree/bindings/input/cap11xx.txt
index 4b46390..738f5f3 100644
--- a/Documentation/devicetree/bindings/input/cap1106.txt
+++ b/Documentation/devicetree/bindings/input/cap11xx.txt
@@ -1,11 +1,12 @@
-Device tree bindings for Microchip CAP1106, 6 channel capacitive touch sensor
+Device tree bindings for Microchip CAP1106 based capacitive touch sensor
The node for this driver must be a child of a I2C controller node, as the
device communication via I2C only.
Required properties:
- compatible: Must be "microchip,cap1106"
+ compatible: Must be on the following, depending on the
model:
+ "microchip,cap1106"
reg:The I2C slave address of the device.
Only 0x28 is valid.
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index a3958c6..96ee26c 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -665,14 +665,14 @@ config KEYBOARD_CROS_EC
To compile this driver as a module, choose M here: the
module will be called cros_ec_keyb.
-config KEYBOARD_CAP1106
- tristate "Microchip CAP1106 touch sensor"
+config KEYBOARD_CAP11XX
+ tristate "Microchip CAP11XX based touch sensors"
depends on OF && I2C
select REGMAP_I2C
help
- Say Y here to enable the CAP1106 touch sensor driver.
+ Say Y here to enable the CAP11XX touch sensor driver.
To compile this driver as a module, choose M here: the
- module will be called cap1106.
+ module will be called cap11xx.
endif
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 0a33456..febafa5 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_KEYBOARD_AMIGA) += amikbd.o
obj-$(CONFIG_KEYBOARD_ATARI) += atakbd.o
obj-$(CONFIG_KEYBOARD_ATKBD) += atkbd.o
obj-$(CONFIG_KEYBOARD_BFIN)+= bf54x-keys.o
-obj-$(CONFIG_KEYBOARD_CAP1106) += cap1106.o
+obj-$(CONFIG_KEYBOARD_CAP11XX) += cap11xx.o
obj-$(CONFIG_KEYBOARD_CLPS711X)+= clps711x-keypad.o
obj-$(CONFIG_KEYBOARD_CROS_EC) += cros_ec_keyb.o
obj-$(CONFIG_KEYBOARD_DAVINCI) += davinci_keyscan.o
diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c
deleted file mode 100644
index d70b65a..000
--- a/drivers/input/keyboard/cap1106.c
+++ /dev/null
@@ -1,341 +0,0 @@
-/*
- * Input driver for Microchip CAP1106, 6 channel capacitive touch sensor
- *
- * http://www.microchip.com/wwwproducts/Devices.aspx?product=CAP1106
- *
- * (c) 2014 Daniel Mack
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#define CAP1106_REG_MAIN_CONTROL 0x00
-#define CAP1106_REG_MAIN_CONTROL_GAIN_SHIFT(6)
-#define CAP1106_REG_MAIN_CONTROL_GAIN_MASK (0xc0)
-#define CAP1106_REG_MAIN_CONTROL_DLSEEPBIT(4)
-#define CAP1106_REG_GENERAL_STATUS 0x02
-#define CAP1106_REG_SENSOR_INPUT 0x03
-#define CAP1106_REG_NOISE_FLAG_STATUS 0x0a
-#define CAP1106_REG_SENOR_DELTA(X) (0x10 + (X))
-#define CAP1106_REG_SENSITIVITY_CONTROL0x1f
-#define CAP1106_REG_CONFIG 0x20
-#define CAP1106_REG_SENSOR_ENABLE 0x21
-#define CAP1106_REG_SENSOR_CONFIG 0x22
-#define CAP1106_REG_SENSOR_CONFIG2 0x23
-#define CAP1106_REG_SAMPLING_CONFIG0x24
-#define CAP1106_REG_CALIBRATION0x26
-#define CAP1106_REG_INT_ENABLE 0x27
-#define CAP1106_REG_REPEAT_RATE0x28
-#define CAP1106_REG_MT_CONFIG 0x2a
-#define CAP1106_REG_MT_PATTERN_CONFIG 0x2b
-#define CAP1106_REG_MT_PATTERN 0x2d
-#define
[PATCH v4 0/3] cap1106: add support for cap11xx variants
Changes from v3:
* Resubmit with "git format-patch -M" to make file rename clear in
cover letter
Matt Ranostay (3):
cap11xx: make driver generic for variant support
cap11xx: Add support for various cap11xx devices
cap11xx: support for irq-active-high option
.../bindings/input/{cap1106.txt => cap11xx.txt}| 12 +-
drivers/input/keyboard/Kconfig | 8 +-
drivers/input/keyboard/Makefile| 2 +-
drivers/input/keyboard/cap1106.c | 341 ---
drivers/input/keyboard/cap11xx.c | 371 +
5 files changed, 385 insertions(+), 349 deletions(-)
rename Documentation/devicetree/bindings/input/{cap1106.txt => cap11xx.txt}
(78%)
delete mode 100644 drivers/input/keyboard/cap1106.c
create mode 100644 drivers/input/keyboard/cap11xx.c
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/3] cap11xx: Add support for various cap11xx devices
Several other variants of the cap11xx device exists with a varying
number of capacitance detection channels. Add support for creating
the channels dynamically.
Signed-off-by: Matt Ranostay
---
.../devicetree/bindings/input/cap11xx.txt | 3 +-
drivers/input/keyboard/cap11xx.c | 65 +++---
2 files changed, 46 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/cap11xx.txt
b/Documentation/devicetree/bindings/input/cap11xx.txt
index 738f5f3..8031aa5 100644
--- a/Documentation/devicetree/bindings/input/cap11xx.txt
+++ b/Documentation/devicetree/bindings/input/cap11xx.txt
@@ -7,9 +7,10 @@ Required properties:
compatible: Must be on the following, depending on the
model:
"microchip,cap1106"
+ "microchip,cap1126"
+ "microchip,cap1188"
reg:The I2C slave address of the device.
- Only 0x28 is valid.
interrupts: Property describing the interrupt line the
device's ALERT#/CM_IRQ# pin is connected to.
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index 0da2e83..adb979e 100644
--- a/drivers/input/keyboard/cap11xx.c
+++ b/drivers/input/keyboard/cap11xx.c
@@ -1,7 +1,6 @@
/*
* Input driver for Microchip CAP11xx based capacitive touch sensors
*
- *
* (c) 2014 Daniel Mack
*
* This program is free software; you can redistribute it and/or modify
@@ -54,8 +53,6 @@
#define CAP11XX_REG_MANUFACTURER_ID0xfe
#define CAP11XX_REG_REVISION 0xff
-#define CAP11XX_NUM_CHN 6
-#define CAP11XX_PRODUCT_ID 0x55
#define CAP11XX_MANUFACTURER_ID0x5d
struct cap11xx_priv {
@@ -63,7 +60,25 @@ struct cap11xx_priv {
struct input_dev *idev;
/* config */
- unsigned short keycodes[CAP11XX_NUM_CHN];
+ u32 *keycodes;
+ unsigned int num_channels;
+};
+
+struct cap11xx_hw_model {
+ uint8_t product_id;
+ unsigned int num_channels;
+};
+
+enum {
+ CAP1106,
+ CAP1126,
+ CAP1188,
+};
+
+struct cap11xx_hw_model cap11xx_devices[] = {
+ [CAP1106] = { .product_id = 0x55, .num_channels = 6 },
+ [CAP1126] = { .product_id = 0x53, .num_channels = 6 },
+ [CAP1188] = { .product_id = 0x50, .num_channels = 8 },
};
static const struct reg_default cap11xx_reg_defaults[] = {
@@ -150,7 +165,7 @@ static irqreturn_t cap11xx_thread_func(int irq_num, void
*data)
if (ret < 0)
goto out;
- for (i = 0; i < CAP11XX_NUM_CHN; i++)
+ for (i = 0; i < priv->num_channels; i++)
input_report_key(priv->idev, priv->keycodes[i],
status & (1 << i));
@@ -187,14 +202,23 @@ static int cap11xx_i2c_probe(struct i2c_client
*i2c_client,
struct device *dev = _client->dev;
struct cap11xx_priv *priv;
struct device_node *node;
+ struct cap11xx_hw_model *cap = _devices[id->driver_data];
int i, error, irq, gain = 0;
unsigned int val, rev;
- u32 gain32, keycodes[CAP11XX_NUM_CHN];
+ u32 gain32;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
+ BUG_ON(!cap->num_channels);
+
+ priv->num_channels = cap->num_channels;
+ priv->keycodes = devm_kcalloc(dev,
+ priv->num_channels, sizeof(u32), GFP_KERNEL);
+ if (!priv->keycodes)
+ return -ENOMEM;
+
priv->regmap = devm_regmap_init_i2c(i2c_client, _regmap_config);
if (IS_ERR(priv->regmap))
return PTR_ERR(priv->regmap);
@@ -203,9 +227,9 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client,
if (error)
return error;
- if (val != CAP11XX_PRODUCT_ID) {
+ if (val != cap->product_id) {
dev_err(dev, "Product ID: Got 0x%02x, expected 0x%02x\n",
- val, CAP11XX_PRODUCT_ID);
+ val, cap->product_id);
return -ENODEV;
}
@@ -234,17 +258,12 @@ static int cap11xx_i2c_probe(struct i2c_client
*i2c_client,
dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
}
- BUILD_BUG_ON(ARRAY_SIZE(keycodes) != ARRAY_SIZE(priv->keycodes));
-
/* Provide some useful defaults */
- for (i = 0; i < ARRAY_SIZE(keycodes); i++)
- keycodes[i] = KEY_A + i;
+ for (i = 0; i < priv->num_channels; i++)
+ priv->keycodes[i] = KEY_A + i;
of_property_read_u32_array(node, "linux,keycodes",
- keycodes, ARRAY_SIZE(keycodes));
-
- for (i = 0; i < ARRAY_SIZE(keycodes); i++)
- priv->keycodes[i] = keycodes[i];
+ priv->keycodes, priv->num_channels);
[PATCH v4 3/3] cap11xx: support for irq-active-high option
Some applications need to use the irq-active-high push-pull option.
This allows it be enabled in the device tree child node.
Signed-off-by: Matt Ranostay
---
Documentation/devicetree/bindings/input/cap11xx.txt | 4
drivers/input/keyboard/cap11xx.c| 8
2 files changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/cap11xx.txt
b/Documentation/devicetree/bindings/input/cap11xx.txt
index 8031aa5..57407be 100644
--- a/Documentation/devicetree/bindings/input/cap11xx.txt
+++ b/Documentation/devicetree/bindings/input/cap11xx.txt
@@ -28,6 +28,10 @@ Optional properties:
Valid values are 1, 2, 4, and 8.
By default, a gain of 1 is set.
+ microchip,irq-active-high: By default the interrupt pin is active
low
+ open drain. This property allows using the
active
+ high push-pull output.
+
linux,keycodes: Specifies an array of numeric keycode values to
be used for the channels. If this property is
omitted, KEY_A, KEY_B, etc are used as
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index adb979e..02bedc1 100644
--- a/drivers/input/keyboard/cap11xx.c
+++ b/drivers/input/keyboard/cap11xx.c
@@ -45,6 +45,7 @@
#define CAP11XX_REG_STANDBY_SENSITIVITY0x42
#define CAP11XX_REG_STANDBY_THRESH 0x43
#define CAP11XX_REG_CONFIG20x44
+#define CAP11XX_REG_CONFIG2_ALT_POLBIT(6)
#define CAP11XX_REG_SENSOR_BASE_CNT(X) (0x50 + (X))
#define CAP11XX_REG_SENSOR_CALIB (0xb1 + (X))
#define CAP11XX_REG_SENSOR_CALIB_LSB1 0xb9
@@ -258,6 +259,13 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client,
dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
}
+ if (of_property_read_bool(node, "microchip,irq-active-high")) {
+ error = regmap_update_bits(priv->regmap, CAP11XX_REG_CONFIG2,
+ CAP11XX_REG_CONFIG2_ALT_POL, 0);
+ if (error)
+ return error;
+ }
+
/* Provide some useful defaults */
for (i = 0; i < priv->num_channels; i++)
priv->keycodes[i] = KEY_A + i;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] perf/x86: Use KERN_INFO when checking PMU fails on virtual environment
Hi Ingo, tglx and hpa, Any comment on this patch? Thanks. -Wei On 09/24/2014 10:55 PM, Wei Huang wrote: PMU checking can fail due to various reasons. On native machine, this is mostly caused by faulty hardware and it is reasonable to use KERN_ERR in reporting. However, when kernel is running on virtualized environment, this checking can fail if virtual PMU is not supported (e.g. KVM on AMD host). It is annoying to see an error message on splash screen, even though we know such failure is benign on virtualized environment. This patch checks if kernel is running in virtualized environment. If so, it will use KERN_INFO in reporting. This patch was tested successfully on KVM. Signed-off-by: Wei Huang --- arch/x86/kernel/cpu/perf_event.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c index 918d75f..16c7302 100644 --- a/arch/x86/kernel/cpu/perf_event.c +++ b/arch/x86/kernel/cpu/perf_event.c @@ -243,7 +243,8 @@ static bool check_hw_exists(void) msr_fail: printk(KERN_CONT "Broken PMU hardware detected, using software events only.\n"); - printk(KERN_ERR "Failed to access perfctr msr (MSR %x is %Lx)\n", reg, val_new); + printk(boot_cpu_has(X86_FEATURE_HYPERVISOR) ? KERN_INFO : KERN_ERR + "Failed to access perfctr msr (MSR %x is %Lx)\n", reg, val_new); return false; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6] mfd: syscon: Decouple syscon interface from platform devices
Hi,
On Monday, September 29, 2014 9:38 PM, Heiko Stübner wrote,
> Am Montag, 29. September 2014, 14:17:38 schrieb Pankaj Dubey:
> > Currently a syscon entity can be only registered directly through a
> > platform device that binds to a dedicated syscon driver. However in
> > certain use cases it is desirable to make a device used with another
> > driver a syscon interface provider.
> >
> > For example, certain SoCs (e.g. Exynos) contain system controller
> > blocks which perform various functions such as power domain control,
> > CPU power management, low power mode control, but in addition contain
> > certain IP integration glue, such as various signal masks, coprocessor
> > power control, etc. In such case, there is a need to have a dedicated
> > driver for such system controller but also share registers with other
> > drivers. The latter is where the syscon interface is helpful.
> >
> > In case of DT based platforms, this patch decouples syscon object from
> > syscon platform driver, and allows to create syscon objects first time
> > when it is required by calling of syscon_regmap_lookup_by APIs and
> > keep a list of such syscon objects along with syscon provider
> > device_nodes and regmap handles.
> >
> > For non-DT based platforms, this patch keeps syscon platform driver
> > structure where is can be probed and such non-DT based drivers can use
> > syscon_regmap_lookup_by_pdev API and get access to regmap handles.
> > Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
> > we can completely remove platform driver of syscon, and keep only
> > helper functions to get regmap handles.
> >
> > Suggested-by: Arnd Bergmann
> > Suggested-by: Tomasz Figa
> > Tested-by: Vivek Gautam
> > Tested-by: Javier Martinez Canillas
> > Signed-off-by: Pankaj Dubey
> > ---
>
> On Rockchip boards during core clock init (aka before timers)
> Tested-by: Heiko Stuebner
>
Thanks for testing.
> Except one issue described inline below
> Reviewed-by: Heiko Stuebner
>
>
> And I'm really looking forward to having this in the kernel :-)
>
> Thanks for working on this
> Heiko
>
>
[snip]
> >
> > drivers/mfd/syscon.c | 106
> > +++--- 1 file
> changed, 84
> > insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c index
> > ca15878..00a8410 100644
> > --- a/drivers/mfd/syscon.c
> > +++ b/drivers/mfd/syscon.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -22,31 +23,104 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > static struct platform_driver syscon_driver;
> >
> > +static DEFINE_SPINLOCK(syscon_list_slock);
> > +static LIST_HEAD(syscon_list);
> > +
> > struct syscon {
> > + struct device_node *np;
> > struct regmap *regmap;
> > + struct list_head list;
> > +};
> > +
> > +static struct regmap_config syscon_regmap_config = {
> > + .reg_bits = 32,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > };
> >
> > -static int syscon_match_node(struct device *dev, void *data)
> > +static struct syscon *of_syscon_register(struct device_node *np)
> > {
> > - struct device_node *dn = data;
> > + struct syscon *syscon;
> > + struct regmap *regmap;
> > + void __iomem *base;
> > + int ret;
> > + enum regmap_endian endian = REGMAP_ENDIAN_DEFAULT;
> > +
> > + if (!of_device_is_compatible(np, "syscon"))
> > + return ERR_PTR(-EINVAL);
> > +
> > + syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
> > + if (!syscon)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + base = of_iomap(np, 0);
> > + if (!base) {
> > + ret = -ENOMEM;
> > + goto err_map;
> > + }
> > +
> > + /* Parse the device's DT node for an endianness specification */
> > + if (of_property_read_bool(np, "big-endian"))
> > + endian = REGMAP_ENDIAN_BIG;
> > +else if (of_property_read_bool(np, "little-endian"))
> > + endian = REGMAP_ENDIAN_LITTLE;
> > +
> > + /* If the endianness was specified in DT, use that */
> > + if (endian != REGMAP_ENDIAN_DEFAULT)
> > + syscon_regmap_config.val_format_endian = endian;
> > +
> > + regmap = regmap_init_mmio(NULL, base, _regmap_config);
> > + if (IS_ERR(regmap)) {
> > + pr_err("regmap init failed\n");
> > + ret = PTR_ERR(regmap);
> > + goto err_regmap;
> > + }
> > +
> > + syscon->regmap = regmap;
> > + syscon->np = np;
> > +
> > + spin_lock(_list_slock);
> > + list_add_tail(>list, _list);
> > + spin_unlock(_list_slock);
> >
> > - return (dev->of_node == dn) ? 1 : 0;
> > + /* Change back endianness of syscon_regmap_config.
> > +* As this is static config in this file and in one system we may
> > +* have more than one syscon
> > +*/
> > + syscon_regmap_config.val_format_endian =
> REGMAP_ENDIAN_DEFAULT;
>
> This should also be done in the error case.
[PATCH] cpufreq: update 'cpufreq_suspended' after stopping governors
Commit 8e30444e1530 ("cpufreq: fix cpufreq suspend/resume for intel_pstate")
introduced a bug where the governors wouldn't be stopped anymore for
->target{_index}() drivers during suspend. This happens because
'cpufreq_suspended' is updated before stopping the governors during suspend and
due to this __cpufreq_governor() would return early due to this check:
/* Don't start any governor operations if we are entering suspend */
if (cpufreq_suspended)
return 0;
This patch tries to fix this bug.
Fixes: 8e30444e1530 ("cpufreq: fix cpufreq suspend/resume for intel_pstate")
Cc: 3.15+ # 3.15+
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 6e93e7f..61190f6 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1658,10 +1658,8 @@ void cpufreq_suspend(void)
if (!cpufreq_driver)
return;
- cpufreq_suspended = true;
-
if (!has_target())
- return;
+ goto suspend;
pr_debug("%s: Suspending Governors\n", __func__);
@@ -1674,6 +1672,9 @@ void cpufreq_suspend(void)
pr_err("%s: Failed to suspend driver: %p\n", __func__,
policy);
}
+
+suspend:
+ cpufreq_suspended = true;
}
/**
--
2.0.3.693.g996b0fd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] fuse: handle release synchronously (v4)
On Thu, Sep 25, 2014 at 5:05 AM, Maxim Patlasov wrote: > > There is a long-standing demand for synchronous behaviour of fuse_release: That's just complete bullshit. The fact is, release() is not synchronous. End of story. If you want to catch "close()" synchronously, you use flush(). The two are NOT the same, and never will be, and never should be confused. "release()" happens at some random time (but only once), and cannot return an error. "flush()" happens synchronously at close() time, and can return an error. Anybody who confuses the two is *wrong*. It sounds like somebody wants to use "flush()" in fuse. But please don't mistake that for "release". It's different. So please kill this "FOPEN_SYNC_RELEASE" thing with fire. It's crazy, it's wrong, it's stupid. It must die. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: rockchip: rk3288: i2s_frac adds flag to set parent's rate
在 09/30/2014 11:38 AM, Kever Yang 写道:
> Hi Jianqun,
>
> pls add linux-rockc...@lists.infradead.org next time.
>
OK, thanks
> On 09/30/2014 11:12 AM, Jianqun wrote:
>> The relation of i2s nodes as follows:
>>i2s_src 0 059400 0
>> i2s_frac 0 011289600 0
>> i2s_pre 0 011289600 0
>> sclk_i2s00 011289600 0
>> i2s0_clkout 0 011289600 0
>>hclk_i2s0 1 19900 0
> I always got the result as following when I set sclk_i2s0 to 11289600,
> any one knows the reason?
>
> gpll 6 659400 0
> sclk_emmc 1 19900 0
> i2s_src 0 011207548 0
> i2s_pre0 011207548 0
> sclk_i2s0 0 011207548 0
> i2s0_clkout 0 011207548 0
> i2s_frac 0 0646456897 0
Hi, as clock tree shows, i2s_pre should come from i2s_frac, that's the root
different above two trees.
>> sclk_i2s0 is the master clock, when to set rate of sclk_i2s0, should
>> allow to set its parent's rate, by add flag CLK_SET_RATE_PARENT for
>> "i2s_frac", "i2s_pre", "i2s0_clkout" and "sclk_i2s0".
>>
>> Tested on rk3288 board using max98090, with command "aplay "
>>
>> Change-Id: I12faad082566532b65a7de8c0a6845e1c17870e6
>> Signed-off-by: Jianqun
>> ---
>> drivers/clk/rockchip/clk-rk3288.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/clk/rockchip/clk-rk3288.c
>> b/drivers/clk/rockchip/clk-rk3288.c
>> index c770de0..baf19b4 100644
>> --- a/drivers/clk/rockchip/clk-rk3288.c
>> +++ b/drivers/clk/rockchip/clk-rk3288.c
>> @@ -301,15 +301,15 @@ static struct rockchip_clk_branch
>> rk3288_clk_branches[] __initdata = {
>> COMPOSITE(0, "i2s_src", mux_pll_src_cpll_gpll_p, 0,
>> RK3288_CLKSEL_CON(4), 15, 1, MFLAGS, 0, 7, DFLAGS,
>> RK3288_CLKGATE_CON(4), 1, GFLAGS),
>> -COMPOSITE_FRAC(0, "i2s_frac", "i2s_src", 0,
>> +COMPOSITE_FRAC(0, "i2s_frac", "i2s_src", CLK_SET_RATE_PARENT,
>> RK3288_CLKSEL_CON(8), 0,
>> RK3288_CLKGATE_CON(4), 2, GFLAGS),
>> -MUX(0, "i2s_pre", mux_i2s_pre_p, 0,
>> +MUX(0, "i2s_pre", mux_i2s_pre_p, CLK_SET_RATE_PARENT,
>> RK3288_CLKSEL_CON(4), 8, 2, MFLAGS),
>> -COMPOSITE_NODIV(0, "i2s0_clkout", mux_i2s_clkout_p, 0,
>> +COMPOSITE_NODIV(0, "i2s0_clkout", mux_i2s_clkout_p, CLK_SET_RATE_PARENT,
>> RK3288_CLKSEL_CON(4), 12, 1, MFLAGS,
>> RK3288_CLKGATE_CON(4), 0, GFLAGS),
>> -GATE(SCLK_I2S0, "sclk_i2s0", "i2s_pre", 0,
>> +GATE(SCLK_I2S0, "sclk_i2s0", "i2s_pre", CLK_SET_RATE_PARENT,
>> RK3288_CLKGATE_CON(4), 3, GFLAGS),
>> MUX(0, "spdif_src", mux_pll_src_cpll_gpll_p, 0,
>
>
>
>
--
Jianqun Xu
*IMPORTANT NOTICE:*This email is from Fuzhou Rockchip Electronics Co.,
Ltd .The contents of this email and any attachments may contain
information that is privileged, confidential and/or exempt from
disclosure under applicable law and relevant NDA. If you are not the
intended recipient, you are hereby notified that any disclosure,
copying, distribution, or use of the information is STRICTLY PROHIBITED.
Please immediately contact the sender as soon as possible and destroy
the material in its entirety in any format. Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Please backport commit 3812c8c8f39 to stable
Hi, Johannes and Greg Please consider to backport the following commit to stable kernels < 3.12. commit 3812c8c8f3953921ef18544110dafc3505c1ac62 Author: Johannes Weiner Date: Thu Sep 12 15:13:44 2013 -0700 mm: memcg: do not trap chargers with full callstack on OOM It should solve some soft lockup I observed on different machines recently. For me myself, I only care about 3.10. :-p commit 4942642080ea82d99ab5b65 (mm: memcg: handle non-error OOM situations more gracefully) seems needed as a followup. Johannes should know much better than I do. Let me know if you need any more information or help from me. Thanks much! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] x86: Bugfix bit-rot in the calling of legacy_cache_size
On Tue, Sep 30, 2014 at 04:11:48AM +0100, Bryan O'Donoghue wrote:
> Make an update to identify_cpu to make an explicit call to default_init()
> We want to do this since some processors that report vendor strings via
> cpuid also want to run legacy_cache_size callbacks - which won't happen
> since init_intel() init_amd() and friends take the place of default_init()
> and don't themselves make explicit calls to legacy_cache_size.
>
> Also current code has an
> #ifdef CONFIG_X86_64
> cpu_detect_cache_sizes(c);
> #endif
...
> static void default_init(struct cpuinfo_x86 *c)
> {
> -#ifdef CONFIG_X86_64
> cpu_detect_cache_sizes(c);
> -#else
> +
> /* Not much we can do here... */
> /* Check if at least it has cpuid */
> if (c->cpuid_level == -1) {
> @@ -79,7 +78,6 @@ static void default_init(struct cpuinfo_x86 *c)
> else if (c->x86 == 3)
> strcpy(c->x86_model_id, "386");
> }
> -#endif
Shouldn't this patch be more like..
-#ifdef CONFIG_X86_64
cpu_detect_cache_sizes(c);
-#else
+
+#ifdef CONFIG_X86_32
?
The 386/486 stuff in this codepath isn't huge, but it
seems pointless to be compiling it on 64-bit.
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: rockchip: rk3288: i2s_frac adds flag to set parent's rate
Hi Jianqun,
pls add linux-rockc...@lists.infradead.org next time.
On 09/30/2014 11:12 AM, Jianqun wrote:
The relation of i2s nodes as follows:
i2s_src 0 059400 0
i2s_frac 0 011289600 0
i2s_pre 0 011289600 0
sclk_i2s00 011289600 0
i2s0_clkout 0 011289600 0
hclk_i2s0 1 19900 0
I always got the result as following when I set sclk_i2s0 to 11289600,
any one knows the reason?
gpll 6 659400 0
sclk_emmc 1 19900 0
i2s_src 0 011207548 0
i2s_pre0 011207548 0
sclk_i2s0 0 011207548 0
i2s0_clkout 0 011207548 0
i2s_frac 0 0646456897 0
sclk_i2s0 is the master clock, when to set rate of sclk_i2s0, should
allow to set its parent's rate, by add flag CLK_SET_RATE_PARENT for
"i2s_frac", "i2s_pre", "i2s0_clkout" and "sclk_i2s0".
Tested on rk3288 board using max98090, with command "aplay "
Change-Id: I12faad082566532b65a7de8c0a6845e1c17870e6
Signed-off-by: Jianqun
---
drivers/clk/rockchip/clk-rk3288.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index c770de0..baf19b4 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -301,15 +301,15 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
COMPOSITE(0, "i2s_src", mux_pll_src_cpll_gpll_p, 0,
RK3288_CLKSEL_CON(4), 15, 1, MFLAGS, 0, 7, DFLAGS,
RK3288_CLKGATE_CON(4), 1, GFLAGS),
- COMPOSITE_FRAC(0, "i2s_frac", "i2s_src", 0,
+ COMPOSITE_FRAC(0, "i2s_frac", "i2s_src", CLK_SET_RATE_PARENT,
RK3288_CLKSEL_CON(8), 0,
RK3288_CLKGATE_CON(4), 2, GFLAGS),
- MUX(0, "i2s_pre", mux_i2s_pre_p, 0,
+ MUX(0, "i2s_pre", mux_i2s_pre_p, CLK_SET_RATE_PARENT,
RK3288_CLKSEL_CON(4), 8, 2, MFLAGS),
- COMPOSITE_NODIV(0, "i2s0_clkout", mux_i2s_clkout_p, 0,
+ COMPOSITE_NODIV(0, "i2s0_clkout", mux_i2s_clkout_p, CLK_SET_RATE_PARENT,
RK3288_CLKSEL_CON(4), 12, 1, MFLAGS,
RK3288_CLKGATE_CON(4), 0, GFLAGS),
- GATE(SCLK_I2S0, "sclk_i2s0", "i2s_pre", 0,
+ GATE(SCLK_I2S0, "sclk_i2s0", "i2s_pre", CLK_SET_RATE_PARENT,
RK3288_CLKGATE_CON(4), 3, GFLAGS),
MUX(0, "spdif_src", mux_pll_src_cpll_gpll_p, 0,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
pipe/page fault oddness.
My fuzz tester ground to a halt, with many child processes blocked on pipe_lock. sysrq-t output: http://codemonkey.org.uk/junk/pipe-lock-wtf.txt Looking at the dump, there's only one running trinity child, with all the others blocking on it. trinity-c49 R running task12856 19464 7633 0x0004 8800a09bf960 0002 8800a09bf9f8 88021965 001d4080 8800a09bffd8 001d4080 88023f755bc0 88021965 8800a09bffd8 88010b017e00 Call Trace: [] preempt_schedule+0x36/0x60 [] ___preempt_schedule+0x56/0xb0 [] ? handle_mm_fault+0x3a7/0xcd0 [] ? _raw_spin_unlock+0x31/0x50 [] ? _raw_spin_unlock+0x45/0x50 [] handle_mm_fault+0x3a7/0xcd0 [] ? __lock_is_held+0x57/0x80 [] __do_page_fault+0x1a4/0x600 [] ? mark_held_locks+0x75/0xa0 [] ? trace_hardirqs_on_caller+0x10d/0x1d0 [] ? trace_hardirqs_on+0xd/0x10 [] ? context_tracking_user_exit+0x67/0x1b0 [] do_page_fault+0x1e/0x70 [] page_fault+0x22/0x30 [] ? copy_page_to_iter+0x3b3/0x500 [] pipe_read+0xdf/0x330 [] ? pipe_write+0x490/0x490 [] ? do_sync_readv_writev+0xa0/0xa0 [] do_iter_readv_writev+0x78/0xc0 [] do_readv_writev+0xce/0x280 [] ? pipe_write+0x490/0x490 [] ? lock_release_holdtime.part.29+0xe6/0x160 [] ? get_parent_ip+0xd/0x50 [] ? get_parent_ip+0xd/0x50 [] ? preempt_count_sub+0x6b/0xf0 [] vfs_readv+0x39/0x50 [] SyS_readv+0x5c/0x100 [] tracesys+0xdd/0xe2 Running the function tracer on that pid shows it spinning forever.. http://codemonkey.org.uk/junk/pipe-trace.txt Kernel bug (missing EFAULT check somewhere perhaps?), or is this a case where the fuzzer asked the kernel to do something stupid, and it obliged ? Trinity's watchdog process has been repeatedly sending SIGKILL's to this running pid, but we never seem to get out of this state long enough for it to take effect. This is 3.17-rc7 fwiw. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the net-next tree
Hi all,
On Tue, 30 Sep 2014 13:13:54 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> net/bridge/br_nf_core.c:77:1: error: expected identifier or '(' before '{'
> token
> {
> ^
> net/bridge/br_nf_core.c:88:12: error: redefinition of 'br_nf_core_init'
> int __init br_nf_core_init(void)
> ^
> In file included from net/bridge/br_nf_core.c:23:0:
> net/bridge/br_private.h:762:19: note: previous definition of
> 'br_nf_core_init' was here
> static inline int br_nf_core_init(void) { return 0; }
>^
> net/bridge/br_nf_core.c:93:6: error: redefinition of 'br_nf_core_fini'
> void br_nf_core_fini(void)
> ^
> In file included from net/bridge/br_nf_core.c:23:0:
> net/bridge/br_private.h:763:20: note: previous definition of
> 'br_nf_core_fini' was here
> static inline void br_nf_core_fini(void) {}
> ^
>
> Caused by commit 34666d467cbf ("netfilter: bridge: move br_netfilter
> out of the core"). This build has CONFIG_BRIDGE_NETFILTER not set ...
>
> I have applied the following patch for today:
>
> From: Stephen Rothwell
> Date: Tue, 30 Sep 2014 13:09:09 +1000
> Subject: [PATCH] netfilter: bridge: don't build br_nf_core unless necessary
>
> Signed-off-by: Stephen Rothwell
> ---
> net/bridge/Makefile | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/net/bridge/Makefile b/net/bridge/Makefile
> index 5e3eac5dc8b9..eb653a225397 100644
> --- a/net/bridge/Makefile
> +++ b/net/bridge/Makefile
> @@ -6,12 +6,11 @@ obj-$(CONFIG_BRIDGE) += bridge.o
>
> bridge-y := br.o br_device.o br_fdb.o br_forward.o br_if.o br_input.o \
> br_ioctl.o br_stp.o br_stp_bpdu.o \
> - br_stp_if.o br_stp_timer.o br_netlink.o \
> - br_nf_core.o
> + br_stp_if.o br_stp_timer.o br_netlink.o
>
> bridge-$(CONFIG_SYSFS) += br_sysfs_if.o br_sysfs_br.o
>
> -obj-$(CONFIG_BRIDGE_NETFILTER) += br_netfilter.o
> +obj-$(CONFIG_BRIDGE_NETFILTER) += br_netfilter.o br_nf_core.o
>
> bridge-$(CONFIG_BRIDGE_IGMP_SNOOPING) += br_multicast.o br_mdb.o
>
> --
> 2.1.1
After whish I get this from an x86_64 allmodconfig build:
ERROR: "br_nf_core_fini" [net/bridge/bridge.ko] undefined!
ERROR: "br_netfilter_rtable_init" [net/bridge/bridge.ko] undefined!
ERROR: "br_nf_core_init" [net/bridge/bridge.ko] undefined!
So I gave up :-(
I have used the net-next tree from next-20140926 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH 0/5] fuse: handle release synchronously (v4)
On Fri, Sep 26, 2014 at 5:28 PM, Miklos Szeredi wrote: > [Adding CC's] > > On Thu, Sep 25, 2014 at 2:05 PM, Maxim Patlasov > wrote: > >> In short, the problem is that fuse_release (that's usually called on last >> user close(2)) sends FUSE_RELEASE to userspace and returns without waiting >> for ACK from userspace. Consequently, there is a gap when user regards the >> file released while userspace fuse is still working on it. An attempt to >> access the file from another node leads to complicated synchronization >> problems because the first node still "holds" the file. >> >> The patch-set resolves the problem by making fuse_release synchronous: >> wait for ACK from userspace for FUSE_RELEASE if the feature is ON. >> >> It must be emphasized that even if the feature is enabled (i.e. fuse_release >> is synchronous), nothing guarantees that fuse_release() will be called >> in the context of close(2). In fact, it may happen later, on last fput(). >> However, there are still a lot of use cases when close(2) is synchronous, >> so the feature must be regarded as an optimization maximizing chances of >> synchronous behaviour of close(2). > > Okay, we have the common case of close -> last-fput ->release. This > being synchronous is fine. Related cases are munmap(), and weird > corner cases including I/O on file descriptor being done in parallel > with close() in another thread. Synchronous behavior is also fine in > these cases, since the task calling the last fput() is in fact > responsible for releasing the file. > > And then we have the uncommon cases when fput() is called from > something unrelated. Take the following DoS example: malicious app > creates a socket loop (sockA is sent over sockB and sockB is sent over > sockA) and in addition it tacks a fuse fd onto one of the sockets. > The fuse fd is implemented to block forever on release. In this case > the loop will persist after the sockets are closed due to refcounting. > Later, a garbage collection is triggered from a completely unrelated > socket operation. This result in the unrelated task being blocked > forever. > > The simplest way to avoid such an attack is to make the sync-release > feature privileged. But even if it's privileged, the fact that > ->release can take a lot of time and a completely unrelated task could > be waiting for it to finish is not a good thing. > > So I'm wondering: could we have some way of distinguishing "good > release" from "bad release"? Maybe adding an fput_sync() variant that > passes an "sync" flag to ->release()? If we just concentrate on close(2), then there's a much simpler solution: in fuse_flush() check if file_count(file) is 1. If it is, then this is a final close and we can mark the FLUSH request as such with a flag (FUSE_FLUSH_FINAL). Userspace filesystem can act accordingly and may even return an error value to close(2). In this case we could even omit the RELEASE request as an optimization, since we know the file cannot be resurrected if this was the last reference. Do we need to be synchronous in any other case? E.g. munmap() comes to mind. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clk: rockchip: rk3288: i2s_frac adds flag to set parent's rate
The relation of i2s nodes as follows:
i2s_src 0 059400 0
i2s_frac 0 011289600 0
i2s_pre 0 011289600 0
sclk_i2s00 011289600 0
i2s0_clkout 0 011289600 0
hclk_i2s0 1 19900 0
sclk_i2s0 is the master clock, when to set rate of sclk_i2s0, should
allow to set its parent's rate, by add flag CLK_SET_RATE_PARENT for
"i2s_frac", "i2s_pre", "i2s0_clkout" and "sclk_i2s0".
Tested on rk3288 board using max98090, with command "aplay "
Change-Id: I12faad082566532b65a7de8c0a6845e1c17870e6
Signed-off-by: Jianqun
---
drivers/clk/rockchip/clk-rk3288.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index c770de0..baf19b4 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -301,15 +301,15 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
COMPOSITE(0, "i2s_src", mux_pll_src_cpll_gpll_p, 0,
RK3288_CLKSEL_CON(4), 15, 1, MFLAGS, 0, 7, DFLAGS,
RK3288_CLKGATE_CON(4), 1, GFLAGS),
- COMPOSITE_FRAC(0, "i2s_frac", "i2s_src", 0,
+ COMPOSITE_FRAC(0, "i2s_frac", "i2s_src", CLK_SET_RATE_PARENT,
RK3288_CLKSEL_CON(8), 0,
RK3288_CLKGATE_CON(4), 2, GFLAGS),
- MUX(0, "i2s_pre", mux_i2s_pre_p, 0,
+ MUX(0, "i2s_pre", mux_i2s_pre_p, CLK_SET_RATE_PARENT,
RK3288_CLKSEL_CON(4), 8, 2, MFLAGS),
- COMPOSITE_NODIV(0, "i2s0_clkout", mux_i2s_clkout_p, 0,
+ COMPOSITE_NODIV(0, "i2s0_clkout", mux_i2s_clkout_p, CLK_SET_RATE_PARENT,
RK3288_CLKSEL_CON(4), 12, 1, MFLAGS,
RK3288_CLKGATE_CON(4), 0, GFLAGS),
- GATE(SCLK_I2S0, "sclk_i2s0", "i2s_pre", 0,
+ GATE(SCLK_I2S0, "sclk_i2s0", "i2s_pre", CLK_SET_RATE_PARENT,
RK3288_CLKGATE_CON(4), 3, GFLAGS),
MUX(0, "spdif_src", mux_pll_src_cpll_gpll_p, 0,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
net/bridge/br_nf_core.c:77:1: error: expected identifier or '(' before '{' token
{
^
net/bridge/br_nf_core.c:88:12: error: redefinition of 'br_nf_core_init'
int __init br_nf_core_init(void)
^
In file included from net/bridge/br_nf_core.c:23:0:
net/bridge/br_private.h:762:19: note: previous definition of 'br_nf_core_init'
was here
static inline int br_nf_core_init(void) { return 0; }
^
net/bridge/br_nf_core.c:93:6: error: redefinition of 'br_nf_core_fini'
void br_nf_core_fini(void)
^
In file included from net/bridge/br_nf_core.c:23:0:
net/bridge/br_private.h:763:20: note: previous definition of 'br_nf_core_fini'
was here
static inline void br_nf_core_fini(void) {}
^
Caused by commit 34666d467cbf ("netfilter: bridge: move br_netfilter
out of the core"). This build has CONFIG_BRIDGE_NETFILTER not set ...
I have applied the following patch for today:
From: Stephen Rothwell
Date: Tue, 30 Sep 2014 13:09:09 +1000
Subject: [PATCH] netfilter: bridge: don't build br_nf_core unless necessary
Signed-off-by: Stephen Rothwell
---
net/bridge/Makefile | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/bridge/Makefile b/net/bridge/Makefile
index 5e3eac5dc8b9..eb653a225397 100644
--- a/net/bridge/Makefile
+++ b/net/bridge/Makefile
@@ -6,12 +6,11 @@ obj-$(CONFIG_BRIDGE) += bridge.o
bridge-y := br.o br_device.o br_fdb.o br_forward.o br_if.o br_input.o \
br_ioctl.o br_stp.o br_stp_bpdu.o \
- br_stp_if.o br_stp_timer.o br_netlink.o \
- br_nf_core.o
+ br_stp_if.o br_stp_timer.o br_netlink.o
bridge-$(CONFIG_SYSFS) += br_sysfs_if.o br_sysfs_br.o
-obj-$(CONFIG_BRIDGE_NETFILTER) += br_netfilter.o
+obj-$(CONFIG_BRIDGE_NETFILTER) += br_netfilter.o br_nf_core.o
bridge-$(CONFIG_BRIDGE_IGMP_SNOOPING) += br_multicast.o br_mdb.o
--
2.1.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
[PATCH 1/3] x86: Bugfix bit-rot in the calling of legacy_cache_size
legacy_cache_size is used by certain processors to report the
size of cache. Currently only X86_VENDOR_UNKNOWN could call
default_init() => cpu_detect_cache_sizes() => legacy_cache_size()
Make an update to identify_cpu to make an explicit call to default_init()
We want to do this since some processors that report vendor strings via
cpuid also want to run legacy_cache_size callbacks - which won't happen
since init_intel() init_amd() and friends take the place of default_init()
and don't themselves make explicit calls to legacy_cache_size.
Also current code has an
#ifdef CONFIG_X86_64
cpu_detect_cache_sizes(c);
#endif
where cpu_detect_cache_sizes calls legacy_cache_size(); is typically
defined inside of a CONFIG_X86_32
#ifdef CONFIG_X86_32
.legacy_cache_size = centaur_size_cache,
#endif
#ifdef CONFIG_X86_32
.legacy_cache_size = intel_size_cache,
#endif
#ifdef CONFIG_X86_32
.legacy_cache_size = amd_size_cache,
#endif
Signed-off-by: Bryan O'Donoghue
---
arch/x86/kernel/cpu/common.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index e4ab2b4..53a33fa 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -67,9 +67,8 @@ void __init setup_cpu_local_masks(void)
static void default_init(struct cpuinfo_x86 *c)
{
-#ifdef CONFIG_X86_64
cpu_detect_cache_sizes(c);
-#else
+
/* Not much we can do here... */
/* Check if at least it has cpuid */
if (c->cpuid_level == -1) {
@@ -79,7 +78,6 @@ static void default_init(struct cpuinfo_x86 *c)
else if (c->x86 == 3)
strcpy(c->x86_model_id, "386");
}
-#endif
}
static const struct cpu_dev default_cpu = {
@@ -874,6 +872,15 @@ static void identify_cpu(struct cpuinfo_x86 *c)
#endif
/*
+* If c_x86_vendor != X86_VENDOR_UNKNOWN i.e. a known vendor then
+* there's a vendor specific c_init()
+*
+* Even still Intel, AMD and VIA make use of legacy_cache_size which
+* is reachable only through default_init right now
+*/
+ if (this_cpu->c_x86_vendor != X86_VENDOR_UNKNOWN)
+ default_init(c);
+ /*
* Vendor-specific initialization. In this section we
* canonicalize the feature flags, meaning if there are
* features a certain CPU supports which CPUID doesn't
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Quark X1000 Cache/TLB reporting/fixes
First patch: legacy_cache_size is currently not reachable code from kernels compiled CONFIG_X86_32 despite most/all legacy_cache_size code being ifdef'd CONFIG_X86_32. Added to which for Intel, AMD and VIA processors that return a valid vendor string via cpuid and hook code into c_init and friends the legacy_cache_size code won't run. So the first patch adds in a call to default_init when the x86_vendor is valid i.e. when x86_vendor != X86_VENDOR_UNKNOWN. This ensures for processors that report a vendor string like "GenuineIntel" that the legacy_cache_size code will still run. Second patch: Quark X1000 contains a 16k 4-way set associative unified L1 cache with 256 sets. The second patch gets Quark X1000 reporting 16k of cache in-line with other legacy reporting processors like PIII Tualatin Third patch: Final patch adds a comment to arch/x86/kernel/setup.c. Quark SoC X1000 advertises PGE via cpuid but doesn't infact implement the functionality to support global pages in the TLB. Linux will by default toggle CR4.PGE for processors that advertise PGE A fix is already in place to ensure __flush_tlb() as opposed to __flush_tlb_all() is called during normal operation. Since __flush_tlb() just rewrites CR3 there's no need to take any further action on Quark after writing CR3 in setup.c to flush the TLB. We comment that behaviour. Note cpu_has_pge() will be nuked later in the boot but, changing the value at this phase of the boot is considered harmful and so instead we have agreed to comment the existing code Bryan O'Donoghue (3): x86: Bugfix bit-rot in the calling of legacy_cache_size x86: Quark: Update cache reporting, add Quark SoC X1000 string x86: Quark: Comment setup_arch for TLB/PGE bugfix arch/x86/kernel/cpu/common.c | 13 ++--- arch/x86/kernel/cpu/intel.c | 20 ++-- arch/x86/kernel/setup.c | 12 3 files changed, 40 insertions(+), 5 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] x86: Quark: Update cache reporting, add Quark SoC X1000 string
Adds a path for legacy_cache_size to get a Quark SoC X1000 cache size
Update init_intel to take account of PIII Tualatin and Quark X1000
reporting cache size via legacy_cache_size
Add string to family/model structure for completeness and better
output of /proc/cpuinfo
Signed-off-by: Bryan O'Donoghue
---
arch/x86/kernel/cpu/intel.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 50ce751..686eae7 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -396,7 +396,13 @@ static void init_intel(struct cpuinfo_x86 *c)
#endif
}
- l2 = init_intel_cacheinfo(c);
+
+ /* legacy_cache may have provided and cache_size already if not probe */
+ if (c->x86_cache_size == 0)
+ l2 = init_intel_cacheinfo(c);
+ else
+ l2 = c->x86_cache_size;
+
if (c->cpuid_level > 9) {
unsigned eax = cpuid_eax(10);
/* Check for version and the number of counters */
@@ -500,6 +506,15 @@ static unsigned int intel_size_cache(struct cpuinfo_x86
*c, unsigned int size)
*/
if ((c->x86 == 6) && (c->x86_model == 11) && (size == 0))
size = 256;
+
+
+ /*
+* Intel Quark SoC X1000 contains a 4-way set associative
+* 16K cache with a 16 byte cache line and 256 lines per tag
+*/
+ if ((c->x86 == 5) && (c->x86_model == 9))
+ size = 16;
+
return size;
}
#endif
@@ -701,7 +716,8 @@ static const struct cpu_dev intel_cpu_dev = {
[3] = "OverDrive PODP5V83",
[4] = "Pentium MMX",
[7] = "Mobile Pentium 75 - 200",
- [8] = "Mobile Pentium MMX"
+ [8] = "Mobile Pentium MMX",
+ [9] = "Quark SoC X1000",
}
},
{ .family = 6, .model_names =
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] x86: Quark: Comment setup_arch for TLB/PGE bugfix
Quark X1000 requires CR3 to be rewritten to flush TLB entries irrespective of the PGE bits in CR4 or PTE.PGE Add a comment to setup_arch to indicate that the code load_cr3(swapper_pg_dir); __flush_tlb_all(); Will already have flushed the TLB @ the CR3 reload allowing us to skip over a potential if/else for Quark. This comment clearly states the bug, the behaviour we rely on and the reason why we only do it this way - one time. Later on cpu_has_pge() will be false due to a fixup in intel_init_early() and __flush_tlb_all() will work as expected from that point onwards Signed-off-by: Bryan O'Donoghue --- arch/x86/kernel/setup.c | 12 1 file changed, 12 insertions(+) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 41ead8d..98b6660 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -878,6 +878,18 @@ void __init setup_arch(char **cmdline_p) initial_page_table + KERNEL_PGD_BOUNDARY, KERNEL_PGD_PTRS); + /* +* Locate the page directory and flush the TLB. +* +* On Quark X1000 CPUs we still have the PGE bit incorrectly set +* due to a processor erratum, so __flush_tlb_all() is not yet +* doing what it says. Fortunately we have a cr3 load here, +* which is what is needed on this processor to flush TLBs, so +* there's no need to add a Quark X1000 quirk here. +* +* early_init_intel will unset the X86_FEATURE_PGE flag later +* and __flush_tlb_all() will flush via cr3 +*/ load_cr3(swapper_pg_dir); __flush_tlb_all(); #else -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V1] regulator: DA9211 : Fix a bug in update of mask bit
This is a patch for fixing a bug about mask bit operation.
Signed-off-by: James Ban
---
This patch is relative to linux-next repository tag next-20140926.
drivers/regulator/da9211-regulator.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/da9211-regulator.c
b/drivers/regulator/da9211-regulator.c
index f47adf3..c78d210 100644
--- a/drivers/regulator/da9211-regulator.c
+++ b/drivers/regulator/da9211-regulator.c
@@ -376,7 +376,7 @@ static int da9211_regulator_init(struct da9211 *chip)
if (chip->chip_irq != 0) {
ret = regmap_update_bits(chip->regmap,
- DA9211_REG_MASK_B, DA9211_M_OV_CURR_A << i, 1);
+ DA9211_REG_MASK_B, DA9211_M_OV_CURR_A << i, 0);
if (ret < 0) {
dev_err(chip->dev,
"Failed to update mask reg: %d\n", ret);
--
end-of-patch for regulator: DA9211 : Fix a bug in update of mask bit V1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 v2] driver:mtd:spi-nor: Add Micron quad I/O support
On Monday, September 29, 2014 at 02:30:04 AM, bpqw wrote: > >> For Micron spi norflash,you can enable Quad spi transfer by clear > >> EVCR(Enhanced Volatile Configuration Register) Quad I/O protocol bit. > > > >OK, this information is nice and all, but what does this patch do? I can't > >learn this information from the commit message as it is, can I ? And , > >the purpose of the commit message is exactly to summarize the change the > >patch implements. > > you don't understand what purpose of this patch! Well, I dare to say, reacting to feedback like you just did won't make you many allies around here. > just as subject and commit > message described, it is for enable Micron Quad spi transfer mode. I understand the subject part. The commit message, on the other hand, just states that it is possible to frob with a certain register to achieve a certain effect ; the commit message does not state what this patch does or how is the patch useful. Does this patch enable the bit or does it disable the bit ? I cannot tell without looking into the code , I really have no clue just by reading the subject and the commit message. > do you > read the spi-nor.c file? No, I didn't even look at the code. > please pay attention to the set_quad_mode() > function. No, what set_quad_mode_function() are you talking about ... > by the way,I can add more commit message for it,but I think it is > redundant,don't need. The commit message shall state what the patch does in the first place, what the hardware can do is ortogonal to that. The commit message can be as short as: The hardware supports 4-bit I/O when bit FOO is set in register BAR. This patch adds function that sets bit FOO in register BAR to enable 4-bit I/O if condition BAZ and QUUX are met. Then I do not even have to look at the code if I want to just get the high-level overview of what the patch does. If I want to know the details, I will look into the code. Do you know what I'm getting at ? [...] Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] toshiba_acpi: Adapt kbd_bl_timeout_store to the new kbd type
With the introduccion of the new keyboard backlight
implementation, the *_timeout_store function is
broken, as it only supports the first kbd_type.
This patch adapt such function for the new kbd_type,
as well as convert from using sscanf to kstrtoint.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 5d509ea..13ee56b 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1453,18 +1453,35 @@ static ssize_t toshiba_kbd_bl_timeout_store(struct
device *dev,
const char *buf, size_t count)
{
struct toshiba_acpi_dev *toshiba = dev_get_drvdata(dev);
- int time = -1;
+ int time;
+ int ret;
+
+ ret = kstrtoint(buf, 0, );
+ if (ret)
+ return ret;
- if (sscanf(buf, "%i", ) != 1 && (time < 0 || time > 60))
+ if (time < 1 || time > 60)
return -EINVAL;
- /* Set the Keyboard Backlight Timeout: 0-60 seconds */
- if (time != -1 && toshiba->kbd_time != time) {
+ /* Set the Keyboard Backlight Timeout: 1-60 seconds */
+
+ /* Only make a change if the actual timeout has changed */
+ if (toshiba->kbd_time != time) {
+ /* Shift the time to "base time" (0x3c == 60 seconds)*/
time = time << HCI_MISC_SHIFT;
- time = (toshiba->kbd_mode == SCI_KBD_MODE_AUTO) ?
- time + 1 : time + 2;
- if (toshiba_kbd_illum_status_set(toshiba, time) < 0)
- return -EIO;
+ /* OR the "base time" to the actual method format */
+ if (toshiba->kbd_type == 1) {
+ /* Type 1 requires the oposite mode */
+ time |= SCI_KBD_MODE_FNZ;
+ } else if (toshiba->kbd_type == 2) {
+ /* Type 2 requires the actual mode */
+ time |= SCI_KBD_MODE_AUTO;
+ }
+
+ ret = toshiba_kbd_illum_status_set(toshiba, time);
+ if (ret)
+ return ret;
+
toshiba->kbd_time = time >> HCI_MISC_SHIFT;
}
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/netfilter/nfnetlink.c between commit cbb8125eb40b ("netfilter:
nfnetlink: deliver netlink errors on batch completion") from the net
tree and commit fc04733a1a71 ("netfilter: nfnetlink: use original
skbuff when committing/aborting") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/netfilter/nfnetlink.c
index f37f0716a9fc,f77d3f7f22b5..
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@@ -380,8 -333,7 +380,8 @@@ replay
* original skb.
*/
if (err == -EAGAIN) {
+ nfnl_err_reset(_list);
- ss->abort(skb);
+ ss->abort(oskb);
nfnl_unlock(subsys_id);
kfree_skb(nskb);
goto replay;
@@@ -418,11 -357,10 +418,11 @@@ ack
}
done:
if (success && done)
- ss->commit(skb);
+ ss->commit(oskb);
else
- ss->abort(skb);
+ ss->abort(oskb);
+ nfnl_err_deliver(_list, oskb);
nfnl_unlock(subsys_id);
kfree_skb(nskb);
}
signature.asc
Description: PGP signature
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/usb/r8152.c between commit 445f7f4d6262 ("r8152: fix the
carrier off when autoresuming") from the net tree and commit
b209af9981ee ("r8152: check code with checkpatch.pl") from the net-next
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/usb/r8152.c
index e0394427e372,a4d4c4a1354f..
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@@ -2067,10 -2080,11 +2097,10 @@@ static void rtl_disable(struct r8152 *t
for (i = 0; i < 1000; i++) {
if (ocp_read_word(tp, MCU_TYPE_PLA, PLA_TCR0) & TCR0_TX_EMPTY)
break;
- mdelay(1);
+ usleep_range(1000, 2000);
}
- for (i = 0; i < RTL8152_MAX_RX; i++)
- usb_kill_urb(tp->rx_info[i].urb);
+ rtl_stop_rx(tp);
rtl8152_nic_reset(tp);
}
@@@ -3131,12 -3211,13 +3229,13 @@@ static int rtl8152_resume(struct usb_in
} else {
tp->rtl_ops.up(tp);
rtl8152_set_speed(tp, AUTONEG_ENABLE,
- tp->mii.supports_gmii ? SPEED_1000 : SPEED_100,
- DUPLEX_FULL);
+ tp->mii.supports_gmii ?
+ SPEED_1000 : SPEED_100,
+ DUPLEX_FULL);
+ tp->speed = 0;
+ netif_carrier_off(tp->netdev);
+ set_bit(WORK_ENABLE, >flags);
}
- tp->speed = 0;
- netif_carrier_off(tp->netdev);
- set_bit(WORK_ENABLE, >flags);
usb_submit_urb(tp->intr_urb, GFP_KERNEL);
}
signature.asc
Description: PGP signature
[PATCH 1/1 v3] driver:mtd:spi-nor: Add Micron quad I/O support
For Micron spi norflash,enables or disables quad I/O
protocol ,which controled by EVCR(Enhanced
Volatile Configuration Register) Quad I/O
protocol bit 7.When EVCR bit 7 is reset to 0,
the spi norflash will operate in quad I/O following
the next WRITE ENHANCED VOLATILE CONFIGURATION
command.
Signed-off-by: bean huo
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
v2-v3:directly use the reurning error value of
read_reg and write_reg,instead of -EINVAL.
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..486b167 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor)
+{
+ int ret, val;
+
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
+ ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
+ if (ret < 0) {
+ dev_err(nor->dev,
+ "error while writing EVCR register\n");
+ return ret;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+ if (val & EVCR_QUAD_EN_MICRON) {
+ dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
{
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor->dev, "Micron quad-read not enabled\n");
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] sysfs - allow attributes to request write buffer be pre-allocated.
md/raid allows metadata management to be performed in user-space.
A various times, particularly on device failure, the metadata needs
to be updated before further writes can be permitted.
This means that the user-space program which updates metadata much
not block on writeout, and so must not allocate memory.
mlockall(MCL_CURRENT|MCL_FUTURE) and pre-allocation can avoid all
memory allocation issues for user-memory, but that does not help
kernel memory.
Several kernel objects can be pre-allocated. e.g. files opened before
any writes to the array are permitted.
However some kernel allocation happen in places that cannot be
pre-allocated.
In particular, writes to sysfs files (to tell md that it can now
allow writes to the array) allocate a buffer using GFP_KERNEL.
This patch allows attributes to be marked as "PREALLOC". In that case
the maximal buffer is allocated when the file is opened, and then used
on each write instead of allocating a new buffer.
As the same buffer is now shared for all writes on the same file
description, the mutex is extended to cover full use of the buffer
including the copy_from_user().
The new __ATTR_PREALLOC() 'or's a new flag in to the 'mode', which is
inspected by sysfs_add_file_mode_ns to determine if the file should be
marked as requiring prealloc.
Signed-off-by: NeilBrown
---
fs/kernfs/file.c | 35 ---
fs/sysfs/file.c| 31 ---
include/linux/kernfs.h |2 ++
include/linux/sysfs.h |9 +
4 files changed, 59 insertions(+), 18 deletions(-)
diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
index 4429d6d9217f..73bd5ed143cd 100644
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -278,16 +278,12 @@ static ssize_t kernfs_fop_write(struct file *file, const
char __user *user_buf,
len = min_t(size_t, count, PAGE_SIZE);
}
- buf = kmalloc(len + 1, GFP_KERNEL);
+ buf = of->buf;
+ if (!buf)
+ buf = kmalloc(len + 1, GFP_KERNEL);
if (!buf)
return -ENOMEM;
- if (copy_from_user(buf, user_buf, len)) {
- len = -EFAULT;
- goto out_free;
- }
- buf[len] = '\0';/* guarantee string termination */
-
/*
* @of->mutex nests outside active ref and is just to ensure that
* the ops aren't called concurrently for the same open file.
@@ -299,19 +295,27 @@ static ssize_t kernfs_fop_write(struct file *file, const
char __user *user_buf,
goto out_free;
}
+ if (copy_from_user(buf, user_buf, len)) {
+ len = -EFAULT;
+ goto out_unlock;
+ }
+ buf[len] = '\0';/* guarantee string termination */
+
ops = kernfs_ops(of->kn);
if (ops->write)
len = ops->write(of, buf, len, *ppos);
else
len = -EINVAL;
- kernfs_put_active(of->kn);
- mutex_unlock(>mutex);
-
if (len > 0)
*ppos += len;
+
+out_unlock:
+ kernfs_put_active(of->kn);
+ mutex_unlock(>mutex);
out_free:
- kfree(buf);
+ if (buf != of->buf)
+ kfree(buf);
return len;
}
@@ -685,6 +689,13 @@ static int kernfs_fop_open(struct inode *inode, struct
file *file)
*/
of->atomic_write_len = ops->atomic_write_len;
+ if (ops->prealloc) {
+ int len = of->atomic_write_len ?: PAGE_SIZE;
+ of->buf = kmalloc(len + 1, GFP_KERNEL);
+ error = -ENOMEM;
+ if (!of->buf)
+ goto err_free;
+ }
/*
* Always instantiate seq_file even if read access doesn't use
* seq_file or is not requested. This unifies private data access
@@ -715,6 +726,7 @@ static int kernfs_fop_open(struct inode *inode, struct file
*file)
err_close:
seq_release(inode, file);
err_free:
+ kfree(of->buf);
kfree(of);
err_out:
kernfs_put_active(kn);
@@ -728,6 +740,7 @@ static int kernfs_fop_release(struct inode *inode, struct
file *filp)
kernfs_put_open_node(kn, of);
seq_release(inode, filp);
+ kfree(of->buf);
kfree(of);
return 0;
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index e9ef59b3abb1..4a959d231b43 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -184,6 +184,17 @@ static const struct kernfs_ops sysfs_file_kfops_rw = {
.write = sysfs_kf_write,
};
+static const struct kernfs_ops sysfs_prealloc_kfops_wo = {
+ .write = sysfs_kf_write,
+ .prealloc = true,
+};
+
+static const struct kernfs_ops sysfs_prealloc_kfops_rw = {
+ .seq_show = sysfs_kf_seq_show,
+ .write = sysfs_kf_write,
+ .prealloc = true,
+};
+
static const struct kernfs_ops sysfs_bin_kfops_ro = {
.read = sysfs_kf_bin_read,
};
@@ -222,13 +233,19 @@ int
[PATCH 2/2] sysfs/kernfs: make read requests on pre-alloc files use the buffer.
To match the previous patch which used the pre-alloc buffer for
writes, this patch causes reads to use the same buffer.
This is not strictly necessary as the current seq_read() will allocate
on first read, so user-space can trigger the required pre-alloc. But
consistency is valuable.
The read function is somewhat simpler than seq_read() and, for example,
does not support reading from an offset into the file: reads must be
at the start of the file.
As the buffer is shared with writes and other reads, the mutex is
extended to cover the copy_to_user.
Signed-off-by: NeilBrown
---
fs/kernfs/file.c | 17 ++---
fs/sysfs/file.c | 28
2 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/fs/kernfs/file.c b/fs/kernfs/file.c
index 73bd5ed143cd..7072240604f5 100644
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -189,7 +189,9 @@ static ssize_t kernfs_file_direct_read(struct
kernfs_open_file *of,
const struct kernfs_ops *ops;
char *buf;
- buf = kmalloc(len, GFP_KERNEL);
+ buf = of->buf;
+ if (!buf)
+ buf = kmalloc(len, GFP_KERNEL);
if (!buf)
return -ENOMEM;
@@ -210,21 +212,22 @@ static ssize_t kernfs_file_direct_read(struct
kernfs_open_file *of,
else
len = -EINVAL;
- kernfs_put_active(of->kn);
- mutex_unlock(>mutex);
-
if (len < 0)
- goto out_free;
+ goto out_unlock;
if (copy_to_user(user_buf, buf, len)) {
len = -EFAULT;
- goto out_free;
+ goto out_unlock;
}
*ppos += len;
+ out_unlock:
+ kernfs_put_active(of->kn);
+ mutex_unlock(>mutex);
out_free:
- kfree(buf);
+ if (buf != of->buf)
+ kfree(buf);
return len;
}
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 4a959d231b43..3f7e4d341546 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -102,6 +102,18 @@ static ssize_t sysfs_kf_bin_read(struct kernfs_open_file
*of, char *buf,
return battr->read(of->file, kobj, battr, buf, pos, count);
}
+/* kernfs read callback for regular sysfs files with pre-alloc */
+static ssize_t sysfs_kf_read(struct kernfs_open_file *of, char *buf,
+size_t count, loff_t pos)
+{
+ const struct sysfs_ops *ops = sysfs_file_ops(of->kn);
+ struct kobject *kobj = of->kn->parent->priv;
+
+ if (pos)
+ return 0;
+ return ops->show(kobj, of->kn->priv, buf);
+}
+
/* kernfs write callback for regular sysfs files */
static ssize_t sysfs_kf_write(struct kernfs_open_file *of, char *buf,
size_t count, loff_t pos)
@@ -184,13 +196,18 @@ static const struct kernfs_ops sysfs_file_kfops_rw = {
.write = sysfs_kf_write,
};
+static const struct kernfs_ops sysfs_prealloc_kfops_ro = {
+ .read = sysfs_kf_read,
+ .prealloc = true,
+};
+
static const struct kernfs_ops sysfs_prealloc_kfops_wo = {
.write = sysfs_kf_write,
.prealloc = true,
};
static const struct kernfs_ops sysfs_prealloc_kfops_rw = {
- .seq_show = sysfs_kf_seq_show,
+ .read = sysfs_kf_read,
.write = sysfs_kf_write,
.prealloc = true,
};
@@ -238,9 +255,12 @@ int sysfs_add_file_mode_ns(struct kernfs_node *parent,
ops = _prealloc_kfops_rw;
else
ops = _file_kfops_rw;
- } else if (sysfs_ops->show)
- ops = _file_kfops_ro;
- else if (sysfs_ops->store) {
+ } else if (sysfs_ops->show) {
+ if (mode & SYSFS_PREALLOC)
+ ops = _prealloc_kfops_ro;
+ else
+ ops = _file_kfops_ro;
+ } else if (sysfs_ops->store) {
if (mode & SYSFS_PREALLOC)
ops = _prealloc_kfops_wo;
else
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Allow access to sysfs attributes without mem allocations.
Hi Tejun, is this closer to what you would like? I do really need this functionality, but I honestly don't like this patch. The need to identify just which attributes need special care seems backwards to me. 1/ it is the process (which has called mlock etc) which needs special care, more than the attribute. Everything that process does needs to avoid allocating memory, whether that this is particularly related to enabling write-out or not. 2/ It is also backwards because the vast majority of sysfs attributes only support bool/enum/int which means at most 23 chars including sign and newline (maybe more for reads if the read provides a list of options). So almost everything doesn't need an allocation at all - just some on-stack space. I would be quite happy to identify those attributes that may need care when accessing and could possibly supports read or write > 128 characters, because there wouldn't be any. I also don't like this approach because we end up allocating 2 pages for the buffer, as we have to ask for "PAGE_SIZE+1" bytes, for the hypothetical case that an important attribute actually requires a full PAGE_SIZE write... Would you be happy to have all specially identified attributes be limited to 127 characters IO max? Then I would just use an on-stack buffer for those which would remove the allocation and simplify some of the code. Thanks, NeilBrown --- NeilBrown (2): sysfs - allow attributes to request write buffer be pre-allocated. sysfs/kernfs: make read requests on pre-alloc files use the buffer. fs/kernfs/file.c | 52 +++ fs/sysfs/file.c| 53 +--- include/linux/kernfs.h |2 ++ include/linux/sysfs.h |9 4 files changed, 90 insertions(+), 26 deletions(-) -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] toshiba_acpi: Rename hci_raw to tci_raw
The function name hci_raw was used before to reflect
a raw (read/write) call to Toshiba's Hardware
Configuration Interface (HCI), however, since the
introduction of the System Configuration Interface
(SCI), that "name" no longer applies.
This patch changes the name of that function to
tci_raw (for Toshiba Configuration Interface), and
change the comments about it.
Also, the HCI_WORDS definition was changed to TCI_RAW,
to better reflect that we're no longer using pure HCI
calls, but a combination of HCI and SCI, which form
part of the Toshiba Configuration Interface.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 119 ++--
1 file changed, 60 insertions(+), 59 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index edd8f3d..ed3671c 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -71,7 +71,8 @@ MODULE_LICENSE("GPL");
/* Toshiba ACPI method paths */
#define METHOD_VIDEO_OUT "\\_SB_.VALX.DSSX"
-/* Toshiba HCI interface definitions
+/* The Toshiba configuration interface is composed of the HCI and the SCI,
+ * which are defined as follows:
*
* HCI is Toshiba's "Hardware Control Interface" which is supposed to
* be uniform across all their models. Ideally we would just call
@@ -84,7 +85,7 @@ MODULE_LICENSE("GPL");
* conceal differences in hardware between different models.
*/
-#define HCI_WORDS 6
+#define TCI_WORDS 6
/* operations */
#define HCI_SET0xff00
@@ -274,22 +275,22 @@ static int write_acpi_int(const char *methodName, int val)
return (status == AE_OK) ? 0 : -EIO;
}
-/* Perform a raw HCI call. Here we don't care about input or output buffer
- * format.
+/* Perform a raw configuration call. Here we don't care about input or output
+ * buffer format.
*/
-static acpi_status hci_raw(struct toshiba_acpi_dev *dev,
- const u32 in[HCI_WORDS], u32 out[HCI_WORDS])
+static acpi_status tci_raw(struct toshiba_acpi_dev *dev,
+ const u32 in[TCI_WORDS], u32 out[TCI_WORDS])
{
struct acpi_object_list params;
- union acpi_object in_objs[HCI_WORDS];
+ union acpi_object in_objs[TCI_WORDS];
struct acpi_buffer results;
- union acpi_object out_objs[HCI_WORDS + 1];
+ union acpi_object out_objs[TCI_WORDS + 1];
acpi_status status;
int i;
- params.count = HCI_WORDS;
+ params.count = TCI_WORDS;
params.pointer = in_objs;
- for (i = 0; i < HCI_WORDS; ++i) {
+ for (i = 0; i < TCI_WORDS; ++i) {
in_objs[i].type = ACPI_TYPE_INTEGER;
in_objs[i].integer.value = in[i];
}
@@ -300,7 +301,7 @@ static acpi_status hci_raw(struct toshiba_acpi_dev *dev,
status = acpi_evaluate_object(dev->acpi_dev->handle,
(char *)dev->method_hci, ,
);
- if ((status == AE_OK) && (out_objs->package.count <= HCI_WORDS)) {
+ if ((status == AE_OK) && (out_objs->package.count <= TCI_WORDS)) {
for (i = 0; i < out_objs->package.count; ++i) {
out[i] = out_objs->package.elements[i].integer.value;
}
@@ -318,9 +319,9 @@ static acpi_status hci_raw(struct toshiba_acpi_dev *dev,
static acpi_status hci_write1(struct toshiba_acpi_dev *dev, u32 reg,
u32 in1, u32 *result)
{
- u32 in[HCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
- u32 out[HCI_WORDS];
- acpi_status status = hci_raw(dev, in, out);
+ u32 in[TCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
+ u32 out[TCI_WORDS];
+ acpi_status status = tci_raw(dev, in, out);
*result = (status == AE_OK) ? out[0] : HCI_FAILURE;
return status;
}
@@ -328,9 +329,9 @@ static acpi_status hci_write1(struct toshiba_acpi_dev *dev,
u32 reg,
static acpi_status hci_read1(struct toshiba_acpi_dev *dev, u32 reg,
u32 *out1, u32 *result)
{
- u32 in[HCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 };
- u32 out[HCI_WORDS];
- acpi_status status = hci_raw(dev, in, out);
+ u32 in[TCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 };
+ u32 out[TCI_WORDS];
+ acpi_status status = tci_raw(dev, in, out);
*out1 = out[2];
*result = (status == AE_OK) ? out[0] : HCI_FAILURE;
return status;
@@ -339,9 +340,9 @@ static acpi_status hci_read1(struct toshiba_acpi_dev *dev,
u32 reg,
static acpi_status hci_write2(struct toshiba_acpi_dev *dev, u32 reg,
u32 in1, u32 in2, u32 *result)
{
- u32 in[HCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 };
- u32 out[HCI_WORDS];
- acpi_status status = hci_raw(dev, in, out);
+ u32 in[TCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 };
+ u32
Re: Removing shared subtrees?
On Mon, Sep 29, 2014 at 7:21 PM, Al Viro wrote: > On Mon, Sep 29, 2014 at 06:24:05PM -0700, Andy Lutomirski wrote: >> On Mon, Sep 29, 2014 at 6:14 PM, Al Viro wrote: >> > On Mon, Sep 29, 2014 at 05:36:27PM -0700, Andy Lutomirski wrote: >> > >> >> Ideally it would leave them around until the whole subtree had no >> >> references, at which point /mnt and everything under it would >> >> disappear with no side effects, because it has no references. >> > >> > So, assuming you've got a stuck NFS mount with a bunch of local stuff >> > bound on top of it, in your ideal we'd have the latter all remaining >> > mounted until the server comes back. Lovely, that... >> >> No, not at all. > > Er... How so? /mnt is stuck NFS. /mnt/foo/bar and /mnt/foo/barf have > /dev/sda1 and /dev/sda2 mounted on them. Both are currently not busy. > /mnt is - there's that shell trying to expand *.c in /mnt/splat, sitting > around blocked with opened directory in its descriptor table. > > Just how would your ideal prevent sda1 and sda2 staying mounted? You can't > say umount /mnt/foo/bar; it'll get blocked trying to revalidate foo and > waiting for server to reply. In real world you can say umount -l /mnt and > be done with that - everything in there becomes detached, what used to be > /mnt stays alive (but not mounted on /mnt anymore) until it ceases to be > busy. What used to be /mnt/foo/bar and /mnt/foo/barf end up shut down > immediately (what with not being busy). In your ideal they would stay around > until the "whole subtree" (of what?) loses all references, i.e. until that > shell closes opened directory. I don't want /mnt/foo/far to stay mounted. I do, however, want their peers, if any, to stay mounted *if /mnt is the root of a shared recursive bind mount*. > >> Let me try this one more time: >> >> I don't *care* whether MNT_DETACH unmounts submounts immediately or >> when all the references are finally gone. I didn't read the docs or >> the code to see which is the case *because I don't care*. >> >> I think it's somewhere between ridiculous and flat-out broken that >> MNT_DETACH of the *root* of a shared subtree *propagates* the unmount >> of submounts to the parent of the shared subtree. This is IMO >> completely bogus. > > Parent in which sense? Try to experiment with this: mount something on > /tmp/foo, then mount --rbind /tmp/foo /mnt/foo, mount something on /mnt/bar > and /tmp/bar and umount -l /mnt/foo. Then think what does and does not > happen. > >> IOW, if I do: >> >> mount --make-rshared / >> mount --rbind / /mnt >> umount -l /mnt/dev >> >> then I fully expect /dev to be unmounted (although I think that this >> is a misfeature). >> >> But I did: >> >> mount --make-rshared / >> mount --rbind / /mnt >> umount -l /mnt <- the ROOT of the fscking shared subtree >> >> And /dev got unmounted. How does this make any sense at all? > > Sigh... umount -l /mnt *includes* unmounting /mnt/dev. Which you > do expect to take /dev out. I expect: mount --rbind / /mnt umount -l /mnt/dev to detach /dev. I expect: mount --rbind / /mnt umount -l /mnt to have no net effect. Another way of thinking about this would be that I would expect the umount -l to propogate as a unit rather than propagating as a bunch of individual unmounts. For example: mount --rbind / /mnt umount -l /mnt/dev means "detach /mnt/dev from /mnt and, due to sharing, detach /dev from /" whereas mount --rbind / /mnt umount -l /mnt means "detach /mnt from /" but does not unmount / or other things in /. IOW MNT_DETACH should only propagate detach of submounts if a umount without MNT_DETACH would propagate. In this case, mount --rbind / /mnt; umount /mnt would either fail with -EBUSY or *not* propagate because it's the root of the shared subtree. Anyway, improving the MNT_DETACH docs to recommend doing MS_PRIVATE first if you're just trying to remove an rbind would solve most of the problem. In any event, I still don't understand why we have shared recursive bind mounts in the first place. What are they used for that wouldn't be better served by slave mounts? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] toshiba_acpi: Unify return codes prefix from HCI/SCI to TOS
The return codes are split in between HCI/SCI prefixes,
but they are shared (used) by both interfaces, mixing
hci_read/write calls with SCI_* return codes, and
sci_read/write calls with HCI_* ones.
This patch changes the prefix of the return codes
definitions, dropping the HCI/SCI naming and instead
replacing it with TOS (for TOShiba).
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 143 ++--
1 file changed, 72 insertions(+), 71 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index ed3671c..589a858 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -96,17 +96,18 @@ MODULE_LICENSE("GPL");
#define SCI_SET0xf400
/* return codes */
-#define HCI_SUCCESS0x
-#define HCI_FAILURE0x1000
-#define HCI_NOT_SUPPORTED 0x8000
-#define HCI_EMPTY 0x8c00
-#define HCI_DATA_NOT_AVAILABLE 0x8d20
-#define HCI_NOT_INITIALIZED0x8d50
-#define SCI_OPEN_CLOSE_OK 0x0044
-#define SCI_ALREADY_OPEN 0x8100
-#define SCI_NOT_OPENED 0x8200
-#define SCI_INPUT_DATA_ERROR 0x8300
-#define SCI_NOT_PRESENT0x8600
+#define TOS_SUCCESS0x
+#define TOS_OPEN_CLOSE_OK 0x0044
+#define TOS_FAILURE0x1000
+#define TOS_NOT_SUPPORTED 0x8000
+#define TOS_ALREADY_OPEN 0x8100
+#define TOS_NOT_OPENED 0x8200
+#define TOS_INPUT_DATA_ERROR 0x8300
+#define TOS_WRITE_PROTECTED0x8400
+#define TOS_NOT_PRESENT0x8600
+#define TOS_FIFO_EMPTY 0x8c00
+#define TOS_DATA_NOT_AVAILABLE 0x8d20
+#define TOS_NOT_INITIALIZED0x8d50
/* registers */
#define HCI_FAN0x0004
@@ -322,7 +323,7 @@ static acpi_status hci_write1(struct toshiba_acpi_dev *dev,
u32 reg,
u32 in[TCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
u32 out[TCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
- *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+ *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
return status;
}
@@ -333,7 +334,7 @@ static acpi_status hci_read1(struct toshiba_acpi_dev *dev,
u32 reg,
u32 out[TCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
*out1 = out[2];
- *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+ *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
return status;
}
@@ -343,7 +344,7 @@ static acpi_status hci_write2(struct toshiba_acpi_dev *dev,
u32 reg,
u32 in[TCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 };
u32 out[TCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
- *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+ *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
return status;
}
@@ -355,7 +356,7 @@ static acpi_status hci_read2(struct toshiba_acpi_dev *dev,
u32 reg,
acpi_status status = tci_raw(dev, in, out);
*out1 = out[2];
*out2 = out[3];
- *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+ *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
return status;
}
@@ -369,17 +370,17 @@ static int sci_open(struct toshiba_acpi_dev *dev)
acpi_status status;
status = tci_raw(dev, in, out);
- if (ACPI_FAILURE(status) || out[0] == HCI_FAILURE) {
+ if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
pr_err("ACPI call to open SCI failed\n");
return 0;
}
- if (out[0] == SCI_OPEN_CLOSE_OK) {
+ if (out[0] == TOS_OPEN_CLOSE_OK) {
return 1;
- } else if (out[0] == SCI_ALREADY_OPEN) {
+ } else if (out[0] == TOS_ALREADY_OPEN) {
pr_info("Toshiba SCI already opened\n");
return 1;
- } else if (out[0] == SCI_NOT_PRESENT) {
+ } else if (out[0] == TOS_NOT_PRESENT) {
pr_info("Toshiba SCI is not present\n");
}
@@ -393,16 +394,16 @@ static void sci_close(struct toshiba_acpi_dev *dev)
acpi_status status;
status = tci_raw(dev, in, out);
- if (ACPI_FAILURE(status) || out[0] == HCI_FAILURE) {
+ if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
pr_err("ACPI call to close SCI failed\n");
return;
}
- if (out[0] == SCI_OPEN_CLOSE_OK)
+ if (out[0] == TOS_OPEN_CLOSE_OK)
return;
- else if (out[0] == SCI_NOT_OPENED)
+ else if (out[0] == TOS_NOT_OPENED)
pr_info("Toshiba SCI not opened\n");
- else if (out[0] == SCI_NOT_PRESENT)
+ else if (out[0] == TOS_NOT_PRESENT)
pr_info("Toshiba SCI is not
[PATCH v2 0/3] Return codes cleanup
Up for review. This series of patches are a cleanup to the Toshiba configuration interface return codes (unification), since we are now using both the HCI and the SCI, as well as changing the returned type of the HCI/SCI read/write functions from acpi_status to u32, since the "status" was never checked on most of the functions. Changes since v1: - Be a bit more verbose on patch 1 about the Toshiba configuration interface - Merged patches 3 and 4 into a same patch Azael Avalos (3): toshiba_acpi: Rename hci_raw to tci_raw toshiba_acpi: Unify return codes prefix from HCI/SCI to TOS toshiba_acpi: Change HCI/SCI functions return code type drivers/platform/x86/toshiba_acpi.c | 369 ++-- 1 file changed, 183 insertions(+), 186 deletions(-) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] toshiba_acpi: Change HCI/SCI functions return code type
Currently the HCI/SCI read/write functions are returning
the status of the ACPI call and also assigning the
returned value of the HCI/SCI function, however, only
the HCI/SCI status is being checked.
This patch changes such functions, returning the value
of the HCI/SCI function instead of the ACPI call status,
eliminating one parameter, and returning something
useful that indeed is being checked.
Signed-off-by: Azael Avalos
---
drivers/platform/x86/toshiba_acpi.c | 129 +---
1 file changed, 62 insertions(+), 67 deletions(-)
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index 589a858..5d509ea 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -317,47 +317,49 @@ static acpi_status tci_raw(struct toshiba_acpi_dev *dev,
* may be useful (such as "not supported").
*/
-static acpi_status hci_write1(struct toshiba_acpi_dev *dev, u32 reg,
- u32 in1, u32 *result)
+static u32 hci_write1(struct toshiba_acpi_dev *dev, u32 reg, u32 in1)
{
u32 in[TCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
u32 out[TCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
- *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
- return status;
+
+ return ACPI_SUCCESS(status) ? out[0] : TOS_FAILURE;
}
-static acpi_status hci_read1(struct toshiba_acpi_dev *dev, u32 reg,
-u32 *out1, u32 *result)
+static u32 hci_read1(struct toshiba_acpi_dev *dev, u32 reg, u32 *out1)
{
u32 in[TCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 };
u32 out[TCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
+ if (ACPI_FAILURE(status))
+ return TOS_FAILURE;
+
*out1 = out[2];
- *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
- return status;
+
+ return out[0];
}
-static acpi_status hci_write2(struct toshiba_acpi_dev *dev, u32 reg,
- u32 in1, u32 in2, u32 *result)
+static u32 hci_write2(struct toshiba_acpi_dev *dev, u32 reg, u32 in1, u32 in2)
{
u32 in[TCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 };
u32 out[TCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
- *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
- return status;
+
+ return ACPI_SUCCESS(status) ? out[0] : TOS_FAILURE;
}
-static acpi_status hci_read2(struct toshiba_acpi_dev *dev, u32 reg,
-u32 *out1, u32 *out2, u32 *result)
+static u32 hci_read2(struct toshiba_acpi_dev *dev, u32 reg, u32 *out1, u32
*out2)
{
u32 in[TCI_WORDS] = { HCI_GET, reg, *out1, *out2, 0, 0 };
u32 out[TCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
+ if (ACPI_FAILURE(status))
+ return TOS_FAILURE;
+
*out1 = out[2];
*out2 = out[3];
- *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
- return status;
+
+ return out[0];
}
/* common sci tasks
@@ -407,25 +409,26 @@ static void sci_close(struct toshiba_acpi_dev *dev)
pr_info("Toshiba SCI is not present\n");
}
-static acpi_status sci_read(struct toshiba_acpi_dev *dev, u32 reg,
- u32 *out1, u32 *result)
+static u32 sci_read(struct toshiba_acpi_dev *dev, u32 reg, u32 *out1)
{
u32 in[TCI_WORDS] = { SCI_GET, reg, 0, 0, 0, 0 };
u32 out[TCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
+ if (ACPI_FAILURE(status))
+ return TOS_FAILURE;
+
*out1 = out[2];
- *result = (ACPI_SUCCESS(status)) ? out[0] : TOS_FAILURE;
- return status;
+
+ return out[0];
}
-static acpi_status sci_write(struct toshiba_acpi_dev *dev, u32 reg,
-u32 in1, u32 *result)
+static u32 sci_write(struct toshiba_acpi_dev *dev, u32 reg, u32 in1)
{
u32 in[TCI_WORDS] = { SCI_SET, reg, in1, 0, 0, 0 };
u32 out[TCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
- *result = (ACPI_SUCCESS(status)) ? out[0] : TOS_FAILURE;
- return status;
+
+ return ACPI_SUCCESS(status) ? out[0] : TOS_FAILURE;
}
/* Illumination support */
@@ -457,7 +460,6 @@ static void toshiba_illumination_set(struct led_classdev
*cdev,
struct toshiba_acpi_dev *dev = container_of(cdev,
struct toshiba_acpi_dev, led_dev);
u32 state, result;
- acpi_status status;
/* First request : initialize communication. */
if (!sci_open(dev))
@@ -465,9 +467,9 @@ static void toshiba_illumination_set(struct led_classdev
*cdev,
/* Switch the illumination on/off */
state = brightness ? 1 : 0;
- status = sci_write(dev, SCI_ILLUMINATION, state, );
+ result = sci_write(dev, SCI_ILLUMINATION, state);
sci_close(dev);
- if (ACPI_FAILURE(status)) {
+ if (result == TOS_FAILURE) {
Re: [torture] BUG: unable to handle kernel NULL pointer dereference at (null)
On Fri, Sep 26, 2014 at 12:42:23AM -0700, Paul E. McKenney wrote: > On Thu, Sep 18, 2014 at 09:17:51PM +0800, Fengguang Wu wrote: > > Hi Paul, > > > > > > > > plymouth-upstart-bridge: ply-event-loop.c:497: ply_event_loop_new: > > > > > > Assertion `loop->epoll_fd >= 0' failed. > > > > > > /etc/lsb-base-logging.sh: line 5: 2580 Aborted > > > > > > plymouth --ping > /dev/null 2>&1 > > > > > > /etc/lsb-base-logging.sh: line 5: 2585 Aborted > > > > > > plymouth --ping > /dev/null 2>&1 > > > > > > mount: proc has wrong device number or fs type proc not supported > > > > > > /etc/lsb-base-logging.sh: line 5: 2601 Aborted > > > > > > plymouth --ping > /dev/null 2>&1 > > > > > > /etc/rc6.d/S40umountfs: line 20: /proc/mounts: No such file or > > > > > > directory > > > > > > cat: /proc/1/maps: No such file or directory > > > > > > cat: /proc/1/maps: No such file or directory > > > > > > cat: /proc/1/maps: No such file or directory > > > > > > cat: /proc/1/maps: No such file or directory > > > > > > cat: /proc/1/maps: No such file or directory > > > > > > cat: /proc/1/maps: No such file or directory > > > > > > umount: /var/run: not mounted > > > > > > umount: /var/lock: not mounted > > > > > > umount: /dev/shm: not mounted > > > > > > mount: / is busy > > > > > > * Will now restart > > > > > > Are these expected behavior? > > > > Yes, because it's randconfig boot tests, the user space may well > > complain about random stuff and I'll ignore them all as long as it > > will eventually call the shutdown command to finish the test in time. :) > > > > > So again, I can invoke this commit without losing much (sendkey > > > alt-sysrq-z is after all my friend), but it is not clear to me that we > > > have gotten to the root of this problem. > > > > Sorry about that! If you see any debug tricks that I can try, or > > information I can collect, please let me know. > > Hmmm... > > Looks like rcutorture might be starting too soon. With all the selftests, > it is taking 3-4 minutes to boot. Sorry my scripts reboot the machine quickly, there is no logic to wait for the completion of rcutorture tests. Looking at the dmesg, the BUG shows up during the shutdown stage: ==> Sending all processes the TERM signal... mount: mounting proc on /proc failed: No such device [ 121.930088] Dumping ftrace buffer: [ 121.930453] - [ 121.930865] BUG: unable to handle kernel NULL pointer dereference at (null) [ 121.931644] IP: [] print_trace_line+0x2b0/0x38a > One approach would be to set > rcutorture.stat_interval=200 or whatever the duration of boot is. > Another would be to set rcutorture.torture_runnable=0, and to change: > > int rcutorture_runnable = RCUTORTURE_RUNNABLE_INIT; > module_param(rcutorture_runnable, int, 0444); > MODULE_PARM_DESC(rcutorture_runnable, "Start rcutorture at boot"); > > To: > > int rcutorture_runnable = RCUTORTURE_RUNNABLE_INIT; > module_param(rcutorture_runnable, int, 0644); > MODULE_PARM_DESC(rcutorture_runnable, "Start rcutorture at boot"); > > In kernel/rcu/rcutorture.c. > > Then have your scripts set rcutorture_runnable=1 from sysfs once boot > completes. That looks suitable to run as a functional test case in LKP. I can enable the below options in the LKP test kernel (hope they will not bring noticeable runtime overheads when not insmod): CONFIG_TORTURE_TEST=m CONFIG_RCU_TORTURE_TEST=m CONFIG_LOCK_TORTURE_TEST=m and write a simple test case for it. To start the torture test, it should be as simple as modproble rcutorture echo 1 > /proc/sys/kernel/rcutorture_runnable To determine if the test has finished, will this do the job in the normal cases? dmesg | grep "--- End of test:" Can I reasonably set the max test timeout to 5 or 10 or more minutes? When exceeded, LKP will assume the machine is dead and need a force reboot. > Alternatively, if poking sysfs is not reasonable (and it > would not be in my test scripts), put a delay just after the > rcutorture_record_test_transition() in rcu_torture_init(). For example, > schedule_timeout_interruptible(200 * HZ) to delay 200 seconds. I'd prefer the boot test to complete sooner than later, which helps improve the test efficiency. :) The 0day boot tests works by running this in a init.d script run CPU hotplug tests in the background enable tracing events [optional] run trinity for 100 seconds ### if feasible, we can add a wait-for-rcutorture-finish here reboot > Another approach would be for me to figure out some way for rcutorture > to figure out that boot was not far enough along for it to safely > do much, probably enabled by a third value of rcutorture_runnable. Will it be *easy* to have a blockable syswrite to "stop rcutorture tests", which will return when all tests have been stopped?
Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support
On Sun, Sep 28, 2014 at 07:07:24PM +0200, Tom Gundersen wrote: > On Fri, Sep 26, 2014 at 11:57 PM, Luis R. Rodriguez > wrote: > > From: "Luis R. Rodriguez" > > Systemd has a general timeout for all workers currently set to 180 > > seconds after which it will send a sigkill signal. Systemd now has a > > warning which is issued once it reaches 1/3 of the timeout. The original > > motivation for the systemd timeout was to help track device drivers > > which do not use asynch firmware loading on init() and the timeout was > > originally set to 30 seconds. > > Please note that the motivation for the timeout in systemd had nothing > to do with async firmware loading (that was just the case where > problems cropped up). *Part *of the original kill logic, according to the commit log, was actually due to the assumption that the issues observed *were* synchronous firmware loading on module init(): commit e64fae5573e566ce4fd9b23c68ac8f3096603314 Author: Kay Sievers Date: Wed Jan 18 05:06:18 2012 +0100 udevd: kill hanging event processes after 30 seconds Some broken kernel drivers load firmware synchronously in the module init path and block modprobe until the firmware request is fulfilled. <...> My point here is not to point fingers but to explain why we went on with this and how we failed to realize only until later that the driver core ran probe together with init. When a few folks pointed out the issues with the kill the issue was punted back to kernel developers and the assumption even among some kernel maintainers was that it was init paths with sync behaviour that was causing some delays and they were broken drivers. It is important to highlight these assumptions ended up setting us off on the wrong path for a while in a hunt to try to fix this issue either in driver or elsewhere. > The motivation was to not allow udev-workers to > stay around indefinitely, and hence put an upper-bound on > their duration (initially 180 s). At some point the bound was reduced > to 30 seconds to make sure module-loading would bail out before the > kernel's firmware loading timeout would bail out (60s I believe). Sure, part of it was that, but folks beat on driver developer about the kill insisting it was drivers that were broken. It was only until Chelsie folks called bloody murder becuase their delays were on probe that we realized there was a bit more to this than what was being pushed back on to driver developers. > That > is no longer relevant, which is why it was safe to reset the timeout > to 180 s. Indeed :D > > Since systemd + kernel are heavily tied in for the purposes of this > > patch it is assumed you have merged on systemd the following > > commits: > > > > 671174136525ddf208cdbe75d6d6bd159afa961fudev: timeout - warn after > > a third of the timeout before killing > > b5338a19864ac3f5632aee48069a669479621dcaudev: timeout - increase > > timeout > > 2e92633dbae52f5ac9b7b2e068935990d475d2cdudev: bump event timeout to > > 60 seconds > > be2ea723b1d023b3d385d3b791ee4607cbfb20caudev: remove userspace > > firmware loading support > > 9f20a8a376f924c8eb5423cfc1f98644fc1e2d1audev: fixup commit > > dd5eddd28a74a49607a8fffcaf960040dba98479udev: unify event timeout > > handling > > 9719859c07aa13539ed2cd4b31972cd30f678543udevd: add --event-timeout > > commandline option > > > > Since we bundle together serially driver init() and probe() > > on module initialiation systemd's imposed timeout put a limit on the > > amount of time a driver init() and probe routines can take. There's a > > few overlooked issues with this and the timeout in general: > > > > 0) Not all drivers are killed, the signal is just sent and > >the kill will only be acted upoon if the driver you loaded > >happens to have some code path that either uses kthreads (which > >as of 786235ee are now killable), or uses some code which checks for > >fatal_signal_pending() on the kernel somewhere -- i.e: pci_read_vpd(). > > Shouldn't this be seen as something to be fixed in the kernel? That's a great question. In practice now after CVE-2012-4398 and its series of patches added which enabled OOM to kill things followed by 786235ee to also handle OOM on kthreads it seems imperative we strive towards this, in practive however if you're getting OOMs on boot you have far more serious issue to be concerned over than handling CVE-2012-4398. Another issue is that even if we wanted to address this a critical right now on module loading driver error paths tend to be pretty buggy and we'd probably end up causing more issues than fixing anything if the sigkill that triggered this was an arbitrary timeout, specially if the timeout is not properly justified. Addressing sigkill due to OOM is important, but as noted if you're running out of memory at load time you have a bit other problems to be concerned over. So extending the kill onto more drivers *because* of the
Re: [PATCH v2] x86: Quark: Add if/else to setup_arch for Quark TLB bug
On 30/09/14 02:46, Ong, Boon Leong wrote:
My view is that the CR3 load should have flushed the TLB in it's entirety.
Ong Boong Leong said that a discussion he had which included HPA concluded
with a flush of the TLB being required after the CR3 reload.
The proposed patch was discussed in April and after much thought into this,
I will suggest that as long as the commentary properly captured down why
__flush_tlb() is **NOT** needed because load_cr3() will have the same effect.
Agree.
The current code
My preference is
1. Just comment the code as is to explain why it works for Quark.
If that's not good enough for people then
2. if/else the flow so that Quark does __flush_tlb() and the rest of the world
does a __flush_tlb_all()
Bryan, just drop this proposal from my submission even though __flush_tlb() is
more obvious in what is supposed to do and does not consume any significant
cpu-time.
Very good. I've a new patchset ready to report cache size based on the
callbacks that Ingo and Dave suggested - found a bug too - so I'll
submit those changes as one.
1. Comment
2. Reporting of cache size
3. Bugfix to the code path for legacy_cache_size => currently broken for
{PIII Tualatin, a bunch of AMDs, and some VIAs too by the looks of it}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Removing shared subtrees?
On Mon, Sep 29, 2014 at 06:24:05PM -0700, Andy Lutomirski wrote: > On Mon, Sep 29, 2014 at 6:14 PM, Al Viro wrote: > > On Mon, Sep 29, 2014 at 05:36:27PM -0700, Andy Lutomirski wrote: > > > >> Ideally it would leave them around until the whole subtree had no > >> references, at which point /mnt and everything under it would > >> disappear with no side effects, because it has no references. > > > > So, assuming you've got a stuck NFS mount with a bunch of local stuff > > bound on top of it, in your ideal we'd have the latter all remaining > > mounted until the server comes back. Lovely, that... > > No, not at all. Er... How so? /mnt is stuck NFS. /mnt/foo/bar and /mnt/foo/barf have /dev/sda1 and /dev/sda2 mounted on them. Both are currently not busy. /mnt is - there's that shell trying to expand *.c in /mnt/splat, sitting around blocked with opened directory in its descriptor table. Just how would your ideal prevent sda1 and sda2 staying mounted? You can't say umount /mnt/foo/bar; it'll get blocked trying to revalidate foo and waiting for server to reply. In real world you can say umount -l /mnt and be done with that - everything in there becomes detached, what used to be /mnt stays alive (but not mounted on /mnt anymore) until it ceases to be busy. What used to be /mnt/foo/bar and /mnt/foo/barf end up shut down immediately (what with not being busy). In your ideal they would stay around until the "whole subtree" (of what?) loses all references, i.e. until that shell closes opened directory. > Let me try this one more time: > > I don't *care* whether MNT_DETACH unmounts submounts immediately or > when all the references are finally gone. I didn't read the docs or > the code to see which is the case *because I don't care*. > > I think it's somewhere between ridiculous and flat-out broken that > MNT_DETACH of the *root* of a shared subtree *propagates* the unmount > of submounts to the parent of the shared subtree. This is IMO > completely bogus. Parent in which sense? Try to experiment with this: mount something on /tmp/foo, then mount --rbind /tmp/foo /mnt/foo, mount something on /mnt/bar and /tmp/bar and umount -l /mnt/foo. Then think what does and does not happen. > IOW, if I do: > > mount --make-rshared / > mount --rbind / /mnt > umount -l /mnt/dev > > then I fully expect /dev to be unmounted (although I think that this > is a misfeature). > > But I did: > > mount --make-rshared / > mount --rbind / /mnt > umount -l /mnt <- the ROOT of the fscking shared subtree > > And /dev got unmounted. How does this make any sense at all? Sigh... umount -l /mnt *includes* unmounting /mnt/dev. Which you do expect to take /dev out. "I expect Y to cause Z; I don't care if X causes Y; why does it end up causing W?!!!?" Where W is vague as hell and depending on what is meant either refers to Z or to something more than that; in the letter case the answer would be "W isn't happening". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] umount.2: Correct the description of MNT_DETACH
On Mon, Sep 29, 2014 at 7:15 PM, Eric W. Biederman wrote: > Andy Lutomirski writes: > >> On Mon, Sep 29, 2014 at 6:04 PM, Eric W. Biederman >> wrote: >>> >>> I recently realized that I had been reasoning improperly about what >>> umount(MNT_DETACH) did based on an insufficient description in >>> the umount.2 man page, that matched my intuition but not the >>> implementation. >>> >>> When there are no submounts MNT_DETACH is essentially harmless to >>> applications. Where there are submounts MNT_DETACH changes what >>> is visible to applications using the detach directories. >>> >>> Signed-off-by: Eric W. Biederman >>> --- >>> man2/umount.2 | 7 --- >>> 1 file changed, 4 insertions(+), 3 deletions(-) >>> >>> diff --git a/man2/umount.2 b/man2/umount.2 >>> index 5ff88152c738..aea39d8306fe 100644 >>> --- a/man2/umount.2 >>> +++ b/man2/umount.2 >>> @@ -66,9 +66,10 @@ This can cause data loss. >>> (Only for NFS mounts.) >>> .TP >>> .BR MNT_DETACH " (since Linux 2.4.11)" >>> -Perform a lazy unmount: make the mount point unavailable for >>> -new accesses, and actually perform the unmount when the mount point >>> -ceases to be busy. >>> +Perform a lazy unmount: make the mount point unavailable for new >>> +accesses, immediately disconnect the filesystem and all filesystems >>> +mounted below it from each other and from the mount table, and >>> +actually perform the unmount when the mount point ceases to be busy. >> >> Want to add something like: >> >> MNT_DETACH on a shared mount will propagate unmount events to its peer >> group. That means that recursively bind mounting a shared mount and >> then unmounting that recursive bind mount will unmount all submounts >> of the original mount. This behavior can be avoided by remounting a >> directory with MS_REC | MS_PRIVATE before unmounting it. > > Make that any unmount on a shared mount that will propogate unmount > events to it's peer group. I don't understand your proposed edit. Can you type it out explicitly? --Andy > > Eric > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] umount.2: Correct the description of MNT_DETACH
Andy Lutomirski writes: > On Mon, Sep 29, 2014 at 6:04 PM, Eric W. Biederman > wrote: >> >> I recently realized that I had been reasoning improperly about what >> umount(MNT_DETACH) did based on an insufficient description in >> the umount.2 man page, that matched my intuition but not the >> implementation. >> >> When there are no submounts MNT_DETACH is essentially harmless to >> applications. Where there are submounts MNT_DETACH changes what >> is visible to applications using the detach directories. >> >> Signed-off-by: Eric W. Biederman >> --- >> man2/umount.2 | 7 --- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/man2/umount.2 b/man2/umount.2 >> index 5ff88152c738..aea39d8306fe 100644 >> --- a/man2/umount.2 >> +++ b/man2/umount.2 >> @@ -66,9 +66,10 @@ This can cause data loss. >> (Only for NFS mounts.) >> .TP >> .BR MNT_DETACH " (since Linux 2.4.11)" >> -Perform a lazy unmount: make the mount point unavailable for >> -new accesses, and actually perform the unmount when the mount point >> -ceases to be busy. >> +Perform a lazy unmount: make the mount point unavailable for new >> +accesses, immediately disconnect the filesystem and all filesystems >> +mounted below it from each other and from the mount table, and >> +actually perform the unmount when the mount point ceases to be busy. > > Want to add something like: > > MNT_DETACH on a shared mount will propagate unmount events to its peer > group. That means that recursively bind mounting a shared mount and > then unmounting that recursive bind mount will unmount all submounts > of the original mount. This behavior can be avoided by remounting a > directory with MS_REC | MS_PRIVATE before unmounting it. Make that any unmount on a shared mount that will propogate unmount events to it's peer group. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] clocksource: Add BE APIs support for clocksource counter reading.
Hi,
> Subject: RE: [PATCH v2] clocksource: Add BE APIs support for clocksource
> counter reading.
>
> On Sun, 28 Sep 2014, li.xi...@freescale.com wrote:
> > > Subject: Re: [PATCH v2] clocksource: Add BE APIs support for clocksource
> > > counter reading.
> > >
> > > On Fri, 26 Sep 2014, Xiubo Li wrote:
> > > > For now I just added _be() support using ioread{16,32}be.
> > > > And i have a check of the clocksource drivers, didn't find anyone
> > > > using LE mode on one BE SoC, so _le() APIs is not needed.
> > >
> > > Nonsense. The existing clocksource_mmio accessor function are
> > > providing LE access independent of the CPU endianess. So we don't need
> > > an _le() API simply because we have it already.
> > >
> > > > cycle_t clocksource_mmio_readl_up(struct clocksource *c)
> > > > {
> > > > - return (cycle_t)readl_relaxed(to_mmio_clksrc(c)->reg);
> > > > + return (cycle_t)ioread32(to_mmio_clksrc(c)->reg);
> > >
> > > And how exactly is this change related to adding BE support?
> > >
> >
> > Actually not very much, since the _be() APIs are using ioread{16,32}be(),
> > so I think using ioread{16,32}() will be less odd to having two different
> > accessors here.
> >
> > Wouldn't this be more unified somehow ?
>
> Changing existing code wants to be a separate patch with a proper
> changelog and a proper argument WHY it needs to be changed in the
> first place.
>
> So please provide that separate patch first with a VERY REASONABLE
> explanation in the changelog WHY the existing readl_relaxed() should
> be replaced by ioread32().
>
Okay, I will follow your advice.
Thanks,
BRs
Xiubo
> Thanks,
>
> tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Microsoft
Your-email-won-£1,000.000.00.From-Microsoft/Yahoo-Email-lottery-SEND-NAME,ADDRESS,TEL-NO:.to-barr.jenniferbr...@hotmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: qup: Fix order of runtime pm initialization
On Mon 29 Sep 15:00 PDT 2014, Andy Gross wrote: > The runtime pm calls need to be done before populating the children via the > i2c_add_adapter call. If this is not done, a child can run into issues trying > to do i2c read/writes due to the pm_runtime_sync failing. > May I ask in what case this would fail? I thought we tested this as we found the faulty error check after calling pm_runtime_get_sync(). Nontheless, Acked-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Andy Gross > --- > drivers/i2c/busses/i2c-qup.c | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c > index 3a4d64e..092d89b 100644 > --- a/drivers/i2c/busses/i2c-qup.c > +++ b/drivers/i2c/busses/i2c-qup.c > @@ -674,16 +674,20 @@ static int qup_i2c_probe(struct platform_device *pdev) > qup->adap.dev.of_node = pdev->dev.of_node; > strlcpy(qup->adap.name, "QUP I2C adapter", sizeof(qup->adap.name)); > > - ret = i2c_add_adapter(>adap); > - if (ret) > - goto fail; > - > pm_runtime_set_autosuspend_delay(qup->dev, MSEC_PER_SEC); > pm_runtime_use_autosuspend(qup->dev); > pm_runtime_set_active(qup->dev); > pm_runtime_enable(qup->dev); > + > + ret = i2c_add_adapter(>adap); > + if (ret) > + goto fail_runtime; > + > return 0; > > +fail_runtime: > + pm_runtime_disable(qup->dev); > + pm_runtime_set_suspended(qup->dev); > fail: > qup_i2c_disable_clocks(qup); > return ret; > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > hosted by The Linux Foundation > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 1/2] bpf: add search pruning optimization to verifier
consider C program represented in eBPF:
int filter(int arg)
{
int a, b, c, *ptr;
if (arg == 1)
ptr =
else if (arg == 2)
ptr =
else
ptr =
*ptr = 0;
return 0;
}
eBPF verifier has to follow all possible paths through the program
to recognize that '*ptr = 0' instruction would be safe to execute
in all situations.
It's doing it by picking a path towards the end and observes changes
to registers and stack at every insn until it reaches bpf_exit.
Then it comes back to one of the previous branches and goes towards
the end again with potentially different values in registers.
When program has a lot of branches, the number of possible combinations
of branches is huge, so verifer has a hard limit of walking no more
than 32k instructions. This limit can be reached and complex (but valid)
programs could be rejected. Therefore it's important to recognize equivalent
verifier states to prune this depth first search.
Basic idea can be illustrated by the program (where .. are some eBPF insns):
1: ..
2: if (rX == rY) goto 4
3: ..
4: ..
5: ..
6: bpf_exit
In the first pass towards bpf_exit the verifier will walk insns: 1, 2, 3, 4, 5,
6
Since insn#2 is a branch the verifier will remember its state in verifier stack
to come back to it later.
Since insn#4 is marked as 'branch target', the verifier will remember its state
in explored_states[4] linked list.
Once it reaches insn#6 successfully it will pop the state recorded at insn#2 and
will continue.
Without search pruning optimization verifier would have to walk 4, 5, 6 again,
effectively simulating execution of insns 1, 2, 4, 5, 6
With search pruning it will check whether state at #4 after jumping from #2
is equivalent to one recorded in explored_states[4] during first pass.
If there is an equivalent state, verifier can prune the search at #4 and declare
this path to be safe as well.
In other words two states at #4 are equivalent if execution of 1, 2, 3, 4 insns
and 1, 2, 4 insns produces equivalent registers and stack.
Signed-off-by: Alexei Starovoitov
---
kernel/bpf/verifier.c | 146 +
1 file changed, 146 insertions(+)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index a086dd3210a8..801f5f3b9307 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -199,6 +199,7 @@ struct verifier_env {
struct verifier_stack_elem *head; /* stack of verifier states to be
processed */
int stack_size; /* number of states to be processed */
struct verifier_state cur_state; /* current verifier state */
+ struct verifier_state_list **explored_states; /* search pruning
optimization */
struct bpf_map *used_maps[MAX_USED_MAPS]; /* array of map's used by
eBPF program */
u32 used_map_cnt; /* number of used maps */
};
@@ -1219,6 +1220,8 @@ enum {
BRANCH = 2,
};
+#define STATE_LIST_MARK ((struct verifier_state_list *) -1L)
+
static int *insn_stack;/* stack of insns to process */
static int cur_stack; /* current stack index */
static int *insn_state;
@@ -1241,6 +1244,10 @@ static int push_insn(int t, int w, int e, struct
verifier_env *env)
return -EINVAL;
}
+ if (e == BRANCH)
+ /* mark branch target for state pruning */
+ env->explored_states[w] = STATE_LIST_MARK;
+
if (insn_state[w] == 0) {
/* tree-edge */
insn_state[t] = DISCOVERED | e;
@@ -1314,6 +1321,10 @@ peek_stack:
goto peek_stack;
else if (ret < 0)
goto err_free;
+ /* tell verifier to check for equivalent states
+* after every call and jump
+*/
+ env->explored_states[t + 1] = STATE_LIST_MARK;
} else {
/* conditional jump with two edges */
ret = push_insn(t, t + 1, FALLTHROUGH, env);
@@ -1364,6 +1375,95 @@ err_free:
return ret;
}
+/* compare two verifier states
+ *
+ * all states stored in state_list are known to be valid, since
+ * verifier reached 'bpf_exit' instruction through them
+ *
+ * this function is called when verifier exploring different branches of
+ * execution popped from the state stack. If it sees an old state that has
+ * more strict register state and more strict stack state then this execution
+ * branch doesn't need to be explored further, since verifier already
+ * concluded that more strict state leads to valid finish.
+ *
+ * Therefore two states are equivalent if register state is more conservative
+ * and explored stack state is more conservative than the current one.
+ * Example:
+ * explored current
+ * (slot1=INV slot2=MISC) == (slot1=MISC slot2=MISC)
+ * (slot1=MISC slot2=MISC) !=
[PATCH net-next 2/2] bpf: add tests to verifier testsuite
add 4 extra tests to cover jump verification better
Signed-off-by: Alexei Starovoitov
---
samples/bpf/test_verifier.c | 130 +++
1 file changed, 130 insertions(+)
diff --git a/samples/bpf/test_verifier.c b/samples/bpf/test_verifier.c
index d10992e2740e..f44ef11f65a7 100644
--- a/samples/bpf/test_verifier.c
+++ b/samples/bpf/test_verifier.c
@@ -461,6 +461,136 @@ static struct bpf_test tests[] = {
.errstr = "R0 invalid mem access",
.result = REJECT,
},
+ {
+ "jump test 1",
+ .insns = {
+ BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
+ BPF_STX_MEM(BPF_DW, BPF_REG_2, BPF_REG_1, -8),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0, 1),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -8, 0),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 1, 1),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -16, 1),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 2, 1),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -8, 2),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 3, 1),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -16, 3),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 4, 1),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -8, 4),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 5, 1),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -32, 5),
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_EXIT_INSN(),
+ },
+ .result = ACCEPT,
+ },
+ {
+ "jump test 2",
+ .insns = {
+ BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0, 2),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -8, 0),
+ BPF_JMP_IMM(BPF_JA, 0, 0, 14),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 1, 2),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -16, 0),
+ BPF_JMP_IMM(BPF_JA, 0, 0, 11),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 2, 2),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -32, 0),
+ BPF_JMP_IMM(BPF_JA, 0, 0, 8),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 3, 2),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -40, 0),
+ BPF_JMP_IMM(BPF_JA, 0, 0, 5),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 4, 2),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -48, 0),
+ BPF_JMP_IMM(BPF_JA, 0, 0, 2),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 5, 1),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -56, 0),
+ BPF_MOV64_IMM(BPF_REG_0, 0),
+ BPF_EXIT_INSN(),
+ },
+ .result = ACCEPT,
+ },
+ {
+ "jump test 3",
+ .insns = {
+ BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0, 3),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -8, 0),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
+ BPF_JMP_IMM(BPF_JA, 0, 0, 19),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 1, 3),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -16, 0),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -16),
+ BPF_JMP_IMM(BPF_JA, 0, 0, 15),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 2, 3),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -32, 0),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -32),
+ BPF_JMP_IMM(BPF_JA, 0, 0, 11),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 3, 3),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -40, 0),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -40),
+ BPF_JMP_IMM(BPF_JA, 0, 0, 7),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 4, 3),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -48, 0),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -48),
+ BPF_JMP_IMM(BPF_JA, 0, 0, 3),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 5, 0),
+ BPF_ST_MEM(BPF_DW, BPF_REG_2, -56, 0),
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -56),
+ BPF_LD_MAP_FD(BPF_REG_1, 0),
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0,
BPF_FUNC_unspec),
+ BPF_EXIT_INSN(),
+ },
+ .fixup = {24},
+ .result = ACCEPT,
+ },
+ {
+ "jump test 4",
+ .insns = {
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, BPF_REG_10, 1),
+ BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, BPF_REG_10, 2),
+
[PATCH net-next 0/2] bpf: add search pruning optimization and tests
Hi All, patch #1 commit log explains why eBPF verifier has to examine some instructions multiple times and describes the search pruning optimization that improves verification speed for branchy programs and allows more complex programs to be verified successfully. This patch completes the core verifier logic. patch #2 adds more verifier tests related to branches and search pruning I'm still working on Andy's 'bitmask for stack slots' suggestion. It will be done on top of this patch. The current verifier algorithm is brute force depth first search with state pruning. If anyone can come up with another algorithm that demonstrates better results, we'll replace the algorithm without affecting user space. Note verifier doesn't guarantee that all possible valid programs are accepted. Overly complex programs may still be rejected. Verifier improvements/optimizations will guarantee that if a program was passing verification in the past, it will still be passing. Alexei Starovoitov (2): bpf: add search pruning optimization to verifier bpf: add tests to verifier testsuite kernel/bpf/verifier.c | 146 +++ samples/bpf/test_verifier.c | 130 ++ 2 files changed, 276 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] mm: constify dump_page and friends
Constify dump_page so that we could dump_page const pages, there is no
functional change here.
Signed-off-by: Sasha Levin
---
include/linux/memcontrol.h | 8
include/linux/mm.h | 2 +-
include/linux/mmdebug.h | 4 ++--
include/linux/page_cgroup.h | 4 ++--
mm/debug.c | 4 ++--
mm/memcontrol.c | 6 +++---
mm/page_cgroup.c| 4 ++--
7 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 19df5d8..534633f 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -200,8 +200,8 @@ void mem_cgroup_split_huge_fixup(struct page *head);
#endif
#ifdef CONFIG_DEBUG_VM
-bool mem_cgroup_bad_page_check(struct page *page);
-void mem_cgroup_print_bad_page(struct page *page);
+bool mem_cgroup_bad_page_check(const struct page *page);
+void mem_cgroup_print_bad_page(const struct page *page);
#endif
#else /* CONFIG_MEMCG */
struct mem_cgroup;
@@ -373,13 +373,13 @@ void mem_cgroup_count_vm_event(struct mm_struct *mm, enum
vm_event_item idx)
#if !defined(CONFIG_MEMCG) || !defined(CONFIG_DEBUG_VM)
static inline bool
-mem_cgroup_bad_page_check(struct page *page)
+mem_cgroup_bad_page_check(const struct page *page)
{
return false;
}
static inline void
-mem_cgroup_print_bad_page(struct page *page)
+mem_cgroup_print_bad_page(const struct page *page)
{
}
#endif
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a91874b..0c13412 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -447,7 +447,7 @@ static inline void page_mapcount_reset(struct page *page)
atomic_set(&(page)->_mapcount, -1);
}
-static inline int page_mapcount(struct page *page)
+static inline int page_mapcount(const struct page *page)
{
return atomic_read(&(page)->_mapcount) + 1;
}
diff --git a/include/linux/mmdebug.h b/include/linux/mmdebug.h
index 877ef22..7d05557 100644
--- a/include/linux/mmdebug.h
+++ b/include/linux/mmdebug.h
@@ -7,8 +7,8 @@ struct page;
struct vm_area_struct;
struct mm_struct;
-extern void dump_page(struct page *page, const char *reason);
-extern void dump_page_badflags(struct page *page, const char *reason,
+extern void dump_page(const struct page *page, const char *reason);
+extern void dump_page_badflags(const struct page *page, const char *reason,
unsigned long badflags);
void dump_vma(const struct vm_area_struct *vma);
void dump_mm(const struct mm_struct *mm);
diff --git a/include/linux/page_cgroup.h b/include/linux/page_cgroup.h
index 5c831f1..fa30115 100644
--- a/include/linux/page_cgroup.h
+++ b/include/linux/page_cgroup.h
@@ -39,7 +39,7 @@ static inline void page_cgroup_init(void)
}
#endif
-struct page_cgroup *lookup_page_cgroup(struct page *page);
+struct page_cgroup *lookup_page_cgroup(const struct page *page);
static inline int PageCgroupUsed(struct page_cgroup *pc)
{
@@ -52,7 +52,7 @@ static inline void pgdat_page_cgroup_init(struct pglist_data
*pgdat)
{
}
-static inline struct page_cgroup *lookup_page_cgroup(struct page *page)
+static inline struct page_cgroup *lookup_page_cgroup(const struct page *page)
{
return NULL;
}
diff --git a/mm/debug.c b/mm/debug.c
index 5ce45c9..d699471 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -80,7 +80,7 @@ static void dump_flags(unsigned long flags,
pr_cont(")\n");
}
-void dump_page_badflags(struct page *page, const char *reason,
+void dump_page_badflags(const struct page *page, const char *reason,
unsigned long badflags)
{
pr_emerg("page:%p count:%d mapcount:%d mapping:%p index:%#lx\n",
@@ -98,7 +98,7 @@ void dump_page_badflags(struct page *page, const char *reason,
mem_cgroup_print_bad_page(page);
}
-void dump_page(struct page *page, const char *reason)
+void dump_page(const struct page *page, const char *reason)
{
dump_page_badflags(page, reason, 0);
}
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 23976fd..b698778 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3546,7 +3546,7 @@ static inline int
mem_cgroup_move_swap_account(swp_entry_t entry,
#endif
#ifdef CONFIG_DEBUG_VM
-static struct page_cgroup *lookup_page_cgroup_used(struct page *page)
+static struct page_cgroup *lookup_page_cgroup_used(const struct page *page)
{
struct page_cgroup *pc;
@@ -3561,7 +3561,7 @@ static struct page_cgroup *lookup_page_cgroup_used(struct
page *page)
return NULL;
}
-bool mem_cgroup_bad_page_check(struct page *page)
+bool mem_cgroup_bad_page_check(const struct page *page)
{
if (mem_cgroup_disabled())
return false;
@@ -3569,7 +3569,7 @@ bool mem_cgroup_bad_page_check(struct page *page)
return lookup_page_cgroup_used(page) != NULL;
}
-void mem_cgroup_print_bad_page(struct page *page)
+void mem_cgroup_print_bad_page(const struct page *page)
{
struct page_cgroup *pc;
diff --git a/mm/page_cgroup.c
[PATCH 4/5] mm: poison vm_area_struct
Add poisoning to vm_area_struct to catch corruption at either the beginning or
the end of the struct.
Signed-off-by: Sasha Levin
---
fs/exec.c| 5 +
include/linux/mm_types.h | 6 ++
include/linux/mmdebug.h | 6 ++
kernel/fork.c| 2 ++
mm/debug.c | 11 +--
mm/mmap.c| 19 ++-
mm/nommu.c | 7 +++
mm/vmacache.c| 3 +++
8 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 7302b75..6cdd652 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -257,6 +257,10 @@ static int __bprm_mm_init(struct linux_binprm *bprm)
return -ENOMEM;
down_write(>mmap_sem);
+#ifdef CONFIG_DEBUG_VM_POISON
+ vma->poison_start = MM_POISON_BEGIN;
+ vma->poison_end = MM_POISON_END;
+#endif
vma->vm_mm = mm;
/*
@@ -283,6 +287,7 @@ static int __bprm_mm_init(struct linux_binprm *bprm)
err:
up_write(>mmap_sem);
bprm->vma = NULL;
+ VM_CHECK_POISON_VMA(vma);
kmem_cache_free(vm_area_cachep, vma);
return err;
}
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 0b0d324..4e2cf93 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -245,6 +245,9 @@ struct vm_region {
* library, the executable area etc).
*/
struct vm_area_struct {
+#ifdef CONFIG_DEBUG_VM_POISON
+ u32 poison_start;
+#endif
/* The first cache line has the info for VMA tree walking. */
unsigned long vm_start; /* Our start address within vm_mm. */
@@ -308,6 +311,9 @@ struct vm_area_struct {
#ifdef CONFIG_NUMA
struct mempolicy *vm_policy;/* NUMA policy for the VMA */
#endif
+#ifdef CONFIG_DEBUG_VM_POISON
+ u32 poison_end;
+#endif
};
struct core_thread {
diff --git a/include/linux/mmdebug.h b/include/linux/mmdebug.h
index 339e40f..75bc69d 100644
--- a/include/linux/mmdebug.h
+++ b/include/linux/mmdebug.h
@@ -45,6 +45,11 @@ void dump_mm(const struct mm_struct *mm);
VM_BUG_ON_MM((mm)->poison_start != MM_POISON_BEGIN, (mm));\
VM_BUG_ON_MM((mm)->poison_end != MM_POISON_END, (mm)); \
} while (0)
+#define VM_CHECK_POISON_VMA(vma) \
+ do {\
+ VM_BUG_ON_VMA((vma)->poison_start != MM_POISON_BEGIN, (vma));\
+ VM_BUG_ON_VMA((vma)->poison_end != MM_POISON_END, (vma));\
+ } while (0)
#endif
#else
#define VM_BUG_ON(cond) BUILD_BUG_ON_INVALID(cond)
@@ -55,6 +60,7 @@ void dump_mm(const struct mm_struct *mm);
#define VM_WARN_ON_ONCE(cond) BUILD_BUG_ON_INVALID(cond)
#define VM_WARN_ONCE(cond, format...) BUILD_BUG_ON_INVALID(cond)
#define VM_CHECK_POISON_MM(mm) do { } while(0)
+#define VM_CHECK_POISON_VMA(vma) do { } while(0)
#endif
#ifdef CONFIG_DEBUG_VIRTUAL
diff --git a/kernel/fork.c b/kernel/fork.c
index 26bedfa..c3ae913 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -415,6 +415,7 @@ static int dup_mmap(struct mm_struct *mm, struct mm_struct
*oldmm)
tmp = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
if (!tmp)
goto fail_nomem;
+ VM_CHECK_POISON_VMA(mpnt);
*tmp = *mpnt;
INIT_LIST_HEAD(>anon_vma_chain);
retval = vma_dup_policy(mpnt, tmp);
@@ -489,6 +490,7 @@ out:
fail_nomem_anon_vma_fork:
mpol_put(vma_policy(tmp));
fail_nomem_policy:
+ VM_CHECK_POISON_VMA(tmp);
kmem_cache_free(vm_area_cachep, tmp);
fail_nomem:
retval = -ENOMEM;
diff --git a/mm/debug.c b/mm/debug.c
index a1ebc5e..d53174e 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -152,11 +152,18 @@ static const struct trace_print_flags vmaflags_names[] = {
void dump_vma(const struct vm_area_struct *vma)
{
pr_emerg("vma %p start %p end %p\n"
+#ifdef CONFIG_DEBUG_VM_POISON
+ "start poison: %s end poison: %s\n"
+#endif
"next %p prev %p mm %p\n"
"prot %lx anon_vma %p vm_ops %p\n"
"pgoff %lx file %p private_data %p\n",
- vma, (void *)vma->vm_start, (void *)vma->vm_end, vma->vm_next,
- vma->vm_prev, vma->vm_mm,
+ vma, (void *)vma->vm_start, (void *)vma->vm_end,
+#ifdef CONFIG_DEBUG_VM_POISON
+ (vma->poison_start == MM_POISON_BEGIN) ? "valid" : "invalid",
+ (vma->poison_end == MM_POISON_END) ? "valid" : "invalid",
+#endif
+ vma->vm_next, vma->vm_prev, vma->vm_mm,
(unsigned long)pgprot_val(vma->vm_page_prot),
vma->anon_vma, vma->vm_ops, vma->vm_pgoff,
vma->vm_file, vma->vm_private_data);
diff --git a/mm/mmap.c b/mm/mmap.c
index 3240bbc..da5ffeb 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -274,6 +274,7 @@ static struct vm_area_struct *remove_vma(struct
vm_area_struct *vma)
[PATCH 5/5] mm: poison page struct
Add poisoning to page struct to catch corruption at either the beginning or
the end of the struct.
Signed-off-by: Sasha Levin
---
include/linux/mm.h | 9 +
include/linux/mm_types.h | 6 ++
include/linux/mmdebug.h| 6 ++
include/linux/page-flags.h | 24
4 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0c13412..c48c4e2 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -524,6 +524,10 @@ static inline struct page *virt_to_head_page(const void *x)
*/
static inline void init_page_count(struct page *page)
{
+#ifdef CONFIG_DEBUG_VM_POISON
+ page->poison_start = MM_POISON_BEGIN;
+ page->poison_end = MM_POISON_END;
+#endif
atomic_set(>_count, 1);
}
@@ -1482,12 +1486,17 @@ static inline void pgtable_init(void)
static inline bool pgtable_page_ctor(struct page *page)
{
+#ifdef CONFIG_DEBUG_VM_POISON
+ page->poison_start = MM_POISON_BEGIN;
+ page->poison_end = MM_POISON_END;
+#endif
inc_zone_page_state(page, NR_PAGETABLE);
return ptlock_init(page);
}
static inline void pgtable_page_dtor(struct page *page)
{
+ VM_CHECK_POISON_PAGE(page);
pte_lock_deinit(page);
dec_zone_page_state(page, NR_PAGETABLE);
}
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 4e2cf93..7cab56a 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -42,6 +42,9 @@ struct address_space;
* and lru list pointers also.
*/
struct page {
+#ifdef CONFIG_DEBUG_VM_POISON
+ u32 poison_start;
+#endif
/* First double word block */
unsigned long flags;/* Atomic flags, some possibly
* updated asynchronously */
@@ -196,6 +199,9 @@ struct page {
#ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS
int _last_cpupid;
#endif
+#ifdef CONFIG_DEBUG_VM_POISON
+ u32 poison_end;
+#endif
}
/*
* The struct page can be forced to be double word aligned so that atomic ops
diff --git a/include/linux/mmdebug.h b/include/linux/mmdebug.h
index 75bc69d..461c452 100644
--- a/include/linux/mmdebug.h
+++ b/include/linux/mmdebug.h
@@ -50,6 +50,11 @@ void dump_mm(const struct mm_struct *mm);
VM_BUG_ON_VMA((vma)->poison_start != MM_POISON_BEGIN, (vma));\
VM_BUG_ON_VMA((vma)->poison_end != MM_POISON_END, (vma));\
} while (0)
+#define VM_CHECK_POISON_PAGE(page) \
+ do {\
+ VM_BUG_ON_PAGE((page)->poison_start != MM_POISON_BEGIN,
(page));\
+ VM_BUG_ON_PAGE((page)->poison_end != MM_POISON_END, (page));\
+ } while (0)
#endif
#else
#define VM_BUG_ON(cond) BUILD_BUG_ON_INVALID(cond)
@@ -61,6 +66,7 @@ void dump_mm(const struct mm_struct *mm);
#define VM_WARN_ONCE(cond, format...) BUILD_BUG_ON_INVALID(cond)
#define VM_CHECK_POISON_MM(mm) do { } while(0)
#define VM_CHECK_POISON_VMA(vma) do { } while(0)
+#define VM_CHECK_POISON_PAGE(page) do { } while(0)
#endif
#ifdef CONFIG_DEBUG_VIRTUAL
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index e1f5fcd..688f72c 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -135,35 +135,43 @@ enum pageflags {
*/
#define TESTPAGEFLAG(uname, lname) \
static inline int Page##uname(const struct page *page) \
- { return test_bit(PG_##lname, >flags); }
+ { VM_CHECK_POISON_PAGE(page); \
+ return test_bit(PG_##lname, >flags); }
#define SETPAGEFLAG(uname, lname) \
static inline void SetPage##uname(struct page *page) \
- { set_bit(PG_##lname, >flags); }
+ { VM_CHECK_POISON_PAGE(page); \
+ set_bit(PG_##lname, >flags); }
#define CLEARPAGEFLAG(uname, lname)\
static inline void ClearPage##uname(struct page *page) \
- { clear_bit(PG_##lname, >flags); }
+ { VM_CHECK_POISON_PAGE(page); \
+ clear_bit(PG_##lname, >flags); }
#define __SETPAGEFLAG(uname, lname)\
static inline void __SetPage##uname(struct page *page) \
- { __set_bit(PG_##lname, >flags); }
+ { VM_CHECK_POISON_PAGE(page); \
+ __set_bit(PG_##lname, >flags); }
#define __CLEARPAGEFLAG(uname, lname) \
static inline void __ClearPage##uname(struct page *page) \
- { __clear_bit(PG_##lname, >flags); }
+ {
[PATCH 3/5] mm: poison mm_struct
Add poisoning to mm_struct to catch corruption at either the beginning or the
end of the struct.
Signed-off-by: Sasha Levin
---
include/linux/mm_types.h | 6 ++
include/linux/mmdebug.h | 8
kernel/fork.c| 11 +++
mm/debug.c | 7 +++
mm/mmap.c| 2 ++
mm/vmacache.c| 2 ++
6 files changed, 36 insertions(+)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 6e0b286..0b0d324 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -343,6 +343,9 @@ struct mm_rss_stat {
struct kioctx_table;
struct mm_struct {
+#ifdef CONFIG_DEBUG_VM_POISON
+ u32 poison_start;
+#endif
struct vm_area_struct *mmap;/* list of VMAs */
struct rb_root mm_rb;
u32 vmacache_seqnum; /* per-thread vmacache */
@@ -454,6 +457,9 @@ struct mm_struct {
bool tlb_flush_pending;
#endif
struct uprobes_state uprobes_state;
+#ifdef CONFIG_DEBUG_VM_POISON
+ u32 poison_end;
+#endif
};
static inline void mm_init_cpumask(struct mm_struct *mm)
diff --git a/include/linux/mmdebug.h b/include/linux/mmdebug.h
index 7d05557..339e40f 100644
--- a/include/linux/mmdebug.h
+++ b/include/linux/mmdebug.h
@@ -39,6 +39,13 @@ void dump_mm(const struct mm_struct *mm);
#define VM_WARN_ON(cond) WARN_ON(cond)
#define VM_WARN_ON_ONCE(cond) WARN_ON_ONCE(cond)
#define VM_WARN_ONCE(cond, format...) WARN_ONCE(cond, format)
+#ifdef CONFIG_DEBUG_VM_POISON
+#define VM_CHECK_POISON_MM(mm) \
+ do {\
+ VM_BUG_ON_MM((mm)->poison_start != MM_POISON_BEGIN, (mm));\
+ VM_BUG_ON_MM((mm)->poison_end != MM_POISON_END, (mm)); \
+ } while (0)
+#endif
#else
#define VM_BUG_ON(cond) BUILD_BUG_ON_INVALID(cond)
#define VM_BUG_ON_PAGE(cond, page) VM_BUG_ON(cond)
@@ -47,6 +54,7 @@ void dump_mm(const struct mm_struct *mm);
#define VM_WARN_ON(cond) BUILD_BUG_ON_INVALID(cond)
#define VM_WARN_ON_ONCE(cond) BUILD_BUG_ON_INVALID(cond)
#define VM_WARN_ONCE(cond, format...) BUILD_BUG_ON_INVALID(cond)
+#define VM_CHECK_POISON_MM(mm) do { } while(0)
#endif
#ifdef CONFIG_DEBUG_VIRTUAL
diff --git a/kernel/fork.c b/kernel/fork.c
index 807633f..26bedfa 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -600,6 +600,8 @@ static void check_mm(struct mm_struct *mm)
{
int i;
+ VM_CHECK_POISON_MM(mm);
+
for (i = 0; i < NR_MM_COUNTERS; i++) {
long x = atomic_long_read(>rss_stat.count[i]);
@@ -624,6 +626,12 @@ struct mm_struct *mm_alloc(void)
return NULL;
memset(mm, 0, sizeof(*mm));
+
+#ifdef CONFIG_DEBUG_VM_POISON
+ mm->poison_start = MM_POISON_BEGIN;
+ mm->poison_end = MM_POISON_END;
+#endif
+
return mm_init(mm, current);
}
@@ -650,6 +658,8 @@ void mmput(struct mm_struct *mm)
{
might_sleep();
+ VM_CHECK_POISON_MM(mm);
+
if (atomic_dec_and_test(>mm_users)) {
uprobe_clear_state(mm);
exit_aio(mm);
@@ -714,6 +724,7 @@ struct mm_struct *get_task_mm(struct task_struct *task)
task_lock(task);
mm = task->mm;
if (mm) {
+ VM_CHECK_POISON_MM(mm);
if (task->flags & PF_KTHREAD)
mm = NULL;
else
diff --git a/mm/debug.c b/mm/debug.c
index d699471..a1ebc5e 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -167,6 +167,9 @@ EXPORT_SYMBOL(dump_vma);
void dump_mm(const struct mm_struct *mm)
{
pr_emerg("mm %p mmap %p seqnum %d task_size %lu\n"
+#ifdef CONFIG_DEBUG_VM_POISON
+ "start poison: %s end poison: %s\n"
+#endif
#ifdef CONFIG_MMU
"get_unmapped_area %p\n"
#endif
@@ -197,6 +200,10 @@ void dump_mm(const struct mm_struct *mm)
"%s", /* This is here to hold the comma */
mm, mm->mmap, mm->vmacache_seqnum, mm->task_size,
+#ifdef CONFIG_DEBUG_VM_POISON
+ (mm->poison_start == MM_POISON_BEGIN) ? "valid" : "invalid",
+ (mm->poison_end == MM_POISON_END) ? "valid" : "invalid",
+#endif
#ifdef CONFIG_MMU
mm->get_unmapped_area,
#endif
diff --git a/mm/mmap.c b/mm/mmap.c
index 9156612..3240bbc 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -469,6 +469,8 @@ static void validate_mm(struct mm_struct *mm)
bug = 1;
}
VM_BUG_ON_MM(bug, mm);
+
+ VM_CHECK_POISON_MM(mm);
}
#else
#define validate_mm_rb(root, ignore) do { } while (0)
diff --git a/mm/vmacache.c b/mm/vmacache.c
index 9f25af8..d507caa 100644
--- a/mm/vmacache.c
+++ b/mm/vmacache.c
@@ -52,6 +52,8 @@ void vmacache_flush_all(struct mm_struct *mm)
*/
static bool vmacache_valid_mm(struct mm_struct *mm)
{
+ VM_CHECK_POISON_MM(mm);
+
return current->mm == mm && !(current->flags & PF_KTHREAD);
}
--
1.9.1
--
To unsubscribe from this
[PATCH 1/5] mm: add poisoning basics
Add poisining basics along with a config option to enable poisoning. Signed-off-by: Sasha Levin --- include/linux/poison.h | 6 ++ lib/Kconfig.debug | 9 + 2 files changed, 15 insertions(+) diff --git a/include/linux/poison.h b/include/linux/poison.h index 2110a81..db4d03e 100644 --- a/include/linux/poison.h +++ b/include/linux/poison.h @@ -86,4 +86,10 @@ /** sound/oss/ **/ #define OSS_POISON_FREE0xAB +/** include/linux/mm_types.h **/ +#ifdef CONFIG_DEBUG_VM_POISON +#define MM_POISON_BEGIN0x89ABCDEF +#define MM_POISON_END 0xFEDCBA98 +#endif /* DEBUG_VM_POISON */ + #endif diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index c366c8a..3b82772 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -543,6 +543,15 @@ config DEBUG_VM_RB If unsure, say N. +config DEBUG_VM_POISON + bool "Poison VM structures" + depends on DEBUG_VM + help + Add poison to the beggining and end of various VM structure to + detect memory corruption in VM management code. + + If unsure, say N. + config DEBUG_VIRTUAL bool "Debug VM translations" depends on DEBUG_KERNEL && X86 -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] mm: poison critical mm/ structs
Currently we're seeing a few issues which are unexplainable by looking at the data we see and are most likely caused by a memory corruption caused elsewhere. This is wasting time for folks who are trying to figure out an issue provided a stack trace that can't really point out the real issue. This patch introduces poisoning on struct page, vm_area_struct, and mm_struct, and places checks in busy paths to catch corruption early. This series was tested, and it detects corruption in vm_area_struct. Right now I'm working on figuring out the source of the corruption, (which is a long standing bug) using KASan, but the current code is useful as it is. Sasha Levin (5): mm: add poisoning basics mm: constify dump_page and friends mm: poison mm_struct mm: poison vm_area_struct mm: poison page struct fs/exec.c | 5 + include/linux/memcontrol.h | 8 include/linux/mm.h | 11 ++- include/linux/mm_types.h| 18 ++ include/linux/mmdebug.h | 24 ++-- include/linux/page-flags.h | 24 include/linux/page_cgroup.h | 4 ++-- include/linux/poison.h | 6 ++ kernel/fork.c | 13 + lib/Kconfig.debug | 9 + mm/debug.c | 22 ++ mm/memcontrol.c | 6 +++--- mm/mmap.c | 21 - mm/nommu.c | 7 +++ mm/page_cgroup.c| 4 ++-- mm/vmacache.c | 5 + 16 files changed, 160 insertions(+), 27 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the arm-soc tree
On 2014/9/30 8:12, Stephen Rothwell wrote: > Hi all, > > On Fri, 26 Sep 2014 11:55:39 +1000 Stephen Rothwell > wrote: >> >> After merging the arm-soc tree, today's linux-next build (arm >> multi_v7_defconfig) failed like this: >> >> Error: arch/arm/boot/dts/hisi-x5hd2.dtsi:374.22-23 syntax error >> FATAL ERROR: Unable to parse input tree > OK, now I get: > > Error: /scratch/sfr/next/arch/arm/boot/dts/hisi-x5hd2.dtsi:417.21-22 syntax > error > FATAL ERROR: Unable to parse input tree > Are you guys really testing this stuff? :-( Hi Stephen, Olof, Arnd, Sorry for my fault and bring so much trouble to all of you. I sent this pull request before the clock patch set being accepted. And I did forget to compile the dtb. But I will make sure it will *not* happen next time. Arnd has already helped to revert the series of this patch set in arm-soc.git:next/dt. Hi Arnd, Olof, Could you please help to revert this series of patch set in arm-soc.git:for-next? Thanks! Best Regards, Wei >> There are a series of new commits to this file today and I have no idea >> which one caused the problem. >> >> I reverted: >> >> 610bd8722ef4 "ARM: dts: hix5hd2: add wdg node" > > Reverted in the arm-soc tree. > >> 6868feb6dd97 "ARM: dts: hix5hd2: add gpio node" > > Error is now: > > Error: /scratch/sfr/next/arch/arm/boot/dts/hisi-x5hd2.dtsi:183.21-22 syntax > error > >> 420a2d55f046 "ARM: dts: hix5hd2: add sata node" > > Error: /scratch/sfr/next/arch/arm/boot/dts/hisi-x5hd2.dtsi:183.21-22 syntax > error > > >> f16c7fb2f3ff "ARM: dts: hix5hd2: add usb node" > > Error: /scratch/sfr/next/arch/arm/boot/dts/hisi-x5hd2.dtsi:183.21-22 syntax > error > >> b196e1ca400d "ARM: dts: hix5hd2: add mmc node" > > Error: /scratch/sfr/next/arch/arm/boot/dts/hisi-x5hd2.dtsi:174.21-22 syntax > error > >> de8b6054780e "ARM: dts: hix5hd2: add gmac node" > > no more errors. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] x86: Quark: Add if/else to setup_arch for Quark TLB bug
> > My view is that the CR3 load should have flushed the TLB in it's entirety. > > Ong Boong Leong said that a discussion he had which included HPA concluded > with a flush of the TLB being required after the CR3 reload. The proposed patch was discussed in April and after much thought into this, I will suggest that as long as the commentary properly captured down why __flush_tlb() is **NOT** needed because load_cr3() will have the same effect. > > The current code > > My preference is > > 1. Just comment the code as is to explain why it works for Quark. > > If that's not good enough for people then > > 2. if/else the flow so that Quark does __flush_tlb() and the rest of the world > does a __flush_tlb_all() Bryan, just drop this proposal from my submission even though __flush_tlb() is more obvious in what is supposed to do and does not consume any significant cpu-time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] bq27x00_battery: Add support to bq27742
Hi, On Mon, Sep 29, 2014 at 02:25:11PM -0700, Puthikorn Voravootivat wrote: > Add support to bq27742 in bq27x00 driver. bq27742 register > addresses are mostly mostly the same as bq27500 addresses > with minor differences. > > Signed-off-by: Puthikorn Voravootivat > Reviewed-by: Gwendal Grignou > Reviewed-by: Rhyland Klein > Reviewed-by: Benson Leung > --- > Change log > v2: Fix flags/full capacity register read Please convert this into an incremental patch, since I already applied v1: http://git.infradead.org/battery-2.6.git/commit/628ef02c56e515430dd8d8439126dd0ecb8ce8bb -- Sebastian signature.asc Description: Digital signature
Re: [RFC] clk: Make clk API return per-user struct clk instances
On 09/29/14 11:17, Tomeu Vizoso wrote: > Also moves clock state to struct clk_core, but takes care to change as little > API as possible. > > struct clk_hw still has a pointer to a struct clk, which is the > implementation's per-user clk instance, for backwards compatibility. > > Signed-off-by: Tomeu Vizoso > > --- > > Hello, > > I'm sending this alternate implementation of the switch to per-user clocks, > with the added goal of not requiring any substantial changes to existing users > of the API. > > This is pretty much RFC-quality right now, having only tested that it builds > on > tegra_defconfig. > > My main question right now is what do we want to do with those drivers that > statically declare clocks. State is now in struct clk_core, so updating the > drivers accordingly will amount to a substantial amount of lines changed, > which > we are now trying to avoid. Who's actually using the static clocks? Isn't it just omap2? It looks like all of those are behind the DEFINE_CLK define so changing it in clk-private.h should "just work". I'm lost as to why static clocks are being used there though. If it was a problem with allocating memory too early it doesn't seem to be the case given that sometimes the .parents field isn't set for a mux and __clk_init() will go and allocate an array of pointers. Maybe I missed something though. > > Thanks, > > Tomeu > --- > drivers/clk/clk-composite.c | 12 +- > drivers/clk/clk.c| 573 > +++ > drivers/clk/clk.h| 5 + > drivers/clk/clkdev.c | 20 +- > drivers/clk/tegra/clk.c | 2 +- > include/linux/clk-private.h | 20 +- > include/linux/clk-provider.h | 22 +- > include/linux/clkdev.h | 2 +- > 8 files changed, 410 insertions(+), 246 deletions(-) > > diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c > index b9355da..cb4a09d 100644 > --- a/drivers/clk/clk-composite.c > +++ b/drivers/clk/clk-composite.c > @@ -57,14 +57,14 @@ static unsigned long clk_composite_recalc_rate(struct > clk_hw *hw, > > static long clk_composite_determine_rate(struct clk_hw *hw, unsigned long > rate, > unsigned long *best_parent_rate, > - struct clk **best_parent_p) > + struct clk_core **best_parent_p) We should avoid exposing clk_core to anything besides clk.c or users of clk-private.h (the latter which should go away once we remove all static clocks). -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] ARM: mvebu: drop unnecessary include
is only being included because of the implicit requirements of v7_exit_coherency_flush(). Now that the implicit include is provided for us, we can drop it from our explicit list. Signed-off-by: Brian Norris Cc: Jason Cooper Cc: Andrew Lunn Cc: Gregory Clement Cc: Sebastian Hesselbarth --- arch/arm/mach-mvebu/pmsu.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c index 8a70a51533fd..2d283cbc5cc7 100644 --- a/arch/arm/mach-mvebu/pmsu.c +++ b/arch/arm/mach-mvebu/pmsu.c @@ -33,7 +33,6 @@ #include #include #include -#include #include #include #include -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] ARM: rockchip: drop unnecessary include
is only being included because of the implicit requirements of v7_exit_coherency_flush(). Now that the implicit include is provided for us, we can drop it from our explicit list. Signed-off-by: Brian Norris Cc: Heiko Stuebner Cc: linux-rockc...@lists.infradead.org --- arch/arm/mach-rockchip/platsmp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-rockchip/platsmp.c b/arch/arm/mach-rockchip/platsmp.c index 189684f55927..9b72e84e6494 100644 --- a/arch/arm/mach-rockchip/platsmp.c +++ b/arch/arm/mach-rockchip/platsmp.c @@ -21,7 +21,6 @@ #include #include -#include #include #include #include -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] ARM: brcmstb: drop unnecessary include
is only being included because of the implicit requirements of v7_exit_coherency_flush(). Now that the implicit include is provided for us, we can drop it from our explicit list. Signed-off-by: Brian Norris Cc: Marc Carino --- This is based on code queued for 3.18 arch/arm/mach-bcm/platsmp-brcmstb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-bcm/platsmp-brcmstb.c b/arch/arm/mach-bcm/platsmp-brcmstb.c index 31c87a284a34..3911ca7a0c3c 100644 --- a/arch/arm/mach-bcm/platsmp-brcmstb.c +++ b/arch/arm/mach-bcm/platsmp-brcmstb.c @@ -25,7 +25,6 @@ #include #include -#include #include #include -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
