RE: [tip:x86/urgent] x86-64, init: Do not set NX bits on non-NX capable hardware
(resending as plaintext) > During early init, we would incorrectly set the NX bit even if the NX > feature was not supported. Instead, only set this bit if NX is > actually available and enabled. We already do very early detection of > the NX bit to enable it in EFER, this simply extends this detection to > the early page table mask. AFAIK the only production x86-64 processor that don't support NX that I know of is the original Nocona D0 stepping. Must more common are the problem of BIOSes disabling the NX feature. Yuhong Bao-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 33/42] drivers/video/omap2: don't check resource with devm_ioremap_resource
On Friday, May 10, 2013 5:17 PM, Wolfram Sang wrote:
>
> devm_ioremap_resource does sanity checks on the given resource. No need to
> duplicate this in the driver.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/video/omap2/vrfb.c |5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
> index 5261229..f346b02 100644
> --- a/drivers/video/omap2/vrfb.c
> +++ b/drivers/video/omap2/vrfb.c
> @@ -353,11 +353,6 @@ static int __init vrfb_probe(struct platform_device
> *pdev)
> /* first resource is the register res, the rest are vrfb contexts */
>
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!mem) {
> - dev_err(>dev, "can't get vrfb base address\n");
> - return -EINVAL;
> - }
> -
> vrfb_base = devm_ioremap_resource(>dev, mem);
> if (IS_ERR(vrfb_base))
> return PTR_ERR(vrfb_base);
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 34/42] drivers/video/omap2/dss: don't check resource with devm_ioremap_resource
On Friday, May 10, 2013 5:17 PM, Wolfram Sang wrote:
>
> devm_ioremap_resource does sanity checks on the given resource. No need to
> duplicate this in the driver.
>
> Signed-off-by: Wolfram Sang
It looks good.
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/video/omap2/dss/hdmi.c |7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
> index 17f4d55..7bc6762 100644
> --- a/drivers/video/omap2/dss/hdmi.c
> +++ b/drivers/video/omap2/dss/hdmi.c
> @@ -1064,13 +1064,8 @@ static int omapdss_hdmihw_probe(struct platform_device
> *pdev)
> mutex_init();
> mutex_init(_data.lock);
>
> - res = platform_get_resource(hdmi.pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - DSSERR("can't get IORESOURCE_MEM HDMI\n");
> - return -EINVAL;
> - }
> -
> /* Base address taken from platform */
> + res = platform_get_resource(hdmi.pdev, IORESOURCE_MEM, 0);
> hdmi.ip_data.base_wp = devm_ioremap_resource(>dev, res);
> if (IS_ERR(hdmi.ip_data.base_wp))
> return PTR_ERR(hdmi.ip_data.base_wp);
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 32/42] drivers/video: don't check resource with devm_ioremap_resource
On Friday, May 10, 2013 5:17 PM, Wolfram Sang wrote:
>
> devm_ioremap_resource does sanity checks on the given resource. No need to
> duplicate this in the driver.
>
> Signed-off-by: Wolfram Sang
CC'ed Tomi Valkeinen, Shawn Guo, Fabio Estevam
It looks good.
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/video/mxsfb.c |7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> index 1b2c26d..3dc3265 100644
> --- a/drivers/video/mxsfb.c
> +++ b/drivers/video/mxsfb.c
> @@ -883,12 +883,6 @@ static int mxsfb_probe(struct platform_device *pdev)
> if (of_id)
> pdev->id_entry = of_id->data;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(>dev, "Cannot get memory IO resource\n");
> - return -ENODEV;
> - }
> -
> fb_info = framebuffer_alloc(sizeof(struct mxsfb_info), >dev);
> if (!fb_info) {
> dev_err(>dev, "Failed to allocate fbdev\n");
> @@ -897,6 +891,7 @@ static int mxsfb_probe(struct platform_device *pdev)
>
> host = to_imxfb_host(fb_info);
>
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> host->base = devm_ioremap_resource(>dev, res);
> if (IS_ERR(host->base)) {
> dev_err(>dev, "ioremap failed\n");
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/73] 3.9.2-stable review
At Thu, 9 May 2013 15:24:50 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.9.2 release. > There are 73 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat May 11 22:23:28 UTC 2013. > Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian wheezy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian wheezy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB I reviewed the following patches and it looks good to me. > David Cohen > MODSIGN: do not send garbage to stderr when enabling modules signature ... > Jan-Simon Möller > perf/x86/intel: Fix unintended variable name reuse Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 23/42] drivers/spi: don't check resource with devm_ioremap_resource
On Friday, May 10, 2013 5:17 PM, Wolfram Sang wrote:
>
> devm_ioremap_resource does sanity checks on the given resource. No need to
> duplicate this in the driver.
>
> Signed-off-by: Wolfram Sang
> ---
> drivers/spi/spi-bcm63xx.c|8 +---
> drivers/spi/spi-ep93xx.c |8 +---
> drivers/spi/spi-omap2-mcspi.c|7 +--
> drivers/spi/spi-s3c64xx.c|7 +--
> drivers/spi/spi-sirf.c |7 +--
> drivers/spi/spi-tegra114.c |7 +--
> drivers/spi/spi-tegra20-sflash.c |5 -
> drivers/spi/spi-tegra20-slink.c |7 +--
> 8 files changed, 7 insertions(+), 49 deletions(-)
>
[.]
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index 5000586..fd763cc 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -1243,12 +1243,6 @@ static int s3c64xx_spi_probe(struct platform_device
> *pdev)
> return -ENODEV;
> }
>
> - mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (mem_res == NULL) {
> - dev_err(>dev, "Unable to get SPI MEM resource\n");
> - return -ENXIO;
> - }
> -
It breaks 'sdd->sfr_start' assignment as below:
1272 sdd->sfr_start = mem_res->start;
Best regards,
Jingoo Han
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> dev_warn(>dev, "Failed to get IRQ: %d\n", irq);
> @@ -1318,6 +1312,7 @@ static int s3c64xx_spi_probe(struct platform_device
> *pdev)
> /* the spi->mode bits understood by this driver: */
> master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
>
> + mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> sdd->regs = devm_ioremap_resource(>dev, mem_res);
> if (IS_ERR(sdd->regs)) {
> ret = PTR_ERR(sdd->regs);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [ 00/26] 3.4.45-stable review
At Thu, 9 May 2013 15:34:14 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.45 release. > There are 26 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat May 11 22:32:50 UTC 2013. > Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian wheezy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian wheezy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB I reviewed the following patch and it looks good to me. > Chen Gang > kernel/audit_tree.c: tree will leak memory when failure occurs in > audit_trim_trees() Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 09/42] drivers/i2c/busses: don't check resource with devm_ioremap_resource
On Friday, May 10, 2013 5:17 PM, Wolfram Sang wrote:
>
> devm_ioremap_resource does sanity checks on the given resource. No need to
> duplicate this in the driver.
>
> Signed-off-by: Wolfram Sang
> ---
> drivers/i2c/busses/i2c-davinci.c|6 +-
> drivers/i2c/busses/i2c-designware-platdrv.c |6 +-
> drivers/i2c/busses/i2c-imx.c|6 +-
> drivers/i2c/busses/i2c-omap.c |6 +-
> drivers/i2c/busses/i2c-rcar.c |7 +--
> drivers/i2c/busses/i2c-s3c2410.c|5 -
For drivers/i2c/busses/i2c-s3c2410.c
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> drivers/i2c/busses/i2c-sirf.c |6 --
> drivers/i2c/busses/i2c-tegra.c |5 -
> 8 files changed, 5 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-davinci.c
> b/drivers/i2c/busses/i2c-davinci.c
> index cf20e06..2ed3e7b 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -647,11 +647,6 @@ static int davinci_i2c_probe(struct platform_device
> *pdev)
> int r;
>
> /* NOTE: driver uses the static register mapping */
> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!mem) {
> - dev_err(>dev, "no mem resource?\n");
> - return -ENODEV;
> - }
>
> irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> if (!irq) {
> @@ -697,6 +692,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
> return -ENODEV;
> clk_prepare_enable(dev->clk);
>
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> dev->base = devm_ioremap_resource(>dev, mem);
> if (IS_ERR(dev->base)) {
> r = PTR_ERR(dev->base);
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
> b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 8ec9133..6f3c612 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -87,11 +87,6 @@ static int dw_i2c_probe(struct platform_device *pdev)
> int irq, r;
>
> /* NOTE: driver uses the static register mapping */
> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!mem) {
> - dev_err(>dev, "no mem resource?\n");
> - return -EINVAL;
> - }
>
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> @@ -103,6 +98,7 @@ static int dw_i2c_probe(struct platform_device *pdev)
> if (!dev)
> return -ENOMEM;
>
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> dev->base = devm_ioremap_resource(>dev, mem);
> if (IS_ERR(dev->base))
> return PTR_ERR(dev->base);
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 82f20c6..b274ca1 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -500,17 +500,13 @@ static int __init i2c_imx_probe(struct platform_device
> *pdev)
>
> dev_dbg(>dev, "<%s>\n", __func__);
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(>dev, "can't get device resources\n");
> - return -ENOENT;
> - }
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> dev_err(>dev, "can't get irq number\n");
> return -ENOENT;
> }
>
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> base = devm_ioremap_resource(>dev, res);
> if (IS_ERR(base))
> return PTR_ERR(base);
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index e02f9e3..8498ab7 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1085,11 +1085,6 @@ omap_i2c_probe(struct platform_device *pdev)
> u16 minor, major, scheme;
>
> /* NOTE: driver uses the static register mapping */
> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!mem) {
> - dev_err(>dev, "no mem resource?\n");
> - return -ENODEV;
> - }
>
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> @@ -1103,6 +1098,7 @@ omap_i2c_probe(struct platform_device *pdev)
> return -ENOMEM;
> }
>
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> dev->base = devm_ioremap_resource(>dev, mem);
> if (IS_ERR(dev->base))
> return PTR_ERR(dev->base);
> diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
> index 4ba4a95..0fc5858 100644
> --- a/drivers/i2c/busses/i2c-rcar.c
> +++ b/drivers/i2c/busses/i2c-rcar.c
> @@ -623,12 +623,6 @@ static int rcar_i2c_probe(struct platform_device *pdev)
> u32 bus_speed;
> int ret;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(dev, "no mmio resources\n");
> - return -ENODEV;
> -
Re: [ 00/12] 3.0.78-stable review
At Thu, 9 May 2013 15:37:13 -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.0.78 release. > There are 12 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat May 11 22:34:47 UTC 2013. > Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian wheezy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian wheezy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB I reviewed the following patch and it looks good to me. > Chen Gang > kernel/audit_tree.c: tree will leak memory when failure occurs in > audit_trim_trees() Thanks, Satoru -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 39/42] arch/arm/plat-samsung: don't check resource with devm_ioremap_resource
On Friday, May 10, 2013 5:17 PM, Wolfram Sang wrote:
>
> devm_ioremap_resource does sanity checks on the given resource. No need to
> duplicate this in the driver.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> arch/arm/plat-samsung/adc.c |5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
> index ca07cb1..79690f2 100644
> --- a/arch/arm/plat-samsung/adc.c
> +++ b/arch/arm/plat-samsung/adc.c
> @@ -381,11 +381,6 @@ static int s3c_adc_probe(struct platform_device *pdev)
> }
>
> regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!regs) {
> - dev_err(dev, "failed to find registers\n");
> - return -ENXIO;
> - }
> -
> adc->regs = devm_ioremap_resource(dev, regs);
> if (IS_ERR(adc->regs))
> return PTR_ERR(adc->regs);
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: exynos: dts: Fixed vbus-gpios
On Thursday, May 09, 2013 2:37 AM, Doug Anderson wrote:
>
> The 'samsung,vbus-gpio' was submitted before pinmux landed for
> exynos5250 and uses the old-style gpio specifier. Fix the two
> exynos5250 boards that use it.
>
> Signed-off-by: Doug Anderson
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 +-
> arch/arm/boot/dts/exynos5250-snow.dts | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index 26d856b..3e0c792 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -214,7 +214,7 @@
> };
>
> usb@1211 {
> - samsung,vbus-gpio = < 6 1 3 3>;
> + samsung,vbus-gpio = < 6 0>;
> };
>
> dp-controller {
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index bf4744b..d449feb 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -183,7 +183,7 @@
> };
>
> usb@1211 {
> - samsung,vbus-gpio = < 1 1 3 3>;
> + samsung,vbus-gpio = < 1 0>;
> };
>
> fixed-rate-clocks {
> --
> 1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: mmc: bcm281xx SDHCI driver
On 05/08/2013 11:55 PM, Christian Daudt wrote: > Add SDHCI driver for the Broadcom 281xx SoCs. Also > add bindings for it into bcm281xx dts files. > Still missing: > - power managemement > diff --git a/drivers/mmc/host/sdhci-bcm-kona.c > b/drivers/mmc/host/sdhci-bcm-kona.c > + /* > + * Back-to-Back register write needs a delay of 1ms at bootup (min 10uS) > + * Back-to-Back writes to same register needs delay when SD bus clock > + * is very low w.r.t AHB clock, mainly during boot-time and during card > + * insert-removal. > + */ > + udelay(1000); > + sdhci_writel(host, val, KONA_SDHOST_CORECTRL); This sounds very similar to the workaround in drivers/mmc/host/sdhci-bcm2835.c. Is this the same IP block supported by that driver? Perhaps not, since bcm2835 apparently needs other WARs such as always using 32-bit IO and hence needing custom read/write w/b functions to do read-modify-write which isn't here? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -v8 01/11] CPU hotplug: Provide a generic helper to disable/enable CPU hotplug
On Fri, May 10, 2013 at 10:03:24AM -0700, Andrew Morton wrote: > On Fri, 10 May 2013 13:11:51 +0200 "Rafael J. Wysocki" wrote: > > > ... > > > > > cpu_hotplug_disable() doesn't get compiled unless we've defined > > > CONFIG_PM_SLEEP_SMP. I cannot begin to imagine what the logic is > > > behind that! > > > > I suppose it was only used by suspend/hibernate code paths when this was > > introduced. > > OK, well I suspect that what I have now is simply wrong for Robin's > application. Robin, can you please check this? We probably want to > make the does-something version of cpu_hotplug_disable/enable available > if CONFIG_HOTPLUG_CPU. This patch came from "Srivatsa S. Bhat" , I think I need to defer. I spent all day trying to get an alpha cross compiler to build an unmodified kernel and modules, only to find I didn't need to go that far and could reproduce the failure with just building vmlinux. Sorry for my slow response, Robin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] radeon: Allow disabling UVD
On Wed, 8 May 2013, Parag Warudkar wrote: > > > On Wed, 8 May 2013, Christian König wrote: > > > If you want to hack a bit on it you could try commenting out the calls to > > "radeon_set_uvd_clocks" in radeon_uvd.c. That should give you the default > > clocks of 100Mhz, not enough for usable decoding, but on SUMO based UVD > > blocks > > a very failsafe default. Commenting out the two calls to radeon_set_uvd_clocks() did not make any difference - still fails to initialize. BTW, this is also an EFI install. Sounds like for some people BIOS mode works based on the bug report. Also confirming that the suspend/resume issue persists with the SUMO_uvd.bin firmware loaded even if the UVD init fails. It is only by removing the firmware I can get the machine to suspend reliably. Parag
Re: [PATCH 1/7] posix-cpu-timers: don't account cpu timer after stopped thread runtime accounting
On Fri, May 10, 2013 at 8:17 PM, Frederic Weisbecker wrote: > On Mon, May 06, 2013 at 11:16:40PM -0400, Olivier Langlois wrote: >> On Tue, 2013-05-07 at 01:47 +0200, Frederic Weisbecker wrote: >> > On Fri, May 03, 2013 at 12:47:42AM -0400, kosaki.motoh...@gmail.com wrote: >> > > From: KOSAKI Motohiro >> > > >> > > When tsk->signal->cputimer->running is 1, signal->cputimer and >> > > tsk->sum_sched_runtime increase at the same pace because update_curr() >> > > increases both accounting. >> > > >> > > However, there is one exception. When thread exiting, __exit_signal() >> > > turns >> > > over task's sum_shced_runtime to sig->sum_sched_runtime, but it doesn't >> > > stop >> > > signal->cputimer accounting. >> > > >> > > This inconsistency makes POSIX timer wake up too early. This patch fixes >> > > it. >> > > >> > > Cc: Thomas Gleixner >> > > Cc: Frederic Weisbecker >> > > Cc: Ingo Molnar >> > > Acked-by: Peter Zijlstra >> > > Signed-off-by: Olivier Langlois >> > > Signed-off-by: KOSAKI Motohiro >> > > --- >> > > kernel/sched/stats.h |7 +++ >> > > 1 files changed, 7 insertions(+), 0 deletions(-) >> > > >> > > diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h >> > > index 2ef90a5..5a0cfc4 100644 >> > > --- a/kernel/sched/stats.h >> > > +++ b/kernel/sched/stats.h >> > > @@ -225,6 +225,13 @@ static inline void >> > > account_group_exec_runtime(struct task_struct *tsk, >> > > if (!cputimer->running) >> > > return; >> > > >> > > + /* >> > > + * After turning over se.sum_exec_runtime to sig->sum_sched_runtime >> > > + * in __exit_signal(), we must not account exec_runtime for >> > > consistency. >> > > + */ > > Please just precise the nature of that consistency: the fact we want > CLOCK_PROCESS_CPUTIME_ID > clock and timer to be consistent. typo? This patch fixes an inconsistency between a thread cputime and a process cputime. How is this? /* * After turning over se.sum_exec_runtime to sig->sum_sched_runtime * in __exit_signal(), a per-thread cputime of the thread will be lost. We * must not account exec_runtime here too because we need to keep * consistent cputime between per-thread and per-process. Otherwise, * the inconsistency is observable when single thread program run. */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/7] posix-cpu-timers: fix acounting delta_exec twice
>> @@ -250,8 +250,13 @@ void thread_group_cputimer(struct task_struct *tsk, >> struct task_cputime *times) >>* values through the TIMER_ABSTIME flag, therefore we have >>* to synchronize the timer to the clock every time we start >>* it. >> + * >> + * Do not add the current delta, because >> + * account_group_exec_runtime() will also this delta and we >> + * wouldn't want to double account time and get ahead of >> + * ourselves. >>*/ >> - thread_group_cputime(tsk, ); >> + thread_group_cputime(tsk, false, ); >> raw_spin_lock_irqsave(>lock, flags); > > I wonder if we should move thread_group_cputime() inside this lock. > Otherwise we can miss some updates in-between. Hmm.. I don't agree with this. Right, we can miss some updates. But 1) cputimer->lock doesn't prevent any update update_curr() only take rq_lock, and 2) POSIX timer and sleeping semantics allow longer sleep than an argument. Then, the missing is safe, nobody can observe which of the timer_setime() syscall and update_curr() happened earlier. Ah, I'm now finding when update_gt_cputime() effectively work. It helps to avoid timer_settime() vs timer_settime() mess. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] module: Add section ".ref.data" into kmemleak-scan-area.
In commit 523c81135,it used "__refdata" on event_class_ftrace_##call. It will cause kmemleak to misjudge because when loading module it did not add '.ref.data' into kmemleak-scan-area. Signed-off-by: Jianpeng Ma --- kernel/module.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/module.c b/kernel/module.c index b049939..dafe2ea 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -2434,7 +2434,8 @@ static void kmemleak_load_module(const struct module *mod, const char *name = info->secstrings + info->sechdrs[i].sh_name; if (!(info->sechdrs[i].sh_flags & SHF_ALLOC)) continue; - if (!strstarts(name, ".data") && !strstarts(name, ".bss")) + if (!strstarts(name, ".data") && !strstarts(name, ".bss") && + !strstarts(name, ".ref.data")) continue; kmemleak_scan_area((void *)info->sechdrs[i].sh_addr, -- 1.7.10.4 >From 9adf5b9aae7ceb97828042d0ae8fe9fb688bc691 Mon Sep 17 00:00:00 2001 From: Jianpeng Ma Date: Sat, 11 May 2013 10:04:14 +0800 Subject: [PATCH] module: Add section ".ref.data" into kmemleak-scan-area. In commit 523c81135,it used "__refdata" on event_class_ftrace_##call. It will cause kmemleak to misjudge because when loading module it did not add '.ref.data' into kmemleak-scan-area. Signed-off-by: Jianpeng Ma --- kernel/module.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/module.c b/kernel/module.c index b049939..dafe2ea 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -2434,7 +2434,8 @@ static void kmemleak_load_module(const struct module *mod, const char *name = info->secstrings + info->sechdrs[i].sh_name; if (!(info->sechdrs[i].sh_flags & SHF_ALLOC)) continue; - if (!strstarts(name, ".data") && !strstarts(name, ".bss")) + if (!strstarts(name, ".data") && !strstarts(name, ".bss") && + !strstarts(name, ".ref.data")) continue; kmemleak_scan_area((void *)info->sechdrs[i].sh_addr, -- 1.7.10.4
[PATCH -v10 00/11] Shutdown from reboot_cpuid without stopping other cpus.
We recently noticed that reboot of a 1024 cpu machine takes approx 16 minutes of just stopping the cpus. The slowdown was tracked to commit f96972f. The current implementation does all the work of hot removing the cpus before halting the system. We are switching to just migrating to the reboot_cpu and then continuing with shutdown/reboot. The patch set is broken into eleven parts. The first two are planned for the stable release. The others move the halt/shutdown/reboot related functions to their own kernel/reboot.c file and then move the handling of the kernel reboot= kernel parameter to generic kernel code. Changes since -v9 - Added Ingo's Acked-by. Changes since -v8 - Changes reboot_cpu on stack to cpu to fix bug noticed by Russell King. - Switched unicore32 and arm from using REBOOT_WARM/COLD to HARD/SOFT. - Fixed case statement bug. - Went to using simple_strtoul for parsing reboot_cpu=smp###. - Made parsing of reboot= not use any #ifdef'd code. Changes since -v7. - Fixed authorship for first patch. - Rebased to Linus' current tree (51a26ae7a). Changes since -v6. - Cross compiled all arm architectures (using v3.9 kernel. Fails with current). - Added a #define for non-hotplug case. - Add #define for PF_THREAD_BOUND as compatibility to make stable easier. - Fixup s/reboot_cpu_id/reboot_cpu/ - Add include of linux/uaccess.h to allow building on arm. - Removed last remaining checkpatch.pl line length warning on kernel/reboot.c. - Fixed the duplicate handling or the reboot= kernel parameter. Changes since -v5. - Moved the arch/x86 reboot= up to the generic kernel code. Changes since -v4. - Integrated Srivatsa S. Bhat creating cpu_hotplug_disable() function - Integrated comments by Srivatsa S. Bhat. - Made one more comment consistent with others in function. Changes since -v3. - Added a tested-by for the original reporter. - Fix compile failure found by Joe Perches. - Integrated comments by Joe Perches. To: Andrew Morton Cc: H. Peter Anvin Cc: Russ Anderson Cc: Robin Holt Cc: Russell King Cc: Guan Xuetao Cc: Linux Kernel Mailing List Cc: the arch/x86 maintainers Cc: Arm Mailing List -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] x86/sched/context_tracking: Call new schedule_preempt_user() from entry_64.S
On Fri, May 10, 2013 at 05:12:26PM -0400, Steven Rostedt wrote:
> +/*
> + * This is a entry point to the scheduler() just before going
> + * back to user space. This is called with irqs disabled
> + * which prevents races with the CONTEXT_TRACKING updates.
> + */
> +asmlinkage void __sched schedule_preempt_user(void)
> +{
> + enum ctx_state prev_state;
> +
> + prev_state = exception_enter();
> +
> + local_irq_enable();
> + __schedule();
> + local_irq_disable();
> +
> + exception_exit(prev_state);
So since it's only ever called right before resuming to userspace and after
the user_exit() call from the end of the syscall/exception/irq code,
you can use user_enter()/user_exit() directly.
I'm also wondering if this assumption that irqs are disabled by the time
we do user preemption is x86-centric or not. May be we can wait for complains
from those who'll port it...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] NTB bug fixes for v3.10
Hi Linus, Below are a number of NTB bug fixes for v3.10. These correct a few Smatch/Coverity errors, as well as addressing some other issues in the NTB driver. Thanks, Jon The following changes since commit c1be5a5b1b355d40e6cf79cc979eb66dafa24ad1: Linux 3.9 (2013-04-28 17:36:01 -0700) are available in the git repository at: https://github.com/jonmason/ntb.git for-linus for you to fetch changes up to 877b38d4f052a2927a900eb0733ad7d749bd0d00: NTB: Multiple NTB client fix (2013-05-10 14:33:45 -0700) Dan Carpenter (2): ntb: off by one sanity checks NTB: fix pointer math issues Jon Mason (8): NTB: variable dereferenced before check NTB: Handle 64bit BAR sizes NTB: Link toggle memory leak NTB: reset tx_index on link toggle NTB: Correctly handle receive buffers of the minimal size NTB: memcpy lockup workaround ntb_netdev: remove from list on exit NTB: Multiple NTB client fix drivers/net/ntb_netdev.c|2 + drivers/ntb/ntb_hw.c| 10 +-- drivers/ntb/ntb_transport.c | 175 --- 3 files changed, 121 insertions(+), 66 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/sched/dynamic-ticks: Call new schedule_irq_disable() for scheduling in entry_64.S
On Thu, May 09, 2013 at 08:47:09PM -0400, Steven Rostedt wrote: > On Fri, 2013-05-10 at 02:22 +0200, Frederic Weisbecker wrote: > > > > > @@ -654,6 +653,7 @@ sysret_check: > > > LOCKDEP_SYS_EXIT > > > DISABLE_INTERRUPTS(CLBR_NONE) > > > TRACE_IRQS_OFF > > > +sysret_check_irqsoff: > > > movl TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET),%edx > > > andl %edi,%edx > > > jnz sysret_careful > > > @@ -675,12 +675,10 @@ sysret_check: > > > sysret_careful: > > > bt $TIF_NEED_RESCHED,%edx > > > jnc sysret_signal > > > - TRACE_IRQS_ON > > > - ENABLE_INTERRUPTS(CLBR_NONE) > > > pushq_cfi %rdi > > > - SCHEDULE_USER > > > + call schedule_irq_disabled > > > popq_cfi %rdi > > > - jmp sysret_check > > > + jmp sysret_check_irqsoff > > > > Don't we still want to call LOCKDEP_SYS_EXIT?, the previous > > task scheduled might have taken some locks. > > Sure, but would that still catch this? I thought LOCKDEP_SYS_EXIT just > cared about going into user land if the current task had locks. Where it > shouldn't here. And you are concerned about the previous task. Well, the > scheduler should have caught that, as you shouldn't have any spin locks > there. And it doesn't matter if the previous task had a mutex. The > previous task is still in kernel space. Ah you're right. But still the current task had several opportunities to take locks since the context switch. It's still relevant to check that. > > > > > + > > > + local_irq_enable(); > > > + __schedule(); > > > > Are you sure it's fine to call __schedule() instead of schedule()? > > I don't know much about the blk work to handle there but it may be > > worth considering. > > Note, this isn't a call to schedule that was made by normal kernel > space. This is very much like a preemption. In fact, it is a preemption > and my first patch used preempt_schedule_irq() instead, but as that's > made for CONFIG_PREEMPT enabled, it seemed a bit hacky to take that out > of that context. > > This is only called when the task is being preempted. But because its > going to user land, its OK. The blk code there is more worried about > something that did some work, set itself to TASK_UNINTERRUPTIBLE and > then called schedule() (think completions). That is, the blk code that > needs to be submitted will be the code that wakes up this task. > > We should never be in anything but TASK_RUNNING when going into user > space. Ok, I haven't checked the details of what that blk_ thing is doing so, if it really doesn't care about any kind of preemption, that's ok. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: remove compressed copy from zram in-memory
On Fri, May 10, 2013 at 4:44 AM, Minchan Kim wrote: > Hi Konrad, > > On Thu, May 09, 2013 at 04:15:42PM -0400, Konrad Rzeszutek Wilk wrote: >> On Thu, May 09, 2013 at 08:41:57AM +0900, Minchan Kim wrote: >> >> Hey Michan, > ^-n > > It's a only thing I can know better than other native speakers. :) I keep on misspelling your name. I am really sorry about that. > > >> Just a couple of syntax corrections. The code comment could also >> benefit from this. >> >> Otherwise it looks OK to me. >> >> > Swap subsystem does lazy swap slot free with expecting the page >> ^-a ^- the expectation that >> > would be swapped out again so we can avoid unnecessary write. >> ^--that it >> > >> > But the problem in in-memory swap(ex, zram) is that it consumes >> ^^-with >> > memory space until vm_swap_full(ie, used half of all of swap device) >> > condition meet. It could be bad if we use multiple swap device, >>^- 'is' ^ - 'would' ^-devices >> > small in-memory swap and big storage swap or in-memory swap alone. >> ^-, ^-, >> > >> > This patch makes swap subsystem free swap slot as soon as swap-read >> > is completed and make the swapcache page dirty so the page should >>^-makes ^-'that the' >> > be written out the swap device to reclaim it. >> > It means we never lose it. >> > >> > I tested this patch with kernel compile workload. >> ^-a > > Thanks for the correct whole sentence! > But Andrew alreay correted it with his style. I saw his email a couple of hours ago. > Although he was done, I'm giving a million thanks to you. > Surely, Thanks Andrew, too. > > -- > Kind regards, > Minchan Kim > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 03/10] clk: mvebu: add Dove SoC-centric clock init
This is moving core clock and clock gating init for Dove to its own
file and adds a Kconfig option. Also init functions are added and
declared so they get called on of_clk_init.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Russell King
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: Mike Turquette
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/mvebu/Kconfig |4 +
drivers/clk/mvebu/Makefile |2 +
drivers/clk/mvebu/dove.c | 194
3 files changed, 200 insertions(+)
create mode 100644 drivers/clk/mvebu/dove.c
diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index 2c3cf95..bc5f05e 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -9,3 +9,7 @@ config MVEBU_CLK_GATING
config MVEBU_CLK_COMMON
bool
+
+config DOVE_CLK
+ bool
+ select MVEBU_CLK_COMMON
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index 2143230..bfc3078 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -2,3 +2,5 @@ obj-$(CONFIG_MVEBU_CLK_COMMON) += common.o
obj-$(CONFIG_MVEBU_CLK_CORE) += clk.o clk-core.o
obj-$(CONFIG_MVEBU_CLK_CPU)+= clk-cpu.o
obj-$(CONFIG_MVEBU_CLK_GATING) += clk-gating-ctrl.o
+
+obj-$(CONFIG_DOVE_CLK) += dove.o
diff --git a/drivers/clk/mvebu/dove.c b/drivers/clk/mvebu/dove.c
new file mode 100644
index 000..79d7aed
--- /dev/null
+++ b/drivers/clk/mvebu/dove.c
@@ -0,0 +1,194 @@
+/*
+ * Marvell Dove SoC clocks
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Gregory CLEMENT
+ * Sebastian Hesselbarth
+ * Andrew Lunn
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include "common.h"
+
+/*
+ * Core Clocks
+ *
+ * Dove PLL sample-at-reset configuration
+ *
+ * SAR0[8:5] : CPU frequency
+ * 5 = 1000 MHz
+ * 6 = 933 MHz
+ * 7 = 933 MHz
+ * 8 = 800 MHz
+ * 9 = 800 MHz
+ * 10 = 800 MHz
+ * 11 = 1067 MHz
+ * 12 = 667 MHz
+ * 13 = 533 MHz
+ * 14 = 400 MHz
+ * 15 = 333 MHz
+ * others reserved.
+ *
+ * SAR0[11:9] : CPU to L2 Clock divider ratio
+ * 0 = (1/1) * CPU
+ * 2 = (1/2) * CPU
+ * 4 = (1/3) * CPU
+ * 6 = (1/4) * CPU
+ * others reserved.
+ *
+ * SAR0[15:12] : CPU to DDR DRAM Clock divider ratio
+ * 0 = (1/1) * CPU
+ * 2 = (1/2) * CPU
+ * 3 = (2/5) * CPU
+ * 4 = (1/3) * CPU
+ * 6 = (1/4) * CPU
+ * 8 = (1/5) * CPU
+ * 10 = (1/6) * CPU
+ * 12 = (1/7) * CPU
+ * 14 = (1/8) * CPU
+ * 15 = (1/10) * CPU
+ * others reserved.
+ *
+ * SAR0[24:23] : TCLK frequency
+ * 0 = 166 MHz
+ * 1 = 125 MHz
+ * others reserved.
+ */
+
+#define SAR_DOVE_CPU_FREQ 5
+#define SAR_DOVE_CPU_FREQ_MASK 0xf
+#define SAR_DOVE_L2_RATIO 9
+#define SAR_DOVE_L2_RATIO_MASK 0x7
+#define SAR_DOVE_DDR_RATIO 12
+#define SAR_DOVE_DDR_RATIO_MASK0xf
+#define SAR_DOVE_TCLK_FREQ 23
+#define SAR_DOVE_TCLK_FREQ_MASK0x3
+
+enum { DOVE_CPU_TO_L2, DOVE_CPU_TO_DDR };
+
+static const struct coreclk_ratio __initconst dove_coreclk_ratios[] = {
+ { .id = DOVE_CPU_TO_L2, .name = "l2clk", },
+ { .id = DOVE_CPU_TO_DDR, .name = "ddrclk", }
+};
+
+static const u32 __initconst dove_tclk_freqs[] = {
+ 16667,
+ 12500,
+ 0, 0
+};
+
+static u32 __init dove_get_tclk_freq(void __iomem *sar)
+{
+ u32 opt = (readl(sar) >> SAR_DOVE_TCLK_FREQ) &
+ SAR_DOVE_TCLK_FREQ_MASK;
+ return dove_tclk_freqs[opt];
+}
+
+static const u32 __initconst dove_cpu_freqs[] = {
+ 0, 0, 0, 0, 0,
+ 10,
+ 9, 9,
+ 8, 8, 8,
+ 106667,
+ 7,
+ 5,
+ 4,
+ 3
+};
+
+static u32 __init dove_get_cpu_freq(void __iomem *sar)
+{
+ u32 opt = (readl(sar) >> SAR_DOVE_CPU_FREQ) &
+ SAR_DOVE_CPU_FREQ_MASK;
+ return dove_cpu_freqs[opt];
+}
+
+static const int __initconst dove_cpu_l2_ratios[8][2] = {
+ { 1, 1 }, { 0, 1 }, { 1, 2 }, { 0, 1 },
+ { 1, 3 }, { 0, 1 }, { 1, 4 }, { 0, 1 }
+};
+
+static const int __initconst dove_cpu_ddr_ratios[16][2] = {
+ { 1, 1 }, { 0, 1 }, { 1, 2 }, { 2, 5 },
+ { 1, 3 }, { 0, 1 }, { 1, 4 }, { 0, 1 },
+ { 1, 5 }, { 0, 1 }, { 1, 6 }, { 0, 1 },
+ { 1, 7 }, { 0, 1 }, { 1, 8 }, { 1, 10 }
[PATCH 04/10] clk: mvebu: add Kirkwood SoC-centric clock init
This is moving core clock and clock gating init for Kirkwood to its
own file and adds a Kconfig option. Also init functions are added and
declared so they get called on of_clk_init.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Russell King
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: Mike Turquette
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/mvebu/Kconfig|4 +
drivers/clk/mvebu/Makefile |1 +
drivers/clk/mvebu/kirkwood.c | 247 ++
3 files changed, 252 insertions(+)
create mode 100644 drivers/clk/mvebu/kirkwood.c
diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index bc5f05e..211695c 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -13,3 +13,7 @@ config MVEBU_CLK_COMMON
config DOVE_CLK
bool
select MVEBU_CLK_COMMON
+
+config KIRKWOOD_CLK
+ bool
+ select MVEBU_CLK_COMMON
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index bfc3078..97d1ab0 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_MVEBU_CLK_CPU) += clk-cpu.o
obj-$(CONFIG_MVEBU_CLK_GATING) += clk-gating-ctrl.o
obj-$(CONFIG_DOVE_CLK) += dove.o
+obj-$(CONFIG_KIRKWOOD_CLK) += kirkwood.o
diff --git a/drivers/clk/mvebu/kirkwood.c b/drivers/clk/mvebu/kirkwood.c
new file mode 100644
index 000..71d2461
--- /dev/null
+++ b/drivers/clk/mvebu/kirkwood.c
@@ -0,0 +1,247 @@
+/*
+ * Marvell Kirkwood SoC clocks
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Gregory CLEMENT
+ * Sebastian Hesselbarth
+ * Andrew Lunn
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include "common.h"
+
+/*
+ * Core Clocks
+ *
+ * Kirkwood PLL sample-at-reset configuration
+ * (6180 has different SAR layout than other Kirkwood SoCs)
+ *
+ * SAR0[4:3,22,1] : CPU frequency (6281,6292,6282)
+ * 4 = 600 MHz
+ * 6 = 800 MHz
+ * 7 = 1000 MHz
+ * 9 = 1200 MHz
+ * 12 = 1500 MHz
+ * 13 = 1600 MHz
+ * 14 = 1800 MHz
+ * 15 = 2000 MHz
+ * others reserved.
+ *
+ * SAR0[19,10:9] : CPU to L2 Clock divider ratio (6281,6292,6282)
+ * 1 = (1/2) * CPU
+ * 3 = (1/3) * CPU
+ * 5 = (1/4) * CPU
+ * others reserved.
+ *
+ * SAR0[8:5] : CPU to DDR DRAM Clock divider ratio (6281,6292,6282)
+ * 2 = (1/2) * CPU
+ * 4 = (1/3) * CPU
+ * 6 = (1/4) * CPU
+ * 7 = (2/9) * CPU
+ * 8 = (1/5) * CPU
+ * 9 = (1/6) * CPU
+ * others reserved.
+ *
+ * SAR0[4:2] : Kirkwood 6180 cpu/l2/ddr clock configuration (6180 only)
+ * 5 = [CPU = 600 MHz, L2 = (1/2) * CPU, DDR = 200 MHz = (1/3) * CPU]
+ * 6 = [CPU = 800 MHz, L2 = (1/2) * CPU, DDR = 200 MHz = (1/4) * CPU]
+ * 7 = [CPU = 1000 MHz, L2 = (1/2) * CPU, DDR = 200 MHz = (1/5) * CPU]
+ * others reserved.
+ *
+ * SAR0[21] : TCLK frequency
+ * 0 = 200 MHz
+ * 1 = 166 MHz
+ * others reserved.
+ */
+
+#define SAR_KIRKWOOD_CPU_FREQ(x) \
+ (((x & (1 << 1)) >> 1) | \
+((x & (1 << 22)) >> 21) | \
+((x & (3 << 3)) >> 1))
+#define SAR_KIRKWOOD_L2_RATIO(x) \
+ (((x & (3 << 9)) >> 9) | \
+(((x & (1 << 19)) >> 17)))
+#define SAR_KIRKWOOD_DDR_RATIO 5
+#define SAR_KIRKWOOD_DDR_RATIO_MASK0xf
+#define SAR_MV88F6180_CLK 2
+#define SAR_MV88F6180_CLK_MASK 0x7
+#define SAR_KIRKWOOD_TCLK_FREQ 21
+#define SAR_KIRKWOOD_TCLK_FREQ_MASK0x1
+
+enum { KIRKWOOD_CPU_TO_L2, KIRKWOOD_CPU_TO_DDR };
+
+static const struct coreclk_ratio __initconst kirkwood_coreclk_ratios[] = {
+ { .id = KIRKWOOD_CPU_TO_L2, .name = "l2clk", },
+ { .id = KIRKWOOD_CPU_TO_DDR, .name = "ddrclk", }
+};
+
+static u32 __init kirkwood_get_tclk_freq(void __iomem *sar)
+{
+ u32 opt = (readl(sar) >> SAR_KIRKWOOD_TCLK_FREQ) &
+ SAR_KIRKWOOD_TCLK_FREQ_MASK;
+ return (opt) ? 16667 : 2;
+}
+
+static const u32 __initconst kirkwood_cpu_freqs[] = {
+ 0, 0, 0, 0,
+ 6,
+ 0,
+ 8,
+ 10,
+ 0,
+ 12,
+ 0, 0,
+ 15,
+ 16,
+ 18,
+ 20
+};
+
+static u32 __init kirkwood_get_cpu_freq(void __iomem *sar)
+{
+ u32 opt = SAR_KIRKWOOD_CPU_FREQ(readl(sar));
+ return kirkwood_cpu_freqs[opt];
+}
+
+static const int __initconst kirkwood_cpu_l2_ratios[8][2] = {
+ { 0, 1 }, { 1, 2 }, { 0, 1 }, { 1, 3 },
+ { 0, 1 }, { 1, 4 }, { 0, 1 }, { 0, 1 }
+};
+
+static const int __initconst kirkwood_cpu_ddr_ratios[16][2] = {
+ { 0, 1 }, { 0, 1 }, { 1, 2 }, { 0, 1 },
+ { 1, 3 }, { 0, 1 }, { 1, 4 }, { 2, 9 },
+ { 1, 5 }, { 1, 6 },
[PATCH 01/10] clk: mvebu: introduce per-clock-gate flags
Clock gates found on MVEBU SoCs get registered by a common function.
To allow specific SoCs to provide tweaks introduce flags to the clock
gate descriptor instead of filling up the common function SoC specific
tweaks.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Russell King
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: Mike Turquette
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/mvebu/clk-gating-ctrl.c | 153 +--
1 file changed, 72 insertions(+), 81 deletions(-)
diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c
b/drivers/clk/mvebu/clk-gating-ctrl.c
index ebf141d..a88e09b 100644
--- a/drivers/clk/mvebu/clk-gating-ctrl.c
+++ b/drivers/clk/mvebu/clk-gating-ctrl.c
@@ -28,6 +28,7 @@ struct mvebu_soc_descr {
const char *name;
const char *parent;
int bit_idx;
+ unsigned long flags;
};
#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, hw)
@@ -88,21 +89,11 @@ static void __init mvebu_clk_gating_setup(
}
for (n = 0; n < ctrl->num_gates; n++) {
- u8 flags = 0;
const char *parent =
(descr[n].parent) ? descr[n].parent : default_parent;
-
- /*
-* On Armada 370, the DDR clock is a special case: it
-* isn't taken by any driver, but should anyway be
-* kept enabled, so we mark it as IGNORE_UNUSED for
-* now.
-*/
- if (!strcmp(descr[n].name, "ddr"))
- flags |= CLK_IGNORE_UNUSED;
-
ctrl->gates[n] = clk_register_gate(NULL, descr[n].name, parent,
- flags, base, descr[n].bit_idx, 0,
>lock);
+ descr[n].flags, base, descr[n].bit_idx,
+ 0, >lock);
WARN_ON(IS_ERR(ctrl->gates[n]));
}
of_clk_add_provider(np, mvebu_clk_gating_get_src, ctrl);
@@ -114,93 +105,93 @@ static void __init mvebu_clk_gating_setup(
#ifdef CONFIG_MACH_ARMADA_370
static const struct mvebu_soc_descr __initconst armada_370_gating_descr[] = {
- { "audio", NULL, 0 },
- { "pex0_en", NULL, 1 },
- { "pex1_en", NULL, 2 },
- { "ge1", NULL, 3 },
- { "ge0", NULL, 4 },
- { "pex0", NULL, 5 },
- { "pex1", NULL, 9 },
- { "sata0", NULL, 15 },
- { "sdio", NULL, 17 },
- { "tdm", NULL, 25 },
- { "ddr", NULL, 28 },
- { "sata1", NULL, 30 },
+ { "audio", NULL, 0, 0 },
+ { "pex0_en", NULL, 1, 0 },
+ { "pex1_en", NULL, 2, 0 },
+ { "ge1", NULL, 3, 0 },
+ { "ge0", NULL, 4, 0 },
+ { "pex0", NULL, 5, 0 },
+ { "pex1", NULL, 9, 0 },
+ { "sata0", NULL, 15, 0 },
+ { "sdio", NULL, 17, 0 },
+ { "tdm", NULL, 25, 0 },
+ { "ddr", NULL, 28, CLK_IGNORE_UNUSED },
+ { "sata1", NULL, 30, 0 },
{ }
};
#endif
#ifdef CONFIG_MACH_ARMADA_XP
static const struct mvebu_soc_descr __initconst armada_xp_gating_descr[] = {
- { "audio", NULL, 0 },
- { "ge3", NULL, 1 },
- { "ge2", NULL, 2 },
- { "ge1", NULL, 3 },
- { "ge0", NULL, 4 },
- { "pex0", NULL, 5 },
- { "pex1", NULL, 6 },
- { "pex2", NULL, 7 },
- { "pex3", NULL, 8 },
- { "bp", NULL, 13 },
- { "sata0lnk", NULL, 14 },
- { "sata0", "sata0lnk", 15 },
- { "lcd", NULL, 16 },
- { "sdio", NULL, 17 },
- { "usb0", NULL, 18 },
- { "usb1", NULL, 19 },
- { "usb2", NULL, 20 },
- { "xor0", NULL, 22 },
- { "crypto", NULL, 23 },
- { "tdm", NULL, 25 },
- { "xor1", NULL, 28 },
- { "sata1lnk", NULL, 29 },
- { "sata1", "sata1lnk", 30 },
+ { "audio", NULL, 0, 0 },
+ { "ge3", NULL, 1, 0 },
+ { "ge2", NULL, 2, 0 },
+ { "ge1", NULL, 3, 0 },
+ { "ge0", NULL, 4, 0 },
+ { "pex0", NULL, 5, 0 },
+ { "pex1", NULL, 6, 0 },
+ { "pex2", NULL, 7, 0 },
+ { "pex3", NULL, 8, 0 },
+ { "bp", NULL, 13, 0 },
+ { "sata0lnk", NULL, 14, 0 },
+ { "sata0", "sata0lnk", 15, 0 },
+ { "lcd", NULL, 16, 0 },
+ { "sdio", NULL, 17, 0 },
+ { "usb0", NULL, 18, 0 },
+ { "usb1", NULL, 19, 0 },
+ { "usb2", NULL, 20, 0 },
+ { "xor0", NULL, 22, 0 },
+ { "crypto", NULL, 23, 0 },
+ { "tdm", NULL, 25, 0 },
+ { "xor1", NULL, 28, 0 },
+ { "sata1lnk", NULL, 29, 0 },
+ { "sata1", "sata1lnk", 30, 0 },
{ }
};
#endif
#ifdef CONFIG_ARCH_DOVE
static const struct mvebu_soc_descr __initconst dove_gating_descr[] = {
- { "usb0", NULL, 0 },
- { "usb1", NULL, 1 },
- { "ge", "gephy", 2 },
- { "sata", NULL, 3 },
- { "pex0", NULL, 4 },
- { "pex1", NULL, 5 },
- { "sdio0", NULL, 8 },
- { "sdio1", NULL, 9 },
- { "nand", NULL, 10
[PATCH 06/10] clk: mvebu: add Armada XP SoC-centric clock init
This is moving core clock and clock gating init for Armada XP to
its own file and adds a Kconfig option. Also init functions are added
and declared so they get called on of_clk_init.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Russell King
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: Mike Turquette
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/mvebu/Kconfig |5 +
drivers/clk/mvebu/Makefile|1 +
drivers/clk/mvebu/armada-xp.c | 204 +
3 files changed, 210 insertions(+)
create mode 100644 drivers/clk/mvebu/armada-xp.c
diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index 1daf61e..8740d34 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -15,6 +15,11 @@ config ARMADA_370_CLK
select MVEBU_CLK_COMMON
select MVEBU_CLK_CPU
+config ARMADA_XP_CLK
+ bool
+ select MVEBU_CLK_COMMON
+ select MVEBU_CLK_CPU
+
config DOVE_CLK
bool
select MVEBU_CLK_COMMON
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index 367b72c..13f3d22 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -4,5 +4,6 @@ obj-$(CONFIG_MVEBU_CLK_CPU) += clk-cpu.o
obj-$(CONFIG_MVEBU_CLK_GATING) += clk-gating-ctrl.o
obj-$(CONFIG_ARMADA_370_CLK) += armada-370.o
+obj-$(CONFIG_ARMADA_XP_CLK)+= armada-xp.o
obj-$(CONFIG_DOVE_CLK) += dove.o
obj-$(CONFIG_KIRKWOOD_CLK) += kirkwood.o
diff --git a/drivers/clk/mvebu/armada-xp.c b/drivers/clk/mvebu/armada-xp.c
new file mode 100644
index 000..cf7612e
--- /dev/null
+++ b/drivers/clk/mvebu/armada-xp.c
@@ -0,0 +1,204 @@
+/*
+ * Marvell Armada XP SoC clocks
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Gregory CLEMENT
+ * Sebastian Hesselbarth
+ * Andrew Lunn
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include "common.h"
+
+/*
+ * Core Clocks
+ *
+ * Armada XP Sample At Reset is a 64 bit bitfiled split in two
+ * register of 32 bits
+ */
+
+#define SARL 0 /* Low part [0:31] */
+#define SARL_AXP_PCLK_FREQ_OPT 21
+#define SARL_AXP_PCLK_FREQ_OPT_MASK0x7
+#define SARL_AXP_FAB_FREQ_OPT 24
+#define SARL_AXP_FAB_FREQ_OPT_MASK 0xF
+#define SARH 4 /* High part [32:63] */
+#define SARH_AXP_PCLK_FREQ_OPT (52-32)
+#define SARH_AXP_PCLK_FREQ_OPT_MASK0x1
+#define SARH_AXP_PCLK_FREQ_OPT_SHIFT 3
+#define SARH_AXP_FAB_FREQ_OPT (51-32)
+#define SARH_AXP_FAB_FREQ_OPT_MASK 0x1
+#define SARH_AXP_FAB_FREQ_OPT_SHIFT4
+
+enum { AXP_CPU_TO_NBCLK, AXP_CPU_TO_HCLK, AXP_CPU_TO_DRAMCLK };
+
+static const struct coreclk_ratio __initconst axp_coreclk_ratios[] = {
+ { .id = AXP_CPU_TO_NBCLK, .name = "nbclk" },
+ { .id = AXP_CPU_TO_HCLK, .name = "hclk" },
+ { .id = AXP_CPU_TO_DRAMCLK, .name = "dramclk" },
+};
+
+/* Armada XP TCLK frequency is fixed to 250MHz */
+static u32 __init axp_get_tclk_freq(void __iomem *sar)
+{
+ return 25000;
+}
+
+static const u32 __initconst axp_cpu_freqs[] = {
+ 10,
+ 106600,
+ 12,
+ 133300,
+ 15,
+ 166600,
+ 18,
+ 20,
+ 66700,
+ 0,
+ 8,
+ 16,
+};
+
+static u32 __init axp_get_cpu_freq(void __iomem *sar)
+{
+ u32 cpu_freq;
+ u8 cpu_freq_select = 0;
+
+ cpu_freq_select = ((readl(sar + SARL) >> SARL_AXP_PCLK_FREQ_OPT) &
+ SARL_AXP_PCLK_FREQ_OPT_MASK);
+ /*
+* The upper bit is not contiguous to the other ones and
+* located in the high part of the SAR registers
+*/
+ cpu_freq_select |= (((readl(sar + SARH) >> SARH_AXP_PCLK_FREQ_OPT) &
+SARH_AXP_PCLK_FREQ_OPT_MASK) << SARH_AXP_PCLK_FREQ_OPT_SHIFT);
+ if (cpu_freq_select >= ARRAY_SIZE(axp_cpu_freqs)) {
+ pr_err("CPU freq select unsupported: %d\n", cpu_freq_select);
+ cpu_freq = 0;
+ } else
+ cpu_freq = axp_cpu_freqs[cpu_freq_select];
+
+ return cpu_freq;
+}
+
+static const int __initconst axp_nbclk_ratios[32][2] = {
+ {0, 1}, {1, 2}, {2, 2}, {2, 2},
+ {1, 2}, {1, 2}, {1, 1}, {2, 3},
+ {0, 1}, {1, 2}, {2, 4}, {0, 1},
+ {1, 2}, {0, 1}, {0, 1}, {2, 2},
+ {0, 1}, {0, 1}, {0, 1}, {1, 1},
+ {2, 3}, {0, 1}, {0, 1}, {0, 1},
+ {0, 1}, {0, 1}, {0, 1}, {1, 1},
+ {0, 1}, {0, 1}, {0, 1}, {0, 1},
+};
+
+static const int __initconst axp_hclk_ratios[32][2] = {
+ {0, 1}, {1, 2}, {2, 6}, {2, 3},
+ {1, 3}, {1,
[PATCH 10/10] clk: mvebu: desintegrate obsolete file
Switch from function-centric to soc-centric clock drivers now makes
a bunch of files obsolete. This deletes all files and Kconfig options
that are not required anymore.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Russell King
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: Mike Turquette
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/mvebu/Kconfig | 10 +-
drivers/clk/mvebu/Makefile |2 -
drivers/clk/mvebu/clk-core.c| 675 ---
drivers/clk/mvebu/clk-core.h| 18 -
drivers/clk/mvebu/clk-gating-ctrl.c | 241 -
drivers/clk/mvebu/clk-gating-ctrl.h | 22 --
drivers/clk/mvebu/clk.c | 23 --
include/linux/clk/mvebu.h | 22 --
8 files changed, 2 insertions(+), 1011 deletions(-)
delete mode 100644 drivers/clk/mvebu/clk-core.c
delete mode 100644 drivers/clk/mvebu/clk-core.h
delete mode 100644 drivers/clk/mvebu/clk-gating-ctrl.c
delete mode 100644 drivers/clk/mvebu/clk-gating-ctrl.h
delete mode 100644 drivers/clk/mvebu/clk.c
delete mode 100644 include/linux/clk/mvebu.h
diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index 8740d34..0b0f3e7 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -1,13 +1,7 @@
-config MVEBU_CLK_CORE
- bool
+config MVEBU_CLK_COMMON
+ bool
config MVEBU_CLK_CPU
- bool
-
-config MVEBU_CLK_GATING
- bool
-
-config MVEBU_CLK_COMMON
bool
config ARMADA_370_CLK
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index 13f3d22..1c7e70c 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -1,7 +1,5 @@
obj-$(CONFIG_MVEBU_CLK_COMMON) += common.o
-obj-$(CONFIG_MVEBU_CLK_CORE) += clk.o clk-core.o
obj-$(CONFIG_MVEBU_CLK_CPU)+= clk-cpu.o
-obj-$(CONFIG_MVEBU_CLK_GATING) += clk-gating-ctrl.o
obj-$(CONFIG_ARMADA_370_CLK) += armada-370.o
obj-$(CONFIG_ARMADA_XP_CLK)+= armada-xp.o
diff --git a/drivers/clk/mvebu/clk-core.c b/drivers/clk/mvebu/clk-core.c
deleted file mode 100644
index 0a53edb..000
--- a/drivers/clk/mvebu/clk-core.c
+++ /dev/null
@@ -1,675 +0,0 @@
-/*
- * Marvell EBU clock core handling defined at reset
- *
- * Copyright (C) 2012 Marvell
- *
- * Gregory CLEMENT
- * Sebastian Hesselbarth
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "clk-core.h"
-
-struct core_ratio {
- int id;
- const char *name;
-};
-
-struct core_clocks {
- u32 (*get_tclk_freq)(void __iomem *sar);
- u32 (*get_cpu_freq)(void __iomem *sar);
- void (*get_clk_ratio)(void __iomem *sar, int id, int *mult, int *div);
- const struct core_ratio *ratios;
- int num_ratios;
-};
-
-static struct clk_onecell_data clk_data;
-
-static void __init mvebu_clk_core_setup(struct device_node *np,
-struct core_clocks *coreclk)
-{
- const char *tclk_name = "tclk";
- const char *cpuclk_name = "cpuclk";
- void __iomem *base;
- unsigned long rate;
- int n;
-
- base = of_iomap(np, 0);
- if (WARN_ON(!base))
- return;
-
- /*
-* Allocate struct for TCLK, cpu clk, and core ratio clocks
-*/
- clk_data.clk_num = 2 + coreclk->num_ratios;
- clk_data.clks = kzalloc(clk_data.clk_num * sizeof(struct clk *),
- GFP_KERNEL);
- if (WARN_ON(!clk_data.clks))
- return;
-
- /*
-* Register TCLK
-*/
- of_property_read_string_index(np, "clock-output-names", 0,
- _name);
- rate = coreclk->get_tclk_freq(base);
- clk_data.clks[0] = clk_register_fixed_rate(NULL, tclk_name, NULL,
- CLK_IS_ROOT, rate);
- WARN_ON(IS_ERR(clk_data.clks[0]));
-
- /*
-* Register CPU clock
-*/
- of_property_read_string_index(np, "clock-output-names", 1,
- _name);
- rate = coreclk->get_cpu_freq(base);
- clk_data.clks[1] = clk_register_fixed_rate(NULL, cpuclk_name, NULL,
- CLK_IS_ROOT, rate);
- WARN_ON(IS_ERR(clk_data.clks[1]));
-
- /*
-* Register fixed-factor clocks derived from CPU clock
-*/
- for (n = 0; n < coreclk->num_ratios; n++) {
- const char *rclk_name = coreclk->ratios[n].name;
- int mult, div;
-
- of_property_read_string_index(np, "clock-output-names",
- 2+n, _name);
- coreclk->get_clk_ratio(base, coreclk->ratios[n].id,
[PATCH 07/10] ARM: dove: move DT boards to SoC-centric clock init
SoC centric clock init for Dove can be used by calling of_clk_init.
Use it and get rid of mvebu_clocks_init.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Russell King
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: Mike Turquette
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/mach-dove/Kconfig|3 +--
arch/arm/mach-dove/board-dt.c |3 +--
arch/arm/mach-dove/common.c |1 -
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
index 36469d8..dff7b2f 100644
--- a/arch/arm/mach-dove/Kconfig
+++ b/arch/arm/mach-dove/Kconfig
@@ -22,8 +22,7 @@ config MACH_CM_A510
config MACH_DOVE_DT
bool "Marvell Dove Flattened Device Tree"
- select MVEBU_CLK_CORE
- select MVEBU_CLK_GATING
+ select DOVE_CLK
select REGULATOR
select REGULATOR_FIXED_VOLTAGE
select USE_OF
diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-dove/board-dt.c
index 0b14280..f3755ac 100644
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach-dove/board-dt.c
@@ -10,7 +10,6 @@
#include
#include
-#include
#include
#include
#include
@@ -49,7 +48,7 @@ static void __init dove_legacy_clk_init(void)
static void __init dove_of_clk_init(void)
{
- mvebu_clocks_init();
+ of_clk_init(NULL);
dove_legacy_clk_init();
}
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index e2b5da0..2a9443d 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -9,7 +9,6 @@
*/
#include
-#include
#include
#include
#include
--
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 09/10] ARM: mvebu: move DT boards to SoC-centric clock init
SoC centric clock init for Armada 370/XP can be used by calling of_clk_init.
Use it and get rid of mvebu_clocks_init.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Russell King
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: Mike Turquette
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/mach-mvebu/Kconfig |5 ++---
arch/arm/mach-mvebu/armada-370-xp.c |4 ++--
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index e11acbb..6512837 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -10,9 +10,6 @@ config ARCH_MVEBU
select PLAT_ORION
select SPARSE_IRQ
select CLKDEV_LOOKUP
- select MVEBU_CLK_CORE
- select MVEBU_CLK_CPU
- select MVEBU_CLK_GATING
select MVEBU_MBUS
select ZONE_DMA if ARM_LPAE
@@ -29,6 +26,7 @@ config MACH_ARMADA_370_XP
config MACH_ARMADA_370
bool "Marvell Armada 370 boards"
+ select ARMADA_370_CLK
select MACH_ARMADA_370_XP
select PINCTRL_ARMADA_370
help
@@ -37,6 +35,7 @@ config MACH_ARMADA_370
config MACH_ARMADA_XP
bool "Marvell Armada XP boards"
+ select ARMADA_XP_CLK
select MACH_ARMADA_370_XP
select PINCTRL_ARMADA_XP
help
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c
b/arch/arm/mach-mvebu/armada-370-xp.c
index 42a4cb3..1d018e4 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -14,10 +14,10 @@
#include
#include
+#include
#include
#include
#include
-#include
#include
#include
#include
@@ -45,7 +45,7 @@ void __init armada_370_xp_map_io(void)
void __init armada_370_xp_timer_and_clk_init(void)
{
- mvebu_clocks_init();
+ of_clk_init(NULL);
armada_370_xp_timer_init();
}
--
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 08/10] ARM: kirkwood: move DT boards to SoC-centric clock init
SoC centric clock init for Kirkwood can be used by calling of_clk_init.
Use it and get rid of mvebu_clocks_init.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Russell King
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: Mike Turquette
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/mach-kirkwood/Kconfig|3 +--
arch/arm/mach-kirkwood/board-dt.c |3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 7509a89..79ee9f2 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -134,13 +134,12 @@ comment "Device tree entries"
config ARCH_KIRKWOOD_DT
bool "Marvell Kirkwood Flattened Device Tree"
+ select KIRKWOOD_CLK
select POWER_SUPPLY
select POWER_RESET
select POWER_RESET_GPIO
select REGULATOR
select REGULATOR_FIXED_VOLTAGE
- select MVEBU_CLK_CORE
- select MVEBU_CLK_GATING
select USE_OF
help
Say 'Y' here if you want your kernel to support the
diff --git a/arch/arm/mach-kirkwood/board-dt.c
b/arch/arm/mach-kirkwood/board-dt.c
index e9647b8..2f695e5 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -15,7 +15,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -77,7 +76,7 @@ static void __init kirkwood_legacy_clk_init(void)
static void __init kirkwood_of_clk_init(void)
{
- mvebu_clocks_init();
+ of_clk_init(NULL);
kirkwood_legacy_clk_init();
}
--
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 05/10] clk: mvebu: add Armada 370 SoC-centric clock init
This is moving core clock and clock gating init for Armada 370 to
its own file and adds a Kconfig option. Also init functions are added
and declared so they get called on of_clk_init.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Russell King
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: Mike Turquette
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/mvebu/Kconfig |5 ++
drivers/clk/mvebu/Makefile |1 +
drivers/clk/mvebu/armada-370.c | 176
3 files changed, 182 insertions(+)
create mode 100644 drivers/clk/mvebu/armada-370.c
diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index 211695c..1daf61e 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -10,6 +10,11 @@ config MVEBU_CLK_GATING
config MVEBU_CLK_COMMON
bool
+config ARMADA_370_CLK
+ bool
+ select MVEBU_CLK_COMMON
+ select MVEBU_CLK_CPU
+
config DOVE_CLK
bool
select MVEBU_CLK_COMMON
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index 97d1ab0..367b72c 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -3,5 +3,6 @@ obj-$(CONFIG_MVEBU_CLK_CORE)+= clk.o clk-core.o
obj-$(CONFIG_MVEBU_CLK_CPU)+= clk-cpu.o
obj-$(CONFIG_MVEBU_CLK_GATING) += clk-gating-ctrl.o
+obj-$(CONFIG_ARMADA_370_CLK) += armada-370.o
obj-$(CONFIG_DOVE_CLK) += dove.o
obj-$(CONFIG_KIRKWOOD_CLK) += kirkwood.o
diff --git a/drivers/clk/mvebu/armada-370.c b/drivers/clk/mvebu/armada-370.c
new file mode 100644
index 000..3c11550
--- /dev/null
+++ b/drivers/clk/mvebu/armada-370.c
@@ -0,0 +1,176 @@
+/*
+ * Marvell Armada 370 SoC clocks
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Gregory CLEMENT
+ * Sebastian Hesselbarth
+ * Andrew Lunn
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include "common.h"
+
+/*
+ * Core Clocks
+ */
+
+#define SARL 0 /* Low part [0:31] */
+#define SARL_A370_PCLK_FREQ_OPT11
+#define SARL_A370_PCLK_FREQ_OPT_MASK 0xF
+#define SARL_A370_FAB_FREQ_OPT 15
+#define SARL_A370_FAB_FREQ_OPT_MASK0x1F
+#define SARL_A370_TCLK_FREQ_OPT20
+#define SARL_A370_TCLK_FREQ_OPT_MASK 0x1
+
+enum { A370_CPU_TO_NBCLK, A370_CPU_TO_HCLK, A370_CPU_TO_DRAMCLK };
+
+static const struct coreclk_ratio __initconst a370_coreclk_ratios[] = {
+ { .id = A370_CPU_TO_NBCLK, .name = "nbclk" },
+ { .id = A370_CPU_TO_HCLK, .name = "hclk" },
+ { .id = A370_CPU_TO_DRAMCLK, .name = "dramclk" },
+};
+
+static const u32 __initconst a370_tclk_freqs[] = {
+ 1660,
+ 2000,
+};
+
+static u32 __init a370_get_tclk_freq(void __iomem *sar)
+{
+ u8 tclk_freq_select = 0;
+
+ tclk_freq_select = ((readl(sar) >> SARL_A370_TCLK_FREQ_OPT) &
+ SARL_A370_TCLK_FREQ_OPT_MASK);
+ return a370_tclk_freqs[tclk_freq_select];
+}
+
+static const u32 __initconst a370_cpu_freqs[] = {
+ 4,
+ 53300,
+ 66700,
+ 8,
+ 10,
+ 106700,
+ 12,
+};
+
+static u32 __init a370_get_cpu_freq(void __iomem *sar)
+{
+ u32 cpu_freq;
+ u8 cpu_freq_select = 0;
+
+ cpu_freq_select = ((readl(sar) >> SARL_A370_PCLK_FREQ_OPT) &
+ SARL_A370_PCLK_FREQ_OPT_MASK);
+ if (cpu_freq_select >= ARRAY_SIZE(a370_cpu_freqs)) {
+ pr_err("CPU freq select unsupported %d\n", cpu_freq_select);
+ cpu_freq = 0;
+ } else
+ cpu_freq = a370_cpu_freqs[cpu_freq_select];
+
+ return cpu_freq;
+}
+
+static const int __initconst a370_nbclk_ratios[32][2] = {
+ {0, 1}, {1, 2}, {2, 2}, {2, 2},
+ {1, 2}, {1, 2}, {1, 1}, {2, 3},
+ {0, 1}, {1, 2}, {2, 4}, {0, 1},
+ {1, 2}, {0, 1}, {0, 1}, {2, 2},
+ {0, 1}, {0, 1}, {0, 1}, {1, 1},
+ {2, 3}, {0, 1}, {0, 1}, {0, 1},
+ {0, 1}, {0, 1}, {0, 1}, {1, 1},
+ {0, 1}, {0, 1}, {0, 1}, {0, 1},
+};
+
+static const int __initconst a370_hclk_ratios[32][2] = {
+ {0, 1}, {1, 2}, {2, 6}, {2, 3},
+ {1, 3}, {1, 4}, {1, 2}, {2, 6},
+ {0, 1}, {1, 6}, {2, 10}, {0, 1},
+ {1, 4}, {0, 1}, {0, 1}, {2, 5},
+ {0, 1}, {0, 1}, {0, 1}, {1, 2},
+ {2, 6}, {0, 1}, {0, 1}, {0, 1},
+ {0, 1}, {0, 1}, {0, 1}, {1, 1},
+ {0, 1}, {0, 1}, {0, 1}, {0, 1},
+};
+
+static const int __initconst a370_dramclk_ratios[32][2] = {
+ {0, 1}, {1, 2}, {2, 3}, {2, 3},
+ {1, 3}, {1, 2}, {1, 2}, {2, 6},
+ {0, 1}, {1, 3}, {2, 5}, {0, 1},
+ {1, 4}, {0, 1}, {0, 1}, {2, 5},
+ {0, 1}, {0, 1}, {0, 1}, {1, 1},
+
[PATCH 00/10] clk: mvebu: restructure SoC clock drivers
Marvell EBU SoCs share some common clock functions that register core clocks or clock gates from SoC specific data. These clock drivers are organized by function and over time the drivers filled up with #ifdefs to separate different SoC specific code. This patch set first adds a new element to clock gate descriptors to allow to pass clk flags per clock gate. (Patch 1) Then it restructures MVEBU clock drivers into common clock setup and SoC specific files and Kconfig options. The driver's init functions are also registered to get called with of_clk_init. (Patches 2, 3-6) It then switches Dove, Kirkwood, and Armada 370/XP to make use of of_clk_init instead of mvebu_clocks_init. (Patches 7-9) Finally, all obsolete files and Kconfig options are removed. (Patch 10) It has been tested on CuBox (Dove) and Dockstar (Kirkwood) by me. Armada 370 and XP are compile tested only and should get their Tested-by from Thomas and Gregory, respectively. @Mike: As this only touches MVEBU related code, I suggest to take it all through the corresponding ARM branch. Sebastian Hesselbarth (10): clk: mvebu: introduce per-clock-gate flags clk: mvebu: add common clock functions for core clk and clk gating clk: mvebu: add Dove SoC-centric clock init clk: mvebu: add Kirkwood SoC-centric clock init clk: mvebu: add Armada 370 SoC-centric clock init clk: mvebu: add Armada XP SoC-centric clock init ARM: dove: move DT boards to SoC-centric clock init ARM: kirkwood: move DT boards to SoC-centric clock init ARM: mvebu: move DT boards to SoC-centric clock init clk: mvebu: desintegrate obsolete file arch/arm/mach-dove/Kconfig |3 +- arch/arm/mach-dove/board-dt.c |3 +- arch/arm/mach-dove/common.c |1 - arch/arm/mach-kirkwood/Kconfig |3 +- arch/arm/mach-kirkwood/board-dt.c |3 +- arch/arm/mach-mvebu/Kconfig |5 +- arch/arm/mach-mvebu/armada-370-xp.c |4 +- drivers/clk/mvebu/Kconfig | 25 +- drivers/clk/mvebu/Makefile |8 +- drivers/clk/mvebu/armada-370.c | 176 + drivers/clk/mvebu/armada-xp.c | 204 +++ drivers/clk/mvebu/clk-core.c| 675 --- drivers/clk/mvebu/clk-core.h| 18 - drivers/clk/mvebu/clk-gating-ctrl.c | 250 - drivers/clk/mvebu/clk-gating-ctrl.h | 22 -- drivers/clk/mvebu/clk.c | 23 -- drivers/clk/mvebu/common.c | 163 + drivers/clk/mvebu/common.h | 48 +++ drivers/clk/mvebu/dove.c| 194 ++ drivers/clk/mvebu/kirkwood.c| 247 + include/linux/clk/mvebu.h | 22 -- 21 files changed, 1066 insertions(+), 1031 deletions(-) create mode 100644 drivers/clk/mvebu/armada-370.c create mode 100644 drivers/clk/mvebu/armada-xp.c delete mode 100644 drivers/clk/mvebu/clk-core.c delete mode 100644 drivers/clk/mvebu/clk-core.h delete mode 100644 drivers/clk/mvebu/clk-gating-ctrl.c delete mode 100644 drivers/clk/mvebu/clk-gating-ctrl.h delete mode 100644 drivers/clk/mvebu/clk.c create mode 100644 drivers/clk/mvebu/common.c create mode 100644 drivers/clk/mvebu/common.h create mode 100644 drivers/clk/mvebu/dove.c create mode 100644 drivers/clk/mvebu/kirkwood.c delete mode 100644 include/linux/clk/mvebu.h --- Cc: Jason Cooper Cc: Andrew Lunn Cc: Russell King Cc: Gregory Clement Cc: Thomas Petazzoni Cc: Mike Turquette Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org -- 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 02/10] clk: mvebu: add common clock functions for core clk and clk gating
Based on the current common functions for core clocks and clock
gating control, new common functions are joined in a single file.
Given the opportunity, names of functions and structs are unified,
and also a Kconfig entry is added.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Russell King
Cc: Gregory Clement
Cc: Thomas Petazzoni
Cc: Mike Turquette
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/clk/mvebu/Kconfig |3 +
drivers/clk/mvebu/Makefile |1 +
drivers/clk/mvebu/common.c | 163
drivers/clk/mvebu/common.h | 48 +
4 files changed, 215 insertions(+)
create mode 100644 drivers/clk/mvebu/common.c
create mode 100644 drivers/clk/mvebu/common.h
diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index 57323fd..2c3cf95 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -6,3 +6,6 @@ config MVEBU_CLK_CPU
config MVEBU_CLK_GATING
bool
+
+config MVEBU_CLK_COMMON
+ bool
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index 58df3dc..2143230 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_MVEBU_CLK_COMMON) += common.o
obj-$(CONFIG_MVEBU_CLK_CORE) += clk.o clk-core.o
obj-$(CONFIG_MVEBU_CLK_CPU)+= clk-cpu.o
obj-$(CONFIG_MVEBU_CLK_GATING) += clk-gating-ctrl.o
diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
new file mode 100644
index 000..adaa4a1
--- /dev/null
+++ b/drivers/clk/mvebu/common.c
@@ -0,0 +1,163 @@
+/*
+ * Marvell EBU SoC common clock handling
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Gregory CLEMENT
+ * Sebastian Hesselbarth
+ * Andrew Lunn
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "common.h"
+
+/*
+ * Core Clocks
+ */
+
+static struct clk_onecell_data clk_data;
+
+void __init mvebu_coreclk_setup(struct device_node *np,
+ const struct coreclk_soc_desc *desc)
+{
+ const char *tclk_name = "tclk";
+ const char *cpuclk_name = "cpuclk";
+ void __iomem *base;
+ unsigned long rate;
+ int n;
+
+ base = of_iomap(np, 0);
+ if (WARN_ON(!base))
+ return;
+
+ /* Allocate struct for TCLK, cpu clk, and core ratio clocks */
+ clk_data.clk_num = 2 + desc->num_ratios;
+ clk_data.clks = kzalloc(clk_data.clk_num * sizeof(struct clk *),
+ GFP_KERNEL);
+ if (WARN_ON(!clk_data.clks))
+ return;
+
+ /* Register TCLK */
+ of_property_read_string_index(np, "clock-output-names", 0,
+ _name);
+ rate = desc->get_tclk_freq(base);
+ clk_data.clks[0] = clk_register_fixed_rate(NULL, tclk_name, NULL,
+ CLK_IS_ROOT, rate);
+ WARN_ON(IS_ERR(clk_data.clks[0]));
+
+ /* Register CPU clock */
+ of_property_read_string_index(np, "clock-output-names", 1,
+ _name);
+ rate = desc->get_cpu_freq(base);
+ clk_data.clks[1] = clk_register_fixed_rate(NULL, cpuclk_name, NULL,
+ CLK_IS_ROOT, rate);
+ WARN_ON(IS_ERR(clk_data.clks[1]));
+
+ /* Register fixed-factor clocks derived from CPU clock */
+ for (n = 0; n < desc->num_ratios; n++) {
+ const char *rclk_name = desc->ratios[n].name;
+ int mult, div;
+
+ of_property_read_string_index(np, "clock-output-names",
+ 2+n, _name);
+ desc->get_clk_ratio(base, desc->ratios[n].id, , );
+ clk_data.clks[2+n] = clk_register_fixed_factor(NULL, rclk_name,
+ cpuclk_name, 0, mult, div);
+ WARN_ON(IS_ERR(clk_data.clks[2+n]));
+ };
+
+ /* SAR register isn't needed anymore */
+ iounmap(base);
+
+ of_clk_add_provider(np, of_clk_src_onecell_get, _data);
+}
+
+/*
+ * Clock Gating Control
+ */
+
+struct clk_gating_ctrl {
+ spinlock_t lock;
+ struct clk **gates;
+ int num_gates;
+};
+
+#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, hw)
+
+static struct clk *clk_gating_get_src(
+ struct of_phandle_args *clkspec, void *data)
+{
+ struct clk_gating_ctrl *ctrl = (struct clk_gating_ctrl *)data;
+ int n;
+
+ if (clkspec->args_count < 1)
+ return ERR_PTR(-EINVAL);
+
+ for (n = 0; n < ctrl->num_gates; n++) {
+ struct clk_gate *gate =
+ to_clk_gate(__clk_get_hw(ctrl->gates[n]));
+
Re: [PATCH 2/7] posix-cpu-timers: fix acounting delta_exec twice
On Fri, May 03, 2013 at 12:47:43AM -0400, kosaki.motoh...@gmail.com wrote: > From: KOSAKI Motohiro > > Currently glibc rt/tst-cpuclock2 test(*) sporadically fails because > scheduler delta can be accounted twice from thread_group_cputimer() > and account_group_exec_runtime(). > > Finally, clock_nanosleep() wakes up before an argument. This is posix > violation. This issue was introduced by commit d670ec1317 (posix-cpu-timers: > Cure SMP wobbles). > > (*) > http://sourceware.org/git/?p=glibc.git;a=blob;f=rt/tst-cpuclock2.c;h=6752721717f959e89c0d692b3f1ee082d507eec2;hb=HEAD > > Cc: Olivier Langlois > Cc: Thomas Gleixner > Cc: Frederic Weisbecker > Cc: Ingo Molnar > Signed-off-by: Peter Zijlstra > Signed-off-by: KOSAKI Motohiro [...] > diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c > index 8fd709c..e56be4c 100644 > --- a/kernel/posix-cpu-timers.c > +++ b/kernel/posix-cpu-timers.c > @@ -220,7 +220,7 @@ static int cpu_clock_sample(const clockid_t which_clock, > struct task_struct *p, > cpu->cpu = virt_ticks(p); > break; > case CPUCLOCK_SCHED: > - cpu->sched = task_sched_runtime(p); > + cpu->sched = task_sched_runtime(p, true); > break; > } > return 0; > @@ -250,8 +250,13 @@ void thread_group_cputimer(struct task_struct *tsk, > struct task_cputime *times) >* values through the TIMER_ABSTIME flag, therefore we have >* to synchronize the timer to the clock every time we start >* it. > + * > + * Do not add the current delta, because > + * account_group_exec_runtime() will also this delta and we > + * wouldn't want to double account time and get ahead of > + * ourselves. >*/ > - thread_group_cputime(tsk, ); > + thread_group_cputime(tsk, false, ); > raw_spin_lock_irqsave(>lock, flags); I wonder if we should move thread_group_cputime() inside this lock. Otherwise we can miss some updates in-between. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rtc: add in ability to push out an existing wakealarm using sysfs
This adds in the ability for the rtc sysfs code to handle += characters
at the beginning of a wakealarm setting string. This will allow the user to
attempt to push out an existing wakealarm by a provided amount.
In the case that the += characters are provided but the alarm is not active
-EVINVAL is returned.
Signed-off-by: Bernie Thompson
---
Documentation/rtc.txt | 7 ---
drivers/rtc/rtc-sysfs.c | 20 +++-
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt
index 32aa400..596b60c 100644
--- a/Documentation/rtc.txt
+++ b/Documentation/rtc.txt
@@ -153,9 +153,10 @@ since_epoch:The number of seconds since the epoch
according to the RTC
time: RTC-provided time
wakealarm: The time at which the clock will generate a system wakeup
event. This is a one shot wakeup event, so must be reset
-after wake if a daily wakeup is required. Format is either
-seconds since the epoch or, if there's a leading +, seconds
-in the future.
+after wake if a daily wakeup is required. Format is seconds
since
+the epoch by default, or if there's a leading +, seconds in the
+future, or if there is a leading +=, seconds ahead of the
current
+alarm.
IOCTL INTERFACE
---
diff --git a/drivers/rtc/rtc-sysfs.c b/drivers/rtc/rtc-sysfs.c
index b70e2bb..4b26f86 100644
--- a/drivers/rtc/rtc-sysfs.c
+++ b/drivers/rtc/rtc-sysfs.c
@@ -164,6 +164,7 @@ rtc_sysfs_set_wakealarm(struct device *dev, struct
device_attribute *attr,
{
ssize_t retval;
unsigned long now, alarm;
+ unsigned long push = 0;
struct rtc_wkalrm alm;
struct rtc_device *rtc = to_rtc_device(dev);
char *buf_ptr;
@@ -180,13 +181,17 @@ rtc_sysfs_set_wakealarm(struct device *dev, struct
device_attribute *attr,
buf_ptr = (char *)buf;
if (*buf_ptr == '+') {
buf_ptr++;
- adjust = 1;
+ if (*buf_ptr == '=') {
+ buf_ptr++;
+ push = 1;
+ } else
+ adjust = 1;
}
alarm = simple_strtoul(buf_ptr, NULL, 0);
if (adjust) {
alarm += now;
}
- if (alarm > now) {
+ if (alarm > now || push) {
/* Avoid accidentally clobbering active alarms; we can't
* entirely prevent that here, without even the minimal
* locking from the /dev/rtcN api.
@@ -194,9 +199,14 @@ rtc_sysfs_set_wakealarm(struct device *dev, struct
device_attribute *attr,
retval = rtc_read_alarm(rtc, );
if (retval < 0)
return retval;
- if (alm.enabled)
- return -EBUSY;
-
+ if (alm.enabled) {
+ if (push) {
+ rtc_tm_to_time(, );
+ alarm += push;
+ } else
+ return -EBUSY;
+ } else if (push)
+ return -EINVAL;
alm.enabled = 1;
} else {
alm.enabled = 0;
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] posix_timers: do not account group_exec_runtime for dying autoreaped tasks
On Mon, May 06, 2013 at 11:35:50PM -0400, Olivier Langlois wrote: > Frederic, > > On Tue, 2013-05-07 at 01:18 +0200, Frederic Weisbecker wrote: > > On Mon, Apr 29, 2013 at 02:04:09PM -0400, Olivier Langlois wrote: > > > > > > > > > Forbids the cputimer to drift ahead of its process clock by > > > blocking its update when a tick occurs while a autoreaping task > > > is currently in do_exit() between the call to release_task() and > > > its final call to schedule(). > > > > > > Any task stats update after having called release_task() will > > > be lost because they are added to the global process stats located > > > in the signal struct from release_task(). > > > > I wonder if this is real problem that the clock is ahead of the timer. > > Have you seen any issue in practice with this? > > note that it is the timer that will be ahead because the process clock > is the sum of past group tasks exec time plus current group tasks exec > time. Few updates are missing in the past group tasks exec time counter > in struct signal. > > The effect of this is failure of the unittest testing POSIX compliance > in glibc rt/tst-cputimer1.c > > pseudo code of the test is: > > 1. call clock_gettime() to get now > 2. Compute timer expiring time now+timer interval > 3. call clock_gettime() when timer cb is called > 4. Compare that clock_gettime() result is >= than computed expiring time > > The error is adding up as more thread exits and usually the test fails > when testing periodic timers where threads are created to handle the > timer timeouts. I see. Ok if it breaks a glibc test, it seems like a good reason to fix it :) Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: high-speed disk I/O is CPU-bound?
Cc-ing Jens David Oostdyk wrote: > Hello, > > I have a few relatively high-end systems with hardware RAIDs which > are being used for recording systems, and I'm trying to get a better > understanding of contiguous write performance. > > The hardware that I've tested with includes two high-end Intel > E5-2600 and E5-4600 (~3GHz) series systems, as well as a slightly > older Xeon 5600 system. The JBODs include a 45x3.5" JBOD, a 28x3.5" > JBOD (with either 7200RPM or 10kRPM SAS drives), and a 24x2.5" JBOD > with 10kRPM drives. I've tried LSI controllers (9285-8e, 9266-8i, > as well as the integrated Intel LSI controllers) as well as Adaptec > Series 7 RAID controllers (72405 and 71685). Which I/O scheduler are you using? noop (or deadline) may improve things with hardware RAID. > Normally I'll setup the RAIDs as RAID60 and format them as XFS, but > the exact RAID level, filesystem type, and even RAID hardware don't > seem to matter very much from my observations (but I'm willing to > try any suggestions). As a basic benchmark, I have an application > that simply writes the same buffer (say, 128MB) to disk repeatedly. > Alternatively you could use the "dd" utility. (For these > benchmarks, I set /proc/sys/vm/dirty_bytes to 512M or lower, since > these systems have a lot of RAM.) > > The basic observations are: > > 1. "single-threaded" writes, either a file on the mounted > filesystem or with a "dd" to the raw RAID device, seem to be limited > to 1200-1400MB/sec. These numbers vary slightly based on whether > TurboBoost is affecting the writing process or not. "top" will show > this process running at 100% CPU. > > 2. With two benchmarks running on the same device, I see aggregate > write speeds of up to ~2.4GB/sec, which is closer to what I'd expect > the drives of being able to deliver. This can either be with two > applications writing to separate files on the same mounted file > system, or two separate "dd" applications writing to distinct > locations on the raw device. (Increasing the number of writers > beyond two does not seem to increase aggregate performance; "top" > will show both processes running at perhaps 80% CPU). > > 3. I haven't been able to find any tricks (lio_listio, multiple > threads writing to distinct file offsets, etc) that seem to deliver > higher write speeds when writing to a single file. (This might be > xfs-specific, though) > > 4. Cheap tricks like making a software RAID0 of two hardware RAID > devices does not deliver any improved performance for > single-threaded writes. (Have not thoroughly tested this > configuration fully with multiple writers, though.) > > 5. Similar hardware on Windows seems to be able to deliver >3GB/sec > write speeds on a single-threaded writes, and the trick of making a > software RAID0 of two hardware RAIDs does deliver increased write > speeds. (I only point this out to say that I think the hardware is > not necessarily the bottleneck.) > > The question is, is it possible that high-speed I/O to these > hardware RAIDs could actually be CPU-bound above ~1400MB/sec? > > It seems to be the only explanation of the benchmarks that I've been > seeing, but I don't know where to start looking to really determine > the bottleneck. I'm certainly open to suggestions to running > different configurations or benchmarks. > > Thanks for any help/advice! > Dave O. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/7] posix-cpu-timers: don't account cpu timer after stopped thread runtime accounting
On Mon, May 06, 2013 at 11:16:40PM -0400, Olivier Langlois wrote: > On Tue, 2013-05-07 at 01:47 +0200, Frederic Weisbecker wrote: > > On Fri, May 03, 2013 at 12:47:42AM -0400, kosaki.motoh...@gmail.com wrote: > > > From: KOSAKI Motohiro > > > > > > When tsk->signal->cputimer->running is 1, signal->cputimer and > > > tsk->sum_sched_runtime increase at the same pace because update_curr() > > > increases both accounting. > > > > > > However, there is one exception. When thread exiting, __exit_signal() > > > turns > > > over task's sum_shced_runtime to sig->sum_sched_runtime, but it doesn't > > > stop > > > signal->cputimer accounting. > > > > > > This inconsistency makes POSIX timer wake up too early. This patch fixes > > > it. > > > > > > Cc: Thomas Gleixner > > > Cc: Frederic Weisbecker > > > Cc: Ingo Molnar > > > Acked-by: Peter Zijlstra > > > Signed-off-by: Olivier Langlois > > > Signed-off-by: KOSAKI Motohiro > > > --- > > > kernel/sched/stats.h |7 +++ > > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > > > diff --git a/kernel/sched/stats.h b/kernel/sched/stats.h > > > index 2ef90a5..5a0cfc4 100644 > > > --- a/kernel/sched/stats.h > > > +++ b/kernel/sched/stats.h > > > @@ -225,6 +225,13 @@ static inline void account_group_exec_runtime(struct > > > task_struct *tsk, > > > if (!cputimer->running) > > > return; > > > > > > + /* > > > + * After turning over se.sum_exec_runtime to sig->sum_sched_runtime > > > + * in __exit_signal(), we must not account exec_runtime for > > > consistency. > > > + */ Please just precise the nature of that consistency: the fact we want CLOCK_PROCESS_CPUTIME_ID clock and timer to be consistent. > > > + if (unlikely(!tsk->sighand)) > > > + return; > > > > Ok, if we want the clock and timer to be consistent, do we also want the > > same check in > > account_group_user_time() and account_group_system_time()? The task can > > still account > > a tick after autoreaping itself between release_task() and the final > > schedule(). > > > If I can reply, I believe that Kosaki refactoring is superior to my > initial proposal because: > > 1. Condition will only be evaluated when cputimer is on (and not slow > down scheduler when it is off) > 2. It handles all the cases when this function is called. There are few > other places outside update_curr() that this function is called. Agreed. Thanks! Acked-by: Frederic Weisbecker -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 01/18] ring-buffer: Select IRQ_WORK
From: "Steven Rostedt (Red Hat)" As the wake up logic for waiters on the buffer has been moved from the tracing code to the ring buffer, it requires also adding IRQ_WORK as the wake up code is performed via irq_work. This fixes compile breakage when a user of the ring buffer is selected but tracing and irq_work are not. Link http://lkml.kernel.org/r/20130503115332.GT8356@rric.localhost Cc: Arnd Bergmann Reported-by: Robert Richter Signed-off-by: Steven Rostedt --- kernel/trace/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index 5e9efd4..015f85a 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -71,6 +71,7 @@ config TRACE_CLOCK config RING_BUFFER bool select TRACE_CLOCK + select IRQ_WORK config FTRACE_NMI_ENTER bool @@ -107,7 +108,6 @@ config TRACING select BINARY_PRINTF select EVENT_TRACING select TRACE_CLOCK - select IRQ_WORK config GENERIC_TRACER bool -- 1.7.10.4 signature.asc Description: This is a digitally signed message part
[PATCH 00/18] tracing/kprobes: Update kprobes with new ftrace changes
Linus, The majority of these changes are from Masami Hiramatsu bringing kprobes up to par with the latest changes to ftrace (multi buffering and the new function probes). He also discovered and fixed some bugs in doing so. When pulling in his patches, I also found a few minor bugs as well and fixed them. This also includes a compile fix for some archs that select the ring buffer but not tracing. I based this off of the last patch you took from me that fixed the merge conflict error, as that was the commit that had all the changes I needed for this set of changes. Please pull the latest trace-fixes-v3.10 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-fixes-v3.10 Tag SHA1: b3955bf07072c5eb343b45faec09fee2d09cf695 Head SHA1: b8820084f2130b3dcfb09c78ac16cdd2194a345b Masami Hiramatsu (11): tracing: Don't succeed if event_enable_func did not register anything ftrace, kprobes: Fix a deadlock on ftrace_regex_lock ftrace: Cleanup regex_lock and ftrace_lock around hash updating tracing/kprobes: Fix to increment return event probe hit-count tracing: Indicate enabled soft-mode in enable file tracing: Modify soft-mode only if there's no other referrer tracing/kprobes: Use bool for retprobe checker tracing/kprobes: Increment probe hit-count even if it is used by perf tracing/kprobes: Pass trace_probe directly from dispatcher tracing/kprobes: Support ftrace_event_file base multibuffer tracing/kprobes: Support soft-mode disabling Steven Rostedt (Red Hat) (7): ring-buffer: Select IRQ_WORK tracing: Return error if register_ftrace_function_probe() fails for event_enable_func() ftrace: Have ftrace_regex_write() return either read or error tracing: Add helper function trace_create_new_event() to remove duplicate code ftrace: Fix locking in register_ftrace_function_probe() ftrace: Fix the output of enabled_functions debug file ftrace: Fix function probe when more than one probe is added include/linux/ftrace.h |4 + include/linux/ftrace_event.h |1 + kernel/trace/Kconfig |2 +- kernel/trace/ftrace.c| 126 -- kernel/trace/trace_events.c | 54 ++-- kernel/trace/trace_kprobe.c | 289 ++ 6 files changed, 368 insertions(+), 108 deletions(-) signature.asc Description: This is a digitally signed message part
[PATCH 06/18] ftrace: Cleanup regex_lock and ftrace_lock around hash updating
From: Masami Hiramatsu
Cleanup regex_lock and ftrace_lock locking points around
ftrace_ops hash update code.
The new rule is that regex_lock protects ops->*_hash
read-update-write code for each ftrace_ops. Usually,
hash update is done by following sequence.
1. allocate a new local hash and copy the original hash.
2. update the local hash.
3. move(actually, copy) back the local hash to ftrace_ops.
4. update ftrace entries if needed.
5. release the local hash.
This makes regex_lock protect #1-#4, and ftrace_lock
to protect #3, #4 and adding and removing ftrace_ops from the
ftrace_ops_list. The ftrace_lock protects #3 as well because
the move functions update the entries too.
Link: http://lkml.kernel.org/r/20130509054421.30398.83411.stgit@mhiramat-M0-7522
Cc: Srikar Dronamraju
Cc: Oleg Nesterov
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Tom Zanussi
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt
---
kernel/trace/ftrace.c | 59 +++--
1 file changed, 32 insertions(+), 27 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 827f2fe..cacf085 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2656,28 +2656,26 @@ ftrace_regex_open(struct ftrace_ops *ops, int flag,
return -ENOMEM;
}
+ iter->ops = ops;
+ iter->flags = flag;
+
+ mutex_lock(>regex_lock);
+
if (flag & FTRACE_ITER_NOTRACE)
hash = ops->notrace_hash;
else
hash = ops->filter_hash;
- iter->ops = ops;
- iter->flags = flag;
-
if (file->f_mode & FMODE_WRITE) {
- mutex_lock(_lock);
iter->hash =
alloc_and_copy_ftrace_hash(FTRACE_HASH_DEFAULT_BITS, hash);
- mutex_unlock(_lock);
-
if (!iter->hash) {
trace_parser_put(>parser);
kfree(iter);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out_unlock;
}
}
- mutex_lock(>regex_lock);
-
if ((file->f_mode & FMODE_WRITE) &&
(file->f_flags & O_TRUNC))
ftrace_filter_reset(iter->hash);
@@ -2697,6 +2695,8 @@ ftrace_regex_open(struct ftrace_ops *ops, int flag,
}
} else
file->private_data = iter;
+
+ out_unlock:
mutex_unlock(>regex_lock);
return ret;
@@ -3012,7 +3012,7 @@ register_ftrace_function_probe(char *glob, struct
ftrace_probe_ops *ops,
if (WARN_ON(not))
return -EINVAL;
- mutex_lock(_lock);
+ mutex_lock(_probe_ops.regex_lock);
hash = alloc_and_copy_ftrace_hash(FTRACE_HASH_DEFAULT_BITS, *orig_hash);
if (!hash) {
@@ -3070,14 +3070,16 @@ register_ftrace_function_probe(char *glob, struct
ftrace_probe_ops *ops,
} while_for_each_ftrace_rec();
+ mutex_lock(_lock);
ret = ftrace_hash_move(_probe_ops, 1, orig_hash, hash);
if (ret < 0)
count = ret;
__enable_ftrace_function_probe();
+ mutex_unlock(_lock);
out_unlock:
- mutex_unlock(_lock);
+ mutex_unlock(_probe_ops.regex_lock);
free_ftrace_hash(hash);
return count;
@@ -3117,7 +3119,7 @@ __unregister_ftrace_function_probe(char *glob, struct
ftrace_probe_ops *ops,
return;
}
- mutex_lock(_lock);
+ mutex_lock(_probe_ops.regex_lock);
hash = alloc_and_copy_ftrace_hash(FTRACE_HASH_DEFAULT_BITS, *orig_hash);
if (!hash)
@@ -3155,6 +3157,7 @@ __unregister_ftrace_function_probe(char *glob, struct
ftrace_probe_ops *ops,
list_add(>free_list, _list);
}
}
+ mutex_lock(_lock);
__disable_ftrace_function_probe();
/*
* Remove after the disable is called. Otherwise, if the last
@@ -3166,9 +3169,10 @@ __unregister_ftrace_function_probe(char *glob, struct
ftrace_probe_ops *ops,
list_del(>free_list);
ftrace_free_entry(entry);
}
+ mutex_unlock(_lock);
out_unlock:
- mutex_unlock(_lock);
+ mutex_unlock(_probe_ops.regex_lock);
free_ftrace_hash(hash);
}
@@ -3284,11 +3288,10 @@ ftrace_regex_write(struct file *file, const char __user
*ubuf,
} else
iter = file->private_data;
- mutex_lock(>ops->regex_lock);
-
- ret = -ENODEV;
if (unlikely(ftrace_disabled))
- goto out_unlock;
+ return -ENODEV;
+
+ /* iter->hash is a local copy, so we don't need regex_lock */
parser = >parser;
read = trace_get_user(parser, ubuf, cnt, ppos);
@@ -3299,13 +3302,11 @@ ftrace_regex_write(struct file *file, const char __user
*ubuf,
parser->idx, enable);
trace_parser_clear(parser);
[PATCH 18/18] tracing/kprobes: Support soft-mode disabling
From: Masami Hiramatsu Support soft-mode disabling on kprobe-based dynamic events. Soft-disabling is just ignoring recording if the soft disabled flag is set. Link: http://lkml.kernel.org/r/20130509054454.30398.7237.stgit@mhiramat-M0-7522 Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Tom Zanussi Cc: Oleg Nesterov Cc: Srikar Dronamraju Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt --- kernel/trace/trace_kprobe.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c index fee865d..636d45f 100644 --- a/kernel/trace/trace_kprobe.c +++ b/kernel/trace/trace_kprobe.c @@ -845,6 +845,9 @@ __kprobe_trace_func(struct trace_probe *tp, struct pt_regs *regs, WARN_ON(call != ftrace_file->event_call); + if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, _file->flags)) + return; + local_save_flags(irq_flags); pc = preempt_count(); @@ -893,6 +896,9 @@ __kretprobe_trace_func(struct trace_probe *tp, struct kretprobe_instance *ri, WARN_ON(call != ftrace_file->event_call); + if (test_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT, _file->flags)) + return; + local_save_flags(irq_flags); pc = preempt_count(); -- 1.7.10.4 signature.asc Description: This is a digitally signed message part
[PATCH 13/18] ftrace: Fix function probe when more than one probe is added
From: "Steven Rostedt (Red Hat)"
When the first function probe is added and the function tracer
is updated the functions are modified to call the probe.
But when a second function is added, it updates the function
records to have the second function also update, but it fails
to update the actual function itself.
This prevents the second (or third or forth and so on) probes
from having their functions called.
# echo vfs_symlink:enable_event:sched:sched_switch > set_ftrace_filter
# echo vfs_unlink:enable_event:sched:sched_switch > set_ftrace_filter
# cat trace
# tracer: nop
#
# entries-in-buffer/entries-written: 0/0 #P:4
#
# _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
# touch /tmp/a
# rm /tmp/a
# cat trace
# tracer: nop
#
# entries-in-buffer/entries-written: 0/0 #P:4
#
# _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
# ln -s /tmp/a
# cat trace
# tracer: nop
#
# entries-in-buffer/entries-written: 414/414 #P:4
#
# _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
-0 [000] d..3 2847.923031: sched_switch:
prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=bash
next_pid=2786 next_prio=120
<...>-3114 [001] d..4 2847.923035: sched_switch: prev_comm=ln
prev_pid=3114 prev_prio=120 prev_state=x ==> next_comm=swapper/1 next_pid=0
next_prio=120
bash-2786 [000] d..3 2847.923535: sched_switch: prev_comm=bash
prev_pid=2786 prev_prio=120 prev_state=S ==> next_comm=kworker/0:1 next_pid=34
next_prio=120
kworker/0:1-34[000] d..3 2847.923552: sched_switch:
prev_comm=kworker/0:1 prev_pid=34 prev_prio=120 prev_state=S ==>
next_comm=swapper/0 next_pid=0 next_prio=120
-0 [002] d..3 2847.923554: sched_switch:
prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=sshd
next_pid=2783 next_prio=120
sshd-2783 [002] d..3 2847.923660: sched_switch: prev_comm=sshd
prev_pid=2783 prev_prio=120 prev_state=S ==> next_comm=swapper/2 next_pid=0
next_prio=120
Still need to update the functions even though the probe itself
does not need to be registered again when added a new probe.
Signed-off-by: Steven Rostedt
---
kernel/trace/ftrace.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index dcca9fa..b549b0f 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2941,8 +2941,12 @@ static void __enable_ftrace_function_probe(void)
int ret;
int i;
- if (ftrace_probe_registered)
+ if (ftrace_probe_registered) {
+ /* still need to update the function call sites */
+ if (ftrace_enabled)
+ ftrace_run_update_code(FTRACE_UPDATE_CALLS);
return;
+ }
for (i = 0; i < FTRACE_FUNC_HASHSIZE; i++) {
struct hlist_head *hhd = _func_hash[i];
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 15/18] tracing/kprobes: Increment probe hit-count even if it is used by perf
From: Masami Hiramatsu
Increment probe hit-count for profiling even if it is used
by perf tool. Same thing has already done in trace_uprobe.
Link: http://lkml.kernel.org/r/20130509054436.30398.21133.stgit@mhiramat-M0-7522
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Tom Zanussi
Cc: Oleg Nesterov
Cc: Srikar Dronamraju
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_kprobe.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 0b7386a..6e86fbb 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -733,8 +733,6 @@ static __kprobes void kprobe_trace_func(struct kprobe *kp,
struct pt_regs *regs)
unsigned long irq_flags;
struct ftrace_event_call *call = >call;
- tp->nhit++;
-
local_save_flags(irq_flags);
pc = preempt_count();
@@ -767,8 +765,6 @@ static __kprobes void kretprobe_trace_func(struct
kretprobe_instance *ri,
unsigned long irq_flags;
struct ftrace_event_call *call = >call;
- tp->nhit++;
-
local_save_flags(irq_flags);
pc = preempt_count();
@@ -1075,6 +1071,8 @@ int kprobe_dispatcher(struct kprobe *kp, struct pt_regs
*regs)
{
struct trace_probe *tp = container_of(kp, struct trace_probe, rp.kp);
+ tp->nhit++;
+
if (tp->flags & TP_FLAG_TRACE)
kprobe_trace_func(kp, regs);
#ifdef CONFIG_PERF_EVENTS
@@ -1089,6 +1087,8 @@ int kretprobe_dispatcher(struct kretprobe_instance *ri,
struct pt_regs *regs)
{
struct trace_probe *tp = container_of(ri->rp, struct trace_probe, rp);
+ tp->nhit++;
+
if (tp->flags & TP_FLAG_TRACE)
kretprobe_trace_func(ri, regs);
#ifdef CONFIG_PERF_EVENTS
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 17/18] tracing/kprobes: Support ftrace_event_file base multibuffer
From: Masami Hiramatsu
Support multi-buffer on kprobe-based dynamic events by
using ftrace_event_file.
Link: http://lkml.kernel.org/r/20130509054449.30398.88343.stgit@mhiramat-M0-7522
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Tom Zanussi
Cc: Oleg Nesterov
Cc: Srikar Dronamraju
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_kprobe.c | 250 ---
1 file changed, 214 insertions(+), 36 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 9ca44fc..fee865d 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -27,7 +27,6 @@
/**
* Kprobe event core functions
*/
-
struct trace_probe {
struct list_headlist;
struct kretproberp; /* Use rp.kp for kprobe use */
@@ -36,6 +35,7 @@ struct trace_probe {
const char *symbol;/* symbol name */
struct ftrace_event_class class;
struct ftrace_event_callcall;
+ struct ftrace_event_file**files;
ssize_t size; /* trace entry size */
unsigned intnr_args;
struct probe_argargs[];
@@ -183,12 +183,57 @@ static struct trace_probe *find_trace_probe(const char
*event,
return NULL;
}
-/* Enable trace_probe - @flag must be TP_FLAG_TRACE or TP_FLAG_PROFILE */
-static int enable_trace_probe(struct trace_probe *tp, int flag)
+static int trace_probe_nr_files(struct trace_probe *tp)
+{
+ struct ftrace_event_file **file = tp->files;
+ int ret = 0;
+
+ if (file)
+ while (*(file++))
+ ret++;
+
+ return ret;
+}
+
+static DEFINE_MUTEX(probe_enable_lock);
+
+/*
+ * Enable trace_probe
+ * if the file is NULL, enable "perf" handler, or enable "trace" handler.
+ */
+static int
+enable_trace_probe(struct trace_probe *tp, struct ftrace_event_file *file)
{
int ret = 0;
- tp->flags |= flag;
+ mutex_lock(_enable_lock);
+
+ if (file) {
+ struct ftrace_event_file **new, **old = tp->files;
+ int n = trace_probe_nr_files(tp);
+
+ /* 1 is for new one and 1 is for stopper */
+ new = kzalloc((n + 2) * sizeof(struct ftrace_event_file *),
+ GFP_KERNEL);
+ if (!new) {
+ ret = -ENOMEM;
+ goto out_unlock;
+ }
+ memcpy(new, old, n * sizeof(struct ftrace_event_file *));
+ new[n] = file;
+ /* The last one keeps a NULL */
+
+ rcu_assign_pointer(tp->files, new);
+ tp->flags |= TP_FLAG_TRACE;
+
+ if (old) {
+ /* Make sure the probe is done with old files */
+ synchronize_sched();
+ kfree(old);
+ }
+ } else
+ tp->flags |= TP_FLAG_PROFILE;
+
if (trace_probe_is_enabled(tp) && trace_probe_is_registered(tp) &&
!trace_probe_has_gone(tp)) {
if (trace_probe_is_return(tp))
@@ -197,19 +242,83 @@ static int enable_trace_probe(struct trace_probe *tp, int
flag)
ret = enable_kprobe(>rp.kp);
}
+ out_unlock:
+ mutex_unlock(_enable_lock);
+
return ret;
}
-/* Disable trace_probe - @flag must be TP_FLAG_TRACE or TP_FLAG_PROFILE */
-static void disable_trace_probe(struct trace_probe *tp, int flag)
+static int
+trace_probe_file_index(struct trace_probe *tp, struct ftrace_event_file *file)
+{
+ int i;
+
+ if (tp->files) {
+ for (i = 0; tp->files[i]; i++)
+ if (tp->files[i] == file)
+ return i;
+ }
+
+ return -1;
+}
+
+/*
+ * Disable trace_probe
+ * if the file is NULL, disable "perf" handler, or disable "trace" handler.
+ */
+static int
+disable_trace_probe(struct trace_probe *tp, struct ftrace_event_file *file)
{
- tp->flags &= ~flag;
+ int ret = 0;
+
+ mutex_lock(_enable_lock);
+
+ if (file) {
+ struct ftrace_event_file **new, **old = tp->files;
+ int n = trace_probe_nr_files(tp);
+ int i, j;
+
+ if (n == 0 || trace_probe_file_index(tp, file) < 0) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
+ if (n == 1) { /* Remove the last file */
+ tp->flags &= ~TP_FLAG_TRACE;
+ new = NULL;
+ } else {
+ new = kzalloc(n * sizeof(struct ftrace_event_file *),
+ GFP_KERNEL);
+ if (!new) {
+ ret = -ENOMEM;
+ goto out_unlock;
+ }
+
+ /*
[PATCH 14/18] tracing/kprobes: Use bool for retprobe checker
From: Masami Hiramatsu
Use bool instead of int for kretprobe checker.
Link: http://lkml.kernel.org/r/20130509054431.30398.38561.stgit@mhiramat-M0-7522
Cc: Srikar Dronamraju
Cc: Oleg Nesterov
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Tom Zanussi
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_kprobe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 6928633..0b7386a 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -46,7 +46,7 @@ struct trace_probe {
(sizeof(struct probe_arg) * (n)))
-static __kprobes int trace_probe_is_return(struct trace_probe *tp)
+static __kprobes bool trace_probe_is_return(struct trace_probe *tp)
{
return tp->rp.handler != NULL;
}
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 05/18] ftrace, kprobes: Fix a deadlock on ftrace_regex_lock
From: Masami Hiramatsu
Fix a deadlock on ftrace_regex_lock which happens when setting
an enable_event trigger on dynamic kprobe event as below.
sh-2.05b# echo p vfs_symlink > kprobe_events
sh-2.05b# echo vfs_symlink:enable_event:kprobes:p_vfs_symlink_0 >
set_ftrace_filter
=
[ INFO: possible recursive locking detected ]
3.9.0+ #35 Not tainted
-
sh/72 is trying to acquire lock:
(ftrace_regex_lock){+.+.+.}, at: []
ftrace_set_hash+0x81/0x1f0
but task is already holding lock:
(ftrace_regex_lock){+.+.+.}, at: []
ftrace_regex_write.isra.29.part.30+0x3d/0x220
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(ftrace_regex_lock);
lock(ftrace_regex_lock);
*** DEADLOCK ***
To fix that, this introduces a finer regex_lock for each ftrace_ops.
ftrace_regex_lock is too big of a lock which protects all
filter/notrace_hash operations, but it doesn't need to be a global
lock after supporting multiple ftrace_ops because each ftrace_ops
has its own filter/notrace_hash.
Link: http://lkml.kernel.org/r/20130509054417.30398.84254.stgit@mhiramat-M0-7522
Cc: Srikar Dronamraju
Cc: Oleg Nesterov
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Tom Zanussi
Signed-off-by: Masami Hiramatsu
[ Added initialization flag and automate mutex initialization for
non ftrace.c ftrace_probes. ]
Signed-off-by: Steven Rostedt
---
include/linux/ftrace.h |4 +++
kernel/trace/ftrace.c | 73 ++--
2 files changed, 56 insertions(+), 21 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index f83e17a..99d0fbc 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -90,6 +90,8 @@ typedef void (*ftrace_func_t)(unsigned long ip, unsigned long
parent_ip,
*not set this, then the ftrace infrastructure will add recursion
*protection for the caller.
* STUB - The ftrace_ops is just a place holder.
+ * INITIALIZED - The ftrace_ops has already been initialized (first use time
+ *register_ftrace_function() is called, it will initialized the
ops)
*/
enum {
FTRACE_OPS_FL_ENABLED = 1 << 0,
@@ -100,6 +102,7 @@ enum {
FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED= 1 << 5,
FTRACE_OPS_FL_RECURSION_SAFE= 1 << 6,
FTRACE_OPS_FL_STUB = 1 << 7,
+ FTRACE_OPS_FL_INITIALIZED = 1 << 8,
};
struct ftrace_ops {
@@ -110,6 +113,7 @@ struct ftrace_ops {
#ifdef CONFIG_DYNAMIC_FTRACE
struct ftrace_hash *notrace_hash;
struct ftrace_hash *filter_hash;
+ struct mutexregex_lock;
#endif
};
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index d85a0ad..827f2fe 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -64,6 +64,13 @@
#define FL_GLOBAL_CONTROL_MASK (FTRACE_OPS_FL_GLOBAL | FTRACE_OPS_FL_CONTROL)
+#ifdef CONFIG_DYNAMIC_FTRACE
+#define INIT_REGEX_LOCK(opsname) \
+ .regex_lock = __MUTEX_INITIALIZER(opsname.regex_lock),
+#else
+#define INIT_REGEX_LOCK(opsname)
+#endif
+
static struct ftrace_ops ftrace_list_end __read_mostly = {
.func = ftrace_stub,
.flags = FTRACE_OPS_FL_RECURSION_SAFE | FTRACE_OPS_FL_STUB,
@@ -131,6 +138,16 @@ static void ftrace_ops_no_ops(unsigned long ip, unsigned
long parent_ip);
while (likely(op = rcu_dereference_raw((op)->next)) && \
unlikely((op) != _list_end))
+static inline void ftrace_ops_init(struct ftrace_ops *ops)
+{
+#ifdef CONFIG_DYNAMIC_FTRACE
+ if (!(ops->flags & FTRACE_OPS_FL_INITIALIZED)) {
+ mutex_init(>regex_lock);
+ ops->flags |= FTRACE_OPS_FL_INITIALIZED;
+ }
+#endif
+}
+
/**
* ftrace_nr_registered_ops - return number of ops registered
*
@@ -907,7 +924,8 @@ static void unregister_ftrace_profiler(void)
#else
static struct ftrace_ops ftrace_profile_ops __read_mostly = {
.func = function_profile_call,
- .flags = FTRACE_OPS_FL_RECURSION_SAFE,
+ .flags = FTRACE_OPS_FL_RECURSION_SAFE |
FTRACE_OPS_FL_INITIALIZED,
+ INIT_REGEX_LOCK(ftrace_profile_ops)
};
static int register_ftrace_profiler(void)
@@ -1103,11 +1121,10 @@ static struct ftrace_ops global_ops = {
.func = ftrace_stub,
.notrace_hash = EMPTY_HASH,
.filter_hash= EMPTY_HASH,
- .flags = FTRACE_OPS_FL_RECURSION_SAFE,
+ .flags = FTRACE_OPS_FL_RECURSION_SAFE |
FTRACE_OPS_FL_INITIALIZED,
+ INIT_REGEX_LOCK(global_ops)
};
-static DEFINE_MUTEX(ftrace_regex_lock);
-
struct ftrace_page {
struct ftrace_page *next;
struct dyn_ftrace *records;
@@ -1247,6 +1264,7 @@ static void
[PATCH 11/18] ftrace: Fix locking in register_ftrace_function_probe()
From: "Steven Rostedt (Red Hat)"
The iteration of the ftrace function list and the call to
ftrace_match_record() need to be protected by the ftrace_lock.
Signed-off-by: Steven Rostedt
---
kernel/trace/ftrace.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index cacf085..f104c45 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3017,14 +3017,16 @@ register_ftrace_function_probe(char *glob, struct
ftrace_probe_ops *ops,
hash = alloc_and_copy_ftrace_hash(FTRACE_HASH_DEFAULT_BITS, *orig_hash);
if (!hash) {
count = -ENOMEM;
- goto out_unlock;
+ goto out;
}
if (unlikely(ftrace_disabled)) {
count = -ENODEV;
- goto out_unlock;
+ goto out;
}
+ mutex_lock(_lock);
+
do_for_each_ftrace_rec(pg, rec) {
if (!ftrace_match_record(rec, NULL, search, len, type))
@@ -3070,15 +3072,15 @@ register_ftrace_function_probe(char *glob, struct
ftrace_probe_ops *ops,
} while_for_each_ftrace_rec();
- mutex_lock(_lock);
ret = ftrace_hash_move(_probe_ops, 1, orig_hash, hash);
if (ret < 0)
count = ret;
__enable_ftrace_function_probe();
- mutex_unlock(_lock);
out_unlock:
+ mutex_unlock(_lock);
+ out:
mutex_unlock(_probe_ops.regex_lock);
free_ftrace_hash(hash);
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 12/18] ftrace: Fix the output of enabled_functions debug file
From: "Steven Rostedt (Red Hat)"
The enabled_functions debugfs file was created to be able to see
what functions have been modified from nops to calling a tracer.
The current method uses the counter in the function record.
As when a ftrace_ops is registered to a function, its count
increases. But that doesn't mean that the function is actively
being traced. /proc/sys/kernel/ftrace_enabled can be set to zero
which would disable it, as well as something can go wrong and
we can think its enabled when only the counter is set.
The record's FTRACE_FL_ENABLED flag is set or cleared when its
function is modified. That is a much more accurate way of knowing
what function is enabled or not.
Signed-off-by: Steven Rostedt
---
kernel/trace/ftrace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index f104c45..dcca9fa 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2459,7 +2459,7 @@ t_next(struct seq_file *m, void *v, loff_t *pos)
!ftrace_lookup_ip(ops->notrace_hash, rec->ip)) ||
((iter->flags & FTRACE_ITER_ENABLED) &&
-!(rec->flags & ~FTRACE_FL_MASK))) {
+!(rec->flags & FTRACE_FL_ENABLED))) {
rec = NULL;
goto retry;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v2] jbd2: Fix block tag checksum verification brokenness
On Fri, May 10, 2013 at 04:38:07PM -0700, Darrick J. Wong wrote: > Al Viro complained of a ton of bogosity with regards to the jbd2 block tag > header checksum. This one checksum is 16 bits, so cut off the upper 16 bits > and treat it as a 16-bit value and don't mess around with be32* conversions. > Fortunately metadata checksumming is still "experimental" and not in a > shipping > e2fsprogs, so there should be few users affected by this. > > v2: Eliminate unnecessary variables and make it clear(er) which values are 32 > bits wide. > > Reported-by: Al Viro > Signed-off-by: Darrick J. Wong ACKed-by: Al Viro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 07/18] tracing/kprobes: Fix to increment return event probe hit-count
From: Masami Hiramatsu Fix to increment probe hit-count for function return event. Link: http://lkml.kernel.org/r/20130509054424.30398.34058.stgit@mhiramat-M0-7522 Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Tom Zanussi Cc: Oleg Nesterov Cc: Srikar Dronamraju Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt --- kernel/trace/trace_kprobe.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c index 1865d5f..6928633 100644 --- a/kernel/trace/trace_kprobe.c +++ b/kernel/trace/trace_kprobe.c @@ -767,6 +767,8 @@ static __kprobes void kretprobe_trace_func(struct kretprobe_instance *ri, unsigned long irq_flags; struct ftrace_event_call *call = >call; + tp->nhit++; + local_save_flags(irq_flags); pc = preempt_count(); -- 1.7.10.4 signature.asc Description: This is a digitally signed message part
[PATCH 04/18] ftrace: Have ftrace_regex_write() return either read or error
From: "Steven Rostedt (Red Hat)" As ftrace_regex_write() reads the result of ftrace_process_regex() which can sometimes return a positive number, only consider a failure if the return is negative. Otherwise, it will skip possible other registered probes and by returning a positive number that wasn't read, it will confuse the user processes doing the writing. Cc: Masami Hiramatsu Signed-off-by: Steven Rostedt --- kernel/trace/ftrace.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 8a5c017..d85a0ad 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -3276,7 +3276,7 @@ ftrace_regex_write(struct file *file, const char __user *ubuf, ret = ftrace_process_regex(iter->hash, parser->buffer, parser->idx, enable); trace_parser_clear(parser); - if (ret) + if (ret < 0) goto out_unlock; } -- 1.7.10.4 signature.asc Description: This is a digitally signed message part
[PATCH 02/18] tracing: Dont succeed if event_enable_func did not register anything
From: Masami Hiramatsu
Return 0 instead of the number of activated ftrace function probes if
event_enable_func succeeded and return an error code if it failed or
did not register any functions. But it currently returns the number
of registered functions and if it didn't register anything, it returns 0,
but that is considered success.
This also fixes the return value. As if it succeeds, it returns the
number of functions that were enabled, which is returned back to
the user in ftrace_regex_write (the write() return code). If only
one function is enabled, then the return code of the write is one,
and this can confuse the user program in thinking it only wrote 1
byte.
Link: http://lkml.kernel.org/r/20130509054413.30398.55650.stgit@mhiramat-M0-7522
Cc: Srikar Dronamraju
Cc: Oleg Nesterov
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Tom Zanussi
Signed-off-by: Masami Hiramatsu
[ Rewrote change log to reflect that this fixes two bugs - SR ]
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_events.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 53582e9..44ac836 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -2061,8 +2061,11 @@ event_enable_func(struct ftrace_hash *hash,
if (ret < 0)
goto out_put;
ret = register_ftrace_function_probe(glob, ops, data);
- if (!ret)
+ if (!ret) {
+ ret = -ENOENT;
goto out_disable;
+ } else
+ ret = 0;
out:
mutex_unlock(_mutex);
return ret;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 08/18] tracing: Indicate enabled soft-mode in enable file
From: Masami Hiramatsu
Indicate enabled soft-mode event as "1*" in "enable" file
for each event, because it can be soft-disabled when disable_event
trigger is hit.
Link: http://lkml.kernel.org/r/20130509054426.30398.28202.stgit@mhiramat-M0-7522
Cc: Srikar Dronamraju
Cc: Oleg Nesterov
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Tom Zanussi
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_events.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 87e826f..915c136 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -623,6 +623,8 @@ event_enable_read(struct file *filp, char __user *ubuf,
size_t cnt,
if (file->flags & FTRACE_EVENT_FL_ENABLED) {
if (file->flags & FTRACE_EVENT_FL_SOFT_DISABLED)
buf = "0*\n";
+ else if (file->flags & FTRACE_EVENT_FL_SOFT_MODE)
+ buf = "1*\n";
else
buf = "1\n";
} else
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 10/18] tracing: Add helper function trace_create_new_event() to remove duplicate code
From: "Steven Rostedt (Red Hat)"
Both __trace_add_new_event() and __trace_early_add_new_event() do
basically the same thing, except that __trace_add_new_event() does
a little more.
Instead of having duplicate code between the two functions, add
a helper function trace_create_new_event() that both can use.
This will help against having bugs fixed in one function but not
the other.
Cc: Masami Hiramatsu
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_events.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 8be1224..7a0cf68 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1529,6 +1529,24 @@ __register_event(struct ftrace_event_call *call, struct
module *mod)
return 0;
}
+static struct ftrace_event_file *
+trace_create_new_event(struct ftrace_event_call *call,
+ struct trace_array *tr)
+{
+ struct ftrace_event_file *file;
+
+ file = kmem_cache_alloc(file_cachep, GFP_TRACE);
+ if (!file)
+ return NULL;
+
+ file->event_call = call;
+ file->tr = tr;
+ atomic_set(>sm_ref, 0);
+ list_add(>list, >events);
+
+ return file;
+}
+
/* Add an event to a trace directory */
static int
__trace_add_new_event(struct ftrace_event_call *call,
@@ -1540,15 +1558,10 @@ __trace_add_new_event(struct ftrace_event_call *call,
{
struct ftrace_event_file *file;
- file = kmem_cache_alloc(file_cachep, GFP_TRACE);
+ file = trace_create_new_event(call, tr);
if (!file)
return -ENOMEM;
- file->event_call = call;
- file->tr = tr;
- atomic_set(>sm_ref, 0);
- list_add(>list, >events);
-
return event_create_dir(tr->event_dir, file, id, enable, filter,
format);
}
@@ -1563,15 +1576,10 @@ __trace_early_add_new_event(struct ftrace_event_call
*call,
{
struct ftrace_event_file *file;
- file = kmem_cache_alloc(file_cachep, GFP_TRACE);
+ file = trace_create_new_event(call, tr);
if (!file)
return -ENOMEM;
- file->event_call = call;
- file->tr = tr;
- atomic_set(>sm_ref, 0);
- list_add(>list, >events);
-
return 0;
}
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 16/18] tracing/kprobes: Pass trace_probe directly from dispatcher
From: Masami Hiramatsu
Pass the pointer of struct trace_probe directly from probe
dispatcher to handlers. This removes redundant container_of
macro uses. Same thing has already done in trace_uprobe.
Link: http://lkml.kernel.org/r/20130509054441.30398.69112.stgit@mhiramat-M0-7522
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Tom Zanussi
Cc: Oleg Nesterov
Cc: Srikar Dronamraju
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_kprobe.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 6e86fbb..9ca44fc 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -723,9 +723,9 @@ static __kprobes void store_trace_args(int ent_size, struct
trace_probe *tp,
}
/* Kprobe handler */
-static __kprobes void kprobe_trace_func(struct kprobe *kp, struct pt_regs
*regs)
+static __kprobes void
+kprobe_trace_func(struct trace_probe *tp, struct pt_regs *regs)
{
- struct trace_probe *tp = container_of(kp, struct trace_probe, rp.kp);
struct kprobe_trace_entry_head *entry;
struct ring_buffer_event *event;
struct ring_buffer *buffer;
@@ -745,7 +745,7 @@ static __kprobes void kprobe_trace_func(struct kprobe *kp,
struct pt_regs *regs)
return;
entry = ring_buffer_event_data(event);
- entry->ip = (unsigned long)kp->addr;
+ entry->ip = (unsigned long)tp->rp.kp.addr;
store_trace_args(sizeof(*entry), tp, regs, (u8 *)[1], dsize);
if (!filter_current_check_discard(buffer, call, entry, event))
@@ -754,10 +754,10 @@ static __kprobes void kprobe_trace_func(struct kprobe
*kp, struct pt_regs *regs)
}
/* Kretprobe handler */
-static __kprobes void kretprobe_trace_func(struct kretprobe_instance *ri,
- struct pt_regs *regs)
+static __kprobes void
+kretprobe_trace_func(struct trace_probe *tp, struct kretprobe_instance *ri,
+struct pt_regs *regs)
{
- struct trace_probe *tp = container_of(ri->rp, struct trace_probe, rp);
struct kretprobe_trace_entry_head *entry;
struct ring_buffer_event *event;
struct ring_buffer *buffer;
@@ -973,10 +973,9 @@ static int set_print_fmt(struct trace_probe *tp)
#ifdef CONFIG_PERF_EVENTS
/* Kprobe profile handler */
-static __kprobes void kprobe_perf_func(struct kprobe *kp,
-struct pt_regs *regs)
+static __kprobes void
+kprobe_perf_func(struct trace_probe *tp, struct pt_regs *regs)
{
- struct trace_probe *tp = container_of(kp, struct trace_probe, rp.kp);
struct ftrace_event_call *call = >call;
struct kprobe_trace_entry_head *entry;
struct hlist_head *head;
@@ -995,7 +994,7 @@ static __kprobes void kprobe_perf_func(struct kprobe *kp,
if (!entry)
return;
- entry->ip = (unsigned long)kp->addr;
+ entry->ip = (unsigned long)tp->rp.kp.addr;
memset([1], 0, dsize);
store_trace_args(sizeof(*entry), tp, regs, (u8 *)[1], dsize);
@@ -1005,10 +1004,10 @@ static __kprobes void kprobe_perf_func(struct kprobe
*kp,
}
/* Kretprobe profile handler */
-static __kprobes void kretprobe_perf_func(struct kretprobe_instance *ri,
- struct pt_regs *regs)
+static __kprobes void
+kretprobe_perf_func(struct trace_probe *tp, struct kretprobe_instance *ri,
+ struct pt_regs *regs)
{
- struct trace_probe *tp = container_of(ri->rp, struct trace_probe, rp);
struct ftrace_event_call *call = >call;
struct kretprobe_trace_entry_head *entry;
struct hlist_head *head;
@@ -1074,10 +1073,10 @@ int kprobe_dispatcher(struct kprobe *kp, struct pt_regs
*regs)
tp->nhit++;
if (tp->flags & TP_FLAG_TRACE)
- kprobe_trace_func(kp, regs);
+ kprobe_trace_func(tp, regs);
#ifdef CONFIG_PERF_EVENTS
if (tp->flags & TP_FLAG_PROFILE)
- kprobe_perf_func(kp, regs);
+ kprobe_perf_func(tp, regs);
#endif
return 0; /* We don't tweek kernel, so just return 0 */
}
@@ -1090,10 +1089,10 @@ int kretprobe_dispatcher(struct kretprobe_instance *ri,
struct pt_regs *regs)
tp->nhit++;
if (tp->flags & TP_FLAG_TRACE)
- kretprobe_trace_func(ri, regs);
+ kretprobe_trace_func(tp, ri, regs);
#ifdef CONFIG_PERF_EVENTS
if (tp->flags & TP_FLAG_PROFILE)
- kretprobe_perf_func(ri, regs);
+ kretprobe_perf_func(tp, ri, regs);
#endif
return 0; /* We don't tweek kernel, so just return 0 */
}
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 09/18] tracing: Modify soft-mode only if theres no other referrer
From: Masami Hiramatsu
Modify soft-mode flag only if no other soft-mode referrer
(currently only the ftrace triggers) by using a reference
counter in each ftrace_event_file.
Without this fix, adding and removing several different
enable/disable_event triggers on the same event clear
soft-mode bit from the ftrace_event_file. This also
happens with a typo of glob on setting triggers.
e.g.
# echo vfs_symlink:enable_event:net:netif_rx > set_ftrace_filter
# cat events/net/netif_rx/enable
0*
# echo typo_func:enable_event:net:netif_rx > set_ftrace_filter
# cat events/net/netif_rx/enable
0
# cat set_ftrace_filter
all functions enabled
vfs_symlink:enable_event:net:netif_rx:unlimited
As above, we still have a trigger, but soft-mode is gone.
Link: http://lkml.kernel.org/r/20130509054429.30398.7464.stgit@mhiramat-M0-7522
Cc: Srikar Dronamraju
Cc: Oleg Nesterov
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: David Sharp
Cc: Hiraku Toyooka
Cc: Tom Zanussi
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt
---
include/linux/ftrace_event.h |1 +
kernel/trace/trace_events.c | 12 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 34e00fb..4372658 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -293,6 +293,7 @@ struct ftrace_event_file {
* caching and such. Which is mostly OK ;-)
*/
unsigned long flags;
+ atomic_tsm_ref; /* soft-mode reference counter */
};
#define __TRACE_EVENT_FLAGS(name, value) \
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 915c136..8be1224 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -251,7 +251,8 @@ static int __ftrace_event_enable_disable(struct
ftrace_event_file *file,
switch (enable) {
case 0:
/*
-* When soft_disable is set and enable is cleared, we want
+* When soft_disable is set and enable is cleared, the sm_ref
+* reference counter is decremented. If it reaches 0, we want
* to clear the SOFT_DISABLED flag but leave the event in the
* state that it was. That is, if the event was enabled and
* SOFT_DISABLED isn't set, then do nothing. But if
SOFT_DISABLED
@@ -263,6 +264,8 @@ static int __ftrace_event_enable_disable(struct
ftrace_event_file *file,
* "soft enable"s (clearing the SOFT_DISABLED bit) wont work.
*/
if (soft_disable) {
+ if (atomic_dec_return(>sm_ref) > 0)
+ break;
disable = file->flags & FTRACE_EVENT_FL_SOFT_DISABLED;
clear_bit(FTRACE_EVENT_FL_SOFT_MODE_BIT, >flags);
} else
@@ -291,8 +294,11 @@ static int __ftrace_event_enable_disable(struct
ftrace_event_file *file,
*/
if (!soft_disable)
clear_bit(FTRACE_EVENT_FL_SOFT_DISABLED_BIT,
>flags);
- else
+ else {
+ if (atomic_inc_return(>sm_ref) > 1)
+ break;
set_bit(FTRACE_EVENT_FL_SOFT_MODE_BIT, >flags);
+ }
if (!(file->flags & FTRACE_EVENT_FL_ENABLED)) {
@@ -1540,6 +1546,7 @@ __trace_add_new_event(struct ftrace_event_call *call,
file->event_call = call;
file->tr = tr;
+ atomic_set(>sm_ref, 0);
list_add(>list, >events);
return event_create_dir(tr->event_dir, file, id, enable, filter,
format);
@@ -1562,6 +1569,7 @@ __trace_early_add_new_event(struct ftrace_event_call
*call,
file->event_call = call;
file->tr = tr;
+ atomic_set(>sm_ref, 0);
list_add(>list, >events);
return 0;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 03/18] tracing: Return error if register_ftrace_function_probe() fails for event_enable_func()
From: "Steven Rostedt (Red Hat)"
register_ftrace_function_probe() returns the number of functions
it registered, which can be zero, it can also return a negative number
if something went wrong. But event_enable_func() only checks for
the case that it didn't register anything, it needs to also check
for the case that something went wrong and return that error code
as well.
Added some comments about the code as well, to make it more
understandable.
Cc: Masami Hiramatsu
Signed-off-by: Steven Rostedt
---
kernel/trace/trace_events.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 44ac836..87e826f 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -2061,11 +2061,18 @@ event_enable_func(struct ftrace_hash *hash,
if (ret < 0)
goto out_put;
ret = register_ftrace_function_probe(glob, ops, data);
+ /*
+* The above returns on success the # of functions enabled,
+* but if it didn't find any functions it returns zero.
+* Consider no functions a failure too.
+*/
if (!ret) {
ret = -ENOENT;
goto out_disable;
- } else
- ret = 0;
+ } else if (ret < 0)
+ goto out_disable;
+ /* Just return zero, not the number of enabled functions */
+ ret = 0;
out:
mutex_unlock(_mutex);
return ret;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
RE: [PATCH 4/4] driver: provide sysfs interfaces to access SMX parameter
On 2013-05-10, Matthew Garrett wrote: > On Fri, 2013-05-10 at 07:05 +, Ren, Qiaowei wrote: >> On 2013-05-08, Matthew Garrett wrote: >>> On Tue, 2013-05-07 at 22:55 +0800, Qiaowei Ren wrote: >>> +What: /sys/devices/platform/intel_txt/parameter/acm_max_size +Date: May 2013 +KernelVersion:3.9 +Contact: "Qiaowei Ren" +Description: The "acm_max_size" property will show max size of + authenticated code execution area. >>> >>> What would userspace use this for? >> >> These sysfs files are just export SMX & TXT related information to userspace. > So that other developers (or OSV & ISV) can be able to develop txt > related applications or tools based on these information. > > If they're only using it for debugging purposes then sysfs probably > isn't the right place. Is there any reason tools would need to know this > during normal usage? Unlike tboot log, these properties are not used for debugging purposes. They are used to report attributes, options and limitations of SMX operation. Software may use them to identify operations limits or additional options. Thanks, Qiaowei
[PATCH] jbd2: Always set journal superblock checksum when writing out superblock
Add a few missing calls to jbd2_superblock_csum_set just prior to calling jbd2_write_superblock. This fixes complaints about corrupt journals if metadata checksumming and journal checksumming are both enabled. Signed-off-by: Darrick J. Wong --- fs/jbd2/journal.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c index b6cdc57..a4c7678 100644 --- a/fs/jbd2/journal.c +++ b/fs/jbd2/journal.c @@ -1348,6 +1348,7 @@ void jbd2_journal_update_sb_log_tail(journal_t *journal, tid_t tail_tid, sb->s_sequence = cpu_to_be32(tail_tid); sb->s_start= cpu_to_be32(tail_block); + jbd2_superblock_csum_set(journal, sb); jbd2_write_superblock(journal, write_op); @@ -1381,6 +1382,7 @@ static void jbd2_mark_journal_empty(journal_t *journal) sb->s_sequence = cpu_to_be32(journal->j_tail_sequence); sb->s_start= cpu_to_be32(0); + jbd2_superblock_csum_set(journal, sb); read_unlock(>j_state_lock); jbd2_write_superblock(journal, WRITE_FUA); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] jbd2: Fix block tag checksum verification brokenness
Al Viro complained of a ton of bogosity with regards to the jbd2 block tag
header checksum. This one checksum is 16 bits, so cut off the upper 16 bits
and treat it as a 16-bit value and don't mess around with be32* conversions.
Fortunately metadata checksumming is still "experimental" and not in a shipping
e2fsprogs, so there should be few users affected by this.
v2: Eliminate unnecessary variables and make it clear(er) which values are 32
bits wide.
Reported-by: Al Viro
Signed-off-by: Darrick J. Wong
---
fs/jbd2/commit.c | 12 ++--
fs/jbd2/recovery.c | 11 +--
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
index 750c701..67a8a2f 100644
--- a/fs/jbd2/commit.c
+++ b/fs/jbd2/commit.c
@@ -343,20 +343,20 @@ static void jbd2_block_tag_csum_set(journal_t *j,
journal_block_tag_t *tag,
{
struct page *page = bh->b_page;
__u8 *addr;
- __u32 csum;
+ __u32 csum32;
if (!JBD2_HAS_INCOMPAT_FEATURE(j, JBD2_FEATURE_INCOMPAT_CSUM_V2))
return;
sequence = cpu_to_be32(sequence);
addr = kmap_atomic(page);
- csum = jbd2_chksum(j, j->j_csum_seed, (__u8 *),
- sizeof(sequence));
- csum = jbd2_chksum(j, csum, addr + offset_in_page(bh->b_data),
- bh->b_size);
+ csum32 = jbd2_chksum(j, j->j_csum_seed, (__u8 *),
+sizeof(sequence));
+ csum32 = jbd2_chksum(j, csum32, addr + offset_in_page(bh->b_data),
+bh->b_size);
kunmap_atomic(addr);
- tag->t_checksum = cpu_to_be32(csum);
+ tag->t_checksum = cpu_to_be16(csum32);
}
/*
* jbd2_journal_commit_transaction
diff --git a/fs/jbd2/recovery.c b/fs/jbd2/recovery.c
index 626846b..d4851464 100644
--- a/fs/jbd2/recovery.c
+++ b/fs/jbd2/recovery.c
@@ -399,18 +399,17 @@ static int jbd2_commit_block_csum_verify(journal_t *j,
void *buf)
static int jbd2_block_tag_csum_verify(journal_t *j, journal_block_tag_t *tag,
void *buf, __u32 sequence)
{
- __u32 provided, calculated;
+ __u32 csum32;
if (!JBD2_HAS_INCOMPAT_FEATURE(j, JBD2_FEATURE_INCOMPAT_CSUM_V2))
return 1;
sequence = cpu_to_be32(sequence);
- calculated = jbd2_chksum(j, j->j_csum_seed, (__u8 *),
-sizeof(sequence));
- calculated = jbd2_chksum(j, calculated, buf, j->j_blocksize);
- provided = be32_to_cpu(tag->t_checksum);
+ csum32 = jbd2_chksum(j, j->j_csum_seed, (__u8 *),
+sizeof(sequence));
+ csum32 = jbd2_chksum(j, csum32, buf, j->j_blocksize);
- return provided == cpu_to_be32(calculated);
+ return tag->t_checksum == cpu_to_be16(csum32);
}
static int do_one_pass(journal_t *journal,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] clk: Introduce userspace clock driver
On Fri, May 10, 2013 at 04:25:45PM -0700, Saravana Kannan wrote: > On 05/10/2013 04:06 PM, Sören Brinkmann wrote: > >On Fri, May 10, 2013 at 04:01:25PM -0700, Saravana Kannan wrote: > >>On 05/10/2013 03:18 PM, Mike Turquette wrote: > > >>>I think that Soren wants something with a stable interface that he can > >>>use for his Zynq use case. Regarding that, why not write an actual > >>>device driver to do what you want to do from userspace? > >> > >>Exposing clock control to userspace production use is a terrible > >>idea. A misbehaving userspace can easily kill the system. This is > >>not so try for GPIO. So, exposing GPIOs to userspace is relatively > >>less of a concern. > >Well, the FPGA clocks are only used by stuff in the FPGA. They cannot > >mess up the Linux on the A9s. I my use-case is kinda special. And people > >request functionality to easily adjust the frequency for their FPGA > >design in SW from Linux. > > How do you talk to the FPGA? What happens if the FPGA clock gets > turned off when the Linux is communicating with it? At the least the > I2C or whatever bus you used to talk to it could hang. You need to > explain more about why it's "special" before people might turn > around to give userspace ABI for clock control. > > >Nevertheless, there is no real protection from taking the driver I'm > >proposing to control the FPGA clocks to control a clock vital to the > >system. > > If we are talking about changing the kernel to control different > clocks, that true for any driver. > > If your idea of this driver was something that will take a clock > name and rate and change that clock's rate, then that's not a good > design. What Mike probably meant was a FPGA specific driver that > will only clk_get() the clocks related to the FPGA, and expose > options to userspace. Not the actual rate or enable/disable > capability. How? You do this through device tree. If you give that driver a different clock than the one it should get it might mess up. But this does apply to all device drivers. Assume you give you ethernet driver the wrong clock reference. When it tries to adjust the link speed it will mess up the clock. There is no protection against this. > For example, opening the device could cause clk_prepare_enable() and > closing it would cause clk_disable_unprepare(). In the current state: Enable/disable is explicitly done through the 'enable' file in sysfs. The driver takes care of that all enable/disable is balanced. I.e. prepare_enable is called if non-zero is written to enable and the driver didn't enable the clock yet and similar for disable. > You might have > ioctls to let userspace pick one of different modes of operation > with each corresponding to a different clock rate and other > corresponding FPGA configuration changes, etc. It's an FPGA and therefore fully programmable even during runtime. > That's just a rough > sketch. If you write such a driver, userspace can't misuse it to > mess with other clocks or leave the FPGA clock in a bad state. Currently, you cannot mess with the enable counts and whether the frequency is sane or not is up to the user. Unless you have a known design and appropriate DT bindings there is no way of knowing this upfront, which is kinda the point of having the driver. The first use case in my mind is just some simple bring up. Having the clocks let some LEDs blink and now let them blink faster/slower by changing the frequency. Sören -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/8] serial:st-asc: Add ST ASC driver.
On Wed, May 08, 2013 at 09:36:13AM -0700, Greg KH wrote: > On Wed, May 08, 2013 at 06:31:48PM +0200, Arnd Bergmann wrote: > > On Wednesday 08 May 2013, Greg KH wrote: > > > > just mention there is not hardware reason to not use the generic ttySx > > > > in place of ttyAS as we have only one IP that handle serial on this > > > > family of SoC > > > > > > > > personally I'll switch to ttySx > > > > > > Great, then you can use the same major/minor range as well, so there's > > > no more objection from me about this :) > > > > Does that work these days when you have kernel with multiple built-in > > uart drivers? > > It "should", as the major/minor registration should only happen when the > hardware is found, but I haven't tested it out, so I can't say for sure. serial stuff has never operated like that. More specifically, it's a limitation with the tty stuff that the way stuff works is that a tty driver can only drive a single bunch of contiguous minor numbers. No interleaving is allowed. That limitation has existed for years, and I don't see it going away. As long as that limitation exists, you can only ever have one serial driver driving a set of contiguous minor numbers. There has been an attempt to "work around" this by making the 8250 driver "special" which was a complete hack to get it to work. That was while I maintained this stuff and I outright refused to make one serial driver magically special. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] clk: Introduce userspace clock driver
On 05/10/2013 04:06 PM, Sören Brinkmann wrote: On Fri, May 10, 2013 at 04:01:25PM -0700, Saravana Kannan wrote: On 05/10/2013 03:18 PM, Mike Turquette wrote: I think that Soren wants something with a stable interface that he can use for his Zynq use case. Regarding that, why not write an actual device driver to do what you want to do from userspace? Exposing clock control to userspace production use is a terrible idea. A misbehaving userspace can easily kill the system. This is not so try for GPIO. So, exposing GPIOs to userspace is relatively less of a concern. Well, the FPGA clocks are only used by stuff in the FPGA. They cannot mess up the Linux on the A9s. I my use-case is kinda special. And people request functionality to easily adjust the frequency for their FPGA design in SW from Linux. How do you talk to the FPGA? What happens if the FPGA clock gets turned off when the Linux is communicating with it? At the least the I2C or whatever bus you used to talk to it could hang. You need to explain more about why it's "special" before people might turn around to give userspace ABI for clock control. Nevertheless, there is no real protection from taking the driver I'm proposing to control the FPGA clocks to control a clock vital to the system. If we are talking about changing the kernel to control different clocks, that true for any driver. If your idea of this driver was something that will take a clock name and rate and change that clock's rate, then that's not a good design. What Mike probably meant was a FPGA specific driver that will only clk_get() the clocks related to the FPGA, and expose options to userspace. Not the actual rate or enable/disable capability. For example, opening the device could cause clk_prepare_enable() and closing it would cause clk_disable_unprepare(). You might have ioctls to let userspace pick one of different modes of operation with each corresponding to a different clock rate and other corresponding FPGA configuration changes, etc. That's just a rough sketch. If you write such a driver, userspace can't misuse it to mess with other clocks or leave the FPGA clock in a bad state. -Saravana -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] clk: Introduce userspace clock driver
On Fri, May 10, 2013 at 03:18:10PM -0700, Mike Turquette wrote:
> On Fri, May 10, 2013 at 11:49 AM, Emilio López wrote:
> > Hi,
> >
> > El 10/05/13 15:15, Sören Brinkmann escribió:
> >> Hi Emilio,
> >>
> >> On Fri, May 10, 2013 at 02:44:44PM -0300, Emilio López wrote:
> >>> Hi,
> >>>
> >>> El 10/05/13 14:31, Soren Brinkmann escribió:
> The userspace clock driver can be used to expose clock controls through
> sysfs to userspace. The driver creates entries in /sys/class/clk.
>
> Signed-off-by: Soren Brinkmann
> ---
> .../devicetree/bindings/clock/clk-userspace.txt| 7 +
> drivers/clk/Kconfig| 9 ++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-userspace.c| 169
> +
> 4 files changed, 186 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/clk-userspace.txt
> create mode 100644 drivers/clk/clk-userspace.c
>
> diff --git a/Documentation/devicetree/bindings/clock/clk-userspace.txt
> b/Documentation/devicetree/bindings/clock/clk-userspace.txt
> new file mode 100644
> index 000..2d153c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/clk-userspace.txt
> @@ -0,0 +1,7 @@
> +
> +Example:
> + usclk: usclk {
> + compatible = "clk-userspace";
> + clocks = < 15>, <>;
> + clock-count = <2>;
> + };
> >>>
> >>> Does this belong on DT? It isn't describing hardware, is it?
> >> I guess, strictly speaking you are right. Do you have a good
> >> alternative?
> >
> > If this was part of the framework instead of a consumer, I suppose a
> > flag on the DT node defining the clock that indicates it should be
> > exported would be acceptable.
> >
> > Another possibility would be letting the user export what they need,
> > like GPIO does, see "Paths in Sysfs" in
> >
> > https://www.kernel.org/doc/Documentation/gpio.txt
> >
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 0357ac4..b35b62c 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -81,6 +81,15 @@ config COMMON_CLK_AXI_CLKGEN
> Support for the Analog Devices axi-clkgen pcore clock generator
> for Xilinx
> FPGAs. It is commonly used in Analog Devices' reference designs.
>
> +config COMMON_CLK_USERSPACE
> + bool "Userspace Clock Controls"
> + depends on OF
> + depends on SYSFS
> + help
> + ---help---
> + Expose clock controls through sysfs to userspace. Clocks are
> selected
> + through the device tree and the controls are exposed in
> + /sys/class/clk.
> endmenu
>
> source "drivers/clk/mvebu/Kconfig"
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index fa435bc..f2f68c8 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_COMMON_CLK)+= clk-fixed-rate.o
> obj-$(CONFIG_COMMON_CLK) += clk-gate.o
> obj-$(CONFIG_COMMON_CLK) += clk-mux.o
> obj-$(CONFIG_COMMON_CLK) += clk-composite.o
> +obj-$(CONFIG_COMMON_CLK_USERSPACE) += clk-userspace.o
>
> # SoCs specific
> obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
> diff --git a/drivers/clk/clk-userspace.c b/drivers/clk/clk-userspace.c
> new file mode 100644
> index 000..931cf92
> --- /dev/null
> +++ b/drivers/clk/clk-userspace.c
> @@ -0,0 +1,169 @@
> +/*
> + * Userspace clock driver
> + *
> + * Copyright (C) 2013 Xilinx
> + *
> + * Sören Brinkmann
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License v2 as published
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see
Re: [PATCH RFC] clk: Introduce userspace clock driver
On Fri, May 10, 2013 at 04:01:25PM -0700, Saravana Kannan wrote:
> On 05/10/2013 03:18 PM, Mike Turquette wrote:
> >On Fri, May 10, 2013 at 11:49 AM, Emilio López wrote:
> >>Hi,
> >>
> >>El 10/05/13 15:15, Sören Brinkmann escribió:
> >>>Hi Emilio,
> >>>
> >>>On Fri, May 10, 2013 at 02:44:44PM -0300, Emilio López wrote:
> Hi,
>
> El 10/05/13 14:31, Soren Brinkmann escribió:
> >The userspace clock driver can be used to expose clock controls through
> >sysfs to userspace. The driver creates entries in /sys/class/clk.
> >
> >Signed-off-by: Soren Brinkmann
> >---
> > .../devicetree/bindings/clock/clk-userspace.txt| 7 +
> > drivers/clk/Kconfig| 9 ++
> > drivers/clk/Makefile | 1 +
> > drivers/clk/clk-userspace.c| 169
> > +
> > 4 files changed, 186 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/clock/clk-userspace.txt
> > create mode 100644 drivers/clk/clk-userspace.c
> >
> >diff --git a/Documentation/devicetree/bindings/clock/clk-userspace.txt
> >b/Documentation/devicetree/bindings/clock/clk-userspace.txt
> >new file mode 100644
> >index 000..2d153c7
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/clock/clk-userspace.txt
> >@@ -0,0 +1,7 @@
> >+
> >+Example:
> >+ usclk: usclk {
> >+ compatible = "clk-userspace";
> >+ clocks = < 15>, <>;
> >+ clock-count = <2>;
> >+ };
>
> Does this belong on DT? It isn't describing hardware, is it?
> >>>I guess, strictly speaking you are right. Do you have a good
> >>>alternative?
> >>
> >>If this was part of the framework instead of a consumer, I suppose a
> >>flag on the DT node defining the clock that indicates it should be
> >>exported would be acceptable.
> >>
> >>Another possibility would be letting the user export what they need,
> >>like GPIO does, see "Paths in Sysfs" in
> >>
> >>https://www.kernel.org/doc/Documentation/gpio.txt
> >>
> >diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> >index 0357ac4..b35b62c 100644
> >--- a/drivers/clk/Kconfig
> >+++ b/drivers/clk/Kconfig
> >@@ -81,6 +81,15 @@ config COMMON_CLK_AXI_CLKGEN
> > Support for the Analog Devices axi-clkgen pcore clock generator
> > for Xilinx
> > FPGAs. It is commonly used in Analog Devices' reference designs.
> >
> >+config COMMON_CLK_USERSPACE
> >+ bool "Userspace Clock Controls"
> >+ depends on OF
> >+ depends on SYSFS
> >+ help
> >+ ---help---
> >+ Expose clock controls through sysfs to userspace. Clocks are
> >selected
> >+ through the device tree and the controls are exposed in
> >+ /sys/class/clk.
> > endmenu
> >
> > source "drivers/clk/mvebu/Kconfig"
> >diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> >index fa435bc..f2f68c8 100644
> >--- a/drivers/clk/Makefile
> >+++ b/drivers/clk/Makefile
> >@@ -8,6 +8,7 @@ obj-$(CONFIG_COMMON_CLK)+= clk-fixed-rate.o
> > obj-$(CONFIG_COMMON_CLK) += clk-gate.o
> > obj-$(CONFIG_COMMON_CLK) += clk-mux.o
> > obj-$(CONFIG_COMMON_CLK) += clk-composite.o
> >+obj-$(CONFIG_COMMON_CLK_USERSPACE) += clk-userspace.o
> >
> > # SoCs specific
> > obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
> >diff --git a/drivers/clk/clk-userspace.c b/drivers/clk/clk-userspace.c
> >new file mode 100644
> >index 000..931cf92
> >--- /dev/null
> >+++ b/drivers/clk/clk-userspace.c
> >@@ -0,0 +1,169 @@
> >+/*
> >+ * Userspace clock driver
> >+ *
> >+ * Copyright (C) 2013 Xilinx
> >+ *
> >+ * Sören Brinkmann
> >+ *
> >+ * This program is free software: you can redistribute it and/or modify
> >+ * it under the terms of the GNU General Public License v2 as published
> >by
> >+ * the Free Software Foundation.
> >+ *
> >+ * This program is distributed in the hope that it will be useful,
> >+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >+ * GNU General Public License for more details.
> >+ *
> >+ * You should have received a copy of the GNU General Public License
> >+ * along with this program. If not, see
Re: [PATCH v2 1/2] clk: Disable unused clocks after deferred probing is done
On 05/09/2013 11:45 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: On 11:35 Thu 09 May , Saravana Kannan wrote: With deferred probing, late_initcall() is too soon to declare a clock as unused. Wait for deferred probing to finish before declaring a clock as unused. Since deferred probing is done in late_initcall(), do the unused check to late_initcall_sync. Nack for both regulator & clk you can not known when the clock need to be shutdown example display splash screen set by the bootloader and display as module Best Regards, J. You are joking right? This is already done in the kernel. If you don't want that, please rip out the code and try to get that picked up. I'm sending out this patch for fix what's currently in the kernel for those who care for the current feature. Regards, Saravana -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] clk: Introduce userspace clock driver
On 05/10/2013 03:18 PM, Mike Turquette wrote:
On Fri, May 10, 2013 at 11:49 AM, Emilio López wrote:
Hi,
El 10/05/13 15:15, Sören Brinkmann escribió:
Hi Emilio,
On Fri, May 10, 2013 at 02:44:44PM -0300, Emilio López wrote:
Hi,
El 10/05/13 14:31, Soren Brinkmann escribió:
The userspace clock driver can be used to expose clock controls through
sysfs to userspace. The driver creates entries in /sys/class/clk.
Signed-off-by: Soren Brinkmann
---
.../devicetree/bindings/clock/clk-userspace.txt| 7 +
drivers/clk/Kconfig| 9 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-userspace.c| 169 +
4 files changed, 186 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/clk-userspace.txt
create mode 100644 drivers/clk/clk-userspace.c
diff --git a/Documentation/devicetree/bindings/clock/clk-userspace.txt
b/Documentation/devicetree/bindings/clock/clk-userspace.txt
new file mode 100644
index 000..2d153c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-userspace.txt
@@ -0,0 +1,7 @@
+
+Example:
+ usclk: usclk {
+ compatible = "clk-userspace";
+ clocks = < 15>, <>;
+ clock-count = <2>;
+ };
Does this belong on DT? It isn't describing hardware, is it?
I guess, strictly speaking you are right. Do you have a good
alternative?
If this was part of the framework instead of a consumer, I suppose a
flag on the DT node defining the clock that indicates it should be
exported would be acceptable.
Another possibility would be letting the user export what they need,
like GPIO does, see "Paths in Sysfs" in
https://www.kernel.org/doc/Documentation/gpio.txt
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 0357ac4..b35b62c 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -81,6 +81,15 @@ config COMMON_CLK_AXI_CLKGEN
Support for the Analog Devices axi-clkgen pcore clock generator for
Xilinx
FPGAs. It is commonly used in Analog Devices' reference designs.
+config COMMON_CLK_USERSPACE
+ bool "Userspace Clock Controls"
+ depends on OF
+ depends on SYSFS
+ help
+ ---help---
+ Expose clock controls through sysfs to userspace. Clocks are selected
+ through the device tree and the controls are exposed in
+ /sys/class/clk.
endmenu
source "drivers/clk/mvebu/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index fa435bc..f2f68c8 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_COMMON_CLK)+= clk-fixed-rate.o
obj-$(CONFIG_COMMON_CLK) += clk-gate.o
obj-$(CONFIG_COMMON_CLK) += clk-mux.o
obj-$(CONFIG_COMMON_CLK) += clk-composite.o
+obj-$(CONFIG_COMMON_CLK_USERSPACE) += clk-userspace.o
# SoCs specific
obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
diff --git a/drivers/clk/clk-userspace.c b/drivers/clk/clk-userspace.c
new file mode 100644
index 000..931cf92
--- /dev/null
+++ b/drivers/clk/clk-userspace.c
@@ -0,0 +1,169 @@
+/*
+ * Userspace clock driver
+ *
+ * Copyright (C) 2013 Xilinx
+ *
+ * Sören Brinkmann
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
[GIT PULL] Final round of SCSI updates for the 3.9+ merge window
This is the final round of SCSI patches for the merge window. It consists mostly of driver updates (bnx2fc, ibmfc, fnic, lpfc, be2iscsi, pm80xx, qla4x and ipr). There's also the power management updates that complete the patches in Jens' tree, an iscsi refcounting problem fix from the last pull, some dif handling in scsi_debug fixes, a few nice code cleanups and an error handling busy bug fix. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-for-linus The short changelog is Adheer Chandravanshi (2): qla4xxx: Assign values using correct datatype qla4xxx: Fix smatch warnings Akinobu Mita (4): scsi_debug: fix logical block provisioning support scsi_debug: clear correct memory region when LBPRZ is enabled scsi_debug: prohibit scsi_debug_unmap_granularity == scsi_debug_unmap_alignment scsi_debug: call map_region() and unmap_region() only when needed Armen Baloyan (1): qla2xxx: fix sparse warning "large integer implicitly truncated to unsigned type" Bhanu Prakash Gollapudi (5): bnx2fc: Bumped version to 1.0.14 bnx2fc: Update copyright dates bnx2fc: Fix race condition between IO completion and abort bnx2fc: Include chip number in the symbolic name bnx2fc: Enable cached tasks to improve performance Brian King (5): ibmvfc: Driver version 1.0.11 ibmvfc: Suppress ABTS if target gone ibmvfc: Send cancel when link is down ibmvfc: Support FAST_IO_FAIL in EH handlers ibmvfc: Properly set cancel flags when cancelling abort Chad Dupuis (1): qla2xxx: Update firmware link in Kconfig file. Dan Carpenter (3): libosd: remover duplicate __bitwise annotation megaraid_sas: release lock on error path csiostor: off by one error Fengguang Wu (1): qla2xxx: qla2x00_sp_compl can be static. Hannes Reinecke (1): Handle MLQUEUE busy response in scsi_send_eh_cmnd Hiral Patel (3): fnic: Incremented driver version fnic: Kernel panic due to FIP mode misconfiguration fnic: FIP VLAN Discovery Feature Support James Bottomley (3): sas: unify the pointlessly separated enums sas_dev_type and sas_device_type lpfc: fix up Kconfig dependencies sd: fix array cache flushing bug causing performance problems James Smart (22): lpfc 8.3.39: Update lpfc version for 8.3.39 driver release lpfc 8.3.39: Fixed driver handling of CLEAR_LA with NPIV enabled causing SID=0 frames out lpfc 8.3.39: Reduced tmo value set to FLOGI WQE for quick recovery from FLOGI sequence timeout lpfc 8.3.39: Add log message when completes with clean address bit set to zero lpfc 8.3.39: Fixed driver vector mapping to CPU affinity lpfc 8.3.39: Fixed iocb flags not being reset for scsi commands lpfc 8.3.39: Fixed system panic during EEH recovery due to midlayer acting on outstanding I/O lpfc 8.3.39: Fixed not returning FAILED status when SCSI invoking host reset handler failed lpfc 8.3.39: Fixed bad book keeping in posting els sgls to port lpfc 8.3.39: Fixed deadlock between hbalock and nlp_lock use lpfc 8.3.39: Fixed BlockGuard to take advantage of rdprotect/wrprotect info when available lpfc 8.3.39: Reduced spinlock contention on SCSI buffer list lpfc 8.3.39: Fixed crash when processing bsg's sg list with high memory pages lpfc 8.3.39: Remove lpfc_fcp_look_ahead module parameter lpfc 8.3.39: Fix driver issues with SCSI Host reset lpfc 8.3.39: Doorbell formation information logged in dual-chute mode WQ and RQ setup lpfc 8.3.39: Fix driver issues with large s/g lists for BlockGuard lpfc 8.3.39: Fix driver issues with large lpfc_sg_seg_cnt values lpfc 8.3.39: Fixed pt2pt and loop discovery problems on topology changes. lpfc 8.3.39: Remove driver dependency on HZ lpfc 8.3.39: Fixed BlockGuard error reporting lpfc 8.3.39: Fixed VPI allocation issues after firmware dump is performed Jayamohan Kallickal (16): be2iscsi: Bump the driver version to 10.0.467.0 be2iscsi: Fix issue in passing the exp_cmdsn and max_cmdsn be2scsi: Update copyright dates to 2013 be2iscsi: Fix checking Adapter state while establishing CXN be2iscsi: Fix dynamic CID allocation Mechanism in driver be2iscsi : Fix the NOP-In handling code path be2iscsi: Fix the Port Link Status issue be2iscsi: Fix displaying the Active Session Count from driver be2iscsi: Fix displaying the FW Version from driver. be2iscsi: Fix support for DEFQ extension be2iscsi: Fix MACRO for checking the adapter type be2iscsi: Fix freeing CXN specific driver resources. be2iscsi: Fix MSIX support in SKH-R to 32 be2iscsi: Fix MBX Command issues be2iscsi: Fix returning Failure when MBX fails with Insufficient buffer error be2iscsi: Fix lack of uninitialize pattern to FW Jeremy Higdon (1):
Re: is L1 really disabled in iwlwifi
[+cc Rafael, other pci_disable_link_state() users]
On Wed, May 01, 2013 at 11:13:15AM -0600, Bjorn Helgaas wrote:
> On Wed, May 1, 2013 at 2:31 AM, Emmanuel Grumbach wrote:
> > [from Bjorn's mail]
> >> In Emmanuel's case, we don't get _OSC control, so
> >> pci_disable_link_state() does nothing.
> >
> > Right, but this is true with the specific log I sent to you. Is it
> > possible that another platform / BIOS, we *will* get _OSC control and
> > that pci_disable_link_state() will actually do something? In that case
> > I would prefer not to remove the call to pcie_disable_link_state().
>
> Yes, absolutely, on many platforms we will get _OSC control, and
> pci_disable_link_state() will work as expected. The problem is that
> the driver doesn't have a good way to know whether pci_disable_link()
> did anything or not.
>
> Today I think we have:
>
> 1) If the BIOS grants the OS permission to control PCIe services via
> _OSC, pci_disable_link_state() works and L1 will be disabled.
>
> 2) If the BIOS does not grant permission, pci_disable_link_state()
> does nothing and L1 may be enabled or not depending on what
> configuration the BIOS did.
>
> If the device really doesn't work reliably when L1 is enabled, we're
> currently at the mercy of the BIOS -- if the BIOS enables L1 but
> doesn't grant us permission via _OSC, L1 will remain enabled (as it is
> on your system).
I propose the following patch. Any comments?
commit cd11e3f87c4d2777cf8921c0454500c9baa54b46
Author: Bjorn Helgaas
Date: Fri May 10 15:54:35 2013 -0600
PCI/ASPM: Allow drivers to disable ASPM unconditionally
Some devices have hardware problems related to using ASPM. Drivers for
these devices use pci_disable_link_state() to prevent their device from
entering L0s or L1. But on platforms where the OS doesn't have permission
to manage ASPM, pci_disable_link_state() does nothing, and the driver has
no way to know this.
Therefore, if the BIOS enables ASPM but declines (either via the FADT
ACPI_FADT_NO_ASPM bit or the _OSC method) to allow the OS to manage it,
the device can still use ASPM and trip over the hardware issue.
This patch makes pci_disable_link_state() disable ASPM unconditionally,
regardless of whether the OS has permission to manage ASPM in general.
Reported-by: Emmanuel Grumbach
Reference:
https://lkml.kernel.org/r/canux_p3f5yhbzx3wgu-j1agpbxb_t9bis2erhvkkfmtdvza...@mail.gmail.com
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=57331
Signed-off-by: Bjorn Helgaas
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index d320df6..9ef4ab8 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -718,15 +718,11 @@ void pcie_aspm_powersave_config_link(struct pci_dev *pdev)
* pci_disable_link_state - disable pci device's link state, so the link will
* never enter specific states
*/
-static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem,
-bool force)
+static void __pci_disable_link_state(struct pci_dev *pdev, int state, bool sem)
{
struct pci_dev *parent = pdev->bus->self;
struct pcie_link_state *link;
- if (aspm_disabled && !force)
- return;
-
if (!pci_is_pcie(pdev))
return;
@@ -757,13 +753,13 @@ static void __pci_disable_link_state(struct pci_dev
*pdev, int state, bool sem,
void pci_disable_link_state_locked(struct pci_dev *pdev, int state)
{
- __pci_disable_link_state(pdev, state, false, false);
+ __pci_disable_link_state(pdev, state, false);
}
EXPORT_SYMBOL(pci_disable_link_state_locked);
void pci_disable_link_state(struct pci_dev *pdev, int state)
{
- __pci_disable_link_state(pdev, state, true, false);
+ __pci_disable_link_state(pdev, state, true);
}
EXPORT_SYMBOL(pci_disable_link_state);
@@ -781,7 +777,7 @@ void pcie_clear_aspm(struct pci_bus *bus)
__pci_disable_link_state(child, PCIE_LINK_STATE_L0S |
PCIE_LINK_STATE_L1 |
PCIE_LINK_STATE_CLKPM,
-false, true);
+false);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: x86_mce: mce_start uses number of phsical cores instead of logical cores
> So only one socket gets the machine check. So is there still a problem but > the fix will be different? > I think the error inject creates a real machine check, but since each CPU has > its own memory controller, > the machine check may only send to the CPU the error happens. If there is a real machine check, then it must go to all logical cpus. If it doesn't get there, then there is a h/w (or possibly f/w configuration) problem. Interesting that few others have seen this. Perhaps because it only shows up in a fatal path and the machine is crashing anyway. A Google search for the "Some CPUs didn't answer in synchronization" message does have a few hits that look relevant, but following a few didn't give me enough details on machine configuration to tell whether they match what you are seeing. If there are many machines that do this - then we may need a workaround in Linux code for them. Who is the manufacturer of the motherboard and/or system you are using? But the current code that expects to see the machine check on all logical cpus is correct (and works as is on other machines that are following the specification). -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ttyprintk: Fix NULL pointer deref by setting tty_port ops after initializing port
tty_port_init() zeroes out the tty port, which means that we have to set the
ops pointer /after/, not before this call. Otherwise, tty_port_open will crash
when it tries to deref ops, which is now a NULL pointer.
Signed-off-by: Darrick J. Wong
---
drivers/char/ttyprintk.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/ttyprintk.c b/drivers/char/ttyprintk.c
index 4945bd3..d5d2e4a 100644
--- a/drivers/char/ttyprintk.c
+++ b/drivers/char/ttyprintk.c
@@ -179,7 +179,6 @@ static int __init ttyprintk_init(void)
{
int ret = -ENOMEM;
- tpk_port.port.ops = _ops;
mutex_init(_port.port_write_mutex);
ttyprintk_driver = tty_alloc_driver(1,
@@ -190,6 +189,7 @@ static int __init ttyprintk_init(void)
return PTR_ERR(ttyprintk_driver);
tty_port_init(_port.port);
+ tpk_port.port.ops = _ops;
ttyprintk_driver->driver_name = "ttyprintk";
ttyprintk_driver->name = "ttyprintk";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] clk: Introduce userspace clock driver
On Fri, May 10, 2013 at 11:49 AM, Emilio López wrote:
> Hi,
>
> El 10/05/13 15:15, Sören Brinkmann escribió:
>> Hi Emilio,
>>
>> On Fri, May 10, 2013 at 02:44:44PM -0300, Emilio López wrote:
>>> Hi,
>>>
>>> El 10/05/13 14:31, Soren Brinkmann escribió:
The userspace clock driver can be used to expose clock controls through
sysfs to userspace. The driver creates entries in /sys/class/clk.
Signed-off-by: Soren Brinkmann
---
.../devicetree/bindings/clock/clk-userspace.txt| 7 +
drivers/clk/Kconfig| 9 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-userspace.c| 169
+
4 files changed, 186 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/clk-userspace.txt
create mode 100644 drivers/clk/clk-userspace.c
diff --git a/Documentation/devicetree/bindings/clock/clk-userspace.txt
b/Documentation/devicetree/bindings/clock/clk-userspace.txt
new file mode 100644
index 000..2d153c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-userspace.txt
@@ -0,0 +1,7 @@
+
+Example:
+ usclk: usclk {
+ compatible = "clk-userspace";
+ clocks = < 15>, <>;
+ clock-count = <2>;
+ };
>>>
>>> Does this belong on DT? It isn't describing hardware, is it?
>> I guess, strictly speaking you are right. Do you have a good
>> alternative?
>
> If this was part of the framework instead of a consumer, I suppose a
> flag on the DT node defining the clock that indicates it should be
> exported would be acceptable.
>
> Another possibility would be letting the user export what they need,
> like GPIO does, see "Paths in Sysfs" in
>
> https://www.kernel.org/doc/Documentation/gpio.txt
>
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 0357ac4..b35b62c 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -81,6 +81,15 @@ config COMMON_CLK_AXI_CLKGEN
Support for the Analog Devices axi-clkgen pcore clock generator for
Xilinx
FPGAs. It is commonly used in Analog Devices' reference designs.
+config COMMON_CLK_USERSPACE
+ bool "Userspace Clock Controls"
+ depends on OF
+ depends on SYSFS
+ help
+ ---help---
+ Expose clock controls through sysfs to userspace. Clocks are selected
+ through the device tree and the controls are exposed in
+ /sys/class/clk.
endmenu
source "drivers/clk/mvebu/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index fa435bc..f2f68c8 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_COMMON_CLK)+= clk-fixed-rate.o
obj-$(CONFIG_COMMON_CLK) += clk-gate.o
obj-$(CONFIG_COMMON_CLK) += clk-mux.o
obj-$(CONFIG_COMMON_CLK) += clk-composite.o
+obj-$(CONFIG_COMMON_CLK_USERSPACE) += clk-userspace.o
# SoCs specific
obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
diff --git a/drivers/clk/clk-userspace.c b/drivers/clk/clk-userspace.c
new file mode 100644
index 000..931cf92
--- /dev/null
+++ b/drivers/clk/clk-userspace.c
@@ -0,0 +1,169 @@
+/*
+ * Userspace clock driver
+ *
+ * Copyright (C) 2013 Xilinx
+ *
+ * Sören Brinkmann
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License v2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
RE: x86_mce: mce_start uses number of phsical cores instead of logical cores
You are right, here is the boot information confirming this: smpboot: Booting Node 0, Processors #1 #2 #3 #4 #5 OK smpboot: Booting Node 1, Processors #6 #7 #8 #9 #10 #11 OK smpboot: Booting Node 0, Processors #12 #13 #14 #15 #16 #17 OK smpboot: Booting Node 1, Processors #18 #19 #20 #21 #22 #23 OK So only one socket gets the machine check. So is there still a problem but the fix will be different? I think the error inject creates a real machine check, but since each CPU has its own memory controller, the machine check may only send to the CPU the error happens. Ming -Original Message- From: Luck, Tony [mailto:tony.l...@intel.com] Sent: Friday, May 10, 2013 2:05 PM To: Ming Lei; linux-kernel@vger.kernel.org Cc: mche...@redhat.com; b...@alien8.de Subject: RE: x86_mce: mce_start uses number of phsical cores instead of logical cores > I used intel edac error injector and saw the same problem. I actually > wrote down the core numbers and I saw mce got to 0-5 and 12-17, but not the > others. I have 2 sockets, 24 logical cores. Mauro: How does the EDAC injector work on E5645 (Westmere-EP)? Does it create a real error in memory that the processor then accesses ... tripping a machine check? The mapping of Linux logical cpu numbers to physical socket/core/thread is somewhat as the mercy of the order that the BIOS lists things in its tables. But those numbers look very much like you just saw the machine check on one socket. Look at /proc/cpuinfo to be sure. If you run "grep ^physical /proc/cpuinfo" I think you'll see output like this (confirming that only socket 0 saw the machine check): physical id : 0 physical id : 0 physical id : 0 physical id : 0 physical id : 0 physical id : 0 physical id : 1 physical id : 1 physical id : 1 physical id : 1 physical id : 1 physical id : 1 physical id : 0 physical id : 0 physical id : 0 physical id : 0 physical id : 0 physical id : 0 physical id : 1 physical id : 1 physical id : 1 physical id : 1 physical id : 1 physical id : 1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/8] pci: Add pci_hp_reset_slot
On Tue, 2013-05-07 at 20:57 -0600, Alex Williamson wrote:
> Provide an interface to get to hotplug controller reset_slot callback
>
> Signed-off-by: Alex Williamson
> ---
> drivers/pci/hotplug/pci_hotplug_core.c | 24
> include/linux/pci_hotplug.h|8
> 2 files changed, 32 insertions(+)
>
> diff --git a/drivers/pci/hotplug/pci_hotplug_core.c
> b/drivers/pci/hotplug/pci_hotplug_core.c
> index 202f4a9..1d0fee4 100644
> --- a/drivers/pci/hotplug/pci_hotplug_core.c
> +++ b/drivers/pci/hotplug/pci_hotplug_core.c
> @@ -537,6 +537,29 @@ int __must_check pci_hp_change_slot_info(struct
> hotplug_slot *hotplug,
> return 0;
> }
>
> +/**
> + * pci_hp_reset_slot - reset slot
> + *
> + * @hotplug: pointer to hotplug slot to reset
> + * @probe: reset slot (0) or just probe
> + *
> + * Returns 0 if successful, anything else for an error.
> + */
> +int pci_hp_reset_slot(struct hotplug_slot *hotplug, int probe)
> +{
> + int result = -ENOTTY;
> +
> + if (!hotplug || !try_module_get(hotplug->ops->owner))
> + return result;
> +
> + if (hotplug->ops->reset_slot)
> + result = hotplug->ops->reset_slot(hotplug, probe);
> +
> + module_put(hotplug->ops->owner);
> +
> + return result;
> +}
> +
> static int __init pci_hotplug_init (void)
> {
> int result;
> @@ -570,3 +593,4 @@ MODULE_PARM_DESC(debug, "Debugging mode enabled or not");
> EXPORT_SYMBOL_GPL(__pci_hp_register);
> EXPORT_SYMBOL_GPL(pci_hp_deregister);
> EXPORT_SYMBOL_GPL(pci_hp_change_slot_info);
> +EXPORT_SYMBOL_GPL(pci_hp_reset_slot);
> diff --git a/include/linux/pci_hotplug.h b/include/linux/pci_hotplug.h
> index 0d3a604..d771cee 100644
> --- a/include/linux/pci_hotplug.h
> +++ b/include/linux/pci_hotplug.h
> @@ -135,6 +135,14 @@ extern int __pci_hp_register(struct hotplug_slot *slot,
> struct pci_bus *pbus,
> extern int pci_hp_deregister(struct hotplug_slot *slot);
> extern int __must_check pci_hp_change_slot_info (struct hotplug_slot
> *slot,
>struct hotplug_slot_info
> *info);
> +#ifdef CONFIG_HOTPLUG_PCI
> +int pci_hp_reset_slot(struct hotplug_slot *slot, int probe);
> +#else
> +static inline int pci_hp_reset_slot(struct hotplug_slot *slot, int probe)
> +{
> + return -ENOTTY;
> +}
> +#endif
>
> /* use a define to avoid include chaining to get THIS_MODULE & friends */
> #define pci_hp_register(slot, pbus, devnr, name) \
>
There's a bug here when CONFIG_HOTPLUG_PCI=m. I'll fix and repost.
self NAK. Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: NOHZ: WARNING: at arch/x86/kernel/smp.c:123 native_smp_send_reschedule
On Fri, May 10, 2013 at 06:23:40PM +0200, Borislav Petkov wrote:
> On Fri, May 10, 2013 at 05:43:50PM +0200, Frederic Weisbecker wrote:
> > So either interrupts are spuriously enabled early, or ts->tick_stopped
> > is not correctly initialized.
>
> Hmm, it can't be interrupts disabled because add_timer_on() does
> spin_lock_irqsave() before calling wake_up_nohz_cpu()... Maybe something
> like the below could help check this...
Right, by the time we call wake_up_nohz_cpu(), irqs can't be enabled, but may
be they were enabled before in start_secondary().
>
> Although AFAICT, we're enabling interrupts much later in
> start_secondary, even after we've set the bit in the online mask.
Right.
>
> ---
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 9c73b51817e4..1b679b0fa57a 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -201,6 +201,8 @@ static void __cpuinit smp_callin(void)
>*/
> setup_vector_irq(smp_processor_id());
>
> + WARN_ON(!irqs_disabled());
> +
The problem is that it doesn't catch issues with irqs that have been enabled
before in start_secondary(), then re-disabled somewhow. Warning on offline CPU
from the place
that disables the tick should catch the issue.
Jiri, could you test the following patch? I also added some code to dump
the value of ts->tick_stopped, in case it's not well initialized or something.
Note this may give you spurious warning when you unplug a CPU or when you
shutdown the
system. But it's interesting if it dumps something in the boot.
Thanks!
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 58453b8..9853125 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -616,8 +616,17 @@ static bool wake_up_full_nohz_cpu(int cpu)
{
if (tick_nohz_full_cpu(cpu)) {
if (cpu != smp_processor_id() ||
- tick_nohz_tick_stopped())
+ tick_nohz_tick_stopped()) {
+ if (!cpu_online(cpu)) {
+ static int printed = 0;
+ if (!printed) {
+ printk("src: %d dst: %d stopped: %d\n",
cpu, smp_processor_id(), tick_nohz_tick_stopped());
+ dump_stack();
+ printed = 1;
+ }
+ }
smp_send_reschedule(cpu);
+ }
return true;
}
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index bc67d42..abfa8c3 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -650,6 +650,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched
*ts,
ts->last_tick = hrtimer_get_expires(>sched_timer);
ts->tick_stopped = 1;
+ WARN_ON_ONCE(!cpu_online(cpu));
trace_tick_stop(1, " ");
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 3.6.11.3
I'm announcing the release of the 3.6.11.3 kernel. The updated 3.6.11.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git v3.6-stable The patch can be downloaded at: https://www.kernel.org/pub/linux/kernel/projects/rt/3.6/stable/patch-3.6.11.3.xz thanks, -- Steve Makefile |2 +- arch/alpha/kernel/sys_nautilus.c |5 ++ arch/arm/include/asm/hardware/iop3xx.h |2 +- arch/arm/kernel/perf_event.c |5 +- arch/arm/kernel/sched_clock.c |4 +- arch/arm/mach-imx/clk-imx35.c |2 + arch/arm/mm/cache-feroceon-l2.c|1 + arch/arm/mm/proc-arm920.S |2 +- arch/arm/mm/proc-arm926.S |2 +- arch/arm/mm/proc-mohawk.S |2 +- arch/arm/mm/proc-sa1100.S |2 +- arch/arm/mm/proc-v6.S |2 +- arch/arm/mm/proc-xsc3.S|2 +- arch/arm/mm/proc-xscale.S |2 +- arch/powerpc/platforms/pseries/lpar.c |8 ++- arch/x86/boot/compressed/Makefile |5 +- arch/x86/include/asm/kvm_host.h|4 +- arch/x86/include/asm/paravirt.h|5 +- arch/x86/include/asm/paravirt_types.h |2 + arch/x86/include/asm/syscall.h |4 +- arch/x86/include/asm/tlb.h |2 +- arch/x86/kernel/cpu/perf_event_intel.c | 20 -- arch/x86/kernel/paravirt.c | 25 arch/x86/kvm/lapic.c |2 +- arch/x86/kvm/x86.c | 45 ++--- arch/x86/lguest/boot.c |1 + arch/x86/mm/fault.c|6 +- arch/x86/mm/pgtable.c |7 ++ arch/x86/xen/mmu.c |1 + block/blk-sysfs.c |2 + crypto/algif_hash.c|2 + crypto/algif_skcipher.c|1 + crypto/gcm.c | 17 - drivers/ata/ata_piix.c | 11 drivers/ata/libata-core.c |4 ++ drivers/base/regmap/regcache-rbtree.c |2 +- drivers/char/hpet.c| 14 +--- drivers/cpufreq/exynos-cpufreq.c |4 +- drivers/crypto/ux500/cryp/cryp_core.c |2 +- drivers/eisa/pci_eisa.c| 67 ++-- drivers/gpu/drm/i915/intel_display.c |9 +++ drivers/gpu/drm/mgag200/mgag200_mode.c | 13 +--- drivers/gpu/drm/udl/udl_connector.c|4 ++ drivers/hwspinlock/hwspinlock_core.c |2 + drivers/mtd/mtdchar.c | 38 ++- drivers/net/bonding/bond_main.c| 10 +++ drivers/net/can/mcp251x.c | 10 ++- drivers/net/can/sja1000/sja1000_of_platform.c | 31 + drivers/net/ethernet/atheros/atl1e/atl1e.h |2 +- drivers/net/ethernet/atheros/atl1e/atl1e_main.c|1 + drivers/net/ethernet/broadcom/tg3.c| 18 +- drivers/net/ethernet/broadcom/tg3.h|2 + drivers/net/ethernet/realtek/r8169.c | 28 +++- .../net/wireless/ath/ath9k/ar9580_1p0_initvals.h |2 +- drivers/net/wireless/ath/ath9k/htc_drv_init.c |2 +- drivers/net/wireless/b43/phy_n.c |3 +- drivers/net/wireless/mwifiex/cfg80211.c|3 +- drivers/net/wireless/rt2x00/rt2x00pci.c|4 +- drivers/pci/pcie/portdrv_pci.c | 13 drivers/platform/x86/msi-wmi.c |4 +- drivers/remoteproc/Kconfig |2 +- drivers/remoteproc/remoteproc_core.c |4 +- drivers/scsi/libsas/sas_expander.c | 12 drivers/spi/spi-mpc512x-psc.c |2 +- drivers/spi/spi-s3c64xx.c | 41 +++- drivers/ssb/driver_chipcommon_pmu.c| 29 + drivers/target/target_core_alua.c |3 + drivers/thermal/thermal_sys.c |1 + drivers/tty/tty_io.c | 14 +++- drivers/vfio/pci/vfio_pci.c|3 +- drivers/video/fbmem.c | 40 fs/aio.c |2 +- fs/btrfs/tree-log.c| 48 -- fs/cifs/connect.c
[RFC PATCHv2 1/2] drivers: power: Add watchdog timer to catch drivers which lockup during suspend/resume.
From: Benoit Goby
Below is a patch from android kernel that detects a driver suspend/resume
lockup and captures dump in the kernel log. Please review and provide
comments.
Rather than hard-lock the kernel, dump the suspend/resume thread stack and
BUG() when a driver takes too long to suspend/resume. The timeout is set to
12 seconds to be longer than the usbhid 10 second timeout.
Exclude from the watchdog the time spent waiting for children that
are resumed asynchronously and time every device, whether or not they
resumed synchronously.
This patch is targeted for mobile devices where a suspend/resume lockup
could cause a system reboot and catch user's attention. Information
about failing device can later be retrieved from captured log in
subsequent boot session.
The hardware watchdog timer is likely suspended during this time and
couldn't be relied upon. The soft-lockup detector would eventually tell
that tasks are not scheduled, but would provide little context as to why.
The patch hence uses system timer and assumes it is still active while the
devices are suspended/resumed.
Cc: Android Kernel Team
Cc: Colin Cross
Cc: Todd Poynor
Cc: San Mehat
Cc: Benoit Goby
Cc: John Stultz
Cc: Pavel Machek
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Greg Kroah-Hartman
Original-author: San Mehat
Signed-off-by: Benoit Goby
[zoran.marko...@linaro.org: Changed printk(KERN_EMERG,...) to pr_emerg(...),
tweaked commit message. Minor changes to merge code into kernel tip.]
Signed-off-by: Zoran Markovic
---
drivers/base/power/main.c | 66 +
1 file changed, 66 insertions(+)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 5a9b656..a6a02c0 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -29,6 +29,8 @@
#include
#include
#include
+#include
+
#include "../base.h"
#include "power.h"
@@ -54,6 +56,12 @@ struct suspend_stats suspend_stats;
static DEFINE_MUTEX(dpm_list_mtx);
static pm_message_t pm_transition;
+struct dpm_watchdog {
+ struct device *dev;
+ struct task_struct *tsk;
+ struct timer_list timer;
+};
+
static int async_error;
/**
@@ -384,6 +392,56 @@ static int dpm_run_callback(pm_callback_t cb, struct
device *dev,
return error;
}
+/**
+ * dpm_wd_handler - Driver suspend / resume watchdog handler.
+ *
+ * Called when a driver has timed out suspending or resuming.
+ * There's not much we can do here to recover so BUG() out for
+ * a crash-dump
+ */
+static void dpm_wd_handler(unsigned long data)
+{
+ struct dpm_watchdog *wd = (void *)data;
+ struct device *dev = wd->dev;
+ struct task_struct *tsk = wd->tsk;
+
+ dev_emerg(dev, " DPM device timeout \n");
+ show_stack(tsk, NULL);
+
+ BUG();
+}
+
+/**
+ * dpm_wd_set - Enable pm watchdog for given device.
+ * @wd: Watchdog. Must be allocated on the stack.
+ * @dev: Device to handle.
+ */
+static void dpm_wd_set(struct dpm_watchdog *wd, struct device *dev)
+{
+ struct timer_list *timer = >timer;
+
+ wd->dev = dev;
+ wd->tsk = get_current();
+
+ init_timer_on_stack(timer);
+ timer->expires = jiffies + HZ * 12;
+ timer->function = dpm_wd_handler;
+ timer->data = (unsigned long)wd;
+ add_timer(timer);
+}
+
+/**
+ * dpm_wd_clear - Disable pm watchdog.
+ * @wd: Watchdog to disable.
+ */
+static void dpm_wd_clear(struct dpm_watchdog *wd)
+{
+ struct timer_list *timer = >timer;
+
+ del_timer_sync(timer);
+ destroy_timer_on_stack(timer);
+}
+
/*- Resume routines -*/
/**
@@ -570,6 +628,7 @@ static int device_resume(struct device *dev, pm_message_t
state, bool async)
pm_callback_t callback = NULL;
char *info = NULL;
int error = 0;
+ struct dpm_watchdog wd;
TRACE_DEVICE(dev);
TRACE_RESUME(0);
@@ -585,6 +644,7 @@ static int device_resume(struct device *dev, pm_message_t
state, bool async)
* a resumed device, even if the device hasn't been completed yet.
*/
dev->power.is_prepared = false;
+ dpm_wd_set(, dev);
if (!dev->power.is_suspended)
goto Unlock;
@@ -636,6 +696,7 @@ static int device_resume(struct device *dev, pm_message_t
state, bool async)
Unlock:
device_unlock(dev);
+ dpm_wd_clear();
Complete:
complete_all(>power.completion);
@@ -1053,6 +1114,7 @@ static int __device_suspend(struct device *dev,
pm_message_t state, bool async)
pm_callback_t callback = NULL;
char *info = NULL;
int error = 0;
+ struct dpm_watchdog wd;
dpm_wait_for_children(dev, async);
@@ -1076,6 +1138,8 @@ static int __device_suspend(struct device *dev,
pm_message_t state, bool async)
if (dev->power.syscore)
goto Complete;
+ dpm_wd_set(, dev);
+
[RFC PATCHv2 2/2] PM: compile-time configuration of device suspend/resume watchdogs.
Power management debug option to configure device suspend/resume watchdogs.
Available options are:
1. Enable/disable the feature.
2. Select triggered watchdog action between:
- system panic (default)
- dump stacktrace
- log event
3. Select timeout value for the watchdog(s).
Minor changes were made to watchdog code to accommodate this feature.
Cc: Android Kernel Team
Cc: Colin Cross
Cc: Todd Poynor
Cc: San Mehat
Cc: Benoit Goby
Cc: John Stultz
Cc: Pavel Machek
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Greg Kroah-Hartman
Signed-off-by: Zoran Markovic
---
drivers/base/power/main.c | 37 ++
kernel/power/Kconfig | 48 +
2 files changed, 77 insertions(+), 8 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index a6a02c0..8e0bb33 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -392,6 +392,26 @@ static int dpm_run_callback(pm_callback_t cb, struct
device *dev,
return error;
}
+#ifdef CONFIG_DPM_WD
+/**
+ * dpm_wd_action - recovery from suspend/resume watchdog timeout
+ * @wd: Watchdog. Must be allocated on the stack.
+ */
+#if defined(CONFIG_DPM_WD_ACTION_STACKTRACE)
+static inline void dpm_wd_action(struct dpm_watchdog *wd)
+{
+ show_stack(wd->tsk, NULL);
+}
+#elif defined(CONFIG_DPM_WD_ACTION_PANIC)
+static inline void dpm_wd_action(struct dpm_watchdog *wd)
+{
+ panic("%s: unrecoverable failure\n", dev_name(wd->dev));
+}
+#else /* CONFIG_DPM_WD_ACTION_LOG */
+/* event already logged in dpm_wd_handler() */
+#define dpm_wd_action(x)
+#endif
+
/**
* dpm_wd_handler - Driver suspend / resume watchdog handler.
*
@@ -402,13 +422,9 @@ static int dpm_run_callback(pm_callback_t cb, struct
device *dev,
static void dpm_wd_handler(unsigned long data)
{
struct dpm_watchdog *wd = (void *)data;
- struct device *dev = wd->dev;
- struct task_struct *tsk = wd->tsk;
-
- dev_emerg(dev, " DPM device timeout \n");
- show_stack(tsk, NULL);
- BUG();
+ dev_emerg(wd->dev, " DPM device timeout \n");
+ dpm_wd_action(wd);
}
/**
@@ -424,14 +440,15 @@ static void dpm_wd_set(struct dpm_watchdog *wd, struct
device *dev)
wd->tsk = get_current();
init_timer_on_stack(timer);
- timer->expires = jiffies + HZ * 12;
+ /* use same timeout value for both suspend and resume */
+ timer->expires = jiffies + HZ * CONFIG_DPM_WD_TIMEOUT;
timer->function = dpm_wd_handler;
timer->data = (unsigned long)wd;
add_timer(timer);
}
/**
- * dpm_wd_clear - Disable pm watchdog.
+ * dpm_wd_clear - Disable suspend/resume watchdog.
* @wd: Watchdog to disable.
*/
static void dpm_wd_clear(struct dpm_watchdog *wd)
@@ -441,6 +458,10 @@ static void dpm_wd_clear(struct dpm_watchdog *wd)
del_timer_sync(timer);
destroy_timer_on_stack(timer);
}
+#else
+#define dpm_wd_set(x, y)
+#define dpm_wd_clear(x)
+#endif
/*- Resume routines -*/
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index edc8bdd..339caa1 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -179,6 +179,54 @@ config PM_SLEEP_DEBUG
def_bool y
depends on PM_DEBUG && PM_SLEEP
+config DPM_WD
+ bool "Device suspend/resume watchdog"
+ depends on PM_DEBUG
+ ---help---
+ Sets up a watchdog timer to capture drivers that are
+ locked up attempting to suspend/resume a device.
+ A detected lockup causes a configurable watchdog action,
+ such as logging the event, dumping the stack trace or
+ kernel panic.
+
+choice
+ prompt "Watchdog recovery action"
+ default DPM_WD_ACTION_PANIC
+ depends on DPM_WD
+ ---help---
+ Select recovery action triggered by suspend/resume watchdog.
+
+config DPM_WD_ACTION_PANIC
+ bool "System panic"
+ ---help---
+ When selected, a lockup during device's suspend or
+ resume would cause a system panic. This would immediately
+ capture user's attention. Panic message can be observed in
+ subsequent boot session using pstore.
+
+config DPM_WD_ACTION_STACKTRACE
+ bool "Dump stack"
+ ---help---
+ When selected, a lockup during device's suspend or
+ resume would cause the caller's stack to be
+ captured in the system log. The stack trace shows
+ which driver call caused a lockup.
+
+config DPM_WD_ACTION_LOG
+ bool "Log event"
+ ---help---
+ When selected, a lockup during device's suspend or
+ resume would cause the watchdog timeout event to be
+ logged in the system log.
+
+endchoice
+
+config DPM_WD_TIMEOUT
+ int "Watchdog timeout in seconds"
+ range 1 120
+ default 12
+ depends on DPM_WD
+
config PM_TRACE
[RFC PATCHv2 0/2] power: device suspend/resume watchdog
Hi all, Attached are two patches addressing comments on the implementation of device suspend (and resume) watchdogs from the android kernel. I have squashed changes for the suspend and resume watchdogs as they address pretty much the same functionality, and also added compile-time configurability of the watchdogs. Please be kind to review and comment if it is ready for upstreaming. Best regards, Zoran Cc: Android Kernel Team Cc: Colin Cross Cc: Todd Poynor Cc: San Mehat Cc: Benoit Goby Cc: John Stultz Cc: Pavel Machek Cc: Rafael J. Wysocki Cc: Len Brown Cc: Greg Kroah-Hartman Benoit Goby (1): drivers: power: Add watchdog timer to catch drivers which lockup during suspend/resume. Zoran Markovic (1): PM: compile-time configuration of device suspend/resume watchdogs. drivers/base/power/main.c | 87 + kernel/power/Kconfig | 48 + 2 files changed, 135 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/11] net/bonding: take msecs_to_jiffies_min into use
On Fri, 2013-05-10 at 15:58 +0200, Michal Kubecek wrote:
> On Fri, May 10, 2013 at 03:13:24PM +0300, Imre Deak wrote:
> > --- a/drivers/net/bonding/bond_main.c
> > +++ b/drivers/net/bonding/bond_main.c
> > @@ -1751,7 +1751,7 @@ int bond_enslave(struct net_device *bond_dev, struct
> > net_device *slave_dev)
> > read_lock(>lock);
> >
> > new_slave->last_arp_rx = jiffies -
> > - (msecs_to_jiffies(bond->params.arp_interval) + 1);
> > + (msecs_to_jiffies_min(bond->params.arp_interval));
> >
> > if (bond->params.miimon && !bond->params.use_carrier) {
> > link_reporting = bond_check_dev_link(bond, slave_dev, 1);
>
> This "+ 1" was actually meant as "plus one". We need to ensure that
>
> slave->last_arp_rx + msecs_to_jiffies(bond->params.arp_interval)
>
> is strictly less than current value of jiffies.
Ok, I see, the adjustment here is for a different reason and
msecs_to_jiffies_min wouldn't express this properly. So we should drop
this patch. Perhaps it'd be nice to add something like the above
explanation as a code comment, to make it clear that the adjustment is
not for guaranteeing a minimum duration as it is in many other places.
--Imre
> So with proposed
> definition of msecs_to_jiffies_min() it works correctly but if the
> implementation ever changes in such way that
>
> msecs_to_jiffies_min(x) >= msecs_to_jiffies(x)
>
> for some value of x, the code would be incorrect.
>
>Michal Kubeček
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] x86/sched/context_tracking: Call new schedule_preempt_user() from entry_64.S
I started testing the new NOHZ_FULL in the kernel and had some issues, so I started function tracing and this bug report came out: [23446.458073] [ cut here ] [23446.461028] WARNING: at /home/rostedt/work/git/linux-trace.git/kernel/rcutree.c:388 rcu_eqs_enter+0x4b/0x89() [23446.466096] Modules linked in: ebtables ipt_MASQUERADE sunrpc bridge stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_id t snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm kvm_intel snd_timer snd kvm soundcore shpchp snd_page_alloc microcode i2c_i801 pata_acpi firewire_ohci firewi re_core crc_itu_t ata_generic i915 drm_kms_helper drm i2c_algo_bit i2c_core video [23446.466096] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.9.0-test+ #11 [23446.466096] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 [23446.466096] 814879f0 81004fa6 810337af 88007d40 [23446.466096] 88007d40d900 81a01f00 [23446.466096] 81acba00 88007d6495c0 810a1f36 0a28 [23446.466096] Call Trace: [23446.466096] [] ? dump_stack+0xd/0x17 [23446.466096] [] ? show_stack+0x5/0x3e [23446.466096] [] ? warn_slowpath_common+0x64/0x7c [23446.466096] [] ? rcu_eqs_enter+0x4b/0x89 [23446.466096] [] ? rcu_idle_enter+0x1a/0x30 [23446.466096] [] ? ftrace_graph_caller+0x85/0x85 [23446.466096] [] cpu_startup_entry+0xb3/0x11c [23446.466096] [] ? start_kernel+0x41a/0x425 [23446.466096] [] ? repair_env_string+0x54/0x54 [23446.466096] ---[ end trace ddbb69ae2a0f6687 ]--- [23446.466096] [ cut here ] This is caused by an imbalance of rcu_eqs_enter() and rcu_eqs_exit(). Adding more tracing, I also discovered that there seemed to be an imbalance in user_exit() and user_enter(). Specifically, I found that user_enter() was called, and then a migration happened and user_exit() was never called before the schedule. Then I had noticed this in my trace: run-isol-11546 1.N.. 37363.637641: function: schedule_user <-- retint_careful run-isol-11546 1.N.. 37363.637641: function: __schedule <-- preempt_schedule The funny part here is that schedule_user does not call preempt_schedule. But then I also noticed the flags of the call to schedule_user(): "1.N..". This shows that it was running on cpu 1 with NEED_RESCHED set (N), but both interrupts and preemption are enabled. If an interrupt came in here we can schedule out again, but that would call preempt_schedule_irq, which has code to check if its in "user context (according to dynamic_ticks)" and would do the user_exit() too. But something didn't seem right here. Then I realized that it was actually the function tracer itself, as for every function it traces, it calls preempt_disable() and preempt_enable() to record the data on a per_cpu buffer. That preempt_enable() noticed the NEED_RESCHED set and since preemption is enabled, it kindly called preempt_schedule() for us! All this before schedule_user() was able to call user_exit() and take us out of dynamic tick user context. I even verified this by adding a: preempt_disable(); preempt_enable(); just before the user_exit() and ran a test without doing any tracing and was able to easily hit this bug. I then looked at the code in entry_64.S, and noticed that the calls to SCHEDULE_USER were all encompassed with ENABLE_INTERRUPTS and DISABLE_INTERRUPTS before calling schedule. And the SCHEDULE_USER macro is different if we have CONTEXT_TRACKING enabled or not. I created a new schedule_preempt_user() which is similar to schedule_preempt_disable() and works like preempt_schedule_irq(), where it includes the exception_enter() and exit() routines that take care of the accounting of dynamic ticks when interrupting user mode or not. It also takes care of it before enabling interrupts, so we don't need to worry about any preemption happening at the wrong time. Now the code always calls schedule_preempt_user() whether or not CONTEXT_TRACKING is configured, which cleans up entry_64.S and removes the need of the context_tracking.h header file in asm. Signed-off-by: Steven Rostedt Index: linux-trace.git/arch/x86/include/asm/context_tracking.h === --- linux-trace.git.orig/arch/x86/include/asm/context_tracking.h +++ /dev/null @@ -1,10 +0,0 @@ -#ifndef _ASM_X86_CONTEXT_TRACKING_H -#define _ASM_X86_CONTEXT_TRACKING_H - -#ifdef CONFIG_CONTEXT_TRACKING -# define SCHEDULE_USER call schedule_user -#else -# define SCHEDULE_USER call schedule -#endif - -#endif Index: linux-trace.git/arch/x86/kernel/entry_64.S === --- linux-trace.git.orig/arch/x86/kernel/entry_64.S +++ linux-trace.git/arch/x86/kernel/entry_64.S @@ -56,7 +56,6 @@ #include #include
[PATCH 0/3] nohz: Some fixes and updates
Frederic, Can you take these patches. The first patch will need to get an ack by one of the x86 maintainers. That one adds a new schedule_preempt_user() that is called before going back to user space in order to safely switch from user_context before calling schedule. The second patch prevents LOCKUP_DETECTION from being selected if NO_HZ_FULL is. That's because if LOCKUP_DETECTION is selected, it will prevent NO_HZ_FULL from functioning. I first thought about having NO_HZ_FULL depend on LOCKUP_DETECTION, but it would hide the feature. As NO_HZ_FULL is a feature and LOCKUP_DETECTION is debugging, I have precedence to the feature. The last patch produces a warning if nohz_full is used or NO_HZ_FULL_ALL is defined, and the system fails to go into nohz_full mode because the machine's clock is unstable. We don't want users thinking they have nohz_full but their machine can't handle it. -- Steve --- arch/x86/include/asm/context_tracking.h | 10 - b/arch/x86/kernel/entry_64.S| 26 + b/kernel/sched/core.c | 33 +--- b/kernel/time/tick-sched.c |5 b/lib/Kconfig.debug |2 + 5 files changed, 31 insertions(+), 45 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] nohz: Warn if the machine can not perform nohz_full
If the user configures NO_HZ_FULL and defines nohz_full=XXX on the
kerenl command line, or enables NO_HZ_FULL_ALL, but nohz fails
due to the machine having a unstable clock, warn about it.
We do not want users thinking that they are getting the benefit
of nohz when their machine can not support it.
Signed-off-by: Steven Rostedt
Index: linux-trace.git/kernel/time/tick-sched.c
===
--- linux-trace.git.orig/kernel/time/tick-sched.c
+++ linux-trace.git/kernel/time/tick-sched.c
@@ -178,6 +178,11 @@ static bool can_stop_full_tick(void)
*/
if (!sched_clock_stable) {
trace_tick_stop(0, "unstable sched clock\n");
+ /*
+* Don't allow the user to think they can get
+* full NO_HZ with this machine.
+*/
+ WARN_ONCE(1, "NO_HZ FULL will not work with unstable sched
clock");
return false;
}
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] nohz: Disable LOCKUP_DETECTOR when NO_HZ_FULL is enabled
Trying to test the nohz_full code, I was not able to get it to work. Finally I enabled the tick_stop tracepoint and it showed: tick_stop:success=no msg=perf events running I talked to Frederic Weisbecker about this and he informed me that perf is used by the lockup detector. I checked the code, and sure enough it is. As perf is always running when LOCKUP_DETECTOR is enabled, which will always disable nohz_full from working, instead of confusing users, disable LOCKUP_DETECTOR when NO_HZ_FULL is enabled. When perf is changed such that it does not prevent nohz_full from working, then we can and should remove this constraint. Signed-off-by: Steven Rostedt diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 566cf2b..1364d09 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -174,6 +174,8 @@ config DEBUG_SHIRQ config LOCKUP_DETECTOR bool "Detect Hard and Soft Lockups" depends on DEBUG_KERNEL && !S390 + # Lockup detector currently prevents NO_HZ_FULL from working + depends on !NO_HZ_FULL help Say Y here to enable the kernel to act as a watchdog to detect hard and soft lockups. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: SyS symbol munging.
On Fri, May 10, 2013 at 04:56:22PM -0400, Steven Rostedt wrote: > On Fri, May 10, 2013 at 09:05:03PM +0100, Al Viro wrote: > > On Fri, May 10, 2013 at 09:55:00PM +0200, Borislav Petkov wrote: > > > On Fri, May 10, 2013 at 12:35:10PM -0700, Andrew Morton wrote: > > > > I forget who did this initially and peeling back those layers with git > > > > is tiresome. > > > > > > 1a94bc34768e4 from 2009, although those SyS* things started appearing in > > > stack traces only recently AFAIR. > > > > Note that both sys_something and SyS_something end up in vmlinux symbol > > table, refering to the same address. AFAICS, what matters is which one > > goes first. May be even linker-dependent... > > Actually, it's the first one that kallsyms finds in its binary search. > > If the table is layed out a little differently, it may find the first > one or the second one. Then maybe it's worth trying to kill these aliases in kallsyms. We also have compat_SyS_something stuff. Actually, most of the aliases seem to be of those forms - after removing (a_sys_b,a_SyS_b) pairs the list of duplicates in System.map shrinks by factor of 15 or so... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 next/akpm] aio: convert the ioctx list to radix tree
On Fri, May 10, 2013 at 01:40:15PM -0700, Andrew Morton wrote: > On Mon, 15 Apr 2013 14:40:55 +0300 Octavian Purdila > wrote: > > > When using a large number of threads performing AIO operations the > > IOCTX list may get a significant number of entries which will cause > > significant overhead. For example, when running this fio script: > > > > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1 > > blocksize=1024; numjobs=512; thread; loops=100 > > > > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to > > 30% CPU time spent by lookup_ioctx: > > > > 32.51% [guest.kernel] [g] lookup_ioctx > > 9.19% [guest.kernel] [g] __lock_acquire.isra.28 > > 4.40% [guest.kernel] [g] lock_release > > 4.19% [guest.kernel] [g] sched_clock_local > > 3.86% [guest.kernel] [g] local_clock > > 3.68% [guest.kernel] [g] native_sched_clock > > 3.08% [guest.kernel] [g] sched_clock_cpu > > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11 > > 2.60% [guest.kernel] [g] memcpy > > 2.33% [guest.kernel] [g] lock_acquired > > 2.25% [guest.kernel] [g] lock_acquire > > 1.84% [guest.kernel] [g] do_io_submit > > > > This patchs converts the ioctx list to a radix tree. > > The patch looks nice. One thing we should pay attention to is the > memory consumption. radix-trees can be far less space-efficient than > lists, and as the tree key comes from mmap() it can be pretty sparsely > distributed. > > So could you please have a think about this, see if we can cook up some > worst-case numbers and decide if they are problematic? Because the overhead of an ioctx is so high (ringbuffer is some number of pages) it shouldn't matter much - but I wouldn't mind seeing a bit of arithmatic. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: x86_mce: mce_start uses number of phsical cores instead of logical cores
> I used intel edac error injector and saw the same problem. I actually wrote > down the core numbers > and I saw mce got to 0-5 and 12-17, but not the others. I have 2 sockets, 24 > logical cores. Mauro: How does the EDAC injector work on E5645 (Westmere-EP)? Does it create a real error in memory that the processor then accesses ... tripping a machine check? The mapping of Linux logical cpu numbers to physical socket/core/thread is somewhat as the mercy of the order that the BIOS lists things in its tables. But those numbers look very much like you just saw the machine check on one socket. Look at /proc/cpuinfo to be sure. If you run "grep ^physical /proc/cpuinfo" I think you'll see output like this (confirming that only socket 0 saw the machine check): physical id : 0 physical id : 0 physical id : 0 physical id : 0 physical id : 0 physical id : 0 physical id : 1 physical id : 1 physical id : 1 physical id : 1 physical id : 1 physical id : 1 physical id : 0 physical id : 0 physical id : 0 physical id : 0 physical id : 0 physical id : 0 physical id : 1 physical id : 1 physical id : 1 physical id : 1 physical id : 1 physical id : 1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SyS symbol munging.
On Fri, May 10, 2013 at 09:05:03PM +0100, Al Viro wrote: > On Fri, May 10, 2013 at 09:55:00PM +0200, Borislav Petkov wrote: > > On Fri, May 10, 2013 at 12:35:10PM -0700, Andrew Morton wrote: > > > I forget who did this initially and peeling back those layers with git > > > is tiresome. > > > > 1a94bc34768e4 from 2009, although those SyS* things started appearing in > > stack traces only recently AFAIR. > > Note that both sys_something and SyS_something end up in vmlinux symbol > table, refering to the same address. AFAICS, what matters is which one > goes first. May be even linker-dependent... Actually, it's the first one that kallsyms finds in its binary search. If the table is layed out a little differently, it may find the first one or the second one. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Add wait_on_atomic_t() and wake_up_atomic_t() [ver #2]
Fengguang's kbuild bot found a compile error on one arch with this patch, so I've pushed a new version to the git tree. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] snd-es1968: Add radio support for MediaForte M56VAP
Add support for TEA5757 tuner on MediaForte M56VAP sound+modem+radio card.
The GPIO connection type is automatically detected (like snd-fm801 driver).
Also add a safety subsystem vendor check to skip radio detection if vendor
differs from ESS (so we don't touch GPIOs on laptops).
Tested with SF64-PCE2 and M56VAP cards.
Signed-off-by: Ondrej Zary
---
sound/pci/es1968.c | 73 +++
1 files changed, 50 insertions(+), 23 deletions(-)
diff --git a/sound/pci/es1968.c b/sound/pci/es1968.c
index a1f32b5..db08641 100644
--- a/sound/pci/es1968.c
+++ b/sound/pci/es1968.c
@@ -564,6 +564,7 @@ struct es1968 {
#ifdef CONFIG_SND_ES1968_RADIO
struct v4l2_device v4l2_dev;
struct snd_tea575x tea;
+ unsigned int tea575x_tuner;
#endif
};
@@ -2557,37 +2558,47 @@ static int snd_es1968_input_register(struct es1968
*chip)
bits 1=unmask write to given bit */
#define IO_DIR 8 /* direction register offset from GPIO_DATA
bits 0/1=read/write direction */
-/* mask bits for GPIO lines */
-#define STR_DATA 0x0040 /* GPIO6 */
-#define STR_CLK0x0080 /* GPIO7 */
-#define STR_WREN 0x0100 /* GPIO8 */
-#define STR_MOST 0x0200 /* GPIO9 */
+
+/* GPIO to TEA575x maps */
+struct snd_es1968_tea575x_gpio {
+ u8 data, clk, wren, most;
+ char *name;
+};
+
+static struct snd_es1968_tea575x_gpio snd_es1968_tea575x_gpios[] = {
+ { .data = 6, .clk = 7, .wren = 8, .most = 9, .name = "SF64-PCE2" },
+ { .data = 7, .clk = 8, .wren = 6, .most = 10, .name = "M56VAP" },
+};
+
+#define get_tea575x_gpio(chip) \
+ (_es1968_tea575x_gpios[(chip)->tea575x_tuner])
+
static void snd_es1968_tea575x_set_pins(struct snd_tea575x *tea, u8 pins)
{
struct es1968 *chip = tea->private_data;
- unsigned long io = chip->io_port + GPIO_DATA;
+ struct snd_es1968_tea575x_gpio gpio = *get_tea575x_gpio(chip);
u16 val = 0;
- val |= (pins & TEA575X_DATA) ? STR_DATA : 0;
- val |= (pins & TEA575X_CLK) ? STR_CLK : 0;
- val |= (pins & TEA575X_WREN) ? STR_WREN : 0;
+ val |= (pins & TEA575X_DATA) ? (1 << gpio.data) : 0;
+ val |= (pins & TEA575X_CLK) ? (1 << gpio.clk) : 0;
+ val |= (pins & TEA575X_WREN) ? (1 << gpio.wren) : 0;
- outw(val, io);
+ outw(val, chip->io_port + GPIO_DATA);
}
static u8 snd_es1968_tea575x_get_pins(struct snd_tea575x *tea)
{
struct es1968 *chip = tea->private_data;
- unsigned long io = chip->io_port + GPIO_DATA;
- u16 val = inw(io);
- u8 ret;
+ struct snd_es1968_tea575x_gpio gpio = *get_tea575x_gpio(chip);
+ u16 val = inw(chip->io_port + GPIO_DATA);
+ u8 ret = 0;
- ret = 0;
- if (val & STR_DATA)
+ if (val & (1 << gpio.data))
ret |= TEA575X_DATA;
- if (val & STR_MOST)
+ if (val & (1 << gpio.most))
ret |= TEA575X_MOST;
+
return ret;
}
@@ -2596,13 +2607,18 @@ static void snd_es1968_tea575x_set_direction(struct
snd_tea575x *tea, bool outpu
struct es1968 *chip = tea->private_data;
unsigned long io = chip->io_port + GPIO_DATA;
u16 odir = inw(io + IO_DIR);
+ struct snd_es1968_tea575x_gpio gpio = *get_tea575x_gpio(chip);
if (output) {
- outw(~(STR_DATA | STR_CLK | STR_WREN), io + IO_MASK);
- outw(odir | STR_DATA | STR_CLK | STR_WREN, io + IO_DIR);
+ outw(~((1 << gpio.data) | (1 << gpio.clk) | (1 << gpio.wren)),
+ io + IO_MASK);
+ outw(odir | (1 << gpio.data) | (1 << gpio.clk) | (1 <<
gpio.wren),
+ io + IO_DIR);
} else {
- outw(~(STR_CLK | STR_WREN | STR_DATA | STR_MOST), io + IO_MASK);
- outw((odir & ~(STR_DATA | STR_MOST)) | STR_CLK | STR_WREN, io +
IO_DIR);
+ outw(~((1 << gpio.clk) | (1 << gpio.wren) | (1 << gpio.data) |
(1 << gpio.most)),
+ io + IO_MASK);
+ outw((odir & ~((1 << gpio.data) | (1 << gpio.most)))
+ | (1 << gpio.clk) | (1 << gpio.wren), io + IO_DIR);
}
}
@@ -2772,6 +2788,9 @@ static int snd_es1968_create(struct snd_card *card,
snd_card_set_dev(card, >dev);
#ifdef CONFIG_SND_ES1968_RADIO
+ /* don't play with GPIOs on laptops */
+ if (chip->pci->subsystem_vendor != 0x125d)
+ goto no_radio;
err = v4l2_device_register(>dev, >v4l2_dev);
if (err < 0) {
snd_es1968_free(chip);
@@ -2781,10 +2800,18 @@ static int snd_es1968_create(struct snd_card *card,
chip->tea.private_data = chip;
chip->tea.radio_nr = radio_nr;
chip->tea.ops = _es1968_tea_ops;
- strlcpy(chip->tea.card, "SF64-PCE2", sizeof(chip->tea.card));
sprintf(chip->tea.bus_info, "PCI:%s", pci_name(pci));
- if
Re: [PATCH v3 next/akpm] aio: convert the ioctx list to radix tree
On Mon, 15 Apr 2013 14:40:55 +0300 Octavian Purdila wrote: > When using a large number of threads performing AIO operations the > IOCTX list may get a significant number of entries which will cause > significant overhead. For example, when running this fio script: > > rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1 > blocksize=1024; numjobs=512; thread; loops=100 > > on an EXT2 filesystem mounted on top of a ramdisk we can observe up to > 30% CPU time spent by lookup_ioctx: > > 32.51% [guest.kernel] [g] lookup_ioctx > 9.19% [guest.kernel] [g] __lock_acquire.isra.28 > 4.40% [guest.kernel] [g] lock_release > 4.19% [guest.kernel] [g] sched_clock_local > 3.86% [guest.kernel] [g] local_clock > 3.68% [guest.kernel] [g] native_sched_clock > 3.08% [guest.kernel] [g] sched_clock_cpu > 2.64% [guest.kernel] [g] lock_release_holdtime.part.11 > 2.60% [guest.kernel] [g] memcpy > 2.33% [guest.kernel] [g] lock_acquired > 2.25% [guest.kernel] [g] lock_acquire > 1.84% [guest.kernel] [g] do_io_submit > > This patchs converts the ioctx list to a radix tree. The patch looks nice. One thing we should pay attention to is the memory consumption. radix-trees can be far less space-efficient than lists, and as the tree key comes from mmap() it can be pretty sparsely distributed. So could you please have a think about this, see if we can cook up some worst-case numbers and decide if they are problematic? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: EXT4 panic at jbd2_journal_put_journal_head() in 3.9+
On 05/10/2013 12:27 PM, Theodore Ts'o wrote: Hmm, since you seem to be able to reproduce the problem reliably, any chance you can try bisecting the problem? I've looked at the commits that touch fs/jbd2 and nothing is jumping out at me. Also, how many CPU's do you have your system, and what kind of storage device were you using when you were running iozone (5400rpm HDD, 7200RPM HDD, RAID array, SSD, etc.)? I too have seen this. My system is: 12 CPU Octeon (MIPS64) Root is ext3, mounted via ext4fs on a slow CompactFlash/PIO6 I saw the crash when simply booting a fairly bare-bones Debian distro, although it is somewhat random: . . ata3: PATA max PIO6 cmd 90001d04 ctl 90001d05000d irq 63 . . ata3.00: CFA: CF 4GB, 20101001, max UDMA/133 ata3.00: 7847280 sectors, multi 0: LBA ata3.00: configured for PIO6 . . scsi 2:0:0:0: Direct-Access ATA CF 4GB 2010 PQ: 0 ANSI: 5 sd 2:0:0:0: [sda] 7847280 512-byte logical blocks: (4.01 GB/3.74 GiB) sd 2:0:0:0: [sda] Write Protect is off sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 2:0:0:0: [sda] Attached SCSI disk EXT4-fs (sda2): mounting ext3 file system using the ext4 subsystem EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) VFS: Mounted root (ext3 filesystem) readonly on device 8:2. . . . I have not been able to get it to fail a second time. So for me bisecting might not work. David Daney Thanks, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.9-linux-next-20130501: OOPS in intel_pstate_sample
[+cc Viresh, Srinivas, Dirk, cpufreq list] On Wed, May 1, 2013 at 3:03 PM, Martin Mokrejs wrote: > Hi, > I opened yet another bug https://bugzilla.kernel.org/show_bug.cgi?id=57411 . > > This is maybe a dupe of bug https://bugzilla.kernel.org/show_bug.cgi?id=57401 > (which is vanilla 3.9) but happened on linux-next-20130501 after I did "dmesg > | less". > > ? pid_param_set > intel_pstate_timer_func > call_timer_fn > ? __internal_add_timer > ? pid_param_set > run_timer_softirq > __do_softirq > irq_exit > smp_apic_timer_interrupt > apic_timer_interrupt > ? sysret_check > > A camera picture of the stacktrace is attached to the bug > https://bugzilla.kernel.org/show_bug.cgi?id=57411 > Please forward this to the appropriate person. > Thanks, > Martin > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: plat-orion: add missing ehci include to common.h
Removing orion ehci include from board files will raise a compiler error because plat/common.h is using an enum provided by orion ehci but not including the include itself. This just adds the missing include. Signed-off-by: Sebastian Hesselbarth --- Cc: Jason Cooper Cc: Andrew Lunn Cc: Russell King Cc: Arnaud Patard Cc: Sebastian Hesselbarth Cc: Thomas Petazzoni Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- arch/arm/plat-orion/include/plat/common.h |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/plat-orion/include/plat/common.h b/arch/arm/plat-orion/include/plat/common.h index e06fc5f..d9a24f6 100644 --- a/arch/arm/plat-orion/include/plat/common.h +++ b/arch/arm/plat-orion/include/plat/common.h @@ -10,6 +10,7 @@ #ifndef __PLAT_COMMON_H #include +#include struct dsa_platform_data; struct mv_sata_platform_data; -- 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: NMIs induced by 'perf top' hogging all CPU time
On 05/10/2013 03:29 AM, Peter Zijlstra wrote: > On Thu, May 09, 2013 at 04:29:16PM -0700, Dave Hansen wrote: >> If I boot a recent kernel (bb9055b) and run 'perf top' on my machine, it >> hangs. It is 100% reproducible; it happens every single time. If I'm >> lucky, I'll get some of the hardlockup detection messages on the console. > > Are you implicitly saying it worked as expected on previous kernels? Yes, it works on older kernels. 3.6.11 works, for instance. This hardware is quite effective at finding bugs. It makes bisecting very challenging as not a lot of random mainline versions boot. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: x86_mce: mce_start uses number of phsical cores instead of logical cores
I used intel edac error injector and saw the same problem. I actually wrote down the core numbers and I saw mce got to 0-5 and 12-17, but not the others. I have 2 sockets, 24 logical cores. Below is the trace I put into mce code. The core number is after "#". Ming 344 :344 #4 ** 802097241816 (207303152230.v1) (207303152334) 4294874599 :24: mce_start do_machine_check 345 :345 #16 ** 802097241876 (207303152404.v1) (207303152426) 4294874599 :12:16:1:4:4: mce_start do_machine_check 346 :346 #0 ** 802097241914 (207303152271.v1) (207303152343) 4294874599 :24: mce_start do_machine_check 347 :347 #1 *802097242074 (207303152515.v1) (207303152599) 4294874599 :8:-4755801206503178081:256::: mce_no_way_out do_machine_check 348 :348 #13 *802097242098 (207303152512.v1) (207303152552) 4294874599 :7: mce_no_way_out do_machine_check 349 :349 #3 *802097242282 (207303152630.v1) (207303152679) 4294874599 :7: mce_no_way_out do_machine_check 350 :350 #14 ** 802097242342 (207303152452.v1) (207303152520) 4294874599 :12:16:1:4:4: mce_start do_machine_check 351 :351 #2 *802097242366 (207303152458.v1) (207303152537) 4294874599 :8:-4755801206503178081:256::: mce_no_way_out do_machine_check 352 :352 #0 ** 802097242774 (207303152627.v1) (207303152676) 4294874599 :12:16:1:4:4: mce_start do_machine_check 353 :353 #12 ** 802097242838 (207303152829.v1) (207303152853) 4294874599 :24: mce_start do_machine_check 354 :354 #15 ** 802097242890 (207303152676.v1) (207303152707) 4294874599 :24: mce_start do_machine_check 355 :355 #4 ** 802097243056 (207303152747.v1) (207303152825) 4294874599 :12:16:1:4:4: mce_start do_machine_check 356 :356 #2 ** 802097243386 (207303152881.v1) (207303153006) 4294874599 :24: mce_start do_machine_check 357 :357 #17 ** 802097243546 (207303152953.v1) (207303153023) 4294874599 :24: mce_start do_machine_check 358 :358 #5 ** 802097243566 (207303152963.v1) (207303153041) 4294874599 :24: mce_start do_machine_check 359 :359 #15 ** 802097243922 (207303153107.v1) (207303153193) 4294874599 :12:21:1:9:9: mce_start do_machine_check 360 :360 #3 *802097243994 (207303153342.v1) (207303153356) 4294874599 :8:-4755801206503178081:256::: mce_no_way_out do_machine_check 361 :361 #13 *802097244074 (207303153175.v1) (207303153242) 4294874599 :8:-4755801206503178081:256::: mce_no_way_out do_machine_check 362 :362 #1 ** 802097244050 (207303153167.v1) (207303153229) 4294874599 :24: mce_start do_machine_check 363 :363 #12 ** 802097244174 (207303153212.v1) (207303153284) 4294874599 :12:22:1:9:9: mce_start do_machine_check 364 :364 #2 ** 802097244490 (207303153347.v1) (207303153419) 4294874599 :12:22:1:10:10: mce_start do_machine_check 365 :365 #1 ** 802097244746 (207303153452.v1) (207303153521) 4294874599 :12:22:1:10:10: mce_start do_machine_check 366 :366 #5 ** 802097244834 (207303153488.v1) (207303153558) 4294874599 :12:22:1:10:10: mce_start do_machine_check 367 :367 #17 ** 802097244902 (207303153645.v1) (207303153665) 4294874599 :12:22:1:10:10: mce_start do_machine_check 368 :368 #3 ** 802097245130 (207303153611.v1) (207303153680) 4294874599 :24: mce_start do_machine_check 369 :369 #13 ** 802097245302 (207303153681.v1) (207303153760) 4294874599 :24: mce_start do_machine_check 370 :370 #3 ** 802097245710 (207303153857.v1) (207303153979) 4294874599 :12:24:1:12:12: mce_start do_machine_check 371 :371 #13 ** 802097246234 (207303154072.v1) (207303154141) 4294874599 :12:24:1:12:12: mce_start do_machine_check 372 :372 #15 *** 802097246542 (207303154201.v1) (207303154283) 4294874599 :12:5 mce_start do_machine_check 373 :373 #3 *** 802097246614 (207303154539.v1) (207303154565) 4294874599 :12:11 mce_start do_machine_check 374 :374 #2 *** 802097246678 (207303154265.v1) (207303154331) 4294874599 :12:9 mce_start do_machine_check 375 :375 #13 *** 802097246794 (207303154313.v1) (207303154376) 4294874599 :12:12 mce_start do_machine_check 376 :376 #1 *** 802097246814 (207303154325.v1) (207303154388) 4294874599 :12:10 mce_start do_machine_check 377 :377 #0 *** 802097246898 (207303154350.v1) (207303154420) 4294874599 :12:4 mce_start do_machine_check 378 :378 #12 *** 802097246966 (207303154614.v1) (207303154640) 4294874599 :12:6 mce_start do_machine_check 379 :379 #4 *** 802097247044 (207303154416.v1) (207303154481) 4294874599 :12:3 mce_start do_machine_check 380 :380 #16 *** 802097247064 (207303154429.v1) (207303154494) 4294874599 :12:1 mce_start do_machine_check 381 :381 #17 *** 802097247226 (207303154669.v1) (207303154696) 4294874599 :12:7 mce_start do_machine_check 382 :382 #14 *** 802097247250 (207303154495.v1) (207303154575) 4294874599 :12:2 mce_start do_machine_check 383 :383 #5 *** 802097247574 (207303154632.v1) (207303154666) 4294874599 :12:8 mce_start
Re: SyS symbol munging.
On Fri, May 10, 2013 at 09:05:03PM +0100, Al Viro wrote: > Note that both sys_something and SyS_something end up in vmlinux > symbol table, refering to the same address. AFAICS, what matters is > which one goes first. May be even linker-dependent... Interesting. So it could be that a change in the linker may have caused the SyS things to go first and start appearing in stack traces, not necessarily a change in the kernel... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SyS symbol munging.
On Fri, May 10, 2013 at 09:55:00PM +0200, Borislav Petkov wrote: > On Fri, May 10, 2013 at 12:35:10PM -0700, Andrew Morton wrote: > > I forget who did this initially and peeling back those layers with git > > is tiresome. > > 1a94bc34768e4 from 2009, although those SyS* things started appearing in > stack traces only recently AFAIR. Note that both sys_something and SyS_something end up in vmlinux symbol table, refering to the same address. AFAICS, what matters is which one goes first. May be even linker-dependent... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/10] Usb: Move PORTSC access to PHY
On 05/10/2013 07:54 AM, Venu Byravarasu wrote: > Changes with this patch: > 1. As PHY is being registered as separate platform driver & EHCI Tegra > is no more calling PHY open, moved tegra_ehci_set_pts & tegra_ehci_set_phcd > functions to PHY driver, > > 2. Removed unused defines for multiple USB port base addresses This patch (mostly?) is a revert of bbdabdb "usb: add APIs to access host registers from Tegra PHY". I don't think we want to revert this[1]. Instead, once patch 9/10 in this series is applied, the Tegra EHCI module should no longer directly reference any symbols in the Tegra USB PHY module. This is because the functions exposed by the Tegra PHY module are now accessed using the new standard PHY APIs, rather than directly by symbol name. Assuming that's true, it is then permissible for the Tegra PHY module to once again directly reference symbols exported by the Tegra EHCI module. So, instead of moving the functions from the EHCI code to the PHY code, keep them in the EHCI code, and call them from the PHY code, but call them by function name instead of by function pointer. That way, there's no need to pass the function pointers during initialization. You will have to roll that change into patch 9/10 to make git bisect work. [1] The background is that NVIDIA HW has added some non-standard register bits to the PORTSC register, related to PHY control. The PHY driver needs to control those bits, but they're in the EHCI register space. Since the non-standard bits are controlled by read-modify-write, the EHCI driver should implement the register accesses, so the it can implement locking against its own read-modify-write of that register if required. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
