* Re: [PATCH 37/51] DMA-API: usb: use new dma_coerce_mask_and_coherent()
From: Nicolas Ferre @ 2013-09-23 12:34 UTC (permalink / raw)
To: Russell King, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Solarflare linux maintainers,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
Cc: Alexander Shishkin, Greg Kroah-Hartman, Felipe Balbi, Kukjin Kim,
Alan Stern, Tony Prisk, Stephen Warren
In-Reply-To: <E1VMmIV-0007jw-Gq-eh5Bv4kxaXIANfyc6IWni62ZND6+EDdj@public.gmane.org>
On 20/09/2013 00:02, Russell King :
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c | 4 +---
> drivers/usb/dwc3/dwc3-exynos.c | 4 +---
> drivers/usb/host/ehci-atmel.c | 4 +---
For Atmel driver:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
[..]
> diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
> index 5831a88..8e7323e 100644
> --- a/drivers/usb/host/ehci-atmel.c
> +++ b/drivers/usb/host/ehci-atmel.c
> @@ -90,9 +90,7 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
> * Since shared usb code relies on it, set it here for now.
> * Once we have dma capability bindings this can go away.
> */
> - if (!pdev->dev.dma_mask)
> - pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> - retval = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + retval = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> if (retval)
> goto fail_create_hcd;
>
[..]
Thanks Russell,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 0/7] driver core: prevent deferred probe with platform_driver_probe
From: Johan Hovold @ 2013-09-23 14:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-fbdev, linux-usb, Mark Brown, Johan Hovold, linux-pcmcia,
linux-mmc, linux-kernel, linux-mtd, Grant Likely
In-Reply-To: <20130923134028.GF21013@sirena.org.uk>
Deferred probing cannot be used with platform_driver_probe as by the
time probing is retried either the driver has been unregistered or its
probe function has been set to platform_drv_probe_fail.
With commit e9354576 ("gpiolib: Defer failed gpio requests by default")
the gpio subsystem started returning -EPROBE_DEFER, which in turn
several platform drivers using platform_driver_probe return to driver
core. Other subsystems (e.g. regulator) has since started doing the
same.
The first patch in this series prevents platform drivers using
platform_driver_probe from requesting probe deferral while warning that
it is not supported.
The remaining patches move six platform-driver probe functions that rely
on gpio_request out of __init. There are likely other probe functions
that might return -EPROBE_DEFER and should be moved out of __init as
well.
Note that the mvsdio, at91_cf and pxa25x_udc patches are completely
untested.
Johan
Johan Hovold (7):
driver core: prevent deferred probe with platform_driver_probe
mmc: mvsdio: fix deferred probe from __init
mtd: atmel_nand: fix deferred probe from __init
pcmcia: at91_cf: fix deferred probe from __init
usb: gadget: pxa25x_udc: fix deferred probe from __init
usb: phy: gpio-vbus: fix deferred probe from __init
backlight: atmel-pwm-bl: fix deferred probe from __init
drivers/base/platform.c | 17 +++++++++++++----
drivers/mmc/host/mvsdio.c | 11 ++++++-----
drivers/mtd/nand/atmel_nand.c | 13 +++++++------
drivers/pcmcia/at91_cf.c | 11 +++++------
drivers/usb/gadget/pxa25x_udc.c | 9 +++++----
drivers/usb/phy/phy-gpio-vbus-usb.c | 11 +++++------
drivers/video/backlight/atmel-pwm-bl.c | 9 +++++----
include/linux/platform_device.h | 1 +
8 files changed, 47 insertions(+), 35 deletions(-)
--
1.8.3.2
^ permalink raw reply
* [PATCH 1/7] driver core: prevent deferred probe with platform_driver_probe
From: Johan Hovold @ 2013-09-23 14:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-fbdev, linux-usb, Mark Brown, Johan Hovold, linux-pcmcia,
linux-mmc, linux-kernel, linux-mtd, Grant Likely
In-Reply-To: <1379946452-25649-1-git-send-email-jhovold@gmail.com>
Prevent drivers relying on platform_driver_probe from requesting
deferred probing in order to avoid further futile probe attempts (either
the driver has been unregistered or its probe function has been set to
platform_drv_probe_fail when probing is retried).
Note that several platform drivers currently return subsystem errors
from probe and that these can include -EPROBE_DEFER (e.g. if a gpio
request fails).
Add a warning to platform_drv_probe that can be used to catch drivers
that inadvertently request probe deferral while using
platform_driver_probe.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/base/platform.c | 17 +++++++++++++----
include/linux/platform_device.h | 1 +
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4f8bef3..47051cd 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -488,6 +488,11 @@ static int platform_drv_probe(struct device *_dev)
if (ret && ACPI_HANDLE(_dev))
acpi_dev_pm_detach(_dev, true);
+ if (drv->prevent_deferred_probe && ret = -EPROBE_DEFER) {
+ dev_warn(_dev, "probe deferral not supported\n");
+ ret = -ENXIO;
+ }
+
return ret;
}
@@ -553,8 +558,7 @@ EXPORT_SYMBOL_GPL(platform_driver_unregister);
/**
* platform_driver_probe - register driver for non-hotpluggable device
* @drv: platform driver structure
- * @probe: the driver probe routine, probably from an __init section,
- * must not return -EPROBE_DEFER.
+ * @probe: the driver probe routine, probably from an __init section
*
* Use this instead of platform_driver_register() when you know the device
* is not hotpluggable and has already been registered, and you want to
@@ -565,8 +569,7 @@ EXPORT_SYMBOL_GPL(platform_driver_unregister);
* into system-on-chip processors, where the controller devices have been
* configured as part of board setup.
*
- * This is incompatible with deferred probing so probe() must not
- * return -EPROBE_DEFER.
+ * Note that this is incompatible with deferred probing.
*
* Returns zero if the driver registered and bound to a device, else returns
* a negative error code and with the driver not registered.
@@ -576,6 +579,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
{
int retval, code;
+ /*
+ * Prevent driver from requesting probe deferral to avoid further
+ * futile probe attempts.
+ */
+ drv->prevent_deferred_probe = true;
+
/* make sure driver won't have bind/unbind attributes */
drv->driver.suppress_bind_attrs = true;
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index ce8e4ff..16f6654 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -178,6 +178,7 @@ struct platform_driver {
int (*resume)(struct platform_device *);
struct device_driver driver;
const struct platform_device_id *id_table;
+ bool prevent_deferred_probe;
};
#define to_platform_driver(drv) (container_of((drv), struct platform_driver, \
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/7] mmc: mvsdio: fix deferred probe from __init
From: Johan Hovold @ 2013-09-23 14:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Grant Likely, Mark Brown, linux-kernel, linux-mmc, linux-mtd,
linux-pcmcia, linux-usb, linux-fbdev, Johan Hovold, Nicolas Pitre,
Chris Ball
In-Reply-To: <1379946452-25649-1-git-send-email-jhovold@gmail.com>
Move probe out of __init section and don't use platform_driver_probe
which cannot be used with deferred probing.
Since commit e9354576 ("gpiolib: Defer failed gpio requests by default")
this driver might return -EPROBE_DEFER if the mmc_gpio_request_cd fails.
Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: Chris Ball <cjb@laptop.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/mmc/host/mvsdio.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
index 06c5b0b..deecee0 100644
--- a/drivers/mmc/host/mvsdio.c
+++ b/drivers/mmc/host/mvsdio.c
@@ -655,7 +655,7 @@ static const struct mmc_host_ops mvsd_ops = {
.enable_sdio_irq = mvsd_enable_sdio_irq,
};
-static void __init
+static void
mv_conf_mbus_windows(struct mvsd_host *host,
const struct mbus_dram_target_info *dram)
{
@@ -677,7 +677,7 @@ mv_conf_mbus_windows(struct mvsd_host *host,
}
}
-static int __init mvsd_probe(struct platform_device *pdev)
+static int mvsd_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct mmc_host *mmc = NULL;
@@ -819,7 +819,7 @@ out:
return ret;
}
-static int __exit mvsd_remove(struct platform_device *pdev)
+static int mvsd_remove(struct platform_device *pdev)
{
struct mmc_host *mmc = platform_get_drvdata(pdev);
@@ -872,7 +872,8 @@ static const struct of_device_id mvsdio_dt_ids[] = {
MODULE_DEVICE_TABLE(of, mvsdio_dt_ids);
static struct platform_driver mvsd_driver = {
- .remove = __exit_p(mvsd_remove),
+ .probe = mvsd_probe,
+ .remove = mvsd_remove,
.suspend = mvsd_suspend,
.resume = mvsd_resume,
.driver = {
@@ -881,7 +882,7 @@ static struct platform_driver mvsd_driver = {
},
};
-module_platform_driver_probe(mvsd_driver, mvsd_probe);
+module_platform_driver(mvsd_driver);
/* maximum card clock frequency (default 50MHz) */
module_param(maxfreq, int, 0);
--
1.8.3.2
^ permalink raw reply related
* [PATCH 3/7] mtd: atmel_nand: fix deferred probe from __init
From: Johan Hovold @ 2013-09-23 14:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Grant Likely, Mark Brown, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pcmcia-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Johan Hovold, David Woodhouse,
Josh Wu
In-Reply-To: <1379946452-25649-1-git-send-email-jhovold-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Move probe out of __init section and don't use platform_driver_probe
which cannot be used with deferred probing.
Since commit e9354576 ("gpiolib: Defer failed gpio requests by default")
this driver might return -EPROBE_DEFER if a gpio_request fails.
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/mtd/nand/atmel_nand.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 060feea..bd1ce7d 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -1139,7 +1139,7 @@ static int pmecc_choose_ecc(struct atmel_nand_host *host,
return 0;
}
-static int __init atmel_pmecc_nand_init_params(struct platform_device *pdev,
+static int atmel_pmecc_nand_init_params(struct platform_device *pdev,
struct atmel_nand_host *host)
{
struct mtd_info *mtd = &host->mtd;
@@ -1548,7 +1548,7 @@ static int atmel_of_init_port(struct atmel_nand_host *host,
}
#endif
-static int __init atmel_hw_nand_init_params(struct platform_device *pdev,
+static int atmel_hw_nand_init_params(struct platform_device *pdev,
struct atmel_nand_host *host)
{
struct mtd_info *mtd = &host->mtd;
@@ -1987,7 +1987,7 @@ static struct platform_driver atmel_nand_nfc_driver;
/*
* Probe for the NAND device.
*/
-static int __init atmel_nand_probe(struct platform_device *pdev)
+static int atmel_nand_probe(struct platform_device *pdev)
{
struct atmel_nand_host *host;
struct mtd_info *mtd;
@@ -2184,7 +2184,7 @@ err_nand_ioremap:
/*
* Remove a NAND device.
*/
-static int __exit atmel_nand_remove(struct platform_device *pdev)
+static int atmel_nand_remove(struct platform_device *pdev)
{
struct atmel_nand_host *host = platform_get_drvdata(pdev);
struct mtd_info *mtd = &host->mtd;
@@ -2270,7 +2270,8 @@ static struct platform_driver atmel_nand_nfc_driver = {
};
static struct platform_driver atmel_nand_driver = {
- .remove = __exit_p(atmel_nand_remove),
+ .probe = atmel_nand_probe,
+ .remove = atmel_nand_remove,
.driver = {
.name = "atmel_nand",
.owner = THIS_MODULE,
@@ -2278,7 +2279,7 @@ static struct platform_driver atmel_nand_driver = {
},
};
-module_platform_driver_probe(atmel_nand_driver, atmel_nand_probe);
+module_platform_driver(atmel_nand_driver);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Rick Bronson");
--
1.8.3.2
^ permalink raw reply related
* [PATCH 4/7] pcmcia: at91_cf: fix deferred probe from __init
From: Johan Hovold @ 2013-09-23 14:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-fbdev, linux-usb, Mark Brown, Nicolas Ferre, Johan Hovold,
linux-pcmcia, linux-mmc, linux-kernel, linux-mtd, Grant Likely,
Jean-Christophe PLAGNIOL-VILLARD
In-Reply-To: <1379946452-25649-1-git-send-email-jhovold@gmail.com>
Move probe out of __init section and don't use platform_driver_probe
which cannot be used with deferred probing.
Since commit e9354576 ("gpiolib: Defer failed gpio requests by default")
this driver might return -EPROBE_DEFER if a gpio_request fails.
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/pcmcia/at91_cf.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/pcmcia/at91_cf.c b/drivers/pcmcia/at91_cf.c
index b8f5acf..de24232 100644
--- a/drivers/pcmcia/at91_cf.c
+++ b/drivers/pcmcia/at91_cf.c
@@ -245,7 +245,7 @@ static int at91_cf_dt_init(struct platform_device *pdev)
}
#endif
-static int __init at91_cf_probe(struct platform_device *pdev)
+static int at91_cf_probe(struct platform_device *pdev)
{
struct at91_cf_socket *cf;
struct at91_cf_data *board = pdev->dev.platform_data;
@@ -354,7 +354,7 @@ fail0a:
return status;
}
-static int __exit at91_cf_remove(struct platform_device *pdev)
+static int at91_cf_remove(struct platform_device *pdev)
{
struct at91_cf_socket *cf = platform_get_drvdata(pdev);
@@ -404,14 +404,13 @@ static struct platform_driver at91_cf_driver = {
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(at91_cf_dt_ids),
},
- .remove = __exit_p(at91_cf_remove),
+ .probe = at91_cf_probe,
+ .remove = at91_cf_remove,
.suspend = at91_cf_suspend,
.resume = at91_cf_resume,
};
-/*--------------------------------------------------------------------------*/
-
-module_platform_driver_probe(at91_cf_driver, at91_cf_probe);
+module_platform_driver(at91_cf_driver);
MODULE_DESCRIPTION("AT91 Compact Flash Driver");
MODULE_AUTHOR("David Brownell");
--
1.8.3.2
^ permalink raw reply related
* [PATCH 5/7] usb: gadget: pxa25x_udc: fix deferred probe from __init
From: Johan Hovold @ 2013-09-23 14:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Grant Likely, Mark Brown, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pcmcia-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Johan Hovold, Eric Miao,
Russell King, Haojian Zhuang, Felipe Balbi
In-Reply-To: <1379946452-25649-1-git-send-email-jhovold-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Move probe out of __init section and don't use platform_driver_probe
which cannot be used with deferred probing.
Since commit e9354576 ("gpiolib: Defer failed gpio requests by default")
this driver might return -EPROBE_DEFER if a gpio_request fails.
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/usb/gadget/pxa25x_udc.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c
index cc92074..0ac6064 100644
--- a/drivers/usb/gadget/pxa25x_udc.c
+++ b/drivers/usb/gadget/pxa25x_udc.c
@@ -2054,7 +2054,7 @@ static struct pxa25x_udc memory = {
/*
* probe - binds to the platform device
*/
-static int __init pxa25x_udc_probe(struct platform_device *pdev)
+static int pxa25x_udc_probe(struct platform_device *pdev)
{
struct pxa25x_udc *dev = &memory;
int retval, irq;
@@ -2203,7 +2203,7 @@ static void pxa25x_udc_shutdown(struct platform_device *_dev)
pullup_off();
}
-static int __exit pxa25x_udc_remove(struct platform_device *pdev)
+static int pxa25x_udc_remove(struct platform_device *pdev)
{
struct pxa25x_udc *dev = platform_get_drvdata(pdev);
@@ -2294,7 +2294,8 @@ static int pxa25x_udc_resume(struct platform_device *dev)
static struct platform_driver udc_driver = {
.shutdown = pxa25x_udc_shutdown,
- .remove = __exit_p(pxa25x_udc_remove),
+ .probe = pxa25x_udc_probe,
+ .remove = pxa25x_udc_remove,
.suspend = pxa25x_udc_suspend,
.resume = pxa25x_udc_resume,
.driver = {
@@ -2303,7 +2304,7 @@ static struct platform_driver udc_driver = {
},
};
-module_platform_driver_probe(udc_driver, pxa25x_udc_probe);
+module_platform_driver(udc_driver);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_AUTHOR("Frank Becker, Robert Schwebel, David Brownell");
--
1.8.3.2
^ permalink raw reply related
* [PATCH 6/7] usb: phy: gpio-vbus: fix deferred probe from __init
From: Johan Hovold @ 2013-09-23 14:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-fbdev, linux-usb, Mark Brown, Johan Hovold, linux-pcmcia,
linux-mmc, linux-kernel, Felipe Balbi, linux-mtd, Grant Likely
In-Reply-To: <1379946452-25649-1-git-send-email-jhovold@gmail.com>
Move probe out of __init section and don't use platform_driver_probe
which cannot be used with deferred probing.
Since commit e9354576 ("gpiolib: Defer failed gpio requests by default")
and 04bf3011 ("regulator: Support driver probe deferral") this driver
might return -EPROBE_DEFER if a gpio_request or regulator_get fails.
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/usb/phy/phy-gpio-vbus-usb.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/phy/phy-gpio-vbus-usb.c b/drivers/usb/phy/phy-gpio-vbus-usb.c
index b2f29c9..02799a5 100644
--- a/drivers/usb/phy/phy-gpio-vbus-usb.c
+++ b/drivers/usb/phy/phy-gpio-vbus-usb.c
@@ -241,7 +241,7 @@ static int gpio_vbus_set_suspend(struct usb_phy *phy, int suspend)
/* platform driver interface */
-static int __init gpio_vbus_probe(struct platform_device *pdev)
+static int gpio_vbus_probe(struct platform_device *pdev)
{
struct gpio_vbus_mach_info *pdata = dev_get_platdata(&pdev->dev);
struct gpio_vbus_data *gpio_vbus;
@@ -349,7 +349,7 @@ err_gpio:
return err;
}
-static int __exit gpio_vbus_remove(struct platform_device *pdev)
+static int gpio_vbus_remove(struct platform_device *pdev)
{
struct gpio_vbus_data *gpio_vbus = platform_get_drvdata(pdev);
struct gpio_vbus_mach_info *pdata = dev_get_platdata(&pdev->dev);
@@ -398,8 +398,6 @@ static const struct dev_pm_ops gpio_vbus_dev_pm_ops = {
};
#endif
-/* NOTE: the gpio-vbus device may *NOT* be hotplugged */
-
MODULE_ALIAS("platform:gpio-vbus");
static struct platform_driver gpio_vbus_driver = {
@@ -410,10 +408,11 @@ static struct platform_driver gpio_vbus_driver = {
.pm = &gpio_vbus_dev_pm_ops,
#endif
},
- .remove = __exit_p(gpio_vbus_remove),
+ .probe = gpio_vbus_probe,
+ .remove = gpio_vbus_remove,
};
-module_platform_driver_probe(gpio_vbus_driver, gpio_vbus_probe);
+module_platform_driver(gpio_vbus_driver);
MODULE_DESCRIPTION("simple GPIO controlled OTG transceiver driver");
MODULE_AUTHOR("Philipp Zabel");
--
1.8.3.2
^ permalink raw reply related
* [PATCH 7/7] backlight: atmel-pwm-bl: fix deferred probe from __init
From: Johan Hovold @ 2013-09-23 14:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Grant Likely, Mark Brown, linux-kernel, linux-mmc, linux-mtd,
linux-pcmcia, linux-usb, linux-fbdev, Johan Hovold,
Richard Purdie, Jingoo Han, Jean-Christophe Plagniol-Villard
In-Reply-To: <1379946452-25649-1-git-send-email-jhovold@gmail.com>
Move probe out of __init section and don't use platform_driver_probe
which cannot be used with deferred probing.
Since commit e9354576 ("gpiolib: Defer failed gpio requests by default")
this driver might return -EPROBE_DEFER if a gpio_request fails.
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/video/backlight/atmel-pwm-bl.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/atmel-pwm-bl.c b/drivers/video/backlight/atmel-pwm-bl.c
index 0393d82..f7447f7 100644
--- a/drivers/video/backlight/atmel-pwm-bl.c
+++ b/drivers/video/backlight/atmel-pwm-bl.c
@@ -118,7 +118,7 @@ static const struct backlight_ops atmel_pwm_bl_ops = {
.update_status = atmel_pwm_bl_set_intensity,
};
-static int __init atmel_pwm_bl_probe(struct platform_device *pdev)
+static int atmel_pwm_bl_probe(struct platform_device *pdev)
{
struct backlight_properties props;
const struct atmel_pwm_bl_platform_data *pdata;
@@ -202,7 +202,7 @@ err_free_mem:
return retval;
}
-static int __exit atmel_pwm_bl_remove(struct platform_device *pdev)
+static int atmel_pwm_bl_remove(struct platform_device *pdev)
{
struct atmel_pwm_bl *pwmbl = platform_get_drvdata(pdev);
@@ -220,10 +220,11 @@ static struct platform_driver atmel_pwm_bl_driver = {
.name = "atmel-pwm-bl",
},
/* REVISIT add suspend() and resume() */
- .remove = __exit_p(atmel_pwm_bl_remove),
+ .probe = atmel_pwm_bl_probe,
+ .remove = atmel_pwm_bl_remove,
};
-module_platform_driver_probe(atmel_pwm_bl_driver, atmel_pwm_bl_probe);
+module_platform_driver(atmel_pwm_bl_driver);
MODULE_AUTHOR("Hans-Christian egtvedt <hans-christian.egtvedt@atmel.com>");
MODULE_DESCRIPTION("Atmel PWM backlight driver");
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 0/7] driver core: prevent deferred probe with platform_driver_probe
From: Sascha Hauer @ 2013-09-23 14:50 UTC (permalink / raw)
To: Johan Hovold
Cc: Greg Kroah-Hartman, Grant Likely, Mark Brown, linux-kernel,
linux-mmc, linux-mtd, linux-pcmcia, linux-usb, linux-fbdev
In-Reply-To: <1379946452-25649-1-git-send-email-jhovold@gmail.com>
On Mon, Sep 23, 2013 at 04:27:25PM +0200, Johan Hovold wrote:
> Deferred probing cannot be used with platform_driver_probe as by the
> time probing is retried either the driver has been unregistered or its
> probe function has been set to platform_drv_probe_fail.
>
> With commit e9354576 ("gpiolib: Defer failed gpio requests by default")
> the gpio subsystem started returning -EPROBE_DEFER, which in turn
> several platform drivers using platform_driver_probe return to driver
> core. Other subsystems (e.g. regulator) has since started doing the
> same.
>
> The first patch in this series prevents platform drivers using
> platform_driver_probe from requesting probe deferral while warning that
> it is not supported.
>
> The remaining patches move six platform-driver probe functions that rely
> on gpio_request out of __init. There are likely other probe functions
> that might return -EPROBE_DEFER and should be moved out of __init as
> well.
As usually when I read this I wonder why platform_driver_probe exists
anyway. The only advantage I can think off is that the probe functions
are in __init and thus can be disposed of later. Now you remove the
__init annotations from these probe functions. Wouldn't it be better to
convert the drivers to regular platform_driver_register instead?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] s3fb: fix error return code in s3_pci_probe()
From: Wei Yongjun @ 2013-09-23 15:00 UTC (permalink / raw)
To: linux-fbdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Fix to return -EINVAL when virtual vertical size smaller than real
instead of 0, as done elsewhere in this function. Also remove dup code.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/video/s3fb.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/video/s3fb.c b/drivers/video/s3fb.c
index 47ca86c..d838ba8 100644
--- a/drivers/video/s3fb.c
+++ b/drivers/video/s3fb.c
@@ -1336,14 +1336,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
(info->var.bits_per_pixel * info->var.xres_virtual);
if (info->var.yres_virtual < info->var.yres) {
dev_err(info->device, "virtual vertical size smaller than real\n");
- goto err_find_mode;
- }
-
- /* maximize virtual vertical size for fast scrolling */
- info->var.yres_virtual = info->fix.smem_len * 8 /
- (info->var.bits_per_pixel * info->var.xres_virtual);
- if (info->var.yres_virtual < info->var.yres) {
- dev_err(info->device, "virtual vertical size smaller than real\n");
+ rc = -EINVAL;
goto err_find_mode;
}
^ permalink raw reply related
* [PATCH] neofb: fix error return code in neofb_probe()
From: Wei Yongjun @ 2013-09-23 15:00 UTC (permalink / raw)
To: linux-fbdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/video/neofb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/neofb.c b/drivers/video/neofb.c
index 891b0bf..2a3e5bd 100644
--- a/drivers/video/neofb.c
+++ b/drivers/video/neofb.c
@@ -2075,6 +2075,7 @@ static int neofb_probe(struct pci_dev *dev, const struct pci_device_id *id)
if (!fb_find_mode(&info->var, info, mode_option, NULL, 0,
info->monspecs.modedb, 16)) {
printk(KERN_ERR "neofb: Unable to find usable video mode.\n");
+ err = -EINVAL;
goto err_map_video;
}
@@ -2097,7 +2098,8 @@ static int neofb_probe(struct pci_dev *dev, const struct pci_device_id *id)
info->fix.smem_len >> 10, info->var.xres,
info->var.yres, h_sync / 1000, h_sync % 1000, v_sync);
- if (fb_alloc_cmap(&info->cmap, 256, 0) < 0)
+ err = fb_alloc_cmap(&info->cmap, 256, 0);
+ if (err < 0)
goto err_map_video;
err = register_framebuffer(info);
^ permalink raw reply related
* Re: [PATCH 0/7] driver core: prevent deferred probe with platform_driver_probe
From: Johan Hovold @ 2013-09-23 15:20 UTC (permalink / raw)
To: Sascha Hauer
Cc: Johan Hovold, Greg Kroah-Hartman, Grant Likely, Mark Brown,
linux-kernel, linux-mmc, linux-mtd, linux-pcmcia, linux-usb,
linux-fbdev
In-Reply-To: <20130923145029.GV30088@pengutronix.de>
On Mon, Sep 23, 2013 at 04:50:29PM +0200, Sascha Hauer wrote:
> On Mon, Sep 23, 2013 at 04:27:25PM +0200, Johan Hovold wrote:
> > Deferred probing cannot be used with platform_driver_probe as by the
> > time probing is retried either the driver has been unregistered or its
> > probe function has been set to platform_drv_probe_fail.
> >
> > With commit e9354576 ("gpiolib: Defer failed gpio requests by default")
> > the gpio subsystem started returning -EPROBE_DEFER, which in turn
> > several platform drivers using platform_driver_probe return to driver
> > core. Other subsystems (e.g. regulator) has since started doing the
> > same.
> >
> > The first patch in this series prevents platform drivers using
> > platform_driver_probe from requesting probe deferral while warning that
> > it is not supported.
> >
> > The remaining patches move six platform-driver probe functions that rely
> > on gpio_request out of __init. There are likely other probe functions
> > that might return -EPROBE_DEFER and should be moved out of __init as
> > well.
>
> As usually when I read this I wonder why platform_driver_probe exists
> anyway. The only advantage I can think off is that the probe functions
> are in __init and thus can be disposed of later. Now you remove the
> __init annotations from these probe functions. Wouldn't it be better to
> convert the drivers to regular platform_driver_register instead?
Perhaps that paragraph was a bit unclear: I move them out of __init
_and_ use platform_driver_register instead of platform_driver_probe as
well.
Johan
^ permalink raw reply
* Re: [PATCH 0/7] driver core: prevent deferred probe with platform_driver_probe
From: Sascha Hauer @ 2013-09-23 15:24 UTC (permalink / raw)
To: Johan Hovold
Cc: linux-fbdev, linux-usb, Mark Brown, Greg Kroah-Hartman,
linux-pcmcia, linux-mmc, linux-kernel, linux-mtd, Grant Likely
In-Reply-To: <20130923152018.GB1454@localhost>
On Mon, Sep 23, 2013 at 05:20:18PM +0200, Johan Hovold wrote:
> On Mon, Sep 23, 2013 at 04:50:29PM +0200, Sascha Hauer wrote:
> > On Mon, Sep 23, 2013 at 04:27:25PM +0200, Johan Hovold wrote:
> > > Deferred probing cannot be used with platform_driver_probe as by the
> > > time probing is retried either the driver has been unregistered or its
> > > probe function has been set to platform_drv_probe_fail.
> > >
> > > With commit e9354576 ("gpiolib: Defer failed gpio requests by default")
> > > the gpio subsystem started returning -EPROBE_DEFER, which in turn
> > > several platform drivers using platform_driver_probe return to driver
> > > core. Other subsystems (e.g. regulator) has since started doing the
> > > same.
> > >
> > > The first patch in this series prevents platform drivers using
> > > platform_driver_probe from requesting probe deferral while warning that
> > > it is not supported.
> > >
> > > The remaining patches move six platform-driver probe functions that rely
> > > on gpio_request out of __init. There are likely other probe functions
> > > that might return -EPROBE_DEFER and should be moved out of __init as
> > > well.
> >
> > As usually when I read this I wonder why platform_driver_probe exists
> > anyway. The only advantage I can think off is that the probe functions
> > are in __init and thus can be disposed of later. Now you remove the
> > __init annotations from these probe functions. Wouldn't it be better to
> > convert the drivers to regular platform_driver_register instead?
>
> Perhaps that paragraph was a bit unclear: I move them out of __init
> _and_ use platform_driver_register instead of platform_driver_probe as
> well.
Oh yes, I should have looked closer. Sorry for the noise.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v3 1/2] video: ARM CLCD: Add DT support
From: Stephen Warren @ 2013-09-23 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1379522363.9244.12.camel@hornet>
On 09/18/2013 10:39 AM, Pawel Moll wrote:
> On Tue, 2013-09-17 at 22:34 +0100, Stephen Warren wrote:
>>> On Tue, 2013-09-17 at 17:36 +0100, Pawel Moll wrote:
>>>> On Mon, 2013-09-16 at 20:52 +0100, Stephen Warren wrote:
>>>>>> +- arm,pl11x,panel-data-pads: array of 24 cells, each of them describing
>>>>>> + a function of one of the CLD pads,
>>>>>> + starting from 0 up to 23; each pad can
>>>>>> + be described by one of the following values:
>>>>>> + - 0: reserved (not connected)
>>>>>> + - 0x100-0x107: color upper STN panel data 0 to 7
>>>>> ...
>>>>>
>>>>> I assume those are the raw values that go into the HW?
>>>
>>> No, they can be considered "labels", defining the way pads are used
>>> (wired). Then, basing on this information, the driver is configuring the
>>> cell, eg. selecting STN or TFT mode (thus switching the output between
>>> panel formatter and raw RGB data source).
>>
>> Oh, why not just use the raw values from the HW registers for this?
>
> How do you mean? Based on the the way the "LCD data" lines are wired up,
> the driver has to decide whether to select STN (LCDControl &= ~(1<<5))
> or TFT mode (LCDControl |= 1<<5), then figures out what memory pixel
> formats are possible (based on this will set LCDControl[3..1] in
> runtime, depending on the mode selected by the user). There isn't a
> separate register as such configuring output pads. It's just the way
> they can used depends on the way they're wired up.
It sounds like you could just put LCDControl & 0x2e in the DT rather
than using values such as 0x100..0x107, which don't appear to match the
register format you mentioned above.
^ permalink raw reply
* Re: [PATCH v3 1/2] video: ARM CLCD: Add DT support
From: Russell King - ARM Linux @ 2013-09-23 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52406646.709@wwwdotorg.org>
On Mon, Sep 23, 2013 at 10:03:18AM -0600, Stephen Warren wrote:
> It sounds like you could just put LCDControl & 0x2e in the DT rather
> than using values such as 0x100..0x107, which don't appear to match the
> register format you mentioned above.
No. Platforms which route the outputs to something like VGA or HDMI can
change the framebuffer format. Your suggestions is far too restrictive.
^ permalink raw reply
* [PATCH] video: mmp: drop needless devm cleanup
From: Uwe Kleine-König @ 2013-09-23 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1379951159-8294-1-git-send-email-u.kleine-koenig@pengutronix.de>
The nice thing about devm_* is that the driver doesn't need to free the
resources but the driver core takes care about that. This also
simplifies the error path quite a bit and removes the wrong check for a
clock pointer being NULL.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/video/mmp/hw/mmp_ctrl.c | 17 ++---------------
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/video/mmp/hw/mmp_ctrl.c b/drivers/video/mmp/hw/mmp_ctrl.c
index 75dca19..6ac7552 100644
--- a/drivers/video/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/mmp/hw/mmp_ctrl.c
@@ -514,7 +514,7 @@ static int mmphw_probe(struct platform_device *pdev)
if (IS_ERR(ctrl->clk)) {
dev_err(ctrl->dev, "unable to get clk %s\n", mi->clk_name);
ret = -ENOENT;
- goto failed_get_clk;
+ goto failed;
}
clk_prepare_enable(ctrl->clk);
@@ -551,21 +551,8 @@ failed_path_init:
path_deinit(path_plat);
}
- if (ctrl->clk) {
- devm_clk_put(ctrl->dev, ctrl->clk);
- clk_disable_unprepare(ctrl->clk);
- }
-failed_get_clk:
- devm_free_irq(ctrl->dev, ctrl->irq, ctrl);
+ clk_disable_unprepare(ctrl->clk);
failed:
- if (ctrl) {
- if (ctrl->reg_base)
- devm_iounmap(ctrl->dev, ctrl->reg_base);
- devm_release_mem_region(ctrl->dev, res->start,
- resource_size(res));
- devm_kfree(ctrl->dev, ctrl);
- }
-
dev_err(&pdev->dev, "device init failed\n");
return ret;
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH] video: mmp: drop needless devm cleanup
From: Russell King - ARM Linux @ 2013-09-23 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1379952790-13202-1-git-send-email-u.kleine-koenig@pengutronix.de>
On Mon, Sep 23, 2013 at 06:13:10PM +0200, Uwe Kleine-König wrote:
> The nice thing about devm_* is that the driver doesn't need to free the
> resources but the driver core takes care about that. This also
> simplifies the error path quite a bit and removes the wrong check for a
> clock pointer being NULL.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/video/mmp/hw/mmp_ctrl.c | 17 ++---------------
> 1 file changed, 2 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/video/mmp/hw/mmp_ctrl.c b/drivers/video/mmp/hw/mmp_ctrl.c
> index 75dca19..6ac7552 100644
> --- a/drivers/video/mmp/hw/mmp_ctrl.c
> +++ b/drivers/video/mmp/hw/mmp_ctrl.c
> @@ -514,7 +514,7 @@ static int mmphw_probe(struct platform_device *pdev)
> if (IS_ERR(ctrl->clk)) {
> dev_err(ctrl->dev, "unable to get clk %s\n", mi->clk_name);
> ret = -ENOENT;
> - goto failed_get_clk;
> + goto failed;
> }
> clk_prepare_enable(ctrl->clk);
>
> @@ -551,21 +551,8 @@ failed_path_init:
> path_deinit(path_plat);
> }
>
> - if (ctrl->clk) {
> - devm_clk_put(ctrl->dev, ctrl->clk);
> - clk_disable_unprepare(ctrl->clk);
And this patch also fixes the above: disabling/unpreparing _after_ putting
the thing - which was quite silly... :)
^ permalink raw reply
* Re: [PATCH v3 1/2] video: ARM CLCD: Add DT support
From: Stephen Warren @ 2013-09-23 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130923160640.GT12758@n2100.arm.linux.org.uk>
On 09/23/2013 10:06 AM, Russell King - ARM Linux wrote:
> On Mon, Sep 23, 2013 at 10:03:18AM -0600, Stephen Warren wrote:
>> It sounds like you could just put LCDControl & 0x2e in the DT rather
>> than using values such as 0x100..0x107, which don't appear to match the
>> register format you mentioned above.
>
> No. Platforms which route the outputs to something like VGA or HDMI can
> change the framebuffer format. Your suggestions is far too restrictive.
Surely the DT should describe the HW setup only. Usually, a particular
HW setup can support multiple different framebuffer formats. Hence, the
DT wouldn't/shouldn't imply anything about the framebuffer format, but
simply which wires are connected to the LCD.
^ permalink raw reply
* Re: [PATCH v3 1/2] video: ARM CLCD: Add DT support
From: Russell King - ARM Linux @ 2013-09-23 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52406C97.3010800@wwwdotorg.org>
On Mon, Sep 23, 2013 at 10:30:15AM -0600, Stephen Warren wrote:
> On 09/23/2013 10:06 AM, Russell King - ARM Linux wrote:
> > On Mon, Sep 23, 2013 at 10:03:18AM -0600, Stephen Warren wrote:
> >> It sounds like you could just put LCDControl & 0x2e in the DT rather
> >> than using values such as 0x100..0x107, which don't appear to match the
> >> register format you mentioned above.
> >
> > No. Platforms which route the outputs to something like VGA or HDMI can
> > change the framebuffer format. Your suggestions is far too restrictive.
>
> Surely the DT should describe the HW setup only. Usually, a particular
> HW setup can support multiple different framebuffer formats. Hence, the
> DT wouldn't/shouldn't imply anything about the framebuffer format, but
> simply which wires are connected to the LCD.
Quite, and putting the contents of the LCDControl register - even just
bits 5 and 3-1 results in you having to modify the DT and reboot the
kernel just to change the framebuffer format. That's why I'm objecting
to your comment.
When I rewrote the way the CLCD driver handles the various panels, I did
it with full information on how the hardware was being used at that time.
That is precisely why I came up with the capability system, where we
describe which formats the hardware can support up to the interface,
separately from the formats which the attached device - be it a LCD
panel, VGA socket or HDMI socket - can support. The resulting set of
formats which can be used are a union of these.
Suggesting that we can do this by putting register values into DT is
completely wrong - if that were possible, I wouldn't have come up with
this capability system to sort this mess out in the first place - I
could've just hard-coded the register values and said to everyone
"tough, on these platforms you only get RGB444 support and that's it."
^ permalink raw reply
* Re: [PATCH 4/7] pcmcia: at91_cf: fix deferred probe from __init
From: Nicolas Ferre @ 2013-09-23 16:53 UTC (permalink / raw)
To: Johan Hovold, Greg Kroah-Hartman
Cc: Grant Likely, Mark Brown, linux-kernel, linux-mmc, linux-mtd,
linux-pcmcia, linux-usb, linux-fbdev,
Jean-Christophe PLAGNIOL-VILLARD
In-Reply-To: <1379946452-25649-5-git-send-email-jhovold@gmail.com>
On 23/09/2013 16:27, Johan Hovold :
> Move probe out of __init section and don't use platform_driver_probe
> which cannot be used with deferred probing.
>
> Since commit e9354576 ("gpiolib: Defer failed gpio requests by default")
> this driver might return -EPROBE_DEFER if a gpio_request fails.
>
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks Johan.
> Signed-off-by: Johan Hovold <jhovold@gmail.com>
> ---
> drivers/pcmcia/at91_cf.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pcmcia/at91_cf.c b/drivers/pcmcia/at91_cf.c
> index b8f5acf..de24232 100644
> --- a/drivers/pcmcia/at91_cf.c
> +++ b/drivers/pcmcia/at91_cf.c
> @@ -245,7 +245,7 @@ static int at91_cf_dt_init(struct platform_device *pdev)
> }
> #endif
>
> -static int __init at91_cf_probe(struct platform_device *pdev)
> +static int at91_cf_probe(struct platform_device *pdev)
> {
> struct at91_cf_socket *cf;
> struct at91_cf_data *board = pdev->dev.platform_data;
> @@ -354,7 +354,7 @@ fail0a:
> return status;
> }
>
> -static int __exit at91_cf_remove(struct platform_device *pdev)
> +static int at91_cf_remove(struct platform_device *pdev)
> {
> struct at91_cf_socket *cf = platform_get_drvdata(pdev);
>
> @@ -404,14 +404,13 @@ static struct platform_driver at91_cf_driver = {
> .owner = THIS_MODULE,
> .of_match_table = of_match_ptr(at91_cf_dt_ids),
> },
> - .remove = __exit_p(at91_cf_remove),
> + .probe = at91_cf_probe,
> + .remove = at91_cf_remove,
> .suspend = at91_cf_suspend,
> .resume = at91_cf_resume,
> };
>
> -/*--------------------------------------------------------------------------*/
> -
> -module_platform_driver_probe(at91_cf_driver, at91_cf_probe);
> +module_platform_driver(at91_cf_driver);
>
> MODULE_DESCRIPTION("AT91 Compact Flash Driver");
> MODULE_AUTHOR("David Brownell");
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()
From: Russell King - ARM Linux @ 2013-09-23 18:42 UTC (permalink / raw)
To: Alan Stern
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Alexander Shishkin,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Kukjin Kim,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Solarflare linux maintainers, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman
In-Reply-To: <Pine.LNX.4.44L0.1309231418030.1348-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
> On Thu, 19 Sep 2013, Russell King wrote:
>
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only arch and bus code should access this
> > member directly.
> >
> > Convert all direct write accesses to using the correct API.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> > diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
> > index f6b790c..5b0cd2d 100644
> > --- a/drivers/usb/host/ehci-platform.c
> > +++ b/drivers/usb/host/ehci-platform.c
>
> > @@ -91,8 +91,9 @@ static int ehci_platform_probe(struct platform_device *dev)
> > dev->dev.platform_data = &ehci_platform_defaults;
> > if (!dev->dev.dma_mask)
> > dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
> > - if (!dev->dev.coherent_dma_mask)
> > - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> > + err = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
> > + if (err)
> > + return err;
> >
> > pdata = dev_get_platdata(&dev->dev);
>
> ehci-platform.c is a generic file, intended for use by multiple
> platforms. Is it not possible that on some platforms, the arch or bus
> code may already have initialized the DMA masks? Isn't something like
> this (i.e., DMA bindings) planned for Device Tree?
>
> By eliminating the tests above and calling dma_set_coherent_mask or
> dma_coerce_mask_and_coherent unconditionally, this patch (and the next)
> would overwrite those initial settings.
>
> I don't know to what extent the same may be true for the other,
> platform-specific, drivers changed by this patch. But it's something
> to be aware of.
Please check the DMA API documentation:
==For correct operation, you must interrogate the kernel in your device
probe routine to see if the DMA controller on the machine can properly
support the DMA addressing limitation your device has. It is good
style to do this even if your device holds the default setting,
because this shows that you did think about these issues wrt. your
device.
The query is performed via a call to dma_set_mask():
int dma_set_mask(struct device *dev, u64 mask);
The query for consistent allocations is performed via a call to
dma_set_coherent_mask():
int dma_set_coherent_mask(struct device *dev, u64 mask);
==
So, All drivers which use DMA are supposed to issue the appropriate
calls to check the DMA masks before they perform DMA, even if the
"default" is correct.
And yes, this is all part of sorting out the DT mess - we should
start not from the current mess (which is really totally haphazard)
but from the well established position of how the DMA API _should_
be used. What that means is that all drivers should be issuing
these calls as appropriate today.
The default mask setup when the device is created is just that -
it's a default mask, and it should not be used to decide anything
about the device. That's something which the driver should compute
on its own accord and then inform the various other layers via the
appropriate call.
Remember, on PCI, even when we have 64-bit, we do not declare PCI
devices with a 64-bit DMA mask: that's up to PCI device drivers to
_try_ to set a 64-bit DMA mask, which when successful _allows_ them
to use 64-bit DMA. If it fails, they have to only use 32-bit. If
they want a smaller mask, the _driver_ has to set the smaller mask,
not the device creating code.
The reason we're into this (particularly on ARM) is that we got lazy
because we could get by with declaring a DMA mask at device creation
time, since all devices were statically declared. Now it's time to
get rid of those old lazy ways and start doing things correctly and
to the requirements of the APIs.
^ permalink raw reply
* Re: [PATCH v3 1/2] video: ARM CLCD: Add DT support
From: Stephen Warren @ 2013-09-23 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130923164302.GW12758@n2100.arm.linux.org.uk>
On 09/23/2013 10:43 AM, Russell King - ARM Linux wrote:
> On Mon, Sep 23, 2013 at 10:30:15AM -0600, Stephen Warren wrote:
>> On 09/23/2013 10:06 AM, Russell King - ARM Linux wrote:
>>> On Mon, Sep 23, 2013 at 10:03:18AM -0600, Stephen Warren wrote:
>>>> It sounds like you could just put LCDControl & 0x2e in the DT rather
>>>> than using values such as 0x100..0x107, which don't appear to match the
>>>> register format you mentioned above.
>>>
>>> No. Platforms which route the outputs to something like VGA or HDMI can
>>> change the framebuffer format. Your suggestions is far too restrictive.
>>
>> Surely the DT should describe the HW setup only. Usually, a particular
>> HW setup can support multiple different framebuffer formats. Hence, the
>> DT wouldn't/shouldn't imply anything about the framebuffer format, but
>> simply which wires are connected to the LCD.
>
> Quite, and putting the contents of the LCDControl register - even just
> bits 5 and 3-1 results in you having to modify the DT and reboot the
> kernel just to change the framebuffer format. That's why I'm objecting
> to your comment.
Oh, so these particular registers define both the output signal muxing
for the pins and the FB data format? If so, yes it's not correct to put
the register values into DT. I assumed that the HW would have a separate
representation of those two concepts, in different registers or at least
different fields in the same register. If not, there is indeed no choice
but to make up some arbitrary values to represent just the pinmuxing :-(
^ permalink raw reply
* Re: [PATCH v3 1/2] video: ARM CLCD: Add DT support
From: Russell King - ARM Linux @ 2013-09-23 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52409C0C.1000406@wwwdotorg.org>
On Mon, Sep 23, 2013 at 01:52:44PM -0600, Stephen Warren wrote:
> On 09/23/2013 10:43 AM, Russell King - ARM Linux wrote:
> > On Mon, Sep 23, 2013 at 10:30:15AM -0600, Stephen Warren wrote:
> >> On 09/23/2013 10:06 AM, Russell King - ARM Linux wrote:
> >>> On Mon, Sep 23, 2013 at 10:03:18AM -0600, Stephen Warren wrote:
> >>>> It sounds like you could just put LCDControl & 0x2e in the DT rather
> >>>> than using values such as 0x100..0x107, which don't appear to match the
> >>>> register format you mentioned above.
> >>>
> >>> No. Platforms which route the outputs to something like VGA or HDMI can
> >>> change the framebuffer format. Your suggestions is far too restrictive.
> >>
> >> Surely the DT should describe the HW setup only. Usually, a particular
> >> HW setup can support multiple different framebuffer formats. Hence, the
> >> DT wouldn't/shouldn't imply anything about the framebuffer format, but
> >> simply which wires are connected to the LCD.
> >
> > Quite, and putting the contents of the LCDControl register - even just
> > bits 5 and 3-1 results in you having to modify the DT and reboot the
> > kernel just to change the framebuffer format. That's why I'm objecting
> > to your comment.
>
> Oh, so these particular registers define both the output signal muxing
> for the pins and the FB data format? If so, yes it's not correct to put
> the register values into DT. I assumed that the HW would have a separate
> representation of those two concepts, in different registers or at least
> different fields in the same register. If not, there is indeed no choice
> but to make up some arbitrary values to represent just the pinmuxing :-(
Unfortunately not. Parameters such as TFT, and dual can be specified by
DT, but the difficulty comes with the pixel wiring.
With a PL110 in TFT mode, the representation of which signals represent
what are a function of the selected BPP:
Panel:
24bpp: Blue[7:0]=CLD[23:16] Green[7:0]=CLD[15:8] Red[7:0]=CLD[7:0]
18bpp: Blue[4:0]=CLD[17:13] Green[4:0]=CLD[11:7] Red[4:0]=CLD[5:1]
Intensity = CLD[12], CLD[6], CLD[0]
24bpp signalling is used when a framebuffer format of 24bpp mode is
selected, otherwise the 18bpp signalling is used.
The PL110 in 16bpp does not support for anything but 1555 mode when wired
up as above, but some people want 565 mode. That's achievable (and is
used on Versatile) by adjusting the wiring via a FPGA:
Blue = CLD[12,17:14] Green = [13,11:7] Blue = CLD[5:1]
This gives us the RGB565 mode on PL110. Now, consider a platform which
wants to use this - if the panel is wired up directly to the CLCD like
that, then it will only support RGB565.
If you were connecting a 4:4:4 panel, a similar thing is possible, and
may be preferable to have the standard framebuffer format in memory to
do this.
So, the supportable framebuffer foramts depends entirely on how the
display is wired up to the controller.
Now, for PL111, things are simpler - it supports 5551, 565 and 444 modes
natively, so supports all the standard framebuffer formats. The output
wiring is different and more sane. In this case, CLD[23] is always the
MSB blue bit, CLD[15] is always the MSB green bit, and CLD[7] is always
the MSB red bit. So here, the wiring matters very much less.
However, even here the "capabilities" play a role. Does driving a TFT
444 panel being driven in 24-bit mode make sense? Yes, it'll work but
the least significant four bits are lost. What about the other way
around? A TFT 888 panel in 12bpp mode? Well, in that case the least
sigificant four bits are marked up as "reserved" - and even if they are
held at zero, you're going to lose some colour range on the panel because
white will be equivalent to colour f0f0f0 not ffffff.
Hence, we probably want to have even here some way to say "I want this
hardware to only support framebuffer formats of X".
My feeling is that even though these capabilities are not part of the
actual hardware spec, they're well worth implementing directly in DT as
they're describing what the *hardware* as a whole is capable of.
Moreover, I created the capabilities purely as a way to describe what
the hardware and panel are capable of. Isn't that what DT is all about
too?
^ permalink raw reply
* Re: [PATCH 1/2] backlight: l4f00242t03: Remove redundant spi_set_drvdata
From: Jingoo Han @ 2013-09-24 5:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1379659133-18799-1-git-send-email-sachin.kamat@linaro.org>
On Friday, September 20, 2013 3:39 PM, Sachin Kamat wrote:
>
> Driver core sets driver data to NULL upon failure or remove.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Jingoo Han <jg1.han@samsung.com>
It looks good.
Thank you for sending the patch.
Best regards,
Jingoo Han
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox