Re: [PATCH part1 v6 4/7] PCI: Introduce pci_serial_number_changed()
>> + * pci_serial_number_changed - check the device SN is changed
>
> How about the name “pci_device_changed”? I think it's more readable,
> though the judgement is according to SN.
Ah, it's nice, will update in next version.
Thanks!
Yijing.
>
> Regards,
> Gu
>
>> + * @pdev: the PCI device
>> + *
>> + * check the device serial number is changed.
>> + * if device does not support device serial number,
>> + * return false.
>> + */
>> +bool pci_serial_number_changed(struct pci_dev *pdev)
>> +{
>> +u64 old, new;
--
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] scsi_sysfs: Implement 'is_visible' callback
On Tue, Feb 11, 2014 at 03:34:53PM +0100, Hannes Reinecke wrote: > Instead of modifying attributes after the device has been created > we should be using the 'is_visible' callback to avoid races. Can't say I like the fact that the is_visible function needs is per-group and not per attribute and thus needs to explicitly check which attribute we call it for, but that seems to be a design issue in the driver core and not the patch. Otherwise looks good with the minor nitpick that it would have looked cleaner in the patch if you had left the queue_type store function in the location it previously was. Reviewed-by: Christoph Hellwig -- 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 part1 v6 5/7] PCI: Add pci_dummy_ops to isolate pci device temporarily
Hi Yijing,
On 02/12/2014 10:52 AM, Yijing Wang wrote:
> Pci_dummy_ops does nothing when we use it to read/write
> pci_device. So we can isolate pci device by replace its
> bus pci_ops by pci_dummy_ops. This is preparation for
> the later patch.
>
> Signed-off-by: Yijing Wang
> ---
> drivers/pci/pci.c | 62
> +++
> include/linux/pci.h |4 +++
> 2 files changed, 66 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index af34057..283e82e 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2226,6 +2226,68 @@ bool pci_serial_number_changed(struct pci_dev *pdev)
> }
> EXPORT_SYMBOL(pci_serial_number_changed);
>
> +static int pci_dummy_read(struct pci_bus *bus, unsigned int devfn,
> + int where, int size, u32 *val)
> +{
> + return PCIBIOS_DEVICE_NOT_FOUND;
> +}
> +
> +static int pci_dummy_write(struct pci_bus *bus, unsigned int devfn,
> + int reg, int size, u32 val)
> +{
> + return PCIBIOS_DEVICE_NOT_FOUND;
> +}
> +
> +static struct pci_ops pci_dummy_ops = {
> + .read = pci_dummy_read,
> + .write = pci_dummy_write,
> +};
> +
> +static DEFINE_SPINLOCK(pci_freeze_lock);
> +/**
> + * pci_bus_freeze_device - freeze pci bus to access pci device
> + * @bus: the pci bus to freeze
> + *
> + * Replace pci bus ops by pci_dummy_ops, protect system from
> + * accessing pci devices.
> + */
> +void pci_bus_freeze_device(struct pci_bus *bus)
> +{
> + struct pci_ops *ops;
> + unsigned long flags;
> +
> + spin_lock_irqsave(_freeze_lock, flags);
> + if (bus->is_frozen)
> + goto out;
> + bus->is_frozen = 1;
> + ops = pci_bus_set_ops(bus, _dummy_ops);
> + bus->save_ops = ops;
> +out:
> + spin_unlock_irqrestore(_freeze_lock, flags);
> +}
> +
> +/**
> + * pci_bus_unfreeze_device - unfreeze pci bus to acess pci devices
> + * @bus: the pci bus to unfreeze
> + *
> + * Restore pci bus original ops, so pci bus can access
> + * pci devices normally.
> + */
> +void pci_bus_unfreeze_device(struct pci_bus *bus)
> +{
> + unsigned long flags;
> +
> + BUG_ON(!bus->save_ops);
> + spin_lock_irqsave(_freeze_lock, flags);
> + if (!bus->is_frozen)
> + goto out;
It seems that the BUG_ON() should placed here, otherwise it will be
triggered if we try to unfreeze the same bus multiply.
Regards,
Gu
> + pci_bus_set_ops(bus, bus->save_ops);
> + bus->save_ops = NULL;
> + bus->is_frozen = 0;
> +out:
> + spin_unlock_irqrestore(_freeze_lock, flags);
> +}
> +
> /**
> * pci_configure_ari - enable or disable ARI forwarding
> * @dev: the PCI device
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index d60c0b6..e3dd4ea 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -442,6 +442,7 @@ struct pci_bus {
> struct resource busn_res; /* bus numbers routed to this bus */
>
> struct pci_ops *ops; /* configuration access functions */
> + struct pci_ops *save_ops; /* save configuration access functions */
> struct msi_chip *msi; /* MSI controller */
> void*sysdata; /* hook for sys-specific extension */
> struct proc_dir_entry *procdir; /* directory entry in /proc/bus/pci */
> @@ -460,6 +461,7 @@ struct pci_bus {
> struct bin_attribute*legacy_io; /* legacy I/O for this bus */
> struct bin_attribute*legacy_mem; /* legacy mem */
> unsigned intis_added:1;
> + unsigned intis_frozen:1;
> };
>
> #define pci_bus_b(n) list_entry(n, struct pci_bus, node)
> @@ -1026,6 +1028,8 @@ ssize_t pci_read_vpd(struct pci_dev *dev, loff_t pos,
> size_t count, void *buf);
> ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const
> void *buf);
>
> bool pci_serial_number_changed(struct pci_dev *pdev);
> +void pci_bus_freeze_device(struct pci_bus *bus);
> +void pci_bus_unfreeze_device(struct pci_bus *bus);
>
> /* Helper functions for low-level code (drivers/pci/setup-[bus,res].c) */
> resource_size_t pcibios_retrieve_fw_addr(struct pci_dev *dev, int idx);
--
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 RESEND] leds-gpio: fix a typo in the documentation
Signed-off-by: Laszlo Papp --- Documentation/devicetree/bindings/leds/leds-gpio.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt b/Documentation/devicetree/bindings/leds/leds-gpio.txt index df1b308..00e94fe 100644 --- a/Documentation/devicetree/bindings/leds/leds-gpio.txt +++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt @@ -16,7 +16,7 @@ LED sub-node properties: see Documentation/devicetree/bindings/leds/common.txt - default-state: (optional) The initial state of the LED. Valid values are "on", "off", and "keep". If the LED is already on or off - and the default-state property is set the to same value, then no + and the default-state property is set to the same value, then no glitch should be produced where the LED momentarily turns off (or on). The "keep" setting will keep the LED at whatever its current state is, without producing a glitch. The default is off if this -- 1.8.5.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 01/28] Remove CPU_MMP3
Cc Yu Xu
On Tue, Feb 11, 2014 at 11:01 PM, Paul Bolle wrote:
> On Tue, 2014-02-11 at 13:30 -0800, Greg Kroah-Hartman wrote:
>> On Sun, Feb 09, 2014 at 07:47:39PM +0100, Richard Weinberger wrote:
>> > The symbol is an orphan, get rid of it.
>> >
>> > Signed-off-by: Richard Weinberger
>> > Acked-by: Paul Bolle
>> >
>> > ---
>> > drivers/usb/phy/Kconfig | 1 -
>> > drivers/video/mmp/Kconfig| 2 +-
>> > drivers/video/mmp/hw/Kconfig | 2 +-
>> > 3 files changed, 2 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
>> > index 7d1451d..b9b1c52 100644
>> > --- a/drivers/usb/phy/Kconfig
>> > +++ b/drivers/usb/phy/Kconfig
>> > @@ -61,7 +61,6 @@ config KEYSTONE_USB_PHY
>> >
>> > config MV_U3D_PHY
>> > bool "Marvell USB 3.0 PHY controller Driver"
>> > - depends on CPU_MMP3
>> > select USB_PHY
>> > help
>> > Enable this to support Marvell USB 3.0 phy controller for Marvell
>>
>> Do this and the driver breaks the build so it needs to depend on
>> something:
>>
>> drivers/usb/phy/phy-mv-u3d-usb.c: In function ‘mv_u3d_phy_read’:
>> drivers/usb/phy/phy-mv-u3d-usb.c:42:2: error: implicit declaration of
>> function ‘writel_relaxed’ [-Werror=implicit-function-declaration]
>
> This sort of proves that a driver that depends on an unknown Kconfig
> symbol gets no build coverage (and will bit rot).
>
>> Sorry, I can't take this as-is.
>
> My mistake, I should have spotted this when looking a Richard's patch.
>
> Some background (which I quickly dug up): config MV_U3D_PHY got added in
> v3.7 through commit a67e76ac904c ("usb: phy: mv_u3d: Add usb phy driver
> for mv_u3d"). It then depended on USB_MV_U3D. And that symbol depended
> on CPU_MMP3 at that time. Ie, MV_U3D_PHY was unbuildable when it was
> added.
>
> In commit 60630c2eabd4 ("usb: gadget: mv_u3d: drop ARCH dependency")
> MV_U3D_PHY was made depended directly on CPU_MMP3. That kept it
> unbuildable, of course.
>
> Richard, assuming you agree with the above short history of MV_U3D_PHY,
> would you mind sending a v2 that removes this unbuildable driver?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 6/8] cgroup: remove cgroup->name
> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c > index dd52e7f..30eee3b 100644 > --- a/kernel/sched/debug.c > +++ b/kernel/sched/debug.c > @@ -111,8 +111,7 @@ static char *task_group_path(struct task_group *tg) > if (autogroup_path(tg, group_path, PATH_MAX)) > return group_path; > > - cgroup_path(tg->css.cgroup, group_path, PATH_MAX); > - return group_path; > + return cgroup_path(tg->css.cgroup, group_path, PATH_MAX); The caller won't check the return value but pass it to printk/seq_printf, but now cgroup_path() might return -ENAMETOOLONG.. -- 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] hwrng: atmel - Use devm_ioremap_resource()
> "Jingoo" == Jingoo Han writes: > Use devm_ioremap_resource() in order to make the code simpler, > and remove redundant return value check of platform_get_resource() > because the value is checked by devm_ioremap_resource(). > Signed-off-by: Jingoo Han Acked-by: Peter Korsgaard > --- > drivers/char/hw_random/atmel-rng.c | 15 --- > 1 file changed, 4 insertions(+), 11 deletions(-) > diff --git a/drivers/char/hw_random/atmel-rng.c > b/drivers/char/hw_random/atmel-rng.c > index bf9fc6b..dfeddf2 100644 > --- a/drivers/char/hw_random/atmel-rng.c > +++ b/drivers/char/hw_random/atmel-rng.c > @@ -54,21 +54,14 @@ static int atmel_trng_probe(struct platform_device *pdev) > struct resource *res; > int ret; > -res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > -if (!res) > -return -EINVAL; > - > trng = devm_kzalloc(>dev, sizeof(*trng), GFP_KERNEL); > if (!trng) > return -ENOMEM; > -if (!devm_request_mem_region(>dev, res->start, > - resource_size(res), pdev->name)) > -return -EBUSY; > - > -trng->base = devm_ioremap(>dev, res->start, resource_size(res)); > -if (!trng->base) > -return -EBUSY; > +res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > +trng->base = devm_ioremap_resource(>dev, res); > +if (IS_ERR(trng->base)) > +return PTR_ERR(trng->base); trng-> clk = clk_get(>dev, NULL); > if (IS_ERR(trng->clk)) > -- > 1.7.10.4 -- Bye, Peter Korsgaard -- 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: 3.12: ethernet controller missing after resuming from suspend to RAM
On 02/12/2014 12:58 AM, Rafael J. Wysocki wrote: > On Tuesday, February 11, 2014 07:17:37 PM Peter Wu wrote: >> On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote: >>> On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote: > _STA() returns 0x0A instead of 0x0F. Could there be something missing in > the ACPI hotplug code that overlooks this and removes the device on > resume? That is possible. Actually even quite likely, but let's wait for the response from Peter. >>> >>> Here's a hack that should take the 0xa return value into consideration. It >>> turned out that this case is even mentioned in the ACPI spec. >> >> Tested-by: Peter Wu >> >> This works, the devices are not lost anymore after resume. dmesg >> mentions the 04:00.* devices at resume compared to the unpatched kernel: >> >> [ 42.650721] PM: Finishing wakeup. >> [ 42.650768] acpiphp_glue: hotplug_event: Bus check notify on >> \_SB_.PCI0.RP03 >> [ 42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under >> \_SB_.PCI0.RP03 >> [ 42.650874] iwlwifi :05:00.0: no hotplug settings from platform >> [ 42.650722] Restarting tasks ... done. >> [ 42.650985] video LNXVIDEO:00: Restoring backlight state >> [ 42.650988] video LNXVIDEO:01: Restoring backlight state >> [ 43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported >> [ 43.128401] jme :04:00.5: irq 50 for MSI/MSI-X >> [ 43.153005] jme :04:00.5 eth0: Link is down >> [ 43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready >> [ 43.154364] iwlwifi :05:00.0: L1 Enabled; Disabling L0S >> [ 43.162307] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1 >> [ 43.276220] acpiphp_glue: hotplug_event: Bus check notify on >> \_SB_.PCI0.RP01 >> [ 43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under >> \_SB_.PCI0.RP01 >> [ 43.276257] xhci_hcd :02:00.0: no hotplug settings from platform >> [ 43.276267] acpiphp_glue: hotplug_event: Bus check notify on >> \_SB_.PCI0.RP02 >> [ 43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under >> \_SB_.PCI0.RP02 >> [ 43.276355] sdhci-pci :04:00.0: no hotplug settings from platform >> [ 43.276368] pci :04:00.2: no hotplug settings from platform >> [ 43.276381] jmb38x_ms :04:00.3: no hotplug settings from platform >> [ 43.276393] jme :04:00.5: no hotplug settings from platform >> [ 43.276398] acpiphp_glue: hotplug_event: Bus check notify on >> \_SB_.PCI0.RP03 >> [ 43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under >> \_SB_.PCI0.RP03 >> [ 43.276491] iwlwifi :05:00.0: no hotplug settings from platform >> [ 43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready >> >> Rafael, do you want me to test the other patch as well? > > No, thanks! > > Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14. > Thanks guys for solving this issue ! Rafael, could this be submitted to stable trees (at least 3.12, 3.13) as well ? -- 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 5/6] vhost_net: poll vhost queue after marking DMA is done
On 2013/8/30 12:29, Jason Wang wrote: We used to poll vhost queue before making DMA is done, this is racy if vhost thread were waked up before marking DMA is done which can result the signal to be missed. Fix this by always poll the vhost thread before DMA is done. Signed-off-by: Jason Wang --- drivers/vhost/net.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index ff60c2a..d09c17c 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -308,6 +308,11 @@ static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success) struct vhost_virtqueue *vq = ubufs->vq; int cnt = atomic_read(>kref.refcount); + /* set len to mark this desc buffers done DMA */ + vq->heads[ubuf->desc].len = success ? + VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN; + vhost_net_ubuf_put(ubufs); + /* * Trigger polling thread if guest stopped submitting new buffers: * in this case, the refcount after decrement will eventually reach 1 @@ -318,10 +323,6 @@ static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success) */ if (cnt <= 2 || !(cnt % 16)) vhost_poll_queue(>poll); - /* set len to mark this desc buffers done DMA */ - vq->heads[ubuf->desc].len = success ? - VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN; - vhost_net_ubuf_put(ubufs); } /* Expects to be always run from workqueue - which acts as with this change, vq would lose protection that provided by ubufs->kref. if another thread is waiting at vhost_net_ubuf_put_and_wait called by vhost_net_release, then after vhost_net_ubuf_put, vq would been free by vhost_net_release soon, vhost_poll_queue(>poll) may cause NULL pointer Exception. another question is that vhost_zerocopy_callback is called by kfree_skb, it may called in different thread context. vhost_poll_queue is called decided by ubufs->kref.refcount, this may cause there isn't any thread call vhost_poll_queue, but at least one is needed. and this cause network break. We could repeat it by using 8 netperf thread in guest to xmit tcp to its host. I think if using atomic_read to decide while do vhost_poll_queue or not, at least a spink_lock is needed. -- 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 part1 v6 4/7] PCI: Introduce pci_serial_number_changed()
Hi Yijing,
On 02/12/2014 10:52 AM, Yijing Wang wrote:
> Sometimes OS do not know the physical device swap,
> for instance, some device hotplug during system suspend.
> Interrupt can not deliver to OS in some platform.
> So we can use pci serial number capability to detect this
> issue if device supports serial number.
>
> Signed-off-by: Yijing Wang
> Cc: Paul Bolle
> Cc: Oliver Neukum
> Cc: Gu Zheng
> Cc: linux-...@vger.kernel.org
> ---
> drivers/pci/pci.c | 28
> include/linux/pci.h |2 ++
> 2 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index a8c1c2d..af34057 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2199,6 +2199,34 @@ void pci_dsn_init(struct pci_dev *dev)
> }
>
> /**
> + * pci_serial_number_changed - check the device SN is changed
How about the name “pci_device_changed”? I think it's more readable,
though the judgement is according to SN.
Regards,
Gu
> + * @pdev: the PCI device
> + *
> + * check the device serial number is changed.
> + * if device does not support device serial number,
> + * return false.
> + */
> +bool pci_serial_number_changed(struct pci_dev *pdev)
> +{
> + u64 old, new;
> + old = pdev->sn;
> +
> + if (!pci_is_pcie(pdev))
> + return false;
> +
> + new = pci_device_serial_number(pdev->bus,
> + pdev->devfn);
> +
> + if (old != new) {
> + pr_info("%s: Device Serial Number Changed!\n",
> + pci_name(pdev));
> + return true;
> + } else
> + return false;
> +}
> +EXPORT_SYMBOL(pci_serial_number_changed);
> +
> +/**
> * pci_configure_ari - enable or disable ARI forwarding
> * @dev: the PCI device
> *
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 3631859..d60c0b6 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1025,6 +1025,8 @@ void pci_unlock_rescan_remove(void);
> ssize_t pci_read_vpd(struct pci_dev *dev, loff_t pos, size_t count, void
> *buf);
> ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const
> void *buf);
>
> +bool pci_serial_number_changed(struct pci_dev *pdev);
> +
> /* Helper functions for low-level code (drivers/pci/setup-[bus,res].c) */
> resource_size_t pcibios_retrieve_fw_addr(struct pci_dev *dev, int idx);
> void pci_bus_assign_resources(const struct pci_bus *bus);
--
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/4] sparc64: convert spinlock_t to raw_spinlock_t in mmu_context_t
On Wednesday 12 February 2014 02:43 AM, Kirill Tkhai wrote: > > > 06.01.2014, 07:56, "Allen Pais" : >> In the attempt of get PREEMPT_RT working on sparc64 using >> linux-stable-rt version 3.10.22-rt19+, the kernel crash >> with the following trace: >> >> [ 1487.027884] I7: >> [ 1487.027885] Call Trace: >> [ 1487.027887] [004967dc] rt_mutex_setprio+0x3c/0x2c0 >> [ 1487.027892] [004afe20] task_blocks_on_rt_mutex+0x180/0x200 >> [ 1487.027895] [00819114] rt_spin_lock_slowlock+0x94/0x300 >> [ 1487.027897] [00817ebc] __schedule+0x39c/0x53c >> [ 1487.027899] [008185fc] schedule+0x1c/0xc0 >> [ 1487.027908] [0048fff4] smpboot_thread_fn+0x154/0x2e0 >> [ 1487.027913] [0048753c] kthread+0x7c/0xa0 >> [ 1487.027920] [004060c4] ret_from_syscall+0x1c/0x2c >> [ 1487.027922] [] (null) >> - spin_unlock_irqrestore(>context.lock, flags); >> + raw_spin_unlock_irqrestore(>context.lock, flags); >> } > > We also should do the same in update_mmu_cache_pmd(). > I have already done this. I should have updated the patch. the issue still persists though. - Allen -- 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 06/35] perf hists: Leave symbol addr hist bucket auto alloc to symbol layer
Hi, > From: Arnaldo Carvalho de Melo > > Since now symbol__addr_inc_samples() does the auto alloc, no need to > do it prior to calling hist_entry__inc_addr_samples. perf annotate on a ppc64 build (no TUI) is failing. I get zero output. I haven't had a chance to look closer, but I used the following git bisect test script to isolate: #!/bin/sh cd tools/perf make || exit 125 PERF=./perf $PERF record -a sleep 5 if [ -z "`$PERF annotate`" ]; then exit 1 else exit 0 fi Anton -- 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: [PATCHv3 1/4] zram: introduce compressing backend abstraction
Hello Sergey,
On Wed, Feb 12, 2014 at 01:21:03AM +0300, Sergey Senozhatsky wrote:
> ZRAM performs direct LZO compression algorithm calls, making it the one
> and only option. Introduce abstract struct zram_comp in order to support
> multiple compression algorithms. struct zram_comp defines the following
> set of compressing backend operations:
> .create
> .destroy
> .compress
> .decompress
>
> Schematically zram write() usually contains the following steps:
> 0) preparation (decompression of partioal IO, etc.)
> 1) lock buffer_lock mutex (protects meta compress buffers)
> 2) compress (using meta compress buffers)
> 3) alloc and map zs_pool object
> 4) copy compressed data (from meta compress buffers) to object allocated by 3)
> 5) free previous pool page, assign a new one
> 6) unlock buffer_lock mutex
>
> As we can see, compressing buffers must remain untouched from 1) to 4),
> because, otherwise, concurrent write() can overwrite data. At the same
> time, zram_meta must be aware of a) specific compression algorithm
> memory requirements and b) necessary locking to protect compression
> buffers. Besides, zram holds buffer_lock almost through the whole write()
> function, making parallel compression impossible. To remove requirement
> a) new struct zcomp_workmem introduced, which contain buffers required by
> compression algorithm. While struct zram_comp implements workmem handling
> and locking by means of get() and put() semantics and removes requirement
> b) from zram meta. zram_comp ->create() and ->destroy(), respectively,
> allocate and deallocate algorithm specific zcomp_workmem `private' buffer.
>
> Every zram_comp has a list of idle workmem buffers (at least 1 workmem),
> spinlock to protect idle list and wait queue, making it possible to perform
> parallel compressions. Each time zram issues a zcomp_workmem_get() call, the
> following set of operations performed:
> - spin lock buffer_lock
> - if idle list is not empty, remove workmem from idle list, spin
> unlock and return workmem pointer
> - if idle list is empty, current adds itself to wait queue. it will be
> awaken by zcomp_workmem_put() caller.
>
> zcomp_workmem_put():
> - spin lock buffer_lock
> - add workmem to idle list
> - spin unlock, wake up sleeper (if any)
>
> In other words, zcomp_workmem_get() turns caller into exclusive user of
> workmem
> and zcomp_workem_put() makes a particular workmem available.
>
> Usage examples.
>
> To initialize compressing backend:
> comp = zcomp_create(NAME) /* NAME e.g. lzo */
>
> which initialises compressing backend if requested algorithm is supported.
>
> Compress:
> wm = zcomp_workmem_get(comp)
> zcomp_compress(comp, wm, src, src_len, _len)
> [..] /* copy compressed data */
> zcomp_workmem_put(comp, wm)
>
> Decompress:
> zcomp_decompress(comp, src, src_len, dst, _len);
>
> Free compessing backend and its workmem:
> zcomp_destroy(comp)
>
> Signed-off-by: Sergey Senozhatsky
> ---
> drivers/block/zram/zcomp_lzo.c | 33 +
> drivers/block/zram/zram_comp.c | 147
> +
> drivers/block/zram/zram_comp.h | 58
> 3 files changed, 238 insertions(+)
> create mode 100644 drivers/block/zram/zcomp_lzo.c
> create mode 100644 drivers/block/zram/zram_comp.c
> create mode 100644 drivers/block/zram/zram_comp.h
>
> diff --git a/drivers/block/zram/zcomp_lzo.c b/drivers/block/zram/zcomp_lzo.c
> new file mode 100644
> index 000..bbde74e
> --- /dev/null
> +++ b/drivers/block/zram/zcomp_lzo.c
> @@ -0,0 +1,33 @@
> +/*
> + * Copyright (C) 2014 Sergey Senozhatsky.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "zram_comp.h"
> +
> +static void * lzo_create(void)
> +{
> + return kmalloc(LZO1X_MEM_COMPRESS, GFP_KERNEL);
> +}
> +
> +static void lzo_destroy(void *workmem)
> +{
> + kfree(workmem);
> +}
It's okay to name "workmem" for lzo because lzo needs only work buffer to work
but let's think about zlib. It needs z_streamp which has many feilds
to work as well as work memory. That's why I don't like "workmem" name which
is very specific. Anyway, it's okay for lzo backend now.
> +
> +extern struct zram_comp_backend zcomp_lzo;
> +struct zram_comp_backend zcomp_lzo = {
> + .compress = lzo1x_1_compress,
> + .decompress = lzo1x_decompress_safe,
> + .create = lzo_create,
> + .destroy = lzo_destroy,
> + .name = "lzo",
> +};
> diff --git a/drivers/block/zram/zram_comp.c b/drivers/block/zram/zram_comp.c
> new file mode 100644
> index 000..139a468
> --- /dev/null
> +++ b/drivers/block/zram/zram_comp.c
> @@ -0,0 +1,147 @@
> +/*
> + * Copyright (C) 2014 Sergey
Re: 3.14-rc2 XFS backtrace because irqs_disabled.
On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote: > On Tue, Feb 11, 2014 at 9:40 PM, Dave Chinner wrote: > > > > None of the XFS code disables interrupts in that path, not does is > > call outside XFS except to dispatch IO. The stack is pretty deep at > > this point and I know that the standard (non stacked) IO stack can > > consume >3kb of stack space when it gets down to having to do memory > > reclaim during GFP_NOIO allocation at the lowest level of SCSI > > drivers. Stack overruns typically show up with symptoms like we are > > seeing. > > That would also explain why it shows up for do_coredump(), even though > clearly interrupts are not disabled at that point. It's just because > do_coredump() opens a filename at a deeper point in the stack than the > more normal system call paths do. Right, it's exactly the same problem we have when knfsd is making the VFS calls. > It looks like just "do_signal()" has a stack frame that is about 230 > bytes even under normal circumstancs (largely due to "struct ksignal" > - which in turn is largely due to the insane 128-byte padding in > siginfo_t). Add a few other frames in there, and I guess that if it > was close before, the coredump path just makes it go off. Yup. But it's when you see this sort of thing you realise that almost no GFP_KERNEL memory allocation is really safe from stack overruns, though: 0) 6064 64 update_group_power+0x2c/0x270 1) 6000 384 find_busiest_group+0x10a/0x8b0 2) 5616 288 load_balance+0x165/0x870 3) 5328 96 idle_balance+0x106/0x1b0 4) 5232 112 __schedule+0x7b6/0x7e0 5) 5120 16 schedule+0x29/0x70 6) 5104 176 percpu_ida_alloc+0x1b3/0x3d0 7) 4928 32 blk_mq_wait_for_tags+0x1f/0x40 8) 4896 80 blk_mq_alloc_request_pinned+0x4e/0x110 9) 4816 128 blk_mq_make_request+0x42b/0x510 10) 4688 48 generic_make_request+0xc0/0x110 11) 4640 96 submit_bio+0x71/0x120 12) 4544 192 _xfs_buf_ioapply+0x2cc/0x3b0 13) 4352 48 xfs_buf_iorequest+0x6f/0xc0 14) 4304 32 xlog_bdstrat+0x23/0x60 15) 4272 96 xlog_sync+0x3a4/0x5c0 16) 4176 48 xlog_state_release_iclog+0x121/0x130 17) 4128 192 xlog_write+0x700/0x7c0 18) 3936 192 xlog_cil_push+0x2ae/0x3d0 19) 3744 128 xlog_cil_force_lsn+0x1b8/0x1e0 20) 3616 144 _xfs_log_force_lsn+0x7c/0x300 21) 3472 48 xfs_log_force_lsn+0x3b/0xa0 22) 3424 112 xfs_iunpin_wait+0xd7/0x160 23) 3312 80 xfs_reclaim_inode+0xd0/0x350 24) 3232 432 xfs_reclaim_inodes_ag+0x277/0x3d0 25) 2800 48 xfs_reclaim_inodes_nr+0x33/0x40 26) 2752 16 xfs_fs_free_cached_objects+0x15/0x20 27) 2736 80 super_cache_scan+0x169/0x170 28) 2656 160 shrink_slab_node+0x133/0x290 29) 2496 80 shrink_slab+0x122/0x160 30) 2416 112 do_try_to_free_pages+0x1de/0x360 31) 2304 192 try_to_free_pages+0x110/0x190 32) 2112 256 __alloc_pages_nodemask+0x5a2/0x8e0 33) 1856 80 alloc_pages_current+0xb2/0x170 34) 1776 64 new_slab+0x265/0x2e0 35) 1712 240 __slab_alloc+0x2fb/0x4c4 36) 1472 80 kmem_cache_alloc+0x10b/0x140 That's almost 4700 bytes of stack usage from the kmem_cache_alloc(GFP_KERNEL) call because it entered the IO path. Yes, it's an extreme case, but if you're looking for a smoking gun :/ I can fix this one easily - we already have a workqueue for doing async log pushes (will split the stack between xlog_cil_force_lsn and xlog_cil_push), but the reason we haven't used it for synchronous log forces is that screws up fsync performance on CFQ. We don't recommend CFQ with XFS anyway, so I think I'll make this change anyway. > And some of the debug options that I'm sure DaveJ has enabled tend to > make the stack usage worse (simply because they make a lot of data > structures bigger). True - CONFIG_XFS_DEBUG tends to add about 5% to the stack usage of XFS, but realistically 5% is not significant especially as we've been hitting stack overflows with XFS on production systems regularly enough on x86-64 over the past 2-3 years that we know what "typical symptoms" of such overflows are... The problem we have now is that everything outside XFS continues to grow in stack usage, so the only choice that remains for us to avoid overruns is to add performance impacting stack switches into the middle of common XFS paths. We also have to do it unconditionally because we don't know ahead of time if any specific operation is going to require all the stack we can give it because - for example - we can't predict when the IO path is going to require memory allocation... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org
Re: [PATCH v2] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/media
Hi, On 11/02/14 23:41, Philipp Zabel wrote: > From: Philipp Zabel > > This patch moves the parsing helpers used to parse connected graphs > in the device tree, like the video interface bindings documented in > Documentation/devicetree/bindings/media/video-interfaces.txt, from > drivers/media/v4l2-core to drivers/media. > > This allows to reuse the same parser code from outside the V4L2 > framework, most importantly from display drivers. > The functions v4l2_of_get_next_endpoint, v4l2_of_get_remote_port, > and v4l2_of_get_remote_port_parent are moved. They are renamed to > of_graph_get_next_endpoint, of_graph_get_remote_port, and > of_graph_get_remote_port_parent, respectively. > Since there are not that many current users, switch all of them > to the new functions right away. > > Signed-off-by: Philipp Zabel > Acked-by: Mauro Carvalho Chehab > Acked-by: Guennadi Liakhovetski I don't think the graphs or the parsing code has anything video specific. It could well be used for anything, whenever there's need to describe connections between devices which are not handled by the normal child-parent relationships. So the code could well reside in some generic place, in my opinion. Also, I have no problem with having it in drivers/media, but drivers/video should work also. We already have other, generic, video related things there like hdmi infoframes and display timings. And last, it's fine to move the funcs as-is in the first place, but I think they should be improved a bit before non-v4l2 users use them. There are a couple of things I tried to accomplish with the omapdss specific versions in https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html: - Iterating ports and endpoints separately. If a node has multiple ports, I would think that the driver needs to know which port and endpoint combination is the current one during iteration. It's not enough to just get the endpoint. - Simplify cases when there's just one port and one endpoint, in which case the port node can be omitted from the DT data. Tomi signature.asc Description: OpenPGP digital signature
[tip:sched/core] cpuidle/pseries: Fix fallout caused due to cleanup in pseries cpuidle backend driver
Commit-ID: 3f67d962c64d9b6de9dab81bdbe6d5c94c80d9b9
Gitweb: http://git.kernel.org/tip/3f67d962c64d9b6de9dab81bdbe6d5c94c80d9b9
Author: Preeti U Murthy
AuthorDate: Wed, 12 Feb 2014 10:18:45 +0530
Committer: Ingo Molnar
CommitDate: Wed, 12 Feb 2014 08:05:03 +0100
cpuidle/pseries: Fix fallout caused due to cleanup in pseries cpuidle backend
driver
Commit d8c6ad3184ca651 ("sched/idle, PPC: Remove redundant
cpuidle_idle_call()") reintroduced ppc64_runlatch_off/on() in the
pseries cpuidle backend driver. Hence the cleanup caused by the
commit "c0c4301c54adde05:pseries/cpuidle: Remove redundant call
to ppc64_runlatch_off() in cpu idle routines" in conjuction
with the commit d8c6ad3184ca651 causes a build failure.
Signed-off-by: Preeti U Murthy
Cc: Peter Zijlstra
Cc: Nicolas Pitre
Cc: Stephen Rothwell
Link: http://lkml.kernel.org/r/52fafd2d.2090...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
drivers/cpuidle/cpuidle-pseries.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpuidle/cpuidle-pseries.c
b/drivers/cpuidle/cpuidle-pseries.c
index d486489..6f7b019 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
struct cpuidle_driver pseries_idle_driver = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] can: xilinx CAN controller support.
This patch adds xilinx CAN controller support.
This driver supports both ZYNQ CANPS IP and
Soft IP AXI CAN controller.
Signed-off-by: Kedareswara rao Appana
---
This patch is rebased on the 3.14 rc2 kernel.
Changes for v2:
- Updated with the review comments.
- Removed unnecessary debug prints.
- included tx,rx fifo depths in ZYNQ CANPS case also.
---
.../devicetree/bindings/net/can/xilinx_can.txt | 45 +
drivers/net/can/Kconfig|7 +
drivers/net/can/Makefile |1 +
drivers/net/can/xilinx_can.c | 1153
4 files changed, 1206 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/xilinx_can.txt
create mode 100644 drivers/net/can/xilinx_can.c
diff --git a/Documentation/devicetree/bindings/net/can/xilinx_can.txt
b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
new file mode 100644
index 000..0e57103
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
@@ -0,0 +1,45 @@
+Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings
+-
+
+Required properties:
+- compatible : Should be "xlnx,zynq-can-1.00.a" for Zynq CAN
+ controllers and "xlnx,axi-can-1.00.a" for Axi CAN
+ controllers.
+- reg : Physical base address and size of the Axi CAN/Zynq
+ CANPS registers map.
+- interrupts : Property with a value describing the interrupt
+ number.
+- interrupt-parent : Must be core interrupt controller
+- clock-names : List of input clock names - "ref_clk", "aper_clk"
+ (See clock bindings for details. Two clocks are
+ required for Zynq CAN. For Axi CAN
+ case it is one(ref_clk)).
+- clocks : Clock phandles (see clock bindings for details).
+- tx-fifo-depth: Can Tx fifo depth.
+- rx-fifo-depth: Can Rx fifo depth.
+
+
+Example:
+
+For Zynq CANPS Dts file:
+ zynq_can_0: zynq-can@e0008000 {
+ compatible = "xlnx,zynq-can-1.00.a";
+ clocks = < 19>, < 36>;
+ clock-names = "ref_clk", "aper_clk";
+ reg = <0xe0008000 0x1000>;
+ interrupts = <0 28 4>;
+ interrupt-parent = <>;
+ tx-fifo-depth = <0x40>;
+ rx-fifo-depth = <0x40>;
+ };
+For Axi CAN Dts file:
+ axi_can_0: axi-can@4000 {
+ compatible = "xlnx,axi-can-1.00.a";
+ clocks = < 0>;
+ clock-names = "ref_clk" ;
+ reg = <0x4000 0x1>;
+ interrupt-parent = <>;
+ interrupts = <0 59 1>;
+ tx-fifo-depth = <0x40>;
+ rx-fifo-depth = <0x40>;
+ };
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index 9e7d95d..b180239 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -125,6 +125,13 @@ config CAN_GRCAN
endian syntheses of the cores would need some modifications on
the hardware level to work.
+config CAN_XILINXCAN
+ tristate "Xilinx CAN"
+ depends on ARCH_ZYNQ || MICROBLAZE
+ ---help---
+ Xilinx CAN driver. This driver supports both soft AXI CAN IP and
+ Zynq CANPS IP.
+
source "drivers/net/can/mscan/Kconfig"
source "drivers/net/can/sja1000/Kconfig"
diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
index c744039..0b8e11e 100644
--- a/drivers/net/can/Makefile
+++ b/drivers/net/can/Makefile
@@ -25,5 +25,6 @@ obj-$(CONFIG_CAN_JANZ_ICAN3) += janz-ican3.o
obj-$(CONFIG_CAN_FLEXCAN) += flexcan.o
obj-$(CONFIG_PCH_CAN) += pch_can.o
obj-$(CONFIG_CAN_GRCAN)+= grcan.o
+obj-$(CONFIG_CAN_XILINXCAN)+= xilinx_can.o
ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
new file mode 100644
index 000..642e6b4
--- /dev/null
+++ b/drivers/net/can/xilinx_can.c
@@ -0,0 +1,1153 @@
+/* Xilinx CAN device driver
+ *
+ * Copyright (C) 2012 - 2014 Xilinx, Inc.
+ * Copyright (C) 2009 PetaLogix. All rights reserved.
+ *
+ * Description:
+ * This driver is developed for Axi CAN IP and for Zynq CANPS Controller.
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *
[PATCH v7] mfd: MAX6650/6651 support
MAX6650/MAX6651 chip is a multi-function device with I2C busses. The
chip includes fan-speed regulators and monitors, GPIO, and alarm.
This patch is an initial release of a MAX6650/6651 MFD driver that
supports to enable the chip with its primary I2C bus that will connect
the hwmon, and then the gpio devices for now.
Signed-off-by: Laszlo Papp
---
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile| 1 +
drivers/mfd/max665x.c | 93 +
include/linux/mfd/max665x-private.h | 34 ++
4 files changed, 139 insertions(+)
create mode 100644 drivers/mfd/max665x.c
create mode 100644 include/linux/mfd/max665x-private.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 49bb445..a6c3152 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -368,6 +368,17 @@ config MFD_MAX8907
accessing the device; additional drivers must be enabled in order
to use the functionality of the device.
+config MFD_MAX665X
+ bool "Maxim Semiconductor MAX6650/MAX6651 Support"
+ depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ Say yes here to add support for Maxim Semiconductor MAX6650/MAX6651.
This
+ is a fan speed regulator and monitor IC. This driver provides common
+ support for accessing the device, additional drivers must be enabled
in
+ order to use the functionality of the device.
+
config MFD_MAX8925
bool "Maxim Semiconductor MAX8925 PMIC Support"
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5aea5ef..63668c5 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -111,6 +111,7 @@ obj-$(CONFIG_MFD_DA9055)+= da9055.o
da9063-objs:= da9063-core.o da9063-irq.o da9063-i2c.o
obj-$(CONFIG_MFD_DA9063) += da9063.o
+obj-$(CONFIG_MFD_MAX665X) += max665x.o
obj-$(CONFIG_MFD_MAX14577) += max14577.o
obj-$(CONFIG_MFD_MAX77686) += max77686.o max77686-irq.o
obj-$(CONFIG_MFD_MAX77693) += max77693.o max77693-irq.o
diff --git a/drivers/mfd/max665x.c b/drivers/mfd/max665x.c
new file mode 100644
index 000..54fdc11
--- /dev/null
+++ b/drivers/mfd/max665x.c
@@ -0,0 +1,93 @@
+/*
+ * Device access for MAX6650-MAX6651
+ *
+ * Copyright(c) 2013 Polatis Ltd.
+ *
+ * Author: Laszlo Papp
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+static struct mfd_cell max665x_devs[] = {
+ { .name = "max6651-gpio", },
+ { .name = "max6650", }, /* hwmon driver */
+ {},
+};
+
+static const struct regmap_config max665x_regmap_config = {
+ .reg_bits = 5,
+};
+
+static int max665x_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+ struct max665x_dev *max665x;
+ int ret;
+
+ max665x = devm_kzalloc(>dev, sizeof(*max665x), GFP_KERNEL);
+ if (!max665x)
+ return -ENOMEM;
+
+ i2c_set_clientdata(i2c, max665x);
+ max665x->dev = >dev;
+ max665x->i2c = i2c;
+ max665x->map = devm_regmap_init_i2c(i2c, _regmap_config);
+ if (IS_ERR(max665x->map)) {
+ ret = PTR_ERR(max665x->map);
+ dev_err(max665x->dev, "Failed to allocate register map: %d\n",
+ ret);
+ return ret;
+ }
+
+ mutex_init(>iolock);
+
+ ret = mfd_add_devices(max665x->dev, -1, max665x_devs,
+ ARRAY_SIZE(max665x_devs),
+ NULL, 0, NULL);
+
+ if (ret < 0)
+ dev_err(max665x->dev, "failed to register child devices\n");
+
+ return ret;
+}
+
+static int max665x_remove(struct i2c_client *i2c)
+{
+ struct max665x_dev *max665x = i2c_get_clientdata(i2c);
+
+ mfd_remove_devices(max665x->dev);
+
+ return 0;
+}
+
+static struct of_device_id max665x_dt_match[] = {
+ { .compatible = "maxim,max665x" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, max665x_dt_match);
+
+static struct i2c_driver max665x_driver = {
+ .driver = {
+ .name = "max665x",
+ .owner = THIS_MODULE,
+ .of_match_table = max665x_dt_match,
+ },
+ .probe = max665x_probe,
+ .remove = max665x_remove,
+};
+
+module_i2c_driver(max665x_driver);
+
+MODULE_AUTHOR("Laszlo Papp ");
+MODULE_DESCRIPTION("MAX6650-MAX6651 MFD");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/max665x-private.h
b/include/linux/mfd/max665x-private.h
new file mode 100644
index 000..293db4b
--- /dev/null
+++ b/include/linux/mfd/max665x-private.h
@@ -0,0 +1,34 @@
+/*
+ * max665x-private.h - Driver for the Maxim 6650/6651
+ *
+ *
Re: [PATCH 07/12] mfd: syscon: Consider platform data a regmap config name
Hello. Вторник, 11 февраля 2014, 17:10 UTC от Pawel Moll : > Use the device platform data as a regmap config > name. This is particularly useful in the regmap > debugfs when there is more than one syscon device > registered, to distinguish the register blocks. > > Cc: Samuel Ortiz > Cc: Lee Jones > Signed-off-by: Pawel Moll > --- ... > syscon_regmap_config.max_register = res->end - res->start - 3; > + syscon_regmap_config.name = dev_get_platdata(>dev); Is dev_name(>dev) can be used for such purpose? Thanks. ---
Re: [PATCHv3 1/4] zram: introduce compressing backend abstraction
On Wed, Feb 12, 2014 at 01:21:03AM +0300, Sergey Senozhatsky wrote:
> ZRAM performs direct LZO compression algorithm calls, making it the one
> and only option. Introduce abstract struct zram_comp in order to support
> multiple compression algorithms. struct zram_comp defines the following
> set of compressing backend operations:
> .create
> .destroy
> .compress
> .decompress
>
> Schematically zram write() usually contains the following steps:
> 0) preparation (decompression of partioal IO, etc.)
> 1) lock buffer_lock mutex (protects meta compress buffers)
> 2) compress (using meta compress buffers)
> 3) alloc and map zs_pool object
> 4) copy compressed data (from meta compress buffers) to object allocated by 3)
> 5) free previous pool page, assign a new one
> 6) unlock buffer_lock mutex
>
> As we can see, compressing buffers must remain untouched from 1) to 4),
> because, otherwise, concurrent write() can overwrite data. At the same
> time, zram_meta must be aware of a) specific compression algorithm
> memory requirements and b) necessary locking to protect compression
> buffers. Besides, zram holds buffer_lock almost through the whole write()
> function, making parallel compression impossible. To remove requirement
> a) new struct zcomp_workmem introduced, which contain buffers required by
> compression algorithm. While struct zram_comp implements workmem handling
> and locking by means of get() and put() semantics and removes requirement
> b) from zram meta. zram_comp ->create() and ->destroy(), respectively,
> allocate and deallocate algorithm specific zcomp_workmem `private' buffer.
>
> Every zram_comp has a list of idle workmem buffers (at least 1 workmem),
> spinlock to protect idle list and wait queue, making it possible to perform
> parallel compressions. Each time zram issues a zcomp_workmem_get() call, the
> following set of operations performed:
> - spin lock buffer_lock
> - if idle list is not empty, remove workmem from idle list, spin
> unlock and return workmem pointer
> - if idle list is empty, current adds itself to wait queue. it will be
> awaken by zcomp_workmem_put() caller.
>
> zcomp_workmem_put():
> - spin lock buffer_lock
> - add workmem to idle list
> - spin unlock, wake up sleeper (if any)
>
> In other words, zcomp_workmem_get() turns caller into exclusive user of
> workmem
> and zcomp_workem_put() makes a particular workmem available.
>
> Usage examples.
>
> To initialize compressing backend:
> comp = zcomp_create(NAME) /* NAME e.g. lzo */
>
> which initialises compressing backend if requested algorithm is supported.
>
> Compress:
> wm = zcomp_workmem_get(comp)
> zcomp_compress(comp, wm, src, src_len, _len)
> [..] /* copy compressed data */
> zcomp_workmem_put(comp, wm)
>
> Decompress:
> zcomp_decompress(comp, src, src_len, dst, _len);
>
> Free compessing backend and its workmem:
> zcomp_destroy(comp)
>
> Signed-off-by: Sergey Senozhatsky
> ---
> drivers/block/zram/zcomp_lzo.c | 33 +
> drivers/block/zram/zram_comp.c | 147
> +
> drivers/block/zram/zram_comp.h | 58
> 3 files changed, 238 insertions(+)
> create mode 100644 drivers/block/zram/zcomp_lzo.c
> create mode 100644 drivers/block/zram/zram_comp.c
> create mode 100644 drivers/block/zram/zram_comp.h
>
> diff --git a/drivers/block/zram/zcomp_lzo.c b/drivers/block/zram/zcomp_lzo.c
> new file mode 100644
> index 000..bbde74e
> --- /dev/null
> +++ b/drivers/block/zram/zcomp_lzo.c
> @@ -0,0 +1,33 @@
> +/*
> + * Copyright (C) 2014 Sergey Senozhatsky.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "zram_comp.h"
> +
> +static void * lzo_create(void)
> +{
> + return kmalloc(LZO1X_MEM_COMPRESS, GFP_KERNEL);
> +}
> +
> +static void lzo_destroy(void *workmem)
> +{
> + kfree(workmem);
> +}
> +
> +extern struct zram_comp_backend zcomp_lzo;
> +struct zram_comp_backend zcomp_lzo = {
> + .compress = lzo1x_1_compress,
> + .decompress = lzo1x_decompress_safe,
> + .create = lzo_create,
> + .destroy = lzo_destroy,
> + .name = "lzo",
> +};
> diff --git a/drivers/block/zram/zram_comp.c b/drivers/block/zram/zram_comp.c
> new file mode 100644
> index 000..139a468
> --- /dev/null
> +++ b/drivers/block/zram/zram_comp.c
> @@ -0,0 +1,147 @@
> +/*
> + * Copyright (C) 2014 Sergey Senozhatsky.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +
>
Re: [GIT PULL] x86, apic: Remove support for Summit and ES7000
* H. Peter Anvin wrote: > On 02/11/2014 06:53 PM, David Rientjes wrote: > > Hi Ingo, Peter, and Thomas, > > > > [ Be aware of bouncing emails on the cc, it includes the last-known email > >addresses of the authors of these subarchitectures and may bounce. ] > > > > If you agree, please pull from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rientjes/linux.git x86/apic > > > > # HEAD: 7cf6c94591bbf3dbe3bf9573a6551328ad76d885 x86, apic: Remove > > support for IBM Summit/EXA chipset > > > > or apply individually. This branch is based on x86/apic. > > > > This is the removal of Summit and ES7000 subarchitectures from x86. I'd > > like to do the same for NumaQ, but am still researching if we can really > > do away with it. > > Nice. I'm fine with this too. 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: [tip:sched/core] sched: Push put_prev_task() into pick_next_task( )
11.02.2014, 16:17, "tip-bot for Peter Zijlstra" :
> Commit-ID: 606dba2e289446600a0b68422ed2019af5355c12
> Gitweb: http://git.kernel.org/tip/606dba2e289446600a0b68422ed2019af5355c12
> Author: Peter Zijlstra
> AuthorDate: Sat, 11 Feb 2012 06:05:00 +0100
> Committer: Ingo Molnar
> CommitDate: Mon, 10 Feb 2014 16:17:13 +0100
>
> sched: Push put_prev_task() into pick_next_task()
>
> In order to avoid having to do put/set on a whole cgroup hierarchy
> when we context switch, push the put into pick_next_task() so that
> both operations are in the same function. Further changes then allow
> us to possibly optimize away redundant work.
>
> Signed-off-by: Peter Zijlstra
> Link: http://lkml.kernel.org/r/1328936700.2476.17.camel@laptop
> Signed-off-by: Ingo Molnar
> ---
> kernel/sched/core.c | 21 -
> kernel/sched/deadline.c | 5 -
> kernel/sched/fair.c | 6 +-
> kernel/sched/idle_task.c | 6 +-
> kernel/sched/rt.c | 27 ---
> kernel/sched/sched.h | 8 +++-
> kernel/sched/stop_task.c | 16 ++--
> 7 files changed, 55 insertions(+), 34 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 417cf65..dedb5f0 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2579,18 +2579,11 @@ static inline void schedule_debug(struct task_struct
> *prev)
> schedstat_inc(this_rq(), sched_count);
> }
>
> -static void put_prev_task(struct rq *rq, struct task_struct *prev)
> -{
> - if (prev->on_rq || rq->skip_clock_update < 0)
> - update_rq_clock(rq);
> - prev->sched_class->put_prev_task(rq, prev);
> -}
> -
> /*
> * Pick up the highest-prio task:
> */
> static inline struct task_struct *
> -pick_next_task(struct rq *rq)
> +pick_next_task(struct rq *rq, struct task_struct *prev)
> {
> const struct sched_class *class;
> struct task_struct *p;
> @@ -2600,13 +2593,13 @@ pick_next_task(struct rq *rq)
> * the fair class we can call that function directly:
> */
> if (likely(rq->nr_running == rq->cfs.h_nr_running)) {
> - p = fair_sched_class.pick_next_task(rq);
> + p = fair_sched_class.pick_next_task(rq, prev);
> if (likely(p))
> return p;
> }
>
> for_each_class(class) {
> - p = class->pick_next_task(rq);
> + p = class->pick_next_task(rq, prev);
> if (p)
> return p;
> }
> @@ -2714,8 +2707,10 @@ need_resched:
> rq->idle_stamp = 0;
> }
>
> - put_prev_task(rq, prev);
> - next = pick_next_task(rq);
> + if (prev->on_rq || rq->skip_clock_update < 0)
> + update_rq_clock(rq);
> +
> + next = pick_next_task(rq, prev);
> clear_tsk_need_resched(prev);
> clear_preempt_need_resched();
> rq->skip_clock_update = 0;
> @@ -4748,7 +4743,7 @@ static void migrate_tasks(unsigned int dead_cpu)
> if (rq->nr_running == 1)
> break;
>
> - next = pick_next_task(rq);
> + next = pick_next_task(rq, NULL);
pick_next_task() firstly checks for prev->sched_class, doesn't it ???
The same for pick_next_task_rt().
> BUG_ON(!next);
> next->sched_class->put_prev_task(rq, next);
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index b5700bc..50797d5 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -990,7 +990,7 @@ static struct sched_dl_entity *pick_next_dl_entity(struct
> rq *rq,
> return rb_entry(left, struct sched_dl_entity, rb_node);
> }
>
> -struct task_struct *pick_next_task_dl(struct rq *rq)
> +struct task_struct *pick_next_task_dl(struct rq *rq, struct task_struct
> *prev)
> {
> struct sched_dl_entity *dl_se;
> struct task_struct *p;
> @@ -1001,6 +1001,9 @@ struct task_struct *pick_next_task_dl(struct rq *rq)
> if (unlikely(!dl_rq->dl_nr_running))
> return NULL;
>
> + if (prev)
> + prev->sched_class->put_prev_task(rq, prev);
> +
> dl_se = pick_next_dl_entity(rq, dl_rq);
> BUG_ON(!dl_se);
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 748a7ac..c4bb0ac 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4655,7 +4655,8 @@ preempt:
> set_last_buddy(se);
> }
>
> -static struct task_struct *pick_next_task_fair(struct rq *rq)
> +static struct task_struct *
> +pick_next_task_fair(struct rq *rq, struct task_struct *prev)
> {
> struct task_struct *p;
> struct cfs_rq *cfs_rq = >cfs;
> @@ -4664,6 +4665,9 @@ static struct task_struct *pick_next_task_fair(struct
> rq *rq)
> if (!cfs_rq->nr_running)
> return NULL;
>
> + if (prev)
> + prev->sched_class->put_prev_task(rq, prev);
> +
> do {
> se = pick_next_entity(cfs_rq);
> set_next_entity(cfs_rq, se);
> diff --git
Re: [PATCH v6] mfd: MAX6650/6651 support
On Wed, Feb 12, 2014 at 4:42 AM, Sachin Kamat wrote:
> Hi Laszlo,
>
> Sorry for missing out on a couple of points during my earlier review.
> Please see inline.
Np.
> On 12 February 2014 09:32, Laszlo Papp wrote:
>> MAX6650/MAX6651 chip is a multi-function device with I2C busses. The
>> chip includes fan-speed regulators and monitors, GPIO, and alarm.
>>
>> This patch is an initial release of a MAX6650/6651 MFD driver that
>> supports to enable the chip with its primary I2C bus that will connect
>> the hwmon, and then the gpio devices for now.
>>
>> Signed-off-by: Laszlo Papp
>> ---
> [snip]
>
>> --- /dev/null
>> +++ b/drivers/mfd/max665x.c
>> @@ -0,0 +1,87 @@
>> +/*
>> + * Device access for MAX6650-MAX6651
>> + *
>> + * Copyright(c) 2013 Polatis Ltd.
>> + *
>> + * Author: Laszlo Papp
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +static struct mfd_cell max665x_devs[] = {
>> + { .name = "max6651-gpio", },
>> + { .name = "max6650", }, /* hwmon driver */
>> + {},
>> +};
>> +
>> +const struct regmap_config max665x_regmap_config = {
>> + .reg_bits = 5,
>> +};
>
> This should be static.
Agree.
>> +static int max665x_probe(struct i2c_client *i2c,
>> + const struct i2c_device_id *id)
>> +{
>> + struct max665x_dev *max665x;
>> + int ret;
>> +
>> + max665x = devm_kzalloc(>dev, sizeof(*max665x), GFP_KERNEL);
>> + if (!max665x)
>> + return -ENOMEM;
>> +
>> + i2c_set_clientdata(i2c, max665x);
>> + max665x->dev = >dev;
>> + max665x->i2c = i2c;
>> + max665x->map = devm_regmap_init_i2c(i2c, _regmap_config);
>
> Don't you need to check the return value of devm_regmap_init_i2c?
I personally think I should. I strived for consistency though with
other similar drivers. After this many reviews about such things, it
seems that consistency matters here less than other projects which I
can cope with, 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 v2] cgroup: protect modifications to cgroup->idr with cgroup_mutex
On 2014/2/12 14:37, Tejun Heo wrote: > Hello, Li. > > On Wed, Feb 12, 2014 at 02:28:53PM +0800, Li Zefan wrote: >> v2: >> - Don't call deactivate_super() inside cgroup_mutex, as cgroup_kill_sb() >> will be called if sb refcnt reaches 0. I don't think this can happen, >> as cgroup_create() is called through vfs, so vfs should guarantee the >> superblock won't disappear. Still better not depend on it even my guess >> is probably correct. > > If the deadlock can't actually happen, I don't really care either way > as the code goes away after kernfs conversion anyway. I've already > applied v1, so if you think this change is important, can you send an > incremental patch? > I'm fine to stick with V1. I'm pretty confident it's safe, as we can increment sb refcnt without any checking or locking (even cgroup_mutex as the comment says) in cgroup_create(). -- 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: 3.14-rc2 XFS backtrace because irqs_disabled.
On Tue, Feb 11, 2014 at 10:31 PM, Dave Chinner wrote: > > FYI, just creating lots of files with open(O_CREAT): > > [ 348.718357] fs_mark (4828) used greatest stack depth: 2968 bytes left > [ 348.769846] fs_mark (4814) used greatest stack depth: 2312 bytes left > [ 349.17] fs_mark (4826) used greatest stack depth: 2280 bytes left > [ 418.139415] fs_mark (4928) used greatest stack depth: 1936 bytes left > [ 460.492282] fs_mark (4993) used greatest stack depth: 1336 bytes left > [ 544.825418] fs_mark (5104) used greatest stack depth: 1112 bytes left > [ 689.503970] fs_mark (5265) used greatest stack depth: 1000 bytes left > > We've got absolutely no spare stack space anymore in the IO path. > And the IO path can't get much simpler than filesystem -> virtio > block device. Ugh, that's bad. A thousand bytes of stack space is much too close to any limits. Do you have the stack traces for these things so that we can look at worst offenders? If the new block-mq code is to blame, it needs to be fixed. __virtblk_add_req() has a 300-byte stack frame, it seems. Looking elsewhere, blkdev_issue_discard() has 350 bytes of stack frame, but is hopefully not in any normal path - online discard is moronic, and I'm assuming XFS doesn't do that. There's a lot of 200+ byte stack frames in block/blk-core.s, and they all seem to be of the type perf_trace_block_buffer() - things created with DECLARE_EVENT_CLASS(), afaik. Why they all have 200+ bytes of frame, I have no idea. That sounds like a potential disaster too, although hopefully it's mostly leaf functions - but leaf functions *deep* in the callchain. Tejun? Steven, why _do_ they end up with such huge frames? And if the stack use comes from the VFS layer, we can probably work on that too. But I don't think that has really changed much lately.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] video: Use fb_sys_write rather than open-coding in drivers
On 12/02/14 19:54, Tomi Valkeinen wrote: > On 11/02/14 21:07, Ryan Mallon wrote: >> On 12/02/14 03:06, Tomi Valkeinen wrote: >> >>> On 20/09/13 10:06, Ryan Mallon wrote: Several video drivers open code the fb_write write function with code which is very similar to fb_sys_write. Replace the open code versions with calls to fb_sys_write. An fb_sync callback is added to each of the drivers. Signed-off-by: Ryan Mallon --- >>> >>> Doesn't this change the behavior so that fb_write does no longer update >>> the display, but fb_sync does? I don't think fb_sync is even meant to >>> update the display, it's meant to wait for an update to finish. Then >>> again, I'm not sure about that, all I see in fb.h is "wait for blit >>> idle, optional" >> >> >> fb_write() in fbmem.c calls ->fb_sync() after ->fb_write(), and I've set >> the fb_sync() for each of the drivers, so the behaviour should be >> unchanged for writes. >> >> The fb_sync() function is also called by fb_read() and >> fb_get_buffer_offset() (if FB_PIXMAP_SYNC flag is set). I don't know if >> that will adversely affect behaviour. > > Well, by just looking at the function names the drivers' fb_syncs call, > it sounds to me that with your patch fb_sync will update the LCD, i.e. > send data to it. Doing that in fb_read sounds totally wrong. Well, the alternative is to supply an fb_write() implementation for each driver that calls fb_sys_write(), and then updates the display. The fb_sync() additions can be removed. That would cut down the boiler-plate code, and should keep the behaviour the same. If you don't think it is worth the effort, then the patch can just be dropped. ~Ryan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/1] drm/i915: Add 180 degree sprite rotation support
From: Ville Syrjälä
The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.
The upper layers are not yet plugged in.
v2: HSW handles the rotated buffer offset automagically
v3: BDW also handles the rotated buffer offset automagically
Testcase: igt/kms_plane_rotation_crc
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ville Syrjälä
Signed-off-by: Sagar Kamble
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_drv.h| 1 +
drivers/gpu/drm/i915/intel_sprite.c | 37 +
3 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index abd18cd..57906c5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3637,6 +3637,7 @@
#define DVS_YUV_ORDER_UYVY (1<<16)
#define DVS_YUV_ORDER_YVYU (2<<16)
#define DVS_YUV_ORDER_VYUY (3<<16)
+#define DVS_ROTATE_180 (1<<15)
#define DVS_DEST_KEY (1<<2)
#define DVS_TRICKLE_FEED_DISABLE (1<<14)
#define DVS_TILED(1<<10)
@@ -3707,6 +3708,7 @@
#define SPRITE_YUV_ORDER_UYVY(1<<16)
#define SPRITE_YUV_ORDER_YVYU(2<<16)
#define SPRITE_YUV_ORDER_VYUY(3<<16)
+#define SPRITE_ROTATE_180(1<<15)
#define SPRITE_TRICKLE_FEED_DISABLE (1<<14)
#define SPRITE_INT_GAMMA_ENABLE (1<<13)
#define SPRITE_TILED (1<<10)
@@ -3780,6 +3782,7 @@
#define SP_YUV_ORDER_UYVY(1<<16)
#define SP_YUV_ORDER_YVYU(2<<16)
#define SP_YUV_ORDER_VYUY(3<<16)
+#define SP_ROTATE_180(1<<15)
#define SP_TILED (1<<10)
#define _SPALINOFF (VLV_DISPLAY_BASE + 0x72184)
#define _SPASTRIDE (VLV_DISPLAY_BASE + 0x72188)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 44067bc..85864fc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -397,6 +397,7 @@ struct intel_plane {
unsigned int crtc_w, crtc_h;
uint32_t src_x, src_y;
uint32_t src_w, src_h;
+ unsigned int rotation;
/* Since we need to change the watermarks before/after
* enabling/disabling the planes, we need to store the parameters here
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 336ae6c..2076878 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -60,6 +60,7 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc
*crtc,
sprctl &= ~SP_PIXFORMAT_MASK;
sprctl &= ~SP_YUV_BYTE_ORDER_MASK;
sprctl &= ~SP_TILED;
+ sprctl &= ~SP_ROTATE_180;
switch (fb->pixel_format) {
case DRM_FORMAT_YUYV:
@@ -131,6 +132,14 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc
*crtc,
fb->pitches[0]);
linear_offset -= sprsurf_offset;
+ if (intel_plane->rotation == BIT(DRM_ROTATE_180)) {
+ sprctl |= SP_ROTATE_180;
+
+ x += src_w;
+ y += src_h;
+ linear_offset += src_h * fb->pitches[0] + src_w * pixel_size;
+ }
+
I915_WRITE(SPSTRIDE(pipe, plane), fb->pitches[0]);
I915_WRITE(SPPOS(pipe, plane), (crtc_y << 16) | crtc_x);
@@ -238,6 +247,7 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
sprctl &= ~SPRITE_RGB_ORDER_RGBX;
sprctl &= ~SPRITE_YUV_BYTE_ORDER_MASK;
sprctl &= ~SPRITE_TILED;
+ sprctl &= ~SPRITE_ROTATE_180;
switch (fb->pixel_format) {
case DRM_FORMAT_XBGR:
@@ -299,6 +309,17 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
pixel_size, fb->pitches[0]);
linear_offset -= sprsurf_offset;
+ if (intel_plane->rotation == BIT(DRM_ROTATE_180)) {
+ sprctl |= SPRITE_ROTATE_180;
+
+ /* HSW and BDW does this automagically in hardware */
+ if (!IS_HASWELL(dev) && !IS_BROADWELL(dev)) {
+ x += src_w;
+ y += src_h;
+ linear_offset += src_h * fb->pitches[0] + src_w *
pixel_size;
+ }
+ }
+
I915_WRITE(SPRSTRIDE(pipe), fb->pitches[0]);
I915_WRITE(SPRPOS(pipe), (crtc_y << 16) | crtc_x);
@@ -422,6 +443,7 @@ ilk_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
dvscntr &= ~DVS_RGB_ORDER_XBGR;
dvscntr &= ~DVS_YUV_BYTE_ORDER_MASK;
dvscntr &= ~DVS_TILED;
+ dvscntr &= ~DVS_ROTATE_180;
switch (fb->pixel_format) {
case
Re: [PATCH] ARM: mm: support big-endian page tables
On 2014/2/11 18:40, Ben Dooks wrote:
> On 11/02/14 09:20, Jianguo Wu wrote:
>> When enable LPAE and big-endian in a hisilicon board, while specify
>> mem=384M mem=512M@7680M, will get bad page state:
>>
>> Freeing unused kernel memory: 180K (c0466000 - c0493000)
>> BUG: Bad page state in process init pfn:fa442
>> page:c7749840 count:0 mapcount:-1 mapping: (null) index:0x0
>> page flags: 0x4400(reserved)
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: init Not tainted 3.10.27+ #66
>> [] (unwind_backtrace+0x0/0x11c) from []
>> (show_stack+0x10/0x14)
>> [] (show_stack+0x10/0x14) from [] (bad_page+0xd4/0x104)
>> [] (bad_page+0xd4/0x104) from []
>> (free_pages_prepare+0xa8/0x14c)
>> [] (free_pages_prepare+0xa8/0x14c) from []
>> (free_hot_cold_page+0x18/0xf0)
>> [] (free_hot_cold_page+0x18/0xf0) from []
>> (handle_pte_fault+0xcf4/0xdc8)
>> [] (handle_pte_fault+0xcf4/0xdc8) from []
>> (handle_mm_fault+0xf4/0x120)
>> [] (handle_mm_fault+0xf4/0x120) from []
>> (do_page_fault+0xfc/0x354)
>> [] (do_page_fault+0xfc/0x354) from []
>> (do_DataAbort+0x2c/0x90)
>> [] (do_DataAbort+0x2c/0x90) from []
>> (__dabt_usr+0x34/0x40)
>>
>> The bad pfn:fa442 is not system memory(mem=384M mem=512M@7680M), after
>> debugging,
>> I find in page fault handler, will get wrong pfn from pte just after set pte,
>> as follow:
>> do_anonymous_page()
>> {
>> ...
>> set_pte_at(mm, address, page_table, entry);
>>
>> //debug code
>> pfn = pte_pfn(entry);
>> pr_info("pfn:0x%lx, pte:0x%llx\n", pfn, pte_val(entry));
>>
>> //read out the pte just set
>> new_pte = pte_offset_map(pmd, address);
>> new_pfn = pte_pfn(*new_pte);
>> pr_info("new pfn:0x%lx, new pte:0x%llx\n", pfn, pte_val(entry));
>> ...
>> }
>
> Thanks, must have missed tickling this one.
>
>>
>> pfn: 0x1fa4f5, pte:0xc1fa4f575f
>> new_pfn:0xfa4f5, new_pte:0xc0fa4f5f5f//new pfn/pte is wrong.
>>
>> The bug is happened in cpu_v7_set_pte_ext(ptep, pte):
>> when pte is 64-bit, for little-endian, will store low 32-bit in r2,
>> high 32-bit in r3; for big-endian, will store low 32-bit in r3,
>> high 32-bit in r2, this will cause wrong pfn stored in pte,
>> so we should exchange r2 and r3 for big-endian.
>>
>> Signed-off-by: Jianguo Wu
>> ---
>> arch/arm/mm/proc-v7-3level.S | 10 ++
>> 1 files changed, 10 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S
>> index 6ba4bd9..71b3892 100644
>> --- a/arch/arm/mm/proc-v7-3level.S
>> +++ b/arch/arm/mm/proc-v7-3level.S
>> @@ -65,6 +65,15 @@ ENDPROC(cpu_v7_switch_mm)
>>*/
>> ENTRY(cpu_v7_set_pte_ext)
>> #ifdef CONFIG_MMU
>> +#ifdef CONFIG_CPU_ENDIAN_BE8
>> +tstr3, #L_PTE_VALID
>> +beq1f
>> +tstr2, #1 << (57 - 32)@ L_PTE_NONE
>> +bicner3, #L_PTE_VALID
>> +bne1f
>> +tstr2, #1 << (55 - 32)@ L_PTE_DIRTY
>> +orreqr3, #L_PTE_RDONLY
>> +#else
>> tstr2, #L_PTE_VALID
>> beq1f
>> tstr3, #1 << (57 - 32)@ L_PTE_NONE
>> @@ -72,6 +81,7 @@ ENTRY(cpu_v7_set_pte_ext)
>> bne1f
>> tstr3, #1 << (55 - 32)@ L_PTE_DIRTY
>> orreqr2, #L_PTE_RDONLY
>> +#endif
>> 1:strdr2, r3, [r0]
>> ALT_SMP(W(nop))
>> ALT_UP (mcrp15, 0, r0, c7, c10, 1)@ flush_pte
>> -- 1.7.1
>
> If possible can we avoid large #ifdef blocks here?
>
> Two ideas are
>
> ARM_LE(tst r2, #L_PTE_VALID)
> ARM_BE(tst r3, #L_PTE_VALID)
>
> or change r2, r3 pair to say rlow, rhi and
>
> #ifdef CONFIG_CPU_ENDIAN_BE8
> #define rlow r3
> #define rhi r2
> #else
> #define rlow r2
> #define rhi r3
> #endif
>
Hi Ben,
Thanks for your suggestion, how about this?
Signed-off-by: Jianguo Wu
---
arch/arm/mm/proc-v7-3level.S | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S
index 01a719e..22e3ad6 100644
--- a/arch/arm/mm/proc-v7-3level.S
+++ b/arch/arm/mm/proc-v7-3level.S
@@ -64,6 +64,14 @@ ENTRY(cpu_v7_switch_mm)
mov pc, lr
ENDPROC(cpu_v7_switch_mm)
+#ifdef __ARMEB__
+#define rl r3
+#define rh r2
+#else
+#define rl r2
+#define rh r3
+#endif
+
/*
* cpu_v7_set_pte_ext(ptep, pte)
*
@@ -73,13 +81,13 @@ ENDPROC(cpu_v7_switch_mm)
*/
ENTRY(cpu_v7_set_pte_ext)
#ifdef CONFIG_MMU
- tst r2, #L_PTE_VALID
+ tst rl, #L_PTE_VALID
beq 1f
- tst r3, #1 << (57 - 32) @ L_PTE_NONE
- bicne r2, #L_PTE_VALID
+ tst rh, #1 << (57 - 32) @ L_PTE_NONE
+ bicne rl, #L_PTE_VALID
bne 1f
- tst r3, #1 << (55 - 32) @ L_PTE_DIRTY
- orreq r2, #L_PTE_RDONLY
+ tst rh, #1 << (55 - 32) @ L_PTE_DIRTY
+ orreq rl, #L_PTE_RDONLY
1: strdr2, r3, [r0]
ALT_SMP(W(nop))
ALT_UP (mcr p15, 0, r0, c7, c10, 1) @ flush_pte
--
Re: [RFC PATCH] video: Use fb_sys_write rather than open-coding in drivers
On 11/02/14 21:07, Ryan Mallon wrote: > On 12/02/14 03:06, Tomi Valkeinen wrote: > >> On 20/09/13 10:06, Ryan Mallon wrote: >>> Several video drivers open code the fb_write write function with code >>> which is very similar to fb_sys_write. Replace the open code versions >>> with calls to fb_sys_write. An fb_sync callback is added to each of >>> the drivers. >>> >>> Signed-off-by: Ryan Mallon >>> --- >> >> Doesn't this change the behavior so that fb_write does no longer update >> the display, but fb_sync does? I don't think fb_sync is even meant to >> update the display, it's meant to wait for an update to finish. Then >> again, I'm not sure about that, all I see in fb.h is "wait for blit >> idle, optional" > > > fb_write() in fbmem.c calls ->fb_sync() after ->fb_write(), and I've set > the fb_sync() for each of the drivers, so the behaviour should be > unchanged for writes. > > The fb_sync() function is also called by fb_read() and > fb_get_buffer_offset() (if FB_PIXMAP_SYNC flag is set). I don't know if > that will adversely affect behaviour. Well, by just looking at the function names the drivers' fb_syncs call, it sounds to me that with your patch fb_sync will update the LCD, i.e. send data to it. Doing that in fb_read sounds totally wrong. > Note that I haven't actually tested this code since I don't have any of > the hardware. It was just something I noticed while digging through > framebuffer driver code. Ok. Well, I think it's safer to drop these, then, if it's not 100% clear that there are no unwanted side effects. Tomi signature.asc Description: OpenPGP digital signature
[PATCH v6 1/1] drm/i915: Add 180 degree primary plane rotation support
From: Sagar Kamble
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.
v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.
v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.
v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.
Testcase: igt/kms_plane_rotation_crc
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: vijay.a.purushotha...@intel.com
Signed-off-by: Uma Shankar
Signed-off-by: Sagar Kamble
---
drivers/gpu/drm/i915/i915_dma.c | 17 +++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 86 ++--
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_pm.c | 8
5 files changed, 110 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 258b1be..19e22a2 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1836,6 +1836,8 @@ int i915_driver_open(struct drm_device *dev, struct
drm_file *file)
void i915_driver_lastclose(struct drm_device * dev)
{
drm_i915_private_t *dev_priv = dev->dev_private;
+ struct intel_crtc *crtc;
+ struct intel_plane *plane;
/* On gen6+ we refuse to init without kms enabled, but then the drm core
* goes right around and calls lastclose. Check for this and don't clean
@@ -1843,6 +1845,21 @@ void i915_driver_lastclose(struct drm_device * dev)
if (!dev_priv)
return;
+ if (dev_priv->rotation_property) {
+ list_for_each_entry(crtc, >mode_config.crtc_list,
base.head) {
+ crtc->rotation = BIT(DRM_ROTATE_0);
+ drm_object_property_set_value(>base.base,
+ dev_priv->rotation_property,
+ crtc->rotation);
+ }
+ list_for_each_entry(plane, >mode_config.plane_list,
base.head) {
+ plane->rotation = BIT(DRM_ROTATE_0);
+ drm_object_property_set_value(>base.base,
+ dev_priv->rotation_property,
+ plane->rotation);
+ }
+ }
+
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
intel_fbdev_restore_mode(dev);
vga_switcheroo_process_delayed_switch();
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 57906c5..d3000c4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3553,6 +3553,7 @@
#define DISPPLANE_NO_LINE_DOUBLE 0
#define DISPPLANE_STEREO_POLARITY_FIRST 0
#define DISPPLANE_STEREO_POLARITY_SECOND (1<<18)
+#define DISPPLANE_ROTATE_180 (1<<15)
#define DISPPLANE_TRICKLE_FEED_DISABLE (1<<14) /* Ironlake */
#define DISPPLANE_TILED (1<<10)
#define _DSPAADDR (dev_priv->info->display_mmio_offset + 0x70184)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4d4a0d9..f6fee29 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2037,6 +2037,7 @@ static int i9xx_update_plane(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
unsigned long linear_offset;
u32 dspcntr;
u32 reg;
+ int pixel_size;
switch (plane) {
case 0:
@@ -2047,6 +2048,7 @@ static int i9xx_update_plane(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
return -EINVAL;
}
+ pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb->obj;
@@ -2054,6 +2056,8 @@ static int i9xx_update_plane(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
dspcntr = I915_READ(reg);
/* Mask out pixel format bits in case we change it */
dspcntr &= ~DISPPLANE_PIXFORMAT_MASK;
+ dspcntr &=
Re: [PATCH 7/9] sys: Replace hardcoding of -20 and 19 with MIN_NICE and MAX_NICE.
On Tue, Feb 11, 2014 at 7:59 PM, Dongsheng Yang wrote: > Hi Kees, > > > On 02/12/2014 02:27 AM, Kees Cook wrote: >> >> On Mon, Feb 10, 2014 at 11:34 PM, Dongsheng Yang >> wrote: >>> >>> Signed-off-by: Dongsheng Yang >>> cc: Andrew Morton >>> cc: Oleg Nesterov >>> cc: Robin Holt >>> cc: Al Viro >>> cc: Kees Cook >>> cc: "Eric W. Biederman" >>> cc: Stephen Rothwell >>> cc: Peter Zijlstra >>> cc: Ingo Molnar >>> --- >>> kernel/sys.c | 8 >>> 1 file changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/kernel/sys.c b/kernel/sys.c >>> index c0a58be..adaeab6 100644 >>> --- a/kernel/sys.c >>> +++ b/kernel/sys.c >>> @@ -174,10 +174,10 @@ SYSCALL_DEFINE3(setpriority, int, which, int, who, >>> int, niceval) >>> >>> /* normalize: avoid signed division (rounding problems) */ >>> error = -ESRCH; >>> - if (niceval < -20) >>> - niceval = -20; >>> - if (niceval > 19) >>> - niceval = 19; >>> + if (niceval < MIN_NICE) >>> + niceval = MIN_NICE; >>> + if (niceval > MAX_NICE) >>> + niceval = MAX_NICE; >> >> Good catch! I'm all for using names instead of numeric values, >> however, I wonder if it'd be more readable to use "clamp" instead? >> >> niceval = clamp(niceval, MIN_NICE, MAX_NICE); > > > Good suggestion! This patch here is just to replace the numeric values with > a name defined in prio.h. So I will send another patch to make it more > readable > with clamp after the patch set here applied. Is this plan ok to you? Sounds good to me. Thanks! -Kees > > Thanx. > >> >> -Kees >> >>> rcu_read_lock(); >>> read_lock(_lock); >>> -- >>> 1.8.2.1 >>> >> >> > -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the final tree (cgroup tree related)
Hello,
On Wed, Feb 12, 2014 at 04:25:00PM +1100, Stephen Rothwell wrote:
> Presumably caused by commit 2bd59d48ebfb ("cgroup: convert to kernfs")
> (see the comment in commit 1ff6bbfd13ca ("arm, pm, vmpressure: add
> missing slab.h includes")). I wonder how mane more builds are broken by
> this :-(
Dang, I was feeling pretty safe as kbuild bot was reporting build
successes. We better fix them at any rate. David / Sam, can you
please pick this one up?
Thanks.
--
tejun
--
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] cgroup: protect modifications to cgroup->idr with cgroup_mutex
Hello, Li. On Wed, Feb 12, 2014 at 02:28:53PM +0800, Li Zefan wrote: > v2: > - Don't call deactivate_super() inside cgroup_mutex, as cgroup_kill_sb() > will be called if sb refcnt reaches 0. I don't think this can happen, > as cgroup_create() is called through vfs, so vfs should guarantee the > superblock won't disappear. Still better not depend on it even my guess > is probably correct. If the deadlock can't actually happen, I don't really care either way as the code goes away after kernfs conversion anyway. I've already applied v1, so if you think this change is important, can you send an incremental patch? Thanks! -- tejun -- 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: 3.14-rc2 XFS backtrace because irqs_disabled.
On Wed, Feb 12, 2014 at 05:10:38PM +1100, Dave Chinner wrote: > On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote: > > On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote: > > > > > None of the XFS code disables interrupts in that path, not does is > > > call outside XFS except to dispatch IO. The stack is pretty deep at > > > this point and I know that the standard (non stacked) IO stack can > > > consume >3kb of stack space when it gets down to having to do memory > > > reclaim during GFP_NOIO allocation at the lowest level of SCSI > > > drivers. Stack overruns typically show up with symptoms like we are > > > seeing. > > > .. > > > > > > Dave, before chasing ghosts, can you (like Eric originally asked) > > > turn on stack overrun detection? > > > > CONFIG_DEBUG_STACKOVERFLOW ? Already turned on. > > That only checks stack usage when an interrupt is taken. If no > interrupts are taken when stack usage is within 128 bytes of > overflow, then it doesn't catch it. > > I tend to use CONFIG_DEBUG_STACK_USAGE=y as it records the maximum > stack usage of a process via canary overwrites and it records it in > do_exit(). I also use the stack tracer to record the largest stack > usage seen so I know exactly what code paths are approaching stack > overruns... FYI, just creating lots of files with open(O_CREAT): [ 348.718357] fs_mark (4828) used greatest stack depth: 2968 bytes left [ 348.769846] fs_mark (4814) used greatest stack depth: 2312 bytes left [ 349.17] fs_mark (4826) used greatest stack depth: 2280 bytes left [ 418.139415] fs_mark (4928) used greatest stack depth: 1936 bytes left [ 460.492282] fs_mark (4993) used greatest stack depth: 1336 bytes left [ 544.825418] fs_mark (5104) used greatest stack depth: 1112 bytes left [ 689.503970] fs_mark (5265) used greatest stack depth: 1000 bytes left We've got absolutely no spare stack space anymore in the IO path. And the IO path can't get much simpler than filesystem -> virtio block device. Cheers, Dave. -- Dave Chinner da...@fromorbit.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/
[PATCH v2] cgroup: protect modifications to cgroup->idr with cgroup_mutex
Setup cgroupfs like this:
# mount -t cgroup -o cpuacct xxx /cgroup
# mkdir /cgroup/sub1
# mkdir /cgroup/sub2
Then run these two commands:
# for ((; ;)) { mkdir /cgroup/sub1/tmp && rmdir /cgroup/sub1/tmp; } &
# for ((; ;)) { mkdir /cgroup/sub2/tmp && rmdir /cgroup/sub2/tmp; } &
After seconds you may see this warning:
[ cut here ]
WARNING: CPU: 1 PID: 25243 at lib/idr.c:527 sub_remove+0x87/0x1b0()
idr_remove called for id=6 which is not allocated.
...
Call Trace:
[] dump_stack+0x7a/0x96
[] warn_slowpath_common+0x8c/0xc0
[] warn_slowpath_fmt+0x46/0x50
[] sub_remove+0x87/0x1b0
[] ? css_killed_work_fn+0x32/0x1b0
[] idr_remove+0x25/0xd0
[] cgroup_destroy_css_killed+0x5b/0xc0
[] css_killed_work_fn+0x130/0x1b0
[] process_one_work+0x26c/0x550
[] worker_thread+0x12e/0x3b0
[] kthread+0xe6/0xf0
[] ret_from_fork+0x7c/0xb0
---[ end trace 2d1577ec10cf80d0 ]---
It's because allocating/removing cgroup ID is not properly synchronized.
The bug was introduced when we converted cgroup_ida to cgroup_idr.
While synchronization is already done inside ida_simple_{get,remove}(),
users are responsible for concurrent calls to idr_{alloc,remove}().
v2:
- Don't call deactivate_super() inside cgroup_mutex, as cgroup_kill_sb()
will be called if sb refcnt reaches 0. I don't think this can happen,
as cgroup_create() is called through vfs, so vfs should guarantee the
superblock won't disappear. Still better not depend on it even my guess
is probably correct.
Fixes: 4e96ee8e981b ("cgroup: convert cgroup_ida to cgroup_idr")
Reported-by: Michal Hocko
Signed-off-by: Li Zefan
---
Also rebased on "cgroup: fix error return from cgroup_create()".
---
include/linux/cgroup.h | 2 ++
kernel/cgroup.c| 47 ++-
2 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index 5c09759..9450f02 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -166,6 +166,8 @@ struct cgroup {
*
* The ID of the root cgroup is always 0, and a new cgroup
* will be assigned with a smallest available ID.
+*
+* Allocating/Removing ID must be protected by cgroup_mutex.
*/
int id;
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 7be8fe4..37f217c 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -886,7 +886,9 @@ static void cgroup_diput(struct dentry *dentry, struct
inode *inode)
* per-subsystem and moved to css->id so that lookups are
* successful until the target css is released.
*/
+ mutex_lock(_mutex);
idr_remove(>root->cgroup_idr, cgrp->id);
+ mutex_unlock(_mutex);
cgrp->id = -1;
call_rcu(>rcu_head, cgroup_free_rcu);
@@ -4174,15 +4176,12 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
}
rcu_assign_pointer(cgrp->name, name);
- /*
-* Temporarily set the pointer to NULL, so idr_find() won't return
-* a half-baked cgroup.
-*/
- cgrp->id = idr_alloc(>cgroup_idr, NULL, 1, 0, GFP_KERNEL);
- if (cgrp->id < 0) {
- err = -ENOMEM;
- goto err_free_name;
- }
+ /* Grab a reference on the superblock so the hierarchy doesn't
+* get deleted on unmount if there are child cgroups. This
+* can be done outside cgroup_mutex, since the sb can't
+* disappear while someone has an open control file on the
+* fs */
+ atomic_inc(>s_active);
/*
* Only live parents can have children. Note that the liveliness
@@ -4193,15 +4192,18 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
*/
if (!cgroup_lock_live_group(parent)) {
err = -ENODEV;
- goto err_free_id;
+ goto err_free_name;
}
- /* Grab a reference on the superblock so the hierarchy doesn't
-* get deleted on unmount if there are child cgroups. This
-* can be done outside cgroup_mutex, since the sb can't
-* disappear while someone has an open control file on the
-* fs */
- atomic_inc(>s_active);
+ /*
+* Temporarily set the pointer to NULL, so idr_find() won't return
+* a half-baked cgroup.
+*/
+ cgrp->id = idr_alloc(>cgroup_idr, NULL, 1, 0, GFP_KERNEL);
+ if (cgrp->id < 0) {
+ err = -ENOMEM;
+ goto err_unlock;
+ }
init_cgroup_housekeeping(cgrp);
@@ -4225,7 +4227,7 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
*/
err = cgroup_create_file(dentry, S_IFDIR | mode, sb);
if (err < 0)
- goto err_unlock;
+ goto err_free_id;
lockdep_assert_held(>d_inode->i_mutex);
cgrp->serial_nr =
[PATCH RESEND] arm: add DSB after icache flush in __flush_icache_all()
Add DSB after icache flush to complete the cache maintenance operation.
Signed-off-by: Vinayak Kale
Acked-by: Catalin Marinas
Cc:
---
KernelVersion: 3.14-rc1
PS:
- This patch is tested for ARM-v7.
arch/arm/include/asm/cacheflush.h |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/cacheflush.h
b/arch/arm/include/asm/cacheflush.h
index ee753f1..ab91ebb 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -212,6 +212,7 @@ extern void copy_to_user_page(struct vm_area_struct *,
struct page *,
static inline void __flush_icache_all(void)
{
__flush_icache_preferred();
+ dsb();
}
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm fixes
Hi Linus, nothing too crazy, radeon irq fixes, i915 regression fixes, exynos fixes, tda998x chip fixes, and a bunch of msm fixes. Dave. The following changes since commit 7c4c62a04a2a80e3feb5d6c97aca1e413b11c790: drm/radeon: allow geom rings to be setup on r600/r700 (v2) (2014-02-06 12:13:52 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 9b244b5dc720f2b2135b2e64d44ab10220c2bf21: Merge branch 'tda998x-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next (2014-02-12 09:51:51 +1000) Alex Deucher (5): drm/radeon: fix UVD IRQ support on 7xx drm/radeon/dpm: use the driver state for dpm debugfs drm/radeon/dpm: use stored max_vddc rather than looking it up drm/radeon: remove useless return drm/radeon: add missing include in btc_dpm.c Christian König (1): drm/radeon: fix UVD IRQ support on SI Daniel Vetter (3): MAINTAINERS: Update drm/i915 git repo drm/i915: Disable dp aux irq on g4x drm/i915: Fix intel_pipe_to_cpu_transcoder for UMS Dave Airlie (6): Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into drm-next Merge branch 'exynos-drm-fixes' of git://git.kernel.org/.../daeinki/drm-exynos into drm-next Merge tag 'drm-intel-fixes-2014-02-06' of ssh://git.freedesktop.org/git/drm-intel into drm-next Merge tag 'drm-intel-fixes-2014-02-11' of ssh://git.freedesktop.org/git/drm-intel into drm-next Merge branch 'tda998x-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next Dave Jones (1): drm/radeon/dpm: fix uninitialized read from stack in kv_dpm_late_enable Imre Deak (1): drm/i915: vlv: fix DP PHY lockup due to invalid PP sequencer setup Jani Nikula (2): drm: add DRM_INFO_ONCE() to print a one-time DRM_INFO() message drm/i915: demote opregion excessive timeout WARN_ONCE to DRM_INFO_ONCE Jean-Francois Moine (6): drm/i2c: tda998x: fix bad value in the AIF drm/i2c: tda998x: check the CEC device creation drm/i2c: tda998x: free the CEC device on encoder_destroy drm/i2c: tda998x: force the page register at startup time drm/i2c: tda998x: set the PLL division factor in range 0..3 drm/i2c: tda998x: fix the ENABLE_SPACE register Mika Kuoppala (1): drm/i915: Pair va_copy with va_end in i915_error_vprintf Rob Clark (6): drm/msm: fix inconsequential typo drm/msm/mdp5: fix ref leaks in error paths drm/msm/mdp4: pageflip fixes drm/msm/mdp4: cursor fixes drm/msm: fix deadlock in bo create fail path drm/msm: bigger synchronization hammer Sachin Kamat (4): drm/exynos: Fix freeing issues in exynos_drm_drv.c drm/exynos: Remove unnecessary semicolon drm/exynos: Fix trivial typo drm/exynos: Convert to use the standard hdmi.h header Tushar Behera (1): drm/exynos: Fix multiplatform breakage for ipp/gsc MAINTAINERS | 2 +- drivers/gpu/drm/exynos/Kconfig| 4 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 ++- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 3 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 66 +-- drivers/gpu/drm/i2c/tda998x_drv.c | 17 ++- drivers/gpu/drm/i915/i915_drv.h | 8 ++ drivers/gpu/drm/i915/i915_gpu_error.c | 5 +- drivers/gpu/drm/i915/i915_irq.c | 3 +- drivers/gpu/drm/i915/intel_dp.c | 12 +- drivers/gpu/drm/i915/intel_i2c.c | 7 -- drivers/gpu/drm/i915/intel_opregion.c | 9 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 179 +++--- drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 4 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 7 +- drivers/gpu/drm/msm/msm_gem.c | 2 +- drivers/gpu/drm/msm/msm_gem_submit.c | 9 +- drivers/gpu/drm/msm/msm_gpu.c | 3 - drivers/gpu/drm/radeon/btc_dpm.c | 32 ++ drivers/gpu/drm/radeon/btcd.h | 4 + drivers/gpu/drm/radeon/kv_dpm.c | 2 +- drivers/gpu/drm/radeon/ni_dpm.c | 8 +- drivers/gpu/drm/radeon/r600.c | 4 + drivers/gpu/drm/radeon/radeon_asic.c | 2 +- drivers/gpu/drm/radeon/radeon_asic.h | 2 + drivers/gpu/drm/radeon/rv770_dpm.c| 5 +- drivers/gpu/drm/radeon/si.c | 4 + drivers/gpu/drm/radeon/si_dpm.c | 3 +- drivers/gpu/drm/radeon/sumo_dpm.c | 2 +- drivers/gpu/drm/radeon/trinity_dpm.c | 3 +- drivers/gpu/drm/radeon/uvd_v2_2.c | 1 - include/drm/drmP.h| 3 + 33 files changed, 270 insertions(+), 161 deletions(-)
Re: 3.14-rc2 XFS backtrace because irqs_disabled.
On Tue, Feb 11, 2014 at 9:40 PM, Dave Chinner wrote: > > None of the XFS code disables interrupts in that path, not does is > call outside XFS except to dispatch IO. The stack is pretty deep at > this point and I know that the standard (non stacked) IO stack can > consume >3kb of stack space when it gets down to having to do memory > reclaim during GFP_NOIO allocation at the lowest level of SCSI > drivers. Stack overruns typically show up with symptoms like we are > seeing. That would also explain why it shows up for do_coredump(), even though clearly interrupts are not disabled at that point. It's just because do_coredump() opens a filename at a deeper point in the stack than the more normal system call paths do. It looks like just "do_signal()" has a stack frame that is about 230 bytes even under normal circumstancs (largely due to "struct ksignal" - which in turn is largely due to the insane 128-byte padding in siginfo_t). Add a few other frames in there, and I guess that if it was close before, the coredump path just makes it go off. And some of the debug options that I'm sure DaveJ has enabled tend to make the stack usage worse (simply because they make a lot of data structures bigger). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:sched/core] sched: Push down pre_schedule() and idle_balance ()
Hi, Peter
On 02/11/2014 08:17 PM, tip-bot for Peter Zijlstra wrote:
[snip]
> +
> +idle:
> +#ifdef CONFIG_SMP
> + idle_enter_fair(rq);
> + /*
> + * We must set idle_stamp _before_ calling idle_balance(), such that we
> + * measure the duration of idle_balance() as idle time.
> + */
> + rq->idle_stamp = rq_clock(rq);
> + if (idle_balance(rq)) { /* drops rq->lock */
Since idle_balance() will release the rq lock, will it happen that some
rt or dl tasks was waken up and enqueued before it hold the lock again?
Should we recheck 'rq->nr_running == rq->cfs.h_nr_running' here before
goto pick fair entity to make sure the priority?
May be like:
if (idle_balance(rq) &&
rq->nr_running == rq->cfs.h_nr_running)
Regards,
Michael Wang
> + rq->idle_stamp = 0;
> + goto again;
> + }
> +#endif
> +
> + return NULL;
> }
>
> /*
> diff --git a/kernel/sched/idle_task.c b/kernel/sched/idle_task.c
> index 721371b..f7d03af 100644
> --- a/kernel/sched/idle_task.c
> +++ b/kernel/sched/idle_task.c
> @@ -13,13 +13,8 @@ select_task_rq_idle(struct task_struct *p, int cpu, int
> sd_flag, int flags)
> {
> return task_cpu(p); /* IDLE tasks as never migrated */
> }
> -
> -static void pre_schedule_idle(struct rq *rq, struct task_struct *prev)
> -{
> - idle_exit_fair(rq);
> - rq_last_tick_reset(rq);
> -}
> #endif /* CONFIG_SMP */
> +
> /*
> * Idle tasks are unconditionally rescheduled:
> */
> @@ -56,6 +51,10 @@ dequeue_task_idle(struct rq *rq, struct task_struct *p,
> int flags)
>
> static void put_prev_task_idle(struct rq *rq, struct task_struct *prev)
> {
> +#ifdef CONFIG_SMP
> + idle_exit_fair(rq);
> + rq_last_tick_reset(rq);
> +#endif
> }
>
> static void task_tick_idle(struct rq *rq, struct task_struct *curr, int
> queued)
> @@ -99,7 +98,6 @@ const struct sched_class idle_sched_class = {
>
> #ifdef CONFIG_SMP
> .select_task_rq = select_task_rq_idle,
> - .pre_schedule = pre_schedule_idle,
> #endif
>
> .set_curr_task = set_curr_task_idle,
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index a15ca1c..72f9ec7 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -229,6 +229,8 @@ int alloc_rt_sched_group(struct task_group *tg, struct
> task_group *parent)
>
> #ifdef CONFIG_SMP
>
> +static int pull_rt_task(struct rq *this_rq);
> +
> static inline int rt_overloaded(struct rq *rq)
> {
> return atomic_read(>rd->rto_count);
> @@ -1330,6 +1332,12 @@ pick_next_task_rt(struct rq *rq, struct task_struct
> *prev)
> struct task_struct *p;
> struct rt_rq *rt_rq = >rt;
>
> +#ifdef CONFIG_SMP
> + /* Try to pull RT tasks here if we lower this rq's prio */
> + if (rq->rt.highest_prio.curr > prev->prio)
> + pull_rt_task(rq);
> +#endif
> +
> if (!rt_rq->rt_nr_running)
> return NULL;
>
> @@ -1721,13 +1729,6 @@ skip:
> return ret;
> }
>
> -static void pre_schedule_rt(struct rq *rq, struct task_struct *prev)
> -{
> - /* Try to pull RT tasks here if we lower this rq's prio */
> - if (rq->rt.highest_prio.curr > prev->prio)
> - pull_rt_task(rq);
> -}
> -
> static void post_schedule_rt(struct rq *rq)
> {
> push_rt_tasks(rq);
> @@ -2004,7 +2005,6 @@ const struct sched_class rt_sched_class = {
> .set_cpus_allowed = set_cpus_allowed_rt,
> .rq_online = rq_online_rt,
> .rq_offline = rq_offline_rt,
> - .pre_schedule = pre_schedule_rt,
> .post_schedule = post_schedule_rt,
> .task_woken = task_woken_rt,
> .switched_from = switched_from_rt,
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index c534cf4..1bf34c2 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -1118,7 +1118,6 @@ struct sched_class {
> int (*select_task_rq)(struct task_struct *p, int task_cpu, int
> sd_flag, int flags);
> void (*migrate_task_rq)(struct task_struct *p, int next_cpu);
>
> - void (*pre_schedule) (struct rq *this_rq, struct task_struct *task);
> void (*post_schedule) (struct rq *this_rq);
> void (*task_waking) (struct task_struct *task);
> void (*task_woken) (struct rq *this_rq, struct task_struct *task);
> --
> 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 1/2] kobject: don't block for each kobject_uevent
On 02/12/2014 03:03 AM, Andrew Morton wrote:
> On Sun, 9 Feb 2014 14:56:15 +0400 Vladimir Davydov
> wrote:
>
>> Currently kobject_uevent has somewhat unpredictable semantics. The point
>> is, since it may call a usermode helper and wait for it to execute
>> (UMH_WAIT_EXEC), it is impossible to say for sure what lock dependencies
>> it will introduce for the caller - strictly speaking it depends on what
>> fs the binary is located on and the set of locks fork may take. There
>> are quite a few kobject_uevent's users that do not take this into
>> account and call it with various mutexes taken, e.g. rtnl_mutex,
>> net_mutex, which might potentially lead to a deadlock.
>>
>> Since there is actually no reason to wait for the usermode helper to
>> execute there, let's make kobject_uevent start the helper asynchronously
>> with the aid of the UMH_NO_WAIT flag.
>>
>> Personally, I'm interested in this, because I really want kobject_uevent
>> to be called under the slab_mutex in the slub implementation as it used
>> to be some time ago, because it greatly simplifies synchronization and
>> automatically fixes a kmemcg-related race. However, there was a deadlock
>> detected on an attempt to call kobject_uevent under the slab_mutex (see
>> https://lkml.org/lkml/2012/1/14/45), which was reported to be fixed by
>> releasing the slab_mutex for kobject_uevent. Unfortunately, there was no
>> information about who exactly blocked on the slab_mutex causing the
>> usermode helper to stall, neither have I managed to find this out or
>> reproduce the issue.
>>
>> BTW, this is not the first attempt to make kobject_uevent use
>> UMH_NO_WAIT. Previous one was made by commit f520360d93c, but it was
>> wrong (it passed arguments allocated on stack to async thread) so it was
>> reverted (commit 05f54c13cd0c). It targeted on speeding up the boot
>> process though.
> The patches look good to me. One is kobject (Greg) and the other is
> slub (Pekka), so I grabbed them ;) Reviews-and-acks, please?
>
>
>
> btw, when referring to commits, please use the form
>
> f520360d93c ("kobject: don't block for each kobject_uevent")
>
> because the same commit can have different hashes in different trees.
Oh, sorry about that. I will take this into account.
Thank you.
>
> (Although I suspect the amount of convenience this provides others
> doesn't match the amount of time I spend fixing changelogs!)
>
--
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 01/51] CPU hotplug: Provide lockless versions of callback registration functions
On 02/12/2014 02:21 AM, Toshi Kani wrote: > On Wed, 2014-02-12 at 00:50 +0530, Srivatsa S. Bhat wrote: >> On 02/11/2014 11:05 PM, Toshi Kani wrote: > : >>> How about this? foo_cpu_notifier returns NOP when foo_notifier_ready is >>> false. >>> >>> register_cpu_notifier(_cpu_notifier); >>> >>> get_online_cpus(); >>> >>> for_each_online_cpu(cpu) >>> init_cpu(cpu); >>> >>> foo_notifier_ready = true; >>> >>> put_online_cpus(); >>> >> >> Nah, that looks a lot like some quick-n-dirty hack ;-( >> It would also amount to burdening the various subsystems to add weird-looking >> pieces of code such as this in their callbacks: >> >> if (!foo_notifier_ready) >> return NOTIFY_OK; >> >> This only makes it all the more evident that the callback registration APIs >> exposed by the CPU hotplug core is poorly designed. >> >> What we need instead, is an elegant, well-defined and easy-to-use set of >> interfaces/APIs exposed by the core CPU hotplug code to the various >> subsystems. I don't think we should worry so much about the fact that >> we can't use the familiar get/put_online_cpus() in this type of callback >> registration scenario. We can introduce a sane set of APIs that work >> well in such situations and use them consistently. > >> For example, something like the code snippet shown below looks pretty >> neat to me: >> >> cpu_notifier_register_begin(); >> >> for_each_online_cpu(cpu) >> init_cpu(cpu); >> >> register_cpu_notifier(_cpu_notifier); >> >> cpu_notifier_register_done(); >> >> What do you think? > > I agree that it is cleaner for the callers as long as people understand > how to use them. Can you document them properly so that they know when > they need to use them instead of the familiar get/put_online_cpus()? > Sure.. I had updated the documentation with the semantics introduced in this patchset, in patch 2: http://thread.gmane.org/gmane.linux.kernel/1641638/focus=1641695 Similarly I'll keep the docs updated with these new APIs in v2 as well. Thank you! Regards, Srivatsa S. Bhat -- 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: 3.14-rc2 XFS backtrace because irqs_disabled.
On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote: > On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote: > > > None of the XFS code disables interrupts in that path, not does is > > call outside XFS except to dispatch IO. The stack is pretty deep at > > this point and I know that the standard (non stacked) IO stack can > > consume >3kb of stack space when it gets down to having to do memory > > reclaim during GFP_NOIO allocation at the lowest level of SCSI > > drivers. Stack overruns typically show up with symptoms like we are > > seeing. > > .. > > > > Dave, before chasing ghosts, can you (like Eric originally asked) > > turn on stack overrun detection? > > CONFIG_DEBUG_STACKOVERFLOW ? Already turned on. That only checks stack usage when an interrupt is taken. If no interrupts are taken when stack usage is within 128 bytes of overflow, then it doesn't catch it. I tend to use CONFIG_DEBUG_STACK_USAGE=y as it records the maximum stack usage of a process via canary overwrites and it records it in do_exit(). I also use the stack tracer to record the largest stack usage seen so I know exactly what code paths are approaching stack overruns... Cheers, Dave. -- Dave Chinner da...@fromorbit.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: [RFC][PATCH 0/5] arch: atomic rework
On Tue, 2014-02-11 at 07:59 -0800, Paul E. McKenney wrote:
> On Mon, Feb 10, 2014 at 11:09:24AM -0800, Linus Torvalds wrote:
> > On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote:
> > >
> > > Intuitively, this is wrong because this let's the program take a step
> > > the abstract machine wouldn't do. This is different to the sequential
> > > code that Peter posted because it uses atomics, and thus one can't
> > > easily assume that the difference is not observable.
> >
> > Btw, what is the definition of "observable" for the atomics?
> >
> > Because I'm hoping that it's not the same as for volatiles, where
> > "observable" is about the virtual machine itself, and as such volatile
> > accesses cannot be combined or optimized at all.
> >
> > Now, I claim that atomic accesses cannot be done speculatively for
> > writes, and not re-done for reads (because the value could change),
> > but *combining* them would be possible and good.
> >
> > For example, we often have multiple independent atomic accesses that
> > could certainly be combined: testing the individual bits of an atomic
> > value with helper functions, causing things like "load atomic, test
> > bit, load same atomic, test another bit". The two atomic loads could
> > be done as a single load without possibly changing semantics on a real
> > machine, but if "visibility" is defined in the same way it is for
> > "volatile", that wouldn't be a valid transformation. Right now we use
> > "volatile" semantics for these kinds of things, and they really can
> > hurt.
> >
> > Same goes for multiple writes (possibly due to setting bits):
> > combining multiple accesses into a single one is generally fine, it's
> > *adding* write accesses speculatively that is broken by design..
> >
> > At the same time, you can't combine atomic loads or stores infinitely
> > - "visibility" on a real machine definitely is about timeliness.
> > Removing all but the last write when there are multiple consecutive
> > writes is generally fine, even if you unroll a loop to generate those
> > writes. But if what remains is a loop, it might be a busy-loop
> > basically waiting for something, so it would be wrong ("untimely") to
> > hoist a store in a loop entirely past the end of the loop, or hoist a
> > load in a loop to before the loop.
> >
> > Does the standard allow for that kind of behavior?
>
> You asked! ;-)
>
> So the current standard allows merging of both loads and stores, unless of
> course ordring constraints prevent the merging. Volatile semantics may be
> used to prevent this merging, if desired, for example, for real-time code.
Agreed.
> Infinite merging is intended to be prohibited, but I am not certain that
> the current wording is bullet-proof (1.10p24 and 1.10p25).
Yeah, maybe not. But it at least seems to rather clearly indicate the
intent ;)
> The only prohibition against speculative stores that I can see is in a
> non-normative note, and it can be argued to apply only to things that are
> not atomics (1.10p22).
I think this one is specifically about speculative stores that would
affect memory locations that the abstract machine would not write to,
and that might be observable or create data races. While a compiler
could potentially prove that such stores aren't leading to a difference
in the behavior of the program (e.g., by proving that there are no
observers anywhere and this isn't overlapping with any volatile
locations), I think that this is hard in general and most compilers will
just not do such things. In GCC, bugs in that category were fixed after
researchers doing fuzz-testing found them (IIRC, speculative stores by
loops).
> I don't see any prohibition against reordering
> a store to precede a load preceding a conditional branch -- which would
> not be speculative if the branch was know to be taken and the load
> hit in the store buffer. In a system where stores could be reordered,
> some other CPU might perceive the store as happening before the load
> that controlled the conditional branch. This needs to be addressed.
I don't know the specifics of your example, but from how I understand
it, I don't see a problem if the compiler can prove that the store will
always happen.
To be more specific, if the compiler can prove that the store will
happen anyway, and the region of code can be assumed to always run
atomically (e.g., there's no loop or such in there), then it is known
that we have one atomic region of code that will always perform the
store, so we might as well do the stuff in the region in some order.
Now, if any of the memory accesses are atomic, then the whole region of
code containing those accesses is often not atomic because other threads
might observe intermediate results in a data-race-free way.
(I know that this isn't a very precise formulation, but I hope it brings
my line of reasoning across.)
> Why this hole? At the time, the current formalizations of popular
> CPU architectures did not exist, and it was
[PATCH net] vhost_net: do not report a used len larger than receive buffer size
Currently, even if the packet were truncated by lower socket, we still report the packet size as the used len which may confuse guest driver. Fixes this by returning the size of guest receive buffer instead. Fixes 3a4d5c94e959359ece6d6b55045c3f046677f55c (vhost_net: a kernel-level virtio server) Cc: Michael S. Tsirkin Signed-off-by: Jason Wang --- drivers/vhost/net.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 9a68409..06268a0 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -525,7 +525,8 @@ static int get_rx_bufs(struct vhost_virtqueue *vq, ++headcount; seg += in; } - heads[headcount - 1].len += datalen; + if (likely(datalen < 0)) + heads[headcount - 1].len += datalen; *iovcount = seg; if (unlikely(log)) *log_num = nlogs; -- 1.8.3.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: [RFC PATCH] Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE
- Original Message - > From: "Steven Rostedt" > To: "Ingo Molnar" > Cc: "Mathieu Desnoyers" , > linux-kernel@vger.kernel.org, "Ingo Molnar" > , "Thomas Gleixner" , "Rusty Russell" > , "David Howells" > , "Greg Kroah-Hartman" > Sent: Tuesday, February 11, 2014 11:45:34 PM > Subject: Re: [RFC PATCH] Fix: module signature vs tracepoints: add new > TAINT_UNSIGNED_MODULE > > On Tue, 11 Feb 2014 08:27:38 +0100 > Ingo Molnar wrote: > > > > > * Mathieu Desnoyers wrote: > > > > > Users have reported being unable to trace non-signed modules loaded > > > within a kernel supporting module signature. > > > > External modules should strive to get out of the 'crap' and > > 'felony law breaker' categories and we should not make it > > easier for them to linger in a broken state. > > > > Nacked-by: Ingo Molnar > > I'm not sure how great this idea is, but it isn't the same as the > "crap" and "fenony law breaker" categories. Having a non-signed module > doesn't mean that it isn't fully GPL compliant, it just means that it > hasn't been signed. There's several things that can taint the kernel > when loading a module. Being non GPL compliant is just one of them, and > that will never be allowed to accept tracepoints. > > Forcing a module that was built for a different kernel version gives us > another taint, which we don't add tracepoints for, not because it is > not compliant, but because that could corrupt the kernel as we can > not guarantee the binary structure layout of those modules would be the > same as what the kernel was built with. We don't want people > complaining about tracepoint failures due to forcing an older module > into a newer kernel with different tracepoint structures. > > But if the kernel expects to have signed modules, and you force a > module to be loaded that is not signed, then you still get that > "forced" module taint, which is the same one as loading a module from > an older kernel into a newer kernel. It's a different problem, and I > can see having a different taint flag be more informative to kernel > developers in general. I would welcome that change with or without > letting tracepoints be set for that module. > > But I have to ask Mathieu, what exactly is the use case here? If you > have a kernel that expects to only load signed modules, why would you > want to force non signed ones? That basically breaks the whole purpose > of signing modules. Once you allow a non signed module to be loaded > then the kernel can be considered compromised. That is, you just gave > kernel access to an untrusted source. The use-case is with a kernel that has this config: CONFIG_MODULE_SIG=y # CONFIG_MODULE_SIG_FORCE is not set which is the case for at least Ubuntu kernels (that I know of). It allows users to specify the kernel boot argument "module.sig_enforce" if they care about refusing unsigned modules. The use-case targeted here is loading GPL compliant out-of-tree modules with those kernels, obviously not using the kernel boot argument "module.sig_enforce". Tracepoints contained within those modules are silently skipped due to the TAINT_FORCED_MODULE flag. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.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: 3.14-rc2 XFS backtrace because irqs_disabled.
On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote: > None of the XFS code disables interrupts in that path, not does is > call outside XFS except to dispatch IO. The stack is pretty deep at > this point and I know that the standard (non stacked) IO stack can > consume >3kb of stack space when it gets down to having to do memory > reclaim during GFP_NOIO allocation at the lowest level of SCSI > drivers. Stack overruns typically show up with symptoms like we are > seeing. > .. > > Dave, before chasing ghosts, can you (like Eric originally asked) > turn on stack overrun detection? CONFIG_DEBUG_STACKOVERFLOW ? Already turned on. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Feb 12
Hi all,
If you see failures in building this tree due to missing declarations of
k..alloc/free, then it may be caused by commit 2bd59d48ebfb ("cgroup:
convert to kernfs"). Please send Tejun Heo a patch
adding an inclusion of linux/slab.h to the appropriate file(s).
This tree fails (more than usual) the powerpc allyesconfig build.
Changes since 20140210:
The powerpc tree still had its build failure.
The mfd-lj tree still had its build failure so I used the version from
next-20140210.
The tip tree lost its build failure but gained another so I used the
version from next-20140210.
The staging tree lost its build failure.
The cgroup tree gained a build failure for which I applied a patch.
The pinctrl tree lost its build failure.
Non-merge commits (relative to Linus' tree): 1763
1848 files changed, 64228 insertions(+), 31255 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final
link) and i386, sparc, sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
I am currently merging 208 trees (counting Linus' and 28 trees of patches
pending for Linus' tree).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master (738b52bb9845 Merge tag 'microblaze-3.14-rc3' of
git://git.monstr.eu/linux-2.6-microblaze)
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1)
Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8)
Merging arm-current/fixes (87f9260bf1fb ARM: dts: fix spdif pinmux
configuration)
Merging m68k-current/for-linus (7247f55381d5 m68k: Wire up sched_setattr and
sched_getattr)
Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2)
Merging powerpc-merge/merge (b3084f4db3ae powerpc/thp: Fix crash on mremap)
Merging sparc/master (738b52bb9845 Merge tag 'microblaze-3.14-rc3' of
git://git.monstr.eu/linux-2.6-microblaze)
Merging net/master (738b52bb9845 Merge tag 'microblaze-3.14-rc3' of
git://git.monstr.eu/linux-2.6-microblaze)
Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in
dccp_probe init)
Merging sound-current/for-linus (ef8e39b51f24 ALSA: hda - Fix undefined symbol
due to builtin/module mixup)
Merging pci-current/for-linus (38dbfb59d117 Linus 3.14-rc1)
Merging wireless/master (348f7d4adee9 rtl8180: Add error check for
pci_map_single return value in TX path)
Merging driver-core.current/driver-core-linus (9e1ccb4a7700 drivers/base: fix
devres handling for master device)
Merging tty.current/tty-linus (d8a5dc3033af tty: Set correct tty name in
'active' sysfs attribute)
Merging usb.current/usb-linus (3635c7e2d59f usb: option: blacklist ZTE MF667
net interface)
Merging staging.current/staging-linus (a0f452520211 Merge tag
'iio-fixes-for-3.14b' of
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (3b1cc9b9622a misc: mic: fix possible
signed underflow (undefined behavior) in userspace API)
Merging input-current/for-linus (55df811f2066 Merge branch 'next' into
for-linus)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard"
stripe)
Merging crypto-current/master (ee97dc7db4cb crypto: s390 - fix des and des3_ede
ctr concurrency issue)
Merging ide/master (738b52bb9845
[PATCH net] virtio-net: alloc big buffers also when guest can receive UFO
We should alloc big buffers also when guest can receive UFO pakcets. Otherwise the big packets will be truncated when mergeable rx buffer is disabled. Fixes 5c5167515d80f78f6bb538492c423adcae31ad65 (virtio-net: Allow UFO feature to be set and advertised.) Cc: Rusty Russell Cc: Michael S. Tsirkin Cc: Sridhar Samudrala Signed-off-by: Jason Wang --- drivers/net/virtio_net.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index d75f8ed..5632a99 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -1711,7 +1711,8 @@ static int virtnet_probe(struct virtio_device *vdev) /* If we can receive ANY GSO packets, we must allocate large ones. */ if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO4) || virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_TSO6) || - virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_ECN)) + virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_ECN) || + virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_UFO)) vi->big_packets = true; if (virtio_has_feature(vdev, VIRTIO_NET_F_MRG_RXBUF)) -- 1.8.3.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: 3.14-rc2 XFS backtrace because irqs_disabled.
On Wed, Feb 12, 2014 at 04:22:15AM +, Al Viro wrote: > On Tue, Feb 11, 2014 at 11:03:58PM -0500, Dave Jones wrote: > > [ 3111.414202] [] bio_alloc_bioset+0x156/0x210 > > [ 3111.414855] [] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs] > > [ 3111.415517] [] ? xlog_bdstrat+0x22/0x60 [xfs] > > [ 3111.416175] [] xfs_buf_iorequest+0x6b/0xf0 [xfs] > > [ 3111.416843] [] xlog_bdstrat+0x22/0x60 [xfs] > > [ 3111.417509] [] xlog_sync+0x3a7/0x5b0 [xfs] > > [ 3111.418175] [] xlog_state_release_iclog+0x10f/0x120 > > [xfs] > > [ 3111.418846] [] xlog_write+0x6f0/0x800 [xfs] > > [ 3111.419518] [] xlog_cil_push+0x2f1/0x410 [xfs] > > Very interesting. The first thing xlog_cil_push() is doing is blocking > kmalloc(). So at that point it still hadn't been atomic. I'd probably > slap may_sleep() in the beginning of xlog_sync() and see if that triggers... None of the XFS code disables interrupts in that path, not does is call outside XFS except to dispatch IO. The stack is pretty deep at this point and I know that the standard (non stacked) IO stack can consume >3kb of stack space when it gets down to having to do memory reclaim during GFP_NOIO allocation at the lowest level of SCSI drivers. Stack overruns typically show up with symptoms like we are seeing. Simple example with memory allocation follows. keep in mind that memory reclaim uses a whole lot more stack if it is needed, and that scheduling at this point requires about 1k of stack to be free for the scheduler footprint, too. FWIW, the blk-mq stuff seems to hae added 200-300 bytes of new stack usage to the IO path $ sudo cat /sys/kernel/debug/tracing/stack_trace DepthSize Location(45 entries) - 0) 5944 40 zone_statistics+0xbd/0xc0 1) 5904 256 get_page_from_freelist+0x3a8/0x8a0 2) 5648 256 __alloc_pages_nodemask+0x143/0x8e0 3) 5392 80 alloc_pages_current+0xb2/0x170 4) 5312 64 new_slab+0x265/0x2e0 5) 5248 240 __slab_alloc+0x2fb/0x4c4 6) 5008 80 __kmalloc+0x133/0x180 7) 4928 112 virtqueue_add_sgs+0x2fe/0x520 8) 4816 288 __virtblk_add_req+0xd5/0x180 9) 4528 96 virtio_queue_rq+0xdd/0x1d0 10) 4432 112 __blk_mq_run_hw_queue+0x1c3/0x3c0 11) 4320 16 blk_mq_run_hw_queue+0x35/0x40 12) 4304 80 blk_mq_insert_requests+0xc5/0x120 13) 4224 96 blk_mq_flush_plug_list+0x129/0x140 14) 4128 112 blk_flush_plug_list+0xe7/0x240 15) 4016 32 blk_finish_plug+0x18/0x50 16) 3984 192 _xfs_buf_ioapply+0x30f/0x3b0 17) 3792 48 xfs_buf_iorequest+0x6f/0xc0 37) 928 16 xfs_vn_create+0x13/0x20 38) 912 64 vfs_create+0xb5/0xf0 39) 848 208 do_last.isra.53+0x6e0/0xd00 40) 640 176 path_openat+0xbe/0x620 41) 464 208 do_filp_open+0x43/0xa0 42) 256 112 do_sys_open+0x13c/0x230 43) 144 16 SyS_open+0x22/0x30 44) 128 128 system_call_fastpath+0x16/0x1b Dave, before chasing ghosts, can you (like Eric originally asked) turn on stack overrun detection? Cheers, Dave. -- Dave Chinner da...@fromorbit.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: [RFC][PATCH 0/5] arch: atomic rework
On Mon, 2014-02-10 at 11:09 -0800, Linus Torvalds wrote:
> On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote:
> >
> > Intuitively, this is wrong because this let's the program take a step
> > the abstract machine wouldn't do. This is different to the sequential
> > code that Peter posted because it uses atomics, and thus one can't
> > easily assume that the difference is not observable.
>
> Btw, what is the definition of "observable" for the atomics?
>
> Because I'm hoping that it's not the same as for volatiles, where
> "observable" is about the virtual machine itself, and as such volatile
> accesses cannot be combined or optimized at all.
No, atomics aren't an observable behavior of the abstract machine
(unless they are volatile). See 1.8.p8 (citing the C++ standard).
> Now, I claim that atomic accesses cannot be done speculatively for
> writes, and not re-done for reads (because the value could change),
Agreed, unless the compiler can prove that this doesn't make a
difference in the program at hand and it's not volatile atomics. In
general, that will be hard and thus won't happen often I suppose, but if
correctly proved it would fall under the as-if rule I think.
> but *combining* them would be possible and good.
Agreed.
> For example, we often have multiple independent atomic accesses that
> could certainly be combined: testing the individual bits of an atomic
> value with helper functions, causing things like "load atomic, test
> bit, load same atomic, test another bit". The two atomic loads could
> be done as a single load without possibly changing semantics on a real
> machine, but if "visibility" is defined in the same way it is for
> "volatile", that wouldn't be a valid transformation. Right now we use
> "volatile" semantics for these kinds of things, and they really can
> hurt.
Agreed. In your example, the compiler would have to prove that the
abstract machine would always be able to run the two loads atomically
(ie, as one load) without running into impossible/disallowed behavior of
the program. But if there's no loop or branch or such in-between, this
should be straight-forward because any hardware oddity or similar could
merge those loads and it wouldn't be disallowed by the standard
(considering that we're talking about a finite number of loads), so the
compiler would be allowed to do it as well.
> Same goes for multiple writes (possibly due to setting bits):
> combining multiple accesses into a single one is generally fine, it's
> *adding* write accesses speculatively that is broken by design..
Agreed. As Paul points out, this being correct assumes that there are
no other ordering guarantees or memory accesses "interfering", but if
the stores are to the same memory location and adjacent to each other in
the program, then I don't see a reason why they wouldn't be combinable.
> At the same time, you can't combine atomic loads or stores infinitely
> - "visibility" on a real machine definitely is about timeliness.
> Removing all but the last write when there are multiple consecutive
> writes is generally fine, even if you unroll a loop to generate those
> writes. But if what remains is a loop, it might be a busy-loop
> basically waiting for something, so it would be wrong ("untimely") to
> hoist a store in a loop entirely past the end of the loop, or hoist a
> load in a loop to before the loop.
Agreed. That's what 1.10p24 and 1.10p25 are meant to specify for loads,
although those might not be bullet-proof as Paul points out. Forward
progress is rather vaguely specified in the standard, but at least parts
of the committee (and people in ISO C++ SG1, in particular) are working
on trying to improve this.
> Does the standard allow for that kind of behavior?
I think the standard requires (or intends to require) the behavior that
you (and I) seem to prefer in these examples.
--
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 01/11] pagewalk: update page table walker core
On Mon, Feb 10, 2014 at 04:44:26PM -0500, Naoya Horiguchi wrote:
> This patch updates mm/pagewalk.c to make code less complex and more
> maintenable.
> The basic idea is unchanged and there's no userspace visible effect.
>
> Most of existing callback functions need access to vma to handle each entry.
> So we had better add a new member vma in struct mm_walk instead of using
> mm_walk->private, which makes code simpler.
>
> One problem in current page table walker is that we check vma in pgd loop.
> Historically this was introduced to support hugetlbfs in the strange manner.
> It's better and cleaner to do the vma check outside pgd loop.
>
> Another problem is that many users of page table walker now use only
> pmd_entry(), although it does both pmd-walk and pte-walk. This makes code
> duplication and fluctuation among callers, which worsens the maintenability.
>
> One difficulty of code sharing is that the callers want to determine
> whether they try to walk over a specific vma or not in their own way.
> To solve this, this patch introduces test_walk() callback.
>
> When we try to use multiple callbacks in different levels, skip control is
> also important. For example we have thp enabled in normal configuration, and
> we are interested in doing some work for a thp. But sometimes we want to
> split it and handle as normal pages, and in another time user would handle
> both at pmd level and pte level.
> What we need is that when we've done pmd_entry() we want to decide whether
> to go down to pte level handling based on the pmd_entry()'s result. So this
> patch introduces a skip control flag in mm_walk.
> We can't use the returned value for this purpose, because we already
> defined the meaning of whole range of returned values (>0 is to terminate
> page table walk in caller's specific manner, =0 is to continue to walk,
> and <0 is to abort the walk in the general manner.)
>
> ChangeLog v5:
> - fix build error ("mm/pagewalk.c:201: error: 'hmask' undeclared")
>
> ChangeLog v4:
> - add more comment
> - remove verbose variable in walk_page_test()
> - rename skip_check to skip_lower_level_walking
> - rebased onto mmotm-2014-01-09-16-23
>
> ChangeLog v3:
> - rebased onto v3.13-rc3-mmots-2013-12-10-16-38
>
> ChangeLog v2:
> - rebase onto mmots
> - add pte_none() check in walk_pte_range()
> - add cond_sched() in walk_hugetlb_range()
> - add skip_check()
> - do VM_PFNMAP check only when ->test_walk() is not defined (because some
> caller could handle VM_PFNMAP vma. copy_page_range() is an example.)
> - use do-while condition (addr < end) instead of (addr != end)
>
> Signed-off-by: Naoya Horiguchi
> ---
> include/linux/mm.h | 18 ++-
> mm/pagewalk.c | 352
> +
> 2 files changed, 235 insertions(+), 135 deletions(-)
>
> diff --git v3.14-rc2.orig/include/linux/mm.h v3.14-rc2/include/linux/mm.h
> index f28f46eade6a..4d0bc01de43c 100644
> --- v3.14-rc2.orig/include/linux/mm.h
> +++ v3.14-rc2/include/linux/mm.h
> @@ -1067,10 +1067,18 @@ void unmap_vmas(struct mmu_gather *tlb, struct
> vm_area_struct *start_vma,
> * @pte_entry: if set, called for each non-empty PTE (4th-level) entry
> * @pte_hole: if set, called for each hole at all levels
> * @hugetlb_entry: if set, called for each hugetlb entry
> - * *Caution*: The caller must hold mmap_sem() if @hugetlb_entry
> - * is used.
> + * @test_walk: caller specific callback function to determine whether
> + * we walk over the current vma or not. A positive returned
> + * value means "do page table walk over the current vma,"
> + * and a negative one means "abort current page table walk
> + * right now." 0 means "skip the current vma."
> + * @mm:mm_struct representing the target process of page table walk
> + * @vma: vma currently walked
> + * @skip: internal control flag which is set when we skip the lower
> + * level entries.
> + * @private: private data for callbacks' use
> *
> - * (see walk_page_range for more details)
> + * (see the comment on walk_page_range() for more details)
> */
> struct mm_walk {
> int (*pgd_entry)(pgd_t *pgd, unsigned long addr,
> @@ -1086,7 +1094,11 @@ struct mm_walk {
> int (*hugetlb_entry)(pte_t *pte, unsigned long hmask,
>unsigned long addr, unsigned long next,
>struct mm_walk *walk);
> + int (*test_walk)(unsigned long addr, unsigned long next,
> + struct mm_walk *walk);
> struct mm_struct *mm;
> + struct vm_area_struct *vma;
> + int skip;
> void *private;
> };
>
> diff --git v3.14-rc2.orig/mm/pagewalk.c v3.14-rc2/mm/pagewalk.c
> index 2beeabf502c5..4770558feea8 100644
> --- v3.14-rc2.orig/mm/pagewalk.c
> +++ v3.14-rc2/mm/pagewalk.c
> @@ -3,29 +3,58 @@
> #include
> #include
>
> -static int walk_pte_range(pmd_t *pmd, unsigned
[PATCH v2] drm/nouveau: support for platform devices
Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead
of PCI to which Nouveau is tightly dependent. This patch allows Nouveau
to handle platform devices by:
- abstracting PCI-dependent functions that were typically used for
resource querying and page mapping,
- introducing a nv_device_is_pci() function that allows to make
PCI-dependent code conditional,
- providing a nouveau_drm_platform_probe() function that takes a GPU
platform device to be probed.
Core code as well as engine/subdev drivers are updated wherever possible
to make use of these functions. Some older drivers are too dependent on
PCI to be properly updated, but all newer code on which future chips may
depend should at least be runnable with platform devices.
Signed-off-by: Alexandre Courbot
---
Changes since v1:
- Refactored nouveau_device_create_() to take an additional bus type
argument instead of having two versions of it that duplicate code.
- Fixed a typo when substituting pci_resource_* with nv_device_resource_*
- Check whether devices are PCI in relevant functions instead of
nouveau_drm_load().
drivers/gpu/drm/nouveau/core/engine/device/base.c | 83 --
drivers/gpu/drm/nouveau/core/engine/falcon.c | 6 +-
drivers/gpu/drm/nouveau/core/engine/fifo/base.c| 2 +-
drivers/gpu/drm/nouveau/core/engine/graph/nv20.c | 2 +-
drivers/gpu/drm/nouveau/core/engine/graph/nv40.c | 2 +-
drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4 +-
drivers/gpu/drm/nouveau/core/engine/xtensa.c | 2 +-
drivers/gpu/drm/nouveau/core/include/core/device.h | 30
.../gpu/drm/nouveau/core/include/engine/device.h | 17 +++--
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/os.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 4 +-
drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c | 4 +-
drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 15 ++--
.../gpu/drm/nouveau/core/subdev/devinit/fbmem.h| 8 ++-
drivers/gpu/drm/nouveau/core/subdev/devinit/nv04.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/devinit/nv05.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/devinit/nv10.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/devinit/nv20.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c | 9 +--
drivers/gpu/drm/nouveau/core/subdev/fb/nvc0.c | 9 +--
drivers/gpu/drm/nouveau/core/subdev/i2c/base.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c | 7 +-
drivers/gpu/drm/nouveau/core/subdev/mc/base.c | 39 ++
drivers/gpu/drm/nouveau/core/subdev/mxm/base.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c| 13 +++-
drivers/gpu/drm/nouveau/nouveau_agp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bios.c | 4 ++
drivers/gpu/drm/nouveau/nouveau_bo.c | 22 +++---
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_display.c | 3 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 59 ---
drivers/gpu/drm/nouveau/nouveau_sysfs.c| 8 ++-
drivers/gpu/drm/nouveau/nouveau_ttm.c | 31
drivers/gpu/drm/nouveau/nouveau_vga.c | 5 ++
35 files changed, 297 insertions(+), 109 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c
b/drivers/gpu/drm/nouveau/core/engine/device/base.c
index dd01c6c435d6..8a8f5f2d0eb5 100644
--- a/drivers/gpu/drm/nouveau/core/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/core/engine/device/base.c
@@ -131,8 +131,8 @@ nouveau_devobj_ctor(struct nouveau_object *parent,
if (ret)
return ret;
- mmio_base = pci_resource_start(device->pdev, 0);
- mmio_size = pci_resource_len(device->pdev, 0);
+ mmio_base = nv_device_resource_start(device, 0);
+ mmio_size = nv_device_resource_len(device, 0);
/* translate api disable mask into internal mapping */
disable = args->debug0;
@@ -446,6 +446,72 @@ nouveau_device_dtor(struct nouveau_object *object)
nouveau_engine_destroy(>base);
}
+resource_size_t
+nv_device_resource_start(struct nouveau_device *device, unsigned int bar)
+{
+ if (nv_device_is_pci(device)) {
+ return pci_resource_start(device->pdev, bar);
+ } else {
+ struct resource *res;
+ res = platform_get_resource(device->platformdev,
+ IORESOURCE_MEM, bar);
+ if (!res)
+ return 0;
+ return res->start;
+ }
+}
+
+resource_size_t
+nv_device_resource_len(struct nouveau_device *device, unsigned int bar)
+{
+ if (nv_device_is_pci(device)) {
+ return pci_resource_len(device->pdev, bar);
+ } else {
+ struct resource *res;
+ res = platform_get_resource(device->platformdev,
+
[PATCH] mfd: ti_am335x_tscadc: Use devm_ioremap_resource()
Use devm_ioremap_resource() in order to make the code simpler,
and remove redundant return value check of platform_get_resource()
because the value is checked by devm_ioremap_resource().
Signed-off-by: Jingoo Han
---
drivers/mfd/ti_am335x_tscadc.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index d4e8604..e0e081e 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -184,12 +184,6 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
return -EINVAL;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(>dev, "no memory resource defined.\n");
- return -EINVAL;
- }
-
/* Allocate memory for device */
tscadc = devm_kzalloc(>dev,
sizeof(struct ti_tscadc_dev), GFP_KERNEL);
@@ -206,19 +200,10 @@ staticint ti_tscadc_probe(struct platform_device
*pdev)
} else
tscadc->irq = err;
- res = devm_request_mem_region(>dev,
- res->start, resource_size(res), pdev->name);
- if (!res) {
- dev_err(>dev, "failed to reserve registers.\n");
- return -EBUSY;
- }
-
- tscadc->tscadc_base = devm_ioremap(>dev,
- res->start, resource_size(res));
- if (!tscadc->tscadc_base) {
- dev_err(>dev, "failed to map registers.\n");
- return -ENOMEM;
- }
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ tscadc->tscadc_base = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(tscadc->tscadc_base))
+ return PTR_ERR(tscadc->tscadc_base);
tscadc->regmap_tscadc = devm_regmap_init_mmio(>dev,
tscadc->tscadc_base, _regmap_config);
--
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 v2] dma: add R-Car Audio DMAC peri peri driver
Hi Vinod
Can I ask you about current status of this patch ?
> From: Kuninori Morimoto
>
> Add support Audio DMAC peri peri driver
> for Renesas R-Car Gen2 SoC, using 'shdma-base'
> DMA driver framework.
>
> Signed-off-by: Kuninori Morimoto
> ---
> v1 -> v2
>
> - run scripts/checkpatch.pl
> - ecchange length settings on audmapp_desc_setup()
> - exchange slave_id check on audmapp_find_slave()
>
> drivers/dma/sh/Kconfig |6 +
> drivers/dma/sh/Makefile|1 +
> drivers/dma/sh/rcar-audmapp.c | 325
>
> include/linux/platform_data/dma-rcar-audmapp.h | 34 +++
> 4 files changed, 366 insertions(+)
> create mode 100644 drivers/dma/sh/rcar-audmapp.c
> create mode 100644 include/linux/platform_data/dma-rcar-audmapp.h
>
> diff --git a/drivers/dma/sh/Kconfig b/drivers/dma/sh/Kconfig
> index dadd9e01..b4c8138 100644
> --- a/drivers/dma/sh/Kconfig
> +++ b/drivers/dma/sh/Kconfig
> @@ -29,6 +29,12 @@ config RCAR_HPB_DMAE
> help
> Enable support for the Renesas R-Car series DMA controllers.
>
> +config RCAR_AUDMAC_PP
> + tristate "Renesas R-Car Audio DMAC Peripheral Peripheral support"
> + depends on SH_DMAE_BASE
> + help
> + Enable support for the Renesas R-Car Audio DMAC Peripheral Peripheral
> controllers.
> +
> config SHDMA_R8A73A4
> def_bool y
> depends on ARCH_R8A73A4 && SH_DMAE != n
> diff --git a/drivers/dma/sh/Makefile b/drivers/dma/sh/Makefile
> index e856af2..1ce88b2 100644
> --- a/drivers/dma/sh/Makefile
> +++ b/drivers/dma/sh/Makefile
> @@ -7,3 +7,4 @@ endif
> shdma-objs := $(shdma-y)
> obj-$(CONFIG_SUDMAC) += sudmac.o
> obj-$(CONFIG_RCAR_HPB_DMAE) += rcar-hpbdma.o
> +obj-$(CONFIG_RCAR_AUDMAC_PP) += rcar-audmapp.o
> diff --git a/drivers/dma/sh/rcar-audmapp.c b/drivers/dma/sh/rcar-audmapp.c
> new file mode 100644
> index 000..cd3c237
> --- /dev/null
> +++ b/drivers/dma/sh/rcar-audmapp.c
> @@ -0,0 +1,325 @@
> +/*
> + * drivers/dma/sh/rcar-audmapp.c
> + *
> + * Copyright (C) 2013 Renesas Electronics Corporation
> + * Copyright (C) 2013 Kuninori Morimoto
> + *
> + * based on the drivers/dma/sh/shdma.c
> + *
> + * Copyright (C) 2011-2012 Guennadi Liakhovetski
> + * Copyright (C) 2009 Nobuhiro Iwamatsu
> + * Copyright (C) 2009 Renesas Solutions, Inc. All rights reserved.
> + * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
> + *
> + * This is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * DMA register
> + */
> +#define PDMASAR 0x00
> +#define PDMADAR 0x04
> +#define PDMACHCR 0x0c
> +
> +/* PDMACHCR */
> +#define PDMACHCR_DE (1 << 0)
> +
> +#define AUDMAPP_MAX_CHANNELS 29
> +
> +/* Default MEMCPY transfer size = 2^2 = 4 bytes */
> +#define LOG2_DEFAULT_XFER_SIZE 2
> +#define AUDMAPP_SLAVE_NUMBER 256
> +#define AUDMAPP_LEN_MAX (16 * 1024 * 1024)
> +
> +struct audmapp_chan {
> + struct shdma_chan shdma_chan;
> + struct audmapp_slave_config *config;
> + void __iomem *base;
> +};
> +
> +struct audmapp_device {
> + struct shdma_dev shdma_dev;
> + struct audmapp_pdata *pdata;
> + struct device *dev;
> + void __iomem *chan_reg;
> +};
> +
> +#define to_chan(chan) container_of(chan, struct audmapp_chan, shdma_chan)
> +#define to_dev(chan) container_of(chan->shdma_chan.dma_chan.device, \
> + struct audmapp_device, shdma_dev.dma_dev)
> +
> +static void audmapp_write(struct audmapp_chan *auchan, u32 data, u32 reg)
> +{
> + struct audmapp_device *audev = to_dev(auchan);
> + struct device *dev = audev->dev;
> +
> + dev_dbg(dev, "w %p : %08x\n", auchan->base + reg, data);
> +
> + iowrite32(data, auchan->base + reg);
> +}
> +
> +static u32 audmapp_read(struct audmapp_chan *auchan, u32 reg)
> +{
> + return ioread32(auchan->base + reg);
> +}
> +
> +static void audmapp_halt(struct shdma_chan *schan)
> +{
> + struct audmapp_chan *auchan = to_chan(schan);
> + int i;
> +
> + audmapp_write(auchan, 0, PDMACHCR);
> +
> + for (i = 0; i < 1024; i++) {
> + if (0 == audmapp_read(auchan, PDMACHCR))
> + return;
> + udelay(1);
> + }
> +}
> +
> +static void audmapp_start_xfer(struct shdma_chan *schan,
> +struct shdma_desc *sdecs)
> +{
> + struct audmapp_chan *auchan = to_chan(schan);
> + struct audmapp_device *audev = to_dev(auchan);
> + struct audmapp_slave_config *cfg = auchan->config;
> + struct device *dev = audev->dev;
> + u32 chcr = cfg->chcr | PDMACHCR_DE;
> +
> + dev_dbg(dev,
linux-next: build failure after merge of the final tree (cgroup tree related)
Hi all,
After merging the final tree, today's linux-next build (sparc defconfig)
failed like this:
arch/sparc/kernel/sun4m_irq.c: In function 'sun4m_build_device_irq':
arch/sparc/kernel/sun4m_irq.c:266:2: error: implicit declaration of function
'kzalloc' [-Werror=implicit-function-declaration]
arch/sparc/kernel/sun4m_irq.c:266:15: error: assignment makes pointer from
integer without a cast [-Werror]
Presumably caused by commit 2bd59d48ebfb ("cgroup: convert to kernfs")
(see the comment in commit 1ff6bbfd13ca ("arm, pm, vmpressure: add
missing slab.h includes")). I wonder how mane more builds are broken by
this :-(
Indeed, reverting that commit fixes the build.
I have added the following build fix for today (please check the
overnight builds for more breakage):
From: Stephen Rothwell
Date: Wed, 12 Feb 2014 16:01:10 +1100
Subject: [PATCH] sun4M: add include of slab.h for kzalloc
This was being included implicitly via cgroup.h's inclusion of xattr.h
(which has now been removed).
Signed-off-by: Stephen Rothwell
---
arch/sparc/kernel/sun4m_irq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/sparc/kernel/sun4m_irq.c b/arch/sparc/kernel/sun4m_irq.c
index c5ade9d27a1d..8bb3b3fddea7 100644
--- a/arch/sparc/kernel/sun4m_irq.c
+++ b/arch/sparc/kernel/sun4m_irq.c
@@ -9,6 +9,8 @@
* Copyright (C) 1996 Dave Redman (d...@tadpole.co.uk)
*/
+#include
+
#include
#include
#include
--
1.9.rc1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp95NMjnbP2W.pgp
Description: PGP signature
Re: [PATCH] ACPI / container: Fix error code path in container_device_attach()
(2014/02/12 9:05), Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
To avoid leaking memory on errors from device_register(), do a
put_device() on the device object in question in the error code
path of container_device_attach().
Fixes: caa73ea158de (ACPI / hotplug / driver core: Handle containers in a
special way)
Signed-off-by: Rafael J. Wysocki
---
Looks good to me.
Reviewed-by: Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
3.14 material.
Thanks!
---
drivers/acpi/container.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux-pm/drivers/acpi/container.c
===
--- linux-pm.orig/drivers/acpi/container.c
+++ linux-pm/drivers/acpi/container.c
@@ -82,9 +82,10 @@ static int container_device_attach(struc
ACPI_COMPANION_SET(dev, adev);
dev->release = acpi_container_release;
ret = device_register(dev);
- if (ret)
+ if (ret) {
+ put_device(dev);
return ret;
-
+ }
adev->driver_data = dev;
return 1;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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] powerpc: Fix "attempt to move .org backwards" error
Hi all, On Tue, 10 Dec 2013 10:26:10 +1100 Benjamin Herrenschmidt wrote: > > On Tue, 2013-12-10 at 10:10 +1100, Stephen Rothwell wrote: > > Reported-by: Stephen Rothwell > > Tested-by: Stephen Rothwell > > > > Works for me. Thanks. I will add this to linux-next today if Ben > > doesn't add it to his tree. > > I will but probably not soon enough for your cut today As noted elsewhere, this did not completely fix the problem and I have been still getting this error from my allyesconfig builds for some time: arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards Could someone please fix this? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpIv81uc7qZk.pgp Description: PGP signature
Re: [GIT PULL] x86, apic: Remove support for Summit and ES7000
On Tue, 11 Feb 2014, H. Peter Anvin wrote: > Nice. > Natalie emailed me and said she agrees with the removal of es7000. Matthew's email address bounces, so summit is orphaned and the email address in its header is obsolete. -- 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] hwrng: pixocell - Use devm_ioremap_resource()
Use devm_ioremap_resource() in order to make the code simpler,
and remove redundant return value check of platform_get_resource()
because the value is checked by devm_ioremap_resource().
Signed-off-by: Jingoo Han
---
drivers/char/hw_random/picoxcell-rng.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/char/hw_random/picoxcell-rng.c
b/drivers/char/hw_random/picoxcell-rng.c
index 3d4c229..c03beee 100644
--- a/drivers/char/hw_random/picoxcell-rng.c
+++ b/drivers/char/hw_random/picoxcell-rng.c
@@ -104,22 +104,9 @@ static int picoxcell_trng_probe(struct platform_device
*pdev)
int ret;
struct resource *mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem) {
- dev_warn(>dev, "no memory resource\n");
- return -ENOMEM;
- }
-
- if (!devm_request_mem_region(>dev, mem->start, resource_size(mem),
-"picoxcell_trng")) {
- dev_warn(>dev, "unable to request io mem\n");
- return -EBUSY;
- }
-
- rng_base = devm_ioremap(>dev, mem->start, resource_size(mem));
- if (!rng_base) {
- dev_warn(>dev, "unable to remap io mem\n");
- return -ENOMEM;
- }
+ rng_base = devm_ioremap_resource(>dev, mem);
+ if (IS_ERR(rng_base))
+ return PTR_ERR(rng_base);
rng_clk = clk_get(>dev, NULL);
if (IS_ERR(rng_clk)) {
--
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] hwrng: atmel - Use devm_ioremap_resource()
Use devm_ioremap_resource() in order to make the code simpler, and remove redundant return value check of platform_get_resource() because the value is checked by devm_ioremap_resource(). Signed-off-by: Jingoo Han --- drivers/char/hw_random/atmel-rng.c | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/drivers/char/hw_random/atmel-rng.c b/drivers/char/hw_random/atmel-rng.c index bf9fc6b..dfeddf2 100644 --- a/drivers/char/hw_random/atmel-rng.c +++ b/drivers/char/hw_random/atmel-rng.c @@ -54,21 +54,14 @@ static int atmel_trng_probe(struct platform_device *pdev) struct resource *res; int ret; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!res) - return -EINVAL; - trng = devm_kzalloc(>dev, sizeof(*trng), GFP_KERNEL); if (!trng) return -ENOMEM; - if (!devm_request_mem_region(>dev, res->start, -resource_size(res), pdev->name)) - return -EBUSY; - - trng->base = devm_ioremap(>dev, res->start, resource_size(res)); - if (!trng->base) - return -EBUSY; + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + trng->base = devm_ioremap_resource(>dev, res); + if (IS_ERR(trng->base)) + return PTR_ERR(trng->base); trng->clk = clk_get(>dev, NULL); if (IS_ERR(trng->clk)) -- 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: [RFC][PATCH 0/5] arch: atomic rework
On Sun, 2014-02-09 at 19:51 -0800, Paul E. McKenney wrote: > On Mon, Feb 10, 2014 at 01:06:48AM +0100, Torvald Riegel wrote: > > On Thu, 2014-02-06 at 20:20 -0800, Paul E. McKenney wrote: > > > On Fri, Feb 07, 2014 at 12:44:48AM +0100, Torvald Riegel wrote: > > > > On Thu, 2014-02-06 at 14:11 -0800, Paul E. McKenney wrote: > > > > > On Thu, Feb 06, 2014 at 10:17:03PM +0100, Torvald Riegel wrote: > > > > > > On Thu, 2014-02-06 at 11:27 -0800, Paul E. McKenney wrote: > > > > > > > On Thu, Feb 06, 2014 at 06:59:10PM +, Will Deacon wrote: > > > > > > > > There are also so many ways to blow your head off it's untrue. > > > > > > > > For example, > > > > > > > > cmpxchg takes a separate memory model parameter for failure and > > > > > > > > success, but > > > > > > > > then there are restrictions on the sets you can use for each. > > > > > > > > It's not hard > > > > > > > > to find well-known memory-ordering experts shouting "Just use > > > > > > > > memory_model_seq_cst for everything, it's too hard otherwise". > > > > > > > > Then there's > > > > > > > > the fun of load-consume vs load-acquire (arm64 GCC completely > > > > > > > > ignores consume > > > > > > > > atm and optimises all of the data dependencies away) as well as > > > > > > > > the definition > > > > > > > > of "data races", which seem to be used as an excuse to > > > > > > > > miscompile a program > > > > > > > > at the earliest opportunity. > > > > > > > > > > > > > > Trust me, rcu_dereference() is not going to be defined in terms of > > > > > > > memory_order_consume until the compilers implement it both > > > > > > > correctly and > > > > > > > efficiently. They are not there yet, and there is currently no > > > > > > > shortage > > > > > > > of compiler writers who would prefer to ignore > > > > > > > memory_order_consume. > > > > > > > > > > > > Do you have any input on > > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448? In particular, > > > > > > the > > > > > > language standard's definition of dependencies? > > > > > > > > > > Let's see... 1.10p9 says that a dependency must be carried unless: > > > > > > > > > > — B is an invocation of any specialization of std::kill_dependency > > > > > (29.3), or > > > > > — A is the left operand of a built-in logical AND (&&, see 5.14) or > > > > > logical OR (||, see 5.15) operator, > > > > > or > > > > > — A is the left operand of a conditional (?:, see 5.16) operator, or > > > > > — A is the left operand of the built-in comma (,) operator (5.18); > > > > > > > > > > So the use of "flag" before the "?" is ignored. But the "flag - flag" > > > > > after the "?" will carry a dependency, so the code fragment in 59448 > > > > > needs to do the ordering rather than just optimizing "flag - flag" out > > > > > of existence. One way to do that on both ARM and Power is to actually > > > > > emit code for "flag - flag", but there are a number of other ways to > > > > > make that work. > > > > > > > > And that's what would concern me, considering that these requirements > > > > seem to be able to creep out easily. Also, whereas the other atomics > > > > just constrain compilers wrt. reordering across atomic accesses or > > > > changes to the atomic accesses themselves, the dependencies are new > > > > requirements on pieces of otherwise non-synchronizing code. The latter > > > > seems far more involved to me. > > > > > > Well, the wording of 1.10p9 is pretty explicit on this point. > > > There are only a few exceptions to the rule that dependencies from > > > memory_order_consume loads must be tracked. And to your point about > > > requirements being placed on pieces of otherwise non-synchronizing code, > > > we already have that with plain old load acquire and store release -- > > > both of these put ordering constraints that affect the surrounding > > > non-synchronizing code. > > > > I think there's a significant difference. With acquire/release or more > > general memory orders, it's true that we can't order _across_ the atomic > > access. However, we can reorder and optimize without additional > > constraints if we do not reorder. This is not the case with consume > > memory order, as the (p + flag - flag) example shows. > > Agreed, memory_order_consume does introduce additional restrictions. > > > > This issue got a lot of discussion, and the compromise is that > > > dependencies cannot leak into or out of functions unless the relevant > > > parameters or return values are annotated with [[carries_dependency]]. > > > This means that the compiler can see all the places where dependencies > > > must be tracked. This is described in 7.6.4. > > > > I wasn't aware of 7.6.4 (but it isn't referred to as an additional > > constraint--what it is--in 1.10, so I guess at least that should be > > fixed). > > Also, AFAIU, 7.6.4p3 is wrong in that the attribute does make a semantic > > difference, at least if one is assuming that normal optimization of > > sequential
[PATCH] regulator: da9055: declare return type of inline function exclusively
da9055_regulator_dt_init does not declare return type and it cause following build warning. drivers/regulator/da9055-regulator.c:582:15: warning: return type defaults to ‘int’ [-Wreturn-type] static inline da9055_regulator_dt_init(struct platform_device *pdev, ^ Fix the warning by declare return type as int exclusively. Signed-off-by: SeongJae Park --- drivers/regulator/da9055-regulator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/da9055-regulator.c b/drivers/regulator/da9055-regulator.c index 3b7a26c..cf74040 100644 --- a/drivers/regulator/da9055-regulator.c +++ b/drivers/regulator/da9055-regulator.c @@ -579,7 +579,7 @@ static int da9055_regulator_dt_init(struct platform_device *pdev, return 0; } #else -static inline da9055_regulator_dt_init(struct platform_device *pdev, +static inline int da9055_regulator_dt_init(struct platform_device *pdev, struct da9055_regulator *regulator, struct regulator_config *config, int regid) -- 1.8.3.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/2] BCM2835: Add dmaengine driver to device tree
On 01/13/2014 04:11 AM, Florian Meier wrote: > This adds the definitions for the BCM2835 dmaengine driver > to the device tree. The dma-channel-mask is currently > fixed. Later it should be set via the firmware. I've applied patch 1, and the part of patch 2 which touches bcm2835.dtsi to bcm2835's for-3.15/dt branch, with minor fixes. -- 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 8/8] cpufreq: ppc: make use of of_find_matching_node_and_match
On 11 February 2014 21:54, Josh Cartwright wrote:
> Instead of the of_find_matching_node()/of_match_node() pair, which requires
> two
> iterations through the match table, make use of
> of_find_matching_node_and_match(),
> which only iterates through the table once.
>
> Signed-off-by: Josh Cartwright
> ---
> drivers/cpufreq/ppc-corenet-cpufreq.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
> b/drivers/cpufreq/ppc-corenet-cpufreq.c
> index 051000f..041ef3a 100644
> --- a/drivers/cpufreq/ppc-corenet-cpufreq.c
> +++ b/drivers/cpufreq/ppc-corenet-cpufreq.c
> @@ -278,7 +278,7 @@ static int __init ppc_corenet_cpufreq_init(void)
> const struct soc_data *data;
> unsigned int cpu;
>
> - np = of_find_matching_node(NULL, node_matches);
> + np = of_find_matching_node_and_match(NULL, node_matches, );
> if (!np)
> return -ENODEV;
>
> @@ -288,7 +288,6 @@ static int __init ppc_corenet_cpufreq_init(void)
> cpumask_copy(per_cpu(cpu_mask, cpu), cpu_core_mask(cpu));
> }
>
> - match = of_match_node(node_matches, np);
> data = match->data;
> if (data) {
> if (data->flag)
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] drm/nouveau: handle -EACCES runtime PM return code
pm_runtime_get*() may return -EACCES to indicate a device does not have runtime PM enabled. This is currently the case with platform devices on Nouveau, and is not an error in that context. Handle this case without failure. Signed-off-by: Alexandre Courbot --- Changes since v1: - Fixed typo and inaccuracy in commit message drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c index 0e3270c3ffd2..1caef1fd139e 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c @@ -1048,7 +1048,7 @@ nouveau_crtc_set_config(struct drm_mode_set *set) /* get a pm reference here */ ret = pm_runtime_get_sync(dev->dev); - if (ret < 0) + if (ret < 0 && ret != -EACCES) return ret; ret = drm_crtc_helper_set_config(set); diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 1674882d60d5..cddef546d9b0 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -255,7 +255,7 @@ nouveau_connector_detect(struct drm_connector *connector, bool force) } ret = pm_runtime_get_sync(connector->dev->dev); - if (ret < 0) + if (ret < 0 && ret != -EACCES) return conn_status; i2c = nouveau_connector_ddc_detect(connector, _encoder); diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index b45fd1a0ab28..c677a09aac3f 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -696,7 +696,7 @@ nouveau_drm_open(struct drm_device *dev, struct drm_file *fpriv) /* need to bring up power immediately if opening device */ ret = pm_runtime_get_sync(dev->dev); - if (ret < 0) + if (ret < 0 && ret != -EACCES) return ret; get_task_comm(tmpname, current); @@ -781,7 +781,7 @@ long nouveau_drm_ioctl(struct file *filp, dev = file_priv->minor->dev; ret = pm_runtime_get_sync(dev->dev); - if (ret < 0) + if (ret < 0 && ret != -EACCES) return ret; ret = drm_ioctl(filp, cmd, arg); -- 1.8.5.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 0/7] ARM: shmobile: r8a7790/Lager QSPI SoC/board integration
Hi Geert, Simon, On Mon, Feb 10, 2014 at 7:47 PM, Geert Uytterhoeven wrote: > Hi Simon, Magnus, > > The following patch series completes r8a7790 SoC and Lager board > integration for the Renesas Quad Serial Peripheral Interface. It brings > r8a7790/Lager to the same support level as r8a7791/Koelsch, allowing access > to the Spansion s25fl512s SPI FLASH for both legacy and multi-platform > kernels. > > [1/7] pinctrl: sh-pfc: r8a7790: Add QSPI pin groups > [2/7] ARM: shmobile: lager legacy: Add QSPI pinmux > [3/7] ARM: shmobile: r8a7790 dtsi: Add QSPI node > [4/7] ARM: shmobile: lager dts: Add QSPI nodes > [5/7] ARM: shmobile: lager defconfig: Enable RSPI and MTD_M25P80 Thanks a lot for this! All patches included in this series look great to me. I noticed that 1/7 turned into a v2, so feel free to omit or include the below ack. Acked-by: Magnus Damm > [6/7] ARM: shmobile: lager legacy: Enable Quad SPI transfers for the SPI > FLASH > [7/7] ARM: shmobile: lager dts: Enable Quad SPI transfers for the SPI > FLASH > > Please do _not_ apply patches [6/7] and [7/7] yet, as these have a runtime > dependency on Quad SPI support in the RSPI/QSPI driver, which is queued up > in the linux-spi tree for v3.15. That makes sense, thanks for pointing that out. You still have my Ack though, so please include that when you resend. Simon, can you please pick up 2-5? Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the tip tree
Hi Stephen,
On 02/12/2014 08:11 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_prolog':
> drivers/cpuidle/cpuidle-pseries.c:32:2: error: implicit declaration of
> function 'ppc64_runlatch_off' [-Werror=implicit-function-declaration]
> ppc64_runlatch_off();
> ^
> drivers/cpuidle/cpuidle-pseries.c: In function 'idle_loop_epilog':
> drivers/cpuidle/cpuidle-pseries.c:52:2: error: implicit declaration of
> function 'ppc64_runlatch_on' [-Werror=implicit-function-declaration]
> ppc64_runlatch_on();
> ^
>
> Caused by commit d8c6ad3184ca ("sched/idle, PPC: Remove redundant
> cpuidle_idle_call()").
Ok so after the commit
d8c6ad3184ca651:sched/idle, PPC: Remove redundant cpuidle_idle_call()
reintroduced ppc64_runlatch_off/on() in drivers/cpuidle/cpuidle-pseries.c
the cleanup caused by the commit "c0c4301c54adde05:pseries/cpuidle:
Remove redundant call to ppc64_runlatch_off() in cpu idle routines"
now needs to be introduced in part.
Below is the patch which should fix this. This is based on top of tip-tree.
Thanks
Regards
Preeti U Murthy
-
cpuidle/pseries: Fix fallout caused due to cleanup in pseries cpuidle backend
driver
From: Preeti U Murthy
Commit "d8c6ad3184ca651:sched/idle, PPC: Remove redundant cpuidle_idle_call()"
reintroduced ppc64_runlatch_off/on() in the pseries cpuidle backend driver.
Hence the cleanup caused by the commit "c0c4301c54adde05:pseries/cpuidle:
Remove redundant call to ppc64_runlatch_off() in cpu idle routines" in
conjuction with the commit d8c6ad3184ca651 causes a build failure.
Signed-off-by: Preeti U Murthy
---
drivers/cpuidle/cpuidle-pseries.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpuidle/cpuidle-pseries.c
b/drivers/cpuidle/cpuidle-pseries.c
index d486489..6f7b019 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
struct cpuidle_driver pseries_idle_driver = {
>
> I have used the tip tree from next-20140210 again today (since
> next-20140211 was broken differently).
>
--
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 V5 4/8] phy: st-miphy-40lp: Add skeleton driver
Hello Arnd, > -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Tuesday, February 11, 2014 8:09 PM > To: Mohit KUMAR DCG > Cc: Pratyush ANAND; Kishon Vijay Abraham I; spear-devel; linux-arm- > ker...@lists.infradead.org; devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org; Lee Jones > Subject: Re: [PATCH V5 4/8] phy: st-miphy-40lp: Add skeleton driver > > On Tuesday 11 February 2014 11:57:46 Mohit KUMAR DCG wrote: > > > > > Maybe mention that this phy is used inside the spear13xx SoC here > > > rather than a standalone phy. > > > > - Yes, for spear13xx its used internally. Do you think that it > > requires to be mentioned here? > > We have few prototype boards that uses this as external phy. > > [adding Lee since he mentioned working on a similar part] > > I'm a bit confused. Is it actually the same IP block that can be used > internally > as part of a SoC and as a standalone chip? > > Since some of the settings of the PHY are controlled through the misc > register in case of spear13xx, I assume that part is different on the > standalone version. How do you actually select the mode in that case? > > It would certainly be helpful to explain this somewhere, and the binding > might not be the worst place for this. > > On a related note, the driver in its current shape looks a bit silly since it > doesn't contain any of the miphy specific code but only the SoC specific parts > (as I suggested you do, so I'm not blaming you :-)) and a multiplexer that > switches between the two possible implementations. - yes, thats what we were explaining earlier. If it is integrated into some SoC Then there are some soc specific configurations. Actual phy reg settings could also vary for the different SoCs for the best tuning. However we agreed to your idea as miphy40lp register definitions would remain same across the SoCs. > > What is your plan for the future, do you intend to add the actual miphy code > soon, or is that something you just want to leave as an option for the future > but have no specific plans to do right now? If not, the driver would probably > look nicer if it were split into two separate implementations, one for each > spear13xx SoC and with a separate set of phy_ops but no multiplexer. Do you want it to split the code into two different files like phy-miphyspear1310.c and phy-miphyspear1340.c ? Regards Mohit -- 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] Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE
On Tue, 11 Feb 2014 08:27:38 +0100 Ingo Molnar wrote: > > * Mathieu Desnoyers wrote: > > > Users have reported being unable to trace non-signed modules loaded > > within a kernel supporting module signature. > > External modules should strive to get out of the 'crap' and > 'felony law breaker' categories and we should not make it > easier for them to linger in a broken state. > > Nacked-by: Ingo Molnar I'm not sure how great this idea is, but it isn't the same as the "crap" and "fenony law breaker" categories. Having a non-signed module doesn't mean that it isn't fully GPL compliant, it just means that it hasn't been signed. There's several things that can taint the kernel when loading a module. Being non GPL compliant is just one of them, and that will never be allowed to accept tracepoints. Forcing a module that was built for a different kernel version gives us another taint, which we don't add tracepoints for, not because it is not compliant, but because that could corrupt the kernel as we can not guarantee the binary structure layout of those modules would be the same as what the kernel was built with. We don't want people complaining about tracepoint failures due to forcing an older module into a newer kernel with different tracepoint structures. But if the kernel expects to have signed modules, and you force a module to be loaded that is not signed, then you still get that "forced" module taint, which is the same one as loading a module from an older kernel into a newer kernel. It's a different problem, and I can see having a different taint flag be more informative to kernel developers in general. I would welcome that change with or without letting tracepoints be set for that module. But I have to ask Mathieu, what exactly is the use case here? If you have a kernel that expects to only load signed modules, why would you want to force non signed ones? That basically breaks the whole purpose of signing modules. Once you allow a non signed module to be loaded then the kernel can be considered compromised. That is, you just gave kernel access to an untrusted source. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6] mfd: MAX6650/6651 support
Hi Laszlo,
Sorry for missing out on a couple of points during my earlier review.
Please see inline.
On 12 February 2014 09:32, Laszlo Papp wrote:
> MAX6650/MAX6651 chip is a multi-function device with I2C busses. The
> chip includes fan-speed regulators and monitors, GPIO, and alarm.
>
> This patch is an initial release of a MAX6650/6651 MFD driver that
> supports to enable the chip with its primary I2C bus that will connect
> the hwmon, and then the gpio devices for now.
>
> Signed-off-by: Laszlo Papp
> ---
[snip]
> --- /dev/null
> +++ b/drivers/mfd/max665x.c
> @@ -0,0 +1,87 @@
> +/*
> + * Device access for MAX6650-MAX6651
> + *
> + * Copyright(c) 2013 Polatis Ltd.
> + *
> + * Author: Laszlo Papp
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +static struct mfd_cell max665x_devs[] = {
> + { .name = "max6651-gpio", },
> + { .name = "max6650", }, /* hwmon driver */
> + {},
> +};
> +
> +const struct regmap_config max665x_regmap_config = {
> + .reg_bits = 5,
> +};
This should be static.
> +static int max665x_probe(struct i2c_client *i2c,
> + const struct i2c_device_id *id)
> +{
> + struct max665x_dev *max665x;
> + int ret;
> +
> + max665x = devm_kzalloc(>dev, sizeof(*max665x), GFP_KERNEL);
> + if (!max665x)
> + return -ENOMEM;
> +
> + i2c_set_clientdata(i2c, max665x);
> + max665x->dev = >dev;
> + max665x->i2c = i2c;
> + max665x->map = devm_regmap_init_i2c(i2c, _regmap_config);
Don't you need to check the return value of devm_regmap_init_i2c?
--
With warm regards,
Sachin
--
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] cpufreq: cpu0: drop selecting of THERMAL and THERMAL_CPU
On 12 February 2014 00:03, Rob Herring wrote: > From: Rob Herring > > The addition of THERMAL and THERMAL_CPU selections causes a kconfig > warning on highbank platforms: > > warning: (ARM_HIGHBANK_CPUFREQ) selects GENERIC_CPUFREQ_CPU0 which has > unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && HAVE_CLK && > REGULATOR && OF && THERMAL && CPU_THERMAL) > > The cpufreq-cpu0 driver does not require thermal zone support to > function as highbank does not need these, so drop selecting of THERMAL > and CPU_THERMAL. > > Reported-by: Olof Johansson > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Cc: cpuf...@vger.kernel.org > Signed-off-by: Rob Herring > --- > v2: > - just drop selecting THERMAL and THERMAL_CPU instead of a new kconfig > option > > Dropping REGULATOR doesn't build w/o some empty regulator functions, so > that's 3.15 material. > > Rob > > drivers/cpufreq/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig > index 4b029c0..d100926 100644 > --- a/drivers/cpufreq/Kconfig > +++ b/drivers/cpufreq/Kconfig > @@ -185,7 +185,7 @@ config CPU_FREQ_GOV_CONSERVATIVE > > config GENERIC_CPUFREQ_CPU0 > tristate "Generic CPU0 cpufreq driver" > - depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL > + depends on HAVE_CLK && REGULATOR && OF > select PM_OPP > help > This adds a generic cpufreq driver for CPU0 frequency management. Acked-by: Viresh Kumar -- 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/
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here is some powerpc goodness for -rc2. Arguably -rc1 material more than -rc2 but I was travelling (again !) It's mostly bug fixes including regressions, but there are a couple of new things that I decided to drop-in. One is a straightforward patch from Michael to add a bunch of P8 cache events to perf. The other one is a patch by myself to add the direct DMA (iommu bypass) for PCIe on Power8 for 64-bit capable devices. This has been around for a while, I had lost track of it. However it's been in our internal kernels we use for testing P8 already and it affects only P8 related code. Since P8 is still unreleased the risk is pretty much nil at this point. Cheers, Ben. The following changes since commit b28a960c42fcd9cfc987441fa6d1c1a471f0f9ed: Linux 3.14-rc2 (2014-02-09 18:15:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to cd15b048445d0a54f7147c35a86c5a16ef231554: powerpc/powernv: Add iommu DMA bypass support for IODA2 (2014-02-11 16:07:37 +1100) Anshuman Khandual (1): powerpc/perf: Configure BHRB filter before enabling PMU interrupts Anton Blanchard (1): powerpc: Fix endian issues in kexec and crash dump code Benjamin Herrenschmidt (1): powerpc/powernv: Add iommu DMA bypass support for IODA2 Kevin Hao (1): powerpc/ppc32: Fix the bug in the init of non-base exception stack for UP Laurent Dufour (1): powerpc/relocate fix relocate processing in LE mode Mahesh Salgaonkar (2): powerpc/pseries: Disable relocation on exception while going down during crash. powerpc: Fix kdump hang issue on p8 with relocation on exception enabled. Michael Ellerman (5): powerpc/perf: Add Power8 cache & TLB events powerpc/pseries: Select ARCH_RANDOM on pseries powerpc/xmon: Don't loop forever in get_output_lock() powerpc/xmon: Fix timeout loop in get_output_lock() powerpc/xmon: Don't signal we've entered until we're finished printing Nathan Fontenot (1): crypto/nx/nx-842: Fix handling of vmalloc addresses Paul Gortmaker (1): powerpc: Fix build failure in sysdev/mpic.c for MPIC_WEIRD=y Thadeu Lima de Souza Cascardo (1): powerpc/eeh: Drop taken reference to driver on eeh_rmv_device arch/powerpc/include/asm/dma-mapping.h| 1 + arch/powerpc/include/asm/iommu.h | 1 + arch/powerpc/include/asm/sections.h | 12 +++ arch/powerpc/kernel/dma.c | 10 ++- arch/powerpc/kernel/eeh_driver.c | 8 +- arch/powerpc/kernel/iommu.c | 12 +++ arch/powerpc/kernel/irq.c | 5 ++ arch/powerpc/kernel/machine_kexec.c | 14 ++- arch/powerpc/kernel/machine_kexec_64.c| 6 +- arch/powerpc/kernel/reloc_64.S| 4 +- arch/powerpc/kernel/setup_32.c| 5 ++ arch/powerpc/mm/hash_utils_64.c | 14 +++ arch/powerpc/perf/core-book3s.c | 5 +- arch/powerpc/perf/power8-pmu.c| 144 ++ arch/powerpc/platforms/powernv/pci-ioda.c | 84 + arch/powerpc/platforms/powernv/pci.c | 10 +++ arch/powerpc/platforms/powernv/pci.h | 6 +- arch/powerpc/platforms/powernv/powernv.h | 8 ++ arch/powerpc/platforms/powernv/setup.c| 9 ++ arch/powerpc/platforms/pseries/Kconfig| 1 + arch/powerpc/platforms/pseries/setup.c| 3 +- arch/powerpc/sysdev/mpic.c| 38 arch/powerpc/xmon/xmon.c | 24 +++-- drivers/crypto/nx/nx-842.c| 29 +++--- 24 files changed, 398 insertions(+), 55 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 v7 0/2] AS3935 lightning sensor support
This series adds support for the AMS AS3935 lightning sensor that allows reporting back estimated storm distance and strike events. Chagges from v6 * Revised binding documents to not use the term "interrupts mapping" * Renamed tune-cap property to a more clear tuning-capacitor-pf Changes from v5 * SPI write cache-aligned issues fixed * Fixed mutex_unlock's being missed * Reports distance in meters instead of kilometers (1km steps) * tune_cap is now in picofarads and not a register value Matt Ranostay (2): iio:as3935: Add DT binding docs for AS3935 driver iio: Add AS3935 lightning sensor support .../ABI/testing/sysfs-bus-iio-proximity-as3935 | 18 + .../devicetree/bindings/iio/proximity/as3935.txt | 28 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/iio/Kconfig| 1 + drivers/iio/Makefile | 1 + drivers/iio/proximity/Kconfig | 19 + drivers/iio/proximity/Makefile | 6 + drivers/iio/proximity/as3935.c | 446 + 8 files changed, 520 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 create mode 100644 Documentation/devicetree/bindings/iio/proximity/as3935.txt create mode 100644 drivers/iio/proximity/Kconfig create mode 100644 drivers/iio/proximity/Makefile create mode 100644 drivers/iio/proximity/as3935.c -- 1.8.3.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/
[PATCH v7 2/2] iio: Add AS3935 lightning sensor support
AS3935 chipset can detect lightning strikes and reports those back as events and the estimated distance to the storm. Signed-off-by: Matt Ranostay --- .../ABI/testing/sysfs-bus-iio-proximity-as3935 | 18 + drivers/iio/Kconfig| 1 + drivers/iio/Makefile | 1 + drivers/iio/proximity/Kconfig | 19 + drivers/iio/proximity/Makefile | 6 + drivers/iio/proximity/as3935.c | 446 + 6 files changed, 491 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 create mode 100644 drivers/iio/proximity/Kconfig create mode 100644 drivers/iio/proximity/Makefile create mode 100644 drivers/iio/proximity/as3935.c diff --git a/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 new file mode 100644 index 000..fc92bce --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 @@ -0,0 +1,18 @@ +What /sys/bus/iio/devices/iio:deviceX/in_proximity_raw +Date: January 2014 +KernelVersion: 3.15 +Contact: Matt Ranostay +Description: + Get the current distance in meters of storm (1km steps) + 1000 = storm overhead + 1000-4 = distance in meters + 63000 = out of range + +What /sys/bus/iio/devices/iio:deviceX/gain_boost +Date: January 2014 +KernelVersion: 3.15 +Contact: Matt Ranostay +Description: + Show or set the gain boost of the amp, from 0-31 range. + 18 = indoors (default) + 14 = outdoors diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig index 5dd0e12..743485e 100644 --- a/drivers/iio/Kconfig +++ b/drivers/iio/Kconfig @@ -74,6 +74,7 @@ if IIO_TRIGGER source "drivers/iio/trigger/Kconfig" endif #IIO_TRIGGER source "drivers/iio/pressure/Kconfig" +source "drivers/iio/proximity/Kconfig" source "drivers/iio/temperature/Kconfig" endif # IIO diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile index 887d390..698afc2 100644 --- a/drivers/iio/Makefile +++ b/drivers/iio/Makefile @@ -24,5 +24,6 @@ obj-y += light/ obj-y += magnetometer/ obj-y += orientation/ obj-y += pressure/ +obj-y += proximity/ obj-y += temperature/ obj-y += trigger/ diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig new file mode 100644 index 000..0c8cdf5 --- /dev/null +++ b/drivers/iio/proximity/Kconfig @@ -0,0 +1,19 @@ +# +# Proximity sensors +# + +menu "Lightning sensors" + +config AS3935 + tristate "AS3935 Franklin lightning sensor" + select IIO_BUFFER + select IIO_TRIGGERED_BUFFER + depends on SPI + help + Say Y here to build SPI interface support for the Austrian + Microsystems AS3935 lightning detection sensor. + + To compile this driver as a module, choose M here: the + module will be called as3935 + +endmenu diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile new file mode 100644 index 000..743adee --- /dev/null +++ b/drivers/iio/proximity/Makefile @@ -0,0 +1,6 @@ +# +# Makefile for IIO proximity sensors +# + +# When adding new entries keep the list in alphabetical order +obj-$(CONFIG_AS3935) += as3935.o diff --git a/drivers/iio/proximity/as3935.c b/drivers/iio/proximity/as3935.c new file mode 100644 index 000..75ef034 --- /dev/null +++ b/drivers/iio/proximity/as3935.c @@ -0,0 +1,446 @@ +/* + * as3935.c - Support for AS3935 Franklin lightning sensor + * + * Copyright (C) 2014 Matt Ranostay + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#define AS3935_AFE_GAIN0x00 +#define AS3935_AFE_MASK0x3F +#define AS3935_AFE_GAIN_MAX0x1F +#define AS3935_AFE_PWR_BIT BIT(0) + +#define AS3935_INT 0x03 +#define AS3935_INT_MASK0x07 +#define AS3935_EVENT_INT BIT(3) +#define AS3935_NOISE_INT BIT(1) + +#define AS3935_DATA0x07 +#define AS3935_DATA_MASK 0x3F + +#define AS3935_TUNE_CAP0x08 +#define AS3935_CALIBRATE 0x3D + +#define AS3935_WRITE_DATA BIT(15) +#define AS3935_READ_DATA BIT(14) +#define
[PATCH v7 1/2] iio:as3935: Add DT binding docs for AS3935 driver
Document compatible string, required and optional DT properties for
AS3935 chipset driver.
Signed-off-by: Matt Ranostay
---
.../devicetree/bindings/iio/proximity/as3935.txt | 28 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
2 files changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/proximity/as3935.txt
diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt
b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
new file mode 100644
index 000..ae23dd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
@@ -0,0 +1,28 @@
+Austrian Microsystems AS3935 Franklin lightning sensor device driver
+
+Required properties:
+ - compatible: must be "ams,as3935"
+ - reg: SPI chip select number for the device
+ - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
+ slave node bindings.
+ - interrupt-parent : should be the phandle for the interrupt controller
+ - interrupts : the sole interrupt generated by the device
+
+ Refer to interrupt-controller/interrupts.txt for generic
+ interrupt client node bindings.
+
+Optional properties:
+ - ams,tuning-capacitor-pf: Calibration tuning capacitor stepping
+ value 0 - 120pF. This will require using the calibration data from
+ the manufacturer.
+
+Example:
+
+as3935@0 {
+ compatible = "ams,as3935";
+ reg = <0>;
+ spi-cpha;
+ interrupt-parent = <>;
+ interrupts = <16 1>;
+ ams,tuning-capacitor-pf = <80>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index e9d19e2..03e50ff 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -11,6 +11,7 @@ akAsahi Kasei Corp.
allwinner Allwinner Technology Co., Ltd.
altr Altera Corp.
amcc Applied Micro Circuits Corporation (APM, formally AMCC)
+amsAMS AG
amstaosAMS-Taos Inc.
apmApplied Micro Circuits Corporation (APM)
armARM Ltd.
--
1.8.3.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: [GIT PULL] x86, apic: Remove support for Summit and ES7000
On 02/11/2014 06:53 PM, David Rientjes wrote: > Hi Ingo, Peter, and Thomas, > > [ Be aware of bouncing emails on the cc, it includes the last-known email >addresses of the authors of these subarchitectures and may bounce. ] > > If you agree, please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/rientjes/linux.git x86/apic > > # HEAD: 7cf6c94591bbf3dbe3bf9573a6551328ad76d885 x86, apic: Remove support > for IBM Summit/EXA chipset > > or apply individually. This branch is based on x86/apic. > > This is the removal of Summit and ES7000 subarchitectures from x86. I'd > like to do the same for NumaQ, but am still researching if we can really > do away with it. Nice. -hpa -- 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.13 000/120] 3.13.3-stable review
On Tue, Feb 11, 2014 at 11:04:01AM -0800, Greg Kroah-Hartman wrote: > Some -stable releases spring out from my build system bright and shiny > and ready to go. Not so with these releases. Maybe it's the horrid > weather that was happening during the creation of these kernels, or > something else, but whatever it was, they came into this world > screaming, kicking, killing build servers left-and-right, and breaking > the build every other patch. Some developers decided to get into the > act, constantly pushing the boundaries of what is an acceptable -stable > patch, and trying to skirt the rules of upstream patches first numerous > times, making me even grumpier than normal, "forcing" me to relax and > take in an afternoon playing of the Lego movie... > Come on, compared to me you are never grumpy. > Test these out well, they have barely survived my systems, and I don't > trust them in the slightest to not eat your disks, reap your tasks, and > run away laughing as your CPU turns into a space heater. > > You have been warned. > Hmm ... not sure if I want to take that risk :-). Going to be fun. And looking for volunteers to provide me with a really great test suite which I can run in qemu (and which doesn't take me days to set up). > - > > This is the start of the stable review cycle for the 3.13.3 release. > There are 120 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Feb 13 18:47:55 UTC 2014. > Anything received after that time might be too late. > Build results: total: 126 pass: 122 skipped: 4 fail: 0 qemu tests all passed. Results are as expected (even though that may be unexpected in this case ;-). Details are available at http://server.roeck-us.net:8010/builders. Guenter -- 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: 3.14-rc2 XFS backtrace because irqs_disabled.
On Tue, Feb 11, 2014 at 11:03:58PM -0500, Dave Jones wrote: > [ 3111.414202] [] bio_alloc_bioset+0x156/0x210 > [ 3111.414855] [] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs] > [ 3111.415517] [] ? xlog_bdstrat+0x22/0x60 [xfs] > [ 3111.416175] [] xfs_buf_iorequest+0x6b/0xf0 [xfs] > [ 3111.416843] [] xlog_bdstrat+0x22/0x60 [xfs] > [ 3111.417509] [] xlog_sync+0x3a7/0x5b0 [xfs] > [ 3111.418175] [] xlog_state_release_iclog+0x10f/0x120 > [xfs] > [ 3111.418846] [] xlog_write+0x6f0/0x800 [xfs] > [ 3111.419518] [] xlog_cil_push+0x2f1/0x410 [xfs] Very interesting. The first thing xlog_cil_push() is doing is blocking kmalloc(). So at that point it still hadn't been atomic. I'd probably slap may_sleep() in the beginning of xlog_sync() and see if that triggers... -- 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.10 00/79] 3.10.30-stable review
On Tue, Feb 11, 2014 at 11:05:04AM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.10.30 release. > There are 79 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Feb 13 18:46:56 UTC 2014. > Anything received after that time might be too late. > Build results: total: 126 pass: 121 skipped: 4 fail: 1 qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- 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.12 000/107] 3.12.11-stable review
On Tue, Feb 11, 2014 at 11:04:26AM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.12.11 release. > There are 107 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Feb 13 18:47:29 UTC 2014. > Anything received after that time might be too late. > Build results: total: 126 pass: 121 skipped: 5 fail: 0 qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- 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.4 00/30] 3.4.80-stable review
On Tue, Feb 11, 2014 at 11:06:00AM -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.4.80 release. > There are 30 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Feb 13 18:46:37 UTC 2014. > Anything received after that time might be too late. > Build results: total: 119 pass: 97 skipped: 18 fail: 4 qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- 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: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
On Tue, 2014-02-11 at 18:07 -0800, Dan Williams wrote: > The overlap granularity is too large. Multiple dma_map_single > mappings are allowed to a given page as long as they don't collide on > the same cache line. > I am not sure why you try number of mappings of a page. Try launching 100 concurrent netperf -t TCP_SENFILE Same page might be mapped more than 100 times, more than 1 times in some cases. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V6 07/12] phy: st-miphy-40lp: Add SPEAr1310 and SPEAr1340 PCIe phy support
Hello Kishon,
> -Original Message-
> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
> Sent: Tuesday, February 11, 2014 5:36 PM
> To: Mohit KUMAR DCG; a...@arndb.de
> Cc: Pratyush ANAND; Viresh Kumar; spear-devel; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH V6 07/12] phy: st-miphy-40lp: Add SPEAr1310 and
> SPEAr1340 PCIe phy support
>
> On Tuesday 11 February 2014 03:00 PM, Mohit Kumar wrote:
> > From: Pratyush Anand
> >
> > SPEAr1310 and SPEAr1340 uses miphy40lp phy for PCIe. This driver adds
> > support for the same.
>
> What's up with SATA support for SPEAr1310? Do you have plans of adding it
> soon?
> >
- yes we will be doing it after this series is finalized.
[...]
> > +
> > + regmap_update_bits(priv->misc, SPEAR1310_PCIE_MIPHY_CFG_1,
> > + SPEAR1310_PCIE_SATA_MIPHY_CFG_PCIE_MASK,
> > + SPEAR1310_PCIE_SATA_MIPHY_CFG_PCIE);
> > +
> > + switch (priv->id) {
>
> 'id' should be made as optional dt property since it's not used for 1340 no?
>
- ok
Thanks
Mohit
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: 3.14-rc2 XFS backtrace because irqs_disabled.
On Tue, Feb 11, 2014 at 06:52:19PM -0800, Linus Torvalds wrote:
> On Tue, Feb 11, 2014 at 5:09 PM, Al Viro wrote:
> >
> > Slap the check in vfs_create(), see if interrupts had been disabled by it
> > or
> > by something in ->create(). Since it's reproducible...
>
> path_openat() starts off with a get_empty_filp(), which allocates a
> file pointer with GFP_KERNEL. So that should have triggered the
> might_sleep warning if irq's were already disabled at that point.
>
> So it's not before that - in particular, it's not in the signal
> handling or do_coredump() paths.
>
> Also, at least xfs_buf_lock() - which is much deeper in that chain -
> does a down(>b_sema). I'm disguested that that doesn't have a
> might_sleep() in it.
>
> Dave, mind adding a "might_sleep()" to the top of
> "down[_interruptible]()". It's silly to not have coverage of semaphore
> use in bad contexts.
Added those, didn't trigger. Neither did Al's suggestion.
Slightly different trace, but still from the coredump path.
Dave
[ 3111.403822] BUG: sleeping function called from invalid context at
mm/mempool.c:203
[ 3111.404414] in_atomic(): 0, irqs_disabled(): 1, pid: 19213, name: trinity-c46
[ 3111.404884] 5 locks held by trinity-c46/19213:
[ 3111.405354] #0: (sb_writers#9){..}, at: []
do_coredump+0xe05/0xf60
[ 3111.405862] #1: (shrinker_rwsem){..}, at: []
shrink_slab+0x3f/0x180
[ 3111.406374] #2: (>s_umount_key#30){..}, at: []
grab_super_passive+0x44/0x90
[ 3111.406905] #3: (>pag_ici_reclaim_lock){..}, at:
[] xfs_reclaim_inodes_ag+0x31a/0x430 [xfs]
[ 3111.407466] #4: (&(>i_lock)->mr_lock){..}, at:
[] xfs_ilock+0x16f/0x1b0 [xfs]
[ 3111.408039] CPU: 0 PID: 19213 Comm: trinity-c46 Not tainted 3.14.0-rc2+ #113
[ 3111.409779] 8da3fde6 4f998871 88023715cce0
8d72b091
[ 3111.410396] 88023715cd08 8d09ddb5
0010
[ 3111.411021] 880243566288 0008 88023715cd88
8d1534f3
[ 3111.411656] Call Trace:
[ 3111.412283] [] dump_stack+0x4e/0x7a
[ 3111.412922] [] __might_sleep+0x105/0x150
[ 3111.413562] [] mempool_alloc+0xa3/0x170
[ 3111.414202] [] bio_alloc_bioset+0x156/0x210
[ 3111.414855] [] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
[ 3111.415517] [] ? xlog_bdstrat+0x22/0x60 [xfs]
[ 3111.416175] [] xfs_buf_iorequest+0x6b/0xf0 [xfs]
[ 3111.416843] [] xlog_bdstrat+0x22/0x60 [xfs]
[ 3111.417509] [] xlog_sync+0x3a7/0x5b0 [xfs]
[ 3111.418175] [] xlog_state_release_iclog+0x10f/0x120 [xfs]
[ 3111.418846] [] xlog_write+0x6f0/0x800 [xfs]
[ 3111.419518] [] xlog_cil_push+0x2f1/0x410 [xfs]
[ 3111.420195] [] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
[ 3111.420865] [] ? __bit_spin_unlock.constprop.66+0x19/0x40
[ 3111.421551] [] _xfs_log_force_lsn+0x93/0x340 [xfs]
[ 3111.422239] [] xfs_log_force_lsn+0x2e/0xb0 [xfs]
[ 3111.422932] [] ? xfs_iunpin_wait+0x19/0x20 [xfs]
[ 3111.423625] [] __xfs_iunpin_wait+0xd0/0x1a0 [xfs]
[ 3111.424310] [] ? autoremove_wake_function+0x40/0x40
[ 3111.425008] [] xfs_iunpin_wait+0x19/0x20 [xfs]
[ 3111.425705] [] xfs_reclaim_inode+0x8c/0x380 [xfs]
[ 3111.426405] [] xfs_reclaim_inodes_ag+0x27b/0x430 [xfs]
[ 3111.427104] [] ? xfs_reclaim_inodes_ag+0x100/0x430 [xfs]
[ 3111.427797] [] xfs_reclaim_inodes_nr+0x33/0x40 [xfs]
[ 3111.428481] [] xfs_fs_free_cached_objects+0x15/0x20 [xfs]
[ 3111.429150] [] super_cache_scan+0x16c/0x180
[ 3111.429824] [] shrink_slab_node+0x14b/0x2e0
[ 3111.430489] [] ? shrink_slab+0x3f/0x180
[ 3111.431146] [] shrink_slab+0x8e/0x180
[ 3111.431796] [] try_to_free_pages+0x516/0x970
[ 3111.432436] [] ? __set_page_dirty+0x27/0xc0
[ 3111.433065] [] __alloc_pages_nodemask+0x7a9/0xb00
[ 3111.433689] [] alloc_pages_current+0x106/0x1f0
[ 3111.434304] [] ? pte_alloc_one+0x17/0x80
[ 3111.434911] [] pte_alloc_one+0x17/0x80
[ 3111.435510] [] __pte_alloc+0x27/0x130
[ 3111.436098] [] handle_mm_fault+0xafc/0xbb0
[ 3111.436681] [] __get_user_pages+0x1ce/0x620
[ 3111.437254] [] get_dump_page+0x54/0x80
[ 3111.437810] [] elf_core_dump+0x12d9/0x1420
[ 3111.438356] [] ? elf_core_dump+0x860/0x1420
[ 3111.438884] [] do_coredump+0xc02/0xf60
[ 3111.439398] [] get_signal_to_deliver+0x2b8/0x6b0
[ 3111.439898] [] do_signal+0x57/0x9d0
[ 3111.440386] [] ? __acct_update_integrals+0x8e/0x120
[ 3111.440873] [] ? preempt_count_sub+0x6b/0xf0
[ 3111.441357] [] ? _raw_spin_unlock+0x31/0x50
[ 3111.441833] [] ? vtime_account_user+0x91/0xa0
[ 3111.442307] [] ? context_tracking_user_exit+0x9b/0x100
[ 3111.442783] [] do_notify_resume+0x5c/0xa0
[ 3111.443260] [] retint_signal+0x46/0x90
[ 3111.443773] [ cut here ]
[ 3111.444248] WARNING: CPU: 0 PID: 19213 at block/blk.h:227
generic_make_request_checks+0x33f/0x460()
[ 3111.444742] Modules linked in: fuse can_bcm can_raw scsi_transport_iscsi
ipt_ULOG nfnetlink nfc caif_socket caif af_802154 phonet af_rxrpc can pppoe
pppox ppp_generic slhc irda crc_ccitt rds rose x25 atm netrom appletalk ipx
[PATCH v6] mfd: MAX6650/6651 support
MAX6650/MAX6651 chip is a multi-function device with I2C busses. The
chip includes fan-speed regulators and monitors, GPIO, and alarm.
This patch is an initial release of a MAX6650/6651 MFD driver that
supports to enable the chip with its primary I2C bus that will connect
the hwmon, and then the gpio devices for now.
Signed-off-by: Laszlo Papp
---
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile| 1 +
drivers/mfd/max665x.c | 87 +
include/linux/mfd/max665x-private.h | 34 +++
4 files changed, 133 insertions(+)
create mode 100644 drivers/mfd/max665x.c
create mode 100644 include/linux/mfd/max665x-private.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 49bb445..a6c3152 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -368,6 +368,17 @@ config MFD_MAX8907
accessing the device; additional drivers must be enabled in order
to use the functionality of the device.
+config MFD_MAX665X
+ bool "Maxim Semiconductor MAX6650/MAX6651 Support"
+ depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ Say yes here to add support for Maxim Semiconductor MAX6650/MAX6651.
This
+ is a fan speed regulator and monitor IC. This driver provides common
+ support for accessing the device, additional drivers must be enabled
in
+ order to use the functionality of the device.
+
config MFD_MAX8925
bool "Maxim Semiconductor MAX8925 PMIC Support"
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5aea5ef..63668c5 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -111,6 +111,7 @@ obj-$(CONFIG_MFD_DA9055)+= da9055.o
da9063-objs:= da9063-core.o da9063-irq.o da9063-i2c.o
obj-$(CONFIG_MFD_DA9063) += da9063.o
+obj-$(CONFIG_MFD_MAX665X) += max665x.o
obj-$(CONFIG_MFD_MAX14577) += max14577.o
obj-$(CONFIG_MFD_MAX77686) += max77686.o max77686-irq.o
obj-$(CONFIG_MFD_MAX77693) += max77693.o max77693-irq.o
diff --git a/drivers/mfd/max665x.c b/drivers/mfd/max665x.c
new file mode 100644
index 000..bf4f595
--- /dev/null
+++ b/drivers/mfd/max665x.c
@@ -0,0 +1,87 @@
+/*
+ * Device access for MAX6650-MAX6651
+ *
+ * Copyright(c) 2013 Polatis Ltd.
+ *
+ * Author: Laszlo Papp
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+static struct mfd_cell max665x_devs[] = {
+ { .name = "max6651-gpio", },
+ { .name = "max6650", }, /* hwmon driver */
+ {},
+};
+
+const struct regmap_config max665x_regmap_config = {
+ .reg_bits = 5,
+};
+
+static int max665x_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+ struct max665x_dev *max665x;
+ int ret;
+
+ max665x = devm_kzalloc(>dev, sizeof(*max665x), GFP_KERNEL);
+ if (!max665x)
+ return -ENOMEM;
+
+ i2c_set_clientdata(i2c, max665x);
+ max665x->dev = >dev;
+ max665x->i2c = i2c;
+ max665x->map = devm_regmap_init_i2c(i2c, _regmap_config);
+
+ mutex_init(>iolock);
+
+ ret = mfd_add_devices(max665x->dev, -1, max665x_devs,
+ ARRAY_SIZE(max665x_devs),
+ NULL, 0, NULL);
+
+ if (ret < 0)
+ dev_err(max665x->dev, "failed to register child devices\n");
+
+ return ret;
+}
+
+static int max665x_remove(struct i2c_client *i2c)
+{
+ struct max665x_dev *max665x = i2c_get_clientdata(i2c);
+
+ mfd_remove_devices(max665x->dev);
+
+ return 0;
+}
+
+static struct of_device_id max665x_dt_match[] = {
+ { .compatible = "maxim,max665x" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, max665x_dt_match);
+
+static struct i2c_driver max665x_driver = {
+ .driver = {
+ .name = "max665x",
+ .owner = THIS_MODULE,
+ .of_match_table = max665x_dt_match,
+ },
+ .probe = max665x_probe,
+ .remove = max665x_remove,
+};
+
+module_i2c_driver(max665x_driver);
+
+MODULE_AUTHOR("Laszlo Papp ");
+MODULE_DESCRIPTION("MAX6650-MAX6651 MFD");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/max665x-private.h
b/include/linux/mfd/max665x-private.h
new file mode 100644
index 000..293db4b
--- /dev/null
+++ b/include/linux/mfd/max665x-private.h
@@ -0,0 +1,34 @@
+/*
+ * max665x-private.h - Driver for the Maxim 6650/6651
+ *
+ * Copyright 2013 Polatis Ltd.
+ *
+ * Author: Laszlo Papp
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software
Re: [PATCH 0/4] hugetlb: add hugepagesnid= command-line option
On Wed, 12 Feb 2014, Andi Kleen wrote: > > The real syntax is hugepagesnid=nid,nr-pages,size. Which looks > > straightforward > > to me. I honestly can't think of anything better than that, but I'm open for > > suggestions. > > hugepages_node=nid:nr-pages:size,... ? > I think that if we actually want this support that it should behave like hugepages= and hugepagesz=, i.e. you specify a hugepagesnode= and, if present, all remaining hugepages= and hugepagesz= parameters act only on that node unless overridden by another hugepagesnode=. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] hugetlb: add hugepagesnid= command-line option
On Tue, 11 Feb 2014, Luiz Capitulino wrote: > > > HugeTLB command-line option hugepages= allows the user to specify how many > > > huge pages should be allocated at boot. On NUMA systems, this argument > > > automatically distributes huge pages allocation among nodes, which can > > > be undesirable. > > > > > > > And when hugepages can no longer be allocated on a node because it is too > > small, the remaining hugepages are distributed over nodes with memory > > available, correct? > > No. hugepagesnid= tries to obey what was specified by the uses as much as > possible. I'm referring to what I quoted above, the hugepages= parameter. I'm saying that using existing functionality you can reserve an excess of hugepages and then free unneeded hugepages at runtime to get the desired amount allocated only on a specific node. > > Strange, it would seem better to just reserve as many hugepages as you > > want so that you get the desired number on each node and then free the > > ones you don't need at runtime. > > You mean, for example, if I have a 2 node system and want 2 1G huge pages > from node 1, then I have to allocate 4 1G huge pages and then free 2 pages > on node 0 after boot? That seems very cumbersome to me. Besides, what if > node0 needs this memory during boot? > All of this functionality, including the current hugepages= reservation at boot, needs to show that it can't be done as late as when you could run an initscript to do the reservation at runtime and fragmentation is at its lowest level when userspace first becomes available. I don't see any justification given in the patchset that suggests you can't simply do this in an initscript if it is possible to allocate 1GB pages at runtime. If it's too late because of oom, then your userspace is going to oom anyway if you reserve the hugepages at boot; if it's too late because of fragmentation, let's work on that issue (and justification why things like movablecore= don't work for you). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] sys: Replace hardcoding of -20 and 19 with MIN_NICE and MAX_NICE.
Hi Kees, On 02/12/2014 02:27 AM, Kees Cook wrote: On Mon, Feb 10, 2014 at 11:34 PM, Dongsheng Yang wrote: Signed-off-by: Dongsheng Yang cc: Andrew Morton cc: Oleg Nesterov cc: Robin Holt cc: Al Viro cc: Kees Cook cc: "Eric W. Biederman" cc: Stephen Rothwell cc: Peter Zijlstra cc: Ingo Molnar --- kernel/sys.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/sys.c b/kernel/sys.c index c0a58be..adaeab6 100644 --- a/kernel/sys.c +++ b/kernel/sys.c @@ -174,10 +174,10 @@ SYSCALL_DEFINE3(setpriority, int, which, int, who, int, niceval) /* normalize: avoid signed division (rounding problems) */ error = -ESRCH; - if (niceval < -20) - niceval = -20; - if (niceval > 19) - niceval = 19; + if (niceval < MIN_NICE) + niceval = MIN_NICE; + if (niceval > MAX_NICE) + niceval = MAX_NICE; Good catch! I'm all for using names instead of numeric values, however, I wonder if it'd be more readable to use "clamp" instead? niceval = clamp(niceval, MIN_NICE, MAX_NICE); Good suggestion! This patch here is just to replace the numeric values with a name defined in prio.h. So I will send another patch to make it more readable with clamp after the patch set here applied. Is this plan ok to you? Thanx. -Kees rcu_read_lock(); read_lock(_lock); -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] hugetlb: add hugepagesnid= command-line option
(2014/02/11 2:27), Luiz Capitulino wrote:
> From: Luiz capitulino
>
> The HugeTLB command-line option hugepages= allow the user to specify
> how many huge pages should be allocated at boot-time. On NUMA systems,
> this option will try to automatically distribute the allocation equally
> among nodes. For example, if you have a 2-node NUMA system and allocates
> 200 huge pages, than hugepages= will try to allocate 100 huge pages from
> node0 and 100 from node1.
>
> The hugepagesnid= option introduced by this commit allows the user
> to specify the nodes from which huge pages are allocated. For example,
> if you have a 2-node NUMA system and want 300 2M huge pages to be
> allocated from node1, you could do:
>
> hugepagesnid=1,300,2M
>
> Or, say you want node0 to allocate 100 huge pages and node1 to
> allocate 200 huge pages, you do:
>
> hugepagesnid=0,100,2M hugepagesnid=1,200,1M
>
> This commit adds support only for 2M huge pages, next commit will
> add support for 1G huge pages.
>
> Signed-off-by: Luiz Capitulino
> ---
> Documentation/kernel-parameters.txt | 8
> arch/x86/mm/hugetlbpage.c | 35 +
> include/linux/hugetlb.h | 2 +
> mm/hugetlb.c| 77
> +
> 4 files changed, 122 insertions(+)
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index 7116fda..3cbe950 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1125,6 +1125,14 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
> registers. Default set by CONFIG_HPET_MMAP_DEFAULT.
>
> hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
> + hugepagesnid= [X86-64] HugeTLB pages to allocate at boot on a NUMA
> system.
> + Format: ,,
> + nid: NUMA node id to allocate pages from
> + nrpages: number of huge pages to allocate
> + size: huge pages size (see hugepagsz below)
> + This argument can be specified multiple times for
> different
> + NUMA nodes, but it shouldn't be mixed with hugepages=
> and
> + hugepagesz=.
> hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
> On x86-64 and powerpc, this option can be specified
> multiple times interleaved with hugepages= to reserve
> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
> index 8c9f647..91c5c98 100644
> --- a/arch/x86/mm/hugetlbpage.c
> +++ b/arch/x86/mm/hugetlbpage.c
> @@ -188,4 +188,39 @@ static __init int setup_hugepagesz(char *opt)
> return 1;
> }
> __setup("hugepagesz=", setup_hugepagesz);
> +
> +static __init int setup_hugepagesnid(char *opt)
> +{
> + unsigned long order, ps, nid, nr_pages;
> + char size_str[3];
> +
> + size_str[2] = '\0';
> + if (sscanf(opt, "%lu,%lu,%c%c",
> + , _pages, _str[0], _str[1]) < 4) {
> + printk(KERN_ERR "hugepagesnid: failed to parse arguments\n");
> + return 0;
> + }
> +
> + if (!nr_pages) {
> + printk(KERN_ERR
> + "hugepagesnid: zero number of pages, ignoring\n");
> + return 0;
> + }
> +
> + ps = memparse(size_str, NULL);
> + if (ps == PMD_SIZE) {
> + order = PMD_SHIFT - PAGE_SHIFT;
> + } else if (ps == PUD_SIZE && cpu_has_gbpages) {
> + order = PUD_SHIFT - PAGE_SHIFT;
> + } else {
> + printk(KERN_ERR "hugepagesnid: Unsupported page size %lu M\n",
> + ps >> 20);
> + return 0;
> + }
You must check that nid is valid or not. When nid is MAX_NUMNODES or more,
hugetlb_add_nrpages_nid() sets nr_pages to wrong memory region.
Thanks,
Yasuaki Ishimatsu
> +
> + hugetlb_add_nrpages_nid(order, nid, nr_pages);
> + return 1;
> +}
> +__setup("hugepagesnid=", setup_hugepagesnid);
> +
> #endif
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 8c43cc4..aae2f9b 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -274,6 +274,8 @@ struct page *alloc_huge_page_noerr(struct vm_area_struct
> *vma,
> int __init alloc_bootmem_huge_page(struct hstate *h);
>
> void __init hugetlb_add_hstate(unsigned order);
> +void __init hugetlb_add_nrpages_nid(unsigned order, unsigned long nid,
> + unsigned long nr_pages);
> struct hstate *size_to_hstate(unsigned long size);
>
> #ifndef HUGE_MAX_HSTATE
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index c01cb9f..439c3b7 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -46,6 +46,7 @@ __initdata LIST_HEAD(huge_boot_pages);
> static struct hstate * __initdata parsed_hstate;
> static
Re: [null_blk] INFO: trying to register non-static key.
On Wed, Feb 12 2014, Fengguang Wu wrote: > Hi Jens, > > I got the below dmesg and the first bad commit is > > commit f2298c0403b0dfcaef637eba0c02c4a06d7a25ab > Author: Jens Axboe > CommitDate: Fri Oct 25 11:56:00 2013 +0100 Hmm dunno, the below looks more like a logfs issue, given the calltrace. The fact that null_blk is the device used is probably less interesting. > [ 18.158432] VFS: could not find a valid V7 on nullb0. > [ 18.159280] LogFS: Start mount 1 > [ 18.159732] LogFS: Start unmounting > [ 18.160368] INFO: trying to register non-static key. > [ 18.160986] the code is fine but needs lockdep annotation. > [ 18.161675] turning off the locking correctness validator. > [ 18.162341] CPU: 0 PID: 634 Comm: mount Not tainted > 3.14.0-rc2-wl-01363-gf8a1366 #2 > [ 18.163266] 88000b839c00 827922a5 > 88000b839cb8 > [ 18.163516] 810c0202 88000bac1008 88000b839c98 > 88000b839c58 > [ 18.163516] 0002 88000bb4f000 8800 > 0001 > [ 18.163516] Call Trace: > [ 18.163516] [] dump_stack+0x19/0x1b > [ 18.163516] [] __lock_acquire+0x252/0x1d80 > [ 18.163516] [] ? writeback_inodes_sb_nr+0xc0/0xe0 > [ 18.163516] [] ? logfs_get_wblocks+0x76/0x90 > [ 18.163516] [] lock_acquire+0x70/0x90 > [ 18.163516] [] ? logfs_get_wblocks+0x76/0x90 > [ 18.163516] [] mutex_lock_nested+0x61/0x380 > [ 18.163516] [] ? logfs_get_wblocks+0x76/0x90 > [ 18.163516] [] logfs_get_wblocks+0x76/0x90 > [ 18.163516] [] logfs_sync_fs+0x14/0x30 > [ 18.163516] [] sync_filesystem+0x59/0xb0 > [ 18.163516] [] logfs_kill_sb+0x27/0xf0 > [ 18.163516] [] deactivate_locked_super+0x2d/0x50 > [ 18.163516] [] logfs_mount+0x763/0x7e0 > [ 18.163516] [] mount_fs+0x10/0xe0 > [ 18.163516] [] vfs_kern_mount+0x69/0x140 > [ 18.163516] [] ? _raw_read_unlock+0x2c/0x50 > [ 18.163516] [] do_mount+0x934/0xb90 > [ 18.163516] [] ? might_fault+0x52/0xb0 > [ 18.163516] [] ? strndup_user+0x35/0x50 > [ 18.163516] [] SyS_mount+0x8c/0xd0 > [ 18.163516] [] system_call_fastpath+0x1a/0x1f -- Jens Axboe -- 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] mmc: Add realtek USB sdmmc host driver
On 02/11/2014 05:50 PM, Ulf Hansson wrote: On 11 February 2014 10:27, Roger wrote: On 02/10/2014 10:58 PM, Ulf Hansson wrote: On 6 February 2014 15:35, wrote: From: Roger Tseng Realtek USB SD/MMC host driver provides mmc host support based on the Realtek USB card reader MFD driver. Signed-off-by: Roger Tseng --- drivers/mmc/host/Kconfig |7 + drivers/mmc/host/Makefile |1 + drivers/mmc/host/rtsx_usb_sdmmc.c | 1500 + 3 files changed, 1508 insertions(+) create mode 100644 drivers/mmc/host/rtsx_usb_sdmmc.c [snip] +#ifdef CONFIG_PM_RUNTIME There are stubs for pm_runtime* functions, thus the ifdefs can be removed. Please go though the complete patch and remove all instances. + pm_runtime_put(sdmmc_dev(host)); I don't know so much about USB mmc hosts hardware, but I just wanted to find out if I have understood this correct. You can't do fine grained power management of the USB parent device, since it needs to be runtime resumed to be able keep the power the card? Once it becomes runtime suspended, the power to the card will thus also be dropped? Yes, and to keep some internal state of the controller. Okay. But the internal state of the controller should be possible to restore at runtime_resume, so that should not be the reason, right? I checked again. Internal registers will hold its state during suspend. Card power is the exact reason. Kind regards Ulf Hansson . -- 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] [GIT PULL] (xen) stable/for-jens-3.14 : NFO: trying to register non-static key. the code is fine but needs lockdep annotation.
On Tue, Feb 11 2014, Konrad Rzeszutek Wilk wrote: > On February 11, 2014 4:44:42 PM EST, Jens Axboe wrote: > >On 2014-02-11 13:21, Sander Eikelenboom wrote: > >> > >> Tuesday, February 11, 2014, 7:21:56 PM, you wrote: > >> > >>> On 11/02/14 18:15, Roger Pau Monné wrote: > On 11/02/14 18:52, David Vrabel wrote: > > > That would mean that unmap_purged_grants would no longer be static > >and > I should also add a prototype for it in blkback/common.h, which is > >kind > of ugly IMHO. > >> > >>> But less ugly than initializing work with a NULL function, IMO. > >> > commit 980e72e45454b64ccb7f23b6794a769384e51038 > Author: Roger Pau Monne > Date: Tue Feb 11 19:04:06 2014 +0100 > > xen-blkback: init persistent_purge_work work_struct > > Initialize persistent_purge_work work_struct on > >xen_blkif_alloc (and > remove the previous initialization done in > >purge_persistent_gnt). This > prevents flush_work from complaining even if > >purge_persistent_gnt has > not been used. > > Signed-off-by: Roger Pau Monné > >> > >>> Reviewed-by: David Vrabel > >> > >> And a Tested-by: Sander Eikelenboom > > > >Konrad, I was going to ship my current tree today, but looks like we > >need this too. > > Yes. Are you OK taking it from this thread or would you like me to prep a GIT > pull with it? I'll just grab it from here, no problem. Done. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] staging: android: remove unused constant, BINDER_SET_IDLE_PRIORITY
On Wed, Feb 12, 2014 at 5:22 AM, Greg KH wrote:
> On Sat, Feb 08, 2014 at 11:59:41AM +0900, SeongJae Park wrote:
>> Remove constant BINDER_SET_IDLE_PRIORITY because it is not used from
>> anywhere.
>
>>
>> Signed-off-by: SeongJae Park
>> ---
>> drivers/staging/android/binder.h | 7 +++
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/android/binder.h
>> b/drivers/staging/android/binder.h
>> index c4c1ed6..6d08e61 100644
>> --- a/drivers/staging/android/binder.h
>> +++ b/drivers/staging/android/binder.h
>> @@ -87,10 +87,9 @@ struct binder_version {
>> #define BINDER_WRITE_READ_IOWR('b', 1, struct binder_write_read)
>> #define BINDER_SET_IDLE_TIMEOUT _IOW('b', 3, __s64)
>> #define BINDER_SET_MAX_THREADS _IOW('b', 5, __u32)
>> -#define BINDER_SET_IDLE_PRIORITY _IOW('b', 6, __s32)
>> -#define BINDER_SET_CONTEXT_MGR _IOW('b', 7, __s32)
>> -#define BINDER_THREAD_EXIT _IOW('b', 8, __s32)
>> -#define BINDER_VERSION _IOWR('b', 9, struct
>> binder_version)
>> +#define BINDER_SET_CONTEXT_MGR _IOW('b', 6, __s32)
>> +#define BINDER_THREAD_EXIT _IOW('b', 7, __s32)
>> +#define BINDER_VERSION _IOWR('b', 8, struct
>> binder_version)
>
> And you just broke all userspace code that uses this interface :(
>
> Please be more careful, and test your patches properly.
Definitely my fault... Sorry.
I will be more careful and will not do such mistake again.
>
> greg k-h
--
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] [GIT PULL] (xen) stable/for-jens-3.14 : NFO: trying to register non-static key. the code is fine but needs lockdep annotation.
On February 11, 2014 4:44:42 PM EST, Jens Axboe wrote: >On 2014-02-11 13:21, Sander Eikelenboom wrote: >> >> Tuesday, February 11, 2014, 7:21:56 PM, you wrote: >> >>> On 11/02/14 18:15, Roger Pau Monné wrote: On 11/02/14 18:52, David Vrabel wrote: > That would mean that unmap_purged_grants would no longer be static >and I should also add a prototype for it in blkback/common.h, which is >kind of ugly IMHO. >> >>> But less ugly than initializing work with a NULL function, IMO. >> commit 980e72e45454b64ccb7f23b6794a769384e51038 Author: Roger Pau Monne Date: Tue Feb 11 19:04:06 2014 +0100 xen-blkback: init persistent_purge_work work_struct Initialize persistent_purge_work work_struct on >xen_blkif_alloc (and remove the previous initialization done in >purge_persistent_gnt). This prevents flush_work from complaining even if >purge_persistent_gnt has not been used. Signed-off-by: Roger Pau Monné >> >>> Reviewed-by: David Vrabel >> >> And a Tested-by: Sander Eikelenboom > >Konrad, I was going to ship my current tree today, but looks like we >need this too. Yes. Are you OK taking it from this thread or would you like me to prep a GIT pull with it? 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/
[PATCH] drm/i915/opregion: work around buggy firmware that provides 8+ output devices
The ACPI table on ASUS UX302LA has more than 8 output devices under the
graphics controller device node. The problem is, the real active output
device, the LCD panel, is listed the last. The result is, the LCD's
device id doesn't get recorded in the active device list CADL array and
when the _DCS control method for the LCD device is executed, it returns
0x1d, meaning it is not active. This affects the hotkey delivery ASL
code that will not deliver a notification if the output device is not
active on backlight hotkey press.
I don't see a clean way to solve this problem since the operation region
spec doesn't allow more than 8 output devices so we have no way of
storing all these output devices. The fact that output devices that have
_BCM control method usually means they have a higher possibility of being
used than those who don't made me choose a simple way to work around
the buggy firmware by replacing the last entry in CADL array with the one
that has _BCM control method. There is no specific reason why the last
entry is picked instead of others.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=70241
Signed-off-by: Aaron Lu
Reported-and-tested-by: Oleksij Rempel
---
drivers/gpu/drm/i915/intel_opregion.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index 4e960ec7419f..fc4348284f41 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -613,6 +613,7 @@ static void intel_didl_outputs(struct drm_device *dev)
acpi_status status;
u32 temp;
int i = 0;
+ bool done;
handle = ACPI_HANDLE(>pdev->dev);
if (!handle || acpi_bus_get_device(handle, _dev))
@@ -634,11 +635,20 @@ static void intel_didl_outputs(struct drm_device *dev)
return;
}
+ done = false;
list_for_each_entry(acpi_cdev, _video_bus->children, node) {
if (i >= 8) {
dev_dbg(>pdev->dev,
- "More than 8 outputs detected via ACPI\n");
- return;
+ "More than 8 outputs detected via ACPI, %s\n",
+ acpi_device_bid(acpi_cdev));
+ if (acpi_has_method(acpi_cdev->handle, "_BCM")) {
+ dev_dbg(>pdev->dev,
+ "%s has _BCM, replacing 8th entry\n",
+ acpi_device_bid(acpi_cdev));
+ i = 7;
+ done = true;
+ } else
+ continue;
}
status =
acpi_evaluate_integer(acpi_cdev->handle, "_ADR",
@@ -650,6 +660,9 @@ static void intel_didl_outputs(struct drm_device *dev)
>acpi->didl[i]);
i++;
}
+
+ if (done)
+ return;
}
end:
--
1.8.5.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 part1 v6 3/7] PCI: Add support for Device Serial Number capability
Add support for the Device Serial Number capability, so we can use the
unique device serial number to identify the physical device. This helps
determine whether a device was replaced while the system was suspended.
[bhelgaas: changelog, drop pci_dsn_init(), spell out "serial_number"]
Reviewed-by: Gu Zheng
Signed-off-by: Yijing Wang
Signed-off-by: Bjorn Helgaas
Cc: Paul Bolle
Cc: Oliver Neukum
Cc: Gu Zheng
---
drivers/pci/pci.c | 30 ++
drivers/pci/pci.h |2 +-
drivers/pci/probe.c |2 ++
include/linux/pci.h |1 +
4 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 4502e6f..a8c1c2d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2169,6 +2169,36 @@ void pci_free_cap_save_buffers(struct pci_dev *dev)
}
/**
+ * pci_device_serial_number - get device serial number
+ * @bus: PCI bus the device on
+ * @devfn: the PCI device
+ *
+ * return the device serial number if device support,
+ * otherwise return 0.
+ */
+static u64 pci_device_serial_number(struct pci_bus *bus, int devfn)
+{
+ int pos;
+ u32 lo, hi;
+
+ if (!pci_bus_find_capability(bus, devfn, PCI_CAP_ID_EXP))
+ return 0;
+
+ pos = pci_bus_find_ext_capability(bus, devfn, PCI_EXT_CAP_ID_DSN);
+ if (!pos)
+ return 0;
+
+ pci_bus_read_config_dword(bus, devfn, pos + 4, );
+ pci_bus_read_config_dword(bus, devfn, pos + 8, );
+ return ((u64)hi << 32) | lo;
+}
+
+void pci_dsn_init(struct pci_dev *dev)
+{
+ dev->sn = pci_device_serial_number(dev->bus, dev->devfn);
+}
+
+/**
* pci_configure_ari - enable or disable ARI forwarding
* @dev: the PCI device
*
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 4df38df..685301a 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -208,7 +208,7 @@ void __ref __pci_bus_size_bridges(struct pci_bus *bus,
void __ref __pci_bus_assign_resources(const struct pci_bus *bus,
struct list_head *realloc_head,
struct list_head *fail_head);
-
+void pci_dsn_init(struct pci_dev *dev);
/**
* pci_ari_enabled - query ARI forwarding status
* @bus: the PCI bus
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6e34498..27d3e6f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1324,6 +1324,8 @@ static void pci_init_capabilities(struct pci_dev *dev)
/* Vital Product Data */
pci_vpd_pci22_init(dev);
+ pci_dsn_init(dev);
+
/* Alternative Routing-ID Forwarding */
pci_configure_ari(dev);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 470de02..3631859 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -354,6 +354,7 @@ struct pci_dev {
struct list_head msi_list;
const struct attribute_group **msi_irq_groups;
#endif
+ u64 sn; /* device serial number, 0 if not support */
struct pci_vpd *vpd;
#ifdef CONFIG_PCI_ATS
union {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part1 v6 7/7] PCI: pciehp: Don't enable/disable slot on resume unless status changed
Currently pciehp_resume() always enables the slot if it is occupied. But
often the slot was already occupied before the suspend, so we complain like
this:
pciehp :00:1c.1:pcie04: Device :03:00.0 already exists at
:03:00, cannot hot-add
pciehp :00:1c.1:pcie04: Cannot add device at :03:00
This patch only enables the slot if it was empty before the suspend and is
now occupied, i.e., a card was inserted while suspended.
Similarly, we only disable the slot if a card was removed while suspended.
If it was already empty before the suspend, we don't need to do anything.
[bhelgaas: changelog]
Tested-by: Paul Bolle
Signed-off-by: Yijing Wang
Signed-off-by: Bjorn Helgaas
Cc: Oliver Neukum
Cc: Gu Zheng
---
drivers/pci/hotplug/pciehp_core.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_core.c
b/drivers/pci/hotplug/pciehp_core.c
index 53b58de..551137f 100644
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -317,6 +317,7 @@ static int pciehp_resume (struct pcie_device *dev)
{
struct controller *ctrl;
struct slot *slot;
+ struct pci_bus *pbus = dev->port->subordinate;
u8 status;
ctrl = get_service_data(dev);
@@ -328,10 +329,13 @@ static int pciehp_resume (struct pcie_device *dev)
/* Check if slot is occupied */
pciehp_get_adapter_status(slot, );
- if (status)
- pciehp_enable_slot(slot);
- else
+ if (status) {
+ if (list_empty(>devices))
+ pciehp_enable_slot(slot);
+ } else if (!list_empty(>devices)) {
pciehp_disable_slot(slot);
+ }
+
return 0;
}
#endif /* PM */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part1 v6 5/7] PCI: Add pci_dummy_ops to isolate pci device temporarily
Pci_dummy_ops does nothing when we use it to read/write
pci_device. So we can isolate pci device by replace its
bus pci_ops by pci_dummy_ops. This is preparation for
the later patch.
Signed-off-by: Yijing Wang
---
drivers/pci/pci.c | 62 +++
include/linux/pci.h |4 +++
2 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index af34057..283e82e 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2226,6 +2226,68 @@ bool pci_serial_number_changed(struct pci_dev *pdev)
}
EXPORT_SYMBOL(pci_serial_number_changed);
+static int pci_dummy_read(struct pci_bus *bus, unsigned int devfn,
+ int where, int size, u32 *val)
+{
+ return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+static int pci_dummy_write(struct pci_bus *bus, unsigned int devfn,
+ int reg, int size, u32 val)
+{
+ return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+static struct pci_ops pci_dummy_ops = {
+ .read = pci_dummy_read,
+ .write = pci_dummy_write,
+};
+
+static DEFINE_SPINLOCK(pci_freeze_lock);
+/**
+ * pci_bus_freeze_device - freeze pci bus to access pci device
+ * @bus: the pci bus to freeze
+ *
+ * Replace pci bus ops by pci_dummy_ops, protect system from
+ * accessing pci devices.
+ */
+void pci_bus_freeze_device(struct pci_bus *bus)
+{
+ struct pci_ops *ops;
+ unsigned long flags;
+
+ spin_lock_irqsave(_freeze_lock, flags);
+ if (bus->is_frozen)
+ goto out;
+ bus->is_frozen = 1;
+ ops = pci_bus_set_ops(bus, _dummy_ops);
+ bus->save_ops = ops;
+out:
+ spin_unlock_irqrestore(_freeze_lock, flags);
+}
+
+/**
+ * pci_bus_unfreeze_device - unfreeze pci bus to acess pci devices
+ * @bus: the pci bus to unfreeze
+ *
+ * Restore pci bus original ops, so pci bus can access
+ * pci devices normally.
+ */
+void pci_bus_unfreeze_device(struct pci_bus *bus)
+{
+ unsigned long flags;
+
+ BUG_ON(!bus->save_ops);
+ spin_lock_irqsave(_freeze_lock, flags);
+ if (!bus->is_frozen)
+ goto out;
+ pci_bus_set_ops(bus, bus->save_ops);
+ bus->save_ops = NULL;
+ bus->is_frozen = 0;
+out:
+ spin_unlock_irqrestore(_freeze_lock, flags);
+}
+
/**
* pci_configure_ari - enable or disable ARI forwarding
* @dev: the PCI device
diff --git a/include/linux/pci.h b/include/linux/pci.h
index d60c0b6..e3dd4ea 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -442,6 +442,7 @@ struct pci_bus {
struct resource busn_res; /* bus numbers routed to this bus */
struct pci_ops *ops; /* configuration access functions */
+ struct pci_ops *save_ops; /* save configuration access functions */
struct msi_chip *msi; /* MSI controller */
void*sysdata; /* hook for sys-specific extension */
struct proc_dir_entry *procdir; /* directory entry in /proc/bus/pci */
@@ -460,6 +461,7 @@ struct pci_bus {
struct bin_attribute*legacy_io; /* legacy I/O for this bus */
struct bin_attribute*legacy_mem; /* legacy mem */
unsigned intis_added:1;
+ unsigned intis_frozen:1;
};
#define pci_bus_b(n) list_entry(n, struct pci_bus, node)
@@ -1026,6 +1028,8 @@ ssize_t pci_read_vpd(struct pci_dev *dev, loff_t pos,
size_t count, void *buf);
ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const
void *buf);
bool pci_serial_number_changed(struct pci_dev *pdev);
+void pci_bus_freeze_device(struct pci_bus *bus);
+void pci_bus_unfreeze_device(struct pci_bus *bus);
/* Helper functions for low-level code (drivers/pci/setup-[bus,res].c) */
resource_size_t pcibios_retrieve_fw_addr(struct pci_dev *dev, int idx);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part1 v6 0/7] Introduce PCIe Device Serial Number capability support
v5->v6: Add is_frozen flag to protect pci bus from double frozen. This series is based on Bjorn's pci-next branch. Currently, more and more PCIe devices support PCIe DSN(Device Serial Number) capability, we can use this cap to identify device. In some platform, when we hotplug PCIe device, no interrupts will be received in system. So we can not identify the device whether is changed during suspend. PCIe DSN can help to identify this. Legacy PCI device can achieve it by PCI Vital Product Data capability. We can use its SN keyword to report the unique number. But in my platform, PCI devices which support VPD SN cap report the meaningless same string "0123456789". Rework PCI VPD code to support device identification is not an easy work. Plan to do it in part2. Yijing Wang (7): PCI: rework pci_find_next_ext_capability() PCI: introduce pci_bus_find_ext_capability() PCI: Add support for Device Serial Number capability PCI: Introduce pci_serial_number_changed() PCI: Add pci_dummy_ops to isolate pci device temporarily PCI: Check pci device serial number when scan device PCI: pciehp: Don't enable/disable slot on resume unless status changed drivers/pci/hotplug/pciehp_core.c | 10 ++- drivers/pci/pci.c | 169 +++-- drivers/pci/pci.h |2 +- drivers/pci/probe.c | 15 +++- include/linux/pci.h | 10 ++- 5 files changed, 192 insertions(+), 14 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/
[GIT PULL] x86, apic: Remove support for Summit and ES7000
Hi Ingo, Peter, and Thomas, [ Be aware of bouncing emails on the cc, it includes the last-known email addresses of the authors of these subarchitectures and may bounce. ] If you agree, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/rientjes/linux.git x86/apic # HEAD: 7cf6c94591bbf3dbe3bf9573a6551328ad76d885 x86, apic: Remove support for IBM Summit/EXA chipset or apply individually. This branch is based on x86/apic. This is the removal of Summit and ES7000 subarchitectures from x86. I'd like to do the same for NumaQ, but am still researching if we can really do away with it. --- arch/x86/kernel/apic/es7000_32.c | 738 --- arch/x86/kernel/apic/summit_32.c | 550 - arch/x86/Kconfig | 45 -- arch/x86/kernel/acpi/boot.c | 12 arch/x86/kernel/apic/Makefile|2 drivers/clocksource/Makefile |1 drivers/clocksource/cyclone.c| 113 - 7 files changed, 9 insertions(+), 1452 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/
