Re: [PATCH 10/11] spi/s3c64xx: improve error handling
On 8 August 2012 20:17, Arnd Bergmann wrote:
> When a device tree definition os an s3c64xx SPI master is missing
> a "controller-data" subnode, the newly added s3c64xx_get_slave_ctrldata
> function might use uninitialized memory in place of that node,
> which was correctly reported by gcc.
>
> Without this patch, building s3c6400_defconfig results in:
>
> drivers/spi/spi-s3c64xx.c: In function 's3c64xx_get_slave_ctrldata.isra.25':
> drivers/spi/spi-s3c64xx.c:841:5: warning: 'data_np' may be used uninitialized
> in this function [-Wuninitialized]
>
> Signed-off-by: Arnd Bergmann
> Cc: Thomas Abraham
> Cc: Jaswinder Singh
> Cc: Grant Likely
> Cc: Kukjin Kim
> ---
> drivers/spi/spi-s3c64xx.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index 646a765..cfa2c35 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -826,7 +826,7 @@ static struct s3c64xx_spi_csinfo
> *s3c64xx_get_slave_ctrldata(
> struct spi_device *spi)
> {
> struct s3c64xx_spi_csinfo *cs;
> - struct device_node *slave_np, *data_np;
> + struct device_node *slave_np, *data_np = NULL;
> u32 fb_delay = 0;
>
> slave_np = spi->dev.of_node;
> --
> 1.7.10
>
Acked-by: Thomas Abraham
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio/omap: add *remove* callback in platform_driver
On Fri, Aug 10, 2012 at 11:38 AM, DebBarma, Tarun Kanti wrote: > > On Thu, Aug 9, 2012 at 8:28 PM, Kevin Hilman wrote: > > "DebBarma, Tarun Kanti" writes: > > > >> On Wed, Aug 8, 2012 at 10:40 PM, Kevin Hilman wrote: > >>> Tarun Kanti DebBarma writes: > >>> > Add *remove* callback so that necessary cleanup operations are > performed when device is unregistered. The device is deleted > from the list and associated clock handle is released by > calling clk_put() and irq descriptor is released using the > irq_free_desc() api. > > Signed-off-by: Tarun Kanti DebBarma > Reported-by: Paul Walmsley > Reviewed-by: Jon Hunter > Cc: Kevin Hilman > Cc: Rajendra Nayak > Cc: Santosh Shilimkar > Cc: Cousson, Benoit > Cc: Paul Walmsley > --- > v2: > Baseline: > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > Commit: 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee (Linux 3.6-rc1) > > (1) Use irq_free_descs() instead of irq_free_desc(). > Besides, irq_free_desc() was using wrong parameter, > irq_base, instead of bank->irq. > (2) irq_free_descs() moved outside spin_lock/unlock_*() > in order to avoid exception warnings. > > (3) pm_runtime_disable() added so that bind can happen successfully > > Test Detail: > Step 1: Unbind gpio.5 device in order to invoke the *remove* > callback. > #echo "omap_gpio.5" > sys/bus/platform/drivers/omap_gpio/unbind > > Step 2: Bind gpio.5 device and confirm probe() for the device > succeeds. > #echo "omap_gpio.5" > sys/bus/platform/drivers/omap_gpio/bind > > Step 3: Execute read/write GPIO test case. > >>> > >>> What happens when GPIOs are in use (requested)? > >> If I try to unbind a currently active GPIO bank then I see an exception > >> after the irq descriptor is freed by the remove. I believe this is > >> expected > >> because interrupt raised by the system would not be handled. > > > > ... and the GPIO is still configured to trigger interrupts. > Right! > > > > > The point is that there is lots to cleanup/unconfigure properly for this > > to work properly. > As far as I can think of, all active gpio requests done either in > board files or through DT > have to be freed. But if this is done then when we bind() the device > again initialization > done in omap_gpio_probe() would not restore the board/DT related > configuration. > So the point is are we supposed to do all these cleanup in *remove* > callback? > If yes, how do we manage board level gpio usage? More and more I think of the .remove() for GPIO, the interface not seems to make sense. Being an infrastructure driver which can be used by many client drivers like Ethernet, MMC card detect, sensors etc etc. And hence it can not be made a loadable module. So I am in favor of dropping the $subject patch completely unless and until we need it genuinely. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dlm: convert add_sock routine return value type to void
Since add_sock() always returns a success code - 0, its return
value type should be changed from integer to void.
Signed-off-by: Ying Xue
---
fs/dlm/lowcomms.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index e7b0ac0..8789309 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -348,7 +348,7 @@ int dlm_lowcomms_connect_node(int nodeid)
}
/* Make a socket active */
-static int add_sock(struct socket *sock, struct connection *con)
+static void add_sock(struct socket *sock, struct connection *con)
{
con->sock = sock;
@@ -358,7 +358,6 @@ static int add_sock(struct socket *sock, struct connection
*con)
con->sock->sk->sk_state_change = lowcomms_state_change;
con->sock->sk->sk_user_data = con;
con->sock->sk->sk_allocation = GFP_NOFS;
- return 0;
}
/* Add the port number to an IPv6 or 4 sockaddr and return the address
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/11] ARM: exynos: exynos_pm_add_dev_to_genpd may be unused
On 8 August 2012 20:17, Arnd Bergmann wrote:
> exynos_pm_add_dev_to_genpd is used if one or more out of a large
> number of Kconfig symbols are enabled. However the new
> exynos_defconfig selects none of those, so the function becomes
> unused. Marking it so lets the compiler automatically discard
> it.
>
> Without this patch, building exynos_defconfig results in:
>
> arch/arm/mach-exynos/pm_domains.c:118:123: warning:
> 'exynos_pm_add_dev_to_genpd' defined but not used [-Wunused-function]
>
> Signed-off-by: Arnd Bergmann
> Cc: Thomas Abraham
> Cc: Rafael J. Wysocki
> Cc: Kukjin Kim
> ---
> arch/arm/mach-exynos/pm_domains.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/pm_domains.c
> b/arch/arm/mach-exynos/pm_domains.c
> index 373c3c0..c0bc83a 100644
> --- a/arch/arm/mach-exynos/pm_domains.c
> +++ b/arch/arm/mach-exynos/pm_domains.c
> @@ -115,7 +115,7 @@ static __init int exynos_pm_dt_parse_domains(void)
> }
> #endif /* CONFIG_OF */
>
> -static __init void exynos_pm_add_dev_to_genpd(struct platform_device *pdev,
> +static __init __maybe_unused void exynos_pm_add_dev_to_genpd(struct
> platform_device *pdev,
> struct exynos_pm_domain *pd)
> {
> if (pdev->dev.bus) {
> --
> 1.7.10
>
Acked-by: Thomas Abraham
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/11] ARM: exynos: exynos_pm_add_dev_to_genpd may be unused
Arnd Bergmann wrote: > > exynos_pm_add_dev_to_genpd is used if one or more out of a large > number of Kconfig symbols are enabled. However the new > exynos_defconfig selects none of those, so the function becomes > unused. Marking it so lets the compiler automatically discard > it. > > Without this patch, building exynos_defconfig results in: > > arch/arm/mach-exynos/pm_domains.c:118:123: warning: > 'exynos_pm_add_dev_to_genpd' defined but not used [-Wunused-function] > > Signed-off-by: Arnd Bergmann > Cc: Thomas Abraham > Cc: Rafael J. Wysocki > Cc: Kukjin Kim Acked-by: Kukjin Kim Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] gpio fixes for v3.6-rc1
Hi Linus, these are some accumulated GPIO fixes I've collected for the -rc1. Description of fixes are in the tag below. All tested in linux-next. Please pull them in! The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git tags/gpio-fixes-v3.6-rc1 for you to fetch changes up to d6a2b7ba67334a7e72cd153c142c449831557cb9: drivers/gpio/gpio-langwell.c: fix error return code (2012-08-07 08:55:52 +0200) gpio fixes for v3.6-rc1 - Fix a resource leak in the SCH driver - Fix the register address calculation in the MSIC driver - Fix the PXA driver's devicetree functions - Delete redundant shadow variable leftovers in the MXC driver - Specify the GPIO base for the device tree probe in the MXC driver - Add a modalias for the i.MX driver - Fix off-by-one bug in the Samsung driver - Fix erroneous errorpath in the Langwell driver Alan Cox (1): gpio-sch: Fix leak of resource Axel Lin (1): gpio: msic: Fix calculating register address in msic_gpio_to_oreg() Daniel Mack (1): GPIO: gpio-pxa: fix devicetree functions Julia Lawall (1): drivers/gpio/gpio-langwell.c: fix error return code Sean Paul (1): gpio: samsung: Fix off-by-one bug in gpio addresses Shawn Guo (3): gpio/mxc: remove redundant shadow variables initialization gpio/mxc: specify gpio base for device tree probe ARM: dts: imx: add alias for gpio arch/arm/boot/dts/imx27.dtsi | 6 ++ arch/arm/boot/dts/imx51.dtsi | 4 arch/arm/boot/dts/imx53.dtsi | 7 +++ arch/arm/boot/dts/imx6q.dtsi | 7 +++ drivers/gpio/gpio-langwell.c | 7 +-- drivers/gpio/gpio-msic.c | 2 +- drivers/gpio/gpio-mxc.c | 5 ++--- drivers/gpio/gpio-pxa.c | 26 ++ drivers/gpio/gpio-samsung.c | 14 +++--- drivers/gpio/gpio-sch.c | 3 ++- 10 files changed, 67 insertions(+), 14 deletions(-) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Fix XIP build due to PHYS_OFFSET definition moving
On 8/2/2012 6:23 PM, Stephen Boyd wrote: > During the p2v changes, the PHYS_OFFSET #define moved into a > !__ASSEMBLY__ section. This causes a XIP build to fail with > > arch/arm/kernel/head.o: In function 'stext': > arch/arm/kernel/head.S:146: undefined reference to 'PHYS_OFFSET' > > Momentarily leave the #ifndef __ASSEMBLY__ section so we can > define PHYS_OFFSET for all compilation units. > > Signed-off-by: Stephen Boyd > --- > > I don't know if it's worth stable, seems that nobody has compiled XIP for > a year (back to 2.6.39 days?). Is this approach acceptable? Shall I put this in the patch tracker? -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/11] spi/s3c64xx: improve error handling
Arnd Bergmann wrote:
>
> When a device tree definition os an s3c64xx SPI master is missing
> a "controller-data" subnode, the newly added s3c64xx_get_slave_ctrldata
> function might use uninitialized memory in place of that node,
> which was correctly reported by gcc.
>
> Without this patch, building s3c6400_defconfig results in:
>
> drivers/spi/spi-s3c64xx.c: In function
> 's3c64xx_get_slave_ctrldata.isra.25':
> drivers/spi/spi-s3c64xx.c:841:5: warning: 'data_np' may be used
> uninitialized in this function [-Wuninitialized]
>
> Signed-off-by: Arnd Bergmann
> Cc: Thomas Abraham
> Cc: Jaswinder Singh
> Cc: Grant Likely
> Cc: Kukjin Kim
> ---
> drivers/spi/spi-s3c64xx.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index 646a765..cfa2c35 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -826,7 +826,7 @@ static struct s3c64xx_spi_csinfo
> *s3c64xx_get_slave_ctrldata(
> struct spi_device *spi)
> {
> struct s3c64xx_spi_csinfo *cs;
> - struct device_node *slave_np, *data_np;
> + struct device_node *slave_np, *data_np = NULL;
> u32 fb_delay = 0;
>
> slave_np = spi->dev.of_node;
> --
> 1.7.10
Looks ok to me,
Acked-by: Kukjin Kim
BTW for same reason, probably, we need following fix?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
From: Kukjin Kim
Signed-off-by: Kukjin Kim
---
arch/arm/mach-tegra/tegra2_emc.c |4 ++--
arch/c6x/kernel/setup.c |2 +-
arch/powerpc/kernel/ibmebus.c|2 +-
arch/powerpc/kernel/pci_of_scan.c|2 +-
arch/powerpc/kernel/prom.c |2 +-
arch/powerpc/kernel/rtas_pci.c |2 +-
arch/powerpc/kernel/vio.c|2 +-
arch/powerpc/platforms/44x/warp.c|2 +-
arch/powerpc/platforms/cell/setup.c |2 +-
arch/powerpc/platforms/powernv/opal.c|2 +-
arch/powerpc/platforms/powernv/pci-ioda.c|2 +-
arch/powerpc/platforms/powernv/pci-p5ioc2.c |2 +-
arch/powerpc/platforms/pseries/eeh.c | 12 ++--
arch/powerpc/sysdev/mv64x60_dev.c|2 +-
drivers/dma/fsldma.c |2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c |2 +-
drivers/hwmon/ads1015.c |2 +-
drivers/i2c/busses/i2c-powermac.c|2 +-
drivers/i2c/busses/i2c-pxa-pci.c |2 +-
drivers/i2c/i2c-mux.c|2 +-
drivers/iio/adc/at91_adc.c |2 +-
drivers/input/keyboard/samsung-keypad.c |2 +-
drivers/leds/leds-gpio.c |2 +-
drivers/net/ethernet/freescale/fsl_pq_mdio.c |2 +-
drivers/net/phy/mdio-mux.c |2 +-
drivers/of/of_i2c.c |2 +-
drivers/of/of_mdio.c |2 +-
drivers/of/of_pci.c |2 +-
drivers/of/platform.c|6 +++---
drivers/pinctrl/pinctrl-imx.c|4 ++--
drivers/pinctrl/pinctrl-tegra.c |2 +-
drivers/pinctrl/spear/pinctrl-spear.c|2 +-
drivers/regulator/da9052-regulator.c |2 +-
drivers/regulator/mc13xxx-regulator-core.c |2 +-
drivers/regulator/of_regulator.c |2 +-
drivers/spi/spi.c|2 +-
drivers/tty/hvc/hvc_opal.c |2 +-
37 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-tegra/tegra2_emc.c
b/arch/arm/mach-tegra/tegra2_emc.c
index 5070d83..d045a9e 100644
--- a/arch/arm/mach-tegra/tegra2_emc.c
+++ b/arch/arm/mach-tegra/tegra2_emc.c
@@ -181,7 +181,7 @@ int tegra_emc_set_rate(unsigned long rate)
#ifdef CONFIG_OF
static struct device_node *tegra_emc_ramcode_devnode(struct device_node
*np)
{
- struct device_node *iter;
+ struct device_node *iter = NULL;
u32 reg;
for_each_child_of_node(np, iter) {
@@ -198,7 +198,7 @@ static struct tegra_emc_pdata *tegra_emc_dt_parse_pdata(
struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
- struct device_node *tnp, *iter;
+ struct device_node *tnp, *iter = NULL;
struct tegra_emc_pdata *pdata;
int ret, i, num_tables;
diff --git a/arch/c6x/kernel/setup.c b/arch/c6x/kernel/setup.c
index f4e72bd..0f4cd29 100644
--- a/arch/c6x/kernel/setup.c
+++ b/arch/c6x/kernel/setup.c
@@ -99,7 +99,7 @@ static void __init get_cpuinfo(void)
unsigned long core_khz;
u64 tmp;
struct cpuinfo_c6x *p;
- struct device_node *node, *np;
+ struct device_node *node, *np = NULL;
p = &per_cpu(cpu_data, smp_processor_id());
diff --git a/arch/powerpc/kernel/ibmeb
Re: [PATCH] [PATCH V5]Extcon: adc_jack: adc-jack driver to support 3.5 pi or simliar devices
Hello,
some nitpicking below; sorry for my late reaction to the patch
regards, p.
> From: anish kumar
>
> External connector devices that decides connection information based on
> ADC values may use adc-jack device driver. The user simply needs to
> provide a table of adc range and connection states. Then, extcon
> framework will automatically notify others.
>
> Changes in V1:
> added Lars-Peter Clausen suggested changes:
> Using macros to get rid of boiler plate code such as devm_kzalloc
> and module_platform_driver.Other changes suggested are related to
> coding guidelines.
>
> Changes in V2:
> Removed some unnecessary checks and changed the way we are un-regitering
> extcon and freeing the irq while removing.
>
> Changes in V3:
> Renamed the files to comply with extcon naming.
>
> Changes in V4:
> Added the cancel_work_sync during removing of driver.
>
> Changes in this version:
> Added the dependency of IIO in Kconfig.
>
> Reviewed-by: Lars-Peter Clausen
> Signed-off-by: anish kumar
> Signed-off-by: MyungJoo Ham
> ---
> drivers/extcon/Kconfig |6 +
> drivers/extcon/Makefile|1 +
> drivers/extcon/extcon-adc-jack.c | 195
>
> include/linux/extcon/extcon-adc-jack.h | 73
> 4 files changed, 275 insertions(+), 0 deletions(-)
> create mode 100644 drivers/extcon/extcon-adc-jack.c
> create mode 100644 include/linux/extcon/extcon-adc-jack.h
>
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index e175c8e..dd5b01b 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -21,6 +21,12 @@ config EXTCON_GPIO
> Say Y here to enable GPIO based extcon support. Note that GPIO
> extcon supports single state per extcon instance.
>
> +config EXTCON_ADC_JACK
> + tristate "ADC Jack extcon support"
> + depends on IIO
> + help
> + Say Y here to enable extcon device driver based on ADC values.
> +
> config EXTCON_MAX77693
> tristate "MAX77693 EXTCON Support"
> depends on MFD_MAX77693
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 88961b3..bc7111e 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -4,6 +4,7 @@
>
> obj-$(CONFIG_EXTCON) += extcon_class.o
> obj-$(CONFIG_EXTCON_GPIO)+= extcon_gpio.o
> +obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
> obj-$(CONFIG_EXTCON_MAX77693)+= extcon-max77693.o
> obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
> diff --git a/drivers/extcon/extcon-adc-jack.c
> b/drivers/extcon/extcon-adc-jack.c
> new file mode 100644
> index 000..5a97a35
> --- /dev/null
> +++ b/drivers/extcon/extcon-adc-jack.c
> @@ -0,0 +1,195 @@
> +/*
> + * drivers/extcon/extcon-adc-jack.c
> + *
> + * Analog Jack extcon driver with ADC-based detection capability.
> + *
> + * Copyright (C) 2012 Samsung Electronics
> + * MyungJoo Ham
> + *
> + * Modified for calling to IIO to get adc by
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * struct adc_jack_data - internal data for adc_jack device driver
> + * @edev- extcon device.
> + * @cable_names - list of supported cables.
> + * @num_cables - size of cable_names.
> + * @adc_condition - list of adc value conditions.
> + * @num_condition - size of adc_condition.
it is num_conditions (not num_condition) in the code below
I suggest t use adc_conditions instead of adc_condition to be in line with
cable_names (vs. cable_name)
> + * @irq - irq number of attach/detach event (0 if not exist).
> + * @handling_delay - interrupt handler will schedule extcon event
> + * handling at handling_delay jiffies.
> + * @handler - extcon event handler called by interrupt handler.
> + * @chan - iio channel being queried.
> + */
> +struct adc_jack_data {
> + struct extcon_dev edev;
> +
> + const char **cable_names;
> + int num_cables;
> + struct adc_jack_cond *adc_condition;
> + int num_conditions;
> +
> + int irq;
> + unsigned long handling_delay; /* in jiffies */
> + struct delayed_work handler;
> +
> + struct iio_channel *chan;
> +};
> +
> +static void adc_jack_handler(struct work_struct *work)
> +{
> + struct adc_jack_data *data = container_of(to_delayed_work(work),
> + struct adc_jack_data,
> + handler);
> + u32 state = 0;
> + int ret, adc_val;
> + int i;
> +
> + ret = iio_read_channel_raw(data->chan, &adc_val);
> + if (ret < 0) {
> + dev_err(
Re: [PATCH v2] staging: gdm72xx: fix reference counting in gdm_wimax_event_init
Ben, I'm confused. Do you have a way to test this, or are you just doing manual review? regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] ARM: OMAP/ASoC: Zoom2: Let the codec to handle the hs_extmute GPIO
* Peter Ujfalusi [120808 02:42]: > Remove the use of set_hs_extmute callback and let the codec driver to > handle the extmute GPIO. Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: host: tegra: fix warning messages in ehci_remove
Existing implementation of tegra_ehci_remove() calls usb_put_hcd(hcd) first and then iounmap(hcd->regs). usb_put_hcd() implementation calls hcd_release() which frees up memory allocated for hcd. As iounmap is trying to unmap hcd->regs, after hcd getting freed up, warning messages were observed during unload of USB. Hence fixing it. Signed-off-by: Venu Byravarasu --- drivers/usb/host/ehci-tegra.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c index 950e95e..26dedb3 100644 --- a/drivers/usb/host/ehci-tegra.c +++ b/drivers/usb/host/ehci-tegra.c @@ -799,11 +799,12 @@ static int tegra_ehci_remove(struct platform_device *pdev) #endif usb_remove_hcd(hcd); - usb_put_hcd(hcd); tegra_usb_phy_close(tegra->phy); iounmap(hcd->regs); + usb_put_hcd(hcd); + clk_disable_unprepare(tegra->clk); clk_put(tegra->clk); -- 1.7.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ASoC: core: remove unused variable in soc_probe() in linux-next
With commit 28d528c8 "ASoC: core: Remove pointless error on card
registration failure", the variable ret is no longer used in
soc_probe() and generates an unused variable warning during a build.
Signed-off-by: Jerry Snitselaar
---
sound/soc/soc-core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 2d98ffc..7adf115 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1816,7 +1816,6 @@ base_error:
static int soc_probe(struct platform_device *pdev)
{
struct snd_soc_card *card = platform_get_drvdata(pdev);
- int ret = 0;
/*
* no card, so machine driver should be registering card
--
1.7.12.rc1.17.g9a7365c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio/omap: add *remove* callback in platform_driver
On Thu, Aug 9, 2012 at 8:28 PM, Kevin Hilman wrote: > "DebBarma, Tarun Kanti" writes: > >> On Wed, Aug 8, 2012 at 10:40 PM, Kevin Hilman wrote: >>> Tarun Kanti DebBarma writes: >>> Add *remove* callback so that necessary cleanup operations are performed when device is unregistered. The device is deleted from the list and associated clock handle is released by calling clk_put() and irq descriptor is released using the irq_free_desc() api. Signed-off-by: Tarun Kanti DebBarma Reported-by: Paul Walmsley Reviewed-by: Jon Hunter Cc: Kevin Hilman Cc: Rajendra Nayak Cc: Santosh Shilimkar Cc: Cousson, Benoit Cc: Paul Walmsley --- v2: Baseline: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Commit: 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee (Linux 3.6-rc1) (1) Use irq_free_descs() instead of irq_free_desc(). Besides, irq_free_desc() was using wrong parameter, irq_base, instead of bank->irq. (2) irq_free_descs() moved outside spin_lock/unlock_*() in order to avoid exception warnings. (3) pm_runtime_disable() added so that bind can happen successfully Test Detail: Step 1: Unbind gpio.5 device in order to invoke the *remove* callback. #echo "omap_gpio.5" > sys/bus/platform/drivers/omap_gpio/unbind Step 2: Bind gpio.5 device and confirm probe() for the device succeeds. #echo "omap_gpio.5" > sys/bus/platform/drivers/omap_gpio/bind Step 3: Execute read/write GPIO test case. >>> >>> What happens when GPIOs are in use (requested)? >> If I try to unbind a currently active GPIO bank then I see an exception >> after the irq descriptor is freed by the remove. I believe this is expected >> because interrupt raised by the system would not be handled. > > ... and the GPIO is still configured to trigger interrupts. Right! > > The point is that there is lots to cleanup/unconfigure properly for this > to work properly. As far as I can think of, all active gpio requests done either in board files or through DT have to be freed. But if this is done then when we bind() the device again initialization done in omap_gpio_probe() would not restore the board/DT related configuration. So the point is are we supposed to do all these cleanup in *remove* callback? If yes, how do we manage board level gpio usage? --- Tarun > > Kevin > >> [ 18.859405] irq_free_descs: calling free_desc(192)... >> [ 18.866180] irq_free_descs: calling free_desc(192)... >> [ 18.872680] irq_free_descs: calling free_desc(192)... >> [ 18.877990] irq_free_descs: calling free_desc(192)... >> [ 18.883270] irq_free_descs: calling free_desc(192)... >> [ 18.888549] irq_free_descs: calling free_desc(192)... >> [ 18.893859] irq_free_descs: calling free_desc(192)... >> [ 18.899139] irq_free_descs: calling free_desc(192)... >> [ 18.904418] irq_free_descs: calling free_desc(192)... >> [ 18.909729] irq_free_descs: calling free_desc(192)... >> [ 18.915008] irq_free_descs: calling free_desc(192)... >> [ 18.920288] irq_free_descs: calling free_desc(192)... >> [ 18.925598] irq_free_descs: calling free_desc(192)... >> [ 18.930877] irq_free_descs: calling free_desc(192)... >> [ 18.936157] irq_free_descs: calling free_desc(192)... >> [ 18.941467] irq_free_descs: calling free_desc(192)... >> [ 18.946746] irq_free_descs: calling free_desc(192)... >> [ 18.952026] irq_free_descs: calling free_desc(192)... >> [ 18.957336] irq_free_descs: calling free_desc(192)... >> [ 18.962615] irq_free_descs: calling free_desc(192)... >> [ 18.967895] irq_free_descs: calling free_desc(192)... >> [ 18.973205] irq_free_descs: calling free_desc(192)... >> [ 18.978485] irq_free_descs: calling free_desc(192)... >> [ 18.983764] irq_free_descs: calling free_desc(192)... >> [ 18.989074] irq_free_descs: calling free_desc(192)... >> [ 18.994354] irq_free_descs: calling free_desc(192)... >> [ 18.999633] irq_free_descs: calling free_desc(192)... >> [ 19.004913] irq_free_descs: calling free_desc(192)... >> [ 19.010223] irq_free_descs: calling free_desc(192)... >> [ 19.015502] irq_free_descs: calling free_desc(192)... >> [ 19.020782] irq_free_descs: calling free_desc(192)... >> [ 19.026092] irq_free_descs: calling free_desc(192)... >> [ 19.032440] irq 194, desc: c072f340, depth: 1, count: 0, unhandled: 0 >> [ 19.039154] ->handle_irq(): c00a3e08, handle_bad_irq+0x0/0x260 >> [ 19.045379] ->irq_data.chip(): c078ff7c, no_irq_chip+0x0/0x5c >> [ 19.051391] ->action(): ef0d42c0 >> [ 19.054748] ->action->handler(): c0399ee0, ks8851_irq+0x0/0x1c >> [ 19.060852]IRQ_NOPROBE set >> [ 19.064056] IRQ_NOREQUEST set >> [ 19.067230] Unable to handle kernel paging request at virtual address >> 203a6c9 >> [ 19.074768] pgd = c0004000 >> [ 19.077606] [203a6c99] *pgd= >> [ 19.081329] Internal error: Oops: 5 [#1] SMP ARM >> [
RE: [PATCH 08/10] ARM: s3c24xx: enable CONFIG_BUG for tct_hammer
Arnd Bergmann wrote: > > Disabling CONFIG_BUG creates an insane amount of build warnings, which > makes it useless to check for building defconfigs to see if new > warnings show up. > > Without this patch, building tct_hammer_defconfig results in: > > net/packet/af_packet.c: In function 'tpacket_rcv': > net/packet/af_packet.c:1889:30: warning: 'hdrlen' may be used > uninitialized in this function [-Wuninitialized] > net/core/ethtool.c: In function 'ethtool_get_feature_mask': > net/core/ethtool.c:213:1: warning: control reaches end of non-void > function [-Wreturn-type] > block/cfq-iosched.c: In function 'cfq_async_queue_prio': > block/cfq-iosched.c:2914:1: warning: control reaches end of non-void > function [-Wreturn-type] > mm/bootmem.c: In function 'mark_bootmem': > mm/bootmem.c:352:1: warning: control reaches end of non-void function [- > Wreturn-type] > net/core/dev.c: In function 'skb_warn_bad_offload': > net/core/dev.c:1904:33: warning: unused variable 'null_features' [- > Wunused-variable] > drivers/mtd/chips/cfi_probe.c: In function 'cfi_chip_setup': > include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized > in this function [-Wuninitialized] > include/linux/mtd/map.h:394:11: note: 'r.x[0]' was declared here > include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized > in this function [-Wuninitialized] > (and many more) > > The size of vmlinux increases by 1.78% because of this: > > size obj-arm/vmlinux.nobug >textdata bss dec hex filename >2108474 116916 55352 2280742 22cd26 obj-arm/vmlinux > size obj-arm/vmlinux.bug >textdata bss dec hex filename >2150804 116916 53696 2321416 236c08 obj-arm/vmlinux > > Signed-off-by: Arnd Bergmann > Cc: Kukjin Kim Acked-by: Kukjin Kim BTW, I'm not sure we should still keep the tct_hammer_defconfig because s3c2410_defconfig is including MACH_TCT_HAMMER, its selection are different though. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > Cc: Ben Dooks > --- > arch/arm/configs/tct_hammer_defconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/configs/tct_hammer_defconfig > b/arch/arm/configs/tct_hammer_defconfig > index 1d24f84..71277a1 100644 > --- a/arch/arm/configs/tct_hammer_defconfig > +++ b/arch/arm/configs/tct_hammer_defconfig > @@ -7,7 +7,7 @@ CONFIG_SYSFS_DEPRECATED_V2=y > CONFIG_BLK_DEV_INITRD=y > CONFIG_EXPERT=y > # CONFIG_KALLSYMS is not set > -# CONFIG_BUG is not set > +# CONFIG_BUGVERBOSE is not set > # CONFIG_ELF_CORE is not set > # CONFIG_SHMEM is not set > CONFIG_SLOB=y > -- > 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched: remove useless code in yield_to
On Fri, 2012-08-10 at 11:10 +0800, Michael Wang wrote:
> On 08/10/2012 11:05 AM, Michael Wang wrote:
> > On 07/03/2012 02:34 PM, Michael Wang wrote:
> >> From: Michael Wang
> >>
> >> it's impossible to enter else branch if we have set skip_clock_update
> >> in task_yield_fair(), as yield_to_task_fair() will directly return
> >> true after invoke task_yield_fair().
> >
> > Could I get some conclusion on this patch? Should we clean up that peace
> > of code or leave it there?
> s /peace/piece and cc mike...
If some other class grows yield_to_task (ick), it'll have to be looked
at again, but hopefully for all eternity that branch is dead. Bury it.
> >
> > Regards,
> > Michael Wang
> >
> >>
> >> Signed-off-by: Michael Wang
> >> ---
> >> kernel/sched/core.c |7 ---
> >> 1 files changed, 0 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> >> index 9bb7d28..77c14aa 100644
> >> --- a/kernel/sched/core.c
> >> +++ b/kernel/sched/core.c
> >> @@ -4737,13 +4737,6 @@ again:
> >> */
> >>if (preempt && rq != p_rq)
> >>resched_task(p_rq->curr);
> >> - } else {
> >> - /*
> >> - * We might have set it in task_yield_fair(), but are
> >> - * not going to schedule(), so don't want to skip
> >> - * the next update.
> >> - */
> >> - rq->skip_clock_update = 0;
> >>}
> >>
> >> out:
> >>
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@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: thermal patches in linux-next
On 五, 2012-08-10 at 10:37 +0530, Amit Kachhap wrote: > On 10 August 2012 08:14, Zhang Rui wrote: > > On 五, 2012-08-10 at 12:23 +1000, Stephen Rothwell wrote: > >> Hi Rui, > >> > >> On Fri, 10 Aug 2012 09:41:06 +0800 Zhang Rui wrote: > >> > > >> > > > And could you please drop these commits > >> > > > ef25a0fe0087963c1611c1c8903886fbea053f76 > >> > > > 09ec52fca274ba88d68df3198de92abdaaff417b > >> > > > ab6d2f029358c917508bf88bbd6a9193a8e39fc8 > >> > > > 66447fa993cbce56b4076f169a56f62350f6c7b8 > >> > > > ec62abb8b46021ca9ee6b8692b26974ace9007f0 > >> > > > 5ecbaf57d7885eedd924e391d91847d3df9fe0f8 > >> > > > 851414b2249afd8c128d29912dfd7060eaea8932 > >> > > > and pull my next branch instead? > >> > > > >> > > That is not how linux-next normally works. Those commits are in > >> > > Adnrew's > >> > > quilt series, so you need to ask him to drop them. However, because of > >> > > the way the akpm tree works, any duplicate patches will disappear from > >> > > my > >> > > copy of Andrew's series. > >> > > >> > could you please drop these patches? > >> > these commits either will be or has been re-based on top of my tree. > >> > >> You should always quote the summary line of commits. Andrew is using > >> quilt to manage his patches and so those commit ids mean nothing to him > >> (and they have changed in today's linux-next anyway). > >> > > got it. > > > > Andrew, > > could you please drop these patches from Amit for now? > > > > ARM: exynos: add thermal sensor driver platform data support > > thermal: exynos: register the tmu sensor with the kernel thermal layer > > thermal: exynos5: add exynos5 thermal sensor driver support > > hwmon: exynos4: move thermal sensor driver to driver/thermal directory > > thermal: add generic cpufreq cooling implementation > > > > these patches can not build because of the recent thermal changes, and > > Amit agreed with me to re-base them on top of my tree. > > Or may be it is better to let them be in linux-next as it is and I > will create a separate adaptation patch to work with Zhang's new > thermal enhancements. Actually the above patches are being used > internally. > well, as the patches has not been in Linus' tree, and they do not compile, IMO, it would be better to fix it in the patch rather than create an incremental one. I can rewrite the generic cpufreq cooling patch if you do not have time to. thanks, rui > Thanks, > Amit Daniel > > > > > thanks, > > rui > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Q: pinctrl: freeing out the allocated map in tegra_pinctrl_dt_node_to_map
On Fri, Aug 10, 2012 at 11:02 AM, devendra.aaru wrote:
> Hi,
>
> In function tegra_pinctrl_dt_node_to_map the num_maps the num_maps
> counter must be incremented for each child node?
>
>
> Actually we are doing free until num_maps if tegra_pinctrl_dt_subnode_to_map,
>
> not only that if num_maps == 0, we wont free up the maps, and also i
> think the for_each_of_node checks whether we have a next child node,
> so its safe to do num_maps++ as it wont get incremented endlessly,
>
> Please correct me if i am wrong.
>
> Thanks,
>
>
> diff --git a/drivers/pinctrl/pinctrl-tegra.c b/drivers/pinctrl/pinctrl-tegra.c
> index ae52e4e..33ae918 100644
> --- a/drivers/pinctrl/pinctrl-tegra.c
> +++ b/drivers/pinctrl/pinctrl-tegra.c
> @@ -303,6 +303,7 @@ int tegra_pinctrl_dt_node_to_map(struct
> pinctrl_dev *pctldev,
> *num_maps = 0;
>
> for_each_child_of_node(np_config, np) {
> + num_maps++;
> ret = tegra_pinctrl_dt_subnode_to_map(pctldev->dev, np, map,
> &reserved_maps,
> num_maps);
> if (ret < 0) {
Sorry all, I forgot to add the subject line.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[no subject]
Hi,
In function tegra_pinctrl_dt_node_to_map the num_maps the num_maps
counter must be incremented for each child node?
Actually we are doing free until num_maps if tegra_pinctrl_dt_subnode_to_map,
not only that if num_maps == 0, we wont free up the maps, and also i
think the for_each_of_node checks whether we have a next child node,
so its safe to do num_maps++ as it wont get incremented endlessly,
Please correct me if i am wrong.
Thanks,
diff --git a/drivers/pinctrl/pinctrl-tegra.c b/drivers/pinctrl/pinctrl-tegra.c
index ae52e4e..33ae918 100644
--- a/drivers/pinctrl/pinctrl-tegra.c
+++ b/drivers/pinctrl/pinctrl-tegra.c
@@ -303,6 +303,7 @@ int tegra_pinctrl_dt_node_to_map(struct
pinctrl_dev *pctldev,
*num_maps = 0;
for_each_child_of_node(np_config, np) {
+ num_maps++;
ret = tegra_pinctrl_dt_subnode_to_map(pctldev->dev, np, map,
&reserved_maps, num_maps);
if (ret < 0) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[3.5.1] tg3 waitqueue hang on hotplug remove...
Hi Matt, Michael, On my Macbook Retina with 3.5.1, I see the tg3 external adapter (via Thunderbolt) get logically disconnected after a while despite remaining connected (Thunderbolt issues). The problem is though, that the pciehp_wq workqueue fails to complete flushing from the call to pcie_cleanup_slot (inlined in pciehp_release_ctrl) [1]; looks like tg3_tx or so is missing a finish_wait(), no? Daniel --- [1] pcieport :00:01.0: irq 42 for MSI/MSI-X pcieport :00:01.1: irq 43 for MSI/MSI-X pcieport :00:01.2: irq 44 for MSI/MSI-X pcieport :05:00.0: irq 45 for MSI/MSI-X pcieport :06:00.0: irq 46 for MSI/MSI-X pcieport :06:03.0: irq 47 for MSI/MSI-X pcieport :06:04.0: irq 48 for MSI/MSI-X pcieport :06:05.0: irq 49 for MSI/MSI-X pcieport :06:06.0: irq 50 for MSI/MSI-X pcieport :08:00.0: irq 51 for MSI/MSI-X pcieport :09:00.0: irq 52 for MSI/MSI-X pci_hotplug: PCI Hot Plug PCI Core version: 0.5 pciehp :06:00.0:pcie24: HPC vendor_id 8086 device_id 1547 ss_vid ss_did pciehp :06:00.0:pcie24: service driver pciehp loaded pciehp :06:03.0:pcie24: HPC vendor_id 8086 device_id 1547 ss_vid ss_did pciehp :06:03.0:pcie24: service driver pciehp loaded pciehp :06:04.0:pcie24: HPC vendor_id 8086 device_id 1547 ss_vid ss_did pciehp :06:04.0:pcie24: service driver pciehp loaded pciehp :06:05.0:pcie24: HPC vendor_id 8086 device_id 1547 ss_vid ss_did pciehp :06:05.0:pcie24: service driver pciehp loaded pciehp :06:06.0:pcie24: HPC vendor_id 8086 device_id 1547 ss_vid ss_did pciehp :06:06.0:pcie24: service driver pciehp loaded pciehp :09:00.0:pcie24: HPC vendor_id 8086 device_id 1549 ss_vid 0 ss_did 0 pciehp :09:00.0:pcie24: service driver pciehp loaded pciehp: PCI Express Hot Plug Controller Driver version: 0.4 tg3 :0a:00.0: eth0: Tigon3 [partno(BCM957762) rev 57766000] (PCI Express) MAC address 40:6c:8f:36:1a:67 tg3 :0a:00.0: eth0: attached PHY is 57765 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0]) tg3 :0a:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1] tg3 :0a:00.0: eth0: dma_rwctrl[0001] dma_mask[64-bit] ... pciehp :06:03.0:pcie24: Card not present on Slot(3) tg3 :0a:00.0: tg3_abort_hw timed out, TX_MODE_ENABLE will not clear MAC_TX_MODE= tg3 :0a:00.0: eth1: No firmware running tg3 :0a:00.0: eth1: Link is down [sched_delayed] sched: RT throttling activated pciehp :09:00.0:pcie24: unloading service driver pciehp INFO: task kworker/0:2:3072 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/0:2 D 8180cc20 0 3072 2 0x 880237f75800 0046 0001 880237f757b0 880237f75fd8 880237f75fd8 880237f75fd8 00013940 88025f3b5c00 880237eb5c00 7fff Call Trace: [] schedule+0x29/0x70 [] schedule_timeout+0x2a5/0x320 [] ? default_spin_lock_flags+0x9/0x10 [] ? pde_put+0x79/0xa0 [] wait_for_common+0xdf/0x180 [] ? pde_put+0x79/0xa0 [] ? try_to_wake_up+0x200/0x200 [] wait_for_completion+0x1d/0x20 [] flush_workqueue+0x143/0x400 [] ? pciehp_disable_slot+0x1f0/0x1f0 [] pciehp_release_ctrl+0x46/0xa0 [] pciehp_remove+0x27/0x30 [] pcie_port_remove_service+0x57/0x70 [] __device_release_driver+0x7c/0xe0 [] device_release_driver+0x2c/0x40 [] bus_remove_device+0xe1/0x120 [] ? resume_iter+0x40/0x40 [] device_del+0x120/0x1b0 [] ? resume_iter+0x40/0x40 [] device_unregister+0x16/0x30 [] remove_iter+0x3d/0x50 [] device_for_each_child+0x44/0x70 [] pcie_port_device_remove+0x26/0x40 [] pcie_portdrv_remove+0x16/0x30 [] pci_device_remove+0x46/0x110 [] __device_release_driver+0x7c/0xe0 [] device_release_driver+0x2c/0x40 [] bus_remove_device+0xe1/0x120 [] device_del+0x120/0x1b0 [] device_unregister+0x16/0x30 [] pci_stop_bus_device+0x94/0xa0 [] pci_stop_bus_device+0x43/0xa0 [] pci_stop_and_remove_bus_device+0x16/0x30 [] pciehp_unconfigure_device+0x91/0x190 [] pciehp_disable_slot+0x75/0x1f0 [] pciehp_power_thread+0xe3/0x110 [] process_one_work+0x11a/0x480 [] worker_thread+0x165/0x370 [] ? manage_workers.isra.29+0x130/0x130 [] kthread+0x93/0xa0 [] kernel_thread_helper+0x4/0x10 [] ? kthread_freezable_should_stop+0x70/0x70 [] ? gs_change+0x13/0x13 -- Daniel J Blueman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] uprobes: remove check for uprobe variable in handle_swbp()
On 08/08/2012 03:05 PM, Sebastian Andrzej Siewior wrote:
On 08/08/2012 11:10 AM, Suzuki K. Poulose wrote:
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1528,17 +1528,15 @@ cleanup_ret:
utask->active_uprobe = NULL;
utask->state = UTASK_RUNNING;
}
- if (uprobe) {
- if (!(uprobe->flags & UPROBE_SKIP_SSTEP))
+ if (!(uprobe->flags & UPROBE_SKIP_SSTEP))
Shouldn't we check uprobe != NULL before we check the uprobe->flags ?
i.e, shouldn't the above line be :
if (uprobe && ! (uprobe->flags & UPROBE_SKIP_SSTEP)) ?
The function starts like this:
if (!uprobe) {
if (is_swbp > 0) {
send_sig(SIGTRAP, current, 0);
} else {
instruction_pointer_set(regs, bp_vaddr);
}
return;
}
Which makes uprobe != NULL by the time we get there, no?
My bad, was looking at an older version of the function. Also,
the removal of the if (uprobe), check triggered the above question.
Thanks
Suzuki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [PATCH V5]Extcon: adc_jack: adc-jack driver to support 3.5 pi or simliar devices
From: anish kumar
External connector devices that decides connection information based on
ADC values may use adc-jack device driver. The user simply needs to
provide a table of adc range and connection states. Then, extcon
framework will automatically notify others.
Changes in V1:
added Lars-Peter Clausen suggested changes:
Using macros to get rid of boiler plate code such as devm_kzalloc
and module_platform_driver.Other changes suggested are related to
coding guidelines.
Changes in V2:
Removed some unnecessary checks and changed the way we are un-regitering
extcon and freeing the irq while removing.
Changes in V3:
Renamed the files to comply with extcon naming.
Changes in V4:
Added the cancel_work_sync during removing of driver.
Changes in this version:
Added the dependency of IIO in Kconfig.
Reviewed-by: Lars-Peter Clausen
Signed-off-by: anish kumar
Signed-off-by: MyungJoo Ham
---
drivers/extcon/Kconfig |6 +
drivers/extcon/Makefile|1 +
drivers/extcon/extcon-adc-jack.c | 195
include/linux/extcon/extcon-adc-jack.h | 73
4 files changed, 275 insertions(+), 0 deletions(-)
create mode 100644 drivers/extcon/extcon-adc-jack.c
create mode 100644 include/linux/extcon/extcon-adc-jack.h
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index e175c8e..dd5b01b 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -21,6 +21,12 @@ config EXTCON_GPIO
Say Y here to enable GPIO based extcon support. Note that GPIO
extcon supports single state per extcon instance.
+config EXTCON_ADC_JACK
+ tristate "ADC Jack extcon support"
+ depends on IIO
+ help
+ Say Y here to enable extcon device driver based on ADC values.
+
config EXTCON_MAX77693
tristate "MAX77693 EXTCON Support"
depends on MFD_MAX77693
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 88961b3..bc7111e 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -4,6 +4,7 @@
obj-$(CONFIG_EXTCON) += extcon_class.o
obj-$(CONFIG_EXTCON_GPIO) += extcon_gpio.o
+obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
new file mode 100644
index 000..5a97a35
--- /dev/null
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -0,0 +1,195 @@
+/*
+ * drivers/extcon/extcon-adc-jack.c
+ *
+ * Analog Jack extcon driver with ADC-based detection capability.
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * MyungJoo Ham
+ *
+ * Modified for calling to IIO to get adc by
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct adc_jack_data - internal data for adc_jack device driver
+ * @edev- extcon device.
+ * @cable_names - list of supported cables.
+ * @num_cables - size of cable_names.
+ * @adc_condition - list of adc value conditions.
+ * @num_condition - size of adc_condition.
+ * @irq - irq number of attach/detach event (0 if not exist).
+ * @handling_delay - interrupt handler will schedule extcon event
+ * handling at handling_delay jiffies.
+ * @handler - extcon event handler called by interrupt handler.
+ * @chan - iio channel being queried.
+ */
+struct adc_jack_data {
+ struct extcon_dev edev;
+
+ const char **cable_names;
+ int num_cables;
+ struct adc_jack_cond *adc_condition;
+ int num_conditions;
+
+ int irq;
+ unsigned long handling_delay; /* in jiffies */
+ struct delayed_work handler;
+
+ struct iio_channel *chan;
+};
+
+static void adc_jack_handler(struct work_struct *work)
+{
+ struct adc_jack_data *data = container_of(to_delayed_work(work),
+ struct adc_jack_data,
+ handler);
+ u32 state = 0;
+ int ret, adc_val;
+ int i;
+
+ ret = iio_read_channel_raw(data->chan, &adc_val);
+ if (ret < 0) {
+ dev_err(data->edev.dev, "read channel() error: %d\n", ret);
+ return;
+ }
+
+ /* Get state from adc value with adc_condition */
+ for (i = 0; i < data->num_conditions; i++) {
+ struct adc_jack_cond *def = &data->adc_condition[i];
+ if (!def->state)
+ break;
+ if (def->min_adc <= adc_val && def->max_adc >= adc_val) {
+ state = def->state;
+ break;
Re: [PATCH] Intel xhci: Only switch the switchable ports
On Fri, Aug 10, 2012 at 3:38 AM, Sarah Sharp wrote: > On Fri, Aug 10, 2012 at 12:13:19AM +0800, Keng-Yu Lin wrote: >> On Thu, Aug 9, 2012 at 10:24 PM, Sarah Sharp >> wrote: >> > On Thu, Aug 09, 2012 at 05:31:51PM +0800, Keng-Yu Lin wrote: >> >> With a previous patch to enable the EHCI/XHCI port switching, it switches >> >> all the available ports. >> >> >> >> The assumption is not correct because the BIOS may expect some ports >> >> not switchable by the OS. >> > >> > Why would the BIOS expect some ports to not be switchable? I know that >> > we internally at Intel had discussed some theoretical reasons why it >> > might not be good to switch some ports, but when I presented the >> > original patch with this same code in it to Linux USB mailing list, both >> > Alan and Greg said, "Why not unconditionally switch ports?" I had no >> > good examples at the time. >> > >> > Is this causing issues with some particular BIOS? >> > >> >> Yes, this is causing the internal webcam missing on the USB bus as I >> observed on some HM70-based laptops. > > Does anything show up in dmesg when you turn on > CONFIG_USB_XHCI_HCD_DEBUGGING? It would be good to know if it is > totally not electrically present, or if there's some sort of xHCI > hardware or software issue that's preventing the webcam from being > enumerated. > I will try to collect the log when I have the laptops handy. >> The internal webcam is attached to one port that is controlled by the >> xhci host. >> But the other ports with the outer plugs work well after booting. I >> cannot test the USB port of the internal webcam easily (without >> tearing down the laptop :-/). >> >> I also tried some similar HM77-based models. HM77 has no this issue. >> This could be some chipset mystery I am not aware now. > > Could be. Can you use any SMBIOS information to change the port > switchover only for those HM70-based laptops? And is it a particular > laptop vendor or all HM70 laptops? > > As Alan said, I would rather not trust the BIOS to provide the correct > port mask. > Frankly, IMHO, I think the patch is not about to trust or not to trust the BIOS. I think this patch just does what the registers are designed to do. What if there is a good BIOS claiming some ports not to be switchable but kernel does so. Isn't it a bad kernel too? :-) cheers, -kengyu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: thermal patches in linux-next
On 10 August 2012 08:14, Zhang Rui wrote: > On 五, 2012-08-10 at 12:23 +1000, Stephen Rothwell wrote: >> Hi Rui, >> >> On Fri, 10 Aug 2012 09:41:06 +0800 Zhang Rui wrote: >> > >> > > > And could you please drop these commits >> > > > ef25a0fe0087963c1611c1c8903886fbea053f76 >> > > > 09ec52fca274ba88d68df3198de92abdaaff417b >> > > > ab6d2f029358c917508bf88bbd6a9193a8e39fc8 >> > > > 66447fa993cbce56b4076f169a56f62350f6c7b8 >> > > > ec62abb8b46021ca9ee6b8692b26974ace9007f0 >> > > > 5ecbaf57d7885eedd924e391d91847d3df9fe0f8 >> > > > 851414b2249afd8c128d29912dfd7060eaea8932 >> > > > and pull my next branch instead? >> > > >> > > That is not how linux-next normally works. Those commits are in Adnrew's >> > > quilt series, so you need to ask him to drop them. However, because of >> > > the way the akpm tree works, any duplicate patches will disappear from my >> > > copy of Andrew's series. >> > >> > could you please drop these patches? >> > these commits either will be or has been re-based on top of my tree. >> >> You should always quote the summary line of commits. Andrew is using >> quilt to manage his patches and so those commit ids mean nothing to him >> (and they have changed in today's linux-next anyway). >> > got it. > > Andrew, > could you please drop these patches from Amit for now? > > ARM: exynos: add thermal sensor driver platform data support > thermal: exynos: register the tmu sensor with the kernel thermal layer > thermal: exynos5: add exynos5 thermal sensor driver support > hwmon: exynos4: move thermal sensor driver to driver/thermal directory > thermal: add generic cpufreq cooling implementation > > these patches can not build because of the recent thermal changes, and > Amit agreed with me to re-base them on top of my tree. Or may be it is better to let them be in linux-next as it is and I will create a separate adaptation patch to work with Zhang's new thermal enhancements. Actually the above patches are being used internally. Thanks, Amit Daniel > > thanks, > rui > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] lp8727_charger: free_irq when lp8727_register_psy fail
Sorry to ask this again,
But will anybody please ACK , NACK or comment on this patch?
Thanks,
Devendra.
On Sun, Jul 29, 2012 at 11:16 PM, Devendra Naga
wrote:
> actually the driver does a request_threaded_irq and after this it calls
> lp8727_register_psy, and if it fails it doesn't free the irqs that it
> registered to
>
> Signed-off-by: Devendra Naga
> ---
> drivers/power/lp8727_charger.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/lp8727_charger.c b/drivers/power/lp8727_charger.c
> index d8b7578..699f0ef 100644
> --- a/drivers/power/lp8727_charger.c
> +++ b/drivers/power/lp8727_charger.c
> @@ -454,11 +454,13 @@ static int lp8727_probe(struct i2c_client *cl, const
> struct i2c_device_id *id)
> ret = lp8727_register_psy(pchg);
> if (ret) {
> dev_err(pchg->dev, "power supplies register err: %d", ret);
> - goto error;
> + goto error_irq;
> }
>
> return 0;
>
> +error_irq:
> + free_irq(pchg->client->irq, pchg);
> error:
> kfree(pchg);
> return ret;
> --
> 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] [PATCH V4]Extcon: adc_jack: adc-jack driver to support 3.5 pi or simliar devices
On Fri, 2012-08-10 at 04:39 +, MyungJoo Ham wrote:
> > From: anish kumar
> >
> > External connector devices that decides connection information based on
> > ADC values may use adc-jack device driver. The user simply needs to
> > provide a table of adc range and connection states. Then, extcon
> > framework will automatically notify others.
>
> 1. Missing header: #include
I didn't come across any problem when I compiled.Is this really needed?
> 2. Missing dependency to IIO. (please add IIO dependency at Kconfig)
Ya forgot that.Sending in some time.
>
>
> Cheers!
> MyungJoo
>
> >
> > Changes in V1:
> > added Lars-Peter Clausen suggested changes:
> > Using macros to get rid of boiler plate code such as devm_kzalloc
> > and module_platform_driver.Other changes suggested are related to
> > coding guidelines.
> >
> > Changes in V2:
> > Removed some unnecessary checks and changed the way we are un-regitering
> > extcon and freeing the irq while removing.
> >
> > Changes in V3:
> > Renamed the files to comply with extcon naming.
> >
> > Changes in this version:
> > Added the cancel_work_sync during removing of driver.
> >
> > Reviewed-by: Lars-Peter Clausen
> > Signed-off-by: anish kumar
> > Signed-off-by: MyungJoo Ham
> > ---
> > drivers/extcon/Kconfig |5 +
> > drivers/extcon/Makefile|1 +
> > drivers/extcon/extcon-adc-jack.c | 194
> >
> > include/linux/extcon/extcon-adc-jack.h | 73
> > 4 files changed, 273 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/extcon/extcon-adc-jack.c
> > create mode 100644 include/linux/extcon/extcon-adc-jack.h
> >
> > diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> > index e175c8e..596e277 100644
> > --- a/drivers/extcon/Kconfig
> > +++ b/drivers/extcon/Kconfig
> > @@ -21,6 +21,11 @@ config EXTCON_GPIO
> > Say Y here to enable GPIO based extcon support. Note that GPIO
> > extcon supports single state per extcon instance.
> >
> > +config EXTCON_ADC_JACK
> > +tristate "ADC Jack extcon support"
> > +help
> > + Say Y here to enable extcon device driver based on ADC values.
> > +
> > config EXTCON_MAX77693
> > tristate "MAX77693 EXTCON Support"
> > depends on MFD_MAX77693
> > diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> > index 88961b3..bc7111e 100644
> > --- a/drivers/extcon/Makefile
> > +++ b/drivers/extcon/Makefile
> > @@ -4,6 +4,7 @@
> >
> > obj-$(CONFIG_EXTCON) += extcon_class.o
> > obj-$(CONFIG_EXTCON_GPIO) += extcon_gpio.o
> > +obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
> > obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
> > obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> > obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
> > diff --git a/drivers/extcon/extcon-adc-jack.c
> > b/drivers/extcon/extcon-adc-jack.c
> > new file mode 100644
> > index 000..cfc8c59
> > --- /dev/null
> > +++ b/drivers/extcon/extcon-adc-jack.c
> > @@ -0,0 +1,194 @@
> > +/*
> > + * drivers/extcon/extcon-adc-jack.c
> > + *
> > + * Analog Jack extcon driver with ADC-based detection capability.
> > + *
> > + * Copyright (C) 2012 Samsung Electronics
> > + * MyungJoo Ham
> > + *
> > + * Modified for calling to IIO to get adc by
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/**
> > + * struct adc_jack_data - internal data for adc_jack device driver
> > + * @edev- extcon device.
> > + * @cable_names - list of supported cables.
> > + * @num_cables - size of cable_names.
> > + * @adc_condition - list of adc value conditions.
> > + * @num_condition - size of adc_condition.
> > + * @irq - irq number of attach/detach event (0 if not exist).
> > + * @handling_delay - interrupt handler will schedule extcon event
> > + * handling at handling_delay jiffies.
> > + * @handler - extcon event handler called by interrupt handler.
> > + * @chan - iio channel being queried.
> > + */
> > +struct adc_jack_data {
> > + struct extcon_dev edev;
> > +
> > + const char **cable_names;
> > + int num_cables;
> > + struct adc_jack_cond *adc_condition;
> > + int num_conditions;
> > +
> > + int irq;
> > + unsigned long handling_delay; /* in jiffies */
> > + struct delayed_work handler;
> > +
> > + struct iio_channel *chan;
> > +};
> > +
> > +static void adc_jack_handler(struct work_struct *work)
> > +{
> > + struct adc_jack_data *data = container_of(to_delayed_work(work),
> > + struct adc_jack_data,
> > +
[PATCH 1/2] pwm: vt8500: Fix coding style issue
Fixes the following:
WARNING: Prefer pr_warn(... to pr_warning(...
pr_warning("Waiting for status bits 0x%x to clear timed out\n",
Signed-off-by: Sachin Kamat
---
drivers/pwm/pwm-vt8500.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index 5480214..ad14389 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -41,7 +41,7 @@ static inline void pwm_busy_wait(void __iomem *reg, u8
bitmask)
cpu_relax();
if (unlikely(!loops))
- pr_warning("Waiting for status bits 0x%x to clear timed out\n",
+ pr_warn("Waiting for status bits 0x%x to clear timed out\n",
bitmask);
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] pwm: core: Fix coding style issues
Fixes the following:
WARNING: line over 80 characters
ERROR: spaces required around that ':' (ctx:VxW)
WARNING: Prefer pr_warn(... to pr_warning(...
Signed-off-by: Sachin Kamat
---
drivers/pwm/core.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index efc20f8..929be13 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -130,7 +130,7 @@ static int pwm_device_request(struct pwm_device *pwm, const
char *label)
}
static struct pwm_device *of_pwm_simple_xlate(struct pwm_chip *pc,
- const struct of_phandle_args
*args)
+const struct of_phandle_args *args)
{
struct pwm_device *pwm;
@@ -549,7 +549,7 @@ void __init pwm_add_table(struct pwm_lookup *table, size_t
num)
struct pwm_device *pwm_get(struct device *dev, const char *con_id)
{
struct pwm_device *pwm = ERR_PTR(-EPROBE_DEFER);
- const char *dev_id = dev ? dev_name(dev): NULL;
+ const char *dev_id = dev ? dev_name(dev) : NULL;
struct pwm_chip *chip = NULL;
unsigned int index = 0;
unsigned int best = 0;
@@ -631,7 +631,7 @@ void pwm_put(struct pwm_device *pwm)
mutex_lock(&pwm_lock);
if (!test_and_clear_bit(PWMF_REQUESTED, &pwm->flags)) {
- pr_warning("PWM device already freed\n");
+ pr_warn("PWM device already freed\n");
goto out;
}
--
1.7.4.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] [PATCH V4]Extcon: adc_jack: adc-jack driver to support 3.5 pi or simliar devices
> From: anish kumar
>
> External connector devices that decides connection information based on
> ADC values may use adc-jack device driver. The user simply needs to
> provide a table of adc range and connection states. Then, extcon
> framework will automatically notify others.
1. Missing header: #include
2. Missing dependency to IIO. (please add IIO dependency at Kconfig)
Cheers!
MyungJoo
>
> Changes in V1:
> added Lars-Peter Clausen suggested changes:
> Using macros to get rid of boiler plate code such as devm_kzalloc
> and module_platform_driver.Other changes suggested are related to
> coding guidelines.
>
> Changes in V2:
> Removed some unnecessary checks and changed the way we are un-regitering
> extcon and freeing the irq while removing.
>
> Changes in V3:
> Renamed the files to comply with extcon naming.
>
> Changes in this version:
> Added the cancel_work_sync during removing of driver.
>
> Reviewed-by: Lars-Peter Clausen
> Signed-off-by: anish kumar
> Signed-off-by: MyungJoo Ham
> ---
> drivers/extcon/Kconfig |5 +
> drivers/extcon/Makefile|1 +
> drivers/extcon/extcon-adc-jack.c | 194
>
> include/linux/extcon/extcon-adc-jack.h | 73
> 4 files changed, 273 insertions(+), 0 deletions(-)
> create mode 100644 drivers/extcon/extcon-adc-jack.c
> create mode 100644 include/linux/extcon/extcon-adc-jack.h
>
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index e175c8e..596e277 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -21,6 +21,11 @@ config EXTCON_GPIO
> Say Y here to enable GPIO based extcon support. Note that GPIO
> extcon supports single state per extcon instance.
>
> +config EXTCON_ADC_JACK
> +tristate "ADC Jack extcon support"
> +help
> + Say Y here to enable extcon device driver based on ADC values.
> +
> config EXTCON_MAX77693
> tristate "MAX77693 EXTCON Support"
> depends on MFD_MAX77693
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 88961b3..bc7111e 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -4,6 +4,7 @@
>
> obj-$(CONFIG_EXTCON) += extcon_class.o
> obj-$(CONFIG_EXTCON_GPIO)+= extcon_gpio.o
> +obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
> obj-$(CONFIG_EXTCON_MAX77693)+= extcon-max77693.o
> obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
> diff --git a/drivers/extcon/extcon-adc-jack.c
> b/drivers/extcon/extcon-adc-jack.c
> new file mode 100644
> index 000..cfc8c59
> --- /dev/null
> +++ b/drivers/extcon/extcon-adc-jack.c
> @@ -0,0 +1,194 @@
> +/*
> + * drivers/extcon/extcon-adc-jack.c
> + *
> + * Analog Jack extcon driver with ADC-based detection capability.
> + *
> + * Copyright (C) 2012 Samsung Electronics
> + * MyungJoo Ham
> + *
> + * Modified for calling to IIO to get adc by
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * struct adc_jack_data - internal data for adc_jack device driver
> + * @edev- extcon device.
> + * @cable_names - list of supported cables.
> + * @num_cables - size of cable_names.
> + * @adc_condition - list of adc value conditions.
> + * @num_condition - size of adc_condition.
> + * @irq - irq number of attach/detach event (0 if not exist).
> + * @handling_delay - interrupt handler will schedule extcon event
> + * handling at handling_delay jiffies.
> + * @handler - extcon event handler called by interrupt handler.
> + * @chan - iio channel being queried.
> + */
> +struct adc_jack_data {
> + struct extcon_dev edev;
> +
> + const char **cable_names;
> + int num_cables;
> + struct adc_jack_cond *adc_condition;
> + int num_conditions;
> +
> + int irq;
> + unsigned long handling_delay; /* in jiffies */
> + struct delayed_work handler;
> +
> + struct iio_channel *chan;
> +};
> +
> +static void adc_jack_handler(struct work_struct *work)
> +{
> + struct adc_jack_data *data = container_of(to_delayed_work(work),
> + struct adc_jack_data,
> + handler);
> + u32 state = 0;
> + int ret, adc_val;
> + int i;
> +
> + ret = iio_read_channel_raw(data->chan, &adc_val);
> + if (ret < 0) {
> + dev_err(data->edev.dev, "read channel() error: %d\n", ret);
> + return;
> + }
> +
> + /* Get state from adc value with adc_condition */
> + for (i = 0; i < data->num_conditions; i++) {
> + struct
Re: [RFC PATCH v2 10/16] ACPIHP: system device hotplug driver skeleton
On 08/09/2012 05:36 PM, Jiang Liu wrote: >> And I just tried it some more times. It just hung up, but dmesg had no >> output. >> Like this: >> >> # modprobe acpihp_enum >> (OK, and sysfs interfaces have been created) >> # modprobe acpihp_drv >> (hang up) >> >> # dmesg >> (nothing) >> >> The "modprobe acpihp_drv" process's call trace shows that it hung at the >> following function: >> #0 0x0032836aab80 in __nanosleep_nocancel () from /lib64/libc.so.6 >> #1 0x0032836deb64 in usleep () from /lib64/libc.so.6 >> .. >> >> I have tried several times and I cannot reproduce the situation I just said. > You can reproduce it by loading acpihp_drv without acpihp_enum driver, I > guess. > The acpihp_drv module_init() should call acpihp_register_class() to > initialize the core. > Hi~ True. Thanks for your comments. :) Since I'm new in PCI related area, if you don't mind, would you please give me some more advice about the following problem ? Thanks. :) "modprobe acpihp_drv" command failed, but acpihp_drv was loaded successfully, and always in use. It cannot be removed. Is it a problem ? [root@DP tangchen]# lsmod | grep acpi acpi_cpufreq9542 0 freq_table 5030 2 cpufreq_ondemand,acpi_cpufreq mperf 1391 1 acpi_cpufreq acpi_memhotplug 4414 0 [root@DP tangchen]# modprobe acpihp_drv Killed (NOTE: The NULL pointer problem happened here.) [root@DP tangchen]# echo $? 137 [root@DP tangchen]# lsmod | grep acpi acpihp_drv 24925 1 (NOTE: Here, the module is loaded.) acpi_cpufreq9542 0 freq_table 5030 2 cpufreq_ondemand,acpi_cpufreq mperf 1391 1 acpi_cpufreq acpi_memhotplug 4414 0 [root@DP tangchen]# rmmod acpihp_drv ERROR: Module acpihp_drv is in use The core.c file has been compiled into kernel because of my configuration "CONFIG_ACPI_HOTPLUG=y". As my colleague said, in this case, there is no dependency between acpihp_enum and acpihp_drv. So I think, do we need to compile core.c into acpihp_enum module, or simply check if acpihp_enum has been loaded in acpihp_drv_init() ? I am not sure if it is a good idea to move acpihp_slot_class definition and all related API to acpihp_enum module. Thanks again for your comments and patient. :) -- Best Regards, Tang chen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: gdm72xx: fix reference counting in gdm_wimax_event_init
On Wed, Jul 25, 2012 at 7:23 PM, Ben Chan wrote: > Hi Devendra, > > Thanks for cleaning up the driver. If I understand the code > correctly, the original author wanted to initialize wm_event once and > reuse it for multiple devices, and thus reference counted it with > ref_cnt. > > For instance, each time gdm_usb_probe() is called, it may call > register_wimax_device() / gdm_wimax_event_init(). wm_event is > initialized the first time when wm_event.ref_cnt == 0 (alternatively, > the code could check !wm_event.sock). Subsequent calls to > gdm_wimax_event_init() will simply increase the ref count. Similarly, > gdm_usb_disconnect() calls unregister_wimax_device() / > gdm_wimax_event_exit(), which decreases the ref count and disposes > wm_event when ref_cnt becomes zero. > > The code change in commit 8df858ea76b76dde9a39d4edd9aaded983582cfe > only prevents ref_cnt from increasing beyond one. So the code no > longer work when there are multiple devices (i.e. wm_event could be > disposed even when there is an active device). > > Thanks, > Ben > > Sorry Ben, I didn't saw the mail for a long time, Thanks a lot for the long explanation, i will keep in mind of these problems, and also i think your patch is ok. Thanks, Devendra. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ipv4: tcp: unicast_sock should not land outside of TCP stack
From: Eric Dumazet Date: Fri, 10 Aug 2012 01:56:06 +0200 > From: Eric Dumazet > > commit be9f4a44e7d41cee (ipv4: tcp: remove per net tcp_sock) added a > selinux regression, reported and bisected by John Stultz > > selinux_ip_postroute_compat() expect to find a valid sk->sk_security > pointer, but this field is NULL for unicast_sock > > It turns out that unicast_sock are really temporary stuff to be able > to reuse part of IP stack (ip_append_data()/ip_push_pending_frames()) > > Fact is that frames sent by ip_send_unicast_reply() should be orphaned > to not fool LSM. > > Note IPv6 never had this problem, as tcp_v6_send_response() doesnt use a > fake socket at all. I'll probably implement tcp_v4_send_response() to > remove these unicast_sock in linux-3.7 > > Reported-by: John Stultz > Bisected-by: John Stultz > Signed-off-by: Eric Dumazet Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/fpu] x86, fpu: fix build issues with CONFIG_IA32_EMULATION, CONFIG_X86_X32_ABI
Commit-ID: b2104ba4a037e296901e73a0d396826c13625bb0
Gitweb: http://git.kernel.org/tip/b2104ba4a037e296901e73a0d396826c13625bb0
Author: Suresh Siddha
AuthorDate: Thu, 9 Aug 2012 13:38:56 -0700
Committer: H. Peter Anvin
CommitDate: Thu, 9 Aug 2012 17:13:57 -0700
x86, fpu: fix build issues with CONFIG_IA32_EMULATION, CONFIG_X86_X32_ABI
Fengguang's automated build reported some compilation failures:
> arch/x86/kernel/signal.c: In function 'setup_rt_frame':
> arch/x86/kernel/signal.c:626:4: error: implicit declaration of function
> '__setup_frame'
> ...
Code saving fsave prefix is applicable only for CONFIG_X86_32 or
CONFIG_IA32_EMULATION. Use config_enabled() checks to remove the unnecessary
code compile-time for x86_64 kernels build without CONFIG_IA32_EMULATION.
Peter reported some build failures with CONFIG_X86_X32_ABI:
> arch/x86/kernel/signal.c:792:12: error:
> static declaration of ‘x32_setup_rt_frame’ follows non-static declaration
> ...
Fix it by moving the x32_setup_rt_frame() code around and removing the
non-static declaration.
Also while we are at this, fix a spurious warning:
> arch/x86/kernel/xsave.c:209:15: warning: ignoring return value
> of ‘__clear_user’, declared with attribute warn_unused_result
Signed-off-by: Suresh Siddha
Link:
http://lkml.kernel.org/r/1344544736.8326.17.ca...@sbsiddha-desk.sc.intel.com
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/fpu-internal.h |7 +--
arch/x86/kernel/signal.c| 134 ++-
arch/x86/kernel/xsave.c | 10 ++-
3 files changed, 77 insertions(+), 74 deletions(-)
diff --git a/arch/x86/include/asm/fpu-internal.h
b/arch/x86/include/asm/fpu-internal.h
index 35ad161..ba83a08 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -22,7 +22,7 @@
#include
#include
-#ifdef CONFIG_IA32_EMULATION
+#ifdef CONFIG_X86_64
# include
# include
int ia32_setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
@@ -52,17 +52,12 @@ extern user_regset_get_fn fpregs_get, xfpregs_get,
fpregs_soft_get,
extern user_regset_set_fn fpregs_set, xfpregs_set, fpregs_soft_set,
xstateregs_set;
-
/*
* xstateregs_active == fpregs_active. Please refer to the comment
* at the definition of fpregs_active.
*/
#define xstateregs_active fpregs_active
-int x32_setup_rt_frame(int sig, struct k_sigaction *ka,
- siginfo_t *info, compat_sigset_t *set,
- struct pt_regs *regs);
-
#ifdef CONFIG_MATH_EMULATION
# define HAVE_HWFP (boot_cpu_data.hard_math)
extern void finit_soft_fpu(struct i387_soft_struct *soft);
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 356e442..e10f96a 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -472,6 +472,74 @@ static int __setup_rt_frame(int sig, struct k_sigaction
*ka, siginfo_t *info,
}
#endif /* CONFIG_X86_32 */
+static int x32_setup_rt_frame(int sig, struct k_sigaction *ka,
+ siginfo_t *info, compat_sigset_t *set,
+ struct pt_regs *regs)
+{
+#ifdef CONFIG_X86_X32_ABI
+ struct rt_sigframe_x32 __user *frame;
+ void __user *restorer;
+ int err = 0;
+ void __user *fpstate = NULL;
+
+ frame = get_sigframe(ka, regs, sizeof(*frame), &fpstate);
+
+ if (!access_ok(VERIFY_WRITE, frame, sizeof(*frame)))
+ return -EFAULT;
+
+ if (ka->sa.sa_flags & SA_SIGINFO) {
+ if (copy_siginfo_to_user32(&frame->info, info))
+ return -EFAULT;
+ }
+
+ put_user_try {
+ /* Create the ucontext. */
+ if (cpu_has_xsave)
+ put_user_ex(UC_FP_XSTATE, &frame->uc.uc_flags);
+ else
+ put_user_ex(0, &frame->uc.uc_flags);
+ put_user_ex(0, &frame->uc.uc_link);
+ put_user_ex(current->sas_ss_sp, &frame->uc.uc_stack.ss_sp);
+ put_user_ex(sas_ss_flags(regs->sp),
+ &frame->uc.uc_stack.ss_flags);
+ put_user_ex(current->sas_ss_size, &frame->uc.uc_stack.ss_size);
+ put_user_ex(0, &frame->uc.uc__pad0);
+ err |= setup_sigcontext(&frame->uc.uc_mcontext, fpstate,
+ regs, set->sig[0]);
+ err |= __copy_to_user(&frame->uc.uc_sigmask, set, sizeof(*set));
+
+ if (ka->sa.sa_flags & SA_RESTORER) {
+ restorer = ka->sa.sa_restorer;
+ } else {
+ /* could use a vstub here */
+ restorer = NULL;
+ err |= -EFAULT;
+ }
+ put_user_ex(restorer, &frame->pretcode);
+ } put_user_catch(err);
+
+ if (err)
+ return -EFAULT;
+
+ /* Set up registers for signal handler */
Re: [Regression] "x86-64/efi: Use EFI to deal with platform wall clock" prevents my machine from booting
FYI I tried to contact support, here's their answer: Dear Valued Customer, Thank you for contacting ASUS Customer Service. My name is Carter and it's my pleasure to help you with your problem. I am afraid to say this board doesn't support linux,so we can't asure the compability. It is depengding on the actual situation. If you continue to experience issues in the future, please do not hesitate to contact us. Best Regard Carter -- Original Message -- >From : cj...@zougloub.eu Sent : 2012/8/7 ?? 01:18:04 To : "t...@asus.com.tw" Subject : Motherboard SABERTOOTH 990FX [CASEID=WTM201208072118475482] Apply date : 8/7/2012 1:18:47 PM(UTC Time) [Contact Information] *Name : Jérôme Carretero *Email Address : cj...@zougloub.eu [Product Information] *Product Type : Motherboard *Product Model : SABERTOOTH 990FX *Product S/N : MB-1234567890 [Motherboard Specification] *Motherboard Revision : 1.xx *Motherboard BIOS Revision : 813 *Operating System : Linux [Problem Description] Hi, A proposed patch to Linux uses EFI GetTime service to get the wall clock time. It seems this function does not work properly. See http://www.gossamer-threads.com/lists/linux/kernel/1576468 I know I don't have the latest bios but the change logs don't mention any EFI change, and upgrades make the settings lost, so I didn't try them. Thanks, -- cJ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 4/4] perf/events: Use helper functions in event assignment to shrink macro size
From: Steven Rostedt
The functions that assign the contents for the perf software events are
defined by the TRACE_EVENT() macros. Each event has its own unique
way to assign data to its buffer. When you have over 700 events,
that means there's 700 functions assigning data uniquely for each
event.
By making helper functions in the core kernel to do the work
instead, we can shrink the size of the kernel down a bit.
With a kernel configured with 707 events, the change in size was:
textdata bss dec hex filename
199669372594648 1945600 24507185175f331 vmlinux-before
199247612594584 1945600 244649451754e31 vmlinux-after
That's a total of 42240 bytes, which comes down to 59 bytes per event.
Cc: Peter Zijlstra
Cc: Frederic Weisbecker
Signed-off-by: Steven Rostedt
---
include/linux/ftrace_event.h| 13 +
include/trace/ftrace.h | 31 ---
kernel/trace/trace_event_perf.c | 26 ++
3 files changed, 47 insertions(+), 23 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index b9f39d3..06c6d04 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -313,6 +313,19 @@ struct perf_event;
DECLARE_PER_CPU(struct pt_regs, perf_trace_regs);
+struct perf_trace_event {
+ struct pt_regs regs;
+ u64 addr;
+ u64 count;
+ int entry_size;
+ int rctx;
+};
+
+extern void *perf_trace_event_setup(struct ftrace_event_call *event_call,
+ struct perf_trace_event *pe);
+extern void perf_trace_event_submit(void *raw_data, struct ftrace_event_call
*event_call,
+ struct perf_trace_event *pe);
+
extern int perf_trace_init(struct perf_event *event);
extern void perf_trace_destroy(struct perf_event *event);
extern int perf_trace_add(struct perf_event *event, int flags);
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 8118451..a02d48d 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -677,10 +677,10 @@ __attribute__((section("_ftrace_events")))
*__event_##call = &event_##call
#define __get_str(field) (char *)__get_dynamic_array(field)
#undef __perf_addr
-#define __perf_addr(a) __addr = (a)
+#define __perf_addr(a) __pe.addr = (a)
#undef __perf_count
-#define __perf_count(c) __count = (c)
+#define __perf_count(c) __pe.count = (c)
#undef TP_perf_assign
#define TP_perf_assign(args...) args
@@ -693,36 +693,21 @@ perf_trace_##call(void *__data, proto)
\
struct ftrace_event_call *event_call = __data; \
struct ftrace_data_offsets_##call __maybe_unused __data_offsets;\
struct ftrace_raw_##call *entry;\
- struct pt_regs __regs; \
- u64 __addr = 0, __count = 1;\
- struct hlist_head *head;\
- int __entry_size; \
+ struct perf_trace_event __pe; \
int __data_size;\
- int rctx; \
- \
- perf_fetch_caller_regs(&__regs);\
\
__data_size = ftrace_get_offsets_##call(&__data_offsets, args); \
- __entry_size = ALIGN(__data_size + sizeof(*entry) + sizeof(u32),\
-sizeof(u64)); \
- __entry_size -= sizeof(u32);\
- \
- if (WARN_ONCE(__entry_size > PERF_MAX_TRACE_SIZE, \
- "profile buffer not large enough")) \
- return; \
+ __pe.entry_size = __data_size + sizeof(*entry); \
+ __pe.addr = 0; \
+ __pe.count = 1; \
\
- entry = (struct ftrace_raw_##call *)perf_trace_buf_prepare( \
- __entry_size, event_call->event.type, &__regs, &rctx); \
- if (!entry) \
- return; \
+ entry = perf_trace_event_setup(event_call, &__pe); \
[RFC][PATCH 2/4] tracing: Move event storage for array from macro to standalone function
From: Steven Rostedt
The code that shows array fields for events is defined for all events.
This can add up quite a bit when you have over 700 events.
By making helper functions in the core kernel to do the work
instead, we can shrink the size of the kernel down a little.
With a kernel configured with 707 events, the change in size was:
textdata bss dec hex filename
199947152594648 1945600 245349631765fb3 vmlinux-before
199917052594648 1945600 2453195317653f1 vmlinux-after
That's a total of 3010 bytes, which comes down to 4 bytes per event.
Although it's not much, this code is just called at initialization.
Signed-off-by: Steven Rostedt
---
include/linux/ftrace_event.h |8
include/trace/ftrace.h | 12
kernel/trace/trace_events.c |6 --
kernel/trace/trace_export.c | 12
kernel/trace/trace_output.c | 20
5 files changed, 32 insertions(+), 26 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 56d1e53..22f5fec 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -144,6 +144,10 @@ int ftrace_output_event(struct trace_iterator *iter,
struct ftrace_event_call *e
int ftrace_output_call(struct trace_iterator *iter, char *name, char *fmt,
...);
+int ftrace_event_define_field(struct ftrace_event_call *call,
+ char *type, int len, char *item, int offset,
+ int field_size, int sign, int filter);
+
struct event_filter;
enum trace_reg {
@@ -260,10 +264,6 @@ enum {
FILTER_TRACE_FN,
};
-#define EVENT_STORAGE_SIZE 128
-extern struct mutex event_storage_mutex;
-extern char event_storage[EVENT_STORAGE_SIZE];
-
extern int trace_event_raw_init(struct ftrace_event_call *call);
extern int trace_define_field(struct ftrace_event_call *call, const char *type,
const char *name, int offset, int size,
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index cb85747..95d6704 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -293,15 +293,11 @@ static struct trace_event_functions
ftrace_event_type_funcs_##call = {\
#undef __array
#define __array(type, item, len) \
do {\
- mutex_lock(&event_storage_mutex); \
BUILD_BUG_ON(len > MAX_FILTER_STR_VAL); \
- snprintf(event_storage, sizeof(event_storage), \
-"%s[%d]", #type, len); \
- ret = trace_define_field(event_call, event_storage, #item, \
-offsetof(typeof(field), item), \
-sizeof(field.item),\
-is_signed_type(type), FILTER_OTHER); \
- mutex_unlock(&event_storage_mutex); \
+ ret = ftrace_event_define_field(event_call, #type, len, \
+ #item, offsetof(typeof(field), item), \
+ sizeof(field.item), \
+ is_signed_type(type), FILTER_OTHER); \
if (ret)\
return ret; \
} while (0);
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 6825d83..5c5dc1f 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -27,12 +27,6 @@
DEFINE_MUTEX(event_mutex);
-DEFINE_MUTEX(event_storage_mutex);
-EXPORT_SYMBOL_GPL(event_storage_mutex);
-
-char event_storage[EVENT_STORAGE_SIZE];
-EXPORT_SYMBOL_GPL(event_storage);
-
LIST_HEAD(ftrace_events);
LIST_HEAD(ftrace_common_fields);
diff --git a/kernel/trace/trace_export.c b/kernel/trace/trace_export.c
index e039906..f837e35 100644
--- a/kernel/trace/trace_export.c
+++ b/kernel/trace/trace_export.c
@@ -96,14 +96,10 @@ static void __always_unused ftrace_check_##name(void)
\
#define __array(type, item, len) \
do {\
BUILD_BUG_ON(len > MAX_FILTER_STR_VAL); \
- mutex_lock(&event_storage_mutex); \
- snprintf(event_storage, sizeof(event_storage), \
-"%s[%d]", #type, len); \
- ret = trace_define_field(event_call, event_storage, #item, \
-offsetof(typeof(field), item), \
-sizeof(field.item),\
-is_signed_type(type), filter_ty
[RFC][PATCH 3/4] tracing: Use helper functions in event assignment to shrink macro size
From: Steven Rostedt
The functions that assign the contents for the ftrace events are
defined by the TRACE_EVENT() macros. Each event has its own unique
way to assign data to its buffer. When you have over 700 events,
that means there's 700 functions assigning data uniquely for each
event (not really that many, as DECLARE_EVENT_CLASS() and multiple
DEFINE_EVENT()s will only need a single function).
By making helper functions in the core kernel to do some of the work
instead, we can shrink the size of the kernel down a bit.
With a kernel configured with 707 events, the change in size was:
textdata bss dec hex filename
199917052594648 1945600 2453195317653f1 vmlinux-before
199669372594648 1945600 24507185175f331 vmlinux-after
That's a total of 24768 bytes, which comes down to 35 bytes per event.
Signed-off-by: Steven Rostedt
---
include/linux/ftrace_event.h | 14 ++
include/trace/ftrace.h | 21 ++---
kernel/trace/trace_output.c | 26 ++
3 files changed, 46 insertions(+), 15 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 22f5fec..b9f39d3 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -148,6 +148,20 @@ int ftrace_event_define_field(struct ftrace_event_call
*call,
char *type, int len, char *item, int offset,
int field_size, int sign, int filter);
+struct ftrace_event_buffer {
+ struct ring_buffer *buffer;
+ struct ring_buffer_event*event;
+ unsigned long flags;
+ int pc;
+};
+
+void *ftrace_event_buffer_reserve(struct ftrace_event_buffer *fbuffer,
+ int type, unsigned long len);
+
+void ftrace_event_buffer_commit(struct ftrace_event_buffer *fbuffer,
+ struct ftrace_event_call *event_call,
+ void *entry);
+
struct event_filter;
enum trace_reg {
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 95d6704..8118451 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -499,33 +499,24 @@ ftrace_raw_event_##call(void *__data, proto)
\
{ \
struct ftrace_event_call *event_call = __data; \
struct ftrace_data_offsets_##call __maybe_unused __data_offsets;\
- struct ring_buffer_event *event;\
+ struct ftrace_event_buffer fbuffer; \
struct ftrace_raw_##call *entry;\
- struct ring_buffer *buffer; \
- unsigned long irq_flags;\
int __data_size;\
- int pc; \
- \
- local_save_flags(irq_flags);\
- pc = preempt_count(); \
\
__data_size = ftrace_get_offsets_##call(&__data_offsets, args); \
\
- event = trace_current_buffer_lock_reserve(&buffer, \
+ entry = ftrace_event_buffer_reserve(&fbuffer, \
event_call->event.type,\
-sizeof(*entry) + __data_size, \
-irq_flags, pc);\
- if (!event) \
+sizeof(*entry) + __data_size); \
+ \
+ if (!entry) \
return; \
- entry = ring_buffer_event_data(event);\
\
tstruct \
\
{ assign; } \
\
- if (!filter_current_check_discard(buffer, event_call, entry, event)) \
- trace_nowake_buffer_unlock_commit(buffer, \
- event, irq_flags, pc); \
+ ftrace_event_buffer_commit
[RFC][PATCH 1/4] tracing: Move print code from macro to standalone function
From: Steven Rostedt
The code for trace events to format the raw recorded event data
into human readable format in the 'trace' file is repeated for every
event in the system. When you have over 700 events, this can add up
quite a bit.
By making helper functions in the core kernel to do the work
instead, we can shrink the size of the kernel down a bit.
With a kernel configured with 707 events, the change in size was:
textdata bss dec hex filename
200164712594648 1945600 24556719176b4af vmlinux-before
199947152594648 1945600 245349631765fb3 vmlinux-after
That's a total of 21756 bytes, which comes down to 30 bytes per event.
Signed-off-by: Steven Rostedt
---
include/linux/ftrace_event.h |5 +
include/trace/ftrace.h | 21 ++--
kernel/trace/trace_output.c | 44 ++
3 files changed, 51 insertions(+), 19 deletions(-)
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index af961d6..56d1e53 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -139,6 +139,11 @@ void trace_current_buffer_discard_commit(struct
ring_buffer *buffer,
void tracing_record_cmdline(struct task_struct *tsk);
+int ftrace_output_event(struct trace_iterator *iter, struct ftrace_event_call
*event,
+ char *fmt, ...);
+
+int ftrace_output_call(struct trace_iterator *iter, char *name, char *fmt,
...);
+
struct event_filter;
enum trace_reg {
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index c6bc2fa..cb85747 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -228,11 +228,9 @@ ftrace_raw_output_##call(struct trace_iterator *iter, int
flags, \
struct trace_event *trace_event) \
{ \
struct ftrace_event_call *event;\
- struct trace_seq *s = &iter->seq; \
struct ftrace_raw_##call *field;\
struct trace_entry *entry; \
struct trace_seq *p = &iter->tmp_seq; \
- int ret;\
\
event = container_of(trace_event, struct ftrace_event_call, \
event);\
@@ -245,15 +243,8 @@ ftrace_raw_output_##call(struct trace_iterator *iter, int
flags, \
} \
\
field = (typeof(field))entry; \
- \
trace_seq_init(p); \
- ret = trace_seq_printf(s, "%s: ", event->name); \
- if (ret)\
- ret = trace_seq_printf(s, print); \
- if (!ret) \
- return TRACE_TYPE_PARTIAL_LINE; \
- \
- return TRACE_TYPE_HANDLED; \
+ return ftrace_output_event(iter, event, print); \
} \
static struct trace_event_functions ftrace_event_type_funcs_##call = { \
.trace = ftrace_raw_output_##call, \
@@ -265,11 +256,9 @@ static notrace enum print_line_t
\
ftrace_raw_output_##call(struct trace_iterator *iter, int flags, \
struct trace_event *event) \
{ \
- struct trace_seq *s = &iter->seq; \
struct ftrace_raw_##template *field;\
struct trace_entry *entry; \
struct trace_seq *p = &iter->tmp_seq; \
- int ret;\
\
entry = iter->ent; \
\
@@ -281,13 +270,7 @@ ftrace_raw_output_##call(struct trace_iterator *iter, int
flags, \
field = (typeof(field))entry; \
[RFC][PATCH 0/4] tracing/perf: Use helper functions to help shrink kernel size
This patch set is another effort to bring down the size of trace events. Helper functions are used to remove duplicate code that is created for each event by the TRACE_EVENT() macros. With a config that enables 707 events in the core kernel, the size is brought down 91,774 bytes! Steven Rostedt (4): tracing: Move print code from macro to standalone function tracing: Move event storage for array from macro to standalone function tracing: Use helper functions in event assignment to shrink macro size perf/events: Use helper functions in event assignment to shrink macro size include/linux/ftrace_event.h| 40 +++-- include/trace/ftrace.h | 85 +--- kernel/trace/trace_event_perf.c | 26 +++ kernel/trace/trace_events.c |6 --- kernel/trace/trace_export.c | 12 ++ kernel/trace/trace_output.c | 90 +++ 6 files changed, 176 insertions(+), 83 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: [Fwd: [PATCH] x86/smp: Fix cpuN startup panic]
On 08/09/2012 05:35 PM, Yanmin Zhang wrote: Peter, What's your opinion about the patch? We hit it when enabling Medfield Android mobile. This patch would put AP to a loop. Another method to fix it is just to enlarge the wait time, for example, from 2HZ to 10HZ. Hmm... and I presume running with preemption disabled doesn't work for hotplug (not that this is a hotplug situation)... 2 seconds is a *long* time, but I guess there isn't really nay harm in making it 10 seconds in the sense that the system is basically dead at that point... tglx - you have been looking at the CPU startup lately, any opinions? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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][SCSI] remove the queue unlock in scsi_requset_fn
We don't need to unlock the queue before put_device in scsi_request_fn() If we trigger the ->remove() function, It occur a oops from the caller. So sdev reference count should not be dropped to zero here. Also It was added before scsi_device_dev_release() was moved to user context, so it is outdated. Signed-off-by: Chanho Min Reviewed-by: Bart Van Assche --- drivers/scsi/scsi_lib.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index ffd7773..cb2185a 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1626,11 +1626,7 @@ out_delay: if (sdev->device_busy == 0) blk_delay_queue(q, SCSI_QUEUE_DELAY); out: - /* must be careful here...if we trigger the ->remove() function -* we cannot be holding the q lock */ - spin_unlock_irq(q->queue_lock); put_device(&sdev->sdev_gendev); - spin_lock_irq(q->queue_lock); } u64 scsi_calculate_bounce_limit(struct Scsi_Host *shost) -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 03/12] KVM: introduce gfn_to_pfn_memslot_atomic
On 08/10/2012 02:50 AM, Marcelo Tosatti wrote:
> On Tue, Aug 07, 2012 at 05:49:36PM +0800, Xiao Guangrong wrote:
>> It can instead of hva_to_pfn_atomic
>>
>> Signed-off-by: Xiao Guangrong
>> ---
>> arch/x86/kvm/mmu.c |5 +
>> include/linux/kvm_host.h |3 ++-
>> virt/kvm/kvm_main.c | 14 --
>> 3 files changed, 11 insertions(+), 11 deletions(-)
>
> What if someone needs gfn_to_hva_memslot in the future, which is not
> unlikely?
Marcelo,
We have already had the function gfn_to_hva_memslot in kvm_host.h which
is not directly used on x86. In this patchset, gfn_to_hva_memslot does
not check the slot->flags.
I think we can let it be based on gfn_to_hva_many:
static inline unsigned long gfn_to_hva_memslot(struct kvm_memory_slot *slot,
gfn_t gfn)
{
return gfn_to_hva_many(slot, gfn, true);
}
Then all gfn_to_*() functions are based on gfn_to_hva_many in which we
will check slot->flags properly.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 3/3] KVM: perf kvm events analysis tool
From: Xiao Guangrong
Add 'perf kvm stat' support to analyze kvm vmexit/mmio/ioport smartly.
Usage:
- kvm stat
run a command and gather performance counter statistics, it is the alias of
perf stat
- trace kvm events:
perf kvm stat record, or, if other tracepoints are interesting as well, we
can append the events like this:
perf kvm stat record -e timer:*
If many guests are running, we can track the specified guest by using -p or
--pid
- show the result:
perf kvm stat report
The output example is following:
# pgrep qemu-kvm
27841
27888
27936
total 3 guests are running on the host
Then, track the guest whose pid is 27936:
# ./perf kvm stat record -p 27936
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.177 MB perf.data.guest (~7742 samples) ]
See the vmexit events:
# ./perf kvm stat report --event=vmexit
Analyze events for all VCPUs:
VM-EXITSamples Samples% Time% Avg time
APIC_ACCESS23780.34% 0.01% 20.86us ( +- 8.03% )
HLT 4515.25%99.98% 790874.75us ( +- 16.93% )
EXTERNAL_INTERRUPT 11 3.73% 0.00% 47.70us ( +- 17.45% )
EXCEPTION_NMI 1 0.34% 0.00% 5.11us ( +- -nan% )
CR_ACCESS 1 0.34% 0.00% 6.33us ( +- -nan% )
Total Samples:295, Total events handled time:35594844.34us.
See the mmio events:
# ./perf kvm stat report --event=mmio
Analyze events for all VCPUs:
MMIO AccessSamples Samples% Time% Avg time
0xfee00380:W15182.07%76.19% 7.72us ( +- 11.96% )
0xfee00300:W 11 5.98%18.86% 26.23us ( +- 27.33% )
0xfee00300:R 11 5.98% 2.16% 3.00us ( +- 9.17% )
0xfee00310:W 11 5.98% 2.79% 3.88us ( +- 9.15% )
Total Samples:184, Total events handled time:1529.42us.
See the ioport event:
# ./perf kvm stat report --event=ioport
Analyze events for all VCPUs:
IO Port AccessSamples Samples% Time% Avg time
0x5658:PIN 335755.22%92.13%162.31us ( +- 0.87% )
0xc090:POUT 122120.09% 2.10% 10.18us ( +- 4.97% )
0x60:PIN74812.30% 3.18% 25.17us ( +- 5.01% )
0x64:PIN74812.30% 2.57% 20.35us ( +- 11.81% )
0xc050:POUT 5 0.08% 0.01% 8.79us ( +- 12.88% )
Total Samples:6079, Total events handled time:591405.43us.
And, --vcpu is used to track the specified vcpu and --key is used to sort the
result:
# ./perf kvm stat report --event=ioport --vcpu=0 --key=time
Analyze events for VCPU 0:
IO Port AccessSamples Samples% Time% Avg time
0x5658:PIN14594.77%99.67%133.00us ( +- 2.96% )
0xc090:POUT 8 5.23% 0.33% 7.99us ( +- 16.85% )
Total Samples:153, Total events handled time:19348.87us.
[ Dong Hao :
- rebase it on current tip tree
- fix the compiling-error on i386
]
Signed-off-by: Xiao Guangrong
Signed-off-by: Dong Hao
---
tools/perf/Documentation/perf-kvm.txt | 30 ++-
tools/perf/MANIFEST |3 +
tools/perf/builtin-kvm.c | 858 -
tools/perf/util/header.c | 55 ++-
tools/perf/util/header.h |1 +
tools/perf/util/thread.h |2 +
6 files changed, 943 insertions(+), 6 deletions(-)
diff --git a/tools/perf/Documentation/perf-kvm.txt
b/tools/perf/Documentation/perf-kvm.txt
index dd84cb2..d52feef 100644
--- a/tools/perf/Documentation/perf-kvm.txt
+++ b/tools/perf/Documentation/perf-kvm.txt
@@ -12,7 +12,7 @@ SYNOPSIS
[--guestkallsyms= --guestmodules= | --guestvmlinux=]]
{top|record|report|diff|buildid-list}
'perf kvm' [--host] [--guest] [--guestkallsyms= --guestmodules=
- | --guestvmlinux=] {top|record|report|diff|buildid-list}
+ | --guestvmlinux=] {top|record|report|diff|buildid-list|stat}
DESCRIPTION
---
@@ -38,6 +38,18 @@ There are a couple of variants of perf kvm:
so that other tools can be used to fetch packages with matching symbol tables
for use by perf report.
+ 'perf kvm stat ' to run a command and gather performance counter
+ statistics.
+ Especially, perf 'kvm stat record/report' generates a statistical analysis
+ of KVM events. Currently, vmexit, mmio and ioport events are supported.
+'perf kvm stat record ' records kvm events and the events between
+start and end .
+And this command produces a file which contains tracing results of kvm
+events.
+
+'perf kvm stat report' reports statistical data which includes events
+handled time, samples, and so on.
+
OPTIONS
---
-i::
@@ -68,7 +80,21 @@ OPTIONS
--guestvmlinux=::
Guest os kernel vmlinux.
+STAT REPORT OPTIONS
+-
[PATCH v6 1/3] KVM: x86: export svm/vmx exit code and vector code to userspace
From: Xiao Guangrong
They will be needed by 'perf kvm stat'
[ Dong Hao : rebase it on current kvm/tip tree]
Signed-off-by: Xiao Guangrong
Signed-off-by: Dong Hao
---
arch/x86/include/asm/kvm_host.h | 36 ---
arch/x86/include/asm/svm.h | 205 +--
arch/x86/include/asm/vmx.h | 126
arch/x86/kvm/trace.h| 89 -
4 files changed, 234 insertions(+), 222 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 1309e69..df23d75 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -11,6 +11,24 @@
#ifndef _ASM_X86_KVM_HOST_H
#define _ASM_X86_KVM_HOST_H
+#define DE_VECTOR 0
+#define DB_VECTOR 1
+#define BP_VECTOR 3
+#define OF_VECTOR 4
+#define BR_VECTOR 5
+#define UD_VECTOR 6
+#define NM_VECTOR 7
+#define DF_VECTOR 8
+#define TS_VECTOR 10
+#define NP_VECTOR 11
+#define SS_VECTOR 12
+#define GP_VECTOR 13
+#define PF_VECTOR 14
+#define MF_VECTOR 16
+#define MC_VECTOR 18
+
+#ifdef __KERNEL__
+
#include
#include
#include
@@ -75,22 +93,6 @@
#define KVM_HPAGE_MASK(x) (~(KVM_HPAGE_SIZE(x) - 1))
#define KVM_PAGES_PER_HPAGE(x) (KVM_HPAGE_SIZE(x) / PAGE_SIZE)
-#define DE_VECTOR 0
-#define DB_VECTOR 1
-#define BP_VECTOR 3
-#define OF_VECTOR 4
-#define BR_VECTOR 5
-#define UD_VECTOR 6
-#define NM_VECTOR 7
-#define DF_VECTOR 8
-#define TS_VECTOR 10
-#define NP_VECTOR 11
-#define SS_VECTOR 12
-#define GP_VECTOR 13
-#define PF_VECTOR 14
-#define MF_VECTOR 16
-#define MC_VECTOR 18
-
#define SELECTOR_TI_MASK (1 << 2)
#define SELECTOR_RPL_MASK 0x03
@@ -995,4 +997,6 @@ int kvm_pmu_read_pmc(struct kvm_vcpu *vcpu, unsigned pmc,
u64 *data);
void kvm_handle_pmu_event(struct kvm_vcpu *vcpu);
void kvm_deliver_pmi(struct kvm_vcpu *vcpu);
+#endif
+
#endif /* _ASM_X86_KVM_HOST_H */
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index f2b83bc..cdf5674 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -1,6 +1,135 @@
#ifndef __SVM_H
#define __SVM_H
+#define SVM_EXIT_READ_CR0 0x000
+#define SVM_EXIT_READ_CR3 0x003
+#define SVM_EXIT_READ_CR4 0x004
+#define SVM_EXIT_READ_CR8 0x008
+#define SVM_EXIT_WRITE_CR0 0x010
+#define SVM_EXIT_WRITE_CR3 0x013
+#define SVM_EXIT_WRITE_CR4 0x014
+#define SVM_EXIT_WRITE_CR8 0x018
+#define SVM_EXIT_READ_DR0 0x020
+#define SVM_EXIT_READ_DR1 0x021
+#define SVM_EXIT_READ_DR2 0x022
+#define SVM_EXIT_READ_DR3 0x023
+#define SVM_EXIT_READ_DR4 0x024
+#define SVM_EXIT_READ_DR5 0x025
+#define SVM_EXIT_READ_DR6 0x026
+#define SVM_EXIT_READ_DR7 0x027
+#define SVM_EXIT_WRITE_DR0 0x030
+#define SVM_EXIT_WRITE_DR1 0x031
+#define SVM_EXIT_WRITE_DR2 0x032
+#define SVM_EXIT_WRITE_DR3 0x033
+#define SVM_EXIT_WRITE_DR4 0x034
+#define SVM_EXIT_WRITE_DR5 0x035
+#define SVM_EXIT_WRITE_DR6 0x036
+#define SVM_EXIT_WRITE_DR7 0x037
+#define SVM_EXIT_EXCP_BASE 0x040
+#define SVM_EXIT_INTR 0x060
+#define SVM_EXIT_NMI 0x061
+#define SVM_EXIT_SMI 0x062
+#define SVM_EXIT_INIT 0x063
+#define SVM_EXIT_VINTR 0x064
+#define SVM_EXIT_CR0_SEL_WRITE 0x065
+#define SVM_EXIT_IDTR_READ 0x066
+#define SVM_EXIT_GDTR_READ 0x067
+#define SVM_EXIT_LDTR_READ 0x068
+#define SVM_EXIT_TR_READ 0x069
+#define SVM_EXIT_IDTR_WRITE0x06a
+#define SVM_EXIT_GDTR_WRITE0x06b
+#define SVM_EXIT_LDTR_WRITE0x06c
+#define SVM_EXIT_TR_WRITE 0x06d
+#define SVM_EXIT_RDTSC 0x06e
+#define SVM_EXIT_RDPMC 0x06f
+#define SVM_EXIT_PUSHF 0x070
+#define SVM_EXIT_POPF 0x071
+#define SVM_EXIT_CPUID 0x072
+#define SVM_EXIT_RSM 0x073
+#define SVM_EXIT_IRET 0x074
+#define SVM_EXIT_SWINT 0x075
+#define SVM_EXIT_INVD 0x076
+#define SVM_EXIT_PAUSE 0x077
+#define SVM_EXIT_HLT 0x078
+#define SVM_EXIT_INVLPG0x079
+#define SVM_EXIT_INVLPGA 0x07a
+#define SVM_EXIT_IOIO 0x07b
+#define SVM_EXIT_MSR 0x07c
+#define SVM_EXIT_TASK_SWITCH 0x07d
+#define SVM_EXIT_FERR_FREEZE 0x07e
+#define SVM_EXIT_SHUTDOWN 0x07f
+#define SVM_EXIT_VMRUN 0x080
+#define SVM_EXIT_VMMCALL 0x081
+#define SVM_EXIT_VMLOAD0x082
+#define SVM_EXIT_VMSAVE0x083
+#define SVM_EXIT_STGI 0x084
+#define SVM_EXIT_CLGI 0x085
+#define SVM_EXIT_SKINIT0x086
+#define SVM_EXIT_RDTSCP0x087
+#define SVM_EXIT_ICEBP 0x088
+#define SVM_EXIT_WBINVD0x089
+#define SVM_EXIT_MONITOR 0x08a
+#define SVM_EXIT_MWAIT 0x08b
+#define SVM_EXIT_MWAIT_COND0x08c
+#define SVM_EXIT_XSETBV0x08d
+#define SVM_EXIT_NPF 0x400
+
+#define SVM_EXIT_ERR -1
+
+#define SVM_EXIT_REASONS \
+ { SVM_EXIT_READ_CR0,"read_cr0" }, \
+ { SVM_EXIT_READ_CR3,"read_cr
[PATCH v6 2/3] KVM: x86: tracemmio begin and complete
From: Xiao Guangrong
'perf kvm stat record/report' will use kvm_exit and kvm_mmio(read...) to
calculate mmio read emulated time for the old kernel, in order to trace
mmio read event more exactly, we add kvm_mmio_begin to trace the time when
mmio read begins, also, add kvm_io_done to trace the time when mmio/pio is
completed
[ Dong Hao : rebase it on current kvm tree ]
Signed-off-by: Xiao Guangrong
Signed-off-by: Dong Hao
---
arch/x86/kvm/x86.c | 32
include/trace/events/kvm.h | 37 +
2 files changed, 57 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8ebf65c..164ed9d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3807,9 +3807,12 @@ mmio:
/*
* Is this MMIO handled locally?
*/
+ trace_kvm_mmio_begin(vcpu->vcpu_id, write, gpa);
handled = ops->read_write_mmio(vcpu, gpa, bytes, val);
- if (handled == bytes)
+ if (handled == bytes) {
+ trace_kvm_io_done(vcpu->vcpu_id);
return X86EMUL_CONTINUE;
+ }
gpa += handled;
bytes -= handled;
@@ -4002,6 +4005,7 @@ static int emulator_pio_in_out(struct kvm_vcpu *vcpu, int
size,
vcpu->arch.pio.size = size;
if (!kernel_pio(vcpu, vcpu->arch.pio_data)) {
+ trace_kvm_io_done(vcpu->vcpu_id);
vcpu->arch.pio.count = 0;
return 1;
}
@@ -4602,9 +4606,7 @@ restart:
inject_emulated_exception(vcpu);
r = EMULATE_DONE;
} else if (vcpu->arch.pio.count) {
- if (!vcpu->arch.pio.in)
- vcpu->arch.pio.count = 0;
- else
+ if (vcpu->arch.pio.in)
writeback = false;
r = EMULATE_DO_MMIO;
} else if (vcpu->mmio_needed) {
@@ -4635,8 +4637,6 @@ int kvm_fast_pio_out(struct kvm_vcpu *vcpu, int size,
unsigned short port)
unsigned long val = kvm_register_read(vcpu, VCPU_REGS_RAX);
int ret = emulator_pio_out_emulated(&vcpu->arch.emulate_ctxt,
size, port, &val, 1);
- /* do not return to emulator after return from userspace */
- vcpu->arch.pio.count = 0;
return ret;
}
EXPORT_SYMBOL_GPL(kvm_fast_pio_out);
@@ -5487,11 +5487,16 @@ static int complete_mmio(struct kvm_vcpu *vcpu)
{
struct kvm_run *run = vcpu->run;
struct kvm_mmio_fragment *frag;
- int r;
+ int r = 1;
if (!(vcpu->arch.pio.count || vcpu->mmio_needed))
return 1;
+ if (vcpu->arch.pio.count && !vcpu->arch.pio.in) {
+ vcpu->arch.pio.count = 0;
+ goto exit;
+ }
+
if (vcpu->mmio_needed) {
/* Complete previous fragment */
frag = &vcpu->mmio_fragments[vcpu->mmio_cur_fragment++];
@@ -5499,8 +5504,10 @@ static int complete_mmio(struct kvm_vcpu *vcpu)
memcpy(frag->data, run->mmio.data, frag->len);
if (vcpu->mmio_cur_fragment == vcpu->mmio_nr_fragments) {
vcpu->mmio_needed = 0;
+
if (vcpu->mmio_is_write)
- return 1;
+ goto exit;
+
vcpu->mmio_read_completed = 1;
goto done;
}
@@ -5517,11 +5524,12 @@ static int complete_mmio(struct kvm_vcpu *vcpu)
}
done:
vcpu->srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
- r = emulate_instruction(vcpu, EMULTYPE_NO_DECODE);
+ r = emulate_instruction(vcpu, EMULTYPE_NO_DECODE) == EMULATE_DONE;
srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
- if (r != EMULATE_DONE)
- return 0;
- return 1;
+
+exit:
+ trace_kvm_io_done(vcpu->vcpu_id);
+ return r;
}
int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
index 7ef9e75..5be5ad3 100644
--- a/include/trace/events/kvm.h
+++ b/include/trace/events/kvm.h
@@ -177,6 +177,43 @@ TRACE_EVENT(kvm_mmio,
__entry->len, __entry->gpa, __entry->val)
);
+TRACE_EVENT(kvm_mmio_begin,
+ TP_PROTO(unsigned int vcpu_id, bool rw, u64 gpa),
+ TP_ARGS(vcpu_id, rw, gpa),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, vcpu_id)
+ __field(int, type)
+ __field(u64, gpa)
+ ),
+
+ TP_fast_assign(
+ __entry->vcpu_id = vcpu_id;
+ __entry->type = rw ? KVM_TRACE_MMIO_WRITE :
+ KVM_TRACE_MMIO_READ;
+ __entry->gpa = gpa;
+ ),
+
+ TP_printk("vcpu %u mmio %s gpa 0x%llx", __entry->vcpu_id,
+ __print_symbolic(__entry->type, kvm_trace_symbol_mmio),
+ _
[PATCH v6 0/3] KVM: perf: kvm events analysis tool
From: Xiao Guangrong This patchset introduces a perf-based tool (perf kvm stat record/report) which can analysis kvm events more smartly. This is a presentation on 2012 Japan LinuxCon: http://events.linuxfoundation.org/images/stories/pdf/lcjp2012_guangrong.pdf You can get more detail from it. Any question/comment please feel free let us know. Patch 1 and patch 3 can be applied to either tip tree or kvm tree, but patch 2 can only be applied to kvm tree. Fortunately, patch 2 is just doing the "improvement" work, and it can be picked up independently. Usage: - kvm stat run a command and gather performance counter statistics, it is the alias of perf stat - trace kvm events: perf kvm stat record, or, if other tracepoints are interesting as well, we can append the events like this: perf kvm stat record -e timer:* If many guests are running, we can track the specified guest by using -p or --pid - show the result: perf kvm stat report The output example is following: # pgrep qemu-kvm 27841 27888 27936 total 3 guests are running on the host Then, track the guest whose pid is 27936: # ./perf kvm stat record -p 27936 ^C[ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.177 MB perf.data.guest (~7742 samples) ] See the vmexit events: # ./perf kvm stat report --event=vmexit Analyze events for all VCPUs: VM-EXITSamples Samples% Time% Avg time APIC_ACCESS23780.34% 0.01% 20.86us ( +- 8.03% ) HLT 4515.25%99.98% 790874.75us ( +- 16.93% ) EXTERNAL_INTERRUPT 11 3.73% 0.00% 47.70us ( +- 17.45% ) EXCEPTION_NMI 1 0.34% 0.00% 5.11us ( +- -nan% ) CR_ACCESS 1 0.34% 0.00% 6.33us ( +- -nan% ) Total Samples:295, Total events handled time:35594844.34us. See the mmio events: # ./perf kvm stat report --event=mmio Analyze events for all VCPUs: MMIO AccessSamples Samples% Time% Avg time 0xfee00380:W15182.07%76.19% 7.72us ( +- 11.96% ) 0xfee00300:W 11 5.98%18.86% 26.23us ( +- 27.33% ) 0xfee00300:R 11 5.98% 2.16% 3.00us ( +- 9.17% ) 0xfee00310:W 11 5.98% 2.79% 3.88us ( +- 9.15% ) Total Samples:184, Total events handled time:1529.42us. See the ioport event: # ./perf kvm stat report --event=ioport Analyze events for all VCPUs: IO Port AccessSamples Samples% Time% Avg time 0x5658:PIN 335755.22%92.13%162.31us ( +- 0.87% ) 0xc090:POUT 122120.09% 2.10% 10.18us ( +- 4.97% ) 0x60:PIN74812.30% 3.18% 25.17us ( +- 5.01% ) 0x64:PIN74812.30% 2.57% 20.35us ( +- 11.81% ) 0xc050:POUT 5 0.08% 0.01% 8.79us ( +- 12.88% ) Total Samples:6079, Total events handled time:591405.43us. And, --vcpu is used to track the specified vcpu and --key is used to sort the result: # ./perf kvm stat report --event=ioport --vcpu=0 --key=time Analyze events for VCPU 0: IO Port AccessSamples Samples% Time% Avg time 0x5658:PIN14594.77%99.67%133.00us ( +- 2.96% ) 0xc090:POUT 8 5.23% 0.33% 7.99us ( +- 16.85% ) Total Samples:153, Total events handled time:19348.87us. Changelog: - merge "perf kvm-events" into perf "perf kvm stat" as Ingo's suggestion - track kvm events for the specified guest - rename kvm_mmio_done to kvm_io_done - fix compiling-error on i386 Dong Hao (3): KVM: x86: export svm/vmx exit code and vector code to userspace KVM: x86: tracemmio begin and complete KVM: perf kvm events analysis tool arch/x86/include/asm/kvm_host.h | 36 +- arch/x86/include/asm/svm.h| 205 +--- arch/x86/include/asm/vmx.h| 126 -- arch/x86/kvm/trace.h | 89 arch/x86/kvm/x86.c| 32 +- include/trace/events/kvm.h| 37 ++ tools/perf/Documentation/perf-kvm.txt | 30 ++- tools/perf/MANIFEST |3 + tools/perf/builtin-kvm.c | 858 - tools/perf/util/header.c | 55 ++- tools/perf/util/header.h |1 + tools/perf/util/thread.h |2 + 12 files changed, 1234 insertions(+), 240 deletions(-) -- 1.7.2.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/
3.5.1 ext4_ sleeping while atomic bug.
BUG: sleeping function called from invalid context at
include/linux/buffer_head.h:333
in_atomic(): 1, irqs_disabled(): 0, pid: 9894, name: fstest
3 locks held by fstest/9894:
#0: (&type->i_mutex_dir_key#4/1){+.+.+.}, at: []
kern_path_create+0x7e/0x140
#1: (&ei->i_data_sem){..}, at: []
ext4_map_blocks+0xb6/0x250
#2: (&(&bgl->locks[i].lock)->rlock){+.+...}, at: []
ext4_validate_block_bitmap+0x77/0x230
Pid: 9894, comm: fstest Not tainted 3.5.1-1.fc17.x86_64.debug #1
Call Trace:
[] __might_sleep+0x18a/0x240
[] __sync_dirty_buffer+0x30/0xf0
[] sync_dirty_buffer+0x13/0x20
[] ext4_commit_super+0x1e8/0x260
[] save_error_info+0x23/0x30
[] __ext4_error+0x89/0xa0
[] ? ext4_validate_block_bitmap+0x77/0x230
[] ext4_validate_block_bitmap+0x1bb/0x230
[] ext4_read_block_bitmap_nowait+0x8e/0x3b0
[] ext4_mb_init_cache+0x160/0x990
[] ? trace_hardirqs_on_caller+0x10d/0x1a0
[] ext4_mb_init_group+0x126/0x250
[] ext4_mb_good_group+0x116/0x130
[] ext4_mb_regular_allocator+0x1a3/0x420
[] ? kmem_cache_alloc+0xe0/0x290
[] ext4_mb_new_blocks+0x4f1/0xb90
[] ? __find_get_block+0xaf/0x220
[] ext4_alloc_branch+0x42e/0x690
[] ? _raw_spin_unlock_irq+0x30/0x50
[] ext4_ind_map_blocks+0x1e7/0x990
[] ? down_write+0x9a/0xb0
[] ? ext4_map_blocks+0xb6/0x250
[] ext4_map_blocks+0xe5/0x250
[] ext4_getblk+0x5b/0x1f0
[] ext4_bread+0x18/0xa0
[] ext4_mkdir+0x147/0x3d0
[] vfs_mkdir+0xa6/0x130
[] sys_mkdirat+0xbe/0xd0
[] sys_mkdir+0x19/0x20
[] system_call_fastpath+0x16/0x1b
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] perf hists: Separate out hist print functions
Hi, Arnaldo On Thu, 9 Aug 2012 16:18:27 -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Aug 06, 2012 at 05:57:36PM +0900, Namhyung Kim escreveu: >> From: Namhyung Kim >> >> Separate out those functions into ui/hist.c. This is required for >> upcoming changes. > > Isn't it better to further separate it by introducing the ui/stdio/ > directory since these functions use fprintf? > Maybe. I agree that general ui code reside on ui/ and front-end specifics should go to their subdirectories. But not sure for the stdio case since they'll have very simple code only. For this case, most of functions would be converted to manipulate a string buffer like scnprintf and shared by all front-end's as long as possible - callchain print code needs some more working. But if you want, I'll separate out actual fprintf's to ui/stdio/. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sched: remove useless code in yield_to
On 08/10/2012 11:05 AM, Michael Wang wrote:
> On 07/03/2012 02:34 PM, Michael Wang wrote:
>> From: Michael Wang
>>
>> it's impossible to enter else branch if we have set skip_clock_update
>> in task_yield_fair(), as yield_to_task_fair() will directly return
>> true after invoke task_yield_fair().
>
> Could I get some conclusion on this patch? Should we clean up that peace
> of code or leave it there?
s /peace/piece and cc mike...
>
> Regards,
> Michael Wang
>
>>
>> Signed-off-by: Michael Wang
>> ---
>> kernel/sched/core.c |7 ---
>> 1 files changed, 0 insertions(+), 7 deletions(-)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 9bb7d28..77c14aa 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -4737,13 +4737,6 @@ again:
>> */
>> if (preempt && rq != p_rq)
>> resched_task(p_rq->curr);
>> -} else {
>> -/*
>> - * We might have set it in task_yield_fair(), but are
>> - * not going to schedule(), so don't want to skip
>> - * the next update.
>> - */
>> -rq->skip_clock_update = 0;
>> }
>>
>> out:
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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: [RFC][PATCH] tracepoints: Move the work out of line from hotpath sections
On Thu, 2012-08-09 at 22:05 -0400, Mathieu Desnoyers wrote:
> In your example, is the attribute attached to the if() or the following
> basic block ? Attaching it to the basic block allows a nice level of
> genericity:
Yes, I meant the block, not the if().
Heck, any block could be done this way, even just a block insertion...
void foo(int bar) {
[...]
__attribute__((section("mysection")) {
/* code here is in 'mysection' */
}
[...]
}
All gcc would have to do is place a hard jump to the code in the
section, and have the section jump back.
-- 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] sched: remove useless code in yield_to
On 07/03/2012 02:34 PM, Michael Wang wrote:
> From: Michael Wang
>
> it's impossible to enter else branch if we have set skip_clock_update
> in task_yield_fair(), as yield_to_task_fair() will directly return
> true after invoke task_yield_fair().
Could I get some conclusion on this patch? Should we clean up that peace
of code or leave it there?
Regards,
Michael Wang
>
> Signed-off-by: Michael Wang
> ---
> kernel/sched/core.c |7 ---
> 1 files changed, 0 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 9bb7d28..77c14aa 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4737,13 +4737,6 @@ again:
>*/
> if (preempt && rq != p_rq)
> resched_task(p_rq->curr);
> - } else {
> - /*
> - * We might have set it in task_yield_fair(), but are
> - * not going to schedule(), so don't want to skip
> - * the next update.
> - */
> - rq->skip_clock_update = 0;
> }
>
> out:
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] cpupower tools: Fix warning and a bug with the cpu package count
On Thu, Aug 09, 2012 at 12:07:36PM +0200, Thomas Renninger wrote:
> On Tuesday 07 August 2012 04:24:48 Palmer Cox wrote:
> > The pkgs member of cpupower_topology is being used as the number of
> > cpu packages. As the comment in get_cpu_topology notes, the package ids
> > are not guaranteed to be contiguous. So, simply setting pkgs to the value
> > of the highest physical_package_id doesn't actually provide a count of
> > the number of cpu packages. Instead, calculate pkgs by setting it to
> > the number of distinct physical_packge_id values which is pretty easy
> > to do after the core_info structs are sorted. Calculating pkgs this
> > way also has the nice benefit of getting rid of a sign comparison warning
> > that GCC 4.6 was reporting.
> > ---
> > tools/power/cpupower/utils/helpers/topology.c | 18 +-
> > 1 file changed, 13 insertions(+), 5 deletions(-)
> >
> > diff --git a/tools/power/cpupower/utils/helpers/topology.c
> > b/tools/power/cpupower/utils/helpers/topology.c
> > index 4e2b583..fd3cc4d 100644
> > --- a/tools/power/cpupower/utils/helpers/topology.c
> > +++ b/tools/power/cpupower/utils/helpers/topology.c
> > @@ -64,7 +64,7 @@ static int __compare(const void *t1, const void *t2)
> > */
> > int get_cpu_topology(struct cpupower_topology *cpu_top)
> > {
> > - int cpu, cpus = sysconf(_SC_NPROCESSORS_CONF);
> > + int cpu, last_pkg, cpus = sysconf(_SC_NPROCESSORS_CONF);
> >
> > cpu_top->core_info = malloc(sizeof(struct cpuid_core_info) * cpus);
> > if (cpu_top->core_info == NULL)
> > @@ -78,20 +78,28 @@ int get_cpu_topology(struct cpupower_topology *cpu_top)
> > "physical_package_id",
> > &(cpu_top->core_info[cpu].pkg)) < 0)
> > return -1;
> > - if ((int)cpu_top->core_info[cpu].pkg != -1 &&
> > - cpu_top->core_info[cpu].pkg > cpu_top->pkgs)
> > - cpu_top->pkgs = cpu_top->core_info[cpu].pkg;
> > if(sysfs_topology_read_file(
> > cpu,
> > "core_id",
> > &(cpu_top->core_info[cpu].core)) < 0)
> > return -1;
> > }
> > - cpu_top->pkgs++;
> >
> > qsort(cpu_top->core_info, cpus, sizeof(struct cpuid_core_info),
> > __compare);
> >
> > + /* Count the number of distinct pkgs values. This works
> > + becuase the primary sort of of the core_info structs was just
> becuase ... of of ... struct instead of structs
Oof. I'm not winning any grammar medals for this. Thanks for
noticing.
>
> Otherwise the first 4 patches look like rather nice and straight forward
> cleanups/fixes.
> Feel free to add a Reviewed-by: Thomas Renninger
Will do. Thanks!
>
> Let me have a closer look at patch 5 and 6. I had problems getting rid of
> the compiler warning, looks like you found an easy way to clean this up.
> I will be back and have time for this in the beginning of next week.
Thanks for the review! Let me know if there is anything in patches 5
and 6 that needs cleaning up and I'll be happy to do it. I only have
access to a laptop with a single package 2 core Centrino2 processor.
I tested each patch in the series on my laptop running a 64-bit 3.5
kernel to make sure that everything functioned. I'm no expert in the
exact expected output of the tool, but the only impact that I
believe these patches should have is the output of the number of cpu
packages. I tested this on my system which resulted in reporting
just a single cpu package as I expected, but I don't have access to
a system with multiple cpu packages to test on.
>
> On which platforms (topology) did you test this?
>
>Thomas
-Palmer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
compile a kernel for kgdb with less "optimized out"
I think those who use kgdb must hate this sentence "optimized out". I have tried many times to build a kernel with less optimization but failed. today,I found a trick method ,just get rid of the -O2 and -Os on the top level of the kernel source and add -O2 for the arch/x86 directory,it works !.I saw much "optimized out" now. I build the kernel of centos6, with kernel 2.6.32. I don't know whether it works with kernel of other versions ,but it worth a try. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] SubmittingPatches: clarify SOB tag usage when evolving submissions
On 10/08/12 06:51, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Initial large code submissions typically are not accepted > on their first patch submission. The developers are > typically given feedback and at times some developers may > even submit changes to the original authors for integration > into their second submission attempt. > > Developers wishing to contribute changes to the evolution > of a second patch submission must supply their own Siged-off-by > tag to the original authors and must submit their changes > on a public mailing list or ensure that these submission > are recorded somewhere publicly. > > To date a few of these type of contributors have expressed > different preferences for whether or not their own SOB tag > should be used for a second code submission. Lets keep things > simple and only require the contributor's SOB tag if so desired > explicitly. It is not technically required if there already > is a public record of their contribution somewhere. > > Document this on Documentation/SubmittingPatches > > Signed-off-by: Luis R. Rodriguez > --- > Documentation/SubmittingPatches | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches > index c379a2a..e018043 100644 > --- a/Documentation/SubmittingPatches > +++ b/Documentation/SubmittingPatches > @@ -366,6 +366,21 @@ and protect the submitter from complaints. Note that > under no circumstances > can you change the author's identity (the From header), as it is the one > which appears in the changelog. > > +If you are submitting a large change (for example a new driver) at times > +you may be asked to make quite a lot of modifications prior to getting > +your change accepted. This applies to any patch, not just large ones and/or drivers. > At times you may even receive patches from developers > +who not only wish to tell you what you should change to get your changes > +upstream but actually send you patches. This sentence is long and confusing. Perhaps something like: "Other developers may send patches to show what changes should be made, rather than just making comments". > If those patches were made publicly > +and they do contain a Singed-off-by tag you are not expected to provide > +their own Singed-off-by tag on the second iteration of the patch so long > +as there is a public record somewhere that can be used to show the > +contributor had sent their changes with their own Singed-off-by tag. If another developer sends a patch with a Signed-off-by, regardless of whether it is a patch against mainline, or a patch on top of a patch, why would you not be required to keep the Signed-off-by tag? Does this mean that I can review somebodies else's patch, send them a patch on top of it with my Signed-off-by, and they can simply drop it and take my work uncredited? If a developer wants to provided patches on top of someone else's work, but does not want to be credited with a Signed-off-by, then surely they should just not sign-off their patch? You also misspelled "Signed-of-by" several times. > + > +If you receive patches privately during development you may want to > +ask for these patches to be re-posted publicly or you can also decide > +to merge the patches as part of a separate historical git tree that > +will remain online for historical archiving. I don't think this necessarily needs to be stated. Lots of patches, especially drivers, have probably had several authors, but only require the sign-off of the person doing the actual submission. So the rules should be (IMHO): 1) The person submitting the code must sign the patch off. 2) If another person contributes to the code, whether during development, or as part of a review, then they should have a Signed-off-by tag applied only if they provide one. 3) Signed-off-by tags (all tags really) should never be added without the express permission of the person themselves. If additional credit needs to be given, but the creditor doesn't want to provide a Signed-off-by then one of the other tags could be used (such as Reviewed-by), or the person could be mentioned in the changelog perhaps? e.g: "Parts of the foo function provided by Joe Bloggs " ~Ryan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dlm: remove redundant variable assignments
From: Xue Ying
Once the tcp_create_listen_sock() is returned successfully, we
will invoke add_sock() immediately. In add_sock(), the 'con'
variable is assigned to 'sk_user_data', meanwhile, the 'sock' is
also set to 'con->sock'. So it's unnecessary to do the same thing
in tcp_create_listen_sock().
Signed-off-by: Xue Ying
---
fs/dlm/lowcomms.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 5c1b0e3..e7b0ac0 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -1044,10 +1044,8 @@ static struct socket *tcp_create_listen_sock(struct
connection *con,
if (result < 0) {
log_print("Failed to set SO_REUSEADDR on socket: %d", result);
}
- sock->sk->sk_user_data = con;
con->rx_action = tcp_accept_from_sock;
con->connect_action = tcp_connect_to_sock;
- con->sock = sock;
/* Bind to our port */
make_sockaddr(saddr, dlm_config.ci_tcp_port, &addr_len);
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/16] perf symbol: remove unused 'end' arg in kallsyms parse cb
Hi, Cody
On Thu, 9 Aug 2012 15:18:27 -0700, Cody P. Schafer wrote:
> kallsyms__parse() takes a callback that is called on every discovered
> symbol. As /proc/kallsyms does not supply symbol sizes, the callback was
> simply called with end=start, faking the symbol size to 1.
>
> All of the callbacks (there are 2) used in calls to kallsyms__parse()
> are _only_ used as callbacks for kallsyms__parse().
>
> Given that kallsyms__parse() lacks real information about what
> end/length should be, don't make up a length in kallsyms__parse().
> Instead have the callbacks handle guessing the length.
>
> Also relocate a comment regarding symbol creation to the callback which
> does symbol creation (kallsyms__parse() is not in general used to create
> symbols).
>
> Signed-off-by: Cody P Schafer
> ---
> tools/perf/util/event.c | 2 +-
> tools/perf/util/symbol.c | 21 ++---
> tools/perf/util/symbol.h | 2 +-
> 3 files changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
> index 2a6f33c..3a0f1a5 100644
> --- a/tools/perf/util/event.c
> +++ b/tools/perf/util/event.c
> @@ -412,7 +412,7 @@ struct process_symbol_args {
> };
>
> static int find_symbol_cb(void *arg, const char *name, char type,
> - u64 start, u64 end __used)
> + u64 start)
> {
> struct process_symbol_args *args = arg;
>
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index df4736d..b2f7597 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -574,7 +574,7 @@ size_t dso__fprintf(struct dso *dso, enum map_type type,
> FILE *fp)
>
> int kallsyms__parse(const char *filename, void *arg,
> int (*process_symbol)(void *arg, const char *name,
> - char type, u64 start, u64 end))
> + char type, u64 start))
> {
> char *line = NULL;
> size_t n;
> @@ -614,13 +614,8 @@ int kallsyms__parse(const char *filename, void *arg,
> break;
> }
>
> - /*
> - * module symbols are not sorted so we add all
> - * symbols, setting length to 1, and rely on
> - * symbols__fixup_end() to fix it up.
> - */
> err = process_symbol(arg, symbol_name,
> - symbol_type, start, start);
> + symbol_type, start);
> if (err)
> break;
> }
> @@ -647,7 +642,7 @@ static u8 kallsyms2elf_type(char type)
> }
>
> static int map__process_kallsym_symbol(void *arg, const char *name,
> -char type, u64 start, u64 end)
> +char type, u64 start)
> {
> struct symbol *sym;
> struct process_kallsyms_args *a = arg;
> @@ -656,8 +651,12 @@ static int map__process_kallsym_symbol(void *arg, const
> char *name,
> if (!symbol_type__is_a(type, a->map->type))
> return 0;
>
> - sym = symbol__new(start, end - start + 1,
> - kallsyms2elf_type(type), name);
> + /*
> + * module symbols are not sorted so we add all
> + * symbols, setting length to 1, and rely on
> + * symbols__fixup_end() to fix it up.
> + */
> + sym = symbol__new(start, 1, kallsyms2elf_type(type), name);
I guess that length of 1 effectively same as zero length in this case
since we end up calling symbols__fixup_end. The 'end - start + 1' part
looks like a leftover from previous change and not needed anymore -
KSYM_NAME_LEN check too, IMHO - so I suggest using 0 length to make it
clear.
And it seems you need to rebase the series onto Arnaldo's current
perf/core branch which separates out ELF bits to symbol-elf.c.
Thanks,
Namhyung
> if (sym == NULL)
> return -ENOMEM;
> /*
> @@ -2528,7 +2527,7 @@ struct process_args {
> };
>
> static int symbol__in_kernel(void *arg, const char *name,
> - char type __used, u64 start, u64 end __used)
> + char type __used, u64 start)
> {
> struct process_args *args = arg;
>
> diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
> index 1fe733a..c8ec1d7 100644
> --- a/tools/perf/util/symbol.h
> +++ b/tools/perf/util/symbol.h
> @@ -297,7 +297,7 @@ bool __dsos__read_build_ids(struct list_head *head, bool
> with_hits);
> int build_id__sprintf(const u8 *build_id, int len, char *bf);
> int kallsyms__parse(const char *filename, void *arg,
> int (*process_symbol)(void *arg, const char *name,
> - char type, u64 start, u64 end));
> + char type, u64 start));
>
> void machine__destroy_kernel_maps(struct machine *machine);
> int __machine__create_kernel_maps(struct machine *machine, st
Re: thermal patches in linux-next
On 五, 2012-08-10 at 12:23 +1000, Stephen Rothwell wrote: > Hi Rui, > > On Fri, 10 Aug 2012 09:41:06 +0800 Zhang Rui wrote: > > > > > > And could you please drop these commits > > > > ef25a0fe0087963c1611c1c8903886fbea053f76 > > > > 09ec52fca274ba88d68df3198de92abdaaff417b > > > > ab6d2f029358c917508bf88bbd6a9193a8e39fc8 > > > > 66447fa993cbce56b4076f169a56f62350f6c7b8 > > > > ec62abb8b46021ca9ee6b8692b26974ace9007f0 > > > > 5ecbaf57d7885eedd924e391d91847d3df9fe0f8 > > > > 851414b2249afd8c128d29912dfd7060eaea8932 > > > > and pull my next branch instead? > > > > > > That is not how linux-next normally works. Those commits are in Adnrew's > > > quilt series, so you need to ask him to drop them. However, because of > > > the way the akpm tree works, any duplicate patches will disappear from my > > > copy of Andrew's series. > > > > could you please drop these patches? > > these commits either will be or has been re-based on top of my tree. > > You should always quote the summary line of commits. Andrew is using > quilt to manage his patches and so those commit ids mean nothing to him > (and they have changed in today's linux-next anyway). > got it. Andrew, could you please drop these patches from Amit for now? ARM: exynos: add thermal sensor driver platform data support thermal: exynos: register the tmu sensor with the kernel thermal layer thermal: exynos5: add exynos5 thermal sensor driver support hwmon: exynos4: move thermal sensor driver to driver/thermal directory thermal: add generic cpufreq cooling implementation these patches can not build because of the recent thermal changes, and Amit agreed with me to re-base them on top of my tree. thanks, rui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [BUGFIX -v3 3/4] PCI/PM: Fix config reg access for D3cold and bridge suspending
On Wed, 2012-08-08 at 09:07 +0800, Huang Ying wrote:
> This patch fixes the following bug:
>
> http://marc.info/?l=linux-pci&m=134338059022620&w=2
>
> Where lspci does not work properly if a device and the corresponding
> parent bridge (such as PCIe port) is suspended. This is because the
> device configuration space registers will be not accessible if the
> corresponding parent bridge is suspended or the device is put into
> D3cold state.
>
> To solve the issue, the bridge/PCIe port connected to the device is
> put into active state before read/write configuration space registers.
> If the device is in D3cold state, it will be put into active state
> too.
>
> To avoid resume/suspend PCIe port for each configuration register
> read/write, a small delay is added before the PCIe port to go
> suspended.
>
> Reported-by: Bjorn Mork
> Signed-off-by: Huang Ying
> ---
> drivers/pci/pci-sysfs.c| 43
> +
> drivers/pci/pcie/portdrv_pci.c |9
> 2 files changed, 52 insertions(+)
>
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -458,6 +458,41 @@ boot_vga_show(struct device *dev, struct
> }
> struct device_attribute vga_attr = __ATTR_RO(boot_vga);
>
> +static void
> +pci_config_pm_runtime_get(struct pci_dev *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device *parent = dev->parent;
> +
> + if (parent)
> + pm_runtime_get_sync(parent);
> + pm_runtime_get_noresume(dev);
> + /*
> + * pdev->current_state is set to PCI_D3cold during suspending,
> + * so wait until suspending completes
> + */
> + pm_runtime_barrier(dev);
> + if (pdev->current_state == PCI_D3cold) {
> + /*
> + * Already called pm_runtime_get_noresume above, so
> + * just calling pm_runtime_resume is sufficient, need
> + * not to call pm_runtime_get_sync.
> + */
> + pm_runtime_resume(dev);
Hi, Rafael,
Do you OK with this new version and the comments added above?
Best Regards,
Huang Ying
> + }
> +}
> +
> +static void
> +pci_config_pm_runtime_put(struct pci_dev *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device *parent = dev->parent;
> +
> + pm_runtime_put(dev);
> + if (parent)
> + pm_runtime_put_sync(parent);
> +}
> +
> static ssize_t
> pci_read_config(struct file *filp, struct kobject *kobj,
> struct bin_attribute *bin_attr,
> @@ -484,6 +519,8 @@ pci_read_config(struct file *filp, struc
> size = count;
> }
>
> + pci_config_pm_runtime_get(dev);
> +
> if ((off & 1) && size) {
> u8 val;
> pci_user_read_config_byte(dev, off, &val);
> @@ -529,6 +566,8 @@ pci_read_config(struct file *filp, struc
> --size;
> }
>
> + pci_config_pm_runtime_put(dev);
> +
> return count;
> }
>
> @@ -549,6 +588,8 @@ pci_write_config(struct file* filp, stru
> count = size;
> }
>
> + pci_config_pm_runtime_get(dev);
> +
> if ((off & 1) && size) {
> pci_user_write_config_byte(dev, off, data[off - init_off]);
> off++;
> @@ -587,6 +628,8 @@ pci_write_config(struct file* filp, stru
> --size;
> }
>
> + pci_config_pm_runtime_put(dev);
> +
> return count;
> }
>
> --- a/drivers/pci/pcie/portdrv_pci.c
> +++ b/drivers/pci/pcie/portdrv_pci.c
> @@ -140,9 +140,17 @@ static int pcie_port_runtime_resume(stru
> {
> return 0;
> }
> +
> +static int pcie_port_runtime_idle(struct device *dev)
> +{
> + /* Delay for a short while to prevent too frequent suspend/resume */
> + pm_schedule_suspend(dev, 10);
> + return -EBUSY;
> +}
> #else
> #define pcie_port_runtime_suspendNULL
> #define pcie_port_runtime_resume NULL
> +#define pcie_port_runtime_idle NULL
> #endif
>
> static const struct dev_pm_ops pcie_portdrv_pm_ops = {
> @@ -155,6 +163,7 @@ static const struct dev_pm_ops pcie_port
> .resume_noirq = pcie_port_resume_noirq,
> .runtime_suspend = pcie_port_runtime_suspend,
> .runtime_resume = pcie_port_runtime_resume,
> + .runtime_idle = pcie_port_runtime_idle,
> };
>
> #define PCIE_PORTDRV_PM_OPS (&pcie_portdrv_pm_ops)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH resend] Extcon: renamed files to comply with the standard naming.
Replaced '_' with '-' in the extcon file names, which has been bogging
since new drivers have been using the standard naming.
Signed-off-by: MyungJoo Ham
---
drivers/extcon/Makefile |4 ++--
drivers/extcon/{extcon_class.c => extcon-class.c} |0
drivers/extcon/{extcon_gpio.c => extcon-gpio.c} |0
3 files changed, 2 insertions(+), 2 deletions(-)
rename drivers/extcon/{extcon_class.c => extcon-class.c} (100%)
rename drivers/extcon/{extcon_gpio.c => extcon-gpio.c} (100%)
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index bc7111e..68d6944 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,8 +2,8 @@
# Makefile for external connector class (extcon) devices
#
-obj-$(CONFIG_EXTCON) += extcon_class.o
-obj-$(CONFIG_EXTCON_GPIO) += extcon_gpio.o
+obj-$(CONFIG_EXTCON) += extcon-class.o
+obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
diff --git a/drivers/extcon/extcon_class.c b/drivers/extcon/extcon-class.c
similarity index 100%
rename from drivers/extcon/extcon_class.c
rename to drivers/extcon/extcon-class.c
diff --git a/drivers/extcon/extcon_gpio.c b/drivers/extcon/extcon-gpio.c
similarity index 100%
rename from drivers/extcon/extcon_gpio.c
rename to drivers/extcon/extcon-gpio.c
--
1.7.4.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: [dm-devel] [PATCH v5 12/12] block: Only clone bio vecs that are in use
Tejun,
On Thu, Aug 9, 2012 at 12:01 AM, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 08, 2012 at 04:47:46PM -0700, Muthu Kumar wrote:
>> You are changing the meaning of __bio_clone() here. In old code, the
>> number of io_vecs, bi_idx, bi_vcnt are preserved. But in this modified
>> code, you are mapping bio_src's bi_iovec[bi_idx] to bio_dests
>> bi_iovec[0] and also restricting the number of allocated io_vecs of
>> the clone. It may be useful for cases were we would like a identical
>> copy of the original bio (may not be in current code base, but this
>> implementation is definitely not what one would expect from the name
>> "clone").
>
> Implementation details changed somewhat but the high-level semantics
> didn't change at all. Any driver not messing with bio internals - and
> they shouldn't - shouldn't notice the change.
The reason for doing this change is because the code in question is
messing with bio internals.
No in-kernel drivers
> seem to be broken by the change. If you ask me, this looks more like
> a bug fix to me where the bug is a silly behavior restricting
> usefulness of the interface.
>
>> May be, call this new implementation some thing else (and use it for bcache)?
>
> This doesn't only change __bio_clone() but all clone interface stacked
> on top of it, so, no way.
>This ain't windows.
ah... when you put it this way, it gets a different perspective :)
Anyway, my point is, we shouldn't make it non-obvious ("clone" should
be just "clone"). But, we can always add more comments i guess.
Regards,
Muthu
>
> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: thermal patches in linux-next
Hi Rui, On Fri, 10 Aug 2012 09:41:06 +0800 Zhang Rui wrote: > > > > And could you please drop these commits > > > ef25a0fe0087963c1611c1c8903886fbea053f76 > > > 09ec52fca274ba88d68df3198de92abdaaff417b > > > ab6d2f029358c917508bf88bbd6a9193a8e39fc8 > > > 66447fa993cbce56b4076f169a56f62350f6c7b8 > > > ec62abb8b46021ca9ee6b8692b26974ace9007f0 > > > 5ecbaf57d7885eedd924e391d91847d3df9fe0f8 > > > 851414b2249afd8c128d29912dfd7060eaea8932 > > > and pull my next branch instead? > > > > That is not how linux-next normally works. Those commits are in Adnrew's > > quilt series, so you need to ask him to drop them. However, because of > > the way the akpm tree works, any duplicate patches will disappear from my > > copy of Andrew's series. > > could you please drop these patches? > these commits either will be or has been re-based on top of my tree. You should always quote the summary line of commits. Andrew is using quilt to manage his patches and so those commit ids mean nothing to him (and they have changed in today's linux-next anyway). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpWCvlQDUs70.pgp Description: PGP signature
Re: [ 055/109] tg3: Fix Read DMA workaround for 5719 A0.
On Tue, 2012-08-07 at 15:35 -0700, Greg Kroah-Hartman wrote: > From: Greg KH > > 3.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Michael Chan > > commit 10ce95d6ef36c65df7dcd3b8fcf86913f8b298bd upstream. > > The workaround was mis-applied to all 5719 and 5720 chips. [...] Isn't this needed for 3.0.y and 3.2.y as well? Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Re: [PATCH] leds: wm8350: Convert to devm_regulator_get()
Thanks, it's a good change. I've applied it to my for-next branch.
-Bryan
On Fri, Aug 10, 2012 at 10:08 AM, Axel Lin wrote:
> Signed-off-by: Axel Lin
> ---
> drivers/leds/leds-wm8350.c | 29 +++--
> 1 file changed, 7 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/leds/leds-wm8350.c b/drivers/leds/leds-wm8350.c
> index 918d4ba..f5d9ac3 100644
> --- a/drivers/leds/leds-wm8350.c
> +++ b/drivers/leds/leds-wm8350.c
> @@ -201,7 +201,7 @@ static int wm8350_led_probe(struct platform_device *pdev)
> struct regulator *isink, *dcdc;
> struct wm8350_led *led;
> struct wm8350_led_platform_data *pdata = pdev->dev.platform_data;
> - int ret, i;
> + int i;
>
> if (pdata == NULL) {
> dev_err(&pdev->dev, "no platform data\n");
> @@ -214,24 +214,21 @@ static int wm8350_led_probe(struct platform_device
> *pdev)
> return -EINVAL;
> }
>
> - isink = regulator_get(&pdev->dev, "led_isink");
> + isink = devm_regulator_get(&pdev->dev, "led_isink");
> if (IS_ERR(isink)) {
> printk(KERN_ERR "%s: can't get ISINK\n", __func__);
> return PTR_ERR(isink);
> }
>
> - dcdc = regulator_get(&pdev->dev, "led_vcc");
> + dcdc = devm_regulator_get(&pdev->dev, "led_vcc");
> if (IS_ERR(dcdc)) {
> printk(KERN_ERR "%s: can't get DCDC\n", __func__);
> - ret = PTR_ERR(dcdc);
> - goto err_isink;
> + return PTR_ERR(dcdc);
> }
>
> led = devm_kzalloc(&pdev->dev, sizeof(*led), GFP_KERNEL);
> - if (led == NULL) {
> - ret = -ENOMEM;
> - goto err_dcdc;
> - }
> + if (led == NULL)
> + return -ENOMEM;
>
> led->cdev.brightness_set = wm8350_led_set;
> led->cdev.default_trigger = pdata->default_trigger;
> @@ -257,17 +254,7 @@ static int wm8350_led_probe(struct platform_device *pdev)
> led->value = LED_OFF;
> platform_set_drvdata(pdev, led);
>
> - ret = led_classdev_register(&pdev->dev, &led->cdev);
> - if (ret < 0)
> - goto err_dcdc;
> -
> - return 0;
> -
> - err_dcdc:
> - regulator_put(dcdc);
> - err_isink:
> - regulator_put(isink);
> - return ret;
> + return led_classdev_register(&pdev->dev, &led->cdev);
> }
>
> static int wm8350_led_remove(struct platform_device *pdev)
> @@ -277,8 +264,6 @@ static int wm8350_led_remove(struct platform_device *pdev)
> led_classdev_unregister(&led->cdev);
> flush_work_sync(&led->work);
> wm8350_led_disable(led);
> - regulator_put(led->dcdc);
> - regulator_put(led->isink);
> return 0;
> }
>
> --
> 1.7.9.5
>
>
>
--
Bryan Wu
Kernel Developer+86.186-168-78255 Mobile
Canonical Ltd. www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 02/12] KVM: hide KVM_MEMSLOT_INVALID from userspace
On 08/10/2012 02:48 AM, Marcelo Tosatti wrote:
>> +#define KVM_MEMSLOT_INVALID (1UL << 31)
>> +
>> /*
>> * If we support unaligned MMIO, at most one fragment will be split into
>> two:
>> */
>
> Please document which range is for userspace visible flags, which range
> is reserved. Mention that in both headers, point to each other
> ("userspace definitions are there" / "internal definitions are there").
>
> 16/16 bits for each should be fine.
Okay, good to me, will do it in the next version, thank you, Marcelo!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Aug 10
Hi all, Changes since 20120809: New trees: xtensa and thermal The tty tree still has its build failures for which I have disabled 2 staging drivers and applied a patch. It lost its conflicts. I have still reverted 3 commits from the signal tree at the request of the arm maintainer. The akpm tree lost a couple of patches that turned up in the thermal tree. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 195 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (f4ba394 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Merging kbuild-current/rc-fixes (f8f5701 Linux 3.5-rc1) Merging arm-current/fixes (b74253f ARM: 7479/1: mm: avoid NULL dereference when flushing gate_vma with VIVT caches) Merging m68k-current/for-linus (9e2760d m68k: Make sys_atomic_cmpxchg_32 work on classic m68k) Merging powerpc-merge/merge (ad36cb0 powerpc/kvm/book3s_32: Fix MTMSR_EERI macro) Merging sparc/master (a27032e sparc64: do not clobber personality flags in sys_sparc64_personality()) Merging net/master (a2d6a1d igb: Fix register defines for all non-82575 hardware) Merging sound-current/for-linus (144dad9 ALSA: hda_intel: Add Device IDs for Intel Lynx Point-LP PCH) Merging pci-current/for-linus (314489b Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging wireless/master (50e2a30 iwlwifi: disable greenfield transmissions as a workaround) Merging driver-core.current/driver-core-linus (0d7614f Linux 3.6-rc1) Merging tty.current/tty-linus (0d7614f Linux 3.6-rc1) Merging usb.current/usb-linus (3557c9a Merge tag 'for-usb-linus-2012-08-09' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus) Merging staging.current/staging-linus (a26f4dd staging: comedi: rtd520: ioremap'ed addresses are resource_size_t) Merging char-misc.current/char-misc-linus (0d7614f Linux 3.6-rc1) Merging input-current/for-linus (cf45b5a Merge branch 'next' into for-linus) Merging md-current/for-linus (58e94ae md/raid1: close some possible races on write errors during resync) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (76f16f8 crypto: hifn_795x - fix 64bit division and undefined __divdi3 on 32bit archs) Merging ide/master (39a50b4 Merge branch 'hfsplus') Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging arm/fo
[PATCH] leds: wm8350: Convert to devm_regulator_get()
Signed-off-by: Axel Lin
---
drivers/leds/leds-wm8350.c | 29 +++--
1 file changed, 7 insertions(+), 22 deletions(-)
diff --git a/drivers/leds/leds-wm8350.c b/drivers/leds/leds-wm8350.c
index 918d4ba..f5d9ac3 100644
--- a/drivers/leds/leds-wm8350.c
+++ b/drivers/leds/leds-wm8350.c
@@ -201,7 +201,7 @@ static int wm8350_led_probe(struct platform_device *pdev)
struct regulator *isink, *dcdc;
struct wm8350_led *led;
struct wm8350_led_platform_data *pdata = pdev->dev.platform_data;
- int ret, i;
+ int i;
if (pdata == NULL) {
dev_err(&pdev->dev, "no platform data\n");
@@ -214,24 +214,21 @@ static int wm8350_led_probe(struct platform_device *pdev)
return -EINVAL;
}
- isink = regulator_get(&pdev->dev, "led_isink");
+ isink = devm_regulator_get(&pdev->dev, "led_isink");
if (IS_ERR(isink)) {
printk(KERN_ERR "%s: can't get ISINK\n", __func__);
return PTR_ERR(isink);
}
- dcdc = regulator_get(&pdev->dev, "led_vcc");
+ dcdc = devm_regulator_get(&pdev->dev, "led_vcc");
if (IS_ERR(dcdc)) {
printk(KERN_ERR "%s: can't get DCDC\n", __func__);
- ret = PTR_ERR(dcdc);
- goto err_isink;
+ return PTR_ERR(dcdc);
}
led = devm_kzalloc(&pdev->dev, sizeof(*led), GFP_KERNEL);
- if (led == NULL) {
- ret = -ENOMEM;
- goto err_dcdc;
- }
+ if (led == NULL)
+ return -ENOMEM;
led->cdev.brightness_set = wm8350_led_set;
led->cdev.default_trigger = pdata->default_trigger;
@@ -257,17 +254,7 @@ static int wm8350_led_probe(struct platform_device *pdev)
led->value = LED_OFF;
platform_set_drvdata(pdev, led);
- ret = led_classdev_register(&pdev->dev, &led->cdev);
- if (ret < 0)
- goto err_dcdc;
-
- return 0;
-
- err_dcdc:
- regulator_put(dcdc);
- err_isink:
- regulator_put(isink);
- return ret;
+ return led_classdev_register(&pdev->dev, &led->cdev);
}
static int wm8350_led_remove(struct platform_device *pdev)
@@ -277,8 +264,6 @@ static int wm8350_led_remove(struct platform_device *pdev)
led_classdev_unregister(&led->cdev);
flush_work_sync(&led->work);
wm8350_led_disable(led);
- regulator_put(led->dcdc);
- regulator_put(led->isink);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Extcon: renamed files to comply with the standard naming.
Replaced '_' with '-' in the extcon file names, which has been bogging
me since new drivers have been using the standard naming.
Signed-off-by: MyungJoo Ham
---
drivers/extcon/Makefile |4 +-
drivers/extcon/extcon-class.c | 832 +
drivers/extcon/extcon-gpio.c | 164
drivers/extcon/extcon_class.c | 832 -
drivers/extcon/extcon_gpio.c | 164
5 files changed, 998 insertions(+), 998 deletions(-)
create mode 100644 drivers/extcon/extcon-class.c
create mode 100644 drivers/extcon/extcon-gpio.c
delete mode 100644 drivers/extcon/extcon_class.c
delete mode 100644 drivers/extcon/extcon_gpio.c
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index bc7111e..68d6944 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,8 +2,8 @@
# Makefile for external connector class (extcon) devices
#
-obj-$(CONFIG_EXTCON) += extcon_class.o
-obj-$(CONFIG_EXTCON_GPIO) += extcon_gpio.o
+obj-$(CONFIG_EXTCON) += extcon-class.o
+obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
new file mode 100644
index 000..e0373a1
--- /dev/null
+++ b/drivers/extcon/extcon-class.c
@@ -0,0 +1,832 @@
+/*
+ * drivers/extcon/extcon-class.c
+ *
+ * External connector (extcon) class driver
+ *
+ * Copyright (C) 2012 Samsung Electronics
+ * Author: Donggeun Kim
+ * Author: MyungJoo Ham
+ *
+ * based on android/drivers/switch/switch_class.c
+ * Copyright (C) 2008 Google, Inc.
+ * Author: Mike Lockwood
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * extcon_cable_name suggests the standard cable names for commonly used
+ * cable types.
+ *
+ * However, please do not use extcon_cable_name directly for extcon_dev
+ * struct's supported_cable pointer unless your device really supports
+ * every single port-type of the following cable names. Please choose cable
+ * names that are actually used in your extcon device.
+ */
+const char *extcon_cable_name[] = {
+ [EXTCON_USB]= "USB",
+ [EXTCON_USB_HOST] = "USB-Host",
+ [EXTCON_TA] = "TA",
+ [EXTCON_FAST_CHARGER] = "Fast-charger",
+ [EXTCON_SLOW_CHARGER] = "Slow-charger",
+ [EXTCON_CHARGE_DOWNSTREAM] = "Charge-downstream",
+ [EXTCON_HDMI] = "HDMI",
+ [EXTCON_MHL]= "MHL",
+ [EXTCON_DVI]= "DVI",
+ [EXTCON_VGA]= "VGA",
+ [EXTCON_DOCK] = "Dock",
+ [EXTCON_LINE_IN]= "Line-in",
+ [EXTCON_LINE_OUT] = "Line-out",
+ [EXTCON_MIC_IN] = "Microphone",
+ [EXTCON_HEADPHONE_OUT] = "Headphone",
+ [EXTCON_SPDIF_IN] = "SPDIF-in",
+ [EXTCON_SPDIF_OUT] = "SPDIF-out",
+ [EXTCON_VIDEO_IN] = "Video-in",
+ [EXTCON_VIDEO_OUT] = "Video-out",
+ [EXTCON_MECHANICAL] = "Mechanical",
+
+ NULL,
+};
+
+static struct class *extcon_class;
+#if defined(CONFIG_ANDROID)
+static struct class_compat *switch_class;
+#endif /* CONFIG_ANDROID */
+
+static LIST_HEAD(extcon_dev_list);
+static DEFINE_MUTEX(extcon_dev_list_lock);
+
+/**
+ * check_mutually_exclusive - Check if new_state violates mutually_exclusive
+ * condition.
+ * @edev: the extcon device
+ * @new_state: new cable attach status for @edev
+ *
+ * Returns 0 if nothing violates. Returns the index + 1 for the first
+ * violated condition.
+ */
+static int check_mutually_exclusive(struct extcon_dev *edev, u32 new_state)
+{
+ int i = 0;
+
+ if (!edev->mutually_exclusive)
+ return 0;
+
+ for (i = 0; edev->mutually_exclusive[i]; i++) {
+ int count = 0, j;
+ u32 correspondants = new_state & edev->mutually_exclusive[i];
+ u32 exp = 1;
+
+ for (j = 0; j < 32; j++) {
+ if (exp & correspondants)
+ count++;
+ if (count > 1)
+ return i + 1;
+ exp <<= 1;
+ }
+ }
+
+ return 0;
+}
+
+static ssize_t state_show(struct device *dev, struct device_attribute *attr
[PATCH] ACPI: power: Use KERN_DEBUG when no power resources are found
commit a606dac368eed5696fb38e16b1394f1d049c09e9 adds support to link devices which have _PRx, if a device does not have _PRx, a warning message will be printed. This commit is for ZPODD on Intel's platform, on AMD's platform, there is no _PRx to support ZPODD, we use _PSx. So instead of printing a useless warning message on AMD's platform, changing the print level to DEBUG to suppress this message. Reported-by: Borislav Petkov Cc: 3.5+ Signed-off-by: Aaron Lu --- drivers/acpi/power.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index 215ecd0..e5e01d9 100644 --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -460,7 +460,7 @@ int acpi_power_resource_register_device(struct device *dev, acpi_handle handle) return ret; no_power_resource: - printk(KERN_WARNING PREFIX "Invalid Power Resource to register!"); + printk(KERN_DEBUG PREFIX "Invalid Power Resource to register!"); return -ENODEV; } EXPORT_SYMBOL_GPL(acpi_power_resource_register_device); -- 1.7.11.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] tracepoints: Move the work out of line from hotpath sections
* Steven Rostedt (rost...@goodmis.org) wrote:
> On Thu, 2012-08-09 at 16:54 -0700, David Daney wrote:
> > On 08/09/2012 04:16 PM, H. Peter Anvin wrote:
> > > On 08/09/2012 03:25 PM, Steven Rostedt wrote:
> > >>>
> > >>> It might be better to improve gcc to move really cold branches out of
> > >>> line (really, really far away), and use the compiler to do this, rather
> > >>> than to use an extra indirection that adds bloat and complexity to the
> > >>> kernel.
> >
> > Oh, you mean like: -freorder-blocks-and-partition
>
> Actually, what would be really nice is to place a block in a section of
> your choice. Something like:
>
>
> if (unlikely(x)) __attribute__((section(".unlikely"))) {
> /* code here will be in the ".unlikely" section */
> }
In your example, is the attribute attached to the if() or the following
basic block ? Attaching it to the basic block allows a nice level of
genericity:
if (unlikely(x)) __attribute__((section(".unlikely"))) {
...
} else __attribute__((section(".likely"))) {
...
}
or
switch (x) {
case 0:
case 1:
case 6:
__attribute__((section(".likely"))) {
...
break;
}
default:
__attribute__((section(".unlikely"))) {
...
break;
}
}
Thanks,
Mathieu
>
> -- Steve
>
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Yama: higher restrictions should block PTRACE_TRACEME
The higher ptrace restriction levels should be blocking even
PTRACE_TRACEME requests. The comments in the LSM documentation are
misleading about when the checks happen (the parent does not go through
security_ptrace_access_check() on a PTRACE_TRACEME call).
Signed-off-by: Kees Cook
Cc: sta...@vger.kernel.org # 3.5.x and later
---
Documentation/security/Yama.txt | 14 ++--
include/linux/security.h|2 -
security/yama/yama_lsm.c| 41 +++
3 files changed, 48 insertions(+), 9 deletions(-)
diff --git a/Documentation/security/Yama.txt b/Documentation/security/Yama.txt
index e369de2..dd908cf 100644
--- a/Documentation/security/Yama.txt
+++ b/Documentation/security/Yama.txt
@@ -46,14 +46,13 @@ restrictions, it can call prctl(PR_SET_PTRACER,
PR_SET_PTRACER_ANY, ...)
so that any otherwise allowed process (even those in external pid namespaces)
may attach.
-These restrictions do not change how ptrace via PTRACE_TRACEME operates.
-
-The sysctl settings are:
+The sysctl settings (writable only with CAP_SYS_PTRACE) are:
0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
process running under the same uid, as long as it is dumpable (i.e.
did not transition uids, start privileged, or have called
-prctl(PR_SET_DUMPABLE...) already).
+prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
+unchanged.
1 - restricted ptrace: a process must have a predefined relationship
with the inferior it wants to call PTRACE_ATTACH on. By default,
@@ -61,12 +60,13 @@ The sysctl settings are:
classic criteria is also met. To change the relationship, an
inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
an allowed debugger PID to call PTRACE_ATTACH on the inferior.
+Using PTRACE_TRACEME is unchanged.
2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace
-with PTRACE_ATTACH.
+with PTRACE_ATTACH, or through children calling PTRACE_TRACEME.
-3 - no attach: no processes may use ptrace with PTRACE_ATTACH. Once set,
-this sysctl cannot be changed to a lower value.
+3 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via
+PTRACE_TRACEME. Once set, this sysctl value cannot be changed.
The original children-only logic was based on the restrictions in grsecurity.
diff --git a/include/linux/security.h b/include/linux/security.h
index 4e5a73c..3dea6a9 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1242,8 +1242,6 @@ static inline void security_free_mnt_opts(struct
security_mnt_opts *opts)
* Check that the @parent process has sufficient permission to trace the
* current process before allowing the current process to present itself
* to the @parent process for tracing.
- * The parent process will still have to undergo the ptrace_access_check
- * checks before it is allowed to trace this one.
* @parent contains the task_struct structure for debugger process.
* Return 0 if permission is granted.
* @capget:
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index 83554ee..d51b7c7 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -290,10 +290,51 @@ static int yama_ptrace_access_check(struct task_struct
*child,
return rc;
}
+/**
+ * yama_ptrace_traceme - validate PTRACE_TRACEME calls
+ * @parent: task that will become the ptracer of the current task
+ *
+ * Returns 0 if following the ptrace is allowed, -ve on error.
+ */
+static int yama_ptrace_traceme(struct task_struct *parent)
+{
+ int rc;
+
+ /* If standard caps disallows it, so does Yama. We should
+* only tighten restrictions further.
+*/
+ rc = cap_ptrace_traceme(parent);
+ if (rc)
+ return rc;
+
+ /* Only disallow PTRACE_TRACEME on more aggressive settings. */
+ switch (ptrace_scope) {
+ case YAMA_SCOPE_CAPABILITY:
+ if (!ns_capable(task_user_ns(parent), CAP_SYS_PTRACE))
+ rc = -EPERM;
+ break;
+ case YAMA_SCOPE_NO_ATTACH:
+ rc = -EPERM;
+ break;
+ }
+
+ if (rc) {
+ char name[sizeof(current->comm)];
+ printk_ratelimited(KERN_NOTICE
+ "ptraceme of pid %d was attempted by: %s (pid %d)\n",
+ current->pid,
+ get_task_comm(name, parent),
+ parent->pid);
+ }
+
+ return rc;
+}
+
static struct security_operations yama_ops = {
.name = "yama",
.ptrace_access_check = yama_ptrace_access_check,
+ .ptrace_traceme = yama_ptrace_traceme,
.task_prctl = yama_task_prctl,
.task_free =yama_task_free,
};
--
1.7.0.4
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubsc
Re: yama_ptrace_access_check(): possible recursive locking detected
On Thu, Aug 09, 2012 at 06:39:34PM -0700, Kees Cook wrote:
> Hi,
>
> So, after taking a closer look at this, I cannot understand how it's
> possible. Yama's task_lock call is against "current", not "child",
> which is what ptrace_may_access() is locking. And the same code makes
> sure that current != child. Yama would never get called if current ==
> child.
>
> How did you reproduce this situation?
This warning can be triggered with Dave Jones' trinity tool:
git://git.codemonkey.org.uk/trinity
That's a very dangerous tool, please only run it as normal user in a
backed up and chrooted test box. I personally run it inside an initrd.
If you are interested in reproducing this, I can send you the ready
made initrd in private email.
Thanks,
Fengguang
> On Thu, Jul 26, 2012 at 6:47 AM, Fengguang Wu wrote:
> > Hi Kees,
> >
> > Here is a recursive lock possibility:
> >
> > ptrace_may_access()
> > =>task_lock(task);
> > yama_ptrace_access_check()
> > get_task_comm()
> > => task_lock(task);
> >
> > [ 60.230444] =
> > [ 60.232078] [ INFO: possible recursive locking detected ]
> > [ 60.232078] 3.5.0+ #281 Not tainted
> > [ 60.232078] -
> > [ 60.232078] trinity-child0/17019 is trying to acquire lock:
> > [ 60.232078] (&(&p->alloc_lock)->rlock){+.+...}, at: []
> > get_task_comm+0x4a/0xf0
> > [ 60.232078]
> > [ 60.232078] but task is already holding lock:
> > [ 60.232078] (&(&p->alloc_lock)->rlock){+.+...}, at: []
> > ptrace_may_access+0x4a/0xf0
> > [ 60.232078]
> > [ 60.232078] other info that might help us debug this:
> > [ 60.232078] Possible unsafe locking scenario:
> > [ 60.232078]
> > [ 60.232078]CPU0
> > [ 60.232078]
> > [ 60.232078] lock(&(&p->alloc_lock)->rlock);
> > [ 60.232078] lock(&(&p->alloc_lock)->rlock);
> > [ 60.232078]
> > [ 60.232078] *** DEADLOCK ***
> > [ 60.232078]
> > [ 60.232078] May be due to missing lock nesting notation
> > [ 60.232078]
> > [ 60.232078] 3 locks held by trinity-child0/17019:
> > [ 60.232078] #0: (&p->lock){+.+.+.}, at: []
> > seq_read+0x33/0x6b0
> > [ 60.232078] #1: (&sig->cred_guard_mutex){+.+.+.}, at: []
> > lock_trace+0x2e/0xb0
> > [ 60.232078] #2: (&(&p->alloc_lock)->rlock){+.+...}, at: []
> > ptrace_may_access+0x4a/0xf0
> > [ 60.232078]
> > [ 60.232078] stack backtrace:
> > [ 60.232078] Pid: 17019, comm: trinity-child0 Not tainted 3.5.0+ #281
> > [ 60.232078] Call Trace:
> > [ 60.232078] [] __lock_acquire+0x1498/0x14f0
> > [ 60.232078] [] ? trace_hardirqs_off+0x27/0x40
> > [ 60.232078] [] lock_acquire+0xd0/0x110
> > [ 60.232078] [] ? get_task_comm+0x4a/0xf0
> > [ 60.232078] [] _raw_spin_lock+0x60/0x110
> > [ 60.232078] [] ? get_task_comm+0x4a/0xf0
> > [ 60.232078] [] get_task_comm+0x4a/0xf0
> > [ 60.232078] [] yama_ptrace_access_check+0x468/0x4a0
> > [ 60.232078] [] ? yama_ptrace_access_check+0x15f/0x4a0
> > [ 60.232078] [] security_ptrace_access_check+0x1a/0x30
> > [ 60.232078] [] __ptrace_may_access+0x189/0x310
> > [ 60.232078] [] ? __ptrace_may_access+0x2c/0x310
> > [ 60.232078] [] ptrace_may_access+0x7d/0xf0
> > [ 60.232078] [] lock_trace+0x6a/0xb0
> > [ 60.232078] [] proc_pid_stack+0x76/0x170
> > [ 60.232078] [] proc_single_show+0x74/0x100
> > [ 60.232078] [] seq_read+0x163/0x6b0
> > [ 60.232078] [] ? do_setitimer+0x220/0x330
> > [ 60.232078] [] ? seq_lseek+0x1f0/0x1f0
> > [ 60.232078] [] vfs_read+0xca/0x280
> > [ 60.232078] [] ? seq_lseek+0x1f0/0x1f0
> > [ 60.232078] [] sys_read+0x66/0xe0
> > [ 60.232078] [] syscall_call+0x7/0xb
> > [ 60.232078] [] ? __schedule+0x2a0/0xc80
> >
> > Thanks,
> > Fengguang
>
>
>
> --
> Kees Cook
> Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon: fixing typos
> Signed-off-by: Peter Meerwald
The three "typo" patches:
Signed-off-by: MyungJoo Ham
I will apply the patches as soon as the branch is cleared up (will be using
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/extcon-for-next
until I get a decent repository somewhere)
Cheers!
MyungJoo
N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콗喩zX㎍썳變}찠꼿쟺�&j:+v돣�쳭喩zZ+�+zf＂톒쉱�~넮녬i鎬z� 췿ⅱ�?솳鈺�&�)刪f뷌^j푹y쬶끷@A첺뛴
0띠h��뭝
Re: [dm-devel] [PATCH v5 12/12] block: Only clone bio vecs that are in use
Kent, >> -- >> You are changing the meaning of __bio_clone() here. In old code, the >> number of io_vecs, bi_idx, bi_vcnt are preserved. But in this modified >> code, you are mapping bio_src's bi_iovec[bi_idx] to bio_dests >> bi_iovec[0] and also restricting the number of allocated io_vecs of >> the clone. It may be useful for cases were we would like a identical >> copy of the original bio (may not be in current code base, but this >> implementation is definitely not what one would expect from the name >> "clone"). > > The problem is that bio_clone() is used on bios that were not allocated > or submitted by the cloning module. > > If some code somewher submits a bio that points to 500 pages, but by the > time it gets to a driver it only points to 200 pages (say, because it > was split), that clone should succeed; it shouldn't fail simply because > it was trying to clone more than was necessary. > I would say, the code that submits bio with 500 pages is broken. It needs to take care of underlying restrictions before submitting bios. And that's one of the reason for having bio_add_page(), especially for stackable modules. > Bios have certain (poorly documented) semantics, and if this breaks > anything it's probably because that code was doing something crazy in > the first place. > Agree. But doing the above doesn't help in improving the situation, just makes it even less clear. Regards, Muthu. > In particular, if this change breaks anything then the new bio_split() > _will_ break things. > > We need to be clear about our interfaces; in this case bi_idx and > bi_vcnt, in particular. Either this is a safe change, or it's not. If > no one knows... that's a bigger problem, and not just for this patch... > > Fortunately this code actually has been tested quite a bit (and the bio > splitting code for even longer), and (somewhat to my surprise) I haven't > run into any bugs caused by it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] tracepoints: Move the work out of line from hotpath sections
On Thu, 2012-08-09 at 16:54 -0700, David Daney wrote:
> On 08/09/2012 04:16 PM, H. Peter Anvin wrote:
> > On 08/09/2012 03:25 PM, Steven Rostedt wrote:
> >>>
> >>> It might be better to improve gcc to move really cold branches out of
> >>> line (really, really far away), and use the compiler to do this, rather
> >>> than to use an extra indirection that adds bloat and complexity to the
> >>> kernel.
>
> Oh, you mean like: -freorder-blocks-and-partition
Actually, what would be really nice is to place a block in a section of
your choice. Something like:
if (unlikely(x)) __attribute__((section(".unlikely"))) {
/* code here will be in the ".unlikely" section */
}
-- 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] efikamx: reintroduce Genesi Efika MX Smarttop via device tree
On Thu, Aug 09, 2012 at 09:29:39AM -0500, Matt Sealey wrote: > The reason the new kernel depends on the new U-Boot is we're trying to > do all pinmux configuration in U-Boot (and we do in-house, and it > works). No pinctrl stuff in the kernel or device tree is required at > this point. The Old Kernel will remux a few things redundantly or > change drive strengths or whatever or add hysteresis to the UART port > which is not board-burning but is not really necessary, but it will > work. The new kernel will just be able to do what it does out of the > box, which is how it should be (hence why I object to adding pinctrl > setup...) > Then I will have to refuse to accept your patch, because I'm working on a series to remove pinctrl_provide_dummies() from imx51_dt_init(). -- Regards, Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: thermal patches in linux-next
Hi, Stephen, On 五, 2012-08-10 at 09:08 +1000, Stephen Rothwell wrote: > Hi Rui, > > On Thu, 09 Aug 2012 14:45:46 +0800 Zhang Rui wrote: > > > > On 二, 2012-08-07 at 10:53 +0800, Zhang Rui wrote: > > > Hi, all, > > > > > > I just created a git tree for catching all thermal changes. > > > http://git.kernel.org/?p=linux/kernel/git/rzhang/linux.git;a=summary > > > and I also created the next branch, which I'd like to be set for > > > linux-next inclusion, but don't know how. > > > > > I create a tree for thermal management, > > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git > > > > could you please include my next branch for linux-next? > > Included from today. > Thank you. > > And could you please drop these commits > > ef25a0fe0087963c1611c1c8903886fbea053f76 > > 09ec52fca274ba88d68df3198de92abdaaff417b > > ab6d2f029358c917508bf88bbd6a9193a8e39fc8 > > 66447fa993cbce56b4076f169a56f62350f6c7b8 > > ec62abb8b46021ca9ee6b8692b26974ace9007f0 > > 5ecbaf57d7885eedd924e391d91847d3df9fe0f8 > > 851414b2249afd8c128d29912dfd7060eaea8932 > > and pull my next branch instead? > > That is not how linux-next normally works. Those commits are in Adnrew's > quilt series, so you need to ask him to drop them. However, because of > the way the akpm tree works, any duplicate patches will disappear from my > copy of Andrew's series. > Andrew, could you please drop these patches? these commits either will be or has been re-based on top of my tree. thanks, rui > > In this case, I will remove them if they conflict too much or you take > them (rebased) into your tree. > > Andrew, any chance of a new mmotm series? I am still working off (a reduced > part) of the mmotm series from July 21 ... > > Thanks for adding your subsystem tree as a participant of linux-next. As > you may know, this is not a judgment of your code. The purpose of > linux-next is for integration testing and to lower the impact of > conflicts between subsystems in the next merge window. > > You will need to ensure that the patches/commits in your tree/series have > been: > * submitted under GPL v2 (or later) and include the Contributor's > Signed-off-by, > * posted to the relevant mailing list, > * reviewed by you (or another maintainer of your subsystem tree), > * successfully unit tested, and > * destined for the current or next Linux merge window. > > Basically, this should be just what you would send to Linus (or ask him > to fetch). It is allowed to be rebased if you deem it necessary. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: yama_ptrace_access_check(): possible recursive locking detected
Hi,
So, after taking a closer look at this, I cannot understand how it's
possible. Yama's task_lock call is against "current", not "child",
which is what ptrace_may_access() is locking. And the same code makes
sure that current != child. Yama would never get called if current ==
child.
How did you reproduce this situation?
Thanks,
-Kees
On Thu, Jul 26, 2012 at 6:47 AM, Fengguang Wu wrote:
> Hi Kees,
>
> Here is a recursive lock possibility:
>
> ptrace_may_access()
> =>task_lock(task);
> yama_ptrace_access_check()
> get_task_comm()
> => task_lock(task);
>
> [ 60.230444] =
> [ 60.232078] [ INFO: possible recursive locking detected ]
> [ 60.232078] 3.5.0+ #281 Not tainted
> [ 60.232078] -
> [ 60.232078] trinity-child0/17019 is trying to acquire lock:
> [ 60.232078] (&(&p->alloc_lock)->rlock){+.+...}, at: []
> get_task_comm+0x4a/0xf0
> [ 60.232078]
> [ 60.232078] but task is already holding lock:
> [ 60.232078] (&(&p->alloc_lock)->rlock){+.+...}, at: []
> ptrace_may_access+0x4a/0xf0
> [ 60.232078]
> [ 60.232078] other info that might help us debug this:
> [ 60.232078] Possible unsafe locking scenario:
> [ 60.232078]
> [ 60.232078]CPU0
> [ 60.232078]
> [ 60.232078] lock(&(&p->alloc_lock)->rlock);
> [ 60.232078] lock(&(&p->alloc_lock)->rlock);
> [ 60.232078]
> [ 60.232078] *** DEADLOCK ***
> [ 60.232078]
> [ 60.232078] May be due to missing lock nesting notation
> [ 60.232078]
> [ 60.232078] 3 locks held by trinity-child0/17019:
> [ 60.232078] #0: (&p->lock){+.+.+.}, at: [] seq_read+0x33/0x6b0
> [ 60.232078] #1: (&sig->cred_guard_mutex){+.+.+.}, at: []
> lock_trace+0x2e/0xb0
> [ 60.232078] #2: (&(&p->alloc_lock)->rlock){+.+...}, at: []
> ptrace_may_access+0x4a/0xf0
> [ 60.232078]
> [ 60.232078] stack backtrace:
> [ 60.232078] Pid: 17019, comm: trinity-child0 Not tainted 3.5.0+ #281
> [ 60.232078] Call Trace:
> [ 60.232078] [] __lock_acquire+0x1498/0x14f0
> [ 60.232078] [] ? trace_hardirqs_off+0x27/0x40
> [ 60.232078] [] lock_acquire+0xd0/0x110
> [ 60.232078] [] ? get_task_comm+0x4a/0xf0
> [ 60.232078] [] _raw_spin_lock+0x60/0x110
> [ 60.232078] [] ? get_task_comm+0x4a/0xf0
> [ 60.232078] [] get_task_comm+0x4a/0xf0
> [ 60.232078] [] yama_ptrace_access_check+0x468/0x4a0
> [ 60.232078] [] ? yama_ptrace_access_check+0x15f/0x4a0
> [ 60.232078] [] security_ptrace_access_check+0x1a/0x30
> [ 60.232078] [] __ptrace_may_access+0x189/0x310
> [ 60.232078] [] ? __ptrace_may_access+0x2c/0x310
> [ 60.232078] [] ptrace_may_access+0x7d/0xf0
> [ 60.232078] [] lock_trace+0x6a/0xb0
> [ 60.232078] [] proc_pid_stack+0x76/0x170
> [ 60.232078] [] proc_single_show+0x74/0x100
> [ 60.232078] [] seq_read+0x163/0x6b0
> [ 60.232078] [] ? do_setitimer+0x220/0x330
> [ 60.232078] [] ? seq_lseek+0x1f0/0x1f0
> [ 60.232078] [] vfs_read+0xca/0x280
> [ 60.232078] [] ? seq_lseek+0x1f0/0x1f0
> [ 60.232078] [] sys_read+0x66/0xe0
> [ 60.232078] [] syscall_call+0x7/0xb
> [ 60.232078] [] ? __schedule+0x2a0/0xc80
>
> Thanks,
> Fengguang
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] regulator: mc13xxx: Remove get_voltage implementation for single voltage regulators
This is not required after commit f7df20ec
"regulator: core: Use list_voltage() to read single voltage regulators"
Signed-off-by: Axel Lin
---
drivers/regulator/mc13783-regulator.c |1 -
drivers/regulator/mc13892-regulator.c |1 -
drivers/regulator/mc13xxx-regulator-core.c | 11 ---
drivers/regulator/mc13xxx.h|1 -
4 files changed, 14 deletions(-)
diff --git a/drivers/regulator/mc13783-regulator.c
b/drivers/regulator/mc13783-regulator.c
index 2587ea1..4977b19 100644
--- a/drivers/regulator/mc13783-regulator.c
+++ b/drivers/regulator/mc13783-regulator.c
@@ -324,7 +324,6 @@ static struct regulator_ops mc13783_gpo_regulator_ops = {
.is_enabled = mc13783_gpo_regulator_is_enabled,
.list_voltage = regulator_list_voltage_table,
.set_voltage = mc13xxx_fixed_regulator_set_voltage,
- .get_voltage = mc13xxx_fixed_regulator_get_voltage,
};
static int __devinit mc13783_regulator_probe(struct platform_device *pdev)
diff --git a/drivers/regulator/mc13892-regulator.c
b/drivers/regulator/mc13892-regulator.c
index 09265f0..1fa6381 100644
--- a/drivers/regulator/mc13892-regulator.c
+++ b/drivers/regulator/mc13892-regulator.c
@@ -390,7 +390,6 @@ static struct regulator_ops mc13892_gpo_regulator_ops = {
.is_enabled = mc13892_gpo_regulator_is_enabled,
.list_voltage = regulator_list_voltage_table,
.set_voltage = mc13xxx_fixed_regulator_set_voltage,
- .get_voltage = mc13xxx_fixed_regulator_get_voltage,
};
static int mc13892_sw_regulator_get_voltage_sel(struct regulator_dev *rdev)
diff --git a/drivers/regulator/mc13xxx-regulator-core.c
b/drivers/regulator/mc13xxx-regulator-core.c
index 8151889..88cbb83 100644
--- a/drivers/regulator/mc13xxx-regulator-core.c
+++ b/drivers/regulator/mc13xxx-regulator-core.c
@@ -152,23 +152,12 @@ int mc13xxx_fixed_regulator_set_voltage(struct
regulator_dev *rdev, int min_uV,
}
EXPORT_SYMBOL_GPL(mc13xxx_fixed_regulator_set_voltage);
-int mc13xxx_fixed_regulator_get_voltage(struct regulator_dev *rdev)
-{
- int id = rdev_get_id(rdev);
-
- dev_dbg(rdev_get_dev(rdev), "%s id: %d\n", __func__, id);
-
- return rdev->desc->volt_table[0];
-}
-EXPORT_SYMBOL_GPL(mc13xxx_fixed_regulator_get_voltage);
-
struct regulator_ops mc13xxx_fixed_regulator_ops = {
.enable = mc13xxx_regulator_enable,
.disable = mc13xxx_regulator_disable,
.is_enabled = mc13xxx_regulator_is_enabled,
.list_voltage = regulator_list_voltage_table,
.set_voltage = mc13xxx_fixed_regulator_set_voltage,
- .get_voltage = mc13xxx_fixed_regulator_get_voltage,
};
EXPORT_SYMBOL_GPL(mc13xxx_fixed_regulator_ops);
diff --git a/drivers/regulator/mc13xxx.h b/drivers/regulator/mc13xxx.h
index eaff551..06c8903 100644
--- a/drivers/regulator/mc13xxx.h
+++ b/drivers/regulator/mc13xxx.h
@@ -34,7 +34,6 @@ struct mc13xxx_regulator_priv {
extern int mc13xxx_fixed_regulator_set_voltage(struct regulator_dev *rdev,
int min_uV, int max_uV, unsigned *selector);
-extern int mc13xxx_fixed_regulator_get_voltage(struct regulator_dev *rdev);
#ifdef CONFIG_OF
extern int mc13xxx_get_num_regulators_dt(struct platform_device *pdev);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] regulator: twl: Remove get_voltage implementation for single voltage regulators
This is not required after commit f7df20ec
"regulator: core: Use list_voltage() to read single voltage regulators"
Signed-off-by: Axel Lin
---
drivers/regulator/twl-regulator.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index f2f49e2..2d9a2a8 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -624,18 +624,9 @@ static int twlfixed_list_voltage(struct regulator_dev
*rdev, unsigned index)
return info->min_mV * 1000;
}
-static int twlfixed_get_voltage(struct regulator_dev *rdev)
-{
- struct twlreg_info *info = rdev_get_drvdata(rdev);
-
- return info->min_mV * 1000;
-}
-
static struct regulator_ops twl4030fixed_ops = {
.list_voltage = twlfixed_list_voltage,
- .get_voltage= twlfixed_get_voltage,
-
.enable = twl4030reg_enable,
.disable= twl4030reg_disable,
.is_enabled = twl4030reg_is_enabled,
@@ -648,8 +639,6 @@ static struct regulator_ops twl4030fixed_ops = {
static struct regulator_ops twl6030fixed_ops = {
.list_voltage = twlfixed_list_voltage,
- .get_voltage= twlfixed_get_voltage,
-
.enable = twl6030reg_enable,
.disable= twl6030reg_disable,
.is_enabled = twl6030reg_is_enabled,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] regulator: isl6271a: Remove get_voltage implementation for isl_fixed_ops
This is not required after commit f7df20ec
"regulator: core: Use list_voltage() to read single voltage regulators"
Signed-off-by: Axel Lin
---
drivers/regulator/isl6271a-regulator.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/regulator/isl6271a-regulator.c
b/drivers/regulator/isl6271a-regulator.c
index 1d145a0..d8ecf49 100644
--- a/drivers/regulator/isl6271a-regulator.c
+++ b/drivers/regulator/isl6271a-regulator.c
@@ -73,13 +73,7 @@ static struct regulator_ops isl_core_ops = {
.map_voltage= regulator_map_voltage_linear,
};
-static int isl6271a_get_fixed_voltage(struct regulator_dev *dev)
-{
- return dev->desc->min_uV;
-}
-
static struct regulator_ops isl_fixed_ops = {
- .get_voltage= isl6271a_get_fixed_voltage,
.list_voltage = regulator_list_voltage_linear,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] regulator: ab8500: Remove get_voltage implementation for ab8500_regulator_fixed_ops
This is not required after commit f7df20ec
"regulator: core: Use list_voltage() to read single voltage regulators"
Signed-off-by: Axel Lin
---
drivers/regulator/ab8500.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index 8807166..c884a5c 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -257,16 +257,10 @@ static struct regulator_ops ab8500_regulator_ops = {
.set_voltage_time_sel = ab8500_regulator_set_voltage_time_sel,
};
-static int ab8500_fixed_get_voltage(struct regulator_dev *rdev)
-{
- return rdev->desc->min_uV;
-}
-
static struct regulator_ops ab8500_regulator_fixed_ops = {
.enable = ab8500_regulator_enable,
.disable= ab8500_regulator_disable,
.is_enabled = ab8500_regulator_is_enabled,
- .get_voltage= ab8500_fixed_get_voltage,
.list_voltage = regulator_list_voltage_linear,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] regulator: ab3100: Remove get_voltage implementation for regulator_ops_fixed
This is not required after commit f7df20ec
"regulator: core: Use list_voltage() to read single voltage regulators"
Signed-off-by: Axel Lin
---
drivers/regulator/ab3100.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/regulator/ab3100.c b/drivers/regulator/ab3100.c
index c151fd5..65ad2b3 100644
--- a/drivers/regulator/ab3100.c
+++ b/drivers/regulator/ab3100.c
@@ -347,17 +347,11 @@ static int ab3100_get_voltage_regulator_external(struct
regulator_dev *reg)
return abreg->plfdata->external_voltage;
}
-static int ab3100_get_fixed_voltage_regulator(struct regulator_dev *reg)
-{
- return reg->desc->min_uV;
-}
-
static struct regulator_ops regulator_ops_fixed = {
.list_voltage = regulator_list_voltage_linear,
.enable = ab3100_enable_regulator,
.disable = ab3100_disable_regulator,
.is_enabled = ab3100_is_enabled_regulator,
- .get_voltage = ab3100_get_fixed_voltage_regulator,
};
static struct regulator_ops regulator_ops_variable = {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] regulator: core: Add checking n_voltages if using list_voltage() to read voltage regulators
Use list_voltage() to read single voltage regulators should be only applied to
single voltage regulators, thus add checking n_voltages for this case.
Signed-off-by: Axel Lin
---
drivers/regulator/core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 0fffeae..5469f9f 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2395,7 +2395,8 @@ static int _regulator_get_voltage(struct regulator_dev
*rdev)
ret = rdev->desc->ops->list_voltage(rdev, sel);
} else if (rdev->desc->ops->get_voltage) {
ret = rdev->desc->ops->get_voltage(rdev);
- } else if (rdev->desc->ops->list_voltage) {
+ } else if (rdev->desc->ops->list_voltage &&
+ (rdev->desc->n_voltages == 1)) {
ret = rdev->desc->ops->list_voltage(rdev, 0);
} else {
return -EINVAL;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] mmap: feed back correct prev vma when finding vma
On Thu, 9 Aug 2012, Hillf Danton wrote:
> After walking rb tree, if vma is determined, prev vma has to be determined
> based on vma; and rb_prev should be considered only if no vma determined.
Why? Because you think more code is better code? I disagree.
If you have seen a bug here, please tell how to reproduce it.
I have not heard of a bug here: I think you're saying, if the rbtree
were inconsistent with the vma list, then you think it would be a good
idea to believe the vma list instead of the rbtree where there's a choice.
But the rbtree had better not be inconsistent with the vma list.
Hugh
>
> Signed-off-by: Hillf Danton
> ---
>
> --- a/mm/mmap.c Fri Aug 3 07:38:10 2012
> +++ b/mm/mmap.c Mon Aug 6 20:10:18 2012
> @@ -385,9 +385,13 @@ find_vma_prepare(struct mm_struct *mm, u
> }
> }
>
> - *pprev = NULL;
> - if (rb_prev)
> - *pprev = rb_entry(rb_prev, struct vm_area_struct, vm_rb);
> + if (vma) {
> + *pprev = vma->vm_prev;
> + } else {
> + *pprev = NULL;
> + if (rb_prev)
> + *pprev = rb_entry(rb_prev, struct vm_area_struct,
> vm_rb);
> + }
> *rb_link = __rb_link;
> *rb_parent = __rb_parent;
> return vma;
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] zram/zsmalloc promotion
On Wed, Aug 08, 2012 at 10:35:37AM -0700, Nitin Gupta wrote: > On 08/07/2012 11:12 PM, Minchan Kim wrote: > > This patchset promotes zram/zsmalloc from staging. > > Both are very clean and zram is used by many embedded product > > for a long time. > > > > [1-3] are patches not merged into linux-next yet but needed > > it as base for [4-5] which promotes zsmalloc. > > Greg, if you merged [1-3] already, skip them. > > > > Seth Jennings (5): > > 1. zsmalloc: s/firstpage/page in new copy map funcs > > 2. zsmalloc: prevent mappping in interrupt context > > 3. zsmalloc: add page table mapping method > > 4. zsmalloc: collapse internal .h into .c > > 5. zsmalloc: promote to mm/ > > > > Minchan Kim (2): > > 6. zram: promote zram from staging > > 7. zram: select ZSMALLOC when ZRAM is configured > > > > All the changes look good to me. FWIW, for the entire series: > Acked-by: Nitin Gupta And Reviewed-by: Konrad Rzeszutek Wilk as well. Thanks! > > Thanks for all the work. > Nitin > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org";> em...@kvack.org > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH] PM QoS: Add a metric : Bus Throughput.
> + Myungjoo Ham,
>
> It used at devfreq. Mr. Ham can you explain it in detail?
>
> Thank you,
> Kyungmin Park
> ,
> On 8/9/12, Rafael J. Wysocki wrote:
> > On Wednesday, August 08, 2012, Jonghwa Lee wrote:
> >> Bus throughput metric is added to PM QoS in order to control the
> >> frequency of memory interfaces and busses with PM QoS.
> >>
> >> Signed-off-by: Jonghwa Lee
> >> Signed-off-by: Kyungmin Park
> >
> > I said some time ago I didn't want any new global PM QoS classes to be
> > added this way.
> >
> > Can you please post a driver patch using this new thing?
> >
> > Rafael
It'd be too early for V4L2 device driver QoS patches as they are undergoing
major updates and the previous QoS patches over they are now obsolete.
However, I've found that one QoS patch is still intact with the current one.
Here goes the example driver that uses Bus-Throughput for its operation.
(Fortunately, it is not V4L2, but DRM driver)
It is a G2D (2D graphics acceleration) device driver that gets command lists
from userspace and then process them via DMA. Many command lists finish even
before any DVFS mechanism may react while the response time of a command list
is still important for the user processes.
Here we go:
---
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index d2d88f2..969b2c5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -135,6 +136,7 @@ struct g2d_data {
struct workqueue_struct *g2d_workq;
struct work_struct runqueue_work;
struct exynos_drm_subdrvsubdrv;
+ struct pm_qos_request_list pm_qos;
boolsuspended;
/* cmdlist */
@@ -314,6 +316,9 @@ static void g2d_dma_start(struct g2d_data *g2d,
pm_runtime_get_sync(g2d->dev);
clk_enable(g2d->gate_clk);
+ /* 416MHz w/ 64b 30% saturating bus */
+ pm_qos_update_request(&g2d->pm_qos, 100);
+
/* interrupt enable */
writel_relaxed(G2D_INTEN_ACF | G2D_INTEN_UCF | G2D_INTEN_GCF,
g2d->regs + G2D_INTEN);
@@ -360,6 +365,7 @@ static void g2d_runqueue_worker(struct work_struct *work)
struct g2d_data *g2d = container_of(work, struct g2d_data,
runqueue_work);
+ pm_qos_update_request(&g2d->pm_qos, 0);
mutex_lock(&g2d->runqueue_mutex);
clk_disable(g2d->gate_clk);
@@ -841,6 +847,8 @@ static int __devinit g2d_probe(struct platform_device *pdev)
goto err_free_irq;
}
+ pm_qos_add_request(&g2d->pm_qos, PM_QOS_BUS_DMA_THROUGHPUT, 0);
+
dev_info(dev, "The exynos g2d(ver %d.%d) successfully probed\n",
G2D_HW_MAJOR_VER, G2D_HW_MINOR_VER);
@@ -872,6 +880,7 @@ static int __devexit g2d_remove(struct platform_device
*pdev)
struct g2d_data *g2d = platform_get_drvdata(pdev);
cancel_work_sync(&g2d->runqueue_work);
+ pm_qos_remove_request(&g2d->pm_qos);
exynos_drm_subdrv_unregister(&g2d->subdrv);
free_irq(g2d->irq, g2d);
> >
> >
> >> ---
> >> include/linux/pm_qos.h |2 ++
> >> kernel/power/qos.c | 15 ++-
> >> 2 files changed, 16 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
> >> index 233149c..6db4939 100644
> >> --- a/include/linux/pm_qos.h
> >> +++ b/include/linux/pm_qos.h
> >> @@ -15,6 +15,7 @@ enum {
> >>PM_QOS_CPU_DMA_LATENCY,
> >>PM_QOS_NETWORK_LATENCY,
> >>PM_QOS_NETWORK_THROUGHPUT,
> >> + PM_QOS_BUS_DMA_THROUGHPUT,
> >>
> >>/* insert new class ID */
> >>PM_QOS_NUM_CLASSES,
> >> @@ -26,6 +27,7 @@ enum {
> >> #define PM_QOS_NETWORK_LAT_DEFAULT_VALUE (2000 * USEC_PER_SEC)
> >> #define PM_QOS_NETWORK_THROUGHPUT_DEFAULT_VALUE 0
> >> #define PM_QOS_DEV_LAT_DEFAULT_VALUE 0
> >> +#define PM_QOS_BUS_DMA_THROUGHPUT_DEFAULT_VALUE 0
> >>
> >> struct pm_qos_request {
> >>struct plist_node node;
> >> diff --git a/kernel/power/qos.c b/kernel/power/qos.c
> >> index 6a031e6..75322cc 100644
> >> --- a/kernel/power/qos.c
> >> +++ b/kernel/power/qos.c
> >> @@ -100,12 +100,25 @@ static struct pm_qos_object
> >> network_throughput_pm_qos = {
> >>.name = "network_throughput",
> >> };
> >>
> >> +static BLOCKING_NOTIFIER_HEAD(bus_dma_throughput_notifier);
> >> +static struct pm_qos_constraints bus_dma_tput_constraints = {
> >> + .list = PLIST_HEAD_INIT(bus_dma_tput_constraints.list),
> >> + .target_value = PM_QOS_BUS_DMA_THROUGHPUT_DEFAULT_VALUE,
> >> + .default_value = PM_QOS_BUS_DMA_THROUGHPUT_DEFAULT_VALUE,
> >> + .type = PM_QOS_MAX,
> >> + .notifiers = &bus_dma_throughput_notifier,
> >> +};
> >> +static struct pm_qos_object bus_dma_throughput_pm_qos = {
> >> + .constraints = &bus_dma_tput_constraints,
> >> + .
Re: [PATCH v2] SubmittingPatches: clarify SOB tag usage when evolving submissions
On Thu, 2012-08-09 at 14:48 -0700, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Initial large code submissions typically are not accepted > on their first patch submission. The developers are > typically given feedback and at times some developers may > even submit changes to the original authors for integration > into their second submission attempt. > > Developers wishing to contribute changes to the evolution > of a second patch submission must supply their own Siged-off-by Signed-off-by: :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] wm831x-dcdc: fix coccinelle warnings of missing IRQF_ONESHOT
From: Fengguang Wu
/c/kernel-tests/src/linux/drivers/regulator/wm831x-dcdc.c:829:7-27: ERROR:
Threaded IRQ with no primary handler requested without IRQF_ONESHOT
/c/kernel-tests/src/linux/drivers/regulator/wm831x-dcdc.c:695:7-27: ERROR:
Threaded IRQ with no primary handler requested without IRQF_ONESHOT
/c/kernel-tests/src/linux/drivers/regulator/wm831x-dcdc.c:533:7-27: ERROR:
Threaded IRQ with no primary handler requested without IRQF_ONESHOT
/c/kernel-tests/src/linux/drivers/regulator/wm831x-dcdc.c:542:7-27: ERROR:
Threaded IRQ with no primary handler requested without IRQF_ONESHOT
Generated by: scripts/coccinelle/misc/irqf_oneshot.cocci
Make sure threaded IRQs without a primary handler are always request with
IRQF_ONESHOT
Signed-off-by: Fengguang Wu
Signed-off-by: Feng Tang
---
drivers/regulator/wm831x-dcdc.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/wm831x-dcdc.c b/drivers/regulator/wm831x-dcdc.c
index 7413885..a2a6093 100644
--- a/drivers/regulator/wm831x-dcdc.c
+++ b/drivers/regulator/wm831x-dcdc.c
@@ -532,7 +532,7 @@ static __devinit int wm831x_buckv_probe(struct
platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "UV"));
ret = request_threaded_irq(irq, NULL, wm831x_dcdc_uv_irq,
- IRQF_TRIGGER_RISING, dcdc->name, dcdc);
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
dcdc->name, dcdc);
if (ret != 0) {
dev_err(&pdev->dev, "Failed to request UV IRQ %d: %d\n",
irq, ret);
@@ -541,7 +541,7 @@ static __devinit int wm831x_buckv_probe(struct
platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "HC"));
ret = request_threaded_irq(irq, NULL, wm831x_dcdc_oc_irq,
- IRQF_TRIGGER_RISING, dcdc->name, dcdc);
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
dcdc->name, dcdc);
if (ret != 0) {
dev_err(&pdev->dev, "Failed to request HC IRQ %d: %d\n",
irq, ret);
@@ -694,7 +694,7 @@ static __devinit int wm831x_buckp_probe(struct
platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "UV"));
ret = request_threaded_irq(irq, NULL, wm831x_dcdc_uv_irq,
- IRQF_TRIGGER_RISING, dcdc->name, dcdc);
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
dcdc->name, dcdc);
if (ret != 0) {
dev_err(&pdev->dev, "Failed to request UV IRQ %d: %d\n",
irq, ret);
@@ -828,7 +828,7 @@ static __devinit int wm831x_boostp_probe(struct
platform_device *pdev)
irq = wm831x_irq(wm831x, platform_get_irq_byname(pdev, "UV"));
ret = request_threaded_irq(irq, NULL, wm831x_dcdc_uv_irq,
- IRQF_TRIGGER_RISING, dcdc->name,
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
dcdc->name,
dcdc);
if (ret != 0) {
dev_err(&pdev->dev, "Failed to request UV IRQ %d: %d\n",
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH v2 1/2] dm: verity support data device offset (Linux 3.4.7)
On Aug 8, 2012, at 7:04 PM, Alasdair G Kergon wrote: > > However, first you need to address the second part of Mikulas's email, > namely to make the case for these changes rather than making no kernel > changes and instead stacking the verity target over a linear target. > > To put this another way, your patch offers an alternative way to do > something we think the existing kernel can already do, so you need to > advance some reasons why you believe the new alternative method is worth > adding to the kernel and explain this in the patch header. I'm afraid for some reason I didn't get Mikulas's first email, only the reply from Milan which must have been an incomplete quote of Mikulas's text. For my part, I approached this as porting my existing code to the new dm-verity implementation included in Linux 3.4. The previous code used a data offset as this was convenient and directly supported the block device image format I put together back then. However I can indeed accomplish what I need using linear, it's just a bit more code. I am not able to measure any runtime performance difference. The primary benefit I can see for is the reduced kernel footprint if the linear target does not need to be included (and my corresponding setup code is about 1/3 smaller). With my cross-compiled kernel the savings is ~1KB; this is obviously a very small benefit. So I would defer to others on this. While supporting the data offset would be convenient and match well with my specific use case I can live without it and I don't think the size cost is significant enough to matter. I expect to get some feedback from other developers in the coming months regarding my Linux 3.4 integration but I doubt it would change my current opinion on the matter. Thanks, -- Wesley Miaw signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PATCH 02/19] mm/mpol: Remove NUMA_INTERLEAVE_HIT
Andrea Arcangeli writes: > Hi, > > On Tue, Jul 31, 2012 at 09:12:06PM +0200, Peter Zijlstra wrote: >> Since the NUMA_INTERLEAVE_HIT statistic is useless on its own; it wants >> to be compared to either a total of interleave allocations or to a miss >> count, remove it. >> >> Fixing it would be possible, but since we've gone years without these >> statistics I figure we can continue that way. >> >> Also NUMA_HIT fully includes NUMA_INTERLEAVE_HIT so users might >> switch to using that. >> >> This cleans up some of the weird MPOL_INTERLEAVE allocation exceptions. > > It's not apparent why you need to remove it for sched-numa. I think I > see it but it'd be nicer if it would explained so one doesn't need to > read an internal bit of several patches later to understand why this > is needed. Also it still breaks the numactl test suite, as already explained multiple times. Without the HIT counter there is no way to check interleave actually happened. I'm a bit concerned about patch kits like this ignoring review feedback? -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Smack: remove task_wait() hook.
On 12/20/2011 11:20 PM, Jarkko Sakkinen wrote:
> Allow SIGCHLD to be passed to child process without
> explicit policy. This will help to keep the access
> control policy simple and easily maintainable with
> complex applications that require use of multiple
> security contexts. It will also help to keep them
> as isolated as possible.
>
> Signed-off-by: Jarkko Sakkinen
I have a slightly different version that applies to the
current smack-next tree.
Allow SIGCHLD to be passed to child process without
explicit policy. This will help to keep the access
control policy simple and easily maintainable with
complex applications that require use of multiple
security contexts. It will also help to keep them
as isolated as possible.
Signed-off-by: Casey Schaufler
security/smack/smack_lsm.c | 37 -
1 files changed, 8 insertions(+), 29 deletions(-)
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 8221514..ce9273a 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -1691,40 +1691,19 @@ static int smack_task_kill(struct task_struct *p,
struct siginfo *info,
* smack_task_wait - Smack access check for waiting
* @p: task to wait for
*
- * Returns 0 if current can wait for p, error code otherwise
+ * Returns 0
*/
static int smack_task_wait(struct task_struct *p)
{
- struct smk_audit_info ad;
- char *sp = smk_of_current();
- char *tsp = smk_of_forked(task_security(p));
- int rc;
-
- /* we don't log here, we can be overriden */
- rc = smk_access(tsp, sp, MAY_WRITE, NULL);
- if (rc == 0)
- goto out_log;
-
/*
-* Allow the operation to succeed if either task
-* has privilege to perform operations that might
-* account for the smack labels having gotten to
-* be different in the first place.
-*
-* This breaks the strict subject/object access
-* control ideal, taking the object's privilege
-* state into account in the decision as well as
-* the smack value.
+* Allow the operation to succeed.
+* Zombies are bad.
+* In userless environments (e.g. phones) programs
+* get marked with SMACK64EXEC and even if the parent
+* and child shouldn't be talking the parent still
+* may expect to know when the child exits.
*/
- if (smack_privileged(CAP_MAC_OVERRIDE) ||
- has_capability(p, CAP_MAC_OVERRIDE))
- rc = 0;
- /* we log only if we didn't get overriden */
- out_log:
- smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_TASK);
- smk_ad_setfield_u_tsk(&ad, p);
- smack_log(tsp, sp, MAY_WRITE, rc, &ad);
- return rc;
+ return 0;
}
/**
> ---
> security/smack/smack_lsm.c | 40
> 1 files changed, 0 insertions(+), 40 deletions(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 7db62b4..cc788f5 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -1685,45 +1685,6 @@ static int smack_task_kill(struct task_struct *p,
> struct siginfo *info,
> }
>
> /**
> - * smack_task_wait - Smack access check for waiting
> - * @p: task to wait for
> - *
> - * Returns 0 if current can wait for p, error code otherwise
> - */
> -static int smack_task_wait(struct task_struct *p)
> -{
> - struct smk_audit_info ad;
> - char *sp = smk_of_current();
> - char *tsp = smk_of_forked(task_security(p));
> - int rc;
> -
> - /* we don't log here, we can be overriden */
> - rc = smk_access(tsp, sp, MAY_WRITE, NULL);
> - if (rc == 0)
> - goto out_log;
> -
> - /*
> - * Allow the operation to succeed if either task
> - * has privilege to perform operations that might
> - * account for the smack labels having gotten to
> - * be different in the first place.
> - *
> - * This breaks the strict subject/object access
> - * control ideal, taking the object's privilege
> - * state into account in the decision as well as
> - * the smack value.
> - */
> - if (capable(CAP_MAC_OVERRIDE) || has_capability(p, CAP_MAC_OVERRIDE))
> - rc = 0;
> - /* we log only if we didn't get overriden */
> - out_log:
> - smk_ad_init(&ad, __func__, LSM_AUDIT_DATA_TASK);
> - smk_ad_setfield_u_tsk(&ad, p);
> - smack_log(tsp, sp, MAY_WRITE, rc, &ad);
> - return rc;
> -}
> -
> -/**
> * smack_task_to_inode - copy task smack into the inode blob
> * @p: task to copy from
> * @inode: inode to copy to
> @@ -3549,7 +3510,6 @@ struct security_operations smack_ops = {
> .task_getscheduler =smack_task_getscheduler,
> .task_movememory = smack_task_movememory,
> .task_kill =smack_task_kill,
> - .task_wait =smack_task_wait,
> .task_to_inode =
[PATCH] debugfs: make __create_file static
It's only used locally, no need to pollute global namespace.
Signed-off-by: Chris Wright
---
fs/debugfs/inode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 4733eab..2c9fafb 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -291,9 +291,9 @@ static struct file_system_type debug_fs_type = {
.kill_sb = kill_litter_super,
};
-struct dentry *__create_file(const char *name, umode_t mode,
- struct dentry *parent, void *data,
- const struct file_operations *fops)
+static struct dentry *__create_file(const char *name, umode_t mode,
+ struct dentry *parent, void *data,
+ const struct file_operations *fops)
{
struct dentry *dentry = NULL;
int error;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Fwd: [PATCH] x86/smp: Fix cpuN startup panic]
Peter,
What's your opinion about the patch? We hit it when enabling Medfield Android
mobile.
This patch would put AP to a loop.
Another method to fix it is just to enlarge the wait time, for example, from
2HZ to 10HZ.
Yanmin
Forwarded Message
> From: Chen, LinX Z
> To: linux-kernel@vger.kernel.org
> Cc: mi...@redhat.com, t...@linutronix.de, h...@zytor.com,
> yanmin_zh...@linux.intel.com
> Subject: [PATCH] x86/smp: Fix cpuN startup panic
> Date: Tue, 07 Aug 2012 18:50:40 +0900
>
> From: Lin Chen
>
> We hit a panic while doing cpu hotplug test.
> <0>[ 627.982857] Kernel panic - not syncing: smp_callin: CPU1 started up but
> did not get a callout!
> <0>[ 627.982864]
> <4>[ 627.982876] Pid: 0, comm: kworker/0:1 Tainted: G ...
> <4>[ 627.982883] Call Trace:
> <4>[ 627.982903] [] panic+0x66/0x16c
> <4>[ 627.982918] [] ? default_get_apic_id+0x1c/0x40
> <4>[ 627.982931] [] start_secondary+0xda/0x252
>
> During BSP bootup AP, it is possible that BSP be preempted before
> finishing STARTUP sequence of AP(set cpu_callout_mask) which maybe cause
> AP busy wait for it. At present, AP will wait for 2 seconds then panic.
>
> This patch let AP waits until BSP finish the startup sequence and gives
> WARNING when BSP is preempted more than 2 seconds.
>
> Signed-off-by: Yanmin Zhang
> Signed-off-by: Lin Chen
> ---
> arch/x86/kernel/smpboot.c | 11 ++-
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 7c5a8c3..a9e3379 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -165,19 +165,20 @@ static void __cpuinit smp_callin(void)
>* Waiting 2s total for startup (udelay is not yet working)
>*/
> timeout = jiffies + 2*HZ;
> - while (time_before(jiffies, timeout)) {
> + while (1) {
> /*
>* Has the boot CPU finished it's STARTUP sequence?
>*/
> if (cpumask_test_cpu(cpuid, cpu_callout_mask))
> break;
> cpu_relax();
> + if (!time_before(jiffies, timeout)) {
> + WARN(1, "%s: CPU%d started up but did not get a
> callout!\n",
> + __func__, cpuid);
> + timeout = jiffies + 2*HZ;
> + }
> }
>
> - if (!time_before(jiffies, timeout)) {
> - panic("%s: CPU%d started up but did not get a callout!\n",
> - __func__, cpuid);
> - }
>
> /*
>* the boot CPU has finished the init stage and is spinning
> --
> 1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] net: add new QCA alx ethernet driver
> The alterations to the description of atl1c ought to be broken out as a > separate patch, though. > Yes, we will separate it. thanks ! -Xiong
Re: BUG: RDMA/ocrdma calls invalid vlan_dev_real_dev()
On Thu, Aug 09, 2012 at 04:54:37PM -0700, Roland Dreier wrote:
> thanks for the report. I assume the system doesn't actually have ocrdma hw?
Yeah, it's a test boot inside KVM.
Thanks,
Fengguang
> - R.
> On Aug 9, 2012 3:00 AM, "Fengguang Wu" wrote:
>
> > Hi Parav,
> >
> > commit fe2caefcdf ("RDMA/ocrdma: Add driver for Emulex OneConnect IBoE
> > RDMA adapter") triggers the below kernel BUG for the attached config.
> >
> > [ 280.861196] kernel BUG at
> > /c/kernel-tests/src/stable/include/linux/if_vlan.h:113!
> > [ 280.861196] invalid opcode: [#1] PREEMPT
> > [ 280.861196] CPU 0
> > [ 280.861196] Pid: 304, comm: ip Not tainted 3.6.0-rc1 #1 Bochs Bochs
> > [ 280.861196] RIP: 0010:[] []
> > ocrdma_inet6addr_event+0x4/0x6
> > [ 280.861196] RSP: 0018:8800066a1548 EFLAGS: 0202
> > [ 280.861196] RAX: 0001 RBX: RCX:
> >
> > [ 280.861196] RDX: 880006b6b400 RSI: 0001 RDI:
> > 8207ecc0
> > [ 280.861196] RBP: 8800066a1548 R08: R09:
> > 8109b657
> > [ 280.861196] R10: R11: 81e0f318 R12:
> >
> > [ 280.861196] R13: 8207ecc0 R14: R15:
> >
> > [ 280.861196] FS: 7f025c12f700() GS:81dfb000()
> > knlGS:
> > [ 280.861196] CS: 0010 DS: ES: CR0: 8005003b
> > [ 280.861196] CR2: 7fe4e1d3 CR3: 06b65000 CR4:
> > 06b0
> > [ 280.861196] DR0: DR1: DR2:
> >
> > [ 280.861196] DR3: DR6: DR7:
> >
> > [ 280.861196] Process ip (pid: 304, threadinfo 8800066a, task
> > 880006a7c2c0)
> > [ 280.861196] Stack:
> > [ 280.861196] 8800066a1598 8109b5a2 880006b6b400
> > 0001
> > [ 280.861196] 8800066a1598 0001 880006b6b400
> >
> > [ 280.861196] 820ad9b0 8800066a15f8
> > 8109b6b7
> > [ 280.861196] Call Trace:
> > [ 280.861196] [] notifier_call_chain+0x60/0x90
> > [ 280.861196] [] __atomic_notifier_call_chain+0x60/0x92
> > [ 280.861196] [] ?
> > atomic_notifier_chain_unregister+0x46/0x46
> > [ 280.861196] [] atomic_notifier_call_chain+0xf/0x11
> > [ 280.861196] [] ipv6_add_addr+0x333/0x388
> > [ 280.861196] [] ? ipv6_add_addr+0x55/0x388
> > [ 280.861196] [] add_addr+0x12/0x5c
> > [ 280.861196] [] init_loopback+0x7b/0x7f
> > [ 280.861196] [] addrconf_notify+0x178/0x2d4
> > [ 280.861196] [] notifier_call_chain+0x60/0x90
> > [ 280.861196] [] __raw_notifier_call_chain+0x9/0xb
> > [ 280.861196] [] raw_notifier_call_chain+0xf/0x11
> > [ 280.861196] [] call_netdevice_notifiers+0x45/0x4a
> > [ 280.861196] [] __dev_notify_flags+0x32/0x56
> > [ 280.861196] [] dev_change_flags+0x43/0x4e
> > [ 280.861196] [] do_setlink+0x2da/0x7f6
> > [ 280.861196] [] ? native_sched_clock+0x38/0x68
> > [ 280.861196] [] ? sched_clock+0x9/0xd
> > [ 280.861196] [] ?
> > sched_clock_local.constprop.2+0xd/0x78
> > [ 280.861196] [] ? sched_clock_cpu+0x7b/0x89
> > [ 280.861196] [] rtnl_newlink+0x264/0x438
> > [ 280.861196] [] ? rtnl_newlink+0xba/0x438
> > [ 280.861196] [] ? avc_has_perm_noaudit+0xd1/0xe3
> > [ 280.861196] [] ? avc_has_perm_noaudit+0x22/0xe3
> > [ 280.861196] [] rtnetlink_rcv_msg+0x22c/0x23b
> > [ 280.861196] [] ? rtnl_lock+0x12/0x14
> > [ 280.861196] [] ? __rtnl_unlock+0x12/0x12
> > [ 280.861196] [] netlink_rcv_skb+0x3d/0x8a
> > [ 280.861196] [] rtnetlink_rcv+0x21/0x28
> > [ 280.861196] [] netlink_unicast+0x12c/0x1b8
> > [ 280.861196] [] netlink_sendmsg+0x212/0x29a
> > [ 280.861196] [] sock_sendmsg+0x9e/0xbf
> > [ 280.861196] [] __sys_sendmsg+0x248/0x2d5
> > [ 280.861196] [] ? _raw_spin_unlock_irq+0x34/0x50
> > [ 280.861196] [] ?
> > finish_task_switch.constprop.48+0x72/0xd9
> > [ 280.861196] [] ?
> > finish_task_switch.constprop.48+0x34/0xd9
> > [ 280.861196] [] ? __schedule+0x501/0x607
> > [ 280.861196] [] ? put_lock_stats.isra.17+0xe/0x28
> > [ 280.861196] [] ? lock_release_holdtime+0xcd/0xd5
> > [ 280.861196] [] sys_sendmsg+0x3d/0x5e
> > [ 280.861196] [] system_call_fastpath+0x16/0x1b
> > [ 280.861196] Code: 00 00 ad de 48 89 93 a8 0b 00 00 e8 c9 2f 2e 00 48 8d
> > bb b0 0b 00 00 48 c7 c6 86 f0 6d 81 e8 b0 b2 9e ff 59 5b 5d c3 55 48 89 e5
> > <0f> 0b 55 48 89 e5 41 54 53 48 89 fb 48 8b bf a0 fc ff ff 4c 8d
> > [ 280.861196] RIP [] ocrdma_inet6addr_event+0x4/0x6
> > [ 280.861196] RSP
> >
> > Thanks,
> > Fengguang
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [trivial] infiniband: Fix typo in infiniband driver
Thanks for the review. I just posted version 2. Masanari On Fri, Aug 10, 2012 at 8:51 AM, Hefty, Sean wrote: >> diff --git a/drivers/infiniband/hw/amso1100/c2_rnic.c >> b/drivers/infiniband/hw/amso1100/c2_rnic.c >> index 8c81992..b80867e 100644 >> --- a/drivers/infiniband/hw/amso1100/c2_rnic.c >> +++ b/drivers/infiniband/hw/amso1100/c2_rnic.c >> @@ -439,7 +439,7 @@ static int c2_rnic_close(struct c2_dev *c2dev) >> >> /* >> * Called by c2_probe to initialize the RNIC. This principally >> - * involves initalizing the various limits and resouce pools that >> + * involves initalizing the various limits and resource pools that > > while we're here, can we fix initializing too? thanks > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH/v2] [trivial] infiniband: Fix typo in infiniband driver
Correct spelling typo in infiniband/hw and infiniband/ulp
Signed-off-by: Masanari Iida
---
drivers/infiniband/hw/amso1100/c2_rnic.c | 2 +-
drivers/infiniband/hw/cxgb3/iwch_cm.c| 2 +-
drivers/infiniband/hw/qib/qib_sd7220.c | 2 +-
drivers/infiniband/ulp/srpt/ib_srpt.c| 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/amso1100/c2_rnic.c
b/drivers/infiniband/hw/amso1100/c2_rnic.c
index 8c81992..b80867e 100644
--- a/drivers/infiniband/hw/amso1100/c2_rnic.c
+++ b/drivers/infiniband/hw/amso1100/c2_rnic.c
@@ -439,7 +439,7 @@ static int c2_rnic_close(struct c2_dev *c2dev)
/*
* Called by c2_probe to initialize the RNIC. This principally
- * involves initalizing the various limits and resouce pools that
+ * involves initializing the various limits and resource pools that
* comprise the RNIC instance.
*/
int __devinit c2_rnic_init(struct c2_dev *c2dev)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c
b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index 77b6b18..aaf88ef9 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -1680,7 +1680,7 @@ static int close_con_rpl(struct t3cdev *tdev, struct
sk_buff *skb, void *ctx)
* T3A does 3 things when a TERM is received:
* 1) send up a CPL_RDMA_TERMINATE message with the TERM packet
* 2) generate an async event on the QP with the TERMINATE opcode
- * 3) post a TERMINATE opcde cqe into the associated CQ.
+ * 3) post a TERMINATE opcode cqe into the associated CQ.
*
* For (1), we save the message in the qp for later consumer consumption.
* For (2), we move the QP into TERMINATE, post a QP event and disconnect.
diff --git a/drivers/infiniband/hw/qib/qib_sd7220.c
b/drivers/infiniband/hw/qib/qib_sd7220.c
index a322d51..50a8a0d 100644
--- a/drivers/infiniband/hw/qib/qib_sd7220.c
+++ b/drivers/infiniband/hw/qib/qib_sd7220.c
@@ -372,7 +372,7 @@ static void qib_sd_trimdone_monitor(struct qib_devdata *dd,
/* Read CTRL reg for each channel to check TRIMDONE */
if (baduns & (1 << chn)) {
qib_dev_err(dd,
- "Reseting TRIMDONE on chn %d (%s)\n",
+ "Resetting TRIMDONE on chn %d (%s)\n",
chn, where);
ret = qib_sd7220_reg_mod(dd, IB_7220_SERDES,
IB_CTRL2(chn), 0x10, 0x10);
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c
b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 7a0ce8d..9e1449f 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -1469,7 +1469,7 @@ static void srpt_handle_send_comp(struct srpt_rdma_ch *ch,
*
* XXX: what is now target_execute_cmd used to be asynchronous, and unmapping
* the data that has been transferred via IB RDMA had to be postponed until the
- * check_stop_free() callback. None of this is nessecary anymore and needs to
+ * check_stop_free() callback. None of this is necessary anymore and needs to
* be cleaned up.
*/
static void srpt_handle_rdma_comp(struct srpt_rdma_ch *ch,
--
1.7.12.rc2.9.ge5acacf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: "Inconsistent kallsyms data" error
On Saturday 2012-07-07 23:40, Michal Marek wrote:
>index cd9c6c6..4629038 100644
>--- a/scripts/link-vmlinux.sh
>+++ b/scripts/link-vmlinux.sh
>@@ -210,8 +210,8 @@ if [ -n "${CONFIG_KALLSYMS}" ]; then
> mksysmap ${kallsyms_vmlinux} .tmp_System.map
>
> if ! cmp -s System.map .tmp_System.map; then
>- echo Inconsistent kallsyms data
>- echo echo Try "make KALLSYMS_EXTRA_PASS=1" as a workaround
>+ echo >&2 Inconsistent kallsyms data
>+ echo >&2 echo Try "make KALLSYMS_EXTRA_PASS=1" as a workaround
Hm why is there echo twice in that one line? Seems like an oversight..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ipv4: tcp: unicast_sock should not land outside of TCP stack
From: Eric Dumazet commit be9f4a44e7d41cee (ipv4: tcp: remove per net tcp_sock) added a selinux regression, reported and bisected by John Stultz selinux_ip_postroute_compat() expect to find a valid sk->sk_security pointer, but this field is NULL for unicast_sock It turns out that unicast_sock are really temporary stuff to be able to reuse part of IP stack (ip_append_data()/ip_push_pending_frames()) Fact is that frames sent by ip_send_unicast_reply() should be orphaned to not fool LSM. Note IPv6 never had this problem, as tcp_v6_send_response() doesnt use a fake socket at all. I'll probably implement tcp_v4_send_response() to remove these unicast_sock in linux-3.7 Reported-by: John Stultz Bisected-by: John Stultz Signed-off-by: Eric Dumazet Cc: Paul Moore Cc: Eric Paris Cc: "Serge E. Hallyn" --- net/ipv4/ip_output.c |1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index 76dde25..ec410e0 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -1536,6 +1536,7 @@ void ip_send_unicast_reply(struct net *net, struct sk_buff *skb, __be32 daddr, arg->csumoffset) = csum_fold(csum_add(nskb->csum, arg->csum)); nskb->ip_summed = CHECKSUM_NONE; + skb_orphan(nskb); skb_set_queue_mapping(nskb, skb_get_queue_mapping(skb)); ip_push_pending_frames(sk, &fl4); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] tracepoints: Move the work out of line from hotpath sections
On 08/09/2012 04:16 PM, H. Peter Anvin wrote: On 08/09/2012 03:25 PM, Steven Rostedt wrote: It might be better to improve gcc to move really cold branches out of line (really, really far away), and use the compiler to do this, rather than to use an extra indirection that adds bloat and complexity to the kernel. Oh, you mean like: -freorder-blocks-and-partition I think modifying gcc is something that can help more than tracing. But that's been a pipe dream for such a long time that I've started dreaming about winning a gold medal in the Olympics instead. Standing on the podium listening to the crowd chanting your name along with your country is more fun to dream about than seeing your unlikely code stop becoming hurdles for the CPU sprinters. At one point, maybe, but lately we have had a lot more traction from the gcc developers, giving us features like __fentry__ and asm goto. I don't claim that -freorder-blocks-and-partition is bug free, but I imagine that the GCC developers would be open to fixing any bugs found. David Daney -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
