Re: [PATCH 01/44] kernel: Add support for poweroff handler call chain
Hello
This seems exactly what I would need on the mc13783 to handle cleanly
the poweroff,
but after reading this patchset I have the following question:
[...]
+/*
+ * Notifier list for kernel code which wants to be called
+ * to power off the system.
+ */
+static ATOMIC_NOTIFIER_HEAD(poweroff_handler_list);
[...]
+void do_kernel_poweroff(void)
+{
+ atomic_notifier_call_chain(&poweroff_handler_list, 0, NULL);
+}
+
It seems that the poweroff callback needs to be atomic as per
_atomic_notifier_call_chain documentation:
"Calls each function in a notifier chain in turn. The functions
run in an atomic context"
But this is a problem for many MFD (mc13783, twl4030 etc ...) which are
accessible on only a blocking bus (SPI, I2C).
What I am missing here ?
Thanks,
Philippe
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 18/44] mfd: twl4030-power: Register with kernel poweroff handler
On Mon, 06 Oct 2014, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly. Register with a low priority value of 64 to reflect that
> the original code only sets pm_power_off if it was not already set.
>
> Make twl4030_power_off static as it is only called from the twl4030-power
> driver.
>
> Cc: Samuel Ortiz
> Cc: Lee Jones
> Signed-off-by: Guenter Roeck
> ---
> drivers/mfd/twl4030-power.c | 25 +
> include/linux/i2c/twl.h | 1 -
> 2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
> index 4d3ff37..bd6b830 100644
> --- a/drivers/mfd/twl4030-power.c
> +++ b/drivers/mfd/twl4030-power.c
> @@ -25,9 +25,10 @@
> */
>
> #include
> -#include
> +#include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -611,7 +612,8 @@ twl4030_power_configure_resources(const struct
> twl4030_power_data *pdata)
> * After a successful execution, TWL shuts down the power to the SoC
> * and all peripherals connected to it.
> */
> -void twl4030_power_off(void)
> +static int twl4030_power_off(struct notifier_block *this, unsigned long
> unused1,
> + void *unused2)
> {
> int err;
>
> @@ -619,8 +621,15 @@ void twl4030_power_off(void)
> TWL4030_PM_MASTER_P1_SW_EVENTS);
> if (err)
> pr_err("TWL4030 Unable to power off\n");
> +
> + return NOTIFY_DONE;
> }
>
> +static struct notifier_block twl4030_poweroff_nb = {
> + .notifier_call = twl4030_power_off,
> + .priority = 64,
64 out of what? How is this calculated? Wouldn't it be better to
define these?
> +};
> +
> static bool twl4030_power_use_poweroff(const struct twl4030_power_data
> *pdata,
> struct device_node *node)
> {
> @@ -836,7 +845,7 @@ static int twl4030_power_probe(struct platform_device
> *pdev)
> }
>
> /* Board has to be wired properly to use this feature */
> - if (twl4030_power_use_poweroff(pdata, node) && !pm_power_off) {
> + if (twl4030_power_use_poweroff(pdata, node)) {
> /* Default for SEQ_OFFSYNC is set, lets ensure this */
> err = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, &val,
> TWL4030_PM_MASTER_CFG_P123_TRANSITION);
> @@ -853,7 +862,13 @@ static int twl4030_power_probe(struct platform_device
> *pdev)
> }
> }
>
> - pm_power_off = twl4030_power_off;
> + err = register_poweroff_handler(&twl4030_poweroff_nb);
> + if (err) {
> + dev_err(&pdev->dev,
> + "Failed to register poweroff handler\n");
If this is not fatal, you should issue a dev_warn() instead.
> + /* Not a fatal error */
> + err = 0;
How about using your own variable for this? Then you don't have to
worry about resetting it.
> + }
> }
>
> relock:
> @@ -869,6 +884,8 @@ relock:
>
> static int twl4030_power_remove(struct platform_device *pdev)
> {
> + unregister_poweroff_handler(&twl4030_poweroff_nb);
Perhaps a naive question, but is there any way you can do this using
devres (devm_* managed resources)?
> return 0;
> }
>
> diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
> index 8cfb50f..f8544f1 100644
> --- a/include/linux/i2c/twl.h
> +++ b/include/linux/i2c/twl.h
> @@ -680,7 +680,6 @@ struct twl4030_power_data {
> };
>
> extern int twl4030_remove_script(u8 flags);
> -extern void twl4030_power_off(void);
>
> struct twl4030_codec_data {
> unsigned int digimic_delay; /* in ms */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 12/44] mfd: ab8500-sysctrl: Register with kernel poweroff handler
On Mon, 06 Oct 2014, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly. Register with a low priority value of 64 to reflect that
> the original code only sets pm_power_off if it was not already set.
>
> Cc: Linus Walleij
> Cc: Lee Jones
> Cc: Samuel Ortiz
> Signed-off-by: Guenter Roeck
> ---
> drivers/mfd/ab8500-sysctrl.c | 26 +++---
> 1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mfd/ab8500-sysctrl.c b/drivers/mfd/ab8500-sysctrl.c
> index 8e0dae5..677438f 100644
> --- a/drivers/mfd/ab8500-sysctrl.c
> +++ b/drivers/mfd/ab8500-sysctrl.c
> @@ -6,6 +6,7 @@
[...]
> +static int ab8500_power_off(struct notifier_block *this, unsigned long
> unused1,
> + void *unused2)
> {
> sigset_t old;
> sigset_t all;
> @@ -34,11 +36,6 @@ static void ab8500_power_off(void)
> struct power_supply *psy;
> int ret;
>
> - if (sysctrl_dev == NULL) {
> - pr_err("%s: sysctrl not initialized\n", __func__);
> - return;
> - }
Can you explain the purpose of this change please?
> /*
>* If we have a charger connected and we're powering off,
>* reboot into charge-only mode.
> @@ -83,8 +80,15 @@ shutdown:
>AB8500_STW4500CTRL1_SWRESET4500N);
> (void)sigprocmask(SIG_SETMASK, &old, NULL);
> }
> +
> + return NOTIFY_DONE;
> }
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 31/44] arm: Register with kernel poweroff handler
On 07/10/2014 07:28, Guenter Roeck :
> Register with kernel poweroff handler instead of setting pm_power_off
> directly. Always use register_poweroff_handler_simple as there is no
> indication that more than one poweroff handler is registered.
>
> If the poweroff handler only resets the system or puts the CPU in sleep mode,
> select a priority of 0 to indicate that the poweroff handler is one of last
> resort. If the poweroff handler powers off the system, select a priority
> of 128.
>
> Cc: Russell King
> Cc: Andrew Victor
> Cc: Nicolas Ferre
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Stephen Warren
> Cc: Christian Daudt
> Cc: Matt Porter
> Cc: Anton Vorontsov
> Cc: Rob Herring
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Imre Kaloz
> Cc: Krzysztof Halasa
> Cc: Tony Lindgren
> Cc: Jason Cooper
> Cc: Andrew Lunn
> Cc: Sebastian Hesselbarth
> Cc: Eric Miao
> Cc: Haojian Zhuang
> Cc: Robert Jarzmik
> Cc: Marek Vasut
> Cc: Ben Dooks
> Cc: Kukjin Kim
> Cc: Linus Walleij
> Cc: Tony Prisk
> Cc: Stefano Stabellini
> Signed-off-by: Guenter Roeck
> ---
> arch/arm/kernel/psci.c | 2 +-
> arch/arm/mach-at91/board-gsia18s.c | 2 +-
> arch/arm/mach-at91/setup.c | 4 ++--
For the 2 files above: NAK just because:
for the first one -> this file will be removed during 3.19 dev cycle.
for the second one -> the poweroff handlers are removed during the 3.18
cycle and converted in the appropriate poweroff drivers (in
drivers/power/reset/at91-poweroff.c).
So, can you remove these changes from your patch?
Thanks for your work, bye.
> arch/arm/mach-bcm/board_bcm2835.c | 2 +-
> arch/arm/mach-cns3xxx/cns3420vb.c | 2 +-
> arch/arm/mach-cns3xxx/core.c | 2 +-
> arch/arm/mach-highbank/highbank.c | 2 +-
> arch/arm/mach-imx/mach-mx31moboard.c | 2 +-
> arch/arm/mach-iop32x/em7210.c | 2 +-
> arch/arm/mach-iop32x/glantank.c| 2 +-
> arch/arm/mach-iop32x/iq31244.c | 2 +-
> arch/arm/mach-iop32x/n2100.c | 2 +-
> arch/arm/mach-ixp4xx/dsmg600-setup.c | 2 +-
> arch/arm/mach-ixp4xx/nas100d-setup.c | 2 +-
> arch/arm/mach-ixp4xx/nslu2-setup.c | 2 +-
> arch/arm/mach-omap2/board-omap3touchbook.c | 2 +-
> arch/arm/mach-orion5x/board-mss2.c | 2 +-
> arch/arm/mach-orion5x/dns323-setup.c | 6 +++---
> arch/arm/mach-orion5x/kurobox_pro-setup.c | 2 +-
> arch/arm/mach-orion5x/ls-chl-setup.c | 2 +-
> arch/arm/mach-orion5x/ls_hgl-setup.c | 2 +-
> arch/arm/mach-orion5x/lsmini-setup.c | 2 +-
> arch/arm/mach-orion5x/mv2120-setup.c | 2 +-
> arch/arm/mach-orion5x/net2big-setup.c | 2 +-
> arch/arm/mach-orion5x/terastation_pro2-setup.c | 2 +-
> arch/arm/mach-orion5x/ts209-setup.c| 2 +-
> arch/arm/mach-orion5x/ts409-setup.c| 2 +-
> arch/arm/mach-pxa/corgi.c | 2 +-
> arch/arm/mach-pxa/mioa701.c| 2 +-
> arch/arm/mach-pxa/poodle.c | 2 +-
> arch/arm/mach-pxa/spitz.c | 2 +-
> arch/arm/mach-pxa/tosa.c | 2 +-
> arch/arm/mach-pxa/viper.c | 2 +-
> arch/arm/mach-pxa/z2.c | 6 +++---
> arch/arm/mach-pxa/zeus.c | 6 +++---
> arch/arm/mach-s3c24xx/mach-gta02.c | 2 +-
> arch/arm/mach-s3c24xx/mach-jive.c | 2 +-
> arch/arm/mach-s3c24xx/mach-vr1000.c| 2 +-
> arch/arm/mach-s3c64xx/mach-smartq.c| 2 +-
> arch/arm/mach-sa1100/generic.c | 2 +-
> arch/arm/mach-sa1100/simpad.c | 2 +-
> arch/arm/mach-u300/regulator.c | 2 +-
> arch/arm/mach-vt8500/vt8500.c | 2 +-
> arch/arm/xen/enlighten.c | 2 +-
> 44 files changed, 51 insertions(+), 51 deletions(-)
>
> diff --git a/arch/arm/kernel/psci.c b/arch/arm/kernel/psci.c
> index f73891b..dd58d86 100644
> --- a/arch/arm/kernel/psci.c
> +++ b/arch/arm/kernel/psci.c
> @@ -264,7 +264,7 @@ static int psci_0_2_init(struct device_node *np)
>
> arm_pm_restart = psci_sys_reset;
>
> - pm_power_off = psci_sys_poweroff;
> + register_poweroff_handler_simple(psci_sys_poweroff, 128);
>
> out_put_node:
> of_node_put(np);
> diff --git a/arch/arm/mach-at91/board-gsia18s.c
> b/arch/arm/mach-at91/board-gsia18s.c
> index b729dd1..6722e66 100644
> --- a/arch/arm/mach-at91/board-gsia18s.c
> +++ b/arch/arm/mach-at91/board-gsia18s.c
> @@ -521,7 +521,7 @@ static void gsia18s_power_off(void)
>
> static int __init gsia18s_power_off_init(void)
> {
> - pm_power_off = gsia18s_power_off;
> + register_poweroff_handler_simple(gsia18s_power_off, 128);
> return 0;
> }
>
> diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
> inde
[PATCH] staging: lustre: fix sparse errors
Mark functions static that are not used or declared outside of lo.c.
Signed-off-by: Thomas Gummerer
---
drivers/staging/lustre/lnet/lnet/lo.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/lustre/lnet/lnet/lo.c
b/drivers/staging/lustre/lnet/lnet/lo.c
index be31dfc..17e1643 100644
--- a/drivers/staging/lustre/lnet/lnet/lo.c
+++ b/drivers/staging/lustre/lnet/lnet/lo.c
@@ -35,7 +35,7 @@
#define DEBUG_SUBSYSTEM S_LNET
#include "../../include/linux/lnet/lib-lnet.h"
-int
+static int
lolnd_send(lnet_ni_t *ni, void *private, lnet_msg_t *lntmsg)
{
LASSERT(!lntmsg->msg_routing);
@@ -44,7 +44,7 @@ lolnd_send(lnet_ni_t *ni, void *private, lnet_msg_t *lntmsg)
return lnet_parse(ni, &lntmsg->msg_hdr, ni->ni_nid, lntmsg, 0);
}
-int
+static int
lolnd_recv(lnet_ni_t *ni, void *private, lnet_msg_t *lntmsg,
int delayed, unsigned int niov,
struct iovec *iov, lnet_kiov_t *kiov,
@@ -86,7 +86,7 @@ lolnd_recv(lnet_ni_t *ni, void *private, lnet_msg_t *lntmsg,
static int lolnd_instanced;
-void
+static void
lolnd_shutdown(lnet_ni_t *ni)
{
CDEBUG(D_NET, "shutdown\n");
@@ -95,7 +95,7 @@ lolnd_shutdown(lnet_ni_t *ni)
lolnd_instanced = 0;
}
-int
+static int
lolnd_startup(lnet_ni_t *ni)
{
LASSERT(ni->ni_lnd == &the_lolnd);
--
2.1.0.GIT
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
各种定价模＠式的砍价策3略
y各种定价模＠式的砍价策3略.xls Description: Binary data ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 04/44] m68k: Replace mach_power_off with pm_power_off
On Tue, Oct 7, 2014 at 7:28 AM, Guenter Roeck wrote:
> Replace mach_power_off with pm_power_off to simplify the subsequent
> move of pm_power_off to generic code.
Thanks!
> Cc: Geert Uytterhoeven
> Cc: Greg Ungerer
> Cc: Joshua Thompson
> Signed-off-by: Guenter Roeck
Looks OK, so since you said it builds ;-)
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 08/44] kernel: Move pm_power_off to common code
On Tue, Oct 7, 2014 at 7:28 AM, Guenter Roeck wrote:
> pm_power_off is defined for all architectures. Move it to common code.
>
> Have all architectures call do_kernel_poweroff instead of pm_power_off.
> Some architectures point pm_power_off to machine_power_off. For those,
> call do_kernel_poweroff from machine_power_off instead.
> arch/m68k/kernel/process.c | 6 +-
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 35/44] m68k: Register with kernel poweroff handler
On Tue, Oct 7, 2014 at 7:28 AM, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly.
>
> Cc: Geert Uytterhoeven
> Cc: Joshua Thompson
> Signed-off-by: Guenter Roeck
As someone already mentioned, having #defines instead of hardcoded
numbers for the priorities would be nice.
Apart from that:
Acked-by: Geert Uytterhoeven
> + register_poweroff_handler_simple(nf_poweroff, 128);
> + register_poweroff_handler_simple(mac_poweroff, 128);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: coding style fixup
checkpatch.pk tiny fix
get rid of 2 warnings and 2 errors for hal/fw.c
Signed-off-by: Igor Bogomazov
Cc: Greg Kroah-Hartman
Cc: navin patidar
Cc: Stephen Rothwell
---
linux-next 3.17.0
diff --git a/drivers/staging/rtl8188eu/hal/fw.c
b/drivers/staging/rtl8188eu/hal/fw.c
index 17b7f37..c4293df 100644
--- a/drivers/staging/rtl8188eu/hal/fw.c
+++ b/drivers/staging/rtl8188eu/hal/fw.c
@@ -154,9 +154,8 @@ static int _rtl88e_fw_free_to_go(struct adapter *adapt)
break;
} while (counter++ < POLLING_READY_TIMEOUT_COUNT);
- if (counter >= POLLING_READY_TIMEOUT_COUNT) {
+ if (counter >= POLLING_READY_TIMEOUT_COUNT)
goto exit;
- }
value32 = usb_read32(adapt, REG_MCUFWDL);
value32 |= MCUFWDL_RDY;
@@ -193,13 +192,13 @@ int rtl88eu_download_fw(struct adapter *adapt)
u32 fwsize;
int err;
- if (request_firmware(&fw, fw_name, device)){
+ if (request_firmware(&fw, fw_name, device)) {
dev_err(device, "Firmware %s not available\n", fw_name);
return -ENOENT;
}
if (fw->size > FW_8188E_SIZE) {
- dev_err(device,"Firmware size exceed 0x%X. Check it.\n",
+ dev_err(device, "Firmware size exceed 0x%X. Check it.\n",
FW_8188E_SIZE);
return -1;
}
@@ -226,7 +225,8 @@ int rtl88eu_download_fw(struct adapter *adapt)
rtl88e_firmware_selfreset(adapt);
}
_rtl88e_enable_fw_download(adapt, true);
- usb_write8(adapt, REG_MCUFWDL, usb_read8(adapt, REG_MCUFWDL) |
FWDL_ChkSum_rpt);
+ usb_write8(adapt, REG_MCUFWDL,
+ usb_read8(adapt, REG_MCUFWDL) | FWDL_ChkSum_rpt);
_rtl88e_write_fw(adapt, pfwdata, fwsize);
_rtl88e_enable_fw_download(adapt, false);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 06/44] gpio-poweroff: Drop reference to pm_power_off from devicetree bindings
On Tue, Oct 07, 2014 at 06:28:08AM +0100, Guenter Roeck wrote: > pm_power_off is an implementation detail. Replace it with a more generic > description of the driver's functionality. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland Acked-by: Mark Rutland > Signed-off-by: Guenter Roeck > --- > Documentation/devicetree/bindings/gpio/gpio-poweroff.txt | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > index d4eab92..c95a1a6 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > @@ -2,12 +2,12 @@ Driver a GPIO line that can be used to turn the power off. > > The driver supports both level triggered and edge triggered power off. > At driver load time, the driver will request the given gpio line and > -install a pm_power_off handler. If the optional properties 'input' is > -not found, the GPIO line will be driven in the inactive > +install a handler to power off the system. If the optional properties > +'input' is not found, the GPIO line will be driven in the inactive > state. Otherwise its configured as an input. > > -When the pm_power_off is called, the gpio is configured as an output, > -and drive active, so triggering a level triggered power off > +When the the poweroff handler is called, the gpio is configured as an > +output, and drive active, so triggering a level triggered power off > condition. This will also cause an inactive->active edge condition, so > triggering positive edge triggered power off. After a delay of 100ms, > the GPIO is set to inactive, thus causing an active->inactive edge, > @@ -24,7 +24,7 @@ Required properties: > > Optional properties: > - input : Initially configure the GPIO line as an input. Only reconfigure > - it to an output when the pm_power_off function is called. If this optional > + it to an output when the poweroff handler is called. If this optional >property is not specified, the GPIO is initialized as an output in its >inactive state. > > -- > 1.9.1 > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
On Tue, Oct 07, 2014 at 06:28:07AM +0100, Guenter Roeck wrote: > Devicetree bindings are supposed to be operating system independent > and should thus not describe how a specific functionality is implemented > in Linux. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Signed-off-by: Guenter Roeck > --- > Documentation/devicetree/bindings/mfd/as3722.txt | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Thanks for the fix-up! Acked-by: Mark Rutland Mark. > > diff --git a/Documentation/devicetree/bindings/mfd/as3722.txt > b/Documentation/devicetree/bindings/mfd/as3722.txt > index 4f64b2a..0b2a609 100644 > --- a/Documentation/devicetree/bindings/mfd/as3722.txt > +++ b/Documentation/devicetree/bindings/mfd/as3722.txt > @@ -122,8 +122,7 @@ Following are properties of regulator subnode. > > Power-off: > = > -AS3722 supports the system power off by turning off all its rail. This > -is provided through pm_power_off. > +AS3722 supports the system power off by turning off all its rails. > The device node should have the following properties to enable this > functionality > ams,system-power-controller: Boolean, to enable the power off functionality > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/44] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings
On Tue, Oct 07, 2014 at 06:28:09AM +0100, Guenter Roeck wrote: > Replace reference to pm_power_off (which is an implementation detail) > and replace it with a more generic description of the driver's functionality. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Signed-off-by: Guenter Roeck > --- > Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > index af25e77..1e2260a 100644 > --- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > +++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > @@ -3,8 +3,8 @@ > QNAP NAS devices have a microcontroller controlling the main power > supply. This microcontroller is connected to UART1 of the Kirkwood and > Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the > -microcontroller to turn the power off. This driver adds a handler to > -pm_power_off which is called to turn the power off. > +microcontroller to turn the power off. This driver installs a handler > +to power off the system. I'd remove the last sentence -- the driver is also independent of the HW, and the description of how the power off works at the HW level is sufficient. With that: Acked-by: Mark Rutland Thanks, Mark. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: octeon-usb: fix checkpatch.pl warnings
fixed several 'line over 80 characters' in places where it can be done
without changing/refactoring code
Signed-off-by: Aleh Suprunovich
---
drivers/staging/octeon-usb/octeon-hcd.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/octeon-usb/octeon-hcd.c
b/drivers/staging/octeon-usb/octeon-hcd.c
index 5f9db4c..69add7b 100644
--- a/drivers/staging/octeon-usb/octeon-hcd.c
+++ b/drivers/staging/octeon-usb/octeon-hcd.c
@@ -1328,7 +1328,8 @@ static void __cvmx_usb_poll_rx_fifo(struct cvmx_usb_state
*usb)
/* Loop writing the FIFO data for this packet into memory */
while (bytes > 0) {
- *ptr++ = __cvmx_usb_read_csr32(usb, USB_FIFO_ADDRESS(channel,
usb->index));
+ *ptr++ = __cvmx_usb_read_csr32(usb,
+ USB_FIFO_ADDRESS(channel, usb->index));
bytes -= 4;
}
CVMX_SYNCW;
@@ -1479,7 +1480,8 @@ static void __cvmx_usb_fill_tx_fifo(struct cvmx_usb_state
*usb, int channel)
fifo = &usb->nonperiodic;
fifo->entry[fifo->head].channel = channel;
- fifo->entry[fifo->head].address = __cvmx_usb_read_csr64(usb,
CVMX_USBNX_DMA0_OUTB_CHN0(usb->index) + channel*8);
+ fifo->entry[fifo->head].address = __cvmx_usb_read_csr64(usb,
+ CVMX_USBNX_DMA0_OUTB_CHN0(usb->index) + channel*8);
fifo->entry[fifo->head].size = (usbc_hctsiz.s.xfersize+3)>>2;
fifo->head++;
if (fifo->head > MAX_CHANNELS)
@@ -1700,7 +1702,9 @@ static void __cvmx_usb_start_channel(struct
cvmx_usb_state *usb,
usbc_hcintmsk.s.stallmsk = 1;
usbc_hcintmsk.s.xfercomplmsk = 1;
}
- __cvmx_usb_write_csr32(usb, CVMX_USBCX_HCINTMSKX(channel,
usb->index), usbc_hcintmsk.u32);
+ __cvmx_usb_write_csr32(usb,
+ CVMX_USBCX_HCINTMSKX(channel, usb->index),
+ usbc_hcintmsk.u32);
/* Enable the channel interrupt to propagate */
usbc_haintmsk.u32 = __cvmx_usb_read_csr32(usb,
@@ -2881,9 +2885,11 @@ static int __cvmx_usb_poll_channel(struct cvmx_usb_state
*usb, int channel)
struct usb_ctrlrequest *header =
cvmx_phys_to_ptr(transaction->control_header);
if (header->wLength)
- transaction->stage =
CVMX_USB_STAGE_DATA;
+ transaction->stage =
+ CVMX_USB_STAGE_DATA;
else
- transaction->stage =
CVMX_USB_STAGE_STATUS;
+ transaction->stage =
+ CVMX_USB_STAGE_STATUS;
}
break;
case CVMX_USB_STAGE_SETUP_SPLIT_COMPLETE:
@@ -2891,9 +2897,11 @@ static int __cvmx_usb_poll_channel(struct cvmx_usb_state
*usb, int channel)
struct usb_ctrlrequest *header =
cvmx_phys_to_ptr(transaction->control_header);
if (header->wLength)
- transaction->stage =
CVMX_USB_STAGE_DATA;
+ transaction->stage =
+ CVMX_USB_STAGE_DATA;
else
- transaction->stage =
CVMX_USB_STAGE_STATUS;
+ transaction->stage =
+ CVMX_USB_STAGE_STATUS;
}
break;
case CVMX_USB_STAGE_DATA:
@@ -3015,7 +3023,8 @@ static int __cvmx_usb_poll_channel(struct cvmx_usb_state
*usb, int channel)
* is complete, the pipe sleeps until the next
* schedule interval
*/
- if (pipe->transfer_dir ==
CVMX_USB_DIRECTION_OUT) {
+ if (pipe->transfer_dir ==
+ CVMX_USB_DIRECTION_OUT) {
/*
* If no space left or this wasn't a max
* size packet then this transfer is
--
2.1.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 08/44] kernel: Move pm_power_off to common code
Am 07.10.2014 07:28, schrieb Guenter Roeck: > arch/um/kernel/reboot.c| 2 -- Acked-by: Richard Weinberger Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 001/002] staging: gs_fpgaboot: Fix "Possible unnecessary KERN_INFO" checkpatch.pl warning
Fix "Possible unnecessary KERN_INFO" checkpatch.pl warning
Signed-off-by: Dzmitry Sledneu
---
drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
index 6aa9d7c..6129164 100644
--- a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
+++ b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
@@ -58,7 +58,7 @@ static void datadump(char *msg, void *m, int n)
for (i = 0; i < n; i++) {
if ((i&0xf) == 0)
- pr_info(KERN_INFO "\n 0x%4x: ", i);
+ pr_info("\n 0x%4x: ", i);
pr_info("%02X ", c[i]);
}
--
2.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 002/002] staging: gs_fpgaboot: Fix "Possible unnecessary 'out of memory' message" checkpatch.pl warning
Fix "Possible unnecessary 'out of memory' message" checkpatch.pl warning
Signed-off-by: Dzmitry Sledneu
---
drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
index 6129164..b7ca3a3 100644
--- a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
+++ b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
@@ -316,10 +316,8 @@ static int gs_fpgaboot(void)
struct fpgaimage*fimage;
fimage = kmalloc(sizeof(struct fpgaimage), GFP_KERNEL);
- if (fimage == NULL) {
- pr_err("No memory is available\n");
- goto err_out;
- }
+ if (!fimage)
+ return -ENOMEM;
err = gs_load_image(fimage, file);
if (err) {
--
2.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 2/4] Documentation: devicetree: bindings: Document deprecated device vendor name to fix related warning
This patch documents deprecated vendor name of device isl29028 for compatibility with older kernels. Signed-off-by: Darshana Padmadas --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ac7269f..ab97459 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -68,6 +68,7 @@ img Imagination Technologies Ltd. intel Intel Corporation intercontrol Inter Control Group isee ISEE 2007 S.L. +isilIntersil (deprecated, use isl) islIntersil karo Ka-Ro electronics GmbH keymileKeymile GmbH -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 0/4] Correct vendor-prefix and document device isl29028
Patchset documents correct and the deprecated vendor-prefix found by checkpatch warning and also documents information of device isl29028 for compatibility. Patchset also includes corrected vendor-prefix and device name in compatible property for files with checkpatch warning of undocumented string "isil,isl29028". Darshana Padmadas (4): Documentation: devicetree: bindings: Document correct and deprecated vendor-prefix with device isl29028 Documentation: devicetree: bindings: Document deprecated device vendor name to fix related warning Staging: iio: light: Added correct vendor-prefix for device isl29028 arch: arm: boot: dts: Added correct vendor-prefix with device name to compatible property Changes in v4: - In PATCH 1/4 gave appropriate description for string describing vendor/chip for deprecated vendor-prefix and device. Documentation/devicetree/bindings/i2c/trivial-devices.txt | 2 ++ Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + arch/arm/boot/dts/tegra30-cardhu.dtsi | 2 +- drivers/staging/iio/light/isl29028.c | 3 ++- 4 files changed, 6 insertions(+), 2 deletions(-) -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 3/4] Staging: iio: light: Added correct vendor-prefix for device isl29028
This patch adds the correct vendor-prefix for device isl29028 and
maintains deprecated vendor-prefix found by checkpatch warning
for older kernel releases.
Signed-off-by: Darshana Padmadas
---
drivers/staging/iio/light/isl29028.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/iio/light/isl29028.c
b/drivers/staging/iio/light/isl29028.c
index 6014625..e969107 100644
--- a/drivers/staging/iio/light/isl29028.c
+++ b/drivers/staging/iio/light/isl29028.c
@@ -537,7 +537,8 @@ static const struct i2c_device_id isl29028_id[] = {
MODULE_DEVICE_TABLE(i2c, isl29028_id);
static const struct of_device_id isl29028_of_match[] = {
- { .compatible = "isil,isl29028", },
+ { .compatible = "isl,isl29028", },
+ { .compatible = "isil,isl29028", },/* deprecated, don't use */
{ },
};
MODULE_DEVICE_TABLE(of, isl29028_of_match);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 4/4] arch: arm: boot: dts: Added correct vendor-prefix with device name to compatible property
This patch adds the correct vendor-prefix listed in
Documentation/devicetree/bindings/vendor-prefixes.txt
with the device name to compatible property.
Signed-off-by: Darshana Padmadas
---
arch/arm/boot/dts/tegra30-cardhu.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi
b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index 2063795..dcc6c75 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -187,7 +187,7 @@
/* ALS and Proximity sensor */
isl29028@44 {
- compatible = "isil,isl29028";
+ compatible = "isl,isl29028";
reg = <0x44>;
interrupt-parent = <&gpio>;
interrupts = ;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4 1/4] Documentation: devicetree: bindings: Document correct and deprecated vendor-prefix with device isl29028
This patch documents the device isl29028 with its vendor-prefix. Undocumented deprecated vendor-prefix found by checkpatch also documented for compatibility reasons. Signed-off-by: Darshana Padmadas --- Documentation/devicetree/bindings/i2c/trivial-devices.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index 6af570e..32edf0b 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -57,6 +57,8 @@ gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire In infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz) isl,isl12057 Intersil ISL12057 I2C RTC Chip +isil,isl29028 (deprecated, use isl) +isl,isl29028Intersil ISL29028 Ambient Light and Proximity Sensor maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/2] staging: gs_fpgaboot: Fix "Possible unnecessary KERN_INFO" checkpatch.pl warning
Fix "Possible unnecessary KERN_INFO" checkpatch.pl warning
Signed-off-by: Dzmitry Sledneu
---
drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
index 6aa9d7c..6129164 100644
--- a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
+++ b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
@@ -58,7 +58,7 @@ static void datadump(char *msg, void *m, int n)
for (i = 0; i < n; i++) {
if ((i&0xf) == 0)
- pr_info(KERN_INFO "\n 0x%4x: ", i);
+ pr_info("\n 0x%4x: ", i);
pr_info("%02X ", c[i]);
}
--
2.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/2] staging: gs_fpgaboot: Fix "Possible unnecessary 'out of memory' message" checkpatch.pl warning
Fix "Possible unnecessary 'out of memory' message" checkpatch.pl warning
Signed-off-by: Dzmitry Sledneu
---
drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
index 6129164..cc788f1 100644
--- a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
+++ b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
@@ -316,10 +316,8 @@ static int gs_fpgaboot(void)
struct fpgaimage*fimage;
fimage = kmalloc(sizeof(struct fpgaimage), GFP_KERNEL);
- if (fimage == NULL) {
- pr_err("No memory is available\n");
- goto err_out;
- }
+ if (!fimage)
+ return -ENOMEM;
err = gs_load_image(fimage, file);
if (err) {
@@ -361,7 +359,6 @@ err_out2:
err_out1:
kfree(fimage);
-err_out:
return -1;
}
--
2.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/4] Documentation: devicetree: bindings: Document correct and deprecated vendor-prefix with device isl29028
Hi Darshana, On Tue, Oct 07, 2014 at 04:19:26PM +0100, Darshana Padmadas wrote: > This patch documents the device isl29028 with its vendor-prefix. Undocumented > deprecated vendor-prefix > found by checkpatch also documented for compatibility reasons. > > Signed-off-by: Darshana Padmadas In future, when you receive an Acked-by (or Reviewed-by, Tested-by, etc), please add them here for subsequent postings, unless there have been substantial changes that mean said tags are not representative. For example, this patch you should have: Signed-off-by: Darshana Padmadas Acked-by: Arnd Bergmann Acked-by: Mark Rutland That makes it obvious that others have looked at your patches, and will help maintainers when deciding whether to pick them up. Additionally, for those who have reviewed or tested patches, it gains them some recognition for that effort. Additionally, it's generally a good idea to wait for at least a day or so between postings so as to give others time to inspect patches. Thanks, Mark. > --- > Documentation/devicetree/bindings/i2c/trivial-devices.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt > b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > index 6af570e..32edf0b 100644 > --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt > +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > @@ -57,6 +57,8 @@ gmt,g751G751: Digital Temperature Sensor and > Thermal Watchdog with Two-Wire In > infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max > 100khz) > infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz) > isl,isl12057 Intersil ISL12057 I2C RTC Chip > +isil,isl29028 (deprecated, use isl) > +isl,isl29028Intersil ISL29028 Ambient Light and Proximity Sensor > maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator > maxim,max1237Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit > ADCs > maxim,max66259-Bit/12-Bit Temperature Sensors with > I²C-Compatible Serial Interface > -- > 1.9.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] staging: gs_fpgaboot: Fix "Possible unnecessary KERN_INFO" checkpatch.pl warning
On Tue, 2014-10-07 at 17:23 +0200, Dzmitry Sledneu wrote:
> Fix "Possible unnecessary KERN_INFO" checkpatch.pl warning
[]
> diff --git a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
> b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
[]
> @@ -58,7 +58,7 @@ static void datadump(char *msg, void *m, int n)
>
> for (i = 0; i < n; i++) {
> if ((i&0xf) == 0)
> - pr_info(KERN_INFO "\n 0x%4x: ", i);
> + pr_info("\n 0x%4x: ", i);
>
> pr_info("%02X ", c[i]);
> }
Please fix this by using print_hex_dump (and family) instead
Something like:
http://www.spinics.net/lists/linux-driver-devel/msg55075.html
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/2] staging: gs_fpgaboot: Use print_hex_dump_bytes instead of pr_info
From: Joe Perches
Use print_hex_dump_bytes instead of pr_info
Signed-off-by: Dzmitry Sledneu
Reviewed-by: Insop Song
---
drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 25 ++---
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
index 6aa9d7c..9764a9a 100644
--- a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
+++ b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
@@ -46,27 +46,6 @@ static char *file = "xlinx_fpga_firmware.bit";
module_param(file, charp, S_IRUGO);
MODULE_PARM_DESC(file, "Xilinx FPGA firmware file.");
-#ifdef DEBUG_FPGA
-static void datadump(char *msg, void *m, int n)
-{
- int i;
- unsigned char *c;
-
- pr_info("=== %s ===\n", msg);
-
- c = m;
-
- for (i = 0; i < n; i++) {
- if ((i&0xf) == 0)
- pr_info(KERN_INFO "\n 0x%4x: ", i);
-
- pr_info("%02X ", c[i]);
- }
-
- pr_info("\n");
-}
-#endif /* DEBUG_FPGA */
-
static void read_bitstream(char *bitdata, char *buf, int *offset, int rdsize)
{
memcpy(buf, bitdata + *offset, rdsize);
@@ -220,9 +199,9 @@ static int gs_download_image(struct fpgaimage *fimage, enum
wbus bus_bytes)
size = fimage->lendata;
#ifdef DEBUG_FPGA
- datadump("bitfile sample", bitdata, 0x100);
+ print_hex_dump_bytes("bitfile sample: ", DUMP_PREFIX_OFFSET,
+bitdata, 0x100);
#endif /* DEBUG_FPGA */
-
if (!xl_supported_prog_bus_width(bus_bytes)) {
pr_err("unsupported program bus width %d\n",
bus_bytes);
--
2.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 2/2] staging: gs_fpgaboot: Fix "Possible unnecessary 'out of memory' message" checkpatch.pl warning
Fix "Possible unnecessary 'out of memory' message" checkpatch.pl warning
Signed-off-by: Dzmitry Sledneu
---
drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
index 9764a9a..0c18c4c 100644
--- a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
+++ b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
@@ -295,10 +295,8 @@ static int gs_fpgaboot(void)
struct fpgaimage*fimage;
fimage = kmalloc(sizeof(struct fpgaimage), GFP_KERNEL);
- if (fimage == NULL) {
- pr_err("No memory is available\n");
- goto err_out;
- }
+ if (!fimage)
+ return -ENOMEM;
err = gs_load_image(fimage, file);
if (err) {
@@ -340,7 +338,6 @@ err_out2:
err_out1:
kfree(fimage);
-err_out:
return -1;
}
--
2.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/44] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings
On Tue, Oct 07, 2014 at 12:02:19PM +0100, Mark Rutland wrote: > On Tue, Oct 07, 2014 at 06:28:09AM +0100, Guenter Roeck wrote: > > Replace reference to pm_power_off (which is an implementation detail) > > and replace it with a more generic description of the driver's > > functionality. > > > > Cc: Rob Herring > > Cc: Pawel Moll > > Cc: Mark Rutland > > Signed-off-by: Guenter Roeck > > --- > > Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git > > a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > > b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > > index af25e77..1e2260a 100644 > > --- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > > +++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > > @@ -3,8 +3,8 @@ > > QNAP NAS devices have a microcontroller controlling the main power > > supply. This microcontroller is connected to UART1 of the Kirkwood and > > Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the > > -microcontroller to turn the power off. This driver adds a handler to > > -pm_power_off which is called to turn the power off. > > +microcontroller to turn the power off. This driver installs a handler > > +to power off the system. > > I'd remove the last sentence -- the driver is also independent of the > HW, and the description of how the power off works at the HW level is > sufficient. > Done. > With that: > > Acked-by: Mark Rutland > Thanks! Guenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 21/44] power/reset: gpio-poweroff: Register with kernel poweroff handler
On Mon, Oct 06, 2014 at 10:28:23PM -0700, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly. Register with a low priority value of 64 to reflect that
> the original code only sets pm_power_off if it was not already set.
>
> Other changes:
>
> Drop note that there can not be an additional instance of this driver.
> The original reason no longer applies, it should be obvious that there
> can only be one instance of the driver if static variables are used to
> reflect its state, and support for multiple instances can now be added
> easily if needed by avoiding static variables.
>
> Do not create an error message if another poweroff handler has already been
> registered. This is perfectly normal and acceptable.
>
> Do not display a warning traceback if the poweroff handler fails to
> power off the system. There may be other poweroff handlers.
I would prefer to keep the warning traceback. We found on some
hardware the GPIO transitions were too fast and it failed to power
off. Seeing the traceback gives an idea where to go look for the
problem.
Other than that,
Acked-by: Andrew Lunn
>
> Cc: Sebastian Reichel
> Cc: Dmitry Eremin-Solenikov
> Cc: David Woodhouse
> Signed-off-by: Guenter Roeck
> ---
> drivers/power/reset/gpio-poweroff.c | 36 ++--
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/power/reset/gpio-poweroff.c
> b/drivers/power/reset/gpio-poweroff.c
> index ce849bc..e95a7a1 100644
> --- a/drivers/power/reset/gpio-poweroff.c
> +++ b/drivers/power/reset/gpio-poweroff.c
> @@ -14,18 +14,18 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> #include
>
> -/*
> - * Hold configuration here, cannot be more than one instance of the driver
> - * since pm_power_off itself is global.
> - */
> static struct gpio_desc *reset_gpio;
>
> -static void gpio_poweroff_do_poweroff(void)
> +static int gpio_poweroff_do_poweroff(struct notifier_block *this,
> + unsigned long unused1, void *unused2)
> +
> {
> BUG_ON(!reset_gpio);
>
> @@ -42,20 +42,18 @@ static void gpio_poweroff_do_poweroff(void)
> /* give it some time */
> mdelay(3000);
>
> - WARN_ON(1);
> + return NOTIFY_DONE;
> }
>
> +static struct notifier_block gpio_poweroff_nb = {
> + .notifier_call = gpio_poweroff_do_poweroff,
> + .priority = 64,
> +};
> +
> static int gpio_poweroff_probe(struct platform_device *pdev)
> {
> bool input = false;
> -
> - /* If a pm_power_off function has already been added, leave it alone */
> - if (pm_power_off != NULL) {
> - dev_err(&pdev->dev,
> - "%s: pm_power_off function already registered",
> -__func__);
> - return -EBUSY;
> - }
> + int err;
>
> reset_gpio = devm_gpiod_get(&pdev->dev, NULL);
> if (IS_ERR(reset_gpio))
> @@ -77,14 +75,16 @@ static int gpio_poweroff_probe(struct platform_device
> *pdev)
> }
> }
>
> - pm_power_off = &gpio_poweroff_do_poweroff;
> - return 0;
> + err = register_poweroff_handler(&gpio_poweroff_nb);
> + if (err)
> + dev_err(&pdev->dev, "Failed to register poweroff handler\n");
> +
> + return err;
> }
>
> static int gpio_poweroff_remove(struct platform_device *pdev)
> {
> - if (pm_power_off == &gpio_poweroff_do_poweroff)
> - pm_power_off = NULL;
> + unregister_poweroff_handler(&gpio_poweroff_nb);
>
> return 0;
> }
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 23/44] power/reset: qnap-poweroff: Register with kernel poweroff handler
On Mon, Oct 06, 2014 at 10:28:25PM -0700, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of setting pm_power_off
> directly. Register with default priority value of 128 to reflect that
> the original code generates an error if another poweroff handler has
> already been registered when the driver is loaded.
>
> Cc: Sebastian Reichel
> Cc: Dmitry Eremin-Solenikov
> Cc: David Woodhouse
> Signed-off-by: Guenter Roeck
Acked-by: Andrew Lunn
Thanks
Andrew
> ---
> drivers/power/reset/qnap-poweroff.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/power/reset/qnap-poweroff.c
> b/drivers/power/reset/qnap-poweroff.c
> index a75db7f..c474980 100644
> --- a/drivers/power/reset/qnap-poweroff.c
> +++ b/drivers/power/reset/qnap-poweroff.c
> @@ -16,7 +16,9 @@
>
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -55,7 +57,8 @@ static void __iomem *base;
> static unsigned long tclk;
> static const struct power_off_cfg *cfg;
>
> -static void qnap_power_off(void)
> +static int qnap_power_off(struct notifier_block *this, unsigned long unused1,
> + void *unused2)
> {
> const unsigned divisor = ((tclk + (8 * cfg->baud)) / (16 * cfg->baud));
>
> @@ -72,14 +75,20 @@ static void qnap_power_off(void)
>
> /* send the power-off command to PIC */
> writel(cfg->cmd, UART1_REG(TX));
> +
> + return NOTIFY_DONE;
> }
>
> +static struct notifier_block qnap_poweroff_nb = {
> + .notifier_call = qnap_power_off,
> + .priority = 128,
> +};
> +
> static int qnap_power_off_probe(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> struct resource *res;
> struct clk *clk;
> - char symname[KSYM_NAME_LEN];
>
> const struct of_device_id *match =
> of_match_node(qnap_power_off_of_match_table, np);
> @@ -106,22 +115,13 @@ static int qnap_power_off_probe(struct platform_device
> *pdev)
>
> tclk = clk_get_rate(clk);
>
> - /* Check that nothing else has already setup a handler */
> - if (pm_power_off) {
> - lookup_symbol_name((ulong)pm_power_off, symname);
> - dev_err(&pdev->dev,
> - "pm_power_off already claimed %p %s",
> - pm_power_off, symname);
> - return -EBUSY;
> - }
> - pm_power_off = qnap_power_off;
> -
> - return 0;
> + return register_poweroff_handler(&qnap_poweroff_nb);
> }
>
> static int qnap_power_off_remove(struct platform_device *pdev)
> {
> - pm_power_off = NULL;
> + unregister_poweroff_handler(&qnap_poweroff_nb);
> +
> return 0;
> }
>
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 20/44] power/reset: restart-poweroff: Register with kernel poweroff handler
On Mon, Oct 06, 2014 at 10:28:22PM -0700, Guenter Roeck wrote:
> Register with kernel poweroff handler instead of seting pm_power_off
> directly. Register as poweroff handler of last resort since the driver
> does not really power off the system but executes a restart.
I would not say last resort, this is how it is designed to work. There
is no way to turn the power off from with linux, it is designed that
u-boot will put the hardware into minimal power consumption until the
"power" button is pressed.
Other than that,
Acked-by: Andrew Lunn
Thanks
Andrew
>
> Cc: Sebastian Reichel
> Cc: Dmitry Eremin-Solenikov
> Cc: David Woodhouse
> Signed-off-by: Guenter Roeck
> ---
> drivers/power/reset/restart-poweroff.c | 25 -
> 1 file changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/power/reset/restart-poweroff.c
> b/drivers/power/reset/restart-poweroff.c
> index edd707e..5437697 100644
> --- a/drivers/power/reset/restart-poweroff.c
> +++ b/drivers/power/reset/restart-poweroff.c
> @@ -12,35 +12,34 @@
> */
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
> #include
> -#include
>
> -static void restart_poweroff_do_poweroff(void)
> +static int restart_poweroff_do_poweroff(struct notifier_block *this,
> + unsigned long unused1, void *unused2)
> {
> reboot_mode = REBOOT_HARD;
> machine_restart(NULL);
> +
> + return NOTIFY_DONE;
> }
>
> +static struct notifier_block restart_poweroff_handler = {
> + .notifier_call = restart_poweroff_do_poweroff,
> +};
> +
> static int restart_poweroff_probe(struct platform_device *pdev)
> {
> - /* If a pm_power_off function has already been added, leave it alone */
> - if (pm_power_off != NULL) {
> - dev_err(&pdev->dev,
> - "pm_power_off function already registered");
> - return -EBUSY;
> - }
> -
> - pm_power_off = &restart_poweroff_do_poweroff;
> - return 0;
> + return register_poweroff_handler(&restart_poweroff_handler);
> }
>
> static int restart_poweroff_remove(struct platform_device *pdev)
> {
> - if (pm_power_off == &restart_poweroff_do_poweroff)
> - pm_power_off = NULL;
> + unregister_poweroff_handler(&restart_poweroff_handler);
>
> return 0;
> }
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for high order
- Original Message - > From: Colin Cross > To: pint...@samsung.com > Cc: Laura Abbott ; Heesub Shin > ; "a...@linux-foundation.org" > ; "gre...@linuxfoundation.org" > ; "john.stu...@linaro.org" > ; "rebe...@android.com" ; > "de...@driverdev.osuosl.org" ; > "linux-ker...@vger.kernel.org" ; IQBAL SHAREEF > ; "pintu_agar...@yahoo.com" ; > Vishnu Pratap Singh ; "c...@samsung.com" > > Sent: Monday, 6 October 2014 11:01 PM > Subject: Re: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER > for high order > > On Mon, Oct 6, 2014 at 9:26 AM, PINTU KUMAR wrote: > >> >> Hi, >> > >> > From: Laura Abbott >> >To: Heesub Shin ; Pintu Kumar > ; a...@linux-foundation.org; > gre...@linuxfoundation.org; john.stu...@linaro.org; rebe...@android.com; > ccr...@android.com; de...@driverdev.osuosl.org; linux-ker...@vger.kernel.org >> >Cc: iqbal@samsung.com; pintu_agar...@yahoo.com; > vishnu...@samsung.com >> >Sent: Monday, 6 October 2014 7:37 PM >> >Subject: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER > for high order >> > >> > >> >On 10/6/2014 3:27 AM, Heesub Shin wrote: >> > >> > >> > >> > >> >> Hello Kumar, >> >> >> >> On 10/06/2014 05:31 PM, Pintu Kumar wrote: >> >>> The Android ion_system_heap uses allocation fallback mechanism >> >>> based on 8,4,0 order pages available in the system. >> >>> It changes gfp flags based on higher order allocation request. >> >>> This higher order value is hard-coded as 4, instead of using >> >>> the system defined higher order value. >> >>> Thus replacing this hard-coded value with > PAGE_ALLOC_COSTLY_ORDER >> >>> which is defined as 3. >> >>> This will help mapping the higher order request in system heap > with >> >>> the actual allocation request. >> >> >> >> Quite reasonable. >> >> >> >> Reviewed-by: Heesub Shin >> >> >> >> BTW, Anyone knows how the allocation order (8,4 and 0) was > decided? I >> >> think only Google guys might know the answer. >> >> >> >> regards, >> >> heesub >> >> >> > >> >My understanding was this was completely unrelated to the costly order >> >and was related to the page sizes corresponding to IOMMU page sizes >> >(1MB, 64K, 4K). This won't make a difference for the uncached page >> >pool case but for the not page pool case, I'm not sure if there > would >> >be a benefit for trying to get 32K pages with some effort vs. just >> >going back to 4K pages. >> >> No, it is not just related to IOMMU case. It comes into picture also for >> normal system-heap allocation (without iommu cases). >> Also, it is applicable for both uncached and page_pool cases. >> Please also check the changes under ion_system_heap_create. >> Here the gfp_flags are set under the pool structure. >> This value is used in ion_page_pool_alloc_pages. >> In both the cases, it internally calls alloc_pages, with this gfp_flags. >> Now, during memory pressure scenario, when alloc_pages moves to slowpath >> this gfp_flags will be used to decide allocation retry. >> In the current code, the higher-order flag is set only when order is > greater than 4. >> But, in MM, the order 4 is also considered as higher-order request. >> This higher-order is decided based on PAGE_ALLOC_COSTLY_ORDER (3) value. >> Hence, I think this value should be in sync with the MM code. >> > >> >Do you have any data/metrics that show a benefit from this patch? >> I think it is not related to any data or metrics. >> It is about replacing the hard-coded higher-order check to be in sync with >> the MM code. >> > > The selection of the orders used for allocation (8, then 4, then 0) is > designed to match with the sizes often found in IOMMUs, but this isn't > changing the order of the allocation, it is changing the GFP flags > used for the order 4 allocation. Right now we are using the > low_order_gfp_flags for order 4, this patch would change it to use > high_order_gfp_flags. We originally used low_order_gfp_flags here > because the MM subsystem can usually satisfy these allocations, and > the additional load placed on the MM subsystem to kick off kswapd to > free up more order 4 chunks is generally worth it. Using order 4 > pages instead of order 0 pages can significantly improve the > performance of many IOMMUs by reducing TLB pressure and time spent > updating page tables. Unless you have data showing that this improves > something, and doesn't just cause all allocations to be order 0 when > under memory pressure, I don't suggest merging this. > Ok agree. It is worth retrying the allocation with order-4 pages. But, since 4 is considered higher order for MM and is greater than PAGE_ALLOC_COSTLY_ORDER. I guess the retrying will not happen, because of the following check in page_alloc: if (order > PAGE_ALLOC_COSTLY_ORDER) goto nopage; ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 06/44] gpio-poweroff: Drop reference to pm_power_off from devicetree bindings
On Mon, Oct 06, 2014 at 10:28:08PM -0700, Guenter Roeck wrote: > pm_power_off is an implementation detail. Replace it with a more generic > description of the driver's functionality. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Signed-off-by: Guenter Roeck Acked-by: Andrew Lunn Thanks Andrew > --- > Documentation/devicetree/bindings/gpio/gpio-poweroff.txt | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > index d4eab92..c95a1a6 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt > @@ -2,12 +2,12 @@ Driver a GPIO line that can be used to turn the power off. > > The driver supports both level triggered and edge triggered power off. > At driver load time, the driver will request the given gpio line and > -install a pm_power_off handler. If the optional properties 'input' is > -not found, the GPIO line will be driven in the inactive > +install a handler to power off the system. If the optional properties > +'input' is not found, the GPIO line will be driven in the inactive > state. Otherwise its configured as an input. > > -When the pm_power_off is called, the gpio is configured as an output, > -and drive active, so triggering a level triggered power off > +When the the poweroff handler is called, the gpio is configured as an > +output, and drive active, so triggering a level triggered power off > condition. This will also cause an inactive->active edge condition, so > triggering positive edge triggered power off. After a delay of 100ms, > the GPIO is set to inactive, thus causing an active->inactive edge, > @@ -24,7 +24,7 @@ Required properties: > > Optional properties: > - input : Initially configure the GPIO line as an input. Only reconfigure > - it to an output when the pm_power_off function is called. If this optional > + it to an output when the poweroff handler is called. If this optional >property is not specified, the GPIO is initialized as an output in its >inactive state. > > -- > 1.9.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/44] qnap-poweroff: Drop reference to pm_power_off from devicetree bindings
On Mon, Oct 06, 2014 at 10:28:09PM -0700, Guenter Roeck wrote: > Replace reference to pm_power_off (which is an implementation detail) > and replace it with a more generic description of the driver's functionality. Acked-by: Andrew Lunn Thanks Andrew > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Signed-off-by: Guenter Roeck > --- > Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > index af25e77..1e2260a 100644 > --- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > +++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt > @@ -3,8 +3,8 @@ > QNAP NAS devices have a microcontroller controlling the main power > supply. This microcontroller is connected to UART1 of the Kirkwood and > Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the > -microcontroller to turn the power off. This driver adds a handler to > -pm_power_off which is called to turn the power off. > +microcontroller to turn the power off. This driver installs a handler > +to power off the system. > > Synology NAS devices use a similar scheme, but a different baud rate, > 9600, and a different character, '1'. > -- > 1.9.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for high order
On Tue, Oct 7, 2014 at 9:07 AM, PINTU KUMAR wrote: > - Original Message - >> From: Colin Cross >> To: pint...@samsung.com >> Cc: Laura Abbott ; Heesub Shin >> ; "a...@linux-foundation.org" >> ; "gre...@linuxfoundation.org" >> ; "john.stu...@linaro.org" >> ; "rebe...@android.com" ; >> "de...@driverdev.osuosl.org" ; >> "linux-ker...@vger.kernel.org" ; IQBAL SHAREEF >> ; "pintu_agar...@yahoo.com" >> ; Vishnu Pratap Singh ; >> "c...@samsung.com" >> Sent: Monday, 6 October 2014 11:01 PM >> Subject: Re: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER >> for high order >> >> On Mon, Oct 6, 2014 at 9:26 AM, PINTU KUMAR wrote: >> >>> >>> Hi, >>> > >>> > From: Laura Abbott >>> >To: Heesub Shin ; Pintu Kumar >> ; a...@linux-foundation.org; >> gre...@linuxfoundation.org; john.stu...@linaro.org; rebe...@android.com; >> ccr...@android.com; de...@driverdev.osuosl.org; linux-ker...@vger.kernel.org >>> >Cc: iqbal@samsung.com; pintu_agar...@yahoo.com; >> vishnu...@samsung.com >>> >Sent: Monday, 6 October 2014 7:37 PM >>> >Subject: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER >> for high order >>> > >>> > >>> >On 10/6/2014 3:27 AM, Heesub Shin wrote: >>> > >>> > >>> > >>> > >>> >> Hello Kumar, >>> >> >>> >> On 10/06/2014 05:31 PM, Pintu Kumar wrote: >>> >>> The Android ion_system_heap uses allocation fallback mechanism >>> >>> based on 8,4,0 order pages available in the system. >>> >>> It changes gfp flags based on higher order allocation request. >>> >>> This higher order value is hard-coded as 4, instead of using >>> >>> the system defined higher order value. >>> >>> Thus replacing this hard-coded value with >> PAGE_ALLOC_COSTLY_ORDER >>> >>> which is defined as 3. >>> >>> This will help mapping the higher order request in system heap >> with >>> >>> the actual allocation request. >>> >> >>> >> Quite reasonable. >>> >> >>> >> Reviewed-by: Heesub Shin >>> >> >>> >> BTW, Anyone knows how the allocation order (8,4 and 0) was >> decided? I >>> >> think only Google guys might know the answer. >>> >> >>> >> regards, >>> >> heesub >>> >> >>> > >>> >My understanding was this was completely unrelated to the costly order >>> >and was related to the page sizes corresponding to IOMMU page sizes >>> >(1MB, 64K, 4K). This won't make a difference for the uncached page >>> >pool case but for the not page pool case, I'm not sure if there >> would >>> >be a benefit for trying to get 32K pages with some effort vs. just >>> >going back to 4K pages. >>> >>> No, it is not just related to IOMMU case. It comes into picture also for >>> normal system-heap allocation (without iommu cases). >>> Also, it is applicable for both uncached and page_pool cases. >>> Please also check the changes under ion_system_heap_create. >>> Here the gfp_flags are set under the pool structure. >>> This value is used in ion_page_pool_alloc_pages. >>> In both the cases, it internally calls alloc_pages, with this gfp_flags. >>> Now, during memory pressure scenario, when alloc_pages moves to slowpath >>> this gfp_flags will be used to decide allocation retry. >>> In the current code, the higher-order flag is set only when order is >> greater than 4. >>> But, in MM, the order 4 is also considered as higher-order request. >>> This higher-order is decided based on PAGE_ALLOC_COSTLY_ORDER (3) value. >>> Hence, I think this value should be in sync with the MM code. >>> > >>> >Do you have any data/metrics that show a benefit from this patch? >>> I think it is not related to any data or metrics. >>> It is about replacing the hard-coded higher-order check to be in sync with >>> the MM code. >>> >> >> The selection of the orders used for allocation (8, then 4, then 0) is >> designed to match with the sizes often found in IOMMUs, but this isn't >> changing the order of the allocation, it is changing the GFP flags >> used for the order 4 allocation. Right now we are using the >> low_order_gfp_flags for order 4, this patch would change it to use >> high_order_gfp_flags. We originally used low_order_gfp_flags here >> because the MM subsystem can usually satisfy these allocations, and >> the additional load placed on the MM subsystem to kick off kswapd to >> free up more order 4 chunks is generally worth it. Using order 4 >> pages instead of order 0 pages can significantly improve the >> performance of many IOMMUs by reducing TLB pressure and time spent >> updating page tables. Unless you have data showing that this improves >> something, and doesn't just cause all allocations to be order 0 when >> under memory pressure, I don't suggest merging this. >> > > Ok agree. It is worth retrying the allocation with order-4 pages. > But, since 4 is considered higher order for MM and is greater than > PAGE_ALLOC_COSTLY_ORDER. > I guess the retrying will not happen, because of the following check in > page_alloc: > if (order > PAGE_ALLOC_COSTLY_ORDER) > goto nopage; It's not the retry that I
Re: [PATCH 29/44] staging: nvec: Register with kernel poweroff handler
On Mon, Oct 06, 2014 at 10:28:31PM -0700, Guenter Roeck wrote: > Register with kernel poweroff handler instead of setting pm_power_off > directly. Register with default priority value of 128 since we don't know > any better. > > Cc: Julian Andres Klode > Cc: Marc Dietrich > Cc: Greg Kroah-Hartman > Signed-off-by: Guenter Roeck > --- > drivers/staging/nvec/nvec.c | 24 +++- > drivers/staging/nvec/nvec.h | 2 ++ > 2 files changed, 17 insertions(+), 9 deletions(-) Acked-by: Greg Kroah-Hartman ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
On 10/07/14 00:28, Guenter Roeck wrote: > Devicetree bindings are supposed to be operating system independent > and should thus not describe how a specific functionality is implemented > in Linux. So your argument is that linux/Documentation/devicetree/bindings should not be specific to Linux. Merely hosted in the Linux kernel source repository. Well that's certainly a point of view. Rob ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 4/4] arch: arm: boot: dts: Added correct vendor-prefix with device name to compatible property
On Tue, Oct 7, 2014 at 10:19 AM, Darshana Padmadas
wrote:
> This patch adds the correct vendor-prefix listed in
> Documentation/devicetree/bindings/vendor-prefixes.txt
> with the device name to compatible property.
It would be nice if the subject and msg gave some clue as to which
binding and platform you are changing. Look at prior commits and
follow their pattern for subject.
Rob
>
> Signed-off-by: Darshana Padmadas
> ---
> arch/arm/boot/dts/tegra30-cardhu.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi
> b/arch/arm/boot/dts/tegra30-cardhu.dtsi
> index 2063795..dcc6c75 100644
> --- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
> +++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
> @@ -187,7 +187,7 @@
>
> /* ALS and Proximity sensor */
> isl29028@44 {
> - compatible = "isil,isl29028";
> + compatible = "isl,isl29028";
> reg = <0x44>;
> interrupt-parent = <&gpio>;
> interrupts = ;
> --
> 1.9.1
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 2/4] Documentation: devicetree: bindings: Document deprecated device vendor name to fix related warning
On Tue, Oct 7, 2014 at 10:19 AM, Darshana Padmadas wrote: > This patch documents deprecated vendor name of device isl29028 for > compatibility with older kernels. Fix your line wrapping to 72 chars. You can shorten the subject "Documentation: devicetree: bindings:" to "dt-bindings:". We're horribly inconsistent there... Rob > Signed-off-by: Darshana Padmadas > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index ac7269f..ab97459 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -68,6 +68,7 @@ img Imagination Technologies Ltd. > intel Intel Corporation > intercontrol Inter Control Group > isee ISEE 2007 S.L. > +isilIntersil (deprecated, use isl) > islIntersil > karo Ka-Ro electronics GmbH > keymileKeymile GmbH > -- > 1.9.1 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
On Tue, Oct 07, 2014 at 11:21:11AM -0500, Rob Landley wrote: > On 10/07/14 00:28, Guenter Roeck wrote: > > Devicetree bindings are supposed to be operating system independent > > and should thus not describe how a specific functionality is implemented > > in Linux. > > So your argument is that linux/Documentation/devicetree/bindings should > not be specific to Linux. Merely hosted in the Linux kernel source > repository. > > Well that's certainly a point of view. > Not specifically my argument, really, and nothing new either. But, yes, I do think that devicetree bindings descriptions should not include implementation details, especially since those may change over time (as is the case here). Thanks, Guenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
On Tue, Oct 07, 2014 at 05:21:11PM +0100, Rob Landley wrote: > On 10/07/14 00:28, Guenter Roeck wrote: > > Devicetree bindings are supposed to be operating system independent > > and should thus not describe how a specific functionality is implemented > > in Linux. > > So your argument is that linux/Documentation/devicetree/bindings should > not be specific to Linux. Merely hosted in the Linux kernel source > repository. Precisely. If nothing else as a general guideline this keeps us honest, and prevents us from embedding arbitrary implementation details into bidnings that cause pain later when we want to change things at either end. There are already otehr users of these bindings, so we can't really claim they're strictly Linux-specific anyhow. > Well that's certainly a point of view. As far as I am aware, it's the point of view shared by the device tree maintainers, and it's been that way for a while. I don't really follow your concern. For one thing were this followed more strictly this file wouldn't need patching at all to correct for this Linux-internal rework... Thanks, Mark. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
On 10/07/2014 09:31 AM, Guenter Roeck wrote: On Tue, Oct 07, 2014 at 11:21:11AM -0500, Rob Landley wrote: On 10/07/14 00:28, Guenter Roeck wrote: Devicetree bindings are supposed to be operating system independent and should thus not describe how a specific functionality is implemented in Linux. So your argument is that linux/Documentation/devicetree/bindings should not be specific to Linux. Merely hosted in the Linux kernel source repository. Well that's certainly a point of view. Not specifically my argument, really, and nothing new either. But, yes, I do think that devicetree bindings descriptions should not include implementation details, especially since those may change over time (as is the case here). I fully agree. Many device trees come from outside the kernel (i.e. they are supplied by the system boot environment). Obviously these device trees cannot be changed at the whim of kernel developers, *and* it is perfectly reasonable to think that software other than the Linux kernel will run on this type of system too. So yes, it is really true, device trees are not a Linux kernel private implementation detail, they are really an external ABI that, although documented in the kernel source tree, cannot be changed in incompatible ways as time progresses. David Daney ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 05/44] mfd: as3722: Drop reference to pm_power_off from devicetree bindings
On 10/07/14 11:59, David Daney wrote: > On 10/07/2014 09:31 AM, Guenter Roeck wrote: >> On Tue, Oct 07, 2014 at 11:21:11AM -0500, Rob Landley wrote: >>> On 10/07/14 00:28, Guenter Roeck wrote: Devicetree bindings are supposed to be operating system independent and should thus not describe how a specific functionality is implemented in Linux. >>> >>> So your argument is that linux/Documentation/devicetree/bindings should >>> not be specific to Linux. Merely hosted in the Linux kernel source >>> repository. >>> >>> Well that's certainly a point of view. >>> >> Not specifically my argument, really, and nothing new either. But, >> yes, I do >> think that devicetree bindings descriptions should not include >> implementation >> details, especially since those may change over time (as is the case >> here). >> > > I fully agree. > > Many device trees come from outside the kernel (i.e. they are supplied > by the system boot environment). Obviously these device trees cannot be > changed at the whim of kernel developers, *and* it is perfectly > reasonable to think that software other than the Linux kernel will run > on this type of system too. > > So yes, it is really true, device trees are not a Linux kernel private > implementation detail, they are really an external ABI that, although > documented in the kernel source tree, cannot be changed in incompatible > ways as time progresses. Ah. Existing thing with backstory among the in-crowd, so I'll assume "git subtree" was previously suggested and you had that discussion already and decided against it. Carry on, Rob ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 0/2] Drivers: scsi: storvsc: Fix issues with hot-add/remove of LUNs
> -Original Message- > From: Christoph Hellwig [mailto:h...@infradead.org] > Sent: Thursday, September 25, 2014 6:47 AM > To: KY Srinivasan > Cc: h...@suse.de; linux-ker...@vger.kernel.org; > de...@linuxdriverproject.org; oher...@suse.com; > jbottom...@parallels.com; linux-s...@vger.kernel.org > Subject: Re: [PATCH 0/2] Drivers: scsi: storvsc: Fix issues with hot- > add/remove of LUNs > > So can anywayone give me a review for those two patches? Did you get the reviews? K. Y > > On Sat, Aug 16, 2014 at 08:09:14PM -0700, K. Y. Srinivasan wrote: > > This patch-set addresses issues with LUN hot-add and remove. When the > > host notifies the guest that a scan is needed, scan the host. Also, > > prior to discovering new devices that may have been added, ensure we > > handle the LUN remove case first. > > > > K. Y. Srinivasan (2): > > Drivers: scsi: storvsc: In responce to a scan event, scan the host > > Drivers: scsi: storvsc: Force discovery of LUNs that may have been > > removed. > > > > drivers/scsi/storvsc_drv.c | 43 - > -- > > 1 files changed, 32 insertions(+), 11 deletions(-) > > > > -- > > 1.7.4.1 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-scsi" > > in the body of a message to majord...@vger.kernel.org More > majordomo > > info at http://vger.kernel.org/majordomo-info.html > ---end quoted text--- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 03/44] hibernate: Call have_kernel_poweroff instead of checking pm_power_off
On Monday, October 06, 2014 10:28:05 PM Guenter Roeck wrote: > Poweroff handlers may now be installed with register_poweroff_handler. > Use the new API function have_kernel_poweroff to determine if a poweroff > handler has been installed. > > Cc: Rafael J. Wysocki > Cc: Pavel Machek > Cc: Len Brown > Signed-off-by: Guenter Roeck ACK > --- > kernel/power/hibernate.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c > index a9dfa79..20353c5 100644 > --- a/kernel/power/hibernate.c > +++ b/kernel/power/hibernate.c > @@ -602,7 +602,7 @@ static void power_down(void) > case HIBERNATION_PLATFORM: > hibernation_platform_enter(); > case HIBERNATION_SHUTDOWN: > - if (pm_power_off) > + if (have_kernel_poweroff()) > kernel_power_off(); > break; > #ifdef CONFIG_SUSPEND > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 44/44] kernel: Remove pm_power_off
On Monday, October 06, 2014 10:28:46 PM Guenter Roeck wrote:
> No users of pm_power_off are left, so it is safe to remove the function.
>
> Cc: Rafael J. Wysocki
> Cc: Pavel Machek
> Cc: Len Brown
> Signed-off-by: Guenter Roeck
ACK
> ---
> include/linux/pm.h | 1 -
> kernel/power/poweroff_handler.c | 10 +-
> 2 files changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/include/linux/pm.h b/include/linux/pm.h
> index 45271b5..fce7645 100644
> --- a/include/linux/pm.h
> +++ b/include/linux/pm.h
> @@ -31,7 +31,6 @@
> /*
> * Callbacks for platform drivers to implement.
> */
> -extern void (*pm_power_off)(void);
> extern void (*pm_power_off_prepare)(void);
>
> /*
> diff --git a/kernel/power/poweroff_handler.c b/kernel/power/poweroff_handler.c
> index 96f59ef..01a3a39 100644
> --- a/kernel/power/poweroff_handler.c
> +++ b/kernel/power/poweroff_handler.c
> @@ -20,12 +20,6 @@
> #include
>
> /*
> - * If set, calling this function will power off the system immediately.
> - */
> -void (*pm_power_off)(void);
> -EXPORT_SYMBOL(pm_power_off);
> -
> -/*
> * Notifier list for kernel code which wants to be called
> * to power off the system.
> */
> @@ -163,8 +157,6 @@ int register_poweroff_handler_simple(void
> (*handler)(void), int priority)
> */
> void do_kernel_poweroff(void)
> {
> - if (pm_power_off)
> - pm_power_off();
> atomic_notifier_call_chain(&poweroff_handler_list, 0, NULL);
> }
>
> @@ -175,6 +167,6 @@ void do_kernel_poweroff(void)
> */
> bool have_kernel_poweroff(void)
> {
> - return pm_power_off != NULL || poweroff_handler_list.head != NULL;
> + return poweroff_handler_list.head != NULL;
> }
> EXPORT_SYMBOL(have_kernel_poweroff);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8712: fix unnecessary elses after return/break in rtl8712_efuse.c
This patch fixes two unnecessary else conditions that were found by
checkpatch.pl.
Signed-off-by: Serguey Parkhomovsky
---
drivers/staging/rtl8712/rtl8712_efuse.c | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl8712_efuse.c
b/drivers/staging/rtl8712/rtl8712_efuse.c
index c9eeb42..0e155d9 100644
--- a/drivers/staging/rtl8712/rtl8712_efuse.c
+++ b/drivers/staging/rtl8712/rtl8712_efuse.c
@@ -414,19 +414,19 @@ u8 r8712_efuse_pg_packet_write(struct _adapter *padapter,
const u8 offset,
bResult = false;
}
break;
- } else { /* write header fail */
- bResult = false;
- if (0xFF == efuse_data)
- return bResult; /* nothing damaged. */
- /* call rescue procedure */
- if (fix_header(padapter, efuse_data, efuse_addr) ==
- false)
- return false; /* rescue fail */
-
- if (++repeat_times > _REPEAT_THRESHOLD_) /* fail */
- break;
- /* otherwise, take another risk... */
}
+ /* write header fail */
+ bResult = false;
+ if (0xFF == efuse_data)
+ return bResult; /* nothing damaged. */
+ /* call rescue procedure */
+ if (fix_header(padapter, efuse_data, efuse_addr) ==
+ false)
+ return false; /* rescue fail */
+
+ if (++repeat_times > _REPEAT_THRESHOLD_) /* fail */
+ break;
+ /* otherwise, take another risk... */
}
return bResult;
}
@@ -541,15 +541,16 @@ u8 r8712_efuse_map_write(struct _adapter *padapter, u16
addr, u16 cnts,
}
idx++;
break;
- } else {
- if ((data[idx] != pktdata[i]) || (data[idx+1] !=
-pktdata[i+1])) {
- word_en &= ~BIT(i >> 1);
- newdata[j++] = data[idx];
- newdata[j++] = data[idx + 1];
- }
- idx += 2;
}
+
+ if ((data[idx] != pktdata[i]) || (data[idx+1] !=
+pktdata[i+1])) {
+ word_en &= ~BIT(i >> 1);
+ newdata[j++] = data[idx];
+ newdata[j++] = data[idx + 1];
+ }
+ idx += 2;
+
if (idx == cnts)
break;
}
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] imx-drm: imx-drm-core: Remove unneeded forward declaration
From: Fabio Estevam
There is no need to forward declare 'struct imx_drm_crtc' because the
"imx-drm.h" header file already includes it.
Signed-off-by: Fabio Estevam
---
drivers/staging/imx-drm/imx-drm-core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-drm-core.c
b/drivers/staging/imx-drm/imx-drm-core.c
index 9cb222e..8a3b967 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -29,8 +29,6 @@
#define MAX_CRTC 4
-struct imx_drm_crtc;
-
struct imx_drm_component {
struct device_node *of_node;
struct list_head list;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8712: fix unnecessary elses after return/break in rtl8712_efuse.c
On Tue, 2014-10-07 at 16:48 -0700, Serguey Parkhomovsky wrote: > This patch fixes two unnecessary else conditions that were found by > checkpatch.pl. [] > diff --git a/drivers/staging/rtl8712/rtl8712_efuse.c > b/drivers/staging/rtl8712/rtl8712_efuse.c [] > @@ -414,19 +414,19 @@ u8 r8712_efuse_pg_packet_write(struct _adapter > *padapter, const u8 offset, [] > + /* call rescue procedure */ > + if (fix_header(padapter, efuse_data, efuse_addr) == > + false) > + return false; /* rescue fail */ Probably better as: if (!fix_header(padapter, efuse_data, efuse_addr)) return false; /* rescue fail */ ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v3] Tools: hv: vssdaemon: ignore the EBUSY on multiple freezing the same partition
> -Original Message- > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf > Of Dexuan Cui > Sent: Friday, September 26, 2014 12:52 PM > To: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; driverdev- > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com > Cc: Haiyang Zhang > Subject: [PATCH v3] Tools: hv: vssdaemon: ignore the EBUSY on multiple > freezing the same partition > > If a partition appears mounted more than once in /proc/mounts, vss_do_freeze() > succeeds only for the first time and gets EBUSY (on freeze) or EINVAL (on > thaw) for the second time. The patch ignores these to make the backup feature > work. > > Also improved the error handling in case a freeze operation fails. > > Signed-off-by: Dexuan Cui > Reviewed-by: K. Y. Srinivasan > --- > > v2: Add "errno = 0;" before the ioctl() > (Unnecessary and removed now since we remove syslog() in vss_do_freeze() in > v3) > > v3: Remove the unsafe syslog() in vss_do_freeze(): that could write the disk. > Thaw the filesystems in case the freezing operation fails. > In main(), add syslog() when we check the return value of vss_operate(). > > tools/hv/hv_vss_daemon.c | 48 Hi Greg, Ping. Thanks, -- Dexuan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
