Re: [PATCH v4 2/3] regulator: tps6586x: add and use correct voltage table
On Tue, Dec 03, 2013 at 11:18:47PM +0100, Stefan Agner wrote:
[...]
> diff --git a/drivers/regulator/tps6586x-regulator.c
> b/drivers/regulator/tps6586x-regulator.c
[...]
> + /* Search version specific table first */
> + if (table) {
> + for (i = 0; i < num; i++) {
> + ri = [i];
> + if (ri->desc.id == id)
> + return ri;
> + }
> + }
Ah... there you go. Looks good:
Reviewed-by: Thierry Reding
pgpFiqmjFswmo.pgp
Description: PGP signature
I Have a donation for you
I Have a donation for you...Kindly contact me for more details DAVE ANGELA ang_dav...@3mail.ie -- 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: [Xen-devel] [PATCH RFC] xen-block: correctly define structures in public headers
On 04/12/13 10:28, Ian Campbell wrote: > On Tue, 2013-12-03 at 15:11 -0500, Konrad Rzeszutek Wilk wrote: If Konrad and Boris agree that breaking the kernel's ABI in this way is acceptable in this specific case, I'll defer to them. >>> >>> My opinion as Xen on ARM hypervisor maintainer is that this is the right >>> thing to do in this case. >> >> Heh. If somebody can guarantee me that (by testing the right variants and >> mentioning this in the git commit) that this does not break x86, then >> I am fine. >> >> And by 'break x86' I mean that this combination works: >> 32-bit domU on 64-bit dom0 >> 64-bit domU on 32-bit dom0 >> >> And perhaps also the obvious: >> 64-bit domU on 64-bit dom0 >> 32-bit domU on 32-bit dom0 > > One way to test this is with gdb on a vmlinux for each arch with > CONFIG_DEBUG_INFO=y. For each MEMBER of each interesting STRUCT: > (gdb) print &((struct STRUCT *)0)->MEMBER > (this is effectively an open coded offsetof) > > This could probably even be semi automated by producing a script to feed > to gdb which run through all of the options and diffing the result. > > If I could have the moon on a stick I would have a tool such as this > running against the canonical Xen headers, to catch breakage as it is > introduced upstream and a tool which could run against an arbitrary ELF > binary to validate it against the upstream results. > tools/include/xen-foreign/mkchecker.py goes some way towards that but > isn't really extensible to the extent we would need/want. > > While I'm asking for unicorns a gcc __attribute__((warn_on_holes)) which > could be applied to a struct to enforce the need for explicit padding > would probably be incredibly useful for this of thing. Right now I would be happy to add something like: #if !defined(CONFIG_X86_32) && !defined(CONFIG_X86_64) && !defined(CONFIG_ARM... #error This architecture is not supported by the Xen PV block ABI #endif To the Linux copy of blkif.h >> Since the xen-blkback has its own version of the structs there is no >> need to change change newer and older version of it. > > Someone should check that these are producing the right interface on ARM > though! AFAICT blkback on ARM is not using the structures defined in blkback/common.h, since the protocol is "native", it's using the same structures defined in the public header (just as blkfront). There's no translation needed and blkback just does a memcpy from the ring to the native struct. -- 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] OF: base: match each node compatible against all given matches first
On Tue, Dec 03, 2013 at 11:55:07PM +0100, Sebastian Hesselbarth wrote: > On 12/03/2013 09:14 PM, Meelis Roos wrote: > >>Currently, of_match_node compares each given match against all node's > >>compatible strings with of_device_is_compatible. > >> > >>To achieve multiple compatible strings per node with ordering from > >>specific to generic, this requires given matches to be ordered from > >>specific to generic. For most of the drivers this is not true and also > >>an alphabetical ordering is more sane there. > >> > >>Therefore, this patch modifies of_match_node to match each of the node's > >>compatible strings against all given matches first, before checking the > >>next compatible string. This implies that node's compatibles are ordered > >>from specific to generic while given matches can be in any order. > > > >I think I am on the CC: list because of a CPU detection problem report > >on sparc64 (183912d352a242a276a7877852f107459a13aff9 (of: move > >of_get_cpu_node implementation to DT core library) caused trouble and > > The reason you are on Cc is that Thierry added you on last patch > version. I cannot see how above commit should be related with this > one, but maybe Thierry can comment on it. > > >was reverted). So while your V2 patch does not cause any visible harm on > >the same Sun E3500, my gut feeling is that an additional patch would be > >needed to actually test it (a patch like > >183912d352a242a276a7877852f107459a13aff9). > > This patch deals with matching a node with more than one compatible > string on a (unordered) list of matches. Although not related to your > issue, it is good to hear that it causes no harm on DT-mature archs :) > > I tested it with ARM and l2x0 cache controllers, where the specific > of_device_id (marvell,tauros3-cache) is sorted after the generic > one (arm,pl310-cache). The corresponding node's property is > compatible = "marvell,tauros3-cache", "arm,pl310-cache". > > Without this patch, of_match_node always hits the first match that > equals _any_ of the above compatible strings. With this patch, it > hits the matches _in order_ of the compatible strings. > > >Is this correct or am I missing something? > > Thierry? I added Meelis on Cc because he found a regression with my original proposal (107a84e61cdd "of: match by compatible property first"). That got later reverted in commit bc51b0c22ceb (Revert "of: match by compatible property first"). Here's the commit message for reference: commit bc51b0c22ceb Author: Linus Torvalds Date: Tue Jul 10 12:49:32 2012 -0700 Revert "of: match by compatible property first" This reverts commit 107a84e61cdd3406c842a0e4be7efffd3a05dba6. Meelis Roos reports a regression since 3.5-rc5 that stops Sun Fire V100 and Sun Netra X1 sparc64 machines from booting, hanging after enabling serial console. He bisected it to commit 107a84e61cdd. Rob Herring explains: "The problem is match combinations of compatible plus name and/or type fail to match correctly. I have a fix for this, but given how late it is for 3.5 I think it is best to revert this for now. There could be other cases that rely on the current although wrong behavior. I will post an updated version for 3.6." Bisected-and-reported-by: Meelis Roos Requested-by: Rob Herring Cc: Thierry Reding Cc: Grant Likely Signed-off-by: Linus Torvalds So if Meelis still has access to the Sun Fire V100 and Sun Netra X1 machines that regressed last time around, it'd be great to get this patch tested on them to verify that it indeed fixes the problem and doesn't regress. Thierry pgpsIqnCz36tQ.pgp Description: PGP signature
Re: [PATCH 1/3] clk: bcm281xx: define kona clock binding
On Wed, Dec 04, 2013 at 03:56:58AM +, Alex Elder wrote: > Document the device tree binding for Broadcom Kona architecture > clock control units and clocks. Kona device nodes are represented > with compatible strings having "bcm11351" in their name. > > Kona clocks are managed by "clock control units" (CCUs). Each CCU > has a device tree node, and within that node are defined the names > of the clocks provided by the CCU. > > The BCM281xx family of SoCs use Kona CCUs and clocks. > > Signed-off-by: Alex Elder > Reviewed-by: Matt Porter > Reviewed-by: Tim Kryger > --- > .../devicetree/bindings/clock/bcm-kona-clock.txt | 95 > > 1 file changed, 95 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/bcm-kona-clock.txt > > diff --git a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt > b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt > new file mode 100644 > index 000..0cafd6a > --- /dev/null > +++ b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt > @@ -0,0 +1,95 @@ > +Broadcom Kona Family Clocks > + > +This binding is associated with Broadcom SoCs having "Kona" style > +clock control units (CCUs). A CCU is a clock provider that manages > +a set of clock signals. Each CCU is represented by a node in the > +device tree. > + > +This binding uses the common clock binding: > +Documentation/devicetree/bindings/clock/clock-bindings.txt > + > +Many source clocks are described using the "fixed-clock" binding: > +Documentation/devicetree/bindings/clock/fixed-clock.txt Is this necessary? While this describes the device it doesn't describe this binding. > + > +Required properties: > +- compatible > + Shall have a value "brcm,bcm11351--ccu", where > + identifies the particular CCU (see below). It would be nice to have a full list here, as that makes finding the file easier. Something like: - compatible: should contain one of: * "brcm,bcm11351-root-ccu" * "brcm,bcm11351-aon-ccu" * "brcm,bcm11351-hub-ccu" * "brcm,bcm11351-master-ccu" The differences between these are described in greater detail below. > +- reg > + Shall define the base and range of the address space > + containing clock control registers > +- #clock-cells > + Shall have the value <1> How about: - #clock-cells: Should be <1>. The permitted clock-specifier values are defined below. > +- clock-output-names > + Shall be an ordered list of strings defining the names of > + the clocks provided by the CCU. > + > +Clock consumers refer to a particular clock supplied by a CCU using > +a phandle and specifier pair, using the phandle for the CCU device > +tree node and the clock's symbolic specifier. The clock specifier > +is a CCU-unique 0-based index value. This is redundant given the common clock binding and the description of #clock-cells above. > + > + > +BCM281XX family SoCs use Kona CCUs. The following table defines > +the set of CCUs and clock specifiers for BCM281XX clocks. The > +compatible string for the CCU uses the name in the "CCU" column > +below as it's value. > + > +CCU Clock TypeIndex Specifier > +--- - - - > +rootfrac_1m peri 0 BCM281XX_ROOT_CCU_FRAC_1M > + > +aon hub_timer peri 0 BCM281XX_AON_CCU_HUB_TIMER > +aon pmu_bsc peri 1 BCM281XX_AON_CCU_PMU_BSC > +aon pmu_bsc_var peri 2 BCM281XX_AON_CCU_PMU_BSC_VAR > + > +hub tmon_1m peri 0 BCM281XX_HUB_CCU_TMON_1M > + > +master sdio1 peri 0 BCM281XX_MASTER_CCU_SDIO1 > +master sdio2 peri 1 BCM281XX_MASTER_CCU_SDIO2 > +master sdio3 peri 2 BCM281XX_MASTER_CCU_SDIO3 > +master sdio4 peri 3 BCM281XX_MASTER_CCU_SDIO4 > +master dmacperi 4 BCM281XX_MASTER_CCU_DMAC > +master usb_ic peri 5 BCM281XX_MASTER_CCU_USB_IC > +master hsic2_48m peri 6 BCM281XX_MASTER_CCU_HSIC_48M > +master hsic2_12m peri 7 BCM281XX_MASTER_CCU_HSIC_12M > + > +slave uartb peri 0 BCM281XX_SLAVE_CCU_UARTB > +slave uartb2 peri 1 BCM281XX_SLAVE_CCU_UARTB2 > +slave uartb3 peri 2 BCM281XX_SLAVE_CCU_UARTB3 > +slave uartb4 peri 3 BCM281XX_SLAVE_CCU_UARTB4 > +slave ssp0peri 4 BCM281XX_SLAVE_CCU_SSP0 > +slave ssp2peri 5 BCM281XX_SLAVE_CCU_SSP2 > +slave bsc1peri 6 BCM281XX_SLAVE_CCU_BSC1 > +slave bsc2peri 7 BCM281XX_SLAVE_CCU_BSC2 > +slave bsc3peri 8 BCM281XX_SLAVE_CCU_BSC3 > +slave pwm peri 9 BCM281XX_SLAVE_CCU_PWM I guess the Specifier column is referring to some
Re: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up.
On Tue, 2013-12-03 at 16:14 -0500, Konrad Rzeszutek Wilk wrote:
> The user has the option of disabling the platform driver:
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
>
> which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
> and allow the PV drivers to take over. If the user wishes
> to disable that they can set:
>
> xen_platform_pci=0
> (in the guest config file)
>
> or
> xen_emul_unplug=never
> (on the Linux command line)
>
> except it does not work properly. The PV drivers still try to
> load and since the Xen platform driver is not run - and it
> has not initialized the grant tables, most of the PV drivers
> stumble upon:
>
> input: Xen Virtual Keyboard as /devices/virtual/input/input5
> input: Xen Virtual Pointer as /devices/virtual/input/input6M
> [ cut here ]
> kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
> invalid opcode: [#1] SMP
> Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
> CPU: 6 PID: 1389 Comm: modprobe Not tainted
> 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
> Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
> RIP: 0010:[] []
> get_free_entries+0x2e0/0x300
> Call Trace:
> [] ? evdev_connect+0x1e3/0x240
> [] gnttab_grant_foreign_access+0x2e/0x70
> [] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
> [] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
> [] xenbus_dev_probe+0x77/0x130
> [] xenbus_frontend_dev_probe+0x47/0x50
> [] driver_probe_device+0x89/0x230
> [] __driver_attach+0x9b/0xa0
> [] ? driver_probe_device+0x230/0x230
> [] ? driver_probe_device+0x230/0x230
> [] bus_for_each_dev+0x8c/0xb0
> [] driver_attach+0x19/0x20
> [] bus_add_driver+0x1a0/0x220
> [] driver_register+0x5f/0xf0
> [] xenbus_register_driver_common+0x15/0x20
> [] xenbus_register_frontend+0x23/0x40
> [] ? 0xa0014fff
> [] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
> [] do_one_initcall+0x49/0x170
>
> .. snip..
>
> which is hardly nice. This patch fixes this by having each
> PV driver check for:
> - if running in PV, then it is fine to execute (as that is their
>native environment).
> - if running in HVM, check if user wanted 'xen_emul_unplug=never',
>in which case bail out and don't load PV drivers.
> - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
>does not exist, then bail out and not load PV drivers.
>
> P.S.
> Ian Campbell suggested getting rid of 'xen_platform_pci_unplug'
> but unfortunatly the xen-blkfront driver is using it, so we
> cannot do it.
It might still be nice to expose a suitable semantic interface (i.e.
some relevant predicate) rather than the raw value for blkfront to use.
But that can be a future thing I think.
> Reported-by: Sander Eikelenboom Reported-by: Anthony PERARD
> Reported-by: Fabio Fantoni
> ---
> arch/x86/xen/platform-pci-unplug.c | 18 ++
> drivers/block/xen-blkfront.c | 2 +-
> drivers/char/tpm/xen-tpmfront.c| 4
> drivers/input/misc/xen-kbdfront.c | 4
> drivers/net/xen-netfront.c | 2 +-
> drivers/pci/xen-pcifront.c | 4
> drivers/video/xen-fbfront.c| 4
> drivers/xen/xenbus/xenbus_probe_frontend.c | 2 +-
> include/xen/platform_pci.h | 13 -
> 9 files changed, 49 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/xen/platform-pci-unplug.c
> b/arch/x86/xen/platform-pci-unplug.c
> index 0a78524..087dfeb 100644
> --- a/arch/x86/xen/platform-pci-unplug.c
> +++ b/arch/x86/xen/platform-pci-unplug.c
> @@ -69,6 +69,24 @@ static int check_platform_magic(void)
> return 0;
> }
>
> +bool xen_has_pv_devices(void)
> +{
> + if (!xen_domain())
> + return false;
> +
> + if (xen_hvm_domain()) {
> + /* User requested no unplug, so no PV drivers. */
> + if (xen_emul_unplug & XEN_UNPLUG_NEVER)
> + return false;
I think you need
if (xen_emul_unpug & XEN_UNPLUG_UNNECESSARY)
return true;
don't you?
> + /* And user has xen_platform_pci=0 set in guest config as
> + * driver did not modify the value. */
> + if (!xen_platform_pci_unplug)
> + return false;
> + }
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(xen_has_pv_devices);
> +
> void xen_unplug_emulated_devices(void)
> {
> int r;
--
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 4/4] usb: chipidea: msm: Use USB PHY API to control PHY state
Hi Peter,
On Wed, 2013-12-04 at 13:37 +0800, Peter Chen wrote:
> On Mon, Nov 11, 2013 at 04:36:09PM +0200, Ivan T. Ivanov wrote:
> >
> > Hi Peter,
> >
> > On Mon, 2013-11-11 at 21:59 +0800, Peter Chen wrote:
> > > On Mon, Nov 11, 2013 at 03:35:37PM +0200, Ivan T. Ivanov wrote:
> > > > From: "Ivan T. Ivanov"
> > > >
> > > > PHY drivers keep track of the current state of the hardware,
> > > > so don't change PHY settings under it.
> > > >
> > > > Signed-off-by: Ivan T. Ivanov
> > > > ---
> > > > drivers/usb/chipidea/ci_hdrc_msm.c |9 ++---
> > > > 1 file changed, 2 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
> > > > b/drivers/usb/chipidea/ci_hdrc_msm.c
> > > > index e9624f3..338b209 100644
> > > > --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> > > > +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> > > > @@ -20,13 +20,11 @@
> > > > static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned
> > > > event)
> > > > {
> > > > struct device *dev = ci->gadget.dev.parent;
> > > > - int val;
> > > >
> > > > switch (event) {
> > > > case CI_HDRC_CONTROLLER_RESET_EVENT:
> > > > dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT
> > > > received\n");
> > > > - writel(0, USB_AHBBURST);
> > > > - writel(0, USB_AHBMODE);
> > > > + usb_phy_init(ci->transceiver);
> > >
> > > It will reset the PHY, but your comment is "don't change PHY settings
> > > under it"
> >
> > :-). This function is exported by PHY drivers, so they will know how
> > to handle this change.
> >
> > >
> > > > break;
> > > > case CI_HDRC_CONTROLLER_STOPPED_EVENT:
> > > > dev_dbg(dev, "CI_HDRC_CONTROLLER_STOPPED_EVENT
> > > > received\n");
> > > > @@ -34,10 +32,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc
> > > > *ci, unsigned event)
> > > > * Put the transceiver in non-driving mode. Otherwise
> > > > host
> > > > * may not detect soft-disconnection.
> > > > */
> > > > - val = usb_phy_io_read(ci->transceiver, ULPI_FUNC_CTRL);
> > > > - val &= ~ULPI_FUNC_CTRL_OPMODE_MASK;
> > > > - val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
> > > > - usb_phy_io_write(ci->transceiver, val, ULPI_FUNC_CTRL);
> > > > + usb_phy_notify_disconnect(ci->transceiver,
> > > > USB_SPEED_UNKNOWN);
> > >
> > > Where you have implemented .notify_disconnect?
> > > I have not found it at your phy driver.
> >
> > Yep, I will post PHY driver changes shortly. Meanwhile this should
> > not break existing board file based platforms, because not of them
> > could be compiled (HTC Dream, Halibut Board) and DT based platforms
> > are sill work in progress.
> >
>
> Hi Ivan, I am going to apply this msm chipidea patchset, but the change
> in this file is different with its original meaning.
What did you mean?
CI_HDRC_CONTROLLER_RESET_EVENT -> usb_phy_init()
Take wherever actions are needed to put device in known state. ?
CI_HDRC_CONTROLLER_STOPPED_EVENT -> usb_phy_notify_disconnect()
Emitted after ci->driver->disconnect(>gadget);
Probably I am missing something.
> Have you
> tested at existing platforms?
I have 8074 based DragonBoard which I used for testing.
CV Test Suite engine "Chapter 9 tests" are passing except
"Halt Endpoint Test".
Regards,
Ivan
>
--
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: [PATCHv2 RESEND] irqchip: Add support for TI-NSPIRE irqchip
Hi,
I've noticed this patch hasn't gotten a reply for a while now. Just wondering
what's the status of this patch and whether there is anything else I should fix
before this can get accepted.
Cheers,
Daniel Tang
On 25/11/2013, at 3:02 PM, dt.ta...@gmail.com wrote:
> From: Daniel Tang
>
> This patch adds support for the interrupt controllers found in some
> TI-Nspire models.
>
> FIQ support was taken out to simplify the driver
> code and may be added in later. Since Linux on this platform doesn't
> really use FIQs, this wasn't really that important in the first
> place.
>
> Changes from v1 to v2:
> * Converted to use generic IRQ chips.
> * Removed FIQ for now to simplify driver code.
> * Based against tip/irq/core and uses IRQ domain support for generic
> chips.
>
> Signed-off-by: Daniel Tang
> Acked-by: Grant Likely
> ---
> .../interrupt-controller/lsi,zevio-intc.txt| 18 +++
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-zevio.c| 129 +
> 3 files changed, 148 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt
> create mode 100644 drivers/irqchip/irq-zevio.c
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt
> b/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt
> new file mode 100644
> index 000..aee38e7
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt
> @@ -0,0 +1,18 @@
> +TI-NSPIRE interrupt controller
> +
> +Required properties:
> +- compatible: Compatible property value should be "lsi,zevio-intc".
> +
> +- reg: Physical base address of the controller and length of memory mapped
> + region.
> +
> +- interrupt-controller : Identifies the node as an interrupt controller
> +
> +Example:
> +
> +interrupt-controller {
> + compatible = "lsi,zevio-intc";
> + interrupt-controller;
> + reg = <0xDC00 0x1000>;
> + #interrupt-cells = <1>;
> +};
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index cda4cb5..f313d14 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -15,4 +15,5 @@ obj-$(CONFIG_SIRF_IRQ) += irq-sirfsoc.o
> obj-$(CONFIG_RENESAS_INTC_IRQPIN) += irq-renesas-intc-irqpin.o
> obj-$(CONFIG_RENESAS_IRQC)+= irq-renesas-irqc.o
> obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
> +obj-$(CONFIG_ARCH_NSPIRE)+= irq-zevio.o
> obj-$(CONFIG_ARCH_VT8500) += irq-vt8500.o
> diff --git a/drivers/irqchip/irq-zevio.c b/drivers/irqchip/irq-zevio.c
> new file mode 100644
> index 000..92e6c7b
> --- /dev/null
> +++ b/drivers/irqchip/irq-zevio.c
> @@ -0,0 +1,129 @@
> +/*
> + * linux/drivers/irqchip/irq-zevio.c
> + *
> + * Copyright (C) 2013 Daniel Tang
> + *
> + * 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 "irqchip.h"
> +
> +#define IO_STATUS0x000
> +#define IO_RAW_STATUS0x004
> +#define IO_ENABLE0x008
> +#define IO_DISABLE 0x00C
> +#define IO_CURRENT 0x020
> +#define IO_RESET 0x028
> +#define IO_MAX_PRIOTY0x02C
> +
> +#define IO_IRQ_BASE 0x000
> +#define IO_FIQ_BASE 0x100
> +
> +#define IO_INVERT_SEL0x200
> +#define IO_STICKY_SEL0x204
> +#define IO_PRIORITY_SEL 0x300
> +
> +#define MAX_INTRS32
> +#define FIQ_STARTMAX_INTRS
> +
> +static struct irq_domain *zevio_irq_domain;
> +static void __iomem *zevio_irq_io;
> +
> +static void zevio_irq_ack(struct irq_data *irqd)
> +{
> + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(irqd);
> + struct irq_chip_regs *regs =
> + _of(irqd->chip, struct irq_chip_type, chip)->regs;
> +
> + irq_gc_lock(gc);
> + readl(gc->reg_base + regs->ack);
> + irq_gc_unlock(gc);
> +}
> +
> +static void init_base(void __iomem *base)
> +{
> + /* Disable all interrupts */
> + writel(~0, base + IO_DISABLE);
> +
> + /* Accept interrupts of all priorities */
> + writel(0xF, base + IO_MAX_PRIOTY);
> +
> + /* Reset existing interrupts */
> + readl(base + IO_RESET);
> +}
> +
> +asmlinkage void __exception_irq_entry zevio_handle_irq(struct pt_regs *regs)
> +{
> + int irqnr;
> +
> + while (readl(zevio_irq_io + IO_STATUS)) {
> + irqnr = readl(zevio_irq_io + IO_CURRENT);
> + irqnr = irq_find_mapping(zevio_irq_domain, irqnr);
> + handle_IRQ(irqnr, regs);
> + };
> +}
> +
> +static int __init zevio_of_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + unsigned int clr = IRQ_NOREQUEST | IRQ_NOPROBE
Re: [RFC PATCH tip 0/5] tracing filters with BPF
* Alexei Starovoitov wrote: > On Tue, Dec 3, 2013 at 1:16 AM, Ingo Molnar wrote: > > > > Very cool! (Added various other folks who might be interested in > > this to the Cc: list.) > > > > I have one generic concern: > > > > It would be important to make it easy to extract loaded BPF code > > from the kernel in source code equivalent form, which compiles to > > the same BPF code. > > > > I.e. I think it would be fundamentally important to make sure that > > this is all within the kernel's license domain, to make it very > > clear there can be no 'binary only' BPF scripts. > > > > By up-loading BPF into a kernel the person loading it agrees to > > make that code available to all users of that system who can > > access it, under the same license as the kernel's code (or under a > > more permissive license). > > > > The last thing we want is people getting funny ideas and writing > > drivers in BPF and hiding the code or making license claims over > > it > > all makes sense. In case of kernel modules all export_symbols are > accessible and module has to have kernel compatible license. Same > licensing terms apply to anything else that interacts with kernel > functions. In case of BPF the list of accessible functions is tiny, > so it's much easier to enforce specific limited use case. For > tracing filters it's just bpf_load_xx/trace_printk/dump_stack. Even > if someone has funny ideas they cannot be brought to life, since > drivers need a lot more than this set of functions and BPF checker > will reject any attempts to call something outside of this tiny > list. imo the same applies to existing BPF as well. Meaning that > tcpdump filter string and seccomp filters, if distributed, has to > have their source code available. I mean more than that, I mean the licensing of BFP filters a user can find on his own system's kernel should be very clear: by the act of loading a BFP script into the kernel the user doing the 'upload' gives permission for it to be redistributed on kernel-compatible license terms. The easiest way to achieve that is to make sure that all loaded BFP scripts are 'registered' and are dumpable, viewable and reusable. That's good for debugging and it's good for transparency. This means a minimal BFP decoder will have to be in the kernel as well, but that's OK, we actually have several x86 instruction decoder in the kernel already, so there's no complexity threshold. > > I.e. we want to allow flexible plugins technologically, but make > > sure people who run into such a plugin can modify and improve it > > under the same license as they can modify and improve the kernel > > itself! > > wow. I guess if the whole thing takes off, we would need an > in-kernel directory to store upstreamed bpf filters as well :) I see no reason why not, but more importantly all currently loaded BFP scripts should be dumpable, displayable and reusable in a kernel license compatible fashion. Thanks, Ingo -- 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 v3 2/3] regulator: tps6586x: add and use correct voltage table
On Tue, Dec 03, 2013 at 08:57:28PM +0100, Stefan Agner wrote:
[...]
> Changes since v2:
> - Removed reg_ from reg_version
> - Moved walk through version dependent tables to find_regulator_info,
> removed the inline definition. This reduces .o size and encapsulates
> the logic of finding the right regulator into one function. It comes
> with a slight code duplication, the table search now appears twice.
Well, the table was searched twice in the original patch, too, so this
variant isn't any worse, really.
> ---
> arch/arm/boot/dts/tegra20-colibri-512.dtsi | 4 +-
> drivers/regulator/tps6586x-regulator.c | 91
> +++---
> 2 files changed, 74 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
[...]
> -static inline struct tps6586x_regulator *find_regulator_info(int id)
> +static struct tps6586x_regulator *find_regulator_info(int id, int version)
> {
> struct tps6586x_regulator *ri;
> + struct tps6586x_regulator *table = NULL;
> + int num;
> int i;
>
> + switch (version) {
> + case TPS658623:
> + table = tps658623_regulator;
> + num = ARRAY_SIZE(tps658623_regulator);
> + break;
> + case TPS658643:
> + table = tps658643_regulator;
> + num = ARRAY_SIZE(tps658643_regulator);
> + break;
> + }
> +
I think you still need to check for table to be valid here. Depending on
the version it might still be NULL.
> + /* Search version specific table first */
> + for (i = 0; i < num; i++) {
> + ri = [i];
> + if (ri->desc.id == id)
> + return ri;
> + }
So this would need to be wrapped in an "if (table) { }" block.
pgpr0PJ2sP20J.pgp
Description: PGP signature
[PATCHv2 2/2] arm: nspire: fix compile-time warnings
From: Daniel Tang
Fix nspire_restart to take enum reboot_mode instead of a char so the
correct function pointer is passed to DT_MACHINE_START.
Signed-off-by: Daniel Tang
---
arch/arm/mach-nspire/nspire.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-nspire/nspire.c b/arch/arm/mach-nspire/nspire.c
index 4b2ed2e..3d24ebf 100644
--- a/arch/arm/mach-nspire/nspire.c
+++ b/arch/arm/mach-nspire/nspire.c
@@ -63,7 +63,7 @@ static void __init nspire_init(void)
nspire_auxdata, NULL);
}
-static void nspire_restart(char mode, const char *cmd)
+static void nspire_restart(enum reboot_mode mode, const char *cmd)
{
void __iomem *base = ioremap(NSPIRE_MISC_PHYS_BASE, SZ_4K);
if (!base)
--
1.8.1.3
--
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/2] macvtap: remove unused paramter in macvtap_do_read()
From: Zhi Yong Wu
Signed-off-by: Zhi Yong Wu
---
drivers/net/macvtap.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 957cc5c..c0d412e 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -823,7 +823,7 @@ done:
return ret ? ret : copied;
}
-static ssize_t macvtap_do_read(struct macvtap_queue *q, struct kiocb *iocb,
+static ssize_t macvtap_do_read(struct macvtap_queue *q,
const struct iovec *iv, unsigned long len,
int noblock)
{
@@ -874,7 +874,7 @@ static ssize_t macvtap_aio_read(struct kiocb *iocb, const
struct iovec *iv,
goto out;
}
- ret = macvtap_do_read(q, iocb, iv, len, file->f_flags & O_NONBLOCK);
+ ret = macvtap_do_read(q, iv, len, file->f_flags & O_NONBLOCK);
ret = min_t(ssize_t, ret, len); /* XXX copied from tun.c. Why? */
if (ret > 0)
iocb->ki_pos = ret;
@@ -1108,7 +1108,7 @@ static int macvtap_recvmsg(struct kiocb *iocb, struct
socket *sock,
int ret;
if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
return -EINVAL;
- ret = macvtap_do_read(q, iocb, m->msg_iov, total_len,
+ ret = macvtap_do_read(q, m->msg_iov, total_len,
flags & MSG_DONTWAIT);
if (ret > total_len) {
m->msg_flags |= MSG_TRUNC;
--
1.7.6.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/
[PATCHv2 1/2] clocksource: zevio-timer: fix compile-time warnings
From: Daniel Tang
Fix incorrect function definition of zevio_timer_add so the correct function
pointer is passed to CLOCKSOURCE_OF_DECLARE.
Signed-off-by: Daniel Tang
---
drivers/clocksource/zevio-timer.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/clocksource/zevio-timer.c
b/drivers/clocksource/zevio-timer.c
index ca81809..a1bd107 100644
--- a/drivers/clocksource/zevio-timer.c
+++ b/drivers/clocksource/zevio-timer.c
@@ -122,28 +122,27 @@ static irqreturn_t zevio_timer_interrupt(int irq, void
*dev_id)
return IRQ_HANDLED;
}
-static int __init zevio_timer_add(struct device_node *node)
+static void __init zevio_timer_add(struct device_node *node)
{
struct zevio_timer *timer;
struct resource res;
- int irqnr, ret;
+ int irqnr;
timer = kzalloc(sizeof(*timer), GFP_KERNEL);
if (!timer)
- return -ENOMEM;
+ return;
timer->base = of_iomap(node, 0);
- if (!timer->base) {
- ret = -EINVAL;
+ if (!timer->base)
goto error_free;
- }
+
timer->timer1 = timer->base + IO_TIMER1;
timer->timer2 = timer->base + IO_TIMER2;
timer->clk = of_clk_get(node, 0);
if (IS_ERR(timer->clk)) {
- ret = PTR_ERR(timer->clk);
- pr_err("Timer clock not found! (error %d)\n", ret);
+ pr_err("Timer clock not found! (error %d)\n",
+ (int)PTR_ERR(timer->clk));
goto error_unmap;
}
@@ -204,12 +203,12 @@ static int __init zevio_timer_add(struct device_node
*node)
pr_info("Added %s as clocksource\n", timer->clocksource_name);
- return 0;
+ return;
error_unmap:
iounmap(timer->base);
error_free:
kfree(timer);
- return ret;
+ return;
}
CLOCKSOURCE_OF_DECLARE(zevio_timer, "lsi,zevio-timer", zevio_timer_add);
--
1.8.1.3
--
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: [Xen-devel] [PATCH RFC] xen-block: correctly define structures in public headers
On Tue, 2013-12-03 at 15:11 -0500, Konrad Rzeszutek Wilk wrote: > > > If Konrad and Boris agree that breaking the kernel's ABI in this way is > > > acceptable in this specific case, I'll defer to them. > > > > My opinion as Xen on ARM hypervisor maintainer is that this is the right > > thing to do in this case. > > Heh. If somebody can guarantee me that (by testing the right variants and > mentioning this in the git commit) that this does not break x86, then > I am fine. > > And by 'break x86' I mean that this combination works: > 32-bit domU on 64-bit dom0 > 64-bit domU on 32-bit dom0 > > And perhaps also the obvious: > 64-bit domU on 64-bit dom0 > 32-bit domU on 32-bit dom0 One way to test this is with gdb on a vmlinux for each arch with CONFIG_DEBUG_INFO=y. For each MEMBER of each interesting STRUCT: (gdb) print &((struct STRUCT *)0)->MEMBER (this is effectively an open coded offsetof) This could probably even be semi automated by producing a script to feed to gdb which run through all of the options and diffing the result. If I could have the moon on a stick I would have a tool such as this running against the canonical Xen headers, to catch breakage as it is introduced upstream and a tool which could run against an arbitrary ELF binary to validate it against the upstream results. tools/include/xen-foreign/mkchecker.py goes some way towards that but isn't really extensible to the extent we would need/want. While I'm asking for unicorns a gcc __attribute__((warn_on_holes)) which could be applied to a struct to enforce the need for explicit padding would probably be incredibly useful for this of thing. > Since the xen-blkback has its own version of the structs there is no > need to change change newer and older version of it. Someone should check that these are producing the right interface on ARM though! > As long as that works I am OK sticking it in. Thanks. > I think from the ARM perspective it is still in 'experimental' phase > so anything goes to make it work under ARM. Ian. -- 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] macvtap: update file current position
From: Zhi Yong Wu Signed-off-by: Zhi Yong Wu --- drivers/net/macvtap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c index 9093004..957cc5c 100644 --- a/drivers/net/macvtap.c +++ b/drivers/net/macvtap.c @@ -876,6 +876,8 @@ static ssize_t macvtap_aio_read(struct kiocb *iocb, const struct iovec *iv, ret = macvtap_do_read(q, iocb, iv, len, file->f_flags & O_NONBLOCK); ret = min_t(ssize_t, ret, len); /* XXX copied from tun.c. Why? */ + if (ret > 0) + iocb->ki_pos = ret; out: return ret; } -- 1.7.6.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: [RFC PATCH tip 3/5] Extended BPF (64-bit BPF) design document
* Alexei Starovoitov wrote: > It's possible to teach it for multi-level, but then analyzer will > become too large and won't be suitable for kernel. Btw., even if we want to start simple with most things, the above statement is not actually true in the broad sense: the constraint for the kernel is utility, not complexity. We have various kinds of highly complex code in the kernel and can deal with it just fine. Throwing away useful ideas just because they seem too complex at first sight is almost always wrong. Thanks, Ingo -- 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 v3 1/3] mfd: tps6586x: add version detection
On Tue, Dec 03, 2013 at 08:57:27PM +0100, Stefan Agner wrote: > Use the VERSIONCRC to determine the exact device version. According to > the datasheet this register can be used as device identifier. The > identification is needed since some tps6586x regulators use a different > voltage table. > > Signed-off-by: Stefan Agner > --- > Since the struct tps6586x is inside the c file, I could not easily > move the tps6586x_get_version function as inline to the header file. > > Changes since v2: > - Avoid moving devm_kzalloc > --- > drivers/mfd/tps6586x.c | 43 ++- > include/linux/mfd/tps6586x.h | 7 +++ > 2 files changed, 45 insertions(+), 5 deletions(-) Reviewed-by: Thierry Reding pgpyp5uyKXqN3.pgp Description: PGP signature
[PATCH 2/2] arm: nspire: modify device tree to use the nspire-usb driver
From: Daniel Tang
This patch adds the needed compatible key to the device tree for TI-Nspires.
Signed-off-by: Daniel Tang
---
arch/arm/boot/dts/nspire.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi
index a22ffe6..baf7153 100644
--- a/arch/arm/boot/dts/nspire.dtsi
+++ b/arch/arm/boot/dts/nspire.dtsi
@@ -65,6 +65,7 @@
};
usb0: usb@B000 {
+ compatible = "lsi,nspire-usb";
reg = <0xB000 0x1000>;
interrupts = <8>;
};
--
1.7.10.4
--
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] usb: chipidea: fix mistake in device tree binding of nspire-usb to use vendor name 'lsi' instead of SoC name 'zevio'
From: Daniel Tang
The SoC name was mistakenly used instead of the vendor name in the
device tree binding for nspire-usb.
This patch fixes this before the driver becomes widely adopted.
Signed-off-by: Daniel Tang
---
Documentation/devicetree/bindings/usb/ci-hdrc-nspire.txt |4 ++--
drivers/usb/chipidea/ci_hdrc_nspire.c|2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-nspire.txt
b/Documentation/devicetree/bindings/usb/ci-hdrc-nspire.txt
index 5ba8e90..ef1fcbf 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-nspire.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-nspire.txt
@@ -1,7 +1,7 @@
* TI-Nspire USB OTG Controller
Required properties:
-- compatible: Should be "zevio,nspire-usb"
+- compatible: Should be "lsi,nspire-usb"
- reg: Should contain registers location and length
- interrupts: Should contain controller interrupt
@@ -11,7 +11,7 @@ Recommended properies:
Examples:
usb0: usb@B000 {
reg = <0xB000 0x1000>;
- compatible = "zevio,nspire-usb";
+ compatible = "lsi,nspire-usb";
interrupts = <8>;
vbus-supply = <_reg>;
};
diff --git a/drivers/usb/chipidea/ci_hdrc_nspire.c
b/drivers/usb/chipidea/ci_hdrc_nspire.c
index 517ce41..c5c2dde 100644
--- a/drivers/usb/chipidea/ci_hdrc_nspire.c
+++ b/drivers/usb/chipidea/ci_hdrc_nspire.c
@@ -52,7 +52,7 @@ static int ci_hdrc_nspire_remove(struct platform_device *pdev)
}
static const struct of_device_id ci_hdrc_nspire_dt_ids[] = {
- { .compatible = "zevio,nspire-usb", },
+ { .compatible = "lsi,nspire-usb", },
{ /* sentinel */ }
};
--
1.7.10.4
--
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] mutexes: Add CONFIG_DEBUG_MUTEX_FASTPATH=y debug variant to debug SMP races
On Tue, Dec 03, 2013 at 10:10:29AM -0800, Linus Torvalds wrote:
> On Tue, Dec 3, 2013 at 12:52 AM, Ingo Molnar wrote:
> >
> > I'd expect such bugs to be more prominent with unlucky object
> > size/alignment: if mutex->count lies on a separate cache line from
> > mutex->wait_lock.
>
> I doubt that makes much of a difference. It's still just "CPU cycles"
> away, and the window will be tiny unless you have multi-socket
> machines and/or are just very unlucky.
>
> For stress-testing, it would be much better to use some hack like
>
> /* udelay a bit if the spinlock isn't contended */
> if (mutex->wait_lock.ticket.head+1 == mutex->wait_lock.ticket.tail)
> udelay(1);
>
> in __mutex_unlock_common() just before the spin_unlock(). Make the
> window really *big*.
I haven't had a chance yet to do much testing of the proposed race fix
and race enlarging patches, but I did write a tool to reproduce the race.
I started it running and left for dinner, and sure enough, it actually
seems to work on plain 3.12 on a Dell PowerEdge r410 w/dual E5520,
reproducing "Poison overwritten" at a rate of about once every 15 minutes
(running 6 in parallel, booted with "slub_debug").
I have no idea if actually relying on tsc alignment between cores and
sockets is a reasonable idea these days, but it seems to work. I first
used a read() on a pipe close()d by the other process to synchronize
them, but this didn't seem to work as well as busy-waiting until the
timestamp counters pass a previously-decided-upon start time.
Meanwhile, I still don't understand how moving the unlock _up_ to cover
less of the code can solve the race, but I will stare at your long
explanation more tomorrow.
Simon-
#include
#include
#include
#include
#include
#define MAX_PIPES 450
#define FORK_CYCLES 200
#define CLOSE_CYCLES 10
#define STAT_SHIFT 6
static inline unsigned long readtsc()
{
unsigned int low, high;
asm volatile("rdtsc" : "=a" (low), "=d" (high));
return low | ((unsigned long)(high) << 32);
}
static int pipefd[MAX_PIPES][2];
int main(int argc, char *argv[]) {
unsigned long loop, race_start, miss;
unsigned long misses = 0, races = 0;
int i;
pid_t pid;
struct rlimit rlim = {
.rlim_cur = MAX_PIPES * 2 + 96,
.rlim_max = MAX_PIPES * 2 + 96,
};
if (setrlimit(RLIMIT_NOFILE, ) != 0)
perror("setrlimit(RLIMIT_NOFILE)");
for (loop = 1;;loop++) {
/*
* Make a bunch of pipes
*/
for (i = 0;i < MAX_PIPES;i++) {
if (pipe(pipefd[i]) == -1) {
perror("pipe()");
exit(EXIT_FAILURE);
}
}
race_start = readtsc() + FORK_CYCLES;
asm("":::"memory");
pid = fork();
if (pid == -1) {
perror("fork()");
exit(EXIT_FAILURE);
}
pid = !!pid;
/*
* Close one pipe descriptor per process
*/
for (i = 0;i < MAX_PIPES;i++)
close(pipefd[i][!pid]);
for (i = 0;i < MAX_PIPES;i++) {
/*
* Line up and try to close at the same time
*/
miss = 1;
while (readtsc() < race_start)
miss = 0;
close(pipefd[i][pid]);
misses+= miss;
race_start+= CLOSE_CYCLES;
}
races+= MAX_PIPES;
if (!(loop & (~(~0UL << STAT_SHIFT
fprintf(stderr, "%c %lu (%.2f%% false starts)\n",
"CP"[pid], readtsc(), misses * 100. / races);
if (pid)
wait(NULL); /* Parent */
else
exit(0); /* Child */
}
}
Re: [GIT PULL 00/12] perf/core improvements and fixes
* Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > The following changes since commit 0ed1e0bee0b2c6b4cc6d7a63787739a9d3ac8aa8: > > Merge tag 'perf-core-for-mingo' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > (2013-11-30 13:42:48 +0100) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux > tags/perf-core-for-mingo > > for you to fetch changes up to f885037ef6400ce4a4c122a88845dea2c9bca256: > > perf trace: Honour -m option (2013-12-02 16:29:40 -0300) > > > perf/tools improvements and fixes: > > . Honour -m option in 'trace', the tool was offering the option to > set the mmap size, but wasn't using it when doing the actual mmap > on the events file descriptors, fix from Jiri Olsa. > > . Correct the message in feature-libnuma checking, swowing the right > devel package names for various distros, from Dongsheng Yang. > > . Polish 'readn' function and introduce its counterpart, 'writen', from > Jiri Olsa. > > . Start moving timechart state from global variables to a 'perf_tool' derived > 'timechart' struct. > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (4): > perf timechart: Introduce tool struct > perf timechart: Move all_data per_pid list to 'struct timechart' > perf timechart: Move power_events list to 'struct timechart' > perf timechart: Move wake_events list to 'struct timechart' > > Dongsheng Yang (1): > perf tools: Correct the message in feature-libnuma checking. > > Jiri Olsa (7): > perf record: Unify data output code into perf_record__write function > perf tools: Use correct return type for readn function > perf tools: Fine tune readn function > perf tools: Add writen function > perf tools: Add perf_data_file__write interface > perf tools: Include test-stackprotector-all.c in test-all > perf trace: Honour -m option > > tools/perf/builtin-record.c | 20 +- > tools/perf/builtin-timechart.c | 364 > +++- > tools/perf/builtin-trace.c | 2 +- > tools/perf/config/Makefile | 2 +- > tools/perf/config/feature-checks/test-all.c | 5 + > tools/perf/util/data.c | 6 + > tools/perf/util/data.h | 14 +- > tools/perf/util/header.c| 18 +- > tools/perf/util/session.c | 2 +- > tools/perf/util/util.c | 32 ++- > tools/perf/util/util.h | 3 +- > 11 files changed, 256 insertions(+), 212 deletions(-) Pulled, thanks a lot Arnaldo! Ingo -- 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: [GIT PULL v2] dynticks updates for 3.14
* Frederic Weisbecker wrote: > Ingo, > > Please pull the timers/core-v2 branch that can be found at: > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > timers/core-v2 > > It's a rebase of the previous pull request against 3.13-rc2 which addresses > your reviews: > > * Fix build error with tick_check_nohz() off case > > * Refine changelog of "posix-timers: Fix full dynticks CPUs kick on timer > rescheduling" > to make it clearer that it's a bug fix and not just an optimization. > Also add more overall details in the changelog about the description of the > issue. > > * Rename tick_check_nohz() and tick_check_oneshot_broadcast() to extend with > *_this_cpu() > suffix. Note that I left functions that use *_idle_* based naming as is > because idle > itself is a per cpu notion already. Now I can still extend these functions > as well > in a delta if you want, although IMHO I fear that would uglify the code > more than helping. > > --- > Here is a summary of the overall changes against tip:timers/core : > > * Optimizations and cleanups on the use of per CPU APIs to improve code > readability, > performance and debuggability in the nohz subsystem; > > * Rename some functions to extend with *_this_cpu() suffix for clarity > > * Refine the naming of some context tracking subsystem state accessors > > * Optimize posix cpu timer by sparing stub workqueue queue with full dynticks > off case > > * Trivial spelling fix by Paul Gortmaker > > * Fix a bug where posix cpu timers requeued due to interval got ignored on > full > dynticks CPUs (not a regression though as it only impacts full dynticks and > the > bug is there since we merged full dynticks). > > > Let me know if you find any issue. > > Thanks, > Frederic > --- > > Frederic Weisbecker (5): > nohz: Convert a few places to use local per cpu accesses > context_tracking: Wrap static key check into more intuitive function > name > context_tracking: Rename context_tracking_active() to > context_tracking_cpu_is_enabled() > posix-timers: Spare workqueue if there is no full dynticks CPU to kick > posix-timers: Fix full dynticks CPUs kick on timer rescheduling > > Paul Gortmaker (1): > trivial: fix spelling in CONTEXT_TRACKING_FORCE help text > > > include/linux/context_tracking.h | 10 - > include/linux/context_tracking_state.h | 11 +++--- > include/linux/tick.h | 8 +++ > include/linux/vtime.h | 4 ++-- > init/Kconfig | 2 +- > kernel/context_tracking.c | 8 +++ > kernel/posix-cpu-timers.c | 21 -- > kernel/softirq.c | 4 +--- > kernel/time/tick-broadcast.c | 6 +++--- > kernel/time/tick-internal.h| 4 ++-- > kernel/time/tick-sched.c | 39 > ++ > 11 files changed, 55 insertions(+), 62 deletions(-) Pulled into tip:timers/core, thanks a lot Frederic! Ingo -- 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] cpuidle: Check for dev before deregistering it.
On 12/03/2013 10:33 PM, Rafael J. Wysocki wrote:
On Tuesday, December 03, 2013 10:59:58 AM Konrad Rzeszutek Wilk wrote:
If not, we could end up in the unfortunate situation where
we dereference a NULL pointer b/c we have cpuidle disabled.
This is the case when booting under Xen (which uses the
ACPI P/C states but disables the CPU idle driver) - and can
be easily reproduced when booting with cpuidle.off=1.
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] cpuidle_unregister_device+0x2a/0x90
.. snip..
Call Trace:
[] acpi_processor_power_exit+0x3c/0x5c
[] acpi_processor_stop+0x61/0xb6
[] __device_release_driver+0f81421653>]
device_release_driver+0x23/0x30
[] bus_remove_device+0x108/0x180
[] device_del+0x129/0x1c0
[] ? unregister_xenbus_watch+0x1f0/0x1f0
[] device_unregister+0x1e/0x60
[] unregister_cpu+0x39/0x60
[] arch_unregister_cpu+0x23/0x30
[] handle_vcpu_hotplug_event+0xc1/0xe0
[] xenwatch_thread+0x45/0x120
[] ? abort_exclusive_wait+0xb0/0xb0
[] kthread+0xd2/0xf0
[] ? kthread_create_on_node+0x180/0x180
[] ret_from_fork+0x7c/0xb0
[] ? kthread_create_on_node+0x180/0x180
This problem also appears in 3.12 and could be a candidate for backport.
CC: "Rafael J. Wysocki"
CC: Daniel Lezcano
CC: linux...@vger.kernel.org
Signed-off-by: Konrad Rzeszutek Wilk
Applied, thanks!
---
drivers/cpuidle/cpuidle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 2a991e4..a55e68f 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -400,7 +400,7 @@ EXPORT_SYMBOL_GPL(cpuidle_register_device);
*/
void cpuidle_unregister_device(struct cpuidle_device *dev)
{
- if (dev->registered == 0)
+ if (!dev || dev->registered == 0)
return;
cpuidle_pause_and_lock();
Oops, wait. Are we sure the problem is coming from cpuidle ?
The cpuidle_unregister_device is called with a NULL pointer, that
shouldn't happen.
Konrad, you say that could be easily reproduced. How do you produce it ?
Unplugging a cpu ?
--
Facebook |
Twitter |
Re: [PATCH 3/4] usb: chipidea: msm: Initialize offset of the capability registers
On Wed, 2013-12-04 at 13:43 +0800, Peter Chen wrote:
> On Mon, Nov 11, 2013 at 03:35:36PM +0200, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
>
> The commit log is needed.
Will fix it.
Regards,
Ivan
>
> > Signed-off-by: Ivan T. Ivanov
> > ---
> > drivers/usb/chipidea/ci_hdrc_msm.c |1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
> > b/drivers/usb/chipidea/ci_hdrc_msm.c
> > index 747d6c1..e9624f3 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> > @@ -47,6 +47,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci,
> > unsigned event)
> >
> > static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
> > .name = "ci_hdrc_msm",
> > + .capoffset = DEF_CAPOFFSET,
> > .flags = CI_HDRC_REGS_SHARED |
> > CI_HDRC_REQUIRE_TRANSCEIVER |
> > CI_HDRC_DISABLE_STREAMING,
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb" 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/
Re: [PATCH v2 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms
* ville.syrj...@linux.intel.com wrote: > v2: Rewrite to use the TOM-TSEG_SIZE-stolen_size and TOUD methods I guess v2 is a reaction to my review feedback? I got no reply to my mail from you so I'm not sure and I'd like to know whether all feedback was addressed. Thanks, Ingo -- 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] vmcore: call remap_pfn_range() separately for respective partial pages
(2013/12/04 0:12), Vivek Goyal wrote: On Tue, Dec 03, 2013 at 02:16:35PM +0900, HATAYAMA Daisuke wrote: [..] Even if copying partial pages into the 2nd kernel, we need to use ioremap() once on them, and I think the ioremap() is exactly similar to remap_pfn_range() for a single page. There seems no difference on safeness between them. I suspected some kind of pre-fetching could be performed when just page table is created. But it's common thing between the two cases above. Then, as you say, it would be safer to read less data from non-System-RAM area. Copying seems better in our case. If we map page and just read *only* those bytes as advertized by ELF headers and fill rest of the bytes with zero, I think that seems like a right thing to do. We are only accessing what has been exported by ELF headers and not trying to read outside that range. Another concern to reading data from partial pages is a possibility of undesirable hardware prefetch to non-System-RAM area. Is it better to disable this? If it becomes an issue, may be. I think we can fix it when we run into an actual issue. I see. Also, current /proc/vmcore shows user-land tools a shape with holes not filled with zeros both in case of read() and in case of mmap(). If we adapt copying one without reading data in holes, shape of /proc/vmcore gets changed again. So, next patch will change data in holes by filling them with zeros. BTW, we have now page cache interface implemented by Michael Holzheu, but we have yet to use it on x86 because we've never wanted it so far. It's natural to use it to read partial pages on-demand, but I also in part think that it's not proper time to start using new mechanism that needs to be tested more. How do you think? Do we gain anything significant by using that interface. To me it looks like this will just delay creation of mapping for partial pages. Does not save us any memory in second kernel? Amount of partial pages seems not so problematic. No, the number of partial pages are at most the number of System RAM entries * 2. I guess the number of the entries doesn't exceed 100 even in the worst case. Less than 1MiB even in the worst case. The mechanism would be useful for platform that has large amount of note segment. But per-cpu note segemnt of x86 is relatively small, so meaningful platform seems the ones with a large number of cpus and they are still restrictive. Other archs that has large per-cpu note segment would already want the feature, just as Michael Holzheu explained previously for some of their s390 platform. I would think that in first pass, keep it simple. Copy partial pages in second kernel's memory. Read data as exported by ELF headers. Fill rest of the page with zeros. Adjust /proc/vmcore ELF headers accordingly and that should do it. Yes, I also want to keep simplicity. I'll post a new patch tomorrow. -- Thanks. HATAYAMA, Daisuke -- 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 4/4] sched: bias to target cpu load to reduce task moving
On Tue, Dec 03, 2013 at 05:05:56PM +0800, Alex Shi wrote:
> Task migration happens when target just a bit less then source cpu load.
> To reduce such situation happens, aggravate the target cpu load with
> sd->imbalance_pct/100.
>
> This patch removes the hackbench thread regression on Daniel's
> Intel Core2 server.
>
> a5d6e63 +patch1~3 +patch1~4
> hackbench -T -s 4096 -l 1000 -g 10 -f 40
> 27.914" 38.694" 28.587"
> 28.390" 38.341" 29.513"
> 28.048" 38.626" 28.706"
>
> Signed-off-by: Alex Shi
Hi Alex,
We obsevered 150% performance gain with vm-scalability/300s-mmap-pread-seq
testcase with this patch applied. Here is a list of changes we got so far:
testbox : brickland
testcase: vm-scalability/300s-mmap-pread-seq
f1b6442c7dd12802e622 d70495ef86f397816d73
(parent commit)(this commit)
26393249.80 +150.9% 66223933.60 vm-scalability.throughput
225.12 -49.9% 112.75 time.elapsed_time
36333.40 -90.7% 3392.20 vmstat.system.cs
2.40 +375.0%11.40 vmstat.cpu.id
3770081.60 -97.7% 87673.40 time.major_page_faults
3975276.20 -97.0%117409.60
time.voluntary_context_switches
3.05 +301.7%12.24 iostat.cpu.idle
21118.41 -70.3% 6277.19 time.system_time
18.40 +130.4%42.40 vmstat.cpu.us
77.00 -41.3%45.20 vmstat.cpu.sy
47459.60 -31.3% 32592.20 vmstat.system.in
82435.40 -12.1% 72443.60
time.involuntary_context_switches
5128.13 +14.0% 5848.30 time.user_time
11656.20-7.8% 10745.60
time.percent_of_cpu_this_job_got
1069997484.80+0.3% 1073679919.00 time.minor_page_faults
--yliu
> ---
> kernel/sched/fair.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index bccdd89..c49b7ba 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -978,7 +978,7 @@ static inline unsigned long group_weight(struct
> task_struct *p, int nid)
>
> static unsigned long weighted_cpuload(const int cpu);
> static unsigned long source_load(int cpu);
> -static unsigned long target_load(int cpu);
> +static unsigned long target_load(int cpu, int imbalance_pct);
> static unsigned long power_of(int cpu);
> static long effective_load(struct task_group *tg, int cpu, long wl, long wg);
>
> @@ -3809,11 +3809,17 @@ static unsigned long source_load(int cpu)
> * Return a high guess at the load of a migration-target cpu weighted
> * according to the scheduling class and "nice" value.
> */
> -static unsigned long target_load(int cpu)
> +static unsigned long target_load(int cpu, int imbalance_pct)
> {
> struct rq *rq = cpu_rq(cpu);
> unsigned long total = weighted_cpuload(cpu);
>
> + /*
> + * without cpu_load decay, in most of time cpu_load is same as total
> + * so we need to make target a bit heavier to reduce task migration
> + */
> + total = total * imbalance_pct / 100;
> +
> if (!sched_feat(LB_BIAS))
> return total;
>
> @@ -4033,7 +4039,7 @@ static int wake_affine(struct sched_domain *sd, struct
> task_struct *p, int sync)
> this_cpu = smp_processor_id();
> prev_cpu = task_cpu(p);
> load = source_load(prev_cpu);
> - this_load = target_load(this_cpu);
> + this_load = target_load(this_cpu, 100);
>
> /*
>* If sync wakeup then subtract the (maximum possible)
> @@ -4089,7 +4095,7 @@ static int wake_affine(struct sched_domain *sd, struct
> task_struct *p, int sync)
>
> if (balanced ||
> (this_load <= load &&
> - this_load + target_load(prev_cpu) <= tl_per_task)) {
> + this_load + target_load(prev_cpu, 100) <= tl_per_task)) {
> /*
>* This domain has SD_WAKE_AFFINE and
>* p is cache cold in this domain, and
> @@ -4135,7 +4141,7 @@ find_idlest_group(struct sched_domain *sd, struct
> task_struct *p, int this_cpu)
> if (local_group)
> load = source_load(i);
> else
> - load = target_load(i);
> + load = target_load(i, sd->imbalance_pct);
>
> avg_load += load;
> }
> @@ -5478,7 +5484,7 @@ static inline void update_sg_lb_stats(struct lb_env
> *env,
>
> /* Bias balancing toward cpus of our domain */
> if (local_group)
> - load =
Re: [PATCH] perf/x86: fix bug in event constraint end marker macro
* Stephane Eranian wrote:
> #define EVENT_CONSTRAINT_END \
> - EVENT_CONSTRAINT(0, 0, 0)
> + { .idxmsk64 = 0,\
> + .code = 0,\
> + .cmask = 0, \
> + .weight = -1, \
> + .overlap = 0, \
> + .flags = 0, \
> +}
A nit, simply writing:
#define EVENT_CONSTRAINT_END { .weight = -1, }
... should be enough as initialization to zero is guaranteed for the
other fields.
Thanks,
Ingo
--
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 RFC] mm readahead: Fix the readahead fail in case of empty numa node
On 12/04/2013 02:11 PM, Andrew Morton wrote: On Wed, 04 Dec 2013 14:00:09 +0530 Raghavendra K T wrote: Unfaortunately, from my search, I saw that the code belonged to pre git time, so could not get much information on that. Here: https://lkml.org/lkml/2004/8/20/242 It seems it was done as a rather thoughtless performance optimisation. I'd say it's time to reimplement max_sane_readahead() from scratch. Ok. Thanks for the link. I think after that, Here it was changed to pernode: https://lkml.org/lkml/2004/8/21/9 to avoid iteration all over. do you think above patch (+comments) with some sanitized nr (thus avoiding iteration over nodes in remote numa readahead case) does look better? or should we iterate all memory. -- 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] perf/x86: fix bug in event constraint end marker macro
[repost because typo in Ingo's email address]
The EVENT_CONSTRAINT_END macro defines the end marker as
a constraint with a weight of zero. This was all fine
until we blacklisted the corrupting memory events on
Intel IvyBridge. These events are blacklisted by using
a counter bitmask of zero. Thus, they also get a constraint
weight of zero.
The iteration macro: for_each_constraint tests the weight==0.
Therefore, it was stopping at the first blacklisted event, i.e.,
0xd0. The corrupting events were therefore considered as
unconstrained and were scheduled on any of the generic counters.
This patch fixes the end marker to have a weight of -1. With this,
the blacklisted events get an empty constraint and cannot be
scheduled which is what we want for now.
Signed-off-by: Stephane Eranian
---
arch/x86/kernel/cpu/perf_event.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index fd00bb2..7c900c9 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -263,10 +263,16 @@ struct cpu_hw_events {
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_ST_HSW)
#define EVENT_CONSTRAINT_END \
- EVENT_CONSTRAINT(0, 0, 0)
+ { .idxmsk64 = 0,\
+ .code = 0,\
+ .cmask = 0, \
+ .weight = -1, \
+ .overlap = 0, \
+ .flags = 0, \
+}
#define for_each_event_constraint(e, c)\
- for ((e) = (c); (e)->weight; (e)++)
+ for ((e) = (c); (e)->weight != -1; (e)++)
/*
* Extra registers for specific events.
--
1.8.1.2
--
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: Regression due to 0c44c2d0f459 x86: Use asm goto to implement better modify_and_test() functions
* H. Peter Anvin wrote: > Hi guys, > > 0c44c2d0f459 x86: Use asm goto to implement better modify_and_test() > functions > > causes a regression, because it incorrectly changed the constraints of > bitops. > > Specifically, the GEN_BINARY_RMWcc() hardcodes a constraint as "er", but > it needs to be "Ir" for the bitops themselves. "I" is correct (as > opposed to "J" even on 64 bits, because we only generate the 64-bit > version when we have a register operand. > > Unfortunately there isn't a way we can get gcc+gas to generate a version > with an offset pointer. Does the regression manifest itself in any actual breakage - if yes, how does it look like? (People experiencing similar symptoms will be helped by seeing a fix matching their problems.) Thanks, ngo -- 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: mac80211: tx.c: be sure of 'sdata->vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
On 12/04/2013 04:49 PM, Johannes Berg wrote: > On Wed, 2013-12-04 at 16:41 +0800, Chen Gang wrote: > >> According to our original discussion, it seems we agree that I am not >> the suitable member to finish it, so I suggest you or another members to >> try. > > There's nothing to finish here. The code is fine. The compiler is wrong, > but we haven't found a way to shut up the compiler without breaking the > code. Please let's just let it rest. > For me, I still stick to the code can be improved, although it is not urgent. But just like you said, we can just stop discussing -- every members can save their own opinions. And I am not the related maintainer, so if no additional suggestions, discussions or completions, I will/should stop here. Thanks. -- Chen Gang -- 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: [tip:x86/urgent] x86-64, build: Always pass in -mno-sse
* tip-bot for H. Peter Anvin wrote: > Commit-ID: 5551a34e5aeab868f8d37f70d8754868921b4ee5 > Gitweb: http://git.kernel.org/tip/5551a34e5aeab868f8d37f70d8754868921b4ee5 > Author: H. Peter Anvin > AuthorDate: Wed, 20 Nov 2013 13:31:49 -0800 > Committer: H. Peter Anvin > CommitDate: Tue, 3 Dec 2013 17:40:22 -0800 > > x86-64, build: Always pass in -mno-sse > > Always pass in the -mno-sse argument, regardless if > -preferred-stack-boundary is supported. We never want to generate SSE > instructions in the kernel unless we *really* know what we're doing. > > According to H. J. Lu, any version of gcc new enough that we support > it at all should handle the -mno-sse option, so just add it > unconditionally. > > Reported-by: Kevin B. Smith > Signed-off-by: H. Peter Anvin > Cc: H. J. Lu > Link: http://lkml.kernel.org/n/tip-j21wzqv790q834n7yc6g8...@git.kernel.org > Cc: # build fix only > --- > arch/x86/Makefile | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > index 41250fb..eda00f9 100644 > --- a/arch/x86/Makefile > +++ b/arch/x86/Makefile > @@ -31,6 +31,9 @@ ifeq ($(CONFIG_X86_32),y) > > KBUILD_CFLAGS += -msoft-float -mregparm=3 -freg-struct-return > > +# Don't autogenerate SSE instructions > + KBUILD_CFLAGS += -mno-sse > + > # Never want PIC in a 32-bit kernel, prevent breakage with GCC built > # with nonstandard options > KBUILD_CFLAGS += -fno-pic > @@ -57,8 +60,11 @@ else > KBUILD_AFLAGS += -m64 > KBUILD_CFLAGS += -m64 > > +# Don't autogenerate SSE instructions > + KBUILD_CFLAGS += -mno-sse > + > # Use -mpreferred-stack-boundary=3 if supported. > - KBUILD_CFLAGS += $(call cc-option,-mno-sse -mpreferred-stack-boundary=3) > + KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=3) > > # FIXME - should be integrated in Makefile.cpu (Makefile_32.cpu) > cflags-$(CONFIG_MK8) += $(call cc-option,-march=k8) Just a detail I noticed: in kbuild we intentionally use 8 spaces for tabs in Makefiles and only use tabs for commands where tabs are required. The above code introduces tabs in the middle of 8-space sequences. It works but is inconsistent. Thanks, Ingo -- 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: mac80211: tx.c: be sure of 'sdata->vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
On Wed, 2013-12-04 at 16:41 +0800, Chen Gang wrote: > According to our original discussion, it seems we agree that I am not > the suitable member to finish it, so I suggest you or another members to > try. There's nothing to finish here. The code is fine. The compiler is wrong, but we haven't found a way to shut up the compiler without breaking the code. Please let's just let it rest. johannes -- 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] atmel_lcdfb: fix module autoload
On 2013-12-02 20:25, Nicolas Ferre wrote:
> On 22/10/2013 18:36, Johan Hovold :
>> Add missing module device table which is needed for module autoloading.
>>
>> Signed-off-by: Johan Hovold
>
> Acked-by: Nicolas Ferre
>
> Jean-Christophe, Tomi,
>
> Can you please take this patch?
>
> Best regards,
>
>
>> ---
>> drivers/video/atmel_lcdfb.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
>> index 088511a..67b339c 100644
>> --- a/drivers/video/atmel_lcdfb.c
>> +++ b/drivers/video/atmel_lcdfb.c
>> @@ -94,6 +94,7 @@ static const struct platform_device_id
>> atmel_lcdfb_devtypes[] = {
>> /* terminator */
>> }
>> };
>> +MODULE_DEVICE_TABLE(platform, atmel_lcdfb_devtypes);
>>
>> static struct atmel_lcdfb_config *
>> atmel_lcdfb_get_config(struct platform_device *pdev)
>>
Thanks, queued for 3.13 fbdev fixes.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs
On 4 December 2013 13:09, Masami Hiramatsu wrote: > (2013/12/04 11:54), Sandeepa Prabhu wrote: >> On 4 December 2013 06:58, Masami Hiramatsu >> wrote: >>> Hi, >>> Here is the version 4 of NOKPORBE_SYMBOL series. >>> >>> In this version, I removed the cleanup patches and >>> add bugfixes I've found, since those bugs will be >>> critical. >>> Rest of the cleanup and visible blacklists will be >>> proposed later in another series. >>> >>> Oh, just one new thing, I added a new RFC patch which >>> removes the dependency of notify_die() from kprobes >>> miss-hit/recovery path. Since the notify_die() involves >>> locking and lockdep code which invokes a lot of heavy >>> printk functions etc. This helped me to minimize the >>> blacklist and provides more stability for kprobes. >>> Actually, most of int3 handlers are already called >>> from do_int3 directly, I think this change is acceptable >>> too. >>> >>> Here is the updates about NOKPROBE_SYMBOL(). >>> - Now _ASM_NOKPROBE() macro is introduced for assembly >>>symbols on x86. >>> - Rename kprobe_blackpoint to kprobe_blacklist_entry >>>and simplify it. Also NOKPROBE_SYMBOL() macro just >>>saves the address of non-probe-able symbols. >>> >>> --- >>> >>> Masami Hiramatsu (6): >> >>> kprobes: Prohibit probing on .entry.text code >>> kprobes: Introduce NOKPROBE_SYMBOL() macro for blacklist >> Hi Masami, >> Is it good idea to split "arch/x86" code from generic kernel changes? >> Then we just need to take above two patches for verifying it on arm64 >> or other platforms. > > Yeah, it can be. > However I think you can apply it without any problem on arm64 tree too, > since it "just adds" an asm macro in arch/x86/include/asm/asm.h. > It should not have any effect for other arch. Could you try it? :) Hmm, for the second patch, git am failed with: "error: patch failed: kernel/sched/core.c:2662", manually patched to resolve it. aarch64 tree is right now at Linux 3.13-rc2. Anyways, no conflicts for x86 arch files. Thanks, Sandeepa > Thank you, > > > -- > Masami HIRAMATSU > IT Management Research Dept. Linux Technology Center > Hitachi, Ltd., Yokohama Research Laboratory > E-mail: masami.hiramatsu...@hitachi.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 -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs
* Masami Hiramatsu wrote: > Hi, > Here is the version 4 of NOKPORBE_SYMBOL series. > > In this version, I removed the cleanup patches and > add bugfixes I've found, since those bugs will be > critical. > > Rest of the cleanup and visible blacklists will be proposed later in > another series. Ok, let me make it clear: we need _both_ the conceptual cleanups and the bug fixes. Right now kprobes are restricted to root, and they are unsafe and buggy, and rather fundamentally so, because probing cannot be done safely without potentially crashing the kernel. So there's no 'regression' to be fixed, it's mostly about pre-existing bugs - so there's no requirement for them to come before maintainability cleanups. So we need both a maintainable and a sane/safe solution, and I'd like to apply the whole thing at once and be at ease that the solution is round. We should have done this years ago. So could you please send a whole series that I can apply to -tip as a work in progress tree, and then we can see what is left to be solved? Thanks, Ingo -- 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 00/41] percpu: Consistent per cpu operations V1
* Christoph Lameter wrote: > The kernel has never been audited to ensure that this_cpu operations > are consistently used throughout the kernel. The code generated in > many places can be improved through the use of this_cpu operations > (which uses a segment register for relocation of per cpu offsets > instead of performing address calculations). Your series lacks the this_cpu ops preempt debugging patches that you worked on before, what happened to them? Those debug facilities caught kernel real bugs and they are thus essential before any percpu extension can be done. Thanks, Ingo -- 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 RFC] mm readahead: Fix the readahead fail in case of empty numa node
On Wed, 04 Dec 2013 14:00:09 +0530 Raghavendra K T wrote: > > I don't recall the rationale for the current code and of course we > > didn't document it. It might be in the changelogs somewhere - could > > you please do the git digging and see if you can find out? > > Unfaortunately, from my search, I saw that the code belonged to pre git > time, so could not get much information on that. Here: https://lkml.org/lkml/2004/8/20/242 It seems it was done as a rather thoughtless performance optimisation. I'd say it's time to reimplement max_sane_readahead() from scratch. -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Hi On 10/24/2013 03:31 PM, Gao feng wrote: > Here is the v1 patchset: http://lwn.net/Articles/549546/ > > The main target of this patchset is allowing user in audit > namespace to generate the USER_MSG type of audit message, > some userspace tools need to generate audit message, or > these tools will broken. > I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. > And the login process in container may want to setup > /proc//loginuid, right now this value is unalterable > once it being set. this will also broke the login problem > in container. After this patchset, we can reset this loginuid > to zero if task is running in a new audit namespace. > I notice this problem has been fixed in audit tree, so may be I don't need to clean up loginuid when we create audit namespace. And in audit tree, audit socket is per net namespace, hmm, I want to know if anybody has a solution to allow processes to generate USER_MSG type of audit message in un init pid/user namepsace. Any idea? Eric,Steve,Richard? Thanks Gao -- 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: mac80211: tx.c: be sure of 'sdata->vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
On 12/04/2013 04:04 PM, Johannes Berg wrote: > On Wed, 2013-12-04 at 10:12 +0800, Chen Gang wrote: > >> It is really not urgent, and for keeping quality, it is necessary to >> spend suitable time resource (e.g 1 hour or more) to make, review and >> test this kind of patch carefully by oneself. >> >> So could you please help improve it when you have suitable related time >> resources? > > No. Who are you to suggest what I need to work on? > > johannes > I am one of volunteers for Open Source, and I don't care about who I am. Since this thread is started by me, I have duty to try my best to let it finish (but may fail). According to our original discussion, it seems we agree that I am not the suitable member to finish it, so I suggest you or another members to try. Thanks. -- Chen Gang -- 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] fs: fix WARN on alloc_super() fail path
On fail path alloc_super() calls destroy_super(), which issues a warning if list_empty() returns false on the s_mounts field. That said s_mounts should be initialized in alloc_super() before any possible failure. Signed-off-by: Vladimir Davydov Cc: Al Viro --- fs/super.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/super.c b/fs/super.c index e5f6c2c..cecd780 100644 --- a/fs/super.c +++ b/fs/super.c @@ -166,6 +166,8 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags) if (!s) return NULL; + INIT_LIST_HEAD(>s_mounts); + if (security_sb_alloc(s)) goto fail; @@ -188,7 +190,6 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags) if (list_lru_init(>s_inode_lru)) goto fail; - INIT_LIST_HEAD(>s_mounts); init_rwsem(>s_umount); lockdep_set_class(>s_umount, >s_umount_key); /* -- 1.7.10.4 -- 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] usb: chipidea: msm: Add device tree binding information
Hi Peter,
Thank you for reviewing this patch.
On Wed, 2013-12-04 at 13:40 +0800, Peter Chen wrote:
> On Mon, Nov 11, 2013 at 03:35:34PM +0200, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
>
> Please add something in commit log
>
> > Signed-off-by: Ivan T. Ivanov
> > Cc: devicet...@vger.kernel.org
> > ---
> > .../devicetree/bindings/usb/msm-hsusb.txt | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
> > b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
> > index 5ea26c6..0a85eba 100644
> > --- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
> > +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
> > @@ -15,3 +15,19 @@ Example EHCI controller device node:
> > usb-phy = <_otg>;
> > };
> >
> > +CI13xxx (Chipidea) USB controllers
> > +
>
> We have already renamed ci13xxx to ci_hdrc.
Yes, but the chip is still CI13XXX. Freescale documentations is also
referring to actual chip family.
>
> > +Required properties:
> > +- compatible: should contain "qcom,ci-hdrc"
> > +- reg: offset and length of the register set in the
> > memory map
> > +- interrupts: interrupt-specifier for the controller interrupt.
> > +- usb-phy: phandle for the PHY device
> > +- dr_mode: Sould be "peripheral"
> > +
>
> Please keep alignment for "reg"
>
It looks aligned in editor with smart-tab support.
Regards,
Ivan
> Peter
>
> > + gadget@f9a55000 {
> > + compatible = "qcom,ci-hdrc";
> > + reg = <0xf9a55000 0x400>;
> > + dr_mode = "peripheral";
> > + interrupts = <0 134 0>;
> > + usb-phy = <_otg>;
> > + };
> > \ No newline at end of file
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] perf/x86: fix bug in event constraint end marker macro
The EVENT_CONSTRAINT_END macro defines the end marker as
a constraint with a weight of zero. This was all fine
until we blacklisted the corrupting memory events on
Intel IvyBridge. These events are blacklisted by using
a counter bitmask of zero. Thus, they also get a constraint
weight of zero.
The iteration macro: for_each_constraint tests the weight==0.
Therefore, it was stopping at the first blacklisted event, i.e.,
0xd0. The corrupting events were therefore considered as
unconstrained and were scheduled on any of the generic counters.
This patch fixes the end marker to have a weight of -1. With this,
the blacklisted events get an empty constraint and cannot be
scheduled which is what we want for now.
Signed-off-by: Stephane Eranian
---
arch/x86/kernel/cpu/perf_event.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index fd00bb2..7c900c9 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -263,10 +263,16 @@ struct cpu_hw_events {
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_ST_HSW)
#define EVENT_CONSTRAINT_END \
- EVENT_CONSTRAINT(0, 0, 0)
+ { .idxmsk64 = 0,\
+ .code = 0,\
+ .cmask = 0, \
+ .weight = -1, \
+ .overlap = 0, \
+ .flags = 0, \
+}
#define for_each_event_constraint(e, c)\
- for ((e) = (c); (e)->weight; (e)++)
+ for ((e) = (c); (e)->weight != -1; (e)++)
/*
* Extra registers for specific events.
--
1.8.1.2
--
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 v4 1/3] mfd: tps6586x: add version detection
Am 2013-12-04 09:10, schrieb Lee Jones:
>> +int tps6586x_get_version(struct device *dev)
>> +{
>> +struct tps6586x *tps6586x = dev_get_drvdata(dev);
>> +
>> +return tps6586x->version;
>> +}
>> +EXPORT_SYMBOL_GPL(tps6586x_get_version);
>
> I thought Mark suggested that this routine was converted to a 'static
> inline' and moved into the header? Did you not think this was a good
> idea?
As I pointed out in the comment above, the struct tps6586x is in the C
file, so I would need to move that too. That's why I did not made that
change in the end. What do you think, should I still move (and move the
struct too?)
--
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] usb: ohci-at91: use device managed clk retrieval
Hello Alan, On 03/12/2013 16:32, Alan Stern wrote: On Tue, 3 Dec 2013, Nicolas Ferre wrote: On 03/12/2013 15:07, Boris BREZILLON : Replace clk_get calls by devm_clk_get calls. Signed-off-by: Boris BREZILLON Tested-by: Robert Nelson Acked-by: Nicolas Ferre Thanks Boris for these fixes. Alan, Greg, can you take the whole series as fixes for 3.13? Signed-off-by: Alan Stern Sorry, but I forgot to add your Signed-off-by in the 2nd version of this series. The patches look fine to me. But only the 1/3 patch fixes a bug; the others merely change the resource management. Do you want me to split this series ? 1) the 1st patch that should be merged in 3.13 2) patches 2 to 4 that might be applied later Best Regards, Boris Alan Stern -- 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] mfd: Fix memory leak in mfd_add_devices()
On Tue, 29 Oct 2013, Geert Uytterhoeven wrote: > If the first call to mfd_add_device() fails, no child devices have been > registered to the parent yet, and thus mfd_remove_devices() won't find > anything to remove nor free. > Hence the previously allocated array of atomic_t objects will leak. > > Free the array instead of calling mfd_remove_devices() on failure during > the first loop iteration to fix this. > > Signed-off-by: Geert Uytterhoeven > --- > drivers/mfd/mfd-core.c | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) Hmm... I didn't see my reply to this, but it has been applied for a while. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
On Wed, 04 Dec 2013 16:13:31 +0800 Axel Lin wrote:
> I can constantly hit this issue:
>
> I trace it to mm/filemap.c: add_to_page_cache_locked
> I print the in_atomic status at BEGIN and END of add_to_page_cache_locked
> call.
> Then I got in_atomic is true at the end of add_to_page_cache_locked call.
>
> int add_to_page_cache_locked(struct page *page, struct address_space *mapping,
> pgoff_t offset, gfp_t gfp_mask)
> {
> int error;
>
> VM_BUG_ON(!PageLocked(page));
> VM_BUG_ON(PageSwapBacked(page));
>
> pr_info(" ##add_to_page_cache_locked BEGIN in_atomic=%d\n", in_atomic());
> error = mem_cgroup_cache_charge(page, current->mm,
> gfp_mask & GFP_RECLAIM_MASK);
> if (error)
> return error;
>
> error = radix_tree_maybe_preload(gfp_mask & ~__GFP_HIGHMEM);
> if (error) {
> mem_cgroup_uncharge_cache_page(page);
> return error;
> }
>
> page_cache_get(page);
> page->mapping = mapping;
> page->index = offset;
>
> spin_lock_irq(>tree_lock);
> error = radix_tree_insert(>page_tree, offset, page);
> radix_tree_preload_end();
> if (unlikely(error))
> goto err_insert;
> mapping->nrpages++;
> __inc_zone_page_state(page, NR_FILE_PAGES);
> spin_unlock_irq(>tree_lock);
> trace_mm_filemap_add_to_page_cache(page);
> pr_info(" ##add_to_page_cache_locked END in_atomic=%d\n", in_atomic());
> return 0;
> err_insert:
> page->mapping = NULL;
> /* Leave page->index set: truncation relies upon it */
> spin_unlock_irq(>tree_lock);
> mem_cgroup_uncharge_cache_page(page);
> page_cache_release(page);
> pr_info(" ##add_to_page_cache_locked ERR in_atomic=%d\n", in_atomic());
> return error;
> }
>
> Then I got below messages:
> ##add_to_page_cache_locked BEGIN in_atomic=0
> ##add_to_page_cache_locked END in_atomic=0
> ##add_to_page_cache_locked BEGIN in_atomic=0
> ##add_to_page_cache_locked END in_atomic=0
> ##add_to_page_cache_locked BEGIN in_atomic=0
> ##add_to_page_cache_locked END in_atomic=1
huh. I can't spot it. mem_cgroup_cache_charge() is by far the most
complex callee.
Is tracing enabled?
Is memcg in use?
Please add a lot more printk's so we can narrow it down further? I'd
use something like
printk(%d: %d\n", __LINE__, preempt_count());
(note: preempt_count(), not in_atomic())
Paste that all over the place so we can see which statement is doing
the wrong thing.
Thanks.
--
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 RFC] mfd: Stop setting refcounting pointers in original mfd_cell arrays
On Tue, 29 Oct 2013, Geert Uytterhoeven wrote:
> Commit 1e29af62f2b285bd18685da93c3ce8c33ca2d1db ("mfd: Add refcounting
> support to mfd_cells") had to drop the "const" keyword on the "cell"
> parameter of mfd_add_devices(), as it added the refcounting pointers
> to the objects of the passed mfd_cell array itself.
>
> However, the mfd core code operates on copies of the mfd_cell objects,
> so there's no need to modify the originally passed objects.
>
> Hence, move the setting of the refcounting pointers from mfd_add_devices()
> to mfd_platform_add_cell(), where the copy of the mfd_cell objects is made.
> mfd_clone_cell() can just pass (a copy of) the original usage_count
> pointer.
>
> This allows to make the "cell" parameter of mfd_add_devices() "const"
> again, and avoids future race conditions when registering multiple
> instances of the same device in parallel.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Ever since this "const" keyword was removed, I was wondering what was
> really going on with these reference counts. My main use case involved
> multiple instances of the same device, where the registration of each
> successive instance would overwrite the refcounting pointer of the
> previous one.
> Finally I found some time to dive into it, and create this patch.
> If it is accepted, I'll create a follow-up patch to add
> "const" keywords to the various mfd_cell arrays.
>
> Note that there's another issue in mfd_add_devices(): if the first call to
> mfd_add_device() fails, the array of atomic_t objects will never be freed,
> as no child devices have been registered to the parent yet, and thus
> mfd_remove_devices() won't find anything to remove nor free.
>
> drivers/mfd/mfd-core.c | 17 +
> include/linux/mfd/core.h |2 +-
> 2 files changed, 10 insertions(+), 9 deletions(-)
Hmm... I didn't see my reply to this, but it has been applied for a
while.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: How to change erasesize of a partition
I though it would be configurable some where in kernel On Wednesday, December 4, 2013 1:25 PM, Richard Weinberger wrote: On Wed, Dec 4, 2013 at 8:46 AM, Suki Buryani wrote: > hi, > > i have few changes in my mtd partitions, i want to change the erasesize of a > partition. can any one tell me where i should look to change erasesize of > mtd3... The erase size is defined by the MTD device, you cannot change it. -- Thanks, //richard -- 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/ -- 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: How to change erasesize of a partition
On Wed, Dec 4, 2013 at 8:46 AM, Suki Buryani wrote: > hi, > > i have few changes in my mtd partitions, i want to change the erasesize of a > partition. can any one tell me where i should look to change erasesize of > mtd3... The erase size is defined by the MTD device, you cannot change it. -- Thanks, //richard -- 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: [f2fs-dev] [PATCH v2] f2fs: refactor bio-related operations
Hi,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Wednesday, December 04, 2013 4:11 PM
> To: Chao Yu
> Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net;
> linux-fsde...@vger.kernel.org; 谭姝
> Subject: RE: [f2fs-dev] [PATCH v2] f2fs: refactor bio-related operations
>
> Hi,
>
> > > + if (btype == META)
> > > + rw |= REQ_META;
> > > +
> > > + if (is_read_io(rw)) {
> > > + if (sync)
> > > + rw |= READ_SYNC;
> > > + submit_bio(rw, io->bio);
> > > + trace_f2fs_submit_read_bio(sbi->sb, rw, type, io->bio);
> > > + io->bio = NULL;
> > > + return;
> > > + }
> > > +
> > > + if (sync)
> > > + rw |= WRITE_SYNC;
> >
> > rw = WRITE_SYNC; ?
>
> No, since it removes the REQ_META.
> See above.
Ah, you're right, Thanks.
>
> >
> > > + if (type >= META_FLUSH)
> > > + rw |= WRITE_FLUSH_FUA;
> >
> > rw = WRITE_FLUSH_FUA; ?
> >
> > > +
> > > + /*
> > > + * META_FLUSH is only from the checkpoint procedure, and we should wait
> > > + * this metadata bio for FS consistency.
> > > + */
> > > + if (type == META_FLUSH) {
> > > + DECLARE_COMPLETION_ONSTACK(wait);
> > > + io->bio->bi_private =
> > > + submit_bio(rw, io->bio);
> > > + wait_for_completion();
> > > + } else {
> > > + submit_bio(rw, io->bio);
> > > + }
> > > + trace_f2fs_submit_write_bio(sbi->sb, rw, btype, io->bio);
> > > + io->bio = NULL;
> > > +}
> >
> > [snip]
> >
> > Thanks,
> > Yu
> >
>
> --
> Jaegeuk Kim
> Samsung
--
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] Staging: speakup: synth.c: removed a space
You and I generally agree on style preferences... I think the warning should be limited to grep " ;$". I did a grep on the kernel for ' ;' and found 8000 results. 6000 of them are caught by my semicolon before the newline rule. The remaining 2000 are assembly, macros, and crappy for loops. regards, dan carpenter -- 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 RFC] mm readahead: Fix the readahead fail in case of empty numa node
Thank you Andrew.
On 12/04/2013 04:08 AM, Andrew Morton wrote:
On Tue, 3 Dec 2013 16:06:17 +0530 Raghavendra K T
wrote:
On a cpu with an empty numa node,
This makes no sense - numa nodes don't reside on CPUs.
I think you mean "on a CPU which resides on a memoryless NUMA node"?
You are right. I was not precise there.
I had this example in mind while talking.
IBM P730
--
# numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
23 24 25 26 27 28 29 30 31
node 0 size: 0 MB
node 0 free: 0 MB
node 1 cpus:
node 1 size: 12288 MB
node 1 free: 10440 MB
node distances:
node 0 1
0: 10 40
1: 40 10
readahead fails because max_sane_readahead
returns zero. The reason is we look into number of inactive + free pages
available on the current node.
The following patch tries to fix the behaviour by checking for potential
empty numa node cases.
The rationale for the patch is, readahead may be worth doing on a remote
node instead of incuring costly disk faults later.
I still feel we may have to sanitize the nr below, (for e.g., nr/8)
to avoid serious consequences of malicious application trying to do
a big readahead on a empty numa node causing unnecessary load on remote nodes.
( or it may even be that current behaviour is right in not going ahead with
readahead to avoid the memory load on remote nodes).
I don't recall the rationale for the current code and of course we
didn't document it. It might be in the changelogs somewhere - could
you please do the git digging and see if you can find out?
Unfaortunately, from my search, I saw that the code belonged to pre git
time, so could not get much information on that.
I don't immediately see why readahead into a different node is
considered a bad thing.
Ok.
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -243,8 +243,11 @@ int force_page_cache_readahead(struct address_space
*mapping, struct file *filp,
*/
unsigned long max_sane_readahead(unsigned long nr)
{
- return min(nr, (node_page_state(numa_node_id(), NR_INACTIVE_FILE)
- + node_page_state(numa_node_id(), NR_FREE_PAGES)) / 2);
+ unsigned long numa_free_page;
+ numa_free_page = (node_page_state(numa_node_id(), NR_INACTIVE_FILE)
+ + node_page_state(numa_node_id(), NR_FREE_PAGES));
+
+ return numa_free_page ? min(nr, numa_free_page / 2) : nr;
Well even if this CPU's node has very little pagecache at all, what's
wrong with permitting readahead? We don't know that the new pagecache
will be allocated exclusively from this CPU's node anyway. All very
odd.
true we do not know from where it gets allocated and also I completely
agree that I could not think why we should not think
of entire memory rather than sticking our decision to one node.
Or is this one of proactive case to stop worsening situation when
system is really short of memory?
Do let me know if you have any idea to handle 'little cache case'
or do you think the current one is simple enough for now to live with.
Whatever we do, we should leave behind some good code comments which
explain the rationale(s), please. Right now it's rather opaque.
Yes. For the current code may be we have to have comment some thing
like ?
/*
* Sanitize readahead when we have less memory on the current node.
* We do not want to load remote memory with readahead case.
*/
and if this patch is okay then some thing like.
/*
* Sanitized readahead onto remote memory is better than no readahead
* when local numa node does not have memory. If local numa has less
* memory we trim readahead size depending on potential free memory
* available.
*/
--
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/2] dma: mmp-tdma: select sram driver
Reported-by: Dan Williams Signed-off-by: Qiao Zhou --- drivers/dma/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index dd2874e..599f0ae 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -288,9 +288,11 @@ config MMP_TDMA bool "MMP Two-Channel DMA support" depends on ARCH_MMP select DMA_ENGINE + select MMP_SRAM help Support the MMP Two-Channel DMA engine. This engine used for MMP Audio DMA and pxa910 SQU. + It needs sram driver under mach-mmp. Say Y here if you enabled MMP ADMA, otherwise say N. -- 1.7.0.4 -- 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] arm: mmp: build sram driver alone
sram driver can be used by many chips besides CPU_MMP2, and so build it alone. Reported-by: Dan Williams Signed-off-by: Qiao Zhou --- arch/arm/mach-mmp/Kconfig |3 +++ arch/arm/mach-mmp/Makefile |3 ++- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-mmp/Kconfig b/arch/arm/mach-mmp/Kconfig index ebdda83..ebdba87 100644 --- a/arch/arm/mach-mmp/Kconfig +++ b/arch/arm/mach-mmp/Kconfig @@ -136,4 +136,7 @@ config USB_EHCI_MV_U2O help Enables support for OTG controller which can be switched to host mode. +config MMP_SRAM + bool + endif diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile index 9b702a1..98f0f63 100644 --- a/arch/arm/mach-mmp/Makefile +++ b/arch/arm/mach-mmp/Makefile @@ -7,7 +7,8 @@ obj-y += common.o devices.o time.o # SoC support obj-$(CONFIG_CPU_PXA168) += pxa168.o obj-$(CONFIG_CPU_PXA910) += pxa910.o -obj-$(CONFIG_CPU_MMP2) += mmp2.o sram.o +obj-$(CONFIG_CPU_MMP2) += mmp2.o +obj-$(CONFIG_MMP_SRAM) += sram.o ifeq ($(CONFIG_COMMON_CLK), ) obj-y += clock.o -- 1.7.0.4 -- 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 V1] arm-mmp-build-sram-driver-alone
V1 -> V0: No need for help text for MMP_SRAM in Kconfig and move it into MMP_TDMA text in Kconfig. Qiao Zhou (2): arm: mmp: build sram driver alone dma: mmp-tdma: select sram driver arch/arm/mach-mmp/Kconfig |3 +++ arch/arm/mach-mmp/Makefile |3 ++- drivers/dma/Kconfig|2 ++ 3 files changed, 7 insertions(+), 1 deletions(-) -- 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 1/2] ARM: tegra: Add header file for pinctrl constants
On Tue, Dec 03, 2013 at 06:46:06PM +0530, Laxman Dewangan wrote: > This new header file defines pincontrol constants for Tegra to > use from Tegra's DTS file for pincontrol properties option. > > Signed-off-by: Laxman Dewangan > --- > Changes from V1: > - Get rid of lots of macro and converge it to TEGRA_PIN_ENABLE/DISABLE. > - Change macro name for PULL UP/DOWN/NONE. > > include/dt-bindings/pinctrl/pinctrl-tegra.h | 40 > +++ > 1 files changed, 40 insertions(+), 0 deletions(-) > create mode 100644 include/dt-bindings/pinctrl/pinctrl-tegra.h I like this a lot. One minor nit below. > diff --git a/include/dt-bindings/pinctrl/pinctrl-tegra.h > b/include/dt-bindings/pinctrl/pinctrl-tegra.h > new file mode 100644 > index 000..e5f02f8 > --- /dev/null > +++ b/include/dt-bindings/pinctrl/pinctrl-tegra.h > @@ -0,0 +1,40 @@ > +/* > + * This header provides constants for TEGRA pinctrl bindings. "TEGRA" -> "Tegra" Other than that: Reviewed-by: Thierry Reding pgpWcJUCR01O2.pgp Description: PGP signature
Re: [PATCH 4/6] kexec: A new system call, kexec_file_load, for in kernel kexec
On 12/04/13 at 09:56am, Baoquan He wrote:
> On 11/20/13 at 12:50pm, Vivek Goyal wrote:
> > + * that kexec_mutex is held.
> > + */
>
> I think kexec_add_buffer is guaranteed to be called before allocating
> control pages, why not updating image->control_page after each time
> kexec_add_buffer is called. Then when control page is needed, effective
> address in crash_kernel region can be given. This can be a little more
> efficient.
Check again, it's not a good idea. Because buf_align is different when
kexec_add_buffer is called. Sometime the bug_align is larger than 4k.
Please ignore this comment.
>
> > +int kexec_add_buffer(struct kimage *image, char *buffer,
> > + unsigned long bufsz, unsigned long memsz,
> > + unsigned long buf_align, unsigned long buf_min,
> > + unsigned long buf_max, int top_down, unsigned long *load_addr)
> > +{
> > +
> > + unsigned long nr_segments = image->nr_segments, new_nr_segments;
> > + struct kexec_segment *ksegment;
> > + struct kexec_buf *kbuf;
> > +
> > + /* Currently adding segment this way is allowed only in file mode */
> > + if (!image->file_mode)
> > + return -EINVAL;
> > +
> > + if (nr_segments >= KEXEC_SEGMENT_MAX)
> > + return -EINVAL;
> > +
> > + /*
> > +* Make sure we are not trying to add buffer after allocating
> > +* control pages. All segments need to be placed first before
> > +* any control pages are allocated. As control page allocation
> > +* logic goes through list of segments to make sure there are
> > +* no destination overlaps.
> > +*/
> > + WARN_ONCE(!list_empty(>control_pages), "Adding kexec buffer"
> > + " after allocating control pages\n");
> > +
> > + kbuf = kzalloc(sizeof(struct kexec_buf), GFP_KERNEL);
> > + if (!kbuf)
> > + return -ENOMEM;
> > +
--
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] mac80211: rx: Neaten ieee80211_deliver_skb, remove compare_ether_addr
On Tue, 2013-12-03 at 10:29 -0800, Joe Perches wrote:
> Remove the unnecessary duplicate test of "if (skb) {"
> when !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS.
>
> Remove now unnecessary __maybe_unused, neaten comment
> Remove unnecessary parenthesis around align cast.
> Substitute reference to deprecated compare_ether_addr
> with ether_addr_equal.
I already had a patch to remove the __maybe_unused, but this looks good,
applied.
johannes
--
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: [Intel-gfx] [PATCH 1/3] ACPI/i915: Fix wrong inclusion in i915 opregion module.
On Wed, Dec 04, 2013 at 08:38:08AM +0800, Lv Zheng wrote: > In Linux kernel, ACPICA is wrapped and safely exported by CONFIG_ACPI. So > all external modules should depend on CONFIG_ACPI rather than using ACPICA > header directly for stubbing. But if we moves inclusions > into "#ifdef CONFIG_ACPI", build breakge can help to detect wrong ACPICA > dependent modules. > > One of the build breakage is: > include/linux/acpi_io.h:7:45: error: unknown type name 'acpi_physical_address' > include/linux/acpi_io.h:8:10: error: unknown type name 'acpi_size' > include/linux/acpi_io.h:13:33: error: unknown type name > 'acpi_physical_address' > include/linux/acpi_io.h:15:40: warning: 'struct acpi_generic_address' > declared inside parameter list [enabled by default] > include/linux/acpi_io.h:15:40: warning: its scope is only this definition or > declaration, which is probably not what you want [enabled by default] > include/linux/acpi_io.h:16:43: warning: 'struct acpi_generic_address' > declared inside parameter list [enabled by default] > drivers/gpu/drm/i915/intel_opregion.c: In function 'intel_opregion_setup': > drivers/gpu/drm/i915/intel_opregion.c:883:2: error: implicit declaration of > function 'acpi_os_ioremap' [-Werror=implicit-function-declaration] > drivers/gpu/drm/i915/intel_opregion.c:883:7: warning: assignment makes > pointer from integer without a cast [enabled by default] > > The root causes of this breakage are: > 1. The depends on CONFIG_ACPI=y as most of the prototypes >exported by it are implemented in drivers/acpi/osl.c. > 2. CONFIG_DRM_I915 uses the only "inline" function acpi_os_ioremap() to >implement stubs but it shouldn't. > > Since ACPI IGD OpRegion is an ACPI-based mechanism, (please refer to the > Doclink below), this patch fixes this issue by making > drivers/gpu/drm/i915/intel_opregion.c dependent on CONFIG_ACPI. This is > identical to other Intel DRM drivers' OpRegion support (e.x., > drivers/gpu/drm/gma500/opregion.c). > > Since acpi_io.h is not safe for CONFIG_ACPI=y environment, this patch also > moves it to include/acpi, includes it in for CONFIG_ACPI=y > build environment and cleans up its inclusions by converting them into > inclusions. > > Doclink: > https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf > Cc: Matthew Garrett > Cc: Daniel Vetter > Cc: intel-...@lists.freedesktop.org > Signed-off-by: Lv Zheng Makes sense. Acked for merging through acpi trees (or whatever else is appropriate, patch seems to be part of a series). Cheers, Daniel > --- > drivers/acpi/apei/apei-base.c |1 - > drivers/acpi/apei/apei-internal.h |1 - > drivers/acpi/apei/ghes.c |1 - > drivers/acpi/nvs.c|1 - > drivers/acpi/osl.c|1 - > drivers/gpu/drm/gma500/opregion.c |1 - > drivers/gpu/drm/i915/Makefile |3 +-- > drivers/gpu/drm/i915/i915_drv.h |3 ++- > include/acpi/acpi_io.h| 17 + > include/linux/acpi.h |1 + > include/linux/acpi_io.h | 18 -- > 11 files changed, 21 insertions(+), 27 deletions(-) > create mode 100644 include/acpi/acpi_io.h > delete mode 100644 include/linux/acpi_io.h > > diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c > index 6d2c49b..0760b75 100644 > --- a/drivers/acpi/apei/apei-base.c > +++ b/drivers/acpi/apei/apei-base.c > @@ -34,7 +34,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/acpi/apei/apei-internal.h > b/drivers/acpi/apei/apei-internal.h > index 21ba34a..e5bcd91 100644 > --- a/drivers/acpi/apei/apei-internal.h > +++ b/drivers/acpi/apei/apei-internal.h > @@ -8,7 +8,6 @@ > > #include > #include > -#include > > struct apei_exec_context; > > diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c > index a30bc31..694c486 100644 > --- a/drivers/acpi/apei/ghes.c > +++ b/drivers/acpi/apei/ghes.c > @@ -33,7 +33,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/acpi/nvs.c b/drivers/acpi/nvs.c > index 386a9fe..ef28613 100644 > --- a/drivers/acpi/nvs.c > +++ b/drivers/acpi/nvs.c > @@ -12,7 +12,6 @@ > #include > #include > #include > -#include > > /* ACPI NVS regions, APEI may use it */ > > diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c > index 7e2d814..63251b6 100644 > --- a/drivers/acpi/osl.c > +++ b/drivers/acpi/osl.c > @@ -39,7 +39,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/gma500/opregion.c > b/drivers/gpu/drm/gma500/opregion.c > index ad0d6de..13ec628 100644 > --- a/drivers/gpu/drm/gma500/opregion.c > +++ b/drivers/gpu/drm/gma500/opregion.c > @@ -22,7 +22,6 @@ > * > */ > #include > -#include > #include "psb_drv.h" > #include "psb_intel_reg.h" > > diff --git
Re: [PATCH] mfd: wm831x: Use PM ops for shutdown
On Fri, 08 Nov 2013, Mark Brown wrote: > From: Mark Brown > > This helps move us towards removing the bus custom operations. > > Signed-off-by: Mark Brown > --- > drivers/mfd/wm831x-i2c.c | 8 +--- > drivers/mfd/wm831x-spi.c | 8 +--- > 2 files changed, 10 insertions(+), 6 deletions(-) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
I can constantly hit this issue:
I trace it to mm/filemap.c: add_to_page_cache_locked
I print the in_atomic status at BEGIN and END of add_to_page_cache_locked call.
Then I got in_atomic is true at the end of add_to_page_cache_locked call.
int add_to_page_cache_locked(struct page *page, struct address_space *mapping,
pgoff_t offset, gfp_t gfp_mask)
{
int error;
VM_BUG_ON(!PageLocked(page));
VM_BUG_ON(PageSwapBacked(page));
pr_info(" ##add_to_page_cache_locked BEGIN in_atomic=%d\n", in_atomic());
error = mem_cgroup_cache_charge(page, current->mm,
gfp_mask & GFP_RECLAIM_MASK);
if (error)
return error;
error = radix_tree_maybe_preload(gfp_mask & ~__GFP_HIGHMEM);
if (error) {
mem_cgroup_uncharge_cache_page(page);
return error;
}
page_cache_get(page);
page->mapping = mapping;
page->index = offset;
spin_lock_irq(>tree_lock);
error = radix_tree_insert(>page_tree, offset, page);
radix_tree_preload_end();
if (unlikely(error))
goto err_insert;
mapping->nrpages++;
__inc_zone_page_state(page, NR_FILE_PAGES);
spin_unlock_irq(>tree_lock);
trace_mm_filemap_add_to_page_cache(page);
pr_info(" ##add_to_page_cache_locked END in_atomic=%d\n", in_atomic());
return 0;
err_insert:
page->mapping = NULL;
/* Leave page->index set: truncation relies upon it */
spin_unlock_irq(>tree_lock);
mem_cgroup_uncharge_cache_page(page);
page_cache_release(page);
pr_info(" ##add_to_page_cache_locked ERR in_atomic=%d\n", in_atomic());
return error;
}
Then I got below messages:
##add_to_page_cache_locked BEGIN in_atomic=0
##add_to_page_cache_locked END in_atomic=0
##add_to_page_cache_locked BEGIN in_atomic=0
##add_to_page_cache_locked END in_atomic=0
##add_to_page_cache_locked BEGIN in_atomic=0
##add_to_page_cache_locked END in_atomic=1
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper
1 lock held by swapper/1:
#0: (>cred_guard_mutex){..}, at: [<00073fac>]
prepare_bprm_creds+0x30/0x6c
CPU: 0 PID: 1 Comm: swapper Not tainted 3.13.0-rc2-00203-g34074bc-dirty #2022
Backtrace:
[] (dump_backtrace+0x0/0x108) from [] (show_stack+0x18/0x1c)
r6: r5:0147abb8 r4:01c34000 r3:00200140
[] (show_stack+0x0/0x1c) from [<002ca948>] (dump_stack+0x20/0x28)
[<002ca928>] (dump_stack+0x0/0x28) from [<0002e3b8>] (__might_sleep+0xfc/0x11c)
[<0002e2bc>] (__might_sleep+0x0/0x11c) from [<002ce0a8>]
(mutex_lock_nested+0x2c/0x30c)
r4:0147abb8
[<002ce07c>] (mutex_lock_nested+0x0/0x30c) from [<000c4e9c>]
(jffs2_readpage+0x50/0x78)
r8:0081a654 r7:0002 r6:01c34000 r5:0147abb8 r4:0081a640
[<000c4e4c>] (jffs2_readpage+0x0/0x78) from [<0005d854>]
(__do_page_cache_readahead+0x2a0/0x338)
r5:0004 r4:0147ad2c
[<0005d5b4>] (__do_page_cache_readahead+0x0/0x338) from [<0005db94>]
(ra_submit+0x5c/0x68)
[<0005db38>] (ra_submit+0x0/0x68) from [<0005de8c>]
(ondemand_readahead+0x2ec/0x314)
r6: r5:0020 r4:01c0fcc8
[<0005dba0>] (ondemand_readahead+0x0/0x314) from [<0005dff8>]
(page_cache_sync_readahead+0x9c/0xa8)
[<0005df5c>] (page_cache_sync_readahead+0x0/0xa8) from [<000561ec>]
(generic_file_aio_read+0x314/0x7b0)
r8:01c35eb0 r7:01c0fc40 r6:0147ad2c r5: r4:0001
[<00055ed8>] (generic_file_aio_read+0x0/0x7b0) from [<0006e7ec>]
(do_sync_read+0x88/0xd0)
[<0006e764>] (do_sync_read+0x0/0xd0) from [<0006f0e0>] (vfs_read+0xac/0xf4)
r7:0080 r6:01e5a400 r5:01c35ef8 r4:01c0fc40
[<0006f034>] (vfs_read+0x0/0xf4) from [<00073acc>] (kernel_read+0x24/0x2c)
r7:89ed r6:0147ac20 r5:01c34000 r4:01e5a400
r7:89ed r6:0147ac20 r5:01c34000 r4:01e5a400
[<00073aa8>] (kernel_read+0x0/0x2c) from [<00073bf8>]
(prepare_binprm+0x124/0x134)
[<00073ad4>] (prepare_binprm+0x0/0x134) from [<000742c4>]
(do_execve+0x250/0x528)
r7:003599eb r6:01c34000 r5: r4:01e5a400
[<00074074>] (do_execve+0x0/0x528) from [<83e4>]
(try_to_run_init_process+0x20/0x4c)
[<83c4>] (try_to_run_init_process+0x0/0x4c) from [<002c74f0>]
(kernel_init+0x98/0x104)
r5:002c7458 r4:003e8300
[<002c7458>] (kernel_init+0x0/0x104) from [<9070>] (ret_from_fork+0x14/0x24)
r4: r3:
於 日，2013-12-01 於 18:53 +0800，Axel Lin 提到：
> Hi,
> I got below messages while booting.
> Testing on a nommu platform with 3.13.0-rc2 + patches for this SoC.
>
> VFS: Mounted root (jffs2 filesystem) on device 31:1.
> devtmpfs: mounted
> Freeing unused kernel memory: 92K (003a4000 - 003bb000)
> BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:616
> in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper
> 1 lock held by swapper/1:
> #0: (>cred_guard_mutex){..}, at: [<0006ea10>]
>
[PATCH v10] x86, apic, kexec, Documentation: Add disable_cpu_apic kernel parameter
This patch set is to allow kdump 2nd kernel to wake up multiple CPUs, a continueing work from: [PATCH v3 0/2] x86, apic, kdump: Disable BSP if boot cpu is AP https://lkml.org/lkml/2013/10/16/300. At v4, basic design has changed. Now users need to figure out initial APIC ID of BSP in the 1st kernel and configures kernel parameter for the 2nd kernel manually using disable_cpu_apicid kernel parameter, which is newly introduced by this patch set. This design is more flexible than the previous version in that we no longer have to rely on ACPI/MP table to get initial APIC ID of BSP. Sorry, this patch set have not include in-source documentation requested by Borislav Petkov yet, but I'll post it later separately, which would be better to focus on documentation reviewing. ChangeLog v9 => v10) - Remove KEXEC tag from the description of disable_cpu_apicid since the parameter is generic, independent of CONFIG_KEXEC, at least in this version. v8 => v9) - Rebased on top of v3.13-rc2 - Call read_apic_id() in case of disable_cpu_apiid only in generic_processor_info(). v7 => v8) - Merge the patch that adds new descption in Documentations/kernel-parameters.txt in the first patch. - Call read_apic_id() directly in generic_processor_info() instead of overriding global boot_cpu_physical_apicid with the local variable with the same name. v6 => v7) - Rebased on top of v3.13-rc1 - Remove a patch that cleans up the code around x86_cpu_physical_apicid. Instead, use read_apic_id() directly in generic_processor_info(). The clean up removed here will be done in different patch set. v5 => v6) - Remove use of rdmsr(IA32_APIC_BASE) to initialize bsp_physical_apicid since the MSR doesn't work well on some cluster systems, suggested by HPA. Also, current users of the variable expects the initial apicid reported through MP table only; removing the use of the MSR is not problematic. - Rename bsp_physical_apicid as bios_bsp_physical_apicid to make it clear that the apidid contained there is the one reported from some BIOS table. Also, initialize it not only by MP table but also by ACPI MADT. - Change message displayed when specified cpu is disabled from: ACPI: Disable specified CPU. Processor 0/0x0 ignored. to: ACPI: Disabling requested cpu. Processor 0/0x0 ignored. v4 => v5) - Rebased on top of v3.12 - Introduce bsp_physical_apicid that has the initial APIC ID for the processor with BSP flag on IA32_APIC_BASE MSR. Without this, boot_cpu_physical_apicid has temporarilly the value around MP table related codes, although it's designed to have the initial APIC ID for the processor that is doing the boot up. Use the bsp_physical_apicid in MP table related codes; no impact on semantics at runtime there. v3 => v4) - Rebased on top of v3.12-rc6 - Basic design has been changed. Now users need to figure out initial APIC ID of BSP in the 1st kernel and configures kernel parameter for the 2nd kernel manually using disable_cpu_apic kernel parameter to be newly introduced in this patch set. This design is more flexible than the previous version in that we no longer have to rely on ACPI/MP table to get initial APIC ID of BSP. v2 => v3) - Change default value of boot_cpu_is_bsp to true. - Before executing rdmsr(MSR_IA32_APICBASE), check if the number of processor family is larger than or equal to 6 in order to avoid invalid opcode exception on processors where MSR_IA32_APICBASE is not supported. v1 => v2) - Rebased on top of v3.12-rc5. - Fix linking time error of boot_cpu_is_bsp_init() in case of CONFIG_LOCAL_APIC disabled by adding empty static inline function instead. - Fix missing feature check by means of cpu_has_apic macro in boot_cpu_is_bsp_init() before calling rdmsr_safe(MSR_IA32_APICBASE). NOTE: I've checked local apic-present case only; I don't have any x86 processor without local apic. - Add __init annotation to boot_cpu_is_bsp_init(). Test - built with and without CONFIG_LOCAL_APIC - tested x86_64 in case of acpi and MP table - tested disable_cpu_apicid= to disable both AP and BSP >From d03e159d9479755b36ac7d4a7d323b3ce95481be Mon Sep 17 00:00:00 2001 From: HATAYAMA Daisuke Date: Tue, 3 Dec 2013 09:21:56 +0900 Subject: [PATCH] x86, apic, kexec, Documentation: Add disable_cpu_apicid kernel parameter Add disable_cpu_apicid kernel parameter. To use this kernel parameter, specify an initial APIC ID of the corresponding CPU you want to disable. This is mostly used for the kdump 2nd kernel to disable BSP to wake up multiple CPUs without causing system reset or hang due to sending INIT from AP to BSP. Kdump users first figure out initial APIC ID of the BSP, CPU0 in the 1st kernel, for example from /proc/cpuinfo and then set up this kernel parameter for the 2nd kernel using the obtained APIC ID. However, doing this procedure at each boot time manually is awkward, which should be automatically done by user-land service scripts,
RE: [f2fs-dev] [PATCH v2] f2fs: refactor bio-related operations
Hi,
> > + if (btype == META)
> > + rw |= REQ_META;
> > +
> > + if (is_read_io(rw)) {
> > + if (sync)
> > + rw |= READ_SYNC;
> > + submit_bio(rw, io->bio);
> > + trace_f2fs_submit_read_bio(sbi->sb, rw, type, io->bio);
> > + io->bio = NULL;
> > + return;
> > + }
> > +
> > + if (sync)
> > + rw |= WRITE_SYNC;
>
> rw = WRITE_SYNC; ?
No, since it removes the REQ_META.
See above.
>
> > + if (type >= META_FLUSH)
> > + rw |= WRITE_FLUSH_FUA;
>
> rw = WRITE_FLUSH_FUA; ?
>
> > +
> > + /*
> > +* META_FLUSH is only from the checkpoint procedure, and we should wait
> > +* this metadata bio for FS consistency.
> > +*/
> > + if (type == META_FLUSH) {
> > + DECLARE_COMPLETION_ONSTACK(wait);
> > + io->bio->bi_private =
> > + submit_bio(rw, io->bio);
> > + wait_for_completion();
> > + } else {
> > + submit_bio(rw, io->bio);
> > + }
> > + trace_f2fs_submit_write_bio(sbi->sb, rw, btype, io->bio);
> > + io->bio = NULL;
> > +}
>
> [snip]
>
> Thanks,
> Yu
>
--
Jaegeuk Kim
Samsung
--
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 v4 1/3] mfd: tps6586x: add version detection
> +int tps6586x_get_version(struct device *dev)
> +{
> + struct tps6586x *tps6586x = dev_get_drvdata(dev);
> +
> + return tps6586x->version;
> +}
> +EXPORT_SYMBOL_GPL(tps6586x_get_version);
I thought Mark suggested that this routine was converted to a 'static
inline' and moved into the header? Did you not think this was a good
idea?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] ARM: OMAP2+: omap_device: add fail hook for runtime_pm when bad data is detected
On 12/04/2013 07:09 AM, Nishanth Menon wrote: > Due to the cross dependencies between hwmod for automanaged device > information for OMAP and dts node definitions, we can run into scenarios > where the dts node is defined, however it's hwmod entry is yet to be > added. In these cases: > a) omap_device does not register a pm_domain (since it cannot find >hwmod entry). > b) driver does not know about (a), does a pm_runtime_get_sync which >never fails > c) It then tries to do some operation on the device (such as read the > revision register (as part of probe) without clock or adequate OMAP > generic PM operation performed for enabling the module. > > This causes a crash such as that reported in: > https://bugzilla.kernel.org/show_bug.cgi?id=66441 > > When 'ti,hwmod' is provided in dt node, it is expected that the device > will not function without the OMAP's power automanagement. Hence, when > we hit a fail condition (due to hwmod entries not present or other > similar scenario), fail at pm_domain level due to lack of data, provide > enough information for it to be fixed, however, it allows for the driver > to take appropriate measures to prevent crash. > > Reported-by: Tobias Jakobi > Signed-off-by: Nishanth Menon > --- > arch/arm/mach-omap2/omap_device.c | 24 > arch/arm/mach-omap2/omap_device.h |1 + > 2 files changed, 25 insertions(+) > > diff --git a/arch/arm/mach-omap2/omap_device.c > b/arch/arm/mach-omap2/omap_device.c > index 53f0735..e0a398c 100644 > --- a/arch/arm/mach-omap2/omap_device.c > +++ b/arch/arm/mach-omap2/omap_device.c > @@ -183,6 +183,10 @@ static int omap_device_build_from_dt(struct > platform_device *pdev) > odbfd_exit1: > kfree(hwmods); > odbfd_exit: > + /* if data/we are at fault.. load up a fail handler */ > + if (ret) > + pdev->dev.pm_domain = _device_fail_pm_domain; > + > return ret; > } > Just wondering, can't we just print the warning here instead of registering new pm_domain callbacks? Concerned that all this LOC may end up being dead code when the "ti,hwmods" property becomes obsolete anyway. -Joel -- 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 v4 0/4] LP3943 MFD driver for a GPIO expander and a PWM generator
> Could you check this patchset? > Driver documentation was moved from 'Documentation' to > 'drivers/mfd/lp3943.c'. Well because the reset of the patch-set wasn't sent as replies to [PATCH 0/X], it's now lost in the ulu. You will have to resubmit. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: mac80211: tx.c: be sure of 'sdata->vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
On Wed, 2013-12-04 at 10:12 +0800, Chen Gang wrote: > It is really not urgent, and for keeping quality, it is necessary to > spend suitable time resource (e.g 1 hour or more) to make, review and > test this kind of patch carefully by oneself. > > So could you please help improve it when you have suitable related time > resources? No. Who are you to suggest what I need to work on? johannes -- 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/2] arm: mmp: build sram driver alone
On 12/04/2013 03:56 PM, Dan Williams wrote: On Tue, Dec 3, 2013 at 11:05 PM, Qiao Zhou wrote: sram driver can be used by many chips besides CPU_MMP2, and so build it alone. Reported-by: Dan Williams Signed-off-by: Qiao Zhou --- arch/arm/mach-mmp/Kconfig |5 + arch/arm/mach-mmp/Makefile |3 ++- 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-mmp/Kconfig b/arch/arm/mach-mmp/Kconfig index ebdda83..6a6597c 100644 --- a/arch/arm/mach-mmp/Kconfig +++ b/arch/arm/mach-mmp/Kconfig @@ -136,4 +136,9 @@ config USB_EHCI_MV_U2O help Enables support for OTG controller which can be switched to host mode. +config MMP_SRAM + bool + help + Select code specific to sram. + No need for help text for something that is selected, and might as well squash this with patch 2. Dan, thanks. I'll update it. -- Best Regards Qiao -- 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/2] arm: mmp: build sram driver alone
On 12/04/2013 03:56 PM, Dan Williams wrote: On Tue, Dec 3, 2013 at 11:05 PM, Qiao Zhou zhouq...@marvell.com wrote: sram driver can be used by many chips besides CPU_MMP2, and so build it alone. Reported-by: Dan Williams dan.j.willi...@intel.com Signed-off-by: Qiao Zhou zhouq...@marvell.com --- arch/arm/mach-mmp/Kconfig |5 + arch/arm/mach-mmp/Makefile |3 ++- 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-mmp/Kconfig b/arch/arm/mach-mmp/Kconfig index ebdda83..6a6597c 100644 --- a/arch/arm/mach-mmp/Kconfig +++ b/arch/arm/mach-mmp/Kconfig @@ -136,4 +136,9 @@ config USB_EHCI_MV_U2O help Enables support for OTG controller which can be switched to host mode. +config MMP_SRAM + bool + help + Select code specific to sram. + No need for help text for something that is selected, and might as well squash this with patch 2. Dan, thanks. I'll update it. -- Best Regards Qiao -- 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: mac80211: tx.c: be sure of 'sdata-vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
On Wed, 2013-12-04 at 10:12 +0800, Chen Gang wrote: It is really not urgent, and for keeping quality, it is necessary to spend suitable time resource (e.g 1 hour or more) to make, review and test this kind of patch carefully by oneself. So could you please help improve it when you have suitable related time resources? No. Who are you to suggest what I need to work on? johannes -- 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 v4 0/4] LP3943 MFD driver for a GPIO expander and a PWM generator
Could you check this patchset? Driver documentation was moved from 'Documentation' to 'drivers/mfd/lp3943.c'. Well because the reset of the patch-set wasn't sent as replies to [PATCH 0/X], it's now lost in the ulu. You will have to resubmit. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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] ARM: OMAP2+: omap_device: add fail hook for runtime_pm when bad data is detected
On 12/04/2013 07:09 AM, Nishanth Menon wrote: Due to the cross dependencies between hwmod for automanaged device information for OMAP and dts node definitions, we can run into scenarios where the dts node is defined, however it's hwmod entry is yet to be added. In these cases: a) omap_device does not register a pm_domain (since it cannot find hwmod entry). b) driver does not know about (a), does a pm_runtime_get_sync which never fails c) It then tries to do some operation on the device (such as read the revision register (as part of probe) without clock or adequate OMAP generic PM operation performed for enabling the module. This causes a crash such as that reported in: https://bugzilla.kernel.org/show_bug.cgi?id=66441 When 'ti,hwmod' is provided in dt node, it is expected that the device will not function without the OMAP's power automanagement. Hence, when we hit a fail condition (due to hwmod entries not present or other similar scenario), fail at pm_domain level due to lack of data, provide enough information for it to be fixed, however, it allows for the driver to take appropriate measures to prevent crash. Reported-by: Tobias Jakobi tjak...@math.uni-bielefeld.de Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/omap_device.c | 24 arch/arm/mach-omap2/omap_device.h |1 + 2 files changed, 25 insertions(+) diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c index 53f0735..e0a398c 100644 --- a/arch/arm/mach-omap2/omap_device.c +++ b/arch/arm/mach-omap2/omap_device.c @@ -183,6 +183,10 @@ static int omap_device_build_from_dt(struct platform_device *pdev) odbfd_exit1: kfree(hwmods); odbfd_exit: + /* if data/we are at fault.. load up a fail handler */ + if (ret) + pdev-dev.pm_domain = omap_device_fail_pm_domain; + return ret; } Just wondering, can't we just print the warning here instead of registering new pm_domain callbacks? Concerned that all this LOC may end up being dead code when the ti,hwmods property becomes obsolete anyway. -Joel -- 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 v4 1/3] mfd: tps6586x: add version detection
+int tps6586x_get_version(struct device *dev)
+{
+ struct tps6586x *tps6586x = dev_get_drvdata(dev);
+
+ return tps6586x-version;
+}
+EXPORT_SYMBOL_GPL(tps6586x_get_version);
I thought Mark suggested that this routine was converted to a 'static
inline' and moved into the header? Did you not think this was a good
idea?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v10] x86, apic, kexec, Documentation: Add disable_cpu_apic kernel parameter
This patch set is to allow kdump 2nd kernel to wake up multiple CPUs, a continueing work from: [PATCH v3 0/2] x86, apic, kdump: Disable BSP if boot cpu is AP https://lkml.org/lkml/2013/10/16/300. At v4, basic design has changed. Now users need to figure out initial APIC ID of BSP in the 1st kernel and configures kernel parameter for the 2nd kernel manually using disable_cpu_apicid kernel parameter, which is newly introduced by this patch set. This design is more flexible than the previous version in that we no longer have to rely on ACPI/MP table to get initial APIC ID of BSP. Sorry, this patch set have not include in-source documentation requested by Borislav Petkov yet, but I'll post it later separately, which would be better to focus on documentation reviewing. ChangeLog v9 = v10) - Remove KEXEC tag from the description of disable_cpu_apicid since the parameter is generic, independent of CONFIG_KEXEC, at least in this version. v8 = v9) - Rebased on top of v3.13-rc2 - Call read_apic_id() in case of disable_cpu_apiid only in generic_processor_info(). v7 = v8) - Merge the patch that adds new descption in Documentations/kernel-parameters.txt in the first patch. - Call read_apic_id() directly in generic_processor_info() instead of overriding global boot_cpu_physical_apicid with the local variable with the same name. v6 = v7) - Rebased on top of v3.13-rc1 - Remove a patch that cleans up the code around x86_cpu_physical_apicid. Instead, use read_apic_id() directly in generic_processor_info(). The clean up removed here will be done in different patch set. v5 = v6) - Remove use of rdmsr(IA32_APIC_BASE) to initialize bsp_physical_apicid since the MSR doesn't work well on some cluster systems, suggested by HPA. Also, current users of the variable expects the initial apicid reported through MP table only; removing the use of the MSR is not problematic. - Rename bsp_physical_apicid as bios_bsp_physical_apicid to make it clear that the apidid contained there is the one reported from some BIOS table. Also, initialize it not only by MP table but also by ACPI MADT. - Change message displayed when specified cpu is disabled from: ACPI: Disable specified CPU. Processor 0/0x0 ignored. to: ACPI: Disabling requested cpu. Processor 0/0x0 ignored. v4 = v5) - Rebased on top of v3.12 - Introduce bsp_physical_apicid that has the initial APIC ID for the processor with BSP flag on IA32_APIC_BASE MSR. Without this, boot_cpu_physical_apicid has temporarilly the value around MP table related codes, although it's designed to have the initial APIC ID for the processor that is doing the boot up. Use the bsp_physical_apicid in MP table related codes; no impact on semantics at runtime there. v3 = v4) - Rebased on top of v3.12-rc6 - Basic design has been changed. Now users need to figure out initial APIC ID of BSP in the 1st kernel and configures kernel parameter for the 2nd kernel manually using disable_cpu_apic kernel parameter to be newly introduced in this patch set. This design is more flexible than the previous version in that we no longer have to rely on ACPI/MP table to get initial APIC ID of BSP. v2 = v3) - Change default value of boot_cpu_is_bsp to true. - Before executing rdmsr(MSR_IA32_APICBASE), check if the number of processor family is larger than or equal to 6 in order to avoid invalid opcode exception on processors where MSR_IA32_APICBASE is not supported. v1 = v2) - Rebased on top of v3.12-rc5. - Fix linking time error of boot_cpu_is_bsp_init() in case of CONFIG_LOCAL_APIC disabled by adding empty static inline function instead. - Fix missing feature check by means of cpu_has_apic macro in boot_cpu_is_bsp_init() before calling rdmsr_safe(MSR_IA32_APICBASE). NOTE: I've checked local apic-present case only; I don't have any x86 processor without local apic. - Add __init annotation to boot_cpu_is_bsp_init(). Test - built with and without CONFIG_LOCAL_APIC - tested x86_64 in case of acpi and MP table - tested disable_cpu_apicid=n to disable both AP and BSP From d03e159d9479755b36ac7d4a7d323b3ce95481be Mon Sep 17 00:00:00 2001 From: HATAYAMA Daisuke d.hatay...@jp.fujitsu.com Date: Tue, 3 Dec 2013 09:21:56 +0900 Subject: [PATCH] x86, apic, kexec, Documentation: Add disable_cpu_apicid kernel parameter Add disable_cpu_apicid kernel parameter. To use this kernel parameter, specify an initial APIC ID of the corresponding CPU you want to disable. This is mostly used for the kdump 2nd kernel to disable BSP to wake up multiple CPUs without causing system reset or hang due to sending INIT from AP to BSP. Kdump users first figure out initial APIC ID of the BSP, CPU0 in the 1st kernel, for example from /proc/cpuinfo and then set up this kernel parameter for the 2nd kernel using the obtained APIC ID. However, doing this procedure at each boot time manually is awkward, which should be automatically done by user-land
RE: [f2fs-dev] [PATCH v2] f2fs: refactor bio-related operations
Hi,
+ if (btype == META)
+ rw |= REQ_META;
+
+ if (is_read_io(rw)) {
+ if (sync)
+ rw |= READ_SYNC;
+ submit_bio(rw, io-bio);
+ trace_f2fs_submit_read_bio(sbi-sb, rw, type, io-bio);
+ io-bio = NULL;
+ return;
+ }
+
+ if (sync)
+ rw |= WRITE_SYNC;
rw = WRITE_SYNC; ?
No, since it removes the REQ_META.
See above.
+ if (type = META_FLUSH)
+ rw |= WRITE_FLUSH_FUA;
rw = WRITE_FLUSH_FUA; ?
+
+ /*
+* META_FLUSH is only from the checkpoint procedure, and we should wait
+* this metadata bio for FS consistency.
+*/
+ if (type == META_FLUSH) {
+ DECLARE_COMPLETION_ONSTACK(wait);
+ io-bio-bi_private = wait;
+ submit_bio(rw, io-bio);
+ wait_for_completion(wait);
+ } else {
+ submit_bio(rw, io-bio);
+ }
+ trace_f2fs_submit_write_bio(sbi-sb, rw, btype, io-bio);
+ io-bio = NULL;
+}
[snip]
Thanks,
Yu
--
Jaegeuk Kim
Samsung
--
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: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
I can constantly hit this issue:
I trace it to mm/filemap.c: add_to_page_cache_locked
I print the in_atomic status at BEGIN and END of add_to_page_cache_locked call.
Then I got in_atomic is true at the end of add_to_page_cache_locked call.
int add_to_page_cache_locked(struct page *page, struct address_space *mapping,
pgoff_t offset, gfp_t gfp_mask)
{
int error;
VM_BUG_ON(!PageLocked(page));
VM_BUG_ON(PageSwapBacked(page));
pr_info( ##add_to_page_cache_locked BEGIN in_atomic=%d\n, in_atomic());
error = mem_cgroup_cache_charge(page, current-mm,
gfp_mask GFP_RECLAIM_MASK);
if (error)
return error;
error = radix_tree_maybe_preload(gfp_mask ~__GFP_HIGHMEM);
if (error) {
mem_cgroup_uncharge_cache_page(page);
return error;
}
page_cache_get(page);
page-mapping = mapping;
page-index = offset;
spin_lock_irq(mapping-tree_lock);
error = radix_tree_insert(mapping-page_tree, offset, page);
radix_tree_preload_end();
if (unlikely(error))
goto err_insert;
mapping-nrpages++;
__inc_zone_page_state(page, NR_FILE_PAGES);
spin_unlock_irq(mapping-tree_lock);
trace_mm_filemap_add_to_page_cache(page);
pr_info( ##add_to_page_cache_locked END in_atomic=%d\n, in_atomic());
return 0;
err_insert:
page-mapping = NULL;
/* Leave page-index set: truncation relies upon it */
spin_unlock_irq(mapping-tree_lock);
mem_cgroup_uncharge_cache_page(page);
page_cache_release(page);
pr_info( ##add_to_page_cache_locked ERR in_atomic=%d\n, in_atomic());
return error;
}
Then I got below messages:
##add_to_page_cache_locked BEGIN in_atomic=0
##add_to_page_cache_locked END in_atomic=0
##add_to_page_cache_locked BEGIN in_atomic=0
##add_to_page_cache_locked END in_atomic=0
##add_to_page_cache_locked BEGIN in_atomic=0
##add_to_page_cache_locked END in_atomic=1
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper
1 lock held by swapper/1:
#0: (sig-cred_guard_mutex){..}, at: [00073fac]
prepare_bprm_creds+0x30/0x6c
CPU: 0 PID: 1 Comm: swapper Not tainted 3.13.0-rc2-00203-g34074bc-dirty #2022
Backtrace:
[b204] (dump_backtrace+0x0/0x108) from [b398] (show_stack+0x18/0x1c)
r6: r5:0147abb8 r4:01c34000 r3:00200140
[b380] (show_stack+0x0/0x1c) from [002ca948] (dump_stack+0x20/0x28)
[002ca928] (dump_stack+0x0/0x28) from [0002e3b8] (__might_sleep+0xfc/0x11c)
[0002e2bc] (__might_sleep+0x0/0x11c) from [002ce0a8]
(mutex_lock_nested+0x2c/0x30c)
r4:0147abb8
[002ce07c] (mutex_lock_nested+0x0/0x30c) from [000c4e9c]
(jffs2_readpage+0x50/0x78)
r8:0081a654 r7:0002 r6:01c34000 r5:0147abb8 r4:0081a640
[000c4e4c] (jffs2_readpage+0x0/0x78) from [0005d854]
(__do_page_cache_readahead+0x2a0/0x338)
r5:0004 r4:0147ad2c
[0005d5b4] (__do_page_cache_readahead+0x0/0x338) from [0005db94]
(ra_submit+0x5c/0x68)
[0005db38] (ra_submit+0x0/0x68) from [0005de8c]
(ondemand_readahead+0x2ec/0x314)
r6: r5:0020 r4:01c0fcc8
[0005dba0] (ondemand_readahead+0x0/0x314) from [0005dff8]
(page_cache_sync_readahead+0x9c/0xa8)
[0005df5c] (page_cache_sync_readahead+0x0/0xa8) from [000561ec]
(generic_file_aio_read+0x314/0x7b0)
r8:01c35eb0 r7:01c0fc40 r6:0147ad2c r5: r4:0001
[00055ed8] (generic_file_aio_read+0x0/0x7b0) from [0006e7ec]
(do_sync_read+0x88/0xd0)
[0006e764] (do_sync_read+0x0/0xd0) from [0006f0e0] (vfs_read+0xac/0xf4)
r7:0080 r6:01e5a400 r5:01c35ef8 r4:01c0fc40
[0006f034] (vfs_read+0x0/0xf4) from [00073acc] (kernel_read+0x24/0x2c)
r7:89ed r6:0147ac20 r5:01c34000 r4:01e5a400
r7:89ed r6:0147ac20 r5:01c34000 r4:01e5a400
[00073aa8] (kernel_read+0x0/0x2c) from [00073bf8]
(prepare_binprm+0x124/0x134)
[00073ad4] (prepare_binprm+0x0/0x134) from [000742c4]
(do_execve+0x250/0x528)
r7:003599eb r6:01c34000 r5: r4:01e5a400
[00074074] (do_execve+0x0/0x528) from [83e4]
(try_to_run_init_process+0x20/0x4c)
[83c4] (try_to_run_init_process+0x0/0x4c) from [002c74f0]
(kernel_init+0x98/0x104)
r5:002c7458 r4:003e8300
[002c7458] (kernel_init+0x0/0x104) from [9070] (ret_from_fork+0x14/0x24)
r4: r3:
於 日，2013-12-01 於 18:53 +0800，Axel Lin 提到：
Hi,
I got below messages while booting.
Testing on a nommu platform with 3.13.0-rc2 + patches for this SoC.
VFS: Mounted root (jffs2 filesystem) on device 31:1.
devtmpfs: mounted
Freeing unused kernel memory: 92K (003a4000 - 003bb000)
BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:616
in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper
1 lock held by swapper/1:
#0: (sig-cred_guard_mutex){..}, at: [0006ea10]
prepare_bprm_creds+0x30/0x6c
CPU: 0 PID: 1 Comm: swapper Not tainted
Re: [PATCH] mfd: wm831x: Use PM ops for shutdown
On Fri, 08 Nov 2013, Mark Brown wrote: From: Mark Brown broo...@linaro.org This helps move us towards removing the bus custom operations. Signed-off-by: Mark Brown broo...@linaro.org --- drivers/mfd/wm831x-i2c.c | 8 +--- drivers/mfd/wm831x-spi.c | 8 +--- 2 files changed, 10 insertions(+), 6 deletions(-) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: [Intel-gfx] [PATCH 1/3] ACPI/i915: Fix wrong acpi/acpi.h inclusion in i915 opregion module.
On Wed, Dec 04, 2013 at 08:38:08AM +0800, Lv Zheng wrote: In Linux kernel, ACPICA is wrapped and safely exported by CONFIG_ACPI. So all external modules should depend on CONFIG_ACPI rather than using ACPICA header directly for stubbing. But if we moves acpi/acpi.h inclusions into #ifdef CONFIG_ACPI, build breakge can help to detect wrong ACPICA dependent modules. One of the build breakage is: include/linux/acpi_io.h:7:45: error: unknown type name 'acpi_physical_address' include/linux/acpi_io.h:8:10: error: unknown type name 'acpi_size' include/linux/acpi_io.h:13:33: error: unknown type name 'acpi_physical_address' include/linux/acpi_io.h:15:40: warning: 'struct acpi_generic_address' declared inside parameter list [enabled by default] include/linux/acpi_io.h:15:40: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] include/linux/acpi_io.h:16:43: warning: 'struct acpi_generic_address' declared inside parameter list [enabled by default] drivers/gpu/drm/i915/intel_opregion.c: In function 'intel_opregion_setup': drivers/gpu/drm/i915/intel_opregion.c:883:2: error: implicit declaration of function 'acpi_os_ioremap' [-Werror=implicit-function-declaration] drivers/gpu/drm/i915/intel_opregion.c:883:7: warning: assignment makes pointer from integer without a cast [enabled by default] The root causes of this breakage are: 1. The linux/acpi_io.h depends on CONFIG_ACPI=y as most of the prototypes exported by it are implemented in drivers/acpi/osl.c. 2. CONFIG_DRM_I915 uses the only inline function acpi_os_ioremap() to implement stubs but it shouldn't. Since ACPI IGD OpRegion is an ACPI-based mechanism, (please refer to the Doclink below), this patch fixes this issue by making drivers/gpu/drm/i915/intel_opregion.c dependent on CONFIG_ACPI. This is identical to other Intel DRM drivers' OpRegion support (e.x., drivers/gpu/drm/gma500/opregion.c). Since acpi_io.h is not safe for CONFIG_ACPI=y environment, this patch also moves it to include/acpi, includes it in linux/acpi.h for CONFIG_ACPI=y build environment and cleans up its inclusions by converting them into linux/acpi.h inclusions. Doclink: https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf Cc: Matthew Garrett mj...@srcf.ucam.org Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: intel-...@lists.freedesktop.org Signed-off-by: Lv Zheng lv.zh...@intel.com Makes sense. Acked for merging through acpi trees (or whatever else is appropriate, patch seems to be part of a series). Cheers, Daniel --- drivers/acpi/apei/apei-base.c |1 - drivers/acpi/apei/apei-internal.h |1 - drivers/acpi/apei/ghes.c |1 - drivers/acpi/nvs.c|1 - drivers/acpi/osl.c|1 - drivers/gpu/drm/gma500/opregion.c |1 - drivers/gpu/drm/i915/Makefile |3 +-- drivers/gpu/drm/i915/i915_drv.h |3 ++- include/acpi/acpi_io.h| 17 + include/linux/acpi.h |1 + include/linux/acpi_io.h | 18 -- 11 files changed, 21 insertions(+), 27 deletions(-) create mode 100644 include/acpi/acpi_io.h delete mode 100644 include/linux/acpi_io.h diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c index 6d2c49b..0760b75 100644 --- a/drivers/acpi/apei/apei-base.c +++ b/drivers/acpi/apei/apei-base.c @@ -34,7 +34,6 @@ #include linux/module.h #include linux/init.h #include linux/acpi.h -#include linux/acpi_io.h #include linux/slab.h #include linux/io.h #include linux/kref.h diff --git a/drivers/acpi/apei/apei-internal.h b/drivers/acpi/apei/apei-internal.h index 21ba34a..e5bcd91 100644 --- a/drivers/acpi/apei/apei-internal.h +++ b/drivers/acpi/apei/apei-internal.h @@ -8,7 +8,6 @@ #include linux/cper.h #include linux/acpi.h -#include linux/acpi_io.h struct apei_exec_context; diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index a30bc31..694c486 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -33,7 +33,6 @@ #include linux/module.h #include linux/init.h #include linux/acpi.h -#include linux/acpi_io.h #include linux/io.h #include linux/interrupt.h #include linux/timer.h diff --git a/drivers/acpi/nvs.c b/drivers/acpi/nvs.c index 386a9fe..ef28613 100644 --- a/drivers/acpi/nvs.c +++ b/drivers/acpi/nvs.c @@ -12,7 +12,6 @@ #include linux/mm.h #include linux/slab.h #include linux/acpi.h -#include linux/acpi_io.h /* ACPI NVS regions, APEI may use it */ diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index 7e2d814..63251b6 100644 --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -39,7 +39,6 @@ #include linux/workqueue.h #include linux/nmi.h #include linux/acpi.h -#include linux/acpi_io.h #include linux/efi.h #include linux/ioport.h #include
Re: [PATCH] mac80211: rx: Neaten ieee80211_deliver_skb, remove compare_ether_addr
On Tue, 2013-12-03 at 10:29 -0800, Joe Perches wrote:
Remove the unnecessary duplicate test of if (skb) {
when !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS.
Remove now unnecessary __maybe_unused, neaten comment
Remove unnecessary parenthesis around align cast.
Substitute reference to deprecated compare_ether_addr
with ether_addr_equal.
I already had a patch to remove the __maybe_unused, but this looks good,
applied.
johannes
--
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 4/6] kexec: A new system call, kexec_file_load, for in kernel kexec
On 12/04/13 at 09:56am, Baoquan He wrote:
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
+ * that kexec_mutex is held.
+ */
I think kexec_add_buffer is guaranteed to be called before allocating
control pages, why not updating image-control_page after each time
kexec_add_buffer is called. Then when control page is needed, effective
address in crash_kernel region can be given. This can be a little more
efficient.
Check again, it's not a good idea. Because buf_align is different when
kexec_add_buffer is called. Sometime the bug_align is larger than 4k.
Please ignore this comment.
+int kexec_add_buffer(struct kimage *image, char *buffer,
+ unsigned long bufsz, unsigned long memsz,
+ unsigned long buf_align, unsigned long buf_min,
+ unsigned long buf_max, int top_down, unsigned long *load_addr)
+{
+
+ unsigned long nr_segments = image-nr_segments, new_nr_segments;
+ struct kexec_segment *ksegment;
+ struct kexec_buf *kbuf;
+
+ /* Currently adding segment this way is allowed only in file mode */
+ if (!image-file_mode)
+ return -EINVAL;
+
+ if (nr_segments = KEXEC_SEGMENT_MAX)
+ return -EINVAL;
+
+ /*
+* Make sure we are not trying to add buffer after allocating
+* control pages. All segments need to be placed first before
+* any control pages are allocated. As control page allocation
+* logic goes through list of segments to make sure there are
+* no destination overlaps.
+*/
+ WARN_ONCE(!list_empty(image-control_pages), Adding kexec buffer
+after allocating control pages\n);
+
+ kbuf = kzalloc(sizeof(struct kexec_buf), GFP_KERNEL);
+ if (!kbuf)
+ return -ENOMEM;
+
--
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 1/2] ARM: tegra: Add header file for pinctrl constants
On Tue, Dec 03, 2013 at 06:46:06PM +0530, Laxman Dewangan wrote: This new header file defines pincontrol constants for Tegra to use from Tegra's DTS file for pincontrol properties option. Signed-off-by: Laxman Dewangan ldewan...@nvidia.com --- Changes from V1: - Get rid of lots of macro and converge it to TEGRA_PIN_ENABLE/DISABLE. - Change macro name for PULL UP/DOWN/NONE. include/dt-bindings/pinctrl/pinctrl-tegra.h | 40 +++ 1 files changed, 40 insertions(+), 0 deletions(-) create mode 100644 include/dt-bindings/pinctrl/pinctrl-tegra.h I like this a lot. One minor nit below. diff --git a/include/dt-bindings/pinctrl/pinctrl-tegra.h b/include/dt-bindings/pinctrl/pinctrl-tegra.h new file mode 100644 index 000..e5f02f8 --- /dev/null +++ b/include/dt-bindings/pinctrl/pinctrl-tegra.h @@ -0,0 +1,40 @@ +/* + * This header provides constants for TEGRA pinctrl bindings. TEGRA - Tegra Other than that: Reviewed-by: Thierry Reding tred...@nvidia.com pgpWcJUCR01O2.pgp Description: PGP signature
[PATCH 0/2 V1] arm-mmp-build-sram-driver-alone
V1 - V0: No need for help text for MMP_SRAM in Kconfig and move it into MMP_TDMA text in Kconfig. Qiao Zhou (2): arm: mmp: build sram driver alone dma: mmp-tdma: select sram driver arch/arm/mach-mmp/Kconfig |3 +++ arch/arm/mach-mmp/Makefile |3 ++- drivers/dma/Kconfig|2 ++ 3 files changed, 7 insertions(+), 1 deletions(-) -- 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] arm: mmp: build sram driver alone
sram driver can be used by many chips besides CPU_MMP2, and so build it alone. Reported-by: Dan Williams dan.j.willi...@intel.com Signed-off-by: Qiao Zhou zhouq...@marvell.com --- arch/arm/mach-mmp/Kconfig |3 +++ arch/arm/mach-mmp/Makefile |3 ++- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-mmp/Kconfig b/arch/arm/mach-mmp/Kconfig index ebdda83..ebdba87 100644 --- a/arch/arm/mach-mmp/Kconfig +++ b/arch/arm/mach-mmp/Kconfig @@ -136,4 +136,7 @@ config USB_EHCI_MV_U2O help Enables support for OTG controller which can be switched to host mode. +config MMP_SRAM + bool + endif diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile index 9b702a1..98f0f63 100644 --- a/arch/arm/mach-mmp/Makefile +++ b/arch/arm/mach-mmp/Makefile @@ -7,7 +7,8 @@ obj-y += common.o devices.o time.o # SoC support obj-$(CONFIG_CPU_PXA168) += pxa168.o obj-$(CONFIG_CPU_PXA910) += pxa910.o -obj-$(CONFIG_CPU_MMP2) += mmp2.o sram.o +obj-$(CONFIG_CPU_MMP2) += mmp2.o +obj-$(CONFIG_MMP_SRAM) += sram.o ifeq ($(CONFIG_COMMON_CLK), ) obj-y += clock.o -- 1.7.0.4 -- 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/2] dma: mmp-tdma: select sram driver
Reported-by: Dan Williams dan.j.willi...@intel.com Signed-off-by: Qiao Zhou zhouq...@marvell.com --- drivers/dma/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index dd2874e..599f0ae 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -288,9 +288,11 @@ config MMP_TDMA bool MMP Two-Channel DMA support depends on ARCH_MMP select DMA_ENGINE + select MMP_SRAM help Support the MMP Two-Channel DMA engine. This engine used for MMP Audio DMA and pxa910 SQU. + It needs sram driver under mach-mmp. Say Y here if you enabled MMP ADMA, otherwise say N. -- 1.7.0.4 -- 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 RFC] mm readahead: Fix the readahead fail in case of empty numa node
Thank you Andrew.
On 12/04/2013 04:08 AM, Andrew Morton wrote:
On Tue, 3 Dec 2013 16:06:17 +0530 Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
On a cpu with an empty numa node,
This makes no sense - numa nodes don't reside on CPUs.
I think you mean on a CPU which resides on a memoryless NUMA node?
You are right. I was not precise there.
I had this example in mind while talking.
IBM P730
--
# numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
23 24 25 26 27 28 29 30 31
node 0 size: 0 MB
node 0 free: 0 MB
node 1 cpus:
node 1 size: 12288 MB
node 1 free: 10440 MB
node distances:
node 0 1
0: 10 40
1: 40 10
readahead fails because max_sane_readahead
returns zero. The reason is we look into number of inactive + free pages
available on the current node.
The following patch tries to fix the behaviour by checking for potential
empty numa node cases.
The rationale for the patch is, readahead may be worth doing on a remote
node instead of incuring costly disk faults later.
I still feel we may have to sanitize the nr below, (for e.g., nr/8)
to avoid serious consequences of malicious application trying to do
a big readahead on a empty numa node causing unnecessary load on remote nodes.
( or it may even be that current behaviour is right in not going ahead with
readahead to avoid the memory load on remote nodes).
I don't recall the rationale for the current code and of course we
didn't document it. It might be in the changelogs somewhere - could
you please do the git digging and see if you can find out?
Unfaortunately, from my search, I saw that the code belonged to pre git
time, so could not get much information on that.
I don't immediately see why readahead into a different node is
considered a bad thing.
Ok.
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -243,8 +243,11 @@ int force_page_cache_readahead(struct address_space
*mapping, struct file *filp,
*/
unsigned long max_sane_readahead(unsigned long nr)
{
- return min(nr, (node_page_state(numa_node_id(), NR_INACTIVE_FILE)
- + node_page_state(numa_node_id(), NR_FREE_PAGES)) / 2);
+ unsigned long numa_free_page;
+ numa_free_page = (node_page_state(numa_node_id(), NR_INACTIVE_FILE)
+ + node_page_state(numa_node_id(), NR_FREE_PAGES));
+
+ return numa_free_page ? min(nr, numa_free_page / 2) : nr;
Well even if this CPU's node has very little pagecache at all, what's
wrong with permitting readahead? We don't know that the new pagecache
will be allocated exclusively from this CPU's node anyway. All very
odd.
true we do not know from where it gets allocated and also I completely
agree that I could not think why we should not think
of entire memory rather than sticking our decision to one node.
Or is this one of proactive case to stop worsening situation when
system is really short of memory?
Do let me know if you have any idea to handle 'little cache case'
or do you think the current one is simple enough for now to live with.
Whatever we do, we should leave behind some good code comments which
explain the rationale(s), please. Right now it's rather opaque.
Yes. For the current code may be we have to have comment some thing
like ?
/*
* Sanitize readahead when we have less memory on the current node.
* We do not want to load remote memory with readahead case.
*/
and if this patch is okay then some thing like.
/*
* Sanitized readahead onto remote memory is better than no readahead
* when local numa node does not have memory. If local numa has less
* memory we trim readahead size depending on potential free memory
* available.
*/
--
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] Staging: speakup: synth.c: removed a space
You and I generally agree on style preferences... I think the warning should be limited to grep ;$. I did a grep on the kernel for ' ;' and found 8000 results. 6000 of them are caught by my semicolon before the newline rule. The remaining 2000 are assembly, macros, and crappy for loops. regards, dan carpenter -- 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: [f2fs-dev] [PATCH v2] f2fs: refactor bio-related operations
Hi,
-Original Message-
From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
Sent: Wednesday, December 04, 2013 4:11 PM
To: Chao Yu
Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net;
linux-fsde...@vger.kernel.org; 谭姝
Subject: RE: [f2fs-dev] [PATCH v2] f2fs: refactor bio-related operations
Hi,
+ if (btype == META)
+ rw |= REQ_META;
+
+ if (is_read_io(rw)) {
+ if (sync)
+ rw |= READ_SYNC;
+ submit_bio(rw, io-bio);
+ trace_f2fs_submit_read_bio(sbi-sb, rw, type, io-bio);
+ io-bio = NULL;
+ return;
+ }
+
+ if (sync)
+ rw |= WRITE_SYNC;
rw = WRITE_SYNC; ?
No, since it removes the REQ_META.
See above.
Ah, you're right, Thanks.
+ if (type = META_FLUSH)
+ rw |= WRITE_FLUSH_FUA;
rw = WRITE_FLUSH_FUA; ?
+
+ /*
+ * META_FLUSH is only from the checkpoint procedure, and we should wait
+ * this metadata bio for FS consistency.
+ */
+ if (type == META_FLUSH) {
+ DECLARE_COMPLETION_ONSTACK(wait);
+ io-bio-bi_private = wait;
+ submit_bio(rw, io-bio);
+ wait_for_completion(wait);
+ } else {
+ submit_bio(rw, io-bio);
+ }
+ trace_f2fs_submit_write_bio(sbi-sb, rw, btype, io-bio);
+ io-bio = NULL;
+}
[snip]
Thanks,
Yu
--
Jaegeuk Kim
Samsung
--
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: How to change erasesize of a partition
On Wed, Dec 4, 2013 at 8:46 AM, Suki Buryani sukibury...@yahoo.com wrote: hi, i have few changes in my mtd partitions, i want to change the erasesize of a partition. can any one tell me where i should look to change erasesize of mtd3... The erase size is defined by the MTD device, you cannot change it. -- Thanks, //richard -- 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: How to change erasesize of a partition
I though it would be configurable some where in kernel On Wednesday, December 4, 2013 1:25 PM, Richard Weinberger richard.weinber...@gmail.com wrote: On Wed, Dec 4, 2013 at 8:46 AM, Suki Buryani sukibury...@yahoo.com wrote: hi, i have few changes in my mtd partitions, i want to change the erasesize of a partition. can any one tell me where i should look to change erasesize of mtd3... The erase size is defined by the MTD device, you cannot change it. -- Thanks, //richard -- 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/ -- 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 RFC] mfd: Stop setting refcounting pointers in original mfd_cell arrays
On Tue, 29 Oct 2013, Geert Uytterhoeven wrote: Commit 1e29af62f2b285bd18685da93c3ce8c33ca2d1db (mfd: Add refcounting support to mfd_cells) had to drop the const keyword on the cell parameter of mfd_add_devices(), as it added the refcounting pointers to the objects of the passed mfd_cell array itself. However, the mfd core code operates on copies of the mfd_cell objects, so there's no need to modify the originally passed objects. Hence, move the setting of the refcounting pointers from mfd_add_devices() to mfd_platform_add_cell(), where the copy of the mfd_cell objects is made. mfd_clone_cell() can just pass (a copy of) the original usage_count pointer. This allows to make the cell parameter of mfd_add_devices() const again, and avoids future race conditions when registering multiple instances of the same device in parallel. Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- Ever since this const keyword was removed, I was wondering what was really going on with these reference counts. My main use case involved multiple instances of the same device, where the registration of each successive instance would overwrite the refcounting pointer of the previous one. Finally I found some time to dive into it, and create this patch. If it is accepted, I'll create a follow-up patch to add const keywords to the various mfd_cell arrays. Note that there's another issue in mfd_add_devices(): if the first call to mfd_add_device() fails, the array of atomic_t objects will never be freed, as no child devices have been registered to the parent yet, and thus mfd_remove_devices() won't find anything to remove nor free. drivers/mfd/mfd-core.c | 17 + include/linux/mfd/core.h |2 +- 2 files changed, 10 insertions(+), 9 deletions(-) Hmm... I didn't see my reply to this, but it has been applied for a while. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
On Wed, 04 Dec 2013 16:13:31 +0800 Axel Lin axel@ingics.com wrote:
I can constantly hit this issue:
I trace it to mm/filemap.c: add_to_page_cache_locked
I print the in_atomic status at BEGIN and END of add_to_page_cache_locked
call.
Then I got in_atomic is true at the end of add_to_page_cache_locked call.
int add_to_page_cache_locked(struct page *page, struct address_space *mapping,
pgoff_t offset, gfp_t gfp_mask)
{
int error;
VM_BUG_ON(!PageLocked(page));
VM_BUG_ON(PageSwapBacked(page));
pr_info( ##add_to_page_cache_locked BEGIN in_atomic=%d\n, in_atomic());
error = mem_cgroup_cache_charge(page, current-mm,
gfp_mask GFP_RECLAIM_MASK);
if (error)
return error;
error = radix_tree_maybe_preload(gfp_mask ~__GFP_HIGHMEM);
if (error) {
mem_cgroup_uncharge_cache_page(page);
return error;
}
page_cache_get(page);
page-mapping = mapping;
page-index = offset;
spin_lock_irq(mapping-tree_lock);
error = radix_tree_insert(mapping-page_tree, offset, page);
radix_tree_preload_end();
if (unlikely(error))
goto err_insert;
mapping-nrpages++;
__inc_zone_page_state(page, NR_FILE_PAGES);
spin_unlock_irq(mapping-tree_lock);
trace_mm_filemap_add_to_page_cache(page);
pr_info( ##add_to_page_cache_locked END in_atomic=%d\n, in_atomic());
return 0;
err_insert:
page-mapping = NULL;
/* Leave page-index set: truncation relies upon it */
spin_unlock_irq(mapping-tree_lock);
mem_cgroup_uncharge_cache_page(page);
page_cache_release(page);
pr_info( ##add_to_page_cache_locked ERR in_atomic=%d\n, in_atomic());
return error;
}
Then I got below messages:
##add_to_page_cache_locked BEGIN in_atomic=0
##add_to_page_cache_locked END in_atomic=0
##add_to_page_cache_locked BEGIN in_atomic=0
##add_to_page_cache_locked END in_atomic=0
##add_to_page_cache_locked BEGIN in_atomic=0
##add_to_page_cache_locked END in_atomic=1
huh. I can't spot it. mem_cgroup_cache_charge() is by far the most
complex callee.
Is tracing enabled?
Is memcg in use?
Please add a lot more printk's so we can narrow it down further? I'd
use something like
printk(%d: %d\n, __LINE__, preempt_count());
(note: preempt_count(), not in_atomic())
Paste that all over the place so we can see which statement is doing
the wrong thing.
Thanks.
--
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] mfd: Fix memory leak in mfd_add_devices()
On Tue, 29 Oct 2013, Geert Uytterhoeven wrote: If the first call to mfd_add_device() fails, no child devices have been registered to the parent yet, and thus mfd_remove_devices() won't find anything to remove nor free. Hence the previously allocated array of atomic_t objects will leak. Free the array instead of calling mfd_remove_devices() on failure during the first loop iteration to fix this. Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- drivers/mfd/mfd-core.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) Hmm... I didn't see my reply to this, but it has been applied for a while. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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] usb: ohci-at91: use device managed clk retrieval
Hello Alan, On 03/12/2013 16:32, Alan Stern wrote: On Tue, 3 Dec 2013, Nicolas Ferre wrote: On 03/12/2013 15:07, Boris BREZILLON : Replace clk_get calls by devm_clk_get calls. Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com Tested-by: Robert Nelson robertcnel...@gmail.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com Thanks Boris for these fixes. Alan, Greg, can you take the whole series as fixes for 3.13? Signed-off-by: Alan Stern st...@rowland.harvard.edu Sorry, but I forgot to add your Signed-off-by in the 2nd version of this series. The patches look fine to me. But only the 1/3 patch fixes a bug; the others merely change the resource management. Do you want me to split this series ? 1) the 1st patch that should be merged in 3.13 2) patches 2 to 4 that might be applied later Best Regards, Boris Alan Stern -- 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 v4 1/3] mfd: tps6586x: add version detection
Am 2013-12-04 09:10, schrieb Lee Jones:
+int tps6586x_get_version(struct device *dev)
+{
+struct tps6586x *tps6586x = dev_get_drvdata(dev);
+
+return tps6586x-version;
+}
+EXPORT_SYMBOL_GPL(tps6586x_get_version);
I thought Mark suggested that this routine was converted to a 'static
inline' and moved into the header? Did you not think this was a good
idea?
As I pointed out in the comment above, the struct tps6586x is in the C
file, so I would need to move that too. That's why I did not made that
change in the end. What do you think, should I still move (and move the
struct too?)
--
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] perf/x86: fix bug in event constraint end marker macro
The EVENT_CONSTRAINT_END macro defines the end marker as
a constraint with a weight of zero. This was all fine
until we blacklisted the corrupting memory events on
Intel IvyBridge. These events are blacklisted by using
a counter bitmask of zero. Thus, they also get a constraint
weight of zero.
The iteration macro: for_each_constraint tests the weight==0.
Therefore, it was stopping at the first blacklisted event, i.e.,
0xd0. The corrupting events were therefore considered as
unconstrained and were scheduled on any of the generic counters.
This patch fixes the end marker to have a weight of -1. With this,
the blacklisted events get an empty constraint and cannot be
scheduled which is what we want for now.
Signed-off-by: Stephane Eranian eran...@google.com
---
arch/x86/kernel/cpu/perf_event.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index fd00bb2..7c900c9 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -263,10 +263,16 @@ struct cpu_hw_events {
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_ST_HSW)
#define EVENT_CONSTRAINT_END \
- EVENT_CONSTRAINT(0, 0, 0)
+ { .idxmsk64 = 0,\
+ .code = 0,\
+ .cmask = 0, \
+ .weight = -1, \
+ .overlap = 0, \
+ .flags = 0, \
+}
#define for_each_event_constraint(e, c)\
- for ((e) = (c); (e)-weight; (e)++)
+ for ((e) = (c); (e)-weight != -1; (e)++)
/*
* Extra registers for specific events.
--
1.8.1.2
--
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] usb: chipidea: msm: Add device tree binding information
Hi Peter,
Thank you for reviewing this patch.
On Wed, 2013-12-04 at 13:40 +0800, Peter Chen wrote:
On Mon, Nov 11, 2013 at 03:35:34PM +0200, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
Please add something in commit log
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/usb/msm-hsusb.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
index 5ea26c6..0a85eba 100644
--- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
@@ -15,3 +15,19 @@ Example EHCI controller device node:
usb-phy = usb_otg;
};
+CI13xxx (Chipidea) USB controllers
+
We have already renamed ci13xxx to ci_hdrc.
Yes, but the chip is still CI13XXX. Freescale documentations is also
referring to actual chip family.
+Required properties:
+- compatible: should contain qcom,ci-hdrc
+- reg: offset and length of the register set in the
memory map
+- interrupts: interrupt-specifier for the controller interrupt.
+- usb-phy: phandle for the PHY device
+- dr_mode: Sould be peripheral
+
Please keep alignment for reg
It looks aligned in editor with smart-tab support.
Regards,
Ivan
Peter
+ gadget@f9a55000 {
+ compatible = qcom,ci-hdrc;
+ reg = 0xf9a55000 0x400;
+ dr_mode = peripheral;
+ interrupts = 0 134 0;
+ usb-phy = usb_otg;
+ };
\ No newline at end of file
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb 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] fs: fix WARN on alloc_super() fail path
On fail path alloc_super() calls destroy_super(), which issues a warning if list_empty() returns false on the s_mounts field. That said s_mounts should be initialized in alloc_super() before any possible failure. Signed-off-by: Vladimir Davydov vdavy...@parallels.com Cc: Al Viro v...@zeniv.linux.org.uk --- fs/super.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/super.c b/fs/super.c index e5f6c2c..cecd780 100644 --- a/fs/super.c +++ b/fs/super.c @@ -166,6 +166,8 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags) if (!s) return NULL; + INIT_LIST_HEAD(s-s_mounts); + if (security_sb_alloc(s)) goto fail; @@ -188,7 +190,6 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags) if (list_lru_init(s-s_inode_lru)) goto fail; - INIT_LIST_HEAD(s-s_mounts); init_rwsem(s-s_umount); lockdep_set_class(s-s_umount, type-s_umount_key); /* -- 1.7.10.4 -- 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: mac80211: tx.c: be sure of 'sdata-vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
On 12/04/2013 04:04 PM, Johannes Berg wrote: On Wed, 2013-12-04 at 10:12 +0800, Chen Gang wrote: It is really not urgent, and for keeping quality, it is necessary to spend suitable time resource (e.g 1 hour or more) to make, review and test this kind of patch carefully by oneself. So could you please help improve it when you have suitable related time resources? No. Who are you to suggest what I need to work on? johannes I am one of volunteers for Open Source, and I don't care about who I am. Since this thread is started by me, I have duty to try my best to let it finish (but may fail). According to our original discussion, it seems we agree that I am not the suitable member to finish it, so I suggest you or another members to try. Thanks. -- Chen Gang -- 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/
