Re: [RFC PATCH] amba: Ensure drvdata is NULL
Hi Russell,
any comment on this one?
Thanks,
Michal
On 09/04/2013 04:44 PM, Michal Simek wrote:
> This patch is inpired by the patch for drvdata
> "device-core: Ensure drvdata = NULL when no driver is bound"
> (sha1: 0998d0631001288a5974afc0b2a5f568bcdecb4d)
>
> Also it fixes all occurences in drivers.
>
> Signed-off-by: Michal Simek
> ---
> arch/arm/kernel/etm.c | 6 --
> drivers/amba/bus.c | 2 ++
> drivers/dma/pl330.c | 3 ---
> drivers/input/serio/ambakmi.c | 2 --
> drivers/mmc/host/mmci.c | 2 --
> drivers/rtc/rtc-pl030.c | 2 --
> drivers/rtc/rtc-pl031.c | 2 --
> drivers/spi/spi-pl022.c | 1 -
> drivers/tty/serial/amba-pl010.c | 3 ---
> drivers/tty/serial/amba-pl011.c | 3 ---
> drivers/video/amba-clcd.c | 2 --
> drivers/watchdog/sp805_wdt.c| 1 -
> 12 files changed, 2 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
> index 8ff0ecd..131a6ab 100644
> --- a/arch/arm/kernel/etm.c
> +++ b/arch/arm/kernel/etm.c
> @@ -385,7 +385,6 @@ out:
> return ret;
>
> out_unmap:
> - amba_set_drvdata(dev, NULL);
> iounmap(t->etb_regs);
>
> out_release:
> @@ -398,8 +397,6 @@ static int etb_remove(struct amba_device *dev)
> {
> struct tracectx *t = amba_get_drvdata(dev);
>
> - amba_set_drvdata(dev, NULL);
> -
> iounmap(t->etb_regs);
> t->etb_regs = NULL;
>
> @@ -588,7 +585,6 @@ out:
> return ret;
>
> out_unmap:
> - amba_set_drvdata(dev, NULL);
> iounmap(t->etm_regs);
>
> out_release:
> @@ -601,8 +597,6 @@ static int etm_remove(struct amba_device *dev)
> {
> struct tracectx *t = amba_get_drvdata(dev);
>
> - amba_set_drvdata(dev, NULL);
> -
> iounmap(t->etm_regs);
> t->etm_regs = NULL;
>
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> index c670727..9762090 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -373,6 +373,7 @@ static int amba_probe(struct device *dev)
> if (ret == 0)
> break;
>
> + amba_set_drvdata(pcdev, NULL);
> pm_runtime_disable(dev);
> pm_runtime_set_suspended(dev);
> pm_runtime_put_noidle(dev);
> @@ -391,6 +392,7 @@ static int amba_remove(struct device *dev)
>
> pm_runtime_get_sync(dev);
> ret = drv->remove(pcdev);
> + amba_set_drvdata(pcdev, NULL);
> pm_runtime_put_noidle(dev);
>
> /* Undo the runtime PM settings in amba_probe() */
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index fa645d8..626f99e 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -3026,8 +3026,6 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
>
> return 0;
> probe_err3:
> - amba_set_drvdata(adev, NULL);
> -
> /* Idle the DMAC */
> list_for_each_entry_safe(pch, _p, >ddma.channels,
> chan.device_node) {
> @@ -3061,7 +3059,6 @@ static int pl330_remove(struct amba_device *adev)
> of_dma_controller_free(adev->dev.of_node);
>
> dma_async_device_unregister(>ddma);
> - amba_set_drvdata(adev, NULL);
>
> /* Idle the DMAC */
> list_for_each_entry_safe(pch, _p, >ddma.channels,
> diff --git a/drivers/input/serio/ambakmi.c b/drivers/input/serio/ambakmi.c
> index 4e2fd44..b7c206d 100644
> --- a/drivers/input/serio/ambakmi.c
> +++ b/drivers/input/serio/ambakmi.c
> @@ -167,8 +167,6 @@ static int amba_kmi_remove(struct amba_device *dev)
> {
> struct amba_kmi_port *kmi = amba_get_drvdata(dev);
>
> - amba_set_drvdata(dev, NULL);
> -
> serio_unregister_port(kmi->io);
> clk_put(kmi->clk);
> iounmap(kmi->base);
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index c3785ed..07e17f1 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -1678,8 +1678,6 @@ static int mmci_remove(struct amba_device *dev)
> {
> struct mmc_host *mmc = amba_get_drvdata(dev);
>
> - amba_set_drvdata(dev, NULL);
> -
> if (mmc) {
> struct mmci_host *host = mmc_priv(mmc);
>
> diff --git a/drivers/rtc/rtc-pl030.c b/drivers/rtc/rtc-pl030.c
> index 22bacdb..a804f75 100644
> --- a/drivers/rtc/rtc-pl030.c
> +++ b/drivers/rtc/rtc-pl030.c
> @@ -153,8 +153,6 @@ static int pl030_remove(struct amba_device *dev)
> {
> struct pl030_rtc *rtc = amba_get_drvdata(dev);
>
> - amba_set_drvdata(dev, NULL);
> -
> writel(0, rtc->base + RTC_CR);
>
> free_irq(dev->irq[0], rtc);
> diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
> index 0f0609b..c9ca86e 100644
> --- a/drivers/rtc/rtc-pl031.c
> +++ b/drivers/rtc/rtc-pl031.c
> @@ -305,7 +305,6 @@ static int pl031_remove(struct amba_device *adev)
> {
> struct pl031_local *ldata = dev_get_drvdata(>dev);
>
> - amba_set_drvdata(adev, NULL);
> free_irq(adev->irq[0], ldata);
>
Re: [PATCH] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB
Le 12/09/2013 02:15, Benjamin Herrenschmidt a écrit : On Wed, 2013-09-11 at 17:36 -0500, Scott Wood wrote: I wonder why we don't start from entry 31 so we can actually make use of that autodecrement. What will happen when we load the first normal TLB entry later on? I don't see any setting of SPRN_MD_CTR after this code, so won't it overwrite entry 30 (the middle 8M) in the CONFIG_PIN_TLB case? Ben, would patches like this be considered bugfixes as far as merging goes, or would they be for next given that it's something that's never really worked right and hasn't been touched in years? Since they don't affect anything outside of 8xx, I'm happy to take them until around -rc2 or 3. But it's your call really. Scott, you're right, I didn't see that other consequence. I'll come with a more complete patch this afternoon. 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 3/3] video: xilinxfb: Simplify error path
devm_iounmap is called automatically that's why remove it from the code
dev_set_drvdata(dev, NULL) is called by generic code
after device_release or on probe failure.
Signed-off-by: Michal Simek
---
drivers/video/xilinxfb.c | 28 ++--
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index fd9c430..7e3036c 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -260,10 +260,9 @@ static int xilinxfb_assign(struct platform_device *pdev,
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
drvdata->regs = devm_ioremap_resource(>dev, res);
- if (IS_ERR(drvdata->regs)) {
- rc = PTR_ERR(drvdata->regs);
- goto err_region;
- }
+ if (IS_ERR(drvdata->regs))
+ return PTR_ERR(drvdata->regs);
+
drvdata->regs_phys = res->start;
}
@@ -279,11 +278,7 @@ static int xilinxfb_assign(struct platform_device *pdev,
if (!drvdata->fb_virt) {
dev_err(dev, "Could not allocate frame buffer memory\n");
- rc = -ENOMEM;
- if (drvdata->flags & BUS_ACCESS_FLAG)
- goto err_fbmem;
- else
- goto err_region;
+ return -ENOMEM;
}
/* Clear (turn to black) the framebuffer */
@@ -363,13 +358,6 @@ err_cmap:
/* Turn off the display */
xilinx_fb_out32(drvdata, REG_CTRL, 0);
-err_fbmem:
- if (drvdata->flags & BUS_ACCESS_FLAG)
- devm_iounmap(dev, drvdata->regs);
-
-err_region:
- dev_set_drvdata(dev, NULL);
-
return rc;
}
@@ -394,16 +382,12 @@ static int xilinxfb_release(struct device *dev)
/* Turn off the display */
xilinx_fb_out32(drvdata, REG_CTRL, 0);
- /* Release the resources, as allocated based on interface */
- if (drvdata->flags & BUS_ACCESS_FLAG)
- devm_iounmap(dev, drvdata->regs);
#ifdef CONFIG_PPC_DCR
- else
+ /* Release the resources, as allocated based on interface */
+ if (!(drvdata->flags & BUS_ACCESS_FLAG))
dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
#endif
- dev_set_drvdata(dev, NULL);
-
return 0;
}
--
1.8.2.3
pgpHK93V4FtbL.pgp
Description: PGP signature
[PATCH 2/3] video: xilinxfb: Use devm_kzalloc instead of kzalloc
Simplify driver probe and release function.
Signed-off-by: Michal Simek
---
drivers/video/xilinxfb.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 123cd70..fd9c430 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -368,7 +368,6 @@ err_fbmem:
devm_iounmap(dev, drvdata->regs);
err_region:
- kfree(drvdata);
dev_set_drvdata(dev, NULL);
return rc;
@@ -403,7 +402,6 @@ static int xilinxfb_release(struct device *dev)
dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
#endif
- kfree(drvdata);
dev_set_drvdata(dev, NULL);
return 0;
@@ -425,7 +423,7 @@ static int xilinxfb_of_probe(struct platform_device *pdev)
pdata = xilinx_fb_default_pdata;
/* Allocate the driver data region */
- drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
+ drvdata = devm_kzalloc(>dev, sizeof(*drvdata), GFP_KERNEL);
if (!drvdata) {
dev_err(>dev, "Couldn't allocate device private
record\n");
return -ENOMEM;
@@ -453,7 +451,6 @@ static int xilinxfb_of_probe(struct platform_device *pdev)
drvdata->dcr_host = dcr_map(op->dev.of_node, start,
drvdata->dcr_len);
if (!DCR_MAP_OK(drvdata->dcr_host)) {
dev_err(>dev, "invalid DCR address\n");
- kfree(drvdata);
return -ENODEV;
}
}
--
1.8.2.3
pgpyLuK7mC9GE.pgp
Description: PGP signature
[PATCH 1/3] video: xilinxfb: Use standard variable name convention
s/op/pdev/ in xilinxfb_of_probe().
No functional chagnes.
Signed-off-by: Michal Simek
---
drivers/video/xilinxfb.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 84c664e..123cd70 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -413,7 +413,7 @@ static int xilinxfb_release(struct device *dev)
* OF bus binding
*/
-static int xilinxfb_of_probe(struct platform_device *op)
+static int xilinxfb_of_probe(struct platform_device *pdev)
{
const u32 *prop;
u32 tft_access = 0;
@@ -427,7 +427,7 @@ static int xilinxfb_of_probe(struct platform_device *op)
/* Allocate the driver data region */
drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
if (!drvdata) {
- dev_err(>dev, "Couldn't allocate device private record\n");
+ dev_err(>dev, "Couldn't allocate device private
record\n");
return -ENOMEM;
}
@@ -435,7 +435,7 @@ static int xilinxfb_of_probe(struct platform_device *op)
* To check whether the core is connected directly to DCR or BUS
* interface and initialize the tft_access accordingly.
*/
- of_property_read_u32(op->dev.of_node, "xlnx,dcr-splb-slave-if",
+ of_property_read_u32(pdev->dev.of_node, "xlnx,dcr-splb-slave-if",
_access);
/*
@@ -459,29 +459,29 @@ static int xilinxfb_of_probe(struct platform_device *op)
}
#endif
- prop = of_get_property(op->dev.of_node, "phys-size", );
+ prop = of_get_property(pdev->dev.of_node, "phys-size", );
if ((prop) && (size >= sizeof(u32)*2)) {
pdata.screen_width_mm = prop[0];
pdata.screen_height_mm = prop[1];
}
- prop = of_get_property(op->dev.of_node, "resolution", );
+ prop = of_get_property(pdev->dev.of_node, "resolution", );
if ((prop) && (size >= sizeof(u32)*2)) {
pdata.xres = prop[0];
pdata.yres = prop[1];
}
- prop = of_get_property(op->dev.of_node, "virtual-resolution", );
+ prop = of_get_property(pdev->dev.of_node, "virtual-resolution", );
if ((prop) && (size >= sizeof(u32)*2)) {
pdata.xvirt = prop[0];
pdata.yvirt = prop[1];
}
- if (of_find_property(op->dev.of_node, "rotate-display", NULL))
+ if (of_find_property(pdev->dev.of_node, "rotate-display", NULL))
pdata.rotate_screen = 1;
- dev_set_drvdata(>dev, drvdata);
- return xilinxfb_assign(op, drvdata, );
+ dev_set_drvdata(>dev, drvdata);
+ return xilinxfb_assign(pdev, drvdata, );
}
static int xilinxfb_of_remove(struct platform_device *op)
--
1.8.2.3
pgpGTX0xGtHEx.pgp
Description: PGP signature
Re: cpufreq_stats NULL deref on second system suspend
Let me fix my mail first.. I was running out of time yesterday and so couldn't frame things correctly :) On 11 September 2013 17:29, Viresh Kumar wrote: > Okay.. There are two different ways in which cpufreq_add_dev() work > currently.. > > Boot cluster (i.e. policy with boot CPU) > --- > > Here cpufreq_remove_dev() is never called for boot cpu but all others. > And similarly cpufreq_add_dev() is never called for boot cpu but all others. > > Now policy->cpu contains meaningful cpu at beginning of resume and > we don't need to modify that at all.. For all the remaining CPUs we > better call cpufreq_add_policy_cpu() rather.. And this should be done without your patch. Or actually we will simply return from this place. Atleast for systems with single cluster, like Tegra. policy->related_cpus is still valid after resume and we haven't removed policy from the cpufreq_policy_list (though there is a bug which I have fixed separately and sent it to you..).. So no change required for a single cluster system.. > Non-boot Cluster > - > > All CPUs here are removed and at the end policy->cpu contains the last > cpu removed.. So, for a cluster with cpu 2 and 3 it will contain 3.. > > Now at resume we will add cpu2 first and so need to update policy->cpu > to 2.. > But for all other CPUs in this cluster we return early from > cpufreq_add_dev() and call cpufreq_add_policy_cpu() as policy->cpus > was fixed by call to ->init() for the first cpu of this cluster.. This was wrong, we need a valid policy->related_cpus field which is always valid and so we return early here too, but not for the first cpu of cluster. > And so we never reach the line: policy->cpu = cpu; > > For the first cpu of non-boot cluster we need to call update_policy_cpu() > and not for others.. that's correct, thought I have one more idea.. :) > But for the boot cluster if we can call ->init() somehow at resume time, > then things would be fairly similar in both cases.. Not required.. its all working already.. and so Stephen shouldn't need your patch for Tegra, but rather my patches that fix other cpufreq bugs.. Now coming back to the ideas I have... Same code will work if hotplug sequence is fixed a bit. Why aren't we doing exact opposite of suspend in resume? We are removing CPUs (leaving the boot cpu) in ascending order and then adding them back in same order.. Why? Why not remove CPUs in descending order and add in ascending order? Or remove in ascending order and add in descending order? That way policy->cpu will be updated with the right cpu and your patch wouldn't be required.. I am not saying that this can't be hacked/fixed in cpufreq but suspend/resume may also be fixed and that looks logically more correct to me.. -- 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/
[087/251] USB: EHCI: Fix resume signalling on remote wakeup
3.6.11.9-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Roger Quadros [ Upstream commit 47a64a13d54f6c669b00542848d5550be3d3310e ] Set the ehci->resuming flag for the port we receive a remote wakeup on so that resume signalling can be completed. Without this, the root hub timer will not fire again to check if the resume was completed and there will be a never-ending wait on on the port. This effect is only observed if the HUB IRQ IN does not come after we have initiated the port resume. Signed-off-by: Roger Quadros Cc: stable Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Steven Rostedt --- drivers/usb/host/ehci-hub.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c index c788022..20a6b75 100644 --- a/drivers/usb/host/ehci-hub.c +++ b/drivers/usb/host/ehci-hub.c @@ -830,6 +830,7 @@ static int ehci_hub_control ( /* resume signaling for 20 msec */ ehci->reset_done[wIndex] = jiffies + msecs_to_jiffies(20); + set_bit(wIndex, >resuming_ports); /* check the port again */ mod_timer(_to_hcd(ehci)->rh_timer, ehci->reset_done[wIndex]); -- 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: [GIT PULL 0/5] perf/urgent fixes
* Arnaldo Carvalho de Melo wrote:
> Em Wed, Sep 11, 2013 at 07:55:03AM +0200, Ingo Molnar escreveu:
> > 16645 perf_event_open(0x1eb7f00, 0x, 0, 0x, 0) = -1 EINVAL
> > (Invalid argument)
> >
> > Caused by:
> >
> > 575a9aab0f85 perf tools: Add attr->mmap2 support
> >
> > We must not force mmap2 support to be present on the kernel side - new
> > perf top should work on older kernels just as well.
> >
> > So I've unpulled the tree for now.
>
> yeah, I noticed this late yesterday, made it to work like the fallback
> for perf_event_attr.{sample_id_all,exclude_{guest,host}} and folded that
> into Stephane's patch, with a committer note, to keep things bisectable.
>
> Can you please do a test pull with the updated branch + tag below? If
> you prefer me to do the whole dance and send a regular pull request,
> please let me now.
Pulled, thanks a lot Arnaldo! 'perf top' works fine here now on older
kernels as well.
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/
[073/251] hrtimers: Move SMP function call to thread context
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
[ Upstream commit 5ec2481b7b47a4005bb446d176e5d0257400c77d ]
smp_call_function_* must not be called from softirq context.
But clock_was_set() which calls on_each_cpu() is called from softirq
context to implement a delayed clock_was_set() for the timer interrupt
handler. Though that almost never gets invoked. A recent change in the
resume code uses the softirq based delayed clock_was_set to support
Xens resume mechanism.
linux-next contains a new warning which warns if smp_call_function_*
is called from softirq context which gets triggered by that Xen
change.
Fix this by moving the delayed clock_was_set() call to a work context.
Reported-and-tested-by: Artem Savkov
Reported-by: Sasha Levin
Cc: David Vrabel
Cc: Ingo Molnar
Cc: H. Peter Anvin ,
Cc: Konrad Wilk
Cc: John Stultz
Cc: xen-de...@lists.xen.org
Cc: sta...@vger.kernel.org
Signed-off-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
kernel/hrtimer.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index e3999c2..e522f9a 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -719,17 +719,20 @@ static int hrtimer_switch_to_hres(void)
return 1;
}
+static void clock_was_set_work(struct work_struct *work)
+{
+ clock_was_set();
+}
+
+static DECLARE_WORK(hrtimer_work, clock_was_set_work);
+
/*
- * Called from timekeeping code to reprogramm the hrtimer interrupt
- * device. If called from the timer interrupt context we defer it to
- * softirq context.
+ * Called from timekeeping and resume code to reprogramm the hrtimer
+ * interrupt device on all cpus.
*/
void clock_was_set_delayed(void)
{
- struct hrtimer_cpu_base *cpu_base = &__get_cpu_var(hrtimer_bases);
-
- cpu_base->clock_was_set = 1;
- __raise_softirq_irqoff(HRTIMER_SOFTIRQ);
+ schedule_work(_work);
}
#else
@@ -779,8 +782,10 @@ void hrtimers_resume(void)
WARN_ONCE(!irqs_disabled(),
KERN_INFO "hrtimers_resume() called with IRQs enabled!");
+ /* Retrigger on the local CPU */
retrigger_next_event(NULL);
- timerfd_clock_was_set();
+ /* And schedule a retrigger for all others */
+ clock_was_set_delayed();
}
static inline void timer_stats_hrtimer_set_start_info(struct hrtimer *timer)
@@ -1416,13 +1421,6 @@ void hrtimer_peek_ahead_timers(void)
static void run_hrtimer_softirq(struct softirq_action *h)
{
- struct hrtimer_cpu_base *cpu_base = &__get_cpu_var(hrtimer_bases);
-
- if (cpu_base->clock_was_set) {
- cpu_base->clock_was_set = 0;
- clock_was_set();
- }
-
hrtimer_peek_ahead_timers();
}
--
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/
[069/251] USB: cp210x: add MMB and PI ZigBee USB Device Support
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sami Rahman
[ Upstream commit 7681156982026ebf7eafd7301eb0374d7648d068 ]
Added support for MMB Networks and Planet Innovation Ingeni ZigBee USB
devices using customized Silicon Labs' CP210x.c USB to UART bridge
drivers with PIDs: 88A4, 88A5.
Signed-off-by: Sami Rahman
Tested-by: Sami Rahman
Cc: stable
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Steven Rostedt
---
drivers/usb/serial/cp210x.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 5e64f6c..5abb19a 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -124,6 +124,8 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x85F8) }, /* Virtenio Preon32 */
{ USB_DEVICE(0x10C4, 0x8664) }, /* AC-Services CAN-IF */
{ USB_DEVICE(0x10C4, 0x8665) }, /* AC-Services OBD-IF */
+ { USB_DEVICE(0x10C4, 0x88A4) }, /* MMB Networks ZigBee USB Device */
+ { USB_DEVICE(0x10C4, 0x88A5) }, /* Planet Innovation Ingeni ZigBee USB
Device */
{ USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */
--
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/
[065/251] usb: serial: option: add Olivetti Olicard 200
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Dan Williams
[ Upstream commit 4cf76df06ecc852633ed927d91e01c83c33bc331 ]
Speaks AT on interfaces 5 (command & PPP) and 3 (secondary), other
interface protocols are unknown.
Signed-off-by: Dan Williams
Cc: stable
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Steven Rostedt
---
drivers/usb/serial/option.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 8b4ea07..ce7a65e 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -348,6 +348,7 @@ static void option_instat_callback(struct urb *urb);
#define OLIVETTI_VENDOR_ID 0x0b3c
#define OLIVETTI_PRODUCT_OLICARD1000xc000
#define OLIVETTI_PRODUCT_OLICARD1450xc003
+#define OLIVETTI_PRODUCT_OLICARD2000xc005
/* Celot products */
#define CELOT_VENDOR_ID0x211f
@@ -1241,6 +1242,7 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD100) },
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD145) },
+ { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD200) },
{ USB_DEVICE(CELOT_VENDOR_ID, CELOT_PRODUCT_CT680M) }, /* CT-650 CDMA
450 1xEVDO modem */
{ USB_DEVICE(ONDA_VENDOR_ID, ONDA_MT825UP) }, /* ONDA MT825UP modem */
{ USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID,
SAMSUNG_PRODUCT_GT_B3730, USB_CLASS_CDC_DATA, 0x00, 0x00) }, /* Samsung
GT-B3730 LTE USB modem.*/
--
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/
[079/251] ASoC: wm8962: Remove remaining direct register cache accesses
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Nicolin Chen
[ Upstream commit 2e7ee15ced914e109a1a5b6dfcd463d846a13bd5 ]
Also fix return values for headphone switch updates.
Signed-off-by: Nicolin Chen
Signed-off-by: Mark Brown
Cc: sta...@vger.kernel.org
Signed-off-by: Steven Rostedt
---
sound/soc/codecs/wm8962.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
index ce67200..df24c54 100644
--- a/sound/soc/codecs/wm8962.c
+++ b/sound/soc/codecs/wm8962.c
@@ -1600,7 +1600,6 @@ static int wm8962_put_hp_sw(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol)
{
struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
- u16 *reg_cache = codec->reg_cache;
int ret;
/* Apply the update (if any) */
@@ -1609,16 +1608,19 @@ static int wm8962_put_hp_sw(struct snd_kcontrol
*kcontrol,
return 0;
/* If the left PGA is enabled hit that VU bit... */
- if (snd_soc_read(codec, WM8962_PWR_MGMT_2) & WM8962_HPOUTL_PGA_ENA)
- return snd_soc_write(codec, WM8962_HPOUTL_VOLUME,
-reg_cache[WM8962_HPOUTL_VOLUME]);
+ ret = snd_soc_read(codec, WM8962_PWR_MGMT_2);
+ if (ret & WM8962_HPOUTL_PGA_ENA) {
+ snd_soc_write(codec, WM8962_HPOUTL_VOLUME,
+ snd_soc_read(codec, WM8962_HPOUTL_VOLUME));
+ return 1;
+ }
/* ...otherwise the right. The VU is stereo. */
- if (snd_soc_read(codec, WM8962_PWR_MGMT_2) & WM8962_HPOUTR_PGA_ENA)
- return snd_soc_write(codec, WM8962_HPOUTR_VOLUME,
-reg_cache[WM8962_HPOUTR_VOLUME]);
+ if (ret & WM8962_HPOUTR_PGA_ENA)
+ snd_soc_write(codec, WM8962_HPOUTR_VOLUME,
+ snd_soc_read(codec, WM8962_HPOUTR_VOLUME));
- return 0;
+ return 1;
}
/* The VU bits for the speakers are in a different register to the mute
@@ -3378,7 +3380,6 @@ static int wm8962_probe(struct snd_soc_codec *codec)
int ret;
struct wm8962_priv *wm8962 = snd_soc_codec_get_drvdata(codec);
struct wm8962_pdata *pdata = dev_get_platdata(codec->dev);
- u16 *reg_cache = codec->reg_cache;
int i, trigger, irq_pol;
bool dmicclk, dmicdat;
@@ -3436,8 +3437,9 @@ static int wm8962_probe(struct snd_soc_codec *codec)
/* Put the speakers into mono mode? */
if (pdata->spk_mono)
- reg_cache[WM8962_CLASS_D_CONTROL_2]
- |= WM8962_SPK_MONO;
+ snd_soc_update_bits(codec, WM8962_CLASS_D_CONTROL_2,
+ WM8962_SPK_MONO_MASK, WM8962_SPK_MONO);
+
/* Micbias setup, detection enable and detection
* threasholds. */
--
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/
[070/251] usb: cp210x support SEL C662 Vendor/Device
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Barry Grussling
[ Upstream commit b579fa52f6be0b4157ca9cc5e94d44a2c89a7e95 ]
This patch adds support for the Schweitzer Engineering Laboratories
C662 USB cable based off the CP210x driver.
Signed-off-by: Barry Grussling
Cc: stable
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Steven Rostedt
---
drivers/usb/serial/cp210x.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 5abb19a..e257c51 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -156,6 +156,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x17F4, 0x) }, /* Wavesense Jazz blood glucose meter */
{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
+ { USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
{ USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
{ USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
--
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/
[075/251] mm: fix the TLB range flushed when __tlb_remove_page() runs out of slots
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Vineet Gupta
[ Upstream commit e6c495a96ce02574e765d5140039a64c8d4e8c9e ]
zap_pte_range loops from @addr to @end. In the middle, if it runs out of
batching slots, TLB entries needs to be flushed for @start to @interim,
NOT @interim to @end.
Since ARC port doesn't use page free batching I can't test it myself but
this seems like the right thing to do.
Observed this when working on a fix for the issue at thread:
http://www.spinics.net/lists/linux-arch/msg21736.html
Signed-off-by: Vineet Gupta
Cc: Mel Gorman
Cc: Hugh Dickins
Cc: Rik van Riel
Cc: David Rientjes
Cc: Peter Zijlstra
Acked-by: Catalin Marinas
Cc: Max Filippov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Steven Rostedt
---
mm/memory.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 06ff7fb..e526880 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1106,6 +1106,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
spinlock_t *ptl;
pte_t *start_pte;
pte_t *pte;
+ unsigned long range_start = addr;
again:
init_rss_vec(rss);
@@ -1211,12 +1212,14 @@ again:
force_flush = 0;
#ifdef HAVE_GENERIC_MMU_GATHER
- tlb->start = addr;
- tlb->end = end;
+ tlb->start = range_start;
+ tlb->end = addr;
#endif
tlb_flush_mmu(tlb);
- if (addr != end)
+ if (addr != end) {
+ range_start = addr;
goto again;
+ }
}
return addr;
--
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] Documentation/kvm: Update cpuid documentation for steal time and pv eoi
On Wed, Sep 04, 2013 at 02:18:46PM +0530, Raghavendra K T wrote: > Signed-off-by: Raghavendra K T > --- > Changes in V2: > Correction in the description of steal time and added msr info (Michael S > Tsirkin) Thanks. Some comments below: > Documentation/virtual/kvm/cpuid.txt | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/virtual/kvm/cpuid.txt > b/Documentation/virtual/kvm/cpuid.txt > index 22ff659..6c4fb20 100644 > --- a/Documentation/virtual/kvm/cpuid.txt > +++ b/Documentation/virtual/kvm/cpuid.txt > @@ -43,6 +43,16 @@ KVM_FEATURE_CLOCKSOURCE2 || 3 || kvmclock > available at msrs > KVM_FEATURE_ASYNC_PF || 4 || async pf can be enabled by > || || writing to msr 0x4b564d02 > > -- > +KVM_FEATURE_STEAL_TIME || 5 || Steal time available at msr > + || || 0x4b564d03. The feature is > enabled > + || || by guest when host has > schedstat > + || || or task delay accounting > support. Well I think we really should be documenting the host/guest interface here. After all it starts out A guest running on a kvm host, can check some of its features using cpuid. And guests really should not try to guess whether host has schedstat or task delay accounting support based on this bit. So I would just say: "steal time can be enabled by writing to msr 0x4b564d02" just like async pf. > +-- > +KVM_FEATURE_PV_EOI || 6 || overrides the generic EOI > + || || implementation with a > + || || paravirtualized version. > Available > + || || at msr 0x4b564d04. Actually there's no override: guest can still use the standard EOI even if PV EOI MSR is enabled. There's a detailed explanation of PV EOI in Documentation/virtual/kvm/msr.txt I think the following would be enough: "paravirtualized end of interrupt handler can be enabled by writing to msr 0x4b564d04" > +-- > KVM_FEATURE_PV_UNHALT || 7 || guest checks this feature bit > || || before enabling > paravirtualized > || || spinlock support. > -- > 1.7.11.7 -- 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] dma: pl330: Simplify irq allocation
Use devm_request_irq function. Signed-off-by: Michal Simek --- drivers/dma/pl330.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c index a562d24..58623dc 100644 --- a/drivers/dma/pl330.c +++ b/drivers/dma/pl330.c @@ -2923,7 +2923,7 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id) amba_set_drvdata(adev, pdmac); irq = adev->irq[0]; - ret = request_irq(irq, pl330_irq_handler, 0, + ret = devm_request_irq(>dev, irq, pl330_irq_handler, 0, dev_name(>dev), pi); if (ret) return ret; @@ -2931,7 +2931,7 @@ pl330_probe(struct amba_device *adev, const struct amba_id *id) pi->pcfg.periph_id = adev->periphid; ret = pl330_add(pi); if (ret) - goto probe_err1; + return ret; INIT_LIST_HEAD(>desc_pool); spin_lock_init(>pool_lock); @@ -3044,8 +3044,6 @@ probe_err3: } probe_err2: pl330_del(pi); -probe_err1: - free_irq(irq, pi); return ret; } @@ -3055,7 +3053,6 @@ static int pl330_remove(struct amba_device *adev) struct dma_pl330_dmac *pdmac = amba_get_drvdata(adev); struct dma_pl330_chan *pch, *_p; struct pl330_info *pi; - int irq; if (!pdmac) return 0; @@ -3082,9 +3079,6 @@ static int pl330_remove(struct amba_device *adev) pl330_del(pi); - irq = adev->irq[0]; - free_irq(irq, pi); - return 0; } -- 1.8.2.3 pgpjCt7AV8CrT.pgp Description: PGP signature
[068/251] usb: serial: cp210x: Add USB ID for Netgear Switches embedded serial adapter
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Luiz Angelo Daros de Luca
[ Upstream commit 90625070c4253377025878c4e82feed8b35c7116 ]
This adds NetGear Managed Switch M4100 series, M5300 series, M7100 series
USB ID (0846:0110) to the cp210x driver. Without this, the serial
adapter is not recognized in Linux. Description was obtained from
an Netgear Eng.
Signed-off-by: Luiz Angelo Daros de Luca
Cc: stable
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Steven Rostedt
---
drivers/usb/serial/cp210x.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 5ad932d..5e64f6c 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -60,6 +60,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0489, 0xE000) }, /* Pirelli Broadband S.p.A, DP-L10
SIP/GSM Mobile */
{ USB_DEVICE(0x0489, 0xE003) }, /* Pirelli Broadband S.p.A, DP-L10
SIP/GSM Mobile */
{ USB_DEVICE(0x0745, 0x1000) }, /* CipherLab USB CCD Barcode Scanner
1000 */
+ { USB_DEVICE(0x0846, 0x1100) }, /* NetGear Managed Switch M4100 series,
M5300 series, M7100 series */
{ USB_DEVICE(0x08e6, 0x5501) }, /* Gemalto Prox-PU/CU contactless
smartcard reader */
{ USB_DEVICE(0x08FD, 0x000A) }, /* Digianswer A/S , ZigBee/802.15.4 MAC
Device */
{ USB_DEVICE(0x0BED, 0x1100) }, /* MEI (TM) Cashflow-SC Bill/Voucher
Acceptor */
--
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/
[081/251] isci: Fix a race condition in the SSP task management path
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Jeff Skirvin
[ Upstream commit 96f15f29038e58e1b0a96483e2b369ff446becf1 ]
This commit fixes a race condition in the isci driver abort task and SSP
device task management path. The race is caused when an I/O termination
in the SCU hardware is necessary because of an SSP target timeout condition,
and the check of the I/O end state races against the HW-termination-driven
end state. The failure of the race meant that no TMF was sent to the device
to clean-up the pending I/O.
Signed-off-by: Jeff Skirvin
Reviewed-by: Lukasz Dorau
Cc:
Signed-off-by: James Bottomley
Signed-off-by: Steven Rostedt
---
drivers/scsi/isci/task.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/isci/task.c b/drivers/scsi/isci/task.c
index 6bc74eb..efd9e9e 100644
--- a/drivers/scsi/isci/task.c
+++ b/drivers/scsi/isci/task.c
@@ -491,6 +491,7 @@ int isci_task_abort_task(struct sas_task *task)
struct isci_tmf tmf;
int ret = TMF_RESP_FUNC_FAILED;
unsigned long flags;
+ int target_done_already = 0;
/* Get the isci_request reference from the task. Note that
* this check does not depend on the pending request list
@@ -505,9 +506,11 @@ int isci_task_abort_task(struct sas_task *task)
/* If task is already done, the request isn't valid */
if (!(task->task_state_flags & SAS_TASK_STATE_DONE) &&
(task->task_state_flags & SAS_TASK_AT_INITIATOR) &&
- old_request)
+ old_request) {
idev = isci_get_device(task->dev->lldd_dev);
-
+ target_done_already = test_bit(IREQ_COMPLETE_IN_TARGET,
+ _request->flags);
+ }
spin_unlock(>task_state_lock);
spin_unlock_irqrestore(>scic_lock, flags);
@@ -561,7 +564,7 @@ int isci_task_abort_task(struct sas_task *task)
if (task->task_proto == SAS_PROTOCOL_SMP ||
sas_protocol_ata(task->task_proto) ||
- test_bit(IREQ_COMPLETE_IN_TARGET, _request->flags) ||
+ target_done_already ||
test_bit(IDEV_GONE, >flags)) {
spin_unlock_irqrestore(>scic_lock, flags);
--
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/
[074/251] ALSA: usb-audio: 6fire: return correct XRUN indication
3.6.11.9-rc1 stable review patch. If anyone has any objections, please let me know. -- From: Eldad Zack [ Upstream commit be2f93a4c4981b3646b6f98f477154411b8516cb ] Return SNDRV_PCM_POS_XRUN (snd_pcm_uframes_t) instead of SNDRV_PCM_STATE_XRUN (snd_pcm_state_t) from the pointer function of 6fire, as expected by snd_pcm_update_hw_ptr0(). Caught by sparse. Signed-off-by: Eldad Zack Cc: Signed-off-by: Takashi Iwai Signed-off-by: Steven Rostedt --- sound/usb/6fire/pcm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/usb/6fire/pcm.c b/sound/usb/6fire/pcm.c index 3143d9c..7c4f311 100644 --- a/sound/usb/6fire/pcm.c +++ b/sound/usb/6fire/pcm.c @@ -540,7 +540,7 @@ static snd_pcm_uframes_t usb6fire_pcm_pointer( snd_pcm_uframes_t ret; if (rt->panic || !sub) - return SNDRV_PCM_STATE_XRUN; + return SNDRV_PCM_POS_XRUN; spin_lock_irqsave(>lock, flags); ret = sub->dma_off; -- 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/
[083/251] qla2xxx: Properly set the tagging for commands.
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Saurav Kashyap
[ Upstream commit c3ccb1d7cf4c4549151876dd37c0944a682fd9e1 ]
This fixes a regression where Xyratex controllers and disks were lost by the
driver:
https://bugzilla.kernel.org/show_bug.cgi?id=59601
Reported-by: Jack Hill
Signed-off-by: Saurav Kashyap
Signed-off-by: Giridhar Malavali
Cc:
Signed-off-by: James Bottomley
Signed-off-by: Steven Rostedt
---
drivers/scsi/qla2xxx/qla_iocb.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_iocb.c b/drivers/scsi/qla2xxx/qla_iocb.c
index 70dbf53..f2254d2 100644
--- a/drivers/scsi/qla2xxx/qla_iocb.c
+++ b/drivers/scsi/qla2xxx/qla_iocb.c
@@ -424,6 +424,8 @@ qla2x00_start_scsi(srb_t *sp)
__constant_cpu_to_le16(CF_SIMPLE_TAG);
break;
}
+ } else {
+ cmd_pkt->control_flags = __constant_cpu_to_le16(CF_SIMPLE_TAG);
}
/* Load SCSI command packet. */
@@ -1353,11 +1355,11 @@ qla24xx_build_scsi_crc_2_iocbs(srb_t *sp, struct
cmd_type_crc_2 *cmd_pkt,
fcp_cmnd->task_attribute = TSK_ORDERED;
break;
default:
- fcp_cmnd->task_attribute = 0;
+ fcp_cmnd->task_attribute = TSK_SIMPLE;
break;
}
} else {
- fcp_cmnd->task_attribute = 0;
+ fcp_cmnd->task_attribute = TSK_SIMPLE;
}
cmd_pkt->fcp_rsp_dseg_len = 0; /* Let response come in status iocb */
@@ -1563,7 +1565,12 @@ qla24xx_start_scsi(srb_t *sp)
case ORDERED_QUEUE_TAG:
cmd_pkt->task = TSK_ORDERED;
break;
+ default:
+ cmd_pkt->task = TSK_SIMPLE;
+ break;
}
+ } else {
+ cmd_pkt->task = TSK_SIMPLE;
}
/* Load SCSI command packet. */
--
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/
[067/251] USB: option: add D-Link DWM-152/C1 and DWM-156/C1
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: "Alexandr \\\"Sky\\\" Ivanov"
[ Upstream commit ca24763588844b14f019ffc45c7df6d9e8f932c5 ]
Adding support for D-Link DWM-152/C1 and DWM-156/C1 devices.
DWM-152/C1:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=07d1 ProdID=3e01 Rev= 0.00
S: Product=USB Configuration
S: SerialNumber=1234567890ABCDEF
C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
DWM-156/C1:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 8 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=07d1 ProdID=3e02 Rev= 0.00
S: Product=DataCard Device
S: SerialNumber=1234567890ABCDEF
C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: Alexandr Ivanov
Cc: stable
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Steven Rostedt
---
drivers/usb/serial/option.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index e142114..d53681f 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1311,6 +1311,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d02, 0xff, 0x00, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x02, 0x01) },
{ USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x00, 0x00) },
+ { USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e01, 0xff, 0xff, 0xff) }, /*
D-Link DWM-152/C1 */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e02, 0xff, 0xff, 0xff) }, /*
D-Link DWM-156/C1 */
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, option_ids);
--
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/
[096/251] Btrfs: fix lock leak when resuming snapshot deletion
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Josef Bacik
[ Upstream commit fec386ac1428f9c0e672df952cbca5cebd4e4e2f ]
We aren't setting path->locks[level] when we resume a snapshot deletion which
means we won't unlock the buffer when we free the path. This causes deadlocks
if we happen to re-allocate the block before we've evicted the extent buffer
from cache. Thanks,
Cc: sta...@vger.kernel.org
Reported-by: Alex Lyakas
Signed-off-by: Josef Bacik
Signed-off-by: Steven Rostedt
---
fs/btrfs/extent-tree.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 6d7b589..dcfce2a 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -7007,6 +7007,7 @@ int btrfs_drop_snapshot(struct btrfs_root *root,
while (1) {
btrfs_tree_lock(path->nodes[level]);
btrfs_set_lock_blocking(path->nodes[level]);
+ path->locks[level] = BTRFS_WRITE_LOCK_BLOCKING;
ret = btrfs_lookup_extent_info(trans, root,
path->nodes[level]->start,
@@ -7023,6 +7024,7 @@ int btrfs_drop_snapshot(struct btrfs_root *root,
break;
btrfs_tree_unlock(path->nodes[level]);
+ path->locks[level] = 0;
WARN_ON(wc->refs[level] != 1);
level--;
}
--
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/
[093/251] usb: Clear both buffers when clearing a control transfer TT buffer.
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: William Gulland
[ Upstream commit 2c7b871b9102c497ba8f972aa5d38532f05b654d ]
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer it's necessary to send
two HUB_CLEAR_TT_BUFFER requests to the hub.
Signed-off-by: William Gulland
Acked-by: Alan Stern
Cc: stable
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Steven Rostedt
---
drivers/usb/core/hub.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index fe7faf0..74ae3a5 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -711,6 +711,15 @@ resubmit:
static inline int
hub_clear_tt_buffer (struct usb_device *hdev, u16 devinfo, u16 tt)
{
+ /* Need to clear both directions for control ep */
+ if (((devinfo >> 11) & USB_ENDPOINT_XFERTYPE_MASK) ==
+ USB_ENDPOINT_XFER_CONTROL) {
+ int status = usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
+ HUB_CLEAR_TT_BUFFER, USB_RT_PORT,
+ devinfo ^ 0x8000, tt, NULL, 0, 1000);
+ if (status)
+ return status;
+ }
return usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0),
HUB_CLEAR_TT_BUFFER, USB_RT_PORT, devinfo,
tt, NULL, 0, 1000);
--
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] uio: Simplify uio error path by using devres functions
Using devres functions simplify driver error path.
- Use devm_kzalloc
- Use devm_request_irq
Signed-off-by: Michal Simek
---
---
drivers/uio/uio.c | 16
drivers/uio/uio_pdrv_genirq.c | 34 ++
2 files changed, 14 insertions(+), 36 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index ba47563..11d4e0a 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -796,10 +796,9 @@ int __uio_register_device(struct module *owner,
info->uio_dev = NULL;
- idev = kzalloc(sizeof(*idev), GFP_KERNEL);
+ idev = devm_kzalloc(parent, sizeof(*idev), GFP_KERNEL);
if (!idev) {
- ret = -ENOMEM;
- goto err_kzalloc;
+ return -ENOMEM;
}
idev->owner = owner;
@@ -809,7 +808,7 @@ int __uio_register_device(struct module *owner,
ret = uio_get_minor(idev);
if (ret)
- goto err_get_minor;
+ return ret;
idev->dev = device_create(_class, parent,
MKDEV(uio_major, idev->minor), idev,
@@ -827,7 +826,7 @@ int __uio_register_device(struct module *owner,
info->uio_dev = idev;
if (info->irq && (info->irq != UIO_IRQ_CUSTOM)) {
- ret = request_irq(info->irq, uio_interrupt,
+ ret = devm_request_irq(parent, info->irq, uio_interrupt,
info->irq_flags, info->name, idev);
if (ret)
goto err_request_irq;
@@ -841,9 +840,6 @@ err_uio_dev_add_attributes:
device_destroy(_class, MKDEV(uio_major, idev->minor));
err_device_create:
uio_free_minor(idev);
-err_get_minor:
- kfree(idev);
-err_kzalloc:
return ret;
}
EXPORT_SYMBOL_GPL(__uio_register_device);
@@ -864,13 +860,9 @@ void uio_unregister_device(struct uio_info *info)
uio_free_minor(idev);
- if (info->irq && (info->irq != UIO_IRQ_CUSTOM))
- free_irq(info->irq, idev);
-
uio_dev_del_attributes(idev);
device_destroy(_class, MKDEV(uio_major, idev->minor));
- kfree(idev);
return;
}
diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pdrv_genirq.c
index 90ff17a..7666931 100644
--- a/drivers/uio/uio_pdrv_genirq.c
+++ b/drivers/uio/uio_pdrv_genirq.c
@@ -112,11 +112,11 @@ static int uio_pdrv_genirq_probe(struct platform_device
*pdev)
if (pdev->dev.of_node) {
/* alloc uioinfo for one device */
- uioinfo = kzalloc(sizeof(*uioinfo), GFP_KERNEL);
+ uioinfo = devm_kzalloc(>dev, sizeof(*uioinfo),
+ GFP_KERNEL);
if (!uioinfo) {
- ret = -ENOMEM;
dev_err(>dev, "unable to kmalloc\n");
- return ret;
+ return -ENOMEM;
}
uioinfo->name = pdev->dev.of_node->name;
uioinfo->version = "devicetree";
@@ -125,20 +125,19 @@ static int uio_pdrv_genirq_probe(struct platform_device
*pdev)
if (!uioinfo || !uioinfo->name || !uioinfo->version) {
dev_err(>dev, "missing platform_data\n");
- goto bad0;
+ return ret;
}
if (uioinfo->handler || uioinfo->irqcontrol ||
uioinfo->irq_flags & IRQF_SHARED) {
dev_err(>dev, "interrupt configuration error\n");
- goto bad0;
+ return ret;
}
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
- ret = -ENOMEM;
dev_err(>dev, "unable to kmalloc\n");
- goto bad0;
+ return -ENOMEM;
}
priv->uioinfo = uioinfo;
@@ -153,7 +152,7 @@ static int uio_pdrv_genirq_probe(struct platform_device
*pdev)
uioinfo->irq = UIO_IRQ_NONE;
else if (ret < 0) {
dev_err(>dev, "failed to get IRQ\n");
- goto bad1;
+ return ret;
}
}
@@ -209,20 +208,12 @@ static int uio_pdrv_genirq_probe(struct platform_device
*pdev)
ret = uio_register_device(>dev, priv->uioinfo);
if (ret) {
dev_err(>dev, "unable to register uio device\n");
- goto bad2;
+ pm_runtime_disable(>dev);
+ return ret;
}
platform_set_drvdata(pdev, priv);
return 0;
- bad2:
- pm_runtime_disable(>dev);
- bad1:
- kfree(priv);
- bad0:
- /* kfree uioinfo for OF */
- if (pdev->dev.of_node)
- kfree(uioinfo);
- return ret;
}
static int uio_pdrv_genirq_remove(struct platform_device *pdev)
@@ -235,11 +226,6 @@ static int uio_pdrv_genirq_remove(struct platform_device
*pdev)
priv->uioinfo->handler = NULL;
[098/251] xen-netfront: pull on receive skb may need to happen earlier
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Jan Beulich
[ Upstream commit 093b9c71b6e450e375f4646ba86faed0195ec7df ]
Due to commit 3683243b ("xen-netfront: use __pskb_pull_tail to ensure
linear area is big enough on RX") xennet_fill_frags() may end up
filling MAX_SKB_FRAGS + 1 fragments in a receive skb, and only reduce
the fragment count subsequently via __pskb_pull_tail(). That's a
result of xennet_get_responses() allowing a maximum of one more slot to
be consumed (and intermediately transformed into a fragment) if the
head slot has a size less than or equal to RX_COPY_THRESHOLD.
Hence we need to adjust xennet_fill_frags() to pull earlier if we
reached the maximum fragment count - due to the described behavior of
xennet_get_responses() this guarantees that at least the first fragment
will get completely consumed, and hence the fragment count reduced.
In order to not needlessly call __pskb_pull_tail() twice, make the
original call conditional upon the pull target not having been reached
yet, and defer the newly added one as much as possible (an alternative
would have been to always call the function right before the call to
xennet_fill_frags(), but that would imply more frequent cases of
needing to call it twice).
Signed-off-by: Jan Beulich
Acked-by: Wei Liu
Cc: Ian Campbell
Cc: sta...@vger.kernel.org (3.6 onwards)
Acked-by: Ian Campbell
Signed-off-by: David S. Miller
Signed-off-by: Steven Rostedt
---
drivers/net/xen-netfront.c | 50
1 file changed, 13 insertions(+), 37 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index ecac034..110c26c 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -275,8 +275,7 @@ no_skb:
break;
}
- __skb_fill_page_desc(skb, 0, page, 0, 0);
- skb_shinfo(skb)->nr_frags = 1;
+ skb_add_rx_frag(skb, 0, page, 0, 0, PAGE_SIZE);
__skb_queue_tail(>rx_batch, skb);
}
@@ -771,7 +770,6 @@ static RING_IDX xennet_fill_frags(struct netfront_info *np,
struct sk_buff_head *list)
{
struct skb_shared_info *shinfo = skb_shinfo(skb);
- int nr_frags = shinfo->nr_frags;
RING_IDX cons = np->rx.rsp_cons;
struct sk_buff *nskb;
@@ -780,19 +778,21 @@ static RING_IDX xennet_fill_frags(struct netfront_info
*np,
RING_GET_RESPONSE(>rx, ++cons);
skb_frag_t *nfrag = _shinfo(nskb)->frags[0];
- __skb_fill_page_desc(skb, nr_frags,
-skb_frag_page(nfrag),
-rx->offset, rx->status);
+ if (shinfo->nr_frags == MAX_SKB_FRAGS) {
+ unsigned int pull_to = NETFRONT_SKB_CB(skb)->pull_to;
- skb->data_len += rx->status;
+ BUG_ON(pull_to <= skb_headlen(skb));
+ __pskb_pull_tail(skb, pull_to - skb_headlen(skb));
+ }
+ BUG_ON(shinfo->nr_frags >= MAX_SKB_FRAGS);
+
+ skb_add_rx_frag(skb, shinfo->nr_frags, skb_frag_page(nfrag),
+ rx->offset, rx->status, PAGE_SIZE);
skb_shinfo(nskb)->nr_frags = 0;
kfree_skb(nskb);
-
- nr_frags++;
}
- shinfo->nr_frags = nr_frags;
return cons;
}
@@ -878,7 +878,8 @@ static int handle_incoming_queue(struct net_device *dev,
while ((skb = __skb_dequeue(rxq)) != NULL) {
int pull_to = NETFRONT_SKB_CB(skb)->pull_to;
- __pskb_pull_tail(skb, pull_to - skb_headlen(skb));
+ if (pull_to > skb_headlen(skb))
+ __pskb_pull_tail(skb, pull_to - skb_headlen(skb));
/* Ethernet work: Delayed to here as it peeks the header. */
skb->protocol = eth_type_trans(skb, dev);
@@ -964,35 +965,10 @@ err:
skb_shinfo(skb)->frags[0].page_offset = rx->offset;
skb_frag_size_set(_shinfo(skb)->frags[0], rx->status);
skb->data_len = rx->status;
+ skb->len += rx->status;
i = xennet_fill_frags(np, skb, );
- /*
-* Truesize approximates the size of true data plus
-* any supervisor overheads. Adding hypervisor
-* overheads has been shown to significantly reduce
-* achievable bandwidth with the default receive
-* buffer size. It is therefore not wise to account
-* for it here.
-*
-* After alloc_skb(RX_COPY_THRESHOLD), truesize is set
-* to RX_COPY_THRESHOLD + the supervisor
-* overheads. Here, we add the size of the data pulled
-* in
[088/251] USB: mos7840: fix memory leak in open
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Johan Hovold
[ Upstream commit 5f8a2e68b679b41cc8e9b642f2f5aa45dd678641 ]
Allocated urbs and buffers were never freed on errors in open.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Steven Rostedt
---
drivers/usb/serial/mos7840.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 3193d25..15cc47d 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -972,20 +972,20 @@ static int mos7840_open(struct tty_struct *tty, struct
usb_serial_port *port)
status = mos7840_get_reg_sync(port, mos7840_port->SpRegOffset, );
if (status < 0) {
dbg("Reading Spreg failed");
- return -1;
+ goto err;
}
Data |= 0x80;
status = mos7840_set_reg_sync(port, mos7840_port->SpRegOffset, Data);
if (status < 0) {
dbg("writing Spreg failed");
- return -1;
+ goto err;
}
Data &= ~0x80;
status = mos7840_set_reg_sync(port, mos7840_port->SpRegOffset, Data);
if (status < 0) {
dbg("writing Spreg failed");
- return -1;
+ goto err;
}
/* End of block to be checked */
@@ -994,7 +994,7 @@ static int mos7840_open(struct tty_struct *tty, struct
usb_serial_port *port)
);
if (status < 0) {
dbg("Reading Controlreg failed");
- return -1;
+ goto err;
}
Data |= 0x08; /* Driver done bit */
Data |= 0x20; /* rx_disable */
@@ -1002,7 +1002,7 @@ static int mos7840_open(struct tty_struct *tty, struct
usb_serial_port *port)
mos7840_port->ControlRegOffset, Data);
if (status < 0) {
dbg("writing Controlreg failed");
- return -1;
+ goto err;
}
/* do register settings here */
/* Set all regs to the device default values. */
@@ -1013,21 +1013,21 @@ static int mos7840_open(struct tty_struct *tty, struct
usb_serial_port *port)
status = mos7840_set_uart_reg(port, INTERRUPT_ENABLE_REGISTER, Data);
if (status < 0) {
dbg("disabling interrupts failed");
- return -1;
+ goto err;
}
/* Set FIFO_CONTROL_REGISTER to the default value */
Data = 0x00;
status = mos7840_set_uart_reg(port, FIFO_CONTROL_REGISTER, Data);
if (status < 0) {
dbg("Writing FIFO_CONTROL_REGISTER failed");
- return -1;
+ goto err;
}
Data = 0xcf;
status = mos7840_set_uart_reg(port, FIFO_CONTROL_REGISTER, Data);
if (status < 0) {
dbg("Writing FIFO_CONTROL_REGISTER failed");
- return -1;
+ goto err;
}
Data = 0x03;
@@ -1181,6 +1181,15 @@ static int mos7840_open(struct tty_struct *tty, struct
usb_serial_port *port)
serial, mos7840_port, port);
return 0;
+err:
+ for (j = 0; j < NUM_URBS; ++j) {
+ urb = mos7840_port->write_urb_pool[j];
+ if (!urb)
+ continue;
+ kfree(urb->transfer_buffer);
+ usb_free_urb(urb);
+ }
+ return status;
}
/*
--
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: "cpufreq: fix serialization issues with freq change notifiers" breaks cpufreq too
On 12 September 2013 06:13, Rafael J. Wysocki wrote: > Yes, if you can point to a specific driver having this problem. There are so many of those (I know it because I went through almost all drivers recently with my cleanup series): cpufreq-cpu0, omap-cpufreq, exynos-cpufreq, etc.. They all do this: A. If new freq is more than old: Increase voltage B. Change freq C. If new freq is less than old: decrease voltage -- 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-rc1] Dependency on module-init-tools >= 3.11 ?
On Thu, Sep 12, 2013 at 02:03:41PM +0900, Tetsuo Handa wrote: > Herbert Xu wrote: > > This way at least you'll have a working system until your initramfs > > tool is fixed to do the right thing. > > Thank you. But it is module-init-tools-3.9-21.el6_4 in RHEL 6.4. > We can't wait until Red Hat backports module-init-tools >= 3.11 to RHEL 6.x. > > Since most people are already using module-init-tools >= 3.11 and > there is workaround for my case (i.e. choose built-in), just updating > > module-init-tools 0.9.10 # depmod -V > > line at "Current Minimal Requirements" in Documentation/Changes will be OK. The trouble is not all distros will include the softdep modules in the initramfs. So for now I think we will have to live with a fallback. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] cpufreq: don't break string in print statements
As a rule its better not to break string (quoted inside "") in a print statement
even if it crosses 80 column boundary as that may introduce unwanted bugs and so
this patch rewrites one of the print statements..
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 28477eb..31f7845 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1192,8 +1192,8 @@ static int __cpufreq_remove_dev_prepare(struct device
*dev,
unlock_policy_rwsem_write(cpu);
if (!frozen) {
- pr_debug("%s: policy Kobject moved to cpu: %d "
-"from: %d\n",__func__, new_cpu, cpu);
+ pr_debug("%s: policy Kobject moved to cpu: %d
from: %d\n",
+ __func__, new_cpu, cpu);
}
}
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] cpufreq: don't update policy->cpu while removing while removing other CPUs
With a recent change the logic here is changed a bit and I just figured out it
is something we don't want.
Consider we have four CPUs (0,1,2,3) managed by a policy and policy->cpu is set
to 0. Now we are suspending and hence we call __cpufreq_remove_dev_prepare() for
cpu 1, 2 & 3..
With the current code we always call cpufreq_nominate_new_policy_cpu() for cpu
1, 2 & 3 whereas we should skipped most of __cpufreq_remove_dev_prepare()
routine.
Lets fix it by moving the check for !frozen inside the first if block.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5e0a82e..0e11fcb 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1182,8 +1182,9 @@ static int __cpufreq_remove_dev_prepare(struct device
*dev,
cpumask_clear_cpu(cpu, policy->cpus);
unlock_policy_rwsem_write(cpu);
- if (cpu != policy->cpu && !frozen) {
- sysfs_remove_link(>kobj, "cpufreq");
+ if (cpu != policy->cpu) {
+ if (!frozen)
+ sysfs_remove_link(>kobj, "cpufreq");
} else if (cpus > 1) {
new_cpu = cpufreq_nominate_new_policy_cpu(policy, cpu, frozen);
if (new_cpu >= 0) {
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] cpufreq: remove __cpufreq_remove_dev()
Nobody except cpufreq_remove_dev() is calling __cpufreq_remove_dev() and so we
don't need separate routines here. Lets merge code from __cpufreq_remove_dev()
to cpufreq_remove_dev() and get rid of __cpufreq_remove_dev().
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 31f7845..5e0a82e 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1285,36 +1285,26 @@ static int __cpufreq_remove_dev_finish(struct device
*dev,
}
/**
- * __cpufreq_remove_dev - remove a CPU device
+ * cpufreq_remove_dev - remove a CPU device
*
* Removes the cpufreq interface for a CPU device.
* Caller should already have policy_rwsem in write mode for this CPU.
* This routine frees the rwsem before returning.
*/
-static inline int __cpufreq_remove_dev(struct device *dev,
- struct subsys_interface *sif,
- bool frozen)
-{
- int ret;
-
- ret = __cpufreq_remove_dev_prepare(dev, sif, frozen);
-
- if (!ret)
- ret = __cpufreq_remove_dev_finish(dev, sif, frozen);
-
- return ret;
-}
-
static int cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif)
{
unsigned int cpu = dev->id;
- int retval;
+ int ret;
if (cpu_is_offline(cpu))
return 0;
- retval = __cpufreq_remove_dev(dev, sif, false);
- return retval;
+ ret = __cpufreq_remove_dev_prepare(dev, sif, false);
+
+ if (!ret)
+ ret = __cpufreq_remove_dev_finish(dev, sif, false);
+
+ return ret;
}
static void handle_update(struct work_struct *work)
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] cpufreq: use correct values of cpus in __cpufreq_remove_dev_finish()
This broke after a recent change "cedb70a cpufreq: Split __cpufreq_remove_dev()
into two parts" from Srivatsa..
Consider a scenario where we have two CPUs in a policy (0 & 1) and we are
removing cpu 1. On the call to __cpufreq_remove_dev_prepare() we have cleared 1
from policy->cpus and now on a call to __cpufreq_remove_dev_finish() we read
cpumask_weight of policy->cpus, which will come as 1 and this code will behave
as if we are removing the last cpu from policy :)
Fix it by clearing cpu mask in __cpufreq_remove_dev_finish() instead of
__cpufreq_remove_dev_prepare().
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 0e11fcb..b556d46 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1175,12 +1175,9 @@ static int __cpufreq_remove_dev_prepare(struct device
*dev,
policy->governor->name, CPUFREQ_NAME_LEN);
#endif
- WARN_ON(lock_policy_rwsem_write(cpu));
+ lock_policy_rwsem_read(cpu);
cpus = cpumask_weight(policy->cpus);
-
- if (cpus > 1)
- cpumask_clear_cpu(cpu, policy->cpus);
- unlock_policy_rwsem_write(cpu);
+ unlock_policy_rwsem_read(cpu);
if (cpu != policy->cpu) {
if (!frozen)
@@ -1222,9 +1219,12 @@ static int __cpufreq_remove_dev_finish(struct device
*dev,
return -EINVAL;
}
- lock_policy_rwsem_read(cpu);
+ WARN_ON(lock_policy_rwsem_write(cpu));
cpus = cpumask_weight(policy->cpus);
- unlock_policy_rwsem_read(cpu);
+
+ if (cpus > 1)
+ cpumask_clear_cpu(cpu, policy->cpus);
+ unlock_policy_rwsem_write(cpu);
/* If cpu is last user of policy, free policy */
if (cpus == 1) {
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] cpufreq: Last minute fixes for 3.12
Hi Rafael/Srivatsa, These are some last minute fixes for 3.12. I have found them while looking at the code to fix the latest suspend/resume crashes we see (Reported by Stephen).. I believe at some place these are behind those crashes, otherwise people with a single cluster or single policy couldn't have faced it.. Like Stephen as he was working on Tegra. I thought you will wait for my conversation with Srivatsa to get over before actually applying his patches, but saw that just happened :) No issues, we can talk a bit more about the problems for now and then you can get whatever patches are required for 3.12-rc2 First three of the patchset are minor cleanups (you may or may not take them for 3.12), but last two are some real fixes.. I haven't faced any issue without them but simply found them in code review. @Stephen: Probably you can try my branch: cpufreq-suspend-fix, which has these patches without Srivatsa's patches (though some bits of those will also be required I believe for multicluster systems).. -- viresh Viresh Kumar (5): cpufreq: Remove extra blank line cpufreq: don't break string in print statements cpufreq: remove __cpufreq_remove_dev() cpufreq: don't update policy->cpu while removing while removing other CPUs cpufreq: use correct values of cpus in __cpufreq_remove_dev_finish() drivers/cpufreq/cpufreq.c | 50 +++ 1 file changed, 20 insertions(+), 30 deletions(-) -- 1.7.12.rc2.18.g61b472e -- 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/5] cpufreq: Remove extra blank line
We don't need a blank line just at start of a block, lets remove it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5a64f66..28477eb 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1185,7 +1185,6 @@ static int __cpufreq_remove_dev_prepare(struct device
*dev,
if (cpu != policy->cpu && !frozen) {
sysfs_remove_link(>kobj, "cpufreq");
} else if (cpus > 1) {
-
new_cpu = cpufreq_nominate_new_policy_cpu(policy, cpu, frozen);
if (new_cpu >= 0) {
WARN_ON(lock_policy_rwsem_write(cpu));
--
1.7.12.rc2.18.g61b472e
--
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] Documentation/kvm: Update cpuid documentation for steal time and pv eoi
On 09/04/2013 02:18 PM, Raghavendra K T wrote: Signed-off-by: Raghavendra K T --- Changes in V2: Correction in the description of steal time and added msr info (Michael S Tsirkin) Documentation/virtual/kvm/cpuid.txt | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt index 22ff659..6c4fb20 100644 --- a/Documentation/virtual/kvm/cpuid.txt +++ b/Documentation/virtual/kvm/cpuid.txt @@ -43,6 +43,16 @@ KVM_FEATURE_CLOCKSOURCE2 || 3 || kvmclock available at msrs KVM_FEATURE_ASYNC_PF || 4 || async pf can be enabled by || || writing to msr 0x4b564d02 -- +KVM_FEATURE_STEAL_TIME || 5 || Steal time available at msr + || || 0x4b564d03. The feature is enabled + || || by guest when host has schedstat + || || or task delay accounting support. +-- +KVM_FEATURE_PV_EOI || 6 || overrides the generic EOI + || || implementation with a + || || paravirtualized version. Available + || || at msr 0x4b564d04. +-- KVM_FEATURE_PV_UNHALT || 7 || guest checks this feature bit || || before enabling paravirtualized || || spinlock support. Michael, Are you okay with the above patch. Please let me know. -- 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-rc1] Dependency on module-init-tools >= 3.11 ?
Herbert Xu wrote: > This way at least you'll have a working system until your initramfs > tool is fixed to do the right thing. Thank you. But it is module-init-tools-3.9-21.el6_4 in RHEL 6.4. We can't wait until Red Hat backports module-init-tools >= 3.11 to RHEL 6.x. Since most people are already using module-init-tools >= 3.11 and there is workaround for my case (i.e. choose built-in), just updating module-init-tools 0.9.10 # depmod -V line at "Current Minimal Requirements" in Documentation/Changes will be OK. Regards. -- 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/
[Bug report] Warning when hot-add an ACPI0004 device.
Hi Rafael, Toshi, When we hot-add an ACPI0004 device, we got the following warning: acpi ACPI0004:01: Attempt to re-insert The ACPI0004 device is a System Board in Fujitsu server, which has two numa nodes (processors and memory). It seems that we reserved the ACPI_NOTIFY_DEVICE_CHECK event twice in acpi_hotplug_notify_cb(). According to bisect, this happens after the following commit: From 68a67f6c78b80525d9b3c6672e7782de95e56a83 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Sun, 3 Mar 2013 23:05:55 +0100 Subject: [PATCH 1/1] ACPI / container: Use common hotplug code Switch the ACPI container driver to using common device hotplug code introduced previously. This reduces the driver down to a trivial definition and registration of a struct acpi_scan_handler object. Signed-off-by: Rafael J. Wysocki Acked-by: Toshi Kani Tested-by: Toshi Kani --- drivers/acpi/container.c | 146 --- 1 file changed, 10 insertions(+), 136 deletions(-) I'm now investigating this problem. If you have any idea about why this happens, please let me know. 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] uprobes: Fix limiting un-nested return probes
Hi Oleg, On 09/09/2013 08:25 PM, Oleg Nesterov wrote: On 09/09, Anton Arapov wrote: On Sun, Sep 08, 2013 at 06:32:32PM +0200, Oleg Nesterov wrote: Not sure, but I can be easily wrong... afaics we need something like below, no? Anton? Oleg, your guess is correct. My original intention was to limit by depth the chained only probes. But later, after your review, we've decided /based on safety concerns/ to limit it hard. Chained or not, we allocate return_instance every time, so we certainly need to account to limit the depth unconditionally. Unless we reuse the same return_instance if chained, but this is another story. Hmm, agreed. Thanks for the description. The decrement 'utask->depth--;' in my own tree is above the 'if (!chained)' check. I think it got mangled somehow when I rebased the code before I sent it to lkml. OK, thanks, I'll write the changelog and re-send the patch below. Anton. Oleg. --- x/kernel/events/uprobes.c +++ x/kernel/events/uprobes.c @@ -1682,12 +1682,10 @@ static bool handle_trampoline(struct pt_ tmp = ri; ri = ri->next; kfree(tmp); + utask->depth--; if (!chained) break; - - utask->depth--; - BUG_ON(!ri); } -- Thanks Hemant -- 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: RFD: Non-Disruptive Core Dump Infrastructure
On 09/12/2013 12:57 AM, KOSAKI Motohiro wrote: > (9/3/13 4:39 AM), Janani Venkataraman wrote: >> Hello, >> >> We are working on an infrastructure to create a system core file of a >> specific >> process at run-time, non-disruptively. It can also be extended to a >> case where >> a process is able to take a self-core dump. >> >> gcore, an existing utility creates a core image of the specified >> process. It >> attaches to the process using gdb and runs the gdb gcore command and then >> detaches. In gcore the dump cannot be issued from a signal handler >> context as >> fork() is not signal safe and moreover it is disruptive in nature as >> the gdb >> attaches using ptrace which sends a SIGSTOP signal. Hence the gcore >> method >> cannot be used if the process wants to initiate a self dump. > > Maybe I'm missing something. But why gcore uses c-level fork()? gcore > need to > call pthread-at-fork handler? No. gcore need to flush stdio buffer? No. > Let me clarify. If an application wants to dump itself, it has to do a fork() and then exec the gcore with the pid of the appication to generate the dump. So, if the application wants to initiate the dump from a signal handler context, it may lead to trouble. Thanks Suzuki -- 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] md/raid5: avoid deadlock when raid5 array has unack badblocks during md_stop_writes.
On Mon, 2 Sep 2013 01:09:55 -0400 ycbzzj...@gmail.com wrote:
> From: Bian Yu
>
> When raid5 hit a fresh badblock, this badblock will flagged as unack
> badblock until md_update_sb is called.
> But md_stop/reboot/md_set_readonly will avoid raid5d call md_update_sb
> in md_check_recovery, the badblock will always be unack, so raid5d
> thread enter a infinite loop and never can unregister sync_thread
> that cause deadlock.
>
> To solve this, before md_stop_writes call md_unregister_thread, set
> MD_STOPPING_WRITES on mddev->flags. In raid5.c analyse_stripe judge
> MD_STOPPING_WRITES bit on mddev->flags, if setted don't block rdev
> to wait md_update_sb. so raid5d thread can be stopped.
>
> I can reproduce it by using follow way:
> When raid5 array is recovering and hit a fresh badblock, then shutdown array
> at once.
>
> [ 480.850203] Not tainted 3.11.0-next-20130906+ #4
> [ 480.852344] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [ 480.854380] [] md_do_sync+0x7e4/0xe60
> [ 480.854386] [] ? _raw_spin_unlock_irq+0x2b/0x40
> [ 480.854395] [] ? md_unregister_thread+0x90/0x90
> [ 480.854400] [] ? trace_hardirqs_on+0xd/0x10
> [ 480.854405] [] md_thread+0x11f/0x170
> [ 480.854410] [] ? md_unregister_thread+0x90/0x90
> [ 480.854415] [] kthread+0xd6/0xe0
> [ 480.854423] [] ? __init_kthread_worker+0x70/0x70
> [ 480.854428] [] ret_from_fork+0x7c/0xb0
> [ 480.854432] [] ? __init_kthread_worker+0x70/0x70
> [ 480.854435] no locks held by md0_resync/3246.
> [ 480.854437] INFO: task mdadm:3257 blocked for more than 120 seconds.
> [ 480.854438] Not tainted 3.11.0-next-20130906+ #4
> [ 480.854439] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [ 480.854442] mdadm D 5024 3257 3209
> 0x0080
> [ 480.854445] 880138c37b18 0046
> 880037d3b120
> [ 480.854447] 88013a038720 88013a038000 00013500
> 880138c37fd8
> [ 480.854449] 880138c36010 00013500 00013500
> 880138c37fd8
> [ 480.854449] Call Trace:
> [ 480.854452] [] schedule+0x24/0x70
> [ 480.854453] [] schedule_timeout+0x175/0x200
> [ 480.854455] [] ? mark_held_locks+0x80/0x130
> [ 480.854457] [] ? _raw_spin_unlock_irq+0x2b/0x40
> [ 480.854459] [] ? trace_hardirqs_on_caller+0xfd/0x1c0
> [ 480.854461] [] ? trace_hardirqs_on+0xd/0x10
> [ 480.854463] [] wait_for_completion+0xa0/0x110
> [ 480.854465] [] ? try_to_wake_up+0x300/0x300
> [ 480.854467] [] kthread_stop+0x4c/0xe0
> [ 480.854468] [] md_unregister_thread+0x4e/0x90
> [ 480.854470] [] md_reap_sync_thread+0x1d/0x140
> [ 480.854472] [] __md_stop_writes+0x2b/0x80
> [ 480.854473] [] do_md_stop+0x91/0x4d0
> [ 480.854475] [] ? md_ioctl+0xf7/0x15c0
> [ 480.854477] [] ? trace_hardirqs_on+0xd/0x10
> [ 480.854479] [] md_ioctl+0xef9/0x15c0
> [ 480.854481] [] ? handle_mm_fault+0x17d/0x920
>
> Signed-off-by: Bian Yu
> ---
> drivers/md/md.c|2 ++
> drivers/md/md.h|4
> drivers/md/raid5.c |3 ++-
> 3 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index adf4d7e..54ef71f 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -5278,6 +5278,7 @@ static void md_clean(struct mddev *mddev)
> static void __md_stop_writes(struct mddev *mddev)
> {
> set_bit(MD_RECOVERY_FROZEN, >recovery);
> + set_bit(MD_STOPPING_WRITES, >flags);
> if (mddev->sync_thread) {
> set_bit(MD_RECOVERY_INTR, >recovery);
> md_reap_sync_thread(mddev);
> @@ -5294,6 +5295,7 @@ static void __md_stop_writes(struct mddev *mddev)
> mddev->in_sync = 1;
> md_update_sb(mddev, 1);
> }
> + clear_bit(MD_STOPPING_WRITES, >flags);
> }
>
> void md_stop_writes(struct mddev *mddev)
> diff --git a/drivers/md/md.h b/drivers/md/md.h
> index 608050c..a24ae1d 100644
> --- a/drivers/md/md.h
> +++ b/drivers/md/md.h
> @@ -214,6 +214,10 @@ struct mddev {
> #define MD_STILL_CLOSED 4 /* If set, then array has not been
> opened since
>* md_ioctl checked on it.
>*/
> +#define MD_STOPPING_WRITES 5 /* If set, raid5 shouldn't set unacknowledged
> + * badblock blocked in analyse_stripe to avoid
> + * infinite loop.
> + */
>
> int suspended;
> atomic_tactive_io;
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index f9972e2..ff1aecf 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -3446,7 +3446,8 @@ static void analyse_stripe(struct stripe_head *sh,
> struct stripe_head_state *s)
> if (rdev) {
> is_bad = is_badblock(rdev, sh->sector, STRIPE_SECTORS,
>
[PATCH] gpu: host1x: use %pa to print dma_addr_t
This removes two warnings where dma_addr_t variables were printed using %x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t: drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' Signed-off-by: Olof Johansson --- drivers/gpu/host1x/hw/cdma_hw.c |4 ++-- drivers/gpu/host1x/hw/debug_hw.c |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/host1x/hw/cdma_hw.c b/drivers/gpu/host1x/hw/cdma_hw.c index 2ee4ad5..3db3011 100644 --- a/drivers/gpu/host1x/hw/cdma_hw.c +++ b/drivers/gpu/host1x/hw/cdma_hw.c @@ -54,8 +54,8 @@ static void cdma_timeout_cpu_incr(struct host1x_cdma *cdma, u32 getptr, u32 *p = (u32 *)((u32)pb->mapped + getptr); *(p++) = HOST1X_OPCODE_NOP; *(p++) = HOST1X_OPCODE_NOP; - dev_dbg(host1x->dev, "%s: NOP at 0x%x\n", __func__, - pb->phys + getptr); + dev_dbg(host1x->dev, "%s: NOP at %pa+0x%x\n", __func__, + >phys, getptr); getptr = (getptr + 8) & (pb->size_bytes - 1); } wmb(); diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c index 334c038..346a54b 100644 --- a/drivers/gpu/host1x/hw/debug_hw.c +++ b/drivers/gpu/host1x/hw/debug_hw.c @@ -171,8 +171,8 @@ static void show_channel_gathers(struct output *o, struct host1x_cdma *cdma) continue; } - host1x_debug_output(o, "GATHER at %08x+%04x, %d words\n", - g->base, g->offset, g->words); + host1x_debug_output(o, "GATHER at %pa+%04x, %d words\n", + >base, g->offset, g->words); show_gather(o, g->base + g->offset, g->words, cdma, g->base, mapped); -- 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] dma: use %pa to print dma_addr_t
This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
dma_addr_t might then be 64-bit:
drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type
'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type
'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type
'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type
'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type
'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type
'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type
'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type
'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type
'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type
'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of
type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
Signed-off-by: Olof Johansson
---
drivers/dma/imx-dma.c | 20 ++--
drivers/dma/imx-sdma.c |8
drivers/dma/ipu/ipu_idmac.c |6 --
3 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index 78f8ca5..fcc8a12 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -576,9 +576,9 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
imx_dmav1_writel(imxdma, d->len, DMA_CNTR(imxdmac->channel));
- dev_dbg(imxdma->dev, "%s channel: %d dest=0x%08x src=0x%08x "
+ dev_dbg(imxdma->dev, "%s channel: %d dest=%pa src=%pa "
"dma_length=%d\n", __func__, imxdmac->channel,
- d->dest, d->src, d->len);
+ >dest, >src, d->len);
break;
/* Cyclic transfer is the same as slave_sg with special sg
configuration. */
@@ -591,9 +591,9 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
DMA_CCR(imxdmac->channel));
dev_dbg(imxdma->dev, "%s channel: %d sg=%p sgcount=%d "
- "total length=%d dev_addr=0x%08x (dev2mem)\n",
+ "total length=%d dev_addr=%pa (dev2mem)\n",
__func__, imxdmac->channel, d->sg, d->sgcount,
- d->len, imxdmac->per_address);
+ d->len, >per_address);
} else if (d->direction == DMA_MEM_TO_DEV) {
imx_dmav1_writel(imxdma, imxdmac->per_address,
DMA_DAR(imxdmac->channel));
@@ -601,9 +601,9 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
DMA_CCR(imxdmac->channel));
dev_dbg(imxdma->dev, "%s channel: %d sg=%p sgcount=%d "
- "total length=%d dev_addr=0x%08x (mem2dev)\n",
+ "total length=%d dev_addr=%pa (mem2dev)\n",
__func__, imxdmac->channel, d->sg, d->sgcount,
- d->len, imxdmac->per_address);
+ d->len, >per_address);
} else {
dev_err(imxdma->dev, "%s channel: %d bad dma mode\n",
__func__, imxdmac->channel);
@@ -927,8 +927,8 @@ static struct dma_async_tx_descriptor
*imxdma_prep_dma_memcpy(
struct imxdma_engine *imxdma = imxdmac->imxdma;
struct imxdma_desc *desc;
- dev_dbg(imxdma->dev, "%s channel: %d src=0x%x dst=0x%x len=%d\n",
- __func__, imxdmac->channel, src, dest, len);
+ dev_dbg(imxdma->dev, "%s channel: %d src=%pa dst=%pa len=%d\n",
+ __func__, imxdmac->channel, , , len);
if (list_empty(>ld_free) ||
imxdma_chan_is_doing_cyclic(imxdmac))
@@ -957,9 +957,9 @@ static struct dma_async_tx_descriptor
*imxdma_prep_dma_interleaved(
struct imxdma_engine *imxdma = imxdmac->imxdma;
struct imxdma_desc *desc;
- dev_dbg(imxdma->dev, "%s channel: %d src_start=0x%x dst_start=0x%x\n"
+ dev_dbg(imxdma->dev,
Re: commit 5fe212364 causes division by zero with large bauds
Actually, here it is, but not formatted properly
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 816d1a2..146e712 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -240,14 +240,14 @@ serial_omap_baud_is_mode16(struct uart_port
*port, unsigned int baud)
{
unsigned int n13 = port->uartclk / (13 * baud);
unsigned int n16 = port->uartclk / (16 * baud);
- int baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
- int baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
+ int baudAbsDiff13 = n13 ? (baud - (port->uartclk / (13 * n13))) : INT_MAX;
+ int baudAbsDiff16 = n16 ? (baud - (port->uartclk / (16 * n16))) : INT_MAX;
if(baudAbsDiff13 < 0)
baudAbsDiff13 = -baudAbsDiff13;
if(baudAbsDiff16 < 0)
baudAbsDiff16 = -baudAbsDiff16;
- return (baudAbsDiff13 > baudAbsDiff16);
+ return (baudAbsDiff13 >= baudAbsDiff16);
}
/*
@@ -258,13 +258,13 @@ serial_omap_baud_is_mode16(struct uart_port
*port, unsigned int baud)
static unsigned int
serial_omap_get_divisor(struct uart_port *port, unsigned int baud)
{
- unsigned int divisor;
+ unsigned int mode;
if (!serial_omap_baud_is_mode16(port, baud))
- divisor = 13;
+ mode = 13;
else
- divisor = 16;
- return port->uartclk/(baud * divisor);
+ mode = 16;
+ return port->uartclk/(mode * baud);
}
static void serial_omap_enable_ms(struct uart_port *port)
On Thu, Sep 12, 2013 at 7:32 AM, Alexey Pelykh wrote:
> On Wed, Sep 11, 2013 at 11:47 PM, Felipe Balbi wrote:
>> Hi,
>>
>> On Wed, Sep 11, 2013 at 10:19:47PM +0300, Alexey Pelykh wrote:
>>> On Wed, Sep 11, 2013 at 10:00 PM, Felipe Balbi wrote:
>>> > On Wed, Sep 11, 2013 at 09:48:13PM +0300, Alexey Pelykh wrote:
>>> >> On Wed, Sep 11, 2013 at 9:38 PM, Felipe Balbi wrote:
>>> >> > Hi,
>>> >> >
>>> >> > On Wed, Sep 11, 2013 at 09:22:26AM +0300, Alexey Pelykh wrote:
>>> >> >> Hi Felipe,
>>> >> >>
>>> >> >> Thanks for finding this issue. Indeed, there is a bug on 3M+ baud
>>> >> >> rates. First patch is close to a complete fix, but still contains
>>> >> >> div-by-zero issue. Here is my version:
>>> >> >>
>>> >> >> diff --git a/drivers/tty/serial/omap-serial.c
>>> >> >> b/drivers/tty/serial/omap-serial.c
>>> >> >> index 816d1a2..808a880 100644
>>> >> >> --- a/drivers/tty/serial/omap-serial.c
>>> >> >> +++ b/drivers/tty/serial/omap-serial.c
>>> >> >> @@ -240,8 +240,8 @@ serial_omap_baud_is_mode16(struct uart_port *port,
>>> >> >> unsigned int baud)
>>> >> >> {
>>> >> >> unsigned int n13 = port->uartclk / (13 * baud);
>>> >> >> unsigned int n16 = port->uartclk / (16 * baud);
>>> >> >> - int baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
>>> >> >> - int baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
>>> >> >> + int baudAbsDiff13 = n13 ? (baud - (port->uartclk / (13 *
>>> >> >> n13))) : INT_MAX;
>>> >> >> + int baudAbsDiff16 = n16 ? (baud - (port->uartclk / (16 *
>>> >> >> n16))) : INT_MAX;
>>> >> >
>>> >> > IOW:
>>> >> >
>>> >> > int baudAbsDiff13 = 0;
>>> >> >
>>> >> > if (n13)
>>> >> > baudAbsDiff13 = (baud - (port->uartclk / (13 * n13)));
>>> >>
>>> >> Not quite same code, INT_MAX instead of 0. With 0 a div-by-zero
>>> >> exception will still occur on 3686400.
>>> >
>>> > why, there's no division after that point, right ? Besides,
>>> > serial_omap_baud_is_mode16() is supposed to return a boolean value.
>>> >
>>> > Setting baudAbsDiff1[36] to 0 will cause no problems, you're only using
>>> > that value with a boolean expression, no divisions whatsoever. Division
>>> > is done after using serial_omap_baud_is_mode16() to initialize divisor
>>> > to 13 or 16 (which is a misnamer, since that's the oversampling
>>> > parameter).
>>> >
>>>
>>> Yes, variables are a bit misnamed, that should be fixed someday.
>>> Regarding 0 vs INT_MAX, in case of 0 values will be
>>> 300: divisor = 12307 (13)
>>> 600: divisor = 6153 (13)
>>> 1200: divisor = 3076 (13)
>>> 2400: divisor = 1538 (13)
>>> 4800: divisor = 625 (16)
>>> 9600: divisor = 384 (13)
>>> 14400: divisor = 256 (13)
>>> 19200: divisor = 192 (13)
>>> 28800: divisor = 128 (13)
>>> 38400: divisor = 96 (13)
>>> 57600: divisor = 64 (13)
>>> 115200: divisor = 32 (13)
>>> 230400: divisor = 16 (13)
>>> 460800: divisor = 8 (13)
>>> 921600: divisor = 4 (13)
>>> 100: divisor = 3 (16)
>>> 1843200: divisor = 2 (13)
>>> 300: divisor = 1 (16)
>>> 3686400: divisor = 0 (16) << error here, should be 1 (13), as it is with
>>> INT_MAX
>>
>> I get it now... your boolean check wants to use the closer baud to
>> requested baud, so it's mode16 if the delta between baudAbsDiff16 and
>> requested rate is less than delta between baudAbsDiff13 and requested
>> baud.
>>
>>> >> > which is exactly what my patch did. I fail to see where division by
>>> >> > zero
>>> >> > would be coming from.
>>> >> >
>>> >> >> if(baudAbsDiff13 < 0)
>>> >> >> baudAbsDiff13 = -baudAbsDiff13;
>>> >> >> if(baudAbsDiff16 < 0)
>>> >> >>
linux-next: Tree for Sep 12
Hi all, Please do not add any code for v3.13 to your linux-next included branches until after v3.12-rc1 is released. Changes since 20130911: The akpm tree gained a conflict against Linus' tree. 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. 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. We are up to 222 trees (counting Linus' and 30 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. 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 (c2d9572 Merge branch 'akpm' (patches from Andrew Morton)) Merging fixes/master (fa8218d Merge tag 'regmap-v3.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap) Merging kbuild-current/rc-fixes (ad81f05 Linux 3.11-rc1) Merging arc-current/for-curr (07b9b65 ARC: fix new Section mismatches in build (post __cpuinit cleanup)) Merging arm-current/fixes (6e46645 Linux 3.11) Merging m68k-current/for-linus (5549005 m68k/atari: ARAnyM - Always use physical addresses in NatFeat calls) Merging metag-fixes/fixes (3b2f64d Linux 3.11-rc2) Merging powerpc-merge/merge (363edbe powerpc: Default arch idle could cede processor on pseries) Merging sparc/master (4de9ad9 Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile) Merging net/master (f3ad857 net_sched: htb: fix a typo in htb_change_class()) Merging ipsec/master (302a50b xfrm: Fix potential null pointer dereference in xdst_queue_output) Merging sound-current/for-linus (3d0049e Merge tag 'asoc-v3.12-4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (a923874 Merge tag 'pci-v3.12-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci) Merging wireless/master (f4e1a4d rt2800: change initialization sequence to fix system freeze) Merging driver-core.current/driver-core-linus (816434e Merge branch 'x86-spinlocks-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging tty.current/tty-linus (c095ba7 Linux 3.11-rc4) Merging usb.current/usb-linus (26b0332 Merge tag 'dmaengine-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine) Merging staging.current/staging-linus (26b0332 Merge tag 'dmaengine-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine) Merging char-misc.current/char-misc-linus (b36f4be Linux 3.11-rc6) Merging input-current/for-linus (c7dc657 Input: evdev - add EVIOCREVOKE ioctl) Merging md-current/for-linus (f94c0b6 md/raid5: fix interaction of 'replace' and 'recovery'.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (77dbd7a crypto: api - Fix race condition in larval lookup) Merging ide/master (64110c1 ide: sgiioc4: Staticize ioc4_ide_attach_one()) Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging devicetree-current/devicetree/merge (cf9e236 of/irq: init struct resource to 0 in of_irq_to_resource()) Merging rr-fixes/fixes (6c2580c Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32) Merging mfd-fixes/master (5649d8f mfd: ab8500-sysctrl: Let sysctrl driver work without pdata) Merging vfio-fixes/for-lin
Re: commit 5fe212364 causes division by zero with large bauds
On Wed, Sep 11, 2013 at 11:47 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Sep 11, 2013 at 10:19:47PM +0300, Alexey Pelykh wrote:
>> On Wed, Sep 11, 2013 at 10:00 PM, Felipe Balbi wrote:
>> > On Wed, Sep 11, 2013 at 09:48:13PM +0300, Alexey Pelykh wrote:
>> >> On Wed, Sep 11, 2013 at 9:38 PM, Felipe Balbi wrote:
>> >> > Hi,
>> >> >
>> >> > On Wed, Sep 11, 2013 at 09:22:26AM +0300, Alexey Pelykh wrote:
>> >> >> Hi Felipe,
>> >> >>
>> >> >> Thanks for finding this issue. Indeed, there is a bug on 3M+ baud
>> >> >> rates. First patch is close to a complete fix, but still contains
>> >> >> div-by-zero issue. Here is my version:
>> >> >>
>> >> >> diff --git a/drivers/tty/serial/omap-serial.c
>> >> >> b/drivers/tty/serial/omap-serial.c
>> >> >> index 816d1a2..808a880 100644
>> >> >> --- a/drivers/tty/serial/omap-serial.c
>> >> >> +++ b/drivers/tty/serial/omap-serial.c
>> >> >> @@ -240,8 +240,8 @@ serial_omap_baud_is_mode16(struct uart_port *port,
>> >> >> unsigned int baud)
>> >> >> {
>> >> >> unsigned int n13 = port->uartclk / (13 * baud);
>> >> >> unsigned int n16 = port->uartclk / (16 * baud);
>> >> >> - int baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
>> >> >> - int baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
>> >> >> + int baudAbsDiff13 = n13 ? (baud - (port->uartclk / (13 *
>> >> >> n13))) : INT_MAX;
>> >> >> + int baudAbsDiff16 = n16 ? (baud - (port->uartclk / (16 *
>> >> >> n16))) : INT_MAX;
>> >> >
>> >> > IOW:
>> >> >
>> >> > int baudAbsDiff13 = 0;
>> >> >
>> >> > if (n13)
>> >> > baudAbsDiff13 = (baud - (port->uartclk / (13 * n13)));
>> >>
>> >> Not quite same code, INT_MAX instead of 0. With 0 a div-by-zero
>> >> exception will still occur on 3686400.
>> >
>> > why, there's no division after that point, right ? Besides,
>> > serial_omap_baud_is_mode16() is supposed to return a boolean value.
>> >
>> > Setting baudAbsDiff1[36] to 0 will cause no problems, you're only using
>> > that value with a boolean expression, no divisions whatsoever. Division
>> > is done after using serial_omap_baud_is_mode16() to initialize divisor
>> > to 13 or 16 (which is a misnamer, since that's the oversampling
>> > parameter).
>> >
>>
>> Yes, variables are a bit misnamed, that should be fixed someday.
>> Regarding 0 vs INT_MAX, in case of 0 values will be
>> 300: divisor = 12307 (13)
>> 600: divisor = 6153 (13)
>> 1200: divisor = 3076 (13)
>> 2400: divisor = 1538 (13)
>> 4800: divisor = 625 (16)
>> 9600: divisor = 384 (13)
>> 14400: divisor = 256 (13)
>> 19200: divisor = 192 (13)
>> 28800: divisor = 128 (13)
>> 38400: divisor = 96 (13)
>> 57600: divisor = 64 (13)
>> 115200: divisor = 32 (13)
>> 230400: divisor = 16 (13)
>> 460800: divisor = 8 (13)
>> 921600: divisor = 4 (13)
>> 100: divisor = 3 (16)
>> 1843200: divisor = 2 (13)
>> 300: divisor = 1 (16)
>> 3686400: divisor = 0 (16) << error here, should be 1 (13), as it is with
>> INT_MAX
>
> I get it now... your boolean check wants to use the closer baud to
> requested baud, so it's mode16 if the delta between baudAbsDiff16 and
> requested rate is less than delta between baudAbsDiff13 and requested
> baud.
>
>> >> > which is exactly what my patch did. I fail to see where division by zero
>> >> > would be coming from.
>> >> >
>> >> >> if(baudAbsDiff13 < 0)
>> >> >> baudAbsDiff13 = -baudAbsDiff13;
>> >> >> if(baudAbsDiff16 < 0)
>> >> >>
>> >> >>
>> >> >> With 48MHz UART clock, it will give
>> >> >> 300: divisor = 12307 (13), real rate 300 (0.00%)
>> >> >> 600: divisor = 6153 (13), real rate 600 (0.00%)
>> >> >> 1200: divisor = 3076 (13), real rate 1200 (0.00%)
>> >> >> 2400: divisor = 1538 (13), real rate 2400 (0.00%)
>> >> >
>> >> > TRM has these all set with oversampling of 16. In fact only 460800,
>> >> > 921600, 1843200 and 3686400 should be using oversampling of 13.
>> >> >
>> >>
>> >> That's true, but TRM anyways does not contain all possible baud rates
>> >> (1M e.g.). IMO, as long as error rate is the same as in TRM,
>> >> it makes no difference what combination of (mode, divisor) to use.
>> >>
>> >> > --
>> >> > balbi
>> >>
>> >> A complex solution may be implemented: use LUT for baud rates that TRM
>> >> defines explicitly, and use calculation if lookup failed.
>> >
>> > why would you try calculating anything if there is nothing in the table
>> > which can support it ? Whatever is in the lookup table, are the only
>> > baud rates the SoC supports, right ?
>> >
>>
>> Actually, I haven't found any statement in TRM, which would mention
>> that listed baudrates in referenced table are the only supported baud
>> rates,
>> and all others are illegal.
>
> "The UART clocks are connected to produce a baud rate of up to 3.6 Mbps.
> Table 24-122 lists the *supported* baud rates, requested divisor, and
> corresponding error versus the standard baud rate."
>
>> At least 1M which I use extensively works perfectly, and I can not
>> figure out any idea
[PATCH] serial: imx: Change cast to handle 64-bit resource_size_t
This resolves a warning where resource_size_t is larger than void *: drivers/tty/serial/imx.c:1542:6: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Since iomem_base is a void *, casting to unsigned long is safe. It's unclear to me that this comparison is truly needed, but it's there on several other drivers as well. Signed-off-by: Olof Johansson --- drivers/tty/serial/imx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index a0ebbc9..dd5e583 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -1539,7 +1539,7 @@ imx_verify_port(struct uart_port *port, struct serial_struct *ser) ret = -EINVAL; if (sport->port.uartclk / 16 != ser->baud_base) ret = -EINVAL; - if ((void *)sport->port.mapbase != ser->iomem_base) + if (sport->port.mapbase != (unsigned long)ser->iomem_base) ret = -EINVAL; if (sport->port.iobase != ser->port) ret = -EINVAL; -- 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: [3.12-rc1] Dependency on module-init-tools >= 3.11 ?
On Wed, Sep 11, 2013 at 08:43:19PM +0900, Tetsuo Handa wrote:
> Hello.
>
> I'm again having the boot failure problem due to commit 68411521 'Reinstate
> "crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform
> framework"' in linux.git .
OK, can you please try this patch on top of the current tree?
This way at least you'll have a working system until your initramfs
tool is fixed to do the right thing.
diff --git a/crypto/Makefile b/crypto/Makefile
index 2d5ed08..80019ba 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -83,7 +83,7 @@ obj-$(CONFIG_CRYPTO_ZLIB) += zlib.o
obj-$(CONFIG_CRYPTO_MICHAEL_MIC) += michael_mic.o
obj-$(CONFIG_CRYPTO_CRC32C) += crc32c.o
obj-$(CONFIG_CRYPTO_CRC32) += crc32.o
-obj-$(CONFIG_CRYPTO_CRCT10DIF) += crct10dif.o
+obj-$(CONFIG_CRYPTO_CRCT10DIF) += crct10dif_common.o crct10dif_generic.o
obj-$(CONFIG_CRYPTO_AUTHENC) += authenc.o authencesn.o
obj-$(CONFIG_CRYPTO_LZO) += lzo.o
obj-$(CONFIG_CRYPTO_LZ4) += lz4.o
diff --git a/crypto/crct10dif.c b/crypto/crct10dif.c
deleted file mode 100644
index 92aca96..000
--- a/crypto/crct10dif.c
+++ /dev/null
@@ -1,178 +0,0 @@
-/*
- * Cryptographic API.
- *
- * T10 Data Integrity Field CRC16 Crypto Transform
- *
- * Copyright (c) 2007 Oracle Corporation. All rights reserved.
- * Written by Martin K. Petersen
- * Copyright (C) 2013 Intel Corporation
- * Author: Tim Chen
- *
- * 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.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
- * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
- * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
- * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
- * SOFTWARE.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-struct chksum_desc_ctx {
- __u16 crc;
-};
-
-/* Table generated using the following polynomium:
- * x^16 + x^15 + x^11 + x^9 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1
- * gt: 0x8bb7
- */
-static const __u16 t10_dif_crc_table[256] = {
- 0x, 0x8BB7, 0x9CD9, 0x176E, 0xB205, 0x39B2, 0x2EDC, 0xA56B,
- 0xEFBD, 0x640A, 0x7364, 0xF8D3, 0x5DB8, 0xD60F, 0xC161, 0x4AD6,
- 0x54CD, 0xDF7A, 0xC814, 0x43A3, 0xE6C8, 0x6D7F, 0x7A11, 0xF1A6,
- 0xBB70, 0x30C7, 0x27A9, 0xAC1E, 0x0975, 0x82C2, 0x95AC, 0x1E1B,
- 0xA99A, 0x222D, 0x3543, 0xBEF4, 0x1B9F, 0x9028, 0x8746, 0x0CF1,
- 0x4627, 0xCD90, 0xDAFE, 0x5149, 0xF422, 0x7F95, 0x68FB, 0xE34C,
- 0xFD57, 0x76E0, 0x618E, 0xEA39, 0x4F52, 0xC4E5, 0xD38B, 0x583C,
- 0x12EA, 0x995D, 0x8E33, 0x0584, 0xA0EF, 0x2B58, 0x3C36, 0xB781,
- 0xD883, 0x5334, 0x445A, 0xCFED, 0x6A86, 0xE131, 0xF65F, 0x7DE8,
- 0x373E, 0xBC89, 0xABE7, 0x2050, 0x853B, 0x0E8C, 0x19E2, 0x9255,
- 0x8C4E, 0x07F9, 0x1097, 0x9B20, 0x3E4B, 0xB5FC, 0xA292, 0x2925,
- 0x63F3, 0xE844, 0xFF2A, 0x749D, 0xD1F6, 0x5A41, 0x4D2F, 0xC698,
- 0x7119, 0xFAAE, 0xEDC0, 0x6677, 0xC31C, 0x48AB, 0x5FC5, 0xD472,
- 0x9EA4, 0x1513, 0x027D, 0x89CA, 0x2CA1, 0xA716, 0xB078, 0x3BCF,
- 0x25D4, 0xAE63, 0xB90D, 0x32BA, 0x97D1, 0x1C66, 0x0B08, 0x80BF,
- 0xCA69, 0x41DE, 0x56B0, 0xDD07, 0x786C, 0xF3DB, 0xE4B5, 0x6F02,
- 0x3AB1, 0xB106, 0xA668, 0x2DDF, 0x88B4, 0x0303, 0x146D, 0x9FDA,
- 0xD50C, 0x5EBB, 0x49D5, 0xC262, 0x6709, 0xECBE, 0xFBD0, 0x7067,
- 0x6E7C, 0xE5CB, 0xF2A5, 0x7912, 0xDC79, 0x57CE, 0x40A0, 0xCB17,
- 0x81C1, 0x0A76, 0x1D18, 0x96AF, 0x33C4, 0xB873, 0xAF1D, 0x24AA,
- 0x932B, 0x189C, 0x0FF2, 0x8445, 0x212E, 0xAA99, 0xBDF7, 0x3640,
- 0x7C96, 0xF721, 0xE04F, 0x6BF8, 0xCE93, 0x4524, 0x524A, 0xD9FD,
- 0xC7E6, 0x4C51, 0x5B3F, 0xD088, 0x75E3, 0xFE54, 0xE93A, 0x628D,
- 0x285B, 0xA3EC, 0xB482, 0x3F35, 0x9A5E, 0x11E9, 0x0687, 0x8D30,
- 0xE232, 0x6985, 0x7EEB, 0xF55C, 0x5037, 0xDB80, 0xCCEE, 0x4759,
- 0x0D8F, 0x8638, 0x9156, 0x1AE1, 0xBF8A, 0x343D, 0x2353, 0xA8E4,
- 0xB6FF, 0x3D48, 0x2A26, 0xA191, 0x04FA, 0x8F4D, 0x9823, 0x1394,
- 0x5942, 0xD2F5, 0xC59B, 0x4E2C, 0xEB47, 0x60F0, 0x779E, 0xFC29,
- 0x4BA8, 0xC01F, 0xD771, 0x5CC6, 0xF9AD, 0x721A, 0x6574, 0xEEC3,
- 0xA415, 0x2FA2, 0x38CC, 0xB37B, 0x1610, 0x9DA7, 0x8AC9, 0x017E,
- 0x1F65, 0x94D2, 0x83BC, 0x080B, 0xAD60, 0x26D7, 0x31B9, 0xBA0E,
- 0xF0D8, 0x7B6F, 0x6C01, 0xE7B6, 0x42DD, 0xC96A, 0xDE04, 0x55B3
-};
-
-__u16 crc_t10dif_generic(__u16 crc, const unsigned char *buffer, size_t len)
-{
- unsigned int i;
-
- for (i = 0 ; i < len ; i++)
- crc = (crc << 8) ^ t10_dif_crc_table[((crc >> 8) ^
[PATCH] net: tulip: remove deprecated IRQF_DISABLED
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/dec/tulip/de4x5.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/dec/tulip/de4x5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/dec/tulip/de4x5.c
b/drivers/net/ethernet/dec/tulip/de4x5.c
index 2db6c57..263b92c 100644
--- a/drivers/net/ethernet/dec/tulip/de4x5.c
+++ b/drivers/net/ethernet/dec/tulip/de4x5.c
@@ -1321,7 +1321,7 @@ de4x5_open(struct net_device *dev)
if (request_irq(dev->irq, de4x5_interrupt, IRQF_SHARED,
lp->adapter_name, dev)) {
printk("de4x5_open(): Requested IRQ%d is busy - attemping
FAST/SHARE...", dev->irq);
- if (request_irq(dev->irq, de4x5_interrupt, IRQF_DISABLED | IRQF_SHARED,
+ if (request_irq(dev->irq, de4x5_interrupt, IRQF_SHARED,
lp->adapter_name, dev)) {
printk("\n Cannot get IRQ- reconfigure your
hardware.\n");
disable_ast(dev);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] sysfs: disentangle kobject namespace handling from sysfs
On Wed, Sep 11, 2013 at 08:38:32PM -0700, Eric W. Biederman wrote: > Greg KH writes: > > > On Wed, Sep 11, 2013 at 10:29:02PM -0400, Tejun Heo wrote: > >> Hello, > >> > >> I'll send out multiple patchsets to separate out sysfs from driver > >> core and kobject. The eventual goal is making sysfs modular enough so > >> that cgroup can replace its nightmarish cgroupfs implementation which > >> repeated and worsened all the past mistakes of sysfs. This patchset > >> is first of the effort and separates out kobject namespace handling > >> from sysfs. > >> > >> I never really understood why namespace support was added the way it > >> was added. > > > > I just took the patches and didn't ask questions :) > > Greg you don't get to play dumb you asked questions and required most of > the current strucuture of the code. I did? Ok, I'll buy that, but please review this code for what it is, nice cleanups and a sanity-check for the ns support in sysfs. It saves 100+ lines of code, what's wrong with that? > The code is convoluted by your request. I really asked for the existing callback chain to look like that? I did want ns to be "minimal" in sysfs as I didn't think it was going to be a good idea, and hoped it would go away. Much like all other kernel maintainers did for cgroups. Turns out, we were wrong, and now Tejun is stepping up and fixing it. So, if I asked for this before, I apologize, I was wrong. Just like I was wrong about containers and cgroups, and I'll probably be wrong about something else in the future. 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/
[PATCH] ethernet: amd: remove deprecated IRQF_DISABLED
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/amd/sun3lance.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/amd/sun3lance.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/sun3lance.c
b/drivers/net/ethernet/amd/sun3lance.c
index d6b2029..3d8c6b2 100644
--- a/drivers/net/ethernet/amd/sun3lance.c
+++ b/drivers/net/ethernet/amd/sun3lance.c
@@ -358,7 +358,7 @@ static int __init lance_probe( struct net_device *dev)
REGA(CSR0) = CSR0_STOP;
- if (request_irq(LANCE_IRQ, lance_interrupt, IRQF_DISABLED, "SUN3
Lance", dev) < 0) {
+ if (request_irq(LANCE_IRQ, lance_interrupt, 0, "SUN3 Lance", dev) < 0) {
#ifdef CONFIG_SUN3
iounmap((void __iomem *)ioaddr);
#endif
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] sysfs: @name comes before @ns
Hello, Eric. On Wed, Sep 11, 2013 at 08:39:27PM -0700, Eric W. Biederman wrote: > @ns is more significant so it should come first. > > Where do we have the backwards convention of putting @name first? Because @ns is optional and you end up with stupid stuff like sysfs_xxx_ns(@param, @ns, @name) sysfs_xxx(@param, @name) You put optional params after the mandatory ones. It may be difficult to accept for you but @ns is a *clearly* optional thing for sysfs. -- 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: [PATCHSET] sysfs: disentangle kobject namespace handling from sysfs
On Wed, Sep 11, 2013 at 08:37:23PM -0700, Eric W. Biederman wrote: > At a practical level you probably just want to copy the good parts of > the structure of sysfs, instead of attempting to share code. > > Sharing code is likely to get you into all kinds of problems with short > term hacks. What? Are you kidding me? This is one of the most basic principles which should be followed. The problem is not doing proper modular design from the get-go. You have it completely backwards. > > I never really understood why namespace support was added the way it > > was added. Namespace information is communicated to sysfs via > > callbacks and back-queries to upper layer, which is a very unusual and > > weird thing to do when all the involved operations are synchronous. > > For example, a tagged attribute creation looks like the following. > > Then please ask. I asked the first time around and the answer I got was basically "I didn't want to go around updating differnet layers and adding stuffing it in the ops struct is more convenient". Do you have a better reason now? > I don't have the time or energy to review these right now, and given the > sweeping nature of the patches, and the dismissive attitude of the > original design there is almost at least one stupid bug if not something > worse. > > So until I have the energy to review these. > > Nacked-by: "Eric W. Biederman" No, you don't get to have a say without actually doing the review. You sure can ask for more time to review stuff as long as it's reasonable. Why are things like this still not clear to you? You have been doing this long enough. > I am sorry but I don't have time to clean up after any more people > touching sysfs when the break something. It does look like there are so > possibly good things going on but.. If you wanna object, do it technically through proper review. That's how it works. 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/
[PATCH] ehea: remove deprecated IRQF_DISABLED
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/ibm/ehea/ehea_main.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c
b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index 35853b4..04e0ef1 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -1285,7 +1285,7 @@ static int ehea_reg_interrupts(struct net_device *dev)
ret = ibmebus_request_irq(port->qp_eq->attr.ist1,
ehea_qp_aff_irq_handler,
- IRQF_DISABLED, port->int_aff_name, port);
+ 0, port->int_aff_name, port);
if (ret) {
netdev_err(dev, "failed registering irq for
qp_aff_irq_handler:ist=%X\n",
port->qp_eq->attr.ist1);
@@ -1303,8 +1303,7 @@ static int ehea_reg_interrupts(struct net_device *dev)
"%s-queue%d", dev->name, i);
ret = ibmebus_request_irq(pr->eq->attr.ist1,
ehea_recv_irq_handler,
- IRQF_DISABLED, pr->int_send_name,
- pr);
+ 0, pr->int_send_name, pr);
if (ret) {
netdev_err(dev, "failed registering irq for ehea_queue
port_res_nr:%d, ist=%X\n",
i, pr->eq->attr.ist1);
@@ -3320,7 +3319,7 @@ static int ehea_probe_adapter(struct platform_device *dev)
}
ret = ibmebus_request_irq(adapter->neq->attr.ist1,
- ehea_interrupt_neq, IRQF_DISABLED,
+ ehea_interrupt_neq, 0,
"ehea_neq", adapter);
if (ret) {
dev_err(>dev, "requesting NEQ IRQ failed\n");
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] ext4: increase mbcache scalability
On 9/11/13 3:36 PM, Thavatchai Makphaibulchoke wrote:
> I seem to be seeing the same thing as Eric is seeing.
...
> For both filesystems, the security xattr are about 32.17 and 34.87 bytes
> respectively.
...
Can you triple-check the inode size on your fs, for good measure?
dumpe2fs -h /dev/whatever | grep "Inode size"
> I also see a similar problem with filefrag.
turns out it's not a problem, it's an undocumented & surprising "feature." :(
/* For inline data all offsets should be in bytes, not blocks */
if (fm_extent->fe_flags & FIEMAP_EXTENT_DATA_INLINE)
blk_shift = 0;
because ... ? (the commit which added it didn't mention anything about it).
But I guess it does mean for at least those files, the xattr data is actually
inline.
> At this point, I'm not sure why we get into the mbcache path when
> SELinux is enabled. As mentioned in one my earlier replies to
> Andreas, I did see actual calls into ext4_xattr_cache.
>
> There seems to be one difference between 3.11 kernel and 2.6 kernel
> in set_inode_init_security(). There is an additional attempt to
> initialize evm xattr. But I do not seem to be seeing any evm xattr in
> any file.
>
> I will continue to try to find out how we get into the mbcache path.
> Please let me know if anyone has any suggestion.
Sorry we got so far off the thread of the original patches.
But it seems like a mystery worth solving.
Perhaps in ext4_xattr_set_handle() you can instrument the case(s) where it
gets into ext4_xattr_block_set().
Or most simply, just printk inode number in ext4_xattr_block_set() so
you can look at them later via debugfs.
And in here,
} else {
error = ext4_xattr_ibody_set(handle, inode, , );
if (!error && !bs.s.not_found) {
i.value = NULL;
error = ext4_xattr_block_set(handle, inode, , );
} else if (error == -ENOSPC) {
if (EXT4_I(inode)->i_file_acl && !bs.s.base) {
error = ext4_xattr_block_find(inode, , );
if (error)
goto cleanup;
}
error = ext4_xattr_block_set(handle, inode, , );
maybe print out in the ext4_xattr_ibody_set error case what the size of
of the xattr is, and probably inode number again for good measure, to get
an idea of what's causing it to fail to land in the inode?
-Eric
>
> Thanks,
> Mak.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/16] [RFC PATCH] Signed kexec support
On Tue, Sep 10, 2013 at 05:44:15PM -0400, Vivek Goyal wrote: > Hi, > > Matthew has been posting patches to lock down kernel either due to > secureboot requirements or because of signed modules with signing > enforced. In kernel lock down mode, kexec will be disabled and that > means kdump will not work either. > > These patches sign /sbin/kexec and kernel verifies the signature > and allows loading a kernel if signature verification is successful. > IOW, trust is extended to validly signed user space. > > Currently it works only for statically linked applications. That's a really big restriction, pretty much making it not workable for distros at the moment to use. Any chance to change this in the future? Or just rely on the existing "signed binaries" functionality we have in the kernel today for the kexec binary as well? Wouldn't that be simpler? thanks, 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: [PATCH 7/7] sysfs: @name comes before @ns
Tejun Heo writes: > Some internal sysfs functions which take explicit namespace argument > are weird in that they place the optional @ns in front of @name which > is contrary to the established convention. This is confusing and > error-prone especially as @ns and @name may be interchanged without > causing compilation warning. > > Swap the positions of @name and @ns in the following internal > functions. Nacked-by: "Eric W. Biederman" @ns is more significant so it should come first. Where do we have the backwards convention of putting @name first? Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linus Git (3.11.0+) - security/apparmor/include/policy.h:363 suspicious rcu_dereference_check() usage!
[ 29.804534] [ INFO: suspicious RCU usage. ]
[ 29.804539] 3.11.0+ #5 Not tainted
[ 29.804541] ---
[ 29.804545] security/apparmor/include/policy.h:363 suspicious
rcu_dereference_check() usage!
[ 29.804548]
[ 29.804548] other info that might help us debug this:
[ 29.804548]
[ 29.804553]
[ 29.804553] rcu_scheduler_active = 1, debug_locks = 1
[ 29.804558] 2 locks held by apparmor_parser/1268:
[ 29.804560] #0: (sb_writers#9){.+.+.+}, at: []
file_start_write+0x27/0x29
[ 29.804576] #1: (>lock){+.+.+.}, at: []
aa_replace_profiles+0x166/0x57c
[ 29.804589]
[ 29.804589] stack backtrace:
[ 29.804595] CPU: 0 PID: 1268 Comm: apparmor_parser Not tainted 3.11.0+ #5
[ 29.804599] Hardware name: ASUSTeK Computer Inc. UL50VT
/UL50VT, BIOS 217 03/01/2010
[ 29.804602] 8800b95a1d90 8144eb9b
8800b94db540
[ 29.804611] 8800b95a1dc0 81087439 880138cc3a18
880138cc3a18
[ 29.804619] 8800b9464a90 880138cc3a38 8800b95a1df0
811f5084
[ 29.804628] Call Trace:
[ 29.804636] [] dump_stack+0x4e/0x82
[ 29.804642] [] lockdep_rcu_suspicious+0xfc/0x105
[ 29.804649] [] __aa_update_replacedby+0x53/0x7f
[ 29.804655] [] __replace_profile+0x11f/0x1ed
[ 29.804661] [] aa_replace_profiles+0x410/0x57c
[ 29.804668] [] profile_replace+0x35/0x4c
[ 29.804674] [] vfs_write+0xad/0x113
[ 29.804680] [] SyS_write+0x44/0x7a
[ 29.804687] [] system_call_fastpath+0x16/0x1b
[ 29.804691]
[ 29.804694] ===
[ 29.804697] [ INFO: suspicious RCU usage. ]
[ 29.804700] 3.11.0+ #5 Not tainted
[ 29.804703] ---
[ 29.804706] security/apparmor/policy.c:566 suspicious
rcu_dereference_check() usage!
[ 29.804709]
[ 29.804709] other info that might help us debug this:
[ 29.804709]
[ 29.804714]
[ 29.804714] rcu_scheduler_active = 1, debug_locks = 1
[ 29.804718] 2 locks held by apparmor_parser/1268:
[ 29.804721] #0: (sb_writers#9){.+.+.+}, at: []
file_start_write+0x27/0x29
[ 29.804733] #1: (>lock){+.+.+.}, at: []
aa_replace_profiles+0x166/0x57c
[ 29.804744]
[ 29.804744] stack backtrace:
[ 29.804750] CPU: 0 PID: 1268 Comm: apparmor_parser Not tainted 3.11.0+ #5
[ 29.804753] Hardware name: ASUSTeK Computer Inc. UL50VT
/UL50VT, BIOS 217 03/01/2010
[ 29.804756] 8800b95a1d80 8144eb9b
8800b94db540
[ 29.804764] 8800b95a1db0 81087439 8800b95b02b0
[ 29.804772] 8800b9efba08 880138cc3a38 8800b95a1dd0
811f4f94
[ 29.804779] Call Trace:
[ 29.804786] [] dump_stack+0x4e/0x82
[ 29.804791] [] lockdep_rcu_suspicious+0xfc/0x105
[ 29.804798] [] aa_free_replacedby_kref+0x4d/0x62
[ 29.804804] [] ? aa_put_namespace+0x17/0x17
[ 29.804810] [] kref_put+0x36/0x40
[ 29.804816] [] __replace_profile+0x13a/0x1ed
[ 29.804822] [] aa_replace_profiles+0x410/0x57c
[ 29.804829] [] profile_replace+0x35/0x4c
[ 29.804835] [] vfs_write+0xad/0x113
[ 29.804840] [] SyS_write+0x44/0x7a
[ 29.804847] [] system_call_fastpath+0x16/0x1b
--
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: [PATCHSET] sysfs: disentangle kobject namespace handling from sysfs
Greg KH writes: > On Wed, Sep 11, 2013 at 10:29:02PM -0400, Tejun Heo wrote: >> Hello, >> >> I'll send out multiple patchsets to separate out sysfs from driver >> core and kobject. The eventual goal is making sysfs modular enough so >> that cgroup can replace its nightmarish cgroupfs implementation which >> repeated and worsened all the past mistakes of sysfs. This patchset >> is first of the effort and separates out kobject namespace handling >> from sysfs. >> >> I never really understood why namespace support was added the way it >> was added. > > I just took the patches and didn't ask questions :) Greg you don't get to play dumb you asked questions and required most of the current strucuture of the code. The code is convoluted by your request. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] sysfs: disentangle kobject namespace handling from sysfs
Tejun Heo writes: > Hello, > > I'll send out multiple patchsets to separate out sysfs from driver > core and kobject. The eventual goal is making sysfs modular enough so > that cgroup can replace its nightmarish cgroupfs implementation which > repeated and worsened all the past mistakes of sysfs. This patchset > is first of the effort and separates out kobject namespace handling > from sysfs. At a practical level you probably just want to copy the good parts of the structure of sysfs, instead of attempting to share code. Sharing code is likely to get you into all kinds of problems with short term hacks. > I never really understood why namespace support was added the way it > was added. Namespace information is communicated to sysfs via > callbacks and back-queries to upper layer, which is a very unusual and > weird thing to do when all the involved operations are synchronous. > For example, a tagged attribute creation looks like the following. Then please ask. I don't have the time or energy to review these right now, and given the sweeping nature of the patches, and the dismissive attitude of the original design there is almost at least one stupid bug if not something worse. So until I have the energy to review these. Nacked-by: "Eric W. Biederman" I am sorry but I don't have time to clean up after any more people touching sysfs when the break something. It does look like there are so possibly good things going on but.. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] bfin_mac: remove deprecated IRQF_DISABLED
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/adi/bfin_mac.c.
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/adi/bfin_mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/adi/bfin_mac.c
b/drivers/net/ethernet/adi/bfin_mac.c
index e66684a..75fb1d2 100644
--- a/drivers/net/ethernet/adi/bfin_mac.c
+++ b/drivers/net/ethernet/adi/bfin_mac.c
@@ -530,7 +530,7 @@ static int bfin_mac_ethtool_setwol(struct net_device *dev,
if (lp->wol && !lp->irq_wake_requested) {
/* register wake irq handler */
rc = request_irq(IRQ_MAC_WAKEDET, bfin_mac_wake_interrupt,
-IRQF_DISABLED, "EMAC_WAKE", dev);
+0, "EMAC_WAKE", dev);
if (rc)
return rc;
lp->irq_wake_requested = true;
@@ -1686,7 +1686,7 @@ static int bfin_mac_probe(struct platform_device *pdev)
/* now, enable interrupts */
/* register irq handler */
rc = request_irq(IRQ_MAC_RX, bfin_mac_interrupt,
- IRQF_DISABLED, "EMAC_RX", ndev);
+ 0, "EMAC_RX", ndev);
if (rc) {
dev_err(>dev, "Cannot request Blackfin MAC RX IRQ!\n");
rc = -EBUSY;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET] sysfs: disentangle kobject namespace handling from sysfs
On Wed, Sep 11, 2013 at 08:33:44PM -0700, Greg KH wrote: > I have to wait for 3.12-rc1 to come out before applying anything, and > then we will be at LinuxCon/Plumbers drinking^Wworking all next week, so > it will be a bit before any of this could hit my tree. Heh, sounds good. See you soon in New Orleans! :) -- 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: [PATCHSET] sysfs: disentangle kobject namespace handling from sysfs
On Wed, Sep 11, 2013 at 11:23:16PM -0400, Tejun Heo wrote: > Hello, Greg. > > > Nice job with these. Do you want me to add them to my tree for 3.13, or > > do you want to take them through yours as you will be building on top of > > them? > > I think it'll be best to route them through your tree but maybe we > want to wait a bit before applying them? I have to wait for 3.12-rc1 to come out before applying anything, and then we will be at LinuxCon/Plumbers drinking^Wworking all next week, so it will be a bit before any of this could hit my tree. thanks, 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/
[PATCH] lib: vsprintf: document formats for dentry and struct file
Looks like these were added to Documentation/printk-formats.txt but not the in-file table. Signed-off-by: Olof Johansson --- lib/vsprintf.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 26559bd..061bacb 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -1218,6 +1218,8 @@ int kptr_restrict __read_mostly; *The maximum supported length is 64 bytes of the input. Consider *to use print_hex_dump() for the larger input. * - 'a' For a phys_addr_t type and its derivative types (passed by reference) + * - 'd[234]' For a dentry name (optionally 2-4 last components) + * - 'D[234]' Same as 'd' but for a struct file * * Note: The difference between 'S' and 'F' is that on ia64 and ppc64 * function pointers are really function descriptors, which contain a -- 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] Restrict kernel spawning of threads to a specified set of cpus.
On Wed, 2013-09-11 at 23:36 +0200, Frederic Weisbecker wrote: > On Wed, Sep 11, 2013 at 02:21:06PM +, Christoph Lameter wrote: > > On Wed, 11 Sep 2013, Mike Galbraith wrote: > > > > > Mind saying why? To me, creating properties of exclusive sets of CPUs > > > that the interface which manages sets and their properties is not fully > > > aware of is a dainbramaged thing to do. > > > > cpusets is being replaced by cgropus. > > You are confusing me. Cpusets is a cgroups subsystem, how can it be replaced > by it? Yeah, the only irritant I know of is the cpuset API variability. It has a backward compatibility mount option, so anything other than the user mounting makes the API selection decision for him/her. systemd mounts cpuset, i.e. OS component pokes OS API backward compatibility button, breaking OS API backward compatibility for the user, who then has to squabble with OS component over button possession if he wants his old cpuset API using toys to continue to work. -Mike -- 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: [PATCHSET] sysfs: disentangle kobject namespace handling from sysfs
Hello, Greg. > Nice job with these. Do you want me to add them to my tree for 3.13, or > do you want to take them through yours as you will be building on top of > them? I think it'll be best to route them through your tree but maybe we want to wait a bit before applying them? 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/
[f2fs-dev][PATCH V2] f2fs: optimize fs_lock for better performance
From: Yu Chao
There is a performance problem: when all sbi->fs_lock are holded, then
all the following threads may get the same next_lock value from
sbi->next_lock_num
in function mutex_lock_op, and wait for the same lock(fs_lock[next_lock]),
it may cause performance reduce.
So we move the sbi->next_lock_num++ before getting lock, this will average the
following threads if all sbi->fs_lock are holded.
v1-->v2:
Drop the needless spin_lock as Jaegeuk suggested.
Suggested-by: Jaegeuk Kim
Signed-off-by: Yu Chao
Signed-off-by: Gu Zheng
---
fs/f2fs/f2fs.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 608f0df..7fd99d8 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -544,15 +544,15 @@ static inline void mutex_unlock_all(struct f2fs_sb_info
*sbi)
static inline int mutex_lock_op(struct f2fs_sb_info *sbi)
{
- unsigned char next_lock = sbi->next_lock_num % NR_GLOBAL_LOCKS;
+ unsigned char next_lock;
int i = 0;
for (; i < NR_GLOBAL_LOCKS; i++)
if (mutex_trylock(>fs_lock[i]))
return i;
+ next_lock = sbi->next_lock_num++ % NR_GLOBAL_LOCKS;
mutex_lock(>fs_lock[next_lock]);
- sbi->next_lock_num++;
return next_lock;
}
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/7] sysfs: clean up sysfs_get_dirent()
>From 5a4b7340199b2d6ff15b6fc551b0ea3f2cc19b6e Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Wed, 11 Sep 2013 23:19:13 -0400
The pre-existing sysfs interfaces which take explicit namespace
argument are weird in that they place the optional @ns in front of
@name which is contrary to the established convention. For example,
we end up forcing vast majority of sysfs_get_dirent() users to do
sysfs_get_dirent(parent, NULL, name), which is silly and error-prone
especially as @ns and @name may be interchanged without causing
compilation warning.
This renames sysfs_get_dirent() to sysfs_get_dirent_ns() and swap the
positions of @name and @ns, and sysfs_get_dirent() is now a wrapper
around sysfs_get_dirent_ns(). This makes confusions a lot less
likely.
There are other interfaces which take @ns before @name. They'll be
updated by following patches.
This patch doesn't introduce any functional changes.
v2: EXPORT_SYMBOL_GPL() wasn't updated leading to undefined symbol
error on module builds. Reported by build test robot. Fixed.
Signed-off-by: Tejun Heo
Cc: Eric W. Biederman
Cc: Kay Sievers
Cc: Fengguang Wu
---
drivers/gpio/gpiolib.c | 2 +-
drivers/md/bitmap.c| 4 ++--
drivers/md/md.c| 2 +-
drivers/md/md.h| 2 +-
fs/sysfs/dir.c | 11 ++-
fs/sysfs/file.c| 4 ++--
fs/sysfs/group.c | 10 +-
fs/sysfs/symlink.c | 2 +-
fs/sysfs/sysfs.h | 3 ---
include/linux/sysfs.h | 19 ---
10 files changed, 31 insertions(+), 28 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 86ef346..a094356 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -408,7 +408,7 @@ static int gpio_setup_irq(struct gpio_desc *desc, struct
device *dev,
IRQF_TRIGGER_FALLING : IRQF_TRIGGER_RISING;
if (!value_sd) {
- value_sd = sysfs_get_dirent(dev->kobj.sd, NULL, "value");
+ value_sd = sysfs_get_dirent(dev->kobj.sd, "value");
if (!value_sd) {
ret = -ENODEV;
goto err_out;
diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
index a7fd821..12dc29b 100644
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -1654,9 +1654,9 @@ int bitmap_create(struct mddev *mddev)
bitmap->mddev = mddev;
if (mddev->kobj.sd)
- bm = sysfs_get_dirent(mddev->kobj.sd, NULL, "bitmap");
+ bm = sysfs_get_dirent(mddev->kobj.sd, "bitmap");
if (bm) {
- bitmap->sysfs_can_clear = sysfs_get_dirent(bm, NULL,
"can_clear");
+ bitmap->sysfs_can_clear = sysfs_get_dirent(bm, "can_clear");
sysfs_put(bm);
} else
bitmap->sysfs_can_clear = NULL;
diff --git a/drivers/md/md.c b/drivers/md/md.c
index adf4d7e..8a0d762 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -3555,7 +3555,7 @@ level_store(struct mddev *mddev, const char *buf, size_t
len)
printk(KERN_WARNING
"md: cannot register extra attributes for %s\n",
mdname(mddev));
- mddev->sysfs_action = sysfs_get_dirent(mddev->kobj.sd, NULL,
"sync_action");
+ mddev->sysfs_action = sysfs_get_dirent(mddev->kobj.sd,
"sync_action");
}
if (mddev->pers->sync_request != NULL &&
pers->sync_request == NULL) {
diff --git a/drivers/md/md.h b/drivers/md/md.h
index 608050c..b0051f2 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
@@ -501,7 +501,7 @@ extern struct attribute_group md_bitmap_group;
static inline struct sysfs_dirent *sysfs_get_dirent_safe(struct sysfs_dirent
*sd, char *name)
{
if (sd)
- return sysfs_get_dirent(sd, NULL, name);
+ return sysfs_get_dirent(sd, name);
return sd;
}
static inline void sysfs_notify_dirent_safe(struct sysfs_dirent *sd)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 1dfb4aa..fee19d1 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -630,9 +630,10 @@ struct sysfs_dirent *sysfs_find_dirent(struct sysfs_dirent
*parent_sd,
}
/**
- * sysfs_get_dirent - find and get sysfs_dirent with the given name
+ * sysfs_get_dirent_ns - find and get sysfs_dirent with the given name
* @parent_sd: sysfs_dirent to search under
* @name: name to look for
+ * @ns: the namespace tag to use
*
* Look for sysfs_dirent with name @name under @parent_sd and get
* it if found.
@@ -643,9 +644,9 @@ struct sysfs_dirent *sysfs_find_dirent(struct sysfs_dirent
*parent_sd,
* RETURNS:
* Pointer to sysfs_dirent if found, NULL if not.
*/
-struct sysfs_dirent *sysfs_get_dirent(struct sysfs_dirent *parent_sd,
- const void *ns,
- const unsigned char *name)
+struct sysfs_dirent *sysfs_get_dirent_ns(struct sysfs_dirent *parent_sd,
Re: [RFC PATCH] timekeeping: introduce timekeeping_is_busy()
* Peter Zijlstra (pet...@infradead.org) wrote:
> On Wed, Sep 11, 2013 at 08:48:11PM -0400, Mathieu Desnoyers wrote:
> > Thoughts ?
>
>
> struct foo {
> ...
> };
>
> spinlock_t foo_lock;
> unsigned int foo_head = 0;
> unsigned int foo_tail = 0;
> struct foo foo_array[2];
>
> void foo_assign(struct foo f)
> {
> spin_lock(_lock);
> foo_head++;
> smp_wmb();
> foo_array[foo_head & 1] = f;
> smp_wmb();
> foo_tail++;
> spin_unlock(_lock);
> }
>
> struct foo foo_get(void)
> {
> unsigned int tail, head;
> struct foo ret;
>
> again:
> tail = ACCESS_ONCE(foo_tail);
> smp_rmb();
> ret = foo_array[tail & 1];
> smp_rmb();
> head = ACCESS_ONCE(foo_head);
> if (head - tail >= 2)
> goto again;
>
> return ret;
> }
>
> Should work and get you the most recent 'complete' foo even when
> foo_get() is called nested inside foo_assign().
Cool!
Your design looks good to me. It reminds me of a latch. My only fear is
that struct timekeeper is probably too large to be copied every time on
the read path. Here is a slightly reworked version that would allow
in-place read of "foo" without copy.
struct foo {
...
};
struct latchfoo {
unsigned int head, tail;
spinlock_t write_lock;
struct foo data[2];
};
static
void foo_update(struct latchfoo *lf, void cb(struct foo *foo), void *ctx)
{
spin_lock(>write_lock);
lf->head++;
smp_wmb();
lf->data[lf->head & 1] = lf->data[lf->tail & 1];
cb(>data[lf->head & 1], ctx);
smp_wmb();
lf->tail++;
spin_unlock(>write_lock);
}
static
unsigned int foo_read_begin(struct latchfoo *lf)
{
unsigned int ret;
ret = ACCESS_ONCE(lf->tail);
smp_rmb();
return ret;
}
static
struct foo *foo_read_get(struct latchfoo *lf, unsigned int tail)
{
return >data[tail & 1];
}
static
int foo_read_retry(struct latchfoo *lf, unsigned int tail)
{
smp_rmb();
return (ACCESS_ONCE(lf->head) - tail >= 2);
}
Comments are welcome,
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: [f2fs-dev][PATCH] f2fs: optimize fs_lock for better performance
Hi Chao,
On 09/12/2013 10:40 AM, 俞超 wrote:
> Hi Gu
>
>> -Original Message-
>> From: Gu Zheng [mailto:guz.f...@cn.fujitsu.com]
>> Sent: Wednesday, September 11, 2013 1:38 PM
>> To: jaegeuk@samsung.com
>> Cc: chao2...@samsung.com; shu@samsung.com;
>> linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> linux-f2fs-de...@lists.sourceforge.net
>> Subject: Re: [f2fs-dev][PATCH] f2fs: optimize fs_lock for better performance
>>
>> Hi Jaegeuk, Chao,
>>
>> On 09/10/2013 08:52 AM, Jaegeuk Kim wrote:
>>
>>> Hi,
>>>
>>> At first, thank you for the report and please follow the email writing
>>> rules. :)
>>>
>>> Anyway, I agree to the below issue.
>>> One thing that I can think of is that we don't need to use the
>>> spin_lock, since we don't care about the exact lock number, but just
>>> need to get any not-collided number.
>>
>> IMHO, just moving sbi->next_lock_num++ before
>> mutex_lock(>fs_lock[next_lock])
>> can avoid unbalance issue mostly.
>> IMO, the case two or more threads increase sbi->next_lock_num in the same
>> time is really very very little. If you think it is not rigorous, change
>> next_lock_num to atomic one can fix it.
>> What's your opinion?
>>
>> Regards,
>> Gu
>
> I did the test sbi->next_lock_num++ compare with the atomic one,
> And I found performance of them is almost the same under a small number
> thread racing.
> So as your and Kim's opinion, it's enough to use "sbi->next_lock_num++" to
> fix this issue.
Good, but it seems that your replay patch is out of format, and it's hard for
Jaegeuk to merge.
I'll format it, see the following thread.
Thanks,
Gu
>
> Thanks for the advice.
>>
>>>
>>> So, how about removing the spin_lock?
>>> And how about using a random number?
>>
>>> Thanks,
>>>
>>> 2013-09-06 (금), 09:48 +, Chao Yu:
Hi Kim:
I think there is a performance problem: when all sbi->fs_lock is
holded,
then all other threads may get the same next_lock value from
sbi->next_lock_num in function mutex_lock_op,
and wait to get the same lock at position fs_lock[next_lock], it
unbalance the fs_lock usage.
It may lost performance when we do the multithread test.
Here is the patch to fix this problem:
Signed-off-by: Yu Chao
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
old mode 100644
new mode 100755
index 467d42d..983bb45
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -371,6 +371,7 @@ struct f2fs_sb_info {
struct mutex fs_lock[NR_GLOBAL_LOCKS]; /* blocking FS
operations */
struct mutex node_write;/* locking node
>> writes
*/
struct mutex writepages;/* mutex for
writepages() */
+ spinlock_t spin_lock; /* lock for
next_lock_num */
unsigned char next_lock_num;/* round-robin
>> global
locks */
int por_doing; /* recovery is doing
or not */
int on_build_free_nids; /* build_free_nids is
doing */
@@ -533,15 +534,19 @@ static inline void mutex_unlock_all(struct
f2fs_sb_info *sbi)
static inline int mutex_lock_op(struct f2fs_sb_info *sbi)
{
- unsigned char next_lock = sbi->next_lock_num %
NR_GLOBAL_LOCKS;
+ unsigned char next_lock;
int i = 0;
for (; i < NR_GLOBAL_LOCKS; i++)
if (mutex_trylock(>fs_lock[i]))
return i;
- mutex_lock(>fs_lock[next_lock]);
+ spin_lock(>spin_lock);
+ next_lock = sbi->next_lock_num % NR_GLOBAL_LOCKS;
sbi->next_lock_num++;
+ spin_unlock(>spin_lock);
+
+ mutex_lock(>fs_lock[next_lock]);
return next_lock;
}
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
old mode 100644
new mode 100755
index 75c7dc3..4f27596
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -657,6 +657,7 @@ static int f2fs_fill_super(struct super_block
*sb, void *data, int silent)
mutex_init(>cp_mutex);
for (i = 0; i < NR_GLOBAL_LOCKS; i++)
mutex_init(>fs_lock[i]);
+ spin_lock_init(>spin_lock);
mutex_init(>node_write);
sbi->por_doing = 0;
spin_lock_init(>stat_lock);
(END)
>>>
>>
>>
>> =
>
>
--
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
Re: [PATCHSET] sysfs: disentangle kobject namespace handling from sysfs
On Wed, Sep 11, 2013 at 10:29:02PM -0400, Tejun Heo wrote:
> Hello,
>
> I'll send out multiple patchsets to separate out sysfs from driver
> core and kobject. The eventual goal is making sysfs modular enough so
> that cgroup can replace its nightmarish cgroupfs implementation which
> repeated and worsened all the past mistakes of sysfs. This patchset
> is first of the effort and separates out kobject namespace handling
> from sysfs.
>
> I never really understood why namespace support was added the way it
> was added.
I just took the patches and didn't ask questions :)
> Namespace information is communicated to sysfs via
> callbacks and back-queries to upper layer, which is a very unusual and
> weird thing to do when all the involved operations are synchronous.
> For example, a tagged attribute creation looks like the following.
>
> driver codedriver callback
> v ^
> netdev_class_create_file() |
> v class_attr->namespace()
> class_create_file()class_attr_namespace()
> v |
> sysfs_create_file()|
> v |
> sysfs_attr_ns() -> sysfs_ops->namespace()
>
> This is an absurd thing to do. It significantly obfuscates what's
> going on and adds unnecessary uncertainties - for example, can
> namespace() return value disagree with the recorded s_ns value without
> being renamed? If so, how should that be handled? If not, what
> guarantees that? Even the basic placements of callbacks don't make
> much, if any, sense. Why is per-directory namespace() callback in
> kobj_type while per-attr namespace() callback is in sysfs_ops? What
> does this even mean?
>
> Maybe there's some grand design scheme governing all this but it isn't
> obvious at all and the whole thing looks like a hodgepodge of
> short-sighted hacks.
>
> There is absolutely *nothing* which requires this convolution. NS tag
> can simply be passed down the stack just like any other type of
> information and adding an extra argument or variant of interface to
> pass down the extra information is way more straight-forward and
> apparently even takes less amount of code, so let's please stop the
> insanity.
>
> This patchset contains the following seven patches.
>
> 0001-sysfs-drop-semicolon-from-to_sysfs_dirent-definition.patch
> 0002-sysfs-make-attr-namespace-interface-less-convoluted.patch
> 0003-sysfs-remove-ktype-namespace-invocations-in-director.patch
> 0004-sysfs-remove-ktype-namespace-invocations-in-symlink-.patch
> 0005-sysfs-drop-kobj_ns_type-handling.patch
> 0006-sysfs-clean-up-sysfs_get_dirent.patch
> 0007-sysfs-name-comes-before-ns.patch
>
> 0001 is a minor prep patch.
>
> 0002 removes the attr namespace callback.
>
> 0003-0004 push the dir namespace callback invocations from sysfs to
> kobjct layer. Eventually, this callback should go too.
>
> 0005 simplifies sysfs ns support such that sysfs doesn't have any
> specific knowledge of kobj namespaces. It now purely deals with
> pointer tags. Combined with the previous changes, this makes sysfs ns
> support mostly modular.
>
> 0006-0007 are cleanup patches to make param orders conventional and
> consistent - optional param after mandatory one; otherwise, things get
> extremely confusing with different variants of interfaces which take
> or don't take optional params. No idea how/why this was done the
> wrong way.
>
> This patchset is based on top of the current master
> c2d95729e3094ecdd8c54e856bbe971adbbd7f48 ("Merge branch 'akpm'
> (patches from Andrew Morton)") and available in the following git
> branch.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git
> review-sysfs-separate-out-ns
Nice job with these. Do you want me to add them to my tree for 3.13, or
do you want to take them through yours as you will be building on top of
them?
If yours, feel free to add:
Acked-by: Greg Kroah-Hartman
To all of these.
And thanks for cleaning this up, it looks much better now.
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/
[RFC PATCH 1/1] module: Make wait module's refcount to zero procedure as async
Currently, if module's refcount is not zero during the unload,
it waits there until the user decreases that refcount. Assume
we have two modules (A & B), there are no symbol relationship
between each other. module B is module A's user, if the end
user tries to unload module A first wrongly, it will stop there
until there is another user process to unload B, and this
process can't be killed.
One use case is: the QA engineers do error test, they unload
module wrongly on purpose, after that, they find the console
is stopped there, and they can't do any thing go on.
Signed-off-by: Peter Chen
---
include/linux/module.h |4 +-
kernel/module.c| 61 ++-
2 files changed, 36 insertions(+), 29 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 05f2447..12edf07 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -367,8 +367,8 @@ struct module
/* What modules do I depend on? */
struct list_head target_list;
- /* Who is waiting for us to be unloaded */
- struct task_struct *waiter;
+ /* The work for waiting refcount to zero */
+ struct work_struct wait_refcount_work;
/* Destruction function. */
void (*exit)(void);
diff --git a/kernel/module.c b/kernel/module.c
index dc58274..94abc7e 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -61,6 +61,7 @@
#include
#include
#include
+#include
#include
#include "module-internal.h"
@@ -644,8 +645,6 @@ static int module_unload_init(struct module *mod)
/* Hold reference count during initialization. */
__this_cpu_write(mod->refptr->incs, 1);
- /* Backwards compatibility macros put refcount during init. */
- mod->waiter = current;
return 0;
}
@@ -813,19 +812,38 @@ EXPORT_SYMBOL(module_refcount);
/* This exists whether we can unload or not */
static void free_module(struct module *mod);
+/* Final destruction now no one is using it. */
+static void module_final_free(struct module *mod)
+{
+ if (mod->exit != NULL)
+ mod->exit();
+ blocking_notifier_call_chain(_notify_list,
+MODULE_STATE_GOING, mod);
+ async_synchronize_full();
+
+ /* Store the name of the last unloaded module for diagnostic purposes */
+ strlcpy(last_unloaded_module, mod->name, sizeof(last_unloaded_module));
+
+ free_module(mod);
+}
+
static void wait_for_zero_refcount(struct module *mod)
{
- /* Since we might sleep for some time, release the mutex first */
- mutex_unlock(_mutex);
for (;;) {
pr_debug("Looking at refcount...\n");
- set_current_state(TASK_UNINTERRUPTIBLE);
if (module_refcount(mod) == 0)
break;
- schedule();
+ msleep(1000);
}
- current->state = TASK_RUNNING;
- mutex_lock(_mutex);
+ module_final_free(mod);
+}
+
+static void wait_module_refcount(struct work_struct *work)
+{
+ struct module *mod = container_of(work,
+ struct module, wait_refcount_work);
+
+ wait_for_zero_refcount(mod);
}
SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
@@ -859,8 +877,7 @@ SYSCALL_DEFINE2(delete_module, const char __user *,
name_user,
/* Doing init or already dying? */
if (mod->state != MODULE_STATE_LIVE) {
- /* FIXME: if (force), slam module count and wake up
- waiter --RR */
+ /* FIXME: if (force), slam module count */
pr_debug("%s already dying\n", mod->name);
ret = -EBUSY;
goto out;
@@ -876,30 +893,23 @@ SYSCALL_DEFINE2(delete_module, const char __user *,
name_user,
}
}
- /* Set this up before setting mod->state */
- mod->waiter = current;
-
/* Stop the machine so refcounts can't move and disable module. */
ret = try_stop_module(mod, flags, );
if (ret != 0)
goto out;
/* Never wait if forced. */
- if (!forced && module_refcount(mod) != 0)
- wait_for_zero_refcount(mod);
+ if (!forced && module_refcount(mod) != 0) {
+ INIT_WORK(>wait_refcount_work, wait_module_refcount);
+ schedule_work(>wait_refcount_work);
+ ret = -EBUSY;
+ goto out;
+ }
mutex_unlock(_mutex);
- /* Final destruction now no one is using it. */
- if (mod->exit != NULL)
- mod->exit();
- blocking_notifier_call_chain(_notify_list,
-MODULE_STATE_GOING, mod);
- async_synchronize_full();
- /* Store the name of the last unloaded module for diagnostic purposes */
- strlcpy(last_unloaded_module, mod->name, sizeof(last_unloaded_module));
+ module_final_free(mod);
- free_module(mod);
Re: [PATCH v4:No Change] xHCI:Fixing xhci_readl definition and function call
On Thursday 12 September 2013 04:44 AM, Sarah Sharp wrote: Hi Kumar, I was waiting until after the 3.12 merge window to queue this patch, but Xenia noticed that the xhci_readl functions can completely go away and be replaced by standard readl/writel operations. She's posted a patchset to do that: http://marc.info/?l=linux-usb=137874983529708=2 I hate to do this to you, but her patch is a better improvement, so I'll be taking that series instead of your patch. I hope you can still find other clean up work to do in the xHCI driver and USB core. :) Sarah Sharp Sure sarah, Thanks On Wed, Sep 04, 2013 at 11:42:33AM +0530, Kumar Gaurav wrote: On Tuesday 03 September 2013 09:34 PM, Sarah Sharp wrote: I'm confused. I said the last version of this patch didn't apply against usb-next, and you should rebase it. Why did you put "No Change" in the subject prefix? I miss understood what Dan said. he said me to add no change if there's no change from previous patch, but he didn't meant in subject (my bad). On Sat, Aug 31, 2013 at 11:02:45PM +0530, Kumar Gaurav wrote: This patch redefine function xhci_readl. xhci_readl function doesn't use xhci_hcd argument. Hence there is no need of keeping it in the function arguments. Redefining this function breaks other functions which calls this function. This phatch also correct those calls in xhci driver. Signed-off-by: Kumar Gaurav --- You didn't describe why you're resending this, or what changed. If you did rebase this against usb-next, you should have left the subject prefix as "PATCH v4" and said here: v4: - rebased against usb-next You can do this by generating the patch with `git format-patch`, edit the patch manually (in whatever directory it was created it), and then send it by passing the file to `git send-email`. Sarah Sharp I rebased it against linux-next and i'll send the same patch as you discribed but please do let me know if i need to mark that as "patch v5" as this patch won't have any change in changelog drivers/usb/host/xhci-dbg.c | 36 - drivers/usb/host/xhci-hub.c | 72 - drivers/usb/host/xhci-mem.c | 20 - drivers/usb/host/xhci-ring.c | 12 +++--- drivers/usb/host/xhci.c | 92 +- drivers/usb/host/xhci.h |3 +- 6 files changed, 117 insertions(+), 118 deletions(-) diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c index 73503a8..229e312 100644 --- a/drivers/usb/host/xhci-dbg.c +++ b/drivers/usb/host/xhci-dbg.c @@ -32,7 +32,7 @@ void xhci_dbg_regs(struct xhci_hcd *xhci) xhci_dbg(xhci, "// xHCI capability registers at %p:\n", xhci->cap_regs); - temp = xhci_readl(xhci, >cap_regs->hc_capbase); + temp = xhci_readl(>cap_regs->hc_capbase); xhci_dbg(xhci, "// @%p = 0x%x (CAPLENGTH AND HCIVERSION)\n", >cap_regs->hc_capbase, temp); xhci_dbg(xhci, "// CAPLENGTH: 0x%x\n", @@ -44,13 +44,13 @@ void xhci_dbg_regs(struct xhci_hcd *xhci) xhci_dbg(xhci, "// xHCI operational registers at %p:\n", xhci->op_regs); - temp = xhci_readl(xhci, >cap_regs->run_regs_off); + temp = xhci_readl(>cap_regs->run_regs_off); xhci_dbg(xhci, "// @%p = 0x%x RTSOFF\n", >cap_regs->run_regs_off, (unsigned int) temp & RTSOFF_MASK); xhci_dbg(xhci, "// xHCI runtime registers at %p:\n", xhci->run_regs); - temp = xhci_readl(xhci, >cap_regs->db_off); + temp = xhci_readl(>cap_regs->db_off); xhci_dbg(xhci, "// @%p = 0x%x DBOFF\n", >cap_regs->db_off, temp); xhci_dbg(xhci, "// Doorbell array at %p:\n", xhci->dba); } @@ -61,7 +61,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci) xhci_dbg(xhci, "xHCI capability registers at %p:\n", xhci->cap_regs); - temp = xhci_readl(xhci, >cap_regs->hc_capbase); + temp = xhci_readl(>cap_regs->hc_capbase); xhci_dbg(xhci, "CAPLENGTH AND HCIVERSION 0x%x:\n", (unsigned int) temp); xhci_dbg(xhci, "CAPLENGTH: 0x%x\n", @@ -69,7 +69,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci) xhci_dbg(xhci, "HCIVERSION: 0x%x\n", (unsigned int) HC_VERSION(temp)); - temp = xhci_readl(xhci, >cap_regs->hcs_params1); + temp = xhci_readl(>cap_regs->hcs_params1); xhci_dbg(xhci, "HCSPARAMS 1: 0x%x\n", (unsigned int) temp); xhci_dbg(xhci, " Max device slots: %u\n", @@ -79,7 +79,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci) xhci_dbg(xhci, " Max ports: %u\n", (unsigned int) HCS_MAX_PORTS(temp)); - temp = xhci_readl(xhci, >cap_regs->hcs_params2); + temp = xhci_readl(>cap_regs->hcs_params2); xhci_dbg(xhci, "HCSPARAMS 2: 0x%x\n", (unsigned int) temp); xhci_dbg(xhci, " Isoc
Re: [PATCH 0/7] preempt_count rework -v2
On Wed, Sep 11, 2013 at 7:20 PM, Peter Zijlstra wrote: > > I split the thing up into two macros GEN_UNARY_RMWcc and > GEN_BINARY_RMWcc which ends up being more readable as well as smaller > code overall. Yes, that looks like the right abstraction level. Powerful without being complicated. > I also attempted to convert asm/bitops.h, although I'm not sure it'll > compile right with older GCCs due to the comment near BITOP_ADDR() Actually, since you now have that memory clobber, it no longer matters, and "m" is the right thing. That said, the very same memory clobber may be what makes this whole approach a loss, if it causes gcc to do tons of reloads or other random things. That memory clobber wasn't an issue for the whole __preempt_count_dec_and_test() thing, because there we needed to keep anything before the decrement contained anyway. For other cases? Who knows.. A lot of the "change and test atomically" things have the same containment need, so it might not be a problem. > I might have to add the clobber to the macro arguments so we can do > version without "memory" clobber, although bitops is inconsistent with > that as well, __test_and_clear_bit() doesn't have a memory clobber but > __test_and_change_bit() does. You do need the memory clobber. The "asm goto" version can not have outputs, so "=m" and "+m" are both no-go, and so the only thing left is that memory clobber, as far as I can see.. The bitops didn't use to need it, because they had that "+/=m" that already tells gcc that the target is changed. 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: [f2fs-dev][PATCH] f2fs: optimize fs_lock for better performance
Hi Gu
> -Original Message-
> From: Gu Zheng [mailto:guz.f...@cn.fujitsu.com]
> Sent: Wednesday, September 11, 2013 1:38 PM
> To: jaegeuk@samsung.com
> Cc: chao2...@samsung.com; shu@samsung.com;
> linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev][PATCH] f2fs: optimize fs_lock for better performance
>
> Hi Jaegeuk, Chao,
>
> On 09/10/2013 08:52 AM, Jaegeuk Kim wrote:
>
> > Hi,
> >
> > At first, thank you for the report and please follow the email writing
> > rules. :)
> >
> > Anyway, I agree to the below issue.
> > One thing that I can think of is that we don't need to use the
> > spin_lock, since we don't care about the exact lock number, but just
> > need to get any not-collided number.
>
> IMHO, just moving sbi->next_lock_num++ before
> mutex_lock(>fs_lock[next_lock])
> can avoid unbalance issue mostly.
> IMO, the case two or more threads increase sbi->next_lock_num in the same
> time is really very very little. If you think it is not rigorous, change
> next_lock_num to atomic one can fix it.
> What's your opinion?
>
> Regards,
> Gu
I did the test sbi->next_lock_num++ compare with the atomic one,
And I found performance of them is almost the same under a small number thread
racing.
So as your and Kim's opinion, it's enough to use "sbi->next_lock_num++" to fix
this issue.
Thanks for the advice.
>
> >
> > So, how about removing the spin_lock?
> > And how about using a random number?
>
> > Thanks,
> >
> > 2013-09-06 (금), 09:48 +, Chao Yu:
> >> Hi Kim:
> >>
> >> I think there is a performance problem: when all sbi->fs_lock is
> >> holded,
> >>
> >> then all other threads may get the same next_lock value from
> >> sbi->next_lock_num in function mutex_lock_op,
> >>
> >> and wait to get the same lock at position fs_lock[next_lock], it
> >> unbalance the fs_lock usage.
> >>
> >> It may lost performance when we do the multithread test.
> >>
> >>
> >>
> >> Here is the patch to fix this problem:
> >>
> >>
> >>
> >> Signed-off-by: Yu Chao
> >>
> >> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >>
> >> old mode 100644
> >>
> >> new mode 100755
> >>
> >> index 467d42d..983bb45
> >>
> >> --- a/fs/f2fs/f2fs.h
> >>
> >> +++ b/fs/f2fs/f2fs.h
> >>
> >> @@ -371,6 +371,7 @@ struct f2fs_sb_info {
> >>
> >> struct mutex fs_lock[NR_GLOBAL_LOCKS]; /* blocking FS
> >> operations */
> >>
> >> struct mutex node_write;/* locking node
> writes
> >> */
> >>
> >> struct mutex writepages;/* mutex for
> >> writepages() */
> >>
> >> + spinlock_t spin_lock; /* lock for
> >> next_lock_num */
> >>
> >> unsigned char next_lock_num;/* round-robin
> global
> >> locks */
> >>
> >> int por_doing; /* recovery is doing
> >> or not */
> >>
> >> int on_build_free_nids; /* build_free_nids is
> >> doing */
> >>
> >> @@ -533,15 +534,19 @@ static inline void mutex_unlock_all(struct
> >> f2fs_sb_info *sbi)
> >>
> >>
> >>
> >> static inline int mutex_lock_op(struct f2fs_sb_info *sbi)
> >>
> >> {
> >>
> >> - unsigned char next_lock = sbi->next_lock_num %
> >> NR_GLOBAL_LOCKS;
> >>
> >> + unsigned char next_lock;
> >>
> >> int i = 0;
> >>
> >>
> >>
> >> for (; i < NR_GLOBAL_LOCKS; i++)
> >>
> >> if (mutex_trylock(>fs_lock[i]))
> >>
> >> return i;
> >>
> >>
> >>
> >> - mutex_lock(>fs_lock[next_lock]);
> >>
> >> + spin_lock(>spin_lock);
> >>
> >> + next_lock = sbi->next_lock_num % NR_GLOBAL_LOCKS;
> >>
> >> sbi->next_lock_num++;
> >>
> >> + spin_unlock(>spin_lock);
> >>
> >> +
> >>
> >> + mutex_lock(>fs_lock[next_lock]);
> >>
> >> return next_lock;
> >>
> >> }
> >>
> >>
> >>
> >> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> >>
> >> old mode 100644
> >>
> >> new mode 100755
> >>
> >> index 75c7dc3..4f27596
> >>
> >> --- a/fs/f2fs/super.c
> >>
> >> +++ b/fs/f2fs/super.c
> >>
> >> @@ -657,6 +657,7 @@ static int f2fs_fill_super(struct super_block
> >> *sb, void *data, int silent)
> >>
> >> mutex_init(>cp_mutex);
> >>
> >> for (i = 0; i < NR_GLOBAL_LOCKS; i++)
> >>
> >> mutex_init(>fs_lock[i]);
> >>
> >> + spin_lock_init(>spin_lock);
> >>
> >> mutex_init(>node_write);
> >>
> >> sbi->por_doing = 0;
> >>
> >> spin_lock_init(>stat_lock);
> >>
> >> (END)
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
>
> =
--
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 0/2] ext4: increase mbcache scalability
On 09/11/2013 09:25 PM, Theodore Ts'o wrote:
> On Wed, Sep 11, 2013 at 03:48:57PM -0500, Eric Sandeen wrote:
>>
>> So at this point I think it's up to Mak to figure out why on his system,
>> aim7 is triggering mbcache codepaths.
>>
>
> Yes, the next thing is to see if on his systems, whether or not he's
> seeing external xattr blocks.
>
> - Ted
>
I seem to be seeing the same thing as Eric is seeing.
On one of my systems,
# find / -mount -exec getfattr --only-values -m security.* {} 2>/dev/null \; |
wc -c
2725655
# df -i /
FilesystemInodes IUsed IFree IUse% Mounted on
/dev/mapper/vg_dhg1-lv_root
[tmac@lxbuild linux]$ man find
1974272 84737 18895355% /
# find /home -mount -exec getfattr --only-values -m security.* {} 2>/dev/null
\; | wc -c
274173
# df -i /home
FilesystemInodes IUsed IFree IUse% Mounted on
/dev/mapper/vg_dhg1-lv_home
1923847862 1845225% /home
For both filesystems, the security xattr are about 32.17 and 34.87 bytes
respectively.
I also see a similar problem with filefrag.
# filefrag -xv /bin/sh
Filesystem type is: ef53
File size of /bin/sh is 938736 (230 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 23622459548 100 not_aligned,inline
/bin/sh: 1 extent found
# getfattr -m - -d /bin/sh
getfattr: Removing leading '/' from absolute path names
# file: bin/sh
security.selinux="system_u:object_r:shell_exec_t:s0"
debugfs: stat /bin/sh
Inode: 1441795 Type: symlinkMode: 0777 Flags: 0x0
Generation: 3470616846Version: 0x:0001
User: 0 Group: 0 Size: 4
File ACL: 0Directory ACL: 0
Links: 1 Blockcount: 0
Fragment: Address: 0Number: 0Size: 0
ctime: 0x50c2779d:ad792a58 -- Fri Dec 7 16:11:25 2012
atime: 0x52311211:006d1658 -- Wed Sep 11 19:00:01 2013
mtime: 0x50c2779d:ad792a58 -- Fri Dec 7 16:11:25 2012
crtime: 0x50c2779d:ad792a58 -- Fri Dec 7 16:11:25 2012
Size of extra inode fields: 28
Extended attributes stored in inode body:
selinux = "system_u:object_r:bin_t:s0\000" (27)
Fast_link_dest: bash
At this point, I'm not sure why we get into the mbcache path when SELinux is
enabled. As mentioned in one my earlier replies to Andreas, I did see actual
calls into ext4_xattr_cache.
There seems to be one difference between 3.11 kernel and 2.6 kernel in
set_inode_init_security(). There is an additional attempt to initialize evm
xattr. But I do not seem to be seeing any evm xattr in any file.
I will continue to try to find out how we get into the mbcache path. Please
let me know if anyone has any suggestion.
Thanks,
Mak.
--
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/
[PATCHSET] sysfs: disentangle kobject namespace handling from sysfs
Hello,
I'll send out multiple patchsets to separate out sysfs from driver
core and kobject. The eventual goal is making sysfs modular enough so
that cgroup can replace its nightmarish cgroupfs implementation which
repeated and worsened all the past mistakes of sysfs. This patchset
is first of the effort and separates out kobject namespace handling
from sysfs.
I never really understood why namespace support was added the way it
was added. Namespace information is communicated to sysfs via
callbacks and back-queries to upper layer, which is a very unusual and
weird thing to do when all the involved operations are synchronous.
For example, a tagged attribute creation looks like the following.
driver codedriver callback
v ^
netdev_class_create_file() |
v class_attr->namespace()
class_create_file()class_attr_namespace()
v |
sysfs_create_file() |
v |
sysfs_attr_ns() -> sysfs_ops->namespace()
This is an absurd thing to do. It significantly obfuscates what's
going on and adds unnecessary uncertainties - for example, can
namespace() return value disagree with the recorded s_ns value without
being renamed? If so, how should that be handled? If not, what
guarantees that? Even the basic placements of callbacks don't make
much, if any, sense. Why is per-directory namespace() callback in
kobj_type while per-attr namespace() callback is in sysfs_ops? What
does this even mean?
Maybe there's some grand design scheme governing all this but it isn't
obvious at all and the whole thing looks like a hodgepodge of
short-sighted hacks.
There is absolutely *nothing* which requires this convolution. NS tag
can simply be passed down the stack just like any other type of
information and adding an extra argument or variant of interface to
pass down the extra information is way more straight-forward and
apparently even takes less amount of code, so let's please stop the
insanity.
This patchset contains the following seven patches.
0001-sysfs-drop-semicolon-from-to_sysfs_dirent-definition.patch
0002-sysfs-make-attr-namespace-interface-less-convoluted.patch
0003-sysfs-remove-ktype-namespace-invocations-in-director.patch
0004-sysfs-remove-ktype-namespace-invocations-in-symlink-.patch
0005-sysfs-drop-kobj_ns_type-handling.patch
0006-sysfs-clean-up-sysfs_get_dirent.patch
0007-sysfs-name-comes-before-ns.patch
0001 is a minor prep patch.
0002 removes the attr namespace callback.
0003-0004 push the dir namespace callback invocations from sysfs to
kobjct layer. Eventually, this callback should go too.
0005 simplifies sysfs ns support such that sysfs doesn't have any
specific knowledge of kobj namespaces. It now purely deals with
pointer tags. Combined with the previous changes, this makes sysfs ns
support mostly modular.
0006-0007 are cleanup patches to make param orders conventional and
consistent - optional param after mandatory one; otherwise, things get
extremely confusing with different variants of interfaces which take
or don't take optional params. No idea how/why this was done the
wrong way.
This patchset is based on top of the current master
c2d95729e3094ecdd8c54e856bbe971adbbd7f48 ("Merge branch 'akpm'
(patches from Andrew Morton)") and available in the following git
branch.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git
review-sysfs-separate-out-ns
The series was lightly tested with normal and basic namespace
operations. diffstat follows.
drivers/base/class.c | 29 ++
drivers/base/core.c |8 +
drivers/gpio/gpiolib.c |2
drivers/md/bitmap.c |4
drivers/md/md.c |2
drivers/md/md.h |2
drivers/net/bonding/bond_sysfs.c | 14 ---
fs/sysfs/bin.c |2
fs/sysfs/dir.c | 163 ++-
fs/sysfs/file.c | 105 ++---
fs/sysfs/group.c | 29 +++---
fs/sysfs/inode.c |6 -
fs/sysfs/mount.c | 24 +
fs/sysfs/symlink.c | 49 +++
fs/sysfs/sysfs.h | 43 +++---
include/linux/device.h | 24 -
include/linux/kobject.h |1
include/linux/netdevice.h| 16 +++
include/linux/sysfs.h| 88 ++---
lib/kobject.c| 31 ++-
net/core/net-sysfs.c | 14 +--
21 files changed, 294 insertions(+), 362 deletions(-)
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
[PATCH 6/7] sysfs: clean up sysfs_get_dirent()
The pre-existing sysfs interfaces which take explicit namespace
argument are weird in that they place the optional @ns in front of
@name which is contrary to the established convention. For example,
we end up forcing vast majority of sysfs_get_dirent() users to do
sysfs_get_dirent(parent, NULL, name), which is silly and error-prone
especially as @ns and @name may be interchanged without causing
compilation warning.
This renames sysfs_get_dirent() to sysfs_get_dirent_ns() and swap the
positions of @name and @ns, and sysfs_get_dirent() is now a wrapper
around sysfs_get_dirent_ns(). This makes confusions a lot less
likely.
There are other interfaces which take @ns before @name. They'll be
updated by following patches.
This patch doesn't introduce any functional changes.
Signed-off-by: Tejun Heo
Cc: Eric W. Biederman
Cc: Kay Sievers
---
drivers/gpio/gpiolib.c | 2 +-
drivers/md/bitmap.c| 4 ++--
drivers/md/md.c| 2 +-
drivers/md/md.h| 2 +-
fs/sysfs/dir.c | 9 +
fs/sysfs/file.c| 4 ++--
fs/sysfs/group.c | 10 +-
fs/sysfs/symlink.c | 2 +-
fs/sysfs/sysfs.h | 3 ---
include/linux/sysfs.h | 19 ---
10 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 86ef346..a094356 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -408,7 +408,7 @@ static int gpio_setup_irq(struct gpio_desc *desc, struct
device *dev,
IRQF_TRIGGER_FALLING : IRQF_TRIGGER_RISING;
if (!value_sd) {
- value_sd = sysfs_get_dirent(dev->kobj.sd, NULL, "value");
+ value_sd = sysfs_get_dirent(dev->kobj.sd, "value");
if (!value_sd) {
ret = -ENODEV;
goto err_out;
diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
index a7fd821..12dc29b 100644
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -1654,9 +1654,9 @@ int bitmap_create(struct mddev *mddev)
bitmap->mddev = mddev;
if (mddev->kobj.sd)
- bm = sysfs_get_dirent(mddev->kobj.sd, NULL, "bitmap");
+ bm = sysfs_get_dirent(mddev->kobj.sd, "bitmap");
if (bm) {
- bitmap->sysfs_can_clear = sysfs_get_dirent(bm, NULL,
"can_clear");
+ bitmap->sysfs_can_clear = sysfs_get_dirent(bm, "can_clear");
sysfs_put(bm);
} else
bitmap->sysfs_can_clear = NULL;
diff --git a/drivers/md/md.c b/drivers/md/md.c
index adf4d7e..8a0d762 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -3555,7 +3555,7 @@ level_store(struct mddev *mddev, const char *buf, size_t
len)
printk(KERN_WARNING
"md: cannot register extra attributes for %s\n",
mdname(mddev));
- mddev->sysfs_action = sysfs_get_dirent(mddev->kobj.sd, NULL,
"sync_action");
+ mddev->sysfs_action = sysfs_get_dirent(mddev->kobj.sd,
"sync_action");
}
if (mddev->pers->sync_request != NULL &&
pers->sync_request == NULL) {
diff --git a/drivers/md/md.h b/drivers/md/md.h
index 608050c..b0051f2 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
@@ -501,7 +501,7 @@ extern struct attribute_group md_bitmap_group;
static inline struct sysfs_dirent *sysfs_get_dirent_safe(struct sysfs_dirent
*sd, char *name)
{
if (sd)
- return sysfs_get_dirent(sd, NULL, name);
+ return sysfs_get_dirent(sd, name);
return sd;
}
static inline void sysfs_notify_dirent_safe(struct sysfs_dirent *sd)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 1dfb4aa..3dacce0 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -630,9 +630,10 @@ struct sysfs_dirent *sysfs_find_dirent(struct sysfs_dirent
*parent_sd,
}
/**
- * sysfs_get_dirent - find and get sysfs_dirent with the given name
+ * sysfs_get_dirent_ns - find and get sysfs_dirent with the given name
* @parent_sd: sysfs_dirent to search under
* @name: name to look for
+ * @ns: the namespace tag to use
*
* Look for sysfs_dirent with name @name under @parent_sd and get
* it if found.
@@ -643,9 +644,9 @@ struct sysfs_dirent *sysfs_find_dirent(struct sysfs_dirent
*parent_sd,
* RETURNS:
* Pointer to sysfs_dirent if found, NULL if not.
*/
-struct sysfs_dirent *sysfs_get_dirent(struct sysfs_dirent *parent_sd,
- const void *ns,
- const unsigned char *name)
+struct sysfs_dirent *sysfs_get_dirent_ns(struct sysfs_dirent *parent_sd,
+const unsigned char *name,
+const void *ns)
{
struct sysfs_dirent *sd;
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index e784340..0f3214a 100644
--- a/fs/sysfs/file.c
+++
[PATCH 4/7] sysfs: remove ktype->namespace() invocations in symlink code
There's no reason for sysfs to be calling ktype->namespace(). It is
backwards, obfuscates what's going on and unnecessarily tangles two
separate layers.
There are two places where symlink code calls ktype->namespace().
* sysfs_do_create_link_sd() calls it to find out the namespace tag of
the target directory. Unless symlinking races with cross-namespace
renaming, this equals @target_sd->s_ns.
* sysfs_rename_link() uses it to find out the new namespace to rename
to and the new namespace can be different from the existing one.
The function is renamed to sysfs_rename_link_ns() with an explicit
@ns argument and the ktype->namespace() invocation is shifted to the
device layer.
While this patch replaces ktype->namespace() invocation with the
recorded result in @target_sd, this shouldn't result in any behvior
difference.
Signed-off-by: Tejun Heo
Cc: Eric W. Biederman
Cc: Kay Sievers
---
drivers/base/core.c | 8 +---
fs/sysfs/symlink.c| 16 +++-
include/linux/sysfs.h | 16
3 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index c7cfadc..3335000 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1881,6 +1881,7 @@ EXPORT_SYMBOL_GPL(device_destroy);
*/
int device_rename(struct device *dev, const char *new_name)
{
+ struct kobject *kobj = >kobj;
char *old_device_name = NULL;
int error;
@@ -1898,13 +1899,14 @@ int device_rename(struct device *dev, const char
*new_name)
}
if (dev->class) {
- error = sysfs_rename_link(>class->p->subsys.kobj,
- >kobj, old_device_name, new_name);
+ error = sysfs_rename_link_ns(>class->p->subsys.kobj,
+kobj, old_device_name,
+new_name, kobject_namespace(kobj));
if (error)
goto out;
}
- error = kobject_rename(>kobj, new_name);
+ error = kobject_rename(kobj, new_name);
if (error)
goto out;
diff --git a/fs/sysfs/symlink.c b/fs/sysfs/symlink.c
index 2dd4507..12d58ad 100644
--- a/fs/sysfs/symlink.c
+++ b/fs/sysfs/symlink.c
@@ -52,7 +52,7 @@ static int sysfs_do_create_link_sd(struct sysfs_dirent
*parent_sd,
ns_type = sysfs_ns_type(parent_sd);
if (ns_type)
- sd->s_ns = target->ktype->namespace(target);
+ sd->s_ns = target_sd->s_ns;
sd->s_symlink.target_sd = target_sd;
target_sd = NULL; /* reference is now owned by the symlink */
@@ -181,19 +181,20 @@ void sysfs_remove_link(struct kobject *kobj, const char
*name)
EXPORT_SYMBOL_GPL(sysfs_remove_link);
/**
- * sysfs_rename_link - rename symlink in object's directory.
+ * sysfs_rename_link_ns - rename symlink in object's directory.
* @kobj: object we're acting for.
* @targ: object we're pointing to.
* @old: previous name of the symlink.
* @new: new name of the symlink.
+ * @new_ns: new namespace of the symlink.
*
* A helper function for the common rename symlink idiom.
*/
-int sysfs_rename_link(struct kobject *kobj, struct kobject *targ,
- const char *old, const char *new)
+int sysfs_rename_link_ns(struct kobject *kobj, struct kobject *targ,
+const char *old, const char *new, const void *new_ns)
{
struct sysfs_dirent *parent_sd, *sd = NULL;
- const void *old_ns = NULL, *new_ns = NULL;
+ const void *old_ns = NULL;
int result;
if (!kobj)
@@ -215,16 +216,13 @@ int sysfs_rename_link(struct kobject *kobj, struct
kobject *targ,
if (sd->s_symlink.target_sd->s_dir.kobj != targ)
goto out;
- if (sysfs_ns_type(parent_sd))
- new_ns = targ->ktype->namespace(targ);
-
result = sysfs_rename(sd, parent_sd, new_ns, new);
out:
sysfs_put(sd);
return result;
}
-EXPORT_SYMBOL_GPL(sysfs_rename_link);
+EXPORT_SYMBOL_GPL(sysfs_rename_link_ns);
static int sysfs_get_target_path(struct sysfs_dirent *parent_sd,
struct sysfs_dirent *target_sd, char *path)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 7f56bad..c792f73 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -213,8 +213,9 @@ int __must_check sysfs_create_link_nowarn(struct kobject
*kobj,
const char *name);
void sysfs_remove_link(struct kobject *kobj, const char *name);
-int sysfs_rename_link(struct kobject *kobj, struct kobject *target,
- const char *old_name, const char *new_name);
+int sysfs_rename_link_ns(struct kobject *kobj, struct kobject *target,
+const char *old_name, const char *new_name,
+const void *new_ns);
void sysfs_delete_link(struct kobject
[PATCH 2/7] sysfs: make attr namespace interface less convoluted
sysfs ns (namespace) implementation became more convoluted than
necessary while trying to hide ns information from visible interface.
The relatively recent attr ns support is a good example.
* attr ns tag is determined by sysfs_ops->namespace() callback while
dir tag is determined by kobj_type->namespace(). The placement is
arbitrary.
* Instead of performing operations with explicit ns tag, the namespace
callback is routed through sysfs_attr_ns(), sysfs_ops->namespace(),
class_attr_namespace(), class_attr->namespace(). It's not simpler
in any sense. The only thing this convolution does is traversing
the whole stack backwards.
The namespace callbacks are unncessary because the operations involved
are inherently synchronous. The information can be provided in in
straight-forward top-down direction and reversing that direction is
unnecessary and against basic design principles.
This backward interface is unnecessarily convoluted and hinders
properly separating out sysfs from driver model / kobject for proper
layering. This patch updates attr ns support such that
* sysfs_ops->namespace() and class_attr->namespace() are dropped.
* sysfs_{create|remove}_file_ns(), which take explicit @ns param, are
added and sysfs_{create|remove}_file() are now simple wrappers
around the ns aware functions.
* ns handling is dropped from sysfs_chmod_file(). Nobody uses it at
this point. sysfs_chmod_file_ns() can be added later if necessary.
* Explicit @ns is propagated through class_{create|remove}_file_ns()
and netdev_class_{create|remove}_file_ns().
* driver/net/bonding which is currently the only user of attr
namespace is updated to use netdev_class_{create|remove}_file_ns()
with @bh->net as the ns tag instead of using the namespace callback.
This patch should be an equivalent conversion without any functional
difference. It makes the code easier to follow, reduces lines of code
a bit and helps proper separation and layering.
Signed-off-by: Tejun Heo
Cc: Eric W. Biederman
Cc: Kay Sievers
---
drivers/base/class.c | 29
drivers/net/bonding/bond_sysfs.c | 14 ++
fs/sysfs/file.c | 95 ++--
fs/sysfs/group.c | 7 +--
fs/sysfs/sysfs.h | 5 ++-
include/linux/device.h | 24 +++---
include/linux/netdevice.h| 16 ++-
include/linux/sysfs.h| 31 +
net/core/net-sysfs.c | 14 +++---
9 files changed, 106 insertions(+), 129 deletions(-)
diff --git a/drivers/base/class.c b/drivers/base/class.c
index 8b7818b..f96f704 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -47,18 +47,6 @@ static ssize_t class_attr_store(struct kobject *kobj, struct
attribute *attr,
return ret;
}
-static const void *class_attr_namespace(struct kobject *kobj,
- const struct attribute *attr)
-{
- struct class_attribute *class_attr = to_class_attr(attr);
- struct subsys_private *cp = to_subsys_private(kobj);
- const void *ns = NULL;
-
- if (class_attr->namespace)
- ns = class_attr->namespace(cp->class, class_attr);
- return ns;
-}
-
static void class_release(struct kobject *kobj)
{
struct subsys_private *cp = to_subsys_private(kobj);
@@ -86,7 +74,6 @@ static const struct kobj_ns_type_operations
*class_child_ns_type(struct kobject
static const struct sysfs_ops class_sysfs_ops = {
.show = class_attr_show,
.store = class_attr_store,
- .namespace = class_attr_namespace,
};
static struct kobj_type class_ktype = {
@@ -99,21 +86,23 @@ static struct kobj_type class_ktype = {
static struct kset *class_kset;
-int class_create_file(struct class *cls, const struct class_attribute *attr)
+int class_create_file_ns(struct class *cls, const struct class_attribute *attr,
+const void *ns)
{
int error;
if (cls)
- error = sysfs_create_file(>p->subsys.kobj,
- >attr);
+ error = sysfs_create_file_ns(>p->subsys.kobj,
+>attr, ns);
else
error = -EINVAL;
return error;
}
-void class_remove_file(struct class *cls, const struct class_attribute *attr)
+void class_remove_file_ns(struct class *cls, const struct class_attribute
*attr,
+ const void *ns)
{
if (cls)
- sysfs_remove_file(>p->subsys.kobj, >attr);
+ sysfs_remove_file_ns(>p->subsys.kobj, >attr, ns);
}
static struct class *class_get(struct class *cls)
@@ -600,8 +589,8 @@ int __init classes_init(void)
return 0;
}
-EXPORT_SYMBOL_GPL(class_create_file);
-EXPORT_SYMBOL_GPL(class_remove_file);
+EXPORT_SYMBOL_GPL(class_create_file_ns);
+EXPORT_SYMBOL_GPL(class_remove_file_ns);
EXPORT_SYMBOL_GPL(class_unregister);
[PATCH 1/7] sysfs: drop semicolon from to_sysfs_dirent() definition
The expansion of to_sysfs_dirent() contains an unncessary trailing semicolon making it impossible to use in the middle of statements. Drop it. Signed-off-by: Tejun Heo --- fs/sysfs/dir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c index 4d83ced..834c64c 100644 --- a/fs/sysfs/dir.c +++ b/fs/sysfs/dir.c @@ -28,7 +28,7 @@ DEFINE_MUTEX(sysfs_mutex); DEFINE_SPINLOCK(sysfs_assoc_lock); -#define to_sysfs_dirent(X) rb_entry((X), struct sysfs_dirent, s_rb); +#define to_sysfs_dirent(X) rb_entry((X), struct sysfs_dirent, s_rb) static DEFINE_SPINLOCK(sysfs_ino_lock); static DEFINE_IDA(sysfs_ino_ida); -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] sysfs: remove ktype->namespace() invocations in directory code
For some unrecognizable reason, namespace information is communicated
to sysfs through ktype->namespace() callback when there's *nothing*
which needs the use of a callback. The whole sequence of operations
is completely synchronous and sysfs operations simply end up calling
back into the layer which just invoked it in order to find out the
namespace information, which is completely backwards, obfuscates
what's going on and unnecessarily tangles two separate layers.
This patch doesn't remove ktype->namespace() but shifts its handling
to kobject layer. We probably want to get rid of the callback in the
long term.
This patch adds an explicit param to sysfs_{create|rename|move}_dir()
and renames them to sysfs_{create|rename|move}_dir_ns(), respectively.
ktype->namespace() invocations are moved to the calling sites of the
above functions. A new helper kboject_namespace() is introduced which
directly tests kobj_ns_type_operations->type which should give the
same result as testing sysfs_fs_type(parent_sd) and returns @kobj's
namespace tag as necessary. kobject_namespace() is extern as it will
be used from another file in the following patches.
This patch should be an equivalent conversion without any functional
difference.
Signed-off-by: Tejun Heo
Cc: Eric W. Biederman
Cc: Kay Sievers
---
fs/sysfs/dir.c | 23 ---
include/linux/kobject.h | 1 +
include/linux/sysfs.h | 20
lib/kobject.c | 28
4 files changed, 45 insertions(+), 27 deletions(-)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 834c64c..878ac3a 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -730,14 +730,14 @@ static enum kobj_ns_type sysfs_read_ns_type(struct
kobject *kobj)
}
/**
- * sysfs_create_dir - create a directory for an object.
- * @kobj: object we're creating directory for.
+ * sysfs_create_dir_ns - create a directory for an object with a namespace tag
+ * @kobj: object we're creating directory for
+ * @ns: the namespace tag to use
*/
-int sysfs_create_dir(struct kobject *kobj)
+int sysfs_create_dir_ns(struct kobject *kobj, const void *ns)
{
enum kobj_ns_type type;
struct sysfs_dirent *parent_sd, *sd;
- const void *ns = NULL;
int error = 0;
BUG_ON(!kobj);
@@ -750,8 +750,6 @@ int sysfs_create_dir(struct kobject *kobj)
if (!parent_sd)
return -ENOENT;
- if (sysfs_ns_type(parent_sd))
- ns = kobj->ktype->namespace(kobj);
type = sysfs_read_ns_type(kobj);
error = create_dir(kobj, parent_sd, type, ns, kobject_name(kobj), );
@@ -909,26 +907,21 @@ int sysfs_rename(struct sysfs_dirent *sd,
return error;
}
-int sysfs_rename_dir(struct kobject *kobj, const char *new_name)
+int sysfs_rename_dir_ns(struct kobject *kobj, const char *new_name,
+ const void *new_ns)
{
struct sysfs_dirent *parent_sd = kobj->sd->s_parent;
- const void *new_ns = NULL;
-
- if (sysfs_ns_type(parent_sd))
- new_ns = kobj->ktype->namespace(kobj);
return sysfs_rename(kobj->sd, parent_sd, new_ns, new_name);
}
-int sysfs_move_dir(struct kobject *kobj, struct kobject *new_parent_kobj)
+int sysfs_move_dir_ns(struct kobject *kobj, struct kobject *new_parent_kobj,
+ const void *new_ns)
{
struct sysfs_dirent *sd = kobj->sd;
struct sysfs_dirent *new_parent_sd;
- const void *new_ns = NULL;
BUG_ON(!sd->s_parent);
- if (sysfs_ns_type(sd->s_parent))
- new_ns = kobj->ktype->namespace(kobj);
new_parent_sd = new_parent_kobj && new_parent_kobj->sd ?
new_parent_kobj->sd : _root;
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index de6dcbcc..e7ba650 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -107,6 +107,7 @@ extern int __must_check kobject_move(struct kobject *,
struct kobject *);
extern struct kobject *kobject_get(struct kobject *kobj);
extern void kobject_put(struct kobject *kobj);
+extern const void *kobject_namespace(struct kobject *kobj);
extern char *kobject_get_path(struct kobject *kobj, gfp_t flag);
struct kobj_type {
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 82f7fac..7f56bad 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -182,11 +182,13 @@ struct sysfs_dirent;
int sysfs_schedule_callback(struct kobject *kobj, void (*func)(void *),
void *data, struct module *owner);
-int __must_check sysfs_create_dir(struct kobject *kobj);
+int __must_check sysfs_create_dir_ns(struct kobject *kobj, const void *ns);
void sysfs_remove_dir(struct kobject *kobj);
-int __must_check sysfs_rename_dir(struct kobject *kobj, const char *new_name);
-int __must_check sysfs_move_dir(struct kobject *kobj,
- struct kobject *new_parent_kobj);
+int __must_check
[PATCH 5/7] sysfs: drop kobj_ns_type handling
The way namespace tags are implemented in sysfs is more complicated
than necessary. As each tag is a pointer value and required to be
non-NULL under a namespace enabled parent, there's no need to record
separately what type each tag is or where namespace is enabled.
If multiple namespace types are needed, which currently aren't, we can
simply compare the tag to a set of allowed tags in the superblock
assuming that the tags, being pointers, won't have the same value
across multiple types. Also, whether to filter by namespace tag or
not can be trivially determined by whether the node has any tagged
children or not.
This patch rips out kobj_ns_type handling from sysfs. sysfs no longer
cares whether specific type of namespace is enabled or not. If a
sysfs_dirent has a non-NULL tag, the parent is marked as needing
namespace filtering and the value is tested against the allowed set of
tags for the superblock (currently only one but increasing this number
isn't difficult) and the sysfs_dirent is ignored if it doesn't match.
This removes most kobject namespace knowledge from sysfs proper which
will enable proper separation and layering of sysfs. The namespace
sanity checks in fs/sysfs/dir.c are replaced by the new sanity check
in kobject_namespace(). As this is the only place ktype->namespace()
is called for sysfs, this doesn't weaken the sanity check
significantly. I omitted converting the sanity check in
sysfs_do_create_link_sd(). While the check can be shifted to upper
layer, mistakes there are well contained and should be easily visible
anyway.
Signed-off-by: Tejun Heo
Cc: Eric W. Biederman
Cc: Kay Sievers
---
fs/sysfs/dir.c | 90 +++---
fs/sysfs/mount.c | 24 ---
fs/sysfs/symlink.c | 27
fs/sysfs/sysfs.h | 25 +--
lib/kobject.c | 5 ++-
5 files changed, 48 insertions(+), 123 deletions(-)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 878ac3a..1dfb4aa 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -111,6 +111,11 @@ static int sysfs_link_sibling(struct sysfs_dirent *sd)
/* add new node and rebalance the tree */
rb_link_node(>s_rb, parent, node);
rb_insert_color(>s_rb, >s_parent->s_dir.children);
+
+ /* if @sd has ns tag, mark the parent to enable ns filtering */
+ if (sd->s_ns)
+ sd->s_parent->s_flags |= SYSFS_FLAG_HAS_NS;
+
return 0;
}
@@ -130,6 +135,13 @@ static void sysfs_unlink_sibling(struct sysfs_dirent *sd)
sd->s_parent->s_dir.subdirs--;
rb_erase(>s_rb, >s_parent->s_dir.children);
+
+ /*
+* Either all or none of the children have tags. Clearing HAS_NS
+* when there's no child left is enough to keep the flag synced.
+*/
+ if (RB_EMPTY_ROOT(>s_parent->s_dir.children))
+ sd->s_parent->s_flags &= ~SYSFS_FLAG_HAS_NS;
}
#ifdef CONFIG_DEBUG_LOCK_ALLOC
@@ -297,7 +309,6 @@ static int sysfs_dentry_delete(const struct dentry *dentry)
static int sysfs_dentry_revalidate(struct dentry *dentry, unsigned int flags)
{
struct sysfs_dirent *sd;
- int type;
if (flags & LOOKUP_RCU)
return -ECHILD;
@@ -318,13 +329,8 @@ static int sysfs_dentry_revalidate(struct dentry *dentry,
unsigned int flags)
goto out_bad;
/* The sysfs dirent has been moved to a different namespace */
- type = KOBJ_NS_TYPE_NONE;
- if (sd->s_parent) {
- type = sysfs_ns_type(sd->s_parent);
- if (type != KOBJ_NS_TYPE_NONE &&
- sysfs_info(dentry->d_sb)->ns[type] != sd->s_ns)
- goto out_bad;
- }
+ if (sd->s_ns && sd->s_ns != sysfs_info(dentry->d_sb)->ns)
+ goto out_bad;
mutex_unlock(_mutex);
out_valid:
@@ -445,13 +451,6 @@ int __sysfs_add_one(struct sysfs_addrm_cxt *acxt, struct
sysfs_dirent *sd)
struct sysfs_inode_attrs *ps_iattr;
int ret;
- if (!!sysfs_ns_type(acxt->parent_sd) != !!sd->s_ns) {
- WARN(1, KERN_WARNING "sysfs: ns %s in '%s' for '%s'\n",
- sysfs_ns_type(acxt->parent_sd) ? "required" : "invalid",
- acxt->parent_sd->s_name, sd->s_name);
- return -EINVAL;
- }
-
sd->s_hash = sysfs_name_hash(sd->s_ns, sd->s_name);
sd->s_parent = sysfs_get(acxt->parent_sd);
@@ -613,13 +612,6 @@ struct sysfs_dirent *sysfs_find_dirent(struct sysfs_dirent
*parent_sd,
struct rb_node *node = parent_sd->s_dir.children.rb_node;
unsigned int hash;
- if (!!sysfs_ns_type(parent_sd) != !!ns) {
- WARN(1, KERN_WARNING "sysfs: ns %s in '%s' for '%s'\n",
- sysfs_ns_type(parent_sd) ? "required" : "invalid",
- parent_sd->s_name, name);
- return NULL;
- }
-
hash = sysfs_name_hash(ns, name);
[PATCH 7/7] sysfs: @name comes before @ns
Some internal sysfs functions which take explicit namespace argument
are weird in that they place the optional @ns in front of @name which
is contrary to the established convention. This is confusing and
error-prone especially as @ns and @name may be interchanged without
causing compilation warning.
Swap the positions of @name and @ns in the following internal
functions.
sysfs_find_dirent()
sysfs_rename()
sysfs_hash_and_remove()
sysfs_name_hash()
sysfs_name_compare()
create_dir()
This patch doesn't introduce any functional changes.
Signed-off-by: Tejun Heo
Cc: Eric W. Biederman
Cc: Kay Sievers
---
fs/sysfs/bin.c | 2 +-
fs/sysfs/dir.c | 45 +++--
fs/sysfs/file.c| 10 +-
fs/sysfs/group.c | 12 ++--
fs/sysfs/inode.c | 6 +++---
fs/sysfs/symlink.c | 6 +++---
fs/sysfs/sysfs.h | 10 +-
7 files changed, 46 insertions(+), 45 deletions(-)
diff --git a/fs/sysfs/bin.c b/fs/sysfs/bin.c
index c590cab..d49e6ca 100644
--- a/fs/sysfs/bin.c
+++ b/fs/sysfs/bin.c
@@ -497,6 +497,6 @@ EXPORT_SYMBOL_GPL(sysfs_create_bin_file);
void sysfs_remove_bin_file(struct kobject *kobj,
const struct bin_attribute *attr)
{
- sysfs_hash_and_remove(kobj->sd, NULL, attr->attr.name);
+ sysfs_hash_and_remove(kobj->sd, attr->attr.name, NULL);
}
EXPORT_SYMBOL_GPL(sysfs_remove_bin_file);
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index 3dacce0..d41b555 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -35,12 +35,12 @@ static DEFINE_IDA(sysfs_ino_ida);
/**
* sysfs_name_hash
- * @ns: Namespace tag to hash
* @name: Null terminated string to hash
+ * @ns: Namespace tag to hash
*
* Returns 31 bit hash of ns + name (so it fits in an off_t )
*/
-static unsigned int sysfs_name_hash(const void *ns, const char *name)
+static unsigned int sysfs_name_hash(const char *name, const void *ns)
{
unsigned long hash = init_name_hash();
unsigned int len = strlen(name);
@@ -56,8 +56,8 @@ static unsigned int sysfs_name_hash(const void *ns, const
char *name)
return hash;
}
-static int sysfs_name_compare(unsigned int hash, const void *ns,
- const char *name, const struct sysfs_dirent *sd)
+static int sysfs_name_compare(unsigned int hash, const char *name,
+ const void *ns, const struct sysfs_dirent *sd)
{
if (hash != sd->s_hash)
return hash - sd->s_hash;
@@ -69,7 +69,7 @@ static int sysfs_name_compare(unsigned int hash, const void
*ns,
static int sysfs_sd_compare(const struct sysfs_dirent *left,
const struct sysfs_dirent *right)
{
- return sysfs_name_compare(left->s_hash, left->s_ns, left->s_name,
+ return sysfs_name_compare(left->s_hash, left->s_name, left->s_ns,
right);
}
@@ -451,7 +451,7 @@ int __sysfs_add_one(struct sysfs_addrm_cxt *acxt, struct
sysfs_dirent *sd)
struct sysfs_inode_attrs *ps_iattr;
int ret;
- sd->s_hash = sysfs_name_hash(sd->s_ns, sd->s_name);
+ sd->s_hash = sysfs_name_hash(sd->s_name, sd->s_ns);
sd->s_parent = sysfs_get(acxt->parent_sd);
ret = sysfs_link_sibling(sd);
@@ -596,6 +596,7 @@ void sysfs_addrm_finish(struct sysfs_addrm_cxt *acxt)
* sysfs_find_dirent - find sysfs_dirent with the given name
* @parent_sd: sysfs_dirent to search under
* @name: name to look for
+ * @ns: the namespace tag to use
*
* Look for sysfs_dirent with name @name under @parent_sd.
*
@@ -606,19 +607,19 @@ void sysfs_addrm_finish(struct sysfs_addrm_cxt *acxt)
* Pointer to sysfs_dirent if found, NULL if not.
*/
struct sysfs_dirent *sysfs_find_dirent(struct sysfs_dirent *parent_sd,
- const void *ns,
- const unsigned char *name)
+ const unsigned char *name,
+ const void *ns)
{
struct rb_node *node = parent_sd->s_dir.children.rb_node;
unsigned int hash;
- hash = sysfs_name_hash(ns, name);
+ hash = sysfs_name_hash(name, ns);
while (node) {
struct sysfs_dirent *sd;
int result;
sd = to_sysfs_dirent(node);
- result = sysfs_name_compare(hash, ns, name, sd);
+ result = sysfs_name_compare(hash, name, ns, sd);
if (result < 0)
node = node->rb_left;
else if (result > 0)
@@ -651,7 +652,7 @@ struct sysfs_dirent *sysfs_get_dirent_ns(struct
sysfs_dirent *parent_sd,
struct sysfs_dirent *sd;
mutex_lock(_mutex);
- sd = sysfs_find_dirent(parent_sd, ns, name);
+ sd = sysfs_find_dirent(parent_sd, name, ns);
sysfs_get(sd);
mutex_unlock(_mutex);
@@ -660,7 +661,8 @@ struct sysfs_dirent
Re: [PATCH] firmware: Be a bit more verbose about direct firmware loading failure
On Wed, Sep 11, 2013 at 10:19 PM, Neil Horman wrote:
> On Wed, Sep 11, 2013 at 07:54:28PM +0800, Ming Lei wrote:
>> On Sat, Sep 7, 2013 at 3:36 AM, Neil Horman wrote:
>> > The direct firmware loading interface is a bit quiet about failures.
>> > Failures
>>
>> Because there are several pre-defined search paths, and generally the
>> requested firmware only exists in one of these paths.
>>
> This is true, but you'll note this patch doesn't make any noise in the event
> that a firmware isn't found until all the search paths are exhausted. I
> didn't
> consider this "unexpected".
Yes, it will cause noise, suppose the firmware is in the last search path, and
we may always get the warning during the first three searches, and it
is certainly
annoying, isn't it?
>
>> > that occur during loading are masked if firmware exists in multiple
>> > locations,
>> > and may be masked entirely in the event that we fall back to the user mode
>>
>> You still can figure out the request falls back to user mode loading since we
>> have the "firmware: direct-loading firmware %s" log.
>>
> Yes, but you're looking at it backwards, that only prints out if the direct
> load
> works. If it doesn't, you get silence, which is bad.
OK, you can change to only log the failure.
>
>> > helper code. It would be nice to see some of the more unexpected errors
>> > get
>>
>> What are the unexpected errors?
>>
> If you get a short read in the direct load path for example, or if someone
> mounts an nfs share over the firmware search path and you get an ESTALE.
That is easy to find, and no one should mount one fs on firmware path.
> Alternatively, if the vmalloc fails during the direct load path, these would
> be
> "unexpected" errors
This one might make sense since size of some firmwares may be several mega
bytes, and vmalloc space is a bit limited on 32bit arch, so how about just log
this failure in fw_read_file_contents()?
>
>> > logged, so in the event that you expect the direct firmware loader to work
>> > (like
>> > if CONFIG_FW_LOADER_USER_HELPER is enabled), and something goes wrong, you
>> > can
>> > figure out what happened.
>>
>> Looks we didn't meet this case, do you have real examples?
>>
> Yeah, we had a vmalloc failure in the direct load path, and unknowingly had
> forgot to configure CONFIG_FW_LOADER_USER_HELPER, so the module load failed
> with
> an ENOENT, even though the firmware was clearly present on the filesystem.
> This
> patch helped us track that down.
Fair enough, looks it is helpful to add some log, :-)
>
> Neil
>
>> >
>> > Signed-off-by: Neil Horman
>> > CC: Ming Lei
>> > CC: Greg Kroah-Hartman
>> > ---
>> > drivers/base/firmware_class.c | 38 +-
>> > 1 file changed, 25 insertions(+), 13 deletions(-)
>> >
>> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
>> > index 10a4467..eb8fb94 100644
>> > --- a/drivers/base/firmware_class.c
>> > +++ b/drivers/base/firmware_class.c
>> > @@ -282,31 +282,35 @@ static noinline_for_stack long fw_file_size(struct
>> > file *file)
>> > return st.size;
>> > }
>> >
>> > -static bool fw_read_file_contents(struct file *file, struct firmware_buf
>> > *fw_buf)
>> > +static int fw_read_file_contents(struct file *file, struct firmware_buf
>> > *fw_buf)
>> > {
>> > long size;
>> > char *buf;
>> > + int rc;
>> >
>> > size = fw_file_size(file);
>> > if (size <= 0)
>> > - return false;
>> > + return -EINVAL;
>> > buf = vmalloc(size);
>> > if (!buf)
>> > - return false;
>> > - if (kernel_read(file, 0, buf, size) != size) {
>> > + return -ENOMEM;
>> > + rc = kernel_read(file, 0, buf, size);
>> > + if (rc != size) {
>> > + if (rc > 0)
>> > + rc = -EIO;
>> > vfree(buf);
>> > - return false;
>> > + return rc;
>> > }
>> > fw_buf->data = buf;
>> > fw_buf->size = size;
>> > - return true;
>> > + return 0;
>> > }
>> >
>> > -static bool fw_get_filesystem_firmware(struct device *device,
>> > +static int fw_get_filesystem_firmware(struct device *device,
>> >struct firmware_buf *buf)
>> > {
>> > int i;
>> > - bool success = false;
>> > + int rc = -ENOENT;
>> > char *path = __getname();
>> >
>> > for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
>> > @@ -321,14 +325,17 @@ static bool fw_get_filesystem_firmware(struct device
>> > *device,
>> > file = filp_open(path, O_RDONLY, 0);
>> > if (IS_ERR(file))
>> > continue;
>> > - success = fw_read_file_contents(file, buf);
>> > + rc = fw_read_file_contents(file, buf);
>> > fput(file);
>> > - if (success)
>> > + if (rc)
>> > +
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Wed, Sep 11, 2013 at 11:45:19AM +0300, Jani Nikula wrote: > On Wed, 11 Sep 2013, Aaron Lu wrote: > > It is possible the i915 driver decides not to register a backlight > > interface for the graphics card for some reason(memory allocation failed > > or it knows the native control does not work on this card or whatever), > > so I would prefer let i915 tell ACPI video that it has registered a > > native backlight control interface as Jani has said. > > > > Then together with the video.use_native_backlight, we can register or > > not register ACPI video backlight interface accordingly. Or rather, we > > can simply not register ACPI video backlight interface for Win8 systems > > as long as i915 indicates that it has native backlight control(if the > > native control is broken, i915 should fix it or blacklist it so that > > i915 will not indicate it has native backlight control and ACPI video > > will continue to register its own). > > > > How does this sound? > > Sounds good to me. > > Before plunging forward, have you observed any difference between the > boot modes? We have reports [1] that the backlight behaviour is Not yet from ACPI's point of view. > different with UEFI vs. UEFI+CSM or legacy boot. So I'm wondering if the > acpi_gbl_osi_data >= ACPI_OSI_WIN_8 check in patch 2/2 is the whole > story. This check in patch 2/2 is a policy: for Win8 system, we think the native backlight control has a better chance of working than the ACPI video's, so I think the check is enough in ACPI video. > > Further, if we tell the BIOS we're Windows 8 to use the tested BIOS code > paths, what guarantees do we have of UEFI+CSM or legacy boots working? I suppose the 'tested BIOS code paths' means the pure UEFI boot mode? I don't know what guatantees do we have since I don't know what happened underneath after the backlight register is set in i915 driver, you or other i915 driver people should know more than I do :-) BTW, after the backlight register is set in i915, is it that some find of firmware code will run in response to the setting of the register(e.g. the BLC_PWM_CTL/BLC_PWM_CPU_CTL/PCI_LBPC reg)? Thanks, Aaron -- 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] cpufreq: tegra: Re-model Tegra cpufreq driver
On Thu, 2013-09-12 at 03:33 +0800, Stephen Warren wrote:
> On 09/11/2013 05:19 AM, Bill Huang wrote:
> > diff --git a/drivers/cpufreq/tegra20-cpufreq.c
> > b/drivers/cpufreq/tegra20-cpufreq.c
>
> > +static struct cpufreq_frequency_table freq_table[] = {
> > + { .frequency = 216000 },
> > + { .frequency = 312000 },
> > + { .frequency = 456000 },
> > + { .frequency = 608000 },
> > + { .frequency = 76 },
> > + { .frequency = 816000 },
> > + { .frequency = 912000 },
> > + { .frequency = 100 },
> > + { .frequency = CPUFREQ_TABLE_END },
> > +};
>
> Should/can we query that list from the clock driver?
>
It's not easy to query that list from clock driver so I'll leave it as
it was. I'll take all the other comments, 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 0/7] preempt_count rework -v2
On Wed, Sep 11, 2013 at 04:02:14PM -0700, Linus Torvalds wrote:
> On Wed, Sep 11, 2013 at 11:59 AM, Peter Zijlstra wrote:
> >
> > OK, stripped it down further, I couldn't quite see how to collapse the
> > unary and binary operator variants though :/
>
> Ok, this looks pretty good. I assume it works too? ;)
Only compile tested that one.. the below is kvm boot tested until root
mount -- I'll try on actual hardware when I've gotten some sleep.
I split the thing up into two macros GEN_UNARY_RMWcc and
GEN_BINARY_RMWcc which ends up being more readable as well as smaller
code overall.
I also attempted to convert asm/bitops.h, although I'm not sure it'll
compile right with older GCCs due to the comment near BITOP_ADDR()
It also changes the fallback from sbb %0,%0 to setc %0, which afaict
should be similar but I'm not too familiar with all that.
I might have to add the clobber to the macro arguments so we can do
version without "memory" clobber, although bitops is inconsistent with
that as well, __test_and_clear_bit() doesn't have a memory clobber but
__test_and_change_bit() does.
---
arch/x86/include/asm/atomic.h | 29 +++---
arch/x86/include/asm/atomic64_64.h | 28 ++---
arch/x86/include/asm/bitops.h | 58 +
arch/x86/include/asm/local.h | 28 ++---
arch/x86/include/asm/rmwcc.h | 52 +
5 files changed, 73 insertions(+), 122 deletions(-)
--- a/arch/x86/include/asm/atomic.h
+++ b/arch/x86/include/asm/atomic.h
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
/*
* Atomic operations that C can't guarantee us. Useful for
@@ -76,12 +77,7 @@ static inline void atomic_sub(int i, ato
*/
static inline int atomic_sub_and_test(int i, atomic_t *v)
{
- unsigned char c;
-
- asm volatile(LOCK_PREFIX "subl %2,%0; sete %1"
-: "+m" (v->counter), "=qm" (c)
-: "ir" (i) : "memory");
- return c;
+ GEN_BINARY_RMWcc(LOCK_PREFIX "subl", v->counter, i, "%0", "e");
}
/**
@@ -118,12 +114,7 @@ static inline void atomic_dec(atomic_t *
*/
static inline int atomic_dec_and_test(atomic_t *v)
{
- unsigned char c;
-
- asm volatile(LOCK_PREFIX "decl %0; sete %1"
-: "+m" (v->counter), "=qm" (c)
-: : "memory");
- return c != 0;
+ GEN_UNARY_RMWcc(LOCK_PREFIX "decl", v->counter, "%0", "e");
}
/**
@@ -136,12 +127,7 @@ static inline int atomic_dec_and_test(at
*/
static inline int atomic_inc_and_test(atomic_t *v)
{
- unsigned char c;
-
- asm volatile(LOCK_PREFIX "incl %0; sete %1"
-: "+m" (v->counter), "=qm" (c)
-: : "memory");
- return c != 0;
+ GEN_UNARY_RMWcc(LOCK_PREFIX "incl", v->counter, "%0", "e");
}
/**
@@ -155,12 +141,7 @@ static inline int atomic_inc_and_test(at
*/
static inline int atomic_add_negative(int i, atomic_t *v)
{
- unsigned char c;
-
- asm volatile(LOCK_PREFIX "addl %2,%0; sets %1"
-: "+m" (v->counter), "=qm" (c)
-: "ir" (i) : "memory");
- return c;
+ GEN_BINARY_RMWcc(LOCK_PREFIX "addl", v->counter, i, "%0", "s");
}
/**
--- a/arch/x86/include/asm/atomic64_64.h
+++ b/arch/x86/include/asm/atomic64_64.h
@@ -72,12 +72,7 @@ static inline void atomic64_sub(long i,
*/
static inline int atomic64_sub_and_test(long i, atomic64_t *v)
{
- unsigned char c;
-
- asm volatile(LOCK_PREFIX "subq %2,%0; sete %1"
-: "=m" (v->counter), "=qm" (c)
-: "er" (i), "m" (v->counter) : "memory");
- return c;
+ GEN_BINARY_RMWcc(LOCK_PREFIX "subq", v->counter, i, "%0", "e");
}
/**
@@ -116,12 +111,7 @@ static inline void atomic64_dec(atomic64
*/
static inline int atomic64_dec_and_test(atomic64_t *v)
{
- unsigned char c;
-
- asm volatile(LOCK_PREFIX "decq %0; sete %1"
-: "=m" (v->counter), "=qm" (c)
-: "m" (v->counter) : "memory");
- return c != 0;
+ GEN_UNARY_RMWcc(LOCK_PREFIX "decq", v->counter, "%0", "e");
}
/**
@@ -134,12 +124,7 @@ static inline int atomic64_dec_and_test(
*/
static inline int atomic64_inc_and_test(atomic64_t *v)
{
- unsigned char c;
-
- asm volatile(LOCK_PREFIX "incq %0; sete %1"
-: "=m" (v->counter), "=qm" (c)
-: "m" (v->counter) : "memory");
- return c != 0;
+ GEN_UNARY_RMWcc(LOCK_PREFIX "incq", v->counter, "%0", "e");
}
/**
@@ -153,12 +138,7 @@ static inline int atomic64_inc_and_test(
*/
static inline int atomic64_add_negative(long i, atomic64_t *v)
{
- unsigned char c;
-
- asm volatile(LOCK_PREFIX "addq %2,%0; sets %1"
-: "=m" (v->counter), "=qm" (c)
-: "er" (i), "m" (v->counter) : "memory");
- return c;
+
Re: [PATCH 27/50] mm: numa: Scan pages with elevated page_mapcount
Hillo Mel On Tue, Sep 10, 2013 at 5:32 PM, Mel Gorman wrote: > Currently automatic NUMA balancing is unable to distinguish between false > shared versus private pages except by ignoring pages with an elevated > page_mapcount entirely. This avoids shared pages bouncing between the > nodes whose task is using them but that is ignored quite a lot of data. > > This patch kicks away the training wheels in preparation for adding support > for identifying shared/private pages is now in place. The ordering is so > that the impact of the shared/private detection can be easily measured. Note > that the patch does not migrate shared, file-backed within vmas marked > VM_EXEC as these are generally shared library pages. Migrating such pages > is not beneficial as there is an expectation they are read-shared between > caches and iTLB and iCache pressure is generally low. > > Signed-off-by: Mel Gorman > --- [...] > @@ -1658,13 +1660,6 @@ int migrate_misplaced_transhuge_page(struct mm_struct > *mm, > int page_lru = page_is_file_cache(page); > > /* > -* Don't migrate pages that are mapped in multiple processes. > -* TODO: Handle false sharing detection instead of this hammer > -*/ > - if (page_mapcount(page) != 1) > - goto out_dropref; > - Is there rmap walk when migrating THP? > - /* > * Rate-limit the amount of data that is being migrated to a node. > * Optimal placement is no good if the memory bus is saturated and > * all the time is being spent migrating! -- 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: Re: [f2fs-dev][PATCH] f2fs: optimize fs_lock for better performance
Hi Kim
> -Original Message-
> From: Kim Jaegeuk [mailto:jaegeuk@gmail.com]
> Sent: Wednesday, September 11, 2013 9:15 PM
> To: chao2...@samsung.com
> Cc: ???; 谭姝; linux-fsde...@vger.kernel.org;
linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: Re: [f2fs-dev][PATCH] f2fs: optimize fs_lock for better
performance
>
> Hi,
>
> 2013/9/11 Chao Yu
> >
> > Hi Kim,
> >
> > I did some tests as you mention of using random instead of spin_lock.
> > The test model is as following:
> > eight threads race to grab one of eight locks for one thousand times,
> > and I used four methods to generate lock num:
> >
> > 1.atomic_add_return(1, >next_lock_num) % NR_GLOBAL_LOCKS;
> > 2.spin_lock(); next_lock_num++ % NR_GLOBAL_LOCKS; spin_unlock();
> > 3.ktime_get().tv64 % NR_GLOBAL_LOCKS;
> > 4.get_random_bytes(_lock, sizeof(unsigned int));
> >
> > the result indicate that:
> > max count of collide continuously: 4 > 3 > 2 = 1 max-min count of lock
> > is grabbed: 4 > 3 > 2 = 1 elapsed time of generating: 3 > 2 > 4 > 1
> >
> > So I think it's better to use atomic_add_return in round-robin method
> > to cost less time and reduce collide.
> > What's your opinion?
>
> Could you test with sbi->next_lock_num++ only instead of using
> atomic_add_return?
> IMO, this is just an integer value and still I don't think this value
should be
> covered by any kind of locks.
> Thanks,
Thanks for the advice, I have tested sbi->next_lock_num++.
The time cost of it is a little bit lower than the atomic one's.
for running 8 thread for 100 times test.
the performance of it's balance and collide play quit well than I expected.
Can we modify this patch as following?
root@virtaulmachine:/home/yuchao/git/linux-next/fs/f2fs# git diff --stat
fs/f2fs/f2fs.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
root@virtaulmachine:/home/yuchao/git/linux-next/fs/f2fs# git diff
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 608f0df..7fd99d8 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -544,15 +544,15 @@ static inline void mutex_unlock_all(struct
f2fs_sb_info *sbi)
static inline int mutex_lock_op(struct f2fs_sb_info *sbi)
{
- unsigned char next_lock = sbi->next_lock_num % NR_GLOBAL_LOCKS;
+ unsigned char next_lock;
int i = 0;
for (; i < NR_GLOBAL_LOCKS; i++)
if (mutex_trylock(>fs_lock[i]))
return i;
+ next_lock = sbi->next_lock_num++ % NR_GLOBAL_LOCKS;
mutex_lock(>fs_lock[next_lock]);
- sbi->next_lock_num++;
return next_lock;
}
>
> >
> > thanks
> >
> > --- Original Message ---
> > Sender : ??? S5(??)/??/?(???)/
> > Date : 九月 10, 2013 09:52 (GMT+09:00)
> > Title : Re: [f2fs-dev][PATCH] f2fs: optimize fs_lock for better
> > performance
> >
> > Hi,
> >
> > At first, thank you for the report and please follow the email writing
> > rules. :)
> >
> > Anyway, I agree to the below issue.
> > One thing that I can think of is that we don't need to use the
> > spin_lock, since we don't care about the exact lock number, but just
> > need to get any not-collided number.
> >
> > So, how about removing the spin_lock?
> > And how about using a random number?
> > Thanks,
> >
> > 2013-09-06 (?), 09:48 +, Chao Yu:
> > > Hi Kim:
> > >
> > > I think there is a performance problem: when all sbi->fs_lock
> > > is holded,
> > >
> > > then all other threads may get the same next_lock value from
> > > sbi->next_lock_num in function mutex_lock_op,
> > >
> > > and wait to get the same lock at position fs_lock[next_lock], it
> > > unbalance the fs_lock usage.
> > >
> > > It may lost performance when we do the multithread test.
> > >
> > >
> > >
> > > Here is the patch to fix this problem:
> > >
> > >
> > >
> > > Signed-off-by: Yu Chao
> > >
> > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > >
> > > old mode 100644
> > >
> > > new mode 100755
> > >
> > > index 467d42d..983bb45
> > >
> > > --- a/fs/f2fs/f2fs.h
> > >
> > > +++ b/fs/f2fs/f2fs.h
> > >
> > > @@ -371,6 +371,7 @@ struct f2fs_sb_info {
> > >
> > > struct mutex fs_lock[NR_GLOBAL_LOCKS]; /* blocking FS
> > > operations */
> > >
> > > struct mutex node_write;/* locking node
> writes
> > > */
> > >
> > > struct mutex writepages;/* mutex for
> > > writepages() */
> > >
> > > + spinlock_t spin_lock; /* lock for
> > > next_lock_num */
> > >
> > > unsigned char next_lock_num;/* round-robin
> global
> > > locks */
> > >
> > > int por_doing; /* recovery is
> doing
> > > or not */
> > >
> > > int on_build_free_nids; /* build_free_nids is
> > > doing */
> > >
> > > @@ -533,15 +534,19 @@ static inline void mutex_unlock_all(struct
> > > f2fs_sb_info *sbi)
> > >
> > >
> > >
> > > static inline int mutex_lock_op(struct f2fs_sb_info *sbi)
> > >
> > > {
> > >
> > > -
Re: [PATCH 4/4] Documentation: add LP3943 DT bindings and document
Hi Everyone,
Please ignore this mail. Version information, 'v3' is missing in the
subject.
Fixed mail has just sent. Please find '[PATCH v3 4/4]' in your mailbox.
Sorry for the inconvenience.
Best regards,
Milo
On 09/12/2013 10:34 AM, Milo Kim wrote:
Bindings for LP3943 MFD, GPIO and PWM controller are added.
And LP3943 driver document is added also.
Cc: devicet...@vger.kernel.org
Cc: Lee Jones
Cc: Linus Walleij
Cc: Samuel Ortiz
Cc: Thierry Reding
Signed-off-by: Milo Kim
---
Documentation/00-INDEX |2 +
.../devicetree/bindings/gpio/gpio-lp3943.txt | 37
Documentation/devicetree/bindings/mfd/lp3943.txt | 33 +++
.../devicetree/bindings/pwm/pwm-lp3943.txt | 58 ++
Documentation/lp3943.txt | 62
5 files changed, 192 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
create mode 100644 Documentation/devicetree/bindings/mfd/lp3943.txt
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
create mode 100644 Documentation/lp3943.txt
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 0c4cc68..5dd921f 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -285,6 +285,8 @@ logo.gif
- full colour GIF image of Linux logo (penguin - Tux).
logo.txt
- info on creator of above logo & site to get additional images from.
+lp3943.txt
+ - info on LP3943 MFD driver structure.
m68k/
- directory with info about Linux on Motorola 68k architecture.
magic-number.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
b/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
new file mode 100644
index 000..80fcb7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
@@ -0,0 +1,37 @@
+TI/National Semiconductor LP3943 GPIO controller
+
+Required properties:
+ - compatible: "ti,lp3943-gpio"
+ - gpio-controller: Marks the device node as a GPIO controller.
+ - #gpio-cells: Should be 2. See gpio.txt in this directory for a
+ description of the cells format.
+
+Example:
+Simple LED controls with LP3943 GPIO controller
+
+ {
+ lp3943@60 {
+ compatible = "ti,lp3943";
+ reg = <0x60>;
+
+ gpioex: gpio {
+ compatible = "ti,lp3943-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+};
+
+leds {
+ compatible = "gpio-leds";
+ indicator1 {
+ label = "indi1";
+ gpios = < 9 GPIO_ACTIVE_LOW>;
+ };
+
+ indicator2 {
+ label = "indi2";
+ gpios = < 10 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+};
diff --git a/Documentation/devicetree/bindings/mfd/lp3943.txt
b/Documentation/devicetree/bindings/mfd/lp3943.txt
new file mode 100644
index 000..e8591d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lp3943.txt
@@ -0,0 +1,33 @@
+TI/National Semiconductor LP3943 MFD driver
+
+Required properties:
+ - compatible: "ti,lp3943"
+ - reg: I2C slave address. From 0x60 to 0x67.
+
+LP3943 consists of two sub-devices, lp3943-gpio and lp3943-pwm.
+
+For the LP3943 GPIO properties please refer to:
+Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
+
+For the LP3943 PWM properties please refer to:
+Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
+
+Example:
+
+lp3943@60 {
+ compatible = "ti,lp3943";
+ reg = <0x60>;
+
+ gpioex: gpio {
+ compatible = "ti,lp3943-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ pwm3943: pwm {
+ compatible = "ti,lp3943-pwm";
+ #pwm-cells = <2>;
+ ti,pwm0 = <8 9 10>;
+ ti,pwm1 = <15>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
b/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
new file mode 100644
index 000..7bd9d3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
@@ -0,0 +1,58 @@
+TI/National Semiconductor LP3943 PWM controller
+
+Required properties:
+ - compatible: "ti,lp3943-pwm"
+ - #pwm-cells: Should be 2. See pwm.txt in this directory for a
+description of the cells format.
+Note that this hardware limits the period length to the
+range 6250~160.
+ - ti,pwm0 or ti,pwm1: Output pin number(s) for PWM channel 0 or 1.
+0 = output 0
+1 = output 1
+.
+.
+15 = output 15
+
+Example:
+PWM 0 is for RGB LED brightness control
+PWM 1 is for brightness control of LP8557 backlight device
+
+ {
+ lp3943@60 {
+ compatible = "ti,lp3943";
+ reg = <0x60>;
+
+ /*
+* PWM 0 : output 8, 9 and 10
+*
[PATCH] regulator: palmas: Remove wrong comment for the equation calculating num_voltages
Current equation on the comment is wrong.
For linear mapping starting from 0, the equation is (maxV-minV)/stepV + 1.
Since the linear mapping for PALMAS is not all starting from 0, the equation
on the comment is not useful and misleading. Thus remove it.
Signed-off-by: Axel Lin
---
drivers/regulator/palmas-regulator.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index fba4faa..7e2b165 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -201,12 +201,6 @@ static unsigned int palmas_smps_ramp_delay[4] = {0, 1,
5000, 2500};
#define SMPS_CTRL_MODE_ECO 0x02
#define SMPS_CTRL_MODE_PWM 0x03
-/* These values are derived from the data sheet. And are the number of steps
- * where there is a voltage change, the ranges at beginning and end of register
- * max/min values where there are no change are ommitted.
- *
- * So they are basically (maxV-minV)/stepV
- */
#define PALMAS_SMPS_NUM_VOLTAGES 122
#define PALMAS_SMPS10_NUM_VOLTAGES 2
#define PALMAS_LDO_NUM_VOLTAGES50
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Large pastes into readline enabled programs causes breakage from v2.6.31 onwards
On 09/03/2013 05:12 PM, Maximiliano Curia wrote: ¡Hola Peter! El 2013-08-19 a las 08:25 -0400, Peter Hurley escribió: My primary concern is canonical readers not become stuck with a full read buffer, even with bogus input data (IOW, that an error condition will not prevent a reader from making forward progress). I believe that won't happen with this change, but what I really need in this case is a detailed analysis from you of why that won't happen. That analysis should be in the patch changelog. (Feel free to send me private mail if you need help preparing a patch.) I'm not sure what level of analysis you are looking for. For example, why will CPU 0 (the reader) not hang forever under the following circumstances? CPU 0| CPU 1 | n_tty_read() | n_tty_receive_buf2() . | receive_room . | . . | is waitqueue_active()? no add_wait_queue() | . .| . is input_available_p()? | . no - schedule_timeout() <-- reader sleeps | . | return 0 | exit i/o loop in flush_to_ldisc() work function | A complete and detailed analysis would go a long way to getting this patch accepted. If you show that your patch won't hang readers _and_ fixes the larger-than-4k-paste bug, then the readline() deficiencies will probably be overlooked. The driver will block when there are no readers but as soon as there is a read call it unblocks. I've added this information to the patch description that I'm including below. And the patch above has a bug that allows a negative 'left' to be assigned to tty->receive_room which will be interpreted as a very large positive value. Ok, fixed with an else clause. It could also use an extra &&, but it looks a bit confusing. This approach still has several drawbacks. 1) Since additional state is reset when the termios is changed by readline(), the canonical line buffer state will be bogus. This renders the termios change by readline() pointless; the caller will not be able to retrieve expected input properly. 2) Since the input data is interpreted with the current termios when data is received, any embedded control characters will not be interpreted properly; again, the caller will not be able to retrieve expected input properly. Indeed this is correct, however this is not an issue of this patch but of the current interaction between the kernel and readline. My point here was this: the whole point of readline() flipping termios settings back and forth is to allow readline() to use one setting while the caller uses a different setting. If you don't care that the readline() caller doesn't receives its input properly when pasted, why is the solution to this problem patching the linux kernel instead of ripping out the termios-flipping that readline() does? In order to fix this, the reading buffer should always be in raw and only when responding to a read call for canonical mode should it be interpreted. This is a very big change, and I'm not sure if anybody will be interested in implementing it. So the receiver only echoes input once it's been read??? Because if implemented as you suggest, until the input has been read you wouldn't know what termios settings to apply for the echoed chars (or even if to echo). What do you think? Is the proposed solution, or something along those lines, acceptable? I'm wondering if this problem might be best addressed on the paste side instead of the read side. Although this wouldn't be a magic bullet, it would be easier to control when more paste data is added. I don't see how this could work, could you elaborate? Well, the vt driver already supports a PASTE_SELECTION ioctl which bypasses the flip buffers. Something similar might be suitable for line-oriented pasting, where only one line is written at a time. I haven't given too much thought to how/what would perform the wake up of the paster; right now, the vt driver implements unthrottle to continue pasting. This is the patch proposal, for comments: From 81afd3b666cbf94bb9923ebf87fb2017a7cd645e Mon Sep 17 00:00:00 2001 From: Maximiliano Curia Date: Tue, 3 Sep 2013 22:48:34 +0200 Subject: [PATCH] Only let characters through when there are active readers. If there is an active reader, previous behavior is in place. When there is no active reader, input is blocked until the next read call unblocks it. This fixes a long standing issue with readline when pasting more than 4096 bytes. --- drivers/tty/n_tty.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
[PATCH v3 4/4] Documentation: add LP3943 DT bindings and document
Bindings for LP3943 MFD, GPIO and PWM controller are added.
And LP3943 driver document is added also.
Cc: devicet...@vger.kernel.org
Cc: Lee Jones
Cc: Linus Walleij
Cc: Samuel Ortiz
Cc: Thierry Reding
Signed-off-by: Milo Kim
---
Documentation/00-INDEX |2 +
.../devicetree/bindings/gpio/gpio-lp3943.txt | 37
Documentation/devicetree/bindings/mfd/lp3943.txt | 33 +++
.../devicetree/bindings/pwm/pwm-lp3943.txt | 58 ++
Documentation/lp3943.txt | 62
5 files changed, 192 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
create mode 100644 Documentation/devicetree/bindings/mfd/lp3943.txt
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
create mode 100644 Documentation/lp3943.txt
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 0c4cc68..5dd921f 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -285,6 +285,8 @@ logo.gif
- full colour GIF image of Linux logo (penguin - Tux).
logo.txt
- info on creator of above logo & site to get additional images from.
+lp3943.txt
+ - info on LP3943 MFD driver structure.
m68k/
- directory with info about Linux on Motorola 68k architecture.
magic-number.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
b/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
new file mode 100644
index 000..80fcb7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
@@ -0,0 +1,37 @@
+TI/National Semiconductor LP3943 GPIO controller
+
+Required properties:
+ - compatible: "ti,lp3943-gpio"
+ - gpio-controller: Marks the device node as a GPIO controller.
+ - #gpio-cells: Should be 2. See gpio.txt in this directory for a
+ description of the cells format.
+
+Example:
+Simple LED controls with LP3943 GPIO controller
+
+ {
+ lp3943@60 {
+ compatible = "ti,lp3943";
+ reg = <0x60>;
+
+ gpioex: gpio {
+ compatible = "ti,lp3943-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+};
+
+leds {
+ compatible = "gpio-leds";
+ indicator1 {
+ label = "indi1";
+ gpios = < 9 GPIO_ACTIVE_LOW>;
+ };
+
+ indicator2 {
+ label = "indi2";
+ gpios = < 10 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+};
diff --git a/Documentation/devicetree/bindings/mfd/lp3943.txt
b/Documentation/devicetree/bindings/mfd/lp3943.txt
new file mode 100644
index 000..e8591d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lp3943.txt
@@ -0,0 +1,33 @@
+TI/National Semiconductor LP3943 MFD driver
+
+Required properties:
+ - compatible: "ti,lp3943"
+ - reg: I2C slave address. From 0x60 to 0x67.
+
+LP3943 consists of two sub-devices, lp3943-gpio and lp3943-pwm.
+
+For the LP3943 GPIO properties please refer to:
+Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
+
+For the LP3943 PWM properties please refer to:
+Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
+
+Example:
+
+lp3943@60 {
+ compatible = "ti,lp3943";
+ reg = <0x60>;
+
+ gpioex: gpio {
+ compatible = "ti,lp3943-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ pwm3943: pwm {
+ compatible = "ti,lp3943-pwm";
+ #pwm-cells = <2>;
+ ti,pwm0 = <8 9 10>;
+ ti,pwm1 = <15>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
b/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
new file mode 100644
index 000..7bd9d3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
@@ -0,0 +1,58 @@
+TI/National Semiconductor LP3943 PWM controller
+
+Required properties:
+ - compatible: "ti,lp3943-pwm"
+ - #pwm-cells: Should be 2. See pwm.txt in this directory for a
+description of the cells format.
+Note that this hardware limits the period length to the
+range 6250~160.
+ - ti,pwm0 or ti,pwm1: Output pin number(s) for PWM channel 0 or 1.
+0 = output 0
+1 = output 1
+.
+.
+15 = output 15
+
+Example:
+PWM 0 is for RGB LED brightness control
+PWM 1 is for brightness control of LP8557 backlight device
+
+ {
+ lp3943@60 {
+ compatible = "ti,lp3943";
+ reg = <0x60>;
+
+ /*
+* PWM 0 : output 8, 9 and 10
+* PWM 1 : output 15
+*/
+ pwm3943: pwm {
+ compatible = "ti,lp3943-pwm";
+ #pwm-cells = <2>;
+ ti,pwm0 = <8 9 10>;
+ ti,pwm1 = <15>;
+ };
+
[PATCH 4/4] Documentation: add LP3943 DT bindings and document
Bindings for LP3943 MFD, GPIO and PWM controller are added.
And LP3943 driver document is added also.
Cc: devicet...@vger.kernel.org
Cc: Lee Jones
Cc: Linus Walleij
Cc: Samuel Ortiz
Cc: Thierry Reding
Signed-off-by: Milo Kim
---
Documentation/00-INDEX |2 +
.../devicetree/bindings/gpio/gpio-lp3943.txt | 37
Documentation/devicetree/bindings/mfd/lp3943.txt | 33 +++
.../devicetree/bindings/pwm/pwm-lp3943.txt | 58 ++
Documentation/lp3943.txt | 62
5 files changed, 192 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
create mode 100644 Documentation/devicetree/bindings/mfd/lp3943.txt
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
create mode 100644 Documentation/lp3943.txt
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 0c4cc68..5dd921f 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -285,6 +285,8 @@ logo.gif
- full colour GIF image of Linux logo (penguin - Tux).
logo.txt
- info on creator of above logo & site to get additional images from.
+lp3943.txt
+ - info on LP3943 MFD driver structure.
m68k/
- directory with info about Linux on Motorola 68k architecture.
magic-number.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
b/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
new file mode 100644
index 000..80fcb7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
@@ -0,0 +1,37 @@
+TI/National Semiconductor LP3943 GPIO controller
+
+Required properties:
+ - compatible: "ti,lp3943-gpio"
+ - gpio-controller: Marks the device node as a GPIO controller.
+ - #gpio-cells: Should be 2. See gpio.txt in this directory for a
+ description of the cells format.
+
+Example:
+Simple LED controls with LP3943 GPIO controller
+
+ {
+ lp3943@60 {
+ compatible = "ti,lp3943";
+ reg = <0x60>;
+
+ gpioex: gpio {
+ compatible = "ti,lp3943-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+};
+
+leds {
+ compatible = "gpio-leds";
+ indicator1 {
+ label = "indi1";
+ gpios = < 9 GPIO_ACTIVE_LOW>;
+ };
+
+ indicator2 {
+ label = "indi2";
+ gpios = < 10 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+};
diff --git a/Documentation/devicetree/bindings/mfd/lp3943.txt
b/Documentation/devicetree/bindings/mfd/lp3943.txt
new file mode 100644
index 000..e8591d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lp3943.txt
@@ -0,0 +1,33 @@
+TI/National Semiconductor LP3943 MFD driver
+
+Required properties:
+ - compatible: "ti,lp3943"
+ - reg: I2C slave address. From 0x60 to 0x67.
+
+LP3943 consists of two sub-devices, lp3943-gpio and lp3943-pwm.
+
+For the LP3943 GPIO properties please refer to:
+Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
+
+For the LP3943 PWM properties please refer to:
+Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
+
+Example:
+
+lp3943@60 {
+ compatible = "ti,lp3943";
+ reg = <0x60>;
+
+ gpioex: gpio {
+ compatible = "ti,lp3943-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ pwm3943: pwm {
+ compatible = "ti,lp3943-pwm";
+ #pwm-cells = <2>;
+ ti,pwm0 = <8 9 10>;
+ ti,pwm1 = <15>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
b/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
new file mode 100644
index 000..7bd9d3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
@@ -0,0 +1,58 @@
+TI/National Semiconductor LP3943 PWM controller
+
+Required properties:
+ - compatible: "ti,lp3943-pwm"
+ - #pwm-cells: Should be 2. See pwm.txt in this directory for a
+description of the cells format.
+Note that this hardware limits the period length to the
+range 6250~160.
+ - ti,pwm0 or ti,pwm1: Output pin number(s) for PWM channel 0 or 1.
+0 = output 0
+1 = output 1
+.
+.
+15 = output 15
+
+Example:
+PWM 0 is for RGB LED brightness control
+PWM 1 is for brightness control of LP8557 backlight device
+
+ {
+ lp3943@60 {
+ compatible = "ti,lp3943";
+ reg = <0x60>;
+
+ /*
+* PWM 0 : output 8, 9 and 10
+* PWM 1 : output 15
+*/
+ pwm3943: pwm {
+ compatible = "ti,lp3943-pwm";
+ #pwm-cells = <2>;
+ ti,pwm0 = <8 9 10>;
+ ti,pwm1 = <15>;
+ };
+
[PATCH v3 3/4] pwm: add LP3943 PWM driver
This is the other of the LP3943 MFD driver.
LP3943 can be used as a PWM generator, up to 2 channels.
* Two PWM generators supported
* Supported PWM operations
request, free, config, enable and disable
* Pin assignment
A driver data, 'pin_used' is checked when a PWM is requested.
If the output pin is already assigned, then returns as failure.
If the pin is available, 'pin_used' is set.
When the PWM is not used anymore, then it is cleared.
It is defined as unsigned long type for atomic bit operation APIs,
but only LSB 16bits are used because LP3943 has 16 outputs.
Cc: Thierry Reding
Signed-off-by: Milo Kim
---
* Patch v3
Manual polarity not supported any more.
Add encapsulation functions for accessing internal data structure.
Use pwm_set_chip_data() and pwm_get_chip_data().
And other code fixes based on Thierry's feedback.
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-lp3943.c | 314 ++
3 files changed, 325 insertions(+)
create mode 100644 drivers/pwm/pwm-lp3943.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 75840b5..9cf38bc 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -81,6 +81,16 @@ config PWM_JZ4740
To compile this driver as a module, choose M here: the module
will be called pwm-jz4740.
+config PWM_LP3943
+ tristate "TI/National Semiconductor LP3943 PWM support"
+ depends on MFD_LP3943
+ help
+ Generic PWM framework driver for LP3943 which supports two PWM
+ channels.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-lp3943.
+
config PWM_LPC32XX
tristate "LPC32XX PWM support"
depends on ARCH_LPC32XX
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 77a8c18..db8e349 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_PWM_ATMEL_TCB) += pwm-atmel-tcb.o
obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
+obj-$(CONFIG_PWM_LP3943) += pwm-lp3943.o
obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
diff --git a/drivers/pwm/pwm-lp3943.c b/drivers/pwm/pwm-lp3943.c
new file mode 100644
index 000..8a843a0
--- /dev/null
+++ b/drivers/pwm/pwm-lp3943.c
@@ -0,0 +1,314 @@
+/*
+ * TI/National Semiconductor LP3943 PWM driver
+ *
+ * Copyright 2013 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LP3943_MAX_DUTY255
+#define LP3943_MIN_PERIOD 6250
+#define LP3943_MAX_PERIOD 160
+
+struct lp3943_pwm {
+ struct pwm_chip chip;
+ struct lp3943 *lp3943;
+ struct lp3943_platform_data *pdata;
+};
+
+static inline struct lp3943_pwm *to_lp3943_pwm(struct pwm_chip *_chip)
+{
+ return container_of(_chip, struct lp3943_pwm, chip);
+}
+
+static struct lp3943_pwm_map *
+lp3943_pwm_request_map(struct lp3943_pwm *lp3943_pwm, int hwpwm)
+{
+ struct lp3943_platform_data *pdata = lp3943_pwm->pdata;
+ struct lp3943 *lp3943 = lp3943_pwm->lp3943;
+ struct lp3943_pwm_map *pwm_map;
+ int i, offset;
+
+ pwm_map = kzalloc(sizeof(*pwm_map), GFP_KERNEL);
+ if (!pwm_map)
+ return ERR_PTR(-ENOMEM);
+
+ pwm_map->output = pdata->pwms[hwpwm]->output;
+ pwm_map->num_outputs = pdata->pwms[hwpwm]->num_outputs;
+
+ for (i = 0; i < pwm_map->num_outputs; i++) {
+ offset = pwm_map->output[i];
+
+ /* Return an error if the pin is already assigned */
+ if (test_and_set_bit(offset, >pin_used))
+ return ERR_PTR(-EBUSY);
+ }
+
+ return pwm_map;
+}
+
+static int lp3943_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct lp3943_pwm *lp3943_pwm = to_lp3943_pwm(chip);
+ struct lp3943_pwm_map *pwm_map;
+
+ pwm_map = lp3943_pwm_request_map(lp3943_pwm, pwm->hwpwm);
+ if (IS_ERR(pwm_map))
+ return PTR_ERR(pwm_map);
+
+ return pwm_set_chip_data(pwm, pwm_map);
+}
+
+static void lp3943_pwm_free_map(struct lp3943_pwm *lp3943_pwm,
+ struct lp3943_pwm_map *pwm_map)
+{
+ struct lp3943 *lp3943 = lp3943_pwm->lp3943;
+ int i, offset;
+
+ for (i = 0; i < pwm_map->num_outputs; i++) {
+ offset = pwm_map->output[i];
+ clear_bit(offset, >pin_used);
+ }
+
+ kfree(pwm_map);
+}
+
+static void lp3943_pwm_free(struct pwm_chip *chip, struct
[PATCH v3 2/4] gpio: add LP3943 I2C GPIO expander driver
This is one of LP3943 MFD driver.
LP3943 is configurable as a GPIO expander, up to 16 GPIOs.
* Application note: how to configure LP3943 as a GPIO expander
http://www.ti.com/lit/an/snva287a/snva287a.pdf
* Supported GPIO controller operations
request, free, direction_input, direction_output, get and set
* GPIO direction register not supported
LP3943 doesn't have the GPIO direction register. It only provides input and
output status registers.
So, private data for the direction should be handled manually.
This variable is updated whenever the direction is changed and
used in 'get' operation.
* Pin assignment
A driver data, 'pin_used' is checked when a GPIO is requested.
If the GPIO is already assigned, then returns as failure.
If the GPIO is available, 'pin_used' is set.
When the GPIO is not used anymore, then it is cleared.
It is defined as unsigned long type for atomic bit operation APIs,
but only LSB 16bits are used because LP3943 has 16 outputs.
Reviewed-by: Linus Walleij
Signed-off-by: Milo Kim
---
* Patch v3
Use inline function instead of macro(), to_lp3943_gpio().
Add 'lp3943_gpio_set_mode()' and use it in lp3943_gpio_direction_input() and
lp3943_gpio_set().
Few code cosmetic applied - indentations.
* Patch v2
Use bitops macros for bit manipulations.
Support device tree structure for the GPIO controller.
Add request() and free() for the pin assignment.
drivers/gpio/Kconfig |8 ++
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-lp3943.c | 242
3 files changed, 251 insertions(+)
create mode 100644 drivers/gpio/gpio-lp3943.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 349b161..60fb6e7 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -360,6 +360,14 @@ config GPIO_ARIZONA
help
Support for GPIOs on Wolfson Arizona class devices.
+config GPIO_LP3943
+ tristate "TI/National Semiconductor LP3943 GPIO expander"
+ depends on MFD_LP3943
+ help
+ GPIO driver for LP3943 MFD.
+ LP3943 can be used as a GPIO expander which provides up to 16 GPIOs.
+ Open drain outputs are required for this usage.
+
config GPIO_MAX7300
tristate "Maxim MAX7300 GPIO expander"
depends on I2C
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 97438bf..d1e2836 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_GPIO_JANZ_TTL) += gpio-janz-ttl.o
obj-$(CONFIG_GPIO_KEMPLD) += gpio-kempld.o
obj-$(CONFIG_ARCH_KS8695) += gpio-ks8695.o
obj-$(CONFIG_GPIO_LANGWELL)+= gpio-langwell.o
+obj-$(CONFIG_GPIO_LP3943) += gpio-lp3943.o
obj-$(CONFIG_ARCH_LPC32XX) += gpio-lpc32xx.o
obj-$(CONFIG_GPIO_LYNXPOINT) += gpio-lynxpoint.o
obj-$(CONFIG_GPIO_MAX730X) += gpio-max730x.o
diff --git a/drivers/gpio/gpio-lp3943.c b/drivers/gpio/gpio-lp3943.c
new file mode 100644
index 000..7b8db88
--- /dev/null
+++ b/drivers/gpio/gpio-lp3943.c
@@ -0,0 +1,242 @@
+/*
+ * TI/National Semiconductor LP3943 GPIO driver
+ *
+ * Copyright 2013 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum lp3943_gpios {
+ LP3943_GPIO1,
+ LP3943_GPIO2,
+ LP3943_GPIO3,
+ LP3943_GPIO4,
+ LP3943_GPIO5,
+ LP3943_GPIO6,
+ LP3943_GPIO7,
+ LP3943_GPIO8,
+ LP3943_GPIO9,
+ LP3943_GPIO10,
+ LP3943_GPIO11,
+ LP3943_GPIO12,
+ LP3943_GPIO13,
+ LP3943_GPIO14,
+ LP3943_GPIO15,
+ LP3943_GPIO16,
+ LP3943_MAX_GPIO,
+};
+
+struct lp3943_gpio {
+ struct gpio_chip chip;
+ struct lp3943 *lp3943;
+ u16 input_mask; /* 1 = GPIO is input direction, 0 = output */
+};
+
+static inline struct lp3943_gpio *to_lp3943_gpio(struct gpio_chip *_chip)
+{
+ return container_of(_chip, struct lp3943_gpio, chip);
+}
+
+static int lp3943_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+ struct lp3943_gpio *lp3943_gpio = to_lp3943_gpio(chip);
+ struct lp3943 *lp3943 = lp3943_gpio->lp3943;
+
+ /* Return an error if the pin is already assigned */
+ if (test_and_set_bit(offset, >pin_used))
+ return -EBUSY;
+
+ return 0;
+}
+
+static void lp3943_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+ struct lp3943_gpio *lp3943_gpio = to_lp3943_gpio(chip);
+ struct lp3943 *lp3943 = lp3943_gpio->lp3943;
+
+ clear_bit(offset, >pin_used);
+}
+
+static int lp3943_gpio_set_mode(struct lp3943_gpio *lp3943_gpio, u8 offset,
+ u8 val)
+{
+ struct lp3943 *lp3943 = lp3943_gpio->lp3943;
+ const struct
[PATCH v3 1/4] mfd: add LP3943 MFD driver
LP3943 has 16 output pins which can be used as GPIO expander and PWM generator.
* Regmap I2C interface for R/W LP3943 registers
* Atomic operations for output pin assignment
The driver should check whether requested pin is available or not.
If the pin is already used, pin request returns as a failure.
A driver data, 'pin_used' is checked when gpio_request() and
pwm_request() are called. If the pin is available, then pin_used is set.
And it is cleared when gpio_free() and pwm_free().
* Device tree support
Compatible strings for GPIO and PWM driver.
LP3943 platform data is PWM related, so parsing the device tree is
implemented in the PWM driver.
Cc: Lee Jones
Cc: Linus Walleij
Cc: Samuel Ortiz
Cc: Thierry Reding
Signed-off-by: Milo Kim
---
* Patch v3
Now, output pin number is exactly matched with enum value of '
lp3943_pwm_output'.
Use dev_get_platdata() helper function in probe().
Use module_i2c_driver() for initcall.
* Patch v2
Handle atomic operations for output pin assignment.
drivers/mfd/Kconfig| 11
drivers/mfd/Makefile |1 +
drivers/mfd/lp3943.c | 148
include/linux/mfd/lp3943.h | 114 ++
4 files changed, 274 insertions(+)
create mode 100644 drivers/mfd/lp3943.c
create mode 100644 include/linux/mfd/lp3943.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index e0e46f5..7058358 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -715,6 +715,17 @@ config MFD_DM355EVM_MSP
boards. MSP430 firmware manages resets and power sequencing,
inputs from buttons and the IR remote, LEDs, an RTC, and more.
+config MFD_LP3943
+ tristate "TI/National Semiconductor LP3943 MFD Driver"
+ depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ Support for the TI/National Semiconductor LP3943.
+ This driver consists of GPIO and PWM drivers.
+ With these functionalities, it can be used for LED string control or
+ general usage such like a GPIO controller and a PWM controller.
+
config MFD_LP8788
bool "TI LP8788 Power Management Unit Driver"
depends on I2C=y && GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 15b905c..a6d2b22 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -102,6 +102,7 @@ obj-$(CONFIG_PMIC_DA9052) += da9052-core.o
obj-$(CONFIG_MFD_DA9052_SPI) += da9052-spi.o
obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
+obj-$(CONFIG_MFD_LP3943) += lp3943.o
obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o
da9055-objs:= da9055-core.o da9055-i2c.o
diff --git a/drivers/mfd/lp3943.c b/drivers/mfd/lp3943.c
new file mode 100644
index 000..d25cc0a
--- /dev/null
+++ b/drivers/mfd/lp3943.c
@@ -0,0 +1,148 @@
+/*
+ * TI/National Semiconductor LP3943 MFD Core Driver
+ *
+ * Copyright 2013 Texas Instruments
+ *
+ * Author: Milo Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LP3943_MAX_REGISTERS 0x09
+
+/* Register configuration for pin MUX */
+static const struct lp3943_reg_cfg lp3943_mux_cfg[] = {
+ /* address, mask, shift */
+ { LP3943_REG_MUX0, 0x03, 0 },
+ { LP3943_REG_MUX0, 0x0C, 2 },
+ { LP3943_REG_MUX0, 0x30, 4 },
+ { LP3943_REG_MUX0, 0xC0, 6 },
+ { LP3943_REG_MUX1, 0x03, 0 },
+ { LP3943_REG_MUX1, 0x0C, 2 },
+ { LP3943_REG_MUX1, 0x30, 4 },
+ { LP3943_REG_MUX1, 0xC0, 6 },
+ { LP3943_REG_MUX2, 0x03, 0 },
+ { LP3943_REG_MUX2, 0x0C, 2 },
+ { LP3943_REG_MUX2, 0x30, 4 },
+ { LP3943_REG_MUX2, 0xC0, 6 },
+ { LP3943_REG_MUX3, 0x03, 0 },
+ { LP3943_REG_MUX3, 0x0C, 2 },
+ { LP3943_REG_MUX3, 0x30, 4 },
+ { LP3943_REG_MUX3, 0xC0, 6 },
+};
+
+static struct mfd_cell lp3943_devs[] = {
+ {
+ .name = "lp3943-pwm",
+ .of_compatible = "ti,lp3943-pwm",
+ },
+ {
+ .name = "lp3943-gpio",
+ .of_compatible = "ti,lp3943-gpio",
+ },
+};
+
+int lp3943_read_byte(struct lp3943 *lp3943, u8 reg, u8 *read)
+{
+ int ret;
+ unsigned int val;
+
+ ret = regmap_read(lp3943->regmap, reg, );
+ if (ret < 0)
+ return ret;
+
+ *read = (u8)val;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(lp3943_read_byte);
+
+int lp3943_write_byte(struct lp3943 *lp3943, u8 reg, u8 data)
+{
+ return regmap_write(lp3943->regmap, reg, data);
+}
+EXPORT_SYMBOL_GPL(lp3943_write_byte);
+
+int lp3943_update_bits(struct lp3943 *lp3943, u8 reg, u8 mask, u8 data)
+{
+ return regmap_update_bits(lp3943->regmap, reg, mask, data);
+}
[PATCH v3 0/4] LP3943 MFD driver for a GPIO expander and a PWM generator
LP3943 is an integrated device capable of driving 16 output channels. It can be used for GPIO expander and PWM generators. LP3493 registers are controlled via the I2C interface. This patch-set consists of four parts - MFD, GPIO, PWM and documents. Major updates in v3: * MFD Lee Jones pointed confusing pin number notation. Now, each output pin number is exactly matched to each enum value. LP3943 has a static configuration from platform data or the device tree, So, I keep the driver structure instead of using the pin control subsystem. (https://lkml.org/lkml/2013/8/14/490) * PWM Do not emulate 'set_polarity' function in case of unsupported feature by the chip. Code fixes based on Thierry Reding's comments. (https://lkml.org/lkml/2013/8/14/188) * Documentation From Thierry's suggestion, detailed driver description was moved to 'Documentation/lp3943.txt'. Fix device tree bindings from maintainers' comments. (https://lkml.org/lkml/2013/7/31/226) (https://lkml.org/lkml/2013/8/14/569) Milo Kim (4): mfd: add LP3943 MFD driver gpio: add LP3943 I2C GPIO expander driver pwm: add LP3943 PWM driver Documentation: add LP3943 DT bindings and document Documentation/00-INDEX |2 + .../devicetree/bindings/gpio/gpio-lp3943.txt | 37 +++ Documentation/devicetree/bindings/mfd/lp3943.txt | 33 ++ .../devicetree/bindings/pwm/pwm-lp3943.txt | 58 Documentation/lp3943.txt | 62 drivers/gpio/Kconfig |8 + drivers/gpio/Makefile |1 + drivers/gpio/gpio-lp3943.c | 242 +++ drivers/mfd/Kconfig| 11 + drivers/mfd/Makefile |1 + drivers/mfd/lp3943.c | 148 + drivers/pwm/Kconfig| 10 + drivers/pwm/Makefile |1 + drivers/pwm/pwm-lp3943.c | 314 include/linux/mfd/lp3943.h | 114 +++ 15 files changed, 1042 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-lp3943.txt create mode 100644 Documentation/devicetree/bindings/mfd/lp3943.txt create mode 100644 Documentation/devicetree/bindings/pwm/pwm-lp3943.txt create mode 100644 Documentation/lp3943.txt create mode 100644 drivers/gpio/gpio-lp3943.c create mode 100644 drivers/mfd/lp3943.c create mode 100644 drivers/pwm/pwm-lp3943.c create mode 100644 include/linux/mfd/lp3943.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] timekeeping: introduce timekeeping_is_busy()
On Wed, Sep 11, 2013 at 08:48:11PM -0400, Mathieu Desnoyers wrote:
> Thoughts ?
struct foo {
...
};
spinlock_t foo_lock;
unsigned int foo_head = 0;
unsigned int foo_tail = 0;
struct foo foo_array[2];
void foo_assign(struct foo f)
{
spin_lock(_lock);
foo_head++;
smp_wmb();
foo_array[foo_head & 1] = f;
smp_wmb();
foo_tail++;
spin_unlock(_lock);
}
struct foo foo_get(void)
{
unsigned int tail, head;
struct foo ret;
again:
tail = ACCESS_ONCE(foo_tail);
smp_rmb();
ret = foo_array[tail & 1];
smp_rmb();
head = ACCESS_ONCE(foo_head);
if (head - tail >= 2)
goto again;
return ret;
}
Should work and get you the most recent 'complete' foo even when
foo_get() is called nested inside foo_assign().
--
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] procfs: restore 0400 permissions on /proc/*/{syscall,stack,personality}
Hi Eric,
(Sorry for the delay, please see below)
On Sat, Aug 31, 2013 at 06:44:39PM -0700, Eric W. Biederman wrote:
> Djalal Harouni writes:
[...]
> > Yes Kees,
> >
> > I did try a year ago to adapt the exec_id from grsecurity and failed
> > (and failed again to resend - not enough resources):
> > https://lkml.org/lkml/2012/3/10/174
> >
> >
> > Kees IMHO the right solution is to invalidate the fd across exec as
> > you suggest
> >
> > Alan Cox's thread which describe the problem correctly:
> > https://lkml.org/lkml/2012/1/29/35
> >
> > Alan suggested to revoke() the file handles.
>
> That was in particular with respect to /dev/mem.
>
> In the general case calling setuid or any of it's cousins can cause the
> same problem. So a revoke that only works at exec time is insufficient.
Well, in that particular case the flaw is in the programs that don't
handle setuid and its cousins correctly. IMHO this is a different case,
our concerns here are external suid-exec programs.
A sort of revoke or file handle invalidating on exec is already used as
the close-on-exec flag.
>
> The problem we are examining is what happens when the file descriptor is
> passed to a more privileged process that will pass the ptrace_may_access
> check while the original process that opened the file did not.
>
> We have file->f_cred that has the permissions of the process at open
> time, and likely that should factor into the calculations somehow.
Ok, thanks
> Alternatively we may simply be able to call get_task_cred() at the time
> we open the file and if the cred on the process changes fail. I know
> Linus was looking at something like that recently, but ran into problmes
> with Chromes sandbox. (Sigh). Although I think he was talking about
> file->f_cred...
Ok, can you provide a link please? thanks
> This is most definitely a solvable problem with current mechanisms, but
> it is going to take some grunt work to make it happen.
Please see below for a small PoC to test what you suggest Eric
So we embed a f_cred inside a seq_file struct and set it at seq_open()
We can also remove that 'user_ns' that is embedded in seq_file sruct
since we'll have it inside the f_cred!
I've added a proc_may_access() function that will check the f_cred of
the opener against the target at read time, I've done this for:
1) the reader at open time may have enough permissions
2) reader does a suid-exec or change its ruid/euid
3) suid-exec or same reader with new privileged creds reads data
This is a legitimate scenario which I didn't want to block, so the fd
still can be passed but you will be able to read from it only if you
pass a) the classic ptrace check b) the check of f_cred against the
target.
IMO it's better than: check only if the cred of the process changes.
Since this is just a PoC for /proc/*/stack, I'll do more test, improve
it and send it as a series, thanks!
Any comment is welcome
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 1485e38..025a53e 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -139,6 +139,54 @@ struct pid_entry {
NULL, _single_file_operations, \
{ .proc_show = show } )
+/* Returns 0 on success, -errno on denial. */
+static int __proc_may_access(struct task_struct *task,
+const struct cred *fcred, unsigned int mode)
+{
+ int ret = 0;
+ const struct cred *tcred;
+
+ rcu_read_lock();
+ tcred = __task_cred(task);
+ if (uid_eq(fcred->uid, tcred->euid) &&
+ uid_eq(fcred->uid, tcred->suid) &&
+ uid_eq(fcred->uid, tcred->uid) &&
+ gid_eq(fcred->gid, tcred->egid) &&
+ gid_eq(fcred->gid, tcred->sgid) &&
+ gid_eq(fcred->gid, tcred->gid))
+ goto out;
+
+ if (mode & PTRACE_MODE_NOAUDIT)
+ ret = security_capable_noaudit(fcred, tcred->user_ns,
+ CAP_SYS_PTRACE);
+ else
+ ret = security_capable(fcred, tcred->user_ns,
+ CAP_SYS_PTRACE);
+
+ if (ret)
+ ret = -EPERM;
+
+out:
+ rcu_read_unlock();
+ return ret;
+}
+
+/**
+ * proc_may_access - Check if the file's opener had enough permissions
+ * to access the target process.
+ *
+ * Callers must hold the task->signal->cred_guard_mutex
+ */
+int proc_may_access(struct task_struct *task,
+ const struct cred *fcred, unsigned int mode)
+{
+ int ret;
+ task_lock(task);
+ ret = __proc_may_access(task, fcred, mode);
+ task_unlock(task);
+ return !ret;
+}
+
/*
* Count the number of hardlinks for the pid_entry table, excluding the .
* and .. links.
@@ -306,6 +354,7 @@ static int proc_pid_stack(struct seq_file *m, struct
pid_namespace *ns,
unsigned long *entries;
int err;
int i;
+ const struct cred *fcred = m->f_cred;
entries = kmalloc(MAX_STACK_TRACE_DEPTH * sizeof(*entries),
